DE102020209942A1

DE102020209942A1 - System und verfahren zum auffinden eines semantischen dienstes für ein fahrzeug

Info

Publication number: DE102020209942A1
Application number: DE102020209942.1A
Authority: DE
Inventors: Ravi Akella
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2019-08-10
Filing date: 2020-08-06
Publication date: 2021-02-11
Also published as: US20210042106A1

Abstract

Ein Fahrsystem für ein erstes Fahrzeug weist einen oder mehrere Sensoren auf, der/die konfiguriert ist/sind, um Proximitätsdaten für ein oder mehrere Objekte in der Nähe des ersten Fahrzeugs und Umgebungsdaten des ersten Fahrzeugs zu gewinnen. Das Fahrsystem enthält ferner einen Fahrzeug-Transceiver, der konfiguriert ist, um mit einer entfernten Infrastruktureinheit zu kommunizieren, sowie einen Prozessor, der mit dem einem oder den mehreren Sensoren und dem Fahrzeug-Transceiver in Verbindung steht. Der Prozessor ist programmiert, um im Ansprechen auf die Proximitätsdaten und die Umgebungsdaten eine Benachrichtigung auszugeben, die eine oder mehrere Anwendungen von der entfernten Infrastruktureinheit identifiziert, wobei die eine oder die mehreren Anwendungen konfiguriert sind, um eine Fahrunterstützungsfunktion im ersten Fahrzeug auszuführen.

Description

TECHNISCHES GEBIET
Die vorliegende Offenbarung bezieht sich auf Dienste und Anwendungen für Fahrzeuge.
HINTERGRUND
Fahrzeuge können mit verschiedenen Diensten, mit denen In-Vehicle-Anwendungen interagieren, vorkonfiguriert sein. Fahrzeuge können in verschiedenen Umgebungen, für die es keine geeigneten In-Vehicle-Anwendungen gibt, fahren oder gefahren werden. Es kann für Fahrzeuge zweckdienlich sein, Software oder andere Dienste in einer Fahrzeugumgebung zu aktualisieren, um einem Benutzer zusätzlichen Komfort zu bieten.
KURZDARSTELLUNG
Gemäß einer Ausführungsform weist ein Fahrzeug-Computersystem in einem Fahrzeug einen Sensor im Fahrzeug auf, der konfiguriert ist, um eine Umgebung in der Nähe des Fahrzeugs zu überwachen. Der Sensor ist ferner konfiguriert, um ein oder mehrere Objekte außerhalb des Fahrzeugs zu erfassen. Das Fahrzeug-Computersystem enthält ferner einen Fahrzeug-Transceiver, der sich im Fahrzeug befindet und konfiguriert ist, um Daten, die indikativ für eine oder mehrere Anwendungen sind, von einer entfernten Infrastruktureinheit zu empfangen. Das Fahrzeug enthält ferner einen Prozessor, der mit dem Sensor und dem Fahrzeug-Transceiver kommuniziert und programmiert ist, um im Ansprechen auf die Umgebung des Fahrzeugs eine Benachrichtigung auszugeben, die die eine oder die mehreren Dienstanwendungen der entfernten Infrastruktureinheit identifiziert. Das Fahrzeug weist ferner eine Anzeige auf, das mit dem Prozessor kommuniziert und konfiguriert ist, um grafische Bilder anzuzeigen.
Gemäß einer zweiten Ausführungsform weist ein Fahrzeug-Computersystem in einem Fahrzeug einen oder mehrere Sensoren im Fahrzeug auf, der/die konfiguriert ist/sind, um einen Bereich in der Nähe des Fahrzeugs unter Verwendung von Proximitätsdaten zu überwachen. Der eine oder die mehreren Sensoren sind ferner konfiguriert, um ein oder mehrere Objekte außerhalb des Fahrzeugs zu erfassen. Das Fahrzeug weist einen Fahrzeug-Transceiver auf, der sich im Fahrzeug befindet und konfiguriert ist, um Daten zu empfangen, die indikativ für eine oder mehrere Anwendungen sind, die mit einer entfernten Infrastruktureinheit verknüpft sind. Das Fahrzeug weist einen Prozessor auf, der mit dem einem oder den mehreren Sensoren und dem Fahrzeug-Transceiver kommuniziert und programmiert ist, um eine Umgebung des Fahrzeugs unter Verwendung mindestens der Proximitätsdaten zu bestimmen, die eine oder die mehreren Anwendungen, die mit der entfernten Infrastruktureinheit verknüpft sind, von einem entfernten Server unter Verwendung eines semantischen Repository einschließlich eines Resource Description Framework (RDF) herunterzuladen, und im Ansprechen auf die Umgebung des Fahrzeugs eine Benachrichtigung auszugeben, die die eine oder die mehreren Anwendungen von der entfernten Infrastruktureinheit identifiziert.
Gemäß einer dritten Ausführungsform weist ein Fahrsystem für ein erstes Fahrzeug einen oder mehrere Sensoren auf, der/die konfiguriert ist/sind, um Proximitätsdaten für ein oder mehrere Objekte in der Nähe des ersten Fahrzeugs und Umgebungsdaten des ersten Fahrzeugs zu gewinnen. Das Fahrsystem enthält ferner einen Fahrzeug-Transceiver, der konfiguriert ist, um mit einer entfernten Infrastruktureinheit zu kommunizieren, sowie einen Prozessor, der mit dem einem oder den mehreren Sensoren und dem Fahrzeug-Transceiver kommuniziert. Der Prozessor ist programmiert, um im Ansprechen auf die Proximitätsdaten und Umgebungsdaten eine Benachrichtigung auszugeben, die eine oder mehrere Anwendungen von der entfernten Infrastruktureinheit identifiziert, wobei die eine oder die mehreren Anwendungen konfiguriert sind, um eine Fahrunterstützungsfunktion im ersten Fahrzeug auszuführen.
Figurenliste

1 zeigt eine Systemarchitektur für ein System 100, das eine Ausführungsform eines semantischen Repository nutzt.
2 zeigt ein Blockdiagramm eines Systems, das einen Dienstanbieter 201 nutzt.
3 zeigt ein Beispiel für ein Fahrzeug 301, das das semantische Repository nutzt.
4 zeigt ein Ablaufdiagramm 400, das in einem Fahrzeug implementiert ist, um einen semantischen Dienst zu identifizieren und zu laden.

DETAILLIERTE BESCHREIBUNG
Nachstehend sind Ausführungsformen der vorliegenden Offenbarung beschrieben. Es ist jedoch zu verstehen, dass die Ausführungsformen lediglich Beispiele sind und andere Ausführungsformen verschiedene und alternative Formen annehmen können. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale könnten übertrieben oder minimiert sein, um Details bestimmter Komponenten zu zeigen. Die hier gezeigten spezifischen strukturellen und funktionellen Details sind daher nicht als einschränkend zu interpretieren, sondern lediglich als repräsentative Grundlage für die Lehre eines Fachmanns, um die Ausführungsformen vielfältig einsetzen zu können. Wie dem Fachmann ersichtlich sein wird, können verschiedene Merkmale, die mit Bezug auf eine der Figuren illustriert und beschrieben sind, mit Merkmalen kombiniert werden, die in einer oder mehreren anderen Figuren illustriert sind, um Ausführungsformen zu generieren, die nicht explizit illustriert oder beschrieben sind. Die abgebildeten Merkmalskombinationen stellen repräsentative Ausführungsformen für typische Anwendungen dar. Verschiedene Kombinationen und Modifikationen der Merkmale, die den Lehren dieser Offenbarung entsprechen, könnten jedoch für bestimmte Anwendungen oder Implementierungen erwünscht sein.
Fahrzeuge können vorkonfigurierte Dienste enthalten, mit denen In-Vehicle-Anwendungen der Fahrzeuge interagieren können. Domain-Ontologien in einer Automobil-Einstellung können verwendet werden, um eine semantische Basis zum Beschreiben von Automobilteilen, Bestand, Abhängigkeiten zwischen verschiedenen Subsystemen, Fahrzeugspezifikationen, Fahrzeugverkauf, Fehlerdiagnose usw. zu schaffen. Das Internet kann stark auf semantische Prinzipien der Verknüpfung von offenen Daten (Open Data) angewiesen sein, um verschiedene interagierende Objekte von Web-Systemen zu beschreiben.
Zukünftige vernetzte Fahrzeugtechnologie kann sich darauf stützen, dem Benutzer eine breite Palette von Diensten für Sicherheit, Komfort und Mobilität zu bieten. In der nachfolgenden Offenbarung kann das System Cloud- oder Fog-Dienste (beispielsweise unter Verwendung von Rand-Vorrichtungen (Edge-Devices) für Berechnung, Speicherung, Kommunikation usw.) am Fahrzeug-Rand nutzen. Durch Erstellen einer dynamischen Wissenskarte (Dynamic Knowledge Map) der Dienste in der Fahrzeugumgebung kann das System neue Dienste, für die das Fahrzeug nicht ausgerüstet ist, auffinden und eine Möglichkeit zum Interagieren mit ihnen bieten.
Durch die Pflege einer dynamischen semantischen Wissenskarte von Diensten und Anwendungskontexten aus der Multi-Domain-Umgebung des Fahrzeugs (wie z.B. Umgebungsverkehr, Smart City Infrastruktur, Benutzervorrichtungen) können neue verbundene Dienste aufgefunden und dem Benutzer präsentiert werden (z.B. eine Benutzerschnittstelle oder -oberfläche (UI für User Interface) am Armaturenbrett oder auf Fahrzeugsteuerungen angewandt), die ebenso die Dienstinteraktionskomponenten umfassen können.
Semantische Web-Technologien entwickelten sich als Erweiterung des World Wide Web, um sinnvolles Wissen aus Daten auf Webseiten zu extrahieren und zu verknüpfen. Eine solche Idee gibt die Möglichkeit, eine semantische Basis für Suchmaschinen und Wissens- bzw. Knowledge-Mapping-Systeme zu schaffen. Eine Ontologie kann Konzepte, Klassen und ihre Beziehungen definieren, die üblicherweise zum semantischen Organisieren domainspezifischer Daten verwendet werden. Semantische Wissenskarten werden unter Verwendung von Ein- oder Multi-Domain-Ontologien erstellt, die in Schema-Sprachen wie Resource Description Framework Schema (RDFS) oder Web Ontology Language (OWL) ausgedrückt werden. Daten in solchen Sprachen werden normalerweise im RDF-Format (RDF für Resource Description Framework) ausgedrückt, das sich auf das Ausdrücken von Aussagen in Dreiergruppen von Subjekt, Prädikat, Objekt bezieht. Eine Datenbank, die zum Speichern solcher RDF-Dreiergruppen verwendet wird, kann als semantisches Repository bezeichnet werden. Zu den Diensten können Dienste gehören, die von Infrastrukturpunkten von Gemeinden bereitgestellt werden, wie z.B. Ampeln, straßenseitige Einheiten, Mautstellen usw. Das System kann je nach Fahrzeugkontext entsprechende Dienste auf einer Benutzeranzeige bereitstellen.
1 zeigt eine Systemarchitektur für ein System 100, das eine Ausführungsform eines semantischen Repository nutzt. Eine Smart-Infrastructure-Einheit 103 kann sich auf straßenseitige Einheiten und Objekte (oder andere Infrastrukturen) beziehen, zu denen, ohne darauf beschränkt zu sein, Straßenlampen, Ampeln, Mautstellen usw. gehören können. Die Smart-Infrastructure-Einheiten 103 können Transceiver enthalten, die Information und Daten an ein Fahrzeug 101 übermitteln können, um diese Daten im Fahrzeug 101 zu nutzen. Das Fahrzeug 101 kann ein Personenfahrzeug, ein Lastkraftwagen, ein Motorrad, ein autonomes Fahrzeug, ein halbautonomes Fahrzeug oder jede Art von Kraftfahrzeug sein. Die Smart-Infrastructure-Einheiten 103 (wie beispielsweise eine entfernte Infrastruktureinheit) können sich an einem Straßenrand oder innerhalb eines Point-of-Interest (POI) befinden, wie z.B. ein Restaurant, eine Bank, ein Parkhaus, ein Haus, ein Büro und dergleichen. Die Smart-Infrastructure-Einheit 103 kann verschiedene Daten an das Fahrzeug 101 übermitteln, um mögliche Dienste 109 zu identifizieren, die in Anspruch genommen werden können. In einer weiteren Ausführungsform kann das Fahrzeug 101 direkt mit einer Cloud 105 kommunizieren, um Webdienste 109 oder Anwendungen zu identifizieren, die das Fahrzeug 101 nutzen soll.
Das System 100 kann ein Fahrerassistenzsystem (ADAS bzw. Advanced Driver-Assistance System) / autonomes Subsystem 117 zum Steuern des Fahrzeugs 101 enthalten. Das ADAS / autonomes Subsystem 117 kann einen Controller oder Prozessor in Kommunikation mit dem Speicher enthalten. Der Speicher kann Anweisungen und Befehle speichern. Die Anweisungen können in Form von Software, Firmware, Computercode oder einer Kombination davon vorliegen. Der Speicher kann in einer beliebigen Form von einer oder mehreren Datenspeichervorrichtungen vorliegen, wie beispielsweise flüchtiger Speicher, nichtflüchtiger Speicher, elektronischer Speicher, Magnetspeicher, optischer Speicher oder jede andere Form von Datenspeichervorrichtung. In einem Beispiel kann der Speicher 2 Gigabyte (GB) DDR3-SDRAM (Double Data Rate 3 Synchronous Dynamic Random Access Memory) sowie andere austauschbare Speicherkomponenten, wie beispielsweise eine 128 GB microSD (Secure Digital) Karte, enthalten.
Der Controller kann mit verschiedenen Sensoren, Modulen und Fahrzeugsystemen sowohl innerhalb als auch außerhalb eines Fahrzeugs kommunizieren. Das Fahrzeug 101 und das ADAS / autonome Subsystem 117 können solche Sensoren enthalten, wie beispielsweise verschiedene Kameras, einen LIDAR-Sensor (Light Detection and Ranging), einen Radarsensor, einen Ultraschallsensor oder einen anderen Sensor zum Erfassen von Information über die Umgebung des Fahrzeugs 101, umfassend beispielsweise andere Fahrzeuge, Fahrbahnlinien, Leitplanken, Objekte in der Fahrbahn, Gebäude, Fußgänger und dergleichen. Im Beispiel von 1 kann das ADAS / autonome Subsystem 117 einen vorwärtsgerichteten LIDAR-Sensor, einen vorwärtsgerichteten Radarsensor, eine vorwärtsgerichtete Kamera, einen Eck-LIDAR-Sensor und einen Eck-Radarsensor enthalten. 1 zeigt ein beispielhaftes System, und das ADAS / autonome Subsystem 117 kann verschiedene Sensoren und Sensoren unterschiedlichen Typs enthalten. Das ADAS / autonome Subsystem 117 kann mit zusätzlichen Sensoren an verschiedenen Orten innerhalb oder auf dem Fahrzeug 101 ausgestattet sein, einschließlich zusätzlicher Sensoren des gleichen oder eines anderen Typs.
Das ADAS / autonome Subsystem 117 kann ebenso einen vorwärtsgerichteten LIDAR-Sensor und einen Ecken-LIDAR-Sensor enthalten, die jeweils konfiguriert sind, um einen Abstand zu einem Ziel zu messen, das sich außerhalb und in der Nähe des Fahrzeugs 101 befindet, und zwar durch Bestrahlen des Ziels mit einem gepulsten Laserlicht und Messen der reflektierten Pulse mit einem Sensor. Die LIDAR-Sensoren können dann die Unterschiede in den Laserrücklaufzeiten messen. Diese können dann zusammen mit den empfangenen Wellenlängen verwendet werden, um eine digitale dreidimensionale Darstellung von Objekten zu erzeugen. Die LIDAR-Sensoren können in der Lage sein, verschiedene Objekte auf der Grundlage der dreidimensionalen Darstellung der Objekte zu klassifizieren. Durch Bestimmen einer Form des Ziels können die LIDAR-Sensoren z.B. ein Ziel als Fahrzeug, Bordstein, Straßensperre, Gebäude, Fußgänger, Beschilderung und dergleichen klassifizieren. Der LIDAR-Sensor kann in Verbindung mit anderen Fahrzeugkomponenten, wie z.B. einer Verbrennungsmotor-Steuereinheit (ECU) und anderen Sensoren, arbeiten, um verschiedene Ziele außerhalb des Fahrzeugs 101 zu klassifizieren. Die LIDAR-Sensoren können Laser-Sender, Laser-Empfänger und andere geeignete LIDAR-Komponenten für autonome Fahrzeugsensoren umfassen. Die LIDAR-Sensoren können in einem Gehäuse angeordnet sein, das drehbar konfiguriert ist, um eine Abtastung der Umgebung zu erleichtern. Der vorwärtsgerichtete LIDAR-Sensor kann verwendet werden, um zu bestimmen, welche Fahrzeuge und Objekte sich in der vorderen Peripherie des Fahrzeugs befinden. Der Eck-LIDAR-Sensor kann ebenso zum Erfassen und Klassifizieren von Objekten verwendet werden. Der Eck-LIDAR-Sensor kann ebenso dazu verwendet werden, eine periphere Sicht des Fahrzeugs auf die Umgebung des Fahrzeugs zu verbessern.
Die Sensoren des ADAS / autonomen Subsystems 117 können konfiguriert sein, um Objekte zu erfassen und zu klassifizieren, um die periphere Sicht des Fahrzeugs auf die Umgebung des Fahrzeugs zu verbessern oder bei der Erkennung von kontextbezogenen Ereignissen in der Umgebung des Fahrzeugs zu helfen. Die Radarsensoren können zur Unterstützung oder Verbesserung verschiedener Fahrzeugsicherheitssysteme eingesetzt werden. Der vorwärtsgerichtete Radarsensor kann in eine vordere Stoßstange des Fahrzeugs eingebaut sein, um zu bestimmen, ob sich ein Objekt vor dem Fahrzeug befindet. Der Eck-Radarsensor kann sich in der hinteren Stoßstange oder an der Seite des Fahrzeugs befinden. Der Eck-Radarsensor kann verwendet werden, um festzustellen, ob sich Objekte im toten Winkel des Fahrers befinden, und um Fahrzeuge oder Objekte, die sich beim Rückwärtsfahren von hinten links und rechts nähern, zu erfassen. Eine solche Funktionalität kann es einem Fahrer ermöglichen, beim Spurwechsel oder beim Rückwärtsfahren aus einer Parklücke um andere Fahrzeuge herum zu navigieren, und bei einer autonomen Notbremsung helfen, um möglicherweise drohende Kollisionen zu vermeiden.
Die Sensoren, wie z.B. ein LIDAR-Sensor oder ein Radarsensor, können überall am Fahrzeug angebracht sein. Beispielsweise ist es möglich, einen LIDAR-Sensor auf dem Dach eines Fahrzeugs mit einer 360-Grad-Sicht auf die Umgebung des Fahrzeugs zu montieren. Darüber hinaus können die verschiedenen Sensoren das Fahrzeug umgeben, um eine 360-Grad-Sicht auf die Umgebung des Fahrzeugs zu ermöglichen. Das Fahrzeug kann ebenso mit einer oder mehreren Kameras, einem oder mehreren LIDAR-Sensoren, einem oder mehreren Radarsensoren, einem oder mehreren Ultraschallsensoren und/oder einem oder mehreren anderen Umgebungssensoren ausgerüstet sein. Aktuatoren können verwendet werden, um einen Winkel des Sichtfeldes der verschiedenen Sensoren anzupassen oder zu steuern.
Das ADAS / autonome Subsystem 117 kann ebenso eine vorwärtsgerichtete Kamera einsetzen. Die vorwärtsgerichtete Kamera kann im Rückspiegel montiert sein. Die vorwärtsgerichtete Kamera kann ebenso durch die Windschutzscheibe des Fahrzeugs aus der Fahrzeugkabine heraus gerichtet sein, um Bilddaten der Umgebung vor dem Fahrzeug zu sammeln bzw. erfassen. Die vorwärtsgerichtete Kamera kann verwendet werden, um Information (z.B. unter Verwendung von Proximitätsdaten) und andere Daten über den Bereich vor dem Fahrzeug zu sammeln und um die Bedingungen vor dem Fahrzeug zu überwachen. Die Kamera kann ebenso dazu verwendet werden, die Bedingungen vor dem Fahrzeug abzubilden und die Positionen von Fahrbahnmarkierungen aus der Kameraposition heraus sowie das Vorhandensein/Nichtvorhandensein beispielsweise einer Beleuchtung der Scheinwerfer entgegenkommender Fahrzeuge korrekt zu erfassen. Die vorwärtsgerichtete Kamera kann beispielsweise zum Erzeugen von Bilddaten in Bezug auf eine Umgebung des Fahrzeugs, wie z.B. Fahrbahnmarkierungen vor dem Fahrzeug, und zum Erfassen anderer Objekte verwendet werden. Ein Fahrzeug kann ferner mit einer rückwärtsgerichteten Kamera für ähnliche Umstände, wie beispielsweise zum Überwachen der Fahrzeugumgebung im Nahbereich hinter dem Fahrzeug, ausgerüstet sein.
Das ADAS / autonome Subsystem 117 kann ebenso ein globales Positionsbestimmungssystem (GPS) aufweisen, das eine aktuelle Position des Fahrzeugs erfasst oder bestimmt. Unter bestimmten Umständen kann das GPS verwendet werden, um die Geschwindigkeit zu bestimmen, mit der das Fahrzeug fährt. Das ADAS / autonome Subsystem 117 kann ebenso einen Fahrzeuggeschwindigkeitssensor enthalten, der die aktuelle Geschwindigkeit, mit der das Fahrzeug fährt, erfasst oder bestimmt. Das ADAS / autonome Subsystem 117 kann ebenso einen Kompass oder ein dreidimensionales Gyroskop aufweisen, um eine aktuelle Richtung des Fahrzeugs zu erfassen oder zu bestimmen. Im Speicher können Kartendaten gespeichert werden. Das GPS kann zum Aktualisieren der Kartendaten verwendet werden. Die Kartendaten können Information enthalten, die mit dem ADAS / autonomen Subsystem 117 verwendet werden können. Solche ADAS-Kartendateninformation kann detaillierte Fahrspurinformation, Neigungsinformation, Straßenkrümmungsdaten, Fahrbahnmarkierungsmerkmale und dergleichen enthalten. Solche ADAS-Karteninformation kann zusätzlich zu herkömmlichen Kartendaten wie Straßennamen, Straßenklassifizierung, Geschwindigkeitsbegrenzungsinformation und dergleichen verwendet werden. Der Controller kann Daten vom GPS sowie Daten/Information vom Gyroskop, Fahrzeuggeschwindigkeitssensor und Kartendaten verwenden, um einen Standort oder die aktuelle Position des Fahrzeugs zu bestimmen.
Das Fahrzeug 101 kann ebenso eine Anzeige für eine Mensch-Maschine-Schnittstelle (HMI oder Human-Machine Interface) enthalten. Die HMI-Anzeige kann jede Art von Anzeige innerhalb einer Fahrzeugkabine umfassen. Eine solche HMI-Anzeige kann eine Armaturenbrett-Anzeige, eine Navigationsanzeige, eine Multimedia-Anzeige, ein Head-up-Display, eine Dünnfilmtransistor-Flüssigkristallanzeige (Flüssigkristallanzeige, Dünnfilmtransistor und dergleichen) usw. umfassen. Die HMI-Anzeige kann ebenso mit Lautsprechern verbunden sein, um Ton in Bezug auf Befehle oder die Benutzerschnittstelle des Fahrzeugs auszugeben. Die HMI-Anzeige kann zum Ausgeben verschiedener Befehle oder Information an Insassen (wie beispielsweise den Fahrer oder Fahrgäste) im Fahrzeug verwendet werden. In einem automatischen Bremsszenario kann die HMI-Anzeige beispielsweise eine Nachricht anzeigen, dass das Fahrzeug zum Bremsen bereit ist, und dem Benutzer eine Rückmeldung darüber geben. Die HMI-Anzeige kann jede Art von Monitor oder Display verwenden, um den Insassen relevante Information anzuzeigen.
Die HMI-Anzeige kann nicht nur visuelle Anzeigen liefern, sondern ebenso konfiguriert sein, um Benutzereingaben über einen Touchscreen, Tasten der Benutzerschnittstelle usw. zu empfangen. Die HMI-Anzeige kann konfiguriert sein, um Benutzerbefehle zu empfangen, die auf verschiedene Fahrzeugsteuerungen, wie beispielsweise audiovisuelle Steuerungen, Steuerungen für autonome Fahrzeugsysteme, bestimmte Fahrzeugmerkmale, Kabinentemperatursteuerung und dergleichen, hinweisen. Ein Fahrzeug-Controller kann solche Benutzereingaben empfangen und seinerseits einem relevanten Fahrzeugsystem der Komponente befehlen, entsprechend den Benutzereingaben zu arbeiten.
Der Controller kann Information und Daten von den verschiedenen Fahrzeugkomponenten wie LIDAR-Sensoren, Radarsensoren, vorwärtsgerichtete Kamera, GPS und HMI-Anzeige empfangen. Das Fahrzeug 101 kann diese Daten nutzen, um Fahrzeugfunktionen bereitzustellen, die sich auf Fahrerassistenz oder autonomes Fahren beziehen können (z.B. ADAS / autonomes Subsystem 117). Beispielsweise können von den LIDAR-Sensoren und der vorwärtsgerichteten Kamera gesammelten Daten im Zusammenhang mit den GPS-Daten und Kartendaten genutzt werden, um eine Funktionalität in Bezug auf eine adaptive Geschwindigkeitsregelung, ein automatisches Einparken, eine Einparkhilfe, eine automatische Notbremsung (AEB oder Automatic Emergency Braking) und dergleichen bereitzustellen oder zu verbessern. Das ADAS / autonome Subsystem 117 kann mit verschiedenen Systemen des Fahrzeugs (z.B. Motor, Getriebe, Bremsen, Lenkmechanismus, Anzeige, Sensoren, Benutzerschnittstellenvorrichtung und dergleichen) in Verbindung stehen. Beispielsweise kann ein Fahrzeug-Controller konfiguriert sein, um Signale an die Bremsen zu senden, um das Fahrzeug 101 zu verlangsamen, oder an den Lenkmechanismus, um den Weg des Fahrzeugs 101 zu ändern, oder an den Verbrennungsmotor oder das Getriebe, um das Fahrzeug 101 zu beschleunigen oder zu verlangsamen. Das Fahrzeug 101 kann konfiguriert sein, um Eingangssignale von den verschiedenen Fahrzeugsensoren zu empfangen, um z.B. Ausgangssignale an die Anzeigevorrichtung zu senden. Das Fahrzeug 101 kann ebenso mit einer oder mehreren Datenbanken, Speichern, dem Internet oder Netzwerken zum Zugreifen auf zusätzliche Information (z.B. Karten, Straßeninformation, Wetter, Fahrzeuginformation und dergleichen) kommunizieren.
Das System 100 kann die Webdienste bzw. Webservices 109 in der Cloud 105 enthalten. Bei den Webdiensten 109 kann es sich um öffentliche oder private, in der Cloud gehostete Anwendungen handeln, die darauf ausgelegt sind, bestimmte Dienste anzubieten (z. B. Carsharing, Navigationshilfe, Musik-Streaming und dergleichen). Ein semantisches Multi-Domain-Fahrzeug-Repository (VSR) 125 kann ontologische Information, die das Fahrzeug selbst beschreibt, in der Fahrzeug-Ontologie halten bzw. speichern (wie z.B. Sensoren, Signale, Vorrichtungsspezifikationen und dergleichen). Die zusätzliche Fahrzeug-Ontologie kann Information über Information liefern, die Objekte und andere Fahrzeuge in der Umgebung des Fahrzeugs beschreibt, wobei Sensoren und Transceiver verwendet werden, um solche Information zu erhalten. Es kann davon ausgegangen werden, dass die Straßen-Ontologie vom Navigationssystem usw. bereitgestellt wird. Die Straßen-Ontologie kann Information aus der Kartendatenbank bezüglich Fahrspurinformation, Straßenklasse, Straßenkrümmung usw. enthalten. Das ADAS / autonome Subsystem 117 kann ein Subsystem für Fahrspurhaltung, Wahrnehmung, Bewegungsbahnplanung enthalten, das zum Aktualisieren der Straßen- und Verkehrsinformation des semantischen Repository 107 verwendet wird. Folglich wird das semantische Repository 107 mit Live-Information basierend auf dem Kontext des Fahrzeugs 101 aktualisiert. Die Benutzer-Ontologie kann die allgemeine Spezifikation von Benutzervorrichtungen und In-Vehicle-Anwendungen (z. B. Benutzerschnittstelle (UI oder User Interface), Sprachunterstützung usw.) erfassen, um Interoperabilität zu gewährleisten. In einem Beispiel kann das Multi-Domain-VSR 125 für einen schnelleren Zugriff im Fahrzeug 101 gespeichert werden, da das Fahrzeug 101 so nicht mit der Cloud 105 kommunizieren muss.
Das Fahrzeug 101 kann mit einem Kontext-Analysator 119 kommunizieren. Der Kontext-Analysator 119 kann ein Softwaremodul sein, das den aktuellen Fahrzeugbetriebszustand, den Fahrkontext und die Geolokalisierung identifiziert, um eine relevante Abfrage zu erstellen. So kann der Kontext-Analysator 119 in Kommunikation mit verschiedenen Fahrzeugsensoren und -hardware stehen, um relevante Daten zu sammeln. In einem Beispiel kann das System 100 in Kommunikation mit einem Radar, LIDAR, einer Kamera oder einem anderen Sensor stehen, um Fahrzeuge und Objekte außerhalb des Fahrzeugs 101 zu identifizieren. In einem anderen Beispiel kann das System 100 in Kommunikation mit einem GPS-Empfänger stehen, um den Standort des Fahrzeugs 101 zu identifizieren. Beispielsweise kann der Kontext-Analysator 119 bei einer Autobahneinfädelung, die das Host-Fahrzeug voraussichtlich vornehmen wird, einen passenden Dienst finden, der von einer straßenseitigen Einheit angeboten wird, die eine Autobahneinfädelungsunterstützung anbietet.
In einem Beispiel kann der Kontext-Analysator 119 des Systems erkennen, dass es sich bei der aktuellen Umgebung oder Fahrsituation des Fahrzeugs um eine Autobahneinfädelung handeln könnte, die das Fahrzeug voraussichtlich nehmen sollte. Der Kontext-Analysator 119 kann mit dem System 100 zusammenarbeiten, um einen passenden Dienst zu finden, der von einer straßenseitigen Einheit angeboten wird, die die Autobahneinfädelungsunterstützungsanweisungen anbietet.
Der Kontext-Analysator 119 kann mit dem ADAS / autonomen Subsystem 117 des Fahrzeugs 101 in Verbindung stehen. So kann der Kontext-Analysator 119 mit Controllern und anderen Daten kommunizieren, die vom ADAS / autonomen Subsystem 117 des Fahrzeugs verwendet werden, um bevorstehende Fahrszenarien oder Manöver vorherzusagen. Die bevorstehenden Manöver und Szenarien können für den Kontext-Analysator 119 nützlich sein, um mögliche Dienste zu identifizieren, die für einen Fahrer oder Benutzer eines Fahrzeugs von Vorteil sein können.
Der Kontext-Analysator 119 kann ebenso mit verschiedenen Benutzervorrichtungen 113 in Kommunikation bzw. Verbindung stehen. Die Benutzervorrichtungen 113 können ein Mobiltelefon, eine tragbare Vorrichtung, ein Tablet oder eine andere elektronische Vorrichtung umfassen. Die Benutzervorrichtungen 113 können Daten über den Benutzer enthalten, die vom Kontext-Analysator 119 verwendet werden könnten. Beispielsweise kann der Kontext-Analysator 119 mit Controllern und anderen Daten kommunizieren, die von Benutzervorrichtungen 113 des Fahrzeugs 101 verwendet werden, um Benutzerdaten eines Fahrers/Benutzers des Fahrzeugs 101 zu erfassen. Beispielsweise können die Benutzervorrichtungen 113 einen Fahrer/Benutzer des Fahrzeugs 101 identifizieren, ob ein Telefongespräch über ein Mobilgerät geführt wird, ob oder nicht Musikinformation abgespielt wird, und dergleichen. Die Identifizierung kann vom Kontext-Analysator 119 genutzt werden, um mögliche Dienste zu identifizieren, die für einen Fahrer oder Benutzer eines Fahrzeugs von Vorteil sein können.
Ein Benutzerabsichts-Modul 121 kann eine Abfrage durch einen Benutzer identifizieren (z.B. ein Spracherkennungsbefehl oder eine Eingabe über eine Benutzerschnittstelle). Somit kann das Benutzerabsichts-Modul 121 verwendet werden, um ein bevorstehendes Manöver oder eine bevorstehende Aktion eines Benutzers vorherzusehen. Wenn ein Benutzer beispielsweise eine Sprachanfrage sendet, um eine Wegbeschreibung zu seinem Wohnort zu erhalten, kann das Benutzerabsichts-Modul 121 voraussehen, dass der Benutzer auf bestimmten Straßen fahren wird. In einem anderen Beispiel, wenn der Benutzer zu einem mehrere hundert Meilen entfernten Zielort fahren möchte, kann das Benutzerabsichts-Modul 121 voraussehen, dass der Benutzer möglicherweise anhalten muss, um Benzin zu tanken oder eine Gebühr zu bezahlen. Das Benutzerabsichts-Modul 121 kann Daten aggregieren bzw. sammeln, die sich auf jede Abfrage beziehen, die der Benutzer an eine Abfrage-Engine 123 sendet. Die Abfrage-Engine 123 kann für die Übersetzung einer Abfrage vom Benutzerabsichts-Modul 121 und Kontext-Analysator 119 in ein semantisch gültiges Konstrukt verantwortlich sein. Die Abfrage-Engine 123 kann die Abfrage ebenso auf dem semantischen Repository 107 optimieren und ausführen. Die Abfrage kann beispielsweise an eine RDFS-Datenbank gerichtet sein, die mit einer spezialisierten Sprache wie SPARQL erstellt werden kann.
Das Fahrzeug 101 kann mit einer In-Vehicle-Benutzerschnittstelle (z.B. einer HMI oder einem Sprachassistenten 115) ausgerüstet sein. Der Sprachassistent 115 kann ein Spracherkennungssystem sein, das es ermöglicht, gesprochene Befehle als Eingabe zu nutzen, oder eine Schnittstelle zum Bedienen verschiedener Fahrzeugsysteme und Subsysteme. Zum Beispiel kann der Sprachassistent 115 verwendet werden, um eine Adresse in ein Fahrzeug-Navigationssystem zu sprechen. Der Sprachassistent 115 kann zum Sprechen von Befehlen verwendet werden, im Gegensatz zu einer herkömmlichen Eingabe auf einer HMI, die die Verwendung von physischen Tasten, Touchscreen, haptischen Vorrichtungen usw. erfordert.
Das System 100 kann das semantische Repository 107 in der Cloud 105 enthalten. Das semantische Repository 107 kann in einem anderen Beispiel ebenso Information im Fahrzeug speichern, oder ein hybrider Ansatz, bei dem sich einige Information im Fahrzeug 101 und einige Information in der Cloud 105 befindet, ist denkbar. In einem weiteren Beispiel kann das Fahrzeug 101 ebenso sein eigenes semantisches Fahrzeug-Repository enthalten. Das semantische Fahrzeug-Repository kann eine Teilmenge des semantischen Repository 107 sein, das sich in der Cloud befindet, da eine Speicherung im Fahrzeug im Gegensatz zur Cloud begrenzter sein kann. Die Pflege und Nutzung von Multi-Domain-Ontologien im Multi-Domain-VSR 125 kann die Erfahrung eines Benutzers in verschiedenen kontextabhängigen Umgebungen bzw. Einstellungen verbessern.
In einem anderen Beispiel kann das System 100 bestimmen, dass der Dienst 109 für den Benutzer geeignet ist. Der Dienst 109 kann aus der Cloud 105 (z.B. für Restaurant und Dienste) oder von einer straßenseitigen Einheit heruntergeladen werden. Bei den Diensten 109 kann es sich um öffentliche oder private Cloud-gehostete Anwendungen handeln, die darauf ausgelegt sind, bestimmte Dienste, wie beispielsweise Carsharing, Navigationshilfe, Musik-Streaming und dergleichen, anzubieten. Zum Beispiel kann das System 100 einen Fahrer des Fahrzeugs 101 auf der Grundlage eines Mobilgeräts, Schlüsselanhängers, biometrischer Erkennung und dergleichen identifizieren. Das System 100 kann diese Information nutzen, um eine Verifizierung vorzunehmen, ob der entsprechende Dienst angesichts des Alters, der Erfahrung als Fahrer, des Führerscheinniveaus (z.B. hat der Fahrer eine Chauffeurlizenz bzw. einen Chauffeurführerschein oder einen anderen Führerscheintyp usw.) angewandt wird. Verschiedene Attribute, die bei dem Benutzerniveau anwendbar sind, können verwendet werden, um die Angemessenheit des Dienstes für den Benutzer zu überprüfen.
In einem anderen Beispiel kann das System 100 die Verkehrssituation um das Fahrzeug 101 herum erkennen. Verkehrsinformation kann den Verkehrsfluss einer Straße oder Route gemäß Kartendaten umfassen, die sich an Bord oder außerhalb des Fahrzeugs (z. B. in der Cloud usw.) befinden können. Darüber hinaus kann die Verkehrsinformation Fahrzeugsensoren nutzen, um verschiedene Objekte (z. B. Fußgänger, Fahrzeuge usw.) zu identifizieren, die sich in der Nähe des Fahrzeugs 101 befinden können, wie durch Proximitätsdaten erfasst, die von den Sensoren gesammelt und von einem Fahrzeugprozessor berechnet werden.
In einem anderen Beispiel kann das System 100 die Umgebungsstraßeninformation um das Fahrzeug 101 herum nutzen. Die Straßeninformation kann die funktionale Straßenklasse, auf der sich das Fahrzeug befindet (z. B. Autobahn, Anliegerstraße, Hauptstraße usw.), Fahrspurlinien, Verkehrsbeschränkungen usw. umfassen. Die Stra-ßeninformation kann von fahrzeugexternen Servern (z.B. der Cloud) oder über eine bordeigene Kartendatenbank, die Straßeninformation definiert, gesammelt werden.
Das semantische Repository 107 kann Webdienste 109 enthalten, die nur für ein bestimmtes Fahrzeug verfügbar sind. Zum Beispiel können die Dienste 109 auf dem Fahrzeugtyp, der Fahrzeuglänge, dem Antriebsstrang des Fahrzeugs (z.B. Batterie versus Verbrennungsmotor versus Hybrid usw.) und anderen fahrzeugbezogenen Attributen basieren. Das System 100 kann bestimmen, ob der Dienst 109 auf das geeignete Fahrzeug zum Anwenden des Dienstes 109 ausgerichtet ist.
Ein Kontext-Repository-Verwaltungsmodul 127 kann verwendet werden, um das semantische Repository 107 und das Multi-Domain-VSR 125 zu synchronisieren. Das semantische Repository 107 und das Multi-Domain-VSR 125 können beispielsweise unterschiedliche Versionen aufweisen, die versucht werden können, in dem Fahrzeug 101 verwendet zu werden. Zum Beispiel kann das semantische Repository 107 eine aktualisierte Software-Version mit neuen Funktionen bzw Eigenschaften oder Software-Patches enthalten. Das Fahrzeug 101 kann jedoch ein Multi-Domain-VSR 125 enthalten, das eine ältere Version oder eine fehlerhafte Version verwendet. Das Kontext-Repository-Verwaltungsmodul 127 kann den aktuellen Standort des Fahrzeugs, den Zeitpunkt, die Softwareversion, die kontextbezogene Umgebung des Fahrzeugs und andere Attribute nutzen, um das Multi-Domain-VSR 125 zu synchronisieren. Das Kontext-Repository-Verwaltungsmodul 127 kann ebenso sicherstellen, dass veraltete bzw. abgelaufene Einträge, die im aktuellen Kontext nicht mehr gültig sind oder über eine vordefinierte Zeitüberschreitung (z.B. zeitbasierter Schwellenwert) abgelaufen sind, entfernt werden. Ein Dienstübereinstimmungs- und -empfehlungsmodul 129 kann verwendet werden, um die Kompatibilität des Webdienstes 109 mit dem Fahrzeug 101 zu bestimmen. Das Dienstübereinstimmungs- und -empfehlungsmodul 129 kann eine Benutzerabfrage verwenden, um die angesichts des Benutzerkontexts am besten geeigneten Ergebnisse eines Webdienstes 109 zu erkennen. Wenn beispielsweise ein Fahrzeug auf einer Autobahn fährt, kann das Dienstübereinstimmungs- und -empfehlungsmodul 129 bestätigen, dass der am besten geeignete Webdienst 109, der zu verwenden ist, für das Fahren auf der Autobahn geeignet ist. Das Dienstübereinstimmungs- und - empfehlungsmodul 129 kann die Ergebnisse einer gültigen In-Vehicle-Abfrage parsen bzw. analysieren und sie auf der Grundlage einer Gewichtungsmethode filtern, um nur die kontextadäquaten Dienste zu priorisieren und zu erbringen.
Ein Dienstvalidierungsmodul 131 kann verwendet werden, um sicherzustellen, dass der Dienst 109 oder die Anwendung für das Fahrzeug geeignet ist. Das Dienstvalidierungsmodul 131 führt Codeanalyse und Integritätsprüfungen durch und kann den erforderlichen Code ausführen, der von einem Dienstanbieter heruntergeladen wird und zur Nutzung des Dienstes 109 in einer für das Host-Fahrzeug spezifischen Sandbox-Umgebung verwendet wird. Es ist möglich, dass ein bestimmtes Angebot eines Dienstanbieters in der Fahrzeugplattform aufgrund unterschiedlicher Faktoren wie Implementierung, Version, Sicherheit, Kontextanwendbarkeit nicht vollständig genutzt werden kann. Das Dienstvalidierungsmodul 131 kann bestätigen, dass der geeignete Dienst auf der Grundlage des Kontexts des Fahrzeugs 101 angewendet wird. Das Dienstvalidierungsmodul 131 kann überprüfen, ob ein bestimmter Dienst 109 mit den Fahrzeugspezifikationen funktioniert, um sicherzustellen, dass ein Dienst 109 für einen bestimmten Benutzer funktioniert. Beispielsweise kann das Dienstvalidierungsmodul 131 bestimmen, ob ein Fahrzeug ein Head-up-Display aufweist, wenn ein bestimmter Dienst das Head-up-Display nutzt.
Ein Dienstbereitstellungsmodul 133 kann verwendet werden, um mit einer entfernten Infrastruktureinheit zu kommunizieren und die geeigneten Anwendungen oder andere erforderliche Daten herunterzuladen. Das Dienstbereitstellungsmodul 133 kann über den Transceiver mit einem Fahrzeug in Kommunikation stehen. Das Dienstbereitstellungsmodul 133 kann Information des Dienstes 109 parsen, um eine Dienstinteraktion über eine HMI oder die native Implementierung (d.h. fahrzeugspezifisch) zu erleichtern. Das Dienstbereitstellungsmodul 133 kann ebenso dazu dienen, alle Ereignisse im Zusammenhang mit einer eingebetteten Steuerung von der Anwendung auf die zugrunde liegende In-Vehicle-Plattform zu übertragen.
2 zeigt ein beispielhaftes Blockdiagramm eines Systems, wie das in 1 beschriebene, unter Verwendung eines Dienstanbieters 201. Der Dienstanbieter 201 kann sich zunächst im System 100 von 1 registrieren, indem er eine Wissenskartenstruktur-Ontologie im semantischen Repository 107 aktualisiert. In einem Beispiel kann dieser Aktualisierungsprozess RDF-Dreiergruppen (RDF für Resource Description Framework) einfügen, die die vom Dienstanbieter 201 angebotenen Dienste beschreiben. Die RDF-Dreiergruppen können dem Format <„Dienstanbieter“, „hasService bzw. has-Dienst“, „Dienst“> folgen, wobei „hasService“ eine Beziehung zwischen den Konzepten „Dienstanbieter“ und „Dienst“ beschreibt, die bereits in der Ontologie im semantischen Repository 107 definiert sind. Die RDF-Dreiergruppen, die die vom Dienstanbieter 201 angebotenen Dienste (z.B. Parken) beschreiben, werden anhand der „islnstanceOf“-Beziehung zwischen Dienst 203 und Parkdienst 209 erfasst. Der semantische Abfragemechanismus kann sich auf solche definierten Beziehungen zwischen den Konzepten und ihren Instanzen im semantischen Repository 107 oder Multi-Domain-VSR 125 stützen.
Der Dienstanbieter 201 kann verschiedene Dienste aus einer Vielzahl von POls, wie beispielsweise ein Parkplatz, ein Restaurant, eine Bank und dergleichen, enthalten. Das System kann einen Dienst 203 für das zu nutzende Fahrzeug identifizieren. Der Dienst 203 kann beispielsweise eine Spureinfädelungsunterstützungsfunktionalität 205 enthalten. Die Spureinfädelungsunterstützungsfunktionalität 205 kann mit verschiedenen Systemen des Fahrzeugs zusammenarbeiten, um bei der Spureinfädelung an einem bestimmten Ort zu unterstützen. In einem anderen Beispiel kann das semantische Repository 107 einen Anomalieerfassungsdienst 207 enthalten. Der Anomalieerfassungsdienst 207 kann eingesetzt werden, um Gegenstände, Ereignisse oder Beobachtungen zu erfassen, die bei einem Fahrzeugsystem Verdacht erregen. Zum Beispiel kann der Anomalieerfassungsdienst 207 verwendet werden, um Szenarien mit hohem Verkehrsaufkommen auf der Grundlage eines Ereignisses zu identifizieren (wie beispielsweise ein Konzert, das in einem örtlichen Stadion stattfand und den Verkehr auf nahegelegenen Straßen hervorruft, oder eine andere Situation). Der Dienst 203 kann ebenso den Parkdienst 209 enthalten, der den Benutzer in einer Parksituation unterstützen kann, die durch den Kontext-Analysator 119 identifiziert wird. In einem solchen Beispiel kann der Dienstanbieter 201 ein Parkplatz sein, der eine entfernte Infrastruktureinheit enthält, die für die Kommunikation mit dem Fahrzeug konfiguriert ist. In einem anderen Beispiel kann der Dienst 203 einen Ampelstatus 211 enthalten. In einem weiteren Beispiel kann das System einen Restaurant-Dienst 213 enthalten. Der Restaurant-Dienst 213 kann genutzt werden, um Reservierungen vorzunehmen, Essen zu bestellen, Speisekarten und Preise anzuzeigen und andere Restaurantbestellinformation am Fahrzeug zu erhalten. Jedes Restaurant kann seine eigene individuelle Anwendung haben, die für das Fahrzeug verwendet wird, oder in anderen Beispielen kann eine Standardschnittstelle für das Restaurant verwendet werden. Es kann beispielsweise eine Schnittstelle für verschiedene Restaurantfranchises oder Betriebe verwendet werden, die eine Anwendungsprogrammschnittstelle (API für Application Programm Interface) zur Interaktion mit einem Fahrzeugsystem verwenden.
3 zeigt ein Beispiel für ein Fahrzeug 301, das das kontextbezogene semantische Repository-System 100 verwendet. In einem Anwendungsfall kann das semantische Bewusstsein des Fahrzeugs 301 es einem Fahrzeug ermöglichen, nahegelegene Dienste zu identifizieren, wenn es an einer Ampel 303 angehalten wird, was ein Beispiel für eine entfernte Infrastruktureinheit 103 ist. In einem Beispiel kann die Ampel 303 mit einem Transceiver zur Kommunikation mit dem Fahrzeug ausgerüstet sein. Die Ampel 303 kann Ampelinformation/-daten über den Transceiver an das Fahrzeug übermitteln. Das Fahrzeug 301 kann solche Daten nutzen, um den aktuellen Ampelstatus, einen Signalzeitgeber oder andere Verkehrsinformation im Fahrzeug im Ansprechen auf die Nutzung der Ampelanwendung (die von der Ampel heruntergeladen werden oder bereits im Fahrzeug vorhanden sein kann) anzuzeigen. In einem anderen Beispiel kann ein Start/Stopp-System des Fahrzeugs die von der Ampel 303 empfangenen Daten nutzen, um zu erkennen, wann der Motor eines Fahrzeugs eingeschaltet werden sollte, wenn der Motor an der Ampel 303 im Leerlauf ist.
In einem anderen Beispiel kann das Fahrzeug 301 in der Lage sein, mit einer Spureinfädelungsunterstützungseinheit 307 zu kommunizieren. Die Spureinfädelungsunterstützungseinheit 307 kann sich in der Nähe einer Auffahrt befinden, die es einem Fahrzeug ermöglicht, sich in den fließenden Verkehr der Autobahn einzufädeln. Der Spureinfädelungsunterstützungseinheit 307 kann dem Fahrzeug Geschwindigkeitsbegrenzungsinformation, Straßenklasseninformation und andere kontextbezogene Information anbieten. Die Anwendung kann eine Geschwindigkeitswarnung oder ein automatisches Geschwindigkeitsmanöver des Fahrzeugs auf der Auffahrt zur Autobahn anbieten.
In einem weiteren Beispiel kann das Fahrzeug 301 in der Lage sein, mit einem Parkplatzanbieter 305 zu kommunizieren. Der Parkplatzanbieter 305 kann mit einem Transceiver ausgestattet sein, der Parkinformation über den Transceiver an das Fahrzeug 301 übermittelt. Solche Parkinformation kann Information über Betriebszeiten, aktuelle Verfügbarkeit, Preise usw. enthalten. Eine Anwendung kann mit dem Parkplatzanbieter 305 verknüpft sein, um Reservierungen und andere mit dem Parkplatzanbieter 305 verbundene Funktionen zu ermöglichen. Die Parkplatzanbieter-Anwendung kann an das Fahrzeug 301 gesendet werden, um auf einer Fahrzeugschnittstelle angezeigt zu werden.
4 zeigt ein Ablaufdiagramm 400, das in einem Fahrzeug implementiert ist, um einen semantischen Dienst zu identifizieren und zu laden. Das Fahrzeug kann in Schritt 401 Umgebungsdaten sammeln und Fahrzeug-Ontologien aktualisieren. Die Umgebungsdaten können zum Bestimmen einer kontextbezogenen Umgebung des Fahrzeugs verwendet werden, um Fahrsituationen oder bevorstehende Szenarien zu verstehen. Beispielsweise können Daten, die von verschiedenen Sensoren und anderen Eingaben gesammelt werden, gesammelt und aggregiert werden, um den Fahrzeugkontext zu bestimmen. In einem Beispiel kann das Fahrzeug Geschwindigkeitssensordaten und Kartendaten nutzen, um zu erkennen, dass sich das Fahrzeug schnell auf einer Autobahn bewegt. Das System kann Cloud-Computing oder Fog-Computing (z. B. Nutzung von Edge- bzw. Rand-Vorrichtungen zur Datenverarbeitung, Speicherung usw.) nutzen, um die geeigneten Ontologien für die Aktualisierung zu identifizieren.
In Schritt 403 kann das System den Kontext und die Absicht des Benutzers verarbeiten, um den geeigneten Dienst zu identifizieren. Das System kann nach der Analyse der Kontextdaten und der Benutzerabsicht entscheiden, ob dem Benutzer ein Dienst zur Verfügung gestellt werden soll. Das System kann die Umgebungsinformation des Fahrzeugs nutzen (z.B. basierend auf den gesammelten Daten von Sensoren und anderer Fahrzeug-Hardware), um festzustellen, ob ein geeigneter Dienst am Fahrzeug anwendbar ist. Zum Beispiel können GPS-Daten und Daten, die von einem FahrzeugGeschwindigkeitssensor gesammelt werden, den Bedarf für einen autobahnbezogenen Dienst identifizieren. Der Dienst kann von einer entfernten Infrastruktureinheit oder einem anderen Hilfsstandort heruntergeladen werden, oder der Dienst kann bereits im Fahrzeug verfügbar sein.
Bei der Entscheidung in Schritt 405 kann das System feststellen, ob die Implementierung des erforderlichen Dienstes im Fahrzeug verfügbar ist. Das Fahrzeug kann bestimmen, ob ein semantisches Multi-Domain-Repository einen geeigneten Dienst angesichts des Kontexts des Fahrzeugs enthält. Das Fahrzeug kann feststellen, ob der entsprechende Dienst verfügbar ist, indem es zuerst das Fahrzeug und dann das cloudbasierte semantische Repository betrachtet und den entsprechenden verfügbaren Dienst identifiziert. Das Fahrzeug kann bestimmen, ob der am Fahrzeug verfügbare Dienst angesichts des Kontexts der Fahrzeugumgebung sowie der verfügbaren Hardware, die am Fahrzeug genutzt werden kann, der am besten geeignete ist. Zum Beispiel kann das Fahrzeug feststellen, ob ein Sensor zum automatischen Einparken für einen zur Verfügung stehenden Einparkdienst verfügbar ist. Das Fahrzeug kann den Fahrzeug-Transceiver zum Kommunizieren mit der entfernten Infrastruktureinheit verwenden, um die Anwendung oder den Dienst herunterzuladen. In einer weiteren Ausführungsform kann das Fahrzeug einen Transceiver verwenden, um den Dienst von der Cloud oder einem entfernten Server herunterzuladen.
Wenn die Implementierung des erforderlichen Dienstes am Fahrzeug nicht verfügbar ist, kann das System den entsprechenden Dienst in Schritt 406 herunterladen. Das System kann den Dienst dann von einem entfernten Server (z.B. aus der Cloud) oder über die Smart-Infrastructure (z.B. entfernte Infrastruktureinheit) herunterladen. Das Fahrzeug kann den Fahrzeug-Transceiver zum Kommunizieren mit der entfernten Infrastruktureinheit verwenden, um die Anwendung oder den Dienst herunterzuladen. In einer weiteren Ausführungsform kann das Fahrzeug einen Transceiver (z.B. ein Mobilfunkmodem oder ein Mobiltelefon) verwenden, um den Dienst von der Cloud oder einem entfernten Server herunterzuladen. Wenn das Fahrzeug den erforderlichen Dienst bereits enthält, kann das System den Download eines neuen Dienstes oder die Implementierung des Dienstes überspringen.
In Schritt 407 kann das System den Dienst oder die Anwendung anwenden. Das System kann bestimmen, wie die HMI auf einer Anzeige oder einer anderen Schnittstelle wiedergegeben bzw. ausgegeben werden soll. Beispielsweise kann das System die verfügbaren Fahrzeugfunktionen ermitteln, mit denen ein Fahrzeug ausgestattet ist. Die Anwendung oder der Dienst kann bestimmen, welche Fahrzeug-Hardware angesichts der verfügbaren Funktionen oder des Dienstes zu verwenden ist. Wenn ein Fahrzeugdienst beispielsweise ein Head-up-Display (HUD) zum Wiedergeben von Grafiken verwendet, kann das System das HUD verwenden. Wenn ein Fahrzeug nicht über ein HUD verfügt, kann das System die HMI mit einer anderen Schnittstelle (z. B. Navigationsbildschirm oder Infotainment-Cluster) wiedergeben.
In Schritt 409 kann das System den Dienst oder die Anwendung durch Wiedergeben der HMI auf dem Fahrzeugsystem erbringen. Auf diese Weise kann die Anwendung oder der Dienst in dem entsprechenden Anwendungsfall-Szenario ausgeführt werden, eine der Anwendung entsprechende Funktion aktivieren und eine Interaktion des Dienstes oder der Anwendung sowie die Ausgabe an eine mit der Anwendung oder dem Dienst verbundene Schnittstelle ermöglichen. Beispielsweise kann im Ansprechen auf die Dienstanwendung eine Fahrerassistenzfunktion genutzt werden. In einem Beispiel kann die Anwendung bei einer Spureinfädelung an einer Autobahn helfen. So kann der Dienst Fahrfunktionen ausführen, damit ein Fahrzeug in den fließenden Verkehr einer Autobahn einfädeln kann. Der Dienst kann mit einer Fahrzeugnavigationskartendatenbank arbeiten, um Straßenkrümmungen, Fahrspurinformation, Straßenneigungsinformation und andere straßenbezogene Information zu ermitteln. Darüber hinaus kann der Dienst mit einem ADAS-System arbeiten, um das Fahrzeug zu manövrieren (z. B. das Fahrzeug zu lenken), zu beschleunigen, abzubremsen, zu bremsen oder andere Fahrfunktionen auszuführen.
Die hier dargestellten Prozesse, Methoden bzw. Verfahren oder Algorithmen können an eine Verarbeitungsvorrichtung, einen Controller oder einen Computer geliefert oder von einer Verarbeitungsvorrichtung, einem Controller oder einem Computer realisiert (implementiert) werden, die jede existierende programmierbare elektronische Steuereinheit oder dedizierte elektronische Steuereinheit umfassen können. In ähnlicher Weise können die Prozesse, Methoden oder Algorithmen als Daten und Anweisungen gespeichert werden, die von einem Controller oder Computer in vielen Formen ausführbar sind, einschließlich, aber nicht beschränkt auf Information, die dauerhaft auf nicht beschreibbaren Speichermedien wie ROM-Vorrichtungen gespeichert ist, und Information, die veränderbar auf beschreibbaren Speichermedien wie Disketten, Magnetbändern, CDs, RAM-Vorrichtungen und anderen magnetischen und optischen Medien gespeichert ist. Die Prozesse, Methoden oder Algorithmen können ebenso in einem ausführbaren Software-Objekt implementiert sein. Alternativ können die Prozesse, Methoden oder Algorithmen ganz oder teilweise durch geeignete Hardwarekomponenten verkörpert werden, wie z.B. ASICs (Application-Specific Integrated Circuits bzw. anwendungsspezifische integrierte Schaltungen), FPGAs (Field Programmable Gate Arrays bzw. programmierbare Logikgatter), Zustandsmaschinen, Controller oder andere Hardwarekomponenten oder -vorrichtungen oder eine Kombination aus Hardware-, Software- und Firmware-Komponenten. Die in der Beschreibung verwendeten Worte sind eher beschreibende als einschränkende Worte, und es wird davon ausgegangen, dass verschiedene Änderungen vorgenommen werden können, ohne vom Geist und Umfang der Offenbarung abzuweichen. Beispielsweise kann der Begriff Modul einen Prozessor, einen Controller oder jede andere Art von Logikschaltung beschreiben, die auf die von einem Computer verwendeten Befehle reagiert und diese verarbeitet. Ein Modul kann ebenso einen Speicher enthalten oder mit einem Speicher in Verbindung stehen, der Befehle ausführt. Darüber hinaus kann der Begriff Modul in Software verwendet werden, um einen Teil eines Programms (oder mehrere Programme) zu beschreiben, die über Routinen verfügen. Darüber hinaus kann eine Anwendung ein Programm oder eine Reihe von Software-Routinen sein.
Während oben beispielhafte Ausführungsformen beschrieben sind, ist es nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen beschreiben, die von den Ansprüchen umfasst sind. Die in der Beschreibung verwendeten Worte sind eher beschreibende als einschränkende Worte, und es wird davon ausgegangen, dass verschiedene Änderungen vorgenommen werden können, ohne vom Geist und Umfang der Offenbarung abzuweichen. Wie bereits beschrieben, sind die Merkmale verschiedener Ausführungsformen kombinierbar, um weitere Ausführungsformen der Erfindung zu bilden, die möglicherweise nicht explizit beschrieben oder illustriert sind. Während verschiedene Ausführungsformen hinsichtlich eines oder mehrerer gewünschter Merkmale als vorteilhaft oder bevorzugt gegenüber anderen Ausführungsformen oder Implementierungen im Stand der Technik hätten beschrieben sein können, wird dem Fachmann ersichtlich sein, dass ein oder mehrere Merkmale oder Eigenschaften kompromittiert werden können, um gewünschte Gesamtsystemattribute zu erreichen, die von der spezifischen Anwendung und Implementierung abhängen. Diese Attribute können unter anderem Kosten, Festigkeit, Haltbarkeit, Lebenszykluskosten, Marktfähigkeit, Aussehen, Verpackung, Größe, Gebrauchstauglichkeit, Gewicht, Herstellbarkeit, Montagefreundlichkeit usw. umfassen, sind aber nicht darauf beschränkt. In dem Maße, in dem Ausführungsformen in Bezug auf ein oder mehrere Merkmale als weniger wünschenswert als andere Ausführungsformen oder herkömmliche Realisierungen beschrieben sind, liegen diese Ausführungsformen nicht außerhalb des Umfangs der Offenbarung und können für bestimmte Anwendungen wünschenswert sein.

Claims

Fahrzeug-Computersystem in einem Fahrzeug (101), aufweisend: - einen Sensor, der sich im Fahrzeug befindet und konfiguriert ist, um eine Umgebung in der Nähe des Fahrzeugs zu überwachen, wobei der Sensor ferner konfiguriert ist, um ein oder mehrere Objekte außerhalb des Fahrzeugs zu erfassen; - einen Fahrzeug-Transceiver, der sich im Fahrzeug befindet und konfiguriert ist, um Daten, die auf eine oder mehrere Dienstanwendungen hinweisen, von einer entfernten Infrastruktureinheit (103) zu empfangen; - einen Prozessor, der mit dem Sensor und dem Fahrzeug-Transceiver in Verbindung steht und programmiert ist, um im Ansprechen auf die Umgebung des Fahrzeugs eine Benachrichtigung auszugeben, die die eine oder die mehreren Dienstanwendungen von der entfernten Infrastruktureinheit identifiziert; und - eine Anzeige, die mit dem Prozessor in Verbindung steht und konfiguriert ist, um grafische Bilder anzuzeigen.
Fahrzeug-Computersystem nach Anspruch 1, wobei der Prozessor ferner programmiert ist, um mit der Anzeige in Verbindung zu stehen und eine graphische Benutzerschnittstelle auszugeben, die mit der einen oder den mehreren Dienstanwendungen von der entfernten Infrastruktureinheit verknüpft ist.
Fahrzeug-Computersystem nach Anspruch 1, wobei die eine oder die mehreren Dienstanwendungen konfiguriert sind, um Fahrbefehle im Ansprechen auf die Umgebung des Fahrzeugs auszuführen.
Fahrzeug-Computersystem nach Anspruch 1, wobei der Fahrzeug-Transceiver konfiguriert ist, um mit mindestens einer Ampel oder einem Parkplatzanbieter zu kommunizieren.
Fahrzeug-Computersystem nach Anspruch 4, wobei der Prozessor ferner programmiert ist, um im Ansprechen auf die Auswahl einer oder mehrerer mit der Ampel verknüpfter Dienstanwendungen einen aktuellen Verkehrsstatus und Signalzeitgeberdaten auszugeben.
Fahrzeug-Computersystem nach Anspruch 4, wobei der Prozessor ferner programmiert ist, um einen Parkstatus im Ansprechen auf die Auswahl einer oder mehrerer mit dem Parkplatzanbieter verknüpfter Dienstanwendungen auszugeben.
Fahrzeug-Computersystem nach Anspruch 1, wobei der Prozessor ferner programmiert ist, um automatisch die eine oder die mehreren Dienstanwendungen von einer entfernten Infrastruktureinheit im Ansprechen auf eine Bestimmung herunterzuladen, dass eine Version der einen oder der mehreren Dienstanwendungen, die sich im Fahrzeug befinden, mit Hardware des Fahrzeugs inkompatibel ist.
Fahrzeug-Computersystem nach Anspruch 1, wobei der Prozessor ferner programmiert ist, um die eine oder die mehreren Dienstanwendungen im Ansprechen auf eine Eingabe herunterzuladen, die im Fahrzeug von einem Benutzer des Fahrzeugs empfangen wird.
Fahrzeug-Computersystem in einem Fahrzeug (101), aufweisend: - einen oder mehrere Sensoren in dem Fahrzeug, wobei der eine oder die mehreren Sensoren konfiguriert sind, um einen Bereich in der Nähe des Fahrzeugs unter Verwendung von Proximitätsdaten zu überwachen, wobei der eine oder die mehreren Sensoren ferner konfiguriert sind, um ein oder mehrere Objekte außerhalb des Fahrzeugs zu erfassen; - einen Fahrzeug-Transceiver, der sich im Fahrzeug befindet und konfiguriert ist, um Daten, die auf eine oder mehrere Anwendungen hinweisen, die mit einer entfernten Infrastruktureinheit (103) verknüpft sind, zu empfangen; und - einen Prozessor, der mit dem einem oder den mehreren Sensoren und dem Fahrzeug-Transceiver in Verbindung steht und programmiert ist, um: - eine Umgebung des Fahrzeugs unter Verwendung zumindest der Proximitätsdaten zu bestimmen; - eine oder mehrere Anwendungen, die mit der entfernten Infrastruktureinheit verknüpft sind, von einem entfernten Server herunterzuladen, der ein semantisches Repository einschließlich eines Resource Description Framework nutzt; und - eine Benachrichtigung, die die eine oder die mehreren Anwendungen von der entfernten Infrastruktureinheit identifiziert, im Ansprechen auf die Umgebung des Fahrzeugs auszugeben.
Fahrzeug-Computersystem nach Anspruch 9, wobei der Prozessor ferner programmiert ist, um mit einer Anzeige des Fahrzeug-Computersystems in Verbindung zu stehen und eine graphische Benutzerschnittstelle auszugeben, die mit der einen oder den mehreren Anwendungen von der entfernten Infrastruktureinheit verknüpft ist.
Fahrzeug-Computersystem nach Anspruch 9, wobei der Prozessor ferner programmiert ist, um eine fahrzeugbasierte Anwendung im Ansprechen auf die Daten auszuführen, die auf die eine oder die mehreren Anwendungen hinweisen, die mit der entfernten Infrastruktureinheit verknüpft sind.
Fahrzeug-Computersystem nach Anspruch 9, wobei der Prozessor ferner programmiert ist, um automatisch die eine oder die mehreren Anwendungen von der entfernten Infrastruktureinheit im Ansprechen auf eine Bestimmung herunterzuladen, dass eine Version der einen oder der mehreren Anwendungen, die sich im Fahrzeug befinden, eine ältere Version ist.
Fahrzeug-Computersystem nach Anspruch 9, wobei der Fahrzeug-Transceiver konfiguriert ist, um mit mindestens einer Ampel oder einem Parkplatzanbieter zu kommunizieren.
Fahrzeug-Computersystem nach Anspruch 13, wobei der Prozessor ferner programmiert ist, um mit einer Anzeige des Fahrzeug-Computersystems in Verbindung zu stehen und einen aktuellen Verkehrsstatus und Signalzeitgeberdaten im Ansprechen auf die Umgebung des Fahrzeugs auszugeben.
Fahrzeug-Computersystem nach Anspruch 13, wobei der Prozessor ferner programmiert ist, um mit einer Anzeige des Fahrzeug-Computersystems in Verbindung zu stehen und einen Parkstatus im Ansprechen auf die Umgebung des Fahrzeugs auszugeben.
Fahrzeug-Computersystem nach Anspruch 9, wobei der Prozessor ferner programmiert ist, um automatisch die eine oder die mehreren Anwendungen von der entfernten Infrastruktureinheit im Ansprechen auf die Proximitätsdaten herunterzuladen.
Fahrzeug-Computersystem nach Anspruch 9, wobei der Prozessor ferner programmiert ist, um die eine oder die mehreren Anwendungen im Ansprechen auf eine im Fahrzeug empfangene Eingabe herunterzuladen.
Fahrsystem für ein erstes Fahrzeug (101), aufweisend: - einen oder mehrere Sensoren, die konfiguriert sind, um Proximitätsdaten für ein oder mehrere Objekte in der Nähe des ersten Fahrzeugs und Umgebungsdaten des ersten Fahrzeugs zu gewinnen; - einen Fahrzeug-Transceiver, der konfiguriert ist, um mit einer entfernten Infrastruktureinheit (103) zu kommunizieren; und - einen Prozessor, der mit dem einem oder den mehreren Sensoren und dem Fahrzeug-Transceiver in Verbindung steht und programmiert ist, um: - im Ansprechen auf die Proximitätsdaten und die Umgebungsdaten eine Benachrichtigung auszugeben, die eine oder mehrere Anwendungen von der entfernten Infrastruktureinheit identifiziert, wobei die eine oder die mehreren Anwendungen konfiguriert sind, um eine Fahrunterstützungsfunktion im ersten Fahrzeug auszuführen.
Fahrsystem nach Anspruch 18, wobei der Fahrzeug-Transceiver ferner konfiguriert ist, um auf eine oder mehrere Anwendungen hinweisende Daten von der entfernten Infrastruktureinheit zu kommunizieren.
Fahrsystem nach Anspruch 19, wobei der Prozessor ferner programmiert ist, um die Fahrunterstützungsfunktion im Ansprechen auf die Daten auszuführen, die auf die eine oder die mehreren Anwendungen von der entfernten Infrastruktureinheit hinweisen.