DE112015006884T5

DE112015006884T5 - Fahrzeugeigene haptische Ausgabe

Info

Publication number: DE112015006884T5
Application number: DE112015006884.8T
Authority: DE
Inventors: Omar Makke; Haysam M. KADRY
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2015-10-29
Filing date: 2015-10-29
Publication date: 2018-05-30
Also published as: CN108140294A; WO2017074381A1; GB2559082B; GB201808316D0; RU2703680C1; CN108140294B; US10752262B2; GB2559082A; US20180257669A1; MX2018004155A

Abstract

Ein Fahrzeugrechner ist mit einer tragbaren Rechenvorrichtung kommunizierend gekoppelt und ist programmiert, in einem Fahrzeugsensor ein Geräusch von außerhalb des Fahrzeugs zu detektieren und in der tragbaren Rechenvorrichtung eine haptische Ausgabe auszulösen, die zumindest zum Teil auf dem detektierten Geräusch beruht.

Description

HINTERGRUND
Fahrzeugeigene Meldungen, z.B. Warnungen, Hinweise etc. und fahrzeugexterne Meldungen, z.B. Sirenen, Hupen etc. sind häufig akustisch. Hörgeschädigte Fahrer von Fahrzeugen könnten auf die akustischen Meldungen langsam reagieren und nicht hörgeschädigte Fahrer könnten von der Hörschädigung von Fahrern nichts wissen.
Figurenliste

1 zeigt ein beispielhaftes Fahrzeugsystem zum Bereitstellen von haptischer Ausgabe in einer tragbaren Nutzervorrichtung.
2 ist ein Diagramm eines beispielhaften Prozesses zum Auslösen von haptischer Ausgabe in einer tragbaren Nutzervorrichtung in einem Fahrzeug.

EINGEHENDE BESCHREIBUNG
Einleitung
1 ist ein Blockdiagramm eines beispielhaften Fahrzeugsystems zum Betreiben eines Fahrzeugs. Das Fahrzeug 101 kann einen Rechner 105 umfassen, der eine Mensch-Maschine-Schnittstelle (HMI) 120, Sensoren 115 und/oder einen Kommunikationsbus 125, der z.B. mit verschiedenen Komponenten des Fahrzeugs 101, etwa elektronischen Steuergeräten (ECUs) für Lenkung, Bremsen, Antriebsstrang etc., kommuniziert, umfasst oder damit kommunizierend gekoppelt ist.
Der Rechner 105 kommuniziert mit anderen Fahrzeugen 102 mithilfe eines bekannten Kommunikationsprotokolls, z.B. Dedicated Short Range Communications (DSCR, dedizierte Nahbereichskommunikationen) etc. Der Rechner 105 kann ferner mittels des Fahrzeugkommunikationsbusses 125 Daten bezüglich des Betriebs des Fahrzeugs 101 empfangen und bereitstellen und kann darüber hinaus mittels eines Netzwerks 130 mit einem oder mehreren fernen Rechnern 140 kommunizieren. Eine tragbare Rechenvorrichtung 135 kann sich in dem Fahrzeug befinden, z.B. von einem Fahrzeuginsassen mitgeführt und/oder getragen werden, wobei die Vorrichtung 135 typischerweise mittels eines Protokolls, wie etwa Bluetooth oder WiFi, möglicherweise aber auch mittels des Netzwerks 130, das extern des Fahrzeugs 101 ist, mit dem Rechner 105 in Verbindung steht. Ferner kann der Rechner 105 z.B. mittels des Netzwerks 130 mit einem fernen Server 140 kommunizieren. Der Server 140 umfasst wiederum einen Datenspeicher 145 bzw. ist mit diesem kommunizierend gekoppelt.
Der Rechner 105 des Fahrzeugs 101 kann programmiert sein, um z.B. mittels der HMI 120 verschiedene Ausgaben, einschließlich akustischer Meldungen, die die Form von Geräuschen, z.B. Alarmglocken oder dergleichen, oder Sprachmeldungen annehmen können, bereitzustellen. Solche akustischen Ausgaben können durch verschiedene Bedingungen ausgelöst werden, die von dem Rechner 105 detektiert werden, z.B. Daten von dem Bus 125 und/oder Daten von einer bekannten globalen Positionierungssystem(GPS)-Einheit, die in dem Rechner 105 enthalten sein könnte, welche anzeigen könnten, dass sich ein Fahrzeug 101 bei über einem vorbestimmten Schwellenwert über einer ausgeschilderten Geschwindigkeitsbegrenzung fortbewegt, z.B. mehr als 16 Kilometer pro Stunde über der Geschwindigkeitsbegrenzung, woraufhin der Rechner 105 programmiert sein könnte, eine akustische Meldung zu liefern. Andere Meldungen könnten ohne Einschränkung Informationen bezüglich Motortemperatur, drohenden Kollisionen, eines Sitzgurt- oder anderen Sicherheitsvorrichtungsstatus etc. umfassen.
Akustische Meldungen stellen aber Hörgeschädigte vor Schwierigkeiten. Daher kann der Rechner 105 programmiert sein, der tragbaren Vorrichtung 135 eine Mitteilung zu senden, eine haptische Ausgabe zusätzlich zu oder anstelle einer akustischen Ausgabe auszulösen, die mittels der HMI 120 bereitgestellt werden könnte oder würde. Ferner könnte eine spezifische haptische Ausgabe, die bereitgestellt wird, gemäß einer spezifischen akustischen Ausgabe gewählt werden, z.B. könnten eine Länge, Anzahl und/oder Intensität von haptischen Vibrationen gemäß einer zugeordneten akustischen Ausgabe, z.B. einer Meldung eines sich nähernden Noteinsatzfahrzeugs, eines Befehls von der GPS-Einheit, einer Meldung über einen Fehler des Fahrzeugs 101, z.B. hohe Motortemperatur, niedriger Kraftfahrzeugstatus etc., verändert werden.
Beispielhaftes System
Der Rechner 105 des Fahrzeugs 101, der wie bekannt einen Prozessor und einen Speicher umfasst, kann z.B. mittels eines Kommunikationsbusses 125 oder anderer bekannter drahtgebundener oder drahtloser Verbindungen kommunizierend an ein oder mehrere elektronische Steuereinheiten, z.B. Steuergeräte oder dergleichen, die in dem Fahrzeug 101 zum Überwachen und/oder Steuern verschiedener Komponenten des Fahrzeugs 101 enthalten sind, z.B. eine Motorsteuereinheit (ECU), eine Getriebesteuereinheit (TCU) etc., angeschlossen sein, oder der Rechner 105 kann diese umfassen. Der Bus 125 kann ein CAN-Bus (Controller Area Network Bus) und/oder ein beliebiger anderer geeigneter fahrzeugeigener Kommunikationsbus, etwa JASPAR, LIN, SAE J1850, AUTOSAR, MOST etc. sein. Elektronische Steuereinheiten können, wie bekannt ist, mit z.B. dem CAN-Bus verbunden sein. Das Fahrzeug 101 kann auch ein oder mehrere elektronische Steuereinheiten speziell zum Empfangen und Senden von Diagnoseinformationen, etwa einen On-Board-Diagnose-Konnektor (OBD-II), umfassen. Mittels des CAN-Busses, OBD II und/oder anderen drahtgebundenen oder drahtlosen Mechanismen kann der Rechner 105 Mitteilungen zu verschiedenen Vorrichtungen in dem Fahrzeug 101 senden und/oder Mitteilungen von den verschiedenen Vorrichtungen, z.B. Steuergeräten, Aktoren etc., empfangen. Alternativ oder zusätzlich kann in Fällen, da der Rechner 105 tatsächlich mehrere Vorrichtungen umfasst, der CAN-Bus oder dergleichen für Kommunikationen zwischen Vorrichtungen genutzt werden, die in dieser Offenbarung als Rechner 105 dargestellt sind, z.B. verschiedene ECUs.
Der Rechner 105 kann mithilfe von mehreren Kommunikationsprotokollen Mitteilungen senden und/oder empfangen, z.B. kann der Rechner 105 einen oder mehrere Sender-Empfänger, wie sie für das Bereitstellen solcher Kommunikationen bekannt sind, umfassen und/oder damit kommunizierend gekoppelt sein. Beispielsweise kann der Rechner 105 mithilfe von Fahrzeug-zu-Fahrzeug-Protokollen wie etwa DSRC (Dedicated Short Range Communication), Funkmodem und Kurzstreckenfunkfrequenz Mitteilungen empfangen und/oder senden.
Der Rechner 105 kann weiterhin mit einem Netzwerk 130 kommunizieren, das sich außerhalb des Fahrzeugs 101 erstreckt, z.B. mit dem Server 140 kommuniziert. Das Netzwerk 130 kann verschiedene drahtgebundene und/oder drahtlose Netzwerktechnologien, z.B. Mobilfunk, Bluetooth, drahtgebundene und/oder drahtlose Pakete etc., umfassen. Das Netzwerk 130 kann eine beliebige geeignete Topologie aufweisen. Beispielhafte Kommunikationsnetzwerke umfassen drahtlose Kommunikationsnetzwerke (z.B. unter Verwenden von Bluetooth, IEEE 802.11 etc.), LAN (Local Area Networks) und/oder WAN (Wide Area Networks), einschließlich Internet, die Datenkommunikationsdienste bieten.
Das Fahrzeug 101 kann verschiedene Sensoren 115 umfassen. Die Sensoren 115 können an elektronische Steuereinheiten angebunden sein und wie vorstehend beschrieben innerhalb eines CAN-Bus-Protokolls oder eines beliebigen anderen geeigneten Protokolls arbeiten. Die Sensoren 115 können Daten sowohl senden als auch empfangen. Die Sensoren 115 können mit dem Rechner 105 oder einer anderen elektronischen Steuereinheit mittels z.B. des CAN-Bus-Protokolls kommunizieren, um Informationen zu verarbeiten, die von den Sensoren 115 gesendet oder von diesen empfangen werden. Die Sensoren 115 können mittels einer beliebigen geeigneten drahtlosen und/oder drahtgebundenen Methode mit dem Rechner 105 oder einer anderen elektronischen Steuereinheit kommunizieren. Die Sensoren 115 können eine beliebige Auswahl aus einer Kamera, einer RADAR-Einheit, einer LADAR-Einheit, einer Sonar-Einheit, einem Alkoholtestgerät, einem Bewegungsdetektor etc. umfassen. Zusätzlich können die Sensoren 115 einen globalen Positionierungssystem(GPS)-Empfänger umfassen, der mit einem globalen Positionierungssystemsatelliten kommunizieren kann, der mit dem Netzwerk verbunden ist etc. Mindestens einige der Sensoren 115 können Mikrofone oder dergleichen sein, um Geräusche zu erfassen, wodurch der Rechner 105 programmiert sein kann, Audioeigenschaften, z.B. Lautstärke, Ton, Rhythmus etc. zu messen, wofür Techniken bekannt sind, und die Messung dem Prozessor einer Prozesskomponente, z.B. dem Server 140, dem Rechner 105 etc., zu übermitteln, um eine entsprechende haptische Ausgabe zu erzeugen. Die Sensoren 115 können Geräusche über einen vorbestimmten Zeitraum überwachen, z.B. auf kontinuierlicher Basis, etwa jede Minute etc.
Das Fahrzeug 101 kann eine Mensch-Maschine-Schnittstelle (HMI) 120 umfassen. Die HMI 120 kann einem Fahrer des Fahrzeugs 101 das Interagieren mit dem Rechner 105, mit elektronischen Steuergeräten etc. ermöglichen. Die HMI 120 kann eine von verschiedenen Rechenvorrichtungen mit einem Prozessor sowie einem Speicher sowie Kommunikationsfähigkeiten umfassen. Die HMI 120 kann ein tragbarer Rechner, ein Tablett-Rechner, ein Mobiltelefon, z.B. ein Smartphone, etc. sein, der/das Funktionen für drahtlose Kommunikationen mithilfe von IEEE 802.11, Bluetooth und/oder Mobilfunkkommunikationsprotokollen etc. umfasst. Die HMI 120 kann weiterhin ein Sprachdialogsystem (IVR) und/oder eine grafische Benutzeroberfläche (GUI) mit z.B. einem Touchbildschirm oder dergleichen etc. umfassen. Die HMI 120 kann mit dem Netzwerk 130 kommunizieren, das sich außerhalb des Fahrzeugs 101 erstreckt, und kann z.B. mithilfe von Bluetooth etc. direkt mit dem Rechner 105 kommunizieren.
Der Rechner 105 kann programmiert sein, mit einer oder mehreren tragbaren Rechenvorrichtungen 135 zu kommunizieren, die in der Lage sind, eine haptische Ausgabe, z.B. Vibrationen, zu erzeugen. Die tragbare Vorrichtung 135 kann eine bekannte Vorrichtung sein, die von einem Fahrer getragen werden kann, z.B. eine Apple-Uhr, Microsoft Band etc., und kann an einem Handgelenk oder einem anderen Körperteil angebracht sein. Die tragbare Vorrichtung 135 kann alternativ oder zusätzlich von einem Insassen des Fahrzeugs 101 mitgeführt werden und kann allgemein eine beliebige von verschiedenen Rechenvorrichtungen mit einem Prozessor und einem Speicher sowie Kommunikationsfunktionen z.B. mithilfe von IEEE 802.11, mithilfe von Bluetooth, mithilfe von Mobilfunkkommunikationsprotokollen etc. umfassen. Die tragbare Vorrichtung 135 umfasst einen oder mehrere haptische Generatoren, wie sie bekannt sind, z.B. Aktoren, winzige Vibrationsmotoren etc., um die haptische Ausgabe zu erzeugen. Die tragbare Vorrichtung 135 kann direkt mit dem Rechner 105 des Fahrzeugs 101 kommunizieren, z.B. mithilfe von Bluetooth etc. Die tragbare Vorrichtung 135 kann auch durch optische, akustische oder sonstige Mechanismen mit dem Fahrer kommunizieren. Die tragbare Vorrichtung 135 kann eine visuelle Schnittstelle, z.B. einen Bildschirm, zum Anzeigen von GUIs (grafischen Benutzeroberflächen) umfassen.
Die tragbare Vorrichtung 135 ist programmiert, um gemäß Fahrereingabe ein oder mehrere Vorgänge zu aktivieren, z.B. haptische Reaktionen etc. Der Fahrer kann mittels einer oder mehrerer Anwendungen, z.B. einschließlich einer mobilen App etc, die auf mindestens einer von: tragbarer Vorrichtung 135, Rechner 105 und HMI 120 des Fahrzeugs 101 installiert sind, Daten in die tragbare Vorrichtung 135 eingeben.
Der Server 140 kann einen Datenspeicher 145 umfassen oder damit kommunizierend gekoppelt sein. Von der tragbaren Vorrichtung 135, dem Rechner 105 und/oder dem Server 140 empfangene Daten können für späteren Abruf in dem Datenspeicher 145 gespeichert werden.
Beispielhafter Prozess
2 ist ein Diagramm eines beispielhaften Prozesses 200, der in dem Rechner 105 zum Senden von haptischer Ausgabe implementiert werden kann.
Der Prozess 200 beginnt in einem Block 205, in dem die tragbare Vorrichtung 135 mit dem Rechner 105 des Fahrzeugs 101 verbunden ist. Die tragbare Vorrichtung 135 bindet an den Rechner 105 an und kann mit einem oder mehreren fahrzeugeigenen Systemen kommunizieren, z.B. einem fahrzeugeigenen Kommunikations- und Unterhaltungssystem etc.
Als Nächstes ermittelt der Rechner 105 in einem Block 210, ob ein Fahrer des Fahrzeugs 101 hörgeschädigt ist. Beispielsweise kann die tragbare Vorrichtung 135 ein oder mehrere Anwendungen (üblicherweise als „Apps“ bezeichnet) laufen lassen und/oder ein Fahrer kann eine solche Anwendung instantiieren, z.B. durch Wahl eines Symbols auf einem Touchbildschirm, die mit dem Rechner 105 des Fahrzeugs 101 kommunizieren, z.B. auf einer vorbestimmten Liste von Apps stehen, die in die Rechner 105 programmiert sind, woraufhin der Rechner 105 eine App zur Verwendung beim Kommunizieren mit einer hörgeschädigten Person ermitteln kann. Alternativ oder zusätzlich könnte ein Identifikator für die tragbare Rechenvorrichtung 135, der für den Rechner 105 bereitgestellt wird, genutzt werden, um eine der Vorrichtung 135 zugeordnete Person als hörgeschädigt zu ermitteln. Wird ein hörgeschädigter Fahrer detektiert oder ermittelt, rückt der Prozess 200 zu einem Block 215 vor. Ansonsten rückt der Prozess 200 zu einem Block 240 vor.
In dem Block 215 sendet der Server 140 und/oder die tragbare Vorrichtung 135 z. B. mittels des Kommunikationsbusses 125 zu dem Rechner 105 des Fahrzeugs 101 Einstellungsdaten, die die Geräusche und/oder Vorgänge beruhend auf empfangenen Daten identifizieren, welche zum Aktivieren der haptischen Ausgabe dienen. Beispielsweise könnten Ereignisse mit verschiedenen Betriebsdaten des Fahrzeugs 101, die von dem Bus 125 verfügbar sind, in Verbindung stehen, z.B. Geschwindigkeit des Fahrzeugs 101, Lenkwinkel, Navigationsinformationen, Motordrehmomentforderung etc. Die Einstellungen für haptische Ausgabe in der Vorrichtung 135 können vorbestimmt sein, z.B. in den Rechner 105 vorprogrammiert sein, und/oder ein Fahrer kann die Einstellungen durch Eingabe zur Vorrichtung 135 und/oder mittels der HMI 120 des Fahrzeugs konfigurieren (oder Standardeinstellungen außer Kraft setzen). Die Einstellungen können in dem Datenspeicher 145 und/oder dem Speicher des Rechners 105 gespeichert werden. In jedem Fall legen die Einstellungen der Vorrichtung 135 ein oder mehrere haptische Ausgaben fest, die einem oder mehreren detektierten Geräuschen und/oder einer oder mehreren mittels des Busses 125 empfangenen Daten entsprechen.
Beispielsweise kann eine bestimmte haptische Ausgabe oder eine Reihe solcher Ausgaben, z.B. eine Vibration bei einer festgelegten Intensität über einen festgelegten Zeitraum, einem einzelnen detektierten Geräusch oder alternativ dem einzelnen Geräusch und einer oder mehreren Daten von dem Fahrzeugkommunikationsbus 125 entsprechen, z.B. der Geschwindigkeit des Fahrzeugs 101 und/oder einer Geschwindigkeit des Fahrzeugs 102 (z.B. eines Noteinsatzfahrzeugs), das das Geräusch erzeugt, einer Herkunftsrichtung (z.B. hinter dem Fahrzeug 101 oder sich diesem nähernd) des Geräusches, einer Art von Fahrzeug 102, das das Geräusch erzeugt (z.B. als Noteinsatzfahrzeug detektiert oder mittels des Servers 140 und/oder DSRC als solches angegeben) etc.
Ferner können ein detektiertes Geräusch und/oder Vorgang/Vorgänge beruhend auf Daten 125 mehreren haptischen Ausgaben, d.h. wie vorstehend erwähnt einer Reihe von haptischen Ausgaben, entsprechen, d.h. diesen zugeordnet werden. Beispielsweise kann ein bestimmter Vorgang, z.B. eine drohende Kollision, einer einzigen haptischen Ausgabe mit maximaler Intensität über einen Zeitraum, z.B. drei Sekunden, zugeordnet werden, wogegen das Detektieren einer sich nähernden Sirene einer Reihe von drei Ausgaben von jeweils einer Sekunde bei einer mittleren Intensität zugeordnet werden kann. Das Detektieren einer Sirene gekoppelt mit dem Überschreiten einer ausgeschilderten Geschwindigkeitsbegrenzung durch das Fahrzeug könnte ferner beispielsweise einer Reihe von drei Ausgaben von jeweils einer Sekunde bei einer hohen Intensität zugeordnet werden.
Als Reaktion darauf, dass Sensoren 115 des Fahrzeugs 101 ferner beispielsweise ein oder mehrere Huptöne des Fahrzeugs 102 detektieren, kann der Rechner 105 eine haptische Ausgabe auslösen, wenn die Fahrzeuge 101, 102 bei hohen Geschwindigkeiten unterwegs sind, z.B. auf einer Fernverkehrsstraße, könnte die haptische Ausgabe aber nicht auslösen, wenn die Fahrzeuge 101, 102 bei Fortbewegung bei langsamen Geschwindigkeiten nahe zueinander sind, z.B. während eines Verkehrsstaus. Weiterhin kann der Rechner 105 des Fahrzeugs 101 beispielsweise die haptische Ausgabe entsprechend dem detektierten Geräusch einer Krankenwagensirene auslösen, wenn sich der Krankenwagen bei hohen Geschwindigkeiten bei einer Entfernung von dem Fahrzeug 101 bewegt, könnte die haptische Ausgabe aber nicht auslösen, wenn sich der Krankenwagen bei gleicher Entfernung von dem Fahrzeug 101 bei niedrigen Geschwindigkeiten fortbewegt. Als weiteres Beispiel kann der Rechner 105 des Fahrzeugs 101 beruhend zumindest zum Teil auf einer geplanten Route des Fahrzeugs 101, die zumindest zum Teil von dem Rechner 105 des Fahrzeugs 101 ermittelt wird, ermitteln, ob die haptische Ausgabe auszulösen ist.
Als Nächstes sendet der Rechner 105 und/oder die tragbare Vorrichtung 135 in einem Block 220 eine erste Mitteilung zu dem fernen Server 140, dass das Fahrzeug 101 einen hörgeschädigten Fahrer hat. Der ferne Server 140 kann die erste Mitteilung zu den Fahrzeugen 102 in der Nähe senden. Das Fahrzeug 101 kann die Mitteilung durch das Fahrzeug-zu-Fahrzeug-Kommunikationsprotokoll zu den Fahrzeugen 102 in der Nähe senden. Das Senden kann die Fahrzeuge 102 in der Nähe anweisen, in bestimmter Weise zu agieren, z.B. Einhalten eines Sicherheitsabstands von dem Fahrzeug 101, Verwenden von nicht akustischen Meldungen, z.B. Leuchten etc. Ferner können die Fahrzeuge 102 dann dem Fahrzeug 101 anstelle von und/oder zusätzlich zu Geräuschkommunikationen, z.B. Sirenen, DSRC-Kommunikationen liefern.
Als Nächstes detektieren in einem Block 225 Sensoren 115 des Fahrzeugs 101 Geräusche und/oder Vorgänge. Detektierte Geräusche können für jeden Zweck entweder von innerhalb oder außerhalb des Fahrzeugs stammen und können z.B. Sirenen, akustische Meldungen der HMI 120, z.B. in Verbindung mit Sitzgurten, Navigationssystemen etc., umfassen, und es können auch Vorgänge detektiert werden, z.B. wie vorstehend erläutert beruhend auf Daten von dem Kommunikationsbus 125. Beispielsweise können Krankenwagensirenen und Richtungsangaben, z.B. in 1,6 Kilometer links abbiegen etc., von dem Navigationssystem durch haptische Ausgabe von der tragbaren Vorrichtung 125 an den Fahrer weitergeleitet werden.
Die tragbare Vorrichtung 135 kann die Geräusche durch geeignete Hörvorrichtungen, z.B. Mikrofone etc., detektieren und die Geräusche in haptische Ausgabe transformieren. Zusätzlich oder alternativ kann die tragbare Vorrichtung 135 eine Mitteilung von dem Rechner 105 erhalten, die die tragbare Vorrichtung 135 anweist, die haptische Ausgabe auszulösen. Beispielsweise kann die HMI 120 des Fahrzeugs 101 der tragbaren Vorrichtung 135 mitteilen, die haptische Ausgabe, die einer offenen Tür des Fahrzeugs 101 entspricht, auszulösen, statt dass die tragbare Vorrichtung 135 mittels Hörvorrichtungen die akustische Meldung detektiert, die der offenen Tür entspricht, z.B. Piepsen etc., und die akustische Meldung in haptische Ausgaben umwandelt.
Zusätzlich oder alternativ kann der Rechner 105 des Fahrzeugs 101 situationsbezogene Mitteilungen über die Fahrzeug-zu-Fahrzeug-Kommunikationsprotokolle und/oder Fahrzeug-zu-Infrastruktur-Protokolle empfangen, d.h. Mitteilungen bezüglich der Herkunft des Geräusches, z.B. von Fahrzeugen 102 in der Nähe und/oder einem in der Nähe kommunizierend gekoppelten Rechner. Beispielsweise können situationsbezogene Mitteilungen die Geschwindigkeit oder Herkunftsrichtung, die von Sensoren 115, z.B. mithilfe von Dopplereffektgrundsätzen etc. gemessen werden, die Identität des Ursprungs, z.B. Noteinsatzfahrzeug etc., umfassen.
Als Nächstes ermittelt der Rechner 105 des Fahrzeugs 101 in einem Block 230, ob ein detektiertes Geräusch und/oder Vorgangsdaten einer haptischen Ausgabe zugeordnet sind. Der Rechner 105 kann detektierte Geräusche mit gespeicherten Geräuschen, die der haptischen Ausgabe entsprechen, mithilfe von bekannten Audio-Interpretations- und Identifizierungstechniken, z.B. Vergleichen von Wellenformen etc., vergleichen. Wird ein detektiertes Geräusch als Übereinstimmung, d.h. innerhalb einer vorbestimmten Varianz, des gespeicherten Geräusches, das haptischer Ausgabe zugeordnet ist, ermittelt und/oder werden Vorgangsdaten detektiert, die einer haptischen Ausgabe zugeordnet sind, rückt der Prozess 200 zu einem Block 235 vor. Ansonsten rückt der Prozess 200 zu dem Block 240 vor.
In Block 235 betätigt die Vorrichtung 135 die in dem Block 230 identifizierte haptische Ausgabe, z.B. bei Erhalt eines Befehls von dem Rechner 105.
Nach einem der Blöcke 210, 230 oder 235 ermittelt der Rechner 105 des Fahrzeugs 101 in dem Block 240, ob der Prozess 200 fortfahren sollte. Beispielsweise kann der Prozess 200 enden, wenn das Fahrzeug 101 den Prozess 200 abschaltet, wenn das Fahrzeug abgeschaltet wird etc. Wenn der Prozess 200 nicht fortgesetzt werden sollte, endet der Prozess 200 in jedem Fall nach dem Block 240. Ansonsten kehrt der Prozess 200 zu Block 205 zurück.
SCHLUSSFOLGERUNG
Rechenvorrichtungen, wie sie hierin diskutiert werden, umfassen im Allgemeinen jeweils Befehle, die von einer oder mehreren Rechenvorrichtungen wie etwa den vorstehend genannten ausführbar sind und zum Ausführen von vorstehend beschriebenen Blöcken oder Schritten von Prozessen dienen. Von einem Rechner ausführbare Befehle können von Computerprogrammen, die mithilfe verschiedener Programmiersprachen und/oder Technologien erzeugt werden, einschließlich, aber nicht ausschließlich und entweder allein oder kombiniert Java™, C, C++, Visual Basic, Java Script, Perl, HTML, etc., kompiliert oder interpretiert werden. Im Allgemeinen empfängt ein Prozessor (z.B. ein Mikroprozessor) Befehle von z.B. einem Speicher, einem von einem Rechner lesbaren Medium etc. und führt diese Befehle aus, wodurch ein oder mehrere Prozesse, einschließlich ein oder mehrere der hierin beschriebenen Prozesse, durchgeführt werden. Solche Befehle und andere Daten können mithilfe verschiedenster von einem Rechner lesbarer Medien gespeichert und gesendet werden. Eine Datei in einer Rechenvorrichtung ist allgemein eine Sammlung von Daten, die auf einem Rechner lesbaren Medium gespeichert werden, etwa einem Speichermedium, einem Arbeitsspeicher, etc.
Ein von einem Rechner lesbares Medium umfasst ein beliebiges Medium, das am Bereitstellen von Daten (z.B. Befehlen) mitwirkt, die von einem Rechner gelesen werden können. Ein solches Medium kann viele Formen annehmen, einschließlich aber nicht ausschließlich nicht flüchtige Medien, flüchtige Medien, etc. Nicht flüchtige Medien umfassen beispielsweise Bild- oder Magnetplatten und andere dauerhafte Speicher. Flüchtige Medien umfassen dynamischen Arbeitsspeicher (DRAM), der typischerweise einen Hauptspeicher bildet. Übliche Formen von von einem Rechner lesbaren Medien umfassen beispielsweise eine Floppydisk, eine flexible Disk, eine Festplatte, ein Magnetband, ein beliebiges anderes magnetisches Medium, eine CD-ROM, eine DVD, ein beliebiges anderes optisches Medium, Lochkarten, Lochstreifen, ein beliebiges anderes physisches Medium mit Lochmustern, einen RAM, einen PROM, einen EPROM, einen FLASH EEPROM, einen beliebigen anderen Speicherchip oder Speicherkassette oder ein beliebiges anderes Medium, das von einem Rechner gelesen werden kann.
Bezüglich der Medien, Prozesse, Systeme, Verfahren etc., die hierin beschrieben sind, versteht sich, dass die Schritte solcher Prozesse etc. zwar gemäß einer bestimmten geordneten Reihenfolge auftretend beschrieben wurden, solche Prozesse aber unter Ausführen der beschriebenen Schritte in einer anderen Reihenfolge als hierin beschrieben umgesetzt werden könnten. Ferner versteht sich, dass bestimmte Schritte gleichzeitig durchgeführt werden könnten, dass andere Schritte hinzugefügt werden könnten oder dass bestimmte hierin beschriebene Schritte übergangen werden könnten. Die Beschreibungen von Systemen und/oder Prozessen werden hierin mit anderen Worten zwecks Veranschaulichung bestimmter Ausführungsformen vorgesehen und sollten in keiner Weise als Einschränkung des offenbarten Gegenstands ausgelegt werden.
Demgemäß versteht sich, dass die vorstehende Beschreibung veranschaulichend und nicht einschränkend sein soll. Für den Fachmann wären bei Lesen der vorstehenden Beschreibung viele andere Ausführungsformen und Anwendungen als die vorgesehenen Beispiele naheliegend. Der Schutzumfang der Erfindung sollte nicht unter Heranziehen der vorstehenden Beschreibung ermittelt werden, sondern sollte stattdessen unter Heranziehen der Ansprüche, die hier beigefügt sind und/oder in einer darauf beruhenden nicht vorläufigen Patentanmeldung enthalten sind, zusammen mit dem vollständigen Schutzumfang von Äquivalenten, den solche Ansprüche beanspruchen, ermittelt werden. Es wird erwartet und es ist beabsichtigt, dass es in dem hier diskutierten Gebiet zu künftigen Entwicklungen kommt und dass die offenbarten Systeme und Verfahren in solche künftigen Ausführungsformen integriert werden. Zusammenfassend versteht sich, dass der offenbarte Gegenstand Abwandlung und Änderung unterliegen kann.

Claims

Verfahren, umfassend: Detektieren mindestens eines von: einem Geräusch außerhalb eines Fahrzeugs und einem Vorgang, der von einem Kommunikationsbus in dem Fahrzeug angezeigt wird; Ermitteln, dass mindestens eines von Geräusch und Vorgang einer haptischen Ausgabe zugeordnet ist; und Anweisen einer tragbaren Rechenvorrichtung, die haptische Ausgabe auszulösen.
Verfahren nach Anspruch 1, welches weiterhin das Empfangen von Fahrereingabe umfasst, die das Geräusch der haptischen Ausgabe zuordnet.
Verfahren nach Anspruch 1, welches weiterhin beruhend auf einem zweiten detektierten Geräusch das Auslösen einer zweiten haptischen Ausgabe umfasst.
Verfahren nach Anspruch 1, welches weiterhin vor dem Detektieren des Geräusches und vor dem Auslösen der haptischen Ausgabe das Ermitteln umfasst, dass ein der tragbaren Rechenvorrichtung zugeordneter Fahrer des Fahrzeugs hörgeschädigt ist.
Verfahren nach Anspruch 4, wobei das Ermitteln, dass der Fahrer des Fahrzeugs hörgeschädigt ist, durch Erkennen, dass eine auf der tragbaren Vorrichtung laufende Anwendung für einen hörgeschädigten Nutzer vorgesehen ist, vorgenommen wird.
Verfahren nach Anspruch 1, wobei der Vorgang eine Geschwindigkeit des Fahrzeugs oder eine drohende Kollision des Fahrzeugs ist.
Verfahren nach Anspruch 1, wobei der Vorgang eine Dedicated Short Range Communication von einem zweiten Fahrzeug ist.
Verfahren nach Anspruch 1, wobei das Geräusch eine Sirene ist.
Verfahren nach Anspruch 1, wobei die haptische Ausgabe mehrere haptische Ausgaben einer festgelegten Dauer und bei einer festgelegten Intensität umfasst.
System, welches einen Rechner umfasst, der einen Prozessor und einen Speicher enthält, wobei der Speicher von dem Prozessor ausführbare Befehle speichert, so dass der Rechner programmiert ist, um: mindestens eines von: einem Geräusch außerhalb eines Fahrzeugs und einem Vorgang, der von einem Kommunikationsbus in dem Fahrzeug angezeigt wird, zu detektieren; zu ermitteln, dass mindestens eines von Geräusch und Vorgang einer haptischen Ausgabe zugeordnet ist; und eine tragbare Rechenvorrichtung anzuweisen, die haptische Ausgabe auszulösen.
System nach Anspruch 10, wobei der Rechner weiterhin programmiert ist, Fahrereingabe zu empfangen, die das Geräusch der haptischen Ausgabe zuordnet.
System nach Anspruch 10, wobei der Rechner weiterhin programmiert ist, eine zweite haptische Ausgabe beruhend auf einem zweiten detektierten Geräusch auszulösen.
System nach Anspruch 10, wobei der Rechner weiterhin programmiert ist, vor dem Detektieren des Geräusches und vor dem Auslösen der haptischen Ausgabe zu ermitteln, dass ein der tragbaren Rechenvorrichtung zugeordneter Fahrer des Fahrzeugs hörgeschädigt ist.
System nach Anspruch 13, wobei das Ermitteln, dass der Fahrer des Fahrzeugs hörgeschädigt ist, durch Erkennen, dass eine auf der tragbaren Vorrichtung laufende Anwendung für einen hörgeschädigten Nutzer vorgesehen ist, vorgenommen wird.
System nach Anspruch 10, wobei der Vorgang eine Geschwindigkeit des Fahrzeugs oder eine drohende Kollision des Fahrzeugs ist.
System nach Anspruch 10, wobei der Vorgang eine Dedicated Short Range Communication von einem zweiten Fahrzeug ist.
System nach Anspruch 10, wobei das Geräusch eine Sirene ist.
System nach Anspruch 10, wobei die haptische Ausgabe mehrere haptische Ausgaben einer festgelegten Dauer und bei einer festgelegten Intensität umfasst.