DE112017006741T5

DE112017006741T5 - Stiller Alarm in einem autonomen Bus

Info

Publication number: DE112017006741T5
Application number: DE112017006741.3T
Authority: DE
Inventors: Oswaldo Perez Barrera; Alvaro JIMENEZ HERNANDEZ
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2017-02-01
Filing date: 2017-02-01
Publication date: 2019-10-10
Also published as: WO2018143974A1; CN110352147A; US20210049912A1; US11037449B2; CN110352147B

Abstract

Ein Fahrzeugsystem umfasst eine Taste, die für die Ausgabe eines Warnsignals programmiert ist, eine Kommunikationsschnittstelle, die für die drahtlose Übertragung einer Warnmeldung programmiert ist, und einen Prozessor, der so programmiert ist, dass er die Kommunikationsschnittstelle befehligt, um die Warnmeldung an einen Notfall zu übermitteln. Dienstanbieter als Reaktion auf die Schaltfläche, die das Warnsignal ausgibt. Die Warnmeldung identifiziert einen zukünftigen Fahrzeugstopp und eine Ankunftszeit an der zukünftigen Fahrzeughaltestelle.

Description

Hintergrund
Ein autonomer Bus ist ein Bus, der autonom von einer Haltestelle zur nächsten fährt. Der autonome Bus navigiert autonom zu vorgegebenen Orten (d.h. „Bushaltestellen“), hält an jedem Standort, öffnet die Tür, so dass die Fahrgäste den Bus betreten oder verlassen können, sammelt Zahlungsinformationen usw., ohne Fahrer.
Figurenliste

1 zeigt ein Beispiel für einen autonomen Bus mit Notrufsystem.
2 ist ein Blockdiagramm, das Beispielkomponenten des Notrufsystems und des autonomen Busses zeigt.
3 ist eine Overhead-Ansicht, die Beispielpositionen von Schaltflächen im autonomen Bus zur Aktivierung des Notrufsystems zeigt.
4A und 4B veranschaulichen Beispielpositionen von Schaltflächen relativ zu einem Sitz im autonomen Bus.
5A und 5B veranschaulichen Overhead-Ansichten des Busses, wo das Notrufsystem die Bewegung einer Person verfolgt, die eine der Tasten gedrückt hat.
6 ist ein Flussdiagramm eines Beispielprozesses, der vom Notrufsystem ausgeführt werden kann.

DETAILLIERTE DESCRIPTION
Fahrgäste von traditionellen Bussen, die einen Notfall wie einen medizinischen Notfall oder Diebstahl erleben, können den Fahrer benachrichtigen. Der Fahrer kann geeignete Maßnahmen ergreifen, z. B. den Bus anhalten und die Polizei oder einen Krankenwagen kontaktieren. Ein Fahrgast eines autonomen Busses kann sich jedoch nicht darauf verlassen, dass der Fahrer im Notfall hilft.
Eine Lösung besteht darin, in den autonomen Bus ein Notrufsystem für Fahrgäste zu integrieren, um den Rettungsdienst zu kontaktieren. Im Falle eines Diebes im Bus sollte der Fahrgast in der Lage sein, den Rettungsdienst zu kontaktieren, ohne den Dieb darüber zu verständigen, dass die Polizei gerufen wurde. Ein Beispiel für ein Notfallbenachrichtigungssystem für einen autonomen Bus umfasst eine Taste, die für die Ausgabe eines Warnsignals programmiert ist, eine Kommunikationsschnittstelle, die für die drahtlose Übertragung einer Warnmeldung programmiert ist, und einen Prozessor, der für die Kommunikation programmiert ist. Schnittstelle, um die Warnmeldung an einen Notfalldienstanbieter als Reaktion auf die Schaltfläche zu übermitteln, die das Warnsignal ausgibt. Mit anderen Worten, das Warnsignal bewirkt, dass die Warnmeldung generiert und übertragen wird. Die Warnmeldung identifiziert einen zukünftigen Fahrzeugstopp und eine Ankunftszeit an der zukünftigen Fahrzeughaltestelle.
In einigen möglichen Implementierungen kann der autonome Bus seine Ankunft an der nächsten Haltestelle mit Rettungsdiensten koordinieren. Zum Beispiel kann der autonome Bus zur gleichen Zeit oder nach eintreffender Rettungsdienst an der nächsten Haltestelle ankommen. Wenn also die Alarmsignalausgabe durch den Button eine stille Warnung ist, wird ein Dieb im Bus nicht wissen, dass die Polizei kontaktiert wurde, noch wird der Dieb die Möglichkeit haben, den Bus zu verlassen, bevor z.B. die Polizei an der nächsten Bushaltestelle eintrifft.
Die gezeigten Elemente können viele verschiedene Formen annehmen und mehrere und/oder alternative Komponenten und Einrichtungen enthalten. Die dargestellten Beispielkomponenten sind nicht als einschränkend gedacht. In der Tat können zusätzliche oder alternative Komponenten und/oder Implementierungen verwendet werden. Darüber hinaus werden die dargestellten Elemente nicht unbedingt maßstabsgetreu gezeichnet, es sei denn, sie werden ausdrücklich als solche angegeben.
Wie in dargestellt, verfügt ein autonomer Bus 100 über ein Notmeldesystem 105. Wie weiter unten ausführlich beschrieben, kommuniziert das Notrufsystem 105 mit einem Notdienstanbieter 110, wenn ein oder mehrere Fahrgäste im autonomen Bus 100 einen Notfall meldet. Beispielsweise kann das Notrufsystem 105 drahtlos eine Warnmeldung an den Notdienstanbieter 110 übermitteln und in einigen Fällen die Ankunft an einer zukünftigen Bushaltestelle (z. B. der nächsten Bushaltestelle) mit dem Notdienstanbieter 110 koordinieren.
Der autonome Bus 100 ist ein großes Automobil, das in der Lage ist, zahlreiche Fahrgäste gleichzeitig auf der Straße zu befördern. Der autonome Bus 100 kann in einen autonomen (z. B. fahrerlosen) Modus, einen teilautonomen Modus oder einen nicht autonomen Modus. Im autonomen Modus navigiert der autonome Bus 100 zu verschiedenen Haltestellen, ermöglicht es den Fahrgästen, den autonomen Bus 100 zu betreten oder zu verlassen, sammelt Zahlungsinformationen usw., ohne dass ein Fahrer anwesend ist.
Der Notdiensti 10 kann sich auf eine Polizeidienststelle, eine Feuerwehr, einen Krankenwagen, ein Krankenhaus oder ähnliches beziehen. Das Notrufsystem 105 kann über einen vernetzten Server mit dem Notdienstanbieter 110 kommunizieren. Der Notdienstanbieter 110 kann die an den Server übermittelten Warnmeldungen empfangen, die entsprechende Notfallreaktion ermitteln und die Reaktion mit dem Notrufsystem 105 koordinieren. Ein Beispiel für eine Notfallreaktion ist die Entsendung eines Polizeiautos, eines Feuerwehrautos oder eines Krankenwagens zum autonomen Bus 100. Darüber hinaus können, wie weiter unten näher erläutert, das Notrufsystem 105 und der Notdienstanbieter 110 die Ankunft des Notdienstanbieters 110 und des autonomen Busses 100 an einer künftigen Haltestelle koordinieren, so dass z. B. beide an der gleichen oder der Notdienst 110 kommt an der künftigen Haltestelle vor dem autonomen Bus 100 an.
Unter Bezugnahme auf enthält oder funktioniert das Notrufsystem 105 mehrere Tasten 115, eine Kamera 120, einen autonomen Modusregler 125, ein Navigationssystem 130, eine Kommunikationsschnittstelle 135, einen Speicher 140 und einen Prozessor 145 in Kommunikation über ein Kommunikationsnetz 150. Das Kommunikationsnetzwerk 150 umfasst Hardware, wie z. B. einen Kommunikationsbus, um die Kommunikation zwischen Komponenten des autonomen Busses 100, des Notmeldesystems 105 oder beides. Das Kommunikationsnetzwerk 150 kann die kabelgebundene oder drahtlose Kommunikation zwischen den Fahrzeugkomponenten in Übereinstimmung mit einer Reihe von Kommunikationsprotokollen wie Controller Area Network (CAN), Ethernet, WiFi, Local Interconnect Network (LIN) und/oder andere kabelgebundene oder drahtlose Mechanismen.
Die Tasten 115 sind physische oder virtuelle Tasten 115 innerhalb des autonomen Busses 100. Die Tasten 115 können sich in einer Schiene befinden, die sich über eine Länge des autonomen Busses 100 erstreckt (siehe 3 und 5A-5B), die sich unter den Sitzen oder zwischen den Sitzen befindet (siehe 4A-4B), usw. Wenn Sie gedrückt werden, wird die Taste 115 so programmiert oder anderweitig konfiguriert, dass sie ein Warnsignal an den Prozessor 145 ausgibt, das angibt, dass einer der Passagiere einen Notfall beim Notdienstanbieter 110 melden möchte. Jede Schaltfläche 115 kann einem eindeutigen Bezeichner zugeordnet sein. Bei dem eindeutigen Bezeichner kann es sich um eine Kombination aus Buchstaben und Zahlen handelt, die verwendet werden kann, um eine Schaltfläche 115 von einer anderen zu unterscheiden. Mit anderen Worten, keine zwei Tasten 115, die sich auf demselben autonomen Bus 100 befinden, dürfen denselben eindeutigen Bezeichner haben. Der eindeutige Bezeichner kann mit dem Warnsignal übertragen oder dargestellt werden.
In einigen Fällen gibt die Taste 115 das Warnsignal als Reaktion auf ein vorgegebenes Eingabemuster aus. Das heißt, das Warnsignal wird als Ergebnis von jemandem ausgegeben, der das vorbestimmte Eingabemuster eingibt. Das vorgegebene Eingabemuster kann doppel- oder dreifaches Klicken auf die Schaltfläche 115 umfassen (d. h. die Taste 115 zweimal oder dreimal innerhalb eines relativ kurzen Zeitraums, z. B. eine Sekunde, drücken und loslassen). Die Anforderung des vordefinierten Eingabemusters kann die Anzahl der falsch positiven Ergebnisse verringern, die auftreten können, wenn jemand versehentlich eine nahe gelegene Taste 115 stoßen würde.
Die Taste 115 gibt das Alarmsignal diskret aus. Das heißt, das Warnsignal wird über das Kommunikationsnetz 150 ohne hörbare, sichtbare oder haptische Reaktion übertragen. Andere Passagiere wissen vielleicht nicht, dass jemand einen der Tasten 115 gedrückt hat. Wenn es sich also um einen mutmaßlichen Dieb an Bord des autonomen Busses 100 handelt, wird dem Dieb nicht bewusst sein, dass einer der Fahrgäste den Knopf 115 gedrückt hat. Darüber hinaus kann das bloße Wissen, dass die Tasten 115 verfügbar sind, dem Dieb eine Pause geben.
Die Kamera 120 ist ein Sehsensor im autonomen Bus 100 mit Blick auf einige oder alle Passagiere. Der autonome Bus 100 kann eine beliebige Anzahl von Kameras 120 enthalten. Jede Kamera 120 kann ein Objektiv enthalten, das Licht auf z. B. einen CCD-Bildsensor, einen CMOS-Bildsensor usw. projiziert. Die Kamera 120 verarbeitet das Licht und erzeugt ein Bild. Das Bild kann an den Prozessor 145 ausgegeben werden und, wie weiter unten ausführlicher erläutert, kann verwendet werden, um zu identifizieren, wer die Taste 115 gedrückt hat, ob ein Dieb an Bord des autonomen Busses 100 ist, verfolgen Sie die Bewegung der Person, die die Taste 115 gedrückt hat. , verfolgen Sie die Bewegung des Diebes, etc. Darüber hinaus kann das Bild an den Notdienst10 übertragen werden, so dass z.B. der Notdienstanbieter 110 den Notfall visuell bestätigen oder feststellen kann, ob es sich um einen Fehlalarm handelt.
Der autonome Modusregler 125, der über Schaltungen, Chips oder andere elektronische Komponenten implementiert wird, ist für verschiedene Operationen programmiert. Der autonome Modusregler 125 empfängt Daten von verschiedenen Fahrzeugsensoren, zu denen ein LIDAR-Sensor, ein Radarsensor, ein Vision-Sensor (d.h. eine externe Kamera), ein Ultraschallsensor usw. gehören können. Der autonome Modusregler 125 ist so programmiert, dass er Steuersignale entsprechend den von den Sensoren empfangenen Signalen ausgibt. Die Steuersignale können an verschiedene Aktoren ausgegeben werden, die mit der Lenkung, Beschleunigung und Bremsung des autonomen Busses 100 verbunden sind. So kann der autonome Modusregler 125 die Steuersignale ausgeben, um den autonomen Modus für den autonomen Bus 100 auszuführen.
Das Navigationssystem 130 wird über Schaltungen, Chips oder andere elektronische Komponenten implementiert, die einen aktuellen Standort des autonomen Busses 100 bestimmen können. Das Navigationssystem 130 kann über ein satellitengestütztes System wie das Global Positioning System (GPS) implementiert werden. Das Navigationssystem 130 kann die Position des autonomen Busses 100 auf der Grundlage von Signalen, die von verschiedenen Satelliten in der Erdumlaufbahn empfangen werden, triangulieren. Das Navigationssystem 130 ist so programmiert, dass Signale ausgegeben werden, die den Standort des autonomen Busses 100 z.B. an den Prozessor 145 über das Kommunikationsnetz 150 darstellen. In einigen Fällen ist das Navigationssystem 130 so programmiert, dass eine Route vom aktuellen Standort zu einem zukünftigen Standort bestimmt wird, z. B. eine zukünftige Bushaltestelle. Das Navigationssystem 130 kann auf eine virtuelle Karte zugreifen, die im Speicher 140 gespeichert ist (siehe unten) und die Route entsprechend den virtuellen Kartendaten entwickeln.
Die Kommunikationsschnittstelle 135 wird über Schaltungen, Chips oder andere elektronische Komponenten implementiert, die die drahtlose Kommunikation zwischen dem autonomen Bus 100 und dem Notdienstanbieter 110 erleichtern. Beispielsweise kann die Kommunikationsschnittstelle 135 so programmiert werden, dass sie die Warnmeldung drahtlos überträgt, nachdem die Taste 115 das Warnsignal ausgegeben hat. Die Kommunikationsschnittstelle 135 kann so programmiert werden, dass sie die Warnmeldung als Antwort auf einen Befehl des Prozessors 145 überträgt. Das heißt, der Befehl des Prozessors 145 bewirkt, dass die Kommunikationsschnittstelle 135 die Warnmeldung überträgt. Die Warnmeldung kann darauf hinweisen, dass ein Fahrgast einen Notfall gemeldet hat, die eindeutige Kennung für die Taste 115, die vom Fahrgast gedrückt wird, eine eindeutige Kennung für den autonomen Bus 100, die Position des autonomen Busses 100, die durch das Navigationssystem 130 bestimmt wird. , eine zukünftige Bushaltestelle, eine geschätzte Ankunftszeit an der zukünftigen Bushaltestelle usw.
In einigen möglichen Implementierungen ist die Kommunikationsschnittstelle 135 so programmiert, dass sie drahtlos eine Notfallreaktion vom Notfalldienstanbieter 110 erhält. Die Notfallreaktion kann auf eine Ankunftszeit des Notdienstes 110 an einer künftigen Bushaltestelle hinweisen. Die Kommunikationsschnittstelle 135 kann die Notfallreaktion, einschließlich der Ankunftszeit des Notdienstanbieters 110 an der künftigen Bushaltestelle, z.B. an den Prozessor 145 über das Kommunikationsnetz 150 übertragen.
Die Kommunikationsschnittstelle 135 kann so programmiert werden, dass sie in Übereinstimmung mit einer beliebigen Anzahl von kabelgebundenen oder drahtlosen Kommunikationsprotokollen kommuniziert. Beispielsweise kann die Kommunikationsschnittstelle 135 so programmiert werden, dass sie in Übereinstimmung mit einem Satellitenkommunikationsprotokoll, einem zellulären Kommunikationsprotokoll (LTE, 3G usw.), Bluetooth®, Bluetooth® Low Energy, Ethernet, CAN, WiFi, LIN usw. kommuniziert.
Der Speicher 140 wird über Schaltungen, Chips oder andere elektronische Komponenten implementiert und kann einen oder mehrere lesegeschützten Speicher (ROM), Random Access Memory (RAM), Flash-Speicher, elektrisch programmierbaren Speicher (EPROM), elektrisch programmierbar und ausserserbar enthalten Speicher (EEPROM), eingebettete MultiMediaCard (eMMC), eine Festplatte oder flüchtige oder nichtflüchtige Medien usw. Der Speicher 140 kann Daten wie eine virtuelle Karte oder eine Tabelle speichern, die zukünftige Fahrzeugstopps identifiziert. Die im Speicher 140 gespeicherten Daten können für den Prozessor 145, das Navigationssystem 130 und möglicherweise andere Komponenten des Notmeldesystems 105, des autonomen Busses 100 oder beides zugänglich sein.
Der Prozessor 145 wird über Schaltungen, Chips oder andere elektronische Komponenten implementiert, die verschiedene Operationen durchführen, einschließlich der Verarbeitung des Warnsignals, der Verarbeitung der Warnmeldung und der Verarbeitung der Notfallreaktion, die vom Notfall empfangen wird. Dienstleister 110 und möglicherweise die Steuerung bestimmter autonomer Vorgänge des autonomen Busses 100. Beispielsweise kann der Prozessor 145 die Alarmsignalausgabe über die von einem der Passagiere gedrückte Taste 115 empfangen und als Reaktion die Warnmeldung generieren und die Kommunikationsschnittstelle 135 befehlen, um die Warnmeldung an den Notdienst zu senden. Anbieter 110.
Der Prozessor 145 kann so programmiert werden, dass er die Warnmeldung generiert, um verschiedene Informationen einzuschließen. Die Warnmeldung kann z. B. darauf hinweisen, dass ein Fahrgast einen Notfall gemeldet hat, die eindeutige Kennung für die vom Fahrgast gedrückte Taste 115, eine eindeutige Kennung für den autonomen Bus 100, den aktuellen Standort des autonomen Busses 100, der durch die Navigationssystem 130, eine zukünftige Bushaltestelle, eine geschätzte Ankunftszeit an der zukünftigen Bushaltestelle, etc. Daher kann das Generieren der Warnmeldung den Prozessor 145 umfassen, der im Speicher 140 gespeicherte Daten abruft, Daten vom Navigationssystem 130 empfängt, den eindeutigen Bezeichner von der Schaltfläche 115 empfängt usw. Beispielsweise kann der Prozessor 145 so programmiert werden, dass er den aktuellen Standort des autonomen Busses 100 erhält und den Speicher 140 nach der virtuellen Karte oder Tabelle abfragt, um den Standort einer zukünftigen Bushaltestelle (z. B. die nächste Bushaltestelle) relativ zur aktuellen Position des utonomous Bus 100. Der Prozessor 145 kann alternativ den aktuellen Standort des autonomen Busses 100, den Standort der künftigen Bushaltestelle oder beides vom Navigationssystem 130 erhalten. Der Prozessor 145 kann weiter programmiert werden, um die Entfernung des derzeitigen Standorts des autonomen Busses 100 zur künftigen Bushaltestelle zu bestimmen und die Ankunftszeit des autonomen Busses 100 als zukünftige Bushaltestelle zu berechnen oder zu schätzen. Der Prozessor 145 kann alternativ die Entfernung zur künftigen Bushaltestelle und die Ankunftszeit vom Navigationssystem 130 erhalten. Der Prozessor 145, das Navigationssystem 130 oder beides, kann bei der Berechnung oder Schätzung der Ankunftszeit an der künftigen Bushaltestelle andere Informationen berücksichtigen, wie z. B. die Geschwindigkeit des autonomen Busses 100.
In einer möglichen Umsetzung wird je nach Art des Notfalls der Prozessor 145 so programmiert, dass er die Ankunft des autonomen Busses 100 an der künftigen Fahrzeughaltestelle mit dem Eintreffen des Notdienstleistenden 110 an der künftigen Fahrzeughaltestelle koordiniert. Beispielsweise kann der Prozessor 145 so programmiert werden, dass er den autonomen Modusregler 125 so beaufträgt, dass der autonome Bus 100 mit einer niedrigeren Geschwindigkeit betrieben wird, so dass der Notdienstanbieter 110 an der künftigen Bushaltestelle vor dem autonomen Bus 100 eintrifft. Der Prozessor 145 kann den Zeitpunkt der Ankunft des Notdienstleistenden 110 aus dem Notfallaussetzen bestimmen. Das heißt, die Notfallreaktion kann anzeigen, wann der Notdienst110 an der künftigen Bushaltestelle eintreffen kann. Wenn der Prozessor 145 feststellt, dass der autonome Bus 100 zuerst dort ankommt, kann der Prozessor 145 so programmiert werden, dass er den autonomen Modusregler 125 befehligt, um den autonomen Bus 100 zu verlangsamen, so dass der Notdienstanbieter 110 am zukünftigen Bus ankommt, zuerst anhalten.
Der Prozessor 145 kann so programmiert werden, dass er die Ankunft des autonomen Busses 100 an der künftigen Haltestelle mit der des Notdienstanbieters 110 koordiniert, wenn es sich bei dem Notfall z.B. um einen mutmaßlichen Dieb im autonomen Bus 100 handelt. Auf diese Weise hat der Dieb keine Möglichkeit, den Bus zu verlassen, bevor der Notdienst 110 (d.h. die Polizei) eintrifft. Darüber hinaus kann der Prozessor 145 den autonomen Modus-Controller 125 befehlen, um die Geschwindigkeit des autonomen Busses 100 so wenig wie nötig zu reduzieren, so dass der Dieb nicht bemerkt, dass der autonome Bus 100 langsamer als normal fährt.
Der Prozessor 145 kann weiter programmiert werden, um dem Notdienstanbieter 110 zu helfen, zu überwachen, was auf dem autonomen Bus 100 passiert, nachdem jemand die Taste 115 gedrückt hat. Beispielsweise kann der Prozessor 145 das von der Kamera 120 aufgenommene Bild verarbeiten und identifizieren, welcher Passagier wahrscheinlich die Taste 115 gedrückt hat, z. B. auf der Nähe des Passagiers zur Taste 115, die gedrückt wurde. Der Prozessor 145 kann die Bildverarbeitung weiter verwenden, um andere Passagiere in der Nähe zu identifizieren, einschließlich eines potenziellen Diebes. Der Prozessor 145 kann weitere Bilder verarbeiten, die von der Kamera 120 aufgenommen wurden, um die Bewegung der Passagiere zu erkennen, einschließlich des Passagiers, der den Knopf 115 gedrückt hat, und des Passagiers, der ein potenzieller Dieb sein könnte. Der Prozessor 145 kann die Kommunikationsschnittstelle 135 befehlen, um von der Kamera 120 aufgenommene Bilder an den Notdienstanbieter 110 zu übertragen. Bevor der Kommunikationsschnittstelle 135 die Bilder übertragen werden, kann der Prozessor 145 das Bild so ändern, dass die Person, die die Taste 115 gedrückt hat, der potenzielle Dieb und die Bewegung der Passagiere angezeigt wird. Der Prozessor 145 kann das Bild mit Text oder Formen (z. B. Kreis, Quadrat, Rechteck usw.) um den Passagier, der die Taste 115 gedrückt hat, und potenziellen Dieb, falls bekannt, ändern. Die Formen können farbkodiert (d.h. grün für den Passagier, der den Knopf 115 gedrückt hat und rot für den potenziellen Dieb) oder anderweitig gekennzeichnet sein, um dem Notdienstanbieter 110 klar zu machen, wer wer ist.
3 ist eine Overhead-Ansicht, die Beispielpositionen der Tasten 115 im autonomen Bus 100 zur Aktivierung des Notmeldesystems 105 zeigt. 4A und 4B veranschaulichen Beispielpositionen der Tasten 115 relativ zu einem Sitz 160 im autonomen Bus 100. Nur einige Sitze 160 und Knöpfe 115 sind aus Gründen der Einfachheit nummeriert. Wie in dargestellt, können mehrere Tasten 115 in Oberschienen 155 eingebaut werden, die sich entlang der Länge des autonomen Busses 100 erstrecken. In sind zwei Oberschienen 155 und jede Oberleitung 155 mit zwölf Tasten 115 dargestellt. Der autonome Bus 100 kann eine beliebige Anzahl von Oberleitungsschienen 155 und eine beliebige Anzahl von Tasten 115 haben. Ferner kann sich unter Bezugnahme auf 4A und 4B eine Taste 115 auf einem oder mehreren Sitzplätzen 160 befinden. Bild 4A zeigt eine Taste 115 unter einem Sitz 160. Bild: 4B zeigt eine Taste 115 auf einer Armlehne 165 zwischen zwei Sitzen 160. Wenn eine der Tasten 115 in der Oberleitung 155 oder auf oder zwischen den Sitzen 160 gedrückt wird, z. B. wenn die Taste 115 mit dem vorgegebenen Eingangsmuster gedrückt wird, gibt die Taste 115 das Warnsignal an den Prozessor 145 aus. Der Prozessor 145 verarbeitet das Warnsignal und befiehlt der Kommunikationsschnittstelle 135, die Warnmeldung an den Notdienstanbieter 110 zu übermitteln.
Unter Bezugnahme auf 5A und 5B kann der Prozessor 145 die Bewegung der Person, die eine der Tasten 115 gedrückt hat, weiter verfolgen. stellt die Positionen der Passagiere (als schwarze Punkte dargestellt) zum Zeitpunkt des Drückens einer der Tasten 115 dar. Der Prozessor 145 kann als Reaktion auf den Empfang des Warnsignals die Kamera 120 befehlen, ein Bild aus dem Inneren des autonomen Busses 100 aufzunehmen. Daher kann der Empfang des Warnsignals dazu führen, dass der Prozessor 145 die Kamera 120 befehligt, das Bild aufzunehmen. Der Prozessor 145 kann das Bild von der Kamera 120 empfangen, das Bild verarbeiten und bestimmen, wer die Taste 115 gedrückt hat, basierend darauf, wer der gedrückten Taste 115 am nächsten ist. Beispielsweise kann der Prozessor 145 die Bildverarbeitung verwenden, um zu bestimmen, welcher Zeiger des Passagiers der gedrückten Taste 115 am nächsten ist. Der Prozessor 145 kann diese Person als die Person identifizieren, die die Taste 115 gedrückt hat.
Im Beispiel von kann der Prozessor 145 anhand der eindeutigen Identifikation im Alarmsignal feststellen, dass eine Taste 115 in der Nähe der Rückseite des autonomen Busses 100 gedrückt wurde. Darüber hinaus kann der Prozessor 145 das von der Kamera 120 aufgenommene Bild verarbeiten, um festzustellen, dass die Person, die neben der Taste 115 steht, die gedrückt wurde, die Person war, die die Taste 115 gedrückt hat. Die vom Prozessor 145 in BILD 5A identifizierte Person wird mit einem Feld in Phantomlinie angezeigt.
Unter Bezugnahme auf kann der Prozessor 145 die Bewegung der Person verfolgen, die die Taste 115 gedrückt hat. Zum Beispiel, nachdem die Tasten 115 gedrückt wird, kann der Prozessor 145 weiterhin Bilder (still oder Video) von der Kamera 120 aufgenommen empfangen. Der Prozessor 145 kann die Bildverarbeitung auf den Bildern durchführen, um festzustellen, ob sich der Fahrgast, der die Taste 115 gedrückt hat, um den autonomen Bus 100 bewegt. Darüber hinaus kann der Prozessor 145 eine beliebige Anzahl der Bilder an den Notdienstanbieter 110 übertragen. In einigen Fällen kann der Prozessor 145 eines oder mehrere der Bilder ändern, um dem Notdienstanbieter 110 anzuzeigen, der die Taste 115 gedrückt hat. Zum Beispiel, wie in 5A und 5B gezeigt, kann der Prozessor 145 das Bild ändern, um eine Form (z. B. einen Kreis oder ein Rechteck) über die Person, die der Prozessor 145 bestimmt hat, die Taste 115 gedrückt hat.
Im Beispiel von bewegte sich die Person, die die Taste 115 drückte, zur hinteren Tür 170B und setzte sich in einen der Sitze in der Nähe der hinteren Tür 170B. Der Prozessor 145 kann dieses Bild an den Notdienstanbieter 110 übertragen. Wenn es sich also um einen medizinischen Notfall handelt, kann der Notdienstleistender 110 wissen, wer im autonomen Bus 100 den medizinischen Notfall erleidet und wo sich diese Person im autonomen Bus 100 befindet.
6 ist ein Flussdiagramm eines Beispielprozesses 600, der vom Notmeldesystem 105 ausgeführt werden kann. Der Prozess 600 kann jederzeit beginnen, während der autonome Bus 100 läuft, zumindest im „Zubehör“-Modus. Der Prozess 600 kann weiterausgeführt werden, bis z.B. der autonome Bus 100 nicht mehr läuft.
Bei Entscheidungsblock 605 wartet das Notrufsystem 105 darauf, dass ein Passagier einen Knopf 115 drückt. Das heißt, der Prozessor 145 kann bestimmen, ob der Passagier die Taste 115 gedrückt hat, z. B. basierend darauf, ob das Warnsignal empfangen wurde. Das Alarmsignal kann von der Taste 115 als Reaktion auf einen Passagier erzeugt und ausgegeben werden, der die Taste 115 entsprechend dem vorgegebenen Eingangsmuster drückt. Wenn das Warnsignal vom Prozessor 145 empfangen wird, wird der Prozess 600 mit Block 610 fortgesetzt. Andernfalls kann Block 605 wiederholt werden, bis das Warnsignal empfangen wird.
Bei Block 610 bestimmt das Notrufsystem 105 einen aktuellen Standort des autonomen Busses 100. Zum Beispiel kann der Prozessor 145 den aktuellen Standort des autonomen Busses 100 anhand z.B. von Signalen aus dem Navigationssystem 130 empfangen bestimmen.
In Block 615 identifiziert das Notrufsystem 105 eine zukünftige Bushaltestelle, die auf (d.h. relativ zum) aktuellen Standort des autonomen Busses 100 basiert. Der Prozessor 145 kann die zukünftige Bushaltestelle identifizieren, indem er auf die virtuelle Karte im Speicher 140 zugreift und die nächste Haltestelle entlang einer Route des autonomen Busses 100 als zukünftige Bushaltestelle auswählt. Anstelle einer Karte kann der Prozessor 145 die zukünftige Bushaltestelle identifizieren, indem er auf in einer Tabelle gespeicherte Daten zugreift. Das heißt, der Prozessor 145 kann bestimmen, welche Daten die nächste Bushaltestelle entlang der Strecke des autonomen Busses 100 darstellen und diese Bushaltestelle als zukünftige Bushaltestelle identifizieren.
Bei Block 620 bestimmt das Notmeldesystem 105 die Ankunftszeit des autonomen Busses 100 an der künftigen Fahrzeughaltestelle. Der Prozessor 145 kann die Ankunftszeit basierend auf dem aktuellen Standort des autonomen Busses 100 bestimmen. Das heißt, der Prozessor 145 kann die Ankunftszeit basierend auf der Entfernung zwischen dem aktuellen Standort des autonomen Busses 100 und der zukünftigen Bushaltestelle, der Geschwindigkeit des autonomen Busses 100 usw. berechnen. Der Prozessor 145 kann den Abstand zwischen dem aktuellen Standort des autonomen Busses 100 und der zukünftigen Bushaltestelle von den Daten in der virtuellen Karte, der Tabelle usw. bestimmen.
Bei Block 625 generiert das Notrufsystem 105 eine Alarmmeldung. Der Prozessor 145 kann die Warnmeldung generieren, die die zukünftige Bushaltestelle, die Ankunftszeit des autonomen Busses 100 an der künftigen Bushaltestelle, die Art des Notfalls (falls bekannt), eine Identifizierung des autonomen Busses 100, eine Passagier, der die Taste 115 gedrückt hat, ein oder mehrere Bilder, die von den Kameras 120 im autonomen Bus 100 oder dergleichen aufgenommen wurden. Daher kann der Prozessor 145 vor dem Generieren der Warnmeldung eine oder mehrere der Kameras 120 befehlen, um ein Bild aus dem inneren des autonomen Busses 100 zu erfassen, das Bild zu verarbeiten, um den Passagier zu identifizieren, der die Taste 115 gedrückt hat, das Bild zu aktualisieren, um anzuzeigen, wer die Taste 115, und integrieren Sie das aktualisierte Bild in die Warnmeldung. Darüber hinaus können einige Informationen, wie z. B. zusätzliche Bilder, in anderen Teilen des Prozesses 600 übertragen werden.
Bei Block 630 überträgt das Notrufsystem 105 die Alarmmeldung an den Notdienst10. Der Prozessor 145 kann die Kommunikationsschnittstelle 135 befehlen, die Warnmeldung drahtlos an den Notdienstanbieter 110 zu übermitteln. Der Prozessor 145 kann bei einigen möglichen Ansätzen zwischen verschiedenen Notdienstanbietern 110 auswählen, die z. B. auf der Art des Notfalls basieren, sofern bekannt. Das heißt, der Prozessor 145 kann die Kommunikationsschnittstelle 135 befehlen, die Warnmeldung an eine Polizeidienststelle zu übermitteln, wenn der Notfall ein Verbrechen am autonomen Bus 100 beinhaltet. Der Prozessor 145 kann die Kommunikationsschnittstelle 135 befehlen, die Warnmeldung an ein Krankenhaus oder einen Rettungsdienst zu übermitteln, wenn der Notfall einen medizinischen Notfall betrifft. Der Prozessor 145 kann die Kommunikationsschnittstelle 135 befehlen, die Alarmmeldung an eine Feuerwehr zu übermitteln, wenn der Notfall einen Brand im Bus mit sich bringt. Ist die Art des Notfalls unbekannt, kann der Prozessor 145 die Kommunikationsschnittstelle 135 befehlen, die Warnmeldung an einen allgemeinen Notfalldisponenten (z. B. einen 911-Dispatcher) zu übermitteln.
Bei Entscheidungsblock 635 wartet das Notrufsystem 105 auf eine Notfallreaktion. Die Notfallreaktion kann vom Notdienst110 übermittelt und über die Kommunikationsschnittstelle 135 beim Notrufsystem 105 empfangen werden. Der Prozess 600 kann mit der Blockierung 640 fortfahren, wenn die Notfallreaktion eingeht. Andernfalls kann der Prozess 600 block 635 weiterhin ausführen. In einigen Fällen, z. B. wenn die Notfallreaktion nicht innerhalb einer bestimmten Zeit (z. B. 2 Minuten) empfangen wird, kann der Prozess 600 auf Block 630 zurückkehren, sodass die Notfallnachricht erneut übermittelt werden kann.
Bei Entscheidungsblock 640 bestimmt das Notrufsystem 105 anhand der Notfallversorgung, ob die Ankunft an der künftigen Bushaltestelle mit dem Notrufanbieter 110 koordiniert werden soll. Die Kommunikationsschnittstelle 135 kann die Notfallreaktion an den Prozessor 145 weiterleiten, der die Notfallreaktion verarbeiten kann. Der Prozessor 145 kann aus der Notfallreaktion entscheiden, ob der Eintreffen der Autonomen an der künftigen Bushaltestelle mit dem Eintreffen des Notdienstleistenden 110 an der künftigen Bushaltestelle koordiniert werden soll. So kann beispielsweise der Notdienstanbieter 110 in der Notfallreaktion angeben, dass die Ankunft an der künftigen Bushaltestelle koordiniert werden sollte. Ob die Ankunft an der künftigen Bushaltestelle koordiniert werden soll, hängt möglicherweise von der Art des Notfalls ab. Beispielsweise kann die Koordinierung der Ankunft an der künftigen Bushaltestelle einen mutmaßlichen Dieb daran hindern, den Bus zu verlassen, bevor die Polizei eintrifft. In einigen Fällen, z. B. aufgrund der Art des Notfalls, kann der Prozessor 145 automatisch beschließen, die Ankunft an der zukünftigen Bushaltestelle zu koordinieren. Das heißt, wenn der Prozessor 145 feststellt, dass der Notfall ein potenzielles Verbrechen am autonomen Bus 100 beinhaltet, kann der Prozessor 145 versuchen, die Ankunft an der zukünftigen Bushaltestelle unabhängig von einer Anweisung zu koordinieren, dies in der Notfallreaktion zu tun. In solchen Fällen kann der Prozessor 145 angeben, dass er das Eintreffen in die Warnmeldung koordiniert, die in Block 630 übermittelt wird. Wenn die Ankunft an der zukünftigen Haltestelle koordiniert werden soll, wird der Prozess 600 zu Blockieren 645. Andernfalls wird der Prozess 600 mit der Sperrung von 650 fortgesetzt.
Bei Block 645 koordiniert das Notrufsystem 105 die Ankunft an der künftigen Haltestelle beim Notdienst 110. So kann der Prozessor 145 beispielsweise die Ankunftszeit des Notdienstleistenden 110 an der zukünftigen Haltestelle von der Notfallreaktion erhalten. Der Prozessor 145 kann das mit der Ankunftszeit des autonomen Busses 100 an der zukünftigen Haltestelle vergleichen. Wenn der autonome Bus 100 voraussichtlich vor dem Notdienstanbieter 110 an der haltestelle ankommen wird, kann der Prozessor 145 den autonomen Bus 100 befehlen, seine Geschwindigkeit zu verlangsamen. Beispielsweise kann der Prozessor 145 ein Steuersignal an den autonomen Modusregler 125 ausgeben, der den autonomen Modusregler 125 befehligt, um den autonomen Bus 100 mit einer langsameren Geschwindigkeit zu betreiben. Der Prozessor 145 kann den autonomen Modusregler 125 befehlen, um die Geschwindigkeit des autonomen Busses 100 um einen Betrag zu reduzieren, so dass der Notdienstanbieter 110 an der künftigen Bushaltestelle vor dem autonomen Bus 100 eintrifft. Der Prozessor 145 kann die Geschwindigkeitsreduzierung auf der Grundlage einer Entfernung zur künftigen Bushaltestelle und der Ankunftszeit des Notdienstanbieters 110 an der künftigen Bushaltestelle berechnen.
Mit Entscheidungsblock 650 kann das Notrufsystem 105 bestimmen, ob der autonome Bus 100 an der künftigen Bushaltestelle angekommen ist. Der Prozessor 145 kann eine solche Bestimmung auf der Grundlage der aktuellen Position des autonomen Busses 100 treffen, die vom Navigationssystem 130 bestimmt wird. Wenn also der Prozessor 145 feststellt, dass der aktuelle Standort des autonomen Busses 100 und der zukünftigen Bushaltestelle identisch sind, kann der Prozessor 145 feststellen, dass der autonome Bus 100 an der zukünftigen Bushaltestelle angekommen ist. Wenn der autonome Bus 100 an der künftigen Bushaltestelle ankommt, kann der Prozess 600 mit der Sperrung 655 fortfahren. Andernfalls führt der Prozess 600 weiterhin Block 650 aus.
Bei Block 655 entriegelt und öffnet das Notmeldesystem 105 die Türen 170A und 170B zum autonomen Bus 100. Das heißt, der Prozessor 145 kann ein Signal an einen Controller im autonomen Bus 100 ausgeben, der den Controller befiehlt, die Türen 170A und 170B zu entriegeln, die Türen 170A und 170B zu öffnen oder beides. Auf diese Weise kann der Notdienstanbieter 110 in den autonomen Bus 100 einsteigen, wenn der autonome Bus 100 angehalten wird. In einigen Fällen sendet das Notrufsignal nur das Signal an den Controller, um die Türen nach Genehmigung des Notdienstanbieters 110 zu entriegeln. Das heißt, der Notdienstanbieter 110 muss möglicherweise das Notrufsystem 105 ermächtigen, die Türen 170A und 170B je nach Art des Notfalls zu entriegeln (z. B. um zu verhindern, dass ein Dieb entkommt).
Der Prozess 600 kann nach Block 655 enden.
Im Allgemeinen können die beschriebenen Computersysteme und/oder -geräte eines der computergestützten Betriebssysteme verwenden, einschließlich, aber keineswegs beschränkt auf Versionen und/oder Varianten der Ford Sync® Anwendung, AppLink/Smart Device Link Middleware, Microsoft Automotive® Betriebssystem, das Betriebssystem Microsoft Windows®, das Unix-Betriebssystem (z. B. das Betriebssystem Solaris®, das von der Oracle Corporation of Redwood Shores, Kalifornien, vertrieben wird), das AIX UNIX-Betriebssystem, das von International Business Machines of Armonk, New York, das Linux-Betriebssystem, die Mac OSX- und iOS-Betriebssysteme, vertrieben von Apple Inc. aus Cupertino, Kalifornien, das BlackBerry OS, das von Blackberry, Ltd. aus Waterloo, Kanada, und Android vertrieben wird Betriebssystem entwickelt von Google, Inc. und der Open Handset Alliance oder der QNX® CAR Platform for Infotainment von QNX Software Systems. Beispiele für Computergeräte sind, ohne Einschränkung, ein Bordcomputer, eine Computerarbeitsstation, ein Server, ein Desktop, ein Notebook, ein Laptop oder ein Handheld-Computer oder ein anderes Computersystem und/oder -Gerät.
Computergeräte enthalten in der Regel computerausführbare Anweisungen, in denen die Anweisungen von einem oder mehreren Computergeräten wie den oben aufgeführten ausführbar sein können. Computer-ausführbare Anweisungen können aus Computerprogrammen kompiliert oder interpretiert werden, die mit einer Vielzahl von Programmiersprachen und/oder Technologien erstellt wurden, einschließlich, aber nicht beschränkt, und entweder allein oder in Kombination, Java™, C, C++, Visual Basic, Java Skript, Perl, etc. Einige dieser Anwendungen können auf einer virtuellen Maschine kompiliert und ausgeführt werden, z. B. auf der virtuellen Java-Maschine, der virtuellen Maschine Dalvik oder dergleichen. Im Allgemeinen erhält 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 hier beschriebenen Prozesse. Solche Anweisungen und andere Daten können mit einer Vielzahl von computerlesbaren Medien gespeichert und übertragen werden.
Ein computerlesbares Medium (auch als prozessorlesbares Medium bezeichnet) umfasst jedes nicht-transitorische (z. B. greifbare) Medium, das an der Bereitstellung von Daten (z. B. Anweisungen) beteiligt ist, die von einem Computer (z. B. von einem Prozessor eines Computers) gelesen werden können. Ein solches Medium kann viele Formen annehmen, einschließlich, aber nicht beschränkt auf nichtflüchtige Medien und flüchtige Medien. Nichtflüchtige Medien können z. B. optische oder magnetische Datenträger und andere persistente Speicher umfassen. Flüchtige Medien können z. B. dynamischen Arbeitsspeicher für zu zufälligen Zugriff (DRAM) umfassen, der in der Regel einen Hauptspeicher darstellt. Diese Anweisungen können von einem oder mehreren Übertragungsmedien übertragen werden, einschließlich Koaxialkabeln, Kupferdraht und Glasfasern, einschließlich der Drähte, die einen Systembus umfassen, der an einen Prozessor eines Computers gekoppelt ist. Häufige Formen computerlesbarer Medien sind z. B. eine Diskette, eine flexible Diskette, eine Festplatte, ein Magnetband, jedes andere magnetische Medium, eine CD-ROM, DVD, jedes andere optische Medium, Lochkarten, Papierband, jedes andere physikalische Medium mit Bohrungsmustern, RAM, ein PROM, ein EPROM, ein FLASH-EEPROM, jeder andere Speicherchip oder jede andere Kassette oder jedes andere Medium, von dem ein Computer lesen kann.
Datenbanken, Datenrepositories oder andere hier beschriebene Datenspeicher können verschiedene Arten von Mechanismen zum Speichern, Zugreifen und Abrufen verschiedener Arten von Daten umfassen, einschließlich einer hierarchischen Datenbank, einer Gruppe von Dateien in einem Dateisystem, einer Anwendungsdatenbank in einem proprietäres Format, ein relationales Datenbankmanagementsystem (RDBMS) usw. Jeder dieser Datenspeicher ist in der Regel in einem Computergerät mit einem Computerbetriebssystem wie einem der oben genannten enthalten und wird über ein Netzwerk in einer oder mehreren artenunterschiedlichen Weisen zugegriffen. Ein Dateisystem kann von einem Computerbetriebssystem aus zugänglich sein und Dateien enthalten, die in verschiedenen Formaten gespeichert sind. Ein RDBMS verwendet im Allgemeinen die Structured Query Language (SQL) zusätzlich zu einer Sprache zum Erstellen, Speichern, Bearbeiten und Ausführen gespeicherter Prozeduren, z. B. der oben genannten PL/SQL-Sprache.
In einigen Beispielen können Systemelemente als computerlesbare Anweisungen (z. B. Software) auf einem oder mehreren Computergeräten (z. B. Servern, PCs usw.) implementiert werden, die auf computerlesbaren Medien gespeichert sind, die damit verbunden sind (z. B. Datenträger, Speicher, usw.). Ein Computerprogrammprodukt kann solche Anweisungen umfassen, die auf computerlesbaren Medien gespeichert sind, um die hier beschriebenen Funktionen auszuführen.
Hinsichtlich der hier beschriebenen Prozesse, Systeme, Methoden, Heuristiken usw. ist zu verstehen, dass, obwohl die Schritte solcher Prozesse usw. nach einer bestimmten geordneten Reihenfolge beschrieben wurden, solche Prozesse praktiziert werden könnten. mit den beschriebenen Schritten, die in einer anderen Reihenfolge als der hier beschriebenen Reihenfolge ausgeführt werden. Es sollte ferner verstanden werden, dass bestimmte Schritte gleichzeitig ausgeführt werden könnten, dass andere Schritte hinzugefügt werden könnten oder dass bestimmte hier beschriebene Schritte weggelassen werden könnten. Mit anderen Worten, die Beschreibungen der hierin enthaltenen Verfahren dienen der Veranschaulichung bestimmter Ausführungsformen und sind in keiner Weise so auszulegen, dass die Ansprüche begrenzt werden.
Daher ist davon auszugehen, dass die vorstehende Beschreibung anschaulich und nicht restriktiv sein soll. Viele Ausführungsformen und Anwendungen, die nicht die angeführten Beispiele sind, würden beim Lesen der obigen Beschreibung sichtbar sein. Der Anwendungsbereich sollte nicht unter Bezugnahme auf die vorstehende Beschreibung bestimmt werden, sondern unter Bezugnahme auf die beigefügten Ansprüche sowie den vollen Umfang der Äquivalente, auf die solche Ansprüche Anspruchsberechtigtsind sind. Es wird erwartet und beabsichtigt, dass zukünftige Entwicklungen in den hier in summierung summierenden Technologien stattfinden und dass die offenbarten Systeme und Methoden in solche zukünftigen Ausführungsformen einbezogen werden. Zusammenfassend ist zu verstehen, dass die Anmeldung änderungs- und variationsfähig ist.
Alle in den Ansprüchen verwendeten Begriffe sollen ihre gewöhnliche Bedeutung erhalten, wie sie in den hier beschriebenen Technologien verstanden werden, es sei denn, hierin wird ausdrücklich auf das Gegenteil hingewiesen. Insbesondere sollte die Verwendung der einzelnen Artikel wie „a“, „die“, „gesagt“ usw. gelesen werden, um eines oder mehrere der angegebenen Elemente zu rezitieren, es sei denn, ein Anspruch rezitiert eine ausdrückliche Einschränkung des Gegenteils.
Das Abstract wird bereitgestellt, damit der Leser die Art der technischen Offenbarung schnell feststellen kann. Sie wird mit der Maßgabe vorgelegt, dass sie nicht zur Auslegung oder Beschränkung des Umfangs oder der Bedeutung der Ansprüche verwendet wird. Darüber hinaus kann in der vorstehenden ausführlichen Beschreibung dargestellt werden, dass verschiedene Merkmale in verschiedenen Ausführungsformen zusammengefasst sind, um die Offenbarung zu straffen. Diese Offenbarungsmethode ist nicht dahin auszulegen, dass sie eine Absicht widerspiegelt, dass die beanspruchten Ausführungsformen mehr Merkmale erfordern, als in jedem Anspruch ausdrücklich vorgetragen werden. Vielmehr liegt der erfinderische Gegenstand, wie die folgenden Ansprüche widerspiegeln, in weniger als allen Merkmalen einer einzigen offenbarten Ausführungsform. So werden die folgenden Ansprüche in die ausführliche Beschreibung aufgenommen, wobei jeder Anspruch für sich genommen als gesondert beanspruchter Gegenstand gilt.

Claims

Ein Fahrzeugsystem bestehend aus: eine Taste, die programmiert ist, um ein Alarmsignal auszugeben; eine Kommunikationsschnittstelle, die für die drahtlose Übertragung einer Warnmeldung programmiert ist; und ein Prozessor, der so programmiert ist, dass er die Kommunikationsschnittstelle befehligt, um die Warnmeldung an einen Notfalldienstanbieter als Reaktion auf die Schaltfläche zu übermitteln, die das Warnsignal ausgibt, die Warnmeldung, die einen zukünftigen Fahrzeugstopp identifiziert, und eine Ankunftszeit in der Zukunft Fahrzeugstopp.
Das Fahrzeugsystem nach Anspruch 1, wobei die Taste das Warnsignal als Reaktion auf ein vorgegebenes Eingabemuster ausgibt.
Das Fahrzeugsystem nach Anspruch 2, wobei das vorgegebene Eingabemuster ein Doppelklick oder dreifaches Klicken auf die Schaltfläche beinhaltet.
Das Fahrzeugsystem nach Anspruch 1, das ferner ein Navigationssystem umfasst, das zur Bestimmung eines aktuellen Standorts programmiert ist, wobei der Prozessor so programmiert ist, dass er den zukünftigen Fahrzeugstopp und die Ankunftszeit am künftigen Fahrzeugstopp zumindest teilweise auf der Grundlage der aktuellen Standort.
Das Fahrzeugsystem nach Anspruch 1, das ferner einen Speicher enthält, in dem eine virtuelle Karte gespeichert ist, wobei der Prozessor so programmiert ist, dass er den zukünftigen Fahrzeugstopp aus der im Speicher gespeicherten virtuellen Karte identifiziert.
Das Fahrzeugsystem nach Anspruch 5, wobei der Prozessor so programmiert ist, dass er die Ankunftszeit am zukünftigen Fahrzeugstopp auf der Grundlage einer Entfernung zum zukünftigen Fahrzeugstopp und einer Fahrzeuggeschwindigkeit berechnet, wobei die Entfernung von der virtuellen Karte bestimmt wird.
Das Fahrzeugsystem nach Anspruch 1, das ferner einen Speicher enthält, in dem eine Tabelle gespeichert ist, wobei der Prozessor so programmiert ist, dass er den zukünftigen Fahrzeugstopp identifiziert und die Ankunftszeit am zukünftigen Fahrzeugstopp anhand der Daten in der Tabelle bestimmt.
Das Fahrzeugsystem nach Anspruch 1, wobei der Prozessor so programmiert ist, dass er die Ankunft am künftigen Fahrzeugstopp mit dem Notdienstanbieter koordiniert.
Das Fahrzeugsystem nach Anspruch 8, wobei die Kommunikationsschnittstelle so programmiert ist, dass sie drahtlos eine Notfallreaktion vom Notfalldienstanbieter erhält, die Notfallreaktion, die einen Zeitpunkt der Ankunft des Notfalldienstanbieters in der Zukunft angibt Fahrzeugstopp.
Das Fahrzeugsystem nach Anspruch 9, wobei der Prozessor so programmiert ist, dass er einen autonomen Modusregler verfügt, um die Fahrzeuggeschwindigkeit zu verlangsamen, so dass die Ankunftszeit am zukünftigen Fahrzeugstopp nach der Ankunftszeit des Notdienstanbieters am künftigen Fahrzeug liegt anhalten.
Eine Methode, die Folgendes umfasst: empfangen ein Warnsignal; Identifizierung eines zukünftigen Fahrzeugstopps; Festlegung eines Zeitpunkts der Ankunft eines Fahrzeugs an der zukünftigen Fahrzeughal te stelle; Erstellen einer Warnmeldung, die den zukünftigen Fahrzeugstopp und den Zeitpunkt der Ankunft des Fahrzeugs an der zukünftigen Fahrzeughaltestelle identifiziert; und Befehl über eine Kommunikationsschnittstelle, um die Warnmeldung drahtlos an einen Notfalldienstanbieter zu übermitteln.
Das Verfahren nach Anspruch 11, das ferner die Bestimmung eines aktuellen Standorts des Fahrzeugs umfasst, wobei die Identifizierung des zukünftigen Fahrzeugstopps und die Bestimmung der Ankunftszeit an der zukünftigen Fahrzeughaltestelle zumindest teilweise auf dem derzeitigen Standort des Fahrzeugs beruhen.
Die Methode des Anspruchs 11, bei der die Identifizierung des zukünftigen Fahrzeugstopps den Zugriff auf eine in einem Speicher gespeicherte virtuelle Karte und die Identifizierung des zukünftigen Fahrzeugstopps von der Karte umfasst.
Das Verfahren nach Anspruch 13, wobei die Bestimmung der Ankunftszeit am künftigen Fahrzeugstopp die Berechnung der Ankunftszeit an der zukünftigen Fahrzeughaltestelle auf der Grundlage einer Entfernung zum zukünftigen Fahrzeugstopp und einer Fahrzeuggeschwindigkeit umfasst, wobei die Entfernung von der virtuelle Karte.
Das Verfahren nach Anspruch 11, bei dem der künftige Fahrzeugstopp ermittelt und die Ankunftszeit am künftigen Fahrzeugstopp bestimmt wird, umfasst den Zugriff auf die in einer Tabelle gespeicherten Daten.
Die Methode des Anspruchs 11, die ferner die Koordinierung der Ankunft am künftigen Fahrzeugstopp mit dem Notdienstanbieter umfasst.
Die Methode des Anspruchs 16, bei der die Koordinierung der Ankunft am zukünftigen Fahrzeugstopp den Eingang eines Notfalleinsatzes durch den Notfalldienstanbieter umfasst, die Notfallreaktion, die einen Zeitpunkt der Ankunft des Notfalldienstanbieters in der Zukunft angibt Fahrzeugstopp.
Die Methode nach Anspruch 17, bei der die Koordinierung der Ankunft am zukünftigen Fahrzeugstopp die Steuerung eines autonomen Modusreglers umfasst, um die Geschwindigkeit des Fahrzeugs zu verlangsamen, so dass die Ankunftszeit am zukünftigen Fahrzeugstopp nach der Ankunftszeit des Rettungsdienstes liegt. Anbieter an der zukünftigen Fahrzeughaltestelle.