-
TECHNISCHES GEBIET
-
Aspekte der Offenbarung betreffen im Allgemeinen ein erweitertes zentrales Gateway zur Fahrzeugvernetzung.
-
ALLGEMEINER STAND DER TECHNIK
-
Fahrzeugkomponenten senden und empfangen Daten über Fahrzeugbusprotokolle, wie etwa ein Controller Area Network (CAN). Die Fahrzeugkomponenten sind ausgebildet, um handgefertigten Datenaustausch zur Kommunikation über den CAN-Bus zu senden. CAN-Nachrichtenlisten sind effektiv statisch; ein Systembetreiber oder -implementierer ist folglich nicht in der Lage, Eingaben oder Ausgaben zu ändern, ohne Softwarekomponenten über mehrere Steuerungen zu ändern. Beschränkungen der Netzwerkbandbreite über den CAN-Bus hindern Module daran, überschüssige Daten zu veröffentlichen, was somit das Absichern von Designs für die Zukunft beschränkt. Komponenten, die eine Echtzeitsteuerung durchführen, sind üblicherweise mit einem beschränkten Raum für neue Merkmale oder Funktionen ausgebildet. Solche Systeme sind oftmals um einen einfachen Taskplaner und nicht ein speicherverwaltetes Betriebssystem konzipiert.
-
KURZDARSTELLUNG
-
In einer oder mehreren veranschaulichenden Ausführungsformen beinhaltet ein System ein zentrales Gateway eines Fahrzeugs, das einen Prozessor und einen Datenspeicher beinhaltet, mit einer Vielzahl von Fahrzeugbussen verbunden ist und programmiert ist, um Rohdaten von einer elektronischen Steuereinheit (Electronic Control Unit - ECU) über einen von den Fahrzeugbussen zu empfangen, die Rohdaten mit Verfügbarkeits-, Klassifizierungs- und Kontextinformationen zu erweitern, die Rohdaten an einem Veröffentlichungs-/Abonnementthema zu veröffentlichen, das an dem Datenspeicher gehostet wird, und das Thema für zumindest eine zweite ECU des Fahrzeugs zu abonnieren.
-
In einer oder mehreren veranschaulichenden Ausführungsformen beinhaltet ein Verfahren Zugreifen auf eine Datenbank des zentralen Gateways gemäß einem bestimmten Typ von Rohdaten, die durch ein zentrales Gateway eines Fahrzeugs von einer elektronischen Steuereinheit (Electronic Control Unit - ECU') über einen Fahrzeugbus empfangen wurden, um die Rohdaten mit Verfügbarkeits-, Klassifizierungs- und Kontextinformationen zu erweitern; und Bereitstellen der erweiterten Daten an einem Veröffentlichungs-/Abonnementthema, das durch das Gateway für den Zugriff über ein Kommunikationsnetzwerk durch einen zu dem Fahrzeug externen Dienst gehostet wird.
-
In einer oder mehreren veranschaulichenden Ausführungsformen umfasst ein nichtflüchtiges computerlesbares Medium Anweisungen, die bei Ausführung durch einen Prozessor eines zentralen Gateways eines Fahrzeugs, das mit einem oder mehreren Fahrzeugbussen verbunden ist, den Prozessor zu Folgendem veranlassen: Identifizieren von Rohdaten von einer elektronischen Steuereinheit, die mit einem von den Fahrzeugbussen verbunden ist, als Reaktion auf Überwachen der einen oder mehreren Fahrzeugbusse bezüglich Datenströmen; Bestimmen eines Datentyps der Rohdaten; Zugreifen auf eine Datenbank des zentralen Gateways, um Verfügbarkeits-, Klassifizierungs- und Kontextinformationen zu identifizieren, mit denen die Rohdaten erweitert werden können; Erweitern der Rohdaten unter Verwendung der Verfügbarkeits-, Klassifizierungs- und Kontextinformationen, um Themeninformationen zu erzeugen; und Veröffentlichen der Themeninformationen an einem Veröffentlichungs-/Abonnementthema, das durch das zentrale Gateway gehostet wird.
-
Figurenliste
-
- 1A veranschaulicht ein Beispielsystem, das eine Informationsarchitektur eines erweiterten zentralen Gateways (Enhanced Central Gateway - ECG) für ein Fahrzeug beinhaltet;
- 1B veranschaulicht ein alternatives Beispielsystem, das eine ECG-Informationsarchitektur für ein Fahrzeug beinhaltet;
- 2 veranschaulicht ein Beispieldiagramm einer Konnektivität einer elektronischen Zielsteuereinheit (target Electronic Control Unit - Ziel-ECU) mit einem Kommunikationsnetzwerk;
- 3 veranschaulicht ein Beispieldiagramm einer Konnektivität der Ziel-ECU mit dem Kommunikationsnetzwerk unter Verwendung eines Kommunikationsdienstes, um den zugrundeliegenden Kommunikationskanal, der durch die Ziel-ECU verwendet wird, ins Unkenntliche zu abstrahieren;
- 4 veranschaulicht ein Beispieldiagramm einer dienstorientierten Architektur für Fahrzeuginformationen;
- 5 veranschaulicht ein Beispieldiagramm einer dienstorientierten Netzwerkarchitektur für Fahrzeuginformationen;
- 6 veranschaulicht einen Beispielprozess zum Umwandeln von Rohdaten von einer Fahrzeug-ECU in Informationen zur Offenlegung über ein Thema;
- 7 veranschaulicht ein Beispieldiagramm einer Beispielumwandlung von Rohdaten in Information zur Offenlegung über ein Thema; und
- 8 veranschaulicht ein Beispieldiagramm einer beispielhaften dynamischen Mensch-Maschine-Schnittstelle (Human-Machine Interface - HMI) unter Verwendung der Dienste des ECG.
-
DETAILLIERTE BESCHREIBUNG
-
Je nach Bedarf werden hierin detaillierte Ausführungsformen der vorliegenden Erfindung offenbart; dabei versteht es sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen ausgeführt sein kann. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Daher sind hierin offenbarte konkrete strukturelle und funktionelle Einzelheiten nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann die vielseitige Verwendung der vorliegenden Erfindung zu lehren.
-
Moderne Unterhaltungselektronikschnittstellen sind um komplexe Datenströme konzipiert, in denen Daten in Behältern gesendet werden, die Kontext und Reaktionsverfahren für die enthaltenen Daten bereitstellen. Aufgrund dessen arbeiten Unterhaltungselektronikvorrichtungen auf höherer Abstraktionsebene und können schneller und auf unabhängigere und auf den Massenmarkt angepasstere Weise entwickelt werden. Für Fahrzeugsysteme werden jedoch üblicherweise Schnittstellen auf niedrigerer Ebene verwendet, was eine Koordination zwischen Implementierern verschiedener Komponenten erforderlich macht, wodurch die Entwicklung von vernetzten Systemen im Fahrzeug verlangsamt wird.
-
In einem verbesserten Fahrzeugnetzwerk kann eine elektrische Architektur des Fahrzeugs in mehrere Domänen aufgeteilt sein, von denen jede auf ihrer eigenen Daten- und Informationsebene arbeitet. Ein zentrales Netzwerk-Gateway (hierin als ein erweitertes zentrales Gateway oder ECG (Enhanced Central Gateway) bezeichnet) ist mit allen öffentlichen Fahrzeugnetzwerken verbunden und wandelt Rohdaten, die das Gateway durchqueren, in komplexe Informationen um. Durch Verwenden des ECG können die Fahrzeugkomponenten in jeder Domäne entwickelt und betätigt werden, ohne durch die Eigenschaften der Komponenten in anderen Domänen des Fahrzeugs eingeschränkt zu werden.
-
Das ECG kann konfiguriert sein, um eine bestehende Gateway-Funktionalität zu unterstützen, eine höhere Netzwerkgeschwindigkeit im Fahrzeug zu unterstützen, eine erweiterte Konnektivität und erweiterte Unternehmensfunktionen bereitzustellen, für Cyber-Sicherheit zu sorgen, Ad-Hoc-Universaldatenverarbeitung in dem Fahrzeug bereitzustellen, eine Informationsarchitektur anstelle einer Datenarchitektur bereitzustellen und Dienste zur Unterstützung einer dynamischen Mensch-Maschine-Schnittstelle (Human-Machine Interface - HMI) bereitzustellen. Weitere Einzelheiten zum Betrieb des ECG sind hierin im Detail erörtert.
-
1A veranschaulicht ein Beispielsystem 100-A, das eine Informationsarchitektur eines erweiterten zentralen Gateways (Enhanced Central Gateway - ECG) 110 für ein Fahrzeug 102 beinhaltet. Das erweiterte zentrale Gateway 110 ist über einen oder mehrere Fahrzeugbusse 106 mit einer Vielzahl von elektronischen Steuereinheiten (Electronic Control Units - ECUs) 104 verbunden. Das erweiterte zentrale Gateway 110 beinhaltet ferner einen oder mehrere Diagnoseanschlüsse 108. Das erweiterte zentrale Gateway 110 beinhaltet außerdem einen Prozessor 112, einen Arbeitsspeicher 114 und einen Datenspeicher 116 für Anwendungen 118 und/oder Daten 120. Obwohl in 1 ein beispielhaftes System 100 gezeigt ist, sollen die veranschaulichten beispielhaften Komponenten nicht der Einschränkung dienen. Tatsächlich kann das System 100 mehr oder weniger Komponenten aufweisen und es können zusätzliche oder alternative Komponenten und/oder Implementierungen verwendet werden.
-
Bei dem Fahrzeug 102 kann es sich um unterschiedliche Arten von Automobilen, Softroadern (Crossover Utility Vehicle - CUV), Geländewagen (Sport Utility Vehicle - SUV), Lastwagen, Wohnmobilen (Recreational Vehicle - RV), Booten, Flugzeugen oder sonstige mobile Maschinen zum Befördern von Personen oder Transportieren von Gütern handeln. In vielen Fällen kann das Fahrzeug 102 von einem Verbrennungsmotor angetrieben werden. Als eine weitere Möglichkeit kann das Fahrzeug 102 ein Hybrid-Elektrofahrzeug (Hybrid Electric Vehicle - HEV) sein, das sowohl durch einen Verbrennungsmotor als auch durch einen oder mehrere Elektromotoren angetrieben wird, wie etwa ein Serienhybrid-Elektrofahrzeug (Series Hybrid Electric Vehicle - SHEV), ein Parallelhybrid-Elektrofahrzeug (Parallel Hybrid Electric Vehicle - PHEV) oder ein Parallel/Serienhybrid-Elektrofahrzeug (Parallel/Series Hybrid Electric Vehicle - PSHEV).
-
Das Fahrzeug 102 kann eine Vielzahl von elektronische Steuereinheiten (Electronic Control Units - ECUs) 104 beinhalten, die konfiguriert sind, um verschiedene Funktion des Fahrzeugs 102, die von der Batterie und/oder dem Antriebsstrang des Fahrzeugs versorgt werden, durchzuführen und zu verwalten. Wie dargestellt, werden die beispielhaften Fahrzeug-ECUs 104 als einzelne ECUs 104-A bis 104-H dargestellt. Die Fahrzeug-ECUs 104 können jedoch eine physische Hardware, Firmware und/oder Software gemein haben, sodass die Funktionalität von mehreren ECUs 104 in eine einzige ECU 104 integriert sein kann. Oder die Funktionalität von verschiedenen solcher ECUs 104 kann über eine Vielzahl von ECUs 104 verteilt sein. Die Fahrzeug-ECUs 104 können verschiedene Komponenten des Fahrzeugs 102 beinhalten, die konfiguriert sind, um Aktualisierungen verbundener Software, Firmware oder Konfigurationseinstellungen zu empfangen.
-
Nichteinschränkende Bespiele für Fahrzeug-ECUs 104 sind Folgende: ein Antriebsstrangsteuermodul (Powertrain Control Module - PCM) 104-A, das konfiguriert sein kann, um Motor- und Getriebekomponenten zu steuern; eine Steuerung eines Antiblockierbremssystems (ABS-Steuerung) 104-B, die konfiguriert ist, um Brems- und Antriebsschlupfregelungskomponenten zu steuern; eine Steuerung einer elektrisch unterstützten Lenkung (Electronic Power-Assisted Steering - EPAS) 104-C, die konfiguriert ist, um Steuerunterstützung und Zuganpassungs- oder Driftkompensationsfunktionen zu steuern; fortschrittliche Fahrerassistenzsysteme (FAS) 104-D, wie etwa adaptive Geschwindigkeitsregelung oder automatisches Bremsen; und ein Scheinwerfersteuermodul (Headlamp Control Module - HCM) 104-E, das konfiguriert ist, um Licht-Ein-/Aus-Einstellungen zu steuern. Die ECUs 104 können außerdem Folgendes beinhalten: andere Komponenten des Antriebsstrangs 104-F oder der Karosserie 104-D, ein Infotainment-System 104-H, das konfiguriert ist, um Sprachbefehle und BLUETOOTH-Schnittstellen mit dem Fahrer und Fahrermobilvorrichtungen zu unterstützen (z. B. das SYNC-System, das durch die Ford Motor Company in Dearborn, Michigan, USA, bereitgestellt wird), eine Konnektivitätssteuerung 104-I, wie etwa eine Telematiksteuereinheit (Telematics Control Unit - TCU), die konfiguriert ist, um ein eingebettetes Modem zu nutzen, um auf vernetzte Vorrichtungen zuzugreifen, die extern zu dem Fahrzeug 102 sind, elektromechanische Karosseriesteuerungen 104-J, wie etwa Fenster- oder Verriegelungsaktoren, und Komponenten der Anhängersteuerung 104-K, wie etwa Lichtsteuerung und Sensordaten, um die verbundenen Anhänger zu unterstützen.
-
Der Fahrzeugbus 106 kann verschiedene verfügbare Verfahren zur Kommunikation zwischen den Fahrzeug-ECUs 104 beinhalten. Der Fahrzeugbus 106 kann außerdem die Kommunikation zwischen dem ECG 110 und den Fahrzeug-ECUs 104 unterstützen. Als einige nicht einschränkende Beispiele kann der Fahrzeugbus 106 ein Controller Area Network (CAN) des Fahrzeugs, ein Ethernet-Netzwerk oder ein Media-Oriented-System-Transport(MOST)-Netzwerk sein. Das CAN-Netzwerk oder die CAN-Netzwerke können von verschiedener Art sein, darunter unter anderem Highspeed-CAN (HS-CAN), das eine Datenkapazität von bis zu 500 Kbit/s aufweist, Midspeed-CAN (MS-CAN), das eine Datenkapazität von bis zu 125 Kbit/s aufweist, und/oder CAN mit flexibler Datenrate (FD-CAN), das eine Datenkapazität von bis zu 2.000 Kbit/s oder mehr aufweist. Es ist anzumerken, dass es sich bei der veranschaulichten Bustopologie lediglich um ein Beispiel handelt und eine andere Anzahl und andere Anordnungen von Fahrzeugbussen 106 verwendet werden können.
-
Das Fahrzeug 102 kann ferner Diagnoseanschlüsse 108 beinhalten, die durch externe Vorrichtungen verwendet werden können, um den Zustand des Fahrzeugs 102 zu überwachen. In einem Beispiel kann der Diagnoseanschluss 108 ein bordeigener Diagnoseanschluss (On-Board Diagnostics port - OBD-Anschluss) sein, der mit dem Fahrzeugbus 106 verbunden ist. Ein Benutzer kann ein Dongle, eine Codelesevorrichtung oder andere Scanvorrichtung mit dem Diagnoseanschluss 108 verbinden und kann die durch den Diagnoseanschluss 108 bereitgestellte Verbindung verwenden, um sich Zugriff auf Nachrichten zu verschaffen, die den Fahrzeugbus 106 durchqueren. Sobald die Scanvorrichtung verbunden ist, kann ein Benutzer diese verbundene Vorrichtung nutzen, um Diagnosecodes zu erfassen, die Fahrzeuggesundheit zu überwachen oder in manchen Fällen Fahrzeugeinstellungen anzupassen. Ähnlich wie die Geschwindigkeit des HS-CAN können die CAN-Diagnoseanschlüsse 108 eine Datenkapazität von bis zu 500 Kbit/s unterstützen. In einem weiteren Beispiel kann der Diagnoseanschluss 108 ein Diagnostic-over-Internet-Protocol(DoIP)-Anschluss 124 sein und kann Zugriff auf Nachrichten bereitstellen, die den Fahrzeugbus 106 über Ethernet anstatt über den OBD-Standard durchqueren. Ein DoIP-Anschluss 124 kann eine höhere Datenrate unterstützen als das CAN, da Ethernet unter Verwendung einer TCP/IP-Nutzlast von 64 Byte Datenraten von etwa 45 Mbit/s unterstützen kann und Nutzlasten von 1.460 Byte Datenraten von etwa 95 Mbit/s unterstützen können.
-
Das ECG 110 kann konfiguriert sein, um eine elektrische Schnittstelle zwischen den Fahrzeugbussen 106 bereitzustellen, die verwendet wird, um innerhalb des Fahrzeugs 102 zu kommunizieren. In einem Beispiel kann das ECG 110 konfiguriert sein, um Signale und Befehle zwischen dem CAN und/oder den Ethernet-Fahrzeugbussen 106 im Fahrzeug, die mit dem ECG 110 verbunden sind, zu übersetzen. Zum Beispiel kann das ECG 110 eine Verbindung von bis zu zehn CAN-Fahrzeugbussen 206 und bis zu sieben Ethernet-Fahrzeugbussen 106 unterstützen. Durch Unterstützten von Ethernet zusätzlich zu dem CAN kann das ECG 110 in der Lage sein, eine Unterstützung von Netzwerkkommunikation im Fahrzeug mit höherer Geschwindigkeit bereitzustellen, während weiterhin bestehende Gateway-Funktionen oder Vorgänger-Gateway-Funktionen in dem Fahrzeug 102 durchgeführt werden.
-
Als ein spezifisches Beispiel kann das ECG 110 mit Folgendem verbunden sein: über einen HS-CAN-Fahrzeugbus 106 mit den Komponenten des Antriebsstrangs 104-F; über einen zweiten HS-CAN-Fahrzeugbus 106 mit den Karosseriekomponenten 104-G, Sicherheitssystemen und einem Cluster; über einen dritten HS-CAN Fahrzeugbus 106 mit dem Infotainment-System 104-G; über einen vierten HS-CAN-Fahrzeugbus 106 mit dem Konnektivitätssystem 104-I und Ethernet-Sicherheitsbackupsystem; über einen ersten MS-CAN-Bus mit den elektromechanischen Karosseriesteuerungen 104-J; über einen zweiten MS-CAN-Fahrzeugbus 106 mit der Anhängersteuerung 104-K und/oder Netzknoten, auf die leicht von außerhalb des Fahrzeugs 102 zugegriffen werden kann; über eine erste und zweite Verbindung eines Diagnosedaten-Fahrzeugdatenbusses 106 mit einem Diagnoseanschluss 108; über einen ersten FD-CAN-Fahrzeugbus 106 mit dem PCM 104-A, ABS 104-B, EPAS 104-C und anderen Steuerungen; und über einen zweiten FD-CAN-Fahrzeugbus 106 mit dem ADAS 104-D, HCM 104-E und anderen Steuerungen.
-
Das ECG 110 kann ferner konfiguriert sein, um eine Ad-Hoc-Datenverarbeitungsfunktion oder andere Datenverarbeitungsfunktionalität zur Unterstützung des Betriebs des Fahrzeugs 102 bereitzustellen. Zum Beispiel kann das ECG 110 eine oder mehrere Prozessoren 112 beinhalten, die konfiguriert sind, um Anweisungen, Befehle und andere Abläufe durchzuführen, um die hierin beschriebenen Prozesse zu unterstützen. In einem Beispiel kann das ECG 110 konfiguriert sein, um Anweisungen von Anwendungen 118 auszuführen, die von einem Speichermedium 116 des ECG 110 auf einen Arbeitsspeicher 114 des ECG 110 geladen sind. Derartige Anwendungen 118 und weitere Daten 120 können auf nichtflüchtige Weise unter Verwendung einer Vielzahl von Arten von computerlesbaren Speichermedien 116 aufbewahrt werden. Das computerlesbare Medium 116 (auch als durch den Prozessor lesbares Medium oder Datenspeicher bezeichnet) beinhaltet ein nichtflüchtiges (z. B. materielles) Medium, das an der Bereitstellung von Anweisungen oder anderen Daten beteiligt ist, die durch den Prozessor 112 des ECG 110 gelesen werden können. Computerausführbare Anweisungen können von Computerprogrammen zusammengestellt oder interpretiert werden, die unter Verwendung einer Vielzahl von Programmiersprachen und/oder -technologien erstellt werden, zu denen unter anderem und entweder für sich oder in Kombination Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl und PL/SQL gehören. Als ein spezifisches Beispiel kann das ECG 110 zum Verarbeiten von Leistung, um verschiedene Datenverarbeitungsaufgaben zu ermöglichen, mit mindestens 128 Megabyte RAM sowie einem 2-4-Core-Prozessor 112 vorgesehen sein.
-
1B veranschaulicht ein alternatives Beispielsystem 100-B, das eine Informationsarchitektur eines erweiterten zentralen Gateways (Enhanced Central Gateway-ECG) 110 für ein Fahrzeug 102 beinhaltet. Verglichen mit dem System 100-A sind die ECUs 104 in dem System 100-B unter Verwendung der Fahrzeugbusse höherer Geschwindigkeit 106 mit dem ECG 110 verbunden. Zum Beispiel sind Infotainment 104-H, Konnektivität 104-I, das Cluster 104-L, die Frontanzeige 104-M und das ADAS 104-D jeweils über getrennte 2-Draht-Ethernet-Busse 106 mit 100 Mbit/s mit dem ECG 110 verbunden. (In weiteren Beispiel kann die Frontanzeige 104-M in das Cluster 104-L integriert sein.) In Bezug auf die Diagnose kann das ECG 110 über einen 4-Draht-Ethernet-Fahrzeugbus 106 mit 100 Mbit/s mit einem ODB-II-Diagnoseanschluss 122 und außerdem über einen zweiten 4-Draht-Ethernet-Fahrzeugbus 106 mit 100 Mbit/s mit einem DoIP-Diagnoseanschluss 124 (wie etwa einer Ethernetbuchse) verbunden sein.
-
Unabhängig von der Architektur kann das ECG 110 seine Datenverarbeitungsfunktionalität nutzen, um verteilte Datenverarbeitungsmerkmale und/oder Unternehmensfunktionen umzusetzen, die üblicherweise nicht in einem spezifischen ECU 104 des Fahrzeug 102 vorkommen (z. B. MyKey-Schnittstellen für erweiterte Einstellungen, erweiterter Arbeitsspeicher über die Eigenschaften der ECUs 104 hinaus, Leistungsmodusverwaltung über mehrere ECUs 104 usw.). Diese und weitere Funktionen können an dem ECU 110 umgesetzt werden, da das ECG 110 verbunden ist, um Netzwerkverkehr an den Fahrzeugbussen 106 zu empfangen, zu überwachen und hierauf zu reagieren. Des Weiteren kann das ECG 110 außerdem unter Verwendung von CARMON, PARSED, einer Funktionalität ähnlich der eines mit einem OBD-II-Anschluss 122 verbunden Servicetools und/oder von Diagnosebefehlen Informationen, die üblicherweise nicht an den Fahrzeugbussen 106 verfügbar sind, zur Verwendung in neuen Merkmalen offenlegen.
-
Dementsprechend können die verteilten Merkmale unter Verwendung des ECG 110 gemäß den Informationen konzipiert sein, die das ECG 110 aufgrund seiner Lage in der Infrastruktur des Fahrzeugbusses 106 des Fahrzeugs 102 kennt. Somit können verschiedene Merkmale in dem Fahrzeug 102 unter Verwendung von ECG 110 konzipiert sein, ohne Änderungen in den eigentlichen ECUs 104 zu erzwingen, die mit den Fahrzeugbussen 106 verbunden sind.
-
In einem Beispiel kann das ECG 110 eine Anwendung 118 beinhalten, die eine Skriptsprache unterstützt, um Änderungen der Datenverarbeitungsaufgaben des ECG 110 auf Anfrage zu ermöglichen. Als einige nicht einschränkende Beispiele kann die verwendete Skriptsprache Lue, Python oder JavaScript sein. Diese Skripts können in dem ECG 110 als Daten 120 aufbewahrt werden. Somit können Skripts hinzugefügt, modifiziert und/oder aus dem ECG 110 gelöscht werden, ohne dass ein erneutes Flashen der Firmware des ECG 110 erforderlich ist. 2 veranschaulicht ein Beispieldiagramm 200 einer Konnektivität einer Ziel-ECU 104 mit einem Kommunikationsnetzwerk 202. Wie gezeugt, kann das ECG 110 über verschiedene Kommunikationskanäle mit dem Kommunikationsnetzwerk 202 verbunden sein. Zu diesen kann gehören: durch eine mobile Vorrichtung, die mit dem Infotainment-System 104-H gekoppelt und verbunden ist, und/oder über ein eingebettetes Modem der Konnektivitätskomponenten 104-I. Es ist anzumerken, dass dies lediglich Beispiele sind und andere Konnektivitätsquellen des Fahrzeugs 102 in anderen Beispielen verfügbar sein können. Autonome Fahrzeuge können zum Beispiel einen weiteren Kommunikationskanal für Daten und Befehle des autonomen Fahrzeugs 102 beinhalten.
-
3 veranschaulicht ein Beispieldiagramm 300 einer Konnektivität der Ziel-ECU 104 mit dem Kommunikationsnetzwerk 202 unter Verwendung eines Kommunikationsmanagers 204, um den zugrundeliegenden Kommunikationskanal, der durch die Ziel-ECU 104 verwendet wird, ins Unkenntliche zu abstrahieren. In einem Beispiel kann der Kommunikationsmanager 204 eine Anwendung 118 sein, die in den Datenspeicher 116 des ECG 110 installiert ist. Der Kommunikationsmanager 204 kann eine einheitliche bidirektionale Schnittstelle zwischen dem Kommunikationsnetzwerk 202 und dem Fahrzeug 102 offenlegen, wodurch ermöglicht wird, dass die Ziel-ECU 104 den Kommunikationsmanager 204 unabhängig von dem verwendeten zugrundeliegenden Kommunikationskanal für Kommunikationsdienste nutzen kann.
-
4 veranschaulicht ein Beispieldiagramm 400 einer dienstorientierten Architektur für Fahrzeuginformationen. In einem Beispiel kann das ECG 110 eine Datenschnittstellenanwendung 118 beinhalten, die in den Datenspeicher des ECG 110 installiert ist. Unter Verwendung der Datenschnittstellenanwendung 118 können Daten in Informationen umgewandelt und dann Benutzern der Datenschnittstellenanwendung 118 zur Verfügung gestellt werden. Zu diesen Benutzern können zum Beispiel andere ECUs 104 des Fahrzeugs 102, Anwendungen 118, die durch das ECG 110 ausgeführt werden, oder Skripts einschließen, die in dem ECG 110 gespeichert sind und durch eine Skriptmodulanwendung 118 des ECG 110 ausgeführt werden. Die Datenkonsumenten können dann unter Verwendung der Datenschnittstellenanwendung 118 entscheiden, an welchen Informationen sie interessiert sind. Die Systeme, die auf die Informationsströme zugreifen, können hierin als fortschrittliche Systeme bezeichnet werden, während Systeme, welche die Rohdaten bereitstellen, hierin als grundlegende Systeme bezeichnet werden.
-
Die Datenschnittstellenanwendung 118 kann ein Veröffentlichungs-/Abonnementdatenmodell unterstützen. Das Veröffentlichungs-/Abonnementmodell kann Themen 402 nutzen, die auch als logische Kanäle bekannt sind und durch welche Veröffentlicher 404 Nachrichten senden können und Abonnenten 406 Nachrichten empfangen können. In einigen Beispielen kann eine Themen-Baumstruktur durch die Datenschnittstellenanwendung 118 genutzt werden, um eine Struktur der Themen und Unterthemen zu definieren, die beim Senden und Empfangen der Nachrichten verwendet werden.
-
In dem veranschaulichten Beispiel ist das ECG 110 ein Veröffentlicher 404 eines Themas 402, in diesem Beispiel über Geschwindigkeitsinformationen des Fahrzeugs 102. Außerdem sind drei Abonnenten 406 des Themas 402 vorhanden, bei denen es sich um eine Anzeige (z. B. die Frontanzeige 104-M), das Cluster 104-L und eine TCU handelt, die als die Konnektivitätssteuerung 104-I verwendet wird. Durch Verwenden des Veröffentlichungs-/Abonnementmodells können die Abonnenten 406 die Geschwindigkeitsinformationen des Fahrzeugs 102 abrufen, ohne die Fahrzeugbusse 106 bezüglich der Geschwindigkeitsrohdaten überwachen zu müssen.
-
5 veranschaulicht ein Beispieldiagramm 500 einer dienstorientierten Netzwerkarchitektur für Fahrzeuginformationen. Wie gezeugt, empfängt das ECG 110 Daten 502 von den Komponenten des Antriebsstrangs 104-F und Daten 504 von den Komponenten der Karosserie 104-G über die Fahrzeugbusse 106. Das ECG 110, das als ein Veröffentlicher 404 handelt, wandelt die Daten 502 in ein Antriebsstranginformationsthema 402-A um und wandelt die Daten 504 in ein Karosserieinformationsthema 402-B um. (Einzelheiten zu einer Beispieldatenumwandlung sind nachfolgend unter Bezugnahme auf 6-7 beschrieben.) Sobald die Themen 402-A und 402-B veröffentlicht wurden, sind diese für Abonnenten in dem Fahrzeug 102 verfügbar, wie vorangehend erörtert. Des Weiteren können die Themen 402-A und 402-B unter Verwendung des Kommunikationsmanagers 204 außerdem von dem Fahrzeug 102 für cloudbasierte Dienste zur Verfügung gestellt werden, die konfiguriert sind, um sich mit durch das Fahrzeug 102 offengelegten Konnektivitätsdiensten zu verbinden.
-
In einigen Fällen können sich die verfügbaren Datenelemente in dem Fahrzeug 102 ändern. In einem Beispiel kann ein neues Karosseriesteuermerkmal 506 in dem Fahrzeug 102 zur Verfügung gestellt werden, wie etwa mithilfe einer Softwareaktualisierung an einer Karosseriesteuerung 104-J. In einem solchen Fall können neue Daten 508 an dem ECG 110 verfügbar werden.
-
Das ECG 110 kann ein grundlegendes Systemauffindbarkeitsmerkmal umsetzen. Das grundlegende Systemauffindbarkeitsmerkmal kann die Fahrzeugbusse 106 bezüglich neuer Datenströme 508 überwachen, sodass das ECG 110 erkennen kann, dass ein neues Merkmal hinzugefügt wurde, wenn ein neues grundlegendes System dem Fahrzeug 102 hinzugefügt wurde (z. B. das neue Karosseriesteuermerkmal 506), und ein neues Thema 402 hinzufügen kann, um Informationen auf Grundlage des neuen Merkmals zur Verfügung zu stellen. Wenn die Hinzufügung des neuen Themas 402, in diesem Beispiel des neuen Themas 402-C, dem neuen Karosseriesteuermerkmal 506 entspricht, kann das ECG 110 die neuen Daten 508 weiter in Informationen umwandeln und ermöglichen, dass die fortschrittlichen Systeme hiermit interagieren.
-
Das ECG 110 kann ferner ein fortschrittliches Systemauffindbarkeitsmerkmal umsetzen. Das fortschrittliche Systemauffindbarkeitsmerkmal kann ermöglichen, dass fortschrittliche Dienste die Informationsthemen 402 untersuchen, um zu bestimmen, welche Informationen verfügbar sind. In einem Beispiel kann die Datenschnittstellenanwendung 118 ein Verzeichnis unterstützen, das die verfügbaren Themen 402 beinhaltet, die durch einen verbundenen fortschrittlichen Dienst abgefragt werden können. In einigen Beispielen können die Themen 402 gemäß Informationskategorien abgefragt werden. In einem Beispiel kann das ECG 110 Abfragen der Themen 402 unterstützen, um eine Auflistung von HMI-bezogenen Informations-Feeds (z. B. Fahrzeuggeschwindigkeit, aktuelle Audioquelle, Öllebensdauer usw.) oder eine Auflistung von nicht-HMI-bezogenen Informations-Feeds (z. B. innere Fahrzeugmotorzeitgebungsmerkmale usw.) bereitzustellen.
-
Das ECG 110 kann außerdem ein stabiles Systemmerkmal umsetzen. Wenn für einen vorbestimmten Zeitraum keine neuen grundlegenden Systeme hinzugefügt oder entfernt werden und kein fortschrittliches System für Themen 402 abgefragt wird, kann das ECG 110 konfiguriert sein, um die Informationsströme zu dem Thema 402 abzukürzen, um die Systemleistung zu verbessern. Die Abkürzung kann beispielsweise Verringern der Abtastrate der Umwandlung beinhalten, die durch das ECG 110 als Veröffentlicher 404 durchgeführt wird. Somit kann das ECG 110 unter Verwendung der Konnektivitätslösungen für eine erweiterte Funktionalität Informationen von und zu lokalen und entfernten Diensten austauschen.
-
6 veranschaulicht einen Beispielprozess 600 zum Umwandeln von Rohdaten von einer Fahrzeug-ECU 104 in Informationen zur Offenlegung über ein Thema 402. In einem Beispiel kann der Prozess 600 von dem ECG 110 durchgeführt werden. Der Prozess 600 beginnt mit Vorgang 602, wobei das ECG 110 Fahrzeugrohdaten empfängt. In einem Beispiel extrahiert das ECG 110 CAN-Datenbits aus einer CAN-Nachricht, die einen CN-Fahrzeugbus 106 durchquert.
-
Bei 604 fügt das ECG 110 den Rohdaten Verfügbarkeitsinformationen hinzu. In einem Beispiel kann das ECG 110 einen Typ der Rohdaten identifizieren und kann auf eine Datenbank zugreifen, um Verfügbarkeitsinformationen abzurufen, die Leistungsmodi, Fehlermodi und eine Latenz des Typs der Rohdatenart angeben. Das ECG 110 kann außerdem Informationen in Bezug darauf abrufen, ob die Daten durchgehen, periodisch oder als Reaktion auf eine Änderung des Werts der Rohdaten verfügbar sind. Das ECG 110 fügt den Rohdaten die Verfügbarkeitsinformationen hinzu.
-
Bei Vorgang 606 fügt das ECG 110 den Rohdaten Klassifizierungsinformationen hinzu. In einem Beispiel kann das ECG 110 auf eine Datenbank zugreifen, um Folgendes abzurufen: das Decodierungsverfahren für den Datentyp (z. B. um es Empfängern zu ermöglichen, die Rohdaten zu entpacken), Kriterien zum Identifizieren von Fehlern in den Daten (z. B. Fehlercodes) und Datenwertgrenzen der Rohdaten (z. B. Minimal- und Maximalwerte). Das ECG 110 fügt den Rohdaten die Klassifizierungsinformationen hinzu.
-
Bei 608 fügt das ECG 110 den Rohdaten Kontextinformationen hinzu. In einem Beispiel kann das ECG 110 auf eine Datenbank zugreifen, um Folgendes abzurufen: ob die Rohdaten eine HMI-Implikation aufweisen (z. B. aktuell angezeigt werden oder möglicherweise Daten darstellen, die angezeigt werden), Einzelheiten der HMI für den Typ der Rohdaten (z. B. Anzeigeeinheiten und -format), Zugehörigkeit der Daten zu einer Gruppe von Datenelementen (ob es sich bei dem Element z. B. um eines von einem Satz von verknüpften Elementen handelt) und Beziehung zu anderen Daten (ob z. B. andere Datenelemente vorhanden sind, die sich als Folge davon, dass sich dieses Element ändert, ändern). Das ECG 110 fügt den Rohdaten die Kontextinformationen hinzu.
-
Bei Vorgang 610 fügt das ECG 110 den Rohdaten Reaktionsinformationen hinzu. In einem Beispiel kann das ECG 110 auf eine Datenbank zugreifen, um Verfahren zur Interaktion mit dem Datensender des Datentyps abzurufen. In einem Beispiel können die Reaktionsinformationen ein Verfahren, um eine Änderung eines durch die Rohdaten angegebenen Werts anzufordern, oder Verfahren, um eine Bestätigung der Rohdaten durch einen Empfänger anzufordern, beinhalten. Das ECG 110 fügt den Rohdaten die Reaktionsinformationen hinzu.
-
Bei 612 veröffentlicht das ECG 110 die umgewandelten Rohdaten an einem Thema 402. In einem Beispiel identifiziert das ECG 110 ein Thema 402, das dem Typ der Rohdaten entspricht, und veröffentlicht die Daten in dem angegebenen Thema 402. Dementsprechend können die Rohdaten als ein Informationsstrom zur Verwendung durch fortschrittliche Systeme des Fahrzeugs 102 oder durch entfernte Cloud-Dienste in Kommunikation mit dem Fahrzeug 102 über das Netzwerk 202 zur Verfügung gestellt werden.
-
7 veranschaulicht ein Beispieldiagramm 700 einer Beispielumwandlung von Rohdaten 702 in Information zur Offenlegung über ein Thema 402. Wie gezeigt, legen die Rohdaten 702 Umdrehungen pro Minute (U/min) eines Motors des Fahrzeugs 102 offen (z. B. dass die U/min aktuell 2.300 U/min betragen). Die Rohdaten 702 können über den Fahrzeugbus 106, in einem Beispiel durch den Antriebsstrang 104-F, zur Verfügung gestellt werden. Das ECG 110 kann den Fahrzeugbus 106 überwachen und die Rohdaten 702 empfangen. Unter Verwendung eines Prozesses, wie etwa des Prozesses 600, kann das ECG 110 den Rohdaten 702 zusätzliche Informationen hinzufügen. Zum Beispiel kann das ECG 110 den Daten Eigenschaften 704 hinzufügen, wie etwa Verfügbarkeitsinformationen, die angeben, dass die Rohdaten durchgehend und quantifiziert zur Verfügung gestellt sind. Das ECG 110 kann außerdem Klassifizierungsinformationen hinzufügen, einschließlich eines Datenbereichs für die U/min (z. B. 0-8.000) und eines Interessenbereichs für die U/min (z. B. U/min von 6.000+ ist kritisch). Das ECG 110 kann den Rohdaten des Weiteren Kontextinformationen hinzufügen, wie etwa, dass die Informationen von einer niedrigen Priorität sind, wenn sie sich unter kritischen U/min befinden, jedoch von höherer Priorität, wenn sie sich auf oder über dem kritischen Wert befinden. Das ECG 110 kann des Weiteren Rücksendeanweisungsdaten hinzufügen (z. B. Angaben von Verfahren, die durch einen Empfänger der Daten verwendet werden können, um Farben oder andere Informationen zur Anzeige der U/min abzufragen). Diese erweiterten Rohdaten können dann an einem U/min-Thema 402 durch das ECG 110, das als Veröffentlicher 404 handelt, veröffentlicht werden. Fortschrittliche Systeme des Fahrzeugs 102, wie etwa Infotainment 104-H, Konnektivität 104-I, das Cluster 104-L und die Frontanzeige 104-M, können das U/min-Thema entsprechend abonnieren, um die Rohdaten 702 sowie die Eigenschaften 704 zu empfangen, um eine Anzeige, Skripting, Protokollieren oder verschiedene andere Verwendungen zu ermöglichen.
-
Es ist anzumerken, dass die an den Themen 402 veröffentlichen Informationsströme nicht nur Einwegströme, sondern auch Zweiwegeströme sein können. In einem Beispiel können die Reaktionsinformationen Informationen beinhalten, die Nachrichten angeben, die durch Abonnenten des Themas 402 veröffentlicht werden können, an dem der Informations-Feed veröffentlicht wird, (oder anderer Themen 402). Diese durch Abonnenten veröffentlichen Nachrichten können durch das ECG 110 empfangen und verwendet werden, um das ECG 110 anzuweisen, Befehle über die Fahrzeugbusse 106 zurück zu senden. Dementsprechend kann das ECG 110 eine Zweiwege-Echtzeitumwandlungsschicht bereitstellen, um zu ermöglichen, dass die fortschrittlichen Systeme/die Cloud-Seite mit den grundlegenden Diensten des Fahrzeugs 102 interagieren können/kann.
-
Zum Beispiel kann das ECG 110 eine Datenanforderung oder Software von einem Cloud-Server empfangen. Als Reaktion darauf kann das ECG 110 die Software an eine Ziel-ECU 104 senden oder die Daten von einer Ziel-ECU 104 anfordern. Die Anforderung oder Übertragung kann über eine oder mehrere Fahrzeugbusse 106 des Fahrzeugs 102 durchgeführt werden, das mit dem ECG 110 verbunden ist. Das ECG 110 kann ferner die Fahrzeugbusse 106 bezüglich einer Reaktion überwachen, wie etwa einer Empfangsbestätigung der Softwareaktualisierung durch die Ziel-ECU 104 oder einem Empfang der angeforderten Informationen von der Ziel-ECU 104. Das ECG 110 kann die empfangenen Rohdaten (wie hierin erörtert) entsprechend übersetzen und den Informationsstrom an dem Cloud-Anforderer veröffentlichen (oder als Reaktion auf diesen Strom senden).
-
8 veranschaulicht ein Beispieldiagramm 800 einer beispielhaften dynamischen HMI unter Verwendung der Dienste des ECG 110. Wie gezeigt, sind drei Benutzererlebniskomponenten (User Experience components - UX-Komponenten) 802-A, 802-B und 802-C (zusammen 802) in Kommunikation mit einer HMI-Masterkomponente 804 eingeschlossen. Die UX-Komponenten 802 können verschiedene Komponenten des Fahrzeugs 102 beinhalten, wie etwa das Cluster 104-L, die Frontanzeige 104-M oder einen Bildschirm des Infotainment-Systems 104-H. Die HMI-Masterkomponente 804 kann durch eine Anwendung 118 umgesetzt werden, die durch das ECG 110 ausgeführt wird. Die HMI-Masterkomponente 804 kann außerdem durch die Dienste der Verbindungen des ECG 110 mit den Fahrzeugbussen 106 in Kommunikation mit verschiedenen ECUs 104 des Fahrzeugs 102 stehen. Zum Beispiel kann das EGC 110 mit einem oder mehreren grundlegenden Systemen in Kommunikation stehen, wie etwa einer Steuerung einer ABS 104-B und einer Steuerung einer EPC 104-N. Das EGC 110 kann außerdem mit einem oder mehreren fortschrittlichen Systemen in Kommunikation stehen, wie etwa einem Audiosystem 104-O und einem Heizungs-, Lüftungs-, Klimatisierungs(HLK)-System 104-P.
-
Die UX-Komponenten 802 können konfiguriert sein, um ihre Schnittstellen und Eigenschaften zu identifizieren. In einem Beispiel können die UX-Komponenten 802 die HMI-Masterkomponente 804 abonnieren und können der HMI-Masterkomponente 804 in einer oder mehreren Nachrichten die Eigenschaften der UX-Komponente 802 angeben. Zum Beispiel kann die UX-Komponente 802 der HMI-Masterkomponente 804 angeben, dass die UX-Komponente 802 eine Liste mit Clusterinformationen zur Spurweite anfordert, von denen fünf Elemente an einem Zeitpunkt angezeigt werden können.
-
Die HMI-Masterkomponente 804 kann konfiguriert sein, um die Dienste des ECG 110 zu nutzen, die Rohdaten (z. B. einfache Daten) aus den grundlegenden Systemen in Informationsströme umwandeln. Die HMI-Masterkomponente 804 kann strukturierte Informationsströmungsdaten unter Verwendung der Themen 402 an die UX-Komponenten 802 leiten. Insbesondere kann dieses Leiten unabhängig von dem physischen Verkehr von den grundlegenden Systemkomponenten an den Fahrzeugbussen 106 durchgeführt werden. Wenn die UX-Komponenten 802 von dem Verkehr des Fahrzeugbusses 106 entkoppelt sind, wenn neue anzeigbare Merkmale hinzugefügt oder entfernt werden, benötigt der Rest der HMI (z. B. jede von den UX-Komponenten 802) des Weiteren keine Programmierungsaktualisierungen oder andere Anpassungen.
-
Als ein weiteres Beispiel für die Flexibilität des ECG 110 kann ein Regensensor des Fahrzeugs 102 einen Rohdatenstrom für einen Zustand der Erfassung von Regen bereitstellen und kann eine Türsteuereinheit (Door Control Unit - DCU) ein Verfahren zum Steuerung von Fahrzeugfenstern bereitstellen. Das ECG 110 kann den Rohdatenstrom des Regensensors in ein Regensensorthema 402 umwandeln und kann die Steuerung der Fenster über die DCU in ein zweites Thema 402 umwandeln. Ein Mittel, wie etwa ein als Daten 120 gespeichertes Skript, das durch eine Skriptsprachenanwendung 118 des ECG 110 ausgeführt werden soll, kann dann programmiert sein, um die Themen 402 zu nutzen, um das Ereignis von erfasstem Regen mit einem Befehl zu verbinden, die Fenster hochzukurbeln. Somit flacht das ECG 110 die CAN-Signale auf Plattformebene auf Informationsströme ab. Während der Regensensor und die DCU Signale in den CAN-Fahrzeugdatenbus 106 einbetten, müssen der Regensensor und die DCU des Weiteren nicht miteinander koordiniert werden.
-
Als eine weitere Möglichkeit kann das ECG 110 einen einzigen Steuerungspunkt für die Netzwerksicherheit des Fahrzeugs 102 bereitstellen. Somit kann das ECG 110 als eine Firewall und außerdem als ein einziger Aktualisierungsort dienen, wenn neue Gefahren ersichtlich werden. Des Weiteren kann die Verarbeitungsleistung des ECG 110 ermöglichen, dass das ECG 110 ein Netzwerkscannen, eine Viruserfassung oder andere Dienste ausführt und Gefahren auf autonome Weise bekämpfen kann.
-
Hierin beschriebene Rechenvorrichtungen, wie etwa die ECUs 104 und das ECG 110, beinhalten im Allgemeinen computerausführbare Anweisungen, von denen die Anweisungen durch eine oder mehrere Rechenvorrichtungen wie die vorstehenden aufgelisteten ausgeführt werden können. Die computerausführbaren Anweisungen können von Computerprogrammen zusammengestellt oder interpretiert werden, die unter Verwendung einer Vielzahl von Programmiersprachen und/oder -technologien erstellt wurden, darunter unter anderem, entweder einzeln oder in Kombination, Java™, C, C++, C#, Visual Basic, JavaScript, Python, JavaScript, Perl, PL/SQL usw. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen z. B. von einem Arbeitsspeicher, einem computerlesbaren Medium usw. und führt diese Anweisungen aus, wodurch er ein oder mehrere Prozesse, einschließlich eines oder mehrerer der hierin beschriebenen Prozesse, durchführt. Derartige Anweisungen und weitere Daten können unter Verwendung einer Vielzahl computerlesbarer Medien gespeichert und übertragen werden.
-
Hinsichtlich der hierin beschriebenen Prozesse, Systeme, Verfahren, Heuristiken usw. versteht es sich, dass die Schritte solcher Prozesse usw. zwar als gemäß einer bestimmten Reihenfolge erfolgend beschrieben worden sind, solche Prozesse aber mit den beschriebenen Schritten in einer Reihenfolge durchgeführt werden könnten, die von der hierin beschriebenen Reihenfolge abweicht. Es versteht sich ferner, dass bestimmte Schritte gleichzeitig ausgeführt, andere Schritte hinzugefügt oder bestimmte hierin beschriebene Schritte weggelassen werden könnten. Anders ausgedrückt dienen die vorliegenden Beschreibungen von Prozessen dem Zwecke der Veranschaulichung bestimmter Ausführungsformen und sollten keinesfalls dahingehend ausgelegt werden, dass sie die Ansprüche einschränken.
-
Dementsprechend versteht es sich, dass die vorstehende Beschreibung veranschaulichend und nicht einschränkend sein soll. Viele Ausführungsformen und Anwendungen, bei denen es sich nicht um die bereitgestellten Beispiele handelt, werden beim Lesen der vorstehenden Beschreibung ersichtlich. Der Schutzumfang der Erfindung sollte nicht unter Bezugnahme auf die vorstehende Beschreibung festgelegt werden, sondern stattdessen unter Bezugnahme auf die beigefügten Patentansprüche unter Hinzunahme des vollständigen Umfangs an Äquivalenten, zu denen solche Patentansprüche berechtigen. Es wird erwartet und beabsichtigt, dass es hinsichtlich der hierin erläuterten Technologien künftige Entwicklungen geben wird und dass die offenbarten Systeme und Verfahren in derartige künftige Ausführungsformen aufgenommen werden. Insgesamt versteht es sich, dass die Anmeldung modifiziert und variiert werden kann.
-
Allen in den Ansprüchen verwendeten Ausdrücken sollen deren umfassendste nachvollziehbare Konstruktionen und deren allgemeine Bedeutung zugeordnet werden, wie sie mit den hierin beschriebenen Technologien vertrauten Fachleuten bekannt sind, sofern hierin kein ausdrücklicher Hinweis auf das Gegenteil erfolgt. Insbesondere ist die Verwendung der Singularartikel, wie etwa „ein“, „einer“, „eine“, „der“, „die“, „das“ usw. dahingehend auszulegen, dass ein oder mehrere der aufgeführten Elemente genannt werden, es sei denn, ein Anspruch enthält eine ausdrücklich gegenteilige Einschränkung.
-
Die Zusammenfassung der Offenbarung wird bereitgestellt, um dem Leser einen schnellen Überblick über den Charakter der technischen Offenbarung zu ermöglichen. Sie wird in der Auffassung eingereicht, dass sie nicht dazu verwendet wird, den Schutzumfang oder die Bedeutung der Patentansprüche auszulegen oder einzuschränken. Des Weiteren geht aus der vorstehenden detaillierten Beschreibung hervor, dass unterschiedliche Merkmale in unterschiedlichen Ausführungsformen zum Zwecke der Vereinfachung der Offenbarung zusammengefasst sind. Dieses Offenbarungsverfahren ist nicht dahingehend auszulegen, dass es eine Absicht widerspiegelt, dass die beanspruchten Ausführungsformen mehr Merkmale als ausdrücklich in jedem Patentanspruch genannt erfordern. Vielmehr liegt der Gegenstand der Erfindung in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform, wie die folgenden Patentansprüche widerspiegeln. Somit werden die folgenden Patentansprüche hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Patentanspruch für sich als separat beanspruchter Gegenstand steht.
-
Während vorstehend beispielhafte Ausführungsformen beschrieben sind, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Die in der Beschreibung verwendeten Ausdrücke sind vielmehr beschreibende Ausdrücke als einschränkende Ausdrücke, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Geist und Umfang der Erfindung abzuweichen. Des Weiteren können die Merkmale unterschiedlicher Umsetzungsausführungsformen miteinander kombiniert werden, um weitere erfindungsgemäße Ausführungsformen zu bilden.
