-
TECHNISCHES GEBIET
-
Die veranschaulichenden Ausführungsformen betreffen im Allgemeinen Verfahren und Vorrichtungen für die Fahrzeugsystemverschleißvorhersage.
-
ALLGEMEINER STAND DER TECHNIK
-
Die Fähigkeit, Daten von einer großen Anzahl an Fahrzeugen auf der Straße zu sammeln, macht eine neue Stufe der Analyse möglich. Interessierte Parteien können Verkehr und Wetter, Leistung, Straßencharakteristika und alle anderen Arten von Daten sammeln, die Daten zusammenfassen und eine breite Analyse durchführen. Vor dem Bestehen von Telematikeinheiten, dem Ermöglichen einer Berichterstellung nach Bedarf und/oder einer regelmäßigen Berichterstellung war das Sammeln dieses Umfangs an Daten eine schwierige Aufgabe. Nun können jedoch viele Fahrzeuge auf Anfrage Daten melden und mit ausreichend Daten können Vorhersagen bezüglich vieler Systeme formuliert und optimiert werden.
-
Durch das Beobachten verschiedener Situationen und Fahrzustände können viele zusammengefasste beobachtete Aktualitäten zusammengefasst werden, um eine angemessene Vorhersage hinsichtlich ähnlicher Bedingungen, unter denen ein ähnlicher Fall erneut auftreten wird, zu bilden. Wenn beispielsweise 100.000 Elektrofahrzeuge einen Abfall der Energieeffizienz von 0,2 % melden, wenn die Temperatur auf unter 20 Grad fällt, wären diese Daten nützlich, um zu bestimmen, dass eine Ursache-Wirkung wahrscheinlich auftritt, und die Daten wären ebenfalls für andere Fahrzeug nützlich, die versuchen, eine „Strecke bis leer“ unter Betriebsbedingungen unter 20 Grad vorherzusagen.
-
Es gibt eine breite Vielfalt bei der Anwendung von über Crowdsourcing erfassten Daten und die veranschaulichenden Ausführungsformen zeigen einige Beispiele für ein nützliches Konzept, welches unter solch einem Modell erreichbar ist.
-
KURZDARSTELLUNG
-
In einer ersten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der dazu konfiguriert ist, erste Nutzungsdaten in Verbindung mit einem Verschleißzustandsbericht, welcher ein erfasstes Ausmaß von Systemverschleiß angibt, von einer Vielzahl von Fahrzeugen drahtlos zu empfangen. Der Prozessor ist außerdem dazu konfiguriert, die ersten Nutzungsdaten zusammenzufassen und zu analysieren, um gemeinsame Parameter und entsprechende Werte, die für das erfasste Ausmaß des Systemverschleißes indikativ sind, zu bestimmen. Der Prozessor ist ferner dazu konfiguriert, zweite Nutzungsdaten von einem Fahrzeug, welches keinen Sensor aufweist, der in der Lage ist, das erfasste Ausmaß des Systemverschleißes zu erfassen, drahtlos zu empfangen. Außerdem ist der Prozessor dazu konfiguriert, Werte der gemeinsamen Parameter in den zweiten Nutzungsdaten mit den bestimmten Werten, die für das erfasste Ausmaß des Systemverschleißes indikativ sind, zu vergleichen und einen wahrscheinlichen Verschleißzustand an das Fahrzeug, welches keinen Sensor aufweist, als Reaktion auf den Vergleich, der ein Ausmaß des Systemverschleißes ähnlich wie der erfasste Ausmaß des Systemverschleißes angibt, zu melden.
-
In einer zweiten veranschaulichenden Ausführungsform beinhaltet ein computerimplementriertes Verfahren Empfangen von Teile-bezogenen Nutzungsdaten, beinhaltend zusammengefasste Nutzung von Fahrzeugsystemen, die einen Verschleiß an einem ersten Teil verursachen, von einer Vielzahl von ersten Fahrzeugen, gemeldet in Verbindung mit einem Sensor in jedem der ersten Fahrzeuge, die ein gemessenes Verschleißausmaß des ersten Teils melden. Das Verfahren beinhaltet außerdem Analysieren der Nutzungsdaten, um Nutzungsparameterwerte zu bestimmen, die für das Verschleißausmaß indikativ sind. Das Verfahren beinhaltet ferner Bestimmen, ob ein projiziertes Verschleißausmaß eines zweiten Teils in einem zweiten Fahrzeug das gemessene Verschleißausmaß des ersten Teils erreicht hat, auf Grundlage von zusammengefassten Nutzungsdaten, die von dem zweiten Fahrzeug empfangen wurden, im Vergleich zu Nutzungsparameterwerten. Außerdem beinhaltet das Verfahren Warnen eines Fahrers des zweiten Fahrzeugs, wenn das voraussichtliche Verschleißausmaß das Verschleißausmaß erreicht.
-
In einer dritten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der dazu konfiguriert ist, Teile-bezogene Fahrzeugsystemnutzungsdaten zusammenzufassen und zu vergleichen, die von einer Vielzahl von ersten Fahrzeugen in Verbindung mit einem Fahrzeugsensorbericht, der ein gemessenes Teile-Verschleißausmaß angibt, empfangen werden, um ein Modell von Verschleiß-verursachenden Faktoren zu bilden. Der Prozessor ist außerdem dazu konfiguriert, den voraussichtlichen Teileverschleiß an ein zweites Fahrzeug zu melden, und zwar als Reaktion auf eine Bestimmung, dass die Teile-bezogenen Fahrzeugsystemnutzungsdaten, die von dem zweiten Fahrzeug empfangen und auf Grundlage des Modells analysiert wurden, das gemessene Verschleißausmaß angeben.
-
Figurenliste
-
- 1 zeigt ein veranschaulichendes Fahrzeugrechensystem;
- 2 zeigt einen veranschaulichenden Prozess zum Verfolgen von Daten;
- 3 zeigt einen veranschaulichenden Prozess zur Vorhersageverwendung;
- 4 zeigt einen veranschaulichenden Prozess zur Datenanalyse;
- 5 zeigt einen veranschaulichenden Prozess zur Datenberichterstellung; und
- 6 zeigt einen veranschaulichenden Prozess zum Verfolgen von und Warnen vor Verschleiß.
-
DETAILLIERTE BESCHREIBUNG
-
Detaillierte Ausführungsformen sind in der vorliegenden Schrift nach Bedarf offenbart; dennoch versteht es sich, dass die offenbarten Ausführungsformen lediglich veranschaulichend sind und in verschiedenen und alternativen Formen ausgeführt sein können. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Dementsprechend sind hierin offenbarte konkrete strukturelle und funktionelle Einzelheiten nicht als einschränkend auszulegen, sondern lediglich als eine repräsentative Grundlage, um einen Fachmann eine vielfältige Ausführung des beanspruchten Gegenstands zu lehren.
-
1 veranschaulicht eine beispielhafte Blockstruktur für ein fahrzeugbasiertes Rechensystem 1 (vehicle based computing system - VCS) für ein Fahrzeug 31. Ein Beispiel für ein derartiges fahrzeugbasiertes Rechensystem 1 ist das SYNC-System, hergestellt durch THE FORD MOTOR COMPANY. Ein mit einem fahrzeugbasierten Rechensystem ausgestattetes Fahrzeug kann eine visuelle Front-End-Schnittstelle 4 enthalten, welche im Fahrzeug positioniert ist. Der Benutzer kann zudem in der Lage sein, mit der Schnittstelle zu interagieren, wenn diese zum Beispiel mit einem berührungsempfindlichen Bildschirm bereitgestellt ist. In einer anderen veranschaulichenden Ausführungsform erfolgt die Interaktion durch das Betätigen von Tasten, ein Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese.
-
Bei der in 1 dargestellten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 wenigstens einen Teil des Betriebs des fahrzeugbasierten Rechensystems. Der in dem Fahrzeug bereitgestellte Prozessor ermöglicht die fahrzeuginterne Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit nichtdauerhaften 5 als auch dauerhaften Speichern 7 verbunden. In dieser veranschaulichenden Ausführungsform handelt es sich bei dem nichtdauerhaften Speicher um einen Direktzugriffsspeicher (random access memory - RAM) und bei dem dauerhaften Speicher um einen Festplattenspeicher (hard disk drive - HDD) oder Flash-Speicher. Im Allgemeinen kann der dauerhafte (nichtflüchtige) Speicher alle Speicherformen beinhalten, die Daten behalten, wenn ein Computer oder eine andere Vorrichtung abgeschaltet wird. Diese beinhalten unter anderem HDDs, CDs, DVDs, Magnetbänder, Festkörperlaufwerke, tragbare USB-Laufwerke und jede andere geeignete Form von dauerhaftem Speicher.
-
Der Prozessor ist zudem mit einer Reihe unterschiedlicher Eingänge ausgestattet, die dem Benutzer ermöglichen, eine Schnittstelle mit dem Prozessor zu bilden. In dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, ein Hilfseingang 25 (zur Eingabe 33), ein USB-Eingang 23, ein GPS-Eingang 24, Bildschirm 4, der eine Touchscreen-Anzeige sein kann, und ein BLUETOOTH-Eingang 15 alle bereitgestellt. Eine Eingangswähleinheit 51 ist ebenfalls bereitgestellt, damit ein Benutzer zwischen verschiedenen Eingängen wechseln kann. Eingaben sowohl an das Mikrofon als auch den Hilfsanschluss werden durch einen Wandler 27 von analog zu digital umgewandelt, bevor sie zum Prozessor weitergeleitet werden. Wenngleich nicht gezeigt, können viele der Fahrzeugkomponenten und Hilfskomponenten, die mit dem VCS in Kommunikation stehen, ein Fahrzeugnetzwerk (wie etwa unter anderem einen CAN-Bus) verwenden, um Daten an das und von dem VCS (oder Komponenten davon) weiterzuleiten.
-
Ausgänge zum System können unter anderem eine visuelle Anzeige 4 und einen Lautsprecher 13 oder einen Stereosystemausgang beinhalten. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt dessen Signal durch einen Digital-Analog-Wandler 9 von dem Prozessor 3. Eine Ausgabe kann zudem an eine entfernte BLUETOOTH-Vorrichtung, wie etwa PND 54, oder eine USB-Vorrichtung, wie etwa die Fahrzeugnavigationsvorrichtung 60, entlang der bidirektionalen Datenströme, die bei 19 bzw. 21 gezeigt sind, erfolgen.
-
In einer veranschaulichenden Ausführungsform verwendet das System 1 den BLUETOOTH-Sendeempfänger 15, um mit der Mobilvorrichtung 53 eines Benutzers zu kommunizieren 17 (z. B. Mobiltelefon, Smartphone, PDA oder jede andere WLAN-fähige Vorrichtung). Die Mobilvorrichtung kann anschließend verwendet werden, um beispielsweise durch Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. Bei einigen Ausführungsformen kann es sich bei dem Mast 57 um einen WLAN-Zugangspunkt handeln.
-
Eine beispielhafte Kommunikation zwischen der Mobilvorrichtung und dem BLUETOOTH-Sendeempfänger wird durch das Signal 14 wiedergegeben.
-
Das Koppeln einer Mobilvorrichtung 53 mit dem BLUETOOTH-Sendeempfänger 15 kann durch eine Taste 52 oder eine ähnliche Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der fahrzeuginterne BLUETOOTH-Sendeempfänger mit einem BLUETOOTH-Sendeempfänger in einer Mobilvorrichtung gekoppelt werden wird.
-
Zwischen der CPU 3 und dem Netzwerk 61 können Daten beispielsweise unter Verwendung eines Datentarifs, Daten über Sprache oder DTMF-Töne kommuniziert werden, welche der Mobilvorrichtung 53 zugeordnet sind. Alternativ kann es wünschenswert sein, ein fahrzeuginternes Modem 63 einzubeziehen, das eine Antenne 18 aufweist, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu kommunizieren 16. Die Mobilvorrichtung 53 kann anschließend verwendet werden, um beispielsweise durch Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. In einigen Ausführungsformen kann das Modem 63 eine Kommunikation 20 mit dem Mast 57 herstellen, um mit dem Netzwerk 61 zu kommunizieren. Als nicht einschränkendes Beispiel kann es sich beim Modem 63 um ein USB-Mobilfunkmodem und bei der Kommunikation 20 um eine Mobilfunkkommunikation handeln.
-
In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem bereitgestellt, das eine API zum Kommunizieren mit einer Modemanwendungssoftware beinhaltet. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder eine Firmware auf dem BLUETOOTH-Sendeempfänger zugreifen, um die drahtlose Kommunikation mit einem entfernten BLUETOOTH-Sendeempfänger (wie etwa dem in einer Mobilvorrichtung) abzuschließen. Bei Bluetooth handelt es sich um eine Teilmenge der IEEE 802 PAN-(Personal Area Network)-Protokolle. IEEE-802-LAN-(Local Area Network)-Protokolle schließen WLAN ein und weisen eine beträchtliche Kreuzfunktionalität mit IEEE 802 PAN auf. Beide eignen sich für die drahtlose Kommunikation in einem Fahrzeug. Ein weiteres Kommunikationsmittel, welches in diesem Bereich verwendet werden kann, sind die optische Freiraumkommunikation (wie etwa IrDA) und nicht standardisierte Verbraucher-IR-Protokolle.
-
In einer anderen Ausführungsform beinhaltet die Mobilvorrichtung 53 ein Modem zur Sprachband- oder Breitbanddatenkommunikation. Bei der Daten-über-Sprache-Ausführungsform kann eine Technik umgesetzt werden, welche als Frequenzmultiplexverfahren bekannt ist, wenn der Besitzer der Mobilvorrichtung bei gleichzeitiger Datenübertragung über die Vorrichtung sprechen kann. Zu anderen Zeitpunkten, wenn der Besitzer der Vorrichtung nicht verwendet, kann für die Datenübertragung die ganze Bandbreite (300 Hz bis 3,4 kHz in einem Beispiel) verwendet werden. Obwohl das Frequenzmultiplexverfahren bei der analogen Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet geläufig sein kann und nach wie vor verwendet wird, wurde es weitgehend durch Hybriden von Codemultiplexverfahren (Code Domain Multiple Access - CDMA), Zeitmultiplexverfahren (Time Domain Multiple Access - TDMA), Raummultiplexverfahren (Space Domain Multiple Access SDMA) für eine digitale Mobilfunkkommunikation ersetzt. Ist die Mobilvorrichtung des Benutzers einem Datentarif zugeordnet, besteht die Möglichkeit, dass der Datentarif eine Breitbandübertragung ermöglicht und das System eine wesentlich größere Bandbreite nutzen könnte (wodurch sich die Datenübertragungsgeschwindigkeit erhöht). In noch einer anderen Ausführungsform wird die Mobilvorrichtung 53 durch eine Mobilfünkkommunikationsvorrichtung (nicht gezeigt) ersetzt, welche in dem Fahrzeug 31 verbaut ist. Bei noch einer weiteren Ausführungsform kann die ND 53 eine Vorrichtung eines drahtlosen lokalen Netzwerks (LAN) sein, die beispielsweise (unter anderem) über ein 802.11g-Netzwerk (d. h. WLAN) oder ein WiMax-Netzwerk kommunizieren kann.
-
Bei einer Ausführungsform können ankommende Daten durch die Mobilvorrichtung über Daten-über-Sprache oder einen Datentarif weitergeleitet werden, durch den fahrzeuginternen BLUETOOTH-Sendeempfänger und in den internen Prozessor 3 des Fahrzeugs. Im Falle bestimmter temporärer Daten können die Daten zum Beispiel auf dem HDD oder einem anderen Speichermedium 7 gespeichert werden, bis die Daten nicht mehr benötigt werden.
-
Zusätzliche Quellen, welche eine Verbindung mit dem Fahrzeug herstellen können, sind eine persönliche Navigationsvorrichtung 54, beispielsweise mit einem USB-Anschluss 56 und/oder einer Antenne 58, eine im Fahrzeug integrierte Navigationsvorrichtung 60 mit einem USB- 62 oder einem anderen Anschluss, eine bordeigene GPS-Vorrichtung 24 oder ein separates Navigationssystem (nicht dargestellt) mit Konnektivität zum Netzwerk 61. Bei USB handelt es sich um eines einer Klasse serieller Netzwerkprotokolle. Die seriellen Protokolle IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony) und Lynx™ (Texas Instruments)), EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Vorrichtung-zu-Vorrichtung-Standards. Die Mehrheit der Protokolle kann entweder für elektrische oder optische Kommunikation umgesetzt werden.
-
Ferner könnte die CPU mit einer Vielfalt von anderen Hilfsvorrichtungen 65 in Kommunikation stehen. Diese Vorrichtungen können über eine drahtlose 67 oder drahtgebundene 69 Verbindung verbunden sein. Die Hilfsvorrichtungen 65 können unter anderem persönliche Medienwiedergabegeräte, drahtlose Gesundheitsvorrichtungen, tragbare Computer und dergleichen beinhalten.
-
Zudem oder alternativ könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73 verbunden sein, beispielsweise unter Verwendung eines WLAN-(IEEE 803.11)-Sendeempfängers 71. Dies könnte der CPU ermöglichen, sich mit Fernnetzwerken in Reichweite des lokalen Routers 73 zu verbinden.
-
Zusätzlich zur Ausführung beispielhafter Prozesse durch ein sich in einem Fahrzeug befindliches Fahrzeugrechensystem können die beispielhaften Prozesse bei bestimmten Ausführungsformen durch ein Rechensystem ausgeführt werden, welches mit einem Fahrzeugrechensystem in Kommunikation steht. Ein derartiges System kann unter anderem eine drahtlose Vorrichtung (z. B. unter anderem ein Mobiltelefon) oder ein über die drahtlose Vorrichtung verbundenes Remote-Rechensystem (z. B. unter anderem einen Server) beinhalten. Zusammen können derartige Systeme als dem Fahrzeug zugeordnete Rechensysteme (vehicle associated computing systems - VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS bestimmte Teile eines Prozesses ausführen, wobei dies von der konkreten Umsetzung des Systems abhängt. Wenn ein Prozess beispielsweise und nicht einschränkend einen Schritt des Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung aufweist, ist es wahrscheinlich, dass die drahtlose Vorrichtung den Teil des Prozesses nicht durchführt, da die drahtlose Vorrichtung Informationen nicht sich selbst bzw. von sich selbst „senden und empfangen“ würde. Ein Durchschnittsfachmann wird verstehen, wann es unangemessen ist, ein bestimmtes Rechensystem auf eine bestimmte Lösung anzuwenden.
-
Bei jeder hier erörterten veranschaulichenden Ausführungsform wird ein beispielhaftes nicht einschränkendes Beispiel eines Prozesses gezeigt, der durch ein Rechensystem durchgeführt werden kann. In Bezug auf den jeweiligen Prozess kann das Rechensystem, das den Prozess ausführt, für den beschränkten Zweck der Ausführung des Prozesses als ein Spezialprozessor zum Durchführen des Prozesses konfiguriert werden. Alle Prozesse müssen nicht in ihrer Gesamtheit durchgeführt werden und sind als Beispiele von Prozesstypen zu verstehen, die durchgeführt werden können, um Elemente der Erfindung zu verwirklichen. Zusätzliche Schritte können nach Bedarf zu den beispielhaften Prozessen hinzugefügt oder daraus entfernt werden.
-
In Bezug auf die veranschaulichenden Ausführungsformen, die in den veranschaulichende Prozessabläufe zeigenden Figuren beschrieben sind, ist anzumerken, dass ein Universalprozessor temporär als ein Spezialprozessor zum Zwecke des Ausführens einiger oder aller der in diesen Figuren gezeigten beispielhaften Verfahren aktiviert werden kann. Wenn Code ausgeführt wird, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor temporär erneut als ein Spezialprozessor eingesetzt werden, und zwar solange, bis das Verfahren abgeschlossen ist. In einem anderen Beispiel kann, bis zu einem angemessenen Grad, Firmware, die in Übereinstimmung mit einem vorkonfigurierten Prozessor agiert, veranlassen, dass der Prozessor als ein Spezialprozessor agiert, der zum Zwecke des Durchführens des Verfahrens oder einer angemessenen Variation davon bereitgestellt ist.
-
Fahrzeuge sind mit einer breiten Vielfalt an Sensoren ausgestattet. Die Arten und Vielfalten von Sensoren können mit Fahrzeugalter, Modell, aktuell verfügbarer Technologie und Spezifikationen des Originalgeräteherstellers (original equipment manufacturer - OEM) variieren. Zum Beispiel kann ein High-End-Modell eines Fahrzeugs mit einem Sensor ausgestattet sein, der Bremsenverschleiß detektieren kann (dies ist lediglich ein veranschaulichendes Beispiel). Eine günstigere Version des gleichen Fahrzeugs weist womöglich keinen verfügbaren Sensor auf. Auch weist ein älteres Modell womöglich einen solchen nicht auf, da der Sensor beispielsweise eine neu entwickelte Technologie darstellen kann.
-
Bei nachgerüsteten Sensoren an anderen Fahrzeugen, die die Sensoren nicht aufweisen, kann es sich um ein teures Unterfangen handeln. Dennoch können die durch diese Sensoren erhaltene Daten nützlich sein, sodass eine Herausforderung darin besteht, diese Informationen an Kunden zu liefern, die ein Fahrzeug besitzen, welches keine bereits installierten Sensoren aufweisen.
-
Da das Konzept von Crowdsourcing-Daten eine Datensammlung in großem Maßstab ermöglicht, können Verschleiß-bezogene Daten von Fahrzeugen gesammelt werden, die den Sensor beinhalten. Diese Daten können umfassend, spezifisch sein und/oder die angeforderten Daten können im Laufe der Zeit optimiert werden. Zum Beispiel kann ein erster Durchlauf das Sammeln von Daten beinhalten, die Geschwindigkeit und Bremsenergie (Verlangsamung) betreffen, wenn eine Bremse verwendet wird. Wenn der Fahrzeugsensor ein bestimmtes Verschleißausmaß registriert, können die zusammengefassten Daten für dieses Fahrzeug eine Annäherung des Gesamtausmaßes der aufgewendeten Energie bieten, um die Bremsen bis zum erfassten Ausmaß zu verschleißen.
-
Natürlich gibt es eine Reihe anderer den Verschleiß betreffender Bedingungen, jedoch können diese im Laufe der Zeit modelliert werden, sobald eine Ausgangserwartung vorliegt. Somit kann sich ein zweiter oder dritter Satz von Datensammlung auf das Verfolgen zusätzlicher Bedingungen beziehen, die einen Verschleiß verursachen können, und im Laufe der Zeit kann eine sehr detaillierte Analyse bezüglich der Ursachen des Verschleißes durchgeführt werden. Positionsdaten, Wetterdaten, Windgeschwindigkeit, Temperatur und eine Vielzahl von anderen Bedingungen können verfolgt werden, sodass, wenn eine Vorhersage getroffen wird, diese für die Fahrzeugbedingungen, für die die Vorhersage getroffen wurde, immer genauer werden können.
-
Auch mit einem grundlegenden Satz an Daten (wie etwa gesamte aufgewendete Energie beim Verschleißen eines Bremsbelags auf ein bestimmtes Ausmaß) kann ein OEM Fahrzeugen, die keine entsprechende Erfassungstechnologie aufweisen, nützliche Vorhersagen bereitstellen.
-
In dem vorhergehenden Beispiel, wenn zum Beispiel ein neuer Satz von Bremsbelägen installiert wird oder wenn ein aktueller Bremszustand (X %) bekannt ist, kann das Fahrzeug, das die Sensoren nicht aufweist, damit beginnen, die beim Bremsen verwendete Energie zu sammeln und zu melden. Diese Daten können zusammengefasst und mit Ausgangserwartungen verglichen werden, sodass ein OEM-Analyseprozess vorhersagen kann, wann ein Fahrzeug ein bestimmtes Ausmaß an Bremsenverschleiß erfahren kann. Das heißt, sobald das Fahrzeug, welches keine Berichterstellung erfasst, das entsprechende Ausmaß an verwendeter Bremskraft meldet (wie im Laufe der Zeit verfolgt), kann das System vorhersagen, dass das erwartete Ausmaß an Verschleiß vorliegt. Dies erreicht im Wesentlichen einen virtuellen Erfassungszustand, indem die Daten in Bezug auf die Ursache für das Erfasste gesammelt und die Daten verwendet werden, um das gleiche Ergebnis vorherzusagen, auch in der Abwesenheit des tatsächlichen Sensors.
-
Wenn der Verschleiß nicht linear ist, kann das Wissen über einen aktuellen Bremszustand (während der Wartung aus anderen Gründen beobachtbar) nützlich sein, wenn die Modellierung von einem Zustand „weniger als perfekt“ nach unten zu einem Zustand „benötigte Reparatur“ erfolgen kann. Dies kann eine zusätzliche Modellierung erfordern, obwohl die laufende Datensammlung in Handelsbetrieben und Servicecentern schnell dabei helfen kann, dieses Modell zu optimieren. Wenn beispielsweise ein Kundenfahrzeug (mit oder ohne Sensoren) ein bestimmtes Ausmaß an Verschleiß zwischen Wartungsprüfungen erfährt, können dieses Ausmaß an Verschleiß und die damit verbundenen Daten gemeldet (vom Händler, vom Fahrzeug usw.) und für eine Analyse in der Mitte des Zyklus verwendet werden.
-
Die gleichen Konzepte, die in Bezug auf das Bremsen erörtert wurden, können auf eine Vielzahl von Fahrzeugsystemen angewendet werden. Außerdem kann das Modellieren verwendet werden, um zu bestimmen, auf welche anderen Fahrzeugmodelle das bestimmte Systemmodell angewendet werden kann. In Bezug auf den Bremsenverschleiß, können Fahrzeugmasse, Reifendurchmesser und eine Vielzahl anderer Spezifikationen ins Spiel kommen, sodass es auch der Fall sein kann, dass die Daten nur für bestimmte ähnlich ausgestattete Fahrzeuge präzise nützlich sein können und dass die Daten für andere marginal ähnliche Fahrzeuge (zum Beispiel andere SUVs, wenn der Ausgangswerte von einem SUV genommen wurde) begrenzt nützlich sind. In Bezug auf ein Ausfall des Fluidsystems, einen Verschleiß der Zündkerze oder einen Verschleiß anderer bestimmter Systeme kann das Modell des Fahrzeugs jedoch eine geringere Rolle spielen und somit kann die Modellierung von Verschleiß bestimmter Systeme auf Basis erfasster Daten an einer breiten Vielfalt von Fahrzeugmodell nützlich sein. Das Erzeugen von Vorhersagen und das Messen tatsächlicher Ergebnisse (d. h., als die Wartung tatsächlich durchgeführt wurde, war die Vorhersage korrekt) hilft dabei, die Modelle zu optimieren und ein Verständnis darüber zu erzeugen, welche Systemmodelle auf welche Fahrzeuge Anwendbarkeit finden.
-
Schließlich könnte ein OEM mit ausreichender Optimierung bewusst eine diskrete Anzahl an besonders geeigneten Sensoren in einer gelieferten Flotte (z. B. in allen Autos in einer Örtlichkeit) positionieren und die von diesen Fahrzeugen gesammelten Daten verwenden, um virtuelle Erfassungsäquivalenzen anderen Fahrzeugen in der Flotte, die womöglich die Sensoren nicht aufweisen, bereitzustellen. Sobald das Fahrzeug über einen langen Zeitraum hinweg überprüft wurde, sodass die Ursächlichkeit bekannt ist, könnte der OEM die Sensoren auch vollständig weglassen und sich stattdessen auf ein sorgfältig gefertigtes Modell verlassen, welches wiederholt nachweislich ein hohes Genauigkeitsniveau aufwies. Oder der OEM könnte die Sensoren als eine Upgrade-Option anbieten, jedoch wäre der einzige praktische Unterschied zu den meisten Kunden, dass das System ein Ausmaß von Verschleiß vorhersagt und nicht beobachtet, und wenn die Vorhersage genau genug ist, würden die meisten Kunden den Unterschied wahrscheinlich nicht merken.
-
2 zeigt einen veranschaulichenden Prozess zum Verfolgen von Daten. In diesem Beispiel identifiziert der Prozess einen bestimmten Satz von Fahrzeugen mit Sensoren und sendet spezifische Datenanforderungen an diese Fahrzeuge. Dies ermöglicht den OEMs, sich auf das Sammeln von zumindest Informationen, die vermutlich zum Bestimmen eines breiteren Modells nützlich sind, zu konzentrieren. Wie vorstehend angemerkt, könnte dies zuerst mit einem Sammeln von beispielsweise Bremsenergie (erneut: Bremsen wird lediglich verwendet, um das Konzept zu veranschaulichen) beginnen und zu einem späteren Zeitpunkt könnte dies beispielsweise Daten hinsichtlich des spezifischen Gewichts oder der Umgebung anfordern.
-
Es ist ebenfalls möglich, alle wahrnehmbaren Daten zu sammeln, da jedoch die Daten an einen OEM übertragen werden, kann das Sammeln einer diskreten Menge an Zieldaten effizienter und weniger Datenübertragungs-intensiv sein. Die Zweckmäßigkeit eines Ansatzes im Gegensatz zu dem anderen Ansatz kann zum Beispiel von der Größe der Daten und der Einfachheit der Übertragung abhängen. Es ist ebenfalls der Fall, dass einige Variablen anfangs womöglich nicht bekannt sind, sodass das in 2 gezeigte Konzept auch das Aktualisieren eines Konzepts „aller Daten“ ermöglicht, in dem zusätzliche Faktoren, die vorher nie berücksichtigt wurden, in einer dynamischen Weise zum Datensammlungsansatz hinzugefügt werden können.
-
Dieser Ansatz ermöglicht außerdem das „theoretische Prüfen“ in Bezug auf Datensätze. Wenn eine Variable voraussichtlich einen Einfluss hat, kann der OEM leicht eine dynamische Sammlungsaktualisierung ausgeben, um entsprechend ausgestattete Fahrzeuge anzuweisen, Daten in Bezug auf die Variable zu sammeln. Sobald ausreichend Daten gesammelt wurden, kann der OEM die Daten analysieren und überprüfen, ob eine aussagekräftige Schlussfolgerung erfolgen kann. Sollte dies nicht der Fall sein, ist es leicht genug, die Objektfahrzeuge einfach anzuweisen, Daten in Bezug auf diese bestimmte Variable zu sammeln.
-
In diesem Beispiel identifiziert 201 der Prozess ein Fahrzeug, welches einen Sensor aufweist, der in der Lage ist, ein bestimmtes Ausmaß an Systemverschleiß oder -verwendung zu detektieren. Beispiele beinhalten unter anderem geringe Fluidzustände, Bremsenverschleiß, Dämpferverschleiß, Reifenverschleiß usw. Während jeder beliebige Sensor berücksichtigt werden kann, liegt der Fokus wahrscheinlich auf Fahrzeugen, die Sensoren aufweisen, die nicht umfassend an nahezu jedes Fahrzeug bereitgestellt werden (wie etwa Sensor für niedrigen Ölstand). Andererseits, wenn bestimmte Fahrzeug einen detaillierteren Ölsensor aufweisen, könnte diese Art von Daten für Fahrzeuge mit einem grundlegenden Füllstandssensor nützlich sein. Wenn beispielsweise ein Fahrzeugmodell ein Ausmaß der Ölverschlechterung und -verschmutzung detektieren kann und die Variablen, die diesen Ölzustand verursachen, verfolgbar sind, könnten diese Informationen für andere Fahrzeug, die ähnliche Bedingungen erfahren können (wie durch die Variablen dargestellt), die jedoch keine optimierte Erfassungsfähigkeit aufweisen, nützlich sein.
-
Das System identifiziert dann eine oder mehrere Verfolgungs-bezogene Variablen, die nützlich sein könnten, um Systemverschleiß zu bestimmen, und fordert an 203, dass das identifizierte Fahrzeug damit beginnt, diese Variablen zu verfolgen. Wenn keine Einzelheiten bekannt sind, kann diese Anforderung eine Anforderung für eine umfassende Datenverfolgung sein und kann später auf Grundlage extrahierter Zustands-beeinflussender Variablen (aus Modellen extrahiert) optimiert werden. Das Fahrzeug sammelt dann Daten für einen bestimmten Zeitraum (z. B. unter anderem, bis der Fahrzeugsensor einen Alarmzustand angibt) und meldet die Daten anschließend zurück.
-
Das Fernsystem empfängt 205 die Daten von dem identifizierten Fahrzeug und allen anderen ähnlich identifizierten Fahrzeugen. Das System empfängt 207 außerdem Teile-/Systemdaten, die Teileinformationen oder Systeminformationen angeben, die bei der Analyse der Ergebnisse nützlich sein können. In Bezug auf Bremsen können Bremsbeläge zum Beispiel unterschiedliche Zusammensetzungen aufweisen und somit sind Daten für einen bestimmten Belag womöglich für einen Belag mit einer anderen Zusammensetzung nicht besonders nützlich. Das gleiche könnte für bestimmte Flüssigkeiten gelten, die in Qualitäten und Arten geliefert werden, und somit ist eine Verschlechterung einer Qualität womöglich nicht nützlich, um die Verschlechterung einer anderen zu bestimmen.
-
Der Prozess fasst die empfangenen Daten mit einem größeren Satz von Daten zusammen 209 und führt dann eine Analyse durch, um zu ermitteln, ob bestimmte Ursachen für den Verschleiß identifiziert oder optimiert werden können. Dies ermöglicht dem System, Variablen, die voraussichtlich zu einem Verschleiß führen, zu profilieren, und das System kann dann ein aktualisiertes Vorhersageprofil an Fahrzeuge verteilen 211, die den bestimmten Sensor nicht aufweisen, die jedoch das Teil oder System beinhalten können, für das die Vorhersage gilt.
-
Wenn die Analyse für ein einzelnes Fahrzeug (zum Bestimmen eines wahrscheinlichen Verschleißzustands) in der Cloud erfolgte (anstatt im Fahrzeug zum Beispiel) kann der Prozess das aktualisierte Modell verwenden, um letzte Daten erneut zu modellieren und Vorhersagen in Bezug auf eingehende Daten zu verbessern. Das heißt, wenn eine Modellverbesserung durch eine zusätzliche Analyse ermöglicht wurde, können kürzlich erfolgte Vorhersagen unter dem verbesserten Modell erneut modelliert werden und neue Vorhersagen für neu meldende Fahrzeuge können modelliert werden.
-
3 zeigt einen veranschaulichenden Prozess zur Vorhersageverwendung. In diesem Beispiel werden die von der Analyse großer Datensätze produzierten Modelle verwendet, um Systemverschleißzustände für Fahrzeuge, die Nutzungsdaten melden, vorherzusagen. In diesem Beispiel produziert das System Vorhersagen oder Richtlinien für nicht erfassende Fahrzeuge, die das System verwenden oder an Fahrzeuge liefern kann, sodass ein Fahrer eines nicht erfassenden Fahrzeugs vor einem wahrscheinlichen Verschleißzustand gewarnt werden kann.
-
In diesem Beispiel hat der Prozess Zugriff auf Fahrzeugdaten für eine große Anzahl an Flottenfahrzeugen auf der Straße (zum Beispiel jedes Mal, wenn ein Kunde ein Fahrzeug kauft, kann es registriert werden). Für jedes Fahrzeug ohne Erfassungsfähigkeit 301 kann der Prozess Konfigurationsdaten in Bezug auf Teile/Komponenten, Fluide usw. in Bezug auf das Fahrzeug erhalten 303. Das System kann diese Daten verwenden, um zu bestimmen, welche Modell auf das nicht erfassende Fahrzeug anwendbar sind (z. B. bestimmte Bremsbelagarten, bestimmte Beleuchtungsmerkmale usw.).
-
Ein vorhersagender Satz von Variablen kann für das bestimmte Fahrzeug 305 erhalten werden. Zum Beispiel können Nutzungsparameter für das bestimmte Fahrzeug bestimmt 305 und zusammengefasst werden. Diese Parameter können durch eine Cloud-Analyse oder eine fahrzeuginterne Analyse verwendet werden, um einen Verschleißzustand für das bestimmte Fahrzeug zu bestimmen. Wenn das Fahrzeug (oder zum Beispiel eine mobile Vorrichtung) selbst analysierend ist, kann der Prozess die Variablenwerte, die einen Verschleiß angeben, an das Fahrzeug liefern 307. Wenn die Cloud die Analyse durchführt, kann der Prozess zum Beispiel die Modellwerte in Bezug auf ein Fahrzeugprofil speichern.
-
Wenn das Fahrzeug die Analyse durchführt, kann das Fahrzeug einen Satz von zusammengefassten Verschleißwerten vom Modell (Cloud) empfangen. Sobald die Fahrzeugnutzungsdaten die Parameterwerte erfüllen, kann das Fahrzeug einen Alarm über einen wahrscheinlichen Verschleißzustand ausgeben. Wenn das Modell im Laufe der Zeit aktualisiert wird, kann das entfernte Cloud-System die aktualisierten Werte an das Fahrzeug liefern. In einem anderen Modell kann die Cloud die Analyse durchführen, wenn das Fahrzeug Daten liefert, wobei die Analyse auf einem neuesten aktualisierten vorhersagenden Modell beruht. Die fahrzeugbasierte Analyse hat den Vorteil, dass zum Zeitpunkt des Alarms keine Verbindung erforderlich ist, vorausgesetzt, dass die Variablenwerte zu einem früheren Zeitpunkt geliefert werden. Das Cloud-Modell hat den Vorteil, dass es üblicherweise schneller ist und stets Zugriff auf aktualisierte Modelldaten hat. Welcher Punkt für die Analyse verwendet wird (Fahrzeug, Cloud, Telefon) ist eine Frage der Wahl, wobei die Vorteile gegen die Nachteile abgewogen werden.
-
4 zeigt einen veranschaulichenden Prozess zur Datenanalyse. In diesem Beispiel erhält (empfangt) 401 der Prozess Fahrzeugdaten. In diesem Beispiel melden die Fahrzeuge Daten, wenn ein bestimmter Sensor einen Verschleißzustand angibt, jedoch könnte das Fahrzeug auch im Laufe der Zeit Daten melden, um zu zeigen, welches Ausmaß der Nutzung den Verschleißzustand noch nicht auslöst.
-
In diesem Beispiel empfängt der Prozess die Werte über Nutzungsdaten und den Sensorauslöser und vergleicht 403 die empfangenen Werte mit bekannten Vorhersagen darüber, wann ein Sensorauslöser hätte erfolgen müssen. Dies zeigt, ob das vorhersagende Modell für die aktuellen Fahrzeugdaten genau ist oder nicht. Wenn keine erhebliche Abweichung 405 vorliegt (wenn die berücksichtigten Daten innerhalb einer vordefinierten für die Daten erwartete Toleranz liegen), fasst der Prozess die Daten im Pool zusammen 407, wodurch das aktuelle Modell verstärkt wird.
-
Wenn eine unerwartete Abweichung vorliegt, kann der Prozess den einen oder die mehreren Datenwerte oder Teiledaten, die sich nicht im Verriegelungsschritt mit dem aktuellen vorhergesagten Modell befinden, isolieren 409. Das heißt, der Prozess könnte identifizieren, dass die Datenwerte für Verschleiß hoch waren, dies könnte jedoch auf eine andere Zusammensetzung im Bremsbelag zurückzuführen sein. Wenn die Bremsbelagwerte konsistent waren, kann eine andere Variable untypisch sein, und durch den Vergleich mit verschiedenen Modellen kann der Prozess die wahrscheinlichen Unterschiede isolieren 409.
-
Sobald der Prozess den Unterschied identifiziert 411 hat, kann der Prozess eine neue Kategorie erstellen 413. Dies könnte eine neue Kategorie eines Teils oder Systems (welches eine andere Zusammensetzung darstellt) oder eine neue Kategorie von zu verfolgenden Daten sein. In einem Beispiel kann der Prozess solche Ausreißer protokollieren, bis eine zusammengefasste Anzahl an entsprechenden Ausreißern angibt, dass wahrscheinlich eine neue Kategorie erstellt werden sollte. Der Prozess sortiert die bereits gesammelten Daten erneut 415, falls Daten, die in Bezug auf die alte Kategorisierung / das alte vorhersagende Modell zusammengefasst wurden, stattdessen in Bezug auf das neue Modell berücksichtigt werden sollten.
-
Zum Beispiel kann der Prozess Daten zur Bremsennutzung empfangen, wobei alle der Daten als eine Einheit zusammengefasst werden, jedoch kann im Laufe der Zeit gezeigt werden, dass ein bestimmter Bremsbelag langsamer verschleißt als ein anderer Bremsbelag. Sobald gemeldet wurde, dass Fahrzeug ausreichend Daten gesammelt hat, um diese Schlussfolgerung zu ziehen, kann der Prozess bereits empfangene Daten, die jeder Bremsbelagart entsprechen (vorausgesetzt, dass sie gespeichert ist) isolieren und die Daten gemäß der Bremsbelagart verteilen. Dies sollte zu zwei neuen Vorhersagen führen, wobei jede auf die verschiedenen Bremsbelagarten zugeschnitten ist und eine bessere Modellierung als ein zusammengefasstes Modell aller Daten, die alle Bremsbeläge gleich behandeln, bereitstellt. Wenn nur 2 % der Fahrzeuge auf der Straße den „besseren“ Bremsbelag aufweisen, könnte es eine Weile dauern, um diese Unterscheidung zu treffen, und in der Zwischenzeit kann es besser sein, die allgemeinen zusammengefassten Schätzungen für alle Fahrzeuge zu verwenden, anstatt zu warten, bis die Unterscheidung in den Modellen tatsächlich erfolgt ist.
-
5 zeigt einen veranschaulichenden Prozess zur Datenberichterstellung. In diesem Beispiel empfängt 501 der Prozess an Bord eines Fahrzeugs eine Verfolgungsanforderung vom entfernten System, welche einen bestimmten zu verfolgenden Nutzungsparameter (oder einen anderen Parameter, z. B. umweltbezogen) angibt. In diesem Beispiel beinhaltet die Verfolgungsanforderung außerdem eine Identifizierung eines entsprechenden Sensors, der als Grundlage für die Berichterstellung der Daten verwendet wird. Das Fahrzeug verifiziert 503, dass der entsprechende Sensor existiert und dass das Fahrzeug in der Lage ist, den angeforderten Parameter zu verfolgen.
-
Jedes Mal, wenn das System, das von dem Sensor erfasst wird, verwendet 505 wird, protokolliert 507 der Prozess die Verwendung und die damit verbundenen Daten wie von der Anforderung identifiziert. Es kann ein Ausgangssatz von Daten vorliegen, den der Prozess immer protokolliert, und eine individuelle Anforderung kann auf Grundlage neu identifizierter Variablen von Interesse zu diesen Daten hinzugefügt werden. Außerdem überprüft der Prozess 509 den Verschleißsensor, um zu bestimmen, ob das System einen Warnpunkt erreicht hat. Während er als ein Verschleißsensor beschrieben wird, kann es sich bei dem Sensor um jeden beliebigen Sensor handeln, der eine Verschlechterung eines Fahrzeugsystems detektieren kann. Wie bereits angemerkt, handelt es sich dabei oftmals, obwohl nicht notwendigerweise, um einen Sensor, der nur einem Teilsatz von Fahrzeugen auf der Straße bereitgestellt wird.
-
Wenn der Fahrzeugsensor angibt, dass ein Verschleißzustand vorliegt, verpackt 511 der Prozess die Nutzungsdaten, die im Laufe der Zeit gesammelt wurden, und sendet 513 die Nutzungsdaten an das Fernsystem. Dies kann auch Senden von Teile-, System- oder Fluiddaten (Modell- oder mfg-Kennung, Parameter usw.) und alle beliebigen anderen Daten beinhalten, die bei der Modellierung von Verschleiß bei Fahrzeugen mit ähnlichen Teilen/Komponenten, Systemen, Fluidnutzung usw., aber ohne Verschleißsensor, als nützlich gelten.
-
6 zeigt einen veranschaulichenden Prozess zum Verfolgen von und Warnen vor Verschleiß. In diesem Beispiel wird der Prozess an Bord eines nicht erfassenden Fahrzeugs oder einer Vorrichtung in Verbindung mit einem nicht erfassenden Fahrzeug (z. B. einer mobilen Vorrichtung eines Fahrgasts) durchgeführt. Der Prozess empfängt 601 hier außerdem Verfolgungsanweisungen, obwohl das Verfolgen in diesem Fall verwendet wird, um mögliche Probleme zu identifizieren, da ein Sensor nicht vorhanden ist.
-
Jedes Mal, wenn das zu verfolgende System verwendet 603 wird, protokolliert der Prozess 605 die Verwendung des Systems. Der Prozess protokolliert außerdem die Variablenwerte in Bezug auf identifizierte Verschleiß-verursachende Aspekte der Verwendung und fasst diese Werte in den meisten Fällen wahrscheinlich zusammen. Der Prozess vergleicht 607 dann die zusammengefassten Werten mit Schwellenwerten, die in den Verfolgungsanweisungen identifiziert wurden, wobei die Schwellenwerte Gesamtsummen für die Verwendung angeben, die wahrscheinlich zu einem ausreichenden Verschleiß führen, um einen Alarm auszulösen. Wenn ein Schwellenwert erfüllt 609 ist, kann der Prozess einen Alarm an den Fahrer (und zu Verfolgungszwecken an ein Fernsystem) ausgeben 611.
-
Zu einem beliebigen Zeitpunkt, entweder aufgrund von übermäßigem Verschleiß und Ausfall oder in einer präventiven Weise, wird das betreffende System repariert 613. Zu diesem Zeitpunkt kann das Fahrzeug oder ein Händler-/Servicesystem den tatsächlichen Verschleißzustand melden 615 und beliebige Nutzungsdaten zusammenfassen. Diese Daten können von dem Fernsystem analysiert werden, um zu bestimmen, wie effektiv das vorhersagende Modell war. Verbesserungen hinsichtlich des vorhersagenden Modells können somit auch in dieser Weise erfolgen.
-
Durch die Verwendung der veranschaulichenden Ausführungsformen können vorhersagende Verschleißmodelle entwickelt und verwendet werden, um Fahrzeugen, die keine tatsächlichen Verschleißsensoren für bestimmte Komponenten, Teile, Systeme und Fluide aufweisen, virtuelle Sensoräquivalenzen bereitzustellen. Mit ausreichend Daten und Modellierung kann sich das vorhersagende Modell Warnbedingungen nah annähern, die denen ähneln, unter denen ein tatsächlicher Sensor eine Warnung generieren würde.
-
Während vorstehend beispielhafte Ausführungsformen beschrieben sind, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Die in der Beschreibung verwendeten Ausdrücke sind vielmehr beschreibende Ausdrücke als einschränkende Ausdrücke, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Geist und Umfang der Erfindung abzuweichen. Zusätzlich können die Merkmale verschiedener implementierender Ausführungsformen auf logische Weise kombiniert werden, um situationsgerechte Variationen von hier beschriebenen Ausführungsformen zu bilden.
