-
HINTERGRUND DER ERFINDUNG
-
Eine Ausführungsform eines Zustandsmanagement-Systems für Fahrzeuge.
-
In verteilten Zustandsmanagement-Systemen für Fahrzeuge findet die Ausführung und Kalibrierung von Algorithmen in der Cloud statt. Die Daten, die zur Ausführung in die Cloud geladen werden, mögen begrenzt sein, die für die Kalibrierung stellen jedoch ein Übermaß dar. Die Kosten der Datenübertragung zur und Datenverarbeitung in der Cloud sind für bestimmte Routinen von Komponenten oder Systemen unverhältnismäßig.
-
Konventionelle Systeme kalibrieren Diagnose-Algorithmen ausschließlich anhand von vielen Fahrzeugen in der Herstellungsphase, die Durchführung geschieht vollständig in der Fahrzeug-ECU. Zentralisierte Systeme sammeln alle Diagnose-Fehlercodes und Daten für Parameter-Identifikationscodes und laden ganze Datensätze in die Cloud, wo fortgeschrittene VHM-Algorithmen ablaufen. Das ist ein teures und rechenintensives Verfahren.
-
KURZDARSTELLUNG DER ERFINDUNG
-
Ein Vorteil einer Ausführungsform ist die Reduzierung der Übertragung von großen Datenmengen von einem Fahrzeug o.ä. Vorrichtung zu einer entfernten Einheit für die Verarbeitung der Daten. Das System und die hierin beschriebenen Techniken nutzen die ECU eines Fahrzeuges, oder ein Smartphone, um Daten vom Fahrzeug zu sammeln und Routinen des Zustandsmanagements für Fahrzeuge (VHM) ablaufen zu lassen, um den Zustand von Komponenten, Subsystemen oder Systemen zu beurteilen. Ein Zustandsmanagement-System für Fahrzeuge (VHM) umfasst typischerweise die folgenden Funktionen: Diagnosen (Erfassung, Isolierung (Fehlerart), Fehlerlokalisierung (wo)), Prognostik (Fehlervorhersage) und Fehlerverringerung (Änderung des Einsatzes des Bauelementes zur Verzögerung des Fehlereintritts). Basierend auf den Ausgaben der Zustandsmanagement-Routinen des Fahrzeugs werden nur bestimmte ausgewählte Datensätze in die Cloud hochgeladen, um dort von einer Einheit für die weitere Kalibrierung von Zustandsmanagement-Algorithmen für die Fahrzeuge oder fahrzeugeigenen Diagnose-Algorithmen genutzt zu werden. Im Ergebnis wird die Menge der zu übertragenden Daten reduziert, indem nur die für die Kalibrierung der VHM-Routinen erforderlichen Daten bereitgestellt werden.
-
Außerdem können VHM-Apps speziell auf einem Smartphone, in einer ECU o.ä. Gerät problemlos aktualisiert werden, ohne die ECU zur Aktualisierung der Algorithmen neu programmieren zu müssen.
-
Eine Ausführungsform stellt ein verteiltes Zustandsmanagement-Systeme für Fahrzeuge dar. Ein fahrzeugbezogener Diagnoseprozessor führt Diagnoseroutinen in einem Fahrzeug durch. Die Diagnoseroutinen erzeugen Diagnosedaten. Eine prozessorgestützte Vorrichtung lässt umfangreiche Zustandsmanagement-Routinen für das Fahrzeug ablaufen. Die prozessorgestützte Vorrichtung bestimmt den Zustand einer Komponente als eine Funktion aus den Diagnosedaten. Ein Telematikgerät überträgt mindestens eine Instanz von Zustandsdaten und Diagnosedaten des Fahrzeugs. Eine entfernte Einheit ist entfernt vom Fahrzeug positioniert. Die Einheit erhält Daten vom Telematikgerät. Die Daten sind eine selektive Teilmenge der Ausgabedaten von mindestens einem Diagnoseprozessor oder einer prozessorgestützten Vorrichtung. Die Einheit führt aufgrund der vom Fahrzeug empfangenen Daten die Kalibrierung von mindestens eine der Diagnoseroutinen und Zustandsmanagement-Routinen durch.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1 zeigt ein Blockschaltbild eines Zustandsmanagement-Systems für Fahrzeuge.
-
2 zeigt ein Flussdiagramm für ein Blockschaltbild zur Analyse von Komponenten und Systemen.
-
3 zeigt ein Flussdiagramm für ein Blockschaltbild zur Identifizierung von nachrichtenbezogenen Diagnose- und Prognoselösungen für ein Kommunikationsnetz.
-
4 zeigt ein Flussdiagramm für ein Blockschaltbild zur Vorhersage der verbleibenden Lebensdauer.
-
5a und 5b zeigen Beispielgraphen zur Modellveranschaulichung
-
6 zeigt ein Flussdiagramm für ein Blockschaltbild zur Kalibrierung von Diagnose-Algorithmen im Zusammenhang mit DTCs/MILs.
-
DETAILLIERTE BESCHREIBUNG
-
1 zeigt ein Blockschaltbild eines verteilten Zustandsmanagement-Systems für Fahrzeuge 10. Obwohl sich das hier beschriebene System auf ein Fahrzeug bezieht, versteht es sich, dass das System auch in einem Zug, Boot, Flugzeug oder einem anderen System, in dem Diagnoseroutinen ausgeführt werden, verbaut und eingesetzt werden kann.
-
Das verteilte Zustandsmanagement-System für Fahrzeuge (VHM) 10 enthält einen Diagnoseprozessor 12 zum Ausführen von Diagnoseroutinen in einem Fahrzeug 14. Zu den Beispielen für Diagnoseroutinen, die durch fahrzeugeigene Diagnose-Algorithmen durchgeführt werden können, gehört ohne Einschränkung der Motorbetrieb, bei dem Parameter-Identifikations-Codes (PIDs) und Diagnosefehler-Codes (DTCs) erzeugt werden.
-
DTCs sind im Fahrzeug beruhend auf fahrzeugeigenen Diagnose-Algorithmen festgelegt. Mit Geräten zur Service-Diagnose können DTCs aus dem Fehlerspeicher des Fahrzeugs ausgelesen werden und dienen zur Bestimmung des Fehlers im Fahrzeug. Jeder der Prozessoren im Fahrzeug verfügt über einen Speicher zur Ablage von DTCs wenn ein Fehler im Fahrzeug auftritt und erfasst wird. DTCs sind alphanumerische Codes zur Erkennung eines Fehlers, der in verschiedenen Komponenten des Fahrzeugs auftreten kann. Solche DTCs beziehen sich auf verschiedene elektrische Fahrzeugfunktionen, zu denen ohne Einschränkung Motorbetrieb, Emissionen, Bremsen, Antriebsstrang, Sicherheit und die Lenkung gehören. Jedes Subsystem kann seinen eigenen integrierten Prozessor zur Überwachung von Fehlern beim Betrieb des Teilsystems haben; es kann aber auch ein Prozessor für die Fehlerüberwachung bei einer Vielzahl von Subsystemen verantwortlich sein. Wenn der Subsystem-Prozessor einen Fehler erkennt, werden ein oder mehrere DTC(s) erzeugt.
-
PIDs können zur Ermittlung spezieller Informationen durch einen Sensor oder ähnliche Vorrichtung abgerufen werden. Ein PID-Code ist ein Betriebsparameter einer Komponente, der im Speicher einer ECU o.ä. abgelegt ist und über einen Scanner oder eine Fahrzeugschnittstelle über einen Kommunikationsbus abgefragt werden kann. Eines der Geräte im Kommunikationsbus erkennt den PID-Code im Rahmen seiner Verantwortlichkeit und sendet Informationen bezogen auf den PID-Code zurück, um weitere Details bezüglich eines oder mehrerer der Geräte(s) zu liefern, die Daten in Verbindung mit dem erkannten Fehler erfassen.
-
Eine prozessorgestützte Vorrichtung 16 agiert als sekundäres Bearbeitungsgerät und lässt umfangreiche Zustandsmanagement-Algorithmen für Fahrzeuge (VHM) ablaufen. Diese erweiterten VHM-Algorithmen nutzen die DTC/PID-Daten zur weiteren Auswertung des Systemzustands im Fahrzeug. Die prozessorgestützte Vorrichtung 16 kann über ein tragbares Kommunikationsgerät verfügen, beispielsweise ohne Einschränkung ein Smartphone oder ein HMI-Gerät des Fahrzeugs.
-
Ein Telematikgerät 18 dient als Gateway zur Übertragung von Daten zum und vom Fahrzeug. Das Telematikgerät 18 kann ein beliebiges Kommunikationsmedium enthalten, mit dem Daten vom Fahrzeug zu einer entfernten Einheit 20 übertragen werden können. Die Einheit 20 kann ein Back-Office mit Speicher, Server, und Computergeräten enthalten, das die Weiterverarbeitung von ausgewählten Daten zur Kalibrierung erweiterter VHM-Algorithmen und fahrzeugeigener Diagnose-Algorithmen ermöglicht. Die Einheit 20 kann einen Cloud Service oder eine feste Infrastruktur nutzen.
-
2 zeigt ein Flussdiagramm eines Blockschaltbilds zur Analyse von Komponenten, darunter ohne Einschränkung eine Batterie, einen Starter oder Kraftstoffkomponenten. Es versteht sich, dass der hier verwendete Begriff Komponente ein Teil, einen Satz Teile, ein Subsystem oder ein System definiert.
-
In Schritt 30 wird bestimmt, ob es ohne entsprechende rote Alarme eine Gewährleistung gibt. Rote Alarme werden durch VHM-Algorithmen festgelegt. Wird bestimmt, dass es ohne entsprechende rote Alarme keine Gewährleistung gibt, setzt die Routine die Schleife fort und überwacht auf rote Alarme. Wird bestimmt, dass rote Alarme vorhanden sind, dann fährt die Routine mit Schritt 32 fort.
-
In Schritt 31 wird eine Reihe von Fahrzeug-Identifizierungsnummern (FIN) der jeweiligen Flottenfahrzeuge für die Datensammlung ausgesucht.
-
In Schritt 32 wird als Reaktion auf die Bestimmung, ob eine Gewährleistung ohne entsprechenden roten Alarm besteht, der Status der FIN auf das Hochladen von Daten gesetzt.
-
Die Schritte 33–38 werden von der prozessorgestützten Vorrichtung ausgeführt. In Schritt 33 wird festgelegt, ob ein VHM-Algorithmus ausgelöst ist. VHM-Algorithmen werden entweder periodisch oder durch ein Ereignis ausgelöst. Beispielsweise kann nach jedem Anlassvorgang ein Prüfalgorithmus für den Zustand der Batterie ausgeführt werden. In einem anderen Beispiel wird ein Algorithmus in Bezug auf einen Lenkmotor nur dann ausgeführt, wenn der Fahrer das Lenkrad bedient hat, andernfalls besteht nicht genug Anregung zum Ausführen des Algorithmus. Weiterhin mit Bezug auf Schritt 33 erfolgt eine Rückkehr zu Schritt 33, wenn bestimmt wurde, dass der VHM-Algorithmus nicht ausgelöst ist. Wurde eine Auslösung des VHM-Algorithmus festgestellt, so fährt die Routine mit Schritt 34 fort.
-
In Schritt 34 werden Rohdaten des Fahrzeugs gesammelt. Zu den Rohdaten gehören alle DTC- und PID-Werte, die bei der Beurteilung des Zustands eines jeweiligen Systems im Fahrzeug hilfreich sein können.
-
In Schritt 35 werden die Daten in einem Ringspeicher abgelegt. Die Daten werden bei der Ausführung von Zustandsmanagement-Algorithmen gespeichert und abgerufen.
-
In Schritt 36 laufen VHM-Algorithmen ab. VHM-Algorithmen betreffen fahrzeugeigene Diagnosen zur Überprüfung und Bestimmung des Zustands von Komponenten im Fahrzeug.
-
In Schritt 37 wird basierend auf der Ausgabe der VHM-Algorithmen entschieden, ob ein roter Alarm vorliegt oder ob die FIN auf das Hochladen von Daten gesetzt ist. Ein hier beschriebener roter Alarm wird von VHM-Algorithmen gebildet, wenn eine Fehlerart oder ein Diagnosefehlercode identifiziert wurde. Wird festgestellt, dass ein roter Alarm vorhanden ist oder dass die FIN auf das Hochladen von Daten gesetzt ist, dann fährt die Routine bei Schritt 38 fort; ansonsten kehrt die Routine zurück zu Schritt 33 und überwacht, ob ein VHM-Algorithmus ausgelöst wird.
-
In Schritt 38 werden die Daten aus dem Bereich vor und nach einer jeweiligen Periode hochgeladen. Über das Telematikgerät werden die Erkenntnisse in eine Cloud oder ähnliche Vorrichtung zur Datenspeicherung hochgeladen.
-
In Schritt 39 wird der Kunde durch eine App, wie eine App auf einem Smartphone, per E-Mail, oder über ein anderes Kommunikationsgerät gewarnt, wenn eine Kundenwarnung als gerechtfertigt angesehen wird.
-
Neben Benachrichtigen des Kunden werden im Schritt 40 die VHM-Algorithmen unter Verwendung der Daten aus den Fahrzeugen mit der Entscheidungen zur Gewährleistung oder zu roten Alarmen kalibriert.
-
In Schritt 41 werden erforderlichenfalls neue Parameter oder Updates für das Fahrzeug-HMI oder das Smartphone heruntergeladen, auf denen die erweiterten VHM-Algorithmen für das Fahrzeug ablaufen.
-
Dieser Vorgang ist kostengünstig und es muss nur ein Bruchteil der gesamten Daten für diese jeweilige Anwendung in die Cloud geladen werden. Die Ausführung erfolgt durch die prozessorgestützte Vorrichtung im Fahrzeug und es werden nur ausgesuchte Daten (z.B. 0,5%) für die entfernte Einheit bereitgestellt.
-
3 zeigt ein Flussdiagramm eines Blockschaltbilds zur Identifizierung von nachrichtengestützten Diagnose- und Prognoselösungen für ein Kommunikationszonennetz (CAN).
-
Die Schritte 50–54 werden durch die prozessorgestützte Vorrichtung ausgeführt. In Schritt 50 wird festgestellt, ob ein VHM-Algorithmus ausgelöst ist. Wurde eine Auslösung des VHM-Algorithmus festgestellt, so fährt die Routine mit Schritt 51 fort; ansonsten verbleibt die Routine in der Schleife und überwacht auf eine Auslösung eines VHM-Algorithmus.
-
In Schritt 51 werden Rohdaten des Fahrzeugs erfasst und der prozessorgestützten Vorrichtung zugänglich gemacht.
-
In Schritt 52 laufen die erweiterten VHM-Algorithmen in der prozessorgestützten Vorrichtung ab.
-
In Schritt 53 wird basierend auf der Ausgabe der VHM-Algorithmen entschieden, ob ein roter Alarm vorliegt oder ob die FIN auf das Hochladen von Daten gesetzt ist. Wird festgestellt, dass ein roter Alarm vorhanden ist oder dass die FIN auf das Hochladen von Daten gesetzt ist, dann fährt die Routine bei Schritt 54 fort; ansonsten kehrt die Routine zurück zu Schritt 50.
-
In Schritt 54 werden als Reaktion auf die Ergebnisse der VHM-Algorithmen deren Entscheidungen in die Cloud hochgeladen.
-
In Schritt 55 wird ein Fahrzeughändler, oder anderes Wartungspersonal, durch einen Dienst informiert, der VHM-Ergebnisse mit den Händlern teilt. Alternativ können E-Mails oder jede andere Art von Kommunikationsdienst verwendet werden, um die Entscheidungsergebnisse der VHM-Algorithmen mitzuteilen.
-
Wenn der Händler aus den Entscheidungen den Schluss zieht, dass eine Topologie in irgendeiner Form verändert wurde, so informiert er bei Schritt 56 die entfernte Einheit (beispielsweise das Back-Office) von dieser Änderung. Die Topologie bezieht sich auf die Verbindungsinformationen (z.B. das Mapping) aller ECUs und Anschlüsse. Beispielsweise ist ein Batterie-Steuermodul (BCM) mit einem Inline-Stecker X1 verbunden und der Inline-Stecker X1 mit einem Motorsteuergerät (ECM), das ECM mit einem Drehmoment-Steuermodul (TCM) usw. Die Topologie kann auch Entfernungs- oder Widerstandswerte für jede Verbindung enthalten. Dank der Topologieinformation lässt sich der Ort des Fehlers (z.B. Bus zwischen BCM und TCM offen) bestimmen. Durch Änderungen der Topologie kann bestimmt werden, ob das Servicepersonal eine ECU-Verbindung geändert hat, oder herausfand, dass ein anderer Händler diese Änderung vorgenommen hat. Topologieinformationen werden basierend auf dem bestehenden Verbindungsstatus erstellt. Die Daten werden in einem speziellen Format erstellt, das vom VHM-Algorithmus gelesen werden kann.
-
In Schritt 57 werden als Reaktion auf die Benachrichtigung durch die Einheit neue oder aktualisierte Topologieinformationen erstellt.
-
Mit dem Schritt 58 wird die aktualisierte Topologie zur App für das Fahrzeug heruntergeladen, welches die Daten geliefert hat.
-
Dieser Vorgang ist kostengünstig und es müssen keine Daten für diese jeweilige Anwendung in die Cloud geladen werden. Die Ausführung erfolgt durch die prozessorgestützte Vorrichtung im Fahrzeug und es werden nur Entscheidungen zur Einheit geliefert, keine Daten.
-
4 zeigt ein Flussdiagramm eines Blockschaltbildes zur Vorhersage der verbleibenden Lebensdauer.
-
Die Schritte 60–63 stellen eine Trainingsphase dar. Das Training wird eingeleitet, um den jeweiligen Abbau der Lebensdauer zur Verwendung in der prozessorgestützten Vorrichtung des Fahrzeugs zu ermitteln. Es werden FIN für eine Flotte von Fahrzeugen zur Datensammlung ausgewählt.
-
In Schritt 61 werden Ausfalldaten der Flotte analysiert, um die Ausfallzeitpunkte der jeweiligen Komponenten zu bestimmen.
-
Im Schritt 62 wird ermittelt, welches Modell für den Lebensdauerabbau der Flotte verwendet werden sollte, damit die Trenddaten zum Modell passen. Es wird untersucht, ob das Lebensdauermodell prognostiziert, dass die Fahrzeugdaten in die gleiche Richtung tendieren wie das Modell. Dies kann durch einen Vergleich der für das Fahrzeug im Modell verwendeten Abbaudaten mit den Daten aller Flottenfahrzeuge festgestellt werden. Es stehen für die Bestimmung des richtigen Lebensdauermodells eine Reihe von Modellen zur Verfügung. Nach Auswahl des Modells wird bestimmt, ob die Abweichung zwischen den Daten und dem Modell minimiert wurde. Falls das zutrifft, ist sichergestellt, dass das gewählte Lebensdauermodell Vorhersagen in Übereinstimmung mit den Trenddaten macht.
-
Im Schritt 63 wird das Lebensdauermodell für die Flotte in die prozessorgestützte Vorrichtung im Fahrzeug geladen.
-
Die Schritte 64–68 werden von der prozessorgestützten Vorrichtung ausgeführt. Im Schritt 64 wird die Ausführung des Lebensdauermodells in der prozessorgestützten Vorrichtung durch die Feststellung eingeleitet, ob der VHM-Algorithmus ausgelöst ist. Wurde eine Auslösung des VHM-Algorithmus festgestellt, so fährt die Routine mit Schritt 65 fort; ansonsten verbleibt die Routine in der Schleife, bis ein VHM-Algorithmus ausgelöst wird.
-
Im Schritt 65 werden vom Fahrzeug Rohdaten erfasst. Zu den Rohdaten gehören alle DTC- und PID-Werte, die bei der Beurteilung des Zustands eines jeweiligen Systems im Fahrzeug hilfreich sein können.
-
Im Schritt 66 werden aktuelle und historische Daten in das ausgewählte Lebensdauermodell eingespielt. Dies erfolgt als eine Funktion des Flottenmodells. Als Trendfunktion wird ein Cluster gebildet. Durch Anwendung der Daten dieses Fahrzeugs kann festgestellt werden, ob ein bestimmter Trend am besten für dieses jeweilige Fahrzeug geeignet ist und es kann verifiziert werden, dass die Trenddaten in eine realistische Richtung zeigen (z.B. hat sich der Zustand verschlechtert und nicht verbessert). Das Flottenmodell wird im Fahrzeug implementiert und basierend auf den aktuellen Daten dieses Fahrzeugs bei einem minimalen mittleren quadratischen Fehler werden die am besten passenden Parameter gewählt. 5a und 5b zeigen Diagramme zur Bestimmung, ob unter Verwendung eines linearen und eines polynomischen Ausgleichs die Fahrzeugdaten in dieselbe Richtung tendieren. 5a zeigt einen Beispielverlauf für Widerstand und 5b einen Beispielverlauf für den Zustand. Wie in 5a gezeigt, befinden sich Datensamples auf der x-Achse und Widerstandswerte auf der y-Achse. Fahrzeugdaten werden allgemein durch 90 repräsentiert. Ein lineares Anpassungsmodell wird allgemein durch 92, ein polynomisches Anpassungsmodell durch 94 dargestellt. Wie aus dem Diagramm ersichtlich, wird das beste Anpassungsmodell basierend auf den aktuellen Daten dieses Fahrzeugs bei einem minimalen mittleren quadratischen Fehler gewählt. 5b zeigt einen Zustand unter Verwendung des gleichen besten Anpassungsmodells.
-
Im Schritt 67 wird das Lebensdauermodell für die Fahrzeugkomponente (ähnlich dem Prozess in Schritt 66) basierend auf Eigendaten zur Bestimmung der Zeit bis zu einem Ausfall angepasst. Als Beispiel wird ein Lebensdauermodell verwendet, um eine bestimmte Komponente einer polynomischen Regression folgen zu lassen. Werden Daten einer einzelnen Komponente Daten des besten Anpassungsmodells der Flotte gegenübergestellt und Komponentendaten weichen von den Flottendaten ab, so werden die Parameter der polynomischen Regression gemäß dem Datentrend der einzelnen Komponente angepasst.
-
Im Schritt 68 wird festgestellt, ob die Zeit des Ausfalls naht. Ist der Zeitpunkt des Ausfalls nahe, fährt die Routine bei Schritt 69 fort; ansonsten kehrt die Routine zu Schritt 64 zurück.
-
In Schritt 69 wird ein roter Alarm gesetzt, wenn die Entscheidungen der Lebensdauermodells in die Cloud oder eine andere Speichervorrichtung geladen werden.
-
In Schritt 70 wird der Kunde über eine App oder per E-Mail über die Zeit bis zu dem Ausfall informiert.
-
6 zeigt ein Flussdiagramm eines Blockschaltbildes zur Vorhersage von Routinen für die Kalibrierung von Routinen für DTC/MIL (Fehlerkontrollleuchte).
-
Die Schritte 80–83 werden von der prozessorgestützten Vorrichtung ausgeführt. In der prozessorgestützten Vorrichtung, beispielsweise das HMI-Gerät oder ein Smartphone, laufen die erweiterten Diagnoseroutinen ab. In Schritt 80 wird festgestellt, ob ein VHM-Algorithmus ausgelöst ist. Wurde eine Auslösung des VHM-Algorithmus festgestellt, so fährt die Routine mit Schritt 81 fort; ansonsten verbleibt die Routine in der Schleife und überwacht auf eine Auslösung eines VHM-Algorithmus.
-
Im Schritt 81 werden Rohdaten des Fahrzeugs gesammelt und in einem Ringspeicher abgelegt.
-
In Schritt 82 wird festgestellt, ob während einer vorbestimmten Anzahl von Tagen ein DTC/MIL gesetzt wurde. Wird festgestellt, dass innerhalb der vorbestimmten Anzahl von Tagen ein DTC/MIL gesetzt wurde, fährt die Routine mit Schritt 83 fort; ansonsten verbleibt die Routine in der Schleife und prüft, ob das DTC/ MIL in der zuvor festgelegten Anzahl von Tagen gesetzt wurde.
-
Im Schritt 83 werden Rohdaten bezüglich der Setzung von DTC/MIL in eine Cloud oder andere Speichervorrichtung geladen.
-
In Schritt 84 werden zur Überprüfung der Genauigkeit der Diagnose-Algorithmen Daten ausgewertet. Das kann von einem Datenanalytiker geleistet werden. Während DTC entsprechend auf den Ersatz der Kraftstoffpumpe eingestellt wird, kann aufgrund aller historischen Daten seit dem bestimmt werden, dass der DTC aufgrund der Geräusche gesetzt wurde. Falls dem so ist, dann ist der DTC ein Fehlalarm. Als Resultat kann die Genauigkeit des Algorithmus bestimmt werden.
-
In Schritt 85 werden als Reaktion auf Überprüfung der Genauigkeit der Diagnose-Algorithmen erforderlichenfalls die DTC/MIL-Algorithmen kalibriert.
-
In Schritt 86 werden die kalibrierten DTC/MIL-Algorithmen an technische Fachleute oder Ingenieure zur Modifikation des Codes der Algorithmen geschickt.
-
In Schritt 87 werden ECUs neu programmiert, um die Algorithmen zu aktualisieren.
-
Während bestimmte Ausführungsformen der vorliegenden Erfindung in Einzelheiten beschrieben wurden, werden Fachleute auf dem Gebiet, auf das sich diese Erfindung bezieht, verschiedene alternative Entwürfe und Ausführungsformen für die Durchführung der Erfindung erkennen, wie durch die folgenden Patentansprüche bestimmt.
