DE102018103188B4

DE102018103188B4 - Verfahren zur spracherkennung in einem fahrzeug zur verbesserung der aufgabenerledigung

Info

Publication number: DE102018103188B4
Application number: DE102018103188.2A
Authority: DE
Inventors: Gaurav Talwar; Xu Fang Zhao; MD Foezur Rahman Chowdhury
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2017-02-15
Filing date: 2018-02-13
Publication date: 2022-01-05
Anticipated expiration: 2038-02-14
Also published as: CN108447488B; US20180233135A1; CN108447488A; US10325592B2; DE102018103188A1

Abstract

Verfahren zur Spracherkennung in einem Fahrzeug (12), umfassend die Schritte:
(a) Bestimmen einer Erfolgsrate der Spracherkennung in einer Spracherkennungsaufgabe, die unter einem vorbestimmten Schwellenwert liegt;
(b) Empfangen von Sprache an einem in einem Fahrzeug (12) installierten Mikrofon (52);
(c) Bestimmen, ob die Sprache an die Spracherkennungsaufgabe gerichtet ist;
(d) als Reaktion auf diese Bestimmungen in den Schritten (a) und (c), Senden der Sprache an eine entfernte Einrichtung (80), wenn die Sprache an die Spracherkennungsaufgabe gerichtet ist; und
(e) Bereitstellen eines lokalen Spracherkennungsergebnisses in dem Fahrzeug (12), nachdem die Sprache in Schritt (c) gesendet wurde, wobei das lokale Spracherkennungsergebnis in dem Fahrzeug (12) bestimmt wird.

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft Spracherkennungsverfahren für ein Fahrzeug.
EINLEITUNG
Spracherkennungssysteme für Fahrzeuge sind grundsätzlich bekannt, siehe hierzu beispielsweise die Druckschriften, US 2014 / 0 058 732 A1 , US 2016 / 0 111 090 A1 und DE 10 2015 213 715 A1 . Solche Spracherkennungssysteme werden für immer mehr Aufgaben eingesetzt, wie beispielsweise die Fahrzeugnavigation, was eine große Anzahl an nicht standardisierten oder spezialisierten Anweisungen, wie beispielsweise Straßennamen, Adressen oder Namen von Sehenswürdigkeiten erfordert. Die große Anzahl möglicher Anweisungen erfordert robuste Spracherkennungssysteme, da mögliche Befehle variiert und unvorhersehbar sind. Dementsprechend sind die Erfolgsraten bei der Spracherkennung typischerweise niedriger. Die für Navigationssysteme typischen, relativ niedrigen Erfolgsraten können zu Frustration bei den Benutzern und zu einer geringeren Auslastung des Spracherkennungssystems führen.
ZUSAMMENFASSUNG
Erfindungsgemäß wird ein Verfahren zur Spracherkennung in einem Fahrzeug vorgeschlagen, das sich durch die Merkmale des Anspruchs 1 auszeichnet.
Das Verfahren zur Spracherkennung in einem Fahrzeug umfasst das Ermitteln einer Erfolgsrate der Spracherkennung in einer Spracherkennungsaufgabe, die unter einem vorgegebenen Schwellenwert liegt. Das Verfahren kann ferner das Empfangen von Sprache an einem in einem Fahrzeug installierten Mikrofon und das Ermitteln, ob die Sprache auf die Spracherkennungsaufgabe gerichtet ist, beinhalten. Als Reaktion auf das Ermitteln, dass die Sprache an die Spracherkennungsaufgabe gerichtet ist und dass die mit der Spracherkennungsaufgabe verbundene Erfolgsrate unter dem vorgegebenen Schwellenwert liegt, kann die Sprache an eine entfernte Einrichtung gesendet werden. Ein lokales Spracherkennungsergebnis im Fahrzeug nach dem Senden der Sprache in Schritt (c), wobei das lokale Spracherkennungsergebnis im Fahrzeug ermittelt wird. In mindestens einigen der hierin beschriebenen Implementierungen kann die an die entfernte Einrichtung gesendete Sprache verwendet werden, um Korrekturmaßnahmen bereitzustellen, wie vorstehend erwähnt.
Ferner wird ein System zur Spracherkennung in einem Fahrzeug beschrieben. Das System umfasst ein im Fahrzeug installiertes Mikrofon, das dazu konfiguriert ist, einen Sprachbefehl von einem Benutzer zu empfangen. Das Spracherkennungssystem in einem Fahrzeug kann konfiguriert sein, ein lokales Spracherkennungsergebnis aus dem Sprachbefehl zu ermitteln und festzustellen, wann der Sprachbefehl eine Navigationsanweisung beinhaltet. Das System kann ferner einen Fernserver in Verbindung mit dem Fahrzeug beinhalten, der dazu konfiguriert ist, eine Probe des Sprachbefehls vom Spracherkennungssystem zu empfangen, wenn der Sprachbefehl eine Navigationsanweisung beinhaltet.
Figurenliste
Eine oder mehrere Ausführungsformen der Erfindung werden im Folgenden in Verbindung mit den beigefügten Zeichnungen beschrieben, worin gleiche Bezeichnungen gleiche Elemente bezeichnen, und worin:

1 ist ein Blockdiagramm, das eine Ausführungsform eines Kommunikationssystems darstellt, das fähig ist, das hierin offenbarte Verfahren zu verwenden; und
2 ein Blockschaltbild ist, das eine Ausführungsform eines automatischen Spracherkennungssystems (ASR) darstellt; und
3 ist ein Prozessflussdiagramm, das ein Prozessflussdiagramm für ein exemplarisches Verfahren zur Spracherkennung in einem Fahrzeug veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG DER VERANSCHAULICHTEN AUSFÜHRUNGSFORM(EN)
Die im Folgenden beschriebenen exemplarischen Verfahren und Systeme können im Allgemeinen Sprache archivieren oder korrigierend wirken, wenn Spracherkennungssysteme unterhalb eines vorgegebenen Schwellenwerts arbeiten. Wenn beispielsweise ein Spracherkennungssystem für ein Fahrzeug benötigt wird um nicht-standardisierte Anweisungen, wie beispielsweise formale Namen von Kontakten, Straßennamen oder andere Eigennamen zu erkennen, können Sprachbefehle am Fahrzeug archiviert oder an eine entfernte Einrichtung gesendet werden. Die Sprachbefehle, die archiviert oder an die entfernte Einrichtung gesendet werden, können dann verwendet werden, wenn ein Problem des Benutzers mit dem Spracherkennungssystem erkannt wird. Das Personal der entfernten Einrichtung kann im Allgemeinen beim Erkennen eines Problems eines Benutzers mit dem Spracherkennungssystem eine Sicherungs- oder Korrekturhilfe zur Verfügung stellen. Darüber hinaus kann die Sprache archiviert oder an die entfernte Einrichtung gesendet werden, sobald sie im Fahrzeug empfangen wird, so dass das entfernte Personal Hilfe leisten kann, sobald ein späteres Benutzerproblem festgestellt wird.
Kommunikationssystem -
Mit Bezug auf 1 ist eine Betriebsumgebung dargestellt, die ein mobiles Fahrzeugkommunikationssystem 10 umfasst, das verwendet werden kann, um das hierin offenbarte Verfahren zu implementieren. Das Kommunikationssystem 10 beinhaltet im Allgemeinen ein Fahrzeug 12, ein oder mehrere Drahtlosträgersysteme 14, ein Festnetz 16, einen Computer 18 und ein Call-Center 20. Es versteht sich, dass das offenbarte Verfahren mit einer beliebigen Anzahl an unterschiedlichen Systemen verwendet werden kann und nicht speziell auf die hierin gezeigte Betriebsumgebung einschränkt ist. Auch die Architektur, Konstruktion, Konfiguration und der Betrieb des Systems 10 und seiner einzelnen Komponenten sind in der Technik allgemein bekannt. Somit stellen die folgenden Absätze lediglich einen kurzen Überblick über ein solches Kommunikationssystem 10 bereit; aber auch andere, hierin nicht dargestellte Systeme könnten die offenbarten Verfahren einsetzen.
Fahrzeug 12 ist in der veranschaulichten Ausführungsform als ein Personenkraftwagen dargestellt, es sollte jedoch beachtet werden, dass jedes andere Fahrzeug, einschließlich Motorräder, Lastwagen, Geländewagen (SUV), Campingfahrzeuge (RV), Wasserfahrzeuge, Flugzeuge usw. ebenfalls verwendet werden kann. Ein Teil der Fahrzeugelektronik 28 wird im Allgemeinen in 1 gezeigt und beinhaltet eine Telematikeinheit 30, ein Mikrofon 32, eine oder mehrere Tasten oder andere Steuereingänge 34, ein Audiosystem 36, eine optische Anzeige 38, ein GPS-Modul 40 sowie eine Anzahl an Fahrzeugsystemmodulen (VSMs) 42. Einige dieser Vorrichtungen können direkt mit der Telematikeinheit, wie z. B. dem Mikrofon 32 und der/den Taste(n) 34, verbunden sein, während andere indirekt unter Verwendung einer oder mehrerer Netzwerkverbindungen, wie einem Kommunikationsbus 44 oder einem Entertainmentbus 46, verbunden sind. Beispiele geeigneter Netzwerkverbindungen beinhalten ein Controller Area Network (CAN), einen medienorientierten Systemtransfer (MOST), ein lokales Kopplungsstrukturnetzwerk (LIN), ein lokales Netzwerk (LAN) und andere geeignete Verbindungen, wie z. B. Ethernet, oder andere, die u. a. den bekannten ISO-, SAE- und IEEE-Standards und -Spezifikationen entsprechen.
Die Telematikeinheit 30 selbst ist ein Fahrzeugsystemmodul (VSM) und kann eine OEM-installierte (eingebettete) oder eine Aftermarketvorrichtung sein, die in dem Fahrzeug installiert ist und eine drahtlose Sprach- und/oder Datenkommunikation über das drahtlose Trägersystem 14 und über eine drahtlose Vernetzung ermöglicht. Dies ermöglicht, dass das Fahrzeug mit Call-Center 20, anderen telematikfähigen Fahrzeugen oder einer anderen Entität oder Vorrichtung kommunizieren kann. Die Telematikeinheit verwendet vorzugsweise Funkübertragungen, um einen Kommunikationskanal (einen Sprachkanal und/oder einen Datenkanal) mit dem Drahtlosträgersystem 14 herzustellen, sodass Sprach- und/oder Datenübertragungen über den Kanal gesendet und erhalten werden können.
Durch Bereitstellen von sowohl Sprach- als auch Datenkommunikation ermöglicht die Telematikeinheit 30 dem Fahrzeug das Anbieten einer Anzahl an unterschiedlichen Diensten, darunter solche, die sich mit Navigation, Fernsprechen, Nothilfe, Diagnose, Infotainment usw. befassen. Daten können entweder über eine Datenverbindung, z. B. die Paketdatenübertragung über einen Datenkanal oder über einen Sprachkanal unter Verwendung von auf dem Fachgebiet bekannten Techniken gesendet werden. Für kombinierte Dienste, die sowohl Sprachkommunikation (z. B. mit einem Live-Berater oder einer Sprachdialogeinheit im Call-Center 20) als auch Datenkommunikation (z. B. für die Bereitstellung von GPS-Ortsdaten oder Fahrzeugdiagnosedaten im Call-Center 20) einschließen, kann das System einen einzelnen Anruf über einen Sprachkanal verwenden und nach Bedarf zwischen Sprach- und Datenübertragung über den Sprachkanal umschalten, und dies kann unter Verwendung von Techniken erfolgen, die dem Fachmann bekannt sind.
Gemäß einer Ausführungsform verwendet die Telematikeinheit 30 Mobilfunkkommunikation gemäß entweder den GSM-, CDMA- oder LTE-Standards und beinhaltet daher einen Mobilfunkstandardchipsatz 50 für die Sprachkommunikation, wie Freisprechen, ein drahtloses Modem für die Datenübertragung, ein elektronisches Verarbeitungsgerät 52, eine oder mehrere Digitalspeichervorrichtungen 54 und eine Dual-Antenne 56. Es versteht sich, dass das Modem entweder durch Software implementiert sein kann, die in der Telematikeinheit gespeichert und durch den Prozessor 52 ausgeführt wird, oder es kann eine separate Hardwarekomponente sein, die sich innerhalb oder außerhalb der Telematikeinheit 30 befinden kann. Das Modem kann mithilfe einer beliebigen Anzahl unterschiedlicher Standards oder Protokolle, wie z. B. LTE, EVDO, CDMA, GPRS und EDGE, betrieben werden. Die drahtlose Vernetzung zwischen dem Fahrzeug und den anderen vernetzten Vorrichtungen kann auch unter Verwendung der Telematikeinheit 30 erfolgen. Für diesen Zweck kann die Telematikeinheit 30 konfiguriert sein, gemäß einem oder mehreren Protokollen drahtlos zu kommunizieren einschließlich drahtloser Nahbereichskommunikation (SRWC), wie irgendwelche von den IEEE 802.11-Protokollen, WiMAX, ZigBee™, Wi-Fi direct, Bluetooth™ oder Nahfeldkommunikation (NFC). Wenn die Telematikeinheit für paketvermittelte Datenkommunikation, wie z. B. TCP/IP verwendet wird, kann sie mit einer statischen IP-Adresse dazu konfiguriert oder eingerichtet sein, eine zugewiesene IP-Adresse von einer anderen Vorrichtung im Netzwerk, wie z. B. einem Router oder einem Netzwerkadressenserver, automatisch zu empfangen.
Der Prozessor 52 kann jede Geräteart sein, die fähig ist elektronische Befehle zu verarbeiten, einschließlich Mikroprozessoren, Mikrocontrollern, Hostprozessoren, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). Er kann ein speziell dafür vorgesehener Prozessor sein, der nur für die Telematikeinheit 30 verwendet wird, oder er kann mit anderen Fahrzeugsystemen geteilt werden. Der Prozessor 52 führt verschiedene Arten von digital gespeicherten Befehlen aus, wie Software oder Firmwareprogramme, die im Speicher 54 gespeichert sind, welche der Telematikeinheit ermöglichen, eine große Vielfalt von Diensten bereitzustellen. Zum Beispiel kann der Prozessor 52 Programme ausführen oder Daten verarbeiten, um mindestens einen Teil des Verfahrens auszuführen, das hierin beschrieben ist.
Die Telematikeinheit 30 kann verwendet werden, um eine vielfältige Palette von Fahrzeugdiensten bereitzustellen, die drahtlose Kommunikation zu und/oder vom Fahrzeug beinhalten. Derartige Dienste beinhalten: Wegbeschreibungen und andere navigationsbezogene Dienste, die in Verbindung mit dem GPS-basierten Fahrzeugnavigationsmodul 40 bereitgestellt sind; Benachrichtigung über die Airbagauslösung und andere mit Notruf oder Pannendienst verbundene Dienste, die in Verbindung mit einem oder mehreren Crashsensor-Schnittstellenmodulen, wie einem Fahrzeugbeherrschbarkeitsmodul (nicht gezeigt), bereitgestellt sind; Diagnosemeldungen unter Verwendung von einem oder mehreren Diagnosemodulen; und mit Infotainment verbundene Dienste, wobei Musik, Internetseiten, Filme, Fernsehprogramme, Videospiele und/oder andere Informationen durch ein Infotainmentmodul (nicht gezeigt) heruntergeladen und für die gegenwärtige oder spätere Wiedergabe gespeichert werden. Die vorstehend aufgelisteten Dienste sind keineswegs eine vollständige Liste aller Fähigkeiten der Telematikeinheit 30, sondem sie sind einfach eine Aufzählung von einigen der Dienste, welche die Telematikeinheit anbieten kann. Des Weiteren versteht es sich, dass mindestens einige der vorstehend genannten Module in der Form von Softwarebefehlen implementiert sein könnten, die innerhalb oder außerhalb der Telematikeinheit 30 gespeichert sind, sie könnten Hardwarekomponenten sein, die sich innerhalb oder außerhalb der Telematikeinheit 30 befinden, oder sie könnten integriert sein und/oder miteinander oder mit anderen Systemen geteilt zu sein, die sich im Fahrzeug befinden, um nur einige Möglichkeiten zu nennen. Für den Fall, dass die Module als VSM 42 implementiert sind, die sich außerhalb der Telematikeinheit 30 befinden, könnten sie den Fahrzeugbus 44 verwenden, um Daten und Befehle mit der Telematikeinheit auszutauschen.
Das GPS-Modul 40 empfängt Funksignale von einer Konstellation 60 von GPS-Satelliten. Von diesen Signalen kann das Modul 40 die Fahrzeugposition ermitteln, die verwendet wird, um Navigation und andere mit der Position verbundene Dienste an den Fahrzeugführer bereitzustellen. Navigationsinformationen können auf der Anzeige 38 (oder einer anderen Anzeige innerhalb des Fahrzeugs) dargestellt oder in verbaler Form präsentiert werden, wie es beispielsweise bei der Wegbeschreibungsnavigation der Fall ist. Die Navigationsdienste können unter Verwendung von einem zugehörigen Fahrzeugnavigationsmodul (das Teil des GPS-Moduls 40 sein kann) bereitgestellt werden, oder einige oder alle Navigationsdienste können über die Telematikeinheit 30 erfolgen, wobei die Positionsinformationen zum Zweck des Ausstattens des Fahrzeugs mit Navigationskarten, Kartenanmerkungen (Sehenswürdigkeiten, Restaurants usw.), Routenberechnungen und dergleichen zu einem entfernten Standort gesendet werden. Die Positionsinformationen können an das Call-Center 20 oder ein anderes Remotecomputersystem, wie Computer 18, für andere Zwecke, wie Flottenmanagement, bereitgestellt werden. Außerdem können neue oder aktualisierte Kartendaten zum GPS-Modul 40 vom Call-Center 20 über die Telematikeinheit 30 heruntergeladen werden.
Abgesehen vom Audiosystem 36 und dem GPS-Modul 40 kann das Fahrzeug 12 andere Fahrzeugsystemmodule (VSM) 42 in der Form von elektronischen Hardwarekomponenten beinhalten, die sich im Fahrzeug befinden und typischerweise eine Eingabe von einem oder mehreren Sensoren erhalten und die erfassten Eingaben verwenden, um Diagnose, Überwachung, Steuerung, Berichterstattung und/oder andere Funktionen auszuführen. Jedes der VSMs 42 ist vorzugsweise durch den Kommunikationsbus 44 mit den anderen VSM sowie der Telematikeinheit 30 verbunden und kann darauf programmiert sein, Fahrzeugsystem- und Subsystemdiagnosetests auszuführen. So kann beispielsweise ein VSM 42 ein Motorsteuergerät (ECM) sein, das verschiedene Aspekte des Motorbetriebs, wie z. B. Kraftstoffzündung und Zündzeitpunkt, steuert, ein weiteres VSM 42 kann ein Antriebsstrangsteuermodul sein, das den Betrieb von einer oder mehreren Komponenten des Fahrzeugantriebsstrangs reguliert, und ein weiteres VSM 42 kann ein Chassis-Steuermodul sein, das verschiedene im Fahrzeug befindliche elektrische Komponente, wie beispielsweise die Zentralverriegelung des Fahrzeugs und die Scheinwerfer, verwaltet. Gemäß einer Ausführungsform ist das Motorsteuergerät mit integrierten Diagnose (OBD)-Funktionen ausgestattet, die unzählige Echtzeitdaten, wie z. B. die von verschiedenen Sensoren, einschließlich Fahrzeugemissionssensoren, erhaltenen Daten bereitstellen und eine standardisierte Reihe von Diagnosefehlercodes (DTCs) liefern, die einem Techniker ermöglichen, Fehlfunktionen innerhalb des Fahrzeugs schnell zu identifizieren und zu beheben. Fachleute auf dem Fachgebiet werden erkennen, dass es sich bei den vorgenannten VSMs nur um Beispiele von einigen der Module handelt, die im Fahrzeug 12 verwendet werden können, zahlreiche andere Module jedoch ebenfalls möglich sind.
Die Fahrzeugelektronik 28 beinhaltet auch eine Anzahl an Fahrzeugbenutzeroberflächen, die Fahrzeuginsassen mit einem Mittel zum Bereitstellen und/oder Empfangen von Informationen ausstattet, einschließlich Mikrofon 32, Taste(n) 34, Audiosystem 36, und optischer Anzeige 38. Wie hierin verwendet, beinhaltet der Begriff „Fahrzeugbenutzeroberfläche“ weitgehend jede geeignete Form von elektronischer Vorrichtung, die sowohl die im Fahrzeug befindlichen Hardware- als auch Softwarekomponenten beinhaltet und einem Fahrzeugbenutzer ermöglicht, mit einer oder durch eine Komponente des Fahrzeugs zu kommunizieren. Das Mikrofon 32 stellt eine Audioeingabe an die Telematikeinheit bereit, um dem Fahrer oder anderen Insassen zu ermöglichen, Sprachsteuerungen bereitzustellen und Freisprechen über das Drahtlosträgersystem 14 auszuführen. Für diesen Zweck kann es mit einer integrierten automatischen Sprachverarbeitungseinheit verbunden sein, welche die unter Fachleuten auf dem Gebiet bekannte Mensch-Maschinen-Schnittstellen (HMI)-Technologie verwendet. Die Taste(n) 34 ermöglichen eine manuelle Benutzereingabe in die Telematikeinheit 30, um drahtlose Telefonanrufe zu initiieren und andere Daten, Antworten oder eine Steuereingabe bereitzustellen. Separate Tasten können zum Initiieren von Notrufen gegenüber regulären Dienstunterstützungsanrufen beim Call-Center 20 verwendet werden. Das Audiosystem 36 stellt eine Audioausgabe an einen Fahrzeuginsassen bereit und kann ein zugehöriges selbstständiges System oder Teil des primären Fahrzeugaudiosystems sein. Gemäß der bestimmten Ausführungsform, die hierin gezeigt ist, ist das Audiosystem 36 operativ sowohl mit dem Fahrzeugbus 44 als auch mit dem Entertainmentbus 46 gekoppelt und kann AM-, FM- und Satellitenradio, CD-, DVD- und andere Multimediafunktionalität bereitstellen. Diese Funktionalität kann in Verbindung mit dem vorstehend beschriebenen Infotainmentmodul oder davon unabhängig bereitgestellt werden. Die optische Anzeige 38 ist vorzugsweise eine Grafikanzeige, wie z. B. ein Touchscreen am Armaturenbrett oder eine Warnanzeige, die von der Frontscheibe reflektiert wird, und verwendet werden kann, um eine Vielzahl von Eingabe- und Ausgabefunktionen bereitzustellen. Verschiedene andere Fahrzeugbenutzeroberflächen können ebenfalls verwendet werden, denn die Schnittstellen von 1 dienen lediglich als Beispiel für eine bestimmte Implementierung.
Das Drahtlosträgersystem 14 ist vorzugsweise ein Smartphonesystem, das eine Vielzahl von Mobilfunkmasten 70 (nur einer gezeigt), eine oder mehrere mobile Vermittlungszentrale Einrichtung (MSC) 72 sowie irgendwelche anderen Netzwerkkomponenten beinhaltet, die erforderlich sind, um das Drahtlosträgersystem 14 mit dem Festnetz 16 zu verbinden. Jeder Mobilfunkturm 70 beinhaltet Sende- und Empfangsantennen und eine Basisstation, wobei die Basisstationen von unterschiedlichen Mobilfunktürmen mit der MSC 72 entweder direkt oder über zwischengeschaltete Geräte, wie z. B. eine Basisstationssteuereinheit, verbunden sind. Das Mobilfunksystem 14 kann jede geeignete Kommunikationstechnik implementieren, einschließlich beispielsweise analoge Technologien, wie AMPS, oder die neueren Digitaltechnologien, wie CDMA (z. B. CDMA2000) oder GSM/GPRS. Der Fachmann wird erkennen, dass verschiedene Zellenturm- /Basisstation/MSC-Anordnungen möglich sind und mit dem drahtlosen System 14 verwendet werden könnten. Zum Beispiel könnten sich Basisstation und Zellentürme an derselben Stelle oder entfernt voneinander befinden, jede Basisstation könnte für einen einzelnen Zellenturm zuständig sein oder eine einzelne Basisstation könnte verschiedene Zellentürme bedienen und verschiedene Basisstationen könnten mit einer einzigen MSC gekoppelt werden, um nur einige der möglichen Anordnungen zu nennen.
Abgesehen vom Verwenden des Drahtlosträgersystems 14 kann ein unterschiedliches Drahtlosträgersystem in der Form von Satellitenkommunikation verwendet werden, um unidirektionale oder bidirektionale Kommunikation mit dem Fahrzeug bereitzustellen. Dies kann unter Verwendung von einem oder mehreren Fernmeldesatelliten 62 und einer aufwärtsgerichteten Sendestation 64 erfolgen. Bei der unidirektionalen Kommunikation kann es sich beispielsweise um Satellitenradiodienste handeln, worin programmierte Inhaltsdaten (Nachrichten, Musik usw.) von der Sendestation 64 erhalten werden, für das Hochladen gepackt und anschließend zum Satelliten 62 gesendet werden, der die Programmierung an die Teilnehmer sendet. Bidirektionale Kommunikation kann beispielsweise Satellitentelefoniedienste unter Verwendung der Satelliten 62 sein, um Telefonkommunikationen zwischen dem Fahrzeug 12 und der Station 64 weiterzugeben. Bei Verwendung kann dieses Satellitenfernsprechen entweder zusätzlich zum oder anstatt des Drahtlosträgersystems 14 verwendet werden.
Das Festnetz 16 kann ein konventionelles landgebundenes Telekommunikationsnetzwerk sein, das mit einem oder mehreren Festnetztelefonen verbunden ist und das Drahtlosträgersystem 14 mit dem Call-Center 20 verbindet. So kann beispielsweise das Festnetz 16 ein Fernsprechnetz (PSTN) wie jenes sein, das verwendet wird, um festverdrahtetes Fernsprechen, paketvermittelte Datenkommunikationen und die Internetinfrastruktur bereitzustellen. Ein oder mehrere Segmente des Festnetzes 16 könnten durch Verwenden eines normalen drahtgebundenen Netzwerks, eines Lichtleiter- oder eines anderen optischen Netzwerks, eines Kabelnetzes, von Stromleitungen, anderen drahtlosen Netzwerken, wie drahtlose lokale Netzwerke (WLANs) oder Netzwerke, die drahtlosen Breitbandzugang (BWA) bereitstellen oder jeder Kombination davon, implementiert sein. Des Weiteren muss das Call-Center 20 nicht über das Festnetz 16 verbunden sein, sondern könnte Funktelefonieausrüstung beinhalten, sodass direkt mit einem drahtlosen Netzwerk, wie dem Drahtlosträgersystem 14, kommuniziert werden kann.
Der Computer 18 kann einer von einer Anzahl an Computern sein, die über ein privates oder öffentliches Netzwerk, wie das Internet, zugänglich sind. Jeder dieser Computer 18 kann für einen oder mehrere Zwecke, wie einen Webserver verwendet werden, der vom Fahrzeug über die Telematikeinheit 30 und das Drahtlosträgersystem 14 zugänglich ist. Andere derartige zugängliche Computer 18 können beispielsweise sein: ein Kundendienstzentrumcomputer, wo Diagnoseinformationen und andere Fahrzeugdaten vom Fahrzeug über die Telematikeinheit 30 hochgeladen werden können; ein Clientcomputer, der vom Fahrzeugbesitzer oder einem anderen Teilnehmer für solche Zwecke, wie das Zugreifen auf oder das Erhalten von Fahrzeugdaten oder zum Einstellen oder Konfigurieren von Teilnehmerpräferenzen oder Steuern von Fahrzeugfunktionen, verwendet wird; oder ein Drittparteispeicherort, zu dem oder von dem Fahrzeugdaten oder andere Informationen entweder durch Kommunizieren mit dem Fahrzeug 12 oder dem Call-Center 20 oder beiden bereitgestellt werden. Ein Computer 18 kann auch für das Bereitstellen von Internetkonnektivität, wie DNS-Dienste oder als ein Netzwerkadressenserver, verwendet werden, der DHCP oder ein anderes geeignetes Protokoll verwendet, um dem Fahrzeug 12 eine IP-Adresse zuzuweisen.
Das Call-Center 20 ist konzipiert, die Fahrzeugelektronik 28 mit einer Anzahl an unterschiedlichen System-Back-End-Funktionen bereitzustellen, und beinhaltet nach dem hierin gezeigten Ausführungsbeispiel im Allgemeinen einen oder mehrere Switches 80, Server 82, Datenbanken 84, Live-Berater 86 sowie ein automatisiertes Sprachausgabesystem (VRS) 88, die alle auf dem Fachgebiet bekannt sind. Diese verschiedenen Komponenten des Call-Centers sind vorzugsweise miteinander über ein verdrahtetes oder drahtloses lokales Netzwerk 90 gekoppelt. Der Switch 80, der ein Nebenstellenanlagen (PBX)-Switch sein kann, leitet eingehende Signale weiter, sodass Sprachübertragungen gewöhnlich entweder zum Live-Berater 86 über das reguläre Telefon oder automatisiert zum Sprachdialogsystem 88 unter Verwendung von VolP gesendet werden. Das Live-Berater-Telefon kann auch VolP verwenden, wie durch die gestrichelte Linie in 1 angezeigt. VolP und andere Datenkommunikation durch den Switch 80 werden über ein Modem (nicht gezeigt) implementiert, das zwischen dem Switch 80 und Netzwerk 90 verbunden ist. Datenübertragungen werden über das Modem an den Server 82 und/oder die Datenbank 84 weitergegeben. Die Datenbank 84 kann Kontoinformationen, wie Teilnehmerauthentisierungsinformationen, Fahrzeugbezeichner, Profilaufzeichnungen, Verhaltensmuster und andere entsprechende Teilnehmerinformationen, speichern. Datenübertragungen können zudem durch drahtlose Systeme, wie z. B. 802.11x, GPRS und dergleichen, erfolgen. Obwohl die veranschaulichte Ausführungsform beschrieben wurde, als ob sie in Verbindung mit einem bemannten Call-Center 20 verwendet werden würde, das den Live-Berater 86 einsetzt, ist es offensichtlich, dass das Call-Center stattdessen VRS 88 als einen automatisierten Berater verwenden kann, oder eine Kombination von VRS 88 und dem Live-Berater 86 verwendet werden kann.
Unter Bezugnahme auf 2, ist nun eine veranschaulichende Architektur für ein ASR-System 210 gezeigt, das für die Umsetzung des hierin offenbarten Verfahrens verwendet werden kann. Generell interagiert ein Fahrzeuginsasse über seine Stimme mit einem automatischen Spracherkennungssystem (ASR) aus einem oder mehreren der folgenden Gründe: Trainieren des Systems auf die spezifische Stimme der Person im Fahrzeug; Speichern von Wort-für-Wort-Begriffen, wie ein gesprochener Kontakt, oder ein gesprochenes Kontrollwort, wie eine Bezugszahl oder ein Schlüsselwort; oder Erkennung der Sprache der Person im Fahrzeug für alle geeigneten Zweck, wie Sprachanwahl, Menü-Navigation, Transkription, Dienstabrufe, Steuerung von Geräten und deren Funktion im Fahrzeug oder ähnliches. Generell zieht ASR akustische Daten aus der menschlichen Sprache, vergleicht und kontrastiert die akustischen Daten mit gespeicherten Daten von Teilwörtern, trifft eine Auswahl eines geeigneten Teilwortes das mit anderen gewählten Teilwörtern verkettet werden kann und gibt die verketteten Teil-Wörter zur Nachbearbeitung weiter, beispielsweise Diktat oder Transkription, Anwahl aus dem Adressbuch, Speichern, Training der ASR-Modelle oder Anpassung der Parameter usw.
ASR-Systeme sind Fachleuten im Allgemeinen bekannt und 2 veranschaulicht nur ein spezifisches veranschaulichendes ASR-System 210. Das System 210 beinhaltet ein Gerät zur Sprachaufnahme, wie das Telematikmikrofon 32 und eine akustische Schnittstelle 33, wie eine Soundkarte der Telematikeinheit 30 mit einem Analog-Digital-Wandler zur Digitalisierung der Sprachausgabe in akustische Daten. Das System 210 hat zum Speichern der akustischen Daten, der Spracherkennungssoftware und Datenbanken auch einen Speicher, wie den Telematikspeicher 54 sowie einen Prozessor für die Verarbeitung der akustischen Daten, wie den Telematikprozessor 52. Der Prozessor arbeitet mit dem Speicher und in Verbindung mit den folgenden Modulen: ein oder mehrere Front-End-Prozessor(en) oder Präprozessor-Softwaremodule 212 zur Zerlegung akustischer Daten der Sprachausgabe in parametrischen Darstellungen, wie z.B. akustische Eigenschaften; ein oder mehrere Decoder-Softwaremodul(e) 214 zur Decodierung der akustischen Eigenschaften in digitale Ausgabedaten in Form von (Teil- )Wörtern entsprechend der Eingabe-Sprachäußerungen; und ein oder mehrere Postprozessor-Softwaremodule 216 zur Verwendung der Ausgabedaten aus dem/den Decoder-Modul(en) 214 für alle geeigneten Zwecke.
Das System 210 kann auch Sprachaufnahmen aus anderen geeigneten Audioquellen 31 empfangen, entweder in direkter Kommunikation mit dem/den Modulen der Präprozessor-Software 212, wie anhand der durchgezogenen Linie zu sehen, oder indirekt über die akustische Schnittstelle 33. Zu den Audioquellen 31 können zum Beispiel eine telefonische Quelle, wie ein Voicemail-System oder andere, beliebige telefongestützte Dienste gehören.
Ein oder mehrere Module oder Modelle kann/können als Eingabe für das/die Decoder-Module 214 verwendet werden. Zunächst können Grammatik- und/oder Lexikonmodelle 218 Regeln liefern, die festlegen, welche Wörter logischerweise auf andere Wörter folgen können, um gültige Sätze zu bilden. Grob gesagt kann eine Grammatik ein Vokabeluniversum definieren, welches das System 210 zu jeder gegebenen Zeit bei jedem ASR-Modus erwartet. Befindet sich das System 210 beispielsweise im Trainingsmodus, um Befehle zu erlernen, dann kann/können das/die Grammatikmodelle 218 Befehle einschließen, die dem System 210 bekannt sind und von diesem genutzt werden. Befindet sich das System 210 bei einem anderen Beispiel im Hauptmenü-Modus, dann kann/können das/die aktiven Grammatikmodelle 218 alle Hauptmenübefehle einschließen, die das System 210 erwartet, beispielsweise Anruf, Wählen, Verlassen, Löschen, Verzeichnis oder ähnliches. Weiterhin wird durch das/die akustischen Modelle 220 eine Unterstützung bei der Auswahl des wahrscheinlichsten Teil-Wortes entsprechend der Eingabe des Präprozessor-Moduls 212 geleistet. Drittens können Wortmodelle 222 und Satz-/Sprachmodelle 224 Regeln, Syntax, und/oder Semantik bei der Einordnung der ausgewählten Teil-Wörter oder Wörter in den Kontext der Wörter oder Sätze liefern. Weiterhin kann/können Satz- und Sprachmodelle 224 ein Universum von Sätzen schaffen, die das System 210 zu jeder gegebenen Zeit bei jedem ASR-Modus erwartet und/oder Regeln bereitstellen, die festlegen, welche Sätze logischerweise auf andere Sätze folgen können, um eine erweiterte, gültige Sprachausgabe zu bilden.
Gemäß einer alternativen Ausführungsform kann das ASR-System 210 ganz oder teilweise abgesetzt vom Fahrzeug 12 untergebracht und tätig sein, wie beispielsweise im Call-Center 20. Die Modelle für Grammatik, Akustik und dergleichen können sich beispielsweise im Speicher eines der Server 82 und/oder den Datenbanken 84 im Call-Center 20 befinden und dann der Telematikeinheit 30 für die fahrzeuginterne Sprachverarbeitung zugänglich gemacht werden. Ebenso kann die Spracherkennungssoftware unter Verwendung von Prozessoren eines der Server 82 im Call-Center 20 ablaufen. Mit anderen Worten kann das ASR-System 210 resident in der Telematikeinheit 30 arbeiten, verteilt über das Call-Center 20 und das Fahrzeug 12 auf jede gewünschte Art, und/oder resident im Call-Center 20.
Zunächst werden akustische Daten aus der menschlichen Sprache extrahiert, die ein Fahrzeuginsasse über das Mikrofon 32 eingegeben hat, welches die Laute in elektrische Signale umwandelt und an die akustische Schnittstelle 33 übergibt. Ein klangempfindliches Element im Mikrofon 32 erfasst die Äußerungen des Insassen als Variationen im Luftdruck und wandelt die Äußerungen in entsprechende Variationen eines analogen, elektrischen Signals um, wie zum Beispiel Gleichstrom oder Spannung. Die akustische Schnittstelle 33 empfängt die analogen elektrischen Signale, die zunächst abgetastet werden, sodass die Werte des analogen Signals an bestimmten Punkten der Zeit erfasst werden, danach erfolgt eine Quantisierung in der Art, dass die Amplituden der analogen Signale an jedem Abtastzeitpunkt in einen kontinuierlichen Strom digitaler Sprachsignale konvertiert werden. Mit anderen Worten, die akustische Schnittstelle 33 wandelt die analogen, elektrischen Signale in digitale, elektronische Signale um. Die digitalen Daten sind binäre Bits, die im Telematikspeicher 54 abgelegt und dann vom Telematikprozessor 52 verarbeitet werden, oder sie werden vom Prozessor 52 in Echtzeit empfangen und sofort verarbeitet.
Dann wird der kontinuierliche Strom von digitalen Sprachsignalen durch das/die Präprozessor-Module 212 in diskrete Sequenzen akustischer Parameter umgewandelt. Genauer gesagt, durchläuft der Prozessor 52 das/die Präprozessor-Module 212, um die digitalen Sprachsignale in sich überlappende phonetische oder akustische Rahmen von beispielsweise 10-30 ms Dauer zu segmentieren. Die Rahmen entsprechen akustischen Teilwörtern, wie Silben, Halbsilben, Phonen, Diphonen, Phonemen usw. Das/die Präprozessor-Module 212 führt/führen für jeden Rahmen auch eine phonetische Analyse zur Extraktion akustischer Parameter aus der Sprachausgabe des Insassen durch, wie beispielsweise zeitvariable Merkmalsvektoren. Äußerungen in der Sprache des Insassen können als Sequenzen dieser Merkmalsvektoren dargestellt werden. Wie unter Fachleuten wohl bekannt ist, können Merkmalsvektoren extrahiert werden und beispielsweise beinhalten: Stimmlage, Energieprofil, spektrale Merkmale und/oder Cepstral-Koeffizienten durch Fouriertransformationen der Rahmen und Dekorrelieren der akustischen Spektren mittels einer Cosinus-Transformation. Akustische Rahmen und entsprechende Parameter die eine bestimmte Sprechdauer abdecken, werden für die Dekodierung zu unbekannten Testmustern verkettet.
Als dritten Schritt lässt der Prozessor das/die Decoder-Module 214 ablaufen, um die eingehenden Merkmalsvektoren jedes Testmusters zu verarbeiten. Das/die Decoder-Module 214 sind auch als Erkennungs-Engine oder Klassifikator bekannt und verwenden gespeicherte Sprachreferenzmuster. Wie die Prüfmuster sind auch die Referenzmuster als eine Verkettung verwandter akustischer Rahmen und entsprechender Parameter definiert. Das Decoder-Modul 214 vergleicht und kontrastiert die akustischen Merkmalsvektoren eines Testmusters für Teilwörter zum Abgleich mit gespeicherten Referenzmustern für Teilwörter, untersucht den Grad der Differenz oder Ähnlichkeit dazwischen, und wendet schließlich Entscheidungslogik zur Auswahl des am ehesten übereinstimmenden Teilwortes als das erkannte Teilwort an. Generell ist das am ehesten übereinstimmende Teilwort das, welches dem gespeicherten Referenzmuster mit der geringsten Abweichung gleicht, oder mit der höchsten Wahrscheinlichkeit übereinstimmt, das Testmuster wird durch eine der verschiedenen unter Fachleuten bekannten Techniken zur Analyse und Erkennung von Teilwörtern ermittelt. Derartige Techniken können beinhalten: dynamische Time-Warping-Klassifikatoren, KI-Techniken, Neuronale Netze, freie Phonemerkenner, und/oder probabilistische Musteranpassungseinrichtungen, wie ein Engine nach dem Hidden Markov Model (HMM).
Das HMM ist unter Fachleuten für die Erstellung vieler Modellhypothesen für Spracherkennung einer akustischen Eingabe bekannt. Die Hypothesen werden bei der abschließenden Identifikation und Auswahl der Ausgabe berücksichtigt, die aufgrund der Merkmalsanalyse der Sprache die wahrscheinlichste korrekte Dekodierung der akustischen Eingabe darstellt. Genauer gesagt erzeugt ein HMM-Engine statistische Modelle in Form einer „N-best“-Liste der Hypothesen für Teilwort-Modelle, die abgestuft anhand von HMM-berechneten Vertrauenswerten oder Wahrscheinlichkeiten einer beobachteten Sequenz von akustischen Daten das eine oder andere Teilwort durch eine Anwendung, wie das Bayes'-Theorem, ermitteln.
Ein Bayesisches HMM-Verfahren identifiziert eine beste Hypothese entsprechend der wahrscheinlichsten Äußerung, oder Teilwort-Sequenz für eine gegebene Beobachtungsreihe von akustischen Merkmalsvektoren, deren Vertrauenswerte von einer Vielzahl von Faktoren abhängen, so auch dem Rauschabstand des eingehenden Akustiksignals. Das HMM kann auch eine statistische Verteilung enthalten, die als Mischung diagonaler Gauss'scher Werte bekannt ist und einen Wahrscheinlichkeitswert für jeden festgestellten Merkmalsvektor jedes Teilwortes enthält, die Werte können zur Neuordnung der N-best-Liste von Hypothesen verwendet werden. Der HMM-Engine kann auch zur Identifikation und Auswahl eines Teilwortes verwendet werden, dessen Wert im Wahrscheinlichkeitsmodell am höchsten ist.
Ähnlich können einzelne HMM für eine Abfolge von Teilwörtern verkettet werden kann, um HMM für einzelne oder mehrere Wörter zu bilden. Danach kann eine N-best Liste von Wortreferenzmustern und zugeordneten Parameterwerten für einzelne oder mehrere Wörter erzeugt und weiter ausgewertet werden.
In einem Beispiel verarbeitet der Spracherkennungs-Decoder 214 die Merkmalsvektoren unter Verwendung der geeigneten akustischen Modelle, Grammatik und Algorithmen zur Erzeugung einer N-best Liste von Referenzmustern. In seiner Verwendung hierin ist der Begriff Referenzmuster austauschbar mit Modellen, Wellenformen, Vorlagen, Durchsatz-Modellen, Exemplaren, Hypothesen oder anderen Arten von Referenzen. Ein Referenzmuster kann eine Reihe von Merkmalsvektoren repräsentativ für ein Wort (oder mehrere Wörter) oder Teilwörter beinhalten und auf bestimmten Sprechern, Sprechstilen und akustischen Umgebungsbedingungen basieren. Fachleute werden erkennen, dass Referenzmuster durch entsprechendes Referenzmuster-Training des ASR-Systems erstellt und im Speicher abgelegt werden können. Fachleute werden weiterhin erkennen, dass auch gespeicherte Muster verändert werden können, worin die Parameterwerte der Referenzmuster aufgrund von Unterschieden bei den Signalen der Spracheingabe beim Referenzmuster-Training und dem aktuellen Einsatz des ASR-Systems angepasst werden. So kann beispielsweise ein Satz von Referenzmustern, die für einen Fahrzeuginsassen, oder bestimmte akustische Verhältnisse erlernt wurden, für einen anderen Fahrzeuginsassen, oder andere akustische Bedingungen angepasst und als anderer Satz von Referenzmuster gespeichert werden, das beruht auf begrenzten Anlerndaten der anderen Person oder akustischen Bedingungen. Mit anderen Worten sind die Muster nicht notwendigerweise starr, sie können während der Spracherkennung angepasst werden.
Bei der Verwendung der Grammatik im Vokabular und aller geeigneten Decoder-Algorithmen und akustischen Modelle greift der Prozessor auf zahlreiche Referenzmuster im Speicher zu, die das Testmuster interpretieren. So kann der Prozessor beispielsweise eine Liste von N-best Vokabularergebnissen oder Referenzmustern zusammen mit entsprechenden Parameterwerten erstellen und abspeichern. Anschauliche Parameterwerte können für jedes Referenzmuster in der N-best-Liste des Vokabulars und zugehöriger Segmentdauern Wertungen für Vertrauen und Wahrscheinlichkeit, Werte für den Rauschspannungsabstand und/oder dergleichen beinhalten. Die N-best-Liste des Vokabulars kann in abnehmender Größe der Parameterwerte sortiert werden. Das Vokabular-Referenzmuster ist beispielsweise mit dem höchsten Vertrauenswert das beste Referenzmuster und so weiter. Sobald eine Reihe von erkannten Teilwörtern erstellt ist, können diese zur Formung von Wörtern mit Eingaben der Wortmodelle 222 genutzt werden, Sätze hingegen mit Eingaben der Sprachmodelle 224.
Abschließend empfangen die Postprozessor-Softwaremodul(e) 216 die Ausgabedaten aus dem/den Decoder-Modul(en) 214 für alle geeigneten Zwecke. Bei einem Beispiel kann/können das/die Postprozessor-Softwaremodul(e) 216 ein oder mehrere Referenzmuster aus der N-best-Liste für Referenzmuster einzelner oder mehrerer Wörter als erkannte Sprache identifizieren. In einem anderen Beispiel kann/können das/die Postprozessor-Softwaremodul(e) 216 verwendet werden, um akustische Daten in Text oder Ziffern für die Verwendung mit anderen Funktionen des ASR-Systems oder anderer Fahrzeugsysteme umzuwandeln. In einem weiteren Beispiel kann/können das/die Postprozessor-Softwaremodul(e) 216 verwendet werden, um ein Trainings-Feedback für den Decoder 214 oder Präprozessor 212 bereitzustellen. Genauer gesagt kann der Postprozessor 216 dafür eingesetzt werden, akustische Modelle für das/die Decoder-Modell(e) 214 oder Anpassungs-Parameter für das/die Präprozessor-Modul(e) 212 zu trainieren.
Die Verfahren, oder Teile davon, können in einem Computerprogramm auf einem computerlesbaren Medium implementiert werden und schließen Anweisungen für einen oder mehrere Prozessoren von einem oder mehreren Rechnern eines oder mehrerer Systeme ein, die diese Systeme dazu veranlassen, einen oder mehrere der Verfahrensschritte zu implementieren. Ein Computersoftwareprodukt kann ein oder mehrere aus Programmanweisungen in Quellcode, Objektcode, ausführbarem Code oder einem anderen Format bestehende Softwareprogramme; ein oder mehrere Firmwareprogramme; oder Dateien einer Hardwarebeschreibungssprache (HDL); und andere programmbezogene Daten beinhalten. Die Daten können Datenstrukturen, Wertetabellen oder Daten in einem anderen geeigneten Format beinhalten. Die Programmbefehle können Programmmodule, Routinen, Programme, Objekte, Komponenten und/oder dergleichen beinhalten. Das Computerprogramm kann von einem oder mehreren Computern in Verbindung miteinander ausgeführt werden.
Das/die Programm(e) kann/können auf computerlesbaren Medien verkörpert sein, die ggf. nicht-flüchtig sind und ein oder mehrere Speichergeräte, Herstellungsartikel oder dergleichen beinhalten. Zu den Beispielen für computerlesbare Medien gehören Systemspeicher von Computern, z.B. RAM (Speicher mit wahlfreiem Zugriff), ROM (Nur-Lese-Speicher); Halbleiterspeicher, z.B. EPROM (löschbarer, programmierbarer ROM), EEPROM (elektrisch löschbarer, programmierbarer ROM), Flash-Speicher; magnetische oder optische Platten oder Bänder; und/oder dergleichen. Ein computerlesbares Medium kann außerdem Verbindungen von Rechner zu Rechner beinhalten, wenn beispielsweise Daten über ein Netzwerk oder eine andere Kommunikationsverbindung (drahtgebunden, drahtlos oder in einer Kombination von beiden) übertragen oder bereitgestellt werden. Sämtliche Kombinationen aus den vorstehenden Beispielen fallen ebenfalls in den Umfang der computerlesbaren Medien. Es versteht sich daher, dass das Verfahren zumindest teilweise durch elektronische Artikel und/oder Geräte ausgeführt werden kann, die Anweisungen gemäß eines oder mehrerer Schritte des offenbarten Verfahrens ausführen können.
Verfahren -
Nun zu 3, ist ein Prozessablaufdiagramm für ein exemplarisches Verfahren zum Abschließen einer Spracherkennungsaufgabe dargestellt. Der Prozess 300 kann bei Block 305 beginnen, wobei im Fahrzeug 12 ein Sprachbefehl empfangen wird. So kann zum Beispiel Sprache am Mikrofon 52 empfangen werden, das im oder am Fahrzeug 12 installiert ist.
Weitergehend zu Block 310 kann der Prozess 300 ermitteln, ob in einem Spracherkennungssystem oder Subsystem Korrekturhilfen erforderlich sind. In einigen Beispielen kann die Leistung unter einem vorgegebenen Schwellenwert im Zeitablauf verwendet werden, um zu ermitteln, ob eine Korrekturhilfe sinnvoll ist. Genauer gesagt, kann eine Genauigkeitsrate eines ASR-Systems, z. B. des Fahrzeugs 12, unter einem vorgeschriebenen Schwellenwert liegen oder es kann ein anderer Hinweis auf ein gleichbleibendes Benutzerproblem vorliegen.
In einigen Beispielen kann Block 310 einfach abfragen, ob die Domäne des Sprachbefehls eine Domäne ist, die typischerweise unter einer verminderten Leistung oder Genauigkeit leidet, wie beispielsweise Navigation oder andere Sprachdomänen, die Eigennamen, Straßennamen, Städtenamen usw. verwenden. In diesen Beispielen kann das Fahrzeug 12 alle Mittel einsetzen, die geeignet sind, um zu ermitteln, ob sich die Domäne der Sprache auf die Navigation bezieht. Lediglich als Beispiele kann die Rede analysiert werden, um zu ermitteln, ob eine Adresse, eine Sehenswürdigkeit oder andere typische Merkmale eines Navigations-Sprachbefehls vorhanden sind.
Wenn das Ergebnis der Abfrage bei Block 310 ist, dass keine Korrekturhilfe erforderlich ist oder die Domäne keine Navigation ist, kann der Prozess 300 zu Block 315 übergehen, wobei ein Standard-Spracherkennungsablauf oder -logik verwendet wird, d. h. ohne den Sprachbefehl zu archivieren, wie im Folgenden in den Blöcken 320-345 näher beschrieben ist. Von Block 315 aus kann der Prozess 300 dann enden.
Alternativ, wenn das Ergebnis der Abfrage bei Block 310 ist, dass eine Korrekturhilfe erforderlich ist oder nützlich wäre, oder wenn die Domäne des Sprachbefehls die Navigation ist, dann kann der Prozess 300 mit Block 320 fortfahren. Bei Block 320 kann der Sprachbefehl archiviert werden, z. B. am Fahrzeug 12. Lediglich exemplarisch kann der Sprachbefehl als.ogg- oder.wav-Datei archiviert und in einem im Fahrzeug 12 installierten Speicher abgelegt werden, z. B. als Teil der Telematikeinheit 30 oder im ASR-System 210. Archivierte Sprache kann verwendet werden, um die Spracherkennung zu verbessern, zumindest in nachfolgenden Spracherkennungssitzungen. So kann beispielsweise in einer nachfolgenden Spracherkennungssitzung am Fahrzeug 12 die archivierte Sprache verwendet werden, um schnell einen Vergleich mit der nachfolgenden Sprache durchzuführen. Auf diese Weise kann das Fahrzeug 12 relativ schnell eine verbesserte Spracherkennung ermöglichen, ohne auf Ressourcen angewiesen zu sein, die vom Fahrzeug 12 entfernt sind, wie sie z. B. von der entfernten Einrichtung 80 bereitgestellt werden. In einigen Beispielen kann die Nutzung von Ressourcen im Fahrzeug, wie beispielsweise der archivierten Sprache, nur in Spracherkennungsdomänen verwendet werden, in denen Genauigkeit oder Kundenzufriedenheit problematisch sind, wie beispielsweise der Navigation. Der Prozess 300 kann dann mit Block 325 fortfahren.
Bei Block 325 kann der archivierte Sprachbefehl an die entfernte Einrichtung 80 gesendet werden. Der Sprachbefehl kann in beliebiger Weise an die entfernte Einrichtung 80 gesendet werden. So kann es beispielsweise wünschenswert sein, eine Größe des archivierten Sprachbefehls zu komprimieren oder anderweitig zu minimieren, bevor er an die entfernte Einrichtung 80 gesendet wird, wodurch die Bandbreitenauslastung des Fahrzeugs 12 reduziert wird.
Das Fahrzeug 12 kann, ausgehend von Block 330, eine lokale Spracherkennung auf dem Sprachbefehl durchführen, d. h. mit dem vorstehend in 2 beschriebenen Spracherkennungssystem des Fahrzeugs 12, und dem Benutzer des Fahrzeugs 12 Ergebnisse präsentieren. Der Prozess 300 kann dann mit Block 335 fortfahren.
Bei Block 335 kann der Prozess 300 abfragen, ob die Ergebnisse der Spracherkennung, die bei Block 330 präsentiert werden, den vorgesehenen Sprachbefehl angemessen repräsentieren. So kann beispielsweise das Fahrzeug 12 ermitteln, ob der Benutzer des Fahrzeugs 12 eines der präsentierten Ergebnisse sofort akzeptiert hat, was auf ein erfolgreiches Erkennungsergebnis hinweist, oder ob er stattdessen Probleme mit den präsentierten Ergebnissen hatte. Wenn der Benutzer die Ergebnisse abgelehnt, die Anfrage wiederholt oder die Anfrage mehrmals wiederholt hat, kann dies ein Hinweis darauf sein, dass die Ergebnisse der Spracherkennung nicht korrekt waren. Der Prozess 300 kann mit Block 345 fortfahren, wenn ermittelt wird, dass die Erkennungsergebnisse nicht korrekt waren oder der Benutzer Probleme mit den Ergebnissen hatte.
Im Allgemeinen kann Block 335 die Analyse verwenden, wie ein Benutzer des Fahrzeugs 12 auf die Spracherkennungsergebnisse bei Block 330 reagiert, um zu ermitteln, ob die dem Benutzer präsentierten Spracherkennungsergebnisse zufriedenstellend waren. Wenn die Reaktion des Benutzers auf Probleme mit den Ergebnissen hindeutet, z. B. indem er die Ergebnisse ein oder mehrere Male ablehnt oder die Sprachbefehlssitzung beendet, bevor sie erfolgreich beendet wird, kann der Prozess 300 ermitteln, dass die Ergebnisse der Spracherkennung den vorgesehenen Sprachbefehl nicht ausreichend erfasst haben.
Dementsprechend kann bei Block 345, wenn ermittelt wird, dass der Benutzer Probleme mit den präsentierten Ergebnissen hatte, eine Routenanfrage angeboten oder über die entfernte Einrichtung 80 an das Fahrzeug 12 übermittelt werden. So kann beispielsweise das Personal der entfernten Einrichtung 80 über die Problematik des Benutzers im Fahrzeug 12 informiert werden und den komprimierten Sprachbefehl analysieren, der an die entfernte Einrichtung 80 gesendet wurde. Das Personal kann den Sprachbefehl, z. B. über den archivierten Befehl, der bereits bei den Blöcken 320/325 an die entfernte Einrichtung gesendet wurde, überprüfen und die beabsichtigte Anforderung ermitteln. Darüber hinaus kann in einigen Beispielen die entfernte Einrichtung 80 eine Aufzeichnung der archivierten Sprache, die vom Fahrzeug 12 empfangen wurde, überprüfen. In dem Fall, in dem bestimmte Formulierungen oder Befehle zu einer Reihe von Ausfällen des ASR-Systems im Fahrzeug 12 geführt haben, kann die entfernte Einrichtung 80 eine Historie früherer Befehle überprüfen, um Korrekturmaßnahmen oder bestimmte Befehle zu ermitteln, die das ASR-System des Fahrzeugs 12 nicht genau identifiziert. Die entfernte Einrichtung 80 kann ein Ergebnis, das dazu bestimmt ist, den beabsichtigten Sprachbefehl zu beantworten, direkt an das Fahrzeug 12 senden. So kann beispielsweise die entfernte Einrichtung 80 zur Erbringung von Navigationsdiensten genutzt werden, z. B. durch das Bereitstellen von Abbiegehinweisen für das Fahrzeug 12, da das Fahrzeug 12 die Benutzeranforderung nicht korrekt ermittelt hat. Auf diese Weise, wenn der Benutzer Probleme mit einem Sprachbefehl hat, kann der Benutzer im Allgemeinen automatisch eine Routenanfrage oder Informationen empfangen, die vermutlich seine ursprüngliche Anfrage beantworten. Das Verfahren 300 kann dann beendet sein.
Wenn die dem Benutzer bei Block 330 präsentierten Erkennungsergebnisse bei Block 335 als vom Benutzer akzeptiert oder anderweitig ohne erhebliche Schwierigkeiten des Benutzers präsentiert werden, kann der Prozess 300 mit Block 340 fortfahren. Bei Block 340 wird die Navigationsaufgabe durch einen gewöhnlichen Spracherkennungsprozess abgeschlossen, d. h. die Fernanalyse des archivierten Navigationsbefehls muss nicht vom Personal der entfernten Einrichtung 80 analysiert werden. Somit kann die Spracherkennungsanforderung, z. B. für die Navigationshilfe, mit den bordeigenen Ressourcen des Fahrzeugs 12, z. B. GPS- und Kartendaten, vollständig erfüllt werden.