-
Privatfahrzeuge stellen allgemein eine flexible Art der Fortbewegung für Pendler und Reisende in städtischen Umgebungen bereit. Der Besitz und die Unterhaltung eines Privatfahrzeugs können jedoch unter Einbeziehung der Kosten für das Fahrzeug, Kraftstoff, Versicherung und Instandhaltung teuer sein. Darüber hinaus erhöhen Privatfahrzeuge Stauaufkommen und Umweltverschmutzung in städtischen Umgebungen. Öffentliche Verkehrsmittel, darunter Busse, Züge, U-Bahnen usw., die nach einem festen Fahrplan betrieben werden, stellen kostengünstigere Alternativen für Pendler dar. Gemeinschaftsbeförderungsalternativen reduzieren Stadtstaus und verbessern die Luftqualität. Ein Pendler hat jedoch möglicherweise weniger Flexibilität in Bezug auf Abfahrts- und Ankunftszeiten sowie Abfahrts- und Ankunftsorte.
-
Eine andere Gemeinschaftsbeförderungsalternative, die ein gutes Maß an Flexibilität, Kosten, Anwenderfreundlichkeit und Umweltbelastung bietet, ist ein Gemeinschaftsfahrzeugsystem. Dabei wird eine Flotte von Fahrzeugen über ein Betriebsgebiet (z. B. eine Stadt) verteilt und ein Nutzer kann ein beliebiges Fahrzeug der Flotte für einen kurzen Zeitraum (z. B. ein paar Stunden am Tag) mieten. Sobald ein Nutzerkonto eingerichtet ist, kann der Nutzer ein Fahrzeug, das er basierend auf seinem Standort in dem Betriebsgebiet mieten möchte, identifizieren und das Fahrzeug ohne weitere Formalitäten mieten. Der Nutzer kann das Fahrzeug dann zum Ausgangsort zurückbringen oder das Fahrzeug an einem alternativen Ort abliefern, je nach Belieben des Nutzers. Das Gemeinschaftsfahrzeugsystem reduziert die Pendelkosten des Nutzers und reduziert gleichzeitig Stadtstaus und Umweltverschmutzung. Zugleich erhöht die Möglichkeit, das Fahrzeug zu einer vom Nutzer bestimmten Zeit an einem vom Nutzer bestimmten Ort abzuholen und abzuliefern, die Flexibilität des Nutzers.
-
Gemeinschaftsfahrzeugsysteme können jedoch Probleme hinsichtlich Stauaufkommen und Luftqualität aufweisen. Wenn das Gemeinschaftsfahrzeug beispielsweise zu Zeiten und an Orten mit hohem Verkehrsaufkommen, Einbahnverkehrsbeschränkungen usw. in städtischen Umgebungen verwendet wird, kann das Gemeinschaftsfahrzeug selbst zum Stauaufkommen und zur Umweltverschmutzung beitragen. Darüber hinaus muss möglicherweise eine intermittierende Umstellung von Gemeinschaftsfahrzeugen durchgeführt werden, um sicherzustellen, dass die Fahrzeuge gleichmäßig über eine Betriebszone verteilt sind und nicht nur in einem Gebiet angehäuft sind. Mit anderen Worten muss die Fahrzeugverteilung möglicherweise ausgeglichen werden. Das Ausgleichen kann dazu führen, dass Fahrzeuge über relativ lange Strecken gefahren werden müssen, was zu den Emissionen beiträgt.
-
1 ist ein Blockdiagramm eines beispielhaften Gemeinschaftsfahrzeugsystems.
-
2 ist eine detaillierte Darstellung einer Implementierung des Systems von 1.
-
3 ist ein Prozessverlaufdiagramm, das einen beispielhaften Prozess zum Wählen eines Kraftmaschinenmodus für ein Gemeinschaftsfahrzeug darstellt.
-
4 ist ein Prozessverlaufdiagramm zum Betrieb eines Gemeinschaftsfahrzeugs mit Kraftmaschinenmodusempfehlungen.
-
Ein Fahrzeugbetriebsmodus, z. B. Elektromotormodus vs. Brennkraftmaschinenmodus, kann bei einem Gemeinschaftsfahrzeugsystem basierend auf Emissionen, Stau und Ausgleichsbedarfen eingestellt werden. Der Betrieb des Gemeinschaftsfahrzeugs kann so gesteuert werden, dass sich keine oder minimale Auswirkungen auf die Fahrzeugnutzung eines Pendlers ergeben, während eine Reduzierung von Emissionen und Staus gestattet wird. Insbesondere kann ein Fahrzeugmodus automatisch eingestellt werden, z. B. über einen zentralen Server, eine zentrale Applikation oder einen Administrator, die z. B. über ein WAN (Wide Area Network), darunter Mechanismen wie ein Mobilfunknetz, WiFi, ein WAN wie das Internet etc. mit jedem Fahrzeug in der Flotte des Gemeinschaftsfahrzeugsystems kommunikativ gekoppelt sind.
-
Einstellungen eines Fahrzeugmodus können auf verschiedenen Faktoren beruhen, darunter das Stauaufkommen und das Emissionsmaß in einer Betriebszone des Fahrzeugs. Darüber hinaus kann der Modus basierend auf einem geschätzten oder vom Nutzer angegebenen Zielort, z. B. basierend auf einem Nutzerprofil, das allgemein eine Fahrthistorie des Nutzers umfasst und anzeigt, wohin das vom Nutzer gemietete Fahrzeug fährt oder wahrscheinlich fährt, wie lange das Fahrzeug wahrscheinlich gefahren werden wird und ob eine weitere Umstellung des Fahrzeugs zu Ausgleichszwecken erforderlich sein wird, nachdem das Fahrzeug vom Nutzer abgestellt worden ist, eingestellt werden. Somit kann das Fahrzeug, wenn das Fahrzeug in eine Betriebszone mit bekanntermaßen hoher Verkehrsdichte (z. B. in die Stadt) gefahren wird, in Erwartung von mehr Stop-and-Go-Verkehr automatisch in einen Elektromodus geschaltet werden. Vergleichsweise kann das Fahrzeug, wenn das Fahrzeug in eine Betriebszone mit bekanntermaßen geringer Verkehrsdichte (z. B. in einen Vorort) gefahren wird, automatisch in einen Kraftmaschinenmodus geschaltet werden, während es sich in der Zone mit geringer Verkehrsdichte befindet, und zwar unabhängig von Anforderungen bezüglich des Fahrzeugbetriebsmodus durch den Nutzer. Beispielsweise kann ein Fahrer eine anfängliche Anforderung für den Fahrzeugbetriebsmodus stellen, jedoch kann ein solcher Modus durch eine/n zentrale/n Managementserver/-applikation basierend auf den verschiedenen hier beschriebenen Faktoren übersteuert werden.
-
Der Betriebsmodus kann ferner darauf basierend, wann und wo das Fahrzeug abgestellt wurde oder werden wird, bestimmt werden. Ein Abstellort kann basierend auf einer Fahrthistorie eines Nutzers und/oder basierend auf nutzerspezifischen Daten vorhergesagt werden. Beispielsweise kann, wenn bekannt ist, dass ein bestimmter Nutzer das Fahrzeug tendenziell innerhalb der Stadt für 30 Minuten nutzt und das Fahrzeug in einem Stadtkern zurückgibt, wo die Nachfrage nach dem Gemeinschaftsfahrzeug höher ist, bestimmt werden, dass das Fahrzeug wahrscheinlich kurz nach der Rückgabe durch den Nutzer gemietet wird, wodurch wenig Zeit zur Fahrzeugaufladung bleibt. Deshalb wird das Fahrzeug aufgrund der begrenzten verfügbaren Zeit zur nachfolgenden Fahrzeugaufladung trotz Betrieb in der Region mit hoher Verkehrsdichte möglicherweise nicht im Elektromodus (oder weniger in dem Elektromodus als normalerweise der Fall wäre) betrieben. In einem alternativen Beispiel kann bekannt sein, dass ein bestimmter Nutzer das Fahrzeug tendenziell für 30 Minuten nutzt und das Fahrzeug in dem Vorort zurückgibt, wo die Nachfrage nach dem Gemeinschaftsfahrzeug geringer ist, jedoch mehr Zeit zum Laden ist. Des Weiteren kann nach einer Zeitdauer der Fahrzeugrückgabe in dem Vorort eine Umstellung des Fahrzeugs erforderlich sein, so dass zur Befriedigung der Nachfrage genügend Fahrzeuge im Stadtkern zur Verfügung stehen. Deshalb wird das Fahrzeug bei Betrieb in der Region mit hoher Verkehrsdichte möglicherweise im Elektromodus betrieben und bei Betrieb in der Region mit niedriger Verkehrsdichte in den Kraftmaschinenmodus geschaltet. Das Fahrzeug kann auch in dem Vorort geladen werden, bevor es zum Ausgleich in den Stadtkern umgestellt wird, wodurch verbessertes Ausgleichen ermöglicht wird.
-
In einem anderen Beispiel kann der Fahrzeugantriebsmodus (z. B. Kraftmaschine, Hybrid, Elektro usw.) nicht nur basierend auf dem Profil des gegenwärtigen Nutzers und der Reservierungsdaten ausgewählt werden, sondern auch basierend auf zukünftigen Reservierungen für dieses bestimmte Fahrzeug und den Reservierungsanforderungen und Nutzerprofilen zukünftiger Nutzer. Des Weiteren kann die Auswahl des Antriebsmodus auf verschiedenen Fahrzeugbetriebsbedingungen in Echtzeit, wie z. B. Ladezustand usw., basieren, jedoch können die Schwellenwerte für die Durchführung einer Änderung des Betriebsmodus für verschiedene Nutzer basierend auf gezahlten Mietgebühren, Nutzerprofilen usw. unterschiedlich eingestellt werden. Somit kann das Fahrzeug, während es bei einem gegebenen Schwellenladezustand für einen gegebenen Satz von Bedingungen für einen ersten Nutzer von Elektro auf Hybrid oder von Hybrid auf rein Elektro wechselt, für einen zweiten anderen Nutzer bei denselben Bedingungen bei einem unterschiedlichen Schwellenwert wechseln. Solche Varianzen können Nutzeranforderungen nach unterschiedlicher Leistung von demselben Fahrzeug besser Rechnung tragen.
-
In einem anderen Beispiel kann das Fahrzeug automatisch die Wahl des Antriebsmodus basierend auf Ausgleichinformationen einstellen, die von einem zentralen Ausgleichssystem, das die Fahrzeugflotte überwacht und mit einer erwünschten Fahrzeugverteilung über die Betriebsregion der Flotte vergleicht, an das Fahrzeugsteuersystem ausgegeben werden. Beispielsweise kann die Fahrzeugsteuerung, obwohl ein Nutzer Elektrobetrieb wünschen kann und Elektrobetrieb auch mit dem gegebenen Ladezustand machbar wäre, basierend auf Anweisungen vom zentralen System, dem bekannt ist, dass das Fahrzeug von einer erwünschten Ausgleichsposition wegsteuert und somit zurückgebracht werden muss und ferner weil sich das Fahrzeug in einer Richtung mit geringer Ladestationsdichte fortbewegt (was bedeutet, dass ein Ausgleichen einen Verbrauch von mehr elektrischer Ladung erfordern wird, als verfügbar ist, und dass es wünschenswert ist, den Elektrobetrieb für einen Teil der Rückkehr/des Ausgleichstrips, der in einer Region der Stadt mit höherem Bedarf oder Anreiz für Elektrobetrieb stattfinden wird, aufzusparen), auf Hybridbetrieb wechseln.
-
Nun mit Bezug auf die Zeichnungen ist 1 ein Blockdiagramm eines beispielhaften Gemeinschaftsfahrzeugsystems 100, das mindestens ein Fahrzeug 101, und in der Regel mehrere Fahrzeuge 101, z. B. ein Gemeinschaftsfahrzeug, wie z. B. ein Motorrad, einen Pkw, einen Großraumwagen etc., umfasst. Jedes Fahrzeug 101 umfasst einen Computer 105, der mit einem Netzwerk 120 kommunikativ gekoppelt ist. Das Fahrzeug 101 kann ferner eine GPS(Global Positioning System)-Vorrichtung 16 oder dergleichen in einem Fahrzeug 101 umfassen. Die Fahrzeuge 101 können Straßen mit Fahrzeugen 102 teilen, die nicht Teil des Gemeinschaftsfahrzeugsystems 100 sind, d.h. die nicht über einen Server 125 zur gemeinsamen Nutzung zur Verfügung stehen.
-
Ein Computer 105 des Fahrzeugs 101 kann zur Kommunikation auf einem CAN(Controller Area Network)-Bus oder dergleichen, und/oder anderen verdrahteten oder drahtlosen Protokollen, z. B. Bluetooth usw., ausgelegt sein, d.h. der Computer kann über verschiedene Mechanismen, die in einem Fahrzeug 101 vorgesehen sein können, kommunizieren und kann entsprechend Daten von Fahrzeugsensoren, Kommunikation über das Netzwerk 120, z. B. vom Server 125, usw. empfangen. Der Computer 105 kann auch eine Verbindung zu einem On-Board-Diagnose-Stecker (OBD II) aufweisen. Über den CAN-Bus, OBD II und/oder andere verdrahtete oder drahtlose Mechanismen. Des Weiteren kann ein Navigationssystem 106 in dem Fahrzeug 101 vorgesehen und kommunikativ mit dem Computer 105 zur Bereitstellung von Standortdaten, z. B. über ein GPS (Global Positioning System) oder dergleichen, gekoppelt sein. Der Computer 105 kann dem Server 125 über ein Netzwerk 120 Daten, die Standortinformationen des Fahrzeugs 101 umfassen, bereitstellen.
-
Das Netzwerk 120 repräsentiert einen oder mehrere Mechanismen, durch die ein Fahrzeugcomputer 105 mit einem entfernten Server 125 und/oder einer Nutzervorrichtung 150 kommunizieren kann. Dementsprechend kann das Netzwerk 120 einer oder mehrere verschiedener verdrahteter oder drahtloser Kommunikationsmechanismen sein, darunter eine beliebige gewünschte Kombination von verdrahteten (z.B. Kabel- und Faser-) und/oder drahtlosen (z.B. Mobilfunk-, drahtlos-, Satelliten-, Mikrowellen- und Hochfrequenz-)Kommunikationsmechanismen und eine beliebige gewünschte Netzwerktopologie (oder -topologien, wenn mehrere Kommunikationsmechanismen verwendet werden). Beispielhafte Kommunikationsnetzwerke umfassen drahtlose Kommunikationsnetzwerke (die z.B. Bluetooth, IEEE 802.101 usw. verwenden), lokale Netzwerke (LAN) und/oder großflächige Netzwerke (WAN), einschließlich des Internets, die Datenkommunikationsdienste bereitstellen.
-
Der Server 125 kann ein oder mehrere Computerserver sein, die jeweils allgemein mindestens einen Prozessor und mindestens einen Speicher umfassen, wobei der Speicher durch den Prozessor ausführbare Anweisungen speichert, darunter Anweisungen zum Ausführen verschiedener hier beschriebener Schritte und Prozesse. Der Server 125 kann den Datenspeicher 130 zum Speichern von aus einem oder mehreren Fahrzeugen 101 empfangenen Daten umfassen oder kommunikativ damit gekoppelt sein.
-
Eine Nutzervorrichtung 150 kann eine beliebige von vielfältigen Datenverarbeitungsvorrichtungen sein, die einen Prozessor und einen Speicher sowie Kommunikationsfähigkeiten umfassen. Beispielsweise kann die Nutzervorrichtung 150 ein tragbarer Computer, Tablet-Computer, Smartphone usw. sein, mit Fähigkeiten zur drahtlosen Kommunikation unter Verwendung von IEEE 802.101, Bluetooth und/oder Mobilfunk-Kommunikationsprotokollen. Ferner kann die Nutzervorrichtung 150 solche Kommunikationsfähigkeiten zur Kommunikation über das Netzwerk 125 einschließlich mit einem Fahrzeugcomputer 105 verwenden. Eine Nutzervorrichtung 150 könnte mit einem Computer 105 oder anderen Mechanismen des Fahrzeugs 101, wie etwa einem Netzwerk im Fahrzeug 101, über bekannte Protokolle wie Bluetooth usw. kommunizieren. Ferner könnte eine Nutzervorrichtung 150 dazu verwendet werden, dem Computer 105 eine Mensch-Maschine-Schnittstelle (HMI) bereitzustellen.
-
2 ist eine detaillierte Darstellung einer Implementierung des Systems von 1 in einem geographischen Gebiet 200. Wie zu sehen ist, kann das Gebiet 200 in mehrere Zonen, z. B. Zone A und Zone B, wie in 2 zu sehen ist, aufgeteilt werden. Fahrzeuge 101 innerhalb jeder der Zonen, d.h. in dem geographischen Gebiet 200 können mit dem Server 125, z. B. über das Netzwerk 120 (wie in 1 zu sehen ist), kommunizieren. Ferner können Fahrzeuge 102, die nicht Teil des Systems 100 sind, wie oben erwähnt, in dem geographischen Gebiet 200 umfasst sein. Fahrzeuge 101 in dem geographischen Gebiet 200 können zur Verwendung durch einen Teilnehmer bei dem Gemeinschaftsfahrzeugsystem 100 zur Verfügung stehen oder sich in Gebrauch befinden. Beispielsweise können Fahrzeuge 101, die in 2 durch unschraffierte Kästchen dargestellt sind, als zur Verwendung verfügbar angesehen werden, wohingegen Fahrzeuge 101, die durch schraffierte Kästchen dargestellt werden, als in Gebrauch befindlich angesehen werden. Wie im weiteren Verlauf erwähnt, kann der Server 125 bestimmen, nicht in Gebrauch befindliche Fahrzeuge 101 von einem ersten Standort zu einem zweiten Standort umzustellen, z. B. könnte der Server 125 entscheiden, ein Fahrzeug 101 aus der Zone A in die Zone B umzustellen, da eine Anzahl an Fahrzeugen 101 in der Zone A höher ist. Darüber hinaus könnte sich ein Fahrzeug 101 von der Zone B in die Zone A fortbewegen, wodurch ein Ausgleichen, sobald ein Nutzer mit diesem Fahrzeug 101 fertig ist, gerechtfertigt wird. Im Rahmen einer solchen Bewegung und/oder eines solchen Ausgleichs des Fahrzeugs 100 können Kraftmaschinenmodi gewechselt werden, wie im weiteren Verlauf beschrieben.
-
3 ist ein Prozessverlaufdiagramm, das einen beispielhaften Prozess 300 zum Wählen eines Kraftmaschinenmodus für ein Gemeinschaftsfahrzeug darstellt. Der Prozess 300 wird laut Beschreibung von dem Server 125 in Kommunikation mit einem Computer 105 in einem Fahrzeug 101 durchgeführt, als Alternative oder zusätzlich dazu könnte jedoch der gesamte Prozess 300 oder ein Teil davon in einem Computer 105 eines Fahrzeugs 101 ausgeführt werden.
-
In jedem Fall beginnt der Prozess 300 in einem Block 305, in dem der Server 125 ein Nutzerprofil, z. B. aus einem Datenspeicher 130, eines Nutzers eines Fahrzeugs 101, das in Betrieb ist oder in Betrieb genommen wird, abruft. Das Nutzerprofil kann Abstell- und/oder Abholorte, die von einem Nutzer bereits genutzt wurden und/oder bevorzugt werden, umfassen, wie oben erwähnt. Ein Nutzerprofil kann auch historische Details, wie z. B. durchschnittliche Triplänge, Fahrgeschwindigkeiten usw., umfassen.
-
Als Nächstes kann der Server 125 in einem Block 310 unter Verwendung von in dem Nutzerprofil enthaltenen Daten Nutzertripdetails vorhersagen. Beispielsweise kann der Server 125 eine Fahrtlänge, eine Betriebszone oder Betriebszonen innerhalb eines vom Server 125 abgedeckten geographischen Gebiets (z. B. des in 2 gezeigten Gebiets 200), einen wahrscheinlichen Abstellort oder wahrscheinliche Abstellorte usw. vorhersagen.
-
Als Nächstes ruft der Server 125 in einem Block 315 ein Profil eines Fahrzeugs 101, z. B. Daten zu und/oder eine Betriebshistorie von einem Fahrzeug 101, das von einem Nutzer für den Trip ausgewählt wurde, ab. Beispielsweise können Daten eines Fahrzeugs 101 einen Status einer Batterie des Fahrzeugs 101, z. B. voll, zur Hälfte geladen, nahezu leer usw., sowie Daten über einen Füllstand von brennbarem Kraftstoff für eine Brennkraftmaschine, Verbrauchsraten der Batterie und/oder des brennbaren Kraftstoffs usw. umfassen.
-
Als Nächstes identifiziert der Server 125 in einem Block 320 eine Betriebszone eines Fahrzeugs 101 in einem von dem Server 125 abgedeckten Gebiet 200. Beispielsweise kann eine Zone ein durch Straßen, Regierungsgrenzen, natürliche Merkmale, wie z. B. Flüsse usw., eingegrenztes geographisches Gebiet sein oder eine Zone könnte gemäß einem Quadrat oder einer anderen Form mit einem Punkt in einem Gebiet 200 als Mittelpunkt oder Lokus definiert werden.
-
Als Nächstes ruft der Server 125 in einem Block 325 Profildaten für die identifizierte Zone ab. Beispielsweise könnten historische Daten für eine Zone eine typische Luftqualität für eine Tageszeit, Kalendertag usw. sowie wahrscheinliche Verkehrsstaus für eine Tageszeit und/oder einen Kalender- oder Wochentag usw. anzeigen.
-
Als Nächstes ruft der Server 125 in einem Block 330 aktuelle, z. B. Echtzeit-, Daten bezüglich Verkehrsstaus, Luftqualität und/oder anderer Faktoren für die identifizierte Zone ab.
-
Als Nächstes bestimmt der Server 125 in einem Block 335 einen aktuellen Betriebsmodus des Fahrzeugs 101, z. B. Elektro(EV)-Modus oder Brennkraftmaschinen(IC)-Modus. Beispielsweise kann der Computer 105 des Fahrzeugs 101 dem Server 125 über das Netzwerk 120 solche Daten bereitstellen, die z. B. einen Betriebsmodus mit einem Elektromotor oder einer Brennkraftmaschine anzeigen.
-
Als Nächstes bestimmt der Server 125 in einem Block 340, ob ein Moduswechsel angebracht ist. Beispielsweise können, wie oben beschrieben, Faktoren, wie z. B. Kraftstofffüllstände, die verschiedene Modi in dem Fahrzeug 101 unterstützen, aktuelle Luftqualität, erwartete Fahrtlänge und/oder möglicherweise andere Faktoren berücksichtigt werden, um zu bestimmen, ob ein EV-Modus oder ein IC-Modus für eine Zone, Merkmale der Zone und Merkmale (und/oder erwartete Merkmale) eines Trips eines Nutzers, wie oben erörtert, geeignet ist. Ein beispielhafter Teilprozess 400 zur Bestimmung eines geeigneten Modus wird im Folgenden mit Bezug auf 4 detaillierter beschrieben. Falls ein Moduswechsel angebracht ist, wird als Nächstes ein Block 350 ausgeführt. Ansonsten wird als Nächstes ein Block 345 ausgeführt.
-
Im Block 345 bestimmt der Server 125, ob der Prozess 300 fortfahren soll. Wenn beispielsweise das Fahrzeug 101 seinen Zielort erreicht hat, abgeschaltet ist usw., endet der Prozess 300. Ansonsten geht der Prozess 300 zu dem Block 320 zurück.
-
Im Block 350 stellt der Server 125 dem Computer 105 des Fahrzeugs 101 die Kraftmaschinenmodusempfehlung bereit. Beispielsweise könnte der Server 125 dem Fahrzeug 101 eine Anweisung bereitstellen, einen Kraftmaschinenmodus, z. B. von EV auf IC oder umgekehrt, zu wechseln. Nach dem Block 350 geht der Prozess 300 zu dem Block 345 über.
-
4 ist ein Prozessverlaufdiagramm für einen Prozess 400 zum Betrieb eines Gemeinschaftsfahrzeugs 101 mit Kraftmaschinenmodusempfehlungen. Der Prozess 400 beginnt in einem Block 405, in dem ähnlich zu dem oben bezüglich des Prozesses 300 beschriebenen Block 345 der Server 125 bestimmt, ob der Betrieb des Fahrzeugs 101 fortgeführt wird. Wenn sich beispielsweise das Fahrzeug 101 an einem Zielort oder Abstellort oder in der Nähe davon befindet, abgeschaltet ist usw., kann ein Block 425 als Nächstes ausgeführt werden. Ansonsten geht der Prozess 400 zu einem Block 410 über.
-
Im Block 410 bestimmt der Server 125, ob das Fahrzeug 101 in einer Zone mit hohem Stauaufkommen und/oder hohem Verkehrsaufkommen betrieben wird. Beispielsweise kann der Server 125 Daten von Quellen, wie z. B. bekannte eine Verkehrsdichte, z. B. Anzahl an Pkw oder anderen Fahrzeugen pro Einheit, z. B. 100 Meter, 500 Meter usw., einer Straße oder von Straßen in einer Zone angebende Quellen, empfangen. Eine Zone kann als eine Zone mit hohem Stauaufkommen oder hohem Verkehrsaufkommen angesehen werden, wenn die Verkehrsdichte einen vorbestimmten Schwellenwert übersteigt. Alternativ oder zusätzlich dazu kann eine Zone als Zone mit hohem Stauaufkommen oder hohem Verkehrsaufkommen bestimmt werden, wenn eine durchschnittliche Geschwindigkeit von Fahrzeugen 101, 102 in der Zone unter einem vorbestimmten Schwellenwert liegt, z. B. unter einer durchschnittlichen Geschwindigkeitsbeschränkung in der Zone usw., liegt. Des Weiteren können Luftqualität und/oder Umweltbedingungen berücksichtigt werden, um zu bestimmen, ob eine Zone eine Zone mit hohem Stauaufkommen ist. Beispielsweise kann Luftqualität unter einem vorbestimmten Schwellenwert, z. B. eine Messung der Umweltverschmutzung unter einem vorbestimmten Schwellenwert, eine Anzeige dafür sein, dass eine Zone eine Zone mit hohem Stauaufkommen ist. Wenn das Fahrzeug 101 in einer Zone mit hohem Stauaufkommen oder hohem Verkehrsaufkommen in Betrieb ist, kann als Nächstes ein Block 420 ausgeführt werden. Wenn das Fahrzeug 101 nicht in einer Zone mit hohem Stauaufkommen oder hohem Verkehrsaufkommen in Betrieb ist, kann als Nächstes ein Block 415 ausgeführt werden. Im Block 415 weist der Server 125 das Fahrzeug 101 zum Betrieb in einem opportunistischen EV-Modus an. Dies erfolgt in Abhängigkeit von einem Batterieladestand, einer Tripstrecke usw., wobei das Fahrzeug 101 in einem EV-Modus betrieben werden kann, solange ausreichende Batterieressourcen für den Trip und/oder für Zonen mit hohem Stauaufkommen oder hohem Verkehrsaufkommen, auf die im späteren Verlauf des Trips getroffen wird, erwartet werden. Andernfalls kann das Fahrzeug 101 in einem IC-Modus betrieben werden. In jedem Fall kehrt der Prozess 400 nach dem Block 415 zu dem Block 405 zurück.
-
Im Block 420, der auf den Block 410 folgen kann, weist der Server 125 das Fahrzeug 101 zum Betrieb in einem EV-Modus an. Der Prozess 400 kehrt dann zu dem Block 405 zurück.
-
In dem Block 425, der auf den Block 405 folgen kann, wird ein Fahrzeug 101 von einem Nutzer an einem Abstellort abgestellt. Solch ein Abstellen kann vom Server 125 z. B. gemäß einer Nachricht über das Netzwerk 120 vom Computer 105 des Fahrzeugs 101 registriert werden.
-
Nach dem Block 425 bestimmt der Server 125 in einem Block 430, ob das Fahrzeug 101, z. B. von einer ersten Zone in eine zweite Zone, nach seinem Abstellen umgestellt werden muss. Beispielsweise kann wie oben mit Bezug auf 2 erwähnt, eine Anzahl an Fahrzeugen in einer ersten Zone eine Anzahl an Fahrzeugen in einer zweiten Zone überschreiten oder diese um einen vorbestimmten Schwellenwert überschreiten, z. B. mehr als 10 Prozent, 20 Prozent usw. In diesem Fall kann der Server 125 bestimmen, dass das soeben abgestellte Fahrzeug 101 umgestellt werden muss. Wenn bestimmt wurde, dass ein Fahrzeug umgestellt werden muss, kann ein Block 435 als Nächstes ausgeführt werden. Ansonsten endet der Prozess 400 nach dem Block 430.
-
Im Block 435 stellt der Server 125 eine Modusempfehlung für die Fahrt des Fahrzeugs 101 von dem Abstellort zu einem Umstellort in einer zweiten Zone bereit. Beispielsweise kann eine solche Empfehlung wie oben beschrieben bereitgestellt werden. Nach dem Block 435 endet der Prozess 400.
-
Datenverarbeitungsvorrichtungen wie die hier erörterten umfassen allgemein jeweils Anweisungen, die durch eine oder mehrere Datenverarbeitungsvorrichtungen ausführbar sind, wie die oben identifizierten, und zum Ausführen von oben beschriebenen Blöcken oder Schritten von Prozessen. Computerausführbare Anweisungen können aus Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung vielfältiger Programmiersprachen und/oder -technologien erstellt werden, darunter, aber ohne Beschränkung und entweder alleine oder in Kombination, JavaTM, C, C++, Visual Basic, Java Script, Perl, HTML usw. Im Allgemeinen empfängt ein Prozessor (z.B. ein Mikroprozessor) Anweisungen z.B. aus einem Speicher, einem computerlesbaren Medium usw. und führt diese Anweisungen aus, um dadurch einen oder mehrere Prozesse, einschließlich eines oder mehrerer der hier beschriebenen Prozesse, auszuführen. Solche Anweisungen und andere Daten können unter Verwendung vielfältiger computerlesbarer Medien gespeichert und übertragen werden.
-
Eine Datei in einer Datenverarbeitungsvorrichtung ist allgemein eine Ansammlung von in einem computerlesbaren Medium, wie etwa einem Speichermedium, einem Direktzugriffsspeicher usw. gespeicherten Daten.
-
Ein computerlesbares Medium umfasst jedes Medium, das bei der Bereitstellung von Daten (z.B. Anweisungen), die durch einen Computer gelesen werden können, teilnimmt. Ein solches Medium kann viele Formen annehmen, darunter, aber ohne Beschränkung darauf, nichtflüchtige Medien, flüchtige Medien usw. Nichtflüchtige Medien umfassen zum Beispiel optische oder magnetische Datenträger und andere persistente Speicher. Zu flüchtigen Medien gehört dynamischer Direktzugriffsspeicher (DRAM), der typischerweise einen Hauptspeicher bildet. Übliche Formen von computerlesbaren Medien umfassen zum Beispiel eine Floppy-Disk, eine Diskette, eine Festplatte, ein Magnetband, ein beliebiges anderes magnetisches Medium, eine CD-ROM, eine DVD, ein beliebiges anderes optisches Medium, Lochkarten, Papierband, ein beliebiges anderes physisches Medium mit einem Muster von Löchern, einen RAM, einen PROM, einen EPROM, einen Flash-EEPROM, einen beliebigen anderen Speicherchip oder eine Speicherkassette oder ein beliebiges anderes Medium, woraus ein Computer lesen kann.
-
Mit Bezug auf die hier beschriebenen Medien, Prozesse, Systeme, Verfahren usw. versteht sich, dass, obwohl die Schritte solcher Prozesse usw. als gemäß einer bestimmten geordneten Sequenz auftretend beschrieben wurden, solche Prozesse mit in einer anderen als der hier beschriebenen Reihenfolge ausgeführten beschriebenen Schritten ausgeübt werden könnten. Ferner versteht sich, dass bestimmte Schritte gleichzeitig ausgeführt werden könnten, dass andere Schritte hinzugefügt werden könnten oder dass bestimmte hier beschriebene Schritte weggelassen werden könnten. Anders ausgedrückt, werden die vorliegenden Beschreibungen von Systemen und/oder Prozessen zum Zwecke der Veranschaulichung bestimmter Ausführungsformen bereitgestellt und sollten auf keinerlei Weise als Beschränkung des offenbarten Gegenstands aufgefasst werden.
-
Dementsprechend versteht sich, dass die obige Beschreibung nicht einschränkend, sondern veranschaulichend sein soll. Für den Fachmann würden bei Durchsicht der obigen Beschreibung viele andere Ausführungsformen und Anwendungen als die gegebenen Beispiele offensichtlich werden. Der Schutzumfang der Erfindung sollte nicht mit Bezug auf die obige Beschreibung bestimmt werden, sondern sollte stattdessen mit Bezug auf die hier angefügten und/oder in einer hierauf basierenden endgültigen Patentanmeldung enthaltenen Ansprüche, zusammen mit dem vollen Umfang von Äquivalenten, zu denen diese Ansprüche berechtigt sind, bestimmt werden. Es wird erwartet und beabsichtigt, dass zukünftige Entwicklungen in der hier besprochenen Technik auftreten werden und dass die offenbarten Systeme und Verfahren in solche zukünftigen Ausführungsformen integriert werden. Zusammengefasst versteht sich, dass der offenbarte Gegenstand modifiziert und abgewandelt werden kann.
-
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 Nicht-Patentliteratur
-
- IEEE 802.101 [0015]
- IEEE 802.101 [0017]
