Adaptive AUTOSAR reprogrammiert klassische Steuergeräte
Adaptive AUTOSAR bietet bei der Realisierung von komplexeren Softwarearchitekturen im Fahrzeug eine hohe Flexibilität. Diese Flexibilität der Software benötigt zur Wartung sogenannte Over the Air (OTA) Updates. Mit der EU7-Regulation könnte OTA für Onboard-Monitoring (OBM) sogar regulativ verpflichtend werden.
In Adaptive AUTOSAR gibt es seit dem Release 2019–11 mit dem Update und Configuration-Management (UCM) eine bordeigene Lösung für Updates von Software Clustern (SWC). Die vielen anderen Butter- und Brot-Steuergeräten im Fahrzeug, die weiterhin mit Classic-AUTOSAR oder mit proprietären Lösungen arbeiten, benötigen ebenso eine Lösung. Mit dem neuen Release 2020–11 wurde die UCM-Spezifikation um die Programmierung von Classic- Steuergeräten erweitert. Die gefundene einfache Lösung beruht auf dem seit 2009 in Off-Board-Testern etablierten Standard ISO 22900–2 „Diagnostic-Protocol Data Unit API“, einfach auch als D-PDU API bezeichnet (Bild 1).
OTA Client
Ausgangspunkt des Update Prozesses ist eine als “OTA Client“ bezeichnete adaptive Applikation. Diese für ein Fahrzeug und OEM spezifische Applikation hat die Aufgabe mit einem OEM-Backend in der Cloud oder alternativ mit einem herkömmlichen Werkstatttester zu kommunizieren und die Flash-Daten im Fahrzeug bereitzustellen. Die Kommunikationskanäle und -physik sind hierbei nicht näher von der AUTOSAR-Architektur vorgegeben. Typisch sind aber kryptografisch abgesicherte Verbindungen über ein Funknetz in die Cloud, oder mit einem lokalen Werkstatttester über Ethernet oder CAN.
Die OTA-Client Applikation ist für die externe Kommunikation verantwortlich und abstrahiert diese Kommunikation völlig. Der UCM-Master ist eine davon getrennte adaptive Service-Instanz. Er stellt die Information über Steuergeräte (ECUs), das Fahrzeug selber, die installierte Software und den Status von Aktualisierungskampagnen über ein ARA::COM Interface für den OTA-Client, aber auch für die „Vehicle Driver Application“ und den „Vehicle State Manager“ zur Verfügung. Die letzten beiden Applikationen stellen sicher, dass sowohl der Fahrer einem Update zustimmt und andererseits während einer Aktualisierungskampagne das Fahrzeug nicht in Betrieb genommen werden kann.
Der UCM-Master empfängt, die als Vehicle Packages bezeichneten Flash-Daten eines gesamten Fahrzeuges. Ein Vehicle Package wird typischerweise vom OEM für ein gesamtes Fahrzeug bereitgestellt. Es enthält neben einem einzigen Vehicle Package Manifest eine Kollektion von Software-Paketen für die verschiedenen (virtuellen) Hardware- Plattformen, ECUs und Softwarecluster.
Weiterhin enthält es für jedes Software- Paket eine eindeutige Möglichkeit, dieses seinem UCM-Client zuzuordnen.
Nachdem das Vehicle Package aus Bild 2 von dem UCM-Master korrekt empfangen wurde, kann der Update- Prozess des Fahrzeuges beginnen. Ein Update umfasst jeweils eine oder mehrere Plattformen, ECUs und (Root-) Softwarecluster.
UCM stellt mit Hilfe der Daten aus dem Vehicle Package den zeitlich korrekten Ablauf der Updates sicher.
Dieser Ablauf kann auch mehrere Reboots von ECUs, der adaptiven Plattform und von UCM selbst enthalten. Dazu werden die verschiedenen UCMClients, auch als UCM-Surrogates bezeichnet, in der notwendigen Reihenfolge aufgerufen.
Der UCM-Master beginnt dann die Programmierung eines Software-Paketes (SWP) durch den Aufruf von RequestPackage am OTA-Client, wie in Bild 3 gezeigt wird. Der UCM-Master führt für alle UCM-Clients die folgenden drei Phasen durch. Hierbei hat er alle Abhängigkeiten der verschiedenen Software-Pakete und ECUs untereinander zu berücksichtigen.
Software-Paket Datentransfer
Der Ablauf startet mit dem Transfer der eigentlichen Flash-Daten von OTA-Client über den UCM-Master zu den UCMClients.
Diese Daten werden mit einer zu UDS analogen Reihenfolge von TransferStart, mehreren TransferData gefolgt von einem finalen TransferExit zu den verschiedenen UCM-Clients übertragen.
Dieser Ablauf darf zur Geschwindigkeitsoptimierung auch parallel für verschiedene UCM-Clients erfolgen. Der Flashing Adapter wird daher die Daten zunächst zwischenspeichern.
Nachdem das Einverständnis des Fahrers vorliegt und weitere Vorbedingungen – wie ein Fahrzeugsstillstand – sichergestellt sind, kann nun die eigentliche Reprogrammierung des Classic- Steuergerätes durch den zugeordneten Flashing Adapter erfolgen.
Software-Pakete Bearbeitung
Der UCM Master entscheidet auf Basis der Daten des Vehicle Package wann die Bearbeitung des Software-Paketes im Gesamtablauf stattfinden darf. Er triggert zum definierten Zeitpunkt das Update der ECU durch den Flashing Adapter mit ProcessSw Package an.
Daraufhin führt der Flashing Adapter eine normale UDS Flash-Sequenz aus, so wie sie in der ISO 14229–1:2020 in den Kapiteln 17.2.1.1 „Pre-Programming step of phase #1“ und 17.2.1.2 „Programming step of phase #1 — Download of application software and data“ beschrieben ist. Ein Flashing Adapter kennt und beachtet den für das Steuergerät spezifischen Ablauf und stellt alle notwendigen Daten bereit, z. B. für einen Security Access und das Erase Memory.
Der Flashing Adapter baut zur Übertragung der UDS-Services auf eine im Umfang deutlich reduzierte D-PDU API „C“-Schnittstelle auf. Diese UDS-Daten werden über einen CAN- oder Ethernet- Bus an das zu reprogrammierende Classic- Steuergerät übertragen. Der Flashing Adapter stellt hierzu nur die eigentlichen Binärdaten (PDU‘s) unabhängig von einem Protokoll oder der Implementierung der D-PDU API zur Verfügung. Er kann daher in verschiedenen adaptiven Umgebungen oder unterschiedlichen Hardware Plattformen ohne Änderung genutzt werden.
Nach den TransferExit schließt dieser Ablauf mit der Berechnung und Überprüfung der Checksumme der neu programmierten Applikation der Classic- ECU ab. Das Ergebnis dieses Flashprozess wird abschließend für diesen Schritt an den UCM-Master mit Current- Status=READY zurückgemeldet.
Aktivierung
Nach dem Transfer der Daten zur Classic- ECU überprüft der UCM-Master nochmals die Abhängigkeiten der beteiligten Software Cluster untereinander und die Sicherheitsbedingungen des Fahrzeuges. Im positiven Fall ruft dann
der UCM-Master den Flashing Adapter nochmals mit Activate auf. Dieser Aufruf löst die in der ISO 14229–1:2020 unter Punkt 17.2.1.3 und 17.2.1.4 beschriebenen Post-Programming Schritte zur Finalisierung aus. Insbesondere wird dadurch auch das verbundene Classic Steuergerät durch einen „Hard Reset“ neu gestartet. Der Flashing Adapter beendet seine Tätigkeit mit der Rückmeldung an den OTA-Client, dass das neue Software-Paket CurrentStatus=ACTIVATED ist. Nach dem Ablauf der Reprogrammierung meldet seinerseits der UCM-Master den erfolgreichen Transfer des Pakets mit den State TransferState= IDLE an den OTA-Client und der Ablauf ist abgeschlossen.
Diese Architektur bringt viele Vorteile mit sich:
– Bei der Bereitstellung eines Vehicle Packages macht es für die Software- Pakete keinen Unterschied ob es sich um ein Adaptive- oder Classic- Steuergerät handelt. Ein adaptiver OTA-Client eines OEMs im Fahrzeug, kann somit alle vernetzten Steuergeräte dieses Fahrzeuges aktualisieren.
– Der Flashing Adapter als UCMClient hat nach oben (Layer 7) die AUTOSAR UCM-Schnittstelle und nach unten (Layer 5) die standardisierte D-PDU API-Schnittstelle. Er hängt somit weder von der Hardware noch von Lieferanten eines AUTOSAR-Stacks ab. Zulieferer für Steuergeräte können somit einen parametrisierten Flashing Adapter als AUTOSAR-Applikation zu ihren Classic-Steuergeräten an den OEM liefern um ihre Steuergeräte im Feld zu reprogrammieren.
– Die ISO 22900–2 (D-PDU API) hat sich seit 2008 in vielen Off-Board Diagnosesystemen im Feld bewährt. In der D-PDU API sind alle Protokollparameter und deren Verhalten vollumfänglich standardisiert, was für einen Austausch von Applikationen essenziell ist.
– Der On-Board Flashing Adapter ist in den relevanten Teilen identisch zu einer Off-Board Diagnoseapplikation entsprechend der ISO 22900–3. Dadurch können Flash-Sequenzen einfach zunächst Off-Board entwickelt und getestet werden, bevor sie dann final als Flashing Adapter in eine adaptive AUTOSAR-Umgebung integriert werden.
Fazit
KPIT hat bei mehreren großen OEMs bereits sehr gute Erfahrungen mit einem Vorläufer dieses Konzeptes, bestehend aus OTA-Client und Flashing Adapter, gesammelt. Insbesondere die standardisierten Protokollparameter sind bei notwendigen Anpassungen während einer dynamischen Entwicklung sehr vorteilhaft. Die Fahrzeug-Updates selber verlaufen problemlos, unauffällig und sind leicht zu testen. www.kpit.com
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Dual Banking für reibungslose SOTA-Updates
Bei Dual Banking ist der Speicherbedarf für updatefähige Softwarekomponenten in der ECU doppelt so hoch wie gewöhnlich. Der Speicher wird in zwei als Bank-A und Bank-B bezeichnete gleich große Partitionen aufgeteilt. Von den zwei Bänken ist zu jedem Zeitpunkt jeweils immer eine aktiv und die andere inaktiv. Die neue Software wird laufend in die inaktive Speicherbank heruntergeladen. Nach einem erfolgreichen Software-Update kann die neue Software dann durch Umschalten der Speicherbank ausgeführt werden. Die Funktionsmerkmale des Dual Banking sind in Bild 1 dargestellt.
Hintergrundprogrammierung
Während das Fahrzeug läuft, also während Software aus der aktiven Bank ausgeführt wird, kann das Telematiksteuergerät (TCU) im Fahrzeug die neuen Software-Updates empfangen, die dann in die inaktive Speicherbank der Ziel-ECU geladen werden. Dies wird als Hintergrundprogrammierung bezeichnet, und es gibt dabei keine Fahrzeugausfallzeiten aufgrund eines Software-Updates. Normalerweise wird die Software digital signiert und in die Ziel-ECU heruntergeladen, um nicht authentifizierte Updates zu vermeiden. Auch eine Fahrzeugdiagnose ist während der Hintergrundprogrammierung möglich.
Software- Teildownload
Mit der Software-Teildownloadfunktion ist es nicht erforderlich, bei jedem Software-Update alle Softwarekomponenten einer ECU herunterzuladen. Es besteht die Möglichkeit, nur die überarbeiteten Softwarekomponenten einzeln herunterzuladen, um die Gesamtdauer des Updates zu verkürzen und die damit verbundenen Übertragungskosten zu reduzieren.
Pause, Wiederaufnahme und Abbruch
Während der Hintergrundprogrammierung kann das Software-Update unterbrochen werden, wenn die ECU oder der Server offline geht und dann später bei erneuter Verfügbarkeit fortgesetzt oder abgebrochen werden. Auf diese Weise lassen sich die Gesamtdauer des Software-Updates und die entsprechenden Datenkosten reduzieren. Das unterbrochene/ abgebrochene Software-Update wirkt sich in keiner Weise auf die ECU aus, da es sich in der inaktiven Speicherbank befindet.
Nach einem erfolgreichen Software-Update wird die aktualisierte Software beim nächsten Fahrzeugstart aus der Download-Speicherbank ausgeführt.
Der Kunde kann die aktualisierte Software in ein paar Probeläufen nutzen und sie dann aktivieren, wenn er mit der Leistung der aktualisierten Version zufrieden ist.
Nach der Aktivierung der Software wird die aktive Speicherbank inaktiv und die Probelauf-Speicherbank aktiv. Ist der Kunde mit der Leistung der aktualisierten Software nicht zufrieden, kann er die vorherige Version der Software wiederherstellen, indem er einfach die Speicherbank umschaltet, sodass er von der neuen Version nicht betroffen ist.
Softwaresynchronisation
Sobald das Software-Update aktiviert ist, die frühere Version wiederhergestellt oder auch das Update abgebrochen ist, wird die Software bei laufendem Fahrzeug aus der aktiven Bank in die inaktive Bank kopiert. Dieser Vorgang wird als Softwaresynchronisation bezeichnet und ist nützlich, um zulässige Software in beiden Bänken der ECU sicherzustellen. Ist die Software in der aktiven Speicherbank aus irgendeinem Grund beschädigt, kann die Software aus der inaktiven Bank verwendet werden.
In diesem Fall wird die aktive Bank zur inaktiven und die inaktive Bank zur aktiven, und die Software aus der neuen aktiven Speicherbank wird ausgeführt.
Dies hilft, einen ECU-Ausfall zu verhindern und das Fahrzeug am Laufen zu halten.
Vordergrundprogrammierung
In Servicestellen kann die ECU per OBD neu programmiert werden, um den Bootloader bei Bugfixes, Erweiterungen und neuen Funktionen zu aktualisieren.
Dies verbessert die SOTA-Updatefähigkeit des Fahrzeugs und trägt somit dazu bei, Stillstandszeiten zu vermeiden.
Auch ist es immer möglich, mit einer solchen Vordergrundprogrammierung Komponenten der Anwendungssoftware zu aktualisieren.
Schnellere Umschaltung
Wenn der Ziel-Mikrocontroller in der ECU die Neuzuordnung logischer Adressen zu physikalischen Adressen unterstützt, kann die ECU-Software mit logischen Adressen aufgebaut werden, die sich aus einer beliebigen Bank ausführen lassen. Dies erleichtert eine schnellere Speicherbankumschaltung bei jedem neuen Software-Update und verhindert so mögliche Fahrzeugstartverzögerungen nach einem neuen Software- Update.
SW-Authentifizierung
Das SOTA-Update ist anfällig für Hacker-Angriffe. Um nicht authentifizierte Software-Updates zu vermeiden, muss die ECU-Software mit Signaturalgorithmen wie ECDSA, RSA und anderen digital signiert werden. Während des Software- Updates berechnet die ECU den Hash-Wert und verifiziert die Signatur der heruntergeladenen Software anhand des in der ECU gespeicherten öffentlichen Schlüssels/Zertifikats. Die heruntergeladene Software wird als gültig behandelt, wenn die Signaturverifizierung erfolgreich ist. Dieser sichere Download der Software hilft, die Programmierung nicht authentifizierter Software und somit Fahrzeug-Stillstandszeiten zu vermeiden.
Fazit
Es ist offensichtlich, dass Dual Banking durch die oben erläuterten Funktionen zur Verbesserung des Kundenerlebnisses beiträgt. Des Weiteren können auch Fahrzeugrückrufe wegen Software-Updates und die damit verbundenen Kosten vermieden werden. Eine problemlose Wartung, Software-Updates und -erweiterungen verbessern die Sicherheit und Leistungsfähigkeit des Fahrzeugs.
Dies wiederum führt zu einem besseren Kundenerlebnis ohne Stillstandszeiten während der Software-Updates. W (oe)
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
KPIT erhält von der BMW Group einen wichtigen strategischen Großauftrag für das Ladeelektronikprogramm der nächsten Generation
Die kombinierte Antriebskoordinationseinheit steuert die Leistungselektroni-karchitektur der nächsten Generation von BMW Battery Electric Vehicles (BEV) und umfasst Softwareentwicklung, -integration und -wartung. Die darin integrierte Ladeeinheit ist ein Onbord-Ladegerät, das mit der Fahrzeugsteuereinheit kombiniert ist.
Microfuzzy, ein Unternehmen der KPIT-Gruppe und Nischenspezialist für Fahrzeugelektrifizierungstechnik wird als Elektroantriebsteam zusammen mit KPIT, bei der Umsetzung dieses strategischen Softwareprogramms an vorderster Front stehen und stellt für BMW Group den ersten Schritt im Aufbau strategischer Software-Entwicklungspartner für Automotive-Software dar.
Im Rahmen der strategischen Zusammenarbeit wurde KPIT als Single-Source-Software-Integrator für das kombinierte Ladeelektronikprogramm 11KW der nächsten Generation, für die kommenden BEVs der BMW Group nominiert. MicroFuzzy und KPIT, als strategischer Softwarepartner übernehmen die Rolle für die vollständige Entwicklung, Integration, Validierung und Wartung der Serien-Software, um die Technologien zu beschleunigen, die ein zukünftiges Elektrofahrzeug erfordert.
Kishor Patil, CEO von KPIT Technologies, teilte mit: „Wir freuen uns sehr über die Weitsicht der BMW Group, in Programme zur Fahrzeugelektrifizierung zu investieren, die weitreichende Auswirkungen haben werden. Wir freuen uns, unsere bestehenden Partnerschaften mit der BMW Group zu erweitern und unser Angebot als Software-Integrator zu verstärken.
KPIT ist ein globales Technologieunternehmen mit Softwarelösungen, die die Mobilität in Richtung einer autonomen, sauberen, intelligenten und vernetzten Zukunft unterstützen. Mit mehr als 6500 Automobelievern weltweit, die auf embedded Software, KI- und digitale Lösungen spezialisiert sind, ermöglicht KPIT Kunden die Implementierung von Mobilitätstechnologien der nächsten Generation zu beschleunigen. Mit Entwicklungszentren in Europa, den USA, Japan, China, Thailand und Indien. KPIT arbeitet mit führenden Mobilitätsunternehmen zusammen und ist dort präsent, wo sich das Ökosystem verändert.
Weitere Informationen finden Sie unter www.kpit.com
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
KPIT erweitert seine Präsenz in Europa durch ein neues Software Engineering Center in München
• Größtes Zentrum für Softwareentwicklung und -integration im Bereich Elektrifizierung, autonomes Fahren, AUTOSAR und Fahrzeugdiagnose außerhalb Indiens.
• Wirkungsstätte für Talente aus mehr als 25 europäischen Ländern.
KPIT Technologies, ein führender Softwareintegrationspartner für OEMs und Tier 1s im Automobilsektor, gab heute die Errichtung eines europäischen Software Engineering Centers in München bekannt. Es wird das größte globale Softwareintegrations- und Technologiezentrum von KPIT im Bereich Elektrifizierung, autonomes Fahren, AUTOSAR und Fahrzeugdiagnose sein und darüber hinaus auch über Know-How aus anderen Bereichen, einschließlich Digital Cockpit verfügen. Es wird die anderen globalen Entwicklungszentren von KPIT in den USA, Japan, Thailand, China und Indien ergänzen und dazu beitragen, eine nahtlose Softwarebereitstellung für globale Fahrzeugprogramme zu ermöglichen.
KPIT ist seit über 15 Jahren in Deutschland tätig und zählt führende europäische OEMs und deren Zulieferer zu seinen Kunden. Mit über 700 Mitarbeitern aus mehr als 25 verschiedenen Ländern wird dieser Standort als globales Kompetenzzentrum dienen, um den komplexen Anforderungen an die Software für die Automobilindustrie, speziell in Zeiten erheblicher technologischer Veränderungen, gerecht zu werden. KPIT ist in Europa sowohl organisch als auch durch Akquisitionen und Partnerschaften mit europäischen Technologieunternehmen stetig gewachsen. MicroFuzzy, ein auf Software für die Fahrzeugelektrifizierung spezialisiertes Unternehmen und Teil der KPIT-Gruppe, wird ebenfalls in diesem Zentrum ansässig sein.
Im Interesse der Sicherheit der Mitarbeiter während der Covid-19-Pandemie, wird KPIT in den kommenden Monaten größtmögliche Sicherheitsvorkehrungen für eine phasenweise Belegung für diesen Standort treffen.
Kishor Patil, CEO von KPIT Technologies, kommentierte diesen wichtigen Meilenstein wie folgt: "Europa ist jetzt unser größter Wachstumsmarkt und zeugt von den bedeutenden Investitionen, die wir in den letzten zehn Jahren in Technologien getätigt haben, welche das Automobil- und das Mobilitätsökosystem verändern werden. Die Investition in diesen Standort bekräftigt unser Commitment, die besten Talente zusammenzubringen und Innovationen im Bereich der Automobilsoftware für unsere Kunden weltweit voranzutreiben.
KPIT ist ein globales Technologieunternehmen, das Softwarelösungen anbietet, die der Mobilität zum Sprung in eine saubere, intelligente und sichere Zukunft verhelfen. Mit mehr als 7000+ Automobelievern rund um den Erdball, die sich auf Embedded Software, KI & digitale Lösungen spezialisiert haben, ermöglicht KPIT den Kunden eine schnellere Umsetzung der Mobilitätstechnologien der nächsten Generation. Mit Entwicklungszentren in Europa, den USA, Japan, China, Thailand und Indien arbeitet KPIT mit Marktführern im Bereich der Mobilität zusammen und ist dort präsent, wo sich das Ökosystem wandelt.
Nähere Details finden Sie unter [url=http://www.kpit.com]www.kpit.com[/url]
KPIT Technologies GmbH
Adams-Lehman-Str. 109
80797 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Global Head, Marketing
E-Mail: mohit.kochar@kpit.com
Director – Marketing
E-Mail: sunil.r@kpit.com
Marketing Lead, Germany
E-Mail: Stefanie.koehler@kpit.com
Team Gutenberg
Telefon: +91 8149773632
E-Mail: reema@thegutenberg.com
Diagnose in Adaptive AUTOSAR
Für einen Diagnosetester ändert sich auf den ersten Blick mit Adaptive AUTOSAR nicht viel. Eine D-PDU API wird ein zusätzliches Protokollmodul für Diagnostics over IP (DoIP) besitzen, um mit einer Adaptive AUTOSAR kommunizieren zu können. Weiterhin wird auch noch die UDS- und ISO-Spezifikation um einige neue Fähigkeiten erweitert. Ende 2019 wird die Standardisierung in der ISO abgeschlossen sein. Da bei der Standardisierung Wert auf Evolution und weitgehende Kompatibilität gelegt wurde, gibt es keine tiefgreifenden Änderungen, die hier ein neues Systemdesign in der Diagnose erfordern würden. Es ist zu erwarten, dass diese Änderungen im Laufe des Jahres 2020 in die bereits existierenden off-the-shelf-Tools für Diagnose einfließen werden.
Softwarecluster
Zunächst wird das jeweilige zu diagnostizierende Fahrzeug bei DoiP anhand der Vehicle-Identifikationsnummer (VIN) ausgewählt und dann die Kommunikation mit den einzelnen Steuergeräten über deren Diagnose-Adressen aufgebaut. Eine Herausforderung dabei ist, dass ein adaptives Steuergerät mehrere Diagnose-Adressen gleichzeitig besitzen kann, jeweils eine Diagnose-Adresse pro Softwarecluster (SWC) mit den zugehörigen DiagnosticManager. Ein adaptives Steuergerät besitzt typischerweise dann 5 bis 10 Softwarecluster und damit gleich viele Diagnose-Adressen.
In dem Beispiel in Bild 1 sind zwei (Diagnose-)Anwendungen bei ECAS gegeben. Die Erste fürs Absenken eines Fahrzeuges, um den Einstieg von Fahrgästen zu erleichtern (sog. Kneeling) und die Zweite eine Tiltfunktion zur Überschlagsverhinderung eines Busses. Diese beiden Applikationen müssen nicht gleichzeitig im Software Cluster „ECAS“ aktiv sein. Sie können nach Bedarf dynamisch zur Betriebszeit gestartet und beendet werden.
Applikationen können auch je nach Fahrzeugvariante ganz ein- oder ausgeschaltet sein. Als Beispiel ist im Beispiel ein „Lane Change Assistent“ als kostenpflichtiges Ausstattungsmerkmal dauerhaft deaktiviert oder wird erst im Laufe des Fahrzeuglebens zusätzlich aktiviert. Dies hat zur Folge, dass die Applikationen mit Diagnosefunktionen nicht mehr gleichzeitig vorhanden oder gar dauerhaft im Fahrzeug deaktiviert sind. Ein Tester muss daher mithilfe der VIN die entsprechenden Fahrzeugdaten kennen und verwalten können. Er kann dabei nicht mehr davon ausgehen, dass alle DTC-Informationen der Diagnostic -Manager eines Steuergeräts aktuell oder vorhanden sind.
Für die beiden Softwarecluster, die jeweils ihre eigene Diagnose-Adresse haben, sind entsprechend auch zwei ODX-Datentöpfe notwendig. Im Prinzip ist ein Steuergerät mit Classic AUTOSAR ein Analogon für einen Softwarecluster in Adaptive AUTOSAR. Die Verteilung der Diagnose-Anfragen auf die jeweiligen DiagnosticManager eines Softwareclusters wird durch die AUTOSAR-Umgebung automatisch sicher – gestellt. Insgesamt entsprechen diese Änderungen jedoch mehr einer Evolu tion als einer Revolution.
Interessanter wird es, wenn man die neuen Möglichkeiten eines OnBoard-Diagnosetesters in Verbindung mit einer erweiterten Diagnosefunktionalität im Fahrzeug betrachtet (Bild 2).
OnBoard-Diagnosetester
Heute ist in Classic AUTOSAR eine elektrische Komponentendiagnose üblich. Dabei wird die angeschlossene Hardware zyklisch auf Fehler überprüft und gefundene Fehler im Diagnostics-Management gespeichert. Die bei der Erstellung der Auswirkungsanalyse, also der Failure Mode and Effects Analysis (FMEA), von Fehler einer Komponente festgelegte Fehlerreaktion wird durch das Fehler-Event ausgelöst.
Beispielsweise bei einem „Stuck at High“-Fehler das Öffnen eines Low-Side-Treibers, um einen dauerhaft fehlerhaft bestromten Aktor auf einen zweiten unabhängigen Weg abschalten zu können. Damit ist zunächst das elektrische Problem auf der Komponentenebene abschließend behandelt, mit der Konsequenz, dass eine Schaltfunktion und damit mindestens ein Aktor ausfällt.
Der Ausfall eines Aktors hat natürlich Auswirkungen auf das System, in dem er eingebunden ist. Damit diese Auswirkungen korrekt berücksichtigt werden, gibt es in AUTOSAR das Konzept von Events, mit denen andere Applikationen über aufgetretene Änderungen informiert werden können. Der Ausfall dieser Schaltfunktion hat beispielsweise zur Folge, dass die Funktion „Liftachse senken“ eines Nutzfahrzeugs auf der Systemebene nicht mehr zur Verfügung steht. Auf dieser Ebene erhält die betroffene Funktion dann ebenfalls einen entsprechenden Fehlercode. Die Auswirkungen auf das System, am Beispiel ECAS, wird in der System-FMEA betrachtet und weitere Folgeaktionen per Event ausgelöst, was im ECAS-Beispiel das Sperren der Funktion „Funktionsliftachse heben“ zur Folge hat, um hier eine Reduzierung der zulässigen Zuladung durch das technisch noch mögliche Anheben der Liftachse zu vermeiden.
Der Ausfall der Systemfunktion „Liftachse“ wirkt sich unterschiedlich aufs Fahrzeug aus. Wenn die aktuelle Liftachse abgesenkt bleibt, beeinträchtigt das nur die Systemeigenschaften und führt zu einer schlechteren Lenkbarkeit, einem erhöhtem Kraftstoffverbrauch und Verschleiß der Reifen.
Im Falle des Ausfalls einer gehobenen Liftachse, ist die noch zur Verfügung stehende Nutzlast reduziert, was erhebliche Auswirkungen auf die Verfügbarkeit des Fahrzeugs und evtl. die Notwendigkeit eines OnRoad-Services des Fahrzeugs zur Ladungsreduzierung bedeutet.
Ein OnBoard-Diagnosetester sammelt hier die eintreffenden Fehlerereignisse über DoIP, trifft daraufhin Entscheidungen, wie weiter mit der Situation zu verfahren ist und steht natürlich bei Onoder Off-Road-Services für weitere Analysen zur Verfügung. Der OnBoard- Tester kann hierbei nicht nur auf originäre UDS-Diagnose-Informationen zugreifen, sondern für tiefere Analysen auch selbst als Adaptive-AUTOSAR-Applikation über die ARA::COM-Schnittstelle aktiv auf weiteren Schnittstellen von anderen Applikation zugreifen.
Die zu analysierenden Datenmengen und gegenseitige Abhängigkeiten der Steuergeräte mit ihren Applikationen in der Steuergeräte-Entwicklung steigen und machen damit die Diagnose-Entwicklung komplexer. Die klassische Trennung zwischen Steuergeräte- und (Aftersales)-Diagnose-Entwicklung in der Zukunft muss daher aufgehoben werden, um hier noch effektivere und effizientere Entwicklungen zu ermöglichen.
Diagnose-Tools Mit den Anforderungen an ein Fahrzeug, inklusive der vorgesehenen Variabilität, startet der E/E-Entwicklungsprozess (Bild 3). Stand der Technik ist hier ein Import der Spezifikationsdaten eines Anforderungs-Managementsystems in einem Fahrzeugdateneditor. In diesem Fahrzeugdateneditor wird die Architektur der Steuergeräte weiter spezifiziert und die Kommunikationsanforderungen (klassisch: eine „CAN-Matrix“) definiert. Moderne Tools ermöglichen hier sowohl die AUTOSAR-Daten (DEXT) wie auch die Diagnosedaten (ODX) gemeinsam und gleichzeitig zu spezifizieren und diese in einer gemeinsamen Datenbank zu verwalten.
Es existiert eine weitgehende Überschneidung des Inhalts dieser beiden Datenformate, zum Beispiel beim DTC und DID. Beide Formate enthalten jedoch alle notwendigen Informationen für die Steuergeräte-Entwicklung. Bei DTCs fehlen in ODX ungefähr 40 Attribute, die zur Beschreibung einen DTC im Steuergerät, wie zum Beispiel die Priorität des Fehlers und die zu verwendende Debouncing-Strategy.
Damit ein Entwickler effektiv und effizient arbeiten kann, wenn er einen DTC hinzufügt oder ändert, ist es nahezu unerlässlich, dass er hierfür nur an einer Stelle die Definitionen erzeugen und verwalten muss. Besitzt ein Tool erstmal alle notwendigen Informationen, können hieraus DEXT- und ODX-Daten generiert werden und bei späteren Änderungen werde diese auch wieder reimportiert und in das jeweils andere Format zurück exportiert. Damit ist eine Kohärenz der ODX und DEXT-Daten sichergestellt, sodass ein Funktionsentwickler für seine tägliche Arbeit nur ein Tool benötigt. Die Änderungen spiegeln sich auf Knopfdruck in beiden Welten wider.
Dieser Prozess ermöglicht die Erzeugung aller notwendigen Datenformate für die Entwicklung und den Aftersales. Zusätzlich können automatisch Test sequenzen zur Verifizierung des tatsächlichen Diagnoseverhaltens der Steuergeräte generiert werden.
Dies bringt in Verbindung mit den verschiedenen Diagnose-Layern Component, System- und Vehicle eines Adap tive AUTOSAR-Steuergeräts wirkungsvolle Diagnosemöglichkeiten direkt ins Fahrzeug. Dadurch wird ein möglichst störungsfreier Betrieb und eine hohe Zuverlässigkeit gewährleistet. Bei auftretenden Fehlern ist eine der Fahrzeugvariante angepasste, zeitnahe Diagnose gegeben. Dank einer intelligenten Problembehandlung können komplexe Funktionen wie ADAS trotz der Störung eines Teilsystems ihren bestmöglichen Funktionsumfang beibehalten.
Fazit
Die Diagnose behält sich die Voraussetzung, sich stetig steigenden Anforderungen komplexer autonomer Systeme der Zukunft anzupassen. Mit der Verfügbarkeit von High-Performance-Computern im Fahrzeug, die auch ausreichende Ressourcen für Diagnosetester besitzen, werden diese Tester ins Fahrzeug integriert. Die Diagnose wird dadurch umfangreicher und mobiler.
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Service-orientierte Architekturen
Grundsätzlich soll mit Service-orientierten Architekturen (SOA) die Strukturierung und Nutzung verteilter Funktionalitäten im Fahrzeug ermöglicht und erleichtert werden. Statt der bisherigen statischen Bindung von Funktionen in einer Applikation (Apps) werden in Zukunft viele Funktionen der Apps erst beim Start miteinander verknüpft. Diese Service-orientierten Architekturen sind in der IT-Welt nichts Neues, aber wie funktionieren sie in Embedded-Systemen im Fahrzeug?
Find Service
Nach dem Einschalten des Fahrzeugs fahren die angeschlossenen Steuergeräte hoch und die dabei startenden Applikationen bieten ihre Services den Clients zur Nutzung an. Diese Services besitzen eine Versionsnummer, um hier die Kompatibilität zwischen verschieden Version sicherzustellen. Mit „Find Service“ können auch die Clients gezielt nach einem Service suchen, wenn der aktuelle Zustand nicht bekannt ist. Dadurch können sich die Kommunikationspartner zur Laufzeit in einem Netzwerk finden, ohne dass hier eine statische Konfiguration vorhanden sein muss. Weitere Applikationen, die neue Services anbieten oder Vorhandene benutzen, können auch nach der Produktion des Fahrzeugs einfach ergänzt werden. Letztlich erreicht man in Fahrzeugen ähnliche Möglichkeiten, wie sie Apps schon heute z. B. bei Smartphones bieten. Die Services selbst können auf drei Arten benutzt werden:
– „Fire und Forget“ – hier sendet der Client Daten an den Server und wartet nicht auf das Ergebnis. Das kann zum Beispiel eine neue Stellgröße für einen Temperaturregler sein.
– „Request und Response“ – hier sendet der Client Daten an den Server und erhält dann das Ergebnis als Antwort zurück. Ein Beispiel wäre das schrittweise Inkrementieren eines Stellwerts und das Zurücksenden des sich dadurch ergebenden
neuen Stellwertes.
– „Event“ – hier sendet der Server selbständig Informationen an einen Client, der sich zuvor registriert hat. Ein Beispiel wäre das zyklische Senden des aktuellen Messwertes der Temperatur an eine Anzeige. Beendet sich ein Server, auch während des laufenden Betriebs, so teilt er dieses den Clients durch das Senden eines Broadcast „Stop Offer Service“ mit. Die Clients können daraufhin ihrerseits entsprechend reagieren.
Fazit
Die Ziele der Service-orientierten Software-Architekturen entsprechen denen in der IT: So soll damit die langfristige Senkung von Kosten in der Entwicklung von Fahrzeugapplikationen erreicht werden. Die höhere Flexibilität dieser Fahrzeugapplikation ermöglicht die Wiederverwendung bestehender Services in verschiedenen Steuergeräten und unterschiedlichen Fahrzeugen. Dies ist notwendig, um die komplexere Software, welche für Autonomes Fahren entwickelt wird, in die Fahrzeuge integrieren und später warten zu können. www.kpit.com
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
FuSi für Künstliche Intelligenz
Um immer komplexere Automated Driving (AD)-Aufgaben zu erfassen, muss die Anwendung durch eine zunehmende Vielfalt von Sensoren in Anzahl und Typ eine komplexere und genauere Darstellung der Verkehrssituation erstellen (siehe Bild 1). In der Folge wird das AD-System immer komplexer und unterliegt daher zunehmend verschiedenen Fehlerarten. Ein unerkannter Fehler in einer der Komponenten dieses AD-Systems kann schwerwiegende Folgen haben. Ziel eines sicheren Systems ist es, sicherzustellen, dass Fehler erkannt werden und dass das System genügend Sicherheitsmechanismen implementiert, um das gesamte System in einen sicheren Zustand zu versetzen. Dennoch zwingt die Komplexität der AD-Komponenten die Anwendungen dazu, die Algorithmen von modellbasierten Techniken auf die der Künstlichen Intelligenz (KI) wie Machine Learning (ML) oder Deep Learning (DL) umzustellen. Solche Verfahren werden zwar immer besser, tendieren aber zur Instabilität, deren Ursprung nur schwer nach zuvollziehen ist.
Vertrauen in die Daten
Die grundlegende Aufgabe einer ADAnwendung besteht darin, die Daten der Sensoren zu erfassen, die Verkehrssituation auszuwerten, eine sichere Trajektorie zu berechnen und diese zur Ausführung an die Aktoren zu senden. Durch Fehler und Toleranzen der Sensoren leidet das System unter einer gewissen Un sicherheit und beeinflusst damit das Vertrauen, das man in die Detektionen setzen kann. Das Vertrauen kann durch den Einsatz von Sensorfusionstechniken im räumlichen Bereich und Zielverfolgungsmethoden im zeitlichen Bereich erhöht werden. Der Kalman-Filter wird häufig für diesen Zweck verwendet, insbesondere bei Radar.
Die Berücksichtigung des Vertrauens niveaus der Detektionen im Entscheidungsprozess ist bei AD-Anwendungen von entscheidender Bedeutung. Das Vertrauen muss sich durch die Verarbeitungskette ausbreiten. Softwarekomponenten, die auf KI basieren, können Teil der Verarbeitungskette sein und sollten daher nicht anders behandelt werden. Wenn man das Konzept auf das Gesamtsystem, vom Sensor bis zum Stellglied, überträgt, wird es möglich, das Gesamtsystem und die Sicherheit der beabsichtigten Funktion (SOTIF) zu bewerten.
NN-Komponenten einfach halten
Eine Möglichkeit, Fehlprognosen aus einem Neuronalen Netz (NN) erkennen zu können, besteht darin, die Komplexität so gering wie möglich zu halten, es mit Merkmalen (z. B. Geschwindigkeit und Lage von Objekten) zu versorgen und die Plausibilität der Ein- und Ausgänge zu überprüfen.
Um die NNs jedoch einfach und klein zu halten, muss eine Sammlung von NNs implementiert werden, die jeweils einer bestimmten Aufgabe zugeordnet sind. Dieser Ansatz unterliegt Abweichungen, wenn die Vorverarbeitungsschritte in Bezug auf die Entwicklungsreife nicht stabil genug sind. Es hat auch den Nachteil, dass kaskadierende NNs eine zunehmende Ungenauigkeit verursachen und sich somit auf das SOTIF auswirken können. Die Verwendung eines End-to-End-Ansatzes kann dieses Problem beheben. Deep Convolutional NNs wie das VGG16 haben eine hervorragende Leistung bei der Objekterkennung gezeigt. Aufgrund seiner Komplexität ist es aber auch wesentlich schwieriger, die Ursache von Fehleinschätzungen zu verstehen und damit Sicherheitsmechanismen zu entwickeln, um sie zu verhindern.
Die Situation wird noch komplizierter, wenn die Anwendung Objekte verfolgen muss. Bewegte Objekte wie z. B. Fußgänger oder Fahrzeuge müssen sehr präzise lokalisiert werden, um eine sichere Trajektorie zu berechnen. Damit ein NN auch eine präzise Lokalisierung der erfassten Objekte ermöglicht, wurden Netzwerkdesigns wie das U-Net [2] entwickelt. Das U-Net fügt ein weiteres Level in der Komplexität des NN hinzu. Es macht die Aufgabe, Fehlprognosen zu erkennen, noch komplizierter. Andererseits, wenn die Information über die Position der Objekte verfügbar ist, kann die zeitliche Verfolgung nicht nur mithilfe der Art des Objekts wie beim VGG16, sondern auch mit der Position dieser Objekte erfolgen.
Eine Möglichkeit, die Größe eines NNs auf der Grundlage von Rohbildern zu reduzieren, besteht darin, eine Sammlung von spezialisierten NNs zu verwenden, die der Erkennung sehr spezifischer Objekte, wie z. B. Verkehrszeichen, dienen (siehe Bild 1). Mit einfachen NNs erleichtert es die Gestaltung funktionaler Sicherheitsmechanismen zur Fehlererkennung. Da sie kleiner sind und sehr spezifischen Aufgaben gewidmet sind, sind diese NN in der Regel einfacher zu trainieren.
Erstellung eines ausfallsicheren Systems
Neben der Implementierung von Sicherheitsmechanismen ist es auch möglich, redundante KI-Komponenten einzusetzen. Diese Technik ist ähnlich wie jede Hardware- oder Software-Redundanz. Die Idee ist, mehrere Implementierungen zu verwenden, die auf den gleichen Anforderungen basieren, von verschiedenen Teams implementiert und auf verschiedenen Datensätzen trainiert werden, um systematische Fehler zu vermeiden. Die Ergebnisse der verschiedenen Versionen von NNs werden zusammen mit dem Vertrauen auf ihre Vorhersagen an ein Abstimmungssystem gesendet (siehe Bild 1). Dieses System kann dann die tatsächliche Leistung des NN-Sets ermitteln.
Fazit
Autonomes Fahren wird immer komplexer, je höher der Grad der Autonomie ist. Die Anzahl und Vielfalt der Sensoren nimmt zu und die AD-Anwendung erfordert immer ausgefeiltere Algorithmen zur Erfassung der Verkehrssituation und der Umgebung des Fahrzeugs.
Die KI ist an einer wachsenden Anzahl von Verarbeitungsstufen beteiligt, von der Wahrnehmung über die Situa tionsanalyse bis hin zur Trajektorienplanung. Trotz der Schwierigkeit, ihre interne Verarbeitung zu verstehen, kann die KI-Komponente in Bezug auf Funktionale Sicherheit und SOTIF wie jede andere Hard- und Softwarekomponente behandelt werden. Um die KI-Komponenten herum können funktionale Sicherheitsmechanismen aufgebaut werden. Sie können die Konsistenz der Vorhersagen sowohl im räumlichen als auch im zeit lichen Bereich überprüfen. Die zeitliche Domäne muss mit Vorsicht behandelt werden, wenn es darum geht, zeitliche Beschränkungen in den Sicherheitsanforderungen festzulegen.
Auf der anderen Seite bietet die Norm ISO 26262 Werkzeuge zur Zuordnung von Fehlerwahrscheinlichkeiten und zur Analyse des Gesamtsystems mit KI. Sicherheitsmechanismen können für das Gesamtsystem einschließlich der KIKomponenten konzipiert werden. Die Normen Für Funktionale Sicherheit und SOTIF sind eine große Hilfe bei der Weiterentwicklung der gesamten Softwarearchitektur, sodass alle Sicherheitsanforderungen erfüllt und die Sicherheitsziele erreicht werden können. » www.kpit.com
Quellenverzeichnis
[1] Very Deep Large Convolutional Networks for Large-Scale Image Recognition, K. Simonyan und A Zisserman, 10–04–2015, Veröffentlicht ICLR 2015,
[2] Convolutional Networks for Biomedical Image Segmentation, O. Ronneberger, P. Fischer und T. Brox, 18–05–2015
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Vernetzte Fahrzeuge und Connected Diagnostics
Die Komplexität moderner Fahrzeug architekturen hat zuletzt durch die Einführung von Gateway-Steuergeräten und DoIP noch einmal deutlich zugenommen. Parallel dazu haben sich die Prüfgeräte weiter entwickelt, um die steigenden Anforderungen von Fahrzeug und Anwender zu erfüllen. Ein Grundprinzip bei der Diagnose blieb bis dato aber unverändert: Sie erfolgt über eine Punkt-zu-Punkt-Verbindung zwischen Diagnosegerät und dem Fahrzeug. Zwar kommen dabei mittlerweile Technologien wie DoIP (Diagnostics over Internet Protocol) und WiFi zum Einsatz. Allerdings kann diese Kommunikation trotzdem nur sporadisch aufgebaut werden und nur dann, wenn das Fahrzeug schon besondere Aufmerksamkeit erfordert und daher beispielsweise in der Werkstatt steht. Die Vernetzung der Fahrzeuge bietet hier in Form von Connected Diagnostics ganz neuen Möglichkeiten für Werkstätten, Mobilitätsdienstleister und Flottenbetreiber.
Diagnose neu denken
Ein dauerhaft verbundenes Fahrzeug ermöglicht viele neue Anwendungen, die das Potenzial haben, Kosten zu senken und das Kundenerlebnis zu verbessern. Zu den möglichen Anwendungen gehören:
- Over-the-Air-Updates: Die Übermittlung von Software-Updates über eine drahtlose Kommunikationsverbindung hat die Automobilindustrie zum Teil bereits implementiert. Die Bedeutung dieser Anwendung wird noch weiter zunehmen.
- Überwachung des Fahrzeugzustands: Ein wichtiger Anwendungsfall ist die Überwachung und Bekanntmachung des Fahrzeugzustands. Auf diese Weise kann eine Organisation die gesammelten Informationen proaktiv einsetzen, um die Fahrtüchtigkeit eines Fahrzeugs ggf. in Interaktion mit dem Kunden und externen Dienstleistern zu gewährleisten. Zusätzlich lassen sich die gesammelten Daten als Grundlage für eine vorausschauende Instandhaltung nutzen.
- Wiederherstellung des Fahrzeugzustands: Wird ein Fahrzeug fahruntüchtig, kann das Fahrzeug in einigen Fällen über Diagnosebefehle in einen Zustand zurückversetzt werden, in dem es wieder sicher fahrbar ist. Damit können Pannendienst- und Kundensupportteams den Kunden bei der Aufrechterhaltung der Mobilität unterstützen.
Sicherheit und Datenschutz
In jeder vernetzten Umgebung sollte das Thema Sicherheit an erster Stelle stehen und das Konzept „Secure by Design“ strengstens eingehalten und befolgt werden. Konzepte wie Fahrzeugzu-Infrastruktur-Kommunikation-VPN, Fahrzeugschlüssel-/Zertifikatautorisierung und permanent sichere Kommunikation sind nur einige der Maßnahmen, die eingesetzt werden können, um Angriffsvektoren (während der externen Kommunikation) zu minimieren.
Auch der Datenschutz ist bei der Entwicklung vernetzter Diagnosesysteme (Connected Diagnostics Systems, CDS) konsequent zu beachten. Grundsätzlich müssen alle übermittelten fahrzeugbezogenen Daten auf eine sichere und kontrollierte Weise behandelt werden. Die Zustimmung des Kunden ist darüber hinaus ein zentraler Faktor. Unternehmen sollten daher Änderungen an ihren Geschäftsbedingungen vornehmen, um sicherzustellen, dass eine rechtskonforme Zustimmung vorliegt und die Dienste entsprechend geschützt sind.
Design to Scale
Die an die Datenerfassungskomponenten eines vernetzten Diagnosesystems gestellten Anforderungen werden mit der Zeit zunehmen bzw. sich verändern. So wird sich die Zahl der vernetzten Fahrzeuge und der Kommunikations ereignisse erhöhen. Gleichzeitig kann die Qualität und Verfügbarkeit der Datenübermittlung (wegen der Verfügbarkeit der Fahrzeugkommunikation, Zeitzonen, usw.) nicht jederzeit vorhergesagt oder garantiert werden.
Die Nutzung von „Design to Scale“-Prinzipien ist hier der Schlüssel zum Erfolg. Das Architekturdiagramm (Bild oben) zeigt eine beispielhafte Lösung.
Es gibt bei diesem Konzept mehrere zusammenwirkende Teile, die zum einen die Bereitstellungs-Gemeinkosten niedrig halten und zum anderen gleichzeitig für größtmögliche Skalierbarkeit und den reibungslosen Umgang mit Bedarfsschwankungen sorgen.
- Der Kommunikationsmanager (A) ist ein skalierbarer Dienst, der exklusiv mit dem Fahrzeug interagiert, und nur für eine minimale Verarbeitung der Nachrichten und die Übergabe an die Warteschlange verantwortlich ist.
- In der Verarbeitungswarteschlange (B) werden die Nachrichten nach der Annahme abgelegt. Dabei wird die Warteschlangentiefe überwacht und die ‚Worker‘ für die Datenverarbeitung bedarfsgerecht skaliert (Serverless Computing).
- ‚Worker‘ übernehmen die Nachrichtenverarbeitung (C) und erweitern die Daten geschäftsspezifisch. Bei einer erfolgreichen Verarbeitung werden die Fertigstellung der Working-Signale und die Quittierung an das Fahrzeug gesendet. Fehlermeldungen können Out-of-Band verwaltet und verarbeitet werden.
Moderne Skalierungstechniken unterstützen diese Architektur und die resultierende Lösung ist dadurch sowohl einfach als auch hochgradig skalierbar.
Neue Geschäftsmodelle
Bei der Einführung dieser Systeme müssen die Kosten (Fahrzeugplattformänderung, Infrastruktur, Systemänderung, Support, usw.) mit dem Nutzen für den Endkunden abgewogen werden. Eine vernetzte Diagnoselösung eröffnet aber eine breite Palette an Möglichkeiten und bietet geschäftliche Vorteile, durch die sich die erforderliche Investition für eine solche Lösung schnell bezahlt macht.
- Vorausschauende Wartung: Auf Basis von Vorort-Fahrzeugdaten und -zuständen ist es möglich, potenzielle Ausfälle zu erkennen, bevor sie auftreten. So lässt sich gemeinsam mit dem Kunden dafür sorgen, dass es nicht zu einem ungeplanten Fahrzeugstillstand kommt. Außerdem ist es im Rahmen von planmäßigen Werkstattbesuchen denkbar, Wartungsarbeiten vorzuschlagen, um erwartete Ausfälle zu vermeiden.
- Wiederherstellung des Fahrzeugzustands: Bei einer Fahrzeugpanne kann vorübergehend ein fahrbereiter Zustand wiederhergestellt werden. Dadurch lassen sich Ausfallzeiten reduzieren und der Kunde bleibt weiter mobil.
- Erhöhte Markentreue: Intelligente Services und die Erhöhung der Fahrzeugverfügbarkeit wirkt sich positiv auf Nutzererfahrung aus. Sie tragen zum Markenwert bei und stärken die Kundentreue.
- Verbesserte Händlererfahrung: Auch das Händlernetz profitiert von vernetzten Diagnosesystemen. Werkstatttechniker können den Fahrzeugzustand ermitteln und Erstdiagnosen durchführen und ggf. Ersatzteile bestellen, bevor das Auto in die Werkstatt kommt. Serviceberater können ein genaues Bild des Zustands vermitteln und Servicearbeiten proaktiv empfehlen, um den Kunden vor Fahrzeugausfälle zu bewahren.
- Lebensdaueranalysen: Derzeit erhalten Zulieferer und OEMs meist nur dann Informationen über eine verbaute Komponente, wenn sie ausfällt – und selbst dann nicht in allen Fällen. Der Kontext zu diesem Ausfall fehlt dabei in der Regel oder beschränkt sich auf einen Diagnose-Fehlercode (DTC). Vernetzte Diagnosesysteme versetzen diese Unternehmen in die Lage, die Leistung von Komponenten zu bewerten und zu verbessern. Zudem könnten sie diese Daten auch in Kombination mit maschinellem Lernen nutzen, um zukünftige Störungen präziser vorherzusagen.
- Aftermarket: Einige Länder verlangen, dass Ferndiagnosemöglichkeiten dem Aftermarket verfügbar gemacht werden. Eine vernetzte Diagnoselösung in Kombination mit einer Extended Vehicle Platform (ISO 20077/8/80) bietet einen Weg, um sowohl diese gesetzlichen Anforderungen zu erfüllen und gleichzeitig ein sicheres, kontrolliertes System zu realisieren.
Eine vernetzte Diagnoselösung hat das Potenzial auch die Anwendungsfälle abzudecken, die heute eine nachgeordnete Rolle oder, wie Pay-per-Use oder Ferninspektion, noch weitgehend Zukunftsmusik sind aber schnell an Bedeutung gewinnen können. Unternehmen, die rechtzeitig eine vernetzte Diagnoselösung einführen, können auf diese und ähnliche Anforderungen reagieren und neue Geschäftsmodelle entwickeln. » www.kpit.com
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Architekturkonzepte für autonome Fahranwendungen
In den vergangenen Jahren hat die Automobilindustrie die Funktionsmerkmale, die auf eine Unterstützung des Fahrers in schwierigen Verkehrssituationen abzielen, ganz erheblich verbessert. Diese im Allgemeinen unter dem Begriff Fahrerassistenzsystem (ADAS, Advanced Driver Assistance System) zusammengefassten Funktionen reichen vom Einparken über Spurhalteassistenten (LKA, Lane Keeping Assistance) bis hin zu komplexeren Funktionen wie adaptivem Tempomat (ACC, Advanced Cruise Control). Solche Funktionen erfordern eine begrenzte Anzahl an Sensoren. Die in Bild 1 gezeigte Architektur stellt eine mögliche Konstruktion zur Implementierung von Funktionen wie Spurhalteassistent und adaptivem Tempomat dar.
Unter der Voraussetzung, dass Spurhalteassistent und Tempomat entsprechend den Richtlinien von ISO 26262 realisiert wurden, kann eine solche Architektur das Egofahrzeug in einem sicheren Zustand halten. Die Erwartungen an Autonomes Fahren (AD) sind jedoch weitaus höher und erweitern den Komplexitätsgrad des Systems ganz erheblich.
Die Komplexitätsexplosion
Um zunehmend komplexe autonome Fahrfunktionen wahrzunehmen, muss die Anwendung eine aufwendigere und präzisere Darstellung der Verkehrssituation durch Einbeziehung einer immer größeren Zahl von Sensoren wie Radargeräten, Kameras, GPS-Ortung und hochauflösenden Karten ermöglichen. Eine Architektur wie die in Bild 1 gezeigte hat grundsätzlich mehrere gravierende Nachteile.
Erstens bietet diese Architektur nur geringe Konfigurationsmöglichkeiten. Zweitens erfordert sie auch den Austausch einer Datenmenge zwischen Komponenten, die mit steigender Anzahl von Sensoren immer größer wird. Damit wächst die Kommunikationsbandbreite, wodurch sich die Skalierbarkeit der Lösung verringern kann. Mit zunehmender Komplexität müssen mehr Funktionen zu den Entscheidungs- und Planungsebenen hinzugefügt werden. In der Folge sinkt die Modularität. Es sei auch darauf hingewiesen, dass diese Aspekte gegen die Empfehlungen der ISO 26262 sprechen.
Eine besser geeignete Architektur ist in Bild 2 zu sehen. Diese Architektur ermöglicht auch die Implementierung des oben erwähnten Spurhalteassistenten und Tempomats, dargestellt in den dunkelblauen Kästen. Auch die Integration neuer autonomer Fahrfunktion kann skalierbarer und reibungsloser erfolgen. Funktionen wie Spurwechselassistent (LCA) oder Notfall-Fahrmanöver (MRM) können ohne Beeinflussung des LKA/ ACC-Moduls hinzugefügt werden.
Zu beachten ist auch, dass diese Architektur vom Standpunkt der Funktionssicherheit aus eine kohärente Partitionierung der unterschiedlichen Module erlaubt, sodass eine hohe Kohärenz erreicht wird und die Schnittstellen zwischen Komponenten gleichzeitig möglichst schmal bleiben.
Sicheres Überholen auf der Autobahn
Der Anwendungsfall des Überholens eines vorausfahrenden Fahrzeugs auf einer dreispurigen Autobahn ist eine der gängigsten Situationen (siehe Bild 3). Für die autonome Fahranwendung besteht das Manöver darin, vom LKA/ACCModus auf den Spurwechselassistenten (LCA) umzuschalten. Aus Gründen der Funktionssicherheit wird die Notfall-Fahrmanöverkomponente ebenfalls aktiviert. Diese sorgt dafür, dass in allen Situationen einschließlich aller Fehlersituationen, die jederzeit auftreten können, ein sicherer Zustand aufrechterhalten werden kann. Hier ist darauf hinzuweisen, dass die autonome Fahranwendung bei einer solchen Aufgabe nur Fahrfertigkeiten ausübt.
Umgang mit Autobahnausfahrten
Bei einem höheren Grad an Autonomie muss die Anwendung komplexere Situationen meistern wie etwa das Anfahren einer Autobahnausfahrt, wie in Bild 4 dargestellt. Das rote Egofahrzeug nähert sich der zu benutzenden Ausfahrt. Nun liegt die Gefahr bei einem abstrakteren Begriff: einem gefährlichen Fahrstil. Dies kommt in einem höheren Abstraktionsgrad zum Ausdruck und kann nicht mit Gefahren aufgrund der Verkehrssituation vermischt werden. Zum Umgang mit dieser Situation muss die autonome Fahranwendung über Situationsanalysefähigkeiten verfügen.
Genauer gesagt verfügt die in Bild 2 gezeigte Architektur über keinerlei Mechanismen, mit denen sich die Frage klären lässt, ob ein Überholen des vorausfahrenden Fahrzeugs bzw. der vorausfahrenden Fahrzeuge auf sichere Weise möglich ist. Eine solche Architektur ist in Bild 5 dargestellt.
Die blau dargestellte Architektur aus Bild 2 ist dabei um das notwendige Modul zur Berechnung der Bahnen auf der Ausfahrtspur ergänzt. Bild 5 zeigt darüber hinaus eine zusätzliche gelbe Ebene. Als Eingangsdaten nutzt diese Ebene Informationen wie die vom GPS ermittelte Position und hochauflösende (HD)-Karten der Fahrzeugumgebung.
Das einem solchen Ansatz zugrunde liegende Konzept lässt sich mit Begriffen wie sichere Zustände und sicheres Segment umschreiben. Ein sicheres Segment besteht aus einer kontinuierlichen Abfolge sicherer Zustände zwischen wesentlichen Aktionspunkten wie Autobahnausfahrten. In diesen Segmenten können alle Fahrentscheidungen der unteren Ebene überlassen werden, auf der die autonome Fahranwendung ihre Fahrfertigkeiten nutzt. Andererseits sind in der Nähe der wesentlichen Punkte einige der fahrfertigkeitsbezogenen Aktionen durch Situationsanalysefähigkeiten zu entschärfen.
Vollautonomes Fahren
Das im vorhergehenden Abschnitt beschriebene Konzept lässt sich noch erweitern. Das eigentlich Ziel des Fahrers und der Insassen des Fahrzeugs besteht darin, von Punkt A zu Punkt B zu gelangen. Der Weg, dem das Fahrzeug folgt, ist eine Ansammlung von Segmenten, die an einigen speziellen Punkten durch Richtungswechsel getrennt sind. Diese Art von Fahrt hat auch einige zeitliche Beschränkungen, selbst wenn es keine sehr dringlichen sind (Beispiel: Ein Fahrer, der sich um 14 Uhr auf eine einstündige Fahrt begibt, möchte vor Anbruch der Dunkelheit am Zielort ankommen). Die Auswahl eines sicheren Wegs muss in Abhängigkeit davon erfolgen. Bei falscher Auswahl kann es zu gefährlichen Situationen kommen.
Es scheint daher die richtige Erweiterung des im vorhergehenden Abschnitts dargelegten Konzepts zu sein, eine sichere Fahrt als eine Ansammlung sichererer Segmente zu betrachten. Am wichtigsten ist eine stabile Definition von sicherer Fahrt. In vielen Fällen entwickelt sich die Verkehrssituation im Verlauf der Fahrt beispielsweise durch Unfälle oder Staus auf eine nicht vorhergesehene Weise. Es ist darauf hinzuweisen, dass die Handhabung des Begriffs einer sicheren Fahrt wiederum auf einer anderen konzeptionellen Ebene erfolgt, aber auch von der Art der behandelten Gefahren abhängt.
Da scheint es nur nahezuliegen, eine weitere Steuerungsebene zur im vorherigen Abschnitt beschriebenen Architektur hinzuzufügen. Ziel dieser Ebene ist die Umsetzung der Planungsfähigkeiten der autonomen Fahranwendung und somit die Umwandlung der geplanten Fahrt in eine Abfolge sicherer Segmente und zweitens bei Bedarf die dynamische Erstellung eines Satzes alternativer Fahrrouten und der zugehörigen Segmente.
Fazit
Mit einfachen ADAS-Funktionen wie Spurhalteassistent und adaptiver Tempomat kann die zugrunde liegende Architektur in einem sehr einfachen, flachen Layout verbleiben. Für die Behandlung komplexerer Situationen wie Autobahnausfahrten müssen die Architekturkonzepte erweitert werden.
Für die allerhöchste Ebene des autonomen Fahrens muss die autonome Fahranwendung in der Lage sein, eine sichere Fahrt auszuwählen, die sich aus einer dynamisch berechneten Ansammlung sicherer Segmente zusammensetzt. Mit einem hierarchischen Ansatz kann sich das Fahrzeug ohne Eingriffe des Fahrers auf eine sichere Reise begeben, und genau dies ist Level 5 des autonomen Fahrens.
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Modell- und netzwerkbasierte Diagnose Vorgestellt wird
Architekturen, virtuelle ECUs usw. an, so
steigt die Komplexität der Diagnostik oder der Diagnose
von Fehlern und der Lokalisierung ihrer Grundursache exponentiell
an. Die Auswirkungen dieser Komplexität sind deutlich
zu erkennen bei denjenigen, die diese Fahrzeugtechnologien
verwalten und aktualisieren müssen (wie End-of-Line-
Fertigung oder OEM-Kundendienstanbieter). Dies konzentriert
sich insbesondere im Kundendienstbereich an der
Schnittstelle zum Kunden. Die Kundenerfahrung ist ein kritischer
Parameter für den Aufbau und Erhalt von Markentreue,
daher ist es wichtig, jegliche Ausfallzeiten von Fahrzeugen
auf ein Minimum zu beschränken.
Diese Komplexität steht im direkten Widerspruch zu den
wachsenden Anforderungen der Kunden und dem Wunsch
nach einer Reduzierung der Fahrzeugausfallzeiten. Früher
verfügte ein Kfz-Mechaniker über die Kenntnisse, die eine effektive
Reparatur des Fahrzeugs gestatteten. In komplexen
Umgebungen sind die Möglichkeiten dieser Fachkräfte trotz
ihres umfangreichen Know-Hows jedoch begrenzt. Letztendlich
beeinträchtigt dies die effektive Diagnose und somit die
Reparatur des Fahrzeugs.
Ein weiterer unbefriedigender Punkt bei modernen Fahrzeugen
ist der immer häufiger vorkommende Austausch nicht
fehlerhafter Teile. Dies wird üblicherweise als „No Fault
Found“ oder „No Trouble Found“ bezeichnet. Dies geschieht
dann, wenn ein Mechaniker ein Teil ersetzt, das eigentlich
nicht die Grundursache für das vom Kunden beanstandete
Problem war. Im Allgemeinen ist es in diesem Fall erforderlich,
dass der Kunde zum Händler zurückkehrt, was mit hoher
Wahrscheinlichkeit mit Unannehmlichkeiten verbunden ist,
die vermeidbar gewesen wären. Wenn es für das Fahrzeug
eine Herstellergarantie gibt, entstehen dem OEM unmittelbare
Kosten.
Die Problempunkte sind offensichtlich – hohe Garantiekosten,
geringe Kundenzufriedenheit usw., und dies alles
letztlich verursacht durch Fehldiagnosen. Solche Probleme
lassen sich nur entschärfen oder lösen, wenn effektive Diagnosen
durchgeführt werden. Zunehmende Komplexität erfordert
erweiterte Kenntnisse, Fähigkeiten und Erfahrungen
– und all dies verursacht (direkte oder indirekte) Kosten. Ein
Ansatz besteht darin, die Abhängigkeit von den Entscheidungen
eines Kfz-Mechanikers zu reduzieren und das Konzept
der geführten Diagnose einzuführen.
Sieht man sich moderne technische Konzepte wie merkmalbasierte Architekturen, virtuelle ECUs usw. an, so steigt die Komplexität der Diagnostik oder der Diagnose von Fehlern und der Lokalisierung ihrer Grundursache exponentiell an. Die Auswirkungen dieser Komplexität sind deutlich zu erkennen bei denjenigen, die diese Fahrzeugtechnologien verwalten und aktualisieren müssen (wie End-of-Line- Fertigung oder OEM-Kundendienstanbieter). Dies konzentriert sich insbesondere im Kundendienstbereich an der Schnittstelle zum Kunden. Die Kundenerfahrung ist ein kritischer Parameter für den Aufbau und Erhalt von Markentreue, daher ist es wichtig, jegliche Ausfallzeiten von Fahrzeugen auf ein Minimum zu beschränken.
Diese Komplexität steht im direkten Widerspruch zu den wachsenden Anforderungen der Kunden und dem Wunsch nach einer Reduzierung der Fahrzeugausfallzeiten. Früher verfügte ein Kfz-Mechaniker über die Kenntnisse, die eine effektive Reparatur des Fahrzeugs gestatteten. In komplexen Umgebungen sind die Möglichkeiten dieser Fachkräfte trotz ihres umfangreichen Know-Hows jedoch begrenzt. Letztendlich beeinträchtigt dies die effektive Diagnose und somit die Reparatur des Fahrzeugs.
Ein weiterer unbefriedigender Punkt bei modernen Fahrzeugen ist der immer häufiger vorkommende Austausch nicht fehlerhafter Teile. Dies wird üblicherweise als "No Fault Found" oder "No Trouble Found" bezeichnet. Dies geschieht dann, wenn ein Mechaniker ein Teil ersetzt, das eigentlich nicht die Grundursache für das vom Kunden beanstandete Problem war. Im Allgemeinen ist es in diesem Fall erforderlich, dass der Kunde zum Händler zurückkehrt, was mit hoher Wahrscheinlichkeit mit Unannehmlichkeiten verbunden ist, die vermeidbar gewesen wären. Wenn es für das Fahrzeug eine Herstellergarantie gibt, entstehen dem OEM unmittelbare Kosten.
Die Problempunkte sind offensichtlich – hohe Garantiekosten, geringe Kundenzufriedenheit usw., und dies alles letztlich verursacht durch Fehldiagnosen. Solche Probleme lassen sich nur entschärfen oder lösen, wenn effektive Diagnosen durchgeführt werden. Zunehmende Komplexität erfordert erweiterte Kenntnisse, Fähigkeiten und Erfahrungen – und all dies verursacht (direkte oder indirekte) Kosten. Ein Ansatz besteht darin, die Abhängigkeit von den Entscheidungen eines Kfz-Mechanikers zu reduzieren und das Konzept der geführten Diagnose einzuführen.
Geführte Diagnose
Geführte Diagnose nennt man gewöhnlich den Prozess der Diagnose einer Fehlergrundursache an einem Fahrzeug. Man beginnt mit einem Fehlerfall (zum Beispiel bestimmten Symptomen oder anderen Hinweisen). Der Mechaniker wird dann durch mehrere Tests geführt, die schließlich eine Schlussfolgerung zulassen, welche Komponenten ursächlich betroffen sind. Geführte Diagnosen haben sich über die Jahre weiterentwickelt. Es gibt verschiedene Methoden und Verfahrensweisen, die eine geführte Diagnose ausmachen:
– Prüfschritt-Diagnose – Die einfachste Form einer geführten Diagnose lässt sich als Ablauf einfacher Verfahrensschritte darstellen, der bei Befolgung (wahrscheinlich) zu einer korrekten Diagnose mechanischer Fehler führen wird.
– DTC-basierte Diagnose – Wenn ein elektrisches System beteiligt ist, ermöglicht die DTC-basierte Diagnose-Tests auf Basis der vorhandenen DTCs durchzuführen. Dabei kann es sich um einen langen, aufwendigen Prozess handeln, der u. a. von der Genauigkeit der Informationen zu den DTCs abhängt.
– Modellbasierte Diagnose – Zur Darstellung der technischen Systeme wird ein mathematisches Modell herangezogen.
– Netzwerkbasierte, geführte Diagnose – Dieses Konzept beruht auf der Idee, dass Modelle zur Darstellung eines digitalen Zwillings des Fahrzeugs gebaut werden und Informationen aus dem realen Fahrzeug auf das Modell übertragen werden können, was ein weit präziseres Bild ermöglicht, sodass die Diagnoseschritte mit diesen Informationen dynamischer und mit ständigen Anpassungen durchgeführt werden können.
Netzwerkbasierte Diagnose?
Der wesentliche Vorteil erweiterter Techniken wie der modell- und netzwerkbasierten Diagnostik liegt im Übergang von statischer zu dynamischer Diagnose. Eine statische Diagnose stützt sich auf eine große Menge vorbestimmter Daten und kann nur so genau sein, wie die Informationen, auf denen sie basiert. Dies ist vollkommen zweckmäßig, wenn der Fehler bekannt ist oder verstanden wird, setzt aber voraus, dass bestimmte Bedingungen erfüllt sind.
Die dynamische Diagnose verwendet hingegen ein Modell, das kontinuierlich angepasst wird. Die dem Modell zugeführten Fakten werden ständig aktualisiert, wenn neue Informationen hinzukommen oder bestimmte Bedingungen erfüllt sind oder ausgeschlossen werden.
Validierung und kontinuierliche Verbesserung
Das Hauptunterscheidungsmerkmal eines solchen Systems besteht in seiner Fähigkeit, fahrzeugtechnische Daten wirksam zu nutzen und sich mit der Zeit zu verbessern. Dies gilt insbesondere für dynamische, datengetriebene Diagnosesysteme. Genauso wichtig ist es jedoch, der Qualität der Daten im Modell vertrauen zu können. Ferner hat ein dynamisches System einen immanenten Vorteil. Die Leistungsfähigkeit der K-Grip Reasoning Engine ermöglicht die Entwicklung intelligenter Algorithmen, die einfache Lücken feststellen können, die ansonsten übersehen und möglicherweise nie entdeckt worden wären. Zum Beispiel:
– Überflüssige Teile – Ein Teil ist im Modell vorhanden, weist aber keine Verbindung auf. Dies bedeutet, dass sämtliche Störungsszenarien (zum Beispiel Symptome in Bezug auf die Komponente oder DTCs), die ansonsten mit einer Grundursache enden würden, nicht diagnostiziert werden. Dies hat "No Fault Found"-Ergebnisse zur Folge, die sich wiederum auf die Kundenzufriedenheit auswirken.
– Unvollständige Störungen – Eine oder mehrere Störungsszenarien (zum Beispiel spezifische Symptome) sind nicht vollständig. Dies wird im Allgemeinen als ein Pfad durch das Modell beschrieben, der nicht zu einer Grundursache führt.
Datenerfassung und -speicherung
Für einen OEM werden täglich tausende Fahrzeuge diagnostiziert.
Die Erfassung dieser Daten ist erforderich, um sowohl aktuelle Modellverknüpfungen zu validieren, als auch von neuen und unzusammenhängenden Verknüpfungen zu erfahren. Ein typischer (vereinfachter) Datenerfassungsprozess ist in Bild 1 zu sehen. Lokale Clients erfassen Daten und speichern Diagnosesitzungen. Diese werden dann asynchron einem Remote-Speichersystem zugeführt, das die Daten erfasst und verwaltet. Die Sitzungsverfolgungs-Engine kann optimiert werden, um Online/Offline-Szenarien zu verarbeiten und mehrere lokale Clients transparent nachzuverfolgen.
Das Volumen der gesammelten Daten ist signifikant. Bild 2 zeigt das Datenvolumen, das für alle Diagnosesitzungen eines typischen mittelgroßen OEM gesammelt würde.
Bei solchen Datenmengen ist es wichtig, dass das Format leicht zu interpretieren und gut zu verschlüsseln ist. Dies ermöglicht den Offline-Prozessoren, den Datenraum zu durchforsten und Fakten zu extrahieren, die dann für weitergehende Analysen genutzt werden können.
Die "Lernschleife"
Das Konzept der Lernschleife wird durch eine große Menge von Daten ermöglicht, die das System zusammenträgt. Nimmt man zum Beispiel ein Szenario, in dem plötzlich eine steigende Anzahl von Komponenten ersetzt wird, ohne dass dabei eine Störung gefunden wird. Mit den im System vorhandenen Daten ist es möglich, nicht erwartete Fehlergruppen ausfindig zu machen – und die Systemtechniker frühzeitig auf Probleme hinzuweisen. Dadurch kann die Ursache identifiziert und das Modell aktualisiert werden, um eine alternative Prüfung bereitzustellen, die den Mechaniker anweist, die "tatsächliche" ursächliche Komponente zu kontrollieren und die No-Fault-Found-Situation zu bereinigen.
Netzwerkbasierte Diagnose K-GRIP
KGRIP ist die netzwerkbasierte Diagnoselösung von KPIT. Ihre von Grund auf skalierbare Architektur macht KGRIP in Kombination mit einer hochmodernen Regel-Engine zur idealen Lösung. Unter anderem sind dabei folgende Fragen zu stellen:
– Lässt sich eine Diagnose für jede Komponente im System durchführen?
– Sind jeder Grundursache Symptome zugewiesen, d. h., lässt sich das Problem beschreiben, das sich für jede Komponente stellt?
– Gibt es irgendwelche Komponenten ohne Grundursache?
Die K-GRIP-Lösung stellt Tools bereit, die den Aufwand für die Validierung dieser Fragen deutlich verringern. Die Lösung umfasst Werkzeuge und Berichte, die es einem Mechaniker ermöglichen, das Modell zu untersuchen und Fehler jeglicher Art sowie die entsprechenden Fehlerbehebungen schnell zu identifizieren. W (oe)
»»www.kpit.com
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
