Optimierung der Fahrzeugdiagnose durch eine cloudbasierte Methode zur Identifikation der Datennetze mit künstlicher Intelligenz 3658431121, 9783658431129, 9783658431136

Table of contents :
Vorwort
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
Symbolverzeichnis
Kurzfassung
Abstract
1 Einleitung
1.1 Motivation und Ziele
1.2 Forschungsfrage
1.3 Aufbau der Arbeit
2 Grundlagen
2.1 Entwicklungszyklen in der Fahrzeugindustrie
2.2 Fahrzeug-Netzwerk-Architektur
2.2.1 Einführung in Bussysteme
2.2.2 Einführung in Steuergeräte
2.3 On-Board-/Off-Board-Diagnose
2.3.1 Einführung in Protokolle
2.3.2 Einführung in die Identifizierung
2.4 Remote-Diagnose
2.4.1 Big Data
2.4.2 Cloud-Technologien
2.4.3 IoT-Messwerkzeuge
3 Testablauferstellung in der Fahrzeugentwicklung
3.1 Manuelle Erstellung
3.2 Stand der Entwicklung und Gründe für eine automatische Erstellung
3.3 Einfluss der Fahrzeug-Netzwerk-Architektur auf die Testablaufgenerierung
3.4 Zusammenfassung und Chancen der automatischen Erstellung
4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur
4.1 Definition der Anforderungen
4.2 Prozess zur Identifikation der physikalischen Netzwerkstruktur
4.3 Datenerhebung und Transformation für eine ML-Datenbasis
4.4 Methode zur Steuergeräte- und Variantenidentifizierung
4.5 Vergleich der Machine-Learning-Modelle
4.5.1 VCI-Identifikation
4.5.2 DIAG-Identifikation
4.5.3 ECU-Identifikation
4.6 Zusammenfassung und Ergebnis der Methode
5 Anwendung und praktischer Nachweis
5.1 Systemüberblick
5.2 Bedatungskreislauf anhand der Diagnose-Plattform
5.3 Ergebnisse
6 Zusammenfassung
6.1 Generalisierung der Methode
6.2 Ausblick
Literaturverzeichnis
Glossar
Anhang
A. Scatter-Plot der reduzierten Datenbasis
B. Quellcode
B.1 Skriptdurchlaufzeit abschätzen über Normalverteilung
B.2 Vergleich der Korrelations-Koeffizienten
B.3 Vergleich der ML-Modelle in Bezug zur Diagnose-Detektion
B.4 Docker-CI-Template für die Software-Architektur

Citation preview

Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart

Ralf Thomas Lutchen

Optimierung der Fahrzeugdiagnose durch eine cloudbasierte Methode zur Identifikation der Datennetze mit künstlicher Intelligenz

Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart Reihe herausgegeben von Michael Bargende, Stuttgart, Deutschland Hans-Christian Reuss, Stuttgart, Deutschland Jochen Wiedemann, Stuttgart, Deutschland

Das Institut für Fahrzeugtechnik Stuttgart (IFS) an der Universität Stuttgart erforscht, entwickelt, appliziert und erprobt, in enger Zusammenarbeit mit der Industrie, Elemente bzw. Technologien aus dem Bereich moderner Fahrzeugkonzepte. Das Institut gliedert sich in die drei Bereiche Kraftfahrwesen, Fahrzeugantriebe und Kraftfahrzeug-Mechatronik. Aufgabe dieser Bereiche ist die Ausarbeitung des Themengebietes im Prüfstandsbetrieb, in Theorie und Simulation. Schwerpunkte des Kraftfahrwesens sind hierbei die Aerodynamik, Akustik (NVH), Fahrdynamik und Fahrermodellierung, Leichtbau, Sicherheit, Kraftübertragung sowie Energie und Thermomanagement – auch in Verbindung mit hybriden und batterieelektrischen Fahrzeugkonzepten. Der Bereich Fahrzeugantriebe widmet sich den Themen Brennverfahrensentwicklung einschließlich Regelungs- und Steuerungskonzeptionen bei zugleich minimierten Emissionen, komplexe Abgasnachbehandlung, Aufladesysteme und -strategien, Hybridsysteme und Betriebsstrategien sowie mechanisch-akustischen Fragestellungen. Themen der Kraftfahrzeug-Mechatronik sind die Antriebsstrangregelung/ Hybride, Elektromobilität, Bordnetz und Energiemanagement, Funktions- und Softwareentwicklung sowie Test und Diagnose. Die Erfüllung dieser Aufgaben wird prüfstandsseitig neben vielem anderen unterstützt durch 19 Motorenprüfstände, zwei Rollenprüfstände, einen 1:1-Fahrsimulator, einen Antriebsstrangprüfstand, einen Thermowindkanal sowie einen 1:1-Aeroakustikwindkanal. Die wissenschaftliche Reihe „Fahrzeugtechnik Universität Stuttgart“ präsentiert über die am Institut entstandenen Promotionen die hervorragenden Arbeitsergebnisse der Forschungstätigkeiten am IFS. Reihe herausgegeben von Prof. Dr.-Ing. Michael Bargende Lehrstuhl Fahrzeugantriebe Institut für Fahrzeugtechnik Stuttgart Universität Stuttgart Stuttgart, Deutschland Prof. Dr.-Ing. Hans-Christian Reuss Lehrstuhl Kraftfahrzeugmechatronik Institut für Fahrzeugtechnik Stuttgart Universität Stuttgart Stuttgart, Deutschland

Prof. Dr.-Ing. Jochen Wiedemann Lehrstuhl Kraftfahrwesen Institut für Fahrzeugtechnik Stuttgart Universität Stuttgart Stuttgart, Deutschland

Ralf Thomas Lutchen

Optimierung der Fahrzeugdiagnose durch eine cloudbasierte Methode zur Identifikation der Datennetze mit künstlicher Intelligenz

Ralf Thomas Lutchen IFS, Fakultät 7, Lehrstuhl für Kraftfahrzeugmechatronik Universität Stuttgart Stuttgart, Deutschland Zugl.: Dissertation Universität Stuttgart, 2023 D93

ISSN 2567-0042 ISSN 2567-0352 (electronic) Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart ISBN 978-3-658-43112-9 ISBN 978-3-658-43113-6 (eBook) https://doi.org/10.1007/978-3-658-43113-6 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Planung/Lektorat: Carina Reibold Springer Vieweg ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH und ist ein Teil von Springer Nature. Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany Das Papier dieses Produkts ist recyclebar.

Vorwort Die vorliegende Arbeit entstand während meiner Tätigkeit als wissenschaftlicher Mitarbeiter am Forschungsinstitut für Kraftfahrwesen und Fahrzeugmotoren Stuttgart (FKFS). Die Ergebnisse sind geprägt und motiviert durch zwei unterschiedliche Projekte, an denen ich mitgewirkt habe. Zum einen ein Projekt als DiagnosesystemExperte für die Mercedes Benz AG ehemals Daimler AG und zum anderen als Software-Architekt für die Entwicklung einer Backend-Plattform für das RemOte Systeme für neue Interaktive Lösungen (ROSI)-Projekt. Mein besonderer Dank gilt in erster Linie Herrn Prof. Dr.-Ing. H.-C. Reuss für das Ermöglichen dieser Promotion, das mir entgegengebrachte Vertrauen sowie die Betreuung und Förderung meiner Arbeit. Er ist Leiter des Lehrstuhls Kraftfahrzeugmechatronik am Institut für Fahrzeugtechnik Stuttgart (IFS) der Universität Stuttgart sowie Vorstandsmitglied des FKFS. Herrn Prof. Dr.-Ing. K.-L. Krieger danke ich für das Interesse an dieser Arbeit sowie die freundliche Übernahme der Mitbericht. Er ist Leiter des Lehrstuhls Elektro- und Informationstechnik des Institut für Theoretische Elektrotechnik und Mikroelektronik (ITEM) der Universität Bremen. Besonders bedanken möchte ich mich bei meinem Bereichsleiter Dr.-Ing. Michael Grimm sowie meinen Kollegen Andreas Krätschmer, Lorenz Görne sowie Kordian Komarek für die fachlichen Diskussionen, welche maßgeblich zur erfolgreichen Umsetzung dieser Arbeit beigetragen haben. Ein weiterer Dank gilt allen meinen Kolleginnen und Kollegen am FKFS für die tolle Arbeitsatmosphäre und das inspirierende Miteinander. Außerdem bedanke ich mich bei meinem Bruder Uwe Lutchen und seiner Frau Marita Lutchen für die unablässige Unterstützung und Beratung sowie die Korrektur aller meiner schriftlichen Ausfertigungen inklusive dieser. Ohne euch beide wäre das alles nicht möglich gewesen. Meinen Freunden Marco Werz und Wolfgang Herberger danke ich nicht zuletzt für die sorgfältige Durchsicht und Korrektur dieser Arbeit. Zudem danke ich all meinen Studentinnen und Studenten, welche durch ihre Abschlussarbeiten und Diskussionen einen Beitrag zur Entstehung dieser Arbeit ge-

VI

Vorwort

leistet haben. Ihnen wünsche ich weiterhin viel Erfolg auf ihrem beruflichen und privaten Lebensweg. Abschließend möchte ich mich noch bei meiner Mutter Brigitte Lutchen sowie meinen Großeltern Marianne und Kaspar Lutchen für das Ermöglichen von Studium und Promotion und das Vertrauen in meine Fähigkeiten bedanken. Tübingen

Ralf Thomas Lutchen M. Sc.

Inhaltsverzeichnis Vorwort ............................................................................................. V Abbildungsverzeichnis ........................................................................ IX Tabellenverzeichnis............................................................................. XI Abkürzungsverzeichnis...................................................................... XIII Symbolverzeichnis ..........................................................................XVII Kurzfassung .................................................................................... XIX Abstract .......................................................................................XXIII 1

Einleitung ..................................................................................... 1 1.1 Motivation und Ziele ................................................................ 4 1.2 Forschungsfrage ...................................................................... 7 1.3 Aufbau der Arbeit .................................................................. 10

2

Grundlagen................................................................................. 13 2.1 Entwicklungszyklen in der Fahrzeugindustrie............................... 13 2.2 Fahrzeug-Netzwerk-Architektur ................................................ 14 2.2.1 Einführung in Bussysteme ............................................. 15 2.2.2 Einführung in Steuergeräte ............................................ 19 2.3 On-Board-/Off-Board-Diagnose ................................................ 22 2.3.1 Einführung in Protokolle ............................................... 23 2.3.2 Einführung in die Identifizierung .................................... 24 2.4 Remote-Diagnose .................................................................. 26 2.4.1 Big Data .................................................................... 26 2.4.2 Cloud-Technologien..................................................... 28 2.4.3 IoT-Messwerkzeuge ..................................................... 30

3

Testablauferstellung in der Fahrzeugentwicklung ............................. 33 3.1 Manuelle Erstellung ............................................................... 36 3.2 Stand der Entwicklung und Gründe für eine automatische Erstellung............................................................................. 46 3.3 Einfluss der Fahrzeug-Netzwerk-Architektur auf die Testablaufgenerierung ............................................................. 51 3.4 Zusammenfassung und Chancen der automatischen Erstellung......... 52

VIII

Inhaltsverzeichnis

4

Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur ...... 55 4.1 Definition der Anforderungen ................................................... 55 4.2 Prozess zur Identifikation der physikalischen Netzwerkstruktur........ 57 4.3 Datenerhebung und Transformation für eine ML-Datenbasis ........... 67 4.4 Methode zur Steuergeräte- und Variantenidentifizierung ................. 73 4.5 Vergleich der Machine-Learning-Modelle ................................... 87 4.5.1 VCI-Identifikation ....................................................... 88 4.5.2 DIAG-Identifikation ....................................................101 4.5.3 ECU-Identifikation .....................................................107 4.6 Zusammenfassung und Ergebnis der Methode .............................109

5

Anwendung und praktischer Nachweis ..........................................113 5.1 Systemüberblick ...................................................................114 5.2 Bedatungskreislauf anhand der Diagnose-Plattform ......................119 5.3 Ergebnisse ...........................................................................121

6

Zusammenfassung ......................................................................127 6.1 Generalisierung der Methode...................................................130 6.2 Ausblick .............................................................................131

Literaturverzeichnis .........................................................................133 Glossar ...........................................................................................141 Anhang ..........................................................................................145 A. Scatter-Plot der reduzierten Datenbasis ......................................145 B. Quellcode............................................................................146 B.1 Skriptdurchlaufzeit abschätzen über Normalverteilung .......146 B.2 Vergleich der Korrelations-Koeffizienten .........................148 B.3 Vergleich der ML-Modelle in Bezug zur Diagnose-Detektion ....................................................151 B.4 Docker-CI-Template für die Software-Architektur .............155

Abbildungsverzeichnis 1.1 1.2 1.3 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3.1 3.2 3.3 3.4 3.5 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15

Methode der VNA-Identifizierung am Beispiel Testablaufgenerierung ...... 6 Bewertungskriterien der Forschungsfrage ........................................... 9 Kapitelübersicht ......................................................................... 11 V-Model ................................................................................... 14 VNA eines modernen Fahrzeuges ................................................... 15 Netzwerktopologien der Fahrzeugnetzwerke ..................................... 16 CAN-Frame............................................................................... 18 Übersicht eines ECU-Mikrocontroller ............................................. 20 ECU-Anwendungsbeispiel ............................................................ 21 Übersicht der On-Board- und Off-Board-Diagnose ............................. 23 Protokollstapel ........................................................................... 24 ISO-OSI-7-Schichten-Modell ........................................................ 35 Expertengruppe bei der Diagnoseentwicklung ................................... 37 Testablaufvielfalt ........................................................................ 39 Normalverteilung der Steuergeräteabschätzung ................................. 41 Testpyramide - Herausforderungen der Automobilhersteller ................. 49 Der logische Fahrzeugaufbau......................................................... 56 Schematische Darstellung der Datenerhebung am Fahrzeug ................. 58 Serverkonzept der Cloud .............................................................. 59 Messmöglichkeiten IoT-Messwerkzeug ........................................... 60 Implementierte KI-Ansätze der Methode.......................................... 62 Konzept der Methode zur Identifizierung der VNA............................. 66 Beispielhafte .asc Messung ........................................................... 68 Beispielhafte .asc Messung nach Transformation ............................... 70 Histogramm FCT-Messung ........................................................... 71 Histogramm FCT-Messung bereinigt für KI-Applikationen.................. 72 Das Datenbankschema der DiagPatternDB ....................................... 75 Datenbankauszug der Interfaces ..................................................... 77 Datenbank-Abfrage der funktionalen Interface-Gruppen...................... 78 Datenbank-Abfrage möglicher Steuergeräte-Interface-Kombinationen .... 79 Ein Auszug der Pattern eines Steuergerätes über mehrere mögliche Varianten .................................................................................. 80 4.16 Vollständiger Diagnostik-Pattern-Ablauf der Methode ........................ 81

X 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26 4.27 4.28 4.29 5.1 5.2 5.3 5.4 5.5 A.1

Abbildungsverzeichnis Darstellung des Ergebnisses nach dem Diagnose-Pattern-Algorithmus.... 85 Herleitung der ECU-Identifikation FCT- und ODX-Ansatz .................. 86 Diag-Cloud-DB Schema............................................................... 89 Unterstützte Bussysteme............................................................... 91 Mögliche Netzwerke, die eine KI identifizieren kann .......................... 93 Verbindungen eines Netzwerkes und Netzwerke eines ECU ................. 94 Fingerabdruck des Engine-CAN..................................................... 95 Alle Fingerabdrücke der Datenbank-Bussysteme ............................... 98 Vergleich der Korrelations-Koeffizienten - Bussystem-Identifikation ...... 99 Alle Fingerabdrücke der Datenbank ARXML eines Bussystems...........100 Vergleich der Korrelations-Koeffizienten - ARXML-Identifikation........101 Standard-Beispiel der Separierbarkeit von Datenklassen .....................104 Diagnose-Klassifikationsergebnis (Konfusionsmatrix)........................106 Software-Architektur der Diagnose-Plattform ..................................115 Das Datenbankschema der Diagnose-Plattform ................................117 Bedatungskreislauf der Diagnose-Plattform .....................................120 Ergebnis der Fahrzeugidentifikation ...............................................123 Generierte Messaufgabe auf Grundlage der identifizierten VNA...........125 Scatter-Matrix der reduzierten FCT-Messung als df...........................145

Tabellenverzeichnis 1.1 2.1 3.1 4.1 4.2 4.3 4.4 4.5 4.6 5.1

Vergleich: Stand der Technik mit dem Ziel der Methode ........................ 3 Vergleich: Big Data mit Smart Data ................................................ 28 Gegenüberstellung: Stand der Technik / Chancen der Methode ............. 54 Vergleich der neuen Methode mit dem Stand der Entwicklung .............. 85 Anschlussbelegung des Kabelbaum, mit dem gemessen wird................ 90 Vergleich der Korrelation zur Identifizierung der Bussysteme ..............102 Vergleich der ML-Ansätze zur Detektion einer Diagnose-Nachricht .....107 Vergleich der neuen Methode mit dem Stand der Technik ...................109 Gegenüberstellung: Ad-hoc-VNA zu der Methode dieser Arbeit...........111 Ergebnis der Identifizierung von Fahrzeug: WDD2132161A698188......125

Abkürzungsverzeichnis 0x22 0x62 0x7F 2NF

UDS Request - Read by Identifier UDS Response - Read by Identifier UDS Response - Error zweite Normalform

A-Eth A2L AD API

ASC ASCII AUTOSAR

Automotive Ethernet ASAP2 ECU Description File Active Directory Applikationsschnittstelle (engl. Application Programming Interface) Anwendungssoftware (engl. Application Software) Autosar Extensible Markup Language Arbeitskreis für die Standardisierung von Automatisierungs- und Messsystemen Action Scrypt Communication American Standard Code for Information Interchange AUTomotive Open System ARchitecture

BMS

Batterie-Management-System

CAN CCE CD CI CRC

Controller Area Network Fehler gleicher Herkunft (engl. Common Cause Errors) Fortlaufende Auslieferung (engl. Continuous Delivery) Kontinuierliche Integration (engl. Continuous Integration) Cyclic Redundancy Code

DB DBC DEV df DHCP DLC

Datenbank (engl. Database) Data Base CAN Softwareentwicklung (engl. Development) Datenrahmen (engl. Data Frame) Dynamic Host Configuration Protocol Datenlängencode (engl. Data Length Code)

App ARXML ASAM

XIV DNS DoCAN

Abkürzungsverzeichnis

DTC

Domain Name System Transportschichtprotokoll: ISO 15765-2 [35] (engl. Diagnostic Communication over Controller Area Network) Transportschichtprotokoll: ISO 13400 [30] (engl. Diagnostics over Internet Protocol) Fehlercode (engl. Diagnostic Trouble Code)

ECU EMV

Steuergerät (engl. Electronic Control Unit) Elektromagnetische Verträglichkeit

FCT FKFS

Full CAN Trace Forschungsinstitut für Kraftfahrwesen und Fahrzeugmotoren Stuttgart

GSM GUI

Mobilfunkkommunikation (engl. Global System for Mobile Communications) grafische Benutzeroberfläche (engl. Graphical User Interface)

HP HTML HTTP HTTPS

Hochpunkt Hypertext Markup Language Hypertext Transfer Protocol Hypertext Transfer Protocol Secure

IaaS ID IFS IoT ISO

IT ITEM

Infrastructure as a Service Identifier Institut für Fahrzeugtechnik Stuttgart Internet der Dinge (engl. Internet of Things) Internationale Organisation für Normung (engl. International Organization for Standardization) Transportschichtprotokoll: ISO 15765 [35] (engl. Transport Layer) Informationstechnik Institut für Theoretische Elektrotechnik und Mikroelektronik

JSON

JavaScript Object Notation

KFZ KI

Kraftfahrzeug (engl. Vehicle) Künstlicher-Intelligenz (engl. Artificial Intelligence)

DOIP

ISOTP

Abkürzungsverzeichnis

XV

KWP 2000

Diagnoseprotokoll: ISO 14230 [32] (engl. Keyword Protocol 2000)

LAN LIN

lokales Netzwerk (engl. Local Area Network) Local Interconnect Network

MDF4 ML MOST

ASAM Measurement Data Format maschinelles Lernen (engl. Machine Learning) Media Oriented Systems Transport

NRZ

Non Return to Zero

OBD-II ODX

On-Board-Diagnose Diagnoseprotokoll: ISO 22901 [29] (engl. Open Diagnostic Data Exchange) Hersteller (engl. Original Equipment Manufacturer) Systemadministration (engl. Operations) Referenzmodell für Netzwerkprotokolle als Schichtenarchitektur (engl. Open Systems Interconnection) Over The Air Diagnoseablaufbeschreibung: ISO 13209 [31] (engl. Open Test sequence eXchange)

OEM OPS OSI OTA OTX

P2P PaaS pkl

Point to Point Platform as a Service Python Pickle File

qtt

Kurztest (engl. Quick Test)

REST ROSI RTR

REpresentational State Transfer RemOte Systeme für neue Interaktive Lösungen Datenanforderung (engl. Remote Transmission Request)

SaaS SIM SOA SOVD SQL

Software as a Service Teilnehmer-Identitätsmodul (engl. Subscriber Identity Module) Service Oriented Architecture Service Oriented Vehicle Diagnostics Structured Query Language

XVI

Abkürzungsverzeichnis

SSL SVM SW

Secure Sockets Layer Support Vector Machine Software

TDMA TLS TtT

Time Division Multiple Access Transport Layer Security Zeit bis zum ersten Test (engl. Time to Test)

UDS

Kommunikationsprotokoll: ISO 14229 [33] - vereinheitlichte Diagnosedienste (engl. Unified Diagnostic Services)

VCI

Fahrzeug-Netzwerk-Schnittstelle (engl. Vehicle Communication Interface) Fahrzeug-Identifizierungsnummer (engl. Vehicle Identification Number) Fahrzeug-Netzwerk-Architektur (engl. Vehicle Network Architecture)

VIN VNA

WLAN

Kabelloses lokales Netzwerk (engl. Wireless Local Area Network)

XCP

Kalibrierungsprotokoll (engl. Universal Measurement and Calibration Protocol) Extensible Markup Language

XML

Symbolverzeichnis Griechische Buchstaben 𝜇 𝜙 𝜌 𝜎

Aritmetischer Mittelwert Winkel Korrelationskoeffizent Standardabweichung

° -

Indizes ident korr mess mess_out out sum tot

Identifiziert Korrigiert Messwerte Timeout aufgrund Messwert Timeout aufgrund Steuergerät Summe Totzeit Lateinische Buchstaben

a b 𝐶𝑜𝑣 (a, b) 𝐸 (𝑥) 𝐹 (𝑥) 𝑓 (𝑥) 𝑓𝑐𝑎𝑛 𝐽 (a, b) 𝑙   𝑁 𝜇, 𝜎 2 𝑛 𝑉 𝑎𝑟 (𝑥)

Messwerte-Vektor Vergleichswerte-Vektor (aus Datenbank) Kovarianz Erwartungswert Wahrscheinlichkeits-Verteilungsfunktion Wahrscheinlichkeits-Dichtefunktion Busfrequenz Jaccard-Koeffizient Framelänge Gaußsche Normalverteilung Stichprobengröße / -länge Varianz

bit / s bit -

Kurzfassung Die vorliegende Arbeit stellt eine neue Methode zur Erstellung von automatisierten Testabläufen in der Fahrzeugentwicklung auf. Basierend auf den Untersuchungen der Forschung zur Digitalisierung der Fahrzeugdiagnose ist eine neue DiagnosePlattform entstanden. Das Testen einer Fahrzeugfunktion innerhalb eines Automobils, ein wenig genauer einer Steuergerätefunktion, ist ein komplexer Vorgang. Ein Steuergerät (engl. Electronic Control Unit) (ECU) besitzt häufig eine Vielzahl an Sensoren und Aktuatoren, die durch die Embedded-Software (SW) (nach dem AUTomotive Open System ARchitecture (AUTOSAR)-Standard) ausgelesen oder angesteuert werden. Bei einem Test einer Steuergerätefunktion ist es üblich, dass Simulationen einen realen Sensor oder Aktuator ersetzen. Weiterhin ist ein Steuergerät im Fahrzeug immer an mindestens ein Bussystem angeschlossen, wodurch es vorkommt, dass dieses ebenfalls simuliert wird (Restbus-Simulation). Das sind Standardmechanismen, mit denen bei der SW-Entwicklung der ECU-SW gearbeitet wird, um zu versuchen, eine möglichst hohe Testabdeckung automatisiert zu erreichen. Auf diesem Wege getestete und freigegebene SW-Stände werden vom Zulieferer der ECU an den Hersteller (engl. Original Equipment Manufacturer) (OEM) des Fahrzeuges übermittelt. Dieser muss infolgedessen den neuen SW-Stand des ECU in seinen Entwicklungsfahrzeugen erproben und freigeben. Hierbei werden Erprobungsfahrten durchgeführt, da Entwicklungsfahrzeuge keine Simulationen mehr benötigen, sondern unter realen Bedingungen manuell getestet werden. Während einer Erprobungsfahrt (im Straßenverkehr oder auf einem Prüfstand) protokollieren Daten-Logger die Buskommunikation der kontaktierten Bussysteme und Diagnose-Systeme verwenden höhere Protokolle (UDS, ODX), um gezielt Daten und Fehlerspeicher auszulesen. Um derartige Daten in einem Entwicklungsfahrzeug abfragen zu können, bedarf es eines Testablaufes, in dem die zu messenden ECUs und Messwerte genauer gesagt, in dem der Messablauf festgelegt ist. Aufgrund der Tatsache, dass ein OEM mehr als eine Baureihe herstellt, müssen mehrere hundert ECUs mit diversen SW-Ständen in einem Testablauf hinterlegt sein, um die Komplexität für die Versuchsingenieure in einem vertretbaren Rahmen zu halten.

XX

Kurzfassung

Die vorliegende Arbeit zeigt eine neue Cloud und Künstlicher-Intelligenz (engl. Artificial Intelligence) (KI) basierende Möglichkeit auf, wie diese Testabläufe automatisiert und individuell auf das jeweilige Entwicklungsfahrzeug optimiert erstellt werden. Hierbei wird in einem ersten Schritt hergeleitet, dass der Stand der Entwicklung mehrere Herausforderungen aufweist, die mit konventioneller Vorgehensweise bisher nicht gelöst werden konnten, zu denen im Rahmen dieser Arbeit erstmalig Lösungsmöglichkeiten aufgezeigt werden. Die Hauptherausforderung, der sich diese Methode stellt, ist die Optimierung der Durchlaufzeit einer Messaufgabe hier ist eine tatsächliche Einsparung von etwa 63 % erzielt worden und eine weitere theoretische um 36 % wird vorgestellt. Weniger als 1 % der Messzeit wird mit den heutigen Testabläufen tatsächlich auf dem Busmedium kommuniziert. Zusätzlich zu dieser Optimierung wird aufgezeigt, wie gleichzeitig die Aktualität der Messaufgabe verbessert wird, bei ebenfalls steigender Vollständigkeit, indem die Komplexität in die Cloud und damit an die KI übertragen wird. Dies wird erreicht, indem in einem ersten Schritt das Entwicklungsfahrzeug identifiziert wird. Alle ECUs und deren SW-Varianten sowie alle Fahrzeug-Netzwerk-Schnittstellen (engl. Vehicle Communication Interfaces) (VCIs), mit denen das Testequipment mit dem Fahrzeug verbunden ist, müssen ermittelt und auf der Datenbank (engl. Database) (DB) abgelegt werden. Mit dieser Information kann die Cloud die Testabläufe individuell generieren und bereitstellen. Die Methode der Fahrzeugidentifizierung funktioniert auf zwei Wegen. Einerseits wird auf Grundlage der ODX-Dateien des OEM eine Datenbank erstellt, die wiederum einen Testablauf erzeugt. Diesen speziellen Testablauf führt das Testequipment, der Internet der Dinge (engl. Internet of Things) (IoT)-Diagnosetester im zu untersuchenden Entwicklungsfahrzeug aus, damit aufgrund der Resultatdatei alle verbauten ECUs bestimmt werden. Andererseits werden die Fahrzeugnetzwerke auf Grundlage der Autosar Extensible Markup Language (ARXML)-Dateien ermittelt. Diese kommen ebenfalls in eine separate DB, woraufhin unterschiedliche Maschinelles Lernen (engl. Machine Learning) (ML)-Modelle trainiert werden, um ein gemessenes Netzwerk aufgrund des Full CAN Trace (FCT) zu analysieren und zu bestimmen. Weiterhin werden hier ML-Modelle vorgestellt, welche die ODX-Nachrichten aus der FCT-Messung extrahieren und somit die Steuergeräte des ersten Weges (Diagnostik-Pattern) verifizieren können. Damit ist die vollständige Fahrzeug-Netzwerk-Architektur (engl. Vehicle Network Architecture) (VNA) bestimmt und kann für beliebige Aufgaben verwendet werden, wie beispielsweise die Durchlaufzeitoptimierung der Testabläufe, die eine Viel-

Kurzfassung

XXI

zahl an Ingenieuren täglich ausführen. Die Methode der VNA-Identifizierung mit der Diagnose-Plattform kann somit hardwareunabhängig zur Einsparung von Ressourcen beitragen. Hierdurch werden zukünftig weniger Entwicklungsfahrzeuge, Messhardware sowie Messkabelbäume und Wartezeit auf Messresultate benötigt, wodurch sich die Entwicklungszeit der Fahrzeuge beschleunigt.

Abstract This work presents a new method for the creation of automated test sequences in vehicle development. Based on research about digitalization of vehicle diagnostics, as well as investigations and development, this thesis created a new diagnostic platform. Testing a vehicle function even a little more exactly an ECU function is a complex process. An ECU often has a large number of sensors and actuators that are read or controlled by the embedded SW (according to the AUTOSAR-standard). When testing an ECU function, it is common to replace a real sensor or actuator with simulations. Furthermore, an ECU in a vehicle is always connected to at least one bus system, which in turn means that this bus must also be simulated (residual bus simulation). So far, these are standard mechanisms used in the SW development of the ECU-SW and attempts are made to achieve the highest possible test coverage in an automated manner. In this way, tested and released SW states are transmitted by the supplier of the ECU to the OEM of the vehicle. As a result, the OEM must test and approve the new SW version of the ECU in his development vehicles. Test drives are carried out here, since development vehicles no longer require simulations, but are tested by hand under real conditions. During a test drive (on the road or on a test bench), data loggers record the bus communication of the contacted bus systems and diagnostic systems use higher protocols to read out data and error memories in a targeted manner. In order to be able to query such data in a development vehicle, a test procedure is required in which the interested ECUs and measured values, more precisely, in which the measurement procedure is defined. Due to the fact that an OEM produces more than one series, several hundred ECUs with various software versions must be stored in a test procedure in order to keep the complexity for the test engineers within an acceptable range. This work shows a new Cloud and AI-based approach on how these test processes are automated and individually optimized for the respective development vehicle. In a first step, it is derived that the current state of development has several challenges

XXIV

Abstract

that could not be solved with conventional procedures and that possible solutions are shown for the first time in the context of this work. The main challenge that this method faces is the optimization of the throughput / pass time of a measurement task. Here a saving of about 63 % has been achieved and another theoretical 36 % is shown. Less than 1 % of the time is communicated on the bus medium with today’s test procedures. Table shows a comparison. STATE OF DEVELOPMENT

GOAL OF THE METHOD

vehicle structure uncertain global database test creation is a multi-Expert-process increased pass time

vehicle structure identified individual database test creation is a multi-AI-process optimized pass time

In addition to this optimization, it is shown how measurement task can be more up-to-date, while also increasing completeness, since the complexity is transferred to the cloud and thus to the AI. To achieve this result, the first step is to identify the current state of a development vehicle. All ECUs and their SW variants as well as all VCIs with which the test equipment is connected to the vehicle must be identified and stored on the database. With this information, the Cloud can generate and provide the test procedures individually for each vehicle. Figure shows this entire process graphically. There are two measurement methods with the respective data pipeline that end together in a verification process. This should check the plausibility of the identified ECUs. Based on the resulting list, for example, individualized test procedures are generated and made available to the measurement system. Looking more closely, if an FCT is executed in the vehicle and this is transmitted to the Cloud, then the right-hand path in Figure comes into play. The individual measured CAN networks are synchronized in terms of time and combined to form an overall vehicle measurement. As a result, this measurement is transferred to a standard ML Panda-df and saved in a „.pkl“ file. This makes it possible for an AI to read and process this file quickly. Once the measurement has been converted into the ML file format, the different AI models that have been trained in advance can conduct the respective classification and thus generate an ECU or VCI list, for example. The left path of Figure is

Abstract

XXV

traversed when a special diagnostic script has been executed, this is the core of the present work and will be discussed in detail in the main part. The result is also an ECU list. In the middle of the private Cloud application, the exemplary implementation of the automatic individualized test procedure generation is shown as a possible application scenario of the method of VNA identification. It can be seen that an OEM can store its global test procedures in a database. As soon as the vehicle is identified and verified by the AI, the diagnostic tester automatically receives its complete and individualized measurement tasks. A method should be found that makes it possible to map the logical structure of an individual development vehicle in as much detail as possible. To this end, three main aspects are relevant and need to be examined. The logical vehicle structure and thus all functions that the vehicle supports depend on the networks used, the ECUs and the data basis. ECUs communicate with each other and exchange data via vehicle networks. Each ECU has software flashed onto the ECU called a variant. Some ECUs also take on a gateway function and connect similar or different networks to transfer the data from the ECUs across the bus system boundaries and map an overall vehicle

XXVI

Abstract

topology. A network and the On-Board diagnostics (ARXML / DBC) are set and maintained in different files than the control unit-specific Off-Board diagnostics (ODX). Three main use cases considered in this work can be derived from the three main categories. Automatic result visualization: If a vehicle measurement has been carried out,

it should be made available in a way that people can read it. For this purpose, the measurement is converted using the data basis and processed visually. The data basis can be set / logged by an AI or by the measuring person for downstream data interpretation. Individual test procedures: The person who carries out the diagnostic measurement does not have to wait too long for the results, the test procedures are individualized, based on the built-in ECUs and optimized for the vehicle. Parallel Flashing: The software of an ECU may be updated OTA. This can be done in parallel to save time. For this, the diagnostic system must know the network structure in order to update only one ECU per network at a time. In this thesis a new method is derived how the VNA can be determined. First, the networks are identified (VCI) so that hardware dependencies in relation to the wiring harness should be eliminated. In the future, any diagnostic wiring harness can be used in any vehicle and the user can switch between vehicles without hesitation. In addition, the user decides which CAN bus he wants to measure and not the measuring system manufacturer together with his wiring harness supplier. This will speed up vehicle development. When a new CAN bus is deployed in the vehicle, this new network does not lead to a physically new diagnostic harness, so the calibration file of this new sub-network is sufficient to start testing. Sources of error are minimized, resources and time are saved, the complexity of the hardware variety is shifted to the software and in this new approach, to the AI. Furthermore, this method supports the user in validating the measurement by proposing the best fitting ARXML file, which the AI considered to be the most probable based on the data in the measurement. In the case of measurement systems with several interfaces, the user must document well which interface was connected to which CAN. This can be omitted in the future and the interpretation and thus the processing of the measurement for a person will be accelerated. Based on further research, this identification can also make it possible to identify the gateway control units and thus enable parallel flashing as a further application. In the future, it would be conceivable that the software that is to be transferred to an ECU is sent OTA to the diagnostic tester, which flashes the ECU. The user decides when to attempt the

Abstract

XXVII

update flash process. If it fails, the Cloud can send a backup SW or a different SW version. The ECU identification marks the second process. In the diagnostic pattern task, a test procedure is conducted in the vehicle to be analyzed. As a result of this measurement task, the Cloud can reliably determine the control units and their software variants. An identified vehicle in the backend is useful in many ways. On the one hand, it can be tracked which revisions to control units and / or software took place. On the other hand, measurement tasks can be created that fit the vehicle, thus reducing the execution time to a minimum. This procedure is also very helpful when it comes to the actuality of a measurement task data. After a change in the measurement task, all measurement systems connected to the Cloud automatically and immediately receive the new measurement task (single source principle). In principle, the method presented here makes it possible to set up a diagnostics platform on the web or intranet and to centralize data entry. This means that the experts stop exchanging information via e-mails, but instead make changes directly on the platform and test whether everything works as desired. This makes it possible to come a little closer to the process of the automatic test pyramid shown in this work and to leave the classic V-model. Another important point is that the user is relieved of the fact that confidential files do not necessarily have to be stored on the personal work computer. These confidential files are automatically downloaded, synchronized and encrypted on the file server in the backend of the Cloud. The keys are managed by an internal blockchain, so all transactions1 can be viewed by all participants and are tamper-proof. This also enables external service providers to be involved in the test operation of the development vehicles without the confidential files having to be handed over. With this method, the OEM can protect its know-how. In addition, the user no longer has to maintain daily backups or have a colleague update them when they return from vacation. This platform also makes it possible to turn users into successful testers who rarely or never conduct measurements on the vehicle. The quality of the results is primarily maintained by the software developers in the backend and not by each individual user. The ability to enhance the system with new modules and more functionality is now given. Referring to the four pillars of the research question, it can be stated that this method can significantly simplify and thus accelerate vehicle development.

1 At

what time did which developer/tool open/modify which file

XXVIII

Abstract

Accuracy: Here the method, when used correctly, provides the opportunity to get

to 100 %. The networks are recognized correctly if the database of ARXML files is kept up-to-date. In addition, the control units and their SW variants are reliably identified if the database of the ODX files is kept up-to-date. The logical structure of a vehicle is analyzed and stored in the Cloud. This also creates a vehicle history when conversions take place, which is a new approach among diagnostic systems. Completeness: If the method is applied to all possible control units at a large OEM, the completeness can be guaranteed, but there is also a large investment of time initially. Optimizations at this point are the responsibility of the OEM. Pass time: There are many positive changes in the pass time. On the one hand, the experts can independently ensure that changes are rolled out and are therefore no longer dependent on update processes from other departments. On the other hand, test sequences that are created individually for a development vehicle on the basis of the VNA are many times faster than global test sequences. Actuality: There is a single source of information and therefore every user is automatically always up to date. Changes have an immediate effect and thus improve measurements worldwide within seconds. This answers the research question - using the presented work, the VNA can be determined with a comparatively high degree of reliability using the most modern IT infrastructure. This means that the digitization of vehicle diagnostics is largely shifted to the backend so that the user can create his measurements with as little expert knowledge as possible. At the same time, the system ensures a uniform quality of all measurements, regardless of knowledge. The present new method requires preliminary work, but the advantages outweigh the disadvantages like the more complex configuration on the part of the measuring system developer. That was not part of the research as the goal was to advance the digitization of vehicle test creation. Many approaches, some of which were also more manageable, were evaluated, but none was able to generate as many improvements as the method presented in this work. For this reason, this disruptive approach was pursued and a complete diagnostic platform was developed and the entire chain of the data cycle was implemented and tested as valid. With this, the full VNA is determined and can be used for any task, such as optimizing the pass time of the test procedures that numerous engineers perform every day. The method of VNA identification with the diagnosis platform can thus help to save resources regardless of the hardware. As a result, fewer development

Abstract

XXIX

vehicles, measurement hardware and measurement cable harnesses and waiting times for measurement results are required in the future, which can speed up the development time of the vehicles.

1 Einleitung Aufgrund der stetig steigenden Funktionen, die ein modernes Kraftfahrzeug (engl. Vehicle) (KFZ) anbietet, steigt infolgedessen auch die Komplexität in der Fahrzeugentwicklung. Einen ersten Indikator dafür liefert die Anzahl an Steuergeräten, die in aktuellen Entwicklungsfahrzeugen zum Einsatz kommt. An dieser Stelle gibt es zwei Trends zu beobachten, Einerseits wird weiter dezentralisiert, wodurch sich ebenfalls die Gateway-Architektur verändert von einer Domain- zu einer ModulArchitektur. Andererseits wird versucht, wieder möglichst zu zentralisieren, mit einem performanten Zentralrechner. Zudem übernimmt jedes Steuergerät (engl. Electronic Control Unit) (ECU) stetig mehr Funktionen und ist nicht nur elektrisch mit den anderen Steuergeräten vernetzt, sondern auch logisch (auf funktionaler Ebene). Auf dieser Basis entstehen neue kooperative verteilte Funktionen, die beispielsweise für das autonome Fahren benötigt werden. Um die korrekte Funktionsweise eines Steuergerätes oder einer steuergeräteübergreifenden Funktion zu überprüfen, werden unterschiedliche Testabläufe, sogenannte Diagnose-Skripte oder Messaufgaben, entwickelt. Basierend auf der Anzahl an möglichen Steuergerätekombinationen resultiert ebenfalls eine beträchtliche Anzahl an solchen Messaufgaben. Eine Alternative dazu ist die Erstellung globaler Testabläufe. Dies bedeutet, dass nicht nur die ECUs, die im KFZ vorkommen, in der Messaufgabe hinterlegt sind, sondern noch viele weitere. Damit entsteht der Vorteil, dass mit dem gleichen Skript bspw. ein Fahrzeug mit elektrischer Sitzverstellung und eines ohne diese Funktionalität gleichermaßen getestet werden kann. Was hier auf den ersten Blick die Komplexität reduziert, wirkt sich auf den zweiten jedoch nachteilig auf die Durchlaufzeit der einzelnen Testabläufe aus. Ein weiterer negativer Aspekt dieser global angelegten Skripte ist, dass der Testfahrer/Ingenieur, der eine Messung durchführt, keinen inhaltlichen Bezug zu der Art und dem Inhalt der Messdaten hat, sondern dass dieser Bezug vielmehr nur unter erhöhtem Aufwand zeitweise/temporär erreicht werden kann. Somit fällt es dem Entwicklungsingenieur zunehmend schwerer, die Korrektheit einer Steuergerätefunktion zu überprüfen bzw. die richtigen Informationen aus dem globalen Testablauf zu extrahieren. Die globalen Testabläufe werden beim Fahrzeug-OEM an zentralen Stellen erstellt, verwaltet und gepflegt. Diese Teams sind für die Anwender der Testabläufe die © Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 R. T. Lutchen, Optimierung der Fahrzeugdiagnose durch eine cloudbasierte Methode zur Identifikation der Datennetze mit künstlicher Intelligenz, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-43113-6_1

2

1 Einleitung

vorwiegende Kommunikationsstelle für Anforderungen. Des Weiteren müssen diese Teams aber mit vielen anderen Fachabteilungen im Kontakt stehen, um einen reibungsfreien Ablauf von Fahrzeugmessungen zu ermöglichen. Dadurch ergibt sich eine Kaskade von Experten bildlich gesprochen ein Wasserfall an Informationen. So gibt es beispielsweise eine Fachabteilung (ein Expertenteam) für jedes Steuergerät bzw. für jede Steuergerätegruppe wie z. B. Steuergeräte für Motor- oder GetriebeApplikation. Weitere Expertenteams gibt es für jedes eingesetztes Diagnosesystem. Diese Experten erstellen und pflegen die globalen Testabläufe und stehen im fortlaufenden Kontakt mit den Steuergeräteentwicklern. Zudem müssen sie in engem Kontakt mit den Fahrzeug-Netzwerk- und Cyber-Security-Architekten sein, um den Anwendern des Diagnosesystems eine stabile Funktionalität zu gewährleisten. Weiterhin gibt es für die divergenten Testabläufe ebenfalls unterschiedliche Beschreibungs-/Konfigurationsdateien (Diagnoseprotokoll: ISO 22901 [29] (engl. Open Diagnostic Data Exchange) (ODX), ASAP2 ECU Description File (A2L), ARXML, Data Base CAN (DBC), ...) für die Steuergeräte. Nicht jede SteuergeräteSW unterstützt jede Konfigurationsdatei und so kann es vorkommen, dass eine Messung am Fahrzeug eine Vielzahl an Randbedingungen (bspw. Freischaltungen, Zertifikate) benötigt, bevor diese ausgeführt werden kann. Ziel dieser Arbeit ist es, eine Methode aufzuzeigen, mit der möglichst vollständige und in der Durchlaufzeit optimierte Testabläufe automatisch erzeugt werden, auf Grundlage eines Internet der Dinge (engl. Internet of Things) (IoT)Diagnose-Testgerätes. Im Speziellen wird die Bestimmung der Fahrzeug-NetzwerkArchitektur (engl. Vehicle Network Architecture) (VNA) hier im Detail analysiert, da bei den globalen Testabläufen vor jeder Messung ein Identifizierungsprozess durchlaufen wird. Die ECUs und deren Datenstände bzw. deren SW-Variante werden beim Interpretieren ermittelt. Diese Daten werden zum aktuellen Stand der Entwicklung jedoch nicht zurück in die Testerstellungskette gespielt, so dass es notwendig ist, die Identifizierung vor jeder Messung erneut durchzuführen. Das hat den Hintergrund, dass diese Information für den Experten, der das Diagnosesystem aktualisiert, nicht relevant ist, da dieser sich mit seinen Skripten möglichst breit aufstellen möchte. Die Ergebnisse dieser Arbeit sind allgemein gehalten und können auf gleichartige Aufgabenstellungen übertragen werden. Zudem liefert diese Arbeit einen Beitrag zur Anwendung von Künstlicher-Intelligenz (engl. Artificial Intelligence) (KI)Methoden in einer Cloud im Big-Data-/Smart-Data-Umfeld. In Tabelle 1.1 wird

1 Einleitung

3

der aktuelle Stand in der Entwicklung den Zielen des Konzeptes/der Methode gegenübergestellt. Tabelle 1.1: Vergleich: Stand der Technik mit dem Ziel der Methode Stand der Entwicklung

Ziel der Methode

logischer Fahrzeugaufbau unbekannt globaler Datenstand Testablauf-Erstellung ist ein Multi-Experten-Prozess erhöhte Durchlaufzeit Konfigurationsdateien nicht plausibilisiert

logischer Fahrzeugaufbau bekannt individueller Datenstand Testablauf-Erstellung ist ein Multi-KI-Prozess optimierte Durchlaufzeit Konfigurationsdateien plausibilisiert

Es ist zu erkennen, dass es ein ganz wesentlicher Bestandteil ist, dass der Fahrzeugnetzwerkaufbau (VNA) bekannt ist (d.h identifiziert und gespeichert wird). Dadurch können die Testabläufe automatisiert generiert und an das analysierte Fahrzeug angepasst werden. Aber der bestehende sowie der neue Prozess sind auf unterschiedliche Art und Weise komplex. Der neue Prozess bedarf der Implementierung mehrerer KI-Algorithmen aus dem Wissen der Experten. Diese Methode kann Zeit und Ressourcen sparen, was wiederum zu einer Kostenreduktion in der Fahrzeugentwicklung führen würde. Die Zeit bis zum ersten Test (engl. Time to Test) (TtT) wird auf ein Minimum reduziert, auf der Grundlage der Identifizierung und Generierung können Entwicklungsfahrzeuge unmittelbar nach der Herstellung/Produktion verwendet werden. Mit den heutigen Mitteln bedarf es an dieser Stelle einer gewissen Vorlaufzeit, wenn es sich beispielsweise um das erste Prototypen-Fahrzeug einer neuen Baureihe handelt. Aber der wesentliche Unterschied ist, dass die Durchlaufzeit der Testabläufe um einen Faktor von meistens über 40 beschleunigt werden kann1 . Abschließend bleibt noch zu erwähnen, dass die Konfigurationsdateien, die ein OEM von seinem Zulieferer erhalten hat, archiviert und plausibilisiert werden, aufgrund der Tatsache, dass dieser Datenstand für die Identifizierung von Bedeutung ist.

1 Hochrechnung

bzw. Optimierungsabschätzung: Bei 100 Entwicklern und 20 Messungen am Tag ergeben sich 60 min im Vergleich zu 2 min Arbeitszeit am Tag pro Entwickler. Ein theoretischer Kostenvorteil von 97 h pro Tag.

4

1 Einleitung

1.1 Motivation und Ziele Wie in einer früheren Arbeit [50] gezeigt wurde, erhält ein modernes Fahrzeug immer mehr Funktionen und ist daher auch stärker vernetzt. Jedes Steuergerät bekommt somit mehr Aufgaben und unterstützt unterschiedliche Standards [76]. Auch die Fahrzeugnetzwerke verändern sich von einer Struktur zentraler SpartenGateways hin zu einem System verteilter Gateways [60]. In der vorliegenden Arbeit wird ein IoT-Diagnosesystem verwendet, welches, wie in der Fahrzeugentwicklung üblich, viele Hardwareschnittstellen anbietet. Hier sind einerseits zwölf Controller Area Network (CAN)-Bus-, zwei FlexRay-, eine RJ45-/Automotive Ethernet (A-Eth)- sowie eine BroadR-Reach-Schnittstelle für die Kommunikation mit den Fahrzeugnetzwerken vorhanden. Anderseits ist dieses Messsystem über eine Mobilfunkkommunikation (engl. Global System for Mobile Communications) (GSM)-Teilnehmer-Identitätsmodul (engl. Subscriber Identity Module) (SIM)-Karte, eine Kabelloses lokales Netzwerk (engl. Wireless Local Area Network) (WLAN)- oder Bluetooth-Schnittstelle mit der internen privaten Cloud verbunden. Dieses IoT-Messsystem kann einfache Messaufgaben ausführen, wie z. B. den Controller Area Network (CAN)- oder FlexRay-Bus abhören, aber es können auch anspruchsvollere Testabläufe ausgeführt werden beispielsweise ein Diagnoseskript zum Löschen der Fehlerspeicher oder eine deterministische zyklische Messung (Kalibrierungsprotokoll (engl. Universal Measurement and Calibration Protocol) (XCP)-Messung) eines Signals auf einem spezifischen Bussystem. Um eine anspruchsvollere Messaufgabe für ein Fahrzeug zu erstellen und diese auszuführen, wird einiges an Expertenwissen benötigt2 , beispielsweise muss die VNA bekannt sein sowie die verbauten ECUs. Fahrzeuge in der Entwicklung werden im Gegensatz zu Serienfahrzeugen häufiger umgebaut oder haben prototypische Softwarestände. Dies stellt in der Fahrzeugentwicklung eine gewisse Herausforderungen dar, wodurch die Verwendung von KI-Algorithmen eine lohnenswerte Alternative bildet. Ziel dieser Arbeit ist es, durch 2 Ein

typisches Beispiel aus der Fahrzeugentwicklung: Eine Person möchte Fahrzeugmessungen an einem ihr unbekannten Entwicklungsfahrzeug durchführen. Daraufhin muss diese Person in einem ersten Schritt Zeit investieren, um etwas über das Fahrzeug herauszufinden und um die richtigen Messdateien bei den verantwortlichen Kollegen anfordern zu können. Dieser expertengetriebene Prozess macht es schwierig, valide Fahrzeugmessungen zu generieren.

1.1 Motivation und Ziele

5

den Einsatz von geeigneten KI-Algorithmen die VNA des Entwicklungsfahrzeuges, welches an den IoT-Diagnosetester angeschlossen wird, sicher zu erkennen, um es so in einem weiteren Schritt zu ermöglichen, die Messaufgaben für dieses Fahrzeug zu individualisieren. Hierzu werden verschiedene Algorithmen der KI untersucht und bewertet. Für die Ergebnisse in dieser Arbeit werden zwei unterschiedliche Serienfahrzeuge verwendet (ein Hybrid- und ein Dieselfahrzeug), da es in erster Linie um die generelle Fragestellung geht, wie der Fahrzeugnetzwerkaufbau mit einer KI ermittelt werden kann. Es gibt zwei Arten von Dateien, die in der Cloud vorliegen, das sind einerseits Konfigurationsdateien wie: Diagnose: einzelne ECUs als ODX- oder A2L-Datei z. B. engine1.ODX-d bzw.

engine1.A2L Messaufgaben: einzelne Testabläufe als Kurztest (engl. Quick Test) (qtt)-Datei z. B. powertrain.qtt Bussysteme: vollständige Bussysteme als ARXML- oder DBC-Datei z. B. infotainment.ARXML bzw. infotainment.DBC Andererseits gibt es die Dateien von den durchgeführten Messungen, die mit dem Fahrzeug erzeugt werden (Messresultate): Binärdatei: vollständige Bussysteme als FCT z. B. can11.bin Messkurven: vollständige Bussysteme als FCT interpretiert und aufbereitet als ASAM Measurement Data Format (MDF4)-Datei z. B. can11.MDF4 Textdatei: vollständige Bussysteme als FCT interpretiert und aufbereitet als American Standard Code for Information Interchange (ASCII)-Datei z. B. can11.ASC Diagnoseergebnisse: vollständige Testabläufe meist als Extensible Markup Language (XML) z. B. powertrain.XML interpretiert und aufbereitet als Hypertext Markup Language (HTML)-Datei z. B. powertrain.HTML

Die Konfigurationsdateien werden verschlüsselt und die Schlüssel werden manipulationssicher in einer Blockchain [61, 63] oder vereinfacht ausgedrückt der DB gespeichert3 . Die notwendigen Informationen für die Identifikationsmethode werden bei diesem Verschlüsselungsprozess ausgelesen und in den entsprechenden DBs hinterlegt. Auf Grundlage der eingelesenen Daten können in der Cloud mehrere 3 Auf

die Blockchain-Applikation wird in dieser Arbeit nicht weiter eingegangen. (Grundlegende Informationen sind festgehalten in der Masterarbeit [25], die Ergebnisse wurden für die vorliegende Forschungsarbeit gemeinsam erarbeitet und in der studentischen Ausfertigung schriftlich niedergeschrieben.)

6

1 Einleitung

Prozesse definiert werden, wie ein Fahrzeug identifiziert wird. Solch ein Prozess besteht aus einer Messung, die der IoT-Diagnosetester im Entwicklungsfahrzeug durchführen und übertragen muss. Mit den empfangenen Daten können daraufhin in der Cloud, abhängig von der Art der Messaufgabe, verschiedene Ansätze durchlaufen werden. Hier sind sowohl KI- als auch konventionelle Modelle möglich. Zudem ist es aufgrund der unterschiedlichen Prozesse realisierbar, eine Plausibilisierung durchzuführen, um so die Zuverlässigkeit der Identifikation zu erhöhen. In Abbildung 1.1 ist dieser gesamte Prozess grafisch dargestellt. Es sind zwei Messmethoden mit der jeweiligen Daten-Pipeline zu erkennen, die gemeinsam in einem Verifikationsverfahren enden. Dieses soll die identifizierten ECUs plausibilisieren. Auf der Grundlage der entstandenen Liste werden beispielsweise individualisierte Testabläufe generiert und dem Messsystem bereitgestellt.

Abbildung 1.1: Konzept der Methode der VNA-Identifizierung am Applikationsbeispiel Testablaufgenerierung Wird im Fahrzeug beispielsweise ein FCT ausgeführt und dieser an die Cloud übertragen, dann kommt der rechte Pfad der Abbildung 1.1 zum Tragen. Die

1.2 Forschungsfrage

7

einzelnen gemessenen CAN-Netzwerke werden zeitlich synchronisiert und zu einer Gesamt-Fahrzeugmessung zusammengefügt. Diese Messung wird infolgedessen in einen ML üblichen Panda-Datenrahmen (engl. Data Frame) (df) überführt und in einer „.pkl“-Datei gespeichert. Hierdurch ist es einer KI möglich, diese Datei vergleichsweise schnell einzulesen und zu verarbeiten. Wenn die Messung in das ML-Dateiformat konvertiert wurde, können die unterschiedlichen, im Vorfeld trainierten Modelle die jeweilige Klassifikation durchführen und erzeugen somit beispielsweise eine Steuergeräte- oder VCI-Liste. Der linke Pfad der Abbildung 1.1 wird durchlaufen, wenn ein spezielles Diagnoseskript ausgeführt wird, welches der Kern der vorliegenden Arbeit ist und im Hauptteil ausführlich behandelt wird. Das Resultat ist ebenfalls eine Steuergeräteliste. In der Mitte der privaten Cloud-Applikation ist noch die beispielhafte Umsetzung der automatischen individualisierten Testablaufgenerierung dargestellt, als ein mögliches Einsatzszenario der Methode der VNA-Identifikation. Es ist zu erkennen, dass ein OEM seine globalen Testabläufe in einer Datenbank ablegen kann. Sobald das Fahrzeug identifiziert und über die KI verifiziert ist, erhält der Diagnosetester dann automatisch seine vollständigen und individualisierten Messaufgaben.

1.2 Forschungsfrage Diese Forschungsarbeit beschäftigt sich mit der Digitalisierung der Fahrzeugdiagnose und somit im weitesten Sinne mit der Digitalisierung der Fahrzeugentwicklung. Dabei wird schwerpunktmäßig untersucht, welche theoretisch erzielbaren Einsparpotenziale (Ressourcen sowie auch monetäre Mittel) durch einen sinnvollen Einsatz modernster Informationstechnik (IT)-Infrastruktur erzielbar sind. Im Folgenden sind Tools und Konzepte, die in dieser Forschungsarbeit untersucht wurden, zusammengefasst: • Cloud-Architekturen (private sowie öffentliche) • Kubernetes-Cluster um Dienste hochverfügbar, ausfallsicher und skalierbar in der Cloud anbieten zu können • Datenbank-/ Blockchain-Applikationen zur sicheren Verwahrung von sensiblen Daten

8

1 Einleitung

• KI-Algorithmen zur Automatisierung von Expertensystemen, um die Einstiegshürden zu minimieren und Fehler zu vermeiden • IoT-Messgeräte zur Trennung von Hard- und Software, um dem Systemanwender durch beliebige Plattformen die Freiheit zu eröffnen sich zu entscheiden, was für ihn den größten Mehrwert bietet • Moderne Software-Architekturen Mit diesen Tools bzw. Konzepten wird analysiert, wie Messaufgaben in einem Entwicklungsfahrzeug im Verhältnis zum heutigen Stand verändert und optimiert werden können bzw. an welcher Stelle sich durch den Einsatz von KI-Algorithmen bestehende Prozesse vereinfachen lassen. Ziel dabei ist es, die eingesetzten Ressourcen in der Fahrzeugentwicklung zu reduzieren, somit die Anzahl der hergestellten Erprobungsfahrzeuge zu verringern und durch optimierte Testabläufe mehr Daten aus weniger Fahrzeugen zu generieren. Dadurch können zudem die Kosten in der Entwicklung verringert werden, aber essentieller ist es, die Entwicklungszeit zu reduzieren bei gleichzeitiger Steigerung der Qualität. In Zeiten der Energiewende des Klimawandels [26, 58], in denen es immer wichtiger wird Energie respektive Ressourcen einzusparen und sinnvoll zu verwenden, liefert diese Arbeit einen Mehrwert. Die Forschungsfrage in dieser Arbeit lautet deshalb konkret: „Wie kann durch den Einsatz modernster IT-Infrastruktur die Fahrzeug-NetzwerkArchitektur (engl. Vehicle Network Architecture) zuverlässig identifiziert und damit die Fahrzeugdiagnose in der Entwicklung digitalisiert bzw. optimiert, abgesichert und gleichzeitig die Komplexität für den Anwender reduziert werden?“ In Abbildung 1.2 sind die vier Kriterien dargestellt, nach denen die Potenziale der Digitalisierung der Fahrzeugdiagnose bewertet werden. Hierbei ist die Durchlaufzeit ein messbares Bewertungskriterium: Je kürzer ein Testablauf ist, desto höher ist die Akzeptanz der Anwender und umso mehr Daten können die Entwickler für die Weiterentwicklung erwarten. Im Bereich Aktualität ist die Herausforderung adressiert, dass zwei Messsystem-Anwender die gleiche Messaufgabe auslösen können, aber da beide einen anderen Datenstand haben, gibt es keine einheitliche Qualität der Resultate. Da aus heutiger SW-Sicht hier ein struktureller Mangel in der Fahrzeugentwicklung vorliegt, muss durch eine Digitalisierung ein größerer Sprung gewagt werden. Die Vollständigkeit einer Messaufgabe ist ein weiteres gut messbares Kriterium und steht ebenfalls stellvertretend für die Reduzierung der Komplexität. Das soll bedeuten, dass das Aufnehmen eines neuen Messwertes durch den Steuergeräte-Verantwortlichen stattfindet und sich

1.2 Forschungsfrage

9

Abbildung 1.2: Die vier Bewertungskriterien der Forschungsfrage bezogen auf die Digitalisierung der Fahrzeugdiagnose in der Fahrzeugentwicklung alle Messaufgaben automatisch auf einen gültigen Stand aktualisieren, so dass der ECU-Verantwortliche unmittelbar die Funktionalität seiner Änderungen überprüfen kann. Die Genauigkeit beschreibt die Identifizierung des Fahrzeuges, somit die Bestimmung der Steuergeräte und deren SW-Variante sowie die Identifizierung der Fahrzeugnetzwerke. So werden über diese vier Kriterien unterschiedliche Digitalisierungsprozesse bewertet. Übertragen auf die Testablauferstellung lässt sich das Potenzial folgendermaßen formulieren: Ziel ist es, die Test-Durchlaufzeit auf ein Minimum zu reduzieren und gleichzeitig dafür zu sorgen, dass die Testabläufe so aktuell und vollständig wie möglich sind. Somit sollen etablierte Prozesse verschlankt und intelligenter gemacht werden, was zu einer Zeit- und Kostenersparnis beitragen wird. Um das sicherzustellen, werden in einem ersten Schritt Informationen über den detaillierten

10

1 Einleitung

Fahrzeugaufbau benötigt. Wie das genau realisiert werden kann, ist im Hauptteil dieser Arbeit formuliert. In einem zweiten Schritt können dann die Testabläufe passend zur identifizierten VNA, generiert und verteilt werden. Somit soll dieses System, das bislang stets Experten benötigt, eine Methodik zur Digitalisierung erhalten, um den Entwickler bestmöglich bei seiner Arbeit zu unterstützen. Gleichfalls soll es einem Laien ermöglicht werden, Fahrzeugmessungen durchzuführen, indem der Umgang mit der Komplexität von der Cloud mit diversen KI-Prozessen übernommen wird.

1.3 Aufbau der Arbeit Ziel des Kapitel 1 ist es zu motivieren, warum diese Forschungsarbeit den Weg in die Industrie finden soll und was die Gründe für die Ausarbeitung der Methode sind. Im Kapitel 2 werden dann die benötigten Grundlagen erklärt. Hier werden Bussysteme, Protokolle sowie die Technologien der Remote-Diagnose eingeführt, soweit diese relevant für den Inhalt der vorliegenden Forschungsarbeit sind. Durch das Kapitel 3 soll der Leser einen Eindruck gewinnen, wie derzeit Testabläufe in der Fahrzeugentwicklung erstellt und gepflegt werden. Hierbei werden die Vorund Nachteile der derzeitigen Umsetzung mit den Chancen der neuen Methode verglichen und ein Zukunftsszenario dargestellt, welche Veränderungen durch die neue Methode erzielt werden und theoretisch noch möglich sind. Schließlich bildet Kapitel 4 den Kern der vorliegenden Arbeit. Hier wird die Methode hergeleitet und alle Details, die zu einer Implementierung notwendig sind, detailliert beschrieben. Dabei kommen zwei unterschiedliche Algorithmen zum Einsatz, die zusammen am Ende eine verifizierte Liste an Steuergeräten und Bussystemen erzeugen. Im Kapitel 5 werden dann real gemessene Ergebnisse der in Kapitel 4 vorgestellten Methode abgebildet. Zudem wird eine hardwareunabhängige Diagnose-Plattform vorgestellt, mit der demonstrativ das in Kapitel 3 beschriebene Anwendungsszenario für den Beweis der Methode angewendet wird. Diese Arbeit wird abgeschlossen durch Kapitel 6, in dem die Ergebnisse aus Kapitel 4 und 5 zusammengefasst, kritisch hinterfragt und auf ihre Generalisierungsfähigkeit hin überprüft werden.

1.3 Aufbau der Arbeit

Abbildung 1.3: Kapitelübersicht für den Lesefluss der vorliegenden Arbeit

11

2 Grundlagen In diesem Kapitel wird eine allgemeine Einführung in die Fahrzeugdiagnose gegeben. Hierbei wird grundlegend dargestellt, wie ein Fahrzeugnetzwerk aufgebaut ist und funktioniert. Es gibt im Fahrzeug eine Selbstdiagnose (On-Board), die unerwünschtes Verhalten erkennt und entsprechend reagiert mit einer Alarmierung des Fahrers und/oder einem Fehlerspeichereintrag. Der Funktionsumfang der Selbstdiagnose kann über ein externes Tool (Off-Board) erweitert werden. In der Fahrzeugentwicklung entstehen unterschiedliche Funktionen für diverse ECUs und Fahrzeugfunktionen. Diese werden mit einem Testablauf/-sequenz auf ihre Korrektheit überprüft. Damit ein Ingenieur eine Messung am Fahrzeug durchführen kann, benötigt dieser in einem ersten Schritt diese Testsequenz. Zudem ist die RemoteDiagnose ein Themengebiet mit wachsender Bedeutung. Wir leben im Zeitalter der Daten, mit denen durch KI-Algorithmen neue Funktionen erschaffen werden. Aus diesem Grund werden Remote-Diagnose-Geräte, sogenannte IoT-Geräte, zum Sammeln der Daten eingesetzt. Die mit solchen Systemen erhobenen Daten eignen sich zur Suche nach Mustern für Algorithmen der KI, nachdem diese in der Cloud vorliegen. Damit wird dieses Kapitel abgeschlossen.

2.1 Entwicklungszyklen in der Fahrzeugindustrie Die Fahrzeugentwicklung verläuft oft nach dem V-Model. Dabei werden auf der einen (linken) Seite Anforderungen gesammelt und definiert, die wiederum auf der anderen (rechten) Seite getestet werden müssen. Diese V-Zyklen laufen bei der Entwicklung einer neuen Baureihe in größeren und kleineren zeitlichen Modellen ab. Prinzipiell ist die Entwicklung einer neuen Baureihe ein V-Model mit einer Zeitbasis von 3-5 Jahren. In diesem finden für die SW-Entwicklung pro Jahr zwei kleinere V-Modelle statt. Dabei handelt es sich um die Sommer- und die Wintervariante. Jede dieser Varianten schlägt sich in der Software aller im Fahrzeug möglichen Steuergeräte nieder. In der vorliegenden Arbeit wird auf die rechte Seite des VModels näher eingegangen, demzufolge auf das Testen der Fahrzeugfunktionen

© Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 R. T. Lutchen, Optimierung der Fahrzeugdiagnose durch eine cloudbasierte Methode zur Identifikation der Datennetze mit künstlicher Intelligenz, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-43113-6_2

14

2 Grundlagen

bzw. der Steuergerätefunktionen je V-Zyklus bis zum serienreifen Fahrzeug. Ein vereinfachtes beispielhaftes V-Model ist in Abbildung 2.1 dargestellt. Akzeptanz-Test

Anforderungen Spezifikation Entwurf Implementierung

System-Test

Validierung Verifikation

Integrations-Test Modul-Test

Abbildung 2.1: V-Model nach [7] Eine Sommervariante ist speziell für die Anforderungen im klimatischen Hochtemperaturbereich (z. B. Sahara) ausgelegt. Sobald dieser Zyklus beginnt, wird von allen Steuergeräte-Zulieferer-Firmen die neue SW-Variante erwartet. Diese wird daraufhin auch unter extremen Bedingungen getestet, also auf die Zuverlässigkeit im oberen positiven Temperaturbereich. Vergleichbar findet für die Wintervariante die Überprüfung der Steuergerätehardware und -software gegen Kälte statt. Das Ziel dieser Zyklen ist es, am Ende des Baureihenzyklus ein Fahrzeug zu entwickeln und zu testen, das robust und zuverlässig ist (detaillierte Informationen zum V-Model in [62]).

2.2 Fahrzeug-Netzwerk-Architektur Die Digitalisierung des Fahrzeuges schreitet stetig voran [72] und mit ihr erhält dieses immer umfangreichere Funktionen und kooperative Aufgaben [65]. Der logische Fahrzeugaufbau ist gemeint, wenn in dieser Arbeit von der VNA gesprochen wird. In einem Fahrzeug gibt es für jede Funktion ein entsprechendes ECU, das die Aufgabe zusammen mit den Sensoren und Aktoren, die an dieses angeschlossen sind, nach einem vorgegebenen Schema, dem Programmcode, löst. Die Steuergeräte müssen untereinander kommunizieren, wofür Bussysteme entwickelt wurden. In Abbildung 2.2 ist eine beispielhafte Architektur dargestellt. Im oberen Bereich der On-Board-Systeme sind unterschiedliche Steuergeräte zu erkennen, die über verschiedene Bussysteme mit einem zentralen Gateway verbunden sind. Über dieses

2.2 Fahrzeug-Netzwerk-Architektur

15

kann wiederum externes Equipment mit dem Fahrzeug vernetzt werden, so wie in dieser Arbeit z. B. das Applikationstool der Entwicklungs-IoT-Diagnosetester. GPS & GSM

Lenkrad LIN On-BoardSysteme

GetriebeECU

Navigation Gateway

Amaturenbrett

MotorECU

BremsenFahrwerkECU

Engine-CAN oder Flexray Body-CAN

TürECU

KlimaECU

Türbusse LIN

LichtECU Leuchten LIN

Radio

Infotainment-MOST

Bluetooth & WLAN DiagnosticsCAN (AutomotivEthernet)

Airbag PSI5

Head Unit Display

Mobiltelefon

Off-BoardSysteme

Werkstatttester

Abgastester

Fertigungstester

EntwicklungsTools

Abbildung 2.2: Fahrzeug-Netzwerk-Architektur eines modernen Fahrzeuges[76]

2.2.1 Einführung in Bussysteme In modernen KFZs werden verschiedene Bussysteme mit unterschiedlichem Einsatzzweck verwendet. Gründe hierfür sind teilweise technisch aber auch monetär bedingt. Am häufigsten kommt der CAN-Bus zum Einsatz. Weitere wichtige Vertreter für Bussysteme, die in heutigen Entwicklungsfahrzeugen eingesetzt werden und damit den Stand der Fahrzeuge von morgen darstellen, sind Local Interconnect Network (LIN), Media Oriented Systems Transport (MOST), A-Eth und FlexRay. Jedes Bussystem hat ein genormtes Protokoll, mit welchem der Kommunikationsaustausch durchgeführt wird. Ebenfalls hat jeder Bus ein eigenes Einsatzgebiet, für das dieser entwickelt wurde. Im Folgenden werden die Bussysteme detailliert vorgestellt.

16

2 Grundlagen

Für das Verständnis der Methode in dieser Arbeit ist in erster Linie der CAN-Bus relevant, da alle Herleitungen auf dieser Technologie beruhen. Jedes Bussystem unterstützt eine Netzwerktopologie, die möglichen sind in Abbildung 2.3 dargestellt. Bus

Ring

Stern

Hub/Switch

Maschen

Baum

Zellen

Abbildung 2.3: Mögliche Netzwerktopologien der Fahrzeugnetzwerke nach [5] Der CAN- und LIN-Bus folgen der Bustopologie, wohingegen der FlexRay ein Vertreter der Sterntopologie ist und der MOST-Bus die Ringtopologie umsetzt. Bei A-Eth liegt eine Maschen- oder Baumtopologie vor und die verbaute GSM-SIMKarte verwendet die Zellentopologie.

Controller Area Network (CAN) Der CAN-Bus ist ein verbreiteter Standard im KFZ, bei dem die Bustopologie zum Einsatz kommt. Es wird das Multi-Master-Prinzip verwendet, bei dem jeder Teilnehmer am Medium seine Nachrichten freiwillig überträgt und diese somit allen zur Verfügung stellt. Dieses Verfahren ist eine verbindungslose Broadcastkommunikation, bei der der Buszugriff geregelt werden muss. Dies geschieht über Identifier (IDs), die im Kopf der Nachricht (engl. Frame) enthalten sind. Bei Standard-CAN kommt ein 11 Bit- und bei CAN-ext ein 29 Bit-Identifier (ID) zum Einsatz. Dabei läuft der Buszugriff nach folgendem Schema durch.

2.2 Fahrzeug-Netzwerk-Architektur

17

Der Teilnehmer, der eine Nachricht übertragen möchte, hört das Medium ab. Sollte es frei sein und der Interframe-Space zur vorherigen Nachricht eingehalten, kann der Knoten (Teilnehmer) das Start-of-Frame-Bit setzen. Dieses signalisiert allen Busteilnehmern, dass eine Übertragung folgen wird. In der anschließenden Phase, die Arbitrierung genannt wird, übertragen alle Knoten, die den Buszugriff erhalten möchten, ihren ID. Dabei wird dieser bitweise verglichen, wobei der kleinste ID die höchste Priorität besitzt und am Ende den Buszugriff erhält. Konkret bedeutet das, dass logisch „0“ dominant ist und „1“ rezessiv. Wenn ein Knoten ein rezessives Bit in der Arbitrierung sendet, aber ein anderer die Busleitung mit einem dominanten Buspegel übersteuert, wird sich der Teilnehmer mit der höheren ID ab diesem Bit zurückziehen und es später erneut versuchen. Der CAN-Bus hat sich seinerzeit aufgrund der hohen Sicherheitsmechanismen im Bezug auf die Fehlerdetektion einer Nachricht durchgesetzt. Es besteht eine Restfehlerwahrscheinlichkeit von 4, 7 · 10−11 pro Botschaft nach [73]. Das liegt an dem Cyclic Redundancy Code (CRC) Generator-Polynom mit 15 bit = 𝑋 15 + 𝑋 14 + 𝑋 10 + 𝑋 8 + 𝑋 7 + 𝑋 4 + 𝑥 3 + 1 im Verhältnis zur Framelänge von 47 + 8 · 𝐷 𝐿𝐶 → 55 + 10 · 𝐷 𝐿𝐶 nach [60]. Das ist dennoch zu wenig für sicherheitskritische Anwendungen wie die elektronische Lenkung, die aufgrund dieser Tatsache in das Aufgabengebiet des FlexRay-Bussystems fällt. Zudem ist der CAN-Bus ebenfalls nur bedingt echtzeitfähig, da aufgrund der Arbitrierung nicht im Vorfeld festgelegt werden kann, wann welche Nachricht übertragen wird. Die maximale Baudrate beträgt 1 Mbit/s auf max. 40 m. Diese Limitierung wurde von dem CAN-FD-Standard aufgehoben, um mit A-Eth zu konkurrieren. Bei CAN-FD wird der Datenbereich (engl. Payload) mit höherer Datenrate übertragen und der Header sowie Trailer mit der Standardgeschwindigkeit, um kompatibel zum Standard-CAN oder CAN-ext zu sein. Dabei steigt nicht nur die Übertragungsgeschwindigkeit, sondern in derselben Proportion auch die Datenmenge, beispielsweise wenn die Standard-Baudrate 𝑓𝑏𝑎𝑠𝑖𝑐 = 500 kbit/s beträgt und anstatt 8-Byte- das Maximum von 64-Byte-Daten in der Payload übertragen werden sollen, dann steigt die Frequenz der Datenübertragung um den gleichen Faktor auf 𝑓 𝑑𝑎𝑡 𝑎 = 8 · 500 kbit/s = 4 Mbit/s an. Alle modernen Möglichkeiten (Standard, CAN-ext, CAN-FD) sowie Kombinationen zeigt das CAN-Frame in Abbildung 2.4.

2 Grundlagen

>= 3-Bit Bus Idle

4-Bit DLC

11- oder 29-Bit 7-Bit CAN-ID Control 19- oder 37-Bit Header

0-8 Byte Nutzdaten 0- oder 64-Bit Payload

15-Bit CRC

SOF

SOF

RTR IDE r0

18

ACK & EOF

25-Bit Trailer

Längenangaben ohne Bit-Stuffing, typisch sind 3-4 Stuff-Bits pro Frame

>= 3-Bit Bus Idle

Abbildung 2.4: Darstellung eines allgemeingültigen CAN-Frames nach [15] Local Interconnect Network (LIN) Der LIN-Bus ist im low-cost Bereich angesiedelt, ein Treiberbaustein kostet vergleichsweise wenig und ist damit auch ein häufig eingesetzter Sensor- und AktorBus im KFZ. Die Kommunikation findet mit einer Leitung gegen Masse statt, was Kupfer einspart und das Fahrzeuggewicht reduziert. Die maximale Buslänge beträgt 40 m und die Bandbreite 19,2 kbit/s. Die Netzwerktopologie ist die Bustopologie. Die Kommunikation findet nach dem Master/Slave-Prinzip statt. Es können 16 Teilnehmer adressiert werden. Eingesetzt wird der LIN-Bus häufig bei sicherheits- und echtzeit-unkritischen Anwendungen wie z. B. der Sitzverstellung, Spiegelverstellung oder den Fensterhebern. Der Master ist in aller Regel mit einem CAN-Controller ausgestattet, wodurch dieser die Daten seiner Ebene mit einer höheren Ebene austauschen kann.

Media Oriented Systems Transport (MOST) Der MOST-Bus wird im Infotainment Bereich eingesetzt. Physikalisch wird er als Ringtopologie ausgeführt. Das hat den Hintergrund, dass für den Fall, dass ein Teilnehmer ausfällt, es noch eine alternative Kommunikationsrichtung gibt. Als Übertragungsmedium kann hier ein optisches sowie ein elektrisches Medium zum Einsatz kommen. Das elektrische besteht aus fünf Leitungen, einerseits die Spannungsversorgung mit 5 V und Masse, sowie andererseits die unisolierte Twisted-Pair-Busleitungen mit einer separaten Steuerleitung. An einem MOST-Bus können maximal 64 Teilnehmer angeschlossen werden und es wird das Token-

2.2 Fahrzeug-Netzwerk-Architektur

19

Passing-Prinzip angewendet. Typische Netzwerkteilnehmer sind Radio, WLAN, Bluetooth, GSM-Antenne.

Automotive Ethernet (A-Eth) A-Eth hat Einzug in aktuelle Entwicklungsfahrzeuge erhalten und geht in eine ähnliche Richtung wie MOST in der ersten Ausbaustufe, aber ersetzt zum jetzigen Stand nicht, sondern erweitert. Sehr datenintensive Schnittstellen werden heute mit A-Eth ausgestattet, beispielsweise die Rückfahrkamera oder die 360◦ Kameravisualisierung. Auch werden Schnittstellen, an denen viele Daten zusammenlaufen, mit einer A-Eth-Schnittelle ausgestattet, typischerweise sind das Gateways. Die Kommunikation ist eine Point to Point (P2P)-Kommunikation und über Switches und Routingtabellen kann oft eine Baumtopologie entstehen.

FlexRay FlexRay ist ein Echtzeitbussystem für sicherheitskritische Anwendungsfälle. Es kommt das Time Division Multiple Access (TDMA)-Verfahren zum Einsatz, bei dem im Vorfeld jeder Zeitschlitz festgelegt wird und somit definiert ist, was wann übertragen wird. Die Topologie ist ein aktiv gemanagter Stern, an den maximal 64 ECUs angeschlossen werden können. FlexRay bietet zwei Kanäle an, mit denen entweder die Bandbreite verdoppelt oder die Daten ausfallsicher redundant übertragen werden können. Die maximale Länge des Bussystems beträgt 24 m bei einer Baudrate von 10 Mbit/s je Kanal. Aufgrund des TDMA-Verfahrens müssen alle Teilnehmer eine einheitliche Zeitbasis besitzen, ansonsten kann es vorkommen, dass der Knoten die Daten nicht in seinem Zeitfenster überträgt. Hierfür werden Kaltstartknoten festgelegt, die eine globale Zeitbasis schaffen, auf die sich per Frequenzund Offsetkorrektur alle Teilnehmer synchronisieren. Typische Anwendungsfälle sind X-By-Wire, wie z. B. das Fahrwerk, die Lenkung (engl. Stear-By-Wire) oder der Allradantrieb.

2.2.2 Einführung in Steuergeräte Ein Steuergerät ist ganz allgemein ein elektronisches Bauteil, das an Sollwertgeber, Sensoren und Aktuatoren angeschlossen ist und somit eine oder mehre-

20

2 Grundlagen

re Steuer- oder Regelungsaufgaben durchführen soll. Zudem besteht es intern aus verschiedenen Bauteilen. Das sind einerseits Bustreiber-Bausteine, um die diversen Bussysteme anschließen zu können. Andererseits Analog/Digital- und Digital/Analog-Wandler-Bausteine, um die Sensoren sowie Aktuatoren mit dem Steuergerät zu verbinden. Intern besteht ein ECU aus einem Mikrocontroller, dieser wiederum aus einem Arbeitsspeicher, Prozessor, I/O-Baustein sowie einem nichtflüchtigen Datenspeicher. Der Aufbau ist in Abbildung 2.5 dargestellt und stellt die Komponenten vereinfacht dar. Mikrocontroller Mikroprozessor

Rechenwerk

Programm- & Datenspeicher

Datenspeicher

Nichtflüchtiger Lesespeicher

Nichtflüchtiger & flüchtiger Schreib-/Lesespeicher

Bus

I/O Ein- & Ausgabeeinheiten Steuerwerk

Eingabe

Ausgabe

Abbildung 2.5: Übersicht der internen Struktur eines Steuergerätes- Mikrocontroller nach [62] Der intern eingezeichnete Bus hat mit den bereits eingeführten Bussystemen nicht viel gemeinsam. Bei der Vernetzung der Steuergeräte kommt ein serieller Bus (z. B. CAN) zum Einsatz, bei dem Bit für Bit übertragen wird. Hier müssen häufig größere Distanzen überwunden werden und die Kosten stehen im Vordergrund. Bei der Anbindung von Mikroprozessor an Datenspeicher oder Steuerwerk wird ein paralleles Bussystem eingesetzt. Hier werden somit bspw. je nach Prozessorarchitektur 8, 16, 32 oder 64 Bit gleichzeitig übertragen. Damit sind diese internen Prozessorbusse sehr performant, benötigen aber viele Verbindungen auf der Platine zwischen den einzelnen Komponenten. Diese Leiterbahnen müssen aufgrund der elektrischen Laufzeiten eines Signals alle exakt gleich lang sein. Weiterhin müssen

2.2 Fahrzeug-Netzwerk-Architektur

21

die Leiterbahnen vor elektromagnetischer Strahlung durch das Gehäuse geschützt werden. Ein ECU wird für unterschiedliche Anwendungen entworfen und optimiert. Die physischen Anforderungen an bspw. ein Motorsteuergerät sind vergleichsweise hoch, da es im Motorraum Wärme, Nässe, Verschmutzung und diversen anderen Faktoren z. B. Elektromagnetische Verträglichkeit (EMV) ausgesetzt ist. Zudem ist die Regelung des Motors ein Prozess, der in deterministischer Echtzeit ablaufen muss, wohingegen der Anwendungsbereich eines Steuergerätes, welches das Kombiinstrument ansteuert, andere Herausforderungen in den Fokus rückt. Hier sind die physischen Anforderungen vergleichsweise gering, aber dafür findet eine Interaktion mit dem Fahrer statt und so müssen Signale von allen im Fahrzeug verbauten Steuergeräten bzw. Systemen eingesammelt und visualisiert werden. Der Fahrer toleriert eine gewisse Antwortverzögerung nach seiner Eingabe, aber der subjektive Eindruck, den er an dieser Stelle erfährt, schlägt sich unter Umständen auf seine Meinung über das gesamte Fahrzeug nieder. So hat jedes Steuergerät andere Herausforderungen, die von den Entwicklern betrachtet werden. In Abbildung 2.6 ist das Anwendungsbeispiel eines Kombiinstrument dargestellt. Kombiinstrument Mikrocontroller

A/DWandler

Mikroprozessor

CANSchnittstelle

ZeigerAnsteuerung

Zeigerinstrument

DisplayAnsteuerung

Displays

LEDAnsteuerung

LEDs

MOSTSchnittstelle

Abbildung 2.6: ECU-Anwendungsbeispiel, hierbei handelt es sich um ein Kombiinstrument aus [62]

22

2 Grundlagen

2.3 On-Board-/Off-Board-Diagnose Bei der On-Board-Diagnose werden die Methoden definiert, die ein Steuergerät implementiert, um basierend auf der Kommunikation über die Fahrzeugbusse und seiner eigenen embedded Software, Fehler zu erkennen (Selbstüberwachung, Fahrzeugeigendiagnose [43]). Häufig sind in einem Steuergerät auch zwei Mikrocontroller verbaut, die mit unterschiedlicher Software zum gleichen Ergebnis der jeweiligen Steuerungs- oder Regelungsaufgabe kommen sollen. Modernere Ansätze beziehen noch einen digitalen Zwilling in der Cloud mit ein, hier wird auf einer dritten Instanz validiert, ob der Prozess so weit plausibel funktioniert bzw. bei einem ausgefallenen Sensor wird dieser von einem Modell aus der Cloud heraus ersetzt1 . Des Weiteren überwacht ein Steuergerät seine Sensoren und Aktuatoren, um etwaige Fehlfunktionen zu erkennen, beispielsweise wenn ein Gleichstrommotor (Fensterheber) nicht in einer gewissen Zeit seine Endlage erreicht oder wenn der Energiebedarf des Motors ungewöhnlich hoch ist (erreichen der Drehmomentgrenze bspw. durch Quetschgefahr). Diese Fehler werden von der On-Board-Diagnose des Steuergerätes erkannt, ggf. Fehlerbehandlungen eingeleitet und im Fehlerspeicher abgelegt. Durch das Auslesen des Fehlerspeichers erhält ein Entwickler oder eine Werkstatt im After-Sales detaillierte Informationen, was passiert ist und kann über Methoden Rückschlüsse ziehen, was verändert werden kann. So findet in der Fahrzeugentwicklung eine Reifegradsteigerung statt, wie in [40] hergeleitet ist. In Abbildung 2.7 ist die soeben beschriebene On-Board-Diagnose grafisch dargestellt und die Schnittstelle der Off-Board-Diagnose eingezeichnet. Bei der Off-Board-Diagnose kommt ein externes Gerät zum Einsatz, welches mit dem Fahrzeug verbunden wird. Stand heute wird bei einem After-Sales-Fahrzeug in aller Regel die On-Board-Diagnose (OBD-II)-Dose verwendet. Zukünftig wird das kabellos über den neuen Standard Service Oriented Vehicle Diagnostics (SOVD) ablaufen2 . Durch den neuen Standard entfällt die Hardwareabhängigkeit von einem OBD-II-Schnittstellengerät mit CAN und A-Eth Schnittstelle, zukünftig könnte eine Anwendungssoftware (engl. Application Software) (App) auf einem Smartphone genügen, um mit dem Fahrzeug Diagnoseprotokolle auszutauschen. In der Fahrzeugentwicklung werden alle Fahrzeugnetzwerke über Messkupplungen ausgeführt, 1 Aufgrund

der Latenzen, die trotz 5G-Funkstandard entstehen, können hier meist nicht die Echtzeitanforderungen, die für die Prozessregelung benötigt werden, erfüllt werden. 2 So wie durch [1, 9, 64, 70] auf der Diagnose-Tagung in Dresden im Mai 2022 durch den Arbeitskreis für die Standardisierung von Automatisierungs- und Messsystemen (ASAM) vorgestellt wurde.

2.3 On-board-/Off-board-Diagnose

23

Steuergerät Software (Verarbeitung) Eingangsparameter i

Steuerungs- und Regelungsfunktionen Ausgangsparameter o Überwachungsfunktionen On-Board-Diagnosefunktionen Sollwertgeber + Sensoren

...

Aktuatoren

Fehlerspeichermanager

Diagnosekommunikationsmanager

Diagnosetester Überwachungsfunktionen Off-Board-Diagnosefunktionen

Abbildung 2.7: Übersicht der On-Board- und Off-Board-Diagnose nach [62] diese werden an Daten-Logger angeschlossen. Dabei nimmt der Daten-Logger an jedem Bus teil und zeichnet gleichzeitig die logischen Signale aller Nachrichten auf. Damit ist es möglich, dass der Daten-Logger auch höhere Protokolle unterstützt, damit dieser gewisse Messaufgaben zyklisch im Fahrzeug durchführen kann (weiterführende Informationen in [41]).

2.3.1 Einführung in Protokolle Der CAN-Standard unterstützt viele Protokolle, wovon die für diese Arbeit relevanten im Folgenden kurz eingeführt werden. Die elektrischen Signale, die auf der Busleitung übertragen werden, sowie die Interpretation dieser in digitale Signale sind in der Norm ISO-11898 [34] definiert. Der High-Speed-CAN, der heutzutage eingesetzt wird, überträgt seine Signale über eine Differenzspannung. Eine Differenz der CAN-High- zur CAN-Low-Leitung von 0 V bedeutet, beide Leitungen führen 2,5 V und stellen eine logische „0“ dar (rezessiv). Die logische „1“ (dominant) wird durch eine Differenz von 2 V

24

2 Grundlagen

dargestellt, wobei CAN-High auf 3,5 V ansteigt und CAN-Low auf 1,5 V absinkt. Als Leitungscode wird Non Return to Zero (NRZ) mit Bitstuffing eingesetzt. Damit ist die unterste Ebene der Kommunikation soweit beschrieben. Es ist bekannt, wie eine logische 0 und 1 elektrisch abgebildet werden, sowie das Data-Frame der CAN-Kommunikation auf dieser Ebene eingeführt ist. Wenn Steuergeräte Daten austauschen wollen, wird das Transportschichtprotokoll: ISO 15765 [35] (engl. Transport Layer) (ISOTP) bzw. Transportschichtprotokoll: ISO 15765-2 [35] (engl. Diagnostic Communication over Controller Area Network) (DoCAN)-Protokoll eingesetzt. In diesen Protokollen ist festgelegt, wie die Daten verpackt werden, um einen einzelnen Frame zu transportieren und auch bei größerem Inhalt, wie die Übertragung von mehreren Frames, zu einer gesamtheitlichen Nachricht dargestellt wird. Wichtig an dieser Stelle ist, dass der Empfänger nicht überlastet wird. Wenn dieser einen Eingangspuffer von wenigen Frames besitzt, muss dieser erst abgearbeitet werden, bevor der Empfänger dem Sender signalisiert, dass es weitergehen kann. Für die Off-Board-Kommunikation kommen außerdem die Protokolle Kommunikationsprotokoll: ISO 14229 [33] - vereinheitlichte Diagnosedienste (engl. Unified Diagnostic Services) (UDS) und ODX hinzu, die später detaillierter vorgestellt werden. An dieser Stelle ist die Verschachtelung des Protokollstapels, wie dieser Ebene für Ebene aufgebaut wird, von Interesse. In Abbildung 2.8 ist dieser Zusammenhang für den Sender und den Empfänger dargestellt. obere Protokollschicht

Senden

Empfangen Header

Header untere Protokollschicht

Header

Payload

Payload

Payload

Trailer

Header

Trailer

Trailer

Payload

Trailer

Abbildung 2.8: Protokollstapel nach [76]

2.3.2 Einführung in die Identifizierung Bei der Teilnehmer-Identifizierung gibt es zwei grundsätzlich verschiedene Ansätze. Der aus der IT bekannteste ist, dass jeder Teilnehmer eine oder mehrere

2.3 On-board-/Off-board-Diagnose

25

Adressen bekommt. Mit so einem Teilnehmer wird infolgedessen eine Verbindung aufgebaut. Sobald diese besteht, können Daten ausgetauscht werden und am Ende wird diese wieder abgebaut. Dieses Konzept wird häufig Master/Slave-Prinzip oder Server/Client-Prinzip genannt, wobei der Master bzw. der Client die Adresse des Slave bzw. Server kennen muss, um eine Verbindung initiieren zu können. Bei dieser Art der Kommunikation fordert ein Teilnehmer seinen Kommunikationspartner auf Daten zu senden. Es findet somit eine Adressen-basierte Kommunikation statt, bei der der Master/Client dafür sorgen muss, dass wichtige Nachrichten priorisiert werden und keine Kollisionen auftreten. Wenn der Slave/Server einen neuen Dienst beherrscht, muss dies auf der Gegenstelle ebenfalls konfiguriert werden, da dieser sonst nicht abgefragt wird, wodurch ein initialer sowie vorlaufender Konfigurationsaufwand entstehen würde. Im Gegensatz dazu steht der in der Automobiltechnik am weitesten verbreitete Ansatz der nachrichtenorientierten Übertragung. Dabei ist es unbedeutend, welcher Teilnehmer im Netzwerk die Nachricht bereitstellt. Das bedeutet, es werden die Identifier (ID) identifiziert, die im Netzwerk übertragen werden, weil die Teilnehmer keine Adressen haben und auch nicht benötigen. Bei dieser Art der Kommunikation liegt das Multi-Master-Prinzip vor, bei dem die Nachrichten freiwillig per Broadcast allen Netzwerkteilnehmern zur Verfügung gestellt werden. Damit ist diese Kommunikation verbindungslos. Wenn ein Teilnehmer eine gewisse Nachricht anfordern will, dann sendet dieser den ID in einem Datenanforderungs-Frame und derjenige, der den angeforderten Messwert bereitstellen kann, überträgt diesen daraufhin. Hier muss nicht jeder Knoten jede Nachricht auf dem Bus für sich verwenden, sondern nur die, die zur Erfüllung der Funktionen relevant sind. Zudem erfolgt die Priorisierung der Nachricht über den ID, je kleiner dieser ist, desto wichtiger ist die Nachricht und wird auf dem Medium bevorzugt3 . Dies bedeutet, dass im ersten Fall jeder Teilnehmer konfiguriert wird und im zweiten jedes Bussystem.

3 Auf

die Untersuchung von Gemeinsamkeiten der Fahrzeugnetzwerke auf Identifikationsmerkmale wird in dieser Arbeit nicht weiter eingegangen. (Grundlegende Informationen befinden sich in der Bachelorarbeit [74], die Ergebnisse wurden für die vorliegende Forschungsarbeit gemeinsam erarbeitet und in der studentischen Ausfertigung schriftlich niedergeschrieben.)

26

2 Grundlagen

2.4 Remote-Diagnose Die Remote-Diagnose ist eine wachsende Disziplin, die es Entwicklern ermöglicht, Messwerte durch Testfahrer oder Fremdfirmen aufzunehmen und diese sehr zeitnah online auszuwerten [2]. Hier erhält die Digitalisierung somit durch modernste SW-Konstrukte Einzug in die Funktionsüberprüfung der Fahrzeugentwicklung. Dies ermöglicht es Messsystem-Herstellern, neuartige Plattformen zu erstellen, um durch Innovationen die Prozesse der Fahrzeugentwicklung, aber auch im AfterSales-Markt disruptiv neu zu denken. Eine mögliche Diagnose-Plattform wird in dieser Arbeit hergeleitet und dargestellt. Hierbei wird das Fahrzeug mit einer Messtechnik ausgestattet, die über die GSMFunkstandards (LTE/4G/5G) Daten an eine Cloud senden kann [24]. Weiterhin kann die Messtechnik Software-Updates Over The Air (OTA) für sich oder einzelne ECUs erhalten und so gezielt das Fahrzeug aktualisieren. Zukünftig ist es zu erwarten, dass diese extern angeschlossene Messtechnik in eines der zentralen Gateways integriert wird, welches aktuell durch den SOVD-Standard festgelegt wird. Der Vorteil an dieser Integration ist hauptsächlich, dass die Schnittstelle definiert ist und auch in Zukunft keine zusätzliche Hardware benötigt wird. Weiterhin können somit auch mit After-Sales-Fahrzeugen Messungen oder Updates durchgeführt werden. Steuergeräte-Updates werden nicht mehr in der Werkstatt, sondern können über Nacht durchgeführt werden. Moderne Fahrzeuge haben alles bereits integriert, um dem Kunden diesen Vorteil anzubieten. Nachteilig ist, dass über die neue Schnittstelle nur aufbereitete Daten zur Verfügung stehen, wie der OEM diese veröffentlichen möchte. Lediglich der IT-Sicherheitsaspekt bedarf an dieser Stelle einer detaillierten Analyse, da durch diese Funktionalität das KFZ Teilnehmer im Internet wird, hierdurch ist ein potenziell unerwünschter Zugriff dritter möglich [12]. Das ist wiederum der Vorteil der externen Messtechnik, bei der sich genau mit diesen Fragestellungen bereits IT-Teams auseinander gesetzt haben und welche zusätzlich durch den Fahrer ausgebaut werden kann.

2.4.1 Big Data „Daten sind das neue Gold bzw. Öl unseres Jahrhunderts.“ [57] Aufgrund der steigenden Anzahl an Funktionen und der Vernetzung derselben gibt es mehrere Ansätze, wie mit Daten umgegangen werden kann. Der naheliegendste Ansatz ist, dass

2.4 Remote-Diagnose

27

so viele Daten wie möglich gesammelt und gespeichert werden. Wenn in Zukunft eine Untersuchung durchzuführen ist, können die gesammelten Daten gezielt nach einer Anforderung untersucht werden. Hierdurch kann eine Komponente oder eine Software-Fehlfunktion unter Umständen detektiert und behoben werden. Jedoch ist es bei diesem Ansatz so, dass nach der sprichwörtlichen Nadel im Heuhaufen gesucht wird. Bei einer derart großen Anzahl an Daten ist es einem Menschen nicht mehr mit vertretbarem Aufwand möglich, eine Analyse zu erstellen und entsprechende Korrelationen aufzuzeigen, einerseits weil die Daten nicht gezielt auf eine Aufgabenstellung bezogen aufgenommen und ausgewertet wurden und anderseits weil die Datenmenge meist nur noch mit automatisierten Prozessen zu beherrschen ist, aufgrund der Speicher- und Rechenkapazitäten, die benötigt werden. Daher gehen Wissenschaftler häufig einen anderen Weg, welcher Smart Data lautet. Hier werden die Daten, welche erhoben werden, feingranular definiert und im selben Stil wie Big Data [20] aufgezeichnet. Aber wie unterscheidet sich Smart Data von Big Data? Das Ziel von Big Data ist es, so viele Daten wie erreichbar in einem so schnellen Raster wie realisierbar aufzuzeichnen und diese an ein Data Lake zu übertragen. Die Daten werden beispielsweise an ein Hadoop Cluster [20] gesendet, welches darauf ausgelegt ist, diese Daten in Blöcken zu speichern und mehrere Backups zu erstellen. Im Gegensatz dazu steht Smart Data. Hier geht es darum, einen Prozess gezielt zu überwachen. In aller Regel ist die gesamte Toolchain implementiert und die Daten werden nicht nur gesammelt, sondern auch synchron ausgewertet. Hier werden die Daten nicht in Blöcken an ein Cluster übertragen, sondern an einen definierten Server, bei dem sich der Dienst zum Beispiel über eine REpresentational State Transfer (REST)-Applikationsschnittstelle (engl. Application Programming Interface) (API) authentifizieren muss. An die REST-API wird dann die abgeschlossene Messung übermittelt. Die REST-API entscheidet aufgrund der Metadaten, welcher der nächste Subprozess ist, der aufgerufen werden muss. Big Data wird in der Industrie eingesetzt, da Firmen sich einen Wettbewerbsvorteil von der Erhebung der Daten zu einem späteren Zeitpunkt erhoffen [4]. Die Unterschiede von Big Data und Smart Data sind zusammengefasst in Tabelle 2.1. In aller Regel werden die Begriffe Big Data und Smart Data in vielen Quellen sehr unterschiedlich definiert und verwendet. Dieses Kapitel soll daher festlegen, wie diese Begriffe in dieser Arbeit einzuordnen sind. Beide Methoden sind wichtig und bieten sich für verschiedene Anwendungen an. Im Folgenden werden SmartData-Prozesse mit vollständigen Prozessketten dargestellt, da alles, was in dieser

28

2 Grundlagen

Tabelle 2.1: Vergleich: Big Data mit Smart Data Kriterium Volume (Größe)

Big Data Viele Daten in Blöcken strukturiert

Velocity (Geschwindigkeit)

Keine Echtzeitanforderungen die Daten müssen nur sicher vorhanden sein.

Variety (Bandbreite)

Zyklischer Upload von 64 MB Blöcken

Komplexität

Daten werden nur gespeichert und zu einem späteren Zeitpunkt analysiert.

Smart Data Wenige Daten in Dateien strukturiert Es können Echtzeitanforderungen gestellt werden, der Verbleib der Dateien ist nach dem Prozess optional. Azyklischer Upload von Dateien von teilweise > 100 MB Daten werden unmittelbar ausgewertet und es erfolgt eine Reaktion.

Arbeit hergeleitet wird, für die Methode der Fahrzeugidentifikation notwendig und relevant ist.

2.4.2 Cloud-Technologien Bei den Cloud-Technologien gibt es ähnlich wie bei Big Data sehr unterschiedliche Definitionen. Es gibt zum einen die öffentlichen Cloud-Anbieter wie beispielsweise Microsoft Azure und Amazon AWS, um nur die beiden größten zu nennen. Zum anderen kann sich jede Firma eine eigene private Cloud in ihre UnternehmensInfrastruktur einbinden. Wenn die interne private mit der öffentlichen Cloud kombiniert wird, entsteht eine hybride Cloud-Lösung. Die klassische IT-Landschaft eines Unternehmens, bevor es Cloud-Ansätze gab, besteht vereinfacht ausgedrückt aus Applikations- und Daten-Servern. Auf Applikationsservern werden unternehmensinterne Programme und Dienste ausgeführt, beispielsweise ein Web-, Mail-, Dynamic Host Configuration Protocol (DHCP)-, Domain Name System (DNS)- und ein Active Directory (AD)-Server. Auf den

2.4 Remote-Diagnose

29

Datenservern werden die Daten des Unternehmens gespeichert und durch Backups gesichert. Jedes Unternehmen, unabhängig von der Größe benötigt eine IT-Abteilung, die diese Server aufsetzt, pflegt und wartet. Die Server stehen physisch im Unternehmen und sind gemäß des Wissensstands der IT-Abteilung gegen Angreifer aus dem Internet geschützt. Wenn das Unternehmen mehrere Standorte besitzt, werden diese häufig durch eine Standleitung verbunden. Welche Herausforderungen sollen Cloud-Technologien angehen und wie werden diese eingesetzt? Einerseits sollen Cloud-Ansätze Kosten sparen, anderseits die Sicherheit erhöhen und gleichzeitig die Komplexität reduzieren. Wo entstehen die Kosten beim konventionellen Ansatz? Die eigene IT-Abteilung kostet Geld, die Standleitung, die die einzelnen Standorte verbindet, ebenfalls. Die Sicherheit gegenüber Angreifern wird dahingehend verbessert, dass bei Microsoft ein großes Team kontinuierlich Verbesserungen und Sicherheitslücken abstellt, wohingegen die eigene IT-Abteilung unter Umständen aufgrund der Vielfalt an Aufgaben diesem nicht gerecht werden kann. Dienste wie ein DHCP- oder DNS-Server könnten bei einem Cloud-Ansatz mit wenigen Klicks erstellt und in Betrieb genommen werden. Der Cloud-Ansatz ermöglicht ebenfalls das Skalieren von Prozessen auf Grundlage der Nachfrage, somit die intelligente Rechenzeitverteilung, und im Extremfall verhindert dieser Ansatz die Ausfallzeiten von Diensten, da Dienste einfach beim Ausfall eines physischen Servers auf einem anderen im Rechenzentrum gestartet werden können. Es gibt nicht mehr wie früher die statische Zuordnung Server zu Dienst. Damit erhält das Unternehmen sehr viele Freiheitsgrade bei der Definition der IT-Infrastruktur. Im Folgenden werden die Prozesse als Cloud-Ready implementiert. Das bedeutet, dass die Programme einerseits klassisch mit der Aufgabenplanung im WindowsServer-Betriebssystem gestartet werden können (Dieser Ansatz entspricht einem eigenständig betriebenen Server (On Premis) oder dem ersten Cloud-Service Infrastructure as a Service (IaaS)). Sie beinhalten aber auch zudem ein DockerContainerfile, was es ermöglicht, die Anwendungen in einem Cloud-Cluster Platform as a Service (PaaS) laufen zu lassen. Für die Entwicklung eines Prozesses ist der IaaS-Ansatz vorteilhaft, da hier eine größere Kontrolle vorliegt. Jedoch ist im produktiven Einsatz eher ein Kubernetes zu empfehlen, welches einem PaaS-Ansatz entspricht. Denn im zweiten Fall kann die Applikation automatisch skalieren und wird im Fehlerfall selbstständig neu gestartet, um nur zwei Vorteile zu nennen.

30

2 Grundlagen

Zusammenfassend lässt sich Folgendes sagen4 : Es wird prinzipiell darin unterschieden, wer für die laufenden Applikationen verantwortlich ist. Bei einem eigen aufgestellten Server ist der Betreiber in der alleinigen Verantwortung. Bei einer privaten oder öffentlichen Cloud übernimmt der Anbieter ein Stück der Verantwortung. Das kann im Falle einer IaaS-Cloud-Lösung so aussehen, dass Rechenleistung eingekauft wird, aber alle Dienste auf dem Server selber eingerichtet und verwaltet werden. Oder es sieht so aus, dass im Falle einer PaaS-Cloud-Lösung, die Dienste gestartet und gestoppt werden, auf welchem Server diese laufen, wird verborgen. Der Cloud-Anbieter kümmert sich um die Verfügbarkeit, das Unternehmen muss nur noch die Applikation stellen oder parametrieren. Die höchste Abstraktion stellt die SaaS-Cloud-Lösung da. Hier bekommt das Unternehmen beispielsweise eine Homepage zur Verfügung gestellt und der Cloud-Anbieter kümmert sich um alles für seinen Kunden.

2.4.3 IoT-Messwerkzeuge Klassisch wird in der Fahrzeugentwicklung eine Messung mit dedizierter Hardware durch einen Entwickler im Fahrzeug durchgeführt. Hierfür benötigt dieser einen Schnittstellen-Treiber (VCI) über welchen sich der Entwickler mit der OBD-IIBuchse des Entwicklungsfahrzeuges verbindet. Daraufhin muss diese Person noch die richtige SW auf dem Rechner installiert, sowie das aktuellste Projekt für das Fahrzeug eingerichtet haben. Sollte alles passend sein, ist eine Messung möglich, welche der Entwickler händisch auswertet, durch verschiedene Interpretationstools aufbereitet und auch auf diverse Datenbanken ablegen kann, wenn er diese seinen Kollegen zur Verfügung stellen möchte. Der Ansatz, den ein IoT-Prozess geht, sieht hingegen anders aus. Hier wird der gesamte Prozess automatisiert und eine Plattform geschaffen, mit der die Daten visualisiert werden. 4 Anschaulich verdeutlichen soll das ein Pizzabeispiel. Es gibt insgesamt vier Möglichkeiten, eine Pizza

zu genießen. Die erste ist eigene Handarbeit. Die Pizza wird vollständig in Eigenleistung erstellt und gegessen. Das spiegelt das Beispiel On Premis Server wieder. Die zweite Möglichkeit ist, dass eine Tiefkühlpizza gekauft wurde. Der Anbieter hat die Zutaten bereits verarbeitet und die Pizza hergestellt, nun liegt es am Anwender, diese richtig zu backen und zu genießen. Dieses Beispiel ist der IaaS-Ansatz. Bei dem PaaS wird die Pizza vom Lieferdienst geliefert. Der Kunde muss nur noch ein Getränk und einen Tisch hinzufügen, um alles andere hat sich der Lieferservice gekümmert. Die letzte und vierte Variante ist das Essen in einem Restaurant, was dem Software as a Service (SaaS)-Cloud-Ansatz gleichzustellen ist. Der Anbieter kümmert sich um alles.

2.4 Remote-Diagnose

31

Bei diesem Prozess wird ein IoT-Messwerkzeug in ein Entwicklungsfahrzeug eingebaut. Dieses Gerät besitzt Kommunikationsschnittstellen mit dem System, welches es überwachen und oder steuern soll. Im vorliegenden Beispiel ist das beispielsweise die OBD-II-Buchse. Weiterhin besitzt dieses Gerät eine Schnittstelle (GSM-SIM-Karte) zum Internet, über die es die Messungen automatisch überträgt und Messaufgaben aktualisiert und herunterlädt. Die Gegenstelle im Internet ist eine REST-API, die alle Subprozesse auf dem Server bzw. auf der privaten Cloud automatisiert. So wird eine Messung bspw. automatisch auf allen Datenbanken abgelegt, um diese allen Entwicklern zur Verfügung zu stellen. Die Daten können in ein lesbares Format konvertiert und grafisch aufbereitet werden. Die Entwickler können die Messungen auf der Webseite der Applikationsplattform des IoT-Systems einsehen. Eine automatische Alarmierung bei Grenzwertverletzungen und Fernwartung ist ebenfalls möglich. Soweit zum Beispiel der klassischen Messung in der Fahrzeugentwicklung. Das Einführen eines IoT-Messsystems hat jedoch noch weitreichendere Vorteile. So kann dieses Systeme zentral verwaltet werden und Messaufgaben immer tagesaktuell halten. Zudem kann der gesamte Prozess der Fahrzeugmessungen automatisiert werden. Beispielsweise kann eine Messung bei jedem Start (Wake Up) oder bei jedem Fehlerspeichereintrag stattfinden. Über den gesamten Fahrzyklus wird ein Lastprofil erstellt, um zum Beispiel „Schaltruckler“ analysieren zu können. Der Prozess der Datenerhebung im Entwicklungsfahrzeug kann hierdurch automatisiert und damit eine erhöhte Testabdeckung gewährleistet werden. Abschließend benötigt ein derartiges System die sensiblen und schützenswerten Dateien ausschließlich auf dem Server und nicht auf beispielsweise dem Laptop eines jeden Entwicklers. Dies wirkt sich zusammengenommen positiv auf die Herausgabe von Versuchsfahrten aus, da das System automatisch misst und bspw. eine externe Firma keine sensiblen Daten erhalten muss. Als besondere Herausforderung ist jedoch zu sehen, dass so ein System eine vergleichsweise lange Integrationszeit benötigt, bis es dem Kunden den entscheidenden Mehrwert bietet und sich damit für den Anbieter monetär lohnt. Das liegt am Konzept, denn ein IoT-Messsystem ist im Speziellen nichts weiter als ein VCI mit mehr Konnektivität. Dahingegen findet die Automatisierung der Messaufgaben auf dem Server statt und es muss eine Webseite / Dashboard für den Kunden entstehen. Durch das entstehende System werden Potenziale der Automatisierung ermöglicht, die früher nicht vorstellbar waren, was es dem Kunden und Anbieter erschwert zu priorisieren, welche Funktionen verpflichtend oder optional sind. Somit resultiert eine verlängerte Integrationszeit, aber durch die

32

2 Grundlagen

Zentralisierung sind neue Anforderungen an das System anschließend schneller zu realisieren.

3 Testablauferstellung in der Fahrzeugentwicklung Ein Testablauf ist ein Überbegriff für eine Messaufgabe, die in einem Fahrzeug durchgeführt wird. Hierbei werden unterschiedliche Programme sowie Anwendungsbereiche abgedeckt. Der wahrscheinlich einfachste Anwendungsfall ist das Abhören und Speichern einer auf einem physikalischen Bussystem übertragenen Kommunikation. Sollte ein CAN-Bussystem abgehört werden, spricht man von einer FCT-Messung. Dabei wird ganz offensichtlich keine Verbindung (Socket und/ oder Session) mit einem Steuergerät aufgebaut. Die Nachrichten (z. B. Messwerte) werden freiwillig vom Master übertragen und stehen jedem Teilnehmer zur freien Verfügung. Bei dieser Art der Kommunikation wird die On-Board-Kommunikation protokolliert, aufgrund dessen das die Daten, die zwischen den Steuergeräten zum Aufrechterhalten des Fahrbetriebes ausgetauscht bzw. aufgezeichnet werden. Hierbei ist definiert, was jedes Steuergerät1 an möglichen Nachrichten übertragen kann und in welchem zeitlichen Abstand dies automatisch passiert. Anstatt nur passiv den Bus abzuhören, kann ein Diagnosetester auch aktiv Nachrichten oder andere Anwendungen übertragen. Dieses aktive Eingreifen kann von Fahrzeugentwicklern genutzt werden, um individuelle Steuergeräte oder steuergeräteübergreifende Funktionen zu überprüfen oder eigene Testabläufe für spezifische Anwendungsbereiche zu entwickeln. In der Fahrzeugentwicklung haben sich Standard-Skripte (Testabläufe) etabliert, mit denen ein Entwickler an ein unbekanntes Fahrzeug herantreten kann und imstande ist, die wichtigsten Steuergeräte und deren Fehlerspeichereinträge auszulesen, um sich einen ersten Überblick zu verschaffen, bevor spezifischere Skripte im Fahrzeug ausgeführt werden. Eines dieser Standard-Skripte ist beispielsweise der „Kurztest“. Bei einem Kurztest wird versucht, von so vielen Steuergeräten wie möglich die Fehlerspeicher-Fehlercodes (engl. Diagnostic Trouble Codes) (DTCs) zu sammeln und in einem einheitlichen Format darzustellen. Ein anderer Testablauf kann zum Beispiel ein „Dauerlauf“Skript sein. Unter einem Dauerlauf wird verstanden, dass von so vielen Steuergerä1 Eine

Steuergerätegruppe ist bspw. das Motorsteuergerät welches auf die Req.ID 0x7E0 und Res.ID 0x7E8 reagiert. Dabei ist es unbedeutend, ob sich hinter dem Motorsteuergerät ein Diesel-, Otto-, Hybrid- oder Elektromotor-Steuergerät verbirgt.

© Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 R. T. Lutchen, Optimierung der Fahrzeugdiagnose durch eine cloudbasierte Methode zur Identifikation der Datennetze mit künstlicher Intelligenz, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-43113-6_3

34

3 Testablauferstellung in der Fahrzeugentwicklung

ten wie möglich so viele Informationen wie gewünscht gesammelt und gespeichert werden. Zusätzlich, da es sich hier um eine Diagnoseablaufbeschreibung: ISO 13209 [31] (engl. Open Test sequence eXchange) (OTX)-Skript handelt, können noch Ablaufprozesse definiert werden. Hierdurch können komplexere Testabläufe erstellt und eingesetzt werden, je nach Bedarf des Fahrzeug-Herstellers, beispielsweise kann ein Testablauf überprüfen, ob der Abgastrakt funktionstüchtig ist, indem verschiedene Stellorgane positioniert und eine spezifische Leerlaufdrehzahl eingestellt wird. Hierfür muss ein Testablauf nicht nur Daten sammeln, sondern aktiv Stellorgane im Fahrzeug ansteuern und auf Endlagensignale warten, bevor eine Zwischenmessung durchgeführt und protokolliert wird. Weiterhin ist es auch geläufig, einen Testablauf für die Katalysator-Regeneration oder -Entschwefelung vorzuhalten. Die Anwendung von Testabläufen ist in vielen Fällen möglich. Die technische Implementierung dieser Testabläufe verwendet dabei unterschiedliche Entwicklungstools. Wenn ein Testablauf es beinhaltet, auf allen Schnittstellen gleichzeitig2 jede übertragene Nachricht zu lesen, dann werden an dieser Stelle synchrone FCT-Messungen erzeugt und gespeichert. Hierbei wird die binäre Datenübertragung mitgeschrieben, welche dem ISOTP-DoCAN-Protokoll folgt. Die Umrechnungsfunktionen befinden sich wiederum in den ARXML- oder DBC-Dateien des jeweiligen Bussystems. Bei den angesprochenen aktiven Diagnoseskripten / Testabläufen, z. B. „Kurztest“, kommen weitere Protokolle zum Einsatz. Das Trägerprotokoll der Transportschicht ist weiterhin ISOTP-DoCAN, allerdings wird der Datenabschnitt (die Payload) nun aus der Anwendungsschicht heraus befüllt. Es werden Daten aus einer ODX-Datei über das UDS-Protokoll segmentiert und verpackt. Um den Datenursprung und die Paketgenerierung besser nachvollziehen zu können, ist in Abbildung 3.1 das klassische ISO-OSI-7-Schichten Modell auf der linken Seite dargestellt. Die im CAN-Bus verwendeten Schichten sowie Protokolle sind auf der rechten Seite der Abbildung eingetragen. Es ist zu erkennen, dass sich eine CAN-Nachricht mit drei Schichten abbilden lässt. Konkret bedeutet dies, dass der Entwickler, der den Kurztest erstellt und erweitert, die Messwerte, die ihn interessieren, aus einer ODX-Datei auswählt und sich so eine Testablauf-Datei zusammenstellt. Sobald diese Datei ausgeführt wird, muss der Diagnosetester die Messwerte in das UDS-Protokoll verpacken und diese wieder in das DoCAN-Protokoll, um es an das gewünschte Steuergerät zu senden. So eine 2 Im

vorliegenden Fall des verwendeten IoT-Diagnosetestgerätes wären das insgesamt zwölf CANNetzwerke.

3 Testablauferstellung in der Fahrzeugentwicklung

35

ISO - OSI - 7 - Schichten-Modell

CAN-Bus - Schichten

7.

Anwendung / Applikation - Applikationsschnittstellen

ODX ISO 22901

6.

Darstellung / Presentation - Verschlüsseln

OEM spezifisch

5.

Kommunikationssteuerung / Session - Aufbauen einer Verbindung

UDS ISO 14229

4.

Transport - Segmentierung der Nachricht

3.

Vermittlung / Network - Logische Adressierung

2.

Sicherung / Data Link - Physikalische Adressierung

1.

Bitübertragung / Physical - Leitungscodes

ISOTP / DoCAN ISO 15765

CAN-Bus ISO 11898

Abbildung 3.1: Praktische Verwendung des ISO-OSI-7-Schichten-Modells am Beispiel des CAN-Bus Skript-Datei, bei der ausschließlich Messwerte abgefragt werden, ist vergleichsweise schnell erstellt und kann mit unterschiedlichen Frameworks durchgeführt und verarbeitet werden. Im Falle des Dauerlauf-Skriptes, bei dem Stellorgane im Fahrzeug auf Positionen gefahren werden und dann daraufhin Messwerte passend zum Zustand angefordert und gespeichert werden, wird eine Ablaufbeschreibung benötigt. In der Fahrzeugentwicklung, kommt an dieser Stelle häufig die Modellierungssprache OTX zum Einsatz. Hier erstellt der Entwickler eine Datei, die im XML-Format vorliegt und einen Messablauf beschreibt, wie die Messung ablaufen soll und zu welchen Zeitpunkten Messwerte aufgezeichnet werden. Somit ist zu erkennen, dass zu den unterschiedlichen Anwendungsbereichen auch unterschiedlich komplexe Messaufgaben gehören. Für jeden Diagnosetester (Entwicklung, After Sales, ...) müssen diese und viele weitere Testabläufe erstellt und gepflegt werden. Die Entwickler haben die Verantwortung, darauf zu achten, dass die Testabläufe zum Entwicklungsfahrzeug passen und keinen Schaden an diesem

36

3 Testablauferstellung in der Fahrzeugentwicklung

anrichten. Das bedeutet, dass alle erstellten Testabläufe eine gemeinsame Herausforderung haben: Das Identifizieren der Steuergeräte und der Netzwerke im Fahrzeug.

3.1 Manuelle Erstellung Der derzeitige Stand der Entwicklung ist, dass die Testabläufe für jeden Diagnosetester in einem eigenem Team erstellt und je nach Dringlichkeit einmal pro Woche oder Monat veröffentlicht werden. Dadurch entstehen etwa 12-52 Versionen pro Jahr und pro Software, die im Einsatz/Umlauf sind. Der Testingenieur kann infolgedessen überprüfen, ob die Unstimmigkeiten, die er gemeldet hat, beseitigt wurden und ob die Testabläufe erfolgreich durchlaufen. Weiterhin kann der Steuergeräteverantwortliche3 validieren, ob die Messwerte, die er beauftragt hat, in der neuen Version berücksichtigt und von den gewünschten Skripten unterstützt werden. Zudem muss das Team, welches den Diagnosetester weiterentwickelt, im ständigen Kontakt mit den Entwicklern der Fahrzeug-Sicherheitsmechanismen sein, um die neuesten Mechanismen frühzeitig einzupflegen. Bei der Erstellung von grafischen Diagnoseoberflächen (grafische Benutzeroberfläche (engl. Graphical User Interface) (GUI)) ist die Zusammenstellung der Steuergeräte relevant4 , so muss ein Fahrzeugnetzwerk-Experte den Entwicklern der Diagnoseapplikation melden, welche Kombinationen in der neuen Baureihe vorkommen. Aus diesen Abhängigkeiten untereinander ist es ersichtlich, dass eine Informationsvernetzung der einzelnen Expertengruppen entsteht. Diese ist in Abbildung 3.2 symbolisch dargestellt, um zu verdeutlichen, dass bei diesem Prozess eine regelmäßige Kommunikation und Abstimmung von Bedeutung ist. Die TestablaufErstellung ist wie dargestellt ein manueller Prozess, an dem viele unterschiedliche Disziplinen beteiligt sind. Häufig werden unterschiedliche Diagnosetester in Entwicklung und Produktion (sowie After Sales) eingesetzt. Ein Grund hierfür ist, dass ein Diagnosetester in der 3 z.B.

Diesel-Motor-ECU, Otto-Motor-ECU, Getriebe-ECU, . . . Konzepte in der automatischen Generierung von Diagnoseoberflächen wird in dieser Arbeit nicht näher eingegangen. (Grundlegende Informationen sind festgehalten in der RD-CollegeAbschlussarbeit [18], die Ergebnisse wurden für die vorliegende Forschungsarbeit gemeinsam erarbeitet und in der studentischen Ausfertigung schriftlich niedergeschrieben.)

4 Auf

3.1 Manuelle Erstellung

37

Abbildung 3.2: Experten, die involviert sind bei der Erstellung einer Testapplikation, um Fahrzeugmessungen für Erprobungsfahrten zu ermöglichen [50]. Entwicklung mehr Freiheitsgrade anbieten kann und nicht so restriktiv und normgerecht sein muss, was das Arbeiten mit Fahrzeugen in frühen Softwareständen erleichtert. Andererseits weisen Entwicklungsfahrzeuge teilweise sehr unterschiedliche Netzwerk- bzw. Steuergerätekonfigurationen auf. Ein Diagnosetester in der Produktion kann hingegen besser optimiert werden, da hier nur serienreife Fahrzeuge angeschlossen und standardisiert überprüft werden. Somit wird im weiteren Verlauf der Entwicklungs-Diagnose-Tester betrachtet, da dieser das erste Entwicklungsfahrzeug bis zum Serienfahrzeug begleitet und mit jedem beliebigen Aufbau innerhalb der Entwicklungszeit konfrontiert wird. Wie bereits beschrieben sammelt das Team des Entwicklungs-Diagnose-Testers die Anforderungen und Änderungswünsche der Steuergeräte-, Netzwerk- und Sicherheitsexperten sowie der Anwender, um ihre Applikation anzupassen und aktualisierte Versionen zu veröffentlichen. Wartezeiten von bis zu zwei Monaten auf einen Änderungswunsch verzögern jedoch die Entwicklung und sind zukünftig nicht mehr tragbar. Diese Problematik kann aber in erster Linie durch das Team in wöchentlichen Updates temporär gelöst werden. Dadurch steigt aber die Softwarevarianz, die im Umlauf ist, und dies animiert jeden Anwender zu regelmäßigen Aktualisierungen. Dieser Prozess hat dennoch

38

3 Testablauferstellung in der Fahrzeugentwicklung

zur Folge, dass das Entwicklungsfahrzeug, in welchem der Änderungswunsch des Testablaufes aufgetreten ist, häufig stillgelegt wird, bis die Änderung durchgeführt und ausgerollt ist. Ein stillgelegtes Entwicklungsfahrzeug ist ein Zustand, dem zeitnah begegnet werden muss, um eine hohe Effizienz zu gewährleisten. Um nicht in solche zeitlichen Abhängigkeiten zu geraten, wird am Anfang einer neuen ECUSW-Variante5 häufig eine sogenannte „Testklausur“ durchgeführt. Dabei geht eine Task Force, gebildet aus Verantwortlichen der eingesetzten Steuergeräte und Diagnosesysteme sowie Testfahrern und Mitarbeitern von unterschiedlichen Baureihen, auf eine meist zweiwöchige Erprobung, bei der versucht wird, viele Testablauffehler zu beseitigen, von möglichst vielen Fahrzeugen vollständige Messungen zu erhalten und die Toolketten sowie den Prozess zur Analyse dieser Daten zu konkretisieren. Bei so einer Klausur wird auch entschieden, welche neuen Funktionen beim Zulieferer des Steuergerätes bestellt und wie diese zukünftig überprüft werden sollen. Konkret bedeutet das, dass der Verantwortliche des ECU beschließt, ab der nächsten Softwarevariante eine neue Funktion in das Steuergerät aufzunehmen. Den Namen des Diagnosemesswertes meldet der Steuergeräteverantwortliche dem Diagnosesystemverantwortlichen, damit dieser den neuen Messwert in der Zukunft berücksichtigt und somit jeder Testingenieur, der eine Messung durchführt, diesen mit aufzeichnet. In der Entwicklung werden diverse Messaufgaben entwickelt und bereitgestellt, deren Testabläufe aus unterschiedlichen Bedatungs- bzw. Quelldateien entstehen. Einen Überblick über die Vielfalt an Möglichkeiten soll die Abbildung 3.3 geben. Es sind drei Datenbasen (A2L, ARXML, ODX) dargestellt sowie welche Standardmesstypen aus den jeweils gezeigten entstanden sind. Jeder dieser Testabläufe wird händisch erstellt: für jede Baureihe, für jede Domäne6 und natürlich für jeden Diagnosetester. Es ist verständlich, dass bei diesem Ansatz immer wieder Diskrepanzen zwischen dem Soll- und dem Istzustand entstehen können. Weiterhin sind, wie beschrieben, viele Fachabteilungen involviert und der interne Kommunikationsbedarf ist hoch. Ein Beispiel aus der Praxis des Diagnosetestsystemverantwortlichen in der Entwicklung eines OEM: Er und sein Team sind z. B. für die Domäne Powertrain zuständig. Ein häufig in der Entwicklung eingesetzter Testablauf ist der Kurztest, dabei kann es vorkommen, dass pro Steuergerät einzelne Messwerte gewünscht werden, zusätzlich 5Winter-

oder Sommervariante mit den entsprechenden Winter- oder Sommererprobungsfahrten Body, Headunit, . . .

6 Powertrain,

3.1 Manuelle Erstellung

39

ODX

ARXML

OTX Kurztest Kurztest Baureihe ...

Kurztest Powertrain

FCT Last Kollective

Wake Up Dauerlauf ... Dauerlauf Diesel

Busruhe Steuergerätetausch

Katalysator Regeneration Applikationsspezifische Skripte

Dauerlauf Otto

A2L

Katalysator Entschwefelung XCP

Abbildung 3.3: Übersicht über unterschiedliche Datenbasen und die jeweils zugehörigen Testabläufe in gruppierter Darstellung zu der Steuergeräte- und Fehlerspeicherabfrage, wie beispielsweise die Schwefelbelastung des Katalysators oder die aktuelle Position der Drosselklappe und viele weitere. Wenn ein Diagnoseexperte den Arbeitsauftrag erhält einen neuen Messwert in den Kurztest aufzunehmen, muss dieser ebenfalls an das Dauerlaufskript und das Steuergerätetauschskript denken, da er alle relevanten Testabläufe eigenverantwortlich pflegen muss. Zudem muss der Diagnoseexperte entscheiden wie wichtig diese Änderung ist und dementsprechend einen Veröffentlichungstermin planen und kommunizieren. Wie umfangreich ein Testablauf ist, hängt von der Domäne ab, in der das Skript durchgeführt wird und welche maximale Durchlaufzeit von den jeweiligen Anwendern toleriert wird. Ebenfalls ist es wichtig, was der Anwender des Testablaufes während der Durchführung parallel machen kann, beispielsweise wenn ein Testablauf (Dauerlauf) speziell die Dichtheit des Abgastraktes überprüft und dafür ein Verweilen des Entwicklungsfahrzeuges im Leerlauf für mehrere Minuten notwendig ist. Dann wird ein Testingenieur in der Domäne Powertrain dafür Verständnis haben und diese blockierende Aufgabe so in seine Tests einplanen, dass er die Laufzeit des Skriptes anderweitig nutzt. Wenn dieses Skript mit einem schnellen Testablauf aus einer anderen Domäne, beispielsweise der Domäne Body, kombiniert wird, kann an dieser Stelle die Häufigkeit der Durchführungen unter Umständen leiden. Es ist also

40

3 Testablauferstellung in der Fahrzeugentwicklung

entscheidend, dass es individuelle und globale Testabläufe gibt. Globale Testabläufe sind aktuell nicht vollumfänglich global, sondern meist limitiert auf eine Domäne oder eine Baureihe. Wenn sich ein globales Testskript über eine Baureihe erstreckt, ist es aus zeitlichen Gründen oft nicht wirtschaftlich, hier Messwerte der einzelnen Steuergeräte abzufragen, aufgrund der Tatsache, dass die Steuergeräteidentifikation bereits viel Zeit in Anspruch nehmen kann. Als ein Beispiel wird eine fiktive statistische Abschätzung der Skriptdurchlaufzeit eines Baureihenkurztestes berechnet. Vereinfacht (Annahme) kann eine Baureihe aus maximal 200 unterschiedlichen ECUs bestehen, die ihrerseits wiederum wahrscheinlich in max. 80 Gruppen unterteilt werden können. Sollte eine ECU-Gruppe nicht antworten, muss ein Timeout7 𝑡 𝑜𝑢𝑡 = 3 s den Skriptablauf weiterschalten. Angenommen, es liegt eine Gaußsche Normalverteilung der Steuergerätegruppen vor, mit einem Minimum von 20 ECUs und einem Maximum von 80 ECUs, ergibt sich der Erwartungswert berechnet mit Formel Gl. 3.1 zu etwa 𝜇 = 50. Die Standardabweichung ergibt sich nach Formel Gl. 3.3 zu 𝜎 = 8. Durch die Wahrscheinlichkeits-Dichtefunktion (Formel Gl. 3.4) werden statistisch im Bereich von ±2𝜎 etwa 95,45 % aller Entwicklungsfahrzeuge abgedeckt. Durch die Verteilungsfunktion (Formel Gl. 3.5) wird dies noch mal verdeutlicht.

𝐸 (𝑥) = 𝜇 = 𝑉 𝑎𝑟 (𝑥) = 𝜎 2 =  𝜎 = 𝑉 𝑎𝑟 (𝑥) =

 

𝑛 1  · 𝑥𝑖 𝑛 𝑖=1

Gl. 3.1

𝑛  1 (𝑥𝑖 − 𝜇) 2 · 𝑛 − 1 𝑖=1

Gl. 3.2

𝑛  1 (𝑥𝑖 − 𝜇) 2 · 𝑛 − 1 𝑖=1

Gl. 3.3

𝑥− 𝜇 2 1 1 · 𝑒− 2 ·( 𝜎 ) 𝑁 (𝜇, 𝜎 2 ) = 𝑓 (𝑥) = √ 2𝜋 · 𝜎 ∫ 𝑥 𝑥− 𝜇 2 1 1 𝑒 − 2 · ( 𝜎 ) · 𝑑𝑡 𝐹 (𝑥) = √ · 2𝜋 · 𝜎 −∞

Gl. 3.4 Gl. 3.5

mit Kommunikations-Timeout-Konstante 𝑃2𝑚𝑎𝑥 war bei den untersuchten Gateway-Steuergeräten bei 2100 ms eingestellt. Im folgenden wird der Extremfall mit 3000 ms durchgerechnet.

7 Die

3.1 Manuelle Erstellung 𝐸 (𝑥) 𝜇 𝑉 𝑎𝑟 (𝑥) 𝜎 𝑁 (𝜇, 𝜎 2 ) 𝑓 (𝑥) 𝐹 (𝑥) 𝑛

41

Erwartungswert Arithmetischer Mittelwert Varianz Standardabweichung Gaußsche Normalverteilung Wahrscheinlichkeits-Dichtefunktion Wahrscheinlichkeits-Verteilungsfunktion Anzahl der Stichprobengröße

In Abbildung 3.4 ist die Normalverteilung8 , die aus den getroffenen Annahmen resultiert, dargestellt.

Abbildung 3.4: Es ist die Gaußsche Normalverteilung f(x) zusammen mit der kumulierten Wahrscheinlichkeit F(x) für die Wahrscheinlichkeit der Steuergeräteanzahl eines Entwicklungsfahrzeuges abgeschätzt. 8 Zum

Nachvollziehen dieser Normalverteilung ist im Anhang der Python-Quellcode im Listing B.1 hinterlegt.

42

3 Testablauferstellung in der Fahrzeugentwicklung

In der oberen Kurve ist die Dichtefunktion und in der unteren Kurve die kumulierte Wahrscheinlichkeitsfunktion dargestellt. Zusätzlich ist in jedem Diagramm noch je eine vertikale Linie für den Erwartungswert (50) sowie die beiden Grenzwerte (34 und 66) ±2𝜎 eingezeichnet. Basierend auf der unteren Kurve ist zu erwarten, dass 50 % aller Entwicklungsfahrzeuge etwa 20 bis 50 ECUs besitzen und bei 66 ECUs erreicht die kumulierte Wahrscheinlichkeit 95,45 %. Aufgrund dieser Zusammenhänge werden drei untersuchte Fälle definiert. Ein mittleres Fahrzeug besitzt 50 verbaute ECU-Gruppen, ein minimales 34 ECU-Gruppen und ein maximales 66 ECU-Gruppen. Basierend auf dieser Festlegung kann die minimale, mittlere und maximale Wartezeit des Steuergeräteidentifikationsprozesses über Formel Gl. 3.6 abgeschätzt werden. 𝑡 𝑡𝑜𝑡 = 𝑥 · 𝑡 𝑜𝑢𝑡

Gl. 3.6

mit 𝑡 𝑡𝑜𝑡 𝑡 𝑜𝑢𝑡 𝑥

Skriptdurchlauf-Totzeit Timeout-Zeit Anzahl fehlender Steuergerätegruppen

Eingesetzt ergibt sich die Totzeit der drei Fälle zu:

𝑡 𝑡𝑜𝑡_𝑚𝑖𝑛 = 𝑥 𝑚𝑖𝑛 · 𝑡 𝑜𝑢𝑡 = 46 · 3 s = 138 s 𝑡 𝑡𝑜𝑡_𝜇 = 𝑥 𝜇 · 𝑡 𝑜𝑢𝑡 = 30 · 3 s = 90 s 𝑡 𝑡𝑜𝑡_𝑚𝑎𝑥 = 𝑥 𝑚𝑎𝑥 · 𝑡 𝑜𝑢𝑡 = 14 · 3 s = 42 s Somit ist ersichtlich, dass der Testingenieur bei der Durchführung eines Kurztestes an einer Baureihe im Mittel 𝑡 𝑡𝑜𝑡_𝜇 = 1,5 min auf die reine Identifizierung der nicht vorhandenen Steuergeräte warten muss, die bereits auf die Baureihe gefiltert sind. Das Auslesen der Fehlerspeicher und der Softwarestände wird mit etwa zwei DTC und zehn Identifikationsnachrichten pro ECU abgeschätzt. Ein DTC besitzt in aller Regel Umgebungsdaten, die zum Zeitpunkt des Fehlers abgespeichert werden. Diese Umgebungsdaten werden bei jedem Auftreten des Fehlers beim Schreiben in den Fehlerspeicher übertragen, ein Fehler kann oft mehr als zehn der letzten Vorkommnisse speichern. Angenommen, dass 20 Nachrichten einem

3.1 Manuelle Erstellung

43

Umgebungsdatensatz entsprechen, ergeben sich 202 Nachrichten für die DTCs. Das bedeutet, die gesamte Nachrichtenanzahl beträgt 212 CAN-Nachrichten, die pro erkanntes bzw. vorhandenes ECU übertragen werden. Bei einer Busgeschwindigkeit von angenommen 𝑓𝑐𝑎𝑛 = 500 kbit/s und bei idealen CAN-Frames9 mit einer Framelänge von 𝑙 = 119 bit (davon 64 bit Payload) ergibt sich die Identifikationszeit nach Gleichung Gl. 3.7.

𝑡 𝑖𝑑𝑒𝑛𝑡

𝑛  𝑥𝑖 · 𝑙 = 𝑓𝑐𝑎𝑛 𝑖=1

Gl. 3.7

mit 𝑡 𝑖𝑑𝑒𝑛𝑡 𝑓𝑐𝑎𝑛 𝑥𝑖 𝑙 𝑛

Zeit zum Identifizieren und DTC-Lesen Busgeschwindigkeit Anzahl Messwerte je ECU Framelänge Steuergeräteanzahl

Eingesetzt ergibt sich:

𝑡𝑖𝑑𝑒𝑛𝑡_𝑚𝑖𝑛 =

34  212 · 119 bit 𝑖=1

𝑡𝑖𝑑𝑒𝑛𝑡_𝜇 =

50  212 · 119 bit 𝑖=1

𝑡𝑖𝑑𝑒𝑛𝑡_𝑚𝑎𝑥 =

500 kbit/s

500 kbit/s

66  212 · 119 bit 𝑖=1

500 kbit/s

= 1,72 s = 2,52 s = 3,33 s

Damit ist gezeigt, dass die Kommunikation mit den Steuergeräten nur einen Bruchteil der Zeit ausmacht, die im Vergleich auf die Timeouts der nicht vorhandenen Steuergeräte gewartet werden muss. Abschließend soll der zeitliche Rahmen der Messwerte abgeschätzt werden. Angenommen, dass jedes ECU 50 Messwerte übertragen soll und zehn dieser Messwerte 9 Ohne

Stuffbits und ohne CAN-ext-IDs

44

3 Testablauferstellung in der Fahrzeugentwicklung

funktionieren aufgrund unterschiedlicher Softwarestände nicht. Für einen Messwert, der keine Antwort liefert, muss eine Wartezeit von in der Regel 𝑡 𝑚𝑒𝑠𝑠_𝑜𝑢𝑡 = 0,1 s ablaufen. Damit kann die Formel Gl. 3.8 aufgestellt werden, um die Laufzeit der Messung abzuschätzen.

𝑡 𝑚𝑒𝑠𝑠 =

𝑛  𝑥𝑖 𝑝 · 𝑙 𝑖=1

𝑓𝑐𝑎𝑛

+ 𝑥 𝑖𝑛 · 𝑡 𝑚𝑒𝑠𝑠_𝑜𝑢𝑡

Gl. 3.8

mit 𝑡 𝑚𝑒𝑠𝑠 𝑡 𝑚𝑒𝑠𝑠_𝑜𝑢𝑡 𝑓𝑐𝑎𝑛 𝑥𝑖 𝑝 𝑥 𝑖𝑛 𝑙 𝑛

Zeit der Messwerte Timeout Busgeschwindigkeit Anzahl positiver Messwerte je ECU Anzahl negativer Messwerte je ECU Framelänge Steuergeräteanzahl

Eingesetzt ergibt sich:

𝑡 𝑚𝑒𝑠𝑠_𝑚𝑖𝑛 =

34  40 · 119 bit 𝑖=1

𝑡 𝑚𝑒𝑠𝑠_𝜇 𝑡 𝑚𝑒𝑠𝑠_𝑚𝑎𝑥

500 kbit/s

+ 10 · 0,1 s = 34,32 s

50 

40 · 119 bit + 10 · 0,1 s = 50,48 s = 500 kbit/s 𝑖=1

66  40 · 119 bit + 10 · 0,1 s = 66,63 s = 500 kbit/s 𝑖=1

Bei der Bestimmung der gesamten Skriptdurchlaufzeit (Gleichung Gl. 3.9) fällt auf, dass ein typisches Skript ca. zwei bis drei Minuten Durchlaufzeit benötigt. 𝑡 = 𝑡 𝑡𝑜𝑡 + 𝑡 𝑖𝑑𝑒𝑛𝑡 + 𝑡 𝑚𝑒𝑠𝑠 mit

Gl. 3.9

3.1 Manuelle Erstellung 𝑡 𝑡 𝑡𝑜𝑡 𝑡 𝑖𝑑𝑒𝑛𝑡 𝑡 𝑚𝑒𝑠𝑠

45

Skriptdurchlaufzeit Skriptdurchlauf-Totzeit Zeit zum Identifizieren und DTC-Lesen Zeit der Messwerte

Eingesetzt ergibt sich:

𝑡 𝑒𝑐𝑢_𝑐𝑜𝑢𝑛𝑡_𝑚𝑖𝑛 = 138 s + 1,72 s + 34,32 s = 174,04 s 𝑡 𝑒𝑐𝑢_𝑐𝑜𝑢𝑛𝑡_𝜇 = 90 s + 2,52 s + 50,48 s = 143 s 𝑡 𝑒𝑐𝑢_𝑐𝑜𝑢𝑛𝑡_𝑚𝑎𝑥 = 42 s + 3,33 s + 66,63 s = 111,96 s Der zeitliche Anteil, in dem der Diagnosetester wartet, ist verhältnismäßig hoch: Im Erwartungswert-Fall beträgt dieser 𝑡 𝑤𝑎𝑖𝑡 = 90 s + 50 s = 140 s. Dahingegen ist die Zeit, in der tatsächlich Diagnosenachrichten ausgetauscht werden, im Verhältnis relativ klein. Im Erwartungswert-Fall beträgt diese 𝑡 𝑤𝑜𝑟 𝑘 = 2,52 s+0,48 s = 3 s. Aufgrund der Tatsache, dass diese Wartezeiten bei jeder Skriptdurchführung auftreten, kann der Entwickler durch die Optimierung der Fahrzeugidentifikation maßgeblich entlastet und die Fahrzeugdiagnose beschleunigt werden. Durch so einen optimierten Prozess würde die Skriptdurchlaufzeit in etwa um den Faktor 47 beschleunigt werden. In Zahlen bedeutet das, dass ≈ 99 % der aktuellen Skriptdurchlaufzeit für Wartezeiten aufgrund der global erstellten Testabläufe anfallen. Diese manuelle Prozesse sind sinnvoll und zweckmäßig für lokale bzw. private Testabläufe, die nur eine geringe Anzahl an Entwicklern betreffen. Aber bei globalen Testabläufen wie beispielsweise dem Kurztest (domain- oder baureihenspezifisch) wäre ein Automatismus lohnenswerter. Im vorangegangenen Kapitel wurde hergeleitet, aus welchen Aspekten eine VNA-Bestimmung notwendig ist. In diesem Kapitel wurde der theoretische Zeitbedarf der VNA-Bestimmung hergeleitet, der zum Stand der Technik je Messung auftritt. Davon ausgehend kann der Kostenvorteil abgeschätzt werden, der durch die Optimierung dieser Prozesse erzielbar ist. Im kommenden Kapitel wird beschrieben, wie Testabläufe automatisch erstellt werden können und diese dabei stets aktuell sind. Es handelt sich hierbei um die Digitalisierung der Diagnose, genauer gesagt um eine Verbesserung der Testablauferstellung zum Stand der Technik der Softwareentwicklung, oder ganz allgemein formuliert die Aufrüstung der IT-Infrastruktur zu einer Diagnose-Plattform.

46

3 Testablauferstellung in der Fahrzeugentwicklung

3.2 Stand der Entwicklung und Gründe für eine automatische Erstellung Eine automatische Testablauferstellung kann in der Fahrzeugentwicklung einen Beitrag leisten, um die Entwicklung zu beschleunigen und die Nachprüfung der Funktionen sicherzustellen. Aber wenn es solchermaßen vorteilhaft wäre, ein derartiges System zu nutzen, welche Gründe sprechen für den derzeitigen Stand der Technik und warum kommt eine so praxisnahe Antwort aus der Forschung? Es begründet sich anhand der „Digitalisierung“ der Fahrzeugdiagnose, anders formuliert aufgrund des Paradigmenwandels, der Einzug erhalten muss. Obwohl alle Daten digital vorliegen, ist es entscheidend, diese intelligent zu vernetzen und die Komplexität für den Anwender zu reduzieren. Aktuell werden einzelne Softwareprodukte eingesetzt, die sowohl Anwender als auch Ersteller installieren, updaten, lizenzieren und pflegen müssen. Zusätzlich werden in diesen Softwareprodukten, wie bereits dargestellt, unterschiedliche Projekte erstellt und gepflegt, so zum Beispiel das Powertrain-Projekt, für welches ein eigenes Team bestellt ist, um die Testabläufe weiterzuentwickeln. Diese Teams veröffentlichen in unregelmäßigen Abständen neue Versionen des Projektstandes, welche wiederum von den Anwender heruntergeladen und in ihre lokal installierte Diagnosesoftware eingespielt wird. Damit wird festgehalten, dass die Qualität der Messungen an jedem einzelnen Anwender hängt, dass dieser immer auf dem neusten Stand ist und den Überblick über die SW-Versionen eigenverantwortlich hat und behält. Zudem benötigt der Anwender zusätzlich zu den Projekt-Dateien ebenfalls die ODX- und ARXML-Dateien. Hierbei ist zu erwarten, dass sich bei etwa 1000 ECUs jeden Tag mindestens eine Datei aktualisieren wird. Wichtig zu erwähnen ist, dass diese Bedatungsdateien als „vertraulich“ eingestuft sind. Folglich ist ersichtlich, dass der Anwender ein hohes Maß an Verantwortung trägt, da dieser jeden Tag alle Daten aktualisieren und vor unbefugtem Zugriff schützen muss. Eine Vergabe einer Fahrzeugerprobung an eine externe Firma ist damit immer verbunden mit dem Herausgeben von vertraulichen Dateien. Somit ist festzuhalten, dass eine lokal installierte Diagnosesoftware die automatische Erstellung von Testabläufen oder anderen nützlichen Funktionen, wie das automatische Erzeugen von grafischen Diagnose-Oberflächen, nicht begünstigt. Die soeben beschriebenen Herausforderungen können gelöst werden, indem eine Trennung von Hardware und Software vollzogen wird. Es muss entkoppelt werden, mit welcher Hardware der Anwender in einem Fahrzeug messen, genauer gesagt, welchen Daten-Logger er in ein Entwicklungsfahrzeug verbauen möchte.

3.2 Stand der Entwicklung und Gründe für eine automatische Erstellung

47

Das Messsystem muss möglichst simpel sein und die Komplexität in die Software verlagert werden. Das hat den Hintergrund, dass die Software zentral gepflegt und aktualisiert werden kann (Standardprozesse der DevOps-IT, dazu später mehr zur Abbildung 3.5). Dahingegen kann die embedded Software einer Hardware nur unter erhöhtem Aufwand aktuell und synchron gehalten werden. Bei der Software bietet sich daher eine Cloud-Anwendung10 an. Was hier auf den ersten Blick die Komplexität zwar erhöht, wirkt sich auf den zweiten aber vorteilhaft auf den Prozess aus und bietet für alle identifizierten Herausforderungen eine Lösung. Da beliebig viele unabhängige Applikationen (Mikroservices) entwickelt und kombiniert werden können, die alle über ein und dasselbe Webinterface abgerufen werden, entsteht eine zentrale Plattform für den Anwender und Ersteller. Daraus resultiert der Vorteil, dass der Anwender keine täglichen Updates mehr durchführen muss, weil die Diagnose-Plattform dies für alle Anwender automatisch übernimmt. Zudem werden die Datenbank- oder Blockchain-Systeme der Cloud-Plattform die vertraulichen ODX- und ARXML-Dateien schützen und somit den Anwender entlasten, da dieser die sensiblen Dateien nicht mehr vorhalten muss. Abschließend bleibt noch festzuhalten, dass diese Applikation immer synchron ist und Updates nicht ein bis zwei Monate benötigen, sondern unmittelbar zur Verfügung stehen. Duplizierungs- oder Übertragungsfehler können vermieden und viele Prozesse der modernen Softwareentwicklung können integriert werden, um Zeit einzusparen, was sich bei einem großen OEM mit ein paar tausend Entwicklungsfahrzeugen und ein paar hundert Entwicklungsingenieuren täglich in Arbeitszeit aufsummiert. Ein weiterer Vorteil ist, dass der Anwender eines solchen Systems weniger Fehler machen kann und somit die Einstiegshürde vergleichsweise gering ist. Hierfür wird eine Diagnose-Cloud benötigt, die verstärkt auf KI-Ansätze aufbaut und mit dem Data Lake der entstehenden Big-Data-Anwendung umgehen kann. Im Prinzip ergibt sich ein Bedatungskreislauf, der wiederholt durchlaufen wird. Am Anfang steht der Steuergeräte-Zulieferer, welcher einen neuen Softwarestand seines ECU bereitstellt, einerseits als flashbare Datei auf dem Steuergerät und anderseits als ODX-Datei für die Testskripterstellung. Der OEM hat dafür in der Regel interne Prozessketten aufgestellt, wie die Steuergeräte schnell und effizient auf den neuen Softwarestand hochzurüsten sind, um die neuen Funktionen des Zulieferers zu nutzen, jedoch ist dies auf der Seite der ODX-Datei nicht so weit ausgebaut. Es gibt keine Funktion, die die alte ODX-Datei mit der neuen vergleicht und auf etwaige Fehler plausibilisiert. Daraus folgt, dass für jedes Steuergerät die ODX-Datei 10 mehrere

API-, Web-, Netzwerk-, Datenbank- sowie Dateiserver

48

3 Testablauferstellung in der Fahrzeugentwicklung

gelesen und die funktionsrelevanten Bereiche in eine Datenbank übertragen werden müssen, um einerseits eine Versionierung und anderseits eine Plausibilisierung durchführen zu können. Durch diesen ersten Schritt hat die Diagnose-Cloud Zugriff auf alle Steuergeräte und alle Messwerte, egal in welchem Softwarestand diese vorkommen. In einem weiteren Schritt müssen die globalen Skripte übertragen und über die Diagnose-Cloud verwaltet werden. Nach diesen beiden essenziellen Schritten kann die Diagnose-Cloud Testabläufe nach dem bisherigen Schema erstellen. Bei einem zentralen System ist es prinzipiell vorstellbar, dass der SteuergeräteEntwickler die Messwerte, die in globalen Testabläufen gesammelt werden sollen, selbstständig an einer zentralen Stelle konfiguriert. Hierfür muss nicht der Diagnosesystemverantwortliche auf die Nachricht des Steuergeräteverantwortlichen reagieren und unter Umständen 10-20 Testabläufe händisch erweitern. Weiterhin ist die Ausrollgeschwindigkeit ein weiteres Unterscheidungskriterium, da es bei dem hier vorgestellten System unmittelbar online ist. Essenziell ist also die Datenvorhaltung der ODX-Daten und die Verlinkung der Testabläufe, dann wird es möglich, die Testskript-Erstellung zu automatisieren11 . Abschließend folgt noch eine kurze Übersicht, wie aktuell die Software eines Fahrzeuges getestet wird und wohin der Prozess sich entwickeln sollte, um Fahrzeuge in schnelleren Zyklen sowie mit steigender Softwarequalität auf den Markt zu bekommen. In Abbildung 3.5 ist auf der rechten Seite der gelebte Prozess eines Softwaretests in der Softwareentwicklung zu erkennen, nach den modernen Methoden der DevOps-Entwicklung12 . Wenn beispielsweise ein Softwareentwickler seine neue Version einer Software an das dezentrale Versionsverwaltungstool (z. B. Git) sendet, kann dieses wiederum die Software automatisch überprüfen und so eine gleichbleibende Mindestqualität gewährleisten. Dabei wird eine Pipeline vollautomatisch (Kontinuierliche Integration (engl. Continuous Integration) (CI)) durchlaufen: Unit-Test: Berechnet für alle Funktionen (kleinste testbare abgeschlossene Einheiten), ob die erwarteten Ergebnisse (oder provozierten Abstürze) nach der Anpassung des Entwicklers weiterhin funktionieren. Diese Art der Tests überprüft auf logische Fehler, die anderweitig nur unter hohen Aufwand gefunden werden 11 Auf

die Generalisierung der Datengrundlage für Testabläufe in einer Datenbank wird in dieser Arbeit nicht weiter eingegangen (Grundlegende Informationen in der Masterarbeit [44], die Ergebnisse wurden für die vorliegende Forschungsarbeit gemeinsam erarbeitet und in der studentischen Ausfertigung schriftlich niedergeschrieben.). 12 Damit häufig verbunden mit der agilen Softwareentwicklung

3.2 Stand der Entwicklung und Gründe für eine automatische Erstellung

Händische Tests

49

Händische Tests

Gesamtfahrzeug-Erprobungs-Tests GUI-Tests Netzwerk-Tests API-Tests SteuergeräteFunktions-Tests

Integrations-Tests statische Codeanalyse & Komponenten-Tests Linting-Style-Tests & Unit-Tests

Testing-Pyramide [V-Modell] am Beispiel eines Produktentwicklungsprozesses

Ideale Testing-Pyramide am Beispiel der Softwareentwicklung

Abbildung 3.5: Ideale und nicht ideale Testpyramide - Herausforderungen, die beim Automobilhersteller noch gelöst werden müssen (Abbildung abgeleitet aus [57] Kapitel 8.1, Abbildung 8.4). können. Einfachstes Beispiel ist eine Bargeld-Auszahlfunktion eines Bankautomaten. Diese übernimmt zwei Eingangswerte, einerseits den Kontostand der durch die Bankkarte identifizierten Person und anderseits den gewünschten Betrag und schreibt das Ergebnis der Subtraktion zurück auf den Kontostand. Bei dieser einfachen Funktion darf nie ein Fehler auftreten, daher wird ein Test integriert, der automatisch durchlaufen wird und immer zu folgendem Ergebnis kommen muss: → 100 − 300 = −200. Liniting: Hält der Programmierer sich an den Unternehmens-Style-Guide und ermöglicht es somit seinen Kollegen, sich schnell und einfach einzuarbeiten? Zusätzlich werden so die „Best Practices“ der jeweils eingesetzten Programmiersprachen automatisch vorgeschrieben und eingehalten. Statische Codeanalyse: Wie komplex sind die einzelnen Funktionen der Software? Hält sich der Entwickler an die Regeln, möglichst kompakte und leicht verständliche Software zu schreiben? Komponententests: Liefern alle Subsysteme der Software die erwarteten Ergebnisse, auch nach der Anpassung des Entwicklers? Hier werden häufig die

50

3 Testablauferstellung in der Fahrzeugentwicklung

öffentlichen Methoden gegen alle vom User möglichen Eingabewerte hin getestet, um sicherzustellen, dass die Verwendung als „Black-Box“ gewährleistet ist. Integrationstest: Testet die gesamte Applikation mit virtuellen Komponenten [Mock13 ] (Datenbanken, Dateien, etc.) auf korrekte Funktionalität. API-Test: Testet die gesamte Applikation mit realen Komponenten (Datenbanken, Dateien, etc.) auf korrekte Funktionalität. GUI-test: Testet das grafische Benutzerinterface auf korrekte Funktionalität. An jedem einzelnen Punkt kann die Pipeline aufgrund eines Fehlers abbrechen und der Entwickler muss die Fehler beheben und erneut starten. Sollte die CI-Pipeline durchlaufen, kann der Roll-out-Prozess (Fortlaufende Auslieferung (engl. Continuous Delivery) (CD)) gestartet werden. Das Ziel einer so aufgesetzten Software ist, dass eine Anwendung vollautomatisch geprüft und veröffentlicht wird. Der Softwareentwickler kann, nachdem die Applikation ausgerollt ist, diese noch händisch testen, um Weiterentwicklungspotenziale zu entdecken, um seinen Anwendern in Zukunft einen größeren Mehrwert zu bieten. Dagegen steht die linke Seite der Abbildung 3.5, bei der der Stand der Technik der Fahrzeug-Testskript-Entwicklung dargestellt ist. Hier wird ein Entwicklungszyklus anhand des V-Modells durchlaufen. Wie zu erkennen ist, steigt damit der Bedarf und das Volumen an händischen durchgeführten Tests. Dabei muss der Steuergeräteverantwortliche die neue Software des Zulieferers14 entgegennehmen und auf einen Demonstrator im Labor flashen und damit die Funktionstests händisch durchführen. Sollten diese Tests positiv verlaufen, wird der Steuergeräteverantwortliche die neue Software freigeben und infolgedessen diese in einem Entwicklungsfahrzeug auf das betreffende Steuergerät übertragen. Daraufhin wird die Netzwerkkommunikation überwacht, ob die neue Software das Bussystem nicht überlastet. Sollte auch hier alles in Ordnung sein, wird die Software für Erprobungsfahrten freigegeben. Es ist zu erkennen, dass an dieser Stelle eine Angleichung an den Stand der Technik der Softwareentwicklung sinnvoll ist, wodurch mit der in dieser Arbeit diskutierten Diagnose-Plattform basierend auf der Methode der Identifizierung, welche in Kapitel 4 hergeleitet wird, begonnen werden kann. 13 Ein

Mock ist eine simulierte Schnittstelle in der SW-Entwicklung, bei der die Antwort einer Funktion/Methode nicht von einer realen Ressource z. B. Datenbank angefragt wird, sondern immer die gleiche Antwort auf die gleiche Anfrage (idempotent) von einer lokalen Instanz generiert wird. Das vereinfacht das Testen bei gleichzeitig hoher Testabdeckung. 14 Diese embedded Software kann unter Verwendung der Testing-Pyramide der Softwareentwicklung gepflegt sein.

3.3 Einfluss der Fahrzeug-Netzwerk-Architektur auf die Testablaufgenerierung51

3.3 Einfluss der Fahrzeug-Netzwerk-Architektur auf die Testablaufgenerierung Ein globaler Testablauf beinhaltet mehrere Steuergeräte, die bei der Durchführung kontaktiert werden sollen dabei müssen diese im Entwicklungsfahrzeug zuverlässig identifiziert werden. Hierfür gibt es zwei mögliche Szenarien, einerseits wie es in der Fahrzeugentwicklung Stand 2022 üblich ist, und andererseits die Methode, die in dieser Arbeit hergeleitet wird. Aktueller Stand ist, dass bei jeder SkriptDurchführung versucht wird, alle Steuergeräte zu kontaktieren und zu identifizieren. Dieses Verfahren stellt sich als zeitintensiv heraus, da pro nicht verbautem Steuergerät meist drei Sekunden vergehen, bevor das Timeout eine negative Antwort generiert. Zusätzlich können Messwerte nur in bestimmten Softwarevarianten eines Steuergerätes vorkommen, somit resultieren für alle übrigen Varianten Wartezeiten auf die negative Antwort des Messwertes von meist 0,1 s. Wie in Kapitel 3.1 bereits berechnet, liegt der größte Teil des Optimierungspotenzials darin, diese Wartezeiten auszuschließen. In der ersten Stufe, die der reinen Steuergeräte-Bestimmung und in der zweiten darauf aufbauend, dass die Messwerte zukünftig variantenspezifisch in die Testabläufe integriert werden. Der in dieser Arbeit vorgestellte neue Ansatz beinhaltet, dass beim Start des Messsystems einmalig versucht wird, alle15 Steuergeräte zu kontaktieren und den aktuellen Zustand des Fahrzeuges in der Cloud zu speichern16 . Damit wäre das Fahrzeug für bspw. diesen Kalendertag identifiziert. Unabhängig davon, mit welchem Messsystem welcher Entwickler Messungen in dem Fahrzeug durchführen möchte, ist dieses für diesen Kalendertag ausgelesen und das Messsystem wird von der Cloud mit den individuellen und idealen Messaufgaben versorgt. Das bedeutet im Umkehrschluss, dass die automatische Generierung von individuellen Testabläufen, damit die Digitalisierung der Diagnose von der Identifizierung der Fahrzeug-Netzwerk-Architektur (engl. Vehicle Network Architecture) abhängt. Beide Ansätze haben Vor- und Nachteile, zudem verschiebt sich die Komplexität. Bei dem aktuellen Ansatz entstehen große Dateien für einen Testablauf und der Diagnosetester muss damit umgehen können. Zudem kann der Ingenieur die Datei nur mit Aufwand auf Gültigkeit überprüfen. Dadurch entsteht eine konfliktreiche Situation für den durchführenden Ingenieur. Dieser kennt die Steuergeräte nicht, 15 Über

alle Baureihen und alle Domain hinweg, sodass wirklich alles über das Fahrzeug bekannt ist. eine Information über die Fahrzeugvergangenheit nach jedem ECU-Umbau, sodass vergangene Messungen mit kompatiblen (gleich alten) Softwareständen verrechnet werden können.

16 Ermöglicht

52

3 Testablauferstellung in der Fahrzeugentwicklung

die im Erprobungsfahrzeug eingesetzt werden, in welchem er gerade Messungen aufnehmen möchte, und die Skriptdatei, welche er ausführen soll, hilft ihm ebenfalls nicht. Sollte er eine falsche Skriptdatei verwenden, bekommt er keinen Anhaltswert, was er benötigt, um mit dem vorliegenden Fahrzeuge seine Messung abschließen zu können, zudem kann das Fahrzeug in Einzelfällen einen Schaden davontragen. Des Weiteren muss jedes Skript immer die Steuergeräte identifizieren, wodurch häufig Wartezeiten entstehen. Für den neuen Ansatz muss die VNA im Boot-Prozess des Diagnosetesters ermittelt und an die Cloud übertragen werden. Dort werden dann die Steuergeräte und die Netzwerke bestimmt, um in einem weiteren Schritt individuelle Testabläufe erstellen und verteilen zu können. Dies sorgt zwar für kurze Durchlaufzeiten, aber ebenfalls dafür, dass der erste Start eines Diagnosetesters am Tag in einem Fahrzeug länger dauert, sogar deutlich, etwa in der Größenordnung von 2-3 aktuellen Skriptdurchläufen und es entsteht ein gewisser Online-Zwang (zumindest beim Starten des Messsystems). Die Komplexität verlagert sich in die Cloud. Mit mehreren KI-Ansätzen lässt sich hier viel bisher nicht wirtschaftlich Mögliches realisieren: Der Ingenieur wird entlastet, da er immer verfolgen kann, welche Steuergeräte in diesem Fahrzeug bereits identifiziert wurden, und wenn er den individualisierten Testablauf öffnet, ist die Überprüfung auf Gültigkeit vergleichsweise einfach, aufgrund der Tatsache, dass die Datei zu 100 % auf das Fahrzeug individualisiert ist.

3.4 Zusammenfassung und Chancen der automatischen Erstellung In diesem Kapitel wurden die Prozesse, die in der Fahrzeugentwicklung bei der Testablauferstellung und Testdurchführung durchgeführt werden, beschrieben. Exemplarische typische Messverfahren wurden eingeführt und deren Verwendung erklärt. Es wurde aufgezeigt, dass der Testingenieur ein vergleichsweise hohes Maß an Verantwortung trägt, um Messungen durchführen zu können. Die Softwarevarianz der Steuergeräte ist bei der Auswahl der passenden Messwerte ein Faktor, der die Messung verlängern kann. Ebenso ist das Überprüfen eines Steuergerätes ein Faktor, welcher das Potenzial hat, die Messung zu verlängern. Diese beiden Faktoren können aber, wie gezeigt, durch einen Prozess der Identifizierung beseitigt werden. Durch ein im Vorfeld identifiziertes Fahrzeug und der damit verbundenen Bestimmung der VNA können Testabläufe vollautomatisch erzeugt und auf das

3.4 Zusammenfassung und Chancen der automatischen Erstellung

53

Entwicklungsfahrzeug individualisiert werden. Durch das Single-Source-Prinzip, welches in dem Konzept der beschriebenen Diagnose-Plattform besteht, werden die Testabläufe immer aktuell und vollständig sein. Die Cloud kann außerdem viele Prozesse der Fahrzeugdiagnose abnehmen und sinnvoll um KI-Algorithmen erweitern. Die Inhalte dieses Kapitels können ebenfalls auf die Forschungsfrage bezogen werden. In Abschnitt 3.1 wurde dargestellt, dass eine Fahrzeugidentifizierung (Genauigkeit) notwendig ist, um die Skriptdurchlaufgeschwindigkeit (Durchlaufzeit) deutlich zu erhöhen. Darauf aufbauend wird in Abschnitt 3.2 gezeigt, wie eine zentrale (Aktualität) Diagnose-Plattform die Entwicklung von Testskripten vereinfachen und somit Entwicklungszeit einsparen kann. Im vorherigen Abschnitt 3.3 wurde durch die Hinterlegung der VNA die Testablaufqualität (Vollständigkeit) gesteigert. Damit wurde gezeigt, dass die Methode, die in dieser Arbeit im anschließenden Kapitel vorgestellt wird, die neuesten Technologien kombiniert, um die Fahrzeugentwicklung zu beschleunigen. Die Digitalisierung der Fahrzeugdiagnose und deren Potenziale für die Fahrzeugentwicklung sind das Thema der vorliegenden Forschungsarbeit. Dahingehend ist der Vergleich der Untersuchungen und der damit erzielten Ergebnisse mit dem derzeitigen Stand der Entwicklung in der Tabelle 3.1 hinterlegt. Über diese Tabelle können die Unterschiede der beiden Systeme nachvollzogen werden.

54

3 Testablauferstellung in der Fahrzeugentwicklung

Tabelle 3.1: Gegenüberstellung: Derzeitiger Stand der Technik gegenüber den Chancen der Methode aus dieser Arbeit Kriterium

Stand der Entwicklung

Chance der Methode

Durchlaufzeit

mehrere Minuten Kollegen fragen, DiagnosetoolVerantwortlichen kontaktieren, dauert unter Umständen mehrere Wochen Groß, unter Umständen 1000 Steuergeräte und mehrere tausend Messwerte enthalten

wenige Sekunden

Time To Test

Dateigröße Online/Offline Sicherheit Nachvollziehbarkeit

Vollständigkeit

Aktualität Software im Umlauf

Offline Vertrauliche Dateien liegen auf jedem Entwicklerrechner Ingenieur kann die Messung nur unter erhöhtem Aufwand reflektieren Es können aufgrund des händischen Prozesses Fehler auftreten bzw. ganze ECUs aus Performance-Gründen entfallen max. 1-2 Monate Verzug

Identifikationsprozess der Cloud in der Regel 10 Minuten nach dem Start des Messsystems Klein, exakt auf das Fahrzeug zugeschnitten Online, beim ersten Start zum Beziehen der Skripte Vertrauliche Dateien liegen auf dem Server Ingenieur kann die Datei lesen und verstehen

immer vollständig

stets aktuell

mehrere Stände

ein Stand

Fehlererkennung

Keine, meist händisch durch Versuchsfahrten

Erster Check von KI, danach händisch durch Versuchsfahrten

Systemaufwand

• lokale Installation einer Diagnosesoftware • täglicher Update-Zwang für jeden Entwickler • Diagnose-Experten benötigt

• Diagnose-Plattform bzw. Cloud mit vielen Servern • Updates werden von Cloud erledigt • IT-Experten benötigt

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur In diesem Kapitel wird ein Prozess vorgestellt, mit welchem in einer Cloud die Fahrzeug-Netzwerk-Architektur (engl. Vehicle Network Architecture) (VNA) bestimmt und für darauf aufbauende Prozesse gespeichert werden kann. Wie im vorangegangenen Kapitel beschrieben kann ein initiales Ermitteln der Steuergeräte (engl. Electronic Control Units) (ECUs) und deren Softwarestände (SW-Variante) die Testabläufe optimieren und automatisieren. Um die Herausforderungen besser einordnen zu können, werden Anforderungen aufgestellt, mit denen die Modelle verglichen werden können. Darauf aufbauend wird der Prozess der VNAIdentifikation hergeleitet und die Datenerhebung sowie die Datentransformation des IoT-Diagnosetesters dargestellt. Ab dem Zeitpunkt, nachdem die Daten aufgezeichnet und übertragen sind und somit der Cloud vorliegen, kann die Methode basierend auf den Off-Board Diagnose-Beschreibungsdateien (ODX) aufgezeigt und bewertet werden. Außerdem ist es aufgrund der Datentransformation ebenfalls möglich, unterschiedliche KI-Modelle zu trainieren und hierdurch einen zweiten Pfad über die On-Board-Diagnose-Netzwerkbeschreibungsdateien (DBC- oder ARXML) zu beschreiten. Auf Grundlage der beiden divergenten Herangehensweisen können Fehler gleicher Herkunft (engl. Common Cause Errors) (CCE) reduziert und somit die Sicherheit dieser Methode verstärkt werden. Dies wird durch die Verifikation der Identifikation erreicht, hierbei werden die identifizierten Steuergeräte über den ODX-Ansatz mit den identifizierten Diagnosenachrichten im FCT ausgewertet und plausibilisiert. Abgeschlossen wird dieses Kapitel mit einer Ergebnisdarstellung, sowie einem Fazit, um Bezug auf die Forschungsfrage zu nehmen.

4.1 Definition der Anforderungen Es soll eine Methode gefunden werden, die es ermöglicht, den logischen Aufbau eines individuellen Entwicklungsfahrzeuges so detailliert wie möglich abzubilden. Hierzu sind drei Hauptaspekte von Relevanz und müssen erfüllt werden, diese sind in Abbildung 4.1 dargestellt. Es ist zu erkennen, dass der logische Fahrzeugauf© Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 R. T. Lutchen, Optimierung der Fahrzeugdiagnose durch eine cloudbasierte Methode zur Identifikation der Datennetze mit künstlicher Intelligenz, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-43113-6_4

56

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

bau und damit alle Funktionen, die das Fahrzeug unterstützt, abhängig von den verwendeten Netzwerken, den ECUs und den Datengrundlagen sind.

Abbildung 4.1: Die drei Hauptkategorien, um den Fahrzeugaufbau darzustellen Über Fahrzeugnetzwerke kommunizieren ECUs miteinander und tauschen Daten aus. Jedes ECU hat eine auf das Steuergerät geflashte Software, die „Variante“ genannt wird. Manche ECUs übernehmen noch eine Gatewayfunktion und verbinden gleichartige oder unterschiedliche Netzwerke, um die Daten der ECUs über die Bussystemgrenzen hinweg zu übertragen und eine Gesamtfahrzeug-Topologie abzubilden. Ein Netzwerk und die On-Board-Diagnose (ARXML / DBC) sind in anderen Dateien bedatet und gepflegt als die Steuergerät spezifische Off-BoardDiagnose (ODX). Aus den drei Hauptkategorien lassen sich drei in dieser Arbeit berücksichtigte Hauptanwendungsfälle herleiten: Automatische Ergebnisvisualisierung: Eine durchgeführte Fahrzeugmessung

soll für einen Menschen lesbar aufbereitet und zur Verfügung gestellt werden. Hierfür wird die Messung mit der Datengrundlage umgerechnet und visuell aufbereitet. Die Datengrundlage kann von einer KI oder von der messenden Person für die nachgelagerte Dateninterpretation festgelegt / protokolliert werden.

4.2 Prozess zur Identifikation der physikalischen Netzwerkstruktur

57

Individuelle Testabläufe: Um lange Wartezeiten zu vermeiden, werden die Test-

abläufe anhand der verbauten ECUs an das Fahrzeug individualisiert und optimiert. Paralleles Flashen: Die Software eines Steuergerätes kann auch OTA aktualisiert werden. Das kann parallelisiert ablaufen, um Zeit einzusparen. Hierzu muss das Diagnosesystem jedoch die Netzwerke kennen, um immer nur ein ECU je Netzwerk zu einer Zeit zu aktualisieren1 . Heutige Diagnosesoftware in der Fahrzeugentwicklung verwendet häufig nur einen Bereich der drei Hauptkategorien, die anderen muss der Anwender mit seinem Wissen füllen. Diese Lücke soll durch die Methode dieser Arbeit geschlossen werden, wobei die Konzepte nach folgenden Kriterien bewertet und ausgewählt werden: • • • • • •

Zuverlässigkeit (Wiederholbarkeit?) Geschwindigkeit (Wie häufig, wie lange pro Durchlauf?) Zuständigkeit (Wer muss es rechnen?) Datengrundlage (Was ist die Grundlage?) Systemabhängigkeit (Welche Hardware/Software wird vorausgesetzt?) Kosten (einmalige und laufende?)

4.2 Prozess zur Identifikation der physikalischen Netzwerkstruktur Die Methode dieser Arbeit verwendet einen mehrschichtigen Prozess, der im Folgenden dargestellt wird. Die gesamte Kommunikation findet zwischen einem IoTMesswerkzeug und einem Server in der Cloud statt. Dieser Zusammenhang ist in Abbildung 4.2 dargestellt. Es ist ein Entwicklungsfahrzeug zu erkennen, welches an einen IoT-Diagnosetester angeschlossen ist. Dieser besitzt viele Schnittstellen über die er Daten vom Fahrzeug mitschneiden und sicher über eine verschlüsselte und getunnelte Verbindung an ein 1 Auf

neuartige Konzepte in der Aktualisierung der Steuergerätesoftware wird in dieser Arbeit nicht näher eingegangen. (Grundlegende Informationen sind festgehalten in der Masterarbeit [22, 38], die Ergebnisse wurden für die vorliegende Forschungsarbeit gemeinsam erarbeitet und in der studentischen Ausfertigung schriftlich niedergeschrieben.)

58

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur LTE, BT, Wlan

Entwicklungs-/ Serienfahrzeug

VPN & HTTPS-REST

Private Cloud

IoT-Messgerät 12 Mess-Can's -11898DoIP -13400UDS -14229- Diagnose ...

Abbildung 4.2: Schematische Darstellung der Datenerhebung im Entwicklungsfahrzeug REST-Backend versenden kann, damit die Daten in der Cloud ausgewertet werden können. Der Neuheitswert und damit einhergehend die eingebrachte Intelligenz besteht hauptsächlich in der Struktur der aufgesetzten Cloud Applikation (DiagnosePlattform). Daher soll diese zuerst in den Fokus gerückt werden, im Anschluss daran folgt eine nähere Betrachtung des IoT-Diagnosetesters, der die Messungen durchführen und infolgedessen mit passenden Testabläufen aus der Cloud heraus versorgt wird. Der Applikationsserver, der in Kontakt mit dem IoT-Messwerkzeug steht, befindet sich in einer privaten Cloud des Institutes (IFS-Universität-Stuttgart). Er hat direkten Zugriff auf Datenbank- und Filesysteme des Instituts, sowie indirekten Zugriff über eine abgesicherte Verbindung und einen filternden Applikations-Server auf die private Cloud des OEM. Diese Serverarchitektur, die auf Grundlage dieser Arbeit entstanden ist, wird in Abbildung 4.3 dargestellt. Eingesetzte Kommunikations- und Netzwerkserver (Proxy-, Reverse-Proxy-, DHCP, DNS-, IP-Sec-, ...) werden aus Vereinfachungsgründen nicht abgebildet [36]. Des Weiteren steht der Applikationsserver stellvertretend für viele verteilte virtuelle Server sowie etwaige eingesetzte Kubernetes-Cluster, die von der Cloud bei Bedarf hoch- bzw. heruntergefahren werden. Durch den Zugriff auf diese Systeme ist es möglich, einen Prozess zu entwerfen, der ein Fahrzeugnetzwerk vollautomatisch auswertet. Beim Analysieren eines Fahrzeuges existieren zwei unterschiedliche Konzepte, die betrachtet werden müssen. Das eine ist die On-Board-Kommunikation, die abläuft, ohne dass ein Messwerkzeug Kontakt mit dem Fahrzeug haben muss. Hierbei tauschen Steuergeräte untereinander Daten aus. Das Messsystem greift dabei nicht aktiv in die Kommunikation ein. Das andere ist die Off-Board-Kommunikation, die

4.2 Prozess zur Identifikation der physikalischen Netzwerkstruktur

59

Private Cloud OEM

Private Cloud Institut Applikations-Server

Applikations-Server

(Fahrzeugidentifikation, Testskriptgenerierung, KI-Anwendungen, Aktualisierung Datenstand, ...)

(Fahrzeugverwaltung, Messungen aufbereiten, ...)

File-Server

Datenbank-Server

File-Server

Datenbank-Server

Web-Server

Abbildung 4.3: Serverkonzept der Cloud am Beispiel der Implementierung der Forschungsarbeit zwingend einen Diagnosetester bedarf. Der Diagnosetester muss eine Kommunikation mit allen Steuergeräten aufbauen, von denen er Messwerte abfragen oder Stellorgane schreiben möchte. Es werden höhere Protokolle UDS verwendet und spezifische Messaufgaben, genauer gesagt OTX-Skripte, durchgeführt. Die Erstellung solcher Messaufgaben bedarf der Identifizierung der im Fahrzeug vorhandenen Steuergeräte, wodurch sich der Kreis wieder schließt. Die beiden soeben beschriebenen Pfade sind in Abbildung 4.4 dargestellt. Beide Kommunikationsarten können und sollen gleichzeitig, sozusagen parallel, stattfinden. Bei der Auswertung bzw. Aufbereitung von FCT-Daten stellen sich auf der Ebene der Visualisierung und Interpretation immer zwei Fragen, sobald die Messung erfolgreich durchgeführt und in die Cloud geladen wurde2 . 2 Das

bedeutet, das Messsystem hat auf dem angeschlossenen CAN-Bus alle CAN-Frames mitgeschrieben und diese binären Daten gebündelt an den Server übertragen. Hier wurden diese dann in das proprietäre Format Action Scrypt Communication (ASC)[69] der Firma „Vector Informatik“ konvertiert und auf dem Server gespeichert.

60

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur IoT-Messgerät

Private Cloud

Off-BoardKommunikation

On-BoardKommunikation

Entwicklungs-/ Serienfahrzeug

Full-Can-Trace (FCT)-Messung an OBD oder Mess-Can's

DiagnoseErgebnis (ODX)

Abbildung 4.4: Messmöglichkeiten / Kommunikationspfade des IoTMesswerkzeugs zur Erhebung von Fahrzeugdaten 1. Welcher CAN-Bus gehört zu welcher Datei? 2. Wie war der Datenstand der einzelnen Steuergeräte? Die erste Frage bezieht sich auf die Detektion der VCI-Schnittstelle. Das bedeutet, in einem ersten Schritt muss bestimmt werden, um welchen CAN-Bus es sich bei dem angeschlossenen Netzwerk handelt. Bei der zweiten Frage ist indirekt gemeint, mit welcher ARXML-Datei die Datei interpretiert und somit einem Menschen vorgelegt werden kann. Da meist monatlich neue ARXML-Dateien passend mit neuer Steuergerätesoftware entwickelt werden, muss abhängig von der im Fahrzeug ermittelten Kommunikation die ARXML-Datei vorgeschlagen werden, die mit der größten Wahrscheinlichkeit zum aktuell geflashten Datenstand des ECU passt. Schlussfolgernd kann festgehalten werden, dass in einem ersten Schritt bei einem FCT der Netzwerkname und somit das VCI bestimmt werden muss. Dieser erste Schritt reduziert die mögliche Anzahl an ARXML-Dateien. Danach muss die ARXML bestimmt werden. Hierbei ist zu erwähnen, dass diese beiden Identifizierungen mit ML-Modellen realisiert werden, da die Daten, die an dieser Stelle

4.2 Prozess zur Identifikation der physikalischen Netzwerkstruktur

61

zu verarbeiten sind, relativ groß und die Unterschiede teilweise sehr gering (ein einziger ID) sind. Beispielsweise wird der ID 47 tendenziell in jedem CAN-Netzwerk existieren, aufgrund der niedrigen Nummer und der damit verbundenen hohen Priorität für den Buszugriff. Dahingegen kommt z. B. die ID 1456 vielleicht nur in einem einzigen Fahrzeugnetzwerk vor. Aufgrund der relativ guten Datengrundlage kommen an dieser Stelle Algorithmen des Narrow Learning zum Einsatz, um Dateien die bereits bestehen, verwenden zu können und kein Modell antrainieren zu müssen. Das hat den Hintergrund, dass ein Modell bei jedem Upload einer neuen ARXML den kompletten Datensatz wiederholt durchgehen und lernen müsste. Das Identifizieren des angeschlossenen Netzwerkes unterstützt den Entwickler bei seiner Arbeit, da er dieses nicht selber durchführen muss. Weiterhin vermeidet das automatische Identifizieren des Netzwerks dadurch Fehler und reduziert Einschränkungen darin, dass Monate nach der Messung die Wahrscheinlichkeit einer korrekten Zuweisung der Buskonfiguration und Interpretationsdatei sinkt. Außerdem muss der Kabelbaum des externen Testequipments so zukünftig nicht mehr fest vorgegeben sein. Stand heute verbindet ein Entwickler mit einem vorgefertigten Kabelbaum die Fahrzeugschnittstellen, entsprechend der Vorgabe des Messsystem-Herstellers. Benötigt er einen anderen CAN-Bus im Fahrzeug oder will er an einer weiteren Baureihe messen, braucht er einen anderen Kabelbaum. Die KI und die Identifizierung des Netzwerkes und darauf aufbauend der ARXML wird das nachhaltig vereinfachen. Solange der Entwickler CAN-High und CAN-Low korrekt anschließt und an die Busterminierung denkt, wird es zukünftig durch diese Methode unbedeutend sein, welcher CAN-Bus mit der Stichleitung des Messsystems kontaktiert ist. Das wird in der Fahrzeugentwicklung auch zur Erleichterung führen, wenn der fahrzeuginterne Kabelbaum an den Messkupplungen nicht korrekt angeschlossen ist, da die Messung durchgeführt werden kann, solange die Baudrate und die Technologie dahinter richtig sind3 . Die KI ermöglicht und übernimmt den dynamischen Kabelbaum-Manager, damit der Entwickler sich auf das Messen und Analysieren konzentrieren kann. Das entkoppelt das benötigte Expertenwissen von demjenigen, der die Messung durch-

3 Eine

Baudraten- und Technologie-Identifizierung (CAN oder CAN-FD) ist noch aktueller Bestandteil der Forschung.

62

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

führen muss und reduziert das Fehlerpotenzial. In Abbildung 4.5 sind die vier KI-Implementierungen, die Bestandteil der Methode sind und in dieser Arbeit entwickelt wurden, dargestellt.

Abbildung 4.5: Die vier in dieser Methode implementierten KI-Ansätze / Einsatzmöglichkeiten Im Detail werden die Ansätze in einem späteren Kapitel definiert und hergeleitet. An dieser Stelle muss darauf hingewiesen werden, dass aus den FCT-Messungen eine Transformation der Daten in ein für eine KI berechenbares Datenschema stattfinden muss und dass daraufhin vier unterschiedliche Modelle benötigt werden, um die Identifikation der VNA zu gewährleisten. Jedoch gibt es weitere übliche Messungen, die regelmäßig durchführt werden, um Subprozesse im Fahrzeug zu überprüfen. Das sind Diagnoseskripte und somit Bestandteil der Off-Board-Kommunikation. Ein Diagnoseskript verwendet in modernen Entwicklungsfahrzeugen das Trägerprotokoll UDS. Ein UDS-Dienst wird an ein Steuergerät über dessen Diagnoseadresse übertragen. Die Diagnosedienste sind in der ODX-Norm festgelegt und die Messwerte werden in entsprechenden Dateien verwaltet. Das bedeutet konkret, dass der Steuergerätehersteller zu seinem Steuergerät mit vorinstallierter Software noch eine Beschreibungsdatei im ODX-Format ausliefert. Durch diese Beschreibungsdatei kann der Entwicklungsingenieur mithilfe eines Off-Board-Testequipments eine Verbindung mit dem ECU aufbauen und einzelne Messwerte abfragen.

4.2 Prozess zur Identifikation der physikalischen Netzwerkstruktur

63

In der ODX-Datei ist definiert, wie der Inhalt der Nachricht, die mit dem UDSProtokoll übertragen wurde, zu interpretieren ist, beispielsweise bei der Drehzahl mit einer Geradengleichung. Der OEM erstellt sich eigene Testabläufe als OTXSkripte und führt diese im Fahrzeug aus, dabei hat er die Erwartungshaltung, dass die Messwerte für seine Ingenieure umgerechnet und aufbereitet werden von dem Testequipmenthersteller. Hier kommt auch schon die eigentliche Herausforderung, woher weiß der Entwickler, wenn er an ein neues Fahrzeug herantritt, was für Steuergeräte verbaut sind und in welchem Softwarestand sich diese befinden? In aller Regel hat der Entwickler keine Chance, das schnell und einfach herauszubekommen. Daher haben sich in der Automobilindustrie umfangreiche Testabläufe etabliert. Der Entwickler weiß nicht, welches Motorsteuergerät in dem konkreten Fahrzeug verbaut ist und somit testet das OTX-Skript alle möglichen durch. So verfährt das OTX-Skript mit allen anderen Steuergerätegruppen ebenfalls. Daraus entsteht ein Diagnoseskript, das mit hoher Wahrscheinlichkeit alle Steuergeräte im Fahrzeug erkennt und die entsprechenden Messwerte abfragt und speichert. Aber diese Verfahren bringen Nachteile mit sich. So dauert ein Skript relativ lange, da beim untersuchten OEM über 300 Gruppen abgefragt werden und angenommen, dass nur 40 im Entwicklungsfahrzeug verfügbar sind, resultiert für den Entwickler alleine für die Steuergeräte-Identifikation pro Skriptdurchlauf 260 negative Antworten (mit je 𝑃2𝑚𝑎𝑥 = 3000 ms). Danach kommen noch die Messwerte, die von Softwarestand (im Folgenden „Variante“ genannt) zu Softwarestand unterschiedlich sein können. Diese negativen Antworten werden schneller übertragen (100 ms in der Regel). Das relativ lange Warten auf Messergebnisse führt dazu, dass die Messungen seltener ausgeführt werden. Weiterhin haben sich die Entwickler in Fraktionen aufgeteilt, um die Wartezeit zu reduzieren. Das bedeutet, es gibt einen Strang Powertrain, Body, Infotainment und so weiter. In den Strängen gibt es meistens noch weitere Spezialisierungen auf einzelne Funktionsgruppen. Das kann in manchen Fällen sinnvoll sein, aber prinzipiell ist diese Reduzierung entstanden durch die Implementierung, wie heute Testabläufe erstellt und verwendet werden. Dieser Prozess ist generell umkehrbar und soll im Folgenden auch detailliert beschrieben werden. Mit dem heute verwendeten Prozess werden relativ viele Testfahrten durchgeführt, aufgrund der Tatsache, dass jede Domäne eigene Testabläufe erstellt und pflegt und nicht von den anderen profitieren kann. Dieser Zeit-, Rohstoff-

64

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

und damit Kostennachteil kann durch die hier vorgestellte Methode ausgeglichen werden. Das kann durch die Umkehrung der Identifizierung der Steuergeräte und ihrer Varianten durch intelligente Prozesse in der Cloud anders realisiert werden. Die Idee ist, dass beim Starten des IoT-Diagnosetesters dieser ein spezielles Diagnoseskript ausführt, durch das alle Steuergerätegruppen abgefragt werden gepaart mit einer gleichzeitigen FCT-Messung auf allen angeschlossenen CAN-Netzwerken. Was aus der FCT-Messung entsteht, ist bereits beschrieben. Aus der Diagnosemessung berechnet nun die Cloud alle verbauten Steuergeräte und deren Varianten, diese werden auf der Datenbank abgelegt. Somit erhält der Entwickler gleichzeitig eine Protokollierung des Fahrzeugaufbaus und der Softwarestände über die gesamte Betriebszeit. Aber hauptsächlich kann durch diesen vorgelagerten Prozess die Testablauferstellung individualisiert werden, was die Skriptdurchlaufzeit bei gleichbleibender Testabdeckung reduziert. In beiden Fällen wird ein Umbau eines Steuergerätes unmittelbar detektiert. Der Unterschied liegt nun darin, dass beim aktuellen Verfahren bei jeder Messung bspw. 10 Minuten benötigt werden und bei dem neuen Prozess nur einmalig bei jedem Start des Messsystems4 . Der Vorteil der hier beschriebenen Methode ist jedoch, dass selten eine Messung unmittelbar nach dem Boot ausgeführt werden soll. Messungen, die nach dem Boot ausgelöst werden, sind häufig FCT-Messungen, um das Aufwachen der Buskommunikation zu dokumentieren. Das wäre sogar schon inklusive, ohne das der Entwickler dafür etwas unternehmen müsste. Ein weiterer Vorteil ist, dass die Skriptabdeckung wieder über alle Domain / Sparten / Baureihen möglich ist, da so optimierte Messungen kaum länger als ein paar Sekunden laufen. Damit würden sich Messungen deutlich mehr lohnen und Versuchsfahrten verringert werden. Zudem kommt diese Herangehensweise dem Thema Big Data näher und kann als Grundlage für neue Ansätze dienen. Wie funktioniert die Steuergeräte-Identifizierung mit dem ODX-Standard? In der ODX ist ein UDS-Dienst festgelegt, der zum Abfragen und Umrechnen der Variante dient. Das ist der Dienst „0xF100“, der mit dem Trägerprotokoll UDS Request 4Wobei

hier Verbesserungspotenzial besteht, die aber einem OEM vorbehalten sind. Die FahrzeugIdentifizierungsnummer (engl. Vehicle Identification Number) (VIN) kann analysiert werden, um die ECU-Gruppen auf Grundlage der Baureihe zu filtern.

4.2 Prozess zur Identifikation der physikalischen Netzwerkstruktur

65

Read by Identifier (0x22) an die Diagnosekennung der ECU-Gruppe übertragen wird. Eine Anfrage „0x22F100“ an die Diagnosekennung Req-ID des Motorsteuergerätes „0x7E0“ fragt in erster Linie ab, ob ein Motorsteuergerät im Netzwerk vorhanden ist. Wenn es vorhanden ist, wird es auf der Adresse „0x7E8“ (Res-ID) mit einer positiven Antwort (UDS Response - Read by Identifier (0x62)) mit „0x62F100xxxxxx“ antworten. Durch die positive Antwort weiß der Server, dass ein Motorsteuergerät anwesend ist. Der Server muss jetzt seinerseits in der Datenbank prüfen, um welches Steuergerät es sich hierbei handelt und mit welcher Variante es aktuell kommuniziert. Der OEM und der Zulieferer sind dafür verantwortlich, die Eindeutigkeit dieses Patterns zu gewährleisten. Daher kann es vereinzelt vorkommen, wenn zwei Zulieferer das gleiche Steuergerät liefern, dass in einem weiteren Schritt der Zulieferer bestimmt werden muss, um das Steuergerät sicher zu identifizieren. Um einen Überblick über die Dimension zu bekommen, werden bei einem OEM mit vielen unterschiedlichen Baureihen etwas mehr als 1000 Steuergeräte verwaltet. Jedes Steuergerät in der Entwicklung unterliegt mindestens zwei Software-Updates, eines für das Sommerhalbjahr und eines für das Winterhalbjahr. Bei einem Motorsteuergerät versteht es sich von selbst, dass hier der Zyklus eher bei monatlichen Updates liegt, die der Zulieferer ausliefert. Diese grob 1000 Steuergeräte teilen sich nun in etwa 300 Steuergerätegruppen auf. Jede Steuergerätegruppe hat eine Diagnose-ID, die mehr oder weniger genormt ist. Bei abgasrelevanten Steuergeräten ist diese genormt über alle OEM hinweg. Das bedeutet, dass wenn der ID „0x7E0 “ gerufen wird, das Motorsteuergerät antwortet. Bei nicht abgasrelevanten Steuergeräten sind die IDs nicht genormt, aber sie werden trotzdem größtenteils eingehalten, zumindest innerhalb eines Zulieferers. In Abbildung 4.6 ist das vollständige Konzept der Methode dieser Arbeit dargestellt. Es ist zu erkennen, dass der IoT-Diagnosetester hauptsächlich als HardwareSchnittstelle für das Fahrzeug betrachtet wird. Dieses Tool führt Messungen aus, die es von der Cloud erhält, und sendet die Resultate wieder an die Cloud. Der Kern dieser Methode ist die VNA-Bestimmung. Hierzu hat die Cloud zwei Schnittstellen, die unterschiedliche Prozesse durchlaufen. Wie auf der linken Seite der Abbildung dargestellt, werden die ODX-Dateien verwendet für die Bestimmung der ECUs und deren Varianten. Hierauf wird in

66

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

Abbildung 4.6: Konzept der Methode zur Identifizierung der FahrzeugNetzwerk-Architektur (engl. Vehicle Network Architecture) Kapitel 4.4 im Detail eingegangen. Auf der rechten Seite der Abbildung werden die ARXML-Dateien verwendet, um die Hardware-Schnittstellen zu bestimmen und die ECU-Validierung zu ermöglichen. Aber damit ein KI-Modell trainiert werden kann, muss zuerst eine Datentransformation in ein übliches ML-Datenformat durchgeführt werden. Diese Transformation ist in Kapitel 4.3 dargestellt. Die Modelle, die auf der Grundlage dieser Daten trainiert werden, sind in Kapitel 4.5 hergeleitet. Aufbauend auf diesen Daten sind zukünftig noch weitere Ansätze möglich, aber diese Arbeit beschränkt sich auf die vier bereits eingeführten. Die vier KI-Modelle und deren tabellarisches Ergebnis sind in der Abbildung ebenfalls festgehalten.

4.3 Datenerhebung und Transformation für eine ML-Datenbasis

67

4.3 Datenerhebung und Transformation für eine ML-Datenbasis In dieser Arbeit werden ML-Algorithmen verwendet, die in Bibliotheken der Programmiersprache Python implementiert sind und durch Hyperparameter-Tuning an einen Anwendungsfall angepasst werden. An dieser Stelle gibt es zwei Fragen, die es zu klären gilt und die im Folgenden beschrieben sind. 1. Wie kann in der Cloud eine ML-Applikation betrieben werden? 2. Welche Daten liegen vor und in welchem Format müssen sie für eine KIApplikation umgerechnet werden? Die erste Frage führt zur Definition der Ressource und die zweite zur Analyse und Festlegung der Datentransformation. Zuerst soll auf die Anforderungen an die Ressource der Cloud eingegangen werden. Wie im Cloud-Computing üblich, wird ein virtueller Server in Form eines IaaS verwendet. Dieser virtuelle Server kann seine Rechenleistung und seinen Arbeitsspeicher dynamisch an die Applikation anpassen und so auf einem oder mehreren physischen Servern betrieben werden. Auf diesem virtuellen Server wird ein Betriebssystem z. B. „Linux“ bereitgestellt, auf welchem die Programmiersprache Python [16] mit der Paketverwaltung „PIP“ installiert und um die ML-Bibliotheken5 ergänzt wird. Das Bereitstellen der Programmiersprache Python und der individuellen Software erfolgt durch die Docker-Engine. Durch die Auslagerung der Applikations-SW in Docker-Container bleibt die Cloud flexibel und portierbar (stateless). Weiterhin kann die verwendete Python-Version und die Versionen der einzelnen Erweiterungen von den Entwicklern festgelegt werden, bzw. die Entwickler können mit gleichen Bedingungen lokal testen, wie wenn der Container zu einem späteren Zeitpunkt veröffentlicht ist. Durch diese Vorbereitung kann die Python-App auf diesem virtuellen Server verwendet werden. Diese App benötigen eine Schnittstelle (API), mit der die KI-Tools aufgerufen und von anderen Servern bzw. Diensten im verteilten System verwendet werden können. Hierzu wird ein REST-Webserver von der Python-Applikation heraus verwendet, die Bibliothek „Flask“6 , um die einzelnen ML-APIs zu definieren und als Mikroservice zu veröffentlichen. Im Umfeld der Fahrzeug-Netzwerk-Messungen sind zwei Dateitypen weit verbreitet, das ist einerseits die binäre Datei (.blf) und andererseits die ASCII-Datei 5 Eingesetzte 6 Eingesetzte

Pakete: jupyter, matplotlib, numpy, pandas, scipy, scikit-learn, tensorflow, tensorboard Pakete: Flask, flasgger, flask-restful

68

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

(.asc). Das in dieser Arbeit verwendete IoT-Messwerkzeug nimmt die .blf-Datei auf und sendet diese an das Backend, welches daraus die .asc-Datei berechnet und beide Dateien auf dem Fileserver vorhält. Die Datenbank verknüpft beide Dateien entsprechend zur weiteren Verarbeitung. In dieser Arbeit wird die .asc-Datei für die implementierten KI-Algorithmen verwendet 7 . Das hat den Hintergrund, dass Supervised-Learning-Algorithmen untersucht werden und eine Klassifikation einer interpretierten ASCII-Datei für einen Experten möglich ist. Das Datenformat .asc kann in der Dokumentation der Firma „Vector Informatik“[69] im Detail nachgesehen werden. Ein Auszug aus einer durchgeführten Messung wird durch Abbildung 4.7 dargestellt. In der Abbildung ist zu erkennen, dass alle im CAN-Standard üblichen Elemente enthalten sind und noch zusätzliche.

Abbildung 4.7: Eine reale Messung im .asc Format zum Einlesen in ein MLDatensystem Von links nach rechts befinden sich in einer Zeile: 1. die absolute Zeit zwischen den Frames und dem Start der Messung 2. die Bussystemnummer VCI, von dem die Zeile aufgezeichnet wurde (Datenpunkt) 3. der Identifier (ID) der Nachricht (Priorität)

7 Auf die Konstruktion der Daten-Pipeline eines Machine Learning Konzeptes wird in dieser Arbeit nicht

näher eingegangen. (Grundlegende Informationen in der Masterarbeit [10], die Ergebnisse wurden für die vorliegende Forschungsarbeit gemeinsam erarbeitet und in der studentischen Ausfertigung schriftlich niedergeschrieben.)

4.3 Datenerhebung und Transformation für eine ML-Datenbasis

69

4. Data- oder Datenanforderung (engl. Remote Transmission Request) (RTR)Frame 5. der Datenlängencode (engl. Data Length Code) (DLC) des CAN-Frames 6. Payload-Byte eins bis acht 7. Flags, die „Vector Informatik GmbH“ für ihre Software „CanOE“ benötigt. Ein Datensatz, mit dem ein Data-Scientist im Umfeld der KI-Forschung arbeitet, hat häufig eine einheitliche Form in der Programmiersprache Python. Hier wird ein Dictionary verwendet, in welchem die Daten definiert gespeichert werden.8 Der Data-Scientist kann dann entscheiden, ob er mit dem Dictionary, also den Numpy-Daten, oder mit dem Panda-Datenrahmen (engl. Data Frame) (df) arbeiten möchte. Die Bestandteile des Dictionary werden im Folgenden erläutert: filename: Der Dateiname der Messung. feature_names: Die Namen der einzelnen Spalten, die für eine ML-Implementierung verwendet werden können. descr: Eine Beschreibung der Daten. data: Die Daten, die für das Training und/oder die Validierung verwendet werden können. target_names: Die Namen der einzelnen Spalten der möglichen Klassifizierungen. target: Die Daten, die zu den Zielspalten gehören. frame: Ein vollständiges Panda-df, das alternativ zu der Struktur abgerufen und verwendet werden kann.

Im weiteren Verlauf der Arbeit wird immer das „frame“ abgefragt und somit mit dem df gearbeitet. Es wurde eine Software entwickelt, die es ermöglicht, eine ASCDatei einzulesen und in das ML-Datenformat zu transferieren. In Abbildung 4.8 ist zu erkennen, wie die Daten nach dem Einlesen in ein ML-Datenformat aussehen. Es sind insgesamt 14 Spalten dargestellt, drei davon dienen als Klassifizierungsziel (BusNumber, is_UDS und target) die anderen 11 Spalten repräsentieren die Daten, die in der Messung enthalten sind. Alle Messwerte wurden bereits in das dezimale Zahlensystem umgerechnet, um später durch eine Normalisierung als Skalierungs-

8 Die

dict_keys lauten: [„filename“, „feature_names“, „descr“, „data“, „target_names“, „targe“, „frame“]

70

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

Abbildung 4.8: Eine reale Messung als df zum Trainieren von ML-Modellen Algorithmus das volle Potenzial der KI-Algorithmen nutzen zu können. Es folgt eine Übersicht über die Klassifizierungsziele der untersuchten KI-Ansätze: • die Spalte „BusNumber“ für die Klassifikation der VCI-KI • die Spalte „is_UDS“ für die Klassifikation der Diagnose-KI • die Spalte „target“ für die Klassifikation der ECUGroup-KI Eine Messung im Fahrzeug kann beliebig lang sein und abhängig von den zu untersuchenden Hypothesen im Datensatz müssen die Daten bereinigt bzw. aufbereitet werden. Der Datensatz, der über das Dictionary abgerufen wird, bleibt unangetastet und der Datensatz, der über das Frame bereitgestellt wird, wird im Folgenden auf die Datenpunkte limitiert, die für eine erfolgreiche Identifikation notwendig und hinreichend sind.

4.3 Datenerhebung und Transformation für eine ML-Datenbasis

71

Abbildung 4.9: Das Histogramm der FCT-Messung vor der Bereinigung Zum Identifizieren der Datenpunkte, welche zum Lösen der gestellten Aufgabe wenig beitragen, sind in Abbildung 4.9 die Histogramme der einzelnen Spalten dargestellt. Auf der x-Achse sind die unterschiedlichen Werte aufgetragen und auf der y-Achse, wie häufig dieser Wert in den Daten vorkommt. In der Abbildung ist zu erkennen, dass bei der beispielhaften Messung in der Spalte „BusNumber“ fünf CAN-Busse (Hardwareschnittelle 6, 9, 10, 11, 12) verbunden waren. Am meisten Buskommunikation hat auf der Busnummer 11 stattgefunden und am wenigsten auf der Nummer 9. Aus dem Histogramm können zwei Datenreduktionen hergeleitet werden. Das eine ist die Löschung der Spalte „Time“. Da in dieser Arbeit keine Zeitabhängigkeiten untersucht werden, ist ein Zeitbezug nicht notwendig. Zusätzlich zeigt das Histogramm, dass diese Daten für die gestellte Hypothese keinen Mehrwert liefen.

72

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

Abbildung 4.10: Das Histogramm der FCT-Messung nach der Bereinigung für die KIs Das andere ist das Löschen aller Datenpunkte, die identisch mehrfach vorkommen9 , sozusagen das Löschen aller Duplikate. Zusätzlich ist in der Spalte ID zu erkennen, dass in dem Fahrzeug, in dem die Messung durchgeführt wurde, sowohl Standard-CAN als auch CAN-ext verwendet werden. Für die Herleitung der Methode wird sich auf Standard-CAN beschränkt. Der Grund dafür liegt in der anschaulicheren Visualisierung der Ergebnisse. Vor der Datenreduktion gab es 14 Spalten und 541,124 Datenpunkte in der Messung und danach bleiben 13 Spalten und 17,261 Datenpunkte übrig. Das bedeutet, die Daten, die von den MLAlgorithmen analysiert werden, wurden um den Faktor 31 reduziert. In Abbildung 4.10 ist das Histogramm der reduzierten Daten dargestellt. Damit ist nun der Datensatz definiert, mit dem die einzelnen ML-Modelle trainiert werden können. Ein Scatter-Plot der Daten befindet sich im Anhang A.1. Zusätzlich zur FCT-Messung 9 Beispielspielweise kann das die Umgebungstemperatur sein, die zyklisch übertragen wird und sich bei

einem stehenden KFZ im Messungsdurchlauf je nach Genauigkeit nicht stark bis gar nicht verändert.

4.4 Methode zur Steuergeräte- und Variantenidentifizierung

73

wird ebenfalls eine Diagnosemessung durchgeführt. Im anschließenden Kapitel wird es genau um diese Messung und die Interpretation dieser gehen.

4.4 Methode zur Steuergeräte- und Variantenidentifizierung Der Prozess der Identifizierung aller in einem Entwicklungsfahrzeug verbauten Steuergeräte ist vielschichtig und es werden verschiedene Geräte benötigt. Für das Fahrzeug wird ein Messgerät benötigt, das an der Diagnoseschnittstelle des Fahrzeuges mit dem Diagnosenetzwerk verbunden ist. Das kann die OBD-II-Schnittstelle sein, aber wenn die Fahrzeugnetzwerke über eine andere Art zugänglich gemacht wurden, kann darüber auch bspw. der Diagnose-CAN kontaktiert werden. Das Messgerät ist im vorliegenden Fall an zwölf Fahrzeugnetzwerke gleichzeitig angeschlossen. Die Zuordnung der Fahrzeugnetzwerke ist vom Kabelsatz vorgeschrieben und im Laufe dieses Kapitels wird dargestellt, dass diese Zuordnung von einer KI in der Cloud nachhaltiger gelöst werden kann, als neue mechanische Kabelsätze herzustellen, um eine andere Kombination an Fahrzeugnetzwerken zu betrachten. Das Messsystem muss eine spezielle Messaufgabe von der Cloud erhalten und durchführen, um die verbauten Steuergeräte zu identifizieren. In erster Linie benötigt das Messsystem Schnittstellen, um mit der Cloud zu kommunizieren, was im vorliegen Fall des IoT-Messsystems mit einer WLAN- und GSM-Antenne gelöst ist. Das Messsystem ist in ständigem Kontakt mit der REST-API in der Cloud und bezieht neue Messaufgaben oder sendet abgeschlossene. Somit ist auch der zweite Teilnehmer des Prozesses definiert, es ist die Cloud. Aber was muss die Cloud alles leisten, um eine Identifizierung der Steuergeräte zu ermöglichen? Zu Beginn stellt sich die Frage, wo die Daten herkommen. Diese Frage kann mit den ODX-Dateien beantwortet werden. In der ODX-Norm 22901[29] ist vorgeschrieben, wie die Vererbung der einzelnen Softwarevarianten eines Steuergerätes vonstattengehen soll. Zudem ist definiert, wie die Identifizierung einer Variante durchgeführt wird. Dabei wird das UDS-Protokoll verwendet und ein 0x22-Messwert versendet. Als Payload erhält das CAN-Frame den hexadezimalen Wert 0xF100. Daraufhin muss innerhalb einer definierten Zeitspanne (Konstante: P2) meistens etwa 3000 ms auf die mögliche Antwort von dem angefragten ECU gewartet werden. Die Antwort beinhaltet eine Herstellereindeutige Zahl, womit der ECU Name und die SW-Variante berechnet werden. Mit Hersteller ist an dieser

74

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

Stelle der Steuergerätehersteller gemeint und nicht der OEM, der am Ende das KFZ unter seinem Markensymbol vermarktet. Somit ist im weiteren Identifizierungsverlauf von Relevanz, dass die Zahlen nicht eindeutig sind und durch einen separaten Prozess überprüft und validiert werden müssen, alle Steuergeräte eines Fahrzeuges sicher und zuverlässig erkannt werden müssen. Daher erschließt sich, dass eine relationale Datenbank eingesetzt werden kann, um die relevanten Bereiche aus einer ODX-Datei zu extrahieren und zu standardisieren, um aufbauend auf dieser Datenbank weitere Tools zu entwickeln. Die Cloud besteht somit aus drei Servern, die es zusammen ermöglichen, die Fahrzeugidentifizierung durchzuführen. 1. Der Fileserver: Hier werden die Dateien in einer definierten Struktur abgelegt und es werden etwaige Back-up Pläne ausgeführt. 2. Der Datenbankserver: Hier liegt die Datenbank der eingelesenen ODX-Dateien, so dass Applikationen nicht mit den Dateien arbeiten müssen, sondern effizient mit Structured Query Language (SQL)-Statements. 3. Der / die Applikationsserver: Hier laufen alle einzelnen Programme und greifen auf den Datenbank- und Fileserver zu. Mitunter läuft auf diesem Server auch der Webserver für die REST-API, mit der der IoT-Diagnosetester auf die Cloud zugreift. Um den Identifizierungsprozess des Gesamtfahrzeuges zu realisieren über alle ECU-Hersteller hinweg, wird der CAN Identifier der übertragenen ODX-Diagnosebotschaft mitanalysiert und ausgewertet. Jedes ECU kann über eine DiagnoseRequest-ID angesprochen werden und wird daraufhin mit der definierten DiagnoseResponse-ID die Anfrage beantworten, wenn das ECU im Fahrzeug vorhanden ist. Das ist die eine Möglichkeit, die ECUs auszuwerten. Die andere ist auf die Diagnose-Funktionsgruppen zurückzugreifen. Hierbei kontaktiert der Diagnosetester nicht ein Steuergerät explizit, sondern es wird eine Gruppenadresse aufgerufen. Die Teilnehmer der Gruppe müssen innerhalb einer definierten Zeit antworten und der Diagnosetester muss diese Zeit abwarten. All diesen Mechanismen liegt eine eingehende analytische Auseinandersetzung mit der ODX-Datei zugrunde und dahingehend mit der Norm, nach welcher die ODX-Datei aufgebaut ist. Eine ODX-Datei entspricht einer ECU-Beschreibungsdatei zu einem Zeitpunkt. In der vorliegenden Arbeit werden alle ECUs eines OEM berücksichtigt, somit erstrecken sich die Analysen, die im Folgenden gezeigt werden, über 1215 unterschiedliche ECUs, die über den Zeitraum eines Jahres täglich abgefragt und ausgewertet wurden. Dadurch ist sichergestellt, dass viele Änderungen, egal zu welchem Softwarestand des Fahrzeuges, berücksichtigt sind. Je länger das System läuft, desto mehr Daten

4.4 Methode zur Steuergeräte- und Variantenidentifizierung

75

werden in der Datenbank enthalten sein. Das ist wichtig, da die Software eines Fahrzeuges unregelmäßig aktualisiert wird, zumindest Stand Mai 2022. Für die Datenextraktion werden somit die eindeutigen Zahlen zur Mustererkennung (engl. pattern recognition), im folgenden Pattern (deutsch Muster) genannt, benötigt, mit denen ein ECU auf die Anfrage „0x22F100“ antworten kann. Da das Pattern nur in Kombination mit dem Hersteller oder der Diagnose-CAN-ID den entscheidenden Mehrwert bietet, muss in der Datenbank sowohl der Pattern-Zweig zu jeder Variante aufgenommen werden als auch die Interfaces, mit denen ein ECU mit den anderen kommunizieren kann. Zusätzlich wird der Dateipfad auf dem Fileserver gespeichert für zukünftige Erweiterungen. In Abbildung 4.11 ist das Datenbankschema dargestellt, das aus den gerade vorgestellten Anforderungen entstanden ist.

Abbildung 4.11: Das Datenbankschema der Diagnose-Pattern-DB

76

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

Das dargestellte Schema teilt die Aufgabenstellung in die zweite Normalform (2NF) einer relationalen Datenbank auf. Hierbei wird versucht, so wenig Daten wie möglich redundant zu speichern, aber es kann vorkommen, dass Daten redundant abliegen. Die 2NF zeichnet sich ebenfalls durch n-zu-n-Verbindungstabellen aus, die das Datenmapping übernehmen. Auf der rechten Seite sind zwei Tabellen dargestellt, die mit den restlichen in keiner Beziehung stehen. Das ist einmal die Tabelle Log, hier werden alle Warnungen bzw. Fehler und Programmabstürze protokolliert, die in der Applikation ausgelöst wurden, zum Zeitpunkt als die ODX-Dateien mit der Datenbank synchronisiert wurden. Neue Fehler- oder Infonachrichten, die in der DB hinterlegt wurden, können automatisch über einen Webhook an den betreffenden Entwickler gemeldet werden. Die andere Tabelle ChangeLog überwacht die DB. Wenn ein bestehender Eintrag verändert werden soll, wird der alte Wert hier gespeichert. Durch diese Tabelle sind Veränderungen über die Zeit darstellbar und die Implementierung einer Alternative10 wäre denkbar. Alle anderen Tabellen sind miteinander verbunden und die Aufteilung in drei Stränge von oben nach unten und von links nach rechts entspricht der Logik, wie die Datenbank funktioniert. Die Datenbank soll nun anhand eines Beispiels befüllt werden, um die Funktionalität zu beschreiben. Am Anfang steht die Datei, die von einer Applikation geöffnet wird. Daraufhin wird ein Eintrag in der Tabelle File getätigt, dieser setzt aber eine Referenz auf die Tabellen Extension und Folder voraus. Mit diesen drei Tabellen ist die Datei auf dem Fileserver jederzeit wieder auffindbar. Nachdem die Datei in der Datenbank angelegt ist, wird ausgewertet, um welches Steuergerät es sich handelt und ein entsprechender Eintrag erzeugt. Jedes ECU hat mehre Schnittstellen, über die es kommunizieren kann. Ein modernes Steuergerät hat eine Schnittstellendefinition für den Betrieb im Fahrzeug und eine separate für die Erprobung auf dem Schreibtisch / Labor. Da der Hersteller des ECU dieses bei mehreren OEMs vermarktet, kommen zudem noch mehrere Standards zum Einsatz. So ist es nicht selten, dass ein Motorsteuergerät über 7 Interfaces (UDS-CAN-B, UDS-CAN-D, UDS-CAN-ext, UDS-CAN-int, UDSEthernet-DoIP, UDS-Ethernet-DOIP-DOBT, KWP-CAN-D) verfügt. Zusätzlich können die CAN-Busse noch den CAN-FD Standard unterstützen. Das Ganze befindet sich zusammengefasst in den Datenbanktabellen Baudrate, Interface und Interfaces aus Abbildung 4.11. Die ODX-Datei wird dahingehend untersucht, wie viele Interfaces in der Basisvariante definiert sind. Diese Interfaces werden hinzuge10 Beispielsweise

wenn die Plausibilisierung die neueste Datei für nicht richtig einstuft

4.4 Methode zur Steuergeräte- und Variantenidentifizierung

77

fügt, mit der entsprechenden Baudrate verlinkt und mit dem Steuergerät verknüpft. Die Tabelle Interface ist so gestaltet, dass hierüber die CAN-IDs ausgegeben werden können, aus denen ein Fahrzeug bestehen kann, also nachdem die 1215 ECUs eingelesen wurden. Einen ersten Überblick über die eingelesenen Interfaces kann mit dem SQL-Statement aus Listing 4.1 abgefragt werden. Listing 4.1: SQL-Abfrage zur Auflistung aller Schnittstellen 01 |

SELECT * FROM [DiagPattern ].[ dbo ].[ Interface ]

Insgesamt sind 1189 unterschiedliche Interfaces in der Datenbank enthalten, ein Auszug der Daten ist in Abbildung 4.12 dargestellt.

Abbildung 4.12: Datenbankauszug der Schnittstellen/Interfaces Es ist zu erkennen, dass unterschiedliche Schnittstellen (Spalte Name) / Protokolle sowie Baudraten von der Methode unterstützt und verwendet werden. Die beiden beschriebenen Adressierungsarten eines Steuergerätes sollen im Folgenden näher analysiert werden. Bei der funktionalen Adressierung wird die SQL-Abfrage entsprechend Listing 4.2 durchgeführt. Listing 4.2: SQL-Abfrage zur Auflistung aller funktionalen Schnittstellen 01 | 02 | 03 | 04 | 05 |

SELECT [FuncReqId\_Dez] AS FuncDiag FROM [ DiagPattern ].[ dbo ].[ Interface ] WHERE [FuncReqId\_Dez] < 2048 GROUP BY [FuncReqId\_Dez] ORDER BY [FuncReqId\_Dez]

78

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

Die CAN-ext-IDs werden zur Vereinfachung herausgefiltert, so dass nur StandardCAN-IDs (CAN und CAN-FD) enthalten sind. Das Resultat sind vier Gruppen, das Abfrageergebnis ist in Abbildung 4.13 abgedruckt.

Abbildung 4.13: Datenbank-Abfrage der funktionalen Interface-Gruppen Da das IoT-Messsystem das Warten auf mehrere Antworten nicht unterstützt, kann dieser vielversprechende Ansatz nicht weiter verfolgt werden. Andere Hardwaresysteme können hier unter Umständen umfangreicher aufgestellt sein. Was das in dieser Arbeit verwendete IoT-Diagnosesystem unterstützt, ist die Abfrage eines spezifischen Diagnosedienstes, mit einer Request-ID, Response-ID und einer Nachricht. Bei dieser Art der Kommunikation ergeben sich nach der SQL-Abfrage aus Listing 4.3 insgesamt 328 unterschiedliche Gruppen, die bei Standard-CAN sequenziell getestet werden müssen. Listing 4.3: SQL-Abfrage zur Auflistung aller physikalischen Schnittstellen 01 | 02 | 03 | 04 | 05 |

SELECT [PhysReqId_Dez] AS Req, [PhysResId_Dez] AS Res FROM [ DiagPattern ].[ dbo ].[ Interface ] WHERE [PhysReqId_Dez] < 2048 GROUP BY [PhysReqId_Dez], [PhysResId_Dez] ORDER BY [PhysReqId_Dez], [PhysResId_Dez]

In Abbildung 4.14 ist ein Auszug der Abfrage dargestellt und beispielhaft die ECU-Gruppe der Motorsteuergeräte markiert. Die Zeile 321 enthält die Request- 0x7E0 (2016) und Response-ID 0x7E8 (2024), die bei der Kontaktierung dieses Steuergerätes notwendig sind. Diese Liste der möglichen ECU-Gruppen kann aus der Datenbank berechnet, in eine Skriptdatei gepackt (VIN_date.ini) und an den Diagnosetester ausgeliefert werden. Im Zuge dieser Arbeit wurde eine Software für den IoT-Diagnosetester entwickelt, die diese Initialdatei nimmt, die einzelnen Zeilen abarbeitet und zu jeder Zeile die Antwort einträgt. Damit kann der Diagnosetester diese 328 Gruppen anfragen und prüfen, ob die Steuergeräte physisch verbaut sind. Sollte ein Steuergerät verbaut sein, wird

4.4 Methode zur Steuergeräte- und Variantenidentifizierung

79

Abbildung 4.14: Datenbank-Abfrage möglicher Steuergeräte-InterfaceKombinationen es die Anfrage mit einem Pattern bestätigen. Diese Datei wird durch eine BatchDatei aufgerufen, mit der gleichzeitig das FCT-Modul auf allen Schnittstellen gestartet werden kann. Somit erhält die Cloud eine Datei je CAN-Bus, der am Messsystem angeschlossen war, sowie die Ergebnisdatei (VIN_date.pini) auf die Diagnoseabfragen. Hierbei ist besonders hilfreich, dass die Diagnosenachrichten ebenfalls in den FCT-Messungen enthalten sind. Für die Interpretation dieser Diagnose-Pattern-Datei wurde eine Software entwickelt, die aus den Antworten die zugehörigen Steuergeräte und deren Varianten bestimmt, diese als JavaScript Object Notation (JSON)-Datei auf dem Fileserver des OEM ablegt und einen Eintrag in der Datenbank des OEM erzeugt. Der rechte Zweig des Datenbankschemas aus Abbildung 4.11 besitzt mehr Abhängigkeiten. Zuerst wird in der Datei nach Varianten gesucht. Die Varianten werden dann an das Steuergerät angehängt. Jede Variante wird durch mehrere Pattern repräsentiert. Das spiegelt ebenfalls die Verwendung des ECU bei unterschiedlichen OEMs wieder. Die Pattern werden pro Variante gesucht und mit der entsprechenden Variante verknüpft. Durch die SQL-Abfrage, die in Listing 4.4 dargestellt ist, können beispielsweise die Pattern und Varianten des ECU „Diesel-Engine1“ angesehen werden.

80

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

Listing 4.4: SQL-Abfrage zur Auflistung aller Varianten mit den möglichen Pattern 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 |

SELECT [ECU].[DisplayName] AS ECU, [Variant].[DisplayName] AS Variant, [Pattern].[ExpectetValue] AS Pattern FROM [ DiagPattern ].[ dbo ].[ Variants] JOIN ECU ON Variants.Ecu_Id = ECU.Id JOIN Variant ON Variants. Variant_Id = Variant.Id JOIN Patterns ON Variant.Id = Patterns . Variant_Id JOIN Pattern ON Patterns . Pattern_Id = Pattern. Id WHERE [ECU].[DisplayName] = ’Diesel-Engine1’ ORDER BY [Variant ].[ DisplayName], [Pattern ].[ ExpectetValue ];

Die Abfrage muss sich die Daten aus fünf Tabellen zusammenstellen. Es ist ein explizites ECU abgefragt, das insgesamt 200 Pattern besitzt, verteilt auf 55 Varianten. In Abbildung 4.15 ist ein Auszug aus der Datenbank zu dieser Abfrage dargestellt.

Abbildung 4.15: Ein Auszug der Pattern eines Steuergerätes über mehrere mögliche Varianten In Abbildung 4.16 ist die vollständige Prozesskette dieser Methode dargestellt. Es ist zu erkennen, dass ODX-Dateien in eine Datenbank eingelesen werden müssen, woraufhin eine Identifikationsdatei erzeugt wird, die an beliebige Fahrzeuge

4.4 Methode zur Steuergeräte- und Variantenidentifizierung

ODX-Parser ISO 22901

81

ODX-Pattern-DB

Beliebig viele PDX- / ODX-Dateien StartupIdentifizierung VIN_Date.ini

GruppenName

Baudrate

Request-ID

Respons-ID

Message

engine-ECU

800

7E0

7E8

22 - F100

gear-ECU

500

7E1

7E9

22 - F100

climate-ECU

250

555

572

22 - F100

Mustererkennung

Private Cloud Institut

Identifiziert Datei im Fahrzeug ausführen VIN_Date.pini

GruppenName

Baudrate

Request-ID

Respons-ID

Message

Mustererkennung

engine-ECU

800

7E0

7E8

22 - F100

62 - F100 - xx

gear-ECU

500

7E1

7E9

22 - F100

62 - F100 - xx

climate-ECU

250

555

572

22 - F100

7F - F100

Fahrzeug-Struktur

VIN_Date.json

Private Cloud OEM

GruppenName

ECU

Variante

engine-ECU

engineA

engineA_20B

gear-ECU

gearC

gearC_21A

climate-ECU

none

none

ODX-PatternInterpreter

Abbildung 4.16: Vollständiger Diagnostik-Pattern-Ablauf der Methode

82

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

ausgeliefert werden kann. Wenn dieser Testablauf im Fahrzeug durchgeführt wurde, ist das KFZ identifiziert. Das Resultat kann zusammen mit den Pattern, die in der Datenbank gespeichert wurden, zurückgerechnet werden auf die ECUs und die vorliegende Variante. Dieses Resultat wird gespeichert und kann für verschiedene Aufgaben verwendet werden. Wie durch diese Prozesskette klar geworden ist, ist es so möglich, alle Steuergeräte, die im Fahrzeug sind, zu bestimmen. Ein praxisnahes Resultat zeigt Abbildung 4.18. Hier sind drei Dateien geöffnet, die linke Datei simuliert die Datenbank11 , die rechte Datei ist das Resultat des Testablaufes, welcher im Fahrzeug ausgeführt wurde12 . Aufgrund der markierten Zeile 16 ist ersichtlich, dass diese in eine Variante und dementsprechend in ein ECU umgerechnet werden kann. An dieser Stelle soll noch einmal auf Folgendes hingewiesen werden: Der reine Messwert, der hier umgerechnet wird, reicht nicht aus für eine sichere Identifizierung. Das wird deutlich über den Datenbankabzug aus Listing 4.5 verbunden mit der Ergebnisdarstellung aus Abbildung 4.17. Es ist zu erkennen, dass drei SQL-Abfragen durchgeführt werden, um die Vorgehensweise dieses Interpretationsalgorithmus zu beschreiben. Auf Grundlage der ersten Abfrage ist ersichtlich, dass wenn rein nach der „eindeutigen Zahl“ gesucht wird, dieses zu drei möglichen Steuergeräten führt. Wird die Abfrage erweitert um die möglichen Interfaces, die diese ECUs besitzen, wird schnell deutlich, dass bei der Erweiterung des Filterkriteriums um die ID des antwortenden ECU die Zuordnung eindeutig ist. Der Algorithmus wird wie folgt formuliert: Abhängig von der vom ECU zurückgemeldeten Zahl werden die möglichen Varianten bestimmt. Diese Varianten gehören wiederum zu einem ECU und dieses besitzt Schnittstellen, über die kommuniziert wurde, und mit diesen kann das ECU und dessen Variante eindeutig bestimmt werden. Damit ist der Interpretationsalgorithmus beschrieben und auch als Pseudocode 4.1 dargestellt. Tabelle 4.1 stellt die neue Methode abschließend dem bisher in der Fahrzeugentwicklung eingesetzten Stand gegenüber. Die Vorzüge der Methode liegen in der Geschwindigkeit und der Zuverlässigkeit. Die Nachteile liegen in dem vergleichsweise hohen Systemaufwand sowie dem Online-Zwang aufgrund der Zuständigkeit

11 Die

„global.pattern“-Datei war ein erster Entwurf, um die Korrektheit der Methode herzuleiten. alle Steuergeräte des Testfahrzeuges bekannt sind, werden nur die vorhandenen abgefragt, im Feld sieht das später umfangreicher aus.

12 Da

4.4 Methode zur Steuergeräte- und Variantenidentifizierung

83

Algorithm 4.1 Diagnose: (ODX)-Pattern-Interpretation 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18:

_inputData = ReadAscFile(Path) for each line ∈ _inputData do patterns = ReadDBPattern(ExpectedValue) for each pattern ∈ patterns do variants = ReadDBVariants() for each variant ∈ variants do ecus = ReadDBEcus() for each ecu ∈ ecus do interfaces = ReadDBinterfaces() for each bussystem ∈ interfaces do if 𝑏𝑢𝑠𝑠𝑦𝑠𝑡𝑒𝑚 == 𝑅𝑒𝑠𝐼𝑑𝐷𝑒𝑧 then ParsedResult = Add(ecu.ShortName, variant.Name) end if end for end for end for end for end for

der Cloud. Aber alles in allem bietet das neue System im Vergleich zum bestehenden mehr Vorzüge und sollte dem aktuellen vorgezogen werden. Im mittleren Bereich der Abbildung 4.18 ist der FCT dargestellt, in dem die Diagnosenachricht hervorgehoben und exemplarisch der Protokollstack beschrieben. Was aber mit diesem Ansatz nicht möglich ist, ist die Bestimmung der Netzwerknamen bzw. der Netzwerkbeschreibungsdateien. Das wird nun im anschließenden Kapitel analysiert und mit KI-Ansätzen gelöst. Listing 4.5: SQL-Abfrage zur Identifizierung des ECU und der Variante 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 |

-- 1 Abfrage -- Filtern nach dem gesuchten Wert SELECT [Pattern ].[ ExpectetValue] AS Pattern, [Variant ].[ DisplayName] AS Variant, [ECU].[DisplayName] AS ECU FROM [ DiagPattern ].[ dbo ].[ Pattern] JOIN [Patterns] ON [Patterns ].[ Pattern_Id ] = [Pattern ].[ Id] JOIN [Variant] ON [Variant ].[ Id] = [Patterns ].[ Variant_Id ] JOIN [Variants] ON [Variants ]. Variant_Id = [Variant ].[ Id] JOIN [ECU] ON [ECU].[Id] = [Variants ].[ Ecu_Id] WHERE ExpectetValue = 1063

84 10 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 |

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur ORDER BY [ECU].[DisplayName], [Variant].[DisplayName]; -- 2 Abfrage -- Filtern nach dem gesuchten Wert und erweitern um die Schnittstellen SELECT [Pattern ].[ ExpectetValue] AS Pattern, [Variant ].[ DisplayName] AS Variant, [ECU].[DisplayName] AS ECU, [Interface].[PhysReqId_Dez] AS REQ, [Interface].[PhysResId_Dez] AS RES, [Interface ].[ Name] AS Schnittstelle FROM [ DiagPattern ].[ dbo ].[ Pattern] JOIN [Patterns] ON [Patterns ].[ Pattern_Id ] = [Pattern ].[ Id] JOIN [Variant] ON [Variant ].[ Id] = [Patterns ].[ Variant_Id ] JOIN [Variants] ON [Variants ]. Variant_Id = [Variant ].[ Id] JOIN [ECU] ON [ECU].[Id] = [Variants ].[ Ecu_Id] JOIN [ Interfaces ] ON [ Interfaces ].[ Ecu_Id] = [ECU].[Id] JOIN [Interface ] ON [ Interface ].[ Id] = [ Interfaces ].[ Interface_Id ] WHERE ExpectetValue = 1063 ORDER BY [ECU].[DisplayName], [Variant].[DisplayName]; -- 3 Abfrage -- Filtern nach dem gesuchten Wert und der verwendeten Antwortadresse SELECT [Pattern ].[ ExpectetValue] AS Pattern, [Variant ].[ DisplayName] AS Variant, [ECU].[DisplayName] AS ECU, [Interface].[PhysReqId_Dez] AS REQ, [Interface].[PhysResId_Dez] AS RES, [Interface ].[ Name] AS Schnittstelle FROM [ DiagPattern ].[ dbo ].[ Pattern] JOIN [Patterns] ON [Patterns ].[ Pattern_Id ] = [Pattern ].[ Id] JOIN [Variant] ON [Variant ].[ Id] = [Patterns ].[ Variant_Id ] JOIN [Variants] ON [Variants ]. Variant_Id = [Variant ].[ Id] JOIN [ECU] ON [ECU].[Id] = [Variants ].[ Ecu_Id] JOIN [ Interfaces ] ON [ Interfaces ].[ Ecu_Id] = [ECU].[Id] JOIN [Interface ] ON [ Interface ].[ Id] = [ Interfaces ].[ Interface_Id ] WHERE ExpectetValue = 1063 AND [ Interface ].[ PhysResId_Dez] = 1421 ORDER BY [ECU].[DisplayName], [Variant].[DisplayName];

4.4 Methode zur Steuergeräte- und Variantenidentifizierung

85

Abbildung 4.17: Darstellung des Ergebnisses nach dem Diagnose-PatternAlgorithmus. Es ist zu erkennen, dass als Steuergerät der „BodyController_Rear“ in der Variante „bc_rear_e124“ ausgewählt wurde Aufgrundlage der KommunikationsschnittstellenAdresse „1549 zu 1421“ Tabelle 4.1: Vergleich der neuen Methode mit dem Stand der Entwicklung Kriterium Zuverlässigkeit (Wiederholbarkeit) Geschwindigkeit (Wie häufig, wie lange pro Durchlauf) Zuständigkeit (Wer muss es rechnen) Datengrundlage (Was ist die Grundlage) Systemabhängigkeit (Welche Hardware/Software wird vorausgesetzt) Kosten (einmalige und laufende) Summe („+=1“; „-=-1“)

Stand der Entwicklung

neue Methode

+

++

-

++

+

-

+

+

+

-

-

+

2

4

Abbildung 4.18: Darstellung der Herleitung der Steuergeräte-Identifikation auf Grundlage des FCT- und ODX-Ansatz

86 4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

4.5 Vergleich der Machine-Learning-Modelle

87

4.5 Vergleich der Machine-Learning-Modelle Wie im vorangegangenen Kapitel 4.4 bereits dargelegt, ist die Bestimmung der Steuergeräte essenziell. Daher soll die konventionelle Programmierung13 im Folgenden durch unterschiedliche KI-Ansätze plausibilisiert werden. Bei den Möglichkeiten einer Mustererkennung (Pattern Recognition), die eine KI zum Klassifizieren hat, ist die Datengrundlage, auf welcher das passiert, von maßgebender Bedeutung. Da wie bereits dargelegt, Fehler gleicher Herkunft (engl. Common Cause Errors) (CCE) durch diese Methode ausgeschlossen sind, nutzen die KI-Modelle für das Training und die Vorhersage die FCT-Messung. Sie nutzen somit die passive On-Board-Kommunikation, um basierend auf den Daten Klassifikationen durchzuführen. Die Steuergerätedetektion und die Variantenbestimmung verwendet die Off-Board-Diagnose und damit einen Testablauf, der von einem Diagnosetester aktiv durchgeführt wird. Wie der Datensatz für die KI-Modelle verarbeitet und aufbereitet wird, ist bereits durch Kapitel 4.3 beschrieben. Eine beispielhafte FCT-Messung besteht, wie in Abbildung 4.8 (Kapitel 4.3) zu erkennen ist, aus insgesamt fünf einzelnen CAN-Messungen. Die Häufigkeitsverteilung der ID ist nicht normalverteilt, es ist zu erkennen, dass kleine IDs häufiger auf dem Busmedium übertragen wurden als hohe IDs. In der Spalte „is_UDS“ ist ebenfalls zu erkennen, dass die 328 gesendeten Diagnosenachrichten nicht ins Gewicht fallen, wenn es um die Frage der Busauslastung geht [28]. Das getestete Fahrzeug besitzt 47 ECUs und durch die Spalte „target“ ist dargestellt, dass die Steuergeräte unterschiedlich viel kommunizieren. Zusammenfassend bedeutet das für die kommenden Betrachtungen, dass bei der Untersuchung die Metrik „Genauigkeit“ nicht angewendet werden kann, da die Daten keiner natürlichen Normalverteilung folgen. Es gibt in diesem Datensatz drei unterschiedliche Klassifikationsaufgaben: VCI: Bestimmung der Hardwareschnittstelle des angeschlossenen Bussystems. DIAG: Ist der Datenpunkt eine UDS-ODX-Nachricht oder nicht? ECU: Bestimmung des Steuergerätes, das den Datenpunkt gesendet hat. Welche

Steuergeräte befinden sich in dem KFZ?

13 Applikationsserver

mit Webserver, REST-API und verschiedene Software-APIs, die auf den Filesowie den Datenbankserver zugreifen.

88

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

4.5.1 VCI-Identifikation Bei der Erkennung der Fahrzeugschnittstellen bzw. der Detektion des verwendeten Bussystems hat es sich im Zuge der Untersuchungen herausgestellt, dass Algorithmen der statistischen Ähnlichkeit gegenüber klassischen ML-Algorithmen bessere Ergebnisse liefern. Jedoch bedarf es hier wieder an Vorbedingungen. Ein Netzwerk besteht aus einer CAN-Busleitung, an die unterschiedlich viele Teilnehmer mit einer Stichleitung angeschlossen sind, mitunter auch das Messgerät, welches zuhört. Jeder Teilnehmer bzw. ECU sendet gewisse Signale zyklisch auf dem Medium, damit die anderen, die sich bspw. für den Sensorwert (z. B. Motordrehzahl oder -temperatur) interessieren, diesen bekommen. Für jedes Netzwerk gibt es unterschiedliche Beschreibungsdateien, bspw. ARXML und DBC, in denen festgehalten wird, welches ECU welche ID in welchem Zyklus bzw. aufgrund welches Ereignisses sendet. Damit kann die folgende Hypothese formuliert werden: Jedes CAN-Netzwerk ist über die vorkommenden IDs einzigartig und kann zurückgerechnet werden auf den Netzwerknamen und auf die Beschreibungsdatei. Als Vorbedingung für dieses System wird in einem ersten Schritt erneut eine Datenbank designt und mit Daten befüllt. Die verwendeten Daten sind die ARXMLDateien, da in diesen immer der Netzwerkname angegeben ist. Des Weiteren ist definiert, welche ECU-Gruppen an dem Bus angeschlossen sein können und welche ECU-Gruppe welchen Messwert sendet bzw. empfängt. Auf der Grundlage der Namen der Messwerte können durch String-Matching-Algorithmen die DiagnoseID der einzelnen ECU-Gruppen bestimmt werden. Hierbei wird im Namen des Messwertes nach einer Kombination einer ECU-Group mit unterschiedlichen Abwandlungen des Wortes Diagnose gesucht. Wenn so ein Messwert identifiziert ist, wird seine Message-ID als Request- oder Response-ID bei der ECU-Group eingetragen. Abbildung 4.19 zeigt das Datenbankschema, das in dieser Arbeit definiert und verwendet wird. Im mittleren unteren Bereich sind erneut die Tabellen ChangeLog und Log zu erkennen. Diese übernehmen auch hier die gleiche Aufgabe wie bei der Pattern-DB, dass bedeutet das Protokollieren von allen Datenbankänderungen bzw. das Informieren eines Entwicklers, wenn ein relevanter Fehler im System erkannt wurde. Es ist ebenfalls zu erkennen, dass beim Einlesen der Datei der Speicherort auf dem Fileserver abgelegt wird über die Tabellen Folder und File. So weit ist das Konzept gleich zu der Pattern-DB aus Kapitel 4.4. Die beiden oberen Tabellen Bus und ECU-Groups repräsentieren die später gesuchten Klassifikationsergebnisse. Die

4.5 Vergleich der Machine-Learning-Modelle

89

Abbildung 4.19: Das Datenbankschema der Diagnose-Cloud-Datenbank zum Einlesen der ARXML-Dateien rechte Tabelle Service enthält alle möglichen Messwerte, die in allen eingelesenen ARXML-Dateien vorhanden waren. Es ist zu erkennen, dass einerseits die Namen und die IDs ausgelesen werden und ein String-Matching-Algorithmus noch implementiert wurde, um Diagnosenachrichten zu erkennen und zu markieren. Erkannte Diagnosenachrichten werden des Weiteren noch in der Tabelle ECU-Groups mit den Steuergeräte-IDs verknüpft. Diese drei Tabellen wurden zur Einhaltung der 2NF abgespalten und können damit redundanzfrei eingelesen werden. Durch die Verbindungstabellen Network, Connect, Send und Receive werden die Daten in der Datenbank verknüpft und somit verschiedene Erkennungen ermöglicht. Als erstes

90

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

ist die Erkennung des Netzwerkes zu nennen und damit verbunden das Schlussfolgern des Bussystem-Namens bzw. der ARXML und als zweites auf Grundlage der Kommunikation das Schlussfolgern der Steuergerätegruppe (ECU-Group). An der Netzwerk-Tabelle ist zu erkennen, dass ein Netzwerk genau zu einem Bussystem und einer ARXML-Datei gehört, jedoch viele Verbindungen besitzen kann. Eine Verbindung wiederum gehört genau zu einer ECU-Gruppe bzw. zu einem Netzwerk, besitzt jedoch viele Sende- bzw. Empfangende-Messwerte. Durch diese Abhängigkeiten kann die ARXML-Datei eingelesen und die gestellten Herausforderungen bewältigt werden, ohne dass alle Daten redundant vorliegen. Somit sind auch bei dieser DB wieder die Regeln der 2NF eingehalten. Im Folgenden werden die Daten genauer betrachtet, um herzuleiten, wie die Modelle erstellt bzw. trainiert werden. Da die Datenbank unabhängig von Hardwareabhängigkeiten erstellt und erweitert werden kann, ist die Pinbelegung des verwendeten Kabelsatzes, mit dem die Daten im Trainings- und Testfahrzeug erhoben wurden, in Tabelle 4.2 dargestellt. Tabelle 4.2: Anschlussbelegung des Kabelbaum, mit dem gemessen wird Busname Freier-CAN Periphery-CAN Freier-CAN-FD Freier-CAN Hybrid-CAN HMI-CAN Headunit-CAN PT Sensor-CAN Body-CAN Powertrain-CAN Engine-CAN Diagnose-CAN

Nummer Kabelbaum 0 1 2 3 4 5 6 7 8 9 10 11

Im Trainingsfahrzeug waren fünf CAN-Netzwerke14 mit dem Messsystem verbunden und im Testfahrzeug nur der Diagnose-CAN über die OBD-II-Schnittstelle. Durch diese Festlegung auf die möglichen Netzwerke, die mit dem IoT-Diganosetester maximal kontaktiert werden können, wurden 36 ARXML-Dateien zu neun unterschiedlichen Netzwerken in die Datenbank eingepflegt und für das Training der 14 5=HMI-CAN,

8=Body-CAN, 9=Powertrain-CAN, 10=Engine-CAN, 11-Diagnose-CAN

4.5 Vergleich der Machine-Learning-Modelle

91

KIs verwendet. Durch das SQL-Statement aus Listing 4.6 wird ein Überblick über die eingelesenen Bussysteme, ECU-Gruppen und unterschiedlichen Messwerte abgefragt werden. Listing 4.6: SQL-Abfragen zur Auflistung aller Bussysteme, Steuergeräte und Messwerte 01 | 02 |

SELECT * FROM [DiagCloud].[dbo ].[ Bus] ORDER BY Name;

04 | 05 |

SELECT * FROM [DiagCloud].[dbo ].[ ECU_Groups] ORDER BY ReqDiagId;

07 | 08 |

SELECT * FROM [DiagCloud].[dbo ].[ Service] ORDER BY MessageId;

Da das Tabellendesign hier Duplikate verhindert, sind alle Daten Unikate, jedoch durch komplexere Abfragen der Schein entstehen kann, als lägen redundante Daten vor. Aber dies wird im Folgenden noch näher dargestellt. In Abbildung 4.20 sind die Namen der Bussysteme mit den zugeordneten IDs dargestellt. Somit ist bewiesen, dass die Datenbank unabhängig von dem vorgestellten/verwendeten Kabelsatz ist15 .

Abbildung 4.20: Alle Bussysteme, die aktuell unterstützt werden In diesen neun Bussystemen werden insgesamt 90 ECU-Groups verwendet. Diese 90 ECU-Groups kommen auf 2187 unterschiedliche Messwerte, die die Steuergeräte untereinander austauschen. Auf dieser Grundlage können für alle neun Bussysteme, die aus unterschiedlich vielen ARXML-Dateien eingelesen wurden, individuelle 15 Die

Bussysteme wurden alphabetisch sortiert eingelesen.

92

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

„Fingerabdrücke“ erstellt werden. Jeder gemessene CAN kann daraufhin mit denen in der Datenbank verglichen werden und hiermit der ähnlichste ermittelt werden. Über die Verbindung, die die Tabelle Network zwischen den Tabellen Bus, File und Connect herstellt, kann der Bussystemname und die ARXML-Datei berechnet werden. Das SQL-Listing 4.7 zeigt, wie alle möglichen Netzwerkkombinationen abgefragt werden können. Listing 4.7: SQL-Abfrage zur Auflistung aller Netzwerkverbindungen mit den möglichen Bussystemnamen und ARXML-Namen 01 | 02 | 03 | 04 | 05 |

SELECT [Bus].[DisplayName] AS BusName, [File].[Name] AS ArxmlName FROM [DiagCloud].[dbo ].[ Network] JOIN [Bus] ON [Network].[Bus_Id] = [Bus].[ Id] JOIN [ File ] ON [Network].[File_Id ] = [ File ].[ Id] ORDER BY ArxmlName, BusName ASC;

Das Resultat dieser Abfrage ist in Abbildung 4.21 dargestellt. Es ist zu erkennen, dass der Bussystemname mit unterschiedlichen ARXMLDateien verknüpft ist. Auf dieser Basis wird später noch gezeigt, wie in einem ersten Schritt der Busname bestimmt wird und darauf aufbauend in einem zweiten dann die konkrete ARXML-Datei. Dies ist wichtig, um die Messung bestmöglich zu interpretieren und in eine MDF4-Datei umzuwandeln. Die Zuordnung des Busnamen und der passenden ARXML ist zustandslos und kann so jederzeit erfolgen. Um den Ablauf ein wenig genauer zu verstehen, ist es im Folgenden relevant zu wissen, wie viele Verbindungen ein Netzwerk hat und wenn ein ECU aus diesen Verbindungen heraus genommen wird, in wie vielen Netzwerken es Teilnehmer ist. Um diese Frage zu beantworten, ist die SQL-Abfrage in Listing 4.8 abgedruckt. Listing 4.8: SQL-Abfrage zur Auflistung aller Verbindungen eines Steuergerätes mit den möglichen Bussystemnamen und ARXML-Namen 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 |

-- 1 Abfrage -- unterstuetzte Steuergeraetegruppen eines Netzwerkes SELECT [ECU_Groups].[DisplayName] AS EcuGroupName, [ECU_Groups].[ReqDiagId] AS DiagReq, [ECU_Groups].[ResDiagId] AS DiagRes, [Bus].[DisplayName] AS BusName, [File].[Name] AS ArxmlName FROM [DiagCloud].[dbo ].[ Connect] JOIN [ECU_Groups] ON [Connect].[ECUGroups_Id] = [ECU_Groups].[Id] JOIN [Network] ON [Connect].[Network_Id] = [Network].[Id] JOIN [Bus] ON [Network].[Bus_Id] = [Bus].[ Id] JOIN [ File ] ON [Network].[File_Id ] = [ File ].[ Id] WHERE [Bus].[DisplayName] = ’ENGINE’

4.5 Vergleich der Machine-Learning-Modelle

Abbildung 4.21: Mögliche Netzwerke, die eine KI identifizieren kann 10 |

ORDER BY EcuGroupName, ArxmlName ASC;

12 | 13 | 14 |

-- 2 Abfrage -- Netzwerkteilnehmer einer unterstuetzten Steuergeraetegruppen SELECT [ECU_Groups].[DisplayName] AS EcuGroupName, [ECU_Groups].[ReqDiagId] AS DiagReq, [ECU_Groups].[ResDiagId] AS DiagRes, [Bus].[DisplayName] AS BusName, [File].[Name] AS ArxmlName FROM [DiagCloud].[dbo ].[ Connect] JOIN [ECU_Groups] ON [Connect].[ECUGroups_Id] = [ECU_Groups].[Id] JOIN [Network] ON [Connect].[Network_Id] = [Network].[Id] JOIN [Bus] ON [Network].[Bus_Id] = [Bus].[ Id] JOIN [ File ] ON [Network].[File_Id ] = [ File ].[ Id] WHERE [ECU_Groups].[DisplayName] = ’Engine1’ ORDER BY ArxmlName ASC;

15 | 16 | 17 | 18 | 19 | 20 | 21 |

In Abbildung 4.22 ist das Resultat dargestellt.

93

94

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

Abbildung 4.22: Alle Verbindungen eines Netzwerkes bzw. Netzwerke in denen ein ECU-Gruppe-Teilnehmer ist. Es ist zu erkennen, dass der CAN-Bus „ENGINE“ insgesamt maximal zwei Steuergerätegruppen enthalten kann. Zudem ist dargestellt, dass das Motorsteuergerät Teilnehmer an drei CAN-Bussystemen ist. Somit ist das Motorsteuergerät „Engine1“ höchstwahrscheinlich ein Gateway, da es Teilnehmer in drei Netzwerken ist. Um den Fingerabdruck eines Netzwerkes zu berechnen, muss die SQL-Abfrage aus Listing 4.9 durchgeführt werden. Dabei werden alle IDs abhängig des gewünschten Netzwerkes aufgelistet. Listing 4.9: Auflistung aller Messwerte-IDs eines Bussystems mit den möglichen Bussystemnamen und ARXML-Namen 01 | 02 | 03 | 04 | 05 |

SELECT COUNT([Service].[MessageId]) AS AnzahlID, [Service ].[ MessageId] AS MesswertID, [ECU_Groups].[DisplayName] AS EcuGroupName FROM [DiagCloud].[dbo ].[ Send] JOIN [Service] ON [Send].[ Service_Id ] = [Service ].[ Id] JOIN [Connect] ON [Send].[Connect_Id] = [Connect].[Id] JOIN [ECU_Groups] ON [Connect].[ECUGroups_Id] = [ECU_Groups].[Id]

4.5 Vergleich der Machine-Learning-Modelle 06 | 07 | 08 | 09 | 10 |

95

JOIN [Network] ON [Connect].[Network_Id] = [Network].[Id] JOIN [Bus] ON [Network].[Bus_Id] = [Bus].[ Id] WHERE [Bus].[DisplayName] = ’ENGINE’ AND [Service].[MessageId] < 2048 GROUP BY [Service ].[ MessageId], [ECU_Groups].[DisplayName] ORDER BY [Service ].[ MessageId] ASC;

Ein Auszug aus dem Resultat ist in Abbildung 4.23 dargestellt.

Abbildung 4.23: Fingerabdruck des Engine-CAN basierend auf den unterschiedlichen Message-IDs Es ist zu erkennen, dass unterschiedliche IDs unterschiedlich oft verknüpft sind. Das kommt daher, dass Messwerte in einer ARXML-Datei neu hinzukommen oder entfernt werden. Zudem ist zu erkennen, welche ECU-Gruppe das sendende Steuergerät der Nachricht ist. Damit wird festgehalten, das die Daten, die zur Bestimmung des Bussystems verwendet werden, einer Nominalskala16 unterliegen und einen eindimensionalen Vektor bilden. Daher sollen Algorithmen untersucht 16 Eine

nominale Skala zeichnet sich dadurch aus, dass jeder annehmbare Wert in keinem Verhältnis zu den anderen steht (sortiert, aber nicht geordnet werden kann). Eine ordinale Skala ist bspw. die Notenskala, hier ist eine 1,0 „besser“ als eine 1,3, wobei die Notenskala ebenfalls als eine

96

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

werden, die Kennzahlen ausgeben basierend auf einem Vergleich der ID-Verteilung der Messung mit den Bussystemen der Datenbank. Dabei kommen prinzipiell drei Standardverfahren der Narrow-KI in Betracht. Korrelations-Koeffizent 𝜌 : Es wird die Kovarianz ins Verhältnis zur Standard-

abweichung der Messkurve und jedes DB-Bussystems gesetzt. Dabei kommt ein Wert heraus, der auf einer Skala von −1 → 0 → 1 angibt, wie die beiden im Verhältnis stehen. Hierbei bedeutet 0, dass kein Zusammenhang besteht und 1 sowie -1 geben die maximale Korrelation (Kohärent) an. Die Gleichung Gl. 4.1 zeigt die mathematische Beschreibung des Korrelations-Koeffizent, es ist zu erkennen, dass die Vektoren a und b die gleiche Dimension haben müssen. Jaccard-Koeffizient 𝐽 : Hier werden die Mengen (vorkommende einzigartige IDs) der Messkurve und jedes DB-Bussystems ins Verhältnis gesetzt. Dabei kommt ein Wert heraus, der auf einer Skala von 0 → 1 angibt, wie die beiden im Verhältnis stehen. Die Gleichung Gl. 4.2 zeigt die mathematische Beschreibung des Jaccard-Koeffizienten. Hier wird die Schnittmenge bestimmt und durch die Vereinigungsmenge geteilt. Es ist zu erkennen, dass die Vektoren a und b nicht die gleiche Dimension haben müssen. Kosinus-Koeffizient 𝑐𝑜𝑠 (𝜙) : Es wird der Winkel zwischen zwei Vektoren der Messkurve und jedes DB-Bussystems beschrieben. Der Koeffizient wird über das Skalarprodukt und die euklidische Länge definiert. Dabei kommt ein Wert heraus, der auf einer Skala von 0 → 𝜋2 angibt, wie die beiden Vektoren im Verhältnis stehen. Die Gleichung Gl. 4.3 zeigt die mathematische Beschreibung des KosinusKoeffizienten. Es ist zu erkennen, dass die Vektoren a und b die gleiche Dimension haben müssen. Damit diese unterschiedlichen Koeffizienten miteinander vergleichbar sind, müssen diese normiert werden. Das bedeutet sie müssen auf eine Vektorsumme von 1 skaliert werden. Bei den neuronalen Netzen wird für diese Aufgabe ein Softmax-Layer eingesetzt. In der Narrow-KI ist das der Korrigierte-Kontingenz-Koeffizient, der in Gleichung Gl. 4.4 dargestellt ist. Es werden alle Ergebnisse zu allen Netzwerken der Datenbank betragsmäßig aufsummiert und daraufhin jeder einzelne durch diese Summe geteilt. Das Resultat ist, dass alle Koeffizienten eine Gesamtwahrscheinlichkeit von 100 % ausgeben und damit die Algorithmen verglichen werden können. Die Untersuchung kann aufgrund von Listing B.1 im Anhang nachvollzogen werden. Intervallskala betrachtet werden kann. Eine klassische Intervallskala ist die Abfrage in einem Fragebogen (Auf einer Skala von 0-10 wie fühlen Sie sich?).

4.5 Vergleich der Machine-Learning-Modelle

97

𝑛

(𝑎 𝑖 − 𝜇 𝑎 ) · (𝑏 𝑖 − 𝜇 𝑏 ) 𝜎𝑎 · 𝜎𝑏 a∩b 𝐽 (𝑎, 𝑏) = a ∪b 𝑛 𝑎 · 𝑏 a·b 𝑖 𝑖=1 𝑖 = 𝑐𝑜𝑠(𝜙) = 𝑛 𝑛

a

b

2 2 𝑖=1 (𝑎 𝑖 ) · 𝑖=1 (𝑏 𝑖 ) 𝐶𝑜𝑣(a, b) 𝜌= = 𝜎𝑎 · 𝜎𝑏

1 𝑛−1

·

𝑖=1

𝐶 𝑘𝑜𝑟𝑟 =

𝐶 𝐶𝑠𝑢𝑚

Gl. 4.1 Gl. 4.2 Gl. 4.3

Gl. 4.4

mit 𝜌 a b 𝑛 𝐶𝑜𝑣 (a, b) 𝜇 𝜎 𝐽 (a, b) 𝑐𝑜𝑠 (𝜙) 𝜙 𝐶 𝑘𝑜𝑟𝑟 𝐶 𝐶𝑠𝑢𝑚

Korrelations-Koeffizient Messvektor DB-Vektor Anzahl der Daten im Vektor Kovarianz Arithmetischer-Mittelwert Standardabweichung Jaccard-Koeffizient Kosinus-Koeffizient Winkel zwischen den Vektoren Korrigierter-Kontingenz-Koeffizient Koeffizient vor Normierung Summe aller Koeffizienten vor Normierung

In Abbildung 4.24 ist die prinzipielle Verteilung der CAN-IDs der in der Datenbank eingelesenen Netzwerke dargestellt. Es ist zu erkennen, dass kleine IDs von fast allen Netzwerken verwendet werden, bei größeren ist das jedoch nicht der Fall und damit individueller. Weiterhin ist zu erkennen, dass auf Grundlage der IDs tatsächlich eine Art Fingerabdruck eines Netzwerkes abgebildet werden kann. In Abbildung 4.25 ist das Ergebnis einer Netzwerkidentifikation dargestellt. Es wird eine Messung mit jedem in der Datenbank möglichen Netzwerk auf Grundlage der drei eingeführten Algorithmen verglichen. In der oberen Grafik der Abbildung 4.25 lässt sich bereits optisch ablesen, dass hier an einem Diagnose-CAN

98

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

Abbildung 4.24: Alle Fingerabdrücke der Datenbank-Bussysteme (Busnummer der Datenbank = 1) gemessen wurde, aufgrund der Tatsache, dass die rot dargestellte Messkurve vollständig verdeckt ist von der grauen DatenbankNetzwerk-Kurve. Im unteren Teil der Abbildung 4.25 sind die Ähnlichkeitsmaße der Messung zu jedem Datenbank-Netzwerk dargestellt. Es ist zu erkennen, dass alle drei Algorithmen das richtige Netzwerk vorhergesagt haben. Die Performanz des Korrelations-Koeffizienten ist am besten, zwischen den anderen beiden kann noch keine Aussage getroffen werden. Aber da auf dieser Grundlage die Messung als DIAGNOSTICS-CAN richtig identifiziert wurde, soll nun die ARXML-Datei bestimmt werden. Dabei sind in Abbildung 4.26 die in der Datenbank vorhandenen Dateien dargestellt. Es ist zu erkennen, dass zwischen sechs Dateien entschieden werden muss. Weiterhin wird durch diese Abbildung ersichtlich, dass es im Folgenden auf kleine Veränderungen ankommt. Teilweise wurde nur ein Service neu in die ARXML aufgenommen und diesen minimalen Unterschied müssen nun die Algorithmen identifizieren und richtig zuordnen. Die Dateien sind aufsteigend sortiert, damit

4.5 Vergleich der Machine-Learning-Modelle

99

Abbildung 4.25: Vergleich der Korrelations-Koeffizienten an den Bussystemen der Datenbank zur Bussystem-Identifikation einer Fahrzeugmessung ist Index = 0 die älteste und Index = 5 die neueste ARXML-Datei, die für dieses Bussystem vorliegt. In Abbildung 4.27 ist erneut der Vergleich der Algorithmen dargestellt, dieses Mal um die richtige ARXML-Datei zu identifizieren. Hier kann im oberen Teil der Abbildung optisch wahrgenommen werden, dass die Dateien 0 → 2 nicht möglich sind, da hier rote Bereiche vorkommen. Das verwendete Fahrzeug ist aus dem Jahr 2019 und die Datei mit dem Index = 3 ist tatsächlich richtig. Beim Betrachten des unteren Abschnittes der Abbildung fällt auf, dass der Jaccard-Algorithmus die Datei mit dem Index = 0 identifiziert hat, damit falsch liegt und somit für diesen Anwendungsfall nicht geeignet ist. Der KorrelationsKoeffizient liefert erneut das beste Ergebnis und wird damit ausgewählt für die VCIund ARXML-Identifikation, da dieser Algorithmus unter schwierigsten Bedingungen zum richtigen Ergebnis gekommen ist. Der Kosinus-Koeffizient hat ebenfalls alles richtig identifiziert und kann für das Anwendungsgebiet empfohlen werden.

100

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

Abbildung 4.26: Alle Fingerabdrücke der Datenbank ARXML eines Bussystems Beide Algorithmen benötigen eine One-Hot-Codierung17 der Eingangsdaten und die verbleibenden Rechenoperationen sind vergleichbar. In Tabelle 4.3 sind die Algorithmen abschließend gegenübergestellt. Wie bereits erwähnt, schließt der Korrelations-Koeffizient (im Anhang dargestellt durch Listing B.1) am besten ab. Der Jaccard-Koeffizient (im Anhang dargestellt durch Listing B.1) ist für die untersuchte Anwendung nicht zu empfehlen. Der Kosinus-Koeffizient (im Anhang dargestellt durch Listing B.1) belegt den zweiten Platz und hätte ebenfalls alles richtig identifiziert.

17 Es

wird ein Array angelegt, das so lange ist wie der maximale Wert. (Im Fall von Standard-CAN 0 → 2047.) Kommt der Identifier in der Messung bzw. DB-Netzwerk oder DB-ARXML vor, wird an der entsprechenden Stelle im Null-Vektor eine Eins eingetragen.

4.5 Vergleich der Machine-Learning-Modelle

101

Abbildung 4.27: Vergleich der Korrelations-Koeffizienten an den ARXML der Datenbank zur ARXML-Identifikation einer Fahrzeugmessung

4.5.2 DIAG-Identifikation Bei der Erkennung der Diagnosenachrichten hat sich gezeigt, dass der Datensatz des untersuchten OEM linear separierbar ist. Das bedeutet das Modell der Support Vector Machine (SVM) mit linearem Kernel liefert mit geringem Trainingsaufwand die besten Ergebnisse, ohne sich zu stark an den Trainingsdatensatz anzupassen (Overfitting). Die Idee ist, dass der ID, den ein ECU verwendet, um Diagnosenachrichten auszutauschen sich am oberen Ende des möglichen Zahlenraumes   (0 → 211 − 1 = 2047) befindet. Zusätzlich wird in der Payload das UDS-Protokoll verwendet. Damit kann folgende Hypothese formuliert werden: Jede Diagnosenachricht verwendet eine hohe ID für die nieder-priorisierte Kommunikation und hat in der Payload signifikante Unterschiede zum reinen DoCANISOTP-Standard der On-Board-Kommunikation und ist daher detektierbar und somit separierbar.

102

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

Tabelle 4.3: Vergleich der Korrelations-Koeffizienten zur Identifizierung der Bussysteme Kriterium Zuverlässigkeit (Wiederholbarkeit) Geschwindigkeit (Wie häufig, wie lange pro Durchlauf) Zuständigkeit (Wer muss es rechnen) Datengrundlage (Was ist die Grundlage) Systemabhängigkeit (Welche Hardware/Software wird vorausgesetzt) Kosten (einmalige und laufende) Summe („+=1“; „-=-1“)

Korrelations- JaccardKoeffizient Koeffizient

KosinusKoeffizient

++

-

+

+

+

+

o

o

o

o

+

o

o

o

o

o

o

o

3

1

2

Hierzu werden drei Standard-Verfahren der Supervised-Learning-ML-Algorithmen anhand eines Mittelklasse-Hybrid Kombi-Fahrzeuges trainiert. Ein MittelklasseDiesel-SUV-Fahrzeug wird verwendet, um zu überprüfen, ob die trainierten Modelle mit unbekannten Daten umgehen und verallgemeinern können. Beide Messungen wurden am Diagnose-CAN des jeweiligen Fahrzeuges durchgeführt, als die Diagnose-Pattern-Messung die 328 ECU-Gruppen kontaktiert hat, um das Fahrzeug anzutrainieren. Dabei ist jeweils eine 10 min FCT-Messung entstanden, die für diese Analyse geeignet ist. KNeighborsClassifier: Der K-Nearest-Neighbors-Algorithmus ist häufig der

Startpunkt einer Datenuntersuchung. Hier werden beispielsweise in einem zweidimensionalen Diagramm (Feature-Raum) drei Gruppen (Klassifikation-Ziel) gebildet. Wenn nun ein neuer Messwert klassifiziert werden soll, zu welcher der Klassen er am wahrscheinlichsten gehört, dann wird über die vektorielle Distanz die Knächsten Nachbarn berechnet und die Gruppe, die häufiger vorkommt, bestimmt die Zugehörigkeit des neuen Messwertes („K“ sollte ungerade gewählt werden, damit keine Pattsituation möglich ist). In der Abbildung 4.28 ist das Prinzip am

4.5 Vergleich der Machine-Learning-Modelle

103

Standardbeispiel Iris-Datensatz grafisch dargestellt. Dieser Algorithmus ist schnell trainiert, jedoch dauert die Bestimmung relativ lange, da hier immer die euklidische Distanz zu jedem Trainings-Datenpunkt im Hyperraum berechnet werden muss. Da eine schnelle Vorhersage (prediction) in vielen Fällen wichtiger ist als ein schnelles Training, scheidet dieser Algorithmus häufig aus. RandomForestClassifier: Der Random Forest beruht auf dem klassischen Entscheidungsbaum. Im Unterschied zum Entscheidungsbaum muss der Random Forest nicht den vollständigen Datensatz auswendig lernen. Hier werden mehrere Entscheidungsbäume (1000, wenn nichts anderes dem Hyperparameter übergeben wird), trainiert. Die Tiefe der Entscheidungsbäume kann festgelegt werden, im Normalfall ist die Tiefe zwei Ebenen. Eine Vorhersage eines neuen Messwertes findet auf die Weise statt, dass die Klasse ausgewählt wird, der am meisten Bäume zustimmen. Die Rechenzeit von diesen „Wäldern“ ist in der Vorhersage immer konstant und kann in Embedded-Systemen zuverlässig eingesetzt werden. Ein Random Forest wird häufig bei komplexen Anwendungen mit großem Feature-Raum eingesetzt. LinearSupportVectorClassifier: Der Algorithmus der SVM mit linearem Kernel beruht darauf, dass die Gleichung einer Geraden im Hyperraum gesucht wird, die die Daten bestmöglich aufteilt. Eine Gerade kann immer gefunden werden, es ist nur zu untersuchen, ob damit die Daten bestmöglich separiert werden. Im Beispiel aus Abbildung 4.28 müssen drei Klassen unterschieden werden und somit muss der Algorithmus zwei Geradengleichungen berechnen und in das Schaubild legen. Das Trennen der blauen von den anderen Datenpunkten scheint vergleichbar einfach, wohingegen das Trennen der roten von den grünen Datenpunkten nicht ohne Fehler möglich ist18 . Damit ist auch offensichtlich, dass vom Rechenaufwand her das Lösen von zwei Geradengleichungen für einen neuen Datenpunkt der schnellste Algorithmus vorliegt bei der Vorhersage und somit in der Anwendung. Die Messreihen der beiden Fahrzeuge können, wie in Kapitel 4.3 beschrieben, eingelesen und somit den soeben eingeführten Algorithmen zugänglich gemacht werden. Doch bevor die Modelle trainiert und überprüft werden, wie gut die Verallgemeinerung ist, müssen die Daten noch skaliert werden. Die Algorithmen Linear-SVM und K-Neighbors funktionieren zuverlässiger, wenn die Daten einer Normalverteilung oder einer Intervallverteilung folgen. Für die hier dargestellten Ergebnisse wurde

18 Zumindest,

solange der Kerneltrick nicht angewendet wird. Es handelt sich hierbei um eine Dimensionsänderung, in aller Regel eine Erhöhung, mehr hierzu in der Literatur[21]

104

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

Abbildung 4.28: Standard-Beispiel der Separierbarkeit von Datenklassen auf Grundlage des IRIS-Blumendatensatzes die Intervallverteilung gewählt. Somit ist jede Spalte (Feature) auf eine Skala von 0 bis 1 normiert. Jetzt müssen noch die erwarteten Ergebnisse eingeordnet werden. Es ist zu erwarten, dass bei 17.261 Datenpunkten, von denen nur 328 Diagnosenachrichten sind, eine KI bzw. ein Mensch, der immer vorhersagt, dass der aktuelle Datenpunkt keine Diagnosenachricht ist, hier vergleichsweise oft recht haben wird. Die Zufallswahrscheinlichkeit für diesen Fall liegt bei 𝑃 = 17261−328 = 0, 981 ≈ 98,1 %. Tatsächlich 17261 kommen alle drei Modelle auf eine Trainingsgenauigkeit von 100 %, somit scheidet diese Metrik aus und es wird die Konfusionsmatrix zusammen mit dem F1-Wert verwendet. Eine Konfusionsmatrix besteht aus vier Feldern, denen die Vorhersage des Datenpunktes entsprechen kann. Die Vorhersage kann „Richtig“ oder „Falsch“ sein und die Zuordnung kann „Positiv“ oder „Negativ“ sein. Auf die Anwendung bezogen gibt es das Feld 0 ⇔ 0 ist es DIAG? ⇒ 𝐹 𝐴𝐿𝑆𝐶𝐻 Negativ (FN). Dieser Gruppe werden erwartungsgemäß 16.933 Datenpunkte entsprechen. Das Feld 1 ⇔ 1 ist es DIAG? ⇒ 𝑅𝐼𝐶𝐻𝑇 𝐼𝐺 POSITIV (RP) bestimmt die 328 Datenpunkte, die gesucht werden. Bei den beiden anderen Feldern liegen nun Falschdetektionen vor. Ein Eintrag im Feld 1 ⇔ 0 ist es DIAG? ⇒ 𝑅𝐼𝐶𝐻𝑇 𝐼𝐺 Negativ (RN)

4.5 Vergleich der Machine-Learning-Modelle

105

beschreibt, dass der Algorithmus schlussfolgert, dass es eine Diagnosenachricht ist, aber in Wirklichkeit liegt er daneben. Ein Eintrag im Feld 0 ⇔ 1 ist es DIAG? ⇒ 𝐹 𝐴𝐿𝑆𝐶𝐻 Positiv (FP) beschreibt, dass der Algorithmus schlussfolgert, dass es keine Diagnosenachricht ist, aber in Wirklichkeit liegt er auch hier daneben. Welcher der beiden Fehlerfälle für die Anwendung schlechter ist, muss abgewogen werden, da prinzipiell die Relevanz nach Gleichung Gl. 4.5 oder die Sensitivität nach Gleichung Gl. 4.5 optimiert werden kann19 . Auf Grundlage der Konfusionsmatrix kann aber auch eine Kennzahl berechnet werden, mit der es möglich ist zu erkennen, ob ein Algorithmus besser oder schlechter für den Anwendungsfall geeignet ist. Diese Kennzahl ist der 𝐹1 -Wert, der in Gleichung Gl. 4.7 dargestellt ist.

𝑅𝑃 𝑅𝑃 + 𝐹𝑃 𝑅𝑃 Sensitivität = 𝑅𝑃 + 𝐹 𝑁 𝑅𝑃 F1 = 𝑅𝑃 + 𝐹 𝑁 2+𝐹 𝑃 Relevanz =

Gl. 4.5 Gl. 4.6 Gl. 4.7

In Abbildung 4.29 ist die Konfusionsmatrix dargestellt. In der oberen Hälfte der Abbildung ist für jeden hier untersuchten Algorithmus eine Konfusionsmatrix der Trainingsdaten dargestellt20 . Im unteren Bereich der Abbildung ist das gleiche noch einmal erkennbar, nur wurden hier die Testdaten verwendet um festzustellen, ob die Modelle generalisieren. Es ist zu erkennen, dass alle Modelle im Training gute Ergebnisse erzielt haben. Durch das Testfahrzeug wird aber deutlich, dass Random Forest und K-Neighbors in der Überanpassung der Trainingsdaten sind. Das lässt sich wie folgt erklären. Das Modell des K-Neighbors ist wahrscheinlich nicht komplex genug und tendiert dazu, immer auf „ist keine Diagnosenachricht“ zu raten (𝐹1 = 0.471, 𝑅𝑒𝑙𝑒𝑣𝑎𝑛𝑧 = 0.308, 𝑆𝑒𝑛𝑠𝑖𝑡𝑖𝑣𝑖𝑡 = 1.0). Bei dem Random Forest zeigt sich ein anderes Bild. Das Modell ist zu komplex und hat die Trainingsdaten auswendig gelernt und sich dabei zu stark angepasst (𝐹1 = 0.809, 𝑅𝑒𝑙𝑒𝑣𝑎𝑛𝑧 = 0.679, 𝑆𝑒𝑛𝑠𝑖𝑡𝑖𝑣𝑖𝑡 = 1.0). Da jedoch die SVM mit linearem Kernel beweist, dass eine Geradengleichung gefunden wurde, die die Daten generell separiert, ist es das Modell der Wahl (𝐹1 = 1.0, 𝑅𝑒𝑙𝑒𝑣𝑎𝑛𝑧 = 1.0, 𝑆𝑒𝑛𝑠𝑖𝑡𝑖𝑣𝑖𝑡 = 1.0). 19 nähere

Details in der Literatur [23] auf Grundlage der Kreuzvalidierung

20 Train-Test-Split

106

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

Abbildung 4.29: Diagnose-Klassifikationsergebnis (Konfusionsmatrix) [51] An dieser Aufgabe wird auch deutlich, warum eine KI eingesetzt wird und nicht klassisch mit der Datenbank gearbeitet wird. In der Fahrzeugentwicklung wird es immer vorkommen, dass eine Datenbank nicht vollständig ist. Ein ML-Modell wie hier die SVM mit linearem Kernel kann diese Aufgabe generalisieren, so dass keine 100 % Datengrundlage benötigt wird. Das Modell erkennt zuverlässig Diagnosenachrichten selbst in einem Fahrzeug, das neuer als das Trainingsfahrzeug und unbekannt ist. Abschließend kommt in Tabelle 4.4 noch die Gegenüberstellung der drei in diesem Kapitel untersuchten Algorithmen. Eingesetzt wird der Algorithmus der linearen-SVM, da dieser wie in der Tabelle zu erkennen ist, sehr zuverlässig und schnell ist. Der K-Nearest-NeighborsAlgorithmus ist für die untersuchte Anwendung nicht geeignet. Der Random-ForestAlgorithmus wäre eine Alternative, aber es müssten die Features erhöht werden, so dass keine Überanpassung mehr auftritt. Beispielweise können neue Features generiert werden, wenn die bestehenden quadriert oder mit den anderen multipliziert werden. Jedoch muss diese Feature-Erhöhung auch bei jeder neuen Messung durchgeführt werden, was sich negativ auf die Durchlaufzeit auswirken würde. Der Quellcode zu diesem Vergleich befindet sich im Anhang im Listing B.3

4.5 Vergleich der Machine-Learning-Modelle

107

Tabelle 4.4: Vergleich der ML-Ansätze zur Detektion einer Diagnose-Nachricht Kriterium Zuverlässigkeit (Wiederholbarkeit) Geschwindigkeit (Wie häufig, wie lange pro Durchlauf) Zuständigkeit (Wer muss es rechnen) Datengrundlage (Was ist die Grundlage) Systemabhängigkeit (Welche Hardware/Software wird vorausgesetzt) Kosten (einmalige und laufende) Summe („+=1“; „-=-1“)

K-NearestNeighbors

RandomeForest

lineareSVM

o

+

++

-

o

++

o

o

o

o

-

o

o

o

o

-

o

+

-2

0

5

4.5.3 ECU-Identifikation Bei der Erkennung der Steuergeräte hat sich herausgestellt, dass das Ziel jeweils über einen Umweg leichter zu erreichen ist21 . Einerseits kann über den VCI-Ansatz die Anzahl der möglichen Steuergeräte reduziert werden. Jedoch stehen in der ARXML-Datei nur ECU-Gruppennamen und nicht das konkrete Steuergerät. Es ist also möglich, jeden Datenpunkt zu klassifizieren mit dem ECU-Gruppennamen bspw. Motorsteuergerät. Über einen Abgleich der Res-ID der beiden Datenbanken (ECU-Group-Res-ID zu Interface-Res-ID) kann zumindest bestätigt werden, dass eine reale Kommunikation stattgefunden hat. Durch diese Bestätigung ist eine Verifikation der Off-Board- mit der On-Board-Kommunikation möglich. Andererseits können über den DIAG-Ansatz die Diagnosenachrichten aus der FCT-Messung mit samt ihrer ID extrahiert werden und über den Ansatz wie in Kapitel 4.4 (DiagnoseODX-Pattern) beschrieben in ECU und SW-Variante umgerechnet werden. Dabei 21 Auf

die Entwicklung KI-basierter Ansätze zur ECU Identifikation auf Grundlage des FCT wird in dieser Arbeit nicht weiter eingegangen. (Grundlegende Informationen in der Wissenschaftlichen Arbeit [71], die Ergebnisse wurden für die vorliegende Forschungsarbeit gemeinsam erarbeitet und in der studentischen Ausfertigung schriftlich niedergeschrieben.)

108

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

wird über die DIAG-KI der Datensatz von 17.261 auf die 328 Diagnosenachrichten reduziert. Dieser reduzierte FCT muss in einem weiteren Schritt in ein kompatibles Datenschema für den Pattern-Interpreter umgewandelt werden, damit dieser eine Liste der Steuergeräte ausgibt. Diese Liste wird im Anschluss zur Verifikation der bestimmten Steuergeräte auf Grundlage der Off-Board-Kommunikation genutzt. Beide Ansätze sind nicht ideal und die trainierten neuronalen Netzwerke [53, 56, 59, 75] stagnieren jeweils bei einer Genauigkeit von etwa 40 % aufgrund der geringen Daten (ohne die Unterstützung des OEM bleiben nur zwei Fahrzeuge für Messungen am Institut). Die Zufallswahrscheinlichkeit, dass ein Mensch aus den 47 möglichen Steuergeräten das richtige auswählt, beträgt bei Gleichverteilung etwa 2,13 % (bei der Verteilung, die in Abbildung 4.7 vor und nach der Datenbereinigung zu sehen war, liegt diese etwa bei 30 %). Damit war das neuronale Netz zwar um den Faktor 16 besser als reines Raten eines Menschen, dem eine Liste der möglichen ECUs gezeigt wird. Aber es ist etwa vergleichbar mit einem Experten, der weiß, dass von einem Motorsteuergerät viele Nachrichten übertragen werden. Das ist für eine VNA-Bestimmung nicht ausreichend. Weder das Normalisieren der Daten, das Normalisieren der Gewichte der hidden Layer noch das Oversampeln haben mit den zur Verfügung stehenden Ressourcen zu zufriedenstellenden zuverlässigen Ergebnissen geführt. An dieser Stelle werden mehr Messungen mit unterschiedlichen Fahrzeugen benötigt22 . Aufgrund dieser Situation wurden die beiden oben beschriebenen Prozesse implementiert. In Tabelle 4.5 werden die beiden verwendeten Algorithmen verglichen. Da an dieser Stelle keine genaue Verifikation möglich ist, wird hier der „best of three“ Ansatz gewählt. Das bedeutet, wenn zwei von drei berechnen, dass das ECU anwesend ist, wird es in die Liste der verbauten Steuergeräte aufgenommen, wobei einer der zwei der Diagnose-ODX-Pattern-Prozess sein muss, da andernfalls nicht die SW-Variante bestimmt werden kann.

22 Dass

es prinzipiell möglich ist, zeigt [51].

4.6 Zusammenfassung und Ergebnis der Methode

109

Tabelle 4.5: Vergleich der neuen Methode mit dem Stand der Technik ECUGruppenAnsatz

DIAGAnsatz

Zuverlässigkeit (Wiederholbarkeit) Geschwindigkeit (Wie häufig, wie lange pro Durchlauf) Zuständigkeit (Wer muss es rechnen) Datengrundlage (Was ist die Grundlage) Systemabhängigkeit (Welche Hardware/Software wird vorausgesetzt) Kosten (einmalige und laufende)

+

++

-

+

o

o

+

+

-

-

o

o

Summe („+=1“; „-=-1“)

0

3

Kriterium

4.6 Zusammenfassung und Ergebnis der Methode In diesem Kapitel wurde die Methode zur Identifikation einer Fahrzeug-NetzwerkArchitektur (engl. Vehicle Network Architecture) (VNA) vorgestellt. Einerseits wurde aufgezeigt, welche Risiken und Herausforderungen aktuell bestehen und wie hieraus Bewertungskriterien abgeleitet werden, um Prozesse und Methoden vergleichen zu können. Darauf aufbauend wurde hergeleitet, warum eine Backendbzw. Cloudbasierte-Lösung das größte Verbesserungspotenzial mit sich bringen würde. Das führte infolgedessen zu der Möglichkeit, KI- bzw. ML-Algorithmen verwenden zu können. Aufgrund dieser neuen Möglichkeit wurde eine Methode aufgezeigt, wie eine CAN-Messung in ein Datenformat transformiert werden kann, durch welches die Cloud in der Lage ist, diverse Analysen mit diesen Daten durchführen zu können.

110

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

Zudem wurde dargestellt, was im Backend alles notwendig ist, um die VNA zu berechnen und zu speichern. Hierbei werden als Datengrundlage die ODX-Dateien in eine DiagPattern-DB eingelesen. Auf Grundlage der entstehenden Datenbasis kann eine Messaufgabe gebildet und an ein IoT-Messsystem übertragen werden, wodurch eine Diagnostik-Pattern-Messung im Fahrzeug durchgeführt und auf dem Server zurückgerechnet wird in die verbauten ECUs und deren SW-Variante. Der beschriebene Off-Board-Diagnoseprozess wird validiert durch einen On-BoardDiagnoseprozess, der hauptsächlich durch ML-Modelle implementiert ist. Es wurde eine Methode dargestellt, mit der der Netzwerkname und die Bedatungsdatei (ARXML) wahrscheinlichkeitsbasiert bestimmt werden kann. Bei dieser Herleitung wurde auf drei unterschiedliche Algorithmen eingegangen, aufgrund einer beschriebenen Skalierung wurde die Möglichkeit eröffnet, diese qualitativ und quantitativ zu bewerten, was auch durchgeführt wurde. Das Resultat ist, dass ein Algorithmus die Anforderungen nicht erfüllen kann, ein anderer gute Ergebnisse liefert und der dritte noch nicht abschließend untersucht ist. Eine weitere KI wurde dargestellt, mit der die Off-Board- von der On-BoardKommunikation einer FCT-Messung getrennt werden kann. An dieser Stelle wurden erneut drei unterschiedliche Modelle trainiert und die Generalisierung verglichen. Dabei befanden sich zwei Modelle in der Überanpassung an die Trainingsdaten und ein Model hat bewiesen, dass hier eine performante generelle Lösung gefunden wurde. Der Vergleich wurde auf Basis einer Konfusionsmatrix durchgeführt, da bezogen auf die Fragestellung ein stark nicht normalverteilter Datensatz untersucht werden muss. Die dritte untersuchte Anwendung der Bestimmung der ECUs auf Grundlage der FCT-Messung unter Verwendung von neuronalen Netzen konnte nicht zu einem zufriedenstellenden Ergebnis gebracht werden. Der Grund hierfür ist, dass nur Daten von zwei Serienfahrzeugen für die Forschung bereit standen und das für ein generalisierendes Modell nicht ausreichend ist. Hier stehen weitere Analysen an, die aber vorzugsweise bei einem OEM durchgeführt werden sollten, um genügend Daten zu erhalten, um sinnvolle neuronale Netze trainieren zu können. Das Resultat dieser Methode ist eine vollständig identifizierte VNA, mit der nun beliebige Anwendungen realisiert werden können. Eine ist die individuelle Testablaufgenerierung, auf die im anschließenden Kapitel eingegangen wird. Eine andere ist die Protokollierung der Fahrzeugvergangenheit, wann welches Steu-

4.6 Zusammenfassung und Ergebnis der Methode

111

Tabelle 4.6: Gegenüberstellung: Ad-hoc-VNA zu der Methode dieser Arbeit Kriterium

ohne VNA

Laufzeit

Mehrere Minuten jede Messung immer aufgrund der Ad-hoc-VNA-Bestimmung

Time To Test

Unter Umständen mehrere Wochen oder Monate, abhängig von einer Expertenkaskade

Online/Offline

Sicherheit

Vollständigkeit

Offline, nachdem einmal am Tag ein händisches Update durchgeführt wurde Vertrauliche ECU-Dateien auf jedem Entwicklerrechner und bei externen Dienstleistern offengelegt Abhängig der Expertise des messenden Ingenieurs

Methode zur Identifikation der VNA Initiale VNA Bestimmung und Sicherung im Backend, Messungen infolgedessen meist 63 % schneller In der Regel ist nach zehn Minuten jede beliebige ECU-Kombination eines OEM ausgelesen, abhängig von der Datengrundlage Online beim ersten Start zum Beziehen der Skripte und für den Upload Vertrauliche ECU-Dateien auf dem Fileserver und in den Datenbanken immer vollständig

Qualifikation

Speziell geschulte Test- und Messingenieure

Jeder kann messen, es bedarf nicht mehr eines Ingenieurs

Aktualität

Abhängig der Update-Mentalität des durchführenden Ingenieurs

stets aktuell

Verfügbarkeit

Messungen werden bei Bedarf von dem Ingenieur hochgeladen

Jede Messung ist online einsehbar für berechtigtes Personal immer unmittelbar nach dem Durchlauf

Interpretation / Visualisierung

Protokollierung des kontaktierten Netzwerks und der ARXML durch den Ingenieur

Bestimmung der Netzwerknamen und der ARXMLs durch je eine KI

112

4 Methode zur Identifizierung der Fahrzeug-Netzwerk-Architektur

ergerät umgebaut oder auf eine neuere SW-Version hochgerüstet wurde. Diese Vergangenheit ist notwendig für die mögliche Anwendung der Visualisierung der Messungen oder der OTA-Flash-Vorbereitung der ECUs. Damit wird festgehalten, die vorgestellte Methode ist ein notwendiger initialer Prozess für nachgelagerte Diagnose-Anwendungen.

5 Anwendung und praktischer Nachweis Zum Nachweis des Konzeptes sowie der Methode dieser Arbeit ist eine exemplarische Diagnoseplattform entstanden. Im Folgenden wird ein Systemüberblick über die Diagnose-Plattform gegeben und somit die Software-Architektur der CloudApplikation dargestellt. Dabei wird eine neue Datenbank vorgestellt, mit der die Messungen des Systems festgehalten werden und zudem beinhaltet die Datenbank noch einen Zustandsautomaten, durch den die Daten-Pipeline der unterschiedlichen Messungen ablaufen. Das Resultat der Plattform ist ein vollständig identifiziertes Fahrzeug und die Messaufgaben für dieses Fahrzeug werden ebenfalls vollautomatisch und natürlich individuell für die Fahrzeuge erstellt. Damit transformiert diese Plattform die Testablauferstellung von einem Wasserfall-Prozess zu einem geschlossenen Kreislauf. Denn es werden keine Skripte mehr händisch erstellt, sondern auf Grundlage der VNA individuell an das Fahrzeug angepasst. Die Messresultate der von der Plattform herausgegebenen Testabläufe werden wiederum an diese übertragen, wodurch die Diagnose-Plattform die Möglichkeit hat, auf Fehler zu reagieren und den Entwickler bzw. Experten zu informieren oder direkt die Testabläufe zu optimieren1 Weiterhin werden mit diesem Ansatz ebenfalls alle Bedatungsdateien ODX und ARXML automatisch einer historischen Protokollierung unterzogen, wodurch sich für die Interpretation bei vermeintlich zum negativen verbesserten Bedatungsdateien ganz neue Möglichkeiten ergeben. Zudem können mit diesem Ansatz einer Plattform mehr bislang stille Fehler den Fahrzeugentwicklern sichtbar gemacht werden, beispielsweise die Plausibilisierung der ODX-Datei beim Upload, hier kann, wenn ein Messwert in einer Variante des Steuergerätes in vielen Skripten bedatet ist, aber laut dem neuesten ODX-Upload gelöscht ist, der Steuergeräte-Experte, der in der ODX-Datei als Ansprechpartner hinterlegt ist, eine E-Mail mit der Diskrepanz erhalten. Stand heute ist so etwas ein stiller Fehler, der kaum aufgedeckt wird. Im folgenden wird ein Systemüberblick über die Diagnose-Plattform gegeben.

1 Auf

die Methode zur Optimierung der Diagnoseskriptbedatung basierend auf Algorithmen der künstlichen Intelligenz wird in dieser Arbeit nicht weiter eingegangen. (Grundlegende Informationen in der Masterarbeit[11], die Ergebnisse wurden für die vorliegende Forschungsarbeit gemeinsam erarbeitet und in der studentischen Ausfertigung schriftlich niedergeschrieben.

© Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 R. T. Lutchen, Optimierung der Fahrzeugdiagnose durch eine cloudbasierte Methode zur Identifikation der Datennetze mit künstlicher Intelligenz, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-43113-6_5

114

5 Anwendung und praktischer Nachweis

5.1 Systemüberblick Moderne Software [13, 19, 46, 54, 66] wird heutzutage meist nicht mehr in einer monolithischen Struktur [42] programmiert. Hier haben sich andere Herangehensweisen als vorteilhaft herausgestellt. Es wird versucht, die Kopplung der Systeme zu reduzieren, um Bestandteile auszutauschen und so dynamisch neue Funktionen oder Fehlerbehebungen einfließen zu lassen. Das Dynamische steht heute eher im Fokus, was daraus resultiert, dass hier mehr Projekte erfolgreich durchgeführt werden [55]. Das klassische Wasserfall- oder V-Modell kommt in der Software-Entwicklung [68] daher eher selten zum Einsatz und ist, wie in Abbildung 3.5 dargestellt ist, auch nicht erstrebenswert [57]. Die agile Entwicklung wird in den Softwareunternehmen gepflegt. Hier gibt es einen Scrum-Master, der zu einem täglichen Standup-Meeting einlädt und den aktuellen Sprint überwacht, im Gegensatz zum klassischen Projekt, bei dem am Anfang der Kunde definiert, was er genau braucht, und nach der Projektlaufzeit das fertige Produkt erhält. Wird der Kunde in der agilen Entwicklung miteinbezogen, er bekommt zu jedem Sprintende die Gelegenheit, das aktuelle Produkt zu bewerten, neue Aspekte einzubringen oder die Priorität der wartenden Aufgaben zu verändern. Somit steigt die Wahrscheinlichkeit, dass der Kunde genau das erhält, was er sich wünscht. Ein Sprint geht in der Regel eine bis vier Wochen. Da eine monolithische Struktur heute nicht mehr zeitgemäß ist, wird die Gesamtaufgabe in kleinere Teile mit jeweils einer Verantwortlichkeit (Grund, diese zu ändern) aufgeteilt, so entsteht beispielsweise eine Service Oriented Architecture (SOA) [14, 27]. Bei einer SOA liegen einzelne Module vor, die jeweils eine Aufgabe haben und von beliebigen anderen Modulen ausgeführt werden können. Hier liegt eine Kopplung der Module weiterhin vor, aber diese ist minimiert. Die Module sind lose gekoppelt und können ohne das erneute Kompilieren der anderen erweitert und ausgerollt werden. Zudem hat diese Architektur den Vorteil, dass wenn ein Service sehr häufig verwendet wird, dieser mit den Aufgaben automatisch mitskaliert. Das macht es ebenfalls möglich, die Services in einem Docker-Container [45] zu virtualisieren und diese in einem Cluster zu starten und zu verwalten. An dieser Stelle soll Kubernetes [3, 8, 47] als Plattform erwähnt werden, da diese in der Cloud verwendet wird [67]. Der Nachteil einer SOA ist, dass viele Module dezentral sind und somit die Anzahl der einzelnen Module, aus der die Anwendung besteht, hoch sein kann. Aber hier wiegen die Vorteile schwerer als die Nachteile. Die Skalierbarkeit, die Wartbarkeit, die Wiederverwendbarkeit und die Erweiterbarkeit sind

5.1 Systemüberblick

115

hier als dominierende Treiber zu erwähnen2 . In Abbildung 5.1 ist die vereinfachte Architektur der Diagnose-Plattform dargestellt.

CompDia-REST (C#) IIS (Webserver) Diagnostic Diagnostic Pattern with Pattern with Full Can Can Trace Full Trace

Delegator Delegator

CompDia

ML-REST (Python) Flask (Webserver)

IoT-Messgerät

Parser ARXML-File

Inbox DiagCloud Results

Parser ODX-File DiagPattern

Generate Testsequence and Rollout

Database

Applikations-Server (Fahrzeugverwaltung, Messungen aufbereiten, ...)

Private Cloud OEM

Abbildung 5.1: Die vereinfachte Software-Architektur der Forschungs-DiagnosePlattform (angelehnt an [52]) Im unteren Bereich ist zu erkennen, wie die beiden Cloud-Systeme gekoppelt sind. Auf Grundlage der Kommunikationspfade des verteilten Systems wird deutlich, dass über Servergrenzen (Fileserver, Datenbankserver, API-Server) hinweg Daten ausgetauscht werden, wobei diese immer verschlüsselt sind. Dadurch, dass die Module über das Dateisystem oder über die Datenbank kommunizieren, liegt hier eine lose Kopplung vor. In der Mitte der Abbildung sind zwei REST-APIs dargestellt, somit werden hier zwei IaaS-Cloud-API-Server eingesetzt. Die obere REST-API übernimmt die Ablaufsteuerung und die untere verwaltet die ML-Algorithmen. Die CompDia3 -REST-APIs stehen in Kontakt mit der Messtechnik im Fahrzeug 2 Dieser

Absatz ist die deutsche Übersetzung eines Papers [52] des Authors der vorliegenden Arbeit Abkürzung steht für Compression and Diagnostics, da die Plattform noch von einer weiteren Dissertation verwendet wird, bei der es um Komprimierungsalgorithmen geht. Die Applikation ist in C# programmiert basierend auf dem .NET Framework in der Entwicklungsumgebung Visual Studio.

3 Diese

116

5 Anwendung und praktischer Nachweis

und erhalten unterschiedliche Fahrzeugmessungen, die auf dem Fileserver in der Inbox abgelegt sowie auf dem Datenbankserver angelegt werden müssen, damit sich nachgelagerte Prozessketten um die übermittelten Daten kümmern können. Weiterhin sind drei Datenbanken dargestellt, zwei davon, die in Kontakt mit der ML-REST-API stehen, sind in Funktion und Anwendungsgebiet bereits im Detail eingeführt durch die Methode der VNA-Identifizierung. Hier ist auch zu erkennen, dass die Datenbasen direkt bei der Cloud des OEM abgefragt werden. Die beiden Parser-Module aktualisieren daraufhin die Identifikationsdatenbanken, das findet jeden Morgen automatisch statt. Die verbleibende Datenbank CompDia verwaltet die Messungen des IoT-Diagnosetesters und wird am Ende des Kapitels zur Visualisierung der Ergebnisse verwendet, da diese Datenbank die Fahrzeuge verwaltet und in Konsequenz der Identifizierungsmethode somit die VNA speichert. Das Modul Delegator und ML-REST-API haben hier eine besondere Aufgabe, da diese weitere Module anbinden, diese wurden der einfacheren Darstellung halber weggelassen. Hierbei handelt es sich beispielsweise im Fall des Delegators um den ASC-, MDF4-Interpreter, den ML-Dataset-Generator und weitere Container und im Fall der ML-REST-API um den Pattern-Interpreter, die VCI-, DIAG- und ECU-KI sowie den Testablauf-Generator (Publisher). Der Delegator übernimmt im Softwareentwurf die Daten-Pipeline. Hier ist festgelegt, welche Applikation für welche Anwendung in welcher Reihenfolge aufgerufen wird. Diese Architektur übernimmt somit mehrere Aufgaben: • Aktualisieren und Vorhalten der ODX-Daten (Steuergeräte-Identifikation) • Aktualisieren und Vorhalten der ARXML-Daten (Steuergeräte-Verifikation und VCI-Identifikation) • Aktualisieren und Vorhalten der Testablauf-Prozeduren, die der Kunde im Messwerkzeug benötigt • Fahrzeugidentifikation durchführen (Diagnose-Pattern mit zeitgleichem FCT) • Messaufgaben erstellen und an das entsprechende Messwerkzeug beim Kunden ausrollen (Testablauf-Generator / Publisher) Stark vereinfacht kann formuliert werden, dass die Plattform eine definierte Messung eines unbekannten Fahrzeuges erhält. Daraufhin werden die Steuergeräte und deren Softwarestände ausgewertet und in der Datenbank zwischengespeichert. Weiterhin werden die verwendeten Hardwareschnittstellen analysiert und die angeschlossenen Fahrzeugnetzwerke bestimmt. Mit diesen Informationen werden die Messaufgaben individuell für das Fahrzeug berechnet und an den Kundenserver übermittelt. Der Kundenserver kennt infolgedessen die Hardwareschnittstellen und

5.1 Systemüberblick

117

die empfohlenen Messaufgaben und kann diese an das Messwerkzeug weiterleiten. Hierdurch kann die erste Messung bereits wenige Minuten, nachdem das Fahrzeug hergestellt wurde, durchgeführt werden. Die IT-Sicherheit [37] bei verteilten Systemen ist von besonderer Bedeutung, da darauf geachtet werden muss, dass alle Regeln zu jedem Zeitpunkt eingehalten werden. Hier werden unterschiedliche Verfahren eingesetzt. Grundsätzlich ist jede Verbindung verschlüsselt und ebenfalls ist jede Datei auf dem Server verschlüsselt. So ist sichergestellt, dass das komplette Filesystem geschützt ist. Es kommt sowohl die symmetrische als auch asymmetrische Verschlüsselung zum Einsatz [17]. Die Datenübertragung findet mit dem Hypertext Transfer Protocol Secure (HTTPS)Protokoll (Transport Layer Security (TLS) 1.3) statt und zusätzlich wird zu den reinen Daten noch der Hashwert übertragen, um ganz sicher zu sein, dass diese Datei nicht verändert wurde oder um eine Alarmierung abzusetzen. Die Benutzerpasswörter werden durch einen „Salt“ und einen BCrypt-Hash-Algorithmus sicher in der Datenbank gespeichert. Die aufgesetzte CompDia-DB für die Dateisteuerung ist in Abbildung 5.2 dargestellt.

Abbildung 5.2: Das Datenbankschema der Diagnose-Plattform

118

5 Anwendung und praktischer Nachweis

Es ist wie bei jeder DB in der vorliegenden Arbeit auch hier wieder eine Tabelle für das Änderungs- und Log-Management vorgesehen4 . Da an dieser Stelle der IoT-Diagnosetester eine Schnittstelle bekommt, mit der dieser Daten senden darf, bedarf es einer Authentifizierung, was durch die gleichnamige Tabelle erledigt wird. Die REST-API überwacht alle Schnittstellen und überträgt ausschließlich Anfragen an die Datenbank, wenn die Basis-Authentifizierung erfolgreich bestanden wurde. Wie in der Abbildung zu sehen ist, gibt es hier einen durchgängigen Prozess, durch den die Daten strukturiert und ohne Limitierungen in der 2NF abgelegt werden. Betrachtet wird zu Beginn das Fahrzeug auf der rechten Seite. Diese Tabelle speichert die Fahrzeuge, die sich mit der Diagnose-Plattform verbunden haben und sorgt dafür, dass die VIN einzigartig und stets 17 Zeichen lang ist. Ein authentifizierter Diagnosetester in einem Fahrzeug kann eine Messung auslösen, was sich in der Tabelle Package widerspiegelt. Diese Tabelle sorgt unabhängig davon, wie komplex die Messung ist, dafür dass alle Daten, die dabei erzeugt werden, gruppiert sind. Zu einem Messpaket gehören zum Beispiel 12-CAN-FCTEinzelmessungen und eine Diagnosemessung ODX-Pattern. Diese 13 Bestandteile der Messung sind jeweils ein Bundle. Auf der linken Seite stehen wie bereits gewohnt die Dateien, die in einem Ordner auf dem Fileserver abgelegt sind. Zum Verbinden der gespeicherten Dateien und der einzelnen Messbundle wird die Tabelle Resultate verwendet. Diese Tabelle folgt dem Ansatz, dass keine Datei eines IoTSystems ohne Grund hochgeladen wird. So gibt es immer eine hochgeladene Datei und das berechnete Ergebnis, welches daraus entstanden ist. Bezogen auf die Diagnose-Plattform bedeutet dies, dass eine binäre CAN-Messung (z. B. CAN11.fbin5 ) hochgeladen wird. Daraufhin wird der ASC-Interpreter und die ASC-Datei und somit das Interpretationsergebnis berechnen. Damit ist das Result-Tupel des Bundles Messung_xyz_CAN11 vollständig. Da aber aus der ASC-Datei die VCIIdentifikation durch einen ML-Datensatz berechnet werden kann, ist diese Datei wieder der Ausgangspunkt für die nächste Interpretation. Somit wird erneut ein 4„In

großen IoT-Softwareprojekten ist es wichtig, über den Zustand der Module Bescheid zu wissen. Wenn eine Exception in einem Modul auftritt und dieses infolgedessen nicht mehr zur Verfügung steht, muss das der Entwickler schnellstmöglich mitbekommen. So ist es dem Software-Entwickler möglich, auf den Fehler zu reagieren und zu analysieren, was passiert ist. Er kann den Fehler dann beheben und das Modul neu starten, damit die Anwender wieder den gewohnten Service nutzen können. Ohne eine solche Alarmierung wird der Anwender den Fehler als erster finden und den Entwickler informieren, dass ein Ausfall des Systems vorliegt. Im zweiten Szenario hat der Entwickler weniger Zeit, eine Lösung zu finden und unter Umständen auch weniger Informationen. Zudem sollten die Anwender einer Applikation nicht die Tester der gleichen sein. “[52] 5 Es ist eigentlich eine .bin Datei, das f steht für FCT, damit auf dem Fileserver besser gefiltert werden kann und das Dateihandling schneller und fehlerfreier ist.

5.2 Bedatungskreislauf anhand der Diagnose-Plattform

119

Result im gleichen Bundle erzeugt. Wichtig an dieser Stelle ist noch der Hinweis auf die Commited-Spalte der File- und Package-Tabelle. Beim Anlegen stehen diese auf null, wenn der IoT-Diagnose-Tester die Datei oder das Package gesendet hat. Nach dem Übertragen der Datei und dem Hypertext Transfer Protocol (HTTP)-Code 200 (OK) fragt das IoT-Device den Hashwert der Datei an und vergleicht diesen mit seinem eigenen derselben Datei. Sind beide gleich, gibt das IoT-Device die Datei frei, indem der Commited-Status auf eins hochzählt6 .

5.2 Bedatungskreislauf anhand der Diagnose-Plattform Durch das vorgestellte Softwarekonzept ergeben sich neue Möglichkeiten für die Fahrzeugentwicklung im Hinblick auf die Testablauferstellung und die Validität der Messresultate. Durch das gezeigte Softwarekonzept wurde aufgezeigt, dass grundlegende Daten (bspw. ODX, ARXML, . . . ) vom OEM täglich angefragt und die benötigten Daten in unterschiedliche Datenbanken eingelesen werden. Das spiegelt den Bereich „Bedaten“ der Abbildung 5.3 wider. Hier ist zu erkennen, dass diese Plattform und das dahinter stehende Konzept grundlegend auf Daten beruht. Ausgehend von diesen Daten können Identifizierungsskripte erstellt werden, mit denen ein Fahrzeug identifiziert wird. Sowie das Fahrzeug erkannt und in der Datenbank aktualisiert wurde, können die Testabläufe, die der Entwickler für die Erprobung vorgesehen hat, generiert und an das Testequipment übertragen werden. Daraufhin ist das Messsystem in dem Fahrzeug bereit und stets auf dem neuesten Stand sowie immer vollständig und so performant wie möglich. In den Bereich „Optimieren“ der Abbildung 5.3 können viele unterschiedliche Aufgaben fallen. Die naheliegendste ist, wenn „Messwert A“ in einem Messresultat-Upload des Fahrzeuges nicht funktioniert hat, diesen Messwert aus dem Testablauf herauszunehmen, um nicht erneut auf das Timeout zu warten, möglicherweise mit einem Monte-Carlo-Drop-out-Layer versehen, um in unregelmäßigen Intervallen zu überprüfen, ob der Messwert immer noch nicht funktioniert, bis ein verantwortlicher Entwickler den Messwert entfernt. Es ist aber ebenfalls vorstellbar, dass die Resultate über Flotten oder sogar ganze Baureihen übergreifend analysiert und die Testabläufe optimiert werden. Es kann im Bereich „Optimieren“ eine KI 6Wenn

ein Interpreter eine Datei erhält, wird auch dieser immer den Status inkrementieren. Somit kann aufgrund dieser Zahl die Tiefe der Pipeline abgelesen werden.

120

5 Anwendung und praktischer Nachweis

Abbildung 5.3: Bedatungskreislauf der Diagnose-Plattform eine Grenzwertkontrolle über alle Entwicklungsfahrzeuge einer Baureihe durchführen und so eine Schwachstellenanalyse realisieren. Viele weitere Ansätze sind mit dieser Cloudbasierten SOA-Architektur möglich. Es ist aber durch diese Plattform ebenfalls vorstellbar, den Anwender zu identifizieren und zu erkennen, welche Messungen Person A häufig durchführt um somit ein spezielles personenabhängiges Skript zur Funktionsüberprüfung bspw. der Lambdasonde anzubieten, wenn die Person als Abgasnachbehandler identifiziert wurde. Abschließend bleibt noch die Optimierung bzw. die Plausibilisierung der Datengrundlage. Hier können ebenfalls viele hilfreiche Tools entstehen, die neue Stände in einem ersten Schritt validieren und somit dem Steuergeräteverantwortlichen ein besseres Gefühl geben. Sollte ein Messwert in der neuen Version des Steuergerätes nicht mehr vorhanden, aber in Skripten noch bedatet sein, so kann der Steuergeräte-Experte benachrichtigt werden. Möglichkeiten einer Benachrichtigung über einen Webhook-Dienst oder klassisch per E-Mail können die Entwicklungsgeschwindigkeit positiv beeinflussen. Durch

5.3 Ergebnisse

121

den Bedatungskreislauf ist jedes System immer automatisch auf dem aktuellsten Stand und es ist egal, mit welcher Hardware gemessen wird. Ein so aufgesetztes System im Umfeld von Big Data bietet viele Optimierungsschnittstellen. Viele neue und innovative Konzepte können durch den Bedatungskreislauf und die damit verbundene Diagnose-Plattform entstehen.

5.3 Ergebnisse Die hier gezeigte Messung wurde am 19.01.2022 um etwa 14:50 Uhr durchgeführt, um die entwickelte Plattform sowie die Methode vorzustellen. Alle bis dahin in der Forschung erzielten Daten in den Datenbanken wurden vor der Präsentation bereinigt. Damit wurde ein initialer Zustand hergestellt, um die Forschungsergebnisse zu präsentieren. Über die SQL-Abfrage, die in Listing 5.1 dargestellt ist, wird eine Messung in der CompDia-DB abgefragt. Listing 5.1: SQL-Abfrage zur Messungsvisualisierung einer Identifikationsmessung im Fahrzeug 01 | 02 | 03 |

-- 1. Abfrage -- Alle Fahrzeuge abfragen SELECT * FROM [CompDia].[dbo].[Car];

05 | 06 | 07 |

-- 2. Abfrage -- Alle Messungen abfragen (Pakete) SELECT * FROM [CompDia].[dbo].[Package] where [Name] LIKE ’Messung2%’;

09 | 10 | 11 |

-- 3. Abfrage -- Alle Einzelmessungen des Paketes abfragen SELECT * FROM [CompDia].[dbo].[Bundle] where [Name] LIKE ’Messung2%’;

13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 |

-- 4. Abfrage -- Alle Dateien der Messung abfragen SELECT count(UploadFile.[Name]) AS UploadFileCount, --UploadFile.[Extension], --UploadFolder.[Name] AS UploadFolderName, --UploadFile.[Commited] AS State, --UploadFile.[Hash] AS Hash, InterpretedFile .[ Name] AS InterpretedFileName, InterpretedFile .[ Extension ], InterpretedFolder .[ Name] AS InterpretedFolderName, InterpretedFile .[ Commited] AS State, InterpretedFile .[ Hash], InterpretedFile .[ MetaData] FROM [CompDia].[dbo].[Result]

122 27 | 28 | 29 | 30 | 31 | 32 | 33 |

5 Anwendung und praktischer Nachweis JOIN [ File ] AS UploadFile ON [Result ]. UploadFileId = UploadFile .[ Id] JOIN [ File ] AS InterpretedFile ON [Result ]. InterpretedFileId = InterpretedFile .[ Id] JOIN [Folder] AS UploadFolder ON UploadFile . FolderId = UploadFolder.Id JOIN [Folder] AS InterpretedFolder ON InterpretedFile . FolderId = InterpretedFolder . Id WHERE InterpretedFile .[ Name] like ’Messung2%’ GROUP BY InterpretedFile .[ Name], InterpretedFile .[ Extension ], InterpretedFile .[ MetaData], InterpretedFile .[ Hash], InterpretedFile .[ Commited], InterpretedFolder .[ Name] ORDER BY InterpretedFile .[ Name] ASC;

Es ist zu erkennen, dass vier Abfragen nacheinander durchgeführt werden. Die ersten drei SQL-Abfragen laden die Fahrzeug-, Pakete- und Bundle-Tabelle der Messung. Die vierte Abfrage kombiniert die Dateien mit den Resultaten und den zugehörigen Ordnern einer gesuchten Messung. Wie bereits erwähnt, wird die Plattform ebenfalls für eine Dissertation zu Automotiv-Kompressions-Algorithmen verwendet. Daher wird in der Abfrage eine Gruppierung auf Grundlage der Zieldatei durchgeführt. In Abbildung 5.4 ist das Ergebnis der SQL-Abfrage aus Listing 5.1 dargestellt. Hier wird nun ein Fahrzeug-Netzwerk vollständig identifiziert und in der Datenbank abgelegt und zusätzlich wird der Kurztest individuell für das identifizierte Fahrzeug generiert. Die vier Abfragen sind zu erkennen. Auf Grundlage der ersten Abfrage wurde das Fahrzeug abgefragt. Der Bereich der VIN und der Metadaten wurde farblich in grün hervorgehoben. Es ist dadurch zu erkennen, dass das Fahrzeug mit der VIN: WDD2132161A698188 die Steuergeräte, die in Listing 5.2 als JSON-Datei dargestellt sind, enthält.

5.3 Ergebnisse

Abbildung 5.4: Ergebnis der Fahrzeugidentifikation

123

124

5 Anwendung und praktischer Nachweis

Listing 5.2: Steuergeräteliste als JSON-Datei - Resultat des Diagnose-PatternInterpreters (anonymisiert für den Druck) 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 |

{ "ECU1": "ECU1_e124", "ECU2": "ECU2_e124", "ECU3": "ECU3_007013" "ECU4": "ECU4_r18a1", "ECU5": "ECU5_006", "ECU6": "ECU6_r17", "ECU7": "ECU7_r17", "ECU8": "ECU8_r17", "ECU9": "ECU9_r17", "ECU10": "ECU10_high", "ECU11": "ECU11_0x005f05", "ECU12": "ECU12_2405", "ECU13": "ECU13_000b47", "ECU14": "ECU14_21", "ECU15": "ECU15_var000418", "ECU16": "ECU16_0005", "ECU17": "ECU17_x30c", "ECU18": "ECU18_cy18_1_row_china", "ECU19": "ECU19_freshup2", "ECU20": "ECU20_hsw08p4", "ECU21": "ECU21_b22_variante", "ECU22": "ECU22_b22_variante", "ECU23": "ECU23_e043", "ECU24": "ECU24_var008231", "ECU25": "ECU25_var008231", "ECU26": "ECU26_b18_peb2", "ECU27": "ECU27_0042", "ECU28": "ECU28_18a_1", "ECU29": "ECU29_004009_gen3", "ECU30": "ECU30_008b11_aej18_1", "ECU31": "ECU31_r18_km1717", "ECU32": "ECU32_006750", "ECU33": "ECU33_id000702", "ECU34": "ECU34_sop_ap2", "ECU35": "ECU35_rbtm213_sop_ap2", "ECU36": "ECU36_0x000b", "ECU37": "ECU37_0x2703" "ECU38": "ECU38_pal_1002",, "ECU39": "ECU39_18a_ms0a30_dk75", "ECU40": "ECU40_000a0c", }

Die zweite Abfrage führt zu dem Ergebnis, dass das Messpaket „Messung2“ heißt. In der dritten Abfrage sind die einzelnen Messungsbestandteile (Bundle) dargestellt. Hier ist zu erkennen, das fünf FCT-CAN-Messungen und eine Diagnostik-PatternMessung durchgeführt und hochgeladen wurden. Die Metadaten der einzelnen Bundle sind ebenfalls farblich in blau hervorgehoben. Hier ist dargestellt, wie die

5.3 Ergebnisse

125

einzelnen Schnittstellen von der VCI-KI identifiziert wurden. In Tabelle 5.1 ist die Zuordnung des Messsystem-Kabelbaums zum erkanntem Datenbus der Datenbank dargestellt. Tabelle 5.1: Ergebnis der Identifizierung von Fahrzeug: WDD2132161A698188 Datenbankbus

Nummer Kabelbaum

Datenbank-ARXML

HMI BODY POWERTRAIN ENGINE DIAGNSTICS

5 8 9 10 11

HMI_CAN_2019_29a.arxml BODY_CAN_2019_29a.arxml POWERTRAIN_CAN_2019_17a_1.arxml ENGINE_CAN_2018_29f.arxml DIAGNOSTICS_CAN_2019_29a_1.arxml

Die letzte Abfrage holt die erzeugten Dateien ab. Hier ist zu erkennen, dass pro CAN-Bus jeweils eine binär-Datei (.fbin) erstellt wurde. Aus der binär-Datei ist dann die ASC-Datei entstanden, um die ML-Modelle zu verwenden. Daraufhin wurde die ARXML-Datei berechnet, die am besten mit der Messung übereinstimmt und auf dieser Grundlage die MDF4-Datei automatisch erstellt. Abschließend ist in Abbildung 5.5 der generierte individuelle Kurztest für das Fahrzeug mit der VIN: WDD2132161A698188 dargestellt. Somit ist der Nachweis der Funktion der Methode erbracht.

Abbildung 5.5: Generierte Messaufgabe auf Grundlage der identifizierten Fahrzeug-Netzwerk-Architektur (engl. Vehicle Network Architecture) (VNA)

6 Zusammenfassung In dieser Arbeit wurde eine neue Methode hergeleitet, wie die Fahrzeug-NetzwerkArchitektur (engl. Vehicle Network Architecture) (VNA) bestimmt werden kann. Hier werden einerseits die Netzwerke identifiziert (Fahrzeug-Netzwerk-Schnittstelle (engl. Vehicle Communication Interface) (VCI)), was den Hintergrund hat, das Hardwareabhängigkeiten im Bezug auf den Kabelbaum entfallen sollen. So kann zukünftig jeder Diagnose-Kabelbaum in jedem Fahrzeug eingesetzt werden und der Anwender kann ohne Bedenken zwischen den Fahrzeugen wechseln. Zusätzlich entscheidet der Anwender, welchen CAN-Bus er messen möchte und nicht der Messsystem-Hersteller zusammen mit seinem Kabelbaum-Lieferanten. Das wird die Fahrzeugentwicklung beschleunigen, da wenn ein neuer CAN-Bus im Fahrzeug eingesetzt wird, dieses neue Netzwerk nicht zu einem physisch neuen Diagnosekabelbaum führt. Um mit den Tests beginnen zu können genügt die Bedatungsdatei dieses neuen Subnetzwerks. Fehlerquellen werden minimiert, Ressourcen sowie Zeit eingespart, die Komplexität der Hardware-Vielfalt wird in die Software verlagert und im Fall der vorliegenden Arbeit in die KI. Weiterhin wird der Anwender durch diese Methode bei der Validierung der Messung unterstützt, indem die am besten passende ARXML-Datei vorgeschlagen wird, die auf Grundlage der Daten in der Messung durch eine KI als am wahrscheinlichsten angesehen wird. Bei Messsystemen mit mehreren Schnittstellen muss der Anwender gut dokumentieren, an welcher Schnittstelle er welchen CAN angeschlossen hat. Das kann zukünftig entfallen und die Interpretation und damit die Aufbereitung der Messung für einen Menschen wird beschleunigt. Diese Identifikation kann es auch bezogen auf weitere Forschung ermöglichen, die Gatewaysteuergeräte zu erkennen und somit das parallele Flashen als weitere Anwendung zu ermöglichen. So wäre es zukünftig vorstellbar, dass die Software, die auf ein Steuergerät übertragen werden soll, OTA an den Diagnosetester gesendet wird und dieser flasht das ECU. Der Anwender entscheidet, wann der Update-Flashprozess versucht werden soll. Bei einem Scheitern kann die Cloud ein Back-up oder eine andere Version senden. Anderseits wurde der Ablauf der Steuergeräteidentifikation vorgestellt. Bei dem Diagnostik-Pattern-Prozess wird eine Testprozedur im zu analysierenden Fahrzeug durchgeführt. In Folge dieser Messung kann die Cloud die Steuergeräte und deren SW-Variante zuverlässig ermitteln. Ein identifiziertes Fahrzeug im Backend ist in © Der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 R. T. Lutchen, Optimierung der Fahrzeugdiagnose durch eine cloudbasierte Methode zur Identifikation der Datennetze mit künstlicher Intelligenz, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-43113-6_6

128

6 Zusammenfassung

vielerlei Hinsicht nützlich. Einerseits kann nachvollzogen werden, wann welcher Umbau an Steuergeräten und/oder Software stattgefunden hat. Andererseits können Messaufgaben passend zu dem Fahrzeug erstellt und somit die Durchführungszeit auf ein Minimum reduziert werden. Zudem ist dieses Vorgehen sehr hilfreich, wenn es um die Aktualität einer Messaufgabe geht, da nach einer Änderung der Messaufgabe alle mit der Cloud verbundenen Messsysteme automatisch und unverzüglich die neue erhalten (Singel-Source-Prinzip). Grundsätzlich ist es durch die hier vorgestellte Methode möglich, eine Diagnose-Plattform im Web oder Intranet aufzusetzen und die Bedatung zu zentralisieren. Damit würden die Experten nicht mehr E-Mails untereinander austauschen, sondern die Änderungen direkt auf der Plattform durchführen und testen, ob alles wie gewünscht funktioniert. Hierdurch ist es möglich, dem in dieser Arbeit gezeigten Prozess der automatischen Testpyramide ein Stück näherzukommen und das klassische V-Model zu verlassen. Ein wichtiger Punkt ist ebenfalls, dass der Anwender dahingehend entlastet wird, dass keine vertraulichen Dateien zwingend auf dem persönlichen Arbeitsrechner liegen müssen. Diese vertraulichen Dateien werden im Backend der Cloud automatisch heruntergeladen, synchronisiert und verschlüsselt auf dem Fileserver abgelegt. Die Schlüssel werden von einer internen Blockchain verwaltet und somit sind alle Transaktionen1 für alle Teilnehmer einsehbar und manipulationssicher. Das ermöglicht es, auch externe Dienstleister in den Testbetrieb der Entwicklungsfahrzeuge einzubinden, ohne dass die vertraulichen Dateien ausgehändigt werden müssen. Mit dieser Methode kann der OEM sein Know-how schützen. Zudem muss der Anwender keine täglichen Backups mehr pflegen und sich nicht nach längerer Abwesenheit (Urlaub, Krankheit, ...) von einem Teammitglied auf den neuesten Stand bringen lassen. Diese Plattform ermöglicht es auch, Anwender zu erfolgreichen Testern zu machen, die selten bis gar nicht am Fahrzeug Messungen durchführen. Die Qualität der Resultate wird maßgeblich von den Software-Entwicklern im Backend zentral gepflegt und nicht von jedem einzelnen Anwender. Die Erweiterbarkeit um neue Tools wird geschaffen. Bezugnehmend auf die vier Säulen der Forschungsfrage kann festgehalten werden, dass diese Methode die Fahrzeugentwicklung deutlich vereinfachen und somit beschleunigen kann. Genauigkeit: Hier liefert die Methode bei richtiger Verwendung die Möglichkeit, auf 100 % zu gelangen. Die Netzwerke werden richtig erkannt, wenn die 1 Zu

welcher Zeit hat welcher Entwickler/Tool welche Datei geöffnet/verändert

6 Zusammenfassung

129

Datenbank der ARXML-Dateien aktuell gehalten wird. Zudem werden die Steuergeräte und deren SW-Variante zuverlässig identifiziert, wenn die Datenbank der ODX-Dateien aktuell gehalten wird. Der logische Aufbau eines Fahrzeuges wird analysiert und in der Cloud gespeichert. Dadurch entsteht ebenfalls eine Übersicht der Fahrzeugvergangenheit, wenn Umbauten stattfinden, und das ist neu unter den Diagnosesystemen. Vollständigkeit: Wenn die Methode bei einem großen OEM auf alle möglichen Steuergeräte angewendet wird, kann dadurch die Vollständigkeit garantiert werden, aber es tritt auch initial ein großer Zeitinvest auf. Optimierungen an dieser Stelle obliegen dem OEM. Hervorzuheben an dieser Stelle ist, dass durch diese Methode erstmalig eine Alternative geschaffen wurde und auf eine unterschätzte Herausforderungen hingewiesen wird. Durchlaufzeit: Bei der Durchlaufzeit ergeben sich viele positive Veränderungen. Einerseits können die Experten eigenständig dafür sorgen, das ihre Änderungen ausgerollt werden und sind somit nicht mehr abhängig von Update-Prozessen anderer Abteilungen. Anderseits sind Testabläufe, die auf Grundlage der VNA individuell für ein Entwicklungsfahrzeug erstellt werden, um ein Vielfaches performanter als globale Testabläufe. Aktualität: Es gibt nur eine Quelle aller Informationen und somit ist jeder Anwender automatisch immer aktuell. Änderungen wirken sich unmittelbar aus und verbessern somit die Messungen innerhalb von Sekunden weltweit. Damit ist die Forschungsfrage beantwortet. Mit der vorliegenden Arbeit kann die VNA unter Einsatz der modernsten IT-Infrastruktur mit einer vergleichsweise hohen Zuverlässigkeit bestimmt werden. Damit wird die Digitalisierung der Fahrzeugdiagnose zu großen Teilen in das Backend verlagert, damit der Anwender seine Messungen mit so wenig Experten-Wissen wie möglich erstellen kann. Gleichzeitig sorgt das System für eine einheitliche Qualität aller Messungen unabhängig der Kenntnisse. Die vorliegende neue Methode bedarf an Vorarbeit, aber die Vorteile überwiegen die Nachteile und die aufwendigere Konfiguration auf der Seite der Messsystementwickler. Das war auch nicht Bestandteil der Forschung, sondern das Ziel ist es, die Digitalisierung der Fahrzeug-Testerstellung voranzubringen. Hierbei wurden viele, teilweise auch handlichere Ansätze bewertet, jedoch konnte keiner so viele Verbesserungen generieren wie die in dieser Arbeit vorgestellte Methode. Aus diesem Grund wurde dieser disruptive Ansatz weiterverfolgt und eine vollständige

130

6 Zusammenfassung

Diagnose-Plattform entwickelt und die gesamte Kette des Bedatungskreislaufes implementiert und als valide getestet.

6.1 Generalisierung der Methode Die Methode wurde auf Grundlage der Standard-CAN-Kommunikation entwickelt und implementiert. Eine Übertragung auf CAN-ext ist sehr naheliegend, da nur der Identifier von 11 bit auf 29 bit verlängert wurde. Die Daten müssen entsprechend in den Datenbanken ergänzt werden, aber generell werden die gezeigten Algorithmen unangepasst auch hier funktionieren. Bei den CAN-FD-Nachrichten ist der Diagnose-Pattern-Prozess unbeteiligt. Jedoch muss das Einlesen von FCTMessungen und das Transformieren in einen ML-Datensatz angepasst werden, da die Payload mit dieser Erweiterung 64 Byte an Daten enthalten kann. Eine derartige Feature-Erweiterung wird Einfluss auf die ML-Algorithmen haben, aber es ist zu erwarten, dass diese nach einem erneuten Training weiter verwendet werden können. Somit kann mit dieser Methode das Standardbussystem (CAN) im Fahrzeug mit größter Wahrscheinlichkeit vollständig abgedeckt werden. Aber wie ist die Erwartung bei den anderen Fahrzeugnetzwerken? Automotive Ethernet (A-Eth) ist grundsätzlich Point to Point (P2P) physikalisch vernetzt. Damit ist ein Zwischenabgriff auf dem Bus schwer möglich. Damit muss wie in der Transportschichtprotokoll: ISO 13400 [30] (engl. Diagnostics over Internet Protocol) (DOIP)-Norm [30] ein Socket mit einem Gateway eröffnet werden und die Kommunikationsduplizierung angefordert werden [48]. Da bei Ethernet generell eine Routingtabelle im Gateway abliegt, kann das Netzwerk mit einfacheren Mitteln abgefragt und die Teilnehmer identifiziert werden. Das bedeutet, dass Automotive Ethernet (A-Eth) einen eigenen Prozess benötigt und nur in Grundzügen auf diese Methode aufbauen kann. Die Diagnose-Plattform aus dieser Arbeit kann aber problemlos um neue Funktionen erweitert werden. Systembedingt kann ein neuer Service in der Cloud gestartet werden und der Funktionsumfang steigt an. Bei LIN, MOST und FlexRay muss systembedingt anders vorgegangen werden. Die gezeigte Methode hat ihre Hauptanwendung in der Identifizierung der Teilnehmer bei einem Netzwerk, das dem Multi-Master-Prinzip unterliegt, das kann der CAN-Bus in der Fahrzeugentwicklung sowie in der Automatisierungstechnik sein. Die Ideen aus dieser Arbeit sind portierbar auf ähnliche Aufgabenstellungen und

6.2 Ausblick

131

die gezeigten Datenbankstrukturen können generell adaptiert werden. Die Methode ist grundsätzlich unabhängig vom Fahrzeughersteller und kann natürlich auch bei einem Zulieferer Dienste leisten. Überall, wo Netzwerkteilnehmer ausgewertet werden sollen, kann auf Grundlage der gezeigten Konzepte eine Anpassung angestrebt werden. Das Anwenden der gezeigten Methode auf weitere oder andere Datengrundlagen ist prinzipiell möglich und bedarf einer Erweiterung der Plattform. Die Generalisierung der Methode in Bezug auf die Grundgesamtheit der Entwicklungsfahrzeuge ist prinzipiell gegeben. Da die Datenbank täglich aktualisiert wird mit den neuesten ODX- und ARXML-Dateien, ist es vorstellbar, dass ein neues Entwicklungsfahrzeug vom Band läuft und mit dieser Methode nach wenigen Minuten feststeht, welche Steuergeräte und Netzwerke eingesetzt werden. Damit kann das neue und unbekannte Entwicklungsfahrzeug individuelle Testabläufe erhalten und die erste erfolgreiche Messung kann innerhalb der ersten halben Stunde nach der Herstellung erfolgen, unabhängig davon, was es für ein Fahrzeug ist. Somit liegen die Stärken dieser Methode bei der Generalisierung über alle Fahrzeuge eines OEM, der eintrainiert ist, hinweg. Dahingegen ist die Portierung der Ergebnisse hin zu einer andern Technologie, bspw. A-Eth, nicht ohne Analysen und Anpassungen möglich.

6.2 Ausblick Wissenschaftlich interessant ist die automatische Baudraten- und Technologieidentifizierung auf der Hardwareseite. Mit dieser und den hier aufgezeigten Methoden kann ein CAN-Netzwerk vollständig automatisiert ausgelesen und eingesetzt werden. Eine wissenschaftliche Auseinandersetzung um weitere zukunftsträchtige Netzwerke wie A-Eth und FlexRay ist ebenfalls ein Themengebiet, welches notwendig und vielversprechend ist. Zudem ist die Erweiterung um CAN-ext und CAN-FD noch nicht bewiesen und ein offenes Forschungsfeld. Weiterhin können die Messresultate detaillierter analysiert und optimiert werden. Mit der hier gezeigten Methode kann 63 % der Skriptdurchlaufzeit von Messaufgaben eingespart werden, aber es gibt wie bereits dargelegt, weiteres Potenzial, wenn die Messwerte auf der Grundlage der Variante selektiert werden und/oder

132

6 Zusammenfassung

versucht wird, fehlerhafte Messwerte im Skript zu identifizieren. Zudem besteht noch Potenzial bei der Individualisierung der Messaufgaben, die einen Anwender identifizieren, beispielsweise könnte eine KI versuchen, die Person in eine Gruppe, z. B. Abgasnachbehandler, einzugruppieren, um domänenspezifische Testabläufe zu erstellen. Auf der Diagnoseplattform sind zudem viele andere Ansätze denkbar, wie ein Empfehlungssystem für Messwerte oder die Erweiterung der Plausibilisierung und das Aufnehmen weiterer Datenquellen. Im Einzelfall muss an dieser Stelle überprüft werden, ob die Konzepte mit oder ohne einen OEM umsetzbar sind. Abschließend bleibt zu sagen, dass bei der KI basierten ECU-Bestimmung durch neuronale Netze weitere Daten benötigt werden. Generell scheint es möglich zu sein, aber hier muss die Testabdeckung der Steuergeräte erhöht werden. Wie gezeigt wurde, ist es mit den 47 unterschiedlichen Steuergeräten im Trainings- und Testfahrzeug möglich, eine zuverlässige Generalisierung der Identifikation herzuleiten, aber nicht mit neuronalen Netzen. Hier ist der zur Verfügung stehende Datensatz zu klein. Aber mit der vorgestellten Datentransformation könnten Daten für ML zugänglich gemacht werden, um diese Untersuchung voranzutreiben.

Literaturverzeichnis [1] Abramowitsch, Dipl.-Inf. T.: SOVD – Hands On. Kap. 10, S. 140–157. Dresden, Deutschland : TUDpress, 2022 [2] Amato, Markus: Maximale Effizienz durch parallelen Remote-Zugriff. Kap. 9, S. 129–139. Dresden, Deutschland : TUDpress, 2022 [3] Arundel, Justin: Cloud Native DevOps mit Kubernetes; Bauen, Deployen und Skalieren moderner Anwendungen in der Cloud. Heidelberg, Deutschland : dpunkt.verlag, 2019. – ISBN 978-3-86490-698-5 [4] Aust, Holger: Das Zeitalter der Daten : Was Sie über Grundlagen, Algorithmen und Anwendungen wissen sollten. Bonn, Deutschland : Springer, 2021. – ISBN 978-3-662-62335-0 [5] Baun, Prof. Dr. C.: Computernetze kompakt : Eine an der Praxis orientierte Einführung für Studium und Berufspraxis. Frankfurt am Main, Deutschland : Springer Vieweg, 2020. – 266 S. – ISBN 978-3-662-59896-2 [6] Beierlein, Prof. Dr.-Ing. T. ; Hagenbruch, Prof. Dr.-Ing. O.: Taschenbuch Mikroprozessortechnik. Mittweida, Deutschland : Hanser, 2011. – ISBN 978-3-446-42331-2 [7] Borgeest, Kai: Elektronik in der Fahrzeugtechnik Hardware, Software, Systeme und Projektmanagement. Aschaffenburg, Deutschland : Springer Vieweg, 2021. – 506 S. – ISBN 978-3-658-23663-2 [8] Burns, Joe; Hightower K.: Kubernetes : Eine kompakte Einführung. Heidelberg, Deutschland : dpunkt.verlag, Dezember 2021. – URL https://www.ebook.de/de/product/39543549/brendan_ burns_joe_beda_kelsey_hightower_kubernetes.html. – ISBN 9783-86490-803-3 [9] B¨ohlen, Dr. Oliver; Becker Dr. Simon; Stoffel Dr. R.: Diagnose von HPCs über SOVD. Kap. 8, S. 113–128. Dresden, Deutschland : TUDpress, 2022

© Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 R. T. Lutchen, Optimierung der Fahrzeugdiagnose durch eine cloudbasierte Methode zur Identifikation der Datennetze mit künstlicher Intelligenz, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-43113-6

134

Literaturverzeichnis

[10] Capci, Onur Z.: Konstruktion der Daten-Pipeline eines Machine Learning Konzeptes zur Identifikation von Fahrzeugkommunikationsdaten. Mai 2021 [11] Cheng, Yajun: Methode zur Optimierung der Diagnoseskriptbedatung basierend auf Algorithmen der künstlichen Intelligenz. Dezember 2019 [12] Cunis, Dr. R.: Vernetzte Diagnose für vernetzte Fahrzeuge. Kap. 2, S. 12–26. Dresden, Deutschland : TUDpress, 2022 [13] Dowalil, Herbert: Modulare Softwarearchitektur. Niederösterreich : Hanser, Juli 2020. – URL https://www.ebook.de/de/product/39121366/ herbert_dowalil_modulare_softwarearchitektur.html. – ISBN 978-3-446-46377-6 [14] Eilebrecht, Karl ; Starke, Dr. G.: Patterns kompakt. Karlsruhe, Deutschland : Springer Vieweg, 2019. – 239 S. – ISBN 978-3-662-57936-7 [15] emotive: emotive Wiki: CAN. Webseite: Online am 04.06.2022 abgerufen unter https://ssl.emotive.de/wiki/index.php?title=CAN. Juni 2022. – Webseite: Online am 04.06.2022 abgerufen unter https://ssl.emotive. de/wiki/index.php?title=CAN [16] Ernesti, Peter: Python 3 : Das umfassende Handbuch : Sprachgrundlagen, Objektorientierte Programmierung, Modularisierung. Bonn, Deutschland : Rheinwerk Computing, 2017. – ISBN 978-3-836-25864-7 [17] Ertel, Prof. Dipl.-Math. E.: Angewandte Kryptographie. Ravensburg, Deutschland : Hanser, 2020. – ISBN 978-3-446-46313-4 [18] Fauss, Jascha: Methode zur automatisierten Erweiterung von Diagnosekonfigurationen im Umfeld der Fahrzeugentwicklung. September 2018 [19] Freeman, Eric ; Robson, Elisabeth ; Sierra, Kathy ; Bates, Bert: Entwurfsmuster von Kopf bis Fuß. Heidelberg, Deutschland : O’Reilly, November 2022. – URL https://www.ebook.de/de/product/41024495/eric_freeman_ elisabeth_robson_kathy_sierra_bert_bates_entwurfsmuster_ von_kopf_bis_fuss.html. – ISBN 978-3-96009-162-2 [20] Freiknecht, Jonas ; Papp, Stefan: Big Data in der Praxis Lösungen mit Hadoop, Spark, HBase und Hive. Daten speichern, aufbereiten, visualisieren. Karlsruhe, Deutschland : Hanser, 2018. – ISBN 978-3-446-45396-8

Literaturverzeichnis

135

[21] Frochte, Prof. Dr. rer. nat. J.: Maschinelles Lernen : Grundlagen und Algorithmen in Python. Bochum, Deutschland : Hanser, 2018. – ISBN 978-3-44645291-6 [22] Grossmann, Kevin: Analyse und Integration einer Software zur Bearbeitung von Powertrain-Releasepaketen. November 2018 [23] G´eron, Aurélien: Praxiseinstieg Machine Learning : mit Scikit-Learn, Keras und TensorFlow : Konzepte, Tools und Techniken für intelligente Systeme. Heidelberg, Deutschland : O’Reilly, 2020. – ISBN 978-3-960-09124-0 [24] Hagen, Lars: Neue Möglichkeiten für die Motorsteuergeräte-Software durch Car-to-Cloud-Vernetzung. Stuttgart, Deutschland : Springer Vieweg, 2020. – ISBN 978-3-658-31564-1 [25] Halimi, Sami E.: Implementierung einer Blockchain-Applikation zur sicheren Vorhaltung von sensiblen Daten im Umfeld der Fahrzeugdiagnose. Mai 2022 [26] Hehl, Walter: Klimawandel – Grundlagen und Spekulation : Wie und warum es so kommen musste und weiter kommen muss. Thalwil, Schweiz : Springer, 2021. – ISBN 978-3-658-35540-1 [27] Heine, Dipl.-Ing. Florian; Fink-Dipl.-Ing. Bernhard; Bäker Prof. Dr.-Ing. B.: Distributed Tracing im Fahrzeug. Kap. 5, S. 62–78. Dresden, Deutschland : TUDpress, 2022 [28] Heinz, Dipl.-Ing. A. ; Grimm, Dr.-Ing. M. ; Reuss, Prof. Dr.-Ing. H.-C.: Beitrag zur effektiven Messdatenerfassung zur Realisierung von Off-Board gestützter präventiver Fahrzeug- und System-Diagnose. Kap. 3, S. 27–46. Dresden, Deutschland : TUDpress, 2022 [29] ISO copyright office (Veranst.): INTERNATIONAL STANDARD - ISO22901 - Road vehicles - Open diagnostic data exchange (ODX). 2008. – E-mail: [email protected] - Web: www.iso.org [30] ISO copyright office (Veranst.): INTERNATIONAL STANDARD - ISO13400 - Road vehicles - Diagnosticcommunication over Internet Protocol(DoIP). 2011. – E-mail: [email protected] - Web: www.iso.org

136

Literaturverzeichnis

[31] ISO copyright office (Veranst.): INTERNATIONAL STANDARD - ISO13209 Road vehicles - Open Test sequenceeXchange format (OTX). 2012. – E-mail: [email protected] - Web: www.iso.org [32] ISO copyright office (Veranst.): INTERNATIONAL STANDARD - ISO14230 - Road vehicles — Diagnosticcommunication over K-Line. 2012. – E-mail: [email protected] - Web: www.iso.org [33] ISO copyright office (Veranst.): INTERNATIONAL STANDARD - ISO14229 - Road vehicles - Unified diagnosticservices (UDS). 2013. – E-mail: [email protected] - Web: www.iso.org [34] ISO copyright office (Veranst.): INTERNATIONAL STANDARD - ISO11898 - Road vehicles - Controller areanetwork (CAN). 2016. – E-mail: [email protected] - Web: www.iso.org [35] ISO copyright office (Veranst.): INTERNATIONAL STANDARD - ISO15765-2 - Road vehicles - Diagnosticcommunication over Controller AreaNetwork (DoCAN). 2016. – E-mail: [email protected] - Web: www.iso.org [36] Kloep, Karsten;Momber-Kevin;Rojas Raphael;Frankl-Annette: Windows Server 2019. Bonn, Deutschland : Rheinwerk Computing, 2019. – ISBN 978-3-8362-6657-4 [37] Kloep, Peter ; Weigel, Karsten: Sichere Windows-Infrastrukturen : Das Handbuch für Administratoren. Bonn, Deutschland : Rheinwerk Computing, September 2020. – URL https://www.ebook.de/ de/product/39014459/peter_kloep_karsten_weigel_sichere_ windows_infrastrukturen.html. – ISBN 978-3-836-27321-7 [38] Kost, Armin: Methode zur automatisierten Ermittlung von PowertrainReleasepaketen. September 2018 [39] Kotz, Jürgen ; Wenz, Christian: C# und .NET 6 - Grundlagen, Profiwissen und Rezepte. München, Deutschland : Hanser, April 2022. – URL https: //www.ebook.de/de/product/41950126/juergen_kotz_christian_ wenz_c_und_net_6_grundlagen_profiwissen_und_rezepte.html. – ISBN 978-3-446-46930-3

Literaturverzeichnis

137

[40] Krausz, Barbara: Methode zur Reifegradsteigerung mittels Fehlerkategorisierung von Diagnoseinformationen in der Fahrzeugentwicklung. Stuttgart, Deutschland : Springer Vieweg, 2018. – 148 S. – ISBN 978-3-658-24017-2 [41] Krieger, Olaf: Wahrscheinlichkeitsbasierte Fahrzeugdiagnose mit individueller Prüfstrategie. Lostau, Deutschland, Technischen Universität Braunschweig, phdthesis, Juni 2011 [42] Krypczyk, Veikko ; Bochkor, Olena: Handbuch für Softwareentwickler. Bonn, Deutschland : Rheinwerk Computing, 2018. – ISBN 978-3-8362-4476-3 [43] Kr¨utzfeldt, Marc S.: Verfahren zur Analyse und zum Test von Fahrzeugdiagnosesystemen im Feld. Stuttgart, Deutschland : Springer Vieweg, 2014. – ISBN 978-3-658-08862-0 [44] Lasmar, Nihed: Erstellung modularer Powertrain-OTX-Skripte für den Einsatz auf unterschiedlichen Diagnosesystemen. Januar 2019 [45] Liebel, Oliver: Skalierbare Container-Infrastrukturen. Bonn, Deutschland : Rheinwerk Computing, 2021. – ISBN 978-3-8362-7772-3 [46] Lilienthal, Dr. C.: Langlebige Software-Architekturen. Hamburg, Deutschland : dpunkt, Dezember 2019. – URL https: //www.ebook.de/de/product/38001529/carola_lilienthal_ langlebige_software_architekturen.html. – ISBN 978-3-86490729-6 [47] Luksa, Marko: Kubernetes in action; Anwendungen in KubernetesClusternbereitstellen und verwalten. Flensburg, Deutschland : Hanser, Juli 2018. – URL https://www.ebook.de/de/product/31060026/marko_ luksa_kubernetes_in_action.html. – ISBN 978-3-446-45510-8 [48] Lutchen, Ralf: Fahrzeug-Diagnose über Ethernet - Entwicklung einer Fahrzeugsimulation zur Validierung der Diagnosefunktionen von Diagnosetools über Ethernet nach ISO 13400 DoIP (Anforderungen, Umsetzung und Problematik). September 2015 [49] Lutchen, Ralf: Automatische Verschleißerkennung bei Transporteinheiten in einem direktangetriebenen linearen Transportsystem. März 2016

138

Literaturverzeichnis

[50] Lutchen, Ralf ; Kr¨atschmer, Andreas ; Reuss, Prof. Dr.-Ing. H.-C.: Concept for the Automatic Generation of Individual Test Sequences Verified by Artificial Intelligence Algorithms. Kap. Band 2 - Test II, S. 95 – 104. In: FKFS (Hrsg.): 21. Internationales Stuttgarter Symposium. Stuttgart, Deutschland : Springer Fachmedien Wiesbaden, 2021. – ISBN 978-3-658-33520-5 [51] Lutchen, Ralf ; Kr¨atschmer, Andreas ; Reuss, Prof. Dr.-Ing. H.-C.: AI-based classification of CAN measurments for network and ECU identification. In: Automotiv and Engine Technology. Stuttgart : Springer, 2022 [52] Lutchen, Ralf ; Kr¨atschmer, Andreas ; Reuss, Prof. Dr.-Ing. H.-C.: Method for the Automatic Generation of Vehicle-Specific Individual Test Sequences. Kap. Band 2 - Test II. In: FKFS (Hrsg.): 22. Internationales Stuttgarter Symposium. Stuttgart : Springer Fachmedien Wiesbaden, 2022 [53] L¨ammel, Prof. Dr. rer. nat. J.: Künstliche Intelligenz : Wissensverarbeitung Neuronale Netze. Wismar, Deutschland : Hanser, 2020. – ISBN 978-3-44645914-4 [54] Martin, Robert C.: Clean Architecture. Frechen, Deutschland : mitp, Februar 2018. – URL https://www.ebook.de/de/product/31137706/robert_ c_martin_clean_architecture.html. – ISBN 978-3-958-45724-9 [55] Metzner, Prof. Dr. A.: Software-Engineering - Kompakt. Augsburg, Deutschland : Hanser, 2020. – ISBN 978-3-446-45949-6 [56] M¨uller, Andreas C. ; Guido, Sarah: Einführung in Machine Learning mit Python. Heidelberg, Deutschland : O’Reilly, Juni 2017. – URL https:// www.ebook.de/de/product/28692616/andreas_c_mueller_sarah_ – guido_einfuehrung_in_machine_learning_mit_python.html. ISBN 978-3-96009-049-6 [57] Nolting, Michael: Künstliche Intelligenz in der Automobilindustrie. Hannover, Deutschland : Springer, 2021. – ISBN 978-3-658-31566-5 [58] Quaschning, Prof. Dr.-Ing. habil. V.: Erneuerbare Energien und Klimaschutz Hintergründe - Techniken und Planung - Ökonomie und Ökologie - Energiewende. Berlin, Deutschland : Hanser, 2021. – ISBN 978-3-446-46867-2 [59] Rashid, Tariq: Neuronale Netze selbst programmieren. Heidelberg, Deutschland : O’Reilly, 2017. – ISBN 978-3-96009-043-4

Literaturverzeichnis

139

[60] Reuss, Prof. Dr.-Ing. H.-C.: Embedded Controller und Datennetze im Kraftfahrzeug. 2020 [61] Schacht, Sigurd ; Lanquillon, Carsten: Blockchain und maschinelles Lernen. Heilbronn, Deutschland : Springer Vieweg, 2019. – 220 S. – ISBN 978-3662-60407-6 [62] Sch¨auffele, Dr. T.: Automotive Software Engineering Grundlagen, Prozesse, Methoden und Werkzeuge effizient einsetzen. Erligheim, Deutschland : Springer Vieweg, 2016. – 334 S. – ISBN 978-3-8348-2469-1 [63] Sch¨utz, Tobias: Blockchain für Entwickler : Grundlagen, Programmierung, Anwendung. Bonn, Deutschland : Rheinwerk Computing, Februar 2019. – URL https://www.ebook.de/de/product/34756687/andreas_ – schuetz_tobias_fertig_blockchain_fuer_entwickler.html. ISBN 978-3-836-26390-0 [64] Specht, Dipl.-Ing. Bernd Gottschalk; Dipl.-Ing. (FH) A.: Diagnose – Next Generation. Kap. 1, S. 11–13. Dresden, Deutschland : TUDpress, 2022 [65] Stan, Cornel: Automobile der Zukunft, mehr als nur elektrisch, digital, autonom. Markkleeberg, Deutschland : Springer, 2021. – 490 S. – ISBN 978-3-662-64115-6 [66] Starke, Dr. G.: Effektive Softwarearchitekturen. Köln, Deutschland : Hanser, 2020. – ISBN 978-3-446-46376-9 [67] Stender, Daniel: Cloud-Infrastrukturen. Bonn, Deutschland : Rheinwerk Computing, 2020. – ISBN 978-3-8362-6948-3 [68] Toth, Stefan: Vorgehensmuster für Softwarearchitektur. Hamburg, Deutschland : Hanser, 2019. – ISBN 978-3-446-46004-1 [69] Vector Informatik GmbH (Veranst.): Specification CAN, Log & Trigger, ASC Logging Format. 1.4.7. März 2018 [70] Weidmann, Dipl.-Ing. B.: SOVD 1.0 – Der Standard erklärt. Kap. 7, S. 94–112. Dresden, Deutschland : TUDpress, 2022 [71] Welt, Carmen: Entwicklung KI-basierter Ansätze zur Identifikation von Fahrzeugsteuergeräten auf Grundlage des Full-CAN-Trace. März 2022

140

Literaturverzeichnis

[72] Winkelhake, Uwe: Die digitale Transformation der Automobilindustrie. Heidelberg, Deutschland : Springer Vieweg, 2021. – ISBN 978-3-662-621011 [73] Wolf, Prof. Dr.-Ing. F.: Fahrzeuginformatik : Eine Einführung in die Softwareund Elektronikentwicklung aus der Praxis der Automobilindustrie. ClausthalZellerfeld, Deutschland : Springer Vieweg, 2018. – 314 S. – ISBN 978-3658-21223-0 [74] Xie, Zuqing: Untersuchung von Gemeinsamkeiten der Fahrzeugnetzwerke auf Identifikationsmerkmale zur Implementierung einer Netzwerkstrukturdarstellung. November 2019 [75] Zai, Alexander ; Brown, Brandon: Einstieg in Deep Reinforcement Learning. Bochum, Deutschland : Hanser, 2020. – ISBN 978-3-446-45900-7 [76] Zimmermann, Prof. Dr.-Ing. W. ; Schmidgall, Dr. R.: Bussysteme in der Fahrzeugtechnik. Esslingen, Deutschland : Springer Vieweg, 2014. – ISBN 978-3-658-02418-5

Glossar .NET Framework

Ist eine Software Plattform von Microsoft zur Unterstützung der Software-Entwicklung. Weitergehende Informationen in [39]

Bluetooth

Ein Nahfeld Funkstandard für die Kommunikation von zwei oder mehr Geräten. Hierbei handelt es sich um eine mögliche Implementierung des pysikalischen Layers einer A-Eth-Anwendung, die entwickelt wurde, um mit einem unisolierten Twistet-Pair-Kabel Daten im Vollduplex mit hoher Bandbreite zu übertragen. Als Einschränkung muss die Verkabelung immer eine P2P-Topologie aufweisen. Dieser Standard wurde für die Automobilindustrie entwicklelt und wird dort aufgrund der Vorteile von weniger Gewicht und Kosten vermehrt eingesetzt.

BroadRReach

C# CAN

CAN-ext

CAN-FD

CanOE

Ist eine Programmiersprache des .NET Framework. Weitergehende Informationen in [39] Standartisiertes Bussyststem welches in einem KFZ vorzugsweise eingesetzt wird. Wurde von der Firma Bosch entwickelt und hat sich zum weltweiten Standard durchgesetzt. Es kommt eine Bustopologie zum Einsatz. Zudem ist es ein Multimaster-System, in dem die Wichtigkeit der Nachricht über den Buszugriff entscheidet. Es können statt 11 bit an Identifyer hier 29 bit verarbeitet werden. Das bedeutet, wenn 211 = 2048 Identifyer für die Einzigartigkeit der übertragenen Daten nicht mehr ausreichen, können alternativ 229 = 536.870.912 eingesetzt werden. Das Datenfeld des CAN-Frame ist nicht mehr auf 8 Byte begrenzt, sondern kann auf bis zu 64 Byte in gewissen Stufen ansteigen. Damit die Framedauer gleichbleibt, müssen die Daten entsprechend schneller übertragen werden. Eine Software der Firma „Vector Informatik GmbH“, mit der die reine CAN-Bus-Kommunikation aufgezeichnet und betrachtet werden kann.

© Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 R. T. Lutchen, Optimierung der Fahrzeugdiagnose durch eine cloudbasierte Methode zur Identifikation der Datennetze mit künstlicher Intelligenz, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-43113-6

142

Glossar

Cloud

Ein Rechenzentrum (Backend) im öffentlichen Raum oder firmenintern, das verschiedene Dienste anbietet.

DevOps

Ein aktueller Trend in der IT, bei dem Versucht wird, die Softwareentwicklung DEV mit der Softwareadministration OPS zu kombinieren. Dabei soll ein Prozess entstehen, durch den Software vollautomaisch getestet und veröffentlicht wird. Eine Virtualisierung einer Applikation ohne Betriebssystem.

Docker FlexRay

frame

Ist ein im Automotive Bereich eingesetztes Bussystem, welches verwendet wird, wenn Nachrichten höchste Ansprüche an harte Echtzeit und Fehlertoleranz besitzen, z. B. wenn das Lenkrad nicht physisch mit dem Lenkgetriebe verbunden ist, sondern diese Funktion mit dem Flexray-Bus erfolgt. (engl. Steer-by-Wire) Eine Nachricht eines Protokolls, die in einem Netzwerk übertragen werden soll.

Hadoop

Ein von Google entwickeltes Filesystem, das auf einem Servercluster betrieben werden kann, um Daten aus einem Big-Data-Prozess in Echtzeit zu übertragen.

Korrelation

„Die Korrelation ist eine Kennzahl, die die Ähnlichkeit zweier Systeme angibt. Diese Kennzahl ist Mittelwert belastet.“ [49] „Der Korrelationskoeffizient ist die bereinigte Kovarianz. Hierbei handelt es sich um eine einheitenlose Zahl, mit der die Ähnlichkeit von zwei Systemen in Prozent angegeben werden kann.“ [49]

KorrelationsKoeffizent

Master/SlavePrinzip

Ein Netzwerkteilnehmer ist der Master, alle anderen Kommunikationsteilnehmer sind die Slaves. Der Master kümmert sich um den Kommunikationsaufbau und um den Nachrichtenaustausch. Der Master frägt die Messwerte seiner Teilnehmer an, welche dann die Daten auf den Bus legen, damit der Master diese erhält. Der Slave kann keine Nachricht auf den Bus legen ,ohne dass der Master diese angefragt hat.

Glossar Metadaten

Mock

MultiMasterPrinzip

143 Sind spezielle Daten, die ein Datenobjekt begleiten können, durch die das Objekt detaillierter beschrieben wird. Bei einem Bild kann das z. B. die Größe in horizontalen und vertikalen Pixeln sein. Bei einer Fahrzeugmessung z. B. die Position, an der die Messung gestartet wurde. Prinzipiell ist der Entwickler frei, was er zusätzlich übertragen möchte und wie er dann in der SW darauf reagieren möchte. Ein Mock ist eine simulierte Schnittstelle in der SW-Entwicklung, bei der die Antwort einer Funktion/Methode nicht von einer realen Ressource z. B. Datenbank angefragt wird, sondern immer die gleiche Antwort auf die gleiche Anfrage (idempotent) von einer lokalen Instanz generiert wird. Das vereinfacht das Testen bei gleichzeitig hoher Testabdeckung. Jeder Busteilnehmer ist ein Master und überwacht selbstständig das Medium. Wenn ein Teilnehmer eine Nachricht auf den Bus legen möchte, muss er unter Umständen mit den anderen Busteilnehmern darum konkurrieren. In einem Multi-Master-System werden nicht die Teilnehmer adressiert, sondern die Nachrichten. Der Nachrichten-Identifier gibt zugleich auch die Priorität der Nachricht an. Wenn ein Teilnehmer seine Nachricht auf den Bus übertragen möchte, muss er mit der Priorität der Nachricht die Arbitrierung gewinnen.

Nominalskala

Eine nominale Skala zeichnet sich dadurch aus, dass jeder annehmbare Wert in keinem Verhältnis zu den anderen steht (sortiert aber nicht geordnet werden kann). Eine ordinale Skala ist bspw. die Notenskala, hier ist eine 1,0 „besser“ als eine 1,3 wobei die Notenskala ebenfalls als eine Intervallskala betrachtet werden kann. Eine klassische Intervallskala ist die Abfrage in einem Fragebogen (Auf einer Skala von 0-10 Wie fühlen Sie sich?).

Off-Board

Hierbei handelt es sich in der Fahrzeugentwicklung um die Kommunikation, die Steuergeräte mit Messwerkzeugen aufbauen, beispielsweise der IoT-Diagnosetester aus dieser Arbeit. Hierbei handelt es sich in der Fahrzeugentwicklung um die Kommunikation, die Steuergeräte untereinander haben um den Fahrbetrieb zu gewährleisten.

On-Board

144

Glossar

Pipeline

„Das Pipelining dient der Erhöhung der Taktrate und damit der Erhöhung der Verarbeitungsgeschwindigkeit. Die Erhöhung der Taktrate erreicht man dadurch, dass ein Befehl in mehrere Teiloperationen zerlegt und in jedem Taktzyklus ein neuer Befehl in die Pipeline eingespeist wird. Teiloperationen mehrerer Befehle werden zeitgleich versetzt parallel ausgeführt. Die Rechenzeit eines Befehls wird dadurch nicht verringert. Es wird jedoch sichergestellt, dass je Takt ein Befehl abgearbeitet wird.“ [6]

RJ45

Ein RJ45-Stecker ist ein klassischer Ethernet-Netzwerk-Stecker. Mit diesem Stecker kann beispielsweise ein Laptop mit einem Router verbunden werden, damit der Laptop mit anderen Netzwerkteilnemern kommunizieren kann.

Visual Studio

Eine von Microsoft vertriebene Entwicklungsumgebung für das .Net Framework. Weitergehende Informationen in [39]

Zustandsautomat

In der Softwareentwicklung kann die Programmsteuerung durch einen Zustandsautomaten beschrieben werden.

Anhang

A. Scatter-Plot der reduzierten Datenbasis

Abbildung A.1: Scatter-Matrix der reduzierten FCT-Messung als df

© Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert an Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 R. T. Lutchen, Optimierung der Fahrzeugdiagnose durch eine cloudbasierte Methode zur Identifikation der Datennetze mit künstlicher Intelligenz, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-43113-6

146

Anhang

In der Abbildung A.1 ist der Scatter-Plot der reduzierten Datenbasis dargestellt. Mit dieser Grafik verschafft sich ein Data-Scientist einen ersten Überblick welche Informationen in den Daten enthalten sind. Damit werden erste Entscheidungen für Untersuchungen getroffen. Da die Abbildung relativ groß ist, soll sie nur einen groben Überblick geben. Auf der Hauptdiagonalen befinden sich die Histogramme, die bereits bekannt sind aus Kapitel 4.3. In allen anderen sind die Punkte farblich nach den Targets (ECUs) eingefärbt (Hier werden 47 Farben verwendet). Ein DataScientist schaut die einzelnen Merkmale durch und sucht nach einer Separierbarkeit der Klassen.

B. Quellcode B.1 Skriptdurchlaufzeit abschätzen über Normalverteilung Das Python-Skript, mit dem die Normalverteilung der Steuergerätegruppen abgeschätzt wurde, ist in Listing B.1 abgedruckt. Listing B.1: Python: Normalverteilung der Steuergeräte-Abschätzung 01 | 02 | 03 | 04 | 05 |

#Bibliotheken laden import math import numpy as np import matplotlib . pyplot as plt from scipy . stats import norm

07 | 08 |

#Zufaellige Daten erzeugen np.random.seed(42)

10 | 11 | 12 | 13 |

data = np.random.randint (low=20, high=81, size =30000) data = np. sort ( data ) print(f"Array x:{data}") print(f"\n Shape of Array x:{data.shape}")

15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 |

#Erwartungswert - Mittelwert mu = math.ceil (np.mean(data)) print(f"Mittelwert x:{mu}") #Standardverteilung sigma = 8 print(f"Standardabweichung x:{sigma}") #Normalverteilung Dichtefunktion f_von_x = norm.pdf(data, mu, sigma) print(f"Array f(x):{f_von_x}") print(f"\n Shape of Array f(x):{f_von_x.shape}")

Quellcode 25 | 26 | 27 | 28 |

#Normalverteilung Verteilungsfunktion F_von_x =norm.cdf(data, mu, sigma) print(f"Array F(x):{F_von_x}") print(f"\n Shape of Array F(x):{F_von_x.shape}")

30 | 31 | 32 |

FIGSIZE = (21, 15) DEFAULT_FONTSIZE = 20 MYCOLOR = (0.109375, 0.2734375, 0.4609375)

34 | 35 | 36 | 37 |

#define multiple normal distributions fig = plt . figure ( figsize =FIGSIZE) plt . subplot (2, 1, 1) plt . plot ( data , f_von_x, color=MYCOLOR, linewidth=2, label=f’$\mu$: {mu}, $\sigma$: {sigma}’) plt . axvline (x=mu−2*sigma, ymin =0, ymax =0.2, color=’red’, linestyle =’dotted’, linewidth=3, label =f’$\mu$ - 2*$\sigma$’) plt . axvline (x=mu+2*sigma, ymin =0, ymax =0.2, color=’red’, linestyle =’dotted’, linewidth=3, label =f’$\mu$ + 2*$\sigma$’) plt . axvline (x=mu, color=’green’, linestyle =’dotted’, linewidth=3, label =f’$\mu$’) #add legend to plot plt . legend( fontsize =DEFAULT_FONTSIZE) plt . grid () #add axes labels and a title plt . ylabel (’Wahrscheinlichkeit f(x)’, fontsize=DEFAULT_FONTSIZE) plt . xlabel (’Steuergeraetegruppen im Fahrzeug’, fontsize=DEFAULT_FONTSIZE) plt . tick_params( labelsize =DEFAULT_FONTSIZE/1.3) plt . title (’Normalverteilung der Steuergeraetegruppen im Fahrzeug’, fontsize=DEFAULT_FONTSIZE*1.3)

38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 63 | 64 |

plt . subplot (2, 1, 2) plt . plot ( data , F_von_x, color=MYCOLOR, linewidth=2, label=f’$\mu$: {mu}, $\sigma$: {sigma}’) plt . axvline (x=mu−2*sigma, ymin =0, ymax =0.08, color=’red’, linestyle =’dotted’, linewidth=3, label =f’$\mu$ - 2*$\sigma$’) plt . axvline (x=mu+2*sigma, ymin =0, ymax =0.95, color=’red’, linestyle =’dotted’, linewidth=3, label =f’v + 2*$\sigma$’) plt . axvline (x=mu, ymin =0, ymax =0.5, color=’green’, linestyle =’dotted’, linewidth=3, label =f’$\mu$’) #add legend to plot plt . legend( fontsize =DEFAULT_FONTSIZE) plt . grid () #add axes labels plt . ylabel (’kumulierte Wahrscheinlichkeit F(x)’, fontsize=DEFAULT_FONTSIZE) plt . xlabel (’Steuergeraetegruppen im Fahrzeug’, fontsize=DEFAULT_FONTSIZE) plt . tick_params( labelsize =DEFAULT_FONTSIZE/1.3) #Save fig plt . savefig ("D://LaTeX_Projekte/Dissertation/Graph/Gesamtverteilung.pdf", format=’pdf’, bbox_inches="tight", pad_inches=0.1)

147

148

Anhang

B.2 Vergleich der Korrelations-Koeffizienten Das Python-Skript, mit dem die VCI-ARXML-Identifikation abgeschätzt wurde, ist in Listing B.2 abgedruckt. Listing B.2: Python: Korrelations-Koeffizient VCI-ARXML-Identifikation 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 |

#Bibliotheken laden %matplotlib inline import matplotlib import matplotlib . pyplot as plt import matplotlib . cm as cm print("matplotlib version:", matplotlib.__version__) import numpy as np from numpy import dot from numpy.linalg import norm print("NumPy version:", np.__version__), import pymssql

13 | 14 | 15 | 16 |

# Open database connection conn = pymssql.connect( server =’FMSQL1.fkfs.de’, user=’CompDiaClient’, password=’***’, database=’DiagCloud’) cursor = conn. cursor () cursor . execute ( f’SELECT [Bus].[Name] FROM [DiagCloud].[dbo].[Bus] ORDER BY Name;’)

18 | 19 | 20 | 21 | 22 | 23 |

# Abfrage auswerten und Netzwerke erhalten networks = [] row = cursor . fetchone () while row: networks.append(str(row[0])) row = cursor . fetchone ()

25 | 26 | 27 | 28 |

db_dict = {} for bus in networks: cursor = conn. cursor () cursor . execute ( f"SELECT [Service].[MessageId] FROM [DiagCloud].[dbo].[Send] JOIN [Service] ON [Send].[Service_Id] = [Service].[Id] JOIN [Connect] ON [Send].[Connect_Id] = [Connect].[Id] JOIN [Network] ON [Connect].[Network_Id] = [Network].[Id] JOIN [Bus] ON [Network].[Bus_Id] = [Bus].[Id] WHERE [Bus].[DisplayName] = ’{bus}’ AND [Service].[MessageId] < 2048 GROUP BY [Service].[MessageId] ORDER BY [Service].[MessageId] ASC;")

30 | 31 | 32 | 33 | 34 | 35 | 36 | 38 | 39 |

# Abfrage auswerten ids = [] row = cursor . fetchone () while row: ids .append(int(row[0])) row = cursor . fetchone () db_dict [bus] = ids # Close database connection conn. close ()

Quellcode 41 | 42 | 43 | 44 | 45 | 46 |

# Funktionen def betrag_summe(a): value = 0.0 for i in a . values () : value += abs(i) return value

48 | 49 | 50 | 51 | 52 |

def jaccard_similarity (a , b) : a = set(a) b = set(b) j = float(len(a. intersection (b)) ) / len(a.union(b)) return j

54 | 55 | 56 | 57 | 58 |

def cos_similarity (a , b) : a = np.array (a) b = np.array (b) j = float(dot(a, b) /( norm(a)*norm(b))) return j

60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 |

# Korrelations-Koeffizent roh = {} for bus in db_dict . keys () : # Die Arrays muessen gleich lang sein! # 1. One Hot Codierung fuer Messung y_mess_onehot = [1 if i in np.array (y_mess) else 0 for i in range(2047)] # 2. One Hot Codierung fuer Datenbank Bus bus_ids_onehot = [1 if i in np.array ( db_dict [bus]) else 0 for i in range(2047)] value = np. corrcoef (bus_ids_onehot , y_mess_onehot)[0,1] print(bus, ’\t\t’, value) roh[bus]=value print(’------------------------------------------------------------’) print(’Summer der Aehnlichkeitswert vor Normierung:’, betrag_summe(roh)) print(’------------------------------------------------------------’) # Korrigierter Kontingenzkoeffizient roh2 = {} for bus in db_dict . keys () : value = abs(roh[bus]) / betrag_summe(roh) print(bus, ’\t\t’, value) roh2[bus] = value print(’------------------------------------------------------------’) print(’Summer der Aehnlichkeitswert nach Normierung:’, betrag_summe(roh2)) print(’------------------------------------------------------------’)

84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 |

# Jaccard-Koeffizent jac = {} for bus in db_dict . keys () : # Die Arrays muessen gleich lang sein! value = jaccard_similarity ( db_dict [bus], y_mess) print(bus, ’\t\t’, value) jac [bus] = value print(’------------------------------------------------------------’) print(’Summer der Aehnlichkeitswert vor Normierung:’, betrag_summe(jac)) print(’------------------------------------------------------------’) # Korrigierter Kontingenzkoeffizient jac2 = {} for bus in db_dict . keys () :

149

150

Anhang

97 | 98 | 99 | 100 | 101 | 102 |

value = abs(jac[bus]) / betrag_summe(jac) print(bus, ’\t\t’, value) jac2 [bus] = value print(’------------------------------------------------------------’) print(’Summer der Aehnlichkeitswert nach Normierung:’, betrag_summe(jac2)) print(’------------------------------------------------------------’)

104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 |

# Kosinus-Koeffizent cos = {} for bus in db_dict . keys () : # Die Arrays muessen gleich lang sein! # 1. One Hot Codierung fuer Messung y_mess_onehot = [1 if i in np.array (y_mess) else 0 for i in range(2047)] # 2. One Hot Codierung fuer Datenbank Bus bus_ids_onehot = [1 if i in np.array ( db_dict [bus]) else 0 for i in range(2047)] value = cos_similarity (bus_ids_onehot , y_mess_onehot) print(bus, ’\t\t’, value) cos[bus] = value print(’------------------------------------------------------------’) print(’Summer der Aehnlichkeitswert vor Normierung:’, betrag_summe(cos)) print(’------------------------------------------------------------’) # Korrigierter Kontingenzkoeffizient cos2 = {} for bus in db_dict . keys () : value = abs(cos[bus]) / betrag_summe(cos) print(bus, ’\t\t’, value) cos2[bus] = value print(’------------------------------------------------------------’) print(’Summer der Aehnlichkeitswert nach Normierung:’, betrag_summe(cos2)) print(’------------------------------------------------------------’)

128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 |

# In cm, Width x Height FIGSIZE = (21, 15) # Basic fontsize, calculated in px, must be tuned to fig sizes DEFAULT_FONTSIZE = 20 # Farbe MYCOLOR = (0.109375, 0.2734375, 0.4609375) MYCOLOR2 = (62/255, 68/255, 76/255) # 62,68,76 MYCOLOR3 = (0/255, 81/255, 156/255) # 0,81,156

137 | 138 | 139 | 140 |

#Scatter- und Bar-Plot zur bestimmung des zuverlaessigsten Algorithmus fig = plt . figure ( figsize =FIGSIZE) X = np.arange(len(ecus)) colors = cm.winter(np. linspace (0, 1, X.shape[0]+1))

142 | 143 | 144 | 145 | 146 | 147 | 148 |

#add 1st Plot plt . subplot (2, 1, 1) for bus,x_val , color in zip(db_dict . keys () , X,colors ) : y = np.array ( db_dict [bus]) y_mess = train_df ["Id"]. drop_duplicates (keep=’first’).sort_values() x = np. linspace (x_val , x_val , num=len(y), endpoint=True, retstep =False, dtype=int, axis=0) x_mess = np. linspace (x_val , x_val , num=len(y_mess), endpoint=True, retstep =False, dtype=int, axis=0) if x_val == 0: plt . scatter (x_mess, y_mess, color=’red’, marker ="s", linewidth =3, label =f’Messung’) else:

149 | 150 | 151 |

Quellcode 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 |

plt . scatter (x_mess, y_mess, color=’red’, marker ="s", linewidth =3) plt . scatter (x, y, color=MYCOLOR, alpha=0.5, linewidth=3, marker ="s", label=f’{bus}’) #add legend to plot plt . legend( fontsize =DEFAULT_FONTSIZE) plt . grid () #add axes labels and a title plt . xticks (X) plt .xlim ([−0.5, len(ecus)+1.1]) plt .ylim ([0,2100]) plt . xlabel ("BusNumber der Datenbank", fontsize=DEFAULT_FONTSIZE) plt . ylabel ("Standard Can-IDs (11Bit ~ 0-2047)", fontsize=DEFAULT_FONTSIZE) plt . tick_params( labelsize =DEFAULT_FONTSIZE/1.3) plt . title ("Vergleich der Korrelationskoeffizienten", fontsize=DEFAULT_FONTSIZE*1.3)

166 | 167 | 168 |

#add 2st Plot plt . subplot (2, 1, 2) plt . bar(X, roh2. values () , edgecolor="white", color = MYCOLOR, width = 0.3, linewidth=2, label=f’Korrelations-Koeffizient’) plt . bar(X + 0.3, jac2 . values () , edgecolor="white", color = ’black’, width = 0.3, linewidth =2, label =f’Jaccard-Koeffizient’) plt . bar(X − 0.3, cos2. values () , edgecolor="white", color = MYCOLOR3, width = 0.3, linewidth=2, label=f’Kosinus-Koeffizient’) #add legend to plot plt . legend( fontsize =DEFAULT_FONTSIZE) plt . grid () #add axes labels and a title plt . xticks (X) plt .xlim ([−0.5, len(ecus)+1.1]) plt .ylim ([0,0.4]) plt . xlabel ("BusNumber der Datenbank", fontsize=DEFAULT_FONTSIZE) plt . ylabel ("Korellation zu dem Netzwerk", fontsize=DEFAULT_FONTSIZE) plt . tick_params( labelsize =DEFAULT_FONTSIZE/1.3)

169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 182 | 183 |

151

#save fig plt . savefig ("D://LaTeX_Projekte/Dissertation/Graph/ID_Verteilung_DB_mit_MK.pdf", format=’pdf’, bbox_inches="tight", pad_inches=0.2)

B.3 Vergleich der ML-Modelle in Bezug zur Diagnose-Detektion Das Python-Skript, mit dem die Diagnose-Identifikation abgeschätzt wurde, ist in Listing B.3 abgedruckt. Listing B.3: Python: Diagnose-Identifikation 01 | 02 | 03 | 04 | 05 |

#Bibliotheken laden %matplotlib inline import matplotlib import matplotlib . pyplot as plt import matplotlib . colors as mcolors

152

Anhang

06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 |

import matplotlib . cm as cm print("matplotlib version:", matplotlib.__version__) import numpy as np print("NumPy version:", np.__version__), import sklearn from sklearn . preprocessing import StandardScaler from sklearn . preprocessing import MinMaxScaler from sklearn . preprocessing import RobustScaler from sklearn . metrics import confusion_matrix from sklearn . metrics import precision_score , recall_score from sklearn . metrics import f1_score from sklearn . metrics import ConfusionMatrixDisplay from sklearn . metrics import roc_auc_score from sklearn . neighbors import KNeighborsClassifier from sklearn .svm import LinearSVC from sklearn .ensemble import RandomForestClassifier from sklearn . model_selection import cross_val_predict print("scikit-learn version:", sklearn.__version__) import mglearn import os import pickle import readASCfile.can_einlesen as can_file

29 | 30 |

# Daten einlesen def file_start (name:str, without_duplikates :bool = True, without_canext :bool = True, without_zeros :bool = True): # ASC File einlesen asc_test_car = can_file . CanASCFileRead(filename=name, extension=".asc", header_lines=5) # Dict abholen dataset = asc_test_car . get_dataframe () # Dataframe auslesen df = dataset ["frame"] # Time loeschen del df[’Time’] # 0-Zeilen loeschen if without_zeros : del_index = [] for index , row in df . iterrows () : if row["PB1"] == 0 and row["PB2"] == 0 and row["PB3"] == 0 and row["PB4"] == 0 and row["PB5"] == 0 and row["PB6"] == 0 and row["PB7"] == 0 and row["PB8"] == 0: del_index . append(index) df .drop( del_index , axis=0, inplace =True) # CAN-EXT loeschen loeschen if without_canext : del_index = [] for index , row in df . iterrows () : if row["Id"] >= 2048: del_index . append(index) df .drop( del_index , axis=0, inplace =True) # Duplikate loeschen if without_duplikates : df . drop_duplicates ( subset=None, keep= ’first’, inplace=True, ignore_index=False) print("----------------------------------------------") print(f"Duplikate sind geloescht:\n{df.info()}") print("----------------------------------------------") print(’--------------------------------------’)

31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 |

Quellcode 60 | 61 | 62 |

153

print(f"Das {name}-Fahrzeug wurde erflgreich eingelesen:\n{df.dtypes}") print(’--------------------------------------’) return dataset , df

64 | 65 |

dataset_Test , test_df = file_start ("test_diagnose_can_64630frames") #dataset_Test, test_df = file_start("test_diagnose_can_842852frames")

67 | 68 | 69 |

dataset_Train , train_df = file_start ("train_diagnose_can_82414frames") #dataset_Train, train_df = file_start("train_diagnose_can_1093647frames") #dataset_Train, train_df = file_start("zusammenkopiert_2_PerfektMatch_541124Frames")

71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 |

# Datensatz vorbereiten print(’--------------------------------------’) x_train = train_df . loc [:, "BusNumber":"PB8"] y_train = train_df ["is_UDS"] print(f"x_train.shape: {x_train.shape} y_train.shape: {y_train.shape}") print(’--------------------------------------’) x_test = test_df . loc [:, "BusNumber":"PB8"] y_test = test_df ["is_UDS"] print(f"x_test.shape: {x_test.shape} y_test.shape: {y_test.shape}") print(’--------------------------------------’)

82 | 83 | 84 | 85 | 86 | 87 |

# Skallieren scaler = MinMaxScaler() scaler . fit ( x_train ) scaler . fit ( x_test ) x_train_scaled = scaler . transform ( x_train ) x_test_scaled = scaler . transform ( x_test )

89 | 90 | 91 | 92 | 93 |

scaler2 = StandardScaler () scaler2 . fit ( x_train ) scaler2 . fit ( x_test ) x_train_scaled2 = scaler2 . transform ( x_train ) x_test_scaled2 = scaler2 . transform ( x_test )

95 | 96 | 97 | 98 | 99 |

scaler3 = RobustScaler () scaler3 . fit ( x_train ) scaler3 . fit ( x_test ) x_train_scaled3 = scaler3 . transform ( x_train ) x_test_scaled3 = scaler3 . transform ( x_test )

101 | 102 | 103 |

# Classifikator (FIT) svc_clf = LinearSVC(random_state=47) svc_clf . fit ( x_train_scaled , y_train )

105 | 106 |

random_forest_clf = RandomForestClassifier (max_depth=2, random_state=47) random_forest_clf . fit ( x_train_scaled , y_train )

108 | 109 |

knn_clf = KNeighborsClassifier () knn_clf . fit ( x_train_scaled , y_train )

111 | 112 | 113 | 114 |

print(’--------------------------------------’) print("Train score LinearSVC: {:.2f}".format(svc_clf.score(x_train_scaled, y_train))) print(’--------------------------------------’) print("Train score Forest: {:.2f}".format(random_forest_clf.score(x_train_scaled, y_train)))

154

Anhang

115 | 116 |

print(’--------------------------------------’) print("Train score Neighbor: {:.2f}".format(knn_clf.score(x_train_scaled, y_train)))

118 | 119 | 120 | 121 | 122 | 123 | 124 |

# Model exportieren program_path = os . path . realpath (os . getcwd()) filename = "TrainedLinearSVM" file_extension = ".pkl" filepath = os . path . join (program_path, filename + file_extension ) with open( filepath , "wb") as f : pickle .dump(svc_clf, f , pickle . HIGHEST_PROTOCOL)

126 | 127 | 128 |

# Model importieren with open( filepath , "rb") as f : load_clf = pickle . load( f )

130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 |

# Train Datensatz verwenden y_train_pred_svc = cross_val_predict ( svc_clf , x_train_scaled , y_train , cv=3) print(’--------------------------------------’) print("Confusion Matrix LinearSVC:\n",confusion_matrix(y_train, y_train_pred_svc)) print(’--------------------------------------’) print("Precision LinearSVC:",precision_score(y_train, y_train_pred_svc)) print("Recall LinearSVC:",recall_score(y_train, y_train_pred_svc ) ) print("f1 LinearSVC:",f1_score(y_train, y_train_pred_svc) )

139 | 140 | 141 | 142 | 143 | 144 | 145 |

y_train_pred_forest = cross_val_predict ( random_forest_clf , x_train_scaled , y_train , cv=3) print(’--------------------------------------’) print("Confusion Matrix Forest:\n",confusion_matrix(y_train, y_train_pred_forest)) print(’--------------------------------------’) print("Precision Forest:",precision_score(y_train, y_train_pred_forest ) ) print("Recall Forest:",recall_score(y_train, y_train_pred_forest ) ) print("f1 Forest:",f1_score(y_train, y_train_pred_forest ) )

147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 |

y_train_pred_neighbor = cross_val_predict ( knn_clf , x_train_scaled , y_train , cv=3) print(’--------------------------------------’) print("Confusion Matrix Neighbor:\n",confusion_matrix(y_train, y_train_pred_neighbor)) print(’--------------------------------------’) print("Precision Neighbor:",precision_score(y_train, y_train_pred_neighbor)) print("Recall Neighbor:",recall_score(y_train, y_train_pred_neighbor ) ) print("f1 Neighbor:",f1_score(y_train, y_train_pred_neighbor ) ) print(’--------------------------------------’)

156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 |

# Test Datensatz verwenden y_test_pred_svc = svc_clf . predict ( x_test_scaled ) print(’--------------------------------------’) print("Confusion Matrix LinearSVC:\n",confusion_matrix(y_test, y_test_pred_svc)) print(’--------------------------------------’) print("Precision LinearSVC:",precision_score(y_test, y_test_pred_svc)) print("Recall LinearSVC:",recall_score(y_test, y_test_pred_svc ) ) print("f1 LinearSVC:",f1_score(y_test, y_test_pred_svc) )

165 | 166 | 167 | 168 | 169 | 170 |

y_test_pred_forest = random_forest_clf . predict ( x_test_scaled ) print(’--------------------------------------’) print("Confusion Matrix Forest:\n",confusion_matrix(y_test, y_test_pred_forest)) print(’--------------------------------------’) print("Precision Forest:",precision_score(y_test, y_test_pred_forest ) ) print("Recall Forest:",recall_score(y_test, y_test_pred_forest ) )

Quellcode 171 |

print("f1 Forest:",f1_score(y_test, y_test_pred_forest ) )

173 | 174 | 175 | 176 | 177 | 178 | 179 |

y_test_pred_neighbor = knn_clf . predict ( x_test_scaled ) print(’--------------------------------------’) print("Confusion Matrix Neighbor:\n",confusion_matrix(y_test, y_test_pred_neighbor)) print(’--------------------------------------’) print("Precision Neighbor:",precision_score(y_test, y_test_pred_neighbor)) print("Recall Neighbor:",recall_score(y_test, y_test_pred_neighbor ) ) print("f1 Neighbor:",f1_score(y_test, y_test_pred_neighbor ) )

181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 |

# In cm, Width x Height FIGSIZE = (21, 15) # Basic fontsize, calculated in px, must be tuned to fig sizes DEFAULT_FONTSIZE = 20 # Farbe MYCOLOR = (0.109375, 0.2734375, 0.4609375) MYCOLOR2 = (62/255, 68/255, 76/255) # 62,68,76 MYCOLOR3 = (0/255, 81/255, 156/255) # 0,81,156

190 | 191 | 192 |

#Konfusionmatrix classifiers = [ svc_clf , random_forest_clf , knn_clf , svc_clf , random_forest_clf , knn_clf ] #x_data = [x_train_scaled, x_train_scaled, x_train_scaled, x_test_scaled, x_test_scaled, x_test_scaled] #y_data = [y_train, y_train, y_train, y_test, y_test, y_test] y2_data = [ y_train_pred_svc , y_train_pred_forest , y_train_pred_neighbor , y_test_pred_svc , y_test_pred_forest , y_test_pred_neighbor ] y_data = [ y_train , y_train , y_train , y_test , y_test , y_test ]

193 | 194 | 195 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 |

155

fig , axes = plt . subplots (nrows=2, ncols=3, figsize =FIGSIZE) for cls , y_true , y_pred, ax in zip( classifiers , y_data , y2_data, axes . flatten () ) : #ConfusionMatrixDisplay.from_estimator(cls, x_temp, y_temp, ax=ax, cmap=plt.cm.Blues, normalize=’pred’, values_format=’.2g’) ConfusionMatrixDisplay. from_predictions ( y_true , y_pred, ax=ax, cmap=plt.cm.Blues, normalize=’pred’, values_format=’.2g’) ax. set_title (type(cls) . __name__, fontsize =DEFAULT_FONTSIZE*1.3) ax. set_xlabel ( f’Predicted Label’, fontsize=DEFAULT_FONTSIZE) ax. set_ylabel ( f’True Label’, fontsize=DEFAULT_FONTSIZE) ax. tick_params( axis=’both’, which=’major’, labelsize=DEFAULT_FONTSIZE/1.3) plt . tight_layout () plt .show()

B.4 Docker-CI-Template für die Software-Architektur Ein Beispiel für eine CI-Pipeline in GitLab mit dem Docker Template Mono zeigt der folgende Quellcode Listing B.4. Listing B.4: YML-Docker 01 | 02 |

image: mono:latest stages :

156 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 |

Anhang − build build : stage: build script : − nuget restore − MONO_IOMAP=case xbuild /t:Build /p:Configuration="Release" /p:Platform="Any CPU" CanOEInterpreter.sln artifacts : name: "CanOEInterpreter-$(date +\"%Y%m%d-%H%M%S\")" paths: − CanOEInterpreter / bin / Release / * expire_in : 10 week only: − master