DE102018104423A1

DE102018104423A1 - Verfahren und vorrichtung zum überwachen einer fahrzeugseitigen steuerung

Info

Publication number: DE102018104423A1
Application number: DE102018104423.2A
Authority: DE
Inventors: Shengbing Jiang; Sandeep U. Menon; James K. Thomas
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2017-03-07
Filing date: 2018-02-27
Publication date: 2018-09-13
Also published as: CN108572637A; US10279816B2; US20180257663A1

Abstract

Ein Verfahren zum Überwachen einer Steuerung für ein Fahrzeug beinhaltet das Ermitteln von Konfigurationsinformationen, die dem Fahrzeug zugeordnet sind, und das Ermitteln von Fahrzeugbetriebszuständen, die einer Vielzahl von Bedingungen zugeordnet sind. Eine statistische Analyse wird durchgeführt, um eine Vielzahl von Fehlern mit den Betriebszuständen des Fahrzeugs und den mit dem Fahrzeug verknüpften Konfigurationsinformationen zu korrelieren. Die Vielzahl von Fehlern in der Steuerung kann basierend auf der statistischen Analyse und den mit dem Fahrzeug verknüpften Konfigurationsinformationen zu einem Hardware- oder Softwarefehler isoliert werden.

Description

EINLEITUNG
Steuerungen, die an Fahrzeugen eingesetzt werden, können Störungen aufweisen.
KURZDARSTELLUNG
Es wird eine Steuerung für ein Fahrzeug beschrieben. Ein Verfahren zum Überwachen der Steuerung beinhaltet das Ermitteln von Konfigurationsinformationen, die dem Fahrzeug zugeordnet sind, und das Ermitteln von Fahrzeugbetriebszuständen, die einer Vielzahl von Bedingungen zugeordnet sind. Eine statistische Analyse wird durchgeführt, um eine Vielzahl von Fehlern mit den Betriebszuständen des Fahrzeugs und den mit dem Fahrzeug verknüpften Konfigurationsinformationen zu korrelieren. Die Vielzahl von Fehlern in der Steuerung kann basierend auf der statistischen Analyse und den mit dem Fahrzeug verknüpften Konfigurationsinformationen zu einem Hardware- oder Softwarefehler isoliert werden.
Ein Aspekt der Offenbarung beinhaltet das Ermitteln einer SteuerungsHardwarekonfiguration, eines Software-Update-Levels, Informationen über den Produktionsstandort der Steuerung, Informationen über den Montagestandort des Fahrzeugs und ein Montagedatum des Fahrzeugs.
Ein weiterer Aspekt der Offenbarung beinhaltet das Ermitteln von Fahrzeugbetriebszuständen einschließlich des Auftretens von Diagnosefehlercodes und der zugehörigen Fehlermeldungen.
Ein weiterer Aspekt der Offenbarung beinhaltet das Ermitteln von Fahrzeugbetriebszuständen einschließlich dem Ermitteln von Umgebungszuständen, wobei die Umgebungszustände Temperatur, Vibration, Feuchtigkeit, Niederschlag und geografische Lage beinhalten.
Ein weiterer Aspekt der Offenbarung beinhaltet das Ermitteln von Fahrzeugbetriebszuständen einschließlich dem Ermitteln von Software-Ausführungszuständen.
Ein weiterer Aspekt der Offenbarung beinhaltet die Software-Ausführungszustände, einschließlich des Vorhandenseins oder Auftretens eines Moduswechsels, eines Moduls, das ein Ereignis auslöst, z. B. Einschalt- oder Ausschaltereignisse oder eine Funktionsanforderung.
Ein weiterer Aspekt der Offenbarung beinhaltet das Ermitteln von Fahrzeugbetriebszuständen, wie beispielsweise Kilometerzähler, Geschwindigkeit, Leistungsmodus, Motorbetriebsstatus, Lenkradwinkel, Gaspedalstellung oder Bremspedalstellung.
Ein weiterer Aspekt der Offenbarung beinhaltet das Ausführen einer statistischen Analyse über eine Steuerung, um die Vielzahl von Fehlern mit den Fahrzeugbetriebszuständen, die mit der Vielzahl von Zuständen und den Konfigurationsinformationen, die dem Fahrzeug zugeordnet sind, zu korrelieren. Dies beinhaltet das Ermitteln von Basislinien- und Fehlerwahrscheinlichkeitsverteilungen für jede der Bedingungen und das Ermitteln eines statistischen Abstands basierend auf den Basislinien- und Fehlerwahrscheinlichkeitsverteilungen. Korrelationen zwischen den Zuständen und der Vielzahl von Fehlern werden basierend auf dem statistischen Abstand ermittelt.
Ein weiterer Aspekt der Offenbarung ist das Ausführen einer Maximum-Likelihood-Schätzung zum Ermitteln der Basislinien- und Fehlerwahrscheinlichkeitsverteilungen.
Die genannten Merkmale und Vorteile sowie weitere Merkmale und Vorteile der vorliegenden Lehren, gehen aus der folgenden ausführlichen Beschreibung von einigen der besten Ausführungsformen und anderen Arten zur Ausführung der vorliegenden Lehren unter Bezugnahme auf die beigefügten Zeichnungen deutlich hervor.
Figurenliste
Im Folgenden werden exemplarisch eine oder mehrere Ausführungen mit Bezug auf die zugehörigen Zeichnungen beschrieben, in welchen gilt:

1 veranschaulicht schematisch ein Fahrzeug mit einem Antriebsstrangsystem, das gemäß der Offenbarung mit einer Steuerung verbunden ist und von dieser betriebsmäßig gesteuert wird;
2 zeigt schematisch einen Steuerungsüberwachungsprozess zum Überwachen einer Steuerung in einem Fahrzeug gemäß der Offenbarung;
3 zeigt schematisch ein Datenerfassungsereignis, das der Überwachung von Fahrzeugbetriebszuständen gemäß der Offenbarung zugeordnet ist;
4 zeigt schematisch einen statistischen Analyseprozess zum Korrelieren eines Fehlers mit Fahrzeugbetriebszuständen gemäß der Offenbarung; und
5 zeigt schematisch einen Prozess zur Fehlerisolierung, um einen Fehler in der Steuerung entweder zu einem Hardwarefehler oder zu einem Softwarefehler zu isolieren, basierend auf den Bedingungen für jeden erzeugten Fehler gemäß der Offenbarung.

AUSFÜHRLICHE BESCHREIBUNG
Die Komponenten der offenbarten Ausführungsformen, die hierin beschrieben und veranschaulicht sind, können in einer Vielfalt von verschiedenen Konfigurationen angeordnet und konstruiert sein. Daher ist die folgende ausführliche Beschreibung der Ausführungsformen nicht dazu gedacht, den Umfang der Offenbarung, wie beansprucht, einzuschränken, sondern sie ist lediglich repräsentativ für mögliche Ausführungsformen davon. Obwohl zahlreiche spezielle Einzelheiten in der folgenden Beschreibung offengelegt werden, um ein gründliches Verständnis der hierin offenbarten Ausführungsformen bereitzustellen, können zudem einige Ausführungsformen ohne einige oder alle diese Details in die Praxis umgesetzt werden. Darüber hinaus wurde der Klarheit halber bestimmtes technisches Material, das im Stand der Technik bekannt ist, nicht im Detail beschrieben, um ein unnötiges Verschleiern der Offenbarung zu vermeiden. Darüber hinaus kann die Offenbarung, wie hierin veranschaulicht und beschrieben, in Abwesenheit eines Elements ausgeführt werden, das hierin nicht ausdrücklich offenbart ist.
Unter Bezugnahme auf die Zeichnungen, worin gleiche Bezugszeichen gleichen oder ähnlichen Komponenten in den verschiedenen Figuren entsprechen, veranschaulicht 1 in Übereinstimmung mit hierin offenbarten Ausführungsformen ein Fahrzeug 100 mit einem Antriebssystem 10, das mit einer Steuerung 20 in Verbindung steht und durch diese betriebsmäßig gesteuert wird. Die Steuerung 20 beinhaltet eine oder mehrere Steuerroutinen in Form von ausführbaren Algorithmen 22 und Kalibrierungen 24, die zum Steuern von einer oder mehreren Fahrzeugoperationen vorgesehen sind.
Die Steuerung 20 ist in Verbindung mit einem Controller-Area-Netzwerk (oder CAN) 30, das einen Kommunikationsbus 11 und eine Kommunikationssteuerung 40 beinhaltet. Die Kommunikationssteuerung 40 beinhaltet vorzugsweise Vorrichtungen und Routinen, die mit einer Cloud Computing-Umgebung 60 drahtlos kommunizieren können, wie beispielsweise ein drahtloses Telematik-Kommunikationssystem, das zur drahtlosen Kommunikation geeignet ist. Die Kommunikationssteuerung 40 beinhaltet vorzugsweise auch Vorrichtungen und Routinen zum Kommunizieren über einen Datenlink 45 mit einem Scan-Tool 55, wie sie z.B. in einer Fahrzeugservicezentrum 50 verfügbar sind. Das Fahrzeug kann, ohne darauf eingeschränkt zu sein, eine mobile Plattform in Form eines Nutzfahrzeuges, Industriefahrzeuges, landwirtschaftlichen Fahrzeugs, Personenkraftwagens, Flugzeugs, Wasserfahrzeugs, Zugs, Geländefahrzeugs, einer persönlichen Bewegungsvorrichtung, Roboters und dergleichen beinhalten, um die Zwecke der vorliegenden Offenbarung zu erfüllen. Das Antriebssystem 10 kann eine geeignete Konfiguration sein, die eine oder eine Vielzahl von drehmomenterzeugenden Vorrichtungen, Getrieben und Antriebsvorrichtungen beinhaltet, die Antriebskraft erzeugen und auf ein oder mehrere Bodenräder übertragen können, um den Vortrieb zu bewirken.
Eine Benutzeroberfläche 26 ist so angeordnet, dass sie die mit der Fahrzeugbedienung zusammenhängenden Bedienbefehle erkennt, die an die Steuerung 20 übermittelt werden. Die Benutzeroberfläche 26 beinhaltet eine Vielzahl von Vorrichtungen, die es einem Benutzer ermöglichen, mit dem Fahrzeug 100 zu interagieren, um dessen Betrieb zu steuern und zu kontrollieren, einschließlich der Steuerung von Elementen des Antriebssystems 10. Derartige Vorrichtungen können als nicht einschränkende Beispiele unter anderem ein Gaspedal, ein Bremspedal, einen Getriebeschalthebel, ein Lenkrad und/oder ein Tempomat beinhalten.
Die Steuerung 20 beinhaltet vorzugsweise Speichervorrichtungen, die ausführbaren Code 22 und Kalibrierungen 24 zur dynamischen Steuerung des Antriebssystems 10 beinhalten. Die Begriffe „Steuerung“ und verwandte Begriffe wie Steuermodul, Modul, Steuern, Steuereinheit, Prozessor und Ähnliches beziehen sich auf eine oder mehrere Kombinationen anwendungsspezifischer integrierter Schaltkreis(e) (ASIC), elektronische(r) Schaltkreis(e), Zentraleinheit(en), wie z. B. Mikroprozessor(en) und diesen zugeordnete nicht-flüchtige Speicherkomponenten in Form von Speicher- und Speichergeräten (Lesespeicher, programmierbarer Lesespeicher, Direktzugriff, Festplatte usw.). Die nichttransitorische Speicherkomponente ist in der Lage, maschinenlesbare Befehle in der Form einer oder mehrerer Software- oder Firmware-Programme oder -Routinen, kombinatorischen Logikschaltung(en), Eingabe-/Ausgabeschaltung(en) und -vorrichtungen, Signalaufbereitungs- und Pufferschaltungen und anderen Komponenten zu speichern, auf die durch einen oder mehrere Prozessoren zugegriffen werden kann, um eine beschriebene Funktionalität bereitzustellen. Zu den Ein- und Ausgabevorrichtungen und Schaltungen gehören Analog-/Digitalwandler und ähnliche Vorrichtungen, die Sensoreingaben mit einer vorgegebenen Abruffrequenz oder in Reaktion auf ein Auslöseereignis überwachen. Software, Firmware, Programme, Befehle, Steuerroutinen, Code, Algorithmen und ähnliche Begriffe beziehen sich auf von einer Steuereinheit ausführbaren Befehlssätze, wie z. B. Kalibrierungen und Wertetabellen. Jede Steuereinheit führt für Steuerroutine(n) aus, um die gewünschten Funktionen, darunter auch die Überwachung der Eingaben von Sensorgeräten und anderen vernetzten Steuereinheiten, bereitzustellen, und führt zudem Steuer- und Diagnoseroutinen aus, um die Betätigung von Stellgliedern zu steuern. Die Routinen können in regelmäßigen Intervallen, wie z. B. während des laufenden Betriebs alle 100 Mikrosekunden, ausgeführt werden. Alternativ dazu können Routinen in Reaktion auf ein Auslöseereignis ausgeführt werden. Die Kommunikation zwischen den Steuerungen und die Kommunikation zwischen Steuerungen und Stellgliedern und/oder Sensoren können über eine direkte Drahtverbindung, einen vernetzten Kommunikationsbus, z. B. den Kommunikationsbus 11, eine drahtlose Verbindung oder eine andere geeignete Kommunikationsverbindung erfolgen. Die Kommunikation beinhaltet den Austausch von Datensignalen auf eine geeignete Art, darunter auch z. B. elektrische Signale über ein leitfähiges Medium, elektromagnetische Signale durch die Luft, optische Signale über Lichtwellenleiter und dergleichen. Datensignale können diskrete, analoge oder digitalisierte analoge Signale beinhalten, die Eingaben von Sensoren und Stellgliedbefehle, sowie Kommunikationssignale zwischen Steuereinheiten darstellen. Der Begriff „Signal“ bezieht sich auf eine physisch wahrnehmbare Anzeige, die Informationen übermittelt und kann eine geeignete Wellenform (z. B. elektrische, optische, magnetische, mechanische oder elektromagnetische) umfassen, wie beispielsweise Gleichstrom, Wechselspannung, Sinuswellen, Dreieckswelle, Rechteckwelle, Vibration und dergleichen, die durch ein Medium laufen können. Der Begriff „Modell“ bezeichnet einen prozessorbasierten oder einen mittels des Prozessors ausführbaren Code und der zugehörigen Kalibrierung, die die physische Existenz einer Vorrichtung oder eines physischen Prozesses simuliert. Wie hier verwendet, beschreibt der Begriff „dynamisch“ Schritte oder Prozesse, die in Echtzeit ausgeführt werden und durch das Überwachen oder sonstige Ermitteln von Parameterzuständen und dem regelmäßigen oder periodischen Aktualisieren von Parameterzuständen beim Ausführen einer Routine oder zwischen Iterationen beim Ausführen der Routine gekennzeichnet sind.
Die Begriffe „Kalibrierung“, „Kalibrieren“ und verwandte Begriffe beziehen sich auf ein Ergebnis oder ein Verfahren, das eine tatsächliche oder Standardmessung, die mit einer Vorrichtung verbunden ist, mit einer wahrgenommenen oder beobachteten Messung oder einer befohlenen Position vergleicht. Eine hierin beschriebene Kalibrierung kann auf eine speicherbare parametrische Tabelle, mehrere ausführbare Gleichungen oder eine jede geeignete Form reduziert werden, die durch die Steuerung 20 verwendet wird. Ein Parameter ist definiert als eine messbare Größe, die eine physikalische Eigenschaft einer Vorrichtung oder eines anderen Elements darstellt, die durch einen oder mehrere Sensoren und/oder ein physikalisches Modell erkennbar ist. Ein Parameter kann einen diskreten Wert aufweisen, z. B. „1“ oder „0“, oder kann stufenlos eingestellt werden.
Die Steuerung 20 ist ein Element eines fahrzeuginternen Computersystems und kann einen Computeralgorithmus, einen ausführbaren Maschinencode, ein nicht flüchtiges, computerlesbares Medium oder Softwareanweisungen ausführen, die in eine oder mehrere geeignete programmierbare Logikbausteine des Fahrzeugs programmiert wurden.
2 zeigt schematisch einen Steuerungsüberwachungsprozess 200 zum Überwachen einer Steuerung in einem Fahrzeug, z. B. die Steuerung 20 des Fahrzeugs 100. Der Steuerungsüberwachungsprozess 200 wird ausgeführt, um einen aufgetretenen Fehler zu erkennen und gegebenenfalls zu isolieren. Der Zweck des Steuerungsüberwachungsprozesses 200 ist es, einen Fehler F entweder zu einem Hardwarefehler oder zu einem Softwarefehler in der Steuerung 20 zu isolieren, basierend auf überwachten oder beobachteten Fahrzeugzuständen, die einem oder einer Vielzahl von Bedingungen C zugeordnet werden können. Der Steuerungsüberwachungsprozess 200 kann ein Element eines Fahrzeugcomputersystems sein, das durch einen Computeralgorithmus, einen maschinenausführbaren Code, ein nicht flüchtiges computerlesbares Medium oder durch Softwareanweisungen, die in eine geeignete(n) programmierbare(n) Logikvorrichtung(en) des Fahrzeugs programmiert sind, implementiert werden kann. Alternativ oder zusätzlich kann der Steuerungsüberwachungs prozess 200 in der Cloud Computing-Umgebung 60 ausgeführt werden. Alternativ oder zusätzlich kann der Steuerungsüberwachungs prozess 200 in einem Fahrzeugservicezentrum 50 ausgeführt werden. Die Lehren hierin in Bezug auf die funktionalen bzw. logischen Blockkomponenten bzw. verschiedene Verarbeitungsschritte beschrieben sein. Es ist zu beachten, dass derartige Blockkomponenten aus Hardware, Software- und/oder Firmware-Komponenten aufgebaut sein können, die konfiguriert wurden, um die spezifizierten Funktionen auszuführen.
Der hierin beschriebene Steuerungsüberwachungsprozess 200 beruht vorteilhaft auf unterschiedlichen Bedingungen, die mit unterschiedlichen Hardware- und Softwarefehlern, d. h. Fehlersignaturen, korrelieren. Das Konzept ist, dass, wenn ein Zustand C mit einem Fehler F korreliert ist, dann muss es einen statistisch signifikanten Unterschied zwischen den Wahrscheinlichkeitsverteilungen des Zustandes C zwischen Grundlinienbetrieb und Fehlerbetrieb geben. Wie hierin beschrieben, können die mit verschiedenen Steuerungsfehlern korrelierten Zustände durch Zustandsüberwachung und statistische Analyse identifiziert werden. Basierend auf den korrelierten Bedingungen können Hardware- und Softwarefehler der Steuerung isoliert werden. Tabelle 1 stellt Details dar, die für diese Analyse herangezogen werden können. Tabelle 1

Fehler/Bedingung (F)/(C) SW Ausführung SW Version Umgebung HW Version Montage werk In Gebrauch

SW Fehler X X - - - -

HW Konstru ktion/ Mfg - - X X X -

Fehler Nutzung sdauer - - X X - X
Die Fehler F lassen sich in Softwarefehler (SW Fehler) und Hardwarefehler (HW Fehler) kategorisieren, wobei die Hardwarefehler einen Fehler beinhalten können, der mit dem Steuerungsdesign oder der Fertigung (Design/Mfg) verbunden ist, und einen Fehler, der mit dem Betrieb und der Nutzungsdauer (Service Life) verbunden ist. Die Bedingungen C lassen sich in eine Software-Ausführungsbedingung (SW Ausführung), eine Software-Versionsbedingung (SW-Version), eine Umgebungsbedingung, eine Hardware-Versionsbedingung (HW-Version), eine Montagewerksbedingung und eine Betriebsbedingung unterteilen. Das ‚X‘ gibt an, welche Fehlerkategorie F mit einer bestimmten Kategorie der Bedingungen C korreliert.
Betriebszustände, die mit den Software-Ausführungsbedingungen verbunden sind, können als unbegrenzte Beispiele einen Software-Moduswechsel, Modultriggerung, Funktionsanfragen usw. beinhalten. Betriebszustände, die mit den Umgebungsbedingungen verbunden sind, beinhalten, als unbegrenzte Beispiele, Temperatur, Spannung, Vibration, Feuchtigkeit usw. Betriebszustände, die mit den Einsatzbedingungen in Verbindung gebracht werden, beziehen sich auf die Nutzungshistorie und beinhalten als unbegrenzte Beispiele thermische Zyklen, Spannungszyklen, akkumulierte Schwingungen, akkumulierte Luftfeuchtigkeit, Wegstrecke, Betriebszeit, usw.
Fehlermeldungen der Steuerung und damit zusammenhängende Parameter können das Auftreten einer Rückstellung beinhalten, z. B. Rückstellungstyp, Weckquelle, Rücksetzfrequenz und Zähler. Fehlermeldungen der Steuerung und damit zusammenhängende Parameter können Aktivitäten zur Verhinderung von Abschaltungen beinhalten, einschließlich Quelle und Frequenz. Fehlermeldungen der Steuerung und damit zusammenhängende Parameter können die Überwachung der Funktionsfähigkeit beinhalten, z. B. einen Fehlerzähler. Fehlermeldungen der Steuerung und damit zusammenhängende Parameter können die Überwachung der Betriebsart des Softwaremoduls beinhalten. Fehlermeldungen der Steuerung und damit zusammenhängende Parameter können die Überwachung des Speicherzustands beinhalten, z. B. Integritätsfehler, Speicherschutzfehler und/oder Stapelüberlauf. Fehlermeldungen der Steuerung und damit zusammenhängende Parameter können einen Fehlerschutzhaken im Betriebssystem beinhalten. Fehlermeldungen der Steuerung und damit zusammenhängende Parameter können die Überwachung von Diagnosesitzungen beinhalten, wie beispielsweise häufige fehlgeschlagene Neuprogrammierung, DTC-Clearing-Anforderung und/oder Fehler beim Start-/Schlüsselzugriff. Fehlermeldungen der Steuerung und damit zusammenhängende Parameter können die Überwachung von Kommunikationsfehlern wie beispielsweise E2E-Fehler (Endto-End-Fehler), Sicherheitsfehler, Busüberflutung und einen Kommunikationszähler beinhalten. Fehlermeldungen der Steuerung und damit zusammenhängende Parameter können einen Signalverfügbarkeitsfehler beinhalten, z. B. Terminüberwachung. Fehlermeldungen der Steuerung und damit zusammenhängende Parameter können einen Software-Watchdog-Manager SoH (Gesundheitszustand) beinhalten. Fehlermeldungen der Steuerung und damit zusammenhängende Parameter können eine allgemeine Fehlerüberwachung beinhalten, wie beispielsweise das Auftreten von Fehlern ohne Einstellung von DTCs und das Auftreten von DTCs, die über einen Diagnose-Ereignismanager erkannt werden.
Der Steuerungsüberwachungsprozess 200 kann als Reaktion auf das Erkennen oder Auftreten eines Fehlers, der mit der Steuerung 10 verbunden ist, ausgeführt werden. Der Steuerungsüberwachungsprozess 200 kann, wie beschrieben, auch ohne Störung periodisch ausgeführt werden.
Der Steuerungsüberwachungsprozess 200 beinhaltet das Ermitteln der mit dem Fahrzeug verbundenen Konfigurationsinformationen (Schritt 210), wie hierin beschrieben. Ein Datenerfassungsereignis zum Erfassen von Fahrzeugbetriebszuständen, die den Bedingungen C zugeordnet sind, wird ausgeführt (Schritt 220), wie im Detail unter Bezugnahme auf 3 beschrieben. Die statistische Analyse wird durchgeführt, um einen Fehler mit den Betriebszuständen des Fahrzeugs zu korrelieren, die einer der Bedingungen zugeordnet sind, und unter Verwendung der Konfigurationsinformationen, die dem Fahrzeug zugeordnet sind (Schritt 230), wie im Detail unter Bezugnahme auf 4 beschrieben. Ein Fehler in der Steuerung 20 kann basierend auf der statistischen Analyse (Schritt 240) entweder zu einem Hardwarefehler oder zu einem Softwarefehler isoliert werden, wie im Detail unter Bezugnahme auf 5 beschrieben. Das Ausführen einer Iteration endet danach (Schritt 250).
Konfigurationsinformationen, die dem Fahrzeug 100 (Schritt 210) zugeordnet sind, beinhalten Fahrzeugmarke, Modell, Modelljahr, Fahrzeugidentifikationsnummer (VIN), Standort des Fahrzeugmontagebetriebs, Datum und Uhrzeit der Fahrzeugmontage, Herstellerseriennummer für die Steuerung 20, Softwarefreigabestufe für die Steuerung 20, Kalibrierfreigabestufe für die Steuerung 20, In-Field-Softwarefreigabe und Aktualisierungen der Kalibrierfreigabe für die Steuerung 20 sowie weitere relevante Informationen.

3 zeigt schematisch ein Datenerfassungsereignis 300, das den Betriebszuständen des Fahrzeugs zugeordnet ist, d. h. Schritt 220 von 2. Tabelle 2 wird als Schlüssel bereitgestellt, in der nummerisch beschriftete Blöcke und entsprechende Funktionen wie folgt dargelegt sind. Tabelle 2

BLOCK	BLOCKINHALTE
302	Auslösen des Datenerfassungsereignisses
304	Wurde ein Fehler gemeldet?
306	Sammeln von Basisdaten?
308	Erfassen und Aufzeichnen von DTCs und Fehlermeldungen
310	Aufzeichnen von Betriebszuständen in Verbindung mit Umgebungsbedingungen
312	Aufzeichnen von Betriebszuständen in Verbindung mit SW-Ausführungs bedingungen
314	Aufzeichnen von Fahrzeugbetriebszuständen
316	Zeit-/Daturnsstempel der Aufzeichnung
320	Ende

Das Ausführen des Datenerfassungsereignisses 300 kann wie folgt ablaufen. Die Schritte können in einer geeigneten Reihenfolge ausgeführt werden und sind nicht auf die Reihenfolge, die mit Bezug auf 3 beschrieben ist, beschränkt. Das Datenerfassungsereignis wird entweder periodisch oder als Reaktion auf ein Ereignis (302) ausgelöst und beinhaltet das Ermitteln, ob ein Fehler an die Steuerung 20 oder durch die Steuerung 20 (304) gemeldet wurde. Wenn ein Fehler gemeldet wurde (304)(1), werden alle zugehörigen Diagnosefehlercodes (DTCs) und die zugehörigen Fehlermeldungen erfasst und in einer Speichervorrichtung der Steuerung 10 oder an einer anderen Stelle (308) aufgezeichnet. Zugehörige Fehlermeldungen können Standbild-Ereignisse beinhalten.
Wenn kein Fehler gemeldet wurde (304)(0), kann dies ein Hinweis darauf sein, dass eine periodische Erfassung von Basisdaten (306) erforderlich ist, und wenn ja, werden diese Basisdaten erfasst (306)(1).
Die Datenerfassung beinhaltet das Aufzeichnen von Betriebszuständen in Verbindung mit den Umgebungsbedingungen (310), die vorzugsweise Umgebungstemperatur, Luftfeuchtigkeit, Höhe/Druck, Spannungspegel, Schwingungspegel, Niederschlag und Längen-/Breitenkoordinaten beinhalten.
Die Datenerfassung beinhaltet das Aufzeichnen von Betriebszuständen in Verbindung mit Software-Ausfiihrungsbedingungen (312), die vorzugsweise das Identifizieren des Vorhandenseins oder Auftretens von Ereignissen wie beispielsweise Modusänderungen, Modulauslöser-Ereignisse, wie z. B. Ein- oder Ausschaltereignisse, und Funktionsanforderungen beinhalten.
Die Datenerfassung beinhaltet das Aufzeichnen von Fahrzeugbetriebszuständen (314), die vorzugsweise Fahrzeugkilometerzähler, Fahrzeuggeschwindigkeit, Antriebsstrang-Betriebsart, wie Hybrid- oder Elektrofahrzeug, Getriebezustand, Lenkradwinkel, Gaspedalstellung, Bremspedalstellung, Tempomat-Sollwert usw. beinhalten.
Die Datenerfassung beinhaltet das Aufzeichnen eines Zeit-/Datumsstempels, der vorzugsweise Tag, Datum, Stunde, Minute und Sekunde der Betriebszustände (316) beinhaltet.
Wenn die gesamte vorgenannte Datenerfassung abgeschlossen ist, endet (320) diese Iteration der Routine 300.

4 zeigt schematisch einen statistischen Analyseprozess 400 zum Korrelieren eines Fehlers mit den Fahrzeugbetriebszuständen, die den Bedingungen C zugeordnet sind, d. h. Schritt 230 von 2. Tabelle 3 dient zur Aufschlüsselung, in der die numerisch beschrifteten Blöcke und entsprechenden Funktionen wie folgt dargelegt sind. Tabelle 3

BLOCK	BLOCKINHALTE
402	Schätzwert P_C ^B, P_C ^F für jede Bedingung C
404	Berechnen des statistischen Abstands D_C ^F basierend auf P_C ^B, P_C ^F
406	Identifizieren des Satzes von Bedingungen C, die mit jedem einer Vielzahl von Fehlern F korrelieren.
408	Ausgabesatz der korrelierten Bedingungen C für jeden Fehler F
410	Ende

Die Ausführung des statistischen Analyseprozesses 400 fährt wie folgt fort. Die Basislinien- und Fehlerwahrscheinlichkeitsverteilungen P_C ^B, P_C ^F werden für jede Bedingung C (404) geschätzt. Die Basiswahrscheinlichkeitsverteilung P_C ^B stellt eine geschätzte Wahrscheinlichkeitsverteilung dar, die mit der Bedingung C für den Basisbetrieb verbunden ist, d. h. wenn kein Fehler im System vorliegt. Die Fehlerwahrscheinlichkeitsverteilung P_C ^F stellt eine geschätzte Wahrscheinlichkeitsverteilung im Zusammenhang mit der Bedingung C dar, wenn ein Fehler F im System vorliegt. Es kann eine Vielzahl von Bedingungen C und eine Vielzahl von Fehlern F vorliegen. Im Falle der diskreten Wahrscheinlichkeitsverteilung kann sie unter Verwendung einer Maximum-Likelihood-Schätzung (MLE) ermittelt werden. MLE ist ein statistisches Verfahren zum Schätzen von Modellparametern, das bestimmt, welche Modellparameter am ehesten geeignet sind, einen gegebenen Datensatz zu charakterisieren, wobei ein vorgegebenes ausführbares Modell verwendet wird. Bei kontinuierlicher Wahrscheinlichkeitsverteilung kann ein Kerndichte-Schätzverfahren verwendet werden, um die Funktion der Wahrscheinlichkeitsdichte zu schätzen. Kerndichte-Schätzungen stehen in engem Zusammenhang mit Histogrammen, können aber mit Eigenschaften wie Glätte oder Kontinuität versehen werden, indem man einen geeigneten Kernel verwendet.
Ein statistischer Abstand D_C ^F kann basierend auf den Basislinien- und Fehlerwahrscheinlichkeitsverteilungen P_C ^B, P_C ^F (404) berechnet werden, wobei eine geeignete analytische Technik wie eine Kullback-Leibler-(KL)-Divergenz verwendet wird. Der statistische Abstand D_C ^F kann als Korrelationskoeffizient für die Bedingung C und Fehler F bezeichnet werden. Als solches besteht eine erhöhte Korrelation zwischen Bedingung C und Fehler F mit einer Erhöhung des statistischen Abstandes D_C ^F.
Eine Kullback-Leibler-(KL)-Divergenz kann wie folgt ausgedrückt werden: $D_{KL} (P ∥ Q) = \sum_{i} P (i) log \frac{P (i)}{Q (i)} .$
worin

D_KL (P||Q) den statistischen Abstand zwischen den Verteilungen P und Q darstellt;
P(i) die Fehlerwahrscheinlichkeitsverteilung darstellt; und
Q(i) die Basiswahrscheinlichkeitsverteilung darstellt.

Eine Teilmenge der Bedingungen C, die mit jedem der Vielzahl von Fehlern F korrelieren, kann identifiziert werden (406), wobei entweder ein Schwellenwertverfahren oder ein Daten-Clustering-Ansatz basierend auf den Korrelationskoeffizienten verwendet wird.
Der hierin beschriebene Steuerungsüberwachungsprozess 200 beruht vorteilhaft auf unterschiedlichen Bedingungen, die mit unterschiedlichen Hardware- und Softwarefehlern, d. h. Fehlersignaturen, korrelieren. Wenn eine Bedingung C mit einem Fehler F korreliert ist, dann muss es einen statistisch signifikanten Unterschied zwischen den Wahrscheinlichkeitsverteilungen des Zustandes C zwischen Grundlinienbetrieb und Fehlerbetrieb geben. Ein Satz von korrelierten Bedingungen C für jeden Fehler F kann erzeugt und für die zukünftige Verwendung erfasst werden (408), und diese Iteration des statistischen Analyseprozesses 400 kann enden (410).

Ein Fehler in der Steuerung kann basierend auf der statistischen Analyse (Schritt 240) entweder zu einem Hardwarefehler oder zu einem Softwarefehler isoliert werden, wie im Detail unter Bezugnahme auf 5 und Tabelle 1 beschrieben. 5 zeigt schematisch einen Fehlerisolierungsprozess 500 zum Isolieren eines Fehlers in der Steuerung entweder zu einem Hardwarefehler oder zu einem Softwarefehler, basierend auf dem Satz von Bedingungen C für jeden Fehler F, der erzeugt und für die zukünftige Verwendung durch den statistischen Analyseprozess 400 erfasst wird. Die Tabelle 4 wird als Schlüssel bereitgestellt, in der numerisch beschriftete Blöcke und entsprechende Funktionen wie folgt dargelegt sind. Tabelle 4

BLOCK	BLOCKINHALTE
502	Start
504	Korreliert der Satz der Bedingungen C für Fehler F mit den Softwarezuständen und/oder Softwareversionen, nicht aber den Umgebungszuständen?
506	Korreliert der Satz der Bedingungen C für Fehler F mit den Umgebungszuständen und/oder Hardwareversionen, nicht aber mit den Softwarezuständen und/oder - versionen?
508	Fehler der Ausgabesoftware
510	Die Ausgabe bedarf weiterer Untersuchungen
512	Korreliert der Satz von Bedingungen C für Fehler F mit den Zuständen der Montagewerke und des Fertigungsplans/der Fertigungszeit, aber nicht mit der Betriebshistorie?
514	Ausgabehardware Design/Fertigungsfehler
516	Ausgabehardware Fehler am Ende der Nutzungsdauer
518	Ende

Die Ausführung des Fehlerisolierungsprozesses 500 kann wie folgt erfolgen, um einen Fehler, der mit der Steuerung verbunden ist, zu einem Hardwarefehler oder einem Softwarefehler zu isolieren, der auf der statistischen Analyse basiert, die einen Fehler mit den Betriebszuständen des Fahrzeugs und den Konfigurationsinformationen, die mit dem Fahrzeug verbunden sind, korreliert, einschließlich des Satzes von Bedingungen C für jeden Fehler F, der erzeugt und erfasst wurde, wie in Bezug auf Schritt 408 von 4 beschrieben. Der Fehlerisolierungsprozess 500 bewertet, ob die Menge der korrelierten Bedingungen C, die mit Fehler F korreliert sind, mit Softwarezuständen und/oder Softwareversionen, aber nicht mit Umgebungszuständen (504) zusammenhängen, und wenn ja (504)(1), wird eine Ausgabe erzeugt, die einen Softwarefehler (508) anzeigt, und diese Iteration endet (518). Andernfalls (504)(0), bewertet der Fehlerisolierungsprozess 500, ob die Menge der Bedingungen C, die mit Fehler F korreliert sind, mit Umgebungszuständen und/oder Hardwareversionen zusammenhängen, aber nicht mit Softwarezuständen und/oder Versionen (506). Ist dies nicht der Fall (506)(0), wird eine Ausgabe erzeugt, die auf die Notwendigkeit weiterer Untersuchungen hinweist (410). Wenn ja (506)(1), bewertet der Fehlerisolierungsprozess 500, ob die Menge der Bedingungen C, die mit dem Fehler F korreliert sind, mit dem Montagewerk und den Fertigungsplan/Zeitzuständen zusammenhängen, aber nicht mit der Betriebshistorie (512). Wenn ja (512)(1), wird eine Ausgabe erzeugt, die einen Fehler anzeigt, der mit dem Hardware-Design und/oder der Fertigung (514) verbunden ist, und diese Iteration endet (518). Wenn nicht (512)(0), wird eine Ausgabe erzeugt, die einen Fehler anzeigt, der mit der Nutzungsdauer der Steuerung (516) verbunden ist, und diese Iteration endet (518).
Ausführungsformen in Übereinstimmung mit der aktuellen Offenbarung können als Apparatur, Verfahren oder Produkt eines Computerprogrammes dargestellt werden. Dementsprechend kann die vorliegende Offenbarung die Form einer vollständigen Hardwareausführungsform, eine vollständige Softwareausführungsform (einschließlich Firmware, residenter Software, Mikrocode usw.) oder eine Ausführungsform annehmen, die Software- und Hardwareaspekte kombiniert, die hier im Allgemeinen als „Modul“ oder „System“ bezeichnet werden können. Außerdem kann die vorliegende Offenbarung die Form eines Computerprogrammprodukts annehmen, welches in einem konkreten Ausdrucksmedium, das über einen für Computer verwendbaren Programmcode verfügt, eingesetzt werden kann.
Ausführungsformen können auch in Cloud-Umgebungen von Computern implementiert werden. In dieser Beschreibung und den folgenden Ansprüchen kann „Cloud-Anlagen“ als ein Modell für das Ermöglichen eines universellen, bequemen, nach Bedarf Netzwerkzuganges zu einem gemeinsam genutzten Pools von konfigurierbaren Ressourcen (z. B. Netzwerke, Server, Speicher, Anwendungen und Services), der schnell über Virtualisierung freigeschaltet und mit einem minimalen Managementaufwand oder Interaktion des Dienstanbieters ausgelöst und dann entsprechend skaliert wird, definiert werden. Ein Cloud-Modell kann aus verschiedenen Eigenschaften (z. B., Selbstbedienung nach Bedarf, breiter Netzwerkzugang, Bündelung von Ressourcen, schnelle Elastizität, gemessener Dienst usw.), Servicemodellen (z. B. Software als ein Service („SaaS“), Plattform als ein Service („PaaS“), Infrastruktur als ein Service („IaaS“) und Entwicklungsmodelle (z. B. private Cloud, Kommunikationscloud, öffentliche Cloud, Hybridcloud usw.) zusammengestellt werden.
Das Flussdiagramm und die Blockdiagramme in den Flussdiagrammen veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedener Ausführungsformen der vorliegenden Offenbarung. In dieser Hinsicht kann jeder Block in den Flussdiagrammen oder Blockdiagrammen ein Modul, ein Segment oder einen Abschnitt eines Codes darstellen, der zum Implementieren der spezifizierten logischen Funktion(en) einen oder mehrere ausführbare Befehle umfasst. Es wird auch darauf hingewiesen, dass jeder Block der Blockdiagramme und/oder Flussdiagrammdarstellungen und Kombinationen von Blöcken in den Blockdiagrammen und/oder Flussdiagrammdarstellungen durch Einzelzweck-Hardware-basierte Systeme, die die spezifizierten Funktionen oder Vorgänge durchführen, oder Kombinationen von Einzelzweck-Hardware und Computerbefehlen implementiert werden können. Diese Computerprogrammanweisungen können auch in einem computerlesbaren Medium gespeichert sein, das einen Computer oder eine andere programmierbare Datenverarbeitungsvorrichtung steuern kann, um in einer bestimmten Art und Weise zu funktionieren, sodass die in dem computerlesbaren Medium gespeicherten Befehle einen Herstellungsartikel erzeugen, einschließlich Anweisungsmitteln, die die Funktion/Vorgang, der in dem Flussdiagramm und/oder Blockdiagrammblock oder Blöcken angegeben ist, implementieren.
Während die ausführliche Beschreibung und die Zeichnungen oder Figuren die vorliegenden Lehren unterstützen und beschreiben, wird der Umfang der vorliegenden Lehren jedoch einzig und allein durch die Ansprüche definiert. Während einige der besten Ausführungsformen und anderen Arten zur Ausführung der vorliegenden Lehren ausführlich beschrieben wurden, gibt es verschiedene alternative Konstruktionen und Ausführungsformen zur Umsetzung der vorliegenden Lehren, die in den hinzugefügten Ansprüchen definiert sind.

Claims

Verfahren zum Überwachen einer Steuerung für ein Fahrzeug, das Verfahren umfassend: das Erkennen des Auftretens eines mit der Steuerung verbundenen Fehlers; das Ermitteln von Konfigurationsinformationen, die dem Fahrzeug zugeordnet sind; das Ermitteln von Fahrzeugbetriebszuständen, die einer Vielzahl von Bedingungen zugeordnet sind; das Ausführen einer statistischen Analyse über eine Steuerung, um die Vielzahl von Fehlern mit den Fahrzeugbetriebszuständen, die mit einer Vielzahl von Zuständen und den Konfigurationsinformationen, die dem Fahrzeug zugeordnet sind, zu korrelieren; und das Isolieren der Vielzahl von Fehlern zu einem Hardwarefehler oder einem Softwarefehler, der mit der Steuerung verbunden ist, basierend auf der statistischen Analyse und den Konfigurationsinformationen, die dem Fahrzeug zugeordnet sind.
Verfahren nach Anspruch 1, worin das Ermitteln der Konfigurationsinformation das Ermitteln einer Steuerungshardwarekonfiguration, eines Software-Update-Levels, einer Steuerungsherstellungsstandortinformation, einer Fahrzeugmontagestandortinformation und eines Fahrzeugmontagedatums beinhaltet.
Verfahren nach Anspruch 1, worin das Ermitteln von Fahrzeugbetriebszuständen das Ermitteln des Auftretens von diagnostischen Fehlercodes und der dazugehörigen Fehlermeldungen umfasst.
Verfahren nach Anspruch 1, worin das Ermitteln von Fahrzeugbetriebszuständen das Ermitteln von Umgebungsbedingungen umfasst.
Verfahren nach Anspruch 4, worin die Umgebungsbedingungen Temperatur, Vibration, Feuchtigkeit, Niederschlag und geographische Lage umfassen.
Verfahren nach Anspruch 1, worin das Ermitteln von Fahrzeugbetriebszuständen das Ermitteln von Software-Ausführungszuständen umfasst.
Steuerung, operativ mit einem Antriebssystem eines Fahrzeuges verbunden und beinhaltend eine Speichervorrichtung, die ausführbaren Code und eine Kalibrierung beinhaltet, wobei der Anweisungssatz für Folgendes ausführbar ist: das Erkennen des Auftretens eines mit der Steuerung verbundenen Fehlers; das Ermitteln von Konfigurationsinformationen, die dem Fahrzeug zugeordnet sind; das Ermitteln von Fahrzeugbetriebszuständen, die einer Vielzahl von Bedingungen zugeordnet sind; das Ausführen einer statistischen Analyse, um eine Vielzahl von Fehlern mit den Fahrzeugbetriebszuständen, die der Vielzahl von Zuständen und den Konfigurationsinformationen zugeordnet sind, die dem Fahrzeug zugeordnet sind, zu korrelieren; und das Isolieren der Vielzahl von Fehlern in der Steuerung zu einem Hardwarefehler oder einem Softwarefehler, basierend auf der statistischen Analyse und den Konfigurationsinformationen, die dem Fahrzeug zugeordnet sind.
Steuerung nach Anspruch 7, worin der Anweisungssatz ausführbar ist, um eine statistische Analyse durchzuführen, um die Vielzahl von Fehlern mit den Fahrzeugbetriebszuständen, die der Vielzahl von Bedingungen zugeordnet sind, zu korrelieren, und die Konfigurationsinformationen, die dem Fahrzeug zugeordnet sind, umfassen den Anweisungssatz, der für Folgendes ausführbar ist: das Ermitteln von Basislinien- und Fehlerwahrscheinlichkeitsverteilungen für jede der Vielzahl von Bedingungen; das Ermitteln eines statistischen Abstands für jede der Vielzahl von Bedingungen basierend auf den Basislinien- und Fehlerwahrscheinlichkeitsverteilungen; und das Ermitteln von Korrelationen zwischen den Fahrzeugzuständen und der Vielzahl von Fehlern basierend auf dem statistischen Abstand.
Steuerung nach Anspruch 7, umfassend den Anweisungssatz, der ausführbar ist, um eine Maximum-Likelihood-Schätzung zu ermitteln, um die Basislinien- und Fehlerwahrscheinlichkeitsverteilungen zu ermitteln.
Steuerung nach Anspruch 7, worin die Konfigurationsinformationen eine Steuerungshardwarekonfiguration, einen Software-Update-Level, Steuerungsherstellungsstandortinformationen, Fahrzeugmontagestandortinformationen und ein Fahrzeugmontagedatum beinhalten.