DE102016111371A1

DE102016111371A1 - Parameterschätzung für schnellen Verkehr

Info

Publication number: DE102016111371A1
Application number: DE102016111371.9A
Authority: DE
Inventors: Engin Ozatay; Dimitar Filev; John Ottavio Michelini
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2015-06-23
Filing date: 2016-06-21
Publication date: 2016-12-29
Also published as: CN106295849B; GB2541511A; RU2016123642A; US20160379126A1; US10495469B2; GB201610908D0; MX2016008333A; CN106295849A

Abstract

Daten in Bezug auf eine Fahrzeugbewegung an einer Ampel werden gesammelt. Eine Ampelzykluszeit wird mit einem Wahrscheinlichkeitsmodell prognostiziert. Die Daten werden mit der prognostizierten Ampelzykluszeit verglichen. Eine Rauschfunktion wird auf die Daten angewendet, um rauschangewandte Daten zu generieren. Das Wahrscheinlichkeitsmodell für die prognostizierte Ampelzykluszeit wird mittels Skalierung des Wahrscheinlichkeitsmodells mit den rauschangewandten Daten aktualisiert, um ein neues Wahrscheinlichkeitsmodell zu generieren. Ein empfohlener Fahrzeugbetrieb wird über ein Netz an wenigstens einen Fahrzeugcomputer bereitgestellt, basierend auf der prognostizierten Ampelzykluszeit, welche vom neuen Wahrscheinlichkeitsmodell bestimmt wird.

Description

HINTERGRUND
Im Stadtverkehr können Stoppschilder und Verkehrsampeln den Kraftstoffverbrauch eines Fahrzeugs erhöhen. Wenn Fahrzeuge stationär sind und/oder stoppen und erneut auf eine Fahrtgeschwindigkeit beschleunigen, nimmt die Kraftstoffeffizienz im Allgemeinen ab. Leider sind Straßen im Allgemeinen derzeit nicht ausgelegt, um einen Non-Stop-Verkehrsfluss oder selbst einen Verkehrsfluss bei einer allgemein gleichbleibenden Geschwindigkeit zu ermöglichen. Daher sind derzeitige Fahrzeuge nicht in der Lage, Vorteile zu erhalten, welche von weniger Stopps und Starts und/oder gleichbleibenderen Fahrtgeschwindigkeiten resultieren würden.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockschaltbild eines Systems zum Schätzen und Abrufen von Verkehrsparametern.
2 ist ein Prozessflussdiagramm eines Prozesses zum Schätzen von Verkehrsparametern.
3 ist ein Prozessflussdiagramm eines Prozesses zum Schätzen einer Ampelzykluszeit.
4 ist eine beispielhafte Darstellung der Ampelzykluszeit, eines Arbeitszyklus und eines Offsets.
5 ist ein beispielhaftes Diagramm, welches mehrere Ampelzyklen von einem Satz von Messungen zeigt.
6 ist ein beispielhaftes Diagramm einer Rauschfunktion zum Bestimmen der Ampelzykluszeit.
DETAILLIERTE BESCHREIBUNG
1 veranschaulicht ein System 100 zum effizienten und genauen Bestimmen von Verkehrsampelparametern. Fahrzeuge 101, welche gemäß solchen Bestimmungen betrieben werden, können Vorteile genießen, darunter verminderten Verschleiß und erhöhte Kraftstoffeffizienz. Insbesondere kann die Bestimmung von Verkehrsampelparametern, wie sie hierin offenbart werden, einschließlich einer Ampelzykluszeit, zu einem besseren Wegebau und einem besseren Kraftstoffverbrauch führen, indem eine Anzahl von Malen, welche das Fahrzeug stoppen muss, reduziert wird.
Ein Fahrzeug 101 umfasst eine Rechenvorrichtung 105 mit einem Datenspeicher 102 und einem Datensammler 103. Die Rechenvorrichtung 105 umfasst einen Prozessor und einen Speicher, wobei der Speicher eine oder mehrere Formen von computerlesbaren Medien umfasst, z. B. flüchtigen und/oder nicht-flüchtigen Speicher, wie bekannt sind, wobei der Speicher Anweisungen speichert, welche vom Prozessor zum Durchführen verschiedener Operationen ausführbar sind, einschließlich wie hierin offenbart. Ferner kann die Rechenvorrichtung 105 mehr als eine Rechenvorrichtung umfassen, z. B. Steuerungen oder dergleichen, welche im Fahrzeug 101 zum Überwachen und/oder Steuern verschiedener Fahrzeugkomponenten eingeschlossen sind, z. B. eine Kraftmaschinensteuereinheit (ECU, Engine Control Unit), Getriebesteuereinheit (TCU, Transmission Control Unit) usw. Die Rechenvorrichtung 105 ist im Allgemeinen für die Kommunikation auf einem fahrzeuginternen Netz und/oder Kommunikationsbus, wie beispielsweise einem Controller Area Network(CAN)-Bus oder dergleichen, ausgelegt. Die Rechenvorrichtung 105 kann auch eine Verbindung zu einem Onboard-Diagnoseverbinder (OBD-II) aufweisen. Über den CAN-Bus, OBD-II und/oder andere verdrahtete oder drahtlose Mechanismen kann der Computer 105 Nachrichten an verschiedene Vorrichtungen in einem Fahrzeug übertragen und/oder Nachrichten von den verschiedenen Vorrichtungen empfangen, z. B. Steuerungen, Betätigungselemente, Sensoren usw., einschließlich Datensammler 103. Alternativ oder zusätzlich kann in Fällen, in denen der Computer 105 tatsächlich mehrere Vorrichtungen umfasst, der CAN-Bus oder dergleichen für die Kommunikation zwischen den Vorrichtungen verwendet werden, welche als die Rechenvorrichtung 105 in dieser Offenbarung repräsentiert wird.
Zusätzlich kann die Rechenvorrichtung 105 ausgelegt sein, z. B. Programmierung und/oder Hardware zu umfassen, wie bekannt ist, um mit einem Netz 110 zu kommunizieren, welches, wie unten beschrieben, verschiedene verdrahtete und/oder drahtlose Netztechnologien umfassen kann, z. B. zellulär, Bluetooth, verdrahtete und/oder drahtlose Paketnetze usw. Ferner umfasst die Rechenvorrichtung 105 im Allgemeinen Anweisungen zum Empfangen von Daten, z. B. von einem oder mehreren Datensammlern 103 und/oder einer Mensch-Maschine-Schnittstelle (HMI, Human Machine Interface), wie beispielsweise einem interaktiven Sprachdialog(IVR, Interactive Voice Response)-System, einer grafischen Benutzerschnittstelle (GUI, Graphical User Interface), einschließlich eines Berührungsbildschirms oder dergleichen, usw.
Unter Verwendung von empfangenen Daten in der Rechenvorrichtung 105, z. B von Datensammlern 105, Daten, welche als gespeicherte Parameter eingeschlossen sind, dem Server usw., kann die Rechenvorrichtung 105 verschiedene Komponenten und/oder Operationen des Fahrzeugs 101 steuern. Beispielsweise kann die Rechenvorrichtung 105 verwendet werden, um die Geschwindigkeit, Beschleunigung, Verlangsamung, Lenkung usw. des Fahrzeugs 101 zu regulieren.
Datensammler 103 können eine Vielzahl von Vorrichtungen umfassen. Zur Vereinfachung der Darstellung wird in 1 ein Datensammler 103 gezeigt, aber wie aus dieser Offenbarung ersichtlich wird, wird ein Fahrzeug 101 wahrscheinlich mehrere Datensammler 103 umfassen. Beispielsweise können verschiedene Steuerungen in einem Fahrzeug als Datensammler 103 arbeiten, um Daten über den CAN-Bus bereitzustellen, z. B. Daten in Bezug auf die Fahrzeuggeschwindigkeit, Beschleunigung usw. Ferner könnten Sensoren oder dergleichen, globale Positionierungssystem(GPS)-Geräte usw. in einem Fahrzeug eingeschlossen sein und als Datensammler 103 ausgelegt sein, um Daten direkt an die Rechenvorrichtung 105 bereitzustellen, z. B. über eine verdrahtete oder drahtlose Verbindung. Datensammler 103 könnten auch Sensoren oder dergleichen umfassen, um Zustände außerhalb des Fahrzeugs 101 zu detektieren, z. B. mittelreichweitige Sensoren und Fernbereichssensoren. Beispielsweise könnten Sensordatensammler 103 Mechanismen umfassen, wie beispielsweise Radar, Lidar, Sonar, Kameras oder andere Bilderfassungsvorrichtungen, welche eingesetzt werden könnten, um eine Distanz zwischen dem Fahrzeug 101 und anderen Fahrzeugen oder Objekten zu messen, andere Fahrzeuge oder Objekte zu detektieren und/oder Straßenzustände zu detektieren, wie beispielsweise Kurven, Schlaglöcher, Senkungen, Bodenwellen, Änderungen in der Steigung usw. Darüber hinaus können Datensammler 103 Sensoren intern im Fahrzeug 101 umfassen, wie beispielsweise Beschleunigungsmesser, Temperatursensoren, Bewegungsmelder usw., um eine Bewegung oder andere Zustände des Fahrzeugs 101 zu detektieren.
Ein Speicher der Rechenvorrichtung 105 speichert im Allgemeinen gesammelte Daten 104. Die gesammelten Daten 104 können eine Vielzahl von Daten umfassen, welche von Datensammlern 103 in einem Fahrzeug 101 gesammelt werden. Beispiele für gesammelte Daten 104 werden oben bereitgestellt, und darüber hinaus können Daten zusätzlich Daten umfassen, welche daraus in der Rechenvorrichtung 105 berechnet werden. Im Allgemeinen können gesammelte Daten 104 beliebige Daten umfassen, welche von den Datensammlern 103 gesammelt werden können und/oder aus solchen Daten berechnet werden können. Dementsprechend könnten gesammelte Daten 104 eine Vielzahl von Daten in Bezug auf Operationen und/oder Leistung des Fahrzeug 101 sowie Daten insbesondere im Zusammenhang mit der Bewegung des Fahrzeugs 101 umfassen. Beispielsweise könnten gesammelte Daten Daten in Bezug auf Geschwindigkeit, Beschleunigung, Bewegung in Längsrichtung, seitliche Bewegung, Nicken, Gieren, Rollen, Bremsen usw. eines Fahrzeugs 101 umfassen.
Ein Speicher der Rechenvorrichtung 105 kann ferner einen oder mehrere Steuerparameter speichern. Ein Steuerparameter regelt im Allgemeinen die Verwendung der gesammelten Daten 104. Beispielsweise kann ein Parameter einen Schwellenwert bereitstellen, mit dem gesammelte Daten verglichen werden können, um zu bestimmen, ob eine Anpassung an der Komponente vorgenommen werden sollte. In ähnlicher Weise könnte ein Parameter einen Schwellenwert bereitstellen, unterhalb dessen ein Element der gesammelten Daten, z. B. ein Datenwert von einem Beschleunigungsmesser, nicht berücksichtigt werden sollte.
Das System 100 umfasst das Netz 110. Das Netz 110 repräsentiert einen oder mehrere Mechanismen, anhand derer die Rechenvorrichtung 105 mit einer Benutzervorrichtung 125 und/oder einem Verkehrsparameterserver 130 kommunizieren kann. Dementsprechend kann das Netz 110 ein oder mehrere von verschiedenen verdrahteten oder drahtlosen Kommunikationsmechanismen sein, einschließlich einer beliebigen Kombination von verdrahteten (z. B. Kabel und Glasfaser) und/oder drahtlosen (z. B. zellulär, drahtlos, Satellit, Mikrowelle und Funkfrequenz) Kommunikationsmechanismen und einer beliebigen Netztopologie (oder Topologien bei Nutzung mehrerer Kommunikationsmechanismen). Beispielhafte Kommunikationsnetze umfassen drahtlose Kommunikationsnetze (z. B. unter Verwendung von Bluetooth, IEEE 802.11 usw.), lokale Netze (LAN, Local Area Network) und/oder weiträumige Netze (WAN, Wide Area Network), einschließlich des Internets, zum Bereitstellen von Datenkommunikationsdiensten.
Eine oder mehrere Benutzervorrichtungen 125 (zur Vereinfachung der Darstellung wird eine einzelne Vorrichtung 125 in 1 gezeigt) können mit dem Netz 110 verbunden sein. Die Benutzervorrichtungen 125 können allgemein getragene Vorrichtungen umfassen, wie beispielsweise eines oder mehrere von Mobiltelefonen, Tablet-Vorrichtungen, Laptop-Computer usw.
Das System 100 umfasst den Verkehrsparameterserver 130, welcher einen Datenspeicher 135 aufweist. Der Verkehrsparameterserver 130 sammelt Verkehrsampelparameterdaten, z. B. gesammelte Daten 104 von einem Fahrzeug 101, einem Datensammler 115 usw., welche über das Netz 110 gesendet werden. Der Verkehrsparameterserver 130 und der Datenspeicher 135 können von einer beliebigen geeigneten Art sein, z. B. Festplattenlaufwerke, Solid-State-Drives oder beliebige andere flüchtige oder nicht-flüchtige Medien. Der Datenspeicher 135 speichert die Verkehrsampelparameterdaten, welche vom Verkehrsparameterserver 130 gesammelt werden.
Das System 100 umfasst den Datensammler 115. Der Datensammler 115 kann an einer Kreuzung und/oder an einer Verkehrsampel positioniert sein. Der Datensammler 115 misst den Start der Bewegungszeit (SOMT, Start of Motion Time) für ein Fahrzeug 101 an einer Kreuzung. Der SOMT kann verwendet werden, um einen SOMT-Datensatz auf dem Server 130 zu generieren. Wie in 5 gezeigt, kann der SOMT-Datensatz einen oder mehrere Ampelzyklen umfassen, z. B. grün-gelb-rot-grün.
2 veranschaulicht einen Prozess 200 für die Verwendung des Systems 100. Der Prozess 200 beginnt in einem Block 205, in dem die Datensammler 103, 115 SOMT-Daten für Fahrzeuge 101 sammeln. Insbesondere detektieren die Datensammler 103, 115 eine Statusänderung eines i-ten Fahrzeugs: Wenn das Fahrzeug stoppt, wird diese Zeit aufgezeichnet, hierin mit t_r(i) bezeichnet. Wenn das Fahrzeug wieder beginnt, sich zu bewegen, wird eine Neustartzeit aufgezeichnet, hierin mit t_g(i) bezeichnet. Eine Verkehrsampeldurchlaufzeit wird gesammelt, hierin mit t_p(i) bezeichnet, und eine Richtung, z. B. Fahrtrichtung, des Fahrzeugs wird aufgezeichnet, hierin mit h(i) bezeichnet.
Als Nächstes senden die Datensammler 103, 115 in einem Block 210 die SOMT-Daten an den Verkehrsparameterserver 130. Durch die Verwendung von Datensammlern sowohl bei Verkehrsampeln als auch in Fahrzeugen 101 kann ein größeres Volumen von nützlichen Daten, als sonst möglich wäre, gesammelt und an den Verkehrsparameterserver 130 gesendet werden. Die SOMT-Daten können gemäß Fahrtrichtungen von Fahrzeugen, von denen sie gesammelt wurden, geclustert werden (z. B. Daten von nach Süden fahrenden Fahrzeugen können zusammen gespeichert werden, Daten von nach Norden fahrenden Fahrzeugen können zusammen gespeichert werden usw.), und können in chronologischer Reihenfolge angeordnet werden.
Als Nächstes wendet der Verkehrsparameterserver 130 in einem Block 220 das Ampelzykluszeitmodell, welches im Prozess 300 aus 3 beschrieben ist, auf die Daten an und generiert eine geschätzte Ampelzykluszeit.
Als Nächstes berechnet der Verkehrsparameterserver 130 in einem Block 225 einen Arbeitszyklus und ein Offset basierend auf der geschätzten Ampelzykluszeit des Blocks 220 (und dem Prozess 300). Das Offset ρ der Ampel ist die Differenz in der Zeit zwischen dem Ende eines Satzes von Ampelzykluszeiten und eines anderen Satzes von Ampelzykluszeiten und wird mittels einer Modulo-Operation bestimmt, welche auf die Zeit des grünen Lichts über die Gesamtzykluszeit angewandt wird: ρ(k) = mod(min(t l,o / g,u), x(k))
Ein Ergebnis der vorstehenden Gleichung kann fehleranfällig sein; daher wird ein linearer Driftterm γ iterativ berechnet: γ_l,o = mod(min(t l,o / g,u), (α + 1)p*) – mod(min(t l,o / g,u), αp*) wobei p* die geschätzte Ampelzykluszeit ist. Der Arbeitszyklus λ, welcher das Verhältnis von der Menge an Zeit ist, welche mit dem grünen Licht verbracht wird, zur gesamten Ampelzykluszeit, kann dann berechnet werden:
wobei ΔT_g die maximale Zeitdifferenz zwischen den aufgezeichneten Zeiten t_p und dem letzten rechtzeitigen grünen Licht ist, welche mit geschätzten Werten von ρ, p berechnet werden kann, und ΔT_r die maximale Zeitdifferenz zwischen der Stoppzeit t_r der ankommenden Fahrzeuge und dem nächsten rechtzeitigen grünen Licht ist. Die gesamten Grün- und Rotzeiten können approximiert werden mittels: ΔT_g ≈ ΔT _g = max(mod(t_p(i) – ρ, p)) für i = 1...N_p ΔT_r ≈ ΔT _r = p – min(mod(t_r(i) – ρ, p)) für i = 1...N_r wobei N_p und N_r den jeweiligen Anzahlen von Messungen von t_p und t_r entsprechen, wie oben beschrieben.
Als Nächstes speichert der Verkehrsparameterserver 130 in einem Block 230 die geschätzte Periode im Datenspeicher 135, wodurch ein Flottendatensatz erzeugt wird.
Als Nächstes erzeugt der Verkehrsparameterserver 130 in einem Block 235, wenn ein Benutzer Ampelzykluszeitdaten vom Verkehrsparameterserver 130 anfordert, Empfehlungen zum Anpassen des Fahrzeugprofils des Benutzers basierend auf der Position des Fahrzeugs des Benutzers und den Ampelzykluszeitdaten. Die Empfehlungen können eine Änderung der Betriebsgeschwindigkeit, Route zu einem Ziel oder Beschleunigung des Fahrzeugs basierend auf einer bevorstehenden Verkehrsampel umfassen.
Als Nächstes sendet der Verkehrsparameterserver 130 in einem Block 240 die Empfehlungen an den Benutzer, und der Prozess 200 endet.
3 veranschaulicht einen Prozess 300, welcher das Ampelzykluszeitmodell des Blocks 220 aus 2 beschreibt. Der Prozess 300 startet in einem Block 305, in dem ein SOMT-Datenwert k gesammelt wird und an den Server 130 bereitgestellt wird. Als Nächstes ruft der Server 130 in einem Block 310 ein Periodenwahrscheinlichkeitsmodell für eine erste Zeitdauer ab: xⁱ(k) = f i / x(xⁱ(k – 1)) = xⁱ(k – 1) wobei xⁱ(k) das aktuelle Periodenwahrscheinlichkeitsmodell für den aktuellen SOMT-Datenwert k ist, welches im Block 305 abgerufen wird, und f i / x(xⁱ(k – 1)) die Wahrscheinlichkeitsdichtefunktion für die Periode des vorhergehenden Datenwerts k – 1 ist, Daten bis zum Datenwert k – 1 gegeben, und i der aktuelle Zeitdauerindex ist. Als Nächstes vergleicht der Server 130 in einem Block 315 den Datenwert k mit der Periodenschätzung xⁱ(k). Die Periodenschätzung xⁱ(k) erzeugt eine wahrscheinlichste Schätzung der Ampelzykluszeit basierend auf dem aktuellen Zeitdauerindex. Falls die Messung nicht innerhalb eines Schwellenwerts der wahrscheinlichsten Schätzung der Ampelzykluszeit liegt, geht der Prozess 300 zu Block 320 weiter.
Als Nächstes prüft der Server 130 im Block 320, um zu sehen, ob irgendwelche weiteren Zeitdauerindizes i vorhanden sind. Falls weitere Zeitdauerindizes vorhanden sind, geht der Prozess 300 zu einem Block 325 weiter.
Als Nächstes ruft der Server 130 im Block 325 das Periodenwahrscheinlichkeitsmodell für den nächsten Zeitdauerindex i + 1 ab und kehrt zum Block 315 zurück.
Unter Rückbezug auf Block 320, falls keine weiteren Zeitdauerindizes vorhanden sind, geht der Prozess 300 zu einem Block 330 weiter. Im Block 330 erstellt der Server 130 einen Zeitdauerindex und initialisiert den neuen Zeitdauerindex mit einem Anfangsperiodenwahrscheinlichkeitsmodell. Der Prozess 300 geht dann zu einem Block 335 weiter.
Unter Rückbezug auf Block 315, falls der Datenwert k innerhalb des Schwellenwerts für die Periodenwahrscheinlichkeit für den aktuellen Markov-Zustand liegt, geht der Prozess 300 zum Block 335 weiter.
Im Block 335 speichert der Server 130 die Messung und wendet eine Rauschfunktion w(k) auf die gespeicherten Messungen an. Die Rauschfunktion ist eine Mischung von Gaußschem Rauschen, welches auf die Messung angewendet wird so dass z(k) = x(k) + w(k) wobei z(k) das rauschangepasste Periodenwahrscheinlichkeitsmodell ist. Durch Anwenden der Rauschfunktion auf die Messung kann die Periode x(k) mit weniger Gesamtmessungen k geschätzt werden. Die Wahrscheinlichkeitsdichtefunktion der Rauschfunktion, in 6 gezeigt, ist definiert durch
wobei σ die Standardabweichung ist, a der abfallende Koeffizient der Gaußschen Mischung ist und N die Anzahl vom Gaußschen Rauschen ist, dessen Signifikanz mit zunehmendem Mehrfachen der Periode abklingt.
Als Nächstes aktualisiert der Server 130 in einem Block 340 das Periodenwahrscheinlichkeitsmodell. An diesem Punkt kann das Wahrscheinlichkeitsmodell geschrieben werden als
Von hier aus wird der neue Datenwert k integriert, um die Periodenwahrscheinlichkeitsdichtefunktion zu aktualisieren
wobei f_x(x(k)|z(1:k)) die Wahrscheinlichkeitsdichtefunktion des geschätzten Zustands am Datenwert k bezeichnet, die Messungen bis k gegeben, f_x(x(k)|z(1:k – 1)) die Ausgabe der vorherigen Aktualisierungsstufe ist und f_z(z(k)|x(k)) die Wahrscheinlichkeitsdichtefunktion des stochastischen Messmodells z(k) ist.
Als Nächstes prüft der Server 130 in einem Block 342, ob sich die Zeitdauer geändert hat, z. B. vom Block 325 oder Block 330. Falls sich die Zeitdauer nicht geändert hat, endet der Prozess 300. Falls sich die Zeitdauer geändert hat, geht der Prozess 300 zu einem Block 345 weiter.
Als Nächstes aktualisiert der Server im Block 345 die Zeitdauerindexmatrix, welche die Länge dⁱ von jedem Zeitdauerindex speichert, und der Prozess 300 endet.
Rechenvorrichtungen wie diese, welche hierin erläutert werden, umfassen im Allgemeinen jeweils Anweisungen, die von einer oder mehreren Rechenvorrichtungen ausführbar sind, wie beispielsweise die oben identifizierten, und zum Ausführen von Blöcken oder Schritten der oben beschriebenen Prozesse. Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder interpretiert werden, welche unter Verwendung einer Vielzahl von Programmiersprachen und/oder Technologien erstellt werden, einschließlich, ohne darauf beschränkt zu werden, und entweder allein oder in Kombination, Java^TM, C, C++, Visual Basic, Java Script, Perl, HTML usw. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem computerlesbaren Medium usw., und führt diese Anweisungen aus, um dadurch einen oder mehrere Prozesse durchzuführen, einschließlich eines oder mehrerer der hierin beschriebenen Prozesse. Solche Anweisungen und andere Daten können unter Verwendung einer Vielzahl von computerlesbaren Medien gespeichert und übertragen werden. Eine Datei in einer Rechenvorrichtung ist im Allgemeinen eine Sammlung von Daten, welche auf einem computerlesbaren Medium gespeichert sind, wie beispielsweise ein Speichermedium, ein Direktzugriffsspeicher usw.
Ein computerlesbares Medium umfasst ein beliebiges Medium, welches am Bereitstellen von Daten (z. B. Anweisungen), die von einem Computer gelesen werden können, beteiligt ist. Ein derartiges Medium kann viele Formen annehmen, einschließlich, aber nicht darauf beschränkt, nicht-flüchtiger Medien, flüchtiger Medien usw. Nicht-flüchtige Medien umfassen beispielsweise optische oder magnetische Platten und anderen persistenten Speicher. Flüchtige Medien umfassen dynamischen Direktzugriffsspeicher (DRAM, Dynamic Random Access Memory), welcher typischerweise einen Hauptspeicher bildet. Übliche Formen von computerlesbaren Medien umfassen beispielsweise eine Diskette, eine flexible Platte, eine Festplatte, ein Magnetband, jedes andere magnetische Medium, eine CD-ROM, DVD, jedes andere optische Medium, Lochkarten, Papierband, ein beliebiges anderes physisches Medium mit Lochmustern, ein RAM, ein PROM, ein EPROM, ein FLASH-EEPROM, jeden anderen Speicherchip oder Kassette oder jedes andere Medium, von dem ein Computer lesen kann.
In Bezug auf die hierin beschriebenen Medien, Prozesse, Systeme, Methoden usw. sollte es verstanden werden, dass zwar die Schritte solcher Prozesse usw. beschrieben wurden, wie sie gemäß einer bestimmten geordneten Abfolge auftreten, dass solche Prozesse aber mit den beschriebenen Schritten auch in einer anderen Reihenfolge als der hierin beschriebenen Reihenfolge umgesetzt werden können. Es sollte ferner zu verstehen sein, dass bestimmte Schritte gleichzeitig durchgeführt werden könnten, dass andere Schritte hinzugefügt werden könnten oder dass hierin beschriebene bestimmte Schritte weggelassen werden könnten. Mit anderen Worten dienen die Beschreibungen von Systemen und/oder Prozessen hierin der Veranschaulichung bestimmter Ausführungsformen und sind in keinster Weise als Einschränkung des offenbarten Gegenstands zu verstehen.
Demententsprechend soll verstanden werden, dass die vorstehende Beschreibung nur als veranschaulichend und nicht einschränkend gedacht ist. Viele Ausführungsformen und Anwendungen außer den bereitgestellten Beispielen würden sich für Fachleute auf dem Gebiet aus dem Durchlesen der obigen Beschreibung ergeben. Der Schutzbereich der Erfindung sollte nicht unter Bezugnahme auf die obige Beschreibung bestimmt werden, sondern sollte stattdessen unter Bezugnahme auf hieran angefügte Ansprüche bestimmt werden und/oder in einer hierauf basierten nicht-vorläufigen Patentanmeldung enthalten sein, zusammen mit dem vollen Umfang von Äquivalenten, auf die derartige Ansprüche Anspruch haben. Es ist antizipiert und beabsichtigt, dass künftige Entwicklungen in den hierin erörterten Technologien erfolgen werden und dass die offenbarten Systeme und Verfahren in derartige künftige Ausführungsformen eingebunden werden. Zusammengefasst sollte verstanden werden, dass der offenbarte Gegenstand zu Modifikationen und Variationen imstande ist.
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.11 [0015]

Claims

System, umfassend einen Computer mit einem Prozessor und einem Speicher, wobei der Speicher Anweisungen speichert, welche vom Computer ausführbar sind zum: Sammeln von Daten in Bezug auf eine Fahrzeugbewegung an einer Ampel; Prognostizieren einer ersten Ampelzykluszeit mit einem ersten Wahrscheinlichkeitsmodell der Ampelzykluszeit, wobei das Wahrscheinlichkeitsmodell einen ersten Bereich von Wahrscheinlichkeiten der ersten prognostizierten Ampelzykluszeit anzeigt; Vergleichen der gesammelten Daten mit der prognostizierten Ampelzykluszeit, um basierend auf dem ersten Wahrscheinlichkeitsmodell ein zweites Wahrscheinlichkeitsmodell zu generieren, welches einen zweiten Bereich von Wahrscheinlichkeiten einer zweiten prognostizierten Ampelzykluszeit angibt; Anwenden einer Rauschfunktion auf die gesammelten Daten, um rauschangewandte Daten zu generieren; Aktualisieren des zweiten Wahrscheinlichkeitsmodells für die prognostizierte Ampelzykluszeit durch Anpassen eines Satzes von Wahrscheinlichkeiten des zweiten Wahrscheinlichkeitsmodells mit den rauschangewandten Daten, um ein aktualisiertes zweites Wahrscheinlichkeitsmodell zu generieren; und Bereitstellen, über ein Netz an wenigstens einen Fahrzeugcomputer, eines empfohlenen Fahrzeugbetriebs wenigstens teilweise basierend auf der prognostizierten Ampelzykluszeit, welche vom aktualisierten zweiten Wahrscheinlichkeitsmodell bestimmt wird.
System nach Anspruch 1, wobei der empfohlene Fahrzeugbetrieb empfohlene Fahrmuster für reduzierten Kraftstoffverbrauch umfasst.
System nach Anspruch 2, wobei das empfohlene Fahrmuster eine empfohlene Betriebsgeschwindigkeit umfasst, welche bestimmt wird, so dass ein Fahrzeug die Ampel während eines bestimmten Teils während der Ampelzykluszeit erreicht.
System nach Anspruch 3, wobei das empfohlene Fahrmuster eine Route zu einem Ziel umfasst, welche bestimmt wird, so dass das Fahrzeug die Ampel bei bestimmten Teilen der Ampelzykluszeit erreicht.
System nach Anspruch 1, wobei der empfohlene Fahrzeugbetrieb wenigstens teilweise durch die aktuelle Zeit bestimmt wird.
System nach Anspruch 1, wobei die Anweisungen ferner Anweisungen umfassen, um eine Benachrichtigung mit dem empfohlenen Fahrzeugbetrieb an eine handgehaltene Benutzervorrichtung zu senden.
System nach Anspruch 1, wobei die Anweisungen ferner Anweisungen umfassen, um ein Offset und einen Arbeitszyklus für die Ampel basierend auf der Ampelzykluszeit zu bestimmen.
System nach Anspruch 1, ferner umfassend einen Datensammler, um die Daten in Bezug auf eine Fahrzeugbewegungszeitsteuerung zu sammeln.
System nach Anspruch 1, wobei die Ampelzykluszeit wenigstens teilweise durch die Fahrzeugbewegungszeitsteuerungsdaten bestimmt wird.
System nach Anspruch 1, wobei das Wahrscheinlichkeitsmodell eines von einer Mehrzahl von Wahrscheinlichkeitsmodellen ist, wobei jedes Wahrscheinlichkeitsmodell ausgelegt ist, um die Ampelzeit für einen speziellen Zeitbereich während eines Tages zu prognostizieren.
System nach Anspruch 10, wobei die Anweisungen ferner Anweisungen zum, falls die Daten nach dem Vergleichen der Daten mit der prognostizierten Ampelzykluszeit nicht innerhalb eines Schwellenwerts der prognostizierten Ampelzeit liegen, Auswählen des nächsten der Mehrzahl von Wahrscheinlichkeitsmodellen, Prognostizieren der Ampelzykluszeit mit dem Wahrscheinlichkeitsmodell und Vergleichen der Daten mit der neu prognostizierten Ampelzykluszeit umfassen.
System nach Anspruch 11, wobei die Anweisungen ferner Anweisungen zum, falls keines der Mehrzahl von Wahrscheinlichkeitsmodellen eine prognostizierte Ampelzeit generiert, für welche die Daten innerhalb des Schwellenwerts fallen, Generieren eines neuen Wahrscheinlichkeitsmodells und Anhängen an die Mehrzahl von Wahrscheinlichkeitsmodellen umfassen.
Verfahren, umfassend: Sammeln von Daten in Bezug auf eine Fahrzeugbewegung an einer Ampel; Prognostizieren einer ersten Ampelzykluszeit mit einem ersten Wahrscheinlichkeitsmodell der Ampelzykluszeit, wobei das Wahrscheinlichkeitsmodell einen ersten Bereich von Wahrscheinlichkeiten der ersten prognostizierten Ampelzykluszeit anzeigt; Vergleichen der gesammelten Daten mit der prognostizierten Ampelzykluszeit, um basierend auf dem ersten Wahrscheinlichkeitsmodell ein zweites Wahrscheinlichkeitsmodell zu generieren, welches einen zweiten Bereich von Wahrscheinlichkeiten einer zweiten prognostizierten Ampelzykluszeit angibt; Anwenden einer Rauschfunktion auf die gesammelten Daten, um rauschangewandte Daten zu generieren; Aktualisieren des zweiten Wahrscheinlichkeitsmodells für die prognostizierte Ampelzykluszeit durch Anpassen eines Satzes von Wahrscheinlichkeiten des zweiten Wahrscheinlichkeitsmodells mit den rauschangewandten Daten, um ein aktualisiertes zweites Wahrscheinlichkeitsmodell zu generieren; und Bereitstellen, über ein Netz an wenigstens einen Fahrzeugcomputer, eines empfohlenen Fahrzeugbetriebs wenigstens teilweise basierend auf der prognostizierten Ampelzykluszeit, welche vom aktualisierten zweiten Wahrscheinlichkeitsmodell bestimmt wird.
Verfahren nach Anspruch 13, wobei der empfohlene Fahrzeugbetrieb empfohlene Fahrmuster für reduzierten Kraftstoffverbrauch umfasst.
Verfahren nach Anspruch 14, wobei das empfohlene Fahrmuster eine empfohlene Betriebsgeschwindigkeit umfasst, welche bestimmt wird, so dass ein Fahrzeug die Ampel während eines bestimmten Teils der Ampelzykluszeit erreicht.
Verfahren nach Anspruch 15, wobei das empfohlene Fahrmuster eine Route zu einem Ziel umfasst, welche bestimmt wird, so dass das Fahrzeug die Ampeln bei bestimmten Teilen der Ampelzykluszeit erreicht.
Verfahren nach Anspruch 13, ferner umfassend Bestimmen eines Offsets und eines Arbeitszyklus für die Ampel basierend auf der Ampelzykluszeit.
Verfahren nach Anspruch 13, wobei das Wahrscheinlichkeitsmodell eines von einer Mehrzahl von Wahrscheinlichkeitsmodellen ist, wobei jedes Wahrscheinlichkeitsmodell ausgelegt ist, um die Ampelzeit für einen speziellen Zeitbereich während eines Tages zu prognostizieren.
Verfahren nach Anspruch 13, wobei die Ampelzykluszeit wenigstens teilweise durch die Fahrzeugbewegungszeitsteuerungsdaten bestimmt wird.
Verfahren nach Anspruch 13, wobei das Wahrscheinlichkeitsmodell eines von einer Mehrzahl von Wahrscheinlichkeitsmodellen ist, wobei jedes Wahrscheinlichkeitsmodell ausgelegt ist, um die Ampelzeit für einen speziellen Zeitbereich während eines Tages zu prognostizieren.