DE102018100109A1

DE102018100109A1 - Wartungs-management für carsharing-systeme

Info

Publication number: DE102018100109A1
Application number: DE102018100109.6A
Authority: DE
Inventors: Christopher L. Oesterling; Jessica Renick; Paul Pebbles; Zafar Razzacki
Original assignee: GM Global Technology Operations LLC; General Motors LLC
Current assignee: GM Global Technology Operations LLC; General Motors LLC
Priority date: 2017-01-09
Filing date: 2018-01-03
Publication date: 2018-07-12
Also published as: US20180197349A1; US10078924B2; CN108288211A; CN108288211B

Abstract

Hierin ist ein System zur Verwaltung der Routinewartung eines Fahrzeugs vorgestellt, das in ein Carsharing-System einbezogen ist. Das Wartungs-Managementsystem enthält ein Fahrzeug mit einem Fahrzeugsensor, einer Fahrzeug-Kommunikationsplattform (VCP) und eine Ferneinheit. Die VCP befindet sich innerhalb des Fahrzeugs und kommuniziert mit dem Fahrzeugsensor. Die VCP ist dazu konfiguriert, eine Datenübertragung zu generieren und zu übertragen. Die Ferneinheit hat mindestens eine Datenbank und ist dazu konfiguriert, die VCP-Datenübertragung zu empfangen. Außerdem arbeitet die VCP mit dem Fahrzeugsensor zusammen, um mindestens eine Routinewartungs-Meldung zu erzeugen und anschließend die Routinewartungs-Meldung zur Ferneinheit zu übertragen. Nach Prüfung und Analyse der Routinewartungs-Meldung wird die Ferneinheit die zukünftige Wartung des Fahrzeugs vorhersagen und den Registrierungsstatus des Fahrzeugs in der Datenbank anpassen, um eine Wartung zu ermöglichen.

Description

EINLEITUNG
Das Mieten eines Fahrzeugs erfordert häufig eine Reservierung mit einer Vermietungsfirma, und dass der Benutzer zum Ort der Vermietungsfirma anreist, um Zugang zum Fahrzeug zu erhalten. Bevor Zugang erteilt wird, muss die Vermietfirma jedoch den Fahrzeugzustand prüfen und ermitteln, ob eine Wartung erforderlich ist. Dies kann eine mühsame Aufgabe für Firmenmitarbeiter sein. Die Vermietung von Fahrzeugen über Carsharing-Systeme stellt eine verträgliche Alternative zu den typischen Fahrzeugvermietungssystemen dar und benötigt weniger Mitarbeiterarbeit. Jedoch erschwert die beteiligte Autonomie dieser Carsharing-Systeme für die Vermietfirma die Prüfung des Fahrzeugzustands und das Ermitteln, wann Wartung erforderlich ist. Es ist daher wünschenswert für Carsharing-Systeme, dass die Fahrzeuge selbst melden, wenn eine Wartung benötigt wird.
ZUSAMMENFASSUNG
Hierin ist ein System zur Verwaltung der Routine-Wartung eines Fahrzeugs vorgestellt, das in ein Carsharing-System einbezogen ist. Das Wartungs-Managementsystem enthält ein Fahrzeug mit einem Fahrzeugsensor, einer Fahrzeug-Kommunikationsplattform (VCP) und eine Ferneinheit. Die VCP befindet sich innerhalb des Fahrzeugs und kommuniziert mit dem Fahrzeugsensor. Die VCP ist dazu konfiguriert, eine Datenübertragung zu generieren und zu übertragen. Die Ferneinheit hat mindestens eine Datenbank und ist dazu konfiguriert, die VCP-Datenübertragung zu empfangen. Außerdem arbeitet die VCP mit dem Fahrzeugsensor zusammen, um mindestens eine Routinewartungs-Meldung zu erzeugen und anschließend die Routinewartungs-Meldung zur Ferneinheit zu übertragen. Nach Prüfung und Analyse der Routinewartungs-Meldung wird die Ferneinheit die zukünftige Wartung des Fahrzeugs vorhersagen und den Registrierungsstatus des Fahrzeugs in der Datenbank anpassen, um eine Wartung zu ermöglichen.
In bestimmten Fällen enthält das Wartungs-Managementsystem eine Wartungseinrichtung für die Durchführung von Routine-Wartungsarbeiten an Fahrzeugen. Außerdem kann die Ferneinheit eine Wartungsbenachrichtigung an die Wartungseinrichtung generieren und übertragen, um die Wartungsarbeiten in der Wartungseinrichtung einzuplanen. In anderen Fällen enthält das Wartungs-Managementsystem einen GNSS-Chipsatz/Komponente und mehrere Wartungseinrichtungen, von denen jede dazu konfiguriert ist, die Routine-Wartungsarbeiten an Fahrzeugen auszuführen. Außerdem arbeitet die VCP in diesem Fall mit dem GNSS-Chipsatz/Komponente zusammen, um mindestens eine Nachricht zum Fahrzeugstandort zu generieren, die VCP überträgt anschließend die Nachricht der Fahrzeugposition zur Ferneinheit. Nach Prüfung und Analyse der Nachricht zum Fahrzeugstandort und der Routinewartungs-Meldung wählt die Ferneinheit eine von den mehreren Wartungseinrichtungen aus, erzeugt eine Wartungsbenachrichtigung und überträgt die Wartungsbenachrichtigung an die ausgewählte Wartungseinrichtung zur Einplanung der Wartungsarbeiten bei der ausgewählten Wartungseinrichtung.
In weiteren Fällen enthält das Wartungs-Managementsystem eine mobile Computervorrichtung mit einer installierten CarShare-App. In solchen Fällen erzeugt und überträgt die Ferneinheit eine Außer-Betrieb-Meldung an die CarShare-App. Die Ferneinheit kann anderweitig eine Außer-Betrieb-Meldung an die VCP erzeugen und übertragen. Die Außer-Betrieb-Meldung kann einen Anreiz enthalten. Die Routinewartungs-Meldung kann Informationen zur verbleibenden Ölnutzungsdauer/Ölmenge, Fehlerinformation des Ölfilters, Komponenten-Fehlerinformation, Selbstdiagnose-Informationen, Kilometerstand oder eine Kombination davon enthalten. Die Wartungsbenachrichtigung kann Informationen zur Fahrzeug-Öllebensdauer, dem Zustand des Ölfilters im Fahrzeug, das Auslösen von Störungsanzeigeleuchten, Kilometerstand, Fahrzeugbauteilversagen, Selbstdiagnose-Meldungen oder eine Kombination davon enthalten.
Hierin ist ebenfalls ein Verfahren zur Verwaltung der Routinewartung eines Fahrzeugs vorgestellt, das in ein Carsharing-System einbezogen ist. Das Wartungs-Managementverfahren enthält die Schritte: (a) Bereitstellen eines Fahrzeug mit mindestens einem Fahrzeugsensor; (b) Bereitstellen einer Fahrzeug-Kommunikationsplattform (VCP) innerhalb des Fahrzeugs, die VCP konfiguriert für die Kommunikation mit dem Fahrzeugsensor, die VCP konfiguriert zum Erzeugen und Übertragen mindestens einer Datenübertragung; (c) Bereitstellen einer Ferneinheit für den Empfang der VCP-Datenübertragung; (d) Empfangen von mindestens einer Kommunikation vom Fahrzeugsensor an der VCP; (e) mittels der VCP das Erzeugen mindestens einer Routinewartungs-Meldung abgeleitet aus der Kommunikation mit dem Fahrzeugsensor; (f) mittels der VCP das Übertragen der Routinewartungs-Meldung zur Ferneinheit; (g) Empfang der Routinewartungs-Meldung an der Ferneinheit; (h) Implementieren einer Backend-Funktion über die Ferneinheit, um die Routinewartungs-Meldung zu prüfen und zu analysieren; (i) über die Ferneinheit das Vorhersagen der zukünftigen Wartung des Fahrzeugs aus der Analyse der Routinewartungs-Meldung; und (j) über die Ferneinheit das Modifizieren des Fahrzeug-Registrierungsstatus in der Datenbank, um die Wartungsarbeiten zu ermöglichen.
Figurenliste
Die vorliegende Offenbarung wird im Folgenden in Verbindung mit den nachstehenden Zeichnungsfiguren beschrieben, worin gleiche Bezugszeichen gleiche Elemente bezeichnen und worin:

1 ein Diagramm zur Darstellung eines nicht ausschließlichen Beispiels einer Kommunikationsumgebung für ein hierin präsentiertes exemplarisches System ist;
2 ein Kommunikations-Flussdiagramm zwischen den Kommunikationseinrichtungen für ein Carsharing-System veranschaulicht;
3 ein breites Übersichts-Flussdiagramm zum Reservieren und Autorisieren der Verwendung des Fahrzeugs ist;
4 ein Flussdiagramm zum Erfassen und Autorisieren eines Benutzers anhand einer sich nähernden mobilen Vorrichtung ist;
5 ein exemplarisches Flussdiagramm zum Ausführen von Fahrzeugfunktionen über die mobile Vorrichtung ist;
6 ein exemplarisches Flussdiagramm zum Ausführen zusätzlicher Fahrzeugfunktionen des Fahrzeugs ist; und
7 ein exemplarisches Flussdiagramm für einen Aspekt einer Ausführungsform der CarShare-App ist.

AUSFÜHRLICHE BESCHREIBUNG
Ausführungsformen der vorliegenden Offenbarung werden hierin beschrieben. Es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich Beispiele sind und andere Ausführungsformen verschiedene und alternative Formen annehmen können. Die Figuren sind nicht unbedingt maßstabsgerecht; einige Merkmale können größer oder kleiner dargestellt sein, um die Einzelheiten bestimmter Komponenten zu veranschaulichen. Folglich sind die hierin offenbarten aufbau- und funktionsspezifischen Details nicht als einschränkend zu verstehen, sondern lediglich als repräsentative Grundlage, um den Fachleuten die verschiedenen Arten und Weisen der Nutzung der exemplarischen Aspekte der vorliegenden Offenbarung zu vermitteln. Wie Fachleute verstehen, können verschiedene Merkmale, die mit Bezug auf beliebige der Figuren dargestellt und beschrieben werden, mit Merkmalen kombiniert werden, die in einer oder mehreren anderen Figuren dargestellt sind, um Ausführungsformen zu erzeugen, die nicht explizit dargestellt oder beschrieben sind. Die dargestellten Kombinationen von Merkmalen stellen repräsentative Ausführungsformen für typische Anwendungen bereit. Beliebige Kombinationen und Modifikationen der Merkmale, die mit den Lehren dieser Offenbarung übereinstimmen, könnten jedoch für bestimmte Anwendungen und Implementierungen erwünscht sein.
Die hierin offenbarten Figuren sind nicht unbedingt maßstabsgerecht; einige Merkmale können größer oder kleiner dargestellt sein, um die Einzelheiten bestimmter Komponenten zu veranschaulichen. Folglich sind die hierin offenbarten aufbau- und funktionsspezifischen Details nicht als einschränkend zu verstehen, sondern lediglich als repräsentative Grundlage, um den Fachleuten die verschiedenen Arten und Weisen der Nutzung der exemplarischen Aspekte der vorliegenden Offenbarung zu vermitteln. Wie Fachleute verstehen, können verschiedene Merkmale, die mit Bezug auf beliebige der Figuren dargestellt und beschrieben werden, mit Merkmalen kombiniert werden, die in einer oder mehreren anderen Figuren dargestellt sind, um Ausführungsformen zu erzeugen, die nicht explizit dargestellt oder beschrieben sind. Die dargestellten Kombinationen von Merkmalen stellen repräsentative Ausführungsformen für typische Anwendungen bereit. Beliebige Kombinationen und Modifikationen der Merkmale, die mit den Lehren dieser Offenbarung übereinstimmen, könnten jedoch für bestimmte Anwendungen und Implementierungen erwünscht sein.
Carsharing-Dienste (SB-Fahrzeugvermietungen) ermöglichen den Kunden, standortgestützte Fahrzeugnutzungen zu reservieren, speziell in urbanen Umgebungen. Diese Mietfahrzeuge befinden sich häufig auf reservierten Stellplätzen, die mit fest montierten Schildern oder Markierungen gekennzeichnet sind. Idealerweise übernimmt ein Benutzer ein Fahrzeug an einem reservierten Stellplatz und gibt das Fahrzeug am gleichen, oder einem ähnlich markierten Stellplatz wieder ab. Es kann auch wünschenswert sein, Systeme zur Überwachung eines Stellplatzes bereitzustellen; zum Beispiel, das Aufstellen von intelligenten Schildern, um das Parken eines autorisierten oder nicht autorisierten Fahrzeugs auf dem Stellplatz zu erkennen sowie den Benutzer oder die Vermietung zu benachrichtigen.
Unter Bezugnahme auf 1 ist ein nicht einschränkendes Beispiel einer Umgebung eines Kommunikationssystems 10 dargestellt, das zusammen mit Beispielen des hierin offenbarten Carsharing-Systems oder zum Implementieren von Beispielen der hier offenbarten Verfahren verwendet werden kann. Das Kommunikationssystem 10 enthält im Allgemeinen ein Fahrzeug 12, ein Drahtlosträgersystem 50, ein Festnetz 16, ein Callcenter 18 und ein System von Wartungseinrichtungen 82 (als eine dargestellt). Es sollte beachtet werden, dass die Architektur, der Aufbau und Betrieb sowie die einzelnen Komponenten des veranschaulichten Systems lediglich exemplarisch sind, und dass anders konfigurierte Kommunikationssysteme ebenfalls verwendet werden können, um die Beispiele des hierin offenbarten Verfahrens zu implementieren. Somit sind die folgenden Absätze, die eine Kurzübersicht des dargestellten Kommunikationssystems 10 bereitstellen, nicht als einschränkend gedacht.
Das Fahrzeug 12 kann jede Art von mobilem Fahrzeug, wie ein Motorrad, Auto, Lastwagen, Freizeitfahrzeug (SV), Boot, Flugzeug usw., sein und ist mit geeigneter Hardware und Software ausgestattet, die es ermöglicht, über das Kommunikationssystem 10 zu kommunizieren. Ein Teil der Fahrzeug-Hardware 20 ist allgemein in 1 gezeigt mit einer Telematikeinheit 24, einem Mikrofon 26, einem Lautsprecher 28, Tasten und/oder Steuerungen 30, die mit der Telematikeinheit 24 verbunden sind, und verschiedene Fahrzeugsysteme wie beispielsweise aber nicht beschränkt auf eine Fahrzeugunfall- bzw. Kollisionserfassungs-Sensorschnittstelle 66 und Sensorschnittstellenmodule 44. Operativ mit der Telematikeinheit 24 ist eine Netzwerkverbindung oder Fahrzeugbus 32 verbunden. Beispiele geeigneter Netzwerkverbindungen beinhalten ein Steuergerätenetz (CAN), einen medienorientierten Systemtransfer (MOST), ein lokales Kopplungsstrukturnetzwerk (LIN), ein Ethernet und andere geeignete Verbindungen, wie z. B. jene, die den bekannten ISO (International Organization for Standardization)-, SAE (Society of Automotive Engineers)- und IEEE (Institute of Electrical and Electronics Engineers)-Standards und -Spezifikationen entsprechen.
Die Telematikeinheit 24 ist eine fahrzeugeigene Fahrzeug-Kommunikationsplattform (hierin nachfolgend „VCP“), die eine Vielfalt von Diensten durch ihre Kommunikationen mit dem entfernt befindlichen Callcenter 18 bereitstellt und im Allgemeinen eine elektronische Verarbeitungsvorrichtung 38, eine oder mehrere Arten von elektronischen Speichern 40, einen Mobiltelefonchipsatz/eine Komponente 34, ein drahtloses Modem 36, eine Dual-Mode-Antenne 70 und eine Navigationseinheit mit einem GNSS-Chipsatz/einer Komponente 42 enthält. In einem Beispiel enthält das drahtlose Modem 36 ein Computerprogramm und/oder Code-Segment (Software-Algorithmus), das/der angepasst ist, um in der elektronischen Verarbeitungsvorrichtung 38 ausgeführt zu werden.
Die VCP 24 kann verschiedene Dienste bereitstellen, darunter: genaue Wegbeschreibungen, bordeigene Sprachnachrichten (IVVM) und andere navigationsbezogene Dienste, die in Verbindung mit dem GNSS-Chipsatz/der Komponente 42 bereitgestellt werden; eine Airbag-Auslösebenachrichtigung und andere Notfall- oder Pannenhilfe-bezogene Dienste, die in Verbindung mit verschiedenen Crash- und/oder Kollisionssensor-Schnittstellenmodulen 66 und Kollisionssensoren 68 bereitgestellt werden, die im gesamten Fahrzeug angeordnet sind; und/oder Infotainment-bezogene Dienste, wobei Musik, Internet-Webseiten, Filme, Fernsehprogramme, Videospiele und/oder andere Inhalte von einem Infotainmentcenter 46 heruntergeladen werden, das mit der Telematikeinheit 24 über einen Fahrzeugbus 32 und einen Audiobus 22 operativ verbunden ist. In einem Beispiel wird der heruntergeladene Inhalt für eine sofortige oder spätere Wiedergabe gespeichert. Die oben genannten Dienste sind keineswegs eine vollständige Liste der Möglichkeiten der VCP 24, sie stellen lediglich eine Aufzählung von einigen der Dienste dar, die die VCP 24 anbieten kann. Es wird erwartet, dass die VCP 24 eine Anzahl an zusätzlichen Komponenten zusätzlich zu und/oder verschiedene Komponenten von den oben aufgeführten enthält, und mit einem oder mehreren zusätzlichen Funktionen des Kommunikationssystems 10 zusammenarbeiten kann, um seine Fähigkeiten zu erreichen.
Die Fahrzeugkommunikation kann Mobilfunk verwenden, um einen Sprachkanal mit dem Drahtlosträgersystem 14 einzurichten, sodass sowohl Sprach- als auch Datenübertragungen über den Sprachkanal gesendet und empfangen werden können. Fahrzeugkommunikationen werden über den/die Mobilfunkchipsatz/Komponente 34 für die Sprachkommunikation und das drahtlose Modem 36 zur Datenübertragung freigegeben. Alle geeigneten Kodierungs- oder Modulationsverfahren können mit den vorliegenden Beispielen verwendet werden, darunter auch digitale Übertragungstechnologien, wie TDMA (Zeitmultiplexzugriff), CDMA (Codemultiplex-Vielfachzugriff), W-CDMA (Breitband-CDMA), FDMA (Frequenzvielfachzugriff), OFDMA (orthogonaler Frequenzvielfachzugriff) usw.
Die Dual-Mode-Antenne 70 bedient den/die GNSS-Chipsatz/Komponente 42 und den/die Mobiltelefonchipsatz/Komponente 34. Unter anderen Funktionen stellt der/die GNSS-Chipsatz/Komponente 42 Zweiwege-, Echtzeit-Datenübertragungen geographischer Positionsinformationen bereit, typischerweise zu und von einem Cluster von GPS-Satelliten (nicht dargestellt), wie allgemein bekannt ist.
Die optische Anzeige 39 ist vorzugsweise eine Grafikanzeige, wie z. B. ein Berührungsbildschirm am Armaturenbrett oder eine Warnanzeige, die von der Frontscheibe reflektiert wird, oder als Teil der Konsole des Infotainment-Centers 46, und verwendet werden kann, um eine Vielzahl von Eingabe- und Ausgabefunktionen bereitzustellen (d. h. zur GUI-Implementierung in der Lage).
Das Mikrofon 26 stellt dem Fahrer oder anderen Fahrzeuginsassen Mittel zur Eingabe von verbalen oder anderen akustischen Befehlen bereit und kann mit einer eingebetteten Sprachverarbeitungseinheit unter Verwendung einer Mensch-Maschine-Schnittstellen-Technologie (HMI), wie in der Technik bekannt, ausgestattet sein. Umgekehrt stellt der Lautsprecher 28 eine verbale Ausgabe für die Insassen bereit und kann entweder ein eigenständiger Lautsprecher speziell zur Verwendung mit der VCP 24 (z. B. IVVM) oder Teil der Fahrzeug-Audiokomponente 64 sein. In jedem Fall ermöglichen das Mikrofon 26 und der Lautsprecher 28 das Kommunizieren der Hardware 20 und des Callcenters 18 mit den Insassen des Fahrzeugs durch hörbare Sprache. Die Fahrzeughardware beinhaltet auch eine oder mehrere Tasten und/oder Steuerungen 30 zum Ermöglichen des Aktivierens oder Einstellens einer oder mehrerer Fahrzeug-Hardware-Komponenten 20. So kann beispielsweise eine der Tasten und/oder Steuerungen 30 eine elektronische Drucktaste zum Einleiten von Sprachkommunikation mit dem Kommunikationszentrum 18 sein (sei es ein Live-Berater, wie Anweiser 58, oder ein automatisiertes Anruf-Reaktionssystem). In einem anderen Beispiel kann eine der Tasten und/oder Steuerungen 30 zum Einleiten von Notdiensten verwendet werden.
Die Audiokomponente 64 ist funktionsfähig mit dem Fahrzeugbus 32 und dem Audiobus 22 verbunden. Die Audiokomponente 64 empfängt analoge Informationen und gibt diese als Schall über den Audiobus 22 wieder. Digitale Informationen werden über den Fahrzeugbus 32 empfangen. Die Audiokomponente 64 stellt AM (amplitude modulated)- und FM (frequency modulated)-Hörrundfunk, CD (Compact Disc), DVD (Digital Video Disc) und Multimediafunktion unabhängig vom Infotainmentcenter 46 bereit. Die Audiokomponente 64 kann ein Lautsprechersystem beinhalten oder kann einen Lautsprecher 28 über Arbitrierung auf dem Fahrzeugbus 32 und/oder dem Audiobus 22 verwenden.
Die Fahrzeugunfall- und/oder Aufprallerfassungs-Sensorschnittstelle 66 ist funktionsfähig mit dem Fahrzeugbus 32 verbunden. Die Kollisionssensoren 68 liefern der VCP 24 Informationen über die Crash- und/oder Kollisionserkennungs-Sensorschnittstelle 66 bezüglich der Schwere einer Fahrzeugkollision wie den Aufprallwinkel und die Größe der Einwirkkraft.
Fahrzeugsensoren 72, die mit verschiedenen Sensorschnittstellenmodulen 44 verbunden sind, sind funktionsfähig mit dem Fahrzeugbus 32 verbunden und überwachen verschiedene Fahrzeugdynamiken. Beispiele von Fahrzeugsensoren enthalten sind aber nicht beschränkt auf Gyroskope, Beschleunigungsmesser, Wegmesser, Kilometerzähler, Tachometer, OBD-Systeme (z. B. OBD II), Magnetometer, Kraftstofftanküberwachung, Ölstandsüberwachung, Ölfilterüberwachung, Hydrauliküberwachung, Emissionserfassung und/oder Steuersensoren und dergleichen. Als Beispiel könnte ein Ölüberwachungsmodul (OMM) 44 unzählige Echtzeitdaten über verschiedene Motoraspekte bezüglich Aspekten des Motoröls einschließlich unter anderem der Motoröl-Lebensdauer, des Ölfilterzustands und des Öldrucks bereitstellen. Als weiteres Beispiel könnte ein Chassis-Steuermodul (BCM) 44 verschiedene Fahrzeugfunktionalitäten bereitstellen, einschließlich, jedoch nicht beschränkt auf, die Verriegelungs- und Entriegelungsfunktionalität, Kofferraum- oder Heckklappenöffnung, Hupe, Ein-/Ausschalten der Beleuchtung, Fernstart- und Motor-Start-Stopp-Funktionalität während typischer Kommunikation mit den RKE- oder passiven Systemen.
Ein Passive Entry Passive Start (PEPS) Modul 44 ist ein weiteres Beispiel eines Fahrzeug-Sensormoduls, das mit dem Fahrzeugbus 32 verbunden werden kann und passive Erfassung der Abwesenheit oder Anwesenheit eines passiven physischen Schlüssels oder eines virtuellen Fahrzeugschlüssels (nachfolgend erörtert) bereitstellt. Das PEPS-Modul 44 kann eine eigene Antenne verwenden oder Signale über die Antenne 70 empfangen. Wenn sich der passive physische Schlüsselanhänger oder ein Smartphone 57 mit virtuellem Fahrzeugschlüssel nähert, kann das PEPS-Modul 43 ermitteln, ob der passive physische Schlüssel zu dem Fahrzeug 12 gehört und/oder (in einigen Ausführungsformen) ermitteln, ob der virtuelle Fahrzeugschlüssel autorisiert/authentisch ist. Ist der virtuelle Fahrzeugschlüssel authentisch, kann das PEPS-Modul 44 einen Befehl an das BCM senden und Zugang zum Fahrzeug 12 erlauben. In anderen Anwendungen ist es dem BCM möglich, die dem PEPS-Modul 44 zugeordnete Funktionalität auszuführen. Fachleute auf dem Fachgebiet werden erkennen, dass es sich bei den vorgenannten VSMs nur um Beispiele von einigen der Sensormodule handelt, die im Fahrzeug 12 verwendet werden können, zahlreiche andere Module jedoch ebenfalls möglich sind.
Das Drahtlosträgersystem 14 kann ein Mobiltelefonsystem oder jedes andere geeignete drahtlose System sein, das Signale zwischen der Fahrzeug-Hardware 20 und dem Festnetz 16 überträgt. Gemäß einem Beispiel beinhaltet das Drahtlosträgersystem 14 einen oder mehrere Zellentürme 48
Das Festnetz 16 kann ein konventionelles Telekommunikations-Festnetz sein, das mit einem oder mehreren Festnetztelefonen verbunden ist und das Drahtlosträgersystem 14 mit dem Callcenter 18 und in bestimmten Fällen mit der Wartungseinrichtung 62 verbindet. So kann beispielsweise das Festnetz 16 ein öffentliches Telefonnetz (PSTN) und/oder ein Internet-Protokoll (IP)-Netzwerk beinhalten, wie von Fachleuten anerkannt. Selbstverständlich können ein oder mehrere Segmente des Festnetzes 16 in der Form eines Standard-verdrahteten Netzwerks, eines Glasfaser- oder anderen optischen Netzwerks, eines Kabelnetzwerks, anderer drahtloser Netzwerke, wie etwa Drahtlosnetzwerke (WLAN), oder von Netzwerken, die Broadband-Wireless-Access (BWA) oder eine beliebige Kombination davon bereitstellen, implementiert werden.
Eine der vernetzten Vorrichtungen, die mit der VCP 24 kommunizieren können, ist eine mobile Computervorrichtung 57 wie beispielsweise ein Smartphone, eine tragbare Computervorrichtung wie eine Smartwatch oder Smart-Brille mit Zweiwege-Kommunikationsfähigkeiten, ein persönlicher Laptop-Computer oder ein Tablet-Computer mit Zweiwege-Kommunikationsfähigkeiten, ein Netbook-Computer oder beliebige geeignete Kombinationen davon. Die mobile Computervorrichtung 57 kann Computerverarbeitungsfähigkeiten durch eine mobile Verarbeitungsvorrichtung (Mobilprozessor) enthalten, einen Sender-Empfänger, der zur Kommunikation mit dem Drahtlosträgersystem 14 in der Lage ist zum Senden, und einen mobilen Speicher 61, eine Digitalkamera 55, Bedienoberfläche 59 und/oder ein GPS-Modul zum Empfang von GPS-Satellitensignalen und zum Erzeugen von GPS-Koordinaten basierend auf diesen Signalen. Die Benutzeroberfläche 59 kann als eine grafische Oberfläche des Touchscreens verkörpert sein, die sowohl für die Benutzerinteraktion als auch zur Anzeige von Informationen geeignet ist. Die Digitalkamera 55 kann die Fähigkeit zum Erzeugen digitaler Bilder (d. h. digitale Bildinformationen) beinhalten, die Bitmap-Datendarstellungen von greifbaren Objekten sind, die im Speicher 61 erfasst und gespeichert sind, und zwar über Vorgänge, die im Stand der Technik bekannt sind. Beispiele für die mobile Computervorrichtung 57 enthalten Smartphones wie das von Apple Inc. hergestellte iPhone™ und das von Motorola Inc. (sowie anderen) hergestellte Droid™ und tragbare Geräte wie die von Apple Inc. hergestellte Apple Watch (sowie andere). Obwohl die Computervorrichtung 57 die Fähigkeit zum Kommunizieren über drahtlose Verbindungen unter Verwendung des Drahtlosträgersystems 14 besitzt, ist dies nicht immer der Fall. So stellt beispielsweise Apple Geräte her, wie die verschiedenen Modelle des iPad™ und iPod Touch™, die Verarbeitungsvermögen, die Schnittstelle 59 und die Möglichkeit zu Kurzbereichs-Drahtloskommunikationsverbindungen beinhalten. Jedoch haben die iPod Touch™ und einige iPads™ keine drahtlosen Kommunikationsfähigkeiten. Dennoch können diese und ähnliche Geräte für die Zwecke der hierin beschriebenen Systeme und Verfahren als eine Art Mobilgerät angesehen und verwendet werden, wie die hierin beschriebene mobile Computervorrichtung 57.
Die mobile Computervorrichtung 57 kann eine oder mehrere Softwareanwendungen empfangen, die dem Fahrzeug 12 zugeordnet werden sollen. So kann beispielsweise der Benutzer der mobilen Vorrichtung 57 einen Online-Softwareanwendungs-Store oder einen Webdienst besuchen und eine Carsharing-Softwareanwendung 86 (nachfolgend „CarShare-App“) daraus herunterladen. Die mobile Computervorrichtung 57 kann darüber hinaus diese CarShare-App auf dem mobilen Speicher 61 installieren. Bei der Implementierung kann die CarShare-App 86 darüber hinaus eine oder mehrere grafische Benutzeroberflächen (GUIs) enthalten, um eine oder mehrere Eingabeaufforderungen zu enthalten, die den Benutzer anweisen, Informationen bzw. einen oder mehrere Befehle bereitzustellen.
Ein Modul für drahtlose Nahbereichsverbindung (SRWC) 74 ermöglicht der mobilen Computervorrichtung 57 und der VCP 24 eine Kopplung miteinander (oder gegenseitige Verbindung), wenn sie sich innerhalb einer drahtlosen Reichweite befinden (z. B. bevor eine Trennung von dem drahtlosen Netzwerk erfolgt), wie es Fachleuten allgemein bekannt ist. SRWC-Kopplung ist dem Fachmann bekannt (z. B. Bluetooth Low Energy). Das Callcenter 20 kann an der Kopplung der mobilen Computervorrichtung 57 und der VCP 30 teilnehmen. So kann beispielsweise das Callcenter 20 für zusätzliche Sicherheit das Abfrageverfahren zwischen der VCP 24 und mobilen Computervorrichtung 57 einleiten.
Das Callcenter 18 ist so konzipiert, dass die Fahrzeug-Hardware 20 durch eine Anzahl an unterschiedlichen Back-End-Funktionen des Systems unterstützt wird; gemäß dem hier gezeigten Beispiel enthält sie allgemein eine(n) oder mehrere Schalter 52, Fern-Computereinheiten 54 (z.B. einen oder mehrere Server), Datenbanken 56, Berater 58, wie auch eine Vielfalt anderer Telekommunikations-/Computerausrüstung 60. Diese verschiedenen Komponenten sind über eine Netzwerkverbindung oder einen Bus 62 wie den/die zuvor in Verbindung mit der Fahrzeug-Hardware 20 beschriebene/n geeignet miteinander verbunden. Schalter 52, der ein Nebenstellenanlagenschalter (PBX) sein kann, leitet eingehende Signale weiter, so dass Sprachübertragungen im Allgemeinen entweder zum Live-Berater 58 oder zu einem automatisierten Reaktionssystem gesendet werden und Datenübertragungen an ein Modem oder andere Komponenten des Telekommunikations-/Computergerätes 60 zur Demodulation und weiteren Signalverarbeitung geleitet werden. Das Modem oder das andere Telekommunikations-/Computergerät 60 kann wie vorstehend erläutert einen Encoder enthalten und kann mit verschiedenen Geräten wie etwa einer Ferneinheit 54 und einer Datenbank 56 verbunden sein. Die Datenbank 56 könnte beispielsweise zum Speichern von Teilnehmerprofilen, Teilnehmerverhaltensmustern, Informationen des Fahrzeug-Reservierungskalenders oder jeglichen anderen relevanten Teilnehmerinformationen ausgestaltet sein. Der Fahrzeug-Reservierungskalender könnte beispielsweise ein ausgeführtes Code-Segment sein, um einen virtuellen Kalender mit zahlreichen bestimmten Zeitfenstern zu erzeugen, damit Benutzer des Carsharing-Systems mindestens ein Fahrzeug im System für eine gewünschte Zeitdauer reservieren können. Eine Ausführungsform des Reservierungskalenders kann die Zeitfenster-Informationen in tabellarischer Form (Kalkulationstabelle) speichern.
Obwohl das veranschaulichte Beispiel beschrieben wurde, als würde es in Verbindung mit einer bemannten Version des Callcenters 18 verwendet werden, versteht es sich, dass das Callcenter 18 eine Vielzahl von geeigneten zentralen oder dezentralen Einrichtungen sein kann, bemannt oder unbemannt, mobil oder fest, für die es wünschenswert ist, Sprache und Daten auszutauschen.
Ein System von Wartungseinrichtungen 82 kann beispielsweise über eine Netzwerkverbindung oder einen Bus 62 in Verbindung mit dem Callcenter 18 stehen. Jede Wartungseinrichtung 82 stellt zahlreiche Routine-Wartungsdienste für jedes Fahrzeug 12 im Carsharing-System 10 bereit. Basierend auf einer unterscheidbaren Wartungsaufgabe kann beispielsweise das Fahrzeug 12 durch Techniker 84 repariert werden. Wenn zum Beispiel OMM erkennt, dass die verbleibende Motoröl-Lebensdauer unter einen bestimmten Schwellwert sinkt (z. B. 20 %) oder der Ölfilter-Gesundheitszustand ausfällt (z. B. geringer Öldruck, Öltropfen usw.) kann das Fahrzeug 12 dafür bestimmt werden, zur nächstgelegenen Einrichtung 82 im System für die Routinewartung eines Ölwechsels (oder eines anderen ähnlichen Services) gebracht zu werden, um das Fahrzeugproblem zu lindern.
Die Wartungseinrichtungen 82 können an ausgewählten Stellen in einem bestimmten geographischen Bereich verstreut sein. So kann sich beispielsweise eine Wartungseinrichtung 82 im System in oder nahe einem Bereich mit einem Cluster reservierbarer Stellplätze befinden (oben erörtert). Eine derartige Stelle ist bequem für das Fahrzeug 12, um zu einer Wartungseinrichtung 82 gebracht zu werden. Es sollte verstanden werden, dass eine der Wartungseinrichtungen 82 auch im Callcenter 20 integriert sein kann. Als solche kann diese spezielle Wartungseinrichtung direkt mit der Ferneinheit 54 verbunden sein oder indirekt über ein LAN, WLAN oder Drahtlosträgersystem 50 mit der Ferneinheit 54 verbunden sein.
2 zeigt ein Kommunikations-Flussdiagramm zwischen den Kommunikationseinrichtungen für ein Carsharing-System. Das Carsharing-System ermöglicht einem Benutzer, ein entsprechendes, nicht reserviertes Fahrzeug über seine mobile Computervorrichtung 57 zu reservieren. Das Carsharing-System koppelt ferner die mobile Vorrichtung 57 an das SRWC-Modul 74 des gewählten Fahrzeugs 12, sodass Funktionen des Fahrzeugs (z. B. Fahrzeugzugang und -betrieb) über die mobile Computervorrichtung 57 befehligt werden können.
2 veranschaulicht die Interaktionen zwischen Fahrzeug 12, mobiler Vorrichtung 57 und Ferneinheit 54. Das SRWC-Modul 74 kann einen SRWC-Chipsatz 76 und eine oder mehrere interne SRWC-Antennen 70 enthalten. Das Fahrzeug 12 enthält weiter ein Sensorschnittstellen-Modul (BCM) 78 und eine VCP 24, wie weiter oben erörtert. In dieser Ausführungsform enthält das BCM 78 verschiedene Fahrzeugfunktionalitäten, einschließlich, jedoch nicht beschränkt auf, die Verriegelungs- und Entriegelungsfunktionalität, Kofferraum- oder Heckklappenöffnung, Hupe, Fahrzeugbeleuchtungs-Blinkkonfigurationen, Fernstart- und Motorstart-Funktionalität während typischer Kommunikation mit dem schlüssellosen Fernzugangssystem (Remote Keyless Entry, RKE) oder passiven Systemen. Die VCP 24 ermöglicht Ferndatenübertragungen vom SRWC-Modul 74 an die Ferneinheit 54. Das VCP 24 kann auch einen drahtlosen für das SRWC-Modul 74 zugänglichen Hotspot als ein Kommunikationsmedium bereitstellen, welches einen zusätzlichen Authentifizierungs-Mechanismus bereitstellen kann. In bestimmten Ausführungsformen kann das SRWC-Modul 74 alternativ seine eigenen Langstrecken-Kommunikationsfähigkeiten enthalten. Es ist darauf hinzuweisen, das SRWC-Modul 74 Funk-Kommunikationsprotokolle implementieren kann, die unter anderem ein Bluetooth Low Energy (BLE) Protokoll, ein Bluetooth-Protokoll, ein ZigBee-Protokoll, ein iBeacon-Protokoll, ein Eddystone-Protokoll, ein Nahfeldkommunikationsprotokoll und/oder ein Wi-Fi Protokoll enthalten können, aber nicht auf diese beschränkt sind.
In bestimmten Ausführungsformen kann das SRWC-Modul 76 als eine adaptive hardwarebasierte Zubehörvorrichtung ausgeführt sein, die lösbar mit einem On-Board-Diagnose (OBD)-Anschluss 80 verbunden ist. Port 80 (auch als ALDL-Port bekannt) ist eine Komponente zum Verbinden mit einem der On-Board-Diagnosesysteme (z. B. OBD II), Fahrzeugsensoren 72 und/oder Sensorschnittstellen-Modulen 44 (z. B. OMM, BCM usw.) über den Fahrzeugbus 32. Port 80 kann ferner Komponenten enthalten, die seine eigenen unabhängigen internen Prüfungen und Diagnosen verschiedener Fahrzeugsysteme (z. B. des Kraftfahrzeugantriebs, der Aufhängung, des Motors usw.) bereitstellen, um sicherzustellen, dass die Fahrzeugleistung bestimmten Standards entspricht. In anderen Ausführungsformen kann das SRW- Modul 76 unabhängig im Fahrzeug 12 installiert sein und im Ergebnis direkt mit den On-Board-Diagnosesystemen (z. B. OBD II), Fahrzeugsensoren 72 und/oder Sensorschnittstellen-Modulen 44 (z. B. OMM, BCM usw.) über den Fahrzeugbus 32 kommunizieren. Es sollte verstanden werden, dass eine solche Anlage während der Fahrzeugherstellung oder als Teil einer Nachrüstinstallation installiert werden kann.
Das SRWC-Modul 74 kann zusätzlich Sicherheitsmechanismen zum Schutz des Fahrzeugs vor unbefugter Benutzung oder Diebstahl enthalten (z. B. über Mechanismen zur Deaktivierung der schlüssellosen Remote-Funktionen). Wie folgt, kann das SRWC-Modul 76 die Notwendigkeit zur Speicherung eines Berechtigungsschlüssels in einem separaten Schlüsselanhänger zur passiven Ausführung bestimmter Fahrzeugfunktionen ersetzen. Wie unten diskutiert, kann die Ferneinheit 54 zum Erhalten der Berechtigung zwei verschlüsselte öffentliche Schlüssel 27 und 29 ausstellen, die zum Entriegeln eines entsprechenden digitalen Zugangs-Tokens (in Datenbank 56 gespeichert) erforderlich sind, das den Fernzugriff auf bestimmte Fahrzeugsysteme ermöglichen kann. Der erste Schlüssel 27 kann zur mobilen Vorrichtung 57 ausgegeben und darauf gespeichert werden. Der zweite Schlüssel 29 kann zum SRWC-Modul 76 ausgegeben und darauf (oder im Speicher 40) gespeichert werden. Das Zugangs-Token kann anderweitig im Speicher 40 wie in der US-Patentanmeldungsveröffentlichung Nr. 2016-0203661A1 beschrieben gespeichert werden, deren Gesamtheit hiermit als Referenz mit einbezogen ist. Es sollte auch verstanden werden, dass neben der Verschlüsselung mit öffentlichen Schlüsseln andere Berechtigungsschemata genutzt werden können.
Das Zugangs-Token enthält eine äußere Schicht (die Schicht „Befehlsanforderung“), die vom ersten und zweiten öffentlichen Schlüssel 27, 29 signiert werden kann und die Schlüssel durch Vergleichen ihrer verschlüsselten Daten überprüfen kann. Das Token enthält zusätzlich eine innere Schicht (die Schicht „digitaler Schlüssel“), die ein unmodifiziertes server-signiertes Objekt enthält und ein Klartext-Paket bereitstellt, welches den zulässigen Fahrzeugbetrieb und Beschränkungen (zulässige Zeitrahmen usw.) beschreibt. Wie folgt, wenn ein Benutzer des Carsharing-Systems das Fahrzeug 12 erreicht, kann dessen mobile Computervorrichtung 57 den ersten Schlüssel 27 digital zum SRWC-Modul 74 übertragen. Das SRWC-Modul 74 (oder Prozessor 38) stellt dann den ersten und zweiten Schlüssel 27, 29 dem Zugangs-Token bereit. Das Zugangs-Token kann dann überprüfen, dass der erste und zweite Schlüssel 27, 29 miteinander übereinstimmen. Wenn die Überprüfung beendet und in Übereinstimmung mit den Parametern der Schicht „digitaler Schlüssel“ ist, kann die mobile Vorrichtung 57 indirekt auf die Fahrzeugsysteme zugreifen, mit ihnen kommunizieren und sie anweisen - die Gesamtheit davon ist in der US-Patentanmeldungsveröffentlichung Nr. 2016-0203661A1 offenbart (zuvor oben als Referenz mit einbezogen). Die mobile Computervorrichtung 57 kann somit BCM 44 befehlen, die Funktionen der Verriegelung und Entriegelung, des Motors und verschiedener anderer Fahrzeugfunktionen zu bedienen. Die mobile Computervorrichtung 57 kann darüber hinaus mit anderen Fahrzeugsystemen kommunizieren und Informationen empfangen, die über die Benutzeroberfläche der CarShare-App 86 anzuzeigen sind.
3 ist ein breiter Überblick über das Verfahren 300 zum Reservieren und Autorisieren der Verwendung des Fahrzeugs, das für das Carsharing-System ausgerüstet ist.
In Schritt 310 wird als erstmalige Einrichtung das SRWC-Modul 74 entweder permanent in Fahrzeug 12 installiert oder lösbar mit Port 80 verbunden. In Schritt 320 wird durch die CarShare-App 86 eine Fahrzeug-Reservierung erzeugt und kann ein Fahrzeug an einem bestimmten Stellplatz reservieren. Um die Fahrzeug-Reservierung abzuschließen, können verschiedene Details notwendig sein wie, jedoch nicht beschränkt auf, Informationen hinsichtlich der Identifikation der mobilen Vorrichtung (d. h. Seriennummer), Benutzername und Reservierungszeiten (z. B. Einträge für die bestimmte Anfangs- und Endzeit). Die mobile Vorrichtung 57 kann dann die Fahrzeug-Registrierung zur Ferneinheit 54 senden, um anschließend die Fahrzeug-Registrierung zu validieren. Wenn die Fahrzeug-Reservierung validiert werden kann, kann die Ferneinheit 54 die Reservierungsinformationen in der Datenbank 56 speichern (z. B. in einem Fahrzeug-Registrierungskalender).
Im Schritt 330 wird die Autorisierung der mobilen Computervorrichtung 57 durch die Ferneinheit 54 ausgeführt, wie weiter oben erörtert. Nach erfolgreicher Autorisierung erhält die mobile Computervorrichtung 57 im Schritt 340 den Zugang zu Funktionen der Fahrzeugsysteme. Im Schritt 350 wird der passive Start (d. h. Zündung) durch die mobile Vorrichtung 57 angewiesen (d. h. über die CarShare-App 86). Bei Beendigung der Fahrzeug-Reservierung deaktiviert die Ferneinheit 54 im Schritt 360 den Zugang zu Fahrzeugsystemen über die mobile Computervorrichtung 57. In diesem Schritt werden der erste und zweite öffentliche Schlüssel 27, 29 auf der mobilen Vorrichtung 57 und dem Fahrzeug 12 bereinigt (d. h. die Schlüsselcodes werden gelöscht).
4 stellt ein Flussdiagramm des Verfahrens 400 zur Registrierung eines reservierten Fahrzeugs im Carsharing-System dar. Im Schritt 410 erzeugt die CarShare-App 86 die Fahrzeug-Registrierungsinformationen. Im Schritt 420 kann die Ferneinheit 54 ein verschlüsselten Zugangs-Token spezifischen für die Registrierung erzeugen. Der Zugangs-Token wird an die mobile Computervorrichtung 57 innerhalb einer zuvor festgelegten Zeitdauer (z. B. 20 Sekunden) ab Zeitpunkt der Registrierungsanforderung übertragen. Das signierte Zugangstoken kann eine universelle eindeutige SRWV-Kennung (UUID), einen Zeitraum und einen Zeitstempel enthalten. Im Schritt 430 aktiviert und startet die CarShare-App 86 die Reservierung. Im Schritt 440 wird über die CarShare-App 86 eine Registrierungsbestätigung an den Benutzer gesendet.
5 stellt ein Verfahren 500 zur Erfassung und Autorisierung einer sich annähernden mobilen Computervorrichtung 57 dar, die zur Vervollständigung der Reservierungsregistrierung konfiguriert ist. Im Schritt 510 wird die mobile Vorrichtung 57 in eine ausgewählte physikalische Nähe des Fahrzeugs 12 bewegt. Im Schritt 520 erkennt die mobile Computervorrichtung 57 das SRWC-Modul 74 durch Implementieren von mindestens einer drahtlosen Sendung (d. h. ein Sweep). Das SRWC-Modul 74 kann auch programmiert werden, um ein Challenge-Signal zu senden (das eine entsprechende UUID enthalten kann). Im Schritt 530 validiert die mobile Computervorrichtung 57 das SRWC-Modul 74 (d. h. die UUID). Im Schritt 540 werden die mobile Computervorrichtung 57 und das SRWC-Modul 74 eindeutig gepaart und es kann eine Benachrichtigung an das SRWC-Modul 74 geliefert werden.
Im Schritt 550 kann das SRWC-Modul 74 ein BUS Wake-Up-Signal an die mit dem Fahrzeugbus 32 und dem Audiobus 22 verbundenen Merkmale übermitteln. Im Schritt 560 ist die VCP 24 durch das BUS Wake-Up-Signal aufgeweckt. Im Schritt 570 aktiviert die VCP 24 einen Funk-Knoten im Fahrzeug 12. Im Schritt 580 wird das SRWC-Modul 74 für die Übertragung einer oder mehrerer drahtloser Datenübertragungen (d. h. WLAN) freigegeben. In diesem Schritt können VCP 24 und/oder die mobile Computervorrichtung 57 optional eine Verifikationsanforderung zur Ferneinheit 54 übertragen und so sicherstellen, dass das Token nicht zuvor widerrufen wurde. Im Schritt 590 überträgt die VCP 24 die Validierungsanforderung zur Ferneinheit 54 zur Validierung von Schlüssel oder Token. Bei Empfang dieser Validierungsanforderung kann die Ferneinheit 54 im Schritt 600 den ersten und öffentlichen Schlüssel 27 und 29 sowie das Zugangs-Token auf Genauigkeit testen.
Im Schritt 610 kann eine Validierungsbenachrichtigung zum SRWC-Modul 74 übertragen werden. Im Schritt 620 wird das Zugangs-Token auch dem SRWC-Modul 74 bereitgestellt. Zusätzlich wird das Zugangs-Token im Schritt 630 von der mobilen Computervorrichtung 57 empfangen. Im Schritt 640 übermittelt die mobile Computervorrichtung 57 automatisch das Zugangs-Token zum SRWC-Modul 74. Im Schritt 650 validiert das SRWC-Modul 74 das Zugangs-Token über die digitale Signatur und die verschlüsselten öffentlichen Schlüssel (wie oben erörtert). Im Schritt 760 wird eine Autorisierungsbenachrichtigung an die mobile Computervorrichtung 57 gesendet, um dem Benutzer mitzuteilen, dass der eindeutige Pairing-Prozess abgeschlossen ist (und damit die CarShare-App 86 das Fahrzeug 12 befehligen kann).
6 ist ein Flussdiagramm für ein Verfahren 700 zum Ausführen von Betriebsfunktionen des Fahrzeugs, nachdem eine Authentifizierung hergestellt worden ist. Sobald die mobile Computervorrichtung 57 im Inneren des Fahrzeugs 12 ist, erkennt das SRWC-Modul 74 im Schritt 710 deren Anwesenheit (d. h. über eine SRWC-Innenantenne 70). In Schritt 720 empfängt das SRWC-Modul 74 den ersten öffentlichen Schlüssel 27 und koppelt den Schlüssel mit dem zweiten öffentlichen Schlüssel 29. Die Autorisierungs-Schlüssel werden dann zur Ferneinheit 54 übertragen. Im Gegenzug ermöglicht die Ferneinheit 54 der mobilen Vorrichtung 57 (d. h. der CarShare-App 86) den Betrieb des Fahrzeugs 12. Im Schritt 730 veranlasst die mobile Vorrichtung 57 den Fahrzeugbetrieb. Es sollte verstanden werden, dass die PEPS-Funktionalität über das Autorisieren des Fahrzeugmotorzugangs ausgeführt werden kann, wie es auch während eines typischen PEPS-Betriebs durchgeführt werden würde. Im Schritt 740 wird der Motor gestartet, und der Benutzer darf das Fahrzeug fahren.
Im laufenden Betrieb erzeugt VCP 24 im Schritt 750 eine Verbindung und kommuniziert mit OMM 44, BCM 44, OBD-Systemen, Wegmesser/Kilometerzähler (oder anderen Fahrzeugsystemen), um bestimmte Fahrzeug-Wartungsinformationen zu empfangen und zusammenzustellen. Die Fahrzeuginformationen können auf laufender Basis oder als einmaliger Vorgang empfangen werden. So könnte beispielsweise VCP 24 routinemäßig mit OMM 44 kommunizieren, um aktualisierte Fahrzeugöl-Informationen wie, jedoch nicht beschränkt auf, Öl-Lebensdauer und Filterzustand zu empfangen. In einem anderen Beispiel könnte VCP 24 mit den OBD-Systemen kommunizieren, um eine Anzeige einer eingetretenen Anomalie zu empfangen, welche das Fehlermeldungslicht (MIL) am Fahrzeug-Armaturenbrett anzeigt, und/oder eine Anzeige, dass ein Fahrzeugbauteil ausgefallen ist, und/oder eine Anzeige, dass es eine Benachrichtigung der Selbstdiagnose gibt. In noch einem weiteren Beispiel könnte VCP 24 routinemäßig mit dem Wegmesser/Kilometerzähler kommunizieren und eine Angabe empfangen, dass Fahrzeug 12 einen bestimmten Kilometerstand überschritten hat. Es sollte verstanden werden, dass für VCP 24 die Fähigkeit zur Kommunikation mit anderen Fahrzeugsensoren 44 vorgesehen ist, um Angaben zu anderen Fahrzeug-Wartungsinformationen zu empfangen. Es wurde vorgesehen, dass Fahrzeug-Wartungsinformationen Informationen von Fahrzeugsystemen (Sensorinformationen) im Hinblick auf Pflege oder Instandhaltung des Fahrzeugs und Motors sind.
Basierend auf den Fahrzeuginformationen kann VCP 24 die Fahrzeuginformationen zusammenstellen und anschließend eine oder mehrere Meldungen zur Routinewartung erzeugen. Wenn zum Beispiel die Wartungsmeldung das Fahrzeugöl betrifft, kann die Meldung Daten bezüglich der Zeit/Menge des verbleibenden Fahrzeugsöls enthalten. Die Meldung könnte außerdem Daten darüber umfassen, ob der Ölfilter vollständig ausgefallen ist. In einem anderen Beispiel, wenn die Wartungsmeldung den Ausfall einer Fahrzeugkomponente oder eine Benachrichtigung der Selbstdiagnose betrifft, könnte die Meldung Daten bezüglich der spezifischen ausgefallenen Komponente enthalten oder von jener Komponente/System von Komponenten, welche die Benachrichtigung der Selbstdiagnose ausgelöst haben. In noch einem weiteren Beispiel, wenn die Wartungsmeldung den Kilometerstand betrifft, könnte die Meldung Daten über den exakt erreichten Kilometerstand oder die Wegstrecke nach einem bestimmten Meilenstein (z. B. dem letzten Ölwechsel) enthalten. Es sollte beachtet werden, dass einer oder mehrere Aspekte von Schritt 750 eines oder mehrere Codesegmente (Software-Algorithmen) der VCP 24 zum Erzeugen einer Datendatei (temporär oder dauerhaft) innerhalb des elektronischen Speichers 40 für Zwecke der Speicherung der vor-/ nachkompilierten Informationen enthalten kann. In bestimmten Fällen kann die VCP 24 Informationen zur Fahrzeugposition vom GNSS-Chipsatz/Komponente 42 nehmen und diese Informationen in andere Fahrzeuginformationen einfügen. Das ermöglicht, den Fahrzeugstandort in der Wartungsmeldung zu berücksichtigen.
Im Schritt 760 überträgt die VCP 24 die Routinewartungs-Meldung zur Ferneinheit 54. Nach Empfang dieser Meldung kann die Ferneinheit 24 eine oder mehrere der Backend-Funktionen verwenden, um die Informationen der Meldung zu überprüfen und zu analysieren. Sobald die ausreichende Prüfung und Analyse abgeschlossen ist, kann die Ferneinheit 54 proaktiv vorhersagen, wann Fahrzeug 12 eine zukünftige Wartung benötigt. Als solches wird die Ferneinheit 54 gemäß diesen Wartungsvorhersagen automatisch den Fahrzeug-Registrierungsstatus für eine ausgewählte Zeitdauer (z. B. über den Fahrzeug-Reservierungskalender) als „außer Betrieb“ (oder einen ähnlichen Status) anpassen, um Benutzern das Reservieren des Fahrzeugs während dieser Zeitdauer zu verbieten und Zeit für das Ausführen mindestens einer Wartungsarbeit zu erlauben.
Die Ferneinheit 54 kann auch automatisch eine abgeleitete Wartungsbenachrichtigung an eine ausgewählte Einrichtung 82 in das System der Einrichtung übertragen, um die Wartungsarbeit für Fahrzeug 12 einzuplanen. Die Einrichtung 82 kann basierend auf einer Anzahl an Faktoren wie, jedoch nicht beschränkt auf, Wartungsspezialitäten, Verfügbarkeit eines Technikers und Kapazität der Einrichtung ausgewählt werden. In jenen Fällen, wo die Wartungsbenachrichtigung Informationen zum Fahrzeugstandort enthält, kann die Ferneinheit 54 eine Einrichtung 82 aus dem System basierend auf ihrem Ort relativ zum Fahrzeug auswählen. Die Ferneinheit 54 kann anderweitig eine Einrichtung 82 basierend auf dem berechneten wahrscheinlichen Ort auswählen, an dem sich Fahrzeug 12 am vorausgesagten Zeitpunkt der zukünftigen Wartung befinden wird. Eine solche Berechnung kann auf der erfassten Anzahl an Malen basieren, die das Fahrzeug an einem bestimmten reservierbaren Stellplatz war, den erfassten Fahrtmustern des Fahrzeugs und den aktuellen Informationen des Fahrzeug-Reservierungskalenders. Weiterhin erlaubt die Wartungsbenachrichtigung dem Techniker 84 zu wissen, wann er die Ausführung der Routine-Wartungsdienste an Fahrzeug 12 (z. B. ein Ölwechsel/ Filteraustausch) erwarten sollte, und die Benachrichtigung kann auch die ausführlichen Besonderheiten der Wartungsarbeiten erklären.
Im optionalen Schritt 770 kann die Ferneinheit 54 weiterhin die überprüften und analysierten Informationen verwenden, um mindestens eine Außer-Betrieb-Benachrichtigung abzuleiten und an die mobile Computervorrichtung 57 (d. h. CarShare-App 86) zu übertragen. Die Außer-Betrieb-Benachrichtigung ermöglicht Benutzern, Zeitabschnitte zu sehen, wo sie Fahrzeug 12 aufgrund der eingeplanten Wartungsarbeiten in Einrichtung 82 nicht reservieren können. Somit können Benutzer zusätzlich zu anderen Fahrzeugen am ähnlichem Ort im Carsharing-System 10 geleitet werden. Weiterhin kann bei Beendigung der Wartungsarbeiten oder zum Zeitfenster vor und nach der geplanten Wartungsarbeit automatisch ein Status „verfügbar für Reservierung“ (oder ein anderer ähnlicher Status) im Fahrzeug-Reservierungskalender zur Ansicht über die CarShare-App 86 bestimmt werden. Die Außer-Betrieb-Benachrichtigung kann auch reaktiv erzeugt werden, wenn ein Benutzer eine Fahrzeug-Registrierung während einem oder mehreren Zeitfenster(n) anfordert, die als Außer-Betrieb gekennzeichnet sind.
Während des optionalen Schritts 770 kann die Ferneinheit 54 ferner die Außer-Betrieb-Benachrichtigung zur VCP 24 zur Unterstützung des Fahrzeugfahrers bereitstellen. Die VCP 24 kann auch die Anzeige 39 und/oder Audiosystem 64 implementieren (z. B. über eine Infotainment-Mittelkonsole, Instrumententafel, IVVM usw.), um die bestimmte Außer-Betrieb-Benachrichtigung zu zeigen. Die Außer-Betrieb-Benachrichtigung kann beispielsweise eine Benachrichtigung an den Benutzer bereitstellen, dass das Fahrzeug aufgrund von Wartungsproblemen wie, jedoch nicht beschränkt auf, Öl-Lebensdauer unter einem gewissen Schwellwert (z. B. 5 %, 2 %) und/oder Gesundheitszustand des Ölfilters versagend nicht reserviert werden kann. Der Fahrzeugmotor kann auch von Ferne deaktiviert werden, so dass der Benutzer Fahrzeug 12 bis zum Abschluss der Wartungsarbeiten nicht betreiben kann. Eine solche Ferndeaktivierung kann durch bekannte Verfahren ergänzt werden und kann durch die Ferneinheit 54 und/oder andere Merkmale des Call-Centers 18 durchgeführt werden.
Es sollte beachtet werden, dass ein Techniker 84 das Fahrzeug 12 betreiben und es für die Wartungsarbeiten in die gewählte Einrichtung 82 im System bringen kann. Die Außer-Betrieb-Benachrichtigung kann ferner einen Zielort-Anreiz bieten, der den aktuellen Benutzer des Fahrzeugs 12 dazu motiviert, es zur ausgewählten Einrichtung 82 im System zu bringen. Die Außer-Betrieb-Benachrichtigung könnte beispielsweise einen Anreiz bieten, bei dem der Benutzer Guthaben erhält, dass für seine aktuelle Reservierung und/oder eine künftige Reservierung verwendet werden kann (z. B. eine 50 % Kostenreduzierung, zusätzliche zwei (2) Stunden zugeteilter Reservierungszeit usw.). Solche Anreize können beispielsweise hilfreich sein, um Benutzer mit zugeteilten Reservierungsendzeiten anzureizen, wenn diese an die Außer-Betrieb-Zeitfenster im Fahrzeug-Reservierungskalender angrenzen. Wobei der Benutzer bei der ausgewählten Einrichtung 82 außerdem ein anderes Fahrzeug 12 zur Komplettierung seiner Reservierung empfangen kann. In bestimmten Fällen kann der Zielanreiz auch dem aktuellen Benutzer erlauben, eine der Einrichtungen 82 im System zu wählen, um dem Benutzer die Möglichkeit der Wahl zu geben.
7 ist ein algorithmisches Flussdiagramm für eine exemplarische Ausführungsform des CarShare-App-Algorithmus 800 für die CarShare-App 86 wie oben erörtert, die in eine Ausführungsform des hierin vorgestellten Systems und Verfahrens einbezogen werden kann. Einer oder mehrere Aspekte des Algorithmus 800 können durch die Implementierung des mobilen Prozessors der mobilen Computervorrichtung 57 abgeschlossen werden, der ein oder mehrere ausführbare Codesegmente/Anweisungen (Software-Algorithmen) im mobilen Speicher 61 enthalten und von einem Benutzer ausgeführt werden kann, der den Algorithmus 800 durch die Benutzeroberfläche 59 bedienen kann. Einer oder mehrere Aspekte des Verfahrens 800 können außerdem von der Ferneinheit 54 des Rechenzentrums 18 implementiert werden, was eine oder mehrere ausführbare Codesegmente/Anweisungen (Software-Algorithmen) enthalten kann, die in Datenbank 56 integriert sind und durch die mobile Vorrichtung 57 ausgeführt werden können (das über einen oder mehrere Satelliten 62 übertragen werden kann). Es sollte ferner einzusehen sein, dass Schritte dieses algorithmischen Ablaufes eine Reihenfolge enthalten können, die wie hierin beschrieben nicht dargestellt ist. Darüber hinaus können andere algorithmische Schritte bevor oder nachdem oder zwischen einem der hierin aufgezeigten Schritte integriert werden.
Wie gezeigt, beginnt Algorithmus 800 bei Schritt 801, der auftreten kann, wenn ein Benutzer der mobilen Vorrichtung 57 auf die CarShare-App 86 vom mobilen Speicher 61 aus über eine von einer Anzahl allgemein bekannter Methoden zugreift. Im Schritt 810 wird die CarShare-App 86 zu einer bidirektionalen Verbindung mit der Ferneinheit 54 befähigt (d. h. per Datenübertragungen, die über das drahtlose Kommunikationssystem 14 gesendet werden). Im Schritt 820 erlaubt die CarShare-App 86 die Erzeugung einer Fahrzeug-Reservierung, die im Wesentlichen ein Fahrzeug 12 reserviert (das für den Betrieb im Carsharing-System 10 konfiguriert ist), das sich an einem bestimmten Stellplatz befindet und für eine bestimmte Zeitdauer (wie oben erörtert) verfügbar ist. Im Schritt 830 erzeugt die CarShare-App 86 die Fahrzeug-Reservierung. In diesem Schritt kann die CarShare-App 86 auch die Fahrzeug-Reservierung zur Ferneinheit übertragen. Eine solche Übertragung kann zum Zeitpunkt der Fahrzeug-Reservierung oder an einem Zeitpunkt danach erfolgen.
Wie durch die gestrichelte Linie angezeigt, erfolgen Schritte 840 bis 870 zu dem Zeitpunkt nach Beginn der Fahrzeug-Reservierung. Im Schritt 840 empfängt und zeigt die CarShare-App 86 eine Autorisierungsbenachrichtigung (d. h. über die Benutzeroberfläche 59). Es sollte beachtet werden, dass dieser Schritt erst nach Abschluss der eindeutigen Paarung erfolgen kann, beispielsweise nachdem die digitale Signatur und verschlüsselten öffentlichen Schlüssel validiert sind (wie oben erörtert). Falls diese Validierung nicht erfolgt, kann Algorithmus 800 aus Sicherheitsgründen einfach zu Schritt 802 gehen und die Vorgänge abschließen. In einem solchen Fall kann Algorithmus 800 für Schutzzwecke auch bestimmte Funktionen der CarShare-App 86 deaktivieren (d. h. den Benutzer für die weitere Verwendung der CarShare-App 86 sperren). In Schritt 850 beginnt die CarShare-App 86 die Fahrzeug-Reservierung (wie oben erörtert). In Schritt 860 wird die CarShare-App 86 für den Zugriff auf die Fahrzeugsysteme sowie den Betrieb des Fahrzeugs freigegeben (wie oben erörtert). Solche Freigabe kann von der Ferneinheit 54 befohlen werden. Bei Schritt 870 wird die CarShare-App 86 für den Zugriff auf die Fahrzeugsysteme sowie den Betrieb des Fahrzeugs deaktiviert (wie oben erörtert). Bei Schritt 802 vollendet die CarShare-App 86 ihre Backend-Operationen, um das aktuelle Nutzungsschema zu beenden.
Schritte 880 bis 890 können gleichzeitig mit einem der vorangehenden Schritte oder jederzeit vor oder nach solchen Schritten auftreten. Bei Schritt 880 empfängt und zeigt die CarShare-App 86 eine Statusbenachrichtigung „außer Betrieb“ oder einen ähnlichen Status (d. h. über Benutzeroberfläche 59), wie weiter oben erörtert. Wie aus oben stehendem gefolgert werden kann, kann dieser Status automatisch einen oder mehrere Aspekte der GUIs der CarShare-App 86 (auf Benutzeroberfläche 59 angezeigt) verändern. Beim optionalen Schritt 881 kann die CarShare-App 86 außerdem eines oder mehrere Anreizangebote im Zusammenhang mit der Statusbenachrichtigung „außer Betrieb“ empfangen und anzeigen, wie oben erörtert. Bei Schritt 890 empfängt und zeigt die CarShare-App 86 eine Statusbenachrichtigung „für Reservierung verfügbar“ oder einen ähnlichen Status (d. h. über Benutzeroberfläche 59). Wie aus oben stehendem gefolgert werden kann, kann dieser Status automatisch die ausgeführte GUI-Version des Reservierungskalenders modifizieren, die zur mobilen Vorrichtung 57 übertragen und auf der Benutzeroberfläche 59 angezeigt wird.
Eine schrittweise Diskussion eines Verfahrens zur Verwaltung der Routinewartung eines Fahrzeugs 12, das in einem Carsharing-System einbezogen ist. In einem ersten Schritt empfängt VCP 24 eine oder mehrere Kommunikationen vom Fahrzeugsystem. Als nächstes erzeugt VCP 24 in einem zweiten Schritt eine Routinewartungs-Meldung, die aus der Kommunikation mit dem Fahrzeugsystem abgeleitet ist. In einem dritten Schritt überträgt die VCP 24 die Routinewartungs-Meldung zur Ferneinheit. In einem vierten Schritt empfängt die Ferneinheit 54 die Routinewartungs-Meldung. In einem fünften Schritt implementiert die Ferneinheit 54 ihre Backend-Funktionen zur Prüfung und Analyse der Routinewartungs-Meldung. In einem sechsten Schritt prognostiziert die Ferneinheit 54 zukünftige Wartungen des Fahrzeugs 12 aus der Analyse der Routinewartungs-Meldung. In einem letzten Schritt modifiziert die Ferneinheit 54 den Fahrzeug-Registrierungsstatus in der Datenbank, um die Wartungsarbeiten zu ermöglichen. Es sollte beachtet werden, dass Aspekte aller Schritte weiter oben ausführlicher erörtert sind.
Die hierin offenbarten Prozesse, Verfahren oder Algorithmen können von einer Verarbeitungsvorrichtung, einer Steuerung oder einem Computer, der jede vorhandene programmierbare elektronische Steuereinheit oder eine dedizierte elektronische Steuereinheit beinhalten kann, bereitgestellt und/oder implementiert werden. Desgleichen können die Prozesse, Verfahren oder Algorithmen als Daten oder ausführbare Anweisungen durch eine Steuerung oder einen Computer in vielfältiger Weise gespeichert werden, darunter ohne Einschränkung die dauerhafte Speicherung auf nicht beschreibbaren Speichermedien, wie einem ROM, und als änderbare Information auf beschreibbaren Speichermedien, wie Disketten, Magnetbändern, CDs, RAM sowie anderen magnetischen und optischen Medien. Die Prozesse, Verfahren oder Algorithmen können auch in einem softwareausführbaren Objekt implementiert werden. Alternativ können die Prozesse, Verfahren oder Algorithmen ganz oder teilweise mit geeigneten Hardwarekomponenten, wie beispielsweise anwendungsspezifischen integrierten Schaltungen (ASICs), feldprogrammierbaren Gate Arrays (FPGAs), Zustandsmaschinen, Steuerungen oder anderen Hardwarekomponenten oder Vorrichtungen oder einer Kombination von Hardware, Software und Firmwarekomponenten verkörpert werden. Die besagten exemplarischen Vorrichtungen können sich als Teil eines Fahrzeugcomputersystems On-Bord oder Off-Board befinden und eine Fernkommunikation mit Vorrichtungen an einem oder mehreren Fahrzeugen durchführen.
Obgleich exemplarische Ausführungsformen vorstehend beschrieben sind, sollen diese Ausführungsformen in keiner Weise alle möglichen Formen beschreiben, die die Ansprüche in sich begreifen. Vielmehr dienen die in der Spezifikation verwendeten Worte der Beschreibung und nicht der Einschränkung und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Erfindungsgedanken und Umfang der Offenbarung abzuweichen. Wie zuvor beschrieben, können die Merkmale verschiedener Ausführungsformen kombiniert werden, um weitere exemplarische Aspekte der vorliegenden Offenbarung auszubilden, die nicht explizit beschrieben oder veranschaulicht werden. Obgleich verschiedene Ausführungsformen beschrieben worden sein könnten, um Vorteile zu bieten oder anderen Ausführungsformen oder Implementierungen des Standes der Technik in Bezug auf eine oder mehrere gewünschte Merkmale vorgezogen zu werden, werden Fachleute auf dem Gebiet erkennen, dass eine oder mehrere Merkmale oder Charakteristika beeinträchtigt werden können, um die gewünschten Gesamtsystemeigenschaften zu erreichen, die von der spezifischen Anwendung und Implementierung abhängen. Diese Eigenschaften können unter anderem Kosten, Festigkeit, Haltbarkeit, Lebenszykluskosten, Marktfähigkeit, Aussehen, Verpackung, Größe, Gebrauchstauglichkeit, Gewicht, Herstellbarkeit, Montagefreundlichkeit usw., beinhalten. Daher liegen Ausführungsformen, die im Vergleich zu anderen Ausführungsformen oder Implementierungen des Standes der Technik als weniger wünschenswert in Bezug auf eine oder mehrere Merkmale beschrieben sind, nicht außerhalb des Umfangs der Offenbarung und können für bestimmte Anwendungen wünschenswert sein.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 20160203661 A1 [0035]

Claims

System zur Verwaltung der Routinewartung eines Fahrzeugs, das in ein Carsharing-System einbezogen ist, das Wartungs-Managementsystem umfassend: ein Fahrzeug, umfassend mindestens einen Fahrzeugsensor; eine Fahrzeugkommunikationsplattform (VCP), die sich innerhalb des Fahrzeugs befindet, worin die VCP dazu konfiguriert ist, mit dem Fahrzeugsensor zu kommunizieren und die VCP konfiguriert ist, um eine Datenübertragung zu erzeugen und zu übermitteln; eine Ferneinheit, umfassend mindestens eine Datenbank und die Ferneinheit konfiguriert, um die VCP-Datenübertragung zu empfangen; worin die VCP mit dem Fahrzeugsensor zusammenarbeitet, um mindestens eine Routinewartungs-Meldung zu erzeugen und die VCP anschließend die Routinewartungs-Meldung zur Ferneinheit zu überträgt; und worin nach Prüfung und Analyse der Routinewartungs-Meldung die Ferneinheit die zukünftige Wartung des Fahrzeugs vorhersagen und den Registrierungsstatus des Fahrzeugs in der Datenbank anpassen wird, um eine Wartung zu ermöglichen.
Wartungs-Managementsystem nach Anspruch 1, weiterhin umfassend: eine Wartungseinrichtung zur Bereitstellung von Fahrzeug-Routine-Wartungsdiensten; und worin die Ferneinheit eine Wartungsbenachrichtigung an die Wartungseinrichtung generiert und überträgt, um die Wartungsarbeiten in der Wartungseinrichtung einzuplanen.
Wartungs-Managementsystem nach Anspruch 1, weiterhin umfassend: eine(n) GNSS-Chipsatz/Komponente; eine Vielzahl von Wartungseinrichtungen, von denen jede Fahrzeug-Routine-Wartungsdienste bereitstellt; worin die VCP mit dem GNSS-Chipsatz/Komponente zusammenarbeitet, um mindestens eine Nachricht zum Fahrzeugstandort zu generieren, die VCP anschließend die Nachricht der Fahrzeugposition zur Ferneinheit überträgt; und worin nach Prüfung und Analyse der Nachricht zum Fahrzeugstandort und der Routinewartungs-Meldung die Ferneinheit eine von den mehreren Wartungseinrichtungen auswählt, eine Wartungsbenachrichtigung erzeugt und die Wartungsbenachrichtigung an die ausgewählte Wartungseinrichtung zur Einplanung der Wartungsarbeiten bei der ausgewählten Wartungseinrichtung überträgt.
Wartungs-Managementsystem nach Anspruch 1, worin die Routinewartungs-Meldung Informationen zur verbleibenden Ölnutzungsdauer/Ölmenge, Fehlerinformationen des Ölfilters, Komponenten-Fehlerinformationen, Selbstdiagnose-Informationen, Kilometerstand oder eine Kombination davon umfasst.
Wartungs-Managementsystem nach Anspruch 1, worin die Wartungsbenachrichtigung Informationen zur Fahrzeug-Öllebensdauer, dem Zustand des Ölfilters im Fahrzeug, dem Auslösen von Störungsanzeigeleuchten, Kilometerstand, Fahrzeugbauteilversagen, Selbstdiagnose-Meldungen oder eine Kombination davon umfasst.
Verfahren zur Verwaltung der Routinewartung eines Fahrzeugs, das in ein Carsharing-System einbezogen ist, das Wartungs-Managementverfahren umfassend: (a) das Bereitstellen eines Fahrzeugs, umfassend mindestens einen Fahrzeugsensor; (b) das Bereitstellen einer Fahrzeugkommunikationsplattform (VCP), die sich innerhalb des Fahrzeugs befindet, worin die VCP dazu konfiguriert ist, mit dem Fahrzeugsensor zu kommunizieren und die VCP konfiguriert ist, um mindestens eine Datenübertragung zu erzeugen und zu übermitteln; (c) das Bereitstellen einer Ferneinheit, umfassend eine Datenbank und die Ferneinheit konfiguriert, um die VCP-Datenübertragung zu empfangen; (d) das Empfangen mindestens einer Kommunikation vom Fahrzeugsensor an der VCP; (e) das Erzeugen mindestens einer Routinewartungs-Meldung über die VCP, abgeleitet aus der Kommunikation vom Fahrzeugsensor; (f) das Übertragen der Routinewartungs-Meldung zur Ferneinheit über die VCP; (g) das Empfangen der Routinewartungs-Meldung an der Ferneinheit; (h) das Implementieren einer Backend-Funktion zur Prüfung und Analyse der Routinewartungs-Meldung über die Ferneinheit; (i) das Vorhersagen der zukünftigen Wartung des Fahrzeugs aus der Analyse der Routinewartungs-Meldung über die Ferneinheit; und. (j) das Modifizieren des Fahrzeug-Registrierungsstatus in der Datenbank über die Ferneinheit, um die Wartungsarbeiten zu ermöglichen.
Wartungs-Managementverfahren nach Anspruch 6, das Verfahren ferner umfassend: (k) das Bereitstellen einer Wartungseinrichtung zur Bereitstellung von Fahrzeug-Routine-Wartungsdiensten; (1) das Erzeugen einer Wartungs-Benachrichtigung über die Ferneinheit, abgeleitet von der Analyse der Wartungsmeldung; (m) das Übertragen der Wartungs-Benachrichtigung zur Wartungseinrichtung über die Ferneinheit; und (n) das Einplanen der Wartungsarbeiten bei der Wartungseinrichtung über die Ferneinheit.
Wartungs-Managementverfahren nach Anspruch 6, das Verfahren ferner umfassend: (k) das Bereitstellen einer Vielzahl von Wartungseinrichtungen, von denen jede Fahrzeug-Routine-Wartungsdienste bereitstellt; (1) das Bereitstellen eines im Fahrzeug befindlichen GNSS-Chipsatz/Komponente, der GNSS-Chipsatz/Komponente dazu konfiguriert, um Informationen zum Fahrzeugstandort bereitzustellen; (m) das Erzeugen einer Wartungs-Benachrichtigung über die Ferneinheit, abgeleitet von der Analyse der Wartungsmeldung und der Information zum Fahrzeugstandort; (n) das Auswählen aus der Vielzahl der Wartungseinrichtungen über die Ferneinheit; (o) das Übertragen der Wartungs-Benachrichtigung zur gewählten Wartungseinrichtung über die Ferneinheit; (p) das Einplanen der Wartungsarbeiten bei der gewählten Wartungseinrichtung über die Ferneinheit.
Wartungs-Managementverfahren nach Anspruch 6, das Verfahren ferner umfassend: (m) das Bereitstellen einer mobilen Computervorrichtung, umfassend eine CarShare-App; (n) das Erzeugen einer Außer-Betrieb-Benachrichtigung über die Ferneinheit; (o) das Übertragen der Außer-Betrieb-Benachrichtigung über die Ferneinheit an die CarShare-App; und (p) das Anzeigen der Außer-Betrieb-Benachrichtigung über die CarShare-App.
Verfahren zur Verwaltung der Routinewartung eines Fahrzeugs, das in ein Carsharing-System einbezogen ist, das Wartungs-Managementverfahren umfassend: (a) das Bereitstellen eines Fahrzeugs, umfassend ein Öl-Überwachungsmodul (OMM); (b) das Bereitstellen einer Fahrzeugkommunikationsplattform (VCP), die sich innerhalb des Fahrzeugs befindet, worin die VCP dazu konfiguriert ist, mit dem OMM zu kommunizieren und die VCP konfiguriert ist, um mindestens eine Datenübertragung zu erzeugen und zu übermitteln; (c) das Bereitstellen einer Ferneinheit, umfassend eine Datenbank und die Ferneinheit konfiguriert, um die VCP-Datenübertragung zu empfangen; (d) das Bereitstellen einer Wartungseinrichtung zur Bereitstellung von Fahrzeug-Routine-Wartungsdiensten; (e) das Empfangen einer Fahrzeug-Ölinformations-Kommunikation vom OMM an der VCP; (f) das Erzeugen mindestens einer Routinewartungs-Meldung über die VCP aus den Fahrzeug-Ölinformationen; (g) das Übertragen der Routinewartungs-Meldung zur Ferneinheit über die VCP; (h) das Empfangen der Routinewartungs-Meldung an der Ferneinheit; (i) das Implementieren einer Backend-Funktion zur Prüfung und Analyse der Routinewartungs-Meldung über die Ferneinheit; (j) das Vorhersagen der zukünftigen Wartung des Fahrzeugs aus der Analyse der Routinewartungs-Meldung über die Ferneinheit; (k) das Modifizieren des Fahrzeug-Registrierungsstatus in der Datenbank über die Ferneinheit, um die Wartungsarbeiten zu ermöglichen; (1) das Erzeugen einer Wartungs-Benachrichtigung über die Ferneinheit, abgeleitet von der Analyse der Wartungsmeldung; (m) das Übertragen der Wartungs-Benachrichtigung zur Wartungseinrichtung über die Ferneinheit; und (n) das Einplanen der Wartungsarbeiten bei der Wartungseinrichtung über die Ferneinheit.