DE112015003379T5

DE112015003379T5 - Systeme und Verfahren für eine adaptive Schnittstelle, um Anwendererfahrungen in einem Fahrzeug zu verbessern

Info

Publication number: DE112015003379T5
Application number: DE112015003379.3T
Authority: DE
Inventors: Asaf Degani; Deutsch Omer; Claudia V. Goldman-Shenhar
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2014-07-22
Filing date: 2015-07-22
Publication date: 2017-04-27
Also published as: WO2016014640A3; WO2016014640A2; CN106716341A; US10106173B2; US20170174230A1

Abstract

Die vorliegende Offenbarung betrifft eine computerlesbare Vorrichtung, die veranlasst, dass ein Prozessor Operationen zur Interpretation einer Anwenderanforderung in ein Fahrzeugsystem ausführt, etwa von taktilen Eingaben, Gesten und Sprache. Die Operationen umfassen, dass ein Eingabedatenpaket empfangen wird, das Anwenderkommunikationen umfasst. Die Operationen ermitteln dann unter Verwendung einer Mensch-Maschine-Schnittstelle, ob das Eingabedatenpaket eine implizite Anwenderanforderung oder eine explizite Anwenderanforderung enthält. Auch ordnen die Operationen eine Abstraktionsebene zu dem Steuerungssprachen-Datensatz zu. Außerdem werden Verfahren zum Empfangen, Interpretieren und Speichern einer Anwenderanforderung auf einer oder mehreren Abstraktionsebenen offenbart.

Description

BEANSPRUCHUNG VON PRIORITÄTEN
Diese Anmeldung beansprucht die Priorität der US-Patentanmeldungen mit den Nummern 62/027,654 und 62/030,853, die am 22. Juli 2014 bzw. am 30. Juli 2014 eingereicht wurden.
TECHNISCHES GEBIET
Die vorliegende Offenbarung betrifft allgemein Systeme und Verfahren für eine adaptive Mensch-Maschine-Schnittstelle (HMI) zur Verbesserung von Anwendererfahrungen. Insbesondere betrifft die vorliegende Offenbarung eine HMI, die ausgestaltet ist, um Systeme innerhalb eines Fahrzeugs umzugestalten.
HINTERGRUND
Erfahrungen eines Fahrers in einem Fahrzeug, welche eine Kommunikation zwischen dem Fahrzeug und dem Fahrer umfassen, beeinflussen, wie gut der Fahrer das Fahrzeug bedient. Systeme und Teilsysteme eines Fahrzeugs sind oftmals derart programmiert, dass ein Fahrer die Systeme durch die Verwendung von Anwendungen bedienen kann, welche von Herstellern vorab in einen bordeigenen Computer integriert sein können oder durch eine Mensch-Maschine-Schnittstelle (HMI) heruntergeladen werden können.
In vielen Fahrzeugen sind HMI-Systeme so konzipiert, dass sie eine Anwenderinteraktion an einer Mittelkonsole eines Fahrzeugs unterstützen, bei der Bedienelemente eine Vielfalt von Eingabekomponenten umfassen, welche Hardware-Druckknöpfe und -Drehknöpfe und/oder Softwareknöpfe auf einem berührungsempfindlichen Bildschirm umfassen. Die für HMI-Interaktionen vorgesehenen Bedienelemente stellen für den Fahrer einen Weg zur Übermittlung eines Wunsches nach einer Veränderung bei den Fahrzeugbedingungen an das HMI-System bereit – z.B. eine Änderung der Klimaanlage oder des Radiosenders.
Jedoch enthalten aktuelle HMI-Systeme eine vorab entworfene Programmierung, die über einen großen Bereich von Fahrzeugen hinweg im Allgemeinen universell ist. Diese universell entworfenen HMI-Systeme antizipieren oftmals nicht auf logische Weise die Art des Denkens und Agierens des Fahrers. Als Folge fassen diese konventionellen Systeme eine Anwendereingabe anders auf als sie vom Anwender beabsichtigt ist. Diese Abweichung führt zu einer Frustration des Anwenders und zu einer ineffizienten und anderweitig ineffektiven Verwendung der Systeme.
ZUSAMMENFASSUNG
In der Industrie besteht ein Bedarf zur Verbesserung der Erfahrungen des Fahrers in einem Fahrzeug, in dem es ermöglicht wird, dass ein Anwender mit dem Fahrzeug über eine neuartige HMI auf eine Weise interagiert, die für einen Menschen natürlich ist.
Die vorliegende Technologie betrifft Systeme und Verfahren zum Verbessern der Erfahrungen eines Fahrers mit Hilfe eines auf einer adaptiven Schnittstelle beruhenden HMI-Systems. Die vorliegende Technologie spricht den Bedarf in der Industrie zur Verbesserung der Erfahrungen eines Fahrers in einem Fahrzeug dadurch an, dass sie die tatsächlichen Wünsche und Absichten des Fahrers (z.B. eine implizite Antwort oder Aussage) versteht, einschließlich dessen, wenn diese von einer tatsächlichen Antwort oder Aussage – z.B. einer expliziten Antwort oder Aussage – abweichen. Darüber hinaus ermöglicht die vorliegende Technologie eine Neuanordnung der Systemparameter in Übereinstimmung mit menschlichen Bedürfnissen und Auffassungen.
Ein Typ eines HMI-Systems mit einer adaptiven Schnittstelle (AI, AI von adaptive interface) berechnet sein Verhalten auf der Grundlage der unterlagerten (impliziten) Anwenderanforderungen. Implizite Anwendereingaben müssen möglicherweise interpretiert und in eine spezielle Aufgabe übersetzt werden, die von einem oder mehreren Fahrzeugsystemen ausgeführt werden muss, um die Kernaussage der Anwendereingabe zu erfüllen. Im Gegensatz dazu antworten herkömmliche HMI-Systeme nur auf explizite Anwendereingaben. Explizite Anwendereingaben sind in den herkömmlichen HMI-Systemen speziellen Aufgaben zugeordnet, die nicht interpretiert werden müssen, um von anderen Fahrzeugsystemen ausgeführt werden zu können.
In einem Aspekt enthält die Technologie ein System, das eine graphische Anzeige/Steuerungs-Sprache umfasst, welche Bausteine (Inhalt und Format) bereitstellt, die geeignet sind, implizite Anwenderanforderungen auf beliebigen von zahlreichen Abstraktionsebenen zu beschaffen und zu interpretieren. Die graphische Sprache erzeugt adaptive Anwenderschnittstellen, welche die Anwenderanforderung auf unterschiedlichen Abstraktionsebenen ermöglichen.
Die Technologie umfasst außerdem ein Rechenverfahren zur Veränderung von Anwenderschnittstellen auf der Grundlage von (1) Anwenderbedürfnissen (z.B. ein Bedürfnis zum Modifizieren der Innentemperatur des Fahrzeugs) und/oder (2) Verhaltensweisen von Maschinen (z.B. Ausfälle, Betriebsgrenzen und Umkonfigurationen) und/oder (3) Änderungen und Aufforderungen der Umwelt (z.B. ein Bedarf zum Einschalten von Scheibenwischern, wenn es zu regnen anfängt). Das Verfahren unterstützt eine Interaktion zwischen dem Anwender und dem System, indem es die Bedürfnisse des Anwenders in Eingabewerte für das System übersetzt. Außerdem unterstützt das Verfahren eine Funktionalität zum entweder statischen oder dynamischen Wählen einer Anwenderschnittstelle.
BESCHREIBUNG DER ZEICHNUNGEN
1 veranschaulicht auf schematische Weise ein funktionales System in Übereinstimmung mit einer beispielhaften Ausführungsform.
2 ist ein Bockdiagramm eines Controllers des funktionalen Systems in 1.
3 ist ein Flussdiagramm, das Verfahren zum Ausführen einer Ausgabebefehlssequenz in Übereinstimmung mit einer beispielhaften Ausführungsform darstellt.
4 veranschaulicht eine beispielhafte Ausführungsform von Abstraktionsebenen innerhalb des funktionalen Systems von 1 hinsichtlich eines Heizungs-, Lüftungs- und Klimaanlagen-Systems (HVAC-Systems).
5 veranschaulicht ein beispielhaftes Bedientableau für eine menschliche Schnittstelle zu dem HVAC-System von 4.
Die Figuren sind nicht unbedingt maßstabsgetreu und einige Merkmale können hervorgehoben oder minimiert sein, um Details von speziellen Komponenten zu zeigen. In einigen Fällen wurden gut bekannte Komponenten, Systeme, Materialien oder Verfahren nicht im Detail beschrieben, um ein Verschleiern der vorliegenden Offenbarung zu vermeiden. Daher dürfen spezielle strukturelle und funktionale Details, die hier offenbart sind, nicht als Einschränkung interpretiert werden, sondern nur als eine Basis für die Ansprüche und als eine repräsentative Basis zur Unterrichtung des Fachmanns darüber, wie die vorliegende Offenbarung auf verschiedene Weise eingesetzt werden kann.
GENAUE BESCHREIBUNG
Wie es gefordert ist, werden hier detaillierte Ausführungsformen der vorliegenden Offenbarung offenbart. Die offenbarten Ausführungsformen sind nur Beispiele, die in verschiedenen und alternativen Formen und Kombinationen daraus ausgeführt werden können. Die Begriffe zum Beispiel, beispielhaft und ähnliche Begriffe bezeichnen, so wie sie hier verwendet werden, umfassend Ausführungsformen, die als Veranschaulichung, Beispiel, Modell oder Muster dienen.
Der Begriff "Fahrzeug" ist, so wie er hier verwendet wird, nicht auf Kraftfahrzeuge begrenzt. Zwar wird die vorliegende Technologie hier primär in Verbindung mit Kraftfahrzeugen beschrieben, jedoch ist die Technologie nicht auf Kraftfahrzeuge beschränkt. Die Konzepte können in einer großen Vielfalt von Anwendungen verwendet werden, etwa in Verbindung mit Flugzeugen, Wasserfahrzeugen, anderen Fahrzeugen, Gebäuden (z.B. Eigenheimen, Appartements, Hotelzimmern) und Verbraucherelektronikkomponenten.
I. Überblick über die Offenbarung – Fig. 1 und Fig. 2
Mit Bezug auf die Figuren und insbesondere auf die erste Figur veranschaulicht 1 ein funktionales System 130, das eine adaptive Mensch-Maschine-Schnittstelle (AHMI) 140 und einen Controller 200 enthält.
Das funktionale System 130 ist ausgestaltet, um von einem Anwender Eingaben zu empfangen, die in Funktionen übersetzt werden, um Operationen eines oder mehrerer Fahrzeugsysteme, die gerade überwacht werden, zu beeinflussen. In verschiedenen Ausführungsformen umfassen die Eingaben Verhaltenseingaben, etwa Anwendergesten, Berührungen, Redebeiträge oder andere Dramatisierungen oder Kommunikationen (z.B. Seufzen). Die Fahrzeugsysteme umfassen beliebige einer großen Vielfalt von Systemen, etwa ein Heizungssystem, ein Klimaanlagensystem, ein Bremssystem, ein Beschleunigungssystem, ein Unterhaltungs- oder Infotainmentsystem (z.B. ein Radio und/oder ein Videoabspielsystem), ein Navigationssystem, ein Spiegelsystem (z.B. Spiegelverstellsysteme), ein Sitzsystem (z.B. Sitzverstellsysteme), ein Fenstersteuerungssystem, ein Türsystem (z.B. Türverriegelungs-Steuerungssysteme), ein Kollisionsvermeidungssystem, eine Antriebsschlupfregelung, ein Hupensystem, ein Scheibenwischersystem, ein Gurt- und/oder Schlauchsystem, ein Emissionssystem, eine Kraftmaschine, ein Kraftmaschinenkühlsystem, ein Abgassystem, ein Beleuchtungssystem, ein Wischersystem, ein Fahrzeugstartsystem, ein Ladesystem, ein Batteriesystem, ein Lenkungssystem, ein Federungssystem, ein Getriebesystem, ein Schaltsystem, ein HVAC-System, ein Kamerasystem, Kommunikationsvorrichtungen (z.B. OnStar-Vorrichtungen und andere fest verdrahtete oder drahtlose Kommunikationsvorrichtungen), Systeme zur Verbindung mit Zubehörvorrichtungen (z.B. Bluetooth-Vorrichtungen, Mobiltelefonen), ein Gerätegruppensystem, ein Mittelkonsolensystem, ein Heads-Up-Displaysystem (HUD-System), ein Sprachsystem, ein Gestensystem, ein Soundsystem oder andere Systeme eines Fahrzeugs.
Ein Fahrerzustand oder ein Beifahrerzustand, zusammengefasst ein Anwenderzustand, ist ein direkt gemessener Parameter, der aus einem gemessenen Parameter identifiziert wird (z.B. Informationen, die von Fahrzeugsensoren wahrgenommen und übermittelt werden). Der Anwenderzustand wird als Anwendereingaben 110 in das funktionale System 130 eingegeben. Die Anwendereingaben 110 können außerdem eine direkte Anwenderinteraktion mit Systemen des Fahrzeugs enthalten (z.B. Einstellen des Radios auf einen gewünschten Sender, Einstellen der Temperatureinstellungen innerhalb des Fahrzeugs).
Die Anwendereingaben 110 können außerdem Daten enthalten, die von einem Zustand (z.B. einem kognitiven Zustand), den der Fahrer des Fahrzeugs zeigt, gesammelt werden, welcher als Fahrer- oder Anwenderzustand bezeichnet wird. Der Anwenderzustand wird auf der Grundlage des Verhaltens des Fahrers (z.B. Unmut über ein spezielles System oder Ablenkung von der Straße), seiner Physiologie (z.B. kognitive Überforderung, Ermüdung) und dergleichen ermittelt, welche das System durch Analyse von Messwerten von Parametern erkennen kann, etwa die Pulsfrequenz, die Fahrzeit, das Lenkverhalten, die galvanische Reaktion der Haut, eine Elektroenzephalographie (EEG), das Fahrverhalten, die Detektion von Redebeiträgen, Kombinationen daraus und dergleichen.
Die Anwendereingabe, welche spezielle Eingaben in eine Mittelkonsole des Fahrzeugs umfasst, die von dem Anwender vorgenommen werden, 110 kann innerhalb des Fahrzeugs von der AHMI 140 empfangen werden. Eingabevorrichtungen können Mikrofone, auf Licht basierende Sensoren (z.B. Sensoren, die Laser verwenden), Druckknöpfe, Drehknöpfe, berührungsempfindliche Anzeigen und/oder andere berührungsempfindliche Vorrichtungen umfassen. Beispielsweise umfasst die Anwendereingabe 110 Eingaben in ein Bedientableau oder in andere Eingabevorrichtungen, die Einstellungen vorschlagen, etwa für eine Temperaturregelung, für eine semiautomatisierte Fahrzeuggeschwindigkeit (z.B. Geschwindigkeitsregelung), für Radiosendereingaben, für eine Sitzposition und für einen Lenkradwinkel.
Bei einigen Implementierungen umfassen die Fahrzeugeingaben 115 Daten, die von einem oder von mehreren Fahrzeugsystemen oder Teilsystemen gesammelt wurden und die unter anderem Informationen über die Struktur und Funktion der Fahrzeugsysteme enthalten. Die Fahrzeugeingaben 115 können Daten enthalten, welche von Sensoren, Aktoren oder anderen Eingabevorrichtungen aufgenommen wurden, welche Informationen über Bedingungen innerhalb des Fahrzeugs oder außerhalb des Fahrzeugs bereitstellen. Beispielsweise enthalten die Fahrzeugeingaben 115 Daten, die von einem Sensor empfangen werden, der eine externe Fahrzeugtemperatur misst, welche mit einer Temperaturregelung innerhalb des Fahrzeugs während der gleichen Zeitspanne verglichen werden. Wenn ein Sensor beispielsweise eine externe Fahrzeugtemperatur misst, die 32°C (90°F) ist, kann von dem Anwender eine entsprechende Temperatur von 18°C (65°F) innerhalb des Fahrzeugs angefordert werden. Eingaben, die von dem Anwender bereitgestellt werden, werden hier primär als Anforderungen bezeichnet.
Die Eingaben können explizite oder implizite Befehle oder Anforderungen für eine Fahrzeugfunktion enthalten, etwa das Ändern der Temperatur der Fahrgastzelle. Der Begriff Anforderungen stellt nicht unbedingt eine Begrenzung dar und er kann sich auf Implementierungen beziehen, bei denen die Anwendereingabe per se keine Anforderung enthält. Die Eingabe kann beispielsweise umfassen, dass ein Fahrer seufzt und seine Stirn wischt, weil es im Fahrzeug warm oder heiß ist. Es kann sein, dass der Fahrer nicht erwartet, dass das System seine Äußerung als Anforderung oder kommuniziertes Bedürfnis interpretiert. Es kann sein, dass sich der Fahrer sogar nicht darüber im Klaren ist, dass das System dies kann oder dass die Äußerung gemacht worden ist.
In einigen Ausführungsformen umfassen Eingaben in die AHMI 140 Umwelteingaben 120. Die Umwelteingaben 120 können von Steuerungssensoren oder anderen (nicht gezeigten) Messvorrichtungen gemessen werden, die innerhalb oder außerhalb des Fahrzeugs angeordnet sind.
Die Messvorrichtungen erfassen Phänomene, Ereignisse oder Vorfälle (zusammengefasst gemessene Eigenschaften) und erzeugen Ausgabedaten, welche die erfassten Eigenschaften anzeigen. Gemessene Eigenschaften umfassen Systemeigenschaften der Fahrzeugsysteme und Umwelteigenschaften aus einer Umwelt (innerhalb oder außerhalb) des Fahrzeugs. Umwelteigenschaften (z.B. ein Geräusch im Fahrzeug, der Abstand zu Objekten um das Fahrzeug herum) betreffen die Umwelt, die den Fahrzeugsystemeigenschaften zugeordnet ist. Diese Umwelteigenschaften spiegeln den Status oder das Verhalten der Fahrzeugsysteme.
Analog erfassen Steuerungssensoren Anwendereingabeaktionen, die unter Verwendung von Steuerungsmechanismen für die Fahrzeugsysteme ausgeführt wurden, und Anwenderzustandssensoren messen Anwenderzustandseigenschaften. Beispielhafte Steuerungsmechanismen umfassen das Empfangen und Ausführen von Anwendereingaben in eine Steuerungsmittelkonsole oder einen anderen Rückmeldungsmechanismus, der vom Fahrzeug bereitgestellt wird.
Steuerungssensoren können Umweltbedingungen beispielsweise durch Temperatursensoren, Verkehrssensoren, Sensoren für den Straßentyp (z.B. Autobahn, Stadtverkehr), Wettersensoren (beispielsweise Regensensoren), Belegungssensoren, Kameras, die einen Abstand zu einem Objekt messen, ein Mikrofon, dergleichen und andere erfassen.
Wie erwähnt, können die Sensoren beliebige aus einer großen Vielfalt von Phänomenen oder Eigenschaften messen. Sensoren können als weiteres Beispiel Fahrzeugbedingungen, eine Zündungsposition oder Zündungszustände des Fahrzeugs, ob das Fahrzeug gerade aus- oder eingeschaltet wird, ob oder in welchem Ausmaß sich das Fahrzeug innerhalb eines Abstands zu einem Ort befindet, einen Wettertyp (z.B. Regen), ein Wetterniveau (z.B. eine Regenmenge), eine Außentemperatur, eine Außenfeuchtigkeit, eine Außenwindtemperatur, eine Fahrgastzellentemperatur, eine Fahrzeuggeschwindigkeit, die Belegung eines Sitzes im Fahrzeug, das Gewicht eines Insassen auf einem Sitz im Fahrzeug (z.B. zum Identifizieren der Belegung und zum Unterscheiden zwischen einem Kind und einem Erwachsenen), wer sich in der Fahrgastzelle befindet (z.B. durch die Anwesenheit von Zubehörvorrichtungen identifiziert, die für einen Anwender spezifisch sind), einen Fahrzeugzustand (z.B. die Treibstoffmenge im Tank, die Fahrgastzellentemperatur, die Ölmenge), einen Anwenderzustand (z.B. wie lange der Fahrer gefahren ist und die Qualität des Fahrens (z.B. erratisches Fahren des Fahrzeugs)), allgemeine Bedingungen (z.B. Wetter, Temperatur, Tag, Uhrzeit), Fahrbedingungen (z.B. Straßentyp, Verkehr) dergleichen und anderes messen.
Die AHMI 140 enthält Software- und/oder Hardware-Komponenten, welche einen integrierten Prozessor zum Verarbeiten der Software enthalten können. Zusätzlich oder alternativ kann die AHMI 140 mit einem separaten Prozessor (z.B. dem Controller 200), welcher die Software verarbeitet, in Verbindung stehen.
Die AHMI 140 ist ausgestaltet, um eine Schnittstelle (z.B. eine graphische Sprache) zu bestimmen, die dem Anwender präsentiert werden kann, und wie die Schnittstelle strukturiert sein soll. Die AHMI 140 kann die Struktur der Schnittstelle entweder statisch oder dynamisch bestimmen, indem sie die Anwendereingaben 110, die Fahrzeugeingaben 115 und die Umwelteingaben 120 (zusammengefasst ein Eingabedatenpaket), welche von entweder einem (nicht gezeigten) Anwenderverhaltensmodell und/oder einem (nicht gezeigten) Maschinenzustandsmodell erkannt werden, von Messvorrichtungen empfängt, welche mit dem Fahrzeug verbunden sind. Die AHMI 140 umfasst eine graphische Anzeige/Steuerungs-Sprache, die Bausteine (Inhalt und Format) bereitstellt, welche geeignet sind, um dem Anwender auf beliebigen von zahlreichen Abstraktionsebenen eine Lösung vorzuschlagen.
Unter Verwendung der Eingaben 110, 115 und 120 kann die Schnittstelle eine oder mehrere adaptive Anwenderschnittstellen erzeugen, die ermöglichen, dass der Anwender eine Anforderung unter Verwendung variierender Abstraktionsebenen ausführt. Die Eingaben 110, 115 und 120 können an den Controller 200 übermittelt werden, um Parameter für die Abstraktionsebenen zu bilden, welche verwendet werden, um einen oder mehrere Ausgabebefehle 150 für ein Fahrzeugsystem bereitzustellen.
Parameter sind spezielle Eigenschaften in einem Fahrzeugsystem, die verwendet werden, um Komponenten oder eine Funktionalität innerhalb des Systems zu beschreiben. Beispielsweise können Parameter, die einem Infotainmentsystem zugeordnet sind, unter anderem Parameter wie etwa die Helligkeit einer Anzeige enthalten.
Abstraktionsebenen sind jedem definierten Parameter innerhalb des Fahrzeugsystems zugeordnet. Jeder definierte Parameter kann niedrige Abstraktionsebenen (L¹) bis hin zu höheren Abstraktionsebenen (Lⁿ) enthalten. Jede Abstraktionsebene wird unter Verwendung von Befehlen definiert, die dem Anwender präsentiert werden.
Die präsentierten Anwenderbefehle können zunehmend abstrakt werden, wenn die Ebenen zunehmen. Beispielsweise ist L¹ die speziellste Ebene und Lⁿ ist die abstrakteste Ebene der Anwenderrückmeldung. Alternativ können die präsentierten Anwenderbefehle zunehmend speziell werden, wenn die Ebenen zunehmen. Beispielsweise ist L¹ die abstrakteste Ebene und Lⁿ ist die speziellste Ebene der Anwenderrückmeldung.
In einem Video-Infotainmentsystem beispielsweise, bei dem die Helligkeit der Anzeige ein relevanter Parameter ist, kann eine niedrige Abstraktionsebene darin bestehen, dass der Anwender eine Zahl 1, ..., 20 wählt (z.B. auf taktile Weise oder verbale Weise), wobei 1 die niedrigste Helligkeitseinstellung der Videoanzeige ist und 20 die höchste Helligkeitseinstellung der Videoanzeige ist. Bei dem gleichen Beispiel kann eine höhere Abstraktionsebene umfassen, dass der Anwender verbale oder taktile Anweisungen zum Einstellen der Helligkeit der Anzeige bereitstellt. Der Anwender kann sagen: "Anzeige heller machen" oder eine Skala wählen, mit welcher die Helligkeit der Anzeige verstellt werden kann. Eine noch höhere Abstraktionsebene kann umfassen, dass das Fahrzeugsystem die Helligkeit der Anzeige auf der Grundlage der Tageszeit automatisch verstellt (z.B. die Helligkeit der Anzeige bei Nacht erhöht), um Bedürfnisse des Anwenders zu antizipieren. Auf einer anderen hohen Abstraktionsebene kann der Anwender eine allgemeine Aussage formulieren, etwa "Ich fühle mich nicht wohl" im Fall eines Klimaregelungssystems, oder "Ich kann nicht gut sehen" im Fall eines Videosystems, oder indem er eine Geste ausführt, etwa Wischen über seine Stirn und/oder ein Geräusch, etwa "Puh", was dem System anzeigt, dass die Temperatur und/oder Feuchtigkeit verstellt werden sollen.
Die vorstehend erwähnten Beispiele veranschaulichen, wie mit jeder zunehmenden Abstraktionsebene die Interaktion des Anwenders mit dem System allgemeiner und vager wird. Jedoch kann die AHMI 140 vorherige Anwendereingaben 110, Fahrzeugeingaben 115 und/oder Umwelteingaben 120 verwenden, um die Bedeutung einer allgemeinen oder vagen Anwenderaussage oder einer anderen Anwendereingabe zu bestimmen.
Potentielle Implementierungen der AHMI 140 werden nachstehend in Verbindung mit 3–5 erörtert.
Das funktionale System 130 enthält außerdem den Controller 200, der in 2 dargestellt ist. In verschiedenen Ausführungsformen enthält der Controller 200 einen Mikrocontroller, einen Mikroprozessor, einen programmierbaren Logikcontroller (PLC), eine komplexe programmierbare Logikvorrichtung (CPLD), ein im Feld programmierbares Gatearray (FPGA) oder dergleichen. Der Controller 200 kann durch die Verwendung von Codebibliotheken, statischen Analysewerkzeugen, Software, Hardware, Firmware oder dergleichen entwickelt worden sein. Jede Verwendung von Hardware oder Firmware umfasst einen Grad von Flexibilität und Hochleistung, die von einem FPGA zur Verfügung steht, wodurch die Vorteile von spezialisierten und allgemeinen Systemen kombiniert werden. Nach dem Lesen dieser Beschreibung wird es dem Fachmann auf dem Gebiet klar sein, wie die Technologie unter Verwendung anderer Computersysteme und/oder Computerarchitekturen implementiert werden kann.
Der Controller 200 enthält einen Speicher 210. Der Speicher 210 kann mehrere Kategorien von Software und Daten enthalten, die in der integrierten Vorrichtung 220 verwendet werden, welche Anwendungen 220, eine Datenbank 230, ein Betriebssystem (OS) 240 und I/O-Gerätetreiber 250 umfassen.
Wie der Fachmann feststellen wird, kann das OS 240 ein beliebiges Betriebssystem zur Verwendung mit einem Datenverarbeitungssystem sein. Die I/O-Gerätetreiber 250 können verschiedene Routinen enthalten, auf welche von den Applikationen 220 durch das OS 240 zugegriffen werden kann, um mit Geräten und bestimmten Speicherkomponenten zu kommunizieren.
Die Anwendungen 220 können in dem Speicher 210 und/oder in einer (nicht gezeigten) Firmware als ausführbare Anweisungen gespeichert sein und sie können von einem Prozessor 260 ausgeführt werden. Die Anwendungen 220 enthalten verschiedene Programme, welche, wenn sie von dem Prozessor 260 ausgeführt werden, Daten verarbeiten, die in der AHMI 140 empfangen wurden. Der Controller 200 und die AHMI 140 können in einer beliebigen einer Vielfalt von Weisen miteinander in Beziehung stehen. Beispielsweise kann der Controller 200 ein Teil der AHMI 140 sein oder umgekehrt. Oder der Controller und die AHMI können separate Komponenten sein, die miteinander in Kommunikation stehen, um hier beschriebene Funktionen auszuführen.
Die Anwendungen 220 können auf Daten angewendet werden, die in der Datenbank 230 gespeichert sind, etwa die angegebenen Parameter, zusammen mit Daten, die beispielsweise über die I/O-Datenkanäle 250 empfangen werden. Die Datenbank 230 repräsentiert die statischen und dynamischen Daten, welche von den Anwendungen 220, dem OS 240, den I/O-Gerätetreibern 250 und anderen Softwareprogrammen, die im Speicher 210 vorhanden sein können, verwendet werden.
Obwohl der Speicher 210 so dargestellt ist, dass er sich nahe bei dem Prozessor 260 befindet, versteht es sich, dass zumindest ein Teil des Speichers 210 ein Massenspeichersystem mit Fernzugriff sein kann, beispielsweise ein Server an einem Kommunikationsnetzwerk, ein entferntes Festplattenlaufwerk, ein entfernbares Massenspeichermedium, Kombinationen daraus und dergleichen. Folglich können beliebige der vorstehend beschriebenen Daten, Anwendungen und/oder Software in dem Speicher 210 gespeichert sein und/oder über drahtlose oder Netzwerkverbindungen zu anderen (nicht gezeigten) Datenverarbeitungssystemen zugänglich sein, welche beispielsweise ein lokales Netzwerk (LAN), ein Metropolnetzwerk (MAN) oder ein Weitbereichsnetzwerk (WAN) umfassen können.
Es versteht sich, dass 2 und die vorstehende Beschreibung zur Bereitstellung einer kurzen allgemeinen Beschreibung für eine geeignete Umwelt gedacht sind, in welcher die verschiedenen Aspekte von einigen Ausführungsformen der vorliegenden Offenbarung implementiert werden können. Obwohl sich die Beschreibung auf computerlesbare Anweisungen bezieht, können Ausführungsformen der vorliegenden Offenbarung außerdem durch Module implementiert sein, die Funktionen von einem oder von mehreren Programmen oder die Anweisungen ausführen, oder in Kombination mit anderen Programmmodulen und/oder als Kombination aus Hardware und Software zusätzlich zu oder anstelle von computerlesbaren Anweisungen implementiert sein.
Der Begriff "Anwendung" oder Varianten desselben wird hier ausgiebig so verwendet, dass er Routinen, Programmmodule, Programme, Komponenten, Datenstrukturen, Algorithmen und dergleichen umfasst. Anwendungen können auf verschiedenen Systemkonfigurationen implementiert werden, welche Einprozessorsysteme oder Multiprozessorsysteme, Minicomputer, Mainframecomputer, Personalcomputer, tragbare Rechenvorrichtungen, auf Mikroprozessoren beruhende programmierbare Verbraucherelektronik, Kombinationen daraus und dergleichen umfassen.
Wieder mit Bezug auf 1 kann jede Anwenderanforderung von dem funktionalen System 130 erkannt werden und eine zugehörige Anfrage, die der Anforderung entspricht, kann aufgebaut und optional übermittelt und in einem Massenspeicher (z.B. einem Cloudserver) innerhalb oder außerhalb des funktionalen Systems 130 untergebracht werden.
Ein Massenspeicher 150 kann personalisierte Dienste und Ausgabebefehle 160 auf der Grundlage des speziellen Verhaltens des Anwenders speichern (z.B. den Anwender über wiederholte Probleme durch mobile Dienste informieren). Gespeicherte Daten können unter anderem das tatsächliche Verhalten eines speziellen Anwenders, Verhaltenssequenzen des speziellen Anwenders und die Bedeutung der Sequenzen für den speziellen Anwender enthalten.
Die in dem Massenspeicher 150 untergebrachten Daten können als computerlesbarer Code gespeichert und/oder übertragen werden. Die Speicherung oder der Transportmodus kann ein beliebiges bekanntes computerlesbares Medium umfassen, welches Halbleiter, magnetische Platten, optische Platten (wie etwa CD-ROM, DVD-ROM) und als Computerdatensignal umfasst, das in einem von einem Computer verwendbaren (z.B. lesbaren) Übertragungsmedium ausgeführt ist (etwa als Trägerwelle oder als ein beliebiges anderes Medium, das ein digitales, optisches oder analoges Medium umfasst). Die im Massenspeicher 150 untergebrachten Daten können von einem Prozessor an den und von dem Controller 200 übertragen werden.
In einigen Ausführungsformen sammelt und speichert der Massenspeicher 150 Daten, die aus einer Gemeinschaft von Fahrern abgeleitet wurden, deren Verhaltensweisen von dem System überwacht werden. Die Verfügbarkeit einer Gemeinschaft von Fahrern ermöglicht, dass der Massenspeicher 150 konstant mit angesammelten Abfragen aktualisiert werden kann, welche über das Signal an den Controller 200 übermittelt werden können. Die in dem Massenspeicher 150 gespeicherten Abfragen können verwendet werden, um auf der Grundlage von großen Datenmengen, die von vielen Anwendern protokolliert werden, personalisierte Dienste und Ausgabebefehle 160 bereitzustellen. Die Abfragedaten können von einem Prozessor an den und von dem Controller 200 übertragen werden.
Die Ausgabebefehle 160 sind Anweisungen, die von der AHMI 140 gebildet werden, welche einen gewünschten Befehl des Anwenders ausführen. Insbesondere gibt die AHMI 140 einen Befehl oder eine Sequenz von Befehlen an Fahrzeugsysteme aus, die auf der Grundlage des Anwenderbefehls aktiviert werden. Beispielsweise ist der Ausgabebefehl 160 die Aktivierung eines speziellen Fahrzeugsystems oder Teilsystems.
Die Ausgabebefehle 160 können in der Form einer Empfehlung für den Anwender vorliegen. Empfehlungen können personalisierte Hilfen für den Anwender beim Ausführen einer Anforderung enthalten. Die Empfehlungen werden von einer oder mehreren Ausgabevorrichtungen an den Anwender übermittelt, welche Informationen durch visuelle, akustische oder taktile Schnittstellen für einen Fahrzeuginsassen über sich verändernde Fahrzeugbedingungen bereitstellen (z.B. eine sich ändernde Position von Objekten, die in einer umgebenden Umwelt detektiert wurden). Beispielsweise kann die Ausgabevorrichtung Text oder Video auf einem Bildschirm innerhalb des Fahrzeugs oder Textanweisungen auf einer mobilen Vorrichtung anzeigen, wenn sich das Fahrzeug nicht mehr bewegt. Als weiteres Beispiel können die Ausgabekomponenten Audio-Sprachanweisungen von Komponenten innerhalb des Fahrzeugs (z.B. Lautsprechern) bereitstellen.
Das funktionale System 130 kann eine beliebige oder mehrere andere Vorrichtungen und Komponenten enthalten und/oder damit in Verbindung stehen, um Funktionen des Systems 130 auszuführen. Beispielsweise können mehrere Controller 200 verwendet werden, um Verhaltensweisen zu erkennen und adaptive Sequenzen zu erzeugen.
II. Betriebsverfahren – Fig. 2
3 ist ein Flussdiagramm, das Algorithmen oder Verfahren zum Ausführen einer funktionalen Sequenz veranschaulicht. Der Begriff Verfahren wird hier primär der Einfachheit halber verwendet. Das Verfahren kann von dem vorstehend beschriebenen Controller 200 ausgeführt werden.
Das Verfahren beginnt damit, dass das funktionale System 130 bei Schritt 310 die Anforderung des Anwenders wahrnimmt. Die Anwenderanforderung kann durch eine Kombination aus Hardware (z.B. Mikrofone und Lautsprecher) und Software (z.B. Spracherkennungssoftware) wahrgenommen werden, um festzustellen, ob ein Anwender eine Unterstützung oder einen Betrieb des funktionalen Systems 130 mögen würde (z.B. anfordert) oder davon profitieren würde.
Als Nächstes stellt der Prozessor 260 bei Schritt 320 fest, ob die von dem Anwender gestellte Anforderung von dem System 130 als eine Anforderung erkannt wird, die zuvor auf einer Abstraktionsebene gespeichert wurde.
In einigen Implementierungen hat das System 130 zuvor einen Typ einer Anwenderanforderung oder einen Bedarf gespeichert, wobei die Speicherfunktion in 3 durch einen Pfad 365 angezeigt wird. Bei späteren Iterationen des Verfahrens 300 kann das System 130 die gespeicherte Anforderung verwenden. Wenn die Anforderung gespeichert wurde, wird das System 130 in der Lage sein, aus einem Speicher (z.B. dem Massenspeicher 150) eine zugehörige Abstraktionsebene abzurufen, die der Anforderung entspricht. In einigen Ausführungsformen hat das System 130 die Anforderung in Verbindung mit einem geeigneten Befehl oder einer geeigneten Funktion gespeichert. Dort, wo die Anwenderanforderung in der Form einer taktilen Eingabe vorliegt (z.B. der Anwender einen Knopf auf einer Anzeige berührt), sind die Optionen, die dem Anwender präsentiert werden, mit einer Abstraktionsebene verbunden, die von dem System 130 vorbestimmt wird. Insbesondere entspricht die Anwendereingabe exakt einem oder mehreren Befehlen, welche das System 130 ermittelt hat oder in Echtzeit ermittelt, um sie in derartigen Situationen auszuführen. Wenn der Anwender beispielsweise einen Knopf auf einer Anzeige berührt, um ein Ventilatorniveau gleich Eins zu wählen (z.B. eine niedrigste Ventilatordrehzahl), führt ein oder führen mehrere Systeme den Anwenderbefehl aus. In einigen Ausführungsformen würde bei Abstraktionsebenen, die nicht so detailliert sind, ein (nicht beschriebenes) intelligentes System, das von dem System 130 getrennt und verschieden ist, die Anwendereingabe interpretieren und die auszuführenden tatsächlichen Befehle auf der Grundlage der ermittelten Abstraktionsebene bestimmen.
Wenn die Abstraktionsebene einer zuvor gespeicherten Anwenderanforderung vorbestimmt ist und in dem System 130 der Anwenderanforderung zugeordnet ist, kann sich der Anwender anschließend zwischen den Abstraktionsebenen bewegen. Das Merkmal, dass der Anwender über die Fähigkeit zur Bewegung zwischen den Abstraktionsebenen verfügt, ist dort von Vorteil, wo sich der Anwender auf eine Aufgabe konzentriert (z.B. Fahren, Sprechen an einem Telefon) und sich nicht speziell auf die Ausgabebefehle 160 konzentrieren kann, die von der AHMI 140 bereitgestellt werden.
Wenn beispielsweise L¹ die abstrakteste oder speziellste Ebene ist, kann sich der Anwender zwischen anderen Abstraktionsebenen L² ... Lⁿ bewegen. Insbesondere kann dann, wenn sich der Anwender auf eine Aufgabe konzentriert (z.B. Fahren, ein Telefonat führen), die Anwenderanforderung oder der Befehl relativ abstrakt sein (z.B. eine niedrigere Abstraktionsebene, wenn L¹ die abstrakteste Ebene ist und Lⁿ die speziellste Ebene der Anwenderrückmeldung ist). Wenn der Anwender jedoch über mehr Zeit oder Aufmerksamkeit verfügt, mit welcher er mit der Schnittstelle interagieren kann, kann der Anwenderbefehl spezieller sein (z.B. eine niedrigere Abstraktionsebene, wenn L¹ die speziellste Ebene und Lⁿ die abstrakteste Ebene der Anwenderrückmeldung ist).
Das System 130 ist in einigen Ausführungsformen ausgestaltet, um die Abstraktionsebenen automatisch einzustellen (um beispielsweise Wetterbedingungen zu berücksichtigen). Beispielsweise kann das System 130 dem Anwender Befehle präsentieren (z.B. auf einer Anzeige), die eine zunehmend abstraktere Abstraktionsebene aufweisen, wenn sich der Anwender auf eine Aufgabe konzentriert, oder dem Anwender Befehle präsentieren, die eine speziellere Abstraktionsebene aufweisen, wenn der Anwender mehr Zeit zur Interaktion zur Verfügung hat.
In einigen Implementierungen hat das System 130 zuvor keinen Typ einer Anwenderanforderung oder eines Bedarfs gespeichert, wobei die Speicherfunktion in 3 durch einen Pfad 325 angezeigt wird. Wenn die Anwenderanforderung nicht gespeichert wurde, holt das System 130 keine Abstraktionsebene als Grundlage für die Anwenderanforderung aus einem Speicher (z.B. dem Massenspeicher 150). Wenn die Anforderung des Anwenders beispielsweise in der Form verbaler Redebeiträge oder einer Geste vorliegt, kann sich der Anwender selbst auf natürliche Weise ausdrücken und das System 130 kann vorherige Anwenderanforderungen speichern, wodurch es die Abstraktionsebenen derartiger Anwenderanforderungen erlernt.
Wenn die Anwenderanforderung unter Verwendung von Hardware (z.B. Knöpfen oder berührungsempfindlichen Bildschirmen) und/oder von graphischen Schnittstellen oder zuvor gespeicherten Redebeiträgen und/oder Gesten gestellt wird, kennt das System 130 die Abstraktionsebene der Anwendereingaben. Auf der Grundlage dieser Abstraktionsebene bestimmt das System, welche Befehlssequenz zur Ausführung an die Fahrzeugsysteme und Teilsysteme gesendet werden wird. In einer Ausführungsform ermittelt ein weiteres intelligentes System, das sich von dem funktionalen System 130 unterscheidet, welche Befehlssequenz zur Ausführung an die Fahrzeugsysteme und Teilsysteme gesendet werden wird.
Wenn eine Anforderung zuvor nicht gespeichert wurde, ermittelt das Verfahren dann, ob die von dem Anwender gestellte Anforderung eine implizite Anforderung oder eine explizite Anforderung ist, was von dem funktionalen System 130 bei Schritt 330 erkannt wird.
Wenn die Anwenderanforderung implizit ist (z.B. Pfad 335), kann es notwendig sein, dass das funktionale System 130 die Abstraktionsebene versteht und die Anwendereingabe verarbeitet, so dass die Eingabe in Systembefehle übersetzt werden kann, die ausgeführt werden können. Insbesondere kann das funktionale System 130 die implizite Anforderung bei Schritt 340 auf der Grundlage von Eingaben, in das funktionale System 130, etwa von Anwendereingaben 110, Fahrzeugeingaben 115 und Umwelteingaben 120, in eine Steuerungssprache übersetzen (z.B. in einen computerlesbaren Code, der von dem Controller 200 verarbeitet wird).
Der Prozessor 260 erzeugt die Steuerungssprache auf der Grundlage der Anwenderschnittstelle entweder statisch oder dynamisch, indem er die Eingaben 110, 115 und 120 empfängt. Als Beispiel für eine dynamische Erzeugung kann das funktionale System 130, wenn die Anwenderanforderung "Ich fühle mich nicht wohl" aussagt, Daten analysieren, die von Temperatursensoren am Fahrzeug empfangen werden, um festzustellen, ob die Temperatur innerhalb des Fahrzeugs im großen Maß von der Temperatur außerhalb des Fahrzeugs abweicht. Als weiteres Beispiel für eine dynamische Erzeugung kann das funktionale System 130 aktuelle Anwenderverhaltensweisen analysieren, um zu ermitteln, wie die Anwenderanforderung zu klassifizieren ist.
Wenn die Anwenderanforderung eine explizite Anforderung ist (z.B. Pfad 345), kann das funktionale System 130 bei Schritt 350 die Anforderung einem Befehl zuordnen (z.B. darauf abbilden), der von dem funktionalen System 130 ausgeführt wird. Wenn als Beispiel die implizite Anforderung der Anwenderanforderung Infotainmentoptionen zugeordnet ist, würde das funktionale System 130 eine Steuerungssprache erzeugen, die ohne Beschränkung Funktionen zum Steuern eines Radios, des Internets oder eines mobilen Geräts zugeordnet ist.
Bei Schritt 360 kann der Prozessor 260 die Steuerungssprache (z.B. die Anforderung des Anwenders oder die tatsächliche Befehlssequenz), welche aus impliziten und/oder expliziten Anforderungen übersetzt wurde, bei den Schritten 340 bzw. 350 auf einer Abstraktionsebene speichern (z.B. im Massenspeicher 150), die von dem System 130 statisch oder dynamisch ermittelt wurde.
Wenn die Anwenderanforderung bei Schritt 320 erkannt wird (z.B. Pfad 365) kann die bei Schritt 360 gespeicherte Steuerungssprache von dem System 130 abgerufen werden. Ein oder mehrere Aspekte der Steuerungssprache, welche die zugeordnete Abstraktionsebene, die der Steuerungssprache zugeordnet ist, umfassen, aber nicht darauf beschränkt sind, können abgerufen und verwendet werden, um die Ausgabebefehle 160 zu erzeugen.
Bei Schritt 380 wird die Anwenderanforderung von dem System 130 ausgeführt. Wenn der Anwender beispielsweise mit einem Klimasteuerungssystem im Fahrzeug interagiert, führt die AHMI 140 eine Funktion aus oder leitet diese ein, von der festgestellt wurde, dass sie der impliziten oder expliziten Anforderung des Anwenders entspricht, etwa um das Klimaregelungssystem einzustellen (z.B. Einstellen eines Lüfters, eines Kompressors, der Temperatur, der Luftrichtung).
In einigen Ausführungsformen wird ein oder werden mehrere Ausgabebefehle 160 dem Anwender als Optionen präsentiert, wodurch ermöglicht wird, dass der Anwender eine Aktion wählt oder bestätigt, die der Anwenderanforderung entspricht.
Es versteht sich, dass die Schritte der Verfahren nicht unbedingt in einer beliebigen speziellen Reihenfolge präsentiert sind und dass das Ausführen einiger oder aller Schritte in einer alternativen Reihenfolge einschließlich über diese Figuren hinweg möglich ist und in Betracht gezogen wird.
Die Schritte wurden in der gezeigten Reihenfolge der Einfachheit der Beschreibung und Darstellung halber präsentiert. Schritte können hinzugefügt, weggelassen und/oder gleichzeitig ausgeführt werden, ohne den Umfang der beigefügten Ansprüche zu verlassen. Es versteht sich außerdem, dass die dargestellten Verfahren oder Teilverfahren jederzeit beendet werden können.
In bestimmten Ausführungsformen werden einige oder alle Schritte dieses Prozesses und/oder im Wesentlichen äquivalente Schritte von einem Prozessor, beispielsweise einem Computerprozessor, durchgeführt, welcher computerausführbare Anweisungen ausführt, die einem oder mehreren entsprechenden Algorithmen entsprechen, und mit zugehörigen Unterstützungsdaten, die in einem computerlesbaren Medium gespeichert oder enthalten sind, etwa in einem beliebigen der vorstehend beschriebenen computerlesbaren Speicher, einschließlich des entfernten Servers und von Fahrzeugen.
III. Beispielhafte Ausführungsformen – Fig. 4 und Fig. 5
4 veranschaulicht eine beispielhafte Ausführungsform des funktionalen Systems 130 mit Bezug auf ein Heizungs-, Lüftungs- und Klimaanlagensystem (HVAC-System).
In diesen Ausführungsformen können verwendete Parameter Optionen enthalten, etwa ohne Einschränkung eine gewünschte Fahrzeugtemperatur, eine Stromeinstellung des Ventilators und eine Luftströmung (z.B. eine Quelle der Luftströmung und eine Zirkulation der Luftströmung, eine externe Zirkulation oder eine Umwälzung von Luft).
In der HVAC-Ausführungsform kann die AHMI 140 Abstraktionsebenen als Teilkategorien der Parameter enthalten, die von dem funktionalen System 130 festgelegt wurden.
Die AHMI 140 kann eine beliebige Anzahl von Abstraktionsebenen (L¹, ..., Lⁿ) für jeden Parameter enthalten. Die Abstraktionsebenen jedes Parameters können von anderen Parametern unabhängig sein. Insbesondere kann jeder Parameter seine eigenen strukturierten Abstraktionsebenen aufweisen.
Als Beispiel enthält die AHMI 140 als die definierten Parameter eine Temperatur, ein Ventilatorniveau, eine Luftquelle und eine Luftzirkulation und es gibt bis zu n Abstraktionsebenen. Die in 4 dargestellte AHMI 140 enthält sechs Abstraktionsebenen, die entlang der linken Seite der Figur als 1, ..., 6 beschriftet sind. Die Abstraktionsebenen und die Anwenderrückmeldung, die durch Referenznummern definiert sind, können als Beispiel ohne Einschränkung dem Folgenden ähneln:
Wie in dem Beispiel von 4 und der vorstehenden Tabelle der Abstraktionsebenen dargestellt wurde, nimmt, wenn die Ebenen zunehmen, die Menge der Einzelheiten, die von dem Anwender an die AHMI 140 bereitgestellt werden, zusätzlich zu.
Auf den niedrigeren Ebenen (z.B. L¹ und L²) werden von dem Anwender minimale Informationen bereitgestellt. Anders ausgedrückt sind die Informationen, die von dem Anwender bereitgestellt werden, abstrakter. Wenn von dem Anwender eine minimale Rückmeldung bereitgestellt wird, kann die AHMI 140 dem Anwender Folgefragen stellen, um die Wünsche des Anwenders zur Verbesserung von Anwendererfahrungen zu bestimmen. Zudem oder alternativ kann die AHMI 140 auf eine vorherige Rückmeldung zugreifen, die von dem Anwender nach ähnlichen Anfragen bereitgestellt wurde. Beispielsweise kann die AHMI 140 dann, wenn der Anwender "Ich fühle mich nicht wohl" angibt, eine Sprach-Folgefrage (z.B. durch Fahrzeuglautsprecher) oder eine taktile Anfrage (z.B. durch ein Bedientableau) bereitstellen, welche eine zusätzliche Rückmeldung vom Anwender anfordert, um den korrekten Handlungsablauf zu bestimmen. Die Folgeanforderung kann abfragen, ob sich der Anwender beispielsweise bei der Temperatur im Fahrzeuginneren oder der Drehzahl des Lüftungsventilators unwohl fühlt. Zusätzlich oder alternativ kann die AHMI 140 zusätzliche Informationen beschaffen, indem sie auf Systeme und Teilsysteme innerhalb des Fahrzeugs zugreift.
Auf höheren Ebenen (z.B. L³ und L⁴) ist die Anwenderrückmeldung an die AHMI 140 gerichtet oder speziell. Wenn von dem Anwender eine gerichtete oder spezielle Rückmeldung bereitgestellt wird, kann die AHMI 140 dem Anwender Folgefragen stellen, um weitere Details in Verbindung mit der Anforderung zu ermitteln. Folgefragen können Informationen von dem Anwender anfordern und/oder auf eine vorherige Rückmeldung zurückgreifen, die von dem Anwender bereitgestellt wurde, nachdem ähnliche Anforderungen gestellt wurden. Wenn der Anwender beispielsweise "Ändere Temperatur" sagt, kann die AHMI 140 eine Sprach-Folgefrage stellen, die eine zusätzliche Rückmeldung anfordert, etwa die Anfrage, ob der Anwender die Temperatur erhöhen oder verringern möchte. Die AHMI 140 kann zusätzlich oder alternativ zusätzliche Informationen von Systemen und Teilsystemen im Fahrzeug beschaffen, etwa eine Anwendereingabe, die nach der letzten Anwenderanforderung zur Veränderung der Fahrzeugtemperatur aufgetreten ist.
Auf noch höheren Ebenen (z.B. L⁵ und L⁶) ist die Anwenderrückmeldung zielgerichtet oder technisch. Wenn die Anwenderrückmeldung zielgerichtet oder technisch ist, kann die AHMI 140 über ausreichend Informationen verfügen, um das System 130 so einzustellen, dass die Anwenderanforderung erfüllt wird. Wenn der Anwender beispielsweise "extremes Kühlen" sagt, kann die AHMI 140 die Anforderung so interpretieren, dass sie bedeutet, dass der Anwender die kühlste Lufttemperatur wünscht, die von dem Klimaanlagensystem zur Verfügung steht. Die AHMI 140 kann außerdem oder alternativ eine zusätzliche Rückmeldung anfordern, etwa den Anwender auffordern, eine spezielle Temperatur anzugeben. Wenn der Anwender als weiteres Beispiel "Ändere die Temperatur auf 18°C (65°F)" sagt, verfügt die AHMI 140 über technische Informationen, so dass sie den exakten Wunsch des Anwenders kennt, und kann die Temperatur entsprechend einstellen.
Unabhängig von der Abstraktionsebene kann die Anwenderrückmeldung durch den Anwender direkt von dem System empfangen werden, an welches die Anforderung gestellt wird. Wenn die Anwenderanforderung beispielsweise darin besteht, die Stärke der Luftströmung einzustellen, werden das System und die Teilsysteme (z.B. Gebläse), welche die Temperaturregelung bedient, als gewünschte Rückmeldung ansteigen.
Zusätzlich oder alternativ kann die Anwenderrückmeldung über ein beliebiges System innerhalb oder außerhalb des Fahrzeugs bereitgestellt werden. Beispielsweise kann die Anwenderrückmeldung verbal als Sprachbefehl bereitgestellt werden, der durch Lautsprecher in einem Fahrzeug empfangen wird, in ein oder mehrere analoge/digitale Signale umgewandelt wird und an ein System/Teilsystem des Fahrzeugs zur Ausführung weitergeleitet wird. Als weiteres Beispiel kann die Anwenderrückmeldung taktil als Anwendereingabe in ein Bedientableau bereitgestellt werden, wie bei dem Beispiel, das in 5 dargestellt ist.
Zusätzlich oder alternativ kann die Anwenderrückmeldung von dem System, an welches die Anforderung gestellt wird, direkt empfangen werden. Beispielsweise wird das Gebläse stärker blasen.
5 veranschaulicht ein beispielhaftes Bedientableau 500 zum Empfangen einer Eingabe von einem Anwender bezüglich HVAC-Justierungen. Ein derartiges Bedientableau kann in einer Fahrzeugmittelkonsole unter Verwendung eines visuellen Anzeigebildschirms angezeigt werden. Obwohl das Bedientableau 500 nur spezielle Parameter auf speziellen Abstraktionsebenen anzeigt, kann das Bedientableau bei der Ausführungsform der AHMI 140 beliebige Parameter auf beliebigen Ebenen anzeigen.
Wie dargestellt, kann das Bedientableau 500 verwendet werden, um die Abstraktionsebenen für die speziellen Parameter anzuzeigen. Der Anwender des Fahrzeugs kann eine nicht gerichtete Rückmeldung bereitstellen, wie auf der zweiten Abstraktionsebene beschrieben ist. Beispielsweise zeigt der Controller eine komfortable Einstellung 510 und eine nicht komfortable Einstellung 520 an. Von dort aus kann die AHMI 140 weitere Rückmeldungen auf einer höheren Abstraktionsebene anfordern.
Wie dargestellt zeigt das Bedientableau 500 einen Teil der speziellen Rückmeldung von dem Anwender (z.B. L⁴, wie in 4 dargestellt ist), mit Bezug auf das Ventilatorniveau und die Temperatureinstellungen. Als Beispiel zeigt der Controller eine Erhöhung 530 der Innentemperatur des Fahrzeugs sowie eine Verringerung 540 der Innentemperatur an. Als weiteres Beispiel zeigt der Controller 500 eine stärkere Ventilatordrehzahl 550 sowie eine schwächere Ventilatordrehzahl 560 an.
Zusätzlich oder alternativ kann der Anwender die spezielle Rückmeldung sowie die nicht gerichtete Rückmeldung zur zukünftigen Speicherung und Verarbeitung durch die AHMI 140 bereitstellen. Beispielsweise kann der Anwender die stärkere Ventilatordrehzahl 550 wählen und dann die komfortable Einstellung 510 wählen. Diese spezielle Anwenderschnittstelle kann nahelegen, dass sich der Anwender bei der gewählten Ventilatoreinstellung wohlfühlt. Die AHMI 140 kann die Informationen verwenden und speichern und sie zu einem späteren Zeitpunkt abrufen, wenn der Anwender nur eine nicht gerichtete oder eine andere Rückmeldung auf niedereren Abstraktionsebenen bereitstellt.
Das Bedientableau 500 kann zusätzlich eine hohe Abstraktionsebene enthalten, bei der alle Parameter zu einer Summenaussage zusammengefasst sein können (z.B. komfortable und nicht komfortable Einstellungen).
In einer anderen Ausführungsform kann sich die AHMI 140 auf das semiautomatisierte Fahren, Navigationssysteme oder anderweitige Sicherheitssysteme beziehen.
In diesen Ausführungsformen können verwendete Parameter Optionen ohne Einschränkungen wie etwa den Abstand zwischen dem Fahrzeug und einem weiteren Fahrzeug (eine Lücke), einen Spurversatz, eine eingestellte Geschwindigkeit des Fahrzeugs, ein Geschwindigkeitsvorzeichen, die Übermittlung von Geschwindigkeiten von Fahrzeug zu Fahrzeug und von Fahrzeug zu Infrastruktur (V2X), einen Radwinkel des Fahrzeugs, eine Krümmung der Straße, eine Geschwindigkeitsregelung des Fahrzeugs und einen Abstand zwischen dem Fahrzeug und einer Fahrspur auf der Straße umfassen.
In einer Ausführungsform für semiautomatisiertes Fahren kann die AHMI 140 Abstraktionsebenen (L¹, ..., Lⁿ) für jeden Parameter enthalten. Die Abstraktionsebenen für jeden Parameter können von anderen Parametern unabhängig sein. Insbesondere kann jeder Parameter seine eigenen strukturierten Abstraktionsebenen aufweisen.
Als Beispiel, das nicht einschränken soll, können Abstraktionsebenen in der Ausführungsform mit semi-automatisiertem Fahren niedrige Abstraktionsebenen (L¹), technische Abstraktionsebenen (L²), Standard-Abstraktionsebenen (L³) und/oder hohe Abstraktionsebenen (L⁴) umfassen.
Auf der höchsten Ebene (Lⁿ) können alle Parameter zu einer Summenaussage zusammengefasst werden (z.B. der Anwender sagt "Ich fühle mich nicht wohl").
In einer anderen Ausführungsform kann sich die AHMI 140 auf Infotainmentparameter beziehen, etwa auf Medien (z.B. Radio) oder mobile Geräte (z.B. ein Mobiltelefon).
Bei Ausführungsformen mit Infotainmentmedien können verwendete Parameter Optionen ohne Einschränkungen wie etwa einen Radiosender, eine Radiolautstärke, ein Radiofrequenzband, den Typ von Mediageräten (z.B. mp3, DVD, Radio) und Geräteeinstellungen (z.B. Höhen und Bass eines Soundsystems) umfassen.
Als Beispiel, das nicht einschränken soll, können Abstraktionsebenen in der Ausführungsform mit Infotainmentmedien niedrige Ebenen (L¹) bis zu höheren Ebenen (L⁵) umfassen, wobei bei jeder Abstraktionsebene die Abstraktheit von Befehlen zunimmt, die von dem Anwender präsentiert werden.
Es sei angemerkt, dass nicht jeder Parameter über alle Abstraktionsebenen verfügt. Es sei auch angemerkt, dass Parameter Abstraktionsebenen definieren können, die nicht aufeinander folgen. Beispielsweise weist der Parameter für Geräteeinstellungen eine niedrige Ebene bei L¹ und eine höhere Ebene bei L³ auf. Jedoch enthält der Parameter für Geräteeinstellungen keine Ebene L².
In anderen Ausführungsformen kann die AHMI 140 Abstraktionsebenen in Verbindung mit Infotainmentoptionen an einem mobilen Gerät enthalten. In diesen Ausführungsformen können Parameter Optionen ohne Einschränkungen enthalten, wie etwa Informationen, die in dem mobilen Gerät gespeichert sind (z.B. Name des Kontakts, Telefonnummer des Kontakts), Einstellungen des mobilen Geräts (z.B. Lautstärke des Lautsprechers) und interaktive Funktionalitäten (z.B. eine Telefonpaarung mit Bluetooth).
Als Beispiel, das nicht einschränken soll, können Abstraktionsebenen in der Ausführungsform mit dem mobilen Gerät niedrige Abstraktionsebenen (L¹) bis zu höheren Abstraktionsebenen (Lⁿ) umfassen, wobei bei jeder Abstraktionsebene die Abstraktheit der Befehle zunimmt, die von dem Anwender präsentiert werden.
IV. Ausgewählte Merkmale
Hier im Vorstehenden wurden viele Merkmale der vorliegenden Technologie beschrieben. Der vorliegende Abschnitt präsentiert in Zusammenfassung einige ausgewählte Merkmale der vorliegenden Technologie. Es versteht sich, dass der vorliegende Abschnitt nur einige wenige der vielen Merkmale der Technologie betont und dass die folgenden Paragraphen nicht als Einschränkung gedacht sind.
Ein Vorteil der vorliegenden Technologie besteht darin, dass das System tatsächliche Absichten des Anwenders interpretiert. Absichten des Anwenders sind manchmal implizit und von herkömmlichen Systemen nicht unmittelbar erkennbar, welche zum Empfangen tatsächlicher (expliziter) Antworten konzipiert wurden. Herkömmliche Systeme erkennen implizite Absichten oftmals nicht, da die Systeme zur allgemeinen Verwendung innerhalb einer Reihe von Fahrzeugen konzipiert sind, nicht speziell für einen speziellen Anwender.
Ein weiterer Vorteil der vorliegenden Technologie besteht darin, dass das System in Übereinstimmung mit Parametern angeordnet werden kann, die sich von herkömmlichen Konstruktionsparametern unterscheiden. Insbesondere ist die vorliegende Technologie in Übereinstimmung mit auf Menschen beruhenden Parametern angeordnet. Das Gründen des Systems auf menschlichen Parametern ermöglicht, dass das System menschliche Bedürfnisse verstehen kann, auch wenn die Absichten implizit sind.
V. Schlussfolgerung
Es wurden hier verschiedene Ausführungsformen der vorliegenden Offenbarung offenbart. Die offenbarten Ausführungsformen sind nur Beispiele, die in verschiedenen und alternativen Formen und Kombinationen daraus ausgeführt werden können.
Die vorstehend beschriebenen Ausführungsformen sind nur beispielhafte Darstellungen von Implementierungen, die für ein klares Verständnis der Prinzipien der Offenbarung offengelegt wurden.
An den vorstehend beschriebenen Ausführungsformen können Variationen, Modifikationen und Kombinationen durchgeführt werden, ohne den Umfang der Ansprüche zu verlassen. Alle derartige Variationen, Modifikationen und Kombinationen sind durch den Umfang dieser Offenbarung und der folgenden Ansprüche hier umfasst.

Claims

Computerlesbare Hardwaremassenspeichervorrichtung, die Anweisungen umfasst, welche, wenn sie von einem Prozessor ausgeführt werden, veranlassen, dass der Prozessor Operationen ausführt, um eine Anwenderanforderung an ein erstes konkretes Fahrzeugsystem zu interpretieren, umfassend: Empfangen eines Eingabedatenpakets, das eine Folge von Anwenderkommunikationen umfasst, eines Fahrzeugsystem-Datenpakets und eines Umweltmesswert-Datenpakets; Ermitteln unter Verwendung einer Mensch-Maschine-Schnittstelle, dass das Eingabedatenpaket eine implizite Anwenderanforderung enthält; Ermitteln einer Abstraktionsebene, die der impliziten Anwenderanforderung entspricht; und Zuordnen der ermittelten Abstraktionsebene zu der Anwenderanforderung zur anschließenden Verwendung beim Steuern eines zweiten konkreten Fahrzeugsystems.
Vorrichtung nach Anspruch 1, wobei die Operationen ferner umfassen, dass ermittelt wird, ob die implizite Anwenderanforderung zuvor auf der Abstraktionsebene gespeichert worden ist.
Vorrichtung nach Anspruch 2, wobei das System dann, wenn die implizite Anforderung zuvor gespeichert worden ist, die Abstraktionsebene auf der Grundlage der Anwenderanforderung abrufen kann.
Vorrichtung nach Anspruch 1, wobei die Operationen ferner umfassen, dass die implizite Anwenderanforderung zur Ausführung an ein Ziel-Fahrzeughardwareteilsystem übermittelt wird.
Vorrichtung nach Anspruch 1, wobei die Operationen ferner umfassen, dass ein oder mehrere Ausgabebefehle auf der Grundlage der Abstraktionsebene zum Empfang für den Fahrzeuganwender präsentiert werden.
Vorrichtung nach Anspruch 5, wobei die Operationen ferner umfassen, dass die Ausgabebefehle in Übereinstimmung mit der Abstraktionsebene eingestellt werden und dass die eingestellten Ausgabebefehle zum Empfang für den Fahrzeuganwender mit Hilfe einer Anzeigevorrichtung präsentiert werden.
Computerlesbare Hardwaremassenspeichervorrichtung, die Anweisungen umfasst, welche, wenn sie von einem Prozessor ausgeführt werden, veranlassen, dass der Prozessor Operationen ausführt, um eine Anwenderanforderung an ein erstes konkretes Fahrzeugsystem zu interpretieren, umfassend: Empfangen eines Eingabedatenpakets, das eine Folge von Anwenderkommunikationen umfasst, eines Fahrzeugsystem-Datenpakets und eines Umweltmesswert-Datenpakets; Ermitteln unter Verwendung einer Mensch-Maschine-Schnittstelle, dass das Eingabedatenpaket eine explizite Anwenderanforderung enthält; Ermitteln einer Abstraktionsebene, die der expliziten Anwenderanforderung entspricht; und Zuordnen der ermittelten Abstraktionsebene zu der Anwenderanforderung zur anschließenden Verwendung beim Steuern eines zweiten konkreten Fahrzeugsystems.
Vorrichtung nach Anspruch 7, wobei die Operationen ferner umfassen, dass ermittelt wird, ob die explizite Anwenderanforderung zuvor auf der Abstraktionsebene gespeichert worden ist.
Vorrichtung nach Anspruch 8, wobei das System dann, wenn die implizite Anforderung zuvor gespeichert worden ist, die Abstraktionsebene auf der Grundlage der Anwenderanforderung abrufen kann.
Vorrichtung nach Anspruch 7, wobei die Operationen ferner umfassen, dass die explizite Anwenderanforderung zur Ausführung an ein Ziel-Fahrzeughardwareteilsystem übermittelt wird.
Vorrichtung nach Anspruch 7, wobei die Operationen ferner umfassen, dass ein oder mehrere Ausgabebefehle auf der Grundlage der Abstraktionsebene zum Empfang für den Fahrzeuganwender präsentiert werden.
Vorrichtung nach Anspruch 11, wobei die Operationen ferner umfassen, dass die Ausgabebefehle in Übereinstimmung mit der Abstraktionsebene eingestellt werden und dass die eingestellten Ausgabebefehle mit Hilfe einer Anzeigevorrichtung zum Empfang für den Fahrzeuganwender präsentiert werden.
Verfahren zum Interpretieren einer Anwenderanforderung an ein erstes konkretes Fahrzeugsystem, wobei das Verfahren umfasst, dass: von einem System, das einen Prozessor aufweist, ein Eingabedatenpaket, das eine Folge von Anwenderkommunikationen umfasst, ein Fahrzeugsystem-Datenpaket und ein Umweltmesswert-Datenpaket empfangen wird; ermittelt wird, dass die Anwenderanforderung implizit ist, wenn das System zusätzliche Informationen zum Ausführen der Anwenderanforderung benötigt, ermittelt wird, dass die Anwenderanforderung explizit ist, wenn das System die Anwenderanforderung direkt ausführen kann und wobei die Anwenderanforderung implizit ist; eine Abstraktionsebene ermittelt wird, die der impliziten Anwenderanforderung entspricht; und die ermittelte Abstraktionsebene zur anschließenden Verwendung beim Steuern eines zweiten konkreten Fahrzeugsystems der Anwenderanforderung zugeordnet wird.
Verfahren nach Anspruch 13, das ferner umfasst, dass ermittelt wird, ob die explizite Anwenderanforderung zuvor auf der Abstraktionsebene gespeichert worden ist.
Verfahren nach Anspruch 14, wobei die explizite Anforderung zuvor gespeichert worden ist, wenn das System die Abstraktionsebene auf der Grundlage der Anwenderanforderung abruft.
Verfahren nach Anspruch 14, wobei die explizite Anforderung auf der Abstraktionsebene gespeichert wird, die durch eine Klassifizierung einer Anwendereingabe in das System ermittelt wurde.
Verfahren nach Anspruch 13, das ferner umfasst, dass ermittelt wird, ob die implizite Anwenderanforderung zuvor auf der Abstraktionsebene gespeichert worden ist.
Verfahren nach Anspruch 17, wobei die implizite Anforderung zuvor gespeichert worden ist, wenn das System die Abstraktionsebene auf der Grundlage der Anwenderanforderung abrufen kann.
Verfahren nach Anspruch 17, wobei die implizite Anforderung auf der Abstraktionsebene gespeichert wird, die durch eine Klassifizierung einer Anwendereingabe in das System bestimmt wurde.
Verfahren nach Anspruch 17, wobei das Verfahren ferner umfasst, dass die implizite Anwenderanforderung zur Ausführung an ein Ziel-Fahrzeughardwareteilsystem übermittelt wird.