DE102015109134A1

DE102015109134A1 - Überwachung des Fahrzeugbetriebs

Info

Publication number: DE102015109134A1
Application number: DE102015109134.8A
Authority: DE
Inventors: Douglas Raymond Martin; Kenneth James Miller
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2014-06-27
Filing date: 2015-06-10
Publication date: 2015-12-31
Also published as: CN105225290A; RU2015125480A

Abstract

Ein Rechner in einem Fahrzeug ist programmiert, um zu bestimmen, dass das Fahrzeug in eine Kreuzungszone eingefahren ist; um Daten in Bezug auf den Betrieb des Fahrzeugs in der Kreuzungszone zu sammeln; um zu bestimmen, dass das Fahrzeug die Kreuzungszone verlassen hat; und um einen aktuellen Fahrerpunktewert zu bestimmen, der zumindest teilweise auf dem Betrieb des Fahrzeugs in der Kreuzungszone basiert.

Description

VERWANDTE ANMELDUNG
Diese Anmeldung ist eine Teilfortsetzung der US-Patentanmeldung, Seriennr. 14/101,815, mit dem Titel “Vehicle Operations Monitoring” (Überwachung des Fahrzeugbetriebs), eingereicht am 10. Dezember 2013, die ihrerseits eine Teilfortsetzung der US-Patentanmeldung, Seriennr. 13/959057, mit dem Titel “Rapid Approach Detector” (Detektor von rascher Annäherung) eingereicht am 5. August 2013 war. Die Inhalte jeder der vorgenannten US-Patentanmeldungen sind hierin durch Bezugnahme vollumfänglich aufgenommen.
ALLGEMEINER STAND DER TECHNIK
Vorfälle in einem Fahrzeug, wie beispielsweise eine Kollision oder ein Fahrzeugunfallvorfall, und auch Fahrvorfälle, die Verhaltensweisen zeigen, die zu Kollisionen oder Unfällen führen können, können sich auf Versicherungsprämien und/oder die Möglichkeit, eine Versicherung zu erhalten, auswirken. Leider gibt es derzeit keine Mechanismen zur Identifikation von Ereignissen, welche die Sicherheit eines Fahrzeugs beeinträchtigen und/oder sich auf Versicherungsprämien auswirken können, und zur Bestimmung der Verantwortung des Fahrzeugführers für Vorfälle.
ZEICHNUNGEN
1 ist ein Blockdiagramm eines beispielhaften Systems zur Überwachung des Fahrzeugbetriebs.
2 ist ein Blockdiagramm, das ein sich rasch einem zweiten Fahrzeug näherndes erstes Fahrzeug zeigt.
3 ist ein Diagramm eines beispielhaften Prozesses zur Identifikation und Meldung von Vorfällen rascher Annäherung.
4 ist ein Diagramm eines beispielhaften Prozesses zur Überwachung des Fahrzeugbetriebs.
5 ist ein Diagramm eines beispielhaften Prozesses, der aus dem Prozess aus 4 fortgesetzt werden kann, zur Überwachung und Bereitstellung von Feedback bezüglich des Fahrzeugbetriebs.
6 ist ein Diagramm eines beispielhaften Prozesses zur Identifikation und Meldung von Fahrzeuginstabilität.
7 ist ein Diagramm eines beispielhaften Prozesses zur Identifikation und Meldung von Kreuzungsvorfällen.
AUSFÜHRLICHE BESCHREIBUNG
ÜBERBLICK ÜBER DAS SYSTEM
1 ist ein Blockdiagramm eines beispielhaften Systems 100 zur Überwachung des Fahrzeugbetriebs. Ein Fahrzeug 101 umfasst einen Fahrzeugrechner 105, der konfiguriert ist, um Informationen, z. B. Benutzungsdaten 115, von einem oder mehreren Datensammlern 110 bezüglich verschiedener Metriken des Fahrzeugs 101 zu empfangen, die für den Betrieb des Fahrzeugs 101 relevant sind, z. B. eine Annäherung des Fahrzeugs 101 an ein oder mehrere andere Fahrzeuge oder stationäre Objekte, einen “Auffahr”-Abstand zwischen dem Fahrzeug 101 und einem oder mehreren anderen Fahrzeugen, Abweichungen eines Fahrzeugs 101 von einem gleichmäßigen Weg auf einer Fahrbahn oder einer Spur in einer Fahrbahn, das Verhalten eines Fahrzeugs 101 in Kreuzungen und in deren Umfeld usw.
Zum Beispiel können bezüglich einer Annäherung des Fahrzeugs 101 an ein oder mehrere andere Fahrzeuge oder Objekte solche Metriken eine Geschwindigkeit (d. h. Schnelligkeit) des Fahrzeugs 101, einen Abstand des Fahrzeugs 101 von einem oder mehreren anderen Objekten, wie beispielsweise Fahrzeugen, stationären Objekten usw., umfassen. Der Rechner 105 kann auch Anweisungen zur Identifikation eines potentiellen Kollisionsvorfalls umfassen, der über ein Netz 120 an einen Server 125 gemeldet und in einem Datenspeicher 130 gespeichert werden kann. Außerdem können Informationen in Bezug auf einen potentiellen Kollisionsvorfall auf einer Anzeige des Fahrzeugrechners 105, einer Benutzervorrichtung 150 oder einer anderen Client-Vorrichtung angezeigt werden.
Zusätzlich kann der Server 125 Informationen in Bezug auf einen potentiellen Kollisionsvorfall und/oder in Bezug auf den Betrieb des Fahrzeugs 101 nutzen, wobei z. B. ein Fahrzeugführer das Fahrzeug 101 auf eine Weise betreibt, mit der er Kollisionsvorfälle wahrscheinlich vermeidet, um Informationen in Bezug auf mögliche Versicherungsprämien und/oder -policen zu erhalten. Außerdem kann der Server 125 dem Führer eines Fahrzeugs 101 einen Punktewert oder eine Bewertung bereitstellen, und ein solcher Punktewert oder eine solche Bewertung kann von dem Führer des Fahrzeugs 101 und/oder automatisch von dem Server 125 über eine oder mehrere Remote-Sites 160, z. B. soziale Netzwerke, wie beispielsweise Facebook, Google+ oder dergleichen, geteilt werden. Der Punktewert oder die Bewertung kann verwendet werden, um ein Angebot für eine Versicherungsprämie bereitzustellen und/oder um eine Prämie für die Versicherung des Fahrzeugs 101 auf Echtzeitbasis oder nahezu Echtzeitbasis anzupassen (z. B. einen “Rabatt für sicheres Fahren” erhöhen oder senken).
BEISPIELHAFTE SYSTEMELEMENTE
Ein Fahrzeug 101 umfasst einen Fahrzeugrechner 105, der im Allgemeinen einen Prozessor und einen Speicher umfasst, wobei der Speicher eine oder mehrere Arten von computerlesbaren Medien umfasst und Anweisungen speichert, die vom Prozessor ausführbar sind, um verschiedene Operationen, einschließlich der hierin offenbarten, auszuführen. Der Speicher des Rechners 105 speichert im Allgemeinen außerdem Benutzungsdaten 115. Der Rechner 105 ist im Allgemeinen zur Datenübertragung auf einem Controller-Area-Network-(CAN-)Bus oder dergleichen konfiguriert. Der Rechner 105 kann auch eine Verbindung mit einem On-Board-Diagnose-Anschluss (OBD-II) aufweisen. Über den CAN-Bus, den OBD-II und/oder andere Draht- oder Drahtlosmechanismen kann der Rechner 105 Meldungen an verschiedene Vorrichtungen in einem Fahrzeug übermitteln und/oder Meldungen von den verschiedenen Vorrichtungen, z.B. Reglern, Aktuatoren, Sensoren usw., einschließlich den Datensammlern 110, empfangen. Außerdem kann der Rechner 105 zur Kommunikation mit dem Netz 120 konfiguriert sein, das wie nachstehend beschrieben verschiedene Draht- und/oder Drahtlosnetztechnologien umfassen kann, z.B. Mobilfunk-, Bluetooth-, Draht- und/oder Drahtlospaketnetze usw.
Ferner umfasst der Rechner 105 im Allgemeinen eine Mensch-Maschine-Schnittstelle (HMI), die einen oder mehrere Mechanismen umfassen kann, wie sie für einen humanen Führer des Fahrzeugs 101 bekannt sind, um Input für den Rechner 105 bereitzustellen und Output von diesem zu empfangen. Zum Beispiel könnte eine HMI des Rechners 105 einen Touchscreen oder dergleichen umfassen, der eine graphische Benutzeroberfläche (GUI), ein interaktives Sprachausgabesystem (IVR) und/oder andere optische Signale, Bildschirme, Geräusche, haptische Ausgabemedien usw. bereitstellt.
Datensammler 110 können verschiedene Vorrichtungen umfassen. Beispielsweise können verschiedene Steuereinrichtungen in einem Fahrzeug als Datensammler 110 arbeiten, um Daten 115 über den CAN-Bus bereitzustellen, z.B. Daten 115 bezüglich der Fahrzeuggeschwindigkeit, -beschleunigung usw. Ferner können Sensoren oder dergleichen, eine Globale Positionierungssystemanlage (GPS) usw. in einem Fahrzeug bereitgestellt werden und als Datensammler 110 konfiguriert sein, um Daten direkt an den Rechner 105 bereitzustellen, z.B. über eine Draht- oder Drahtlosverbindung. Sensordatensammler 110 können Mechanismen, wie beispielsweise RADAR, LADAR, Sonar usw. umfassen, d. h. Sensoren, die eingesetzt werden können, um eine Position eines Fahrzeugs 101 in Bezug auf andere Objekte, eine Position in einer Fahrbahn, z. B. einer Spur usw., zu messen Zum Beispiel könnte eine Metrik, die durch Benutzungsdaten 115 bestimmt werden könnte, die von einem Sensordatensammler 110 erhalten werden, den nachstehend erläuterten Abstand zwischen dem Fahrzeug 101 und einem zweiten Fahrzeug 101, einem stationären Objekt usw., umfassen.
Benutzungsdaten 115 können verschiedene Daten umfassen, die in einem oder mehreren Fahrzeugen basierend auf Aktivitäten eines bestimmten Konsumenten gesammelt werden, d. h. Fahrzeugbenutzerdaten 115 werden im Allgemeinen unter Verwendung eines oder mehrerer Datensammler 110 gesammelt und können zusätzliche Daten umfassen, die im Rechner 105 und/oder am Server 125 aus diesen berechnet werden. Im Allgemeinen können die Benutzungsdaten 115 beliebige Daten umfassen, die von einer Sammelvorrichtung 110 gewonnen werden können und/oder aus solchen Daten berechnet werden können und die für die Kraftübertragungsnutzung eines Fahrzeugs relevant sein können. Beispielsweise können Benutzungsdaten 115 Fahrzeuggeschwindigkeit, Fahrzeugbeschleunigung, einen Abstand von einem anderen Fahrzeug 101 usw. umfassen. Im Allgemeinen ist ein Benutzerdatum 115, wie nachstehend erläutert, einem bestimmten Zeitpunkt zugeordnet.
Das Netz 120 stellt einen oder mehrere Mechanismen dar, über die ein Fahrzeugrechner 105 mit einem Remote-Server 125 kommunizieren kann. Demgemäß kann das Netz 120 einer oder mehrere aus verschiedenen Draht- oder Drahtlosdatenübertragungsmechanismen sein, einschließlich einer beliebigen gewünschten Kombination aus verschiedenen Draht-(z.B. Kabel und Faser) und/oder Drahtlos-(z.B. Mobilfunk, drahtlos, Satellit, Mikrowellen und Funkfrequenz)Datenübertragungsmechanismen und (einer) beliebigen gewünschten Netztopologie (oder -topologien, wenn mehrere Datenübertragungsmechanismen verwendet werden). Beispielhafte Datenübertragungsnetze umfassen Drahtlosdatenübertragungsnetze (z.B. unter Verwendung von Bluetooth, IEEE 802.11 usw.), lokale Netze (LAN) und/oder Weitverkehrsnetze (WAN), einschließlich des Internets, die Datenübertragungsdienste bereitstellen.
Der Server 125 kann ein oder mehrere Rechnerserver sein, die im Allgemeinen jeweils zumindest einen Prozessor und zumindest einen Speicher umfassen, wobei der Speicher Anweisungen speichert, die vom Prozessor ausführbar sind, einschließlich Anweisungen zur Ausführung verschiedener der hierin beschriebenen Schritte und Prozesse. Der Server 125 kann einen Datenspeicher 130 umfassen oder zur Datenübertragung mit einem solchen verbunden sein, um Benutzungsdaten 115, Datensätze bezüglich potentieller Vorfälle, die wie hierin beschrieben erzeugt werden, usw. zu speichern.
Eine Benutzervorrichtung 150 kann eine beliebige von verschiedenen Rechenvorrichtungen sein, die einen Prozessor und einen Speicher sowie Datenübertragungsfähigkeiten umfassen. Beispielsweise kann die Benutzervorrichtung 155 ein tragbarer Rechner, ein Tablet-Rechner, ein Smartphone usw. sein, die zur drahtlosen Datenübertragung unter Verwendung von IEEE-802.11-, Bluetooth- und/oder Mobilfunk-Datenübertragungsprotokollen fähig sind. Außerdem kann die Benutzervorrichtung 150 solche Datenübertragungsfähigkeiten nutzen, um über das Netz 120 und auch direkt mit einem Fahrzeugrechner 105, z. B. unter Verwendung von Bluetooth, Daten zu übertragen.
Eine Remote-Site 160 kann eine Stelle im Internet sein, z. B. eine soziale Netzwerk-Site, wie beispielsweise Facebook, Google+ usw. Remote-Sites 160 können Daten von Führern von Fahrzeugen 101 empfangen, einschließlich Benutzungsdaten 115, und/oder Zusammenfassungen davon oder Meldungen, die damit zusammenhängen, und/oder sie können Daten zur Anzeige auf einer HMI eines Rechners 105 oder einer Anzeige einer Vorrichtung 150 bereitstellen.
BEISPIELHAFTE PROZESSABLÄUFE
4 ist ein Diagramm eines beispielhaften Prozesses 400 zur Überwachung des Fahrzeugbetriebs 101.
Der Prozess 400 beginnt in einem Block 405, in dem der Rechner 105 Daten 115 von Datensammlern 110 empfängt. Beispiele für solche Daten 115 werden oben genannt und außerdem werden unten ausführliche Beispiele in Bezug auf den Prozess 300 aus 3 bereitgestellt.
In einem Block 410 evaluiert der Rechner 105 als Nächstes Fahrmuster des Fahrzeugs 101. Zum Beispiel kann der Rechner 105 versuchen, Indizien für sichere und/oder unsichere Fahrmuster zu identifizieren, z. B. eine Annäherung des Fahrzeugs 101 an ein oder mehrere andere Fahrzeuge oder stationäre Objekte, bei denen die Annäherungsgeschwindigkeit höher ist als eine, die als sicher bestimmt wurde, wie z. B. unten in Bezug auf 2 und 3 genauer erläutert wird. Andere Beispiele für Fahrmuster, für die Daten 115 evaluiert werden könnten, umfassen einen “Auffahr”-Abstand zwischen dem Fahrzeug 101 und einem oder mehreren anderen Fahrzeugen, der kleiner ist als ein solcher Abstand angesichts einer Geschwindigkeit des Fahrzeugs 101 sein sollte, Abweichungen eines Fahrzeugs 101 von einem gleichmäßigen Weg in einer Fahrbahn oder einer Spur in einer Fahrbahn, Verhalten eines Fahrzeugs 101 in Kreuzungen und deren Umfeld (z. B. nicht reduzieren oder tatsächlich erhöhen der Geschwindigkeit in und durch eine Kreuzung usw.) usw.
Wie oben erwähnt und wie nachstehend ausführlich in Bezug auf den beispielhaften Prozess 300 erörtert, bestimmt der Rechner 105 im Allgemeinen als Teil der Evaluierung von Daten 115, die in dem Block 410 durchgeführt wird, außerdem auch einen Fahrerpunktewert oder eine Bewertung. Ein ausführliches Beispiel zum Bestimmen eines Fahrerpunktewerts wird unten in Bezug auf 3 bereitgestellt und andere Beispiele werden in Bezug auf 6 und 7 bereitgestellt.
Ferner kann in dem Beispiel aus 1 der Fahrerpunktewert auf einer Anzahl von Vorfällen, die innerhalb eines bestimmten Zeitraums stattfinden, und/oder einer Größe des Werts, der mit solchen Vorfällen assoziiert ist, basieren. Ein Vorfallswert könnte eine positive Größe haben, wenn er gutes Fahrverhalten widerspiegelt, und eine negative Größe, wenn er schlechtes Fahrverhalten widerspiegelt. Ferner könnte eine positive oder negative Größe gemäß einer Schwere eines Vorfalls bestimmt werden. Wenn beispielsweise eine Annäherungsgeschwindigkeit zwischen einem Fahrzeug 101 und einem anderen Objekt einen vorbestimmten Wert überschritten hätte und der Vorfallswert eine erste negative Größe sein könnte, während wenn eine Annäherungsgeschwindigkeit zwischen dem Fahrzeug 101 und einem anderen Objekt einen zweiten vorbestimmten Wert, der größer ist als der erste vorbestimmte Wert, überschritten hätte, dann könnte der Vorfallswert eine zweite negative Größe aufweisen, die einen größeren absoluten Wert aufweist als die erste Größe. Positives Verhalten in Bezug auf Annäherungsgeschwindigkeiten könnte auf ähnliche Weise mit Vorfallswerten mit positiven Größen quantifiziert werden. In jedem Fall könnte, wenn ein Fahrer eine Anzahl von Vorfällen rascher Annäherung in einem Zeitraum hat, ein Fahrerpunktewert basierend auf den Vorfällen rascher Annäherung berechnet werden, wobei ein Beispiel für eine solche Bestimmung nachfolgend in Bezug auf 3 ausführlicher bereitgestellt wird.
Ferner können mehrere Fahrerpunktewerte für einen einzigen Fahrer eines Fahrzeugs 101 bestimmt werden. Zum Beispiel zeigt die nachfolgend erörterte 3 einen beispielhaften Fahrerpunktewert in Bezug auf Annäherungsgeschwindigkeiten zwischen einem Fahrzeug 101 und einem anderen Objekt. 6 und 7 zeigen weitere Beispiele. Andere Fahrerpunktewerte könnten sich auf andere Fahrerverhalten beziehen, z. B. Auffahren, Spurwechsel, Halten der Spur, Bremsweg, mittlere Geschwindigkeit bezogen auf eine ausgeschilderte Geschwindigkeitsbegrenzung usw.
In einem Block 415 bestimmt der Rechner 105 als Nächstes, ob der Fahrerpunktewert oder die Bewertung positiv oder negativ ist, d. h. ob der Punktewert gute oder schlechte Fahrmuster widerspiegelt. Zum Beispiel könnte der Rechner 105 Parameter gespeichert haben, die einen Schwellenwert oder einen Bereich von Werten für einen Fahrerpunktewert identifizieren, um als positiv, negativ, gut, schlecht usw. angesehen werden. In einigen Ausführungsformen, einschließlich der nachfolgend in Bezug auf 3 beschriebenen beispielhaften Bestimmung eines Fahrerpunktewerts, wird ein Fahrerpunktewert ein numerischer Wert zwischen null und eins sein. Demgemäß könnte eine Zahl zwischen null und eins, z. B. 0,5 einen Schwellenwert zur Bestimmung bereitstellen, ob ein Fahrerpunktewert in einem “guten“ oder “positiven” Bereich oder in einem “schlechten“ oder „negativen“ Bereich war. Alternativ könnte zum Beispiel ein “schlechter” Fahrerpunktewert einer sein, der unter einem ersten Schwellenwert liegt, z. B. 0,4, während ein “guter” Fahrerpunktewert einer sein könnte, der oberhalb eines bestimmten Schwellenwerts, z. B. 0,6. liegt. Fahrerpunktewerte an oder zwischen den beiden Schellenwerten könnten ignoriert werden.
Wenn der Rechner 105 ferner konfiguriert ist, um mehrere Fahrerpunktewerte zu bestimmen, könnten Schwellenwerte für verschiedene Arten oder Kategorien von Fahrerpunktewerten verschieden sein. Ein Fahrerpunktewert in Bezug auf Annäherungsgeschwindigkeiten an oder über einem Schwellenwert von 0,6 könnte beispielsweise als “gut” angesehen werden, während ein Fahrerpunktewert in Bezug auf die Einhaltung von ausgeschilderten Geschwindigkeitsbegrenzungen an oder über einem Schwellenwert als “gut” angesehen werden könnten, wenn er an oder über einem Schwellenwert von 0,5 liegt.
Im Allgemeinen können die in dem Rechner 105 gespeicherten vorbestimmten Fahrerpunktewertschwellenwerte auf Schwellenwerten basieren, die als für die Fähigkeit eines Fahrers eines Fahrzeugs 101 relevant bestimmt wurden, um bestimmte Versicherungspolicen und/oder -prämien zu erhalten. Gutes Fahrverhalten, wie das Halten sicherer Geschwindigkeiten, das Halten eines sicheren Abstands zu anderen Fahrzeugen usw., kann beispielsweise mit dem Erhalt vorteilhafter Versicherungspolicen und/oder -prämien assoziiert sein. Entsprechend kann schlechtes Fahrverhalten, wie beispielsweise “Auffahren”, d. h. anderen Fahrzeugen zu nah zu folgen, das Halten unsicherer Geschwindigkeiten usw., einen Fahrer eines Fahrzeugs 101 daran hindern, günstige Versicherungspolicen und/oder -prämien zu erhalten. Demgemäß bezieht sich die Bestimmung des Blocks 415 im Allgemeinen auf die Identifikation von gutem und schlechtem Fahrverhalten und insbesondere auf Fahrverhalten, das wahrscheinlich eine Auswirkung auf die Fähigkeit hat, eine Versicherungspolice und/oder Prämien für eine Versicherungspolice zu erhalten.
In jedem Fall wird dann, wenn der Fahrerpunktewert positiv oder gut ist, als Nächstes ein Block 420 ausgeführt. Wenn der Fahrerpunktewert negativ oder schlecht (oder in der vorliegenden beispielhaften Ausführungsform neutral) ist, dann wird als Nächstes ein Block 425 ausgeführt.
In dem Block 420 kann der Rechner 105, z. B. über eine HMI, wie oben erörtert, eine Nachricht oder eine Warnung für den Fahrer des Fahrzeugs bereitstellen, die den Fahrer über den bestimmten Fahrerpunktewert informiert. Ferner kann der Rechner 105 zeitgleich mit dem Betrieb des Fahrzeugs 101, z. B. in Echtzeit oder nahezu Echtzeit, unter Bestimmung des Fahrerpunktewerts, der bestimmt wird, während das Fahrzeug 101 betrieben wird, dem Fahrer eine Gelegenheit bieten, ein Angebot für eine Fahrzeugversicherung zu erhalten, das auf dem Fahrerpunktewert basiert, und/oder eine Versicherungsprämie basierend auf dem Fahrerpunktewert, einschließlich auf Echtzeitbasis oder nahezu Echtzeitbasis, angepasst zu bekommen. Die HMI könnte beispielsweise eine Meldung, wie etwa “Guter Fahrerpunktewert! Würden Sie das Sammeln von Informationen erlauben, um festzustellen, ob Sie bei Ihrer Autoversicherung Geld sparen können?” bereitstellen. Mit anderen Worten bitten die HMI in Block 420 im Allgemeinen einen Nutzer, das Sammeln von Informationen für die Übertragung an den Server 125 und/oder andere Ziele zu erlauben, um zu bestimmen, ob die Fahrmuster ein Angebot für oder eine Anpassung einer Autoversicherungsprämie rechtfertigen.
Im Block 425 kann der Rechner 105, z. B. über eine HMI oder dergleichen, größtenteils wie oben in Bezug auf den Block 420 beschrieben, eine Nachricht oder eine Warnung an den Fahrer des Fahrzeugs 101 bereitstellen, die den Fahrer über den bestimmten Fahrerpunktewert informiert. Jedoch wird in dem Block 425 keine Möglichkeit für ein Versicherungsprämienangebot und/oder eine Prämienanpassung bereitgestellt, weil ein Fahrerpunktewert nicht darauf schließen lässt, dass eine gute Prämie möglich wäre, es sei denn, der Fahrerpunktewert verbesserte sich. Stattdessen kann die HMI in dem Block 425 verwendet werden, um einen Hinweis auf einen negativen Fahrerpunktewert und/oder Tipps oder Vorschläge für die Verbesserung eines Fahrerpunktwerts bereitzustellen. Die HMI könnte beispielsweise eine Nachricht, wie etwa “Schlechter Fahrerpunktewert. Um ihren Fahrerpunktewert zu verbessern, sollten Sie nicht so nahe auf andere Autos auffahren. Würden Sie das Sammeln von Informationen erlauben, um festzustellen, ob Sie ihr Fahrverhalten verbessern und sich möglicherweise für eine bessere Autoversicherung qualifizieren können?“ In anderen Worten kann die HMI in Block 425 einen Nutzer über Wege informieren, um Fahrmuster zu verbessern, sowie die Genehmigung für das Sammeln von Informationen zu erbitten, die an den Server 125 und/oder andere Ziele übertragen werden könnten, um zu bestimmen, ob Fahrmuster ein Angebot für die Autoversicherung rechtfertigen.
In einem Block 430 bestimmt der Rechner 105, ob ein Nutzer in einem der Blöcke 420, 425 eine Eingabe bereitgestellt hat, die die Genehmigung oder die Akzeptierung der Überwachung von Fahrmustern anzeigt, um z. B. zu bestimmen, ob ein Angebot für eine Versicherungspolicenprämie erhalten werden kann. Wenn der Führer des Fahrzeugs 101 keine Eingabe bereitgestellt hat, die die Akzeptierung der vorgeschlagenen Überwachung anzeigt, dann wird der Prozess 400 mit einem Block 450 fortgesetzt. Ansonsten wird der Prozess 400 mit einem Block 435 fortgesetzt.
In dem Block 435 fragt der Rechner 105 den Server 125, z. B. über das Netzwerk 120, dahingehend ab, ob ein vorteilhaftes Prämienangebot und/oder eine Prämienanpassung für den Führer des Fahrzeugs 101 erhalten werden können. Zum Beispiel kann die Abfrage Marke, Modell, Jahr usw. eines Fahrzeugs 101, das Alters des Führers von Fahrzeug 101, dessen Geschlecht, seine Einträge in der Verkehrssünderdatei identifizieren, wobei ein oder mehrere Fahrmuster (z. B. Annäherungsgeschwindigkeiten, Halten der Spur, Auffahren usw.) usw. evaluiert werden. Der Server 125 kann seinerseits andere Rechner, einschließlich eine oder mehrere Remote-Sites 160 abfragen, z. B. Rechner, die von Versicherungsunternehmen, Regierungsstellen usw. unterhalten werden. Um beispielsweise ein mögliches Prämienangebot oder -angebote zu bestimmen, kann der Server 125 nach Versicherungspolicen suchen, die mit Prämienrabatten oder vorteilhaften Prämien angeboten werden, die auf einem oder mehreren Fahrmustern, z. B. dem Einhalten einer Geschwindigkeitsbegrenzung, dem Einhalten sicherer Annäherungsgeschwindigkeiten usw., basieren. Der Server 125 wird dann allgemein konfiguriert, um zu bestimmen, ob eine vorteilhafte Versicherungspolice für einen Fahrer eines Fahrzeugs 101 basierend auf einem Fahrerpunktewert und/oder identifizierten Fahrmuster in Frage kommt, und wenn eine oder mehrere mögliche Policen identifiziert werden, Informationen in Bezug auf spezifische Fahrmuster, z. B. spezifische Fahrerpunktewerte, zu erhalten, die dazu führen würden, eine Versicherungspolice mit einer bestimmten Prämie erhalten zu können. Um zu bestimmen, ob eine günstige Anpassung, d. h., ein Rabatt für “sicheres Fahren” oder dergleichen, angewendet werden kann, kann der Server 12 entsprechend den Fahrerpunktewert evaluieren und bestimmen, ob für ein aktuelles Fahrzeug 101 und/oder eine Fahrerversicherungspolice, der Fahrerpunktewert oder die Fahrerpunktewerte für einen Echtzeit- oder nahezu Echtzeit-Rabatt qualifizieren.
In einem Block 440 stellt der Server 125 als Nächstes bereit, und der Rechner 105 empfängt, eine Antwort auf die Anfrage von dem Rechner 105, die in Block 435 gestellt wurde. Zum Beispiel kann der Server 125 den Rechner 105 informieren, ob eine oder mehrere mögliche Versicherungspolicen basierend auf dem Fahrerpunktewert des Fahrers des Fahrzeugs 101 und/oder identifizierten Fahrmustern identifiziert wurden. Ferner kann der Server 125 in einer Nachricht an den Rechner 105 Parameter oder dergleichen zum Erhalten einer oder mehrerer Versicherungspolicen aufnehmen. Zum Beispiel könnte ein Fahrerpunktewert bereitgestellt werden, der erforderlich ist, um eine Versicherungspolice und/oder eine bestimmte Prämie, z. B. eine rabattierte Prämie, für eine angebotene Police zu erhalten. Zusätzlich und/oder alternativ könnte ein Parameter für eine Komponente eines Fahrerpunktewerts bereitgestellt werden, z. B. könnte ein mittlerer Auffahrabstand bei einer gegebenen Geschwindigkeit vorgeschrieben werden, um eine Versicherungspolice und/oder -prämie zu erhalten. Entsprechend könnten, wie oben erwähnt, mehrere Fahrerpunktwerte für einen einzigen Fahrer eines Fahrzeugs 101 bestimmt werden, wobei sich jeder der mehreren Fahrerpunktwerte auf ein bestimmtes Fahrerverhalten, z. B. Auffahren, Annäherungsgeschwindigkeit, Halten der Spur usw., bezieht.
In einigen Ausführungsformen können, wenn in Block 415 ein schlechter oder negativer Fahrerpunktewert identifiziert wurde, die Blöcke 435, 440 weggelassen werden. Das heißt, ein schlechter Fahrerpunktewert zeigt an, dass es unwahrscheinlich ist, dass ein Führer des Fahrzeugs 101 den Vorteil einer vorteilhaften Versicherungspolice und/oder -prämie erhalten kann. Daher ist es weder effizient noch wahrscheinlich, dass es vorteilhaft ist, den Server 125 auf Versicherungsinformationen abzufragen. In solchen Fällen kann jedoch, wie nachfolgend in Bezug auf 5 erörtert, der Server 125 auf diese Weise abgefragt werden, sobald sich ein Fahrerpunktewert (oder Fahrerpunktewerte) verbessert hat (haben). Weiterhin alternativ kann in einigen Ausführungsformen der Prozess 400 direkt von dem Block 425 zu dem Block 450 fortgesetzt werden. Das heißt, in diesen Ausführungsformen kann einem Fahrzeug 101 die Gelegenheit geboten werden, wie nachfolgend in Bezug auf 5 beschrieben, nur dann an der Überwachung teilzunehmen, wenn ein guter Fahrerpunktewert aufgezeichnet wurde.
In einem Bock 445 bestimmt der Rechner 105 als Nächstes, ob die Überwachung von Fahrmustern für eine Meldung an den Server 125 fortgesetzt wird. Wenn beispielsweise keine möglichen Versicherungspolicen und/oder vorteilhafte Prämien von dem Server 125 identifiziert wurden, wie oben beschrieben, dann kann der Rechner 105 bestimmen, keine Überwachung und keine Meldung von Daten 115 an den Server 125 vorzunehmen. Wenn eine Überwachung und Meldung an den Server 125 nicht stattfinden soll, dann wird der Prozess 400 mit dem Block 450 fortgesetzt. Wenn es jedoch möglich ist, dass ein Fahrerpunktewert, der, wie oben in Bezug auf die Blöcke 415, 420 beschrieben, als positiver Fahrerpunktewert bestimmt wurde, zu einem Versicherungsprämienangebot und/oder -rabatt führen könnte, oder wenn ein Fahrerpunktewert, der, wie oben in Bezug auf den Block 415, 425 beschrieben, als negativer Fahrerpunktewert bestimmt wurde, verbessert werden könnte, um zu einem Versicherungsprämienangebot und/oder -rabatt zu führen, dann kann der Prozess 400 in den nachfolgend beschriebenen Prozess 500 übergehen.
Im Block 450 bestimmt der Rechner 105, ob der Prozess 400 fortgesetzt werden soll. Zum Beispiel könnte ein Fahrzeug 101 abgestellt werden, ein Nutzer könnte Eingaben bereitstellen, um den Prozess 400 zu stoppen usw., woraufhin der Prozess 400 enden sollte. Ferner kann, wenn in Block 430 bestimmt wurde, dass ein Nutzer keine Überwachung und Meldung an den Server 125 wünscht, oder wenn in Block 445 bestimmt wurde, dass eine solche Überwachung und Meldung nicht zu einem Versicherungsprämienvorschlag führen wird, dann bestimmt werden, den Prozess 400 zu beenden. Es ist jedoch auch möglich, dass eine weitere Überwachung und Evaluierung von Fahrmustern für einen Nutzer vorteilhaft sein könnte, wobei in diesem Fall der Prozess 400 zu dem Block 405 zurückkehrt.
5 ist ein Diagramm eines beispielhaften Prozesses 500 zum Überwachen und Bereitstellen von Feedback in Bezug auf den Betrieb des Fahrzeugs 101, der von dem Prozess 400 aus 4, d. h. dem Block 445, fortgesetzt werden kann. Der Rechner 105 könnte jedoch den Prozess 500 über einen alternativen Mechanismus, z. B. gemäß einer Nutzereingabe, gemäß einer Anweisung oder einer Eingabe von dem Server 125 usw. starten.
Der Prozess 500 beginnt in einem Block 505, auf den ein Block 510 folgt. In Block 505 empfängt der Rechner 105 Nutzerdaten 115, wie z. B. oben in Bezug auf den Block 405 beschrieben. In Block 510 evaluiert der Rechner 105 Fahrmuster und stellt einen Fahrerpunktewert bereit, wie oben in Bezug auf den Block 410 beschrieben.
Nach dem Block 510 vergleicht der Rechner 105 in einem Block 515 Parameter für Versicherungspolicen, die wie z. B. oben in Bezug auf den Prozess 400 beschrieben, empfangen wurden. Zum Beispiel kann ein Versicherungspolicenparameter einen Fahrerpunktewert oder dergleichen vorschreiben, der einen Fahrer eines Fahrzeugs 101 für eine besondere Versicherungspolice und/oder -prämie, z. B., eine rabattierte Prämie, qualifiziert. Wenn ein Fahrerpunktewert innerhalb eines vorbestimmten Bereichs eines durch einen Parameter vorgeschriebenen Fahrerpunktewerts liegt, könnte der Rechner 105 bestimmen, dass eine Gelegenheit besteht, Feedback an einen Führer eines Fahrzeugs 101 bezüglich des Fahrerpunktewerts bereitzustellen. Alternativ könnte, wenn ein Fahrerpunktewert überhaupt mit einem durch einen Parameter vorgeschriebenen Fahrerpunktewert verglichen werden kann, der Rechner 105 bestimmen, dass es eine Gelegenheit gibt, Feedback bereitzustellen. Wenn Feedback bereitgestellt wird, dann wird der Prozess 500 mit einem Block 520 fortgesetzt. Wenn es jedoch keinen Parameter gibt, mit dem ein Fahrerpunktewert verglichen werden kann, dann wird der Prozess 500 mit einem Block 525 fortgesetzt.
Im Block 520 stellt der Rechner 105, z. B. über eine HMI in dem Fahrzeug 101, über eine Vorrichtung 150 usw. Feedback bezüglich einer Leistung eines Fahrers eines Fahrzeugs 101 bereit. Zum Beispiel könnte der Rechner 105 Informationen in Bezug auf einen Trend in einem bestimmten Fahrerpunktewert bereitstellen, indem eine Verbesserungsquantität und/oder ein Verbesserungsbereich identifiziert wird, die/der erforderlich ist, um sich für eine Versicherungsprämie und/oder -police usw. zu qualifizieren. Eine beispielhafte Nachricht über die HMI könnte eine aus “Glückwunsch! Sie haben sich für eine besondere Prämie qualifiziert”, “Glückwunsch! Sie haben gerade einen Prämienrabatt für sicheres Fahren” erhalten und “Gutes Fahrverhalten – Halten Sie weiterhin einen sicheren Abstand, wenn Sie hinter anderen Autos herfahren und Sie werden sich für eine spezielle Prämie qualifizieren”, sein. Alternativ könnte eine beispielhafte Nachricht lauten “Vorsicht: Gute Versicherungsprämien sind für unsicheres Auffahren nicht verfügbar”. Weiterhin alternativ oder zusätzlich könnte die HMI eine Verbesserungsquantität anzeigen, die erforderlich ist, z. B. “Um Ihren Fahrerpunktewert zu verbessern, erhöhen Sie den Auffahrabstand bei Highway-Geschwindigkeiten um 10 Yards (9,144 m)”.
Im Block 525 bestimmt der Rechner 105, ob der Server 125 auf aktualisierte Informationen zu Versicherungspolicen abgefragt werden soll. Zum Beispiel könnte der Rechner 105 konfiguriert sein, um den Server 125 in regelmäßigen Abständen, z. B. einmal täglich, einmal wöchentlich usw. und/oder gemäß einer Zeitmenge, in der das Fahrzeug 101 betrieben wird, z. B., alle fünf Betriebsstunden, 10 Betriebsstunden usw., abzufragen. Wenn der Server abgefragt werden soll, dann wird der Prozess 500 mit einem Block 530 fortgesetzt. Ansonsten wird ein Block 540 ausgeführt.
In dem Block 530 fragt der Rechner 105 den Server 125 z. B. auf aktualisierte Informationen zu Versicherungspolicen ab, wie es oben in Bezug auf den Block 435 beschrieben wurde.
Im Block 540, der auf den Block 530 folgt, empfängt der Rechner 105 eine Antwort von dem Server 125 und zeigt beliebige geeignete Informationen über eine HMI, über die Vorrichtung 150 usw. an. Wenn sich ein Fahrer eines Fahrzeugs 101 beispielsweise für einen Versicherungspolicen- und/oder Prämienrabatt qualifiziert hat, könnte der Rechner 105 eine Nachricht bereitstellen, die dies in Echtzeit oder nahezu in Echtzeit (d. h. innerhalb von Sekunden oder Minuten nachdem eine Abfrage für den Server 125 bereitgestellt wurde) angibt. Entsprechend könnte der Rechner 105 eine Nachricht bereitstellen, die anzeigt, dass ein Nutzer kurz davor ist, sich für einen Versicherungspolicen- und/oder Prämienrabatt zu qualifizieren, z. B. können sicheres Fahren für einen weiteren Zeitraum, z. B. 20 Fahrstunden usw., den Nutzer auf diese Weise qualifizieren.
Nach entweder dem Block 525 mit einem Block 535, kann der Block 540 ausgeführt werden. In Block 540, ähnlich dem oben beschriebenen Block 450, bestimmt der Rechner 105, ob der Prozess 500 fortgesetzt werden soll. Wenn ja, kehrt der Prozess 500 zu dem Block 505 zurück. Ansonsten endet der Prozess 500.
2 wird bereitgestellt, um ein Szenario zu zeigen, bei dem der beispielhafte Prozess 300, der nachfolgend in Bezug auf 3 erörtert wird, zur Identifikation und Meldung von Vorfällen rascher Annäherung durchgeführt werden kann. 2 ist ein Blockdiagramm, das ein erstes Fahrzeug 101a zeigt, das sich einem zweiten Fahrzeug 101b nähert. Wie in 2 gezeigt, kann sich das erste Fahrzeug 101a mit einer ersten Geschwindigkeit (mit V bezeichnet) fortbewegen, während sich das zweite Fahrzeug mit einer zweiten Geschwindigkeit (mit Vf bezeichnet) fortbewegt. Ein Abstand (mit Df bezeichnet) zwischen dem ersten Fahrzeug 101a und dem zweiten Fahrzeug 101b, das sich in diesem Beispiel vor dem ersten Fahrzeug 101a befindet, kann durch einen oder mehreren Datensammler 110 gemessen werden, wie nachstehend erläutert ist. Ausgehend von der jeweiligen Geschwindigkeit der beiden Fahrzeuge und dem Abstand Df kann die Annäherungsgeschwindigkeit Vc, d.h. die Geschwindigkeit, mit der sich die Fahrzeuge 101 einander nähern, berechnet werden. Die Annäherungsgeschwindigkeit Vc und andere, nachstehend erläuterte Faktoren, können verwendet werden, um zu bestimmen, ob ein potentieller Vorfall, z.B. ein potentieller Kollisionsvorfall, identifiziert werden soll.
3 ist ein Diagramm eines beispielhaften Prozesses 300 zur Identifikation und Meldung von Vorfällen rascher Annäherung. Es versteht sich jedoch, dass einige oder alle Prozesse 300 alternativ oder zusätzlich auf andere Arten von Vorfällen angewendet werden könnten. Zum Beispiel könnten Auffahrvorfälle, Spurabweichungsvorfälle usw., detektiert und/oder in eine Berechnung des Fahrerpunktewerts DS, der in Bezug auf Prozess 300 erörtert wurde, aufgenommen werden. Bestimmte Daten 115 und/oder Berechnungen wären für einen Fahrerpunktewert DS verschieden, der ganz oder teilweise auf anderen Arten von Vorfällen basiert, aber andere Abschnitte des Prozesses 300 können größtenteils so sein, wie hierin beschrieben und dargestellt.
Der Prozess 300 beginnt in einem Block 305, in dem einer Variable PI eines „potentiellen Vorfalls“ ein Initialwert von null zugewiesen und ein Zeitmesser gestartet wird. Außerdem wird auch einer Variable PI_total, die nachstehend genauer erläutert ist, ein Initialwert von null zugewiesen. Normalerweise beginnt der Prozess 300 und der Zeitmesser wird gestartet, wenn eine Fahrt beginnt, z.B. wenn ein Fahrzeug 101 gestartet wird, woraufhin der Rechner 105 gestartet wird. Demgemäß beginnt der Zeitmesser mit Beginn einer Fahrt Zeit zu messen, beispielsweise eine Reihe von Zeitindizes bereitzustellen.
In einem Block 310 stellen die Datensammler 110 als Nächstes dem Rechner 105 Daten bereit, die anzeigen, dass ein Objekt nahe beim Fahrzeug 101 detektiert wurde. Für die Zwecke von Block 310 könnte „nahe“ als Abstandsschwellwert definiert sein, z.B. fünf Fuß, 10 Fuß, 50 Fuß usw. Im Allgemeinen kann das andere Objekt ein weiteres Fahrzeug sein, das andere Objekt kann aber auch ein stationäres oder sich langsam bewegendes Objekt, wie z.B. eine Person, ein Gebäude, ein Baum, ein Zaun usw. sein.
In einem Block 315 empfängt der Rechner 105 als Nächstes, z.B. über CAN-Bus-Datenübertragungen oder dergleichen, eine Messung der Geschwindigkeit des Fahrzeugs 101 zu einem aktuellen Zeitpunkt, der vom Zeitmesser angegeben wird (Vt). Außerdem empfängt der Rechner 105, z.B. von einem Datensammler 110, wie etwa einer RADAR-Vorrichtung, einer LADAR-Vorrichtung usw., eine Messung des Abstands (Df) zwischen dem Fahrzeug 101 und dem in Block 310 detektierten Objekt. Wie nachstehend zu sehen ist, z.B. in Bezug auf den Block 320, nimmt der Rechner 105 außerdem im Allgemeinen mehrere Messungen des Abstands zwischen dem Fahrzeug 101 und dem Objekt zu unterschiedlichen Zeitpunkten, z.B. Df_t, Df_t-1, vor, wobei Df_t eine aktuelle oder die zuletzt vorgenommene Abstandsmessung darstellt und Df_t-1 eine vorherige Abstandsmessung darstellt. Die Differenz zwischen den Zeiten t und t – 1 kann beispielsweise 1 Sekunde betragen.
In einem Block 320 berechnet der Rechner 105 als Nächstes eine Annäherungsgeschwindigkeit (VC) zwischen dem Fahrzeug 101 und dem Objekt. Die Annäherungsgeschwindigkeit zu einem Zeitpunkt t könnte beispielsweise gemäß der folgenden Formel berechnet werden: VC_t = (Df_t, – Df_t-1)/[t – (t – 1)].
Wenn also Df_t 100 Fuß (30,48 m) wäre und Df_t-1 99 Fuß (30,18 m) wäre und die Differenz zwischen t und t – 1 eine Sekunde betrüge, dann wäre die Annäherungsgeschwindigkeit oder das Annäherungstempo VC ein Fuß (0,3048 m) pro Sekunde oder 1,11 Kilometer pro Stunde (km/h).
In einem Block 325 berechnet der Rechner 105 als Nächstes eine Geschwindigkeit (Vf) des Objekts, z.B. eines weiteren Fahrzeugs, das sich vor dem Fahrzeug 101 befindet. Die Geschwindigkeit Vf kann durch Addieren der Geschwindigkeit des Fahrzeugs 101 mit der Annäherungsgeschwindigkeit berechnet werden, z.B. gemäß der folgenden Formel: Vf_t = V_t + VC_t.
In einem Block 330 bestimmt der Rechner 105 als Nächstes eine Änderungsrate der Geschwindigkeit ΔVf_t, d.h. eine Beschleunigung oder Verlangsamung, des Objekts. Wie an anderer Stelle hierin erläutert, z.B. in Bezug auf den Block 335, kann die Berechnung der Änderungsrate der Geschwindigkeit des weiteren Fahrzeugs oder Objekts zusätzlich zur Annäherungsgeschwindigkeit und zur Geschwindigkeit des Fahrzeugs 101 wichtig bei der Bestimmung sein, ob ein potentieller Vorfall zu identifizieren ist. Beispielsweise kann ein Auto sehr plötzlich vor einem Fahrzeug 101 zum Stehen kommen, d.h. die Geschwindigkeitsänderungsrate des vorderen Autos kann eine rasche Verlangsamung sein, in welchem Fall ein Führer des Fahrzeugs 101 relativ schuldlos an einer Kollision oder potentiellen Kollision sein kann. Ein Wert für die Geschwindigkeitsänderungsrate des Objekts kann gemäß der folgenden Formel berechnet werden: ΔVf_t = Vf_t – Vf_t-1.
Natürlich kann dieser Wert null sein, wenn das Objekt z.B. ein stationäres Objekt ist oder ein Fahrzeug seine Geschwindigkeit nicht ändert.
In einem Block 335 berechnet der Rechner 105 als Nächstes einen Verantwortungsfaktor (AF), bei dem es sich um einen Wert handelt, der den Grad widerspiegelt, in dem der Führer eines Fahrzeugs 101 für einen potentiellen Vorfall verantwortlich gemacht werden sollte, im Gegensatz zum Grad, in dem das Verhalten des Objekts, z.B. eines weiteren Fahrzeugs, dem dieser sich nähert, für den potentiellen Vorfall verantwortlich ist, z.B. aufgrund von raschem Bremsen, rascher Rückwärtsbewegung usw. In einer Ausführungsform umfasst der Verantwortungsfaktor AF zwei Komponenten oder Subfaktoren: AF1, der eine Funktion der Geschwindigkeit des Objekts Vf_t ist, und AF2, der eine Funktion der Geschwindigkeitsänderungsrate des Objekts ΔVf_t ist. Beispiele für die Funktionen für AF1 und AF2 umfassen, wobei die Funktionen ferner bereitstellen können, dass Werte für Vf_t und ΔVf_t unter bestimmten jeweiligen Schwellenwerten, z. B. < –24 km/h, oder ΔVf_t < –16 Kilometer pro Stunde pro Sekunde, jeweils zum Wert null für AF1 und AF2 führen. Der Verantwortungsfaktor AF kann dann basierend auf den Werten seiner Komponenten berechnet werden, z.B. als einfaches Produkt gemäß folgender Formel: AF = AF1 * AF2.
Im Allgemeinen kann ein Verantwortungsfaktor das Produkt von zwei oder mehr Verantwortungssubfaktoren AF1 * AF2 * ... AFn sein. Ein erster Verantwortungssubfaktor, AF1, kann eine Funktion der Geschwindigkeit sein, mit der sich das Objekt, z.B. ein Fahrzeug vor dem Fahrzeug 101, rückwärts bewegt (z.B. eliminiert ein vorderes Fahrzeug, das sich mit –24 km/h rückwärts (angezeigt durch negatives Vorzeichen) bewegt, die Verantwortung, d.h. AF1 = 0). Als weiteres Beispiel könnte der Wert von AF1 1,0 sein, wenn sich das Objekt, z.B. ein weiteres Fahrzeug, nicht bewegt hat. In einem weiteren Beispiel könnte AF1 einen Wert von 0,5 aufweisen, wenn sich das vordere Fahrzeug mit 8 km/h rückwärts bewegt hat. Ferner könnte, wie in Tabelle 1 zu sehen, ein Verantwortungsfaktor AF1 eine Funktion der Geschwindigkeit des Objekts, z.B. des vorderen Fahrzeugs sein:

Vf (km/h) 0 –4 –8 –16 –24

AF1 1 0,75 0,5 0,25 0

Tabelle 1
Ein zweiter beispielhafter Verantwortungsfaktor, AF2, könnte eine Funktion der Verlangsamungsrate des Objekts sein, z.B. könnte eine vorderes Fahrzeug, das seine Geschwindigkeit innerhalb von 1 Sekunde um 16 km/h. verringert, die Verantwortung eliminieren, d.h. AF2 = 0. Als weiteres Beispiel könnten die Werte von AF1 und AF2 jeweils 1,0 sein, wenn das Objekt, z.B. ein weiteres Fahrzeug, sich nicht bewegt hat. Als weiteres Beispiel könnte AF2 einen Wert von 0,5 aufweisen, wenn das vordere Fahrzeug seine Geschwindigkeit innerhalb von 1 Sekunde um 8 km/h. verringert hat. Ferner könnte, wie in Tabelle 2 zu sehen, ein Verantwortungsfaktor AF2 eine Funktion der Geschwindigkeitsänderungsrate des Objekts, z.B. des vorderen Fahrzeugs, sein:

ΔVf (km/h pro Sek.) 0 –8 –16 –24 –32

AF2 1 0,75 0,5 0,25 0

Tabelle 2
Andere Verantwortungsfaktoren (AF3 ... AFn) sind ebenfalls möglich und könnten auf Faktoren wie einem Fahrzeug, das unerwarteterweise auf die Spur des Fahrzeugs 101 wechselt, detektierten Straßenhindernissen usw., basieren.
Nach dem Block 335 berechnet der Rechner 105 als Nächstes in einem Block 340 einen Wert eines potentiellen Vorfalls (PI) in Bezug auf die Zeit t. Der PI-Wert könnte beispielsweise gemäß einer Logik berechnet werden, die den PI-Wert auf null hält, bis die Annäherungsgeschwindigkeit VCt einen bestimmten Schwellenwert, z.B. 20 Meilen pro Stunde (32,19 km/h), überschreitet und der Abstand Df zwischen dem Fahrzeug 101 und dem Objekt unter einen bestimmten Schwellenwert, z.B. 100 Fuß (30,48 m) gesunken ist. In einer Ausführungsform könnte PI als Produkt des Verantwortungsfaktors (AF) und eines Vorfallswerts (IV) berechnet werden, z.B. gemäß der folgenden Formel: PI = AF * IV.
Der Vorfallswert (IV) ist im Allgemeinen eine Funktion der Annäherungsgeschwindigkeit (CS) und des Abstands zum Objekt (Df). Tabelle 3 stellt Beispiele für Werte bereit, die für solch eine Funktion verwendet werden könnten: Tabelle 3
In einem Block 345 bestimmt der Rechner 105 als Nächstes, ob der Wert eines potentiellen Vorfalls PI größer als null ist. Wenn ja, dann wird als Nächstes ein Block 350 ausgeführt. Ansonsten wird der Prozess 300 mit einem Block 375 fortgesetzt.
Im Block 350 berechnet der Rechner 105 einen Gesamtwert eines potentiellen Vorfalls PI_total, im Allgemeinen gemäß folgender Formel: PI_total = PI_total + PI.
Nach dem Block 350 berechnet der Rechner 105 als Nächstes in einem Block 355 einen Fahrerpunktewert DS_appr für einen Führer des Fahrzeugs 101. In einer Ausführungsform gibt ein Fahrerpunktewert eine mittlere Fahrdauer zwischen potentiellen Vorfällen an. Demgemäß kann für die Gesamtfahrzeit einer Fahrt, z.B. die Zeit (T), die auf dem in Block 305 gestarteten Zeitmesser vergangen ist, eine Formel für den Fahrerpunktewert DS_appr wie folgt aussehen: DS = T/PI_total.
In einem Block 360 wird als Nächstes die Variable PI auf null zurückgesetzt.
In einem Block 365 wird als Nächstes der Fahrerpunktewert DS_appr an den Server 125 übermittelt. Außerdem können noch andere Benutzungsdaten 115 als Aufzeichnungen der Fahrweise eines Führers an den Server 125 übermittelt werden, z.B. mittlere Geschwindigkeiten, zurückgelegte Entfernungen, Fälle von Beschleunigungen oder Verlangsamungen über einem bestimmten Schwellenwert usw.
In einem Block 370 kann der Rechner 105 als Nächstes, größtenteils wie oben in Bezug auf die Prozesse 400, 500 beschrieben, eine Warnung oder Meldung an einen Führer des Fahrzeugs 101 ausgeben, z.B. über eine Anzeige im Fahrzeug 101, die mit dem Rechner 105 verbunden ist, über eine Benutzervorrichtung 150, über einen Nachrichtenübermittlungsmechanismus, wie z.B. E-Mail oder Short Message Service (SMS) usw. In jedem Fall kann eine solche Warnung, Nachricht oder Meldung den Fahrerpunktewert wiedergeben. Bei einem geringen Fahrerpunktewert, wenn z.B. DS_appr < 1 ist, könnte eine Nachricht beispielsweise folgende Meldung enthalten: „Geringer Fahrerpunktewert. Sie könnten Ihren Punktewert verbessern, indem Sie Ihre Geschwindigkeit besser an das vordere Fahrzeug anpassen.“ oder „Geringer Fahrerpunktewert. Sie könnten Geld bei Versicherungsprämien sparen, indem Sie Ihre Geschwindigkeit besser an die des vorderen Fahrzeugs anpassen.” Auf ähnliche Weise könnte eine Meldung bereitgestellt werden, die auf einen guten Fahrerpunktewert hinweist.
Nach entweder dem Block 370 oder dem Block 345 kann der Block 375 ausgeführt werden. Im Block 375 bestimmt der Rechner 105, ob der im Block 305 gestartete Zeitmesser weiter läuft, d.h. ob eine Fahrt fortgesetzt wird. Wenn nicht, oder alternativ dazu, wenn ein Fahrzeug 101, einschließlich des Rechners 105, abgestellt wird, endet der Prozess 300. Ansonsten kehrt der Prozess 300 zu Block 310 zurück.
6 ist ein Diagramm eines beispielhaften Prozesses 600 zur Identifikation und Meldung von Instabilität des Fahrzeugs 101 und zur Berechnung eines alternativen oder zusätzlichen Fahrerpunktewerts DS_stab daraus. Im Allgemeinen kann die Stabilität von Fahrzeug 101 gemäß verschiedener Faktoren bestimmt werden, einschließlich (1) Wankstabilität (Rollstabilität), (2) Gierrate, (3) Aktivität eines Brems-Antiblockiersystems (ABS), z. B. Gleit- oder Schlupfregelung, und/oder (4) Traktion des Fahrzeugs 101, z. B. Übersteuerung oder Untersteuerung, die in dem Fahrzeug 101 erfahren wird, Durchdrehen der Reifen usw., und/oder eine beliebige Kombination der vorgenannten vier Faktoren.
Demgemäß kann der Prozess 600 in einem Block 605 beginnen, wobei der Rechner 105 die Benutzungsdaten 115 evaluiert, um zu bestimmen, ob ein Wankereignis stattgefunden hat, das einen vorbestimmten Schwellenwert übersteigt. Ein Fahrzeugüberschlag 101 wird im Allgemeinen als eine Drehung des Fahrzeugs 101 in Bezug auf eine horizontale Längsachse durch das Fahrzeug 101, z. B. durch einen Schwerpunkt des Fahrzeugs 101, gemessen. Die Datensammler 110 stellen Daten 115 bereit, die anzeigen, dass ein Wankereignis eines Fahrzeugs 101 mehr als fünf Prozent eines vollständigen Überschlags überschritten hat, d. h., bei 100 Prozent Überschlag hätte sich das Fahrzeug 101 vollständig überschlagen, d. h. es würde auf dem Dach liegen, dann kann der Schwellenwert überschritten sein. Wenn der Schwellenwert überschritten ist, dann speichert der Rechner 105 einen Wankprozentsatz P_rollover, d. h. einen Wert zwischen oder möglicherweise einschließlich null und 100 und ein Block 610 wird als Nächstes ausgeführt. Wenn der Schwellenwert nicht überschritten ist, dann wird der Prozess 600 mit einem Block 625 fortgesetzt.
Im Block 610 bestimmt der Rechner 105 einen Korrekturfaktor M_rollover, bei dem es sich um einen Faktor handelt, der basierend darauf bestimmt wird, ob eine Korrekturmaßnahme angesichts des in Block 605 detektierten Wankereignisses erforderlich war. Zum Beispiel kann eine Korrekturmaßnahme durch ein Wankkontrollsystem (Roll Stability Control = RSC) oder dergleichen in dem Fahrzeug 101, wie es bekannt sein dürfte, vorgenommen werden. Zum Beispiel kann das RSC die Seitenkräfte auf ein Fahrzeug 101 reduzieren, indem es in einer Richtung eines Wankmoments zeitgesteuert einwirkt, wodurch eine Wankneigung des Fahrzeugs 101 korrigiert wird. Wie bekannt ist, kann das RSC demgemäß eine Wankkorrektur durchführen, indem es ein Fahrzeug 101 durch Bremsen, Lenken, usw. steuert. In jedem Fall ist es möglich, dass ein Wankereignis in Block 605 detektiert wird, das keine Korrektur erfordert, wobei in diesem Fall einem Korrekturfaktor ein Wert von null zugeordnet werden kann. Wenn jedoch eine Korrektur erforderlich war, kann einem Korrekturfaktor ein Wert zugeordnet werden, der sich auf ein Niveau oder eine Quantität an erforderlicher Korrektur bezieht. Ein Korrekturfaktor gemäß einem Prozentsatz an Nutzung des RSC-Systems könnte beispielsweise einen Wert zwischen einschließlich null und einhundert haben, z. B. würden 10 Prozent Nutzung des RSC-Systems einen Korrekturfaktor von 10 ergeben.
Nach dem Block 610 bestimmt der Rechner 105 in einem Block 615 einen Wankpunktewert RS_n für das Wankereignis n, das in dem Block 605 bestimmt wird. Der Punktewert RS_n wird im Allgemeinen gemäß einer Kombination des Korrekturfaktors M_rollover und des Wankprozentsatzes P_rollover bestimmt. In einer Ausführungsform zum Beispiel: RS_n = (0.2* P_rollover + M_rollover 0.8*)⁴.
Wie sich in der vorstehenden Formel für den Punktewert RS_n, widerspiegelt, kann es im Allgemeinen wünschenswert sein, dem Korrekturfaktor ein größeres Gewicht zu geben, insofern als der Korrekturfaktor, d. h. in welchem Umfang eine Korrektur erforderlich war, um eine Gefahr für das Fahrzeug 101 zu bannen, ein signifikanter Indikator für fahrlässiges Fahren sein kann. Wie der Exponent, d. h. das Potenzieren mit vier der Kombination des gewichteten Wankprozentsatzes und des Korrekturfaktors, außerdem widerspiegelt, kann es wünschenswert sein, höheren Punktewerten relativ mehr Gewicht zu geben, im Gegensatz zu niedrigeren Punktewerten. Das heißt, höhere Wankprozentsätze und/oder Korrekturfaktoren können ein unverhältnismäßig höheres Gewicht erhalten als niedrigere Punktewerte.
Nach dem Block 615 stellt der Rechner 105 in einem Block 620 einen kumulativen Wankpunktewert RS_cum bereit. In einer ersten Iteration des Prozesses 600 und/oder wenn nur ein Gierereignis detektiert wurde, d. h. wenn ein aktueller Wert für n eins ist, wird der Punktewert RS_cum einfach RS_n sein. In zweiten oder anschließenden Iterationen des Prozesses 600 wird ein Wert für den kumulativen Wankpunktewert, wenn k Wankereignisse detektiert wurden, jedoch wie folgt sein: RS_cum = (RS_n + RS_n + ... + RS_k)^0.25/k
In einem Block 625, auf den entweder die Blöcke 605 oder 620 folgen können, bestimmt der Rechner 105, ob eine Gierrate des Fahrzeugs 101, die einen vorbestimmten Schwellenwert übersteigt, detektiert wurde. Gieren des Fahrzeugs 101 wird im Allgemeinen als eine Drehung des Fahrzeugs 101 in Bezug auf eine Vertikalachse durch das Fahrzeug 101, z. B. durch einen Schwerpunkt des Fahrzeugs 101, gemessen. Die Datensammler 110 stellen Daten 115 bereit, die anzeigen, dass die Gierrate eines Fahrzeug 101 fünf Prozent einer Gierrate überstieg, d. h., bei 100 Prozent Gier hätte sich das Fahrzeug 101 um 180 Grad gedreht, dann kann der Schwellenwert überschritten sein. Wenn der Schwellenwert überschritten ist, dann speichert der Rechner 105 einen Gierprozentsatz P_yaw, d. h. einen Wert zwischen oder möglicherweise einschließlich null und 100 und ein Block 630 wird als Nächstes ausgeführt. Wenn der Schwellenwert nicht überschritten ist, dann wird der Prozess 600 mit einem Block 645 fortgesetzt.
Im Block 630 bestimmt der Rechner 105 einen Korrekturfaktor M_yaw, bei dem es sich um einen Faktor handelt, der basierend darauf bestimmt wird, ob eine Korrekturmaßnahme angesichts des in Block 625 detektierten Gierereignisses erforderlich war. Zum Beispiel kann eine Korrekturmaßnahme, wie bekannt sein dürfte, durch ein Gierregelungssystem oder dergleichen in dem Fahrzeug 101 vorgenommen werden. Das Gierregelungssystem kann beispielsweise das auf ein Fahrzeug 101 aufgebrachte Giermoment reduzieren, wodurch die Gierneigung des Fahrzeugs 101 abgeschwächt wird. Wie bekannt ist, kann das Gierregelungssystem demgemäß eine Gierkorrektur durchführen, indem es das Bremsen, Lenken, usw. eines Fahrzeugs 101 steuert. In jedem Fall ist es möglich, dass ein Gierratenereignis in dem Block 625 detektiert wird, das keine Korrektur erfordert, wobei in diesem Fall einem Korrekturfaktor ein Wert von null zugeordnet werden kann. Wenn jedoch eine Korrektur erforderlich war, kann einem Korrekturfaktor ein Wert zugeordnet werden, der sich auf ein Niveau oder eine Quantität an erforderlicher Korrektur bezieht. Ein Korrekturfaktor könnte, gemäß einem Prozentsatz an Nutzung des RSC-Systems, beispielsweise einen Wert zwischen und einschließlich null und einhundert haben, z. B. würden 10 Prozent Nutzung des Gierratenregelungssystems einen Korrekturfaktor von 10 ergeben.
Nach dem Block 630 bestimmt der Rechner 105 in einem Block 635 einen Gierratenpunktewert YS_n für das Gierereignis n, das in dem Block 625 bestimmt wird. Der Punktewert YS_n wird im Allgemeinen gemäß einer Kombination des Korrekturfaktors M_yaw und des Gierprozentsatzes P_yaw bestimmt. In einer Ausführungsform zum Beispiel: YS_n = (0.2* P_yaw + M_yaw 0.8*)⁴.
Wie sich in der vorstehenden Formel für den Punktewert YS_n, widerspiegelt, kann es im Allgemeinen wünschenswert sein, dem Korrekturfaktor ein größeres Gewicht zu geben, insofern als der Korrekturfaktor, d. h. in welchem Umfang eine Korrektur erforderlich war, um eine Gefahr für das Fahrzeug 101 zu bannen, ein signifikanter Indikator für fahrlässiges Fahren sein kann. Wie der Exponent, d. h. das Potenzieren mit vier der Kombination des gewichteten Gierprozentsatzes und des Korrekturfaktors, außerdem widerspiegelt, kann es wünschenswert sein, höheren Punktewerten relativ mehr Gewicht zu geben, im Gegensatz zu niedrigeren Punktewerten. Das heißt, höhere Gierprozentsätze und/oder Korrekturfaktoren können ein unverhältnismäßig höheres Gewicht erhalten als niedrigere Punktewerte.
Nach dem Block 635 stellt der Rechner 105 in einem Block 640 einen kumulativen Gierpunktewert YS_cum bereit. In einer ersten Iteration des Prozesses 600 und/oder wenn nur ein Gierereignis detektiert wurde, d. h. wenn ein aktueller Wert für n eins ist, wird der Punktewert YS_cum einfach YS_n sein. In zweiten oder anschließenden Iterationen des Prozesses 600 wird ein Wert für den kumulativen Gierpunktewert, wenn k Gierereignisse detektiert wurden, jedoch wie folgt sein: YS_cum = (YS_n + YS_n + ... + YS_k)^0.25/k
In einem Block 645, der entweder auf die Blöcke 625 oder 640 folgen kann, bestimmt der Rechner 105, ob eine Anforderung eines Brems-Antiblockiersystems eines Fahrzeugs 101, z. B. Schlupf, d. h., wie bekannt ist, eine detektierte Diskrepanz bei der erwarteten Raddrehzahl, die kleiner ist als erwartet, z. B. ein linkes Vorderrad langsamer wird, oder die Raddrehzahl von Fahrzeug 101 geringer ist als der Durchschnitt der anderen Räder, die einen vorbestimmten Schwellenwert übersteigt, detektiert wurde. Wenn zum Beispiel eine oder mehrere von vier Raddrehzahlen von Fahrzeug 101 um mehr als 5 % einer erwarteten mittleren Raddrehzahl langsamer werden, dann fand ein ABS-Ereignis statt und der Schwellenwert ist überschritten. Wenn der Schwellenwert überschritten ist, dann speichert der Rechner 105 einen ABS-Prozentsatz P_ABS, d. h. einen Wert zwischen oder möglicherweise einschließlich null und 100, und ein Block 630 wird als Nächstes ausgeführt. Wenn der Schwellenwert nicht überschritten ist, dann wird der Prozess 600 mit einem Block 645 fortgesetzt.
Im Block 650 bestimmt der Rechner 105 einen Korrekturfaktor M_ABBS, bei dem es sich um einen Faktor handelt, der basierend darauf bestimmt wird, ob eine Korrekturmaßnahme angesichts des in Block 645 detektierten ABS-Ereignisses erforderlich war. Zum Beispiel kann eine Korrekturmaßnahme durch ein ABS-Kontrollsystem oder dergleichen in dem Fahrzeug 101, wie es bekannt sein dürfte, vorgenommen werden. Zum Beispiel kann der Rechner 105 den Bremsdruck reduzieren, wodurch eine Schlupfneigung des Fahrzeugs 101 abgeschwächt wird. In jedem Fall ist es möglich, dass ein ABS-Ereignis in dem Block 645 detektiert wird, das keine Korrektur erfordert, wobei in diesem Fall einem Korrekturfaktor ein Wert von null zugeordnet werden kann. Wenn jedoch eine Korrektur erforderlich war, kann einem Korrekturfaktor ein Wert zugeordnet werden, der sich auf ein Niveau oder eine Quantität an erforderlicher Korrektur bezieht. Ein Korrekturfaktor könnte gemäß einem Prozentsatz an Nutzung des RSC-Systems beispielsweise einen Wert zwischen und einschließlich null und einhundert haben, z. B. würden 10 Prozent Nutzung des ABS-Kontrollsystems einen Korrekturfaktor von 10 ergeben.
Nach dem Block 650 bestimmt der Rechner 105 in einem Block 655 einen ABS-Punktewert AS_n für das ABS-Ereignis n, das in Block 645 bestimmt wird. Der Punktewert AS_n wird im Allgemeinen gemäß einer Kombination des Korrekturfaktors M_ABS und des ABS-Prozentsatzes P_ABS bestimmt. In einer Ausführungsform zum Beispiel: AS_n = (0.2* P_ABS + M_ABS 0.8*)⁴.
Wie sich in der vorstehenden Formel für den Punktewert AS_n, widerspiegelt, kann es im Allgemeinen wünschenswert sein, dem Korrekturfaktor ein größeres Gewicht zu geben, insofern als der Korrekturfaktor, d. h. in welchem Umfang eine Korrektur erforderlich war, um eine Gefahr für das Fahrzeug 101 zu bannen, ein signifikanter Indikator für fahrlässiges Fahren sein kann. Wie der Exponent, d. h. das Potenzieren mit vier der Kombination des gewichteten ABS-Prozentsatzes und des Korrekturfaktors, außerdem widerspiegelt, kann es wünschenswert sein, höheren Punktewerten relativ mehr Gewicht zu geben, im Gegensatz zu niedrigeren Punktewerten. Das heißt, höhere ABS-Prozentsätze und/oder Korrekturfaktoren können ein unverhältnismäßig höheres Gewicht erhalten als niedrigere Punktewerte.
Nach dem Block 655 stellt der Rechner 105 in einem Block 660 einen kumulativen ABS-Punktewert AS_cum bereit. In einer ersten Iteration des Prozesses 600 und/oder wenn nur ein ABS-Ereignis detektiert wurde, d. h. wenn ein aktueller Wert für n eins ist, wird der Punktewert AS_cum einfach AS_n sein. In zweiten oder anschließenden Iterationen des Prozesses 600 wird ein Wert für den kumulativen ABS-Punktewert, wenn k ABS-Ereignisse detektiert wurden, jedoch wie folgt sein: AS_cum = (AS_n + AS_n + ... + AS_k)^0.25/k
In einem Block 665, der entweder auf die Blöcke 645 oder 660 folgen kann, evaluiert der Rechner 105 Benutzungsdaten 115, um zu bestimmen, ob ein Traktionsereignis stattgefunden hat, das einen vorbestimmten Schwellenwert übersteigt. Die Traktion des Fahrzeugs 101 wird im Allgemeinen als ein Grad gemessen, in dem das Fahrzeug 101 Traktion verliert. Das heißt, wie bekannt ist, kann Traktionsverlust gemäß einer detektierten Diskrepanz bei der erwarteten Raddrehzahl, die größer ist als erwartet, bestimmt werden, z. B. ein linkes Vorderrad wird im Vergleich zu anderen Rädern schneller, oder die Raddrehzahl von Fahrzeug 101 ist geringer als der Durchschnitt der anderen Räder, dann wurde das Überschreiten eines vorbestimmten Traktionsschwellenwerts detektiert. Wenn zum Beispiel eine oder mehrere von vier Raddrehzahlen von Fahrzeug 101 um mehr als 5 % einer erwarteten mittleren Raddrehzahl schneller werden, dann kann ein Traktionsereignis stattgefunden haben und der Schwellenwert ist überschritten. Die Datensammler 110 können daher Daten 115 bereitstellen, die anzeigen, dass eine Traktion eines Fahrzeugs 101 fünf Prozent einer Traktionsmessung überschritten hat. Wenn der Schwellenwert überschritten ist, dann speichert der Rechner 105 einen Traktionsprozentsatz P_traction, d. h. einen Wert zwischen oder möglicherweise einschließlich null und 100 und ein Block 670 wird als Nächstes ausgeführt. Wenn der Schwellenwert nicht überschritten ist, dann wird der Prozess 600 mit einem Block 680 fortgesetzt.
Im Block 670 bestimmt der Rechner 105 einen Korrekturfaktor M_traction, bei dem es sich um einen Faktor handelt, der basierend darauf bestimmt wird, ob eine Korrekturmaßnahme angesichts des in Block 665 detektierten Traktionsereignisses erforderlich war. Korrekturmaßnahme können beispielsweise von einem Traktionskontrollsystem oder dergleichen in dem Fahrzeug 101 vorgenommen werden, z. B. kann das Radmoment, die Fahrzeuglenkung usw. gesteuert werden, um die Traktion des Fahrzeugs 101 zu verbessern. In jedem Fall ist es möglich, dass ein Traktionsereignis in Block 605 detektiert wird, das keine Korrektur erfordert, wobei in diesem Fall einem Korrekturfaktor ein Wert von null zugeordnet werden kann. Wenn jedoch eine Korrektur erforderlich war, kann einem Korrekturfaktor ein Wert zugeordnet werden, der sich auf ein Niveau oder eine Quantität an erforderlicher Korrektur bezieht. Ein Korrekturfaktor könnte gemäß einem Prozentsatz an Nutzung des RSC-Systems beispielsweise einen Wert zwischen und einschließlich null und einhundert haben, z. B. würden 10 Prozent Nutzung des Traktions-Kontrollsystems einen Korrekturfaktor von 10 ergeben.
Nach dem Block 670 bestimmt der Rechner 105 in einem Block 675 einen Traktionspunktewert TS_n für das Traktionsereignis n, das in dem Block 665 bestimmt wird. In einer Ausführungsform zum Beispiel: TS_n = (0.2* P_traction + M_traction 0.8*)⁴.
Wie sich in der vorstehenden Formel für den Punktewert TS_n, widerspiegelt, kann es im Allgemeinen wünschenswert sein, dem Korrekturfaktor ein größeres Gewicht zu geben, insofern als der Korrekturfaktor, d. h. in welchem Umfang eine Korrektur erforderlich war, um eine Gefahr für das Fahrzeug 101 zu bannen, ein signifikanter Indikator für fahrlässiges Fahren sein kann. Wie der Exponent, d. h. das Potenzieren mit vier der Kombination des gewichteten Traktionsprozentsatzes und des Korrekturfaktors, außerdem widerspiegelt, kann es wünschenswert sein, höheren Punktewerten relativ mehr Gewicht zu geben, im Gegensatz zu niedrigeren Punktewerten. Das heißt, höhere Traktionsprozentsätze und/oder Korrekturfaktoren können ein unverhältnismäßig höheres Gewicht erhalten als niedrigere Punktewerte.
Nach dem Block 675 stellt der Rechner 105 in einem Block 680 einen kumulativen Traktionspunktewert TS_cum bereit. In einer ersten Iteration des Prozesses 600 und/oder wenn nur ein Traktionsereignis detektiert wurde, d. h. wenn ein aktueller Wert für n eins ist, wird der Punktewert TS_cum einfach TS_n sein. In zweiten oder anschließenden Iterationen des Prozesses 600 wird ein Wert für den kumulativen Traktionspunktewert, wenn k Traktionsereignisse detektiert wurden, jedoch wie folgt sein: TS_cum = ( TS_n + TS_n + ... + TS_k)^0.25/k
Als Nächstes bestimmt der Rechner 105 nach einem der Blöcke 665, 680 in einem Block 685 einen auf die Stabilität des Fahrzeugs 101 bezogenen Gesamtfahrerpunktewert DS_stab wie folgt: DS_stab = w_roll*RS_cum + w_yaw*YS_cum + w_ABS*AS_cum + w_traction*TS_cum, wobei w_roll, w_yaw*, w_ABS und w_traction Gewichtungen sind, die auf jeweilige Punktewerte angewendet werden. Die Werte für die Gewichtungen w können variieren und können festgelegt sein, um eine oder mehrere Komponenten des Fahrerpunktewerts DS_stab zu betonen und/oder abzuschwächen. In einer Ausführungsform wird beispielsweise dem Wankpunktewert RS die höchste Gewichtung (0,5) gegeben, während der Gierpunktewert YS als nächstes gewichtet wird (0,25), gefolgt von dem ABS-Punktewert AS (0,2) und dem Traktionspunktewert TS (0,05).
Nach dem Block 685 kann der Fahrerpunktewert in einem Block 687 von dem Rechner 105 auf verschiedene Arten gemeldet werden. Der Fahrerpunktewert kann beispielsweise auf einem Bildschirm des Rechners 105 angezeigt werden, möglicherweise zusammen mit einer Nachricht, die den Fahrerpunktewert wie oben beschrieben charakterisiert, z. B. “Gut gemacht! Ihr Stabilitäts-Fahrerpunktewert beträgt __”, oder “Der Stabilitäts-Fahrerpunktewert von __ könnte verbessert werden”.
Der Prozess 600 kann nach Block 687 in Block 697 fortgesetzt werden. Wie jedoch aus 6 hervorgeht, kann ein optionaler Block 690 auf Block 687 folgen, auf den seinerseits ein Block 695 folgt, der Block 697 vorausgeht. In Block 690 evaluiert der Rechner 105 die verschiedenen Korrekturfaktoren, die wie oben beschrieben bestimmt werden konnten. Der Rechner 105 kann programmiert sein, um Korrekturfaktoren, die einen vorbestimmten Schwellenwert überschreiten, z. B. fünf Prozent, 10 Prozent usw., zu markieren.
Als Nächstes meldet der Rechner 105 in einem Block 695, beliebige markierte Korrekturfaktoren an den Remote-Server 125 und/oder an eine Remote-Site 160.
Nach dem Block 695 oder, in Ausführungsformen, in denen die Blöcke 690 und 695 weggelassen werden, dem Block 687, bestimmt der Rechner 105, ob der Prozess 600 fortgesetzt werden soll. Das Fahrzeug 101 könnte zum Beispiel abgestellt sein, zu fahren aufhören usw. Wenn ja, kann der Prozess 600 enden. Ansonsten kann der Prozess 600 zu Block 605 zurückkehren.
7 ist ein Diagramm eines beispielhaften Prozesses 700 zur Identifikation und Meldung von Kreuzungsvorfällen und zur Berechnung eines Fahrerpunktewerts DS_int daraus.
Der Prozess 700 beginnt in einem Block 705, in dem der Rechner 105 bestimmt, ob sich das Fahrzeug 101 in einer Kreuzungszone befindet. Eine Kreuzungszone könnte beispielsweise in Bezug auf einen Bereich definiert sein, in dem sich zwei oder mehr Straßen kreuzen, z. B., einem Bereich, der zwei oder mehr Straßen umfasst, sowie einem Bereich oder Bereichen auf einer oder mehreren der Straßen innerhalb eines definierten Abstands des Bereichs, in dem sich die zwei oder mehr Straßen kreuzen, z. B. 50 Fuß (15,24 m) usw. Eine Kreuzungszone könnte von verschiedenen Mechanismen detektiert werden, z. B. könnte ein Globales Positionierungssystem (GPS) einen Hinweis für den Rechner 105 bereitstellen, dass sich das Fahrzeug 101 in einer Kreuzungszone befindet, verschiedene Sensordatensammler 110 könnten Daten 115 bereitstellen, die sich z. B. auf Straßenmarkierungen, Verkehrszeichen, Ampelanlagen usw. beziehen, die anzeigen, dass sich das Fahrzeug 101 in oder in der Nähe einer Kreuzungszone befindet. Wenn der Rechner 105 bestimmt, dass sich das Fahrzeug 101 in einer Kreuzungszone befindet, dann wird als Nächstes ein Block 710 ausgeführt. Ansonsten wird der Prozess 700 mit einem Block 715 fortgesetzt.
Im Block 710 sammelt der Rechner 105 Daten 115, die bei der Berechnung eines Kreuzungs-Fahrerpunktewerts DS_int verwendet werden sollen. Solche Daten 115 können sich auf einen oder mehrere der folgenden Faktoren beziehen, die auf einer Skala, z. B. von 0 bis 1, bewertet werden können:

• Haben die Augen des Fahrers vor dem Abbiegen nach beiden Seiten geschaut (wird unter Verwendung einer im Spiegel befestigten Kamera 110 beobachtet); wenn ja, könnte ein Faktorwert von 1 zugeordnet werden, wenn nicht, könnte ein Faktorwert von 0 zugeordnet werden, wenn der Fahrer nur nach einer Seite aber nicht nach beiden Seiten geschaut hat, könnte ein Faktorwert von 0,5 zugeordnet werden;
• Die Geschwindigkeit des Fahrzeugs 101 reduziert sich um mehr als einen vorbestimmten Schwellenwert, z. B., 2 mph (3,22 km/h) vor dem Einfahren in die Kreuzung (Bestimmung unter Verwendung von Fahrzeuggeschwindigkeitssensor 110); es könnte ein Faktorwert zugeordnet werden, der auf einer Quantität basiert, um die die Geschwindigkeitsreduktion des Fahrzeugs 101 den vorbestimmten Schwellenwert übersteigt und/oder um den das Fahrzeug 101 die Geschwindigkeit gemäß dem Schwellenwert nicht reduzierte;
• Ist das Niveau an Querbeschleunigungs-g-Kraft kleiner als ein vorbestimmter Schwellenwert, z. B. 0,25g.
• Wurde ein Blinkersignal des Fahrzeugs 101 zur besten Zeit vor dem Abbiegen verwendet; z. B. wird ein Faktorwert von 1,0 für ein Blinkersignal zugeordnet, das 3 bis 10 Sekunden bevor eine Kreuzungszone erreicht wird eingesetzt wird, 0,5 könnte für ein Blinkersignal zugeordnet werden, das zu spät/zu früh eingesetzt wird, 0 könnte für einen Abbiegevorgang zugeordnet werden, der ohne Signal erfolgte.
• Ampelfarbe, wenn die Kreuzung überquert wird (Beobachtung unter Verwendung von einer vorne befestigten Kamera oder anderer Datenquellen); der Faktor könnte mit 1 für grün, 0,54 für gelb und 04 für rot bewertet werden;
• Nähe des Fahrzeugs 101 zu Objekten, während es sich beim Abbiegen übermäßig von einem vorbestimmten Abstandsschwellenwert entfernt, z. B. 6 Fuß (1,83 m) (vorne und seitlich) (Beobachtung unter Verwendung von vorderseitigen und seitlichen Radarsensoren).

Nach dem Block 710 kehrt der Prozess 700 zu Block 705 zurück. Anders ausgedrückt sammelt der Rechner 105 in Block 710 Daten, bis, wie in Bezug auf Block 705 beschrieben, bestimmt wird, dass sich das Fahrzeug 101 nicht in einer Kreuzungszone befindet.
Im Block 715, nachdem der Rechner 105 bestimmt hat, dass sich das Fahrzeug 101 nicht in einer Kreuzungszone befindet, bestimmt der Rechner 105, ob das Fahrzeug 101 die Kreuzungszone verlassen hat, d. h., ob Daten 115 gesammelt wurden, wie in Bezug auf Block 710 beschrieben. Wenn das Fahrzeug 101 die Kreuzungszone nicht verlassen hat, dann wird der Prozess 700 mit einem Block 735 fortgesetzt. Wenn das Fahrzeug 101 jedoch eine Kreuzungszone verlassen hat, dann wird der Prozess 700 mit einem Block 720 fortgesetzt.
Im Block 720 berechnet der Rechner 105, z. B. gemäß dem folgenden Prozess, einen Kreuzungs-Fahrerpunktewert. Zuerst kann ein Punktewert für eine aktuelle Iteration des Prozesses 700, d. h., für eine soeben durchfahrene Kreuzung, wie folgt berechnet werden, wobei F₁, F_2...F_n Faktoren sind, die gemäß Daten 115 wie oben beschrieben bestimmt wurden, und n eine Anzahl von Faktoren ist, die berücksichtigt werden. DS_{current_iteration} = (F₁ + F₂ + ... + F_n)/n
Als Nächstes kann ein Gesamtfahrerpunktewert DS_{int_total} wie folgt bestimmt werden: DS_{int_total} = DS_{int_total} + DS_{current_iteration.}
Das heißt, in jeder Iteration des Prozesses 700 wird der Wert DS_{int_total} durch die Addition von DS_{current_iteration} zu dem Wert von DS_{int_total} aus der unmittelbar vorausgehenden Iteration des Prozesses 700 erhöht, wobei verstanden werden soll, dass DS_{int_total} auf der rechten Seite der obigen Gleichung in einer ersten Iteration des Prozesses 700 null sein wird.
Ein Wert NT kann eine Anzahl von Abbiegungen darstellen, die ein Fahrzeug 101 während der Ausführung von Prozess 100 vorgenommen hat, oder kann eine Anzahl von überquerten Kreuzungen darstellen (unabhängig davon, ob das Fahrzeug 101 abgebogen ist). Wie DS_{int_total} kann NT anfangs auf null gesetzt werden und kann dann in einer Iteration des Prozesses 700 wie folgt erhöht werden: NT = NT + 1.
Ein mittlerer Kreuzungs-Fahrerpunktewert DS_{int_avg} kann dann wie folgt berechnet werden: DS_{int_avg} = DS_{int_total}/NT.
Zu beachten ist, dass NT und DS_{int_total} in einem Speicher des Rechners 105 in regelmäßigen Abständen, z. B. monatlich, auf null zurückgesetzt werden, wodurch die Meldung eines regelmäßigen, z. B. monatlichen Fahrerpunktewerts DS_{int_total}, ermöglicht wird.
Nach dem Block 720 kann der Kreuzungs-Fahrerpunktewert DS_{int_avg} in einem Block 725 von dem Rechner 105 auf verschiedene Arten gemeldet werden. Der Fahrerpunktewert DS_{int_avg} kann beispielsweise auf einem Bildschirm des Rechners 105 angezeigt werden, möglicherweise zusammen mit einer Nachricht, die den Fahrerpunktewert wie oben beschrieben charakterisiert, z. B. “Gut gemacht! Ihr Kreuzungs-Fahrerpunktewert beträgt __”, oder “Der Kreuzungs-Fahrerpunktewert von __ könnte verbessert werden”.
Nach dem Block 725 könnte in einem Block 730 der Fahrerpunktewert DS_{int_avg} auf den Server 125 übertragen werden, z. B. auf ähnlich Weise wie oben erörtert.
Entweder nach den Blöcken 715, 730 bestimmt der Rechner 105, ob der Prozess 700 fortgesetzt werden soll. Das Fahrzeug 101 könnte zum Beispiel abgestellt sein, zu fahren aufhören usw. Wenn ja, kann der Prozess 700 enden. Ansonsten kann der Prozess 700 zu Block 705 zurückkehren.
SCHLUSSFOLGERUNG
Rechenvorrichtungen, wie sie hierin erläutert sind, umfassen im Allgemeinen jeweils Anweisungen, die von einer oder mehreren Rechenvorrichtungen, wie sie oben identifiziert sind, ausführbar sind und zur Ausführung von Blöcken oder Schritten von oben beschriebenen Prozessen dienen. Oben erläuterte Prozessblöcke können beispielsweise als computerausführbare Anweisungen ausgeführt sein.
Computerausführbare Anweisungen können aus Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung verschiedener Programmiersprachen und/oder -technologien geschaffen wurden, einschließlich, nicht jedoch eingeschränkt auf, 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, wodurch ein oder mehrere Prozesse ausgeführt werden, einschließlich eines oder mehrerer der hierin beschriebenen Prozesse. Solche Anweisungen und andere Daten können unter Verwendung verschiedener computerlesbarer Medien gespeichert und übertragen werden. Eine Datei in einer Rechenvorrichtung ist im Allgemeinen eine Sammlung von Daten, die auf einem computerlesbaren Medium, z.B. einem Speichermedium, einen Direktzugriffsspeicher usw., gespeichert sind.
Ein computerlesbares Medium umfasst jedes beliebige Medium, das an der Bereitstellung von Daten (z.B. Anweisungen) mitwirkt, die von einem Rechner gelesen werden können. Solch ein Medium kann zahlreiche Formen aufweisen, einschließlich, nicht jedoch eingeschränkt auf, nichtflüchtigen Medien, flüchtigen Medien usw. Nichtflüchtige Medien umfassen beispielsweise optische oder magnetische Discs und andere persistente Speicher. Flüchtige Medien umfassen einen dynamischen Direktzugriffsspeicher (DRAM), der üblicherweise einen Hauptspeicher darstellt. Häufige Formen von computerlesbaren Medien umfassen beispielsweise eine Diskette, eine flexible Diskette, eine Festplatte, ein Magnetband, jedes beliebige andere magnetische Medium, eine CD-ROM, eine DVD, jedes beliebige andere optische Medium, Lochkarten, einen Papierstreifen, jedes beliebige andere physikalische Medium mit Lochmustern, ein RAM, ein PROM, ein EPROM, ein FLASH-EEPROM, jeden beliebigen anderen Speicherchip oder jedes beliebige andere Speichermodul oder jedes beliebige andere Medium, von dem ein Rechner lesen kann.
In den Zeichnungen bezeichnen gleiche Bezugszahlen gleiche Elemente. Außerdem können eines oder alle dieser Elemente verändert werden. In Bezug auf die hierin beschriebenen Medien, Prozesse, Systeme, Verfahren usw. versteht sich, dass, obwohl die Schritte solcher Prozesse usw. als in einer bestimmten geordneten Reihenfolge auftretend beschrieben wurden, solche Prozesse mit den beschriebenen Schritten in einer anderen Reihenfolge als der hierin beschriebenen Reihenfolge umgesetzt werden könnten. Ferner versteht sich, dass bestimmte Schritte gleichzeitig ausgeführt werden können, dass weitere Schritte hinzugefügt werden können oder dass bestimmte, hierin beschriebene Schritte weggelassen werden können. Mit anderen Worten dienen die Beschreibungen der Prozesse hierin dem Zweck der Veranschaulichung bestimmter Ausführungsformen und sind in keiner Weise als Einschränkung der beanspruchten Erfindung zu verstehen.
Demgemäß versteht sich, dass die obige Beschreibung veranschaulichend und nicht einschränkend zu verstehen ist. Für Fachleute auf dem Gebiet der Erfindung ergeben sich beim Lesen der obigen Beschreibung zahlreiche weitere Ausführungsformen und Anwendungen als die bereitgestellten Beispiele. Der Schutzumfang der Erfindung sollte nicht unter Bezugnahme auf die obige Beschreibung, sondern stattdessen unter Bezugnahme auf die beiliegenden Ansprüche zusammen mit dem gesamten Umfang an Äquivalenten, zu denen solche Ansprüche berechtigt sind, bestimmt werden. Es wird erwartet und es ist beabsichtigt, dass es zukünftige Entwicklungen auf dem hierin erläuterten Gebiet geben wird, und dass die offenbarten Systeme und Verfahren in solche zukünftigen Ausführungsformen integriert werden. Zusammengefasst versteht sich, dass Modifikationen und Variationen an der Erfindung möglich sind und dass diese nur durch die nachfolgenden Ansprüche eingeschränkt ist.
Alle in den Ansprüchen verwendeten Begriffe sind in ihren herkömmlichen Bedeutungen, wie sie Fachleuten auf dem Gebiet der Erfindung bekannt sind, zu verstehen, sofern nicht hierin explizit das Gegenteil angegeben ist. Insbesondere sind Einzahlartikel wie „ein/eine“ und „der/die/das“ sowie „der/die/das genannte“ so zu verstehen, dass sie eines oder mehrere der angeführten Elemente umfassen, sofern nicht in einem Anspruch explizit das Gegenteil angeführt ist.
Es wird ferner beschrieben:

A. System, umfassend einen Rechner 105 in einem Fahrzeug 101, wobei der Rechner 105 einen Prozessor und einen Speicher umfasst, wobei der Rechner 105 programmiert ist, um: während des Betriebs des Fahrzeugs 101 Daten aus einem oder mehreren Datensammlern 110 in Bezug auf mindestens ein Stabilitätsereignis des Fahrzeugs 101 zu identifizieren; einen Korrekturfaktor in Bezug auf jedes zu mindestens eine Ereignis zu bestimmen; und einen Fahrerpunktewert für einen Fahrer des Fahrzeugs 101 zu bestimmen, der zumindest teilweise auf den Daten in Bezug auf das zumindest eine Stabilitätsereignis und den Korrekturfaktor in Bezug auf jedes zumindest eine Ereignis basiert.
B. System nach A, wobei das zumindest eine Stabilitätsereignis eines aus einem Fahrzeugwankereignis, einem Fahrzeuggierbewegungsereignis, einem Fahrzeugschlupfereignis und einem Fahrzeugtraktionsereignis umfasst.
C. System nach A, wobei das zumindest eine Stabilitätsereignis zwei Stabilitätsereignisse umfasst, einschließlich zumindest zwei aus einem Fahrzeugwankereignis, einem Fahrzeuggierbewegungsereignis, einem Fahrzeugschlupfereignis und einem Fahrzeugtraktionsereignis.
D. System nach C, wobei jedem der zumindest zwei Stabilitätsereignisse eine Gewichtung zugeordnet wird, wenn es verwendet wird, um den Fahrerpunktewert zu bestimmen.
E. System nach A, wobei der Rechner 105 ferner programmiert ist, um den Fahrerpunktewert an einen Remote-Server 125 zu übermitteln.
F. System nach A, wobei der Korrekturfaktor auf einem Korrekturprozentsatz basiert, der verwendet wird, um das Stabilitätsereignis zu behandeln.
G. System nach Anspruch F, wobei der Korrekturfaktorprozentsatz in einem Bereich zwischen null (einschließlich) und einhundert Prozent liegt.
H. System nach A, wobei der Rechner ferner programmiert ist, um das zumindest eine Ereignis zu identifizieren, wenn die Daten einen Wert umfassen, der einen bestimmten Schwellenwert überschreitet.
I. System nach A, wobei der Rechner ferner programmiert ist, um verschiedene Fahrerpunktewerte zu bestimmen.
J. Verfahren, das in einem Rechner 105 in einem Fahrzeug 101 implementiert ist, wobei der Rechner 105 einen Prozessor und einen Speicher umfasst, wobei das Verfahren umfasst: während des Betriebs des Fahrzeugs 101, Identifizieren von Daten aus einem oder mehreren Datensammlern 110 in Bezug auf mindestens ein Stabilitätsereignis des Fahrzeugs 101; Bestimmen eines Korrekturfaktors in Bezug auf mindestens ein Ereignis; und Bestimmen eines Fahrerpunktewerts für einen Fahrer des Fahrzeugs 101, der zumindest teilweise auf den Daten in Bezug auf das zumindest eine Stabilitätsereignis und dem Korrekturfaktor in Bezug auf jedes zumindest eine Ereignis basiert.
K. Verfahren nach J, wobei das zumindest eine Stabilitätsereignis eines aus einem Fahrzeugüberschlagereignis, einem Fahrzeuggierbewegungsereignis, einem Fahrzeugschlupfereignis und einem Fahrzeugtraktionsereignis umfasst.
L. Verfahren nach J, wobei das zumindest eine Stabilitätsereignis zwei Stabilitätsereignisse umfasst, einschließlich zumindest zwei aus einem Fahrzeugwankereignis, einem Fahrzeuggierbewegungsereignis, einem Fahrzeugschlupfereignis und einem Fahrzeugtraktionsereignis umfasst.
M. Verfahren nach L, wobei jedem der zumindest zwei Stabilitätsereignisse eine Gewichtung zugeordnet wird, wenn es verwendet wird, um den Fahrerpunktewert zu bestimmen.
N. Verfahren nach J, ferner umfassend das Übermitteln des Fahrerpunktewerts an einen Remote-Server 125.
O. Verfahren nach J, wobei der Korrekturfaktor auf einem Korrekturprozentsatz basiert, der verwendet wird, um das Stabilitätsereignis zu behandeln.
P. Verfahren nach Anspruch O, wobei der Korrekturfaktorprozentsatz in einem Bereich zwischen null (einschließlich) und einhundert Prozent liegt.
Q. Verfahren nach J, ferner umfassend das Identifizieren des zumindest einen Ereignisses, wenn die Daten einen Wert über einem bestimmten Schwellenwert umfassen.
R. Verfahren nach J, ferner umfassend das Bestimmen verschiedener Fahrerpunktewerte.

605	Roll exceeding threshold detected?	Detektion von Überschlag über dem Schwellenwert?
610	Determine mitigation factor	Bestimmen des Korrekturfaktors
615	Derive combined roll rating	Ableiten der kombinierten Wankbewertung
620	Accumulate roll scores	Ansammeln der Wankpunktewerte
625	Yaw exceeding threshold detected?	Detektion von Gier über dem Schwellenwert?
630	Determine mitigation factor	Bestimmen des Korrekturfaktors
635	Derive combined yaw rating	Ableiten der kombinierten Gierbewertung
640	Accumulate yaw scores	Ansammeln der Gierpunktewerte
645	ABS threshold exceeded?	ABS über dem Schwellenwert?
650	Determine mitigation factor	Bestimmen des Korrekturfaktors
655	Derive combined ABS rating	Ableiten der kombinierten ABS- Bewertung
660	Accumulate ABS scores	Ansammeln der ABS-Punktewerte
665	Traction threshold exceeded?	Traktion über dem Schwellenwert?
670	Determine mitigation factor	Bestimmen des Korrekturfaktors
675	Derive combined traction rating	Ableiten der kombinierten Traktionsbewertung
680	Accumulate traction scores	Ansammeln der Traktionspunktewerte
685	Compute total score	Berechnen des Gesamtpunktewerts
687	Report total score	Melden des Gesamtpunktewerts
690	Evaluate mitigations	Korrekturen evaluieren
695	Report mitigation(s)	Korrektur(en) melden
697	Continue?	Fortsetzen?
	GOTO 605	ZU 605 GEHEN

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 [0017]
IEEE-802.11- [0019]

Claims

System, umfassend einen Rechner (105) in einem Fahrzeug (101), wobei der Rechner (105) einen Prozessor und einen Speicher umfasst, wobei der Rechner (105) programmiert ist, um: während des Betriebs des Fahrzeugs (101) Daten aus einem oder mehreren Datensammlern (110) in Bezug auf mindestens ein Stabilitätsereignis des Fahrzeugs (101) zu identifizieren; einen Korrekturfaktor in Bezug auf jedes zumindestens eine Ereignis zu bestimmen; und einen Fahrerpunktewert für einen Fahrer des Fahrzeugs (101) zu bestimmen, der zumindest teilweise auf den Daten in Bezug auf das zumindest eine Stabilitätsereignis und den Korrekturfaktor in Bezug auf jedes zumindest eine Ereignis basiert.
System nach Anspruch 1, wobei das zumindest eine Stabilitätsereignis eines aus einem Fahrzeugwankereignis, einem Fahrzeuggierbewegungsereignis, einem Fahrzeugschlupfereignis und einem Fahrzeugtraktionsereignis umfasst.
System nach Anspruch 1, wobei das zumindest eine Stabilitätsereignis zwei Stabilitätsereignisse umfasst, einschließlich zumindest zwei aus einem Fahrzeugwankereignis, einem Fahrzeuggierbewegungsereignis, einem Fahrzeugschlupfereignis und einem Fahrzeugtraktionsereignis.
System nach Anspruch 3, wobei jedem der zumindest zwei Stabilitätsereignisse eine Gewichtung zugeordnet wird, wenn es verwendet wird, um den Fahrerpunktewert zu bestimmen.
System nach Anspruch 1, wobei der Rechner (105) ferner programmiert ist, um den Fahrerpunktewert an einen Remote-Server (125) zu übermitteln.
Verfahren, das in einem Rechner (105) in einem Fahrzeug (101) implementiert ist, wobei der Rechner (105) einen Prozessor und einen Speicher umfasst, wobei das Verfahren umfasst: während des Betriebs des Fahrzeugs (101), Identifizieren von Daten aus einem oder mehreren Datensammlern (110) in Bezug auf mindestens ein Stabilitätsereignis des Fahrzeugs (101); Bestimmen eines Korrekturfaktors in Bezug auf mindestens ein Ereignis; und Bestimmen eines Fahrerpunktewerts für einen Fahrer des Fahrzeugs (101), der zumindest teilweise auf den Daten in Bezug auf das zumindest eine Stabilitätsereignis und dem Korrekturfaktor in Bezug auf jedes zumindest eine Ereignis basiert.
Verfahren nach Anspruch 6, wobei das zumindest eine Stabilitätsereignis eines aus einem Fahrzeugüberschlagereignis, einem Fahrzeuggierbewegungsereignis, einem Fahrzeugschlupfereignis und einem Fahrzeugtraktionsereignis umfasst.
Verfahren nach Anspruch 6, wobei das zumindest eine Stabilitätsereignis zwei Stabilitätsereignisse umfasst, einschließlich zumindest zwei aus einem Fahrzeugwankereignis, einem Fahrzeuggierbewegungsereignis, einem Fahrzeugschlupfereignis und einem Fahrzeugtraktionsereignis umfasst.
Verfahren nach Anspruch 8, wobei jedem der zumindest zwei Stabilitätsereignisse eine Gewichtung zugeordnet wird, wenn es verwendet wird, um den Fahrerpunktewert zu bestimmen.
Verfahren nach Anspruch 6, ferner umfassend das Übermitteln des Fahrerpunktewerts an einen Remote-Server (125).