-
Die vorliegende Erfindung betrifft die Verbesserung von Positionsdiensten für Fahrzeuge.
-
HINTERGRUND
-
Geräte im Globalen Satelliten-Navigationssystem (GNSS) (zu denen neben anderen auch GPS-Geräte zur globalen Positionsbestimmung gehören), unterliegen verschiedenen Arten von böswilligen Angriffen. Ein solcher Angriff ist als Man-in-the-Middle Angriff (MITM) bekannt, bei dem die böswillige Partei bzw. der Angreifer ein legitimes GNSS-Signal empfangen und ein unrechtmäßiges GNSS-Signal an das Gerät des beabsichtigten Empfängers senden kann (z. B. durch Spoofing des ursprünglichen GNSS-Signals). In anderen Angriffen kann der böswillige Angreifer ein gefälschtes GNSS-Signal erzeugen. In der einen oder anderen Form werden die Geräte des Empfängers daher mit unrechtmäßigen Signalen versorgt und gehen fälschlicherweise davon aus, es würde sich um ein authentisches Signal handeln (oder ein GNSS-Signal von einem legitimen GNSS-Satelliten). Mit diesen und ähnlichen Techniken können böswillige Angreifer unzutreffende GNSS-Signaldaten an ein oder mehreren Geräten von GNSS-Empfängern senden. Moderne GNSS-Chipsätze empfangen und verwenden die GNSS-Daten von drei oder vier verschiedenen Satelliten, um die GNSS-Position zu berechnen. Wenn eines oder mehrere dieser GNSS-Signale durch Spoofing verfälscht wurde(n), so kann der GNSS-Chipsatz des Empfängers eine falsche Position, einen falschen Kurs oder beides errechnen. In einigen Fällen kann diese Abweichung erheblich sein und den Benutzer des Geräts in eine gefährliche Situation bringen.
-
Daher sind Gegenmaßnahmen erforderlich, damit das Gerät des Empfängers während eines böswilligen Angriffes eine genaue Position und/oder Route ermitteln kann.
-
ZUSAMMENFASSUNG
-
Gemäß einer Ausführungsform der Erfindung wird ein Verfahren zur Verbesserung der Positionsdienste für einen Anwender in einem Fahrzeug bereitgestellt. Das Verfahren beinhaltet die Schritte: Empfang einer ersten Nachricht vom Fahrzeug durch ein Backend-System aufgrund der Entdeckung eines böswilligen Angriffes mit Daten aus dem Globalen Satelliten-Navigationssystem (GNSS); Empfangen von Positionsdaten des Fahrzeugs aus einem Mobilfunkanbieter-System (WCS); Bereitstellung dieser Positionsdaten für das Fahrzeug durch das Backend-System als Reaktion auf den Empfang der ersten Nachricht; Empfang einer zweiten Nachricht vom Fahrzeug, dass der böswillige Angriff nicht mehr besteht; und als Reaktion auf den Empfang der zweiten Nachricht Einstellung der Bereitstellung von Positionsdaten durch das Backend-System.
-
Gemäß einer anderen Ausführungsform der Erfindung wird ein Verfahren zur Verbesserung der Positionsdienste für einen Anwender in einem Fahrzeug bereitgestellt. Das Verfahren beinhaltet die Schritte: vom Fahrzeug wird ein Zustand erkannt, der einen böswilligen Angriff mit einem Modul des Globalen Satelliten-Navigationssystems (GNSS) darstellt; als Reaktion auf die Erkennung des Zustandes wird eine Positionsabfrage vom Fahrzeug an das Backend-System abgesetzt; als Antwort darauf gehen die Positionsdaten vom Backend-System ein; nach Erkennung, dass der Zustand nicht länger besteht und als Reaktion darauf wir eine Beendigungsanforderung an das Backend-System abgesetzt.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Eine oder mehrere Ausführungsformen der Erfindung werden im Folgenden in Verbindung mit den beigefügten Zeichnungen beschrieben, worin gleiche Bezeichnungen gleiche Elemente bezeichnen, und worin:
-
1 ein Blockdiagramm ist, das eine Ausführungsform eines Kommunikationssystems darstellt, das fähig ist, das hier offenbarte Verfahren zu verwenden;
-
2 ein schematisches Diagramm zur Darstellung eines Man-in-the-Middle Angriffs ist; und
-
3A–3B Flussdiagramme zur Darstellung eines Verfahrens zur Verbesserung der Positionsdienste für den Benutzer eines Fahrzeugs sind.
-
DETAILLIERTE BESCHREIBUNG DER VERANSCHAULICHTEN AUSFÜHRUNGSFORM(EN)
-
Das nachfolgend beschriebene Verfahren betrifft die Verbesserung von Positionsdiensten durch das Globale Satelliten-Navigationssystem (GNSS) für den Benutzer eines Fahrzeugs während eines böswilligen Angriffs (z. B. einer Hacking-Attacke auf Daten der GNSS-Signale). Momentan können böswillige Angreifer oder Hacker unzulässige oder bösartige Signale erzeugen, die GNSS-Signalen ähneln und die rechtmäßigen Signale von einem oder mehreren GNSS-Satelliten nachahmen. Dadurch können Empfänger dieser Signale unzutreffende Standortdaten erhalten. Beispielsweise können Standortdaten von einem GNSS-Satelliten jegliche geeigneten standortabhängigen Daten oder Ortsdaten enthalten (z. B. Zeitstempel, Dopplerfrequenz-Daten und dergleichen; geeignete GNSS-abhängige Ortsdaten und deren Elemente sind unter Fachleuten bekannt). Die böswilligen Angreifer können ein bösartiges Signal übertragen, bei dem eines oder mehrere der ortsbezogenen Datenelemente ungenau oder gefälscht ist/sind. Empfängt ein GNSS-Modul in einem Fahrzeug eines oder mehrere dieser falschen Datenelemente, so werden diese Datenelemente entsprechend von dem Modul für die Bestimmung der GNSS-Position verwendet. Selbstverständlich ergibt die Verwendung von falschen Eingabedaten folgerichtig auch falsche Ergebnisse (z. B. die berechnete GNSS-Position) nach dem GIGO-Prinzip (garbage in, garbage out).
-
Das nachfolgend beschriebene Kommunikationssystem verwendet Verfahren zur Abwehr und für Gegenmaßnahmen in Situationen, in denen das Fahrzeug Hinweise auf eine solche bösartige Attacke erfasst hat. Wird zum Beispiel ein bösartiger Angriff festgestellt, so kommuniziert das Fahrzeug mit einem Backend-System, das wiederum die Standortdaten des Fahrzeugs durch ein Mobilfunkanbieter-System empfängt und diese dann an das Fahrzeug übermittelt. Dieser Vorgang kann für die Dauer des bösartigen Angriffes fortgesetzt werden.
-
Das Kommunikationssystem des Fahrzeuges wird nachfolgend genauer beschrieben. Danach werden ein oder mehrere der Verfahren für Abwehr und Gegenmaßnahmen untersucht.
-
Kommunikationssystem –
-
Mit Bezug auf 1 ist eine Betriebsumgebung dargestellt, die ein mobiles Fahrzeugkommunikationssystem 10 umfasst, das verwendet werden kann, um das hier offenbarte Verfahren zu implementieren. Das Kommunikationssystem 10 beinhaltet im Allgemeinen ein Fahrzeug 12, eine lokale Infrastruktur für drahtlose Kommunikation 13, ein oder mehrere Drahtlosträgersysteme 14, ein Festnetz 16 und ein Backend-System 17, das einen Computer 18 und ein Rechenzentrum 20 beinhalten kann. Es versteht sich, dass das offenbarte Verfahren mit einer beliebigen Anzahl von unterschiedlichen Systemen verwendet werden kann und nicht speziell auf die hier gezeigte Betriebsumgebung einschränkt ist. Auch die Architektur, Konstruktion, Konfiguration und der Betrieb des Systems 10 und seiner einzelnen Komponenten sind in der Technik allgemein bekannt. Somit stellen die folgenden Absätze lediglich einen kurzen Überblick über ein solches Kommunikationssystem 10 bereit; aber auch andere, hier nicht dargestellte Systeme könnten die offenbarten Verfahren einsetzen.
-
Fahrzeug 12 ist in der veranschaulichten Ausführungsform als ein Personenkraftwagen dargestellt, es sollte jedoch beachtet werden, dass jedes andere Fahrzeug, einschließlich Motorräder, Lastwagen, Geländewagen (SUVs), Campingfahrzeuge (RVs), Wasserfahrzeuge, Flugzeuge usw. ebenfalls verwendet werden kann. Generell wird in 1 ein Teil der Fahrzeugelektronik 28 gezeigt, dazu gehören eine Telematikeinheit 30, ein Mikrofon 32, eine oder mehrere Tasten oder andere Eingabesteuerungen 34, ein Audiosystem 36, eine optische Anzeige 38, ein GNSS-Modul 40 sowie eine Anzahl von Fahrzeugsystemmodulen (VSM) 42. Wie nachfolgend erläutert, kann das GNSS-Modul 40 GPS-Dienste (Global Position System) liefern Dienste (und zusätzlich andere unter Fachleuten bekannte Dienste: Glonass, Beidou, Galileo usw.). Einige dieser Vorrichtungen können direkt mit der Telematikeinheit wie z. B. Mikrofon 32, und der bzw. den Tasten 34 verbunden sein, während andere indirekt unter Verwendung von einer oder mehreren Netzwerkverbindungen, wie einem Kommunikationsbus 44 oder einem Entertainmentbus 46, verbunden sind. Beispiele geeigneter Netzwerkverbindungen beinhalten ein Controller Area Network, (CAN) ein medienorientierter Systemtransfer (MOST), ein lokales Kopplungsstrukturnetzwerk (LIN), ein lokales Netzwerk (LAN) und andere geeignete Verbindungen, wie z. B. Ethernet oder andere, die u. a. den bekannten ISO-, SAE- und IEEE-Standards und -Spezifikationen entsprechen.
-
Die Telematikeinheit 30 kann eine OEM-installierte (eingebettete) oder eine Aftermarketvorrichtung sein, die in dem Fahrzeug installiert ist und drahtlose Sprach- und/oder Datenkommunikation über das Mobilfunkanbietersystem 14 und über drahtlose Vernetzung ermöglicht. Dies ermöglicht dem Fahrzeug die Kommunikation mit dem Rechenzentrum 20, anderen telematikfähigen Fahrzeugen oder anderen Einheiten und Geräten. Die Telematikeinheit verwendet bevorzugt Funkübertragungen, um einen Kommunikationskanal (einen Sprachkanal und/oder einen Datenkanal) mit dem drahtlosen Trägerfrequenzsystem 14 herzustellen, sodass Sprach- und/oder Datenübertragungen über den Kanal gesendet und empfangen werden können. Durch Bereitstellen von sowohl Sprach- als auch Datenkommunikation ermöglicht die Telematikeinheit 30, dass das Fahrzeug eine Anzahl von unterschiedlichen Diensten anbieten kann, die diejenigen umfassen, die mit Navigation, Fernsprechen, Nothilfe, Diagnose, Infotainment usw. verbunden sind. Daten können entweder über eine Datenverbindung, wie über Paketdatenübertragung über einen Datenkanal oder über einen Sprachkanal unter Verwendung von auf dem Fachgebiet bekannten Techniken gesendet werden. Für kombinierte Dienste, welche Sprachkommunikation (z. B. mit einem Service-Mitarbeiter oder einem Sprachmodul im Rechenzentrum 20) und Datenkommunikation (z. B. die Bereitstellung von GNSS-Daten oder Fahrzeugdiagnosedaten für das Rechenzentrum 20) zusammenlegen, kann das System einen einzelnen Anruf über einen Sprachkanal verwenden und nach Bedarf zwischen Sprach- und Datenübertragung auf dem Sprachkanal umschalten, dies kann unter Verwendung von Techniken erfolgen, die bei Fachleuten bekannt sind.
-
Gemäß einer Ausführungsform verwendet die Telematikeinheit 30 Mobilfunkkommunikation gemäß entweder den GSM-, CDMA- oder LTE-Standards und beinhaltet daher einen Mobilfunkstandardchipsatz 50 für die Sprachkommunikation, wie Freisprechen, ein drahtloses Modem für die Datenübertragung, ein elektronisches Verarbeitungsgerät 52, eine oder mehrere Digitalspeichervorrichtungen 54 und eine Dual-Antenne 56. Es versteht sich, dass das Modem entweder durch Software implementiert sein kann, die in der Telematikeinheit gespeichert und durch den Prozessor 52 ausgeführt wird, oder es kann eine separate Hardwarekomponente sein, die sich innerhalb oder außerhalb der Telematikeinheit 30 befinden kann. Das Modem kann mithilfe einer beliebigen Anzahl unterschiedlicher Standards oder Protokolle wie z. B. LTE, EVDO, CDMA, GPRS und EDGE betrieben werden. Die drahtlose Vernetzung zwischen dem Fahrzeug und den anderen vernetzten Vorrichtungen kann auch unter Verwendung der Telematikeinheit 30 erfolgen. Für diesen Zweck kann die Telematikeinheit 30 konfiguriert sein, gemäß einem oder mehreren Protokollen drahtlos zu kommunizieren, einschließlich drahtloser Nahbereichskommunikation (SRWC), wie irgendwelche von den IEEE 802.11-Protokollen, WiMAX, ZigBeeTM, Wi-Fi direct, Bluetooth oder Nahfeldkommunikation (NFC). Wenn die Telematikeinheit für paketvermittelte Datenkommunikation eingesetzt wird, kann sie TCP/IP verwenden.
-
Der Prozessor 52 kann jede Geräteart sein, die fähig ist elektronische Befehle zu verarbeiten, einschließlich Mikroprozessoren, Mikrocontrollern, Hostprozessoren, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). Er kann ein speziell dafür vorgesehener Prozessor sein, der nur für die Telematikeinheit 30 verwendet wird, oder er kann mit anderen Fahrzeugsystemen geteilt werden. Der Prozessor 52 führt verschiedene Arten von digital gespeicherten Befehlen aus, wie Software oder Firmwareprogramme, die im Speicher 54 gespeichert sind, welche der Telematikeinheit ermöglichen, eine große Vielfalt von Diensten bereitzustellen. Zum Beispiel kann der Prozessor 52 Programme ausführen oder Daten verarbeiten, um mindestens einen Teil des Verfahrens auszuführen, das hierin beschrieben ist.
-
Der Speicher 54 kann jedes geeignete nichtflüchtige, computerlesbare, oder vom Computer nutzbare Medium enthalten, das seinerseits eine oder mehrere Speichervorrichtungen oder -Gegenstände beinhalten kann. Bei mindestens einer Umsetzung kann zumindest ein Teil des Speichers 54 Teil des Prozessors 60 (beispielsweise in einem Mikroprozessor) sein. Exemplarische nicht-transitorische computernutzbare Speichervorrichtungen beinhalten ein herkömmliches Computersystem-RAM (random access memory), ROM (read only memory), EPROM (löschbarer, programmierbarer ROM), EEPROM (elektrisch löschbarer, programmierbarer ROM) und magnetische oder optische Platten oder Bänder.
-
Die Telematikeinheit 30 kann verwendet werden, um eine vielfältige Palette von Fahrzeugdiensten bereitzustellen, die drahtlose Kommunikation zu und/oder von dem Fahrzeug beinhalten. Zu diesen Diensten gehören: genaue Wegbeschreibungen und andere navigationsbezogene Dienste, die in Verbindung mit dem GNSS-basierten Navigationsmodul 40 des Fahrzeugs bereitgestellt werden; Airbag-Auslösemeldungen und andere mit Notruf oder Pannendienst verbundene Dienste, die in Verbindung mit einem oder mehreren Aufprallsensor(en), wie z. B. in einem Karosserie-Steuermodul (nicht dargestellt), bereitgestellt werden; Diagnosemeldungen, die ein oder mehrere Diagnosemodul(e) verwenden sowie Infotainment-bezogene Dienste, bei denen Musik, Internetseiten, Filme, Fernsehprogramme, Videospiele und/oder andere Informationen von einem Infotainmentmodul (nicht dargestellt) heruntergeladen und für die aktuelle oder spätere Wiedergabe gespeichert werden. Die oben aufgelisteten Dienste sind keineswegs eine vollständige Liste aller Fähigkeiten der Telematikeinheit 30, sondern sie sind einfach eine Aufzählung von einigen der Dienste, die die Telematikeinheit anbieten kann. Des Weiteren versteht es sich, dass mindestens einige der vorstehend genannten Module in der Form von Softwarebefehlen implementiert sein könnten, die innerhalb oder außerhalb der Telematikeinheit 30 gespeichert sind, sie könnten Hardwarekomponenten sein, die sich innerhalb oder außerhalb der Telematikeinheit 30 befinden, oder sie könnten integriert sein und/oder miteinander oder mit anderen Systemen geteilt zu sein, die sich im Fahrzeug befinden, um nur einige Möglichkeiten zu nennen. Für den Fall, dass die Module als VSMs 42 implementiert sind, die sich außerhalb der Telematikeinheit 30 befinden, könnten sie den Fahrzeugbus 44 verwenden, um Daten und Befehle mit der Telematikeinheit auszutauschen.
-
Das GNSS-Modul 40 (Globales Satelliten-Navigationssystem) empfängt Funksignale von einer Zusammenstellung 60 von GNSS-Satelliten. Aus diesen Signalen kann das Modul 40 Position und/oder Bewegungsrichtung des Fahrzeuges bestimmen, durch deren Verwendung Navigations- und andere standortbezogene Dienste für den Fahrer bereitgestellt werden. Navigationsinformationen können auf der Anzeige 38 (oder einer anderen Anzeige innerhalb des Fahrzeugs) dargestellt oder in verbaler Form präsentiert werden, wie es beispielsweise bei der Wegbeschreibungsnavigation der Fall ist. Die Navigationsdienste können von einem speziellen Navigationsmodul im Fahrzeug (das Teil des GNSS-Moduls 40 sein kann) bereitgestellt werden, oder einige oder alle Navigationsdienste werden von der Telematikeinheit 30 ausgeführt, wobei die Position an einen entfernten Standort geschickt wird, um im Gegenzug Navigationskarten, Kartenanmerkungen (Sehenswürdigkeiten, Restaurants usw.), Routenberechnungen und dergleichen für das Fahrzeug zu erhalten. Die Positionsinformationen können auch für andere Zwecke wie z. B. das Fuhrparkmanagement an das Rechenzentrum 20 oder ein anderes abgesetztes Computersystem, wie Computer 18 übermittelt werden. Außerdem können über die Telematikeinheit 30 neue oder aktualisierte Karten für das GNSS-Modul 40 vom Rechenzentrum 20 heruntergeladen werden.
-
Wie in 2 gezeigt, kann das GNSS-Modul 40 einen GNSS-Chipsatz 39, einen oder mehrere dedizierte(n) Prozessor(en) 41 sowie einen Speicher 43 beinhalten. Die GNSS Chipsatz 39 kann für ein oder mehrere GNSS-Signal(e) ausgelegt sein; bei mindestens einer Ausführung kann der Chipsatz 39 beispielsweise mindestens vier GNSS-Signale gleichzeitig verarbeiten. Der Prozessor 41 und Speicher 43 können für Berechnungen der empfangenen GNSS-Signale ausgelegt sein, z. B. zur Positionsbestimmung des Fahrzeuges 12 und zur Kommunikation mit anderen Fahrzeugsystemmodulen 42. Bei mindestens einer Ausführungsform können der Prozessor 41 und Speicher 43 ähnliche physikalische Eigenschaften und Funktionen wie Prozessor 52 und Speicher 54 haben; natürlich können der Prozessor 41 und Speicher 43 jedoch auch angepasst und/oder konfiguriert werden (z. B. durch Software, Firmware oder dergleichen), um (anstelle der Telematikeinheit 30) Aufgaben, Routinen, Programme oder eine Kombination aus diesen ablaufen zu lassen, die mit dem GNSS-Modul 40 zu tun haben. Bei einer anderen Ausführungsform werden zumindest einige der Aufgaben des GNSS-Moduls wie Routinen, Programme usw. von der Telematikeinheit 30 abgearbeitet. Und bei mindestens einer Umsetzung hat das GNSS-Modul 40 keinen speziellen Prozessor 41 oder Speicher 43, da z. B. die Telematikeinheit 30 oder andere VSM 42 die Rechen- und Speicherfunktionen übernehmen.
-
Wiederum mit Bezug auf 1 kann das Fahrzeug 12 abgesehen vom Audiosystem 36 und dem GNSS-Modul 40 auch noch andere Fahrzeugsystemmodule (VSM) 42 in Form von elektronischen Hardwarekomponenten verteilt über das Fahrzeug beinhalten, die typischerweise Eingaben von einem oder mehreren Sensoren empfangen und diese zur Durchführung von Funktionen der Diagnose, Überwachung, Steuerung, Berichterstattung usw. nutzen. Jedes der VSM 42 sollte vorzugsweise über den Kommunikationsbus 44 mit den anderen VSM sowie der Telematikeinheit 30 verbunden sein und kann für den Ablauf von Programmen im Fahrzeugsystem und Subsystem sowie für OBD-Tests und andere programmiert werden.
-
Die Fahrzeugelektronik 28 beinhaltet auch eine Anzahl von Fahrzeugbenutzeroberflächen, die Fahrzeuginsassen mit einem Mittel zum Bereitstellen und/oder Empfangen von Informationen ausstattet, einschließlich Mikrofon 32, Taste(n) 34, Audiosystem 36, und optischer Anzeige 38. Wie hierin verwendet, beinhaltet der Begriff „Fahrzeugbenutzeroberfläche” weitgehend jede geeignete Form von elektronischer Vorrichtung, die sowohl die im Fahrzeug befindlichen Hardware- als auch Softwarekomponenten beinhaltet und einem Fahrzeugbenutzer ermöglicht, mit einer oder durch eine Komponente des Fahrzeugs zu kommunizieren.
-
Zu den lokalen drahtlosen Infrastrukturen 13 gehört eine jede geeignete drahtlose Vorrichtung als Teil der Straßennetzinfrastruktur, die aufgrund ihrer Auslegung mit passierenden oder sich in der Nähe aufhaltenden Fahrzeugen (wie 12) kommunizieren kann. Die Infrastruktur 13 ist dafür ausgelegt, mindestens eine Art von drahtloser Nahbereichskommunikation (SRWC) mit dem Fahrzeug 12 zu ermöglichen. Das kann unter Verwendung von Protokollen aus den Bereichen Wi-Fi, Bluetooth usw. geschehen. Gemäß der Verwendung hierin beinhalten die Infrastrukturen 13 drahtlose Hotspots und SRWC von lokalen, kommerziellen Unternehmen, Gemeinden und dergleichen. Die Infrastruktur 13 kann ein oder mehrere Systeme aus vernetzten Kommunikationseinrichtungen entlang der Straßen, Parkplätze usw. beinhalten. Solche Infrastrukturen können in bewohnten Gegenden vorhanden sein (z. B. Großstädten).
-
Das Mobilfunkanbietersystem 14 ist bevorzugt ein Mobiltelefonsystem, mit einer Vielzahl von Mobilfunkmasten 70 (nur einer gezeigt), einer oder mehreren mobilen Vermittlungszentralen (MSC) 72 sowie anderen erforderlichen Netzwerkkomponenten für die Anbindung des Mobilfunkanbietersystems 14 an das Festnetz 16. Jeder Mobilfunkturm 70 beinhaltet Sende- und Empfangsantennen und eine Basisstation, wobei die Basisstationen von unterschiedlichen Mobilfunktürmen mit der MSC 72 entweder direkt oder über zwischengeschaltete Geräte, wie z. B. eine Basisstationssteuereinheit, verbunden sind. Das Mobilsystem 14 kann jede geeignete Kommunikationstechnologie implementieren, einschließlich beispielsweise analoger Technologien, wie AMPS, oder der neueren digitalen Technologien, wie beispielsweise CDMA (beispielsweise CDMA2000), GSM/GPRS oder LTE. Der Fachmann wird erkennen, dass verschiedene Mobilfunkmast/Basisstation/MSC-Anordnungen möglich sind und mit dem drahtlosen System 14 verwendet werden könnten. Zum Beispiel könnten sich Basisstation und Mobilfunkturm an derselben Stelle oder entfernt voneinander befinden, jede Basisstation könnte für einen einzelnen Mobilfunkturm zuständig sein oder eine einzelne Basisstation könnte verschiedene Mobilfunktürme bedienen und verschiedene Basisstationen könnten mit einer einzigen MSC gekoppelt werden, um nur einige der möglichen Anordnungen zu nennen.
-
Abgesehen von dem Verwenden des Drahtlosträgersystems 14 kann ein unterschiedliches Drahtlosträgersystem in der Form von Satellitenkommunikation verwendet werden, um unidirektionale oder bidirektionale Kommunikation mit dem Fahrzeug bereitzustellen. Dies kann unter Verwendung von einem oder mehreren Fernmeldesatelliten 62 und einer aufwärtsgerichteten Sendestation 64 erfolgen. Bei unidirektionaler Kommunikation kann es sich beispielsweise um Satellitenradiodienste handeln, bei denen Programminhalte (Nachrichten, Musik usw.) von der Sendestation 64 empfangen, für den Upload gepackt und anschließend zum Satelliten 62 gesendet werden, der das Programm an die Teilnehmer ausstrahlt. Bidirektionale Kommunikation kann beispielsweise Satellitentelefoniedienste unter Verwendung der Satelliten 62 sein, um Telefonkommunikationen zwischen dem Fahrzeug 12 und der der Station 64 weiterzugeben. Bei Verwendung kann dieses Satellitenfernsprechen entweder zusätzlich zu dem oder anstatt des drahtlosen Trägerfrequenzsystems 14 verwendet werden.
-
Das Festnetz 16 kann ein konventionelles landgebundenes Telekommunikationsnetzwerk sein, das mit einem oder mehreren Festnetztelefonen verbunden ist und das Drahtlosträgersystem 14 mit dem Rechenzentrum 20 verbindet. So kann beispielsweise das Festnetz 16 ein Fernsprechnetz (PSTN) wie dasjenige sein, das verwendet wird, um festverdrahtetes Fernsprechen, paketvermittelte Datenkommunikationen und die Internetinfrastruktur bereitzustellen. Ein oder mehrere Segmente des Festnetzes 16 könnten durch Verwenden eines normalen drahtgebundenen Netzwerks, eines Lichtleiter- oder eines anderen optischen Netzwerks, eines Kabelnetzes, von Stromleitungen, anderen drahtlosen Netzwerken wie drahtlose lokale Netzwerke (WLANs) oder Netzwerke, die drahtlosen Breitbandzugang (BWA) bereitstellen oder jeder Kombination davon implementiert sein. Des Weiteren muss das Rechenzentrum 20 nicht über das Festnetz 16 verbunden sein, sondern könnte mit Mobilfunkgeräten ausgestattet sein, sodass es direkt über ein drahtloses Netzwerk wie das Drahtlosträgersystem 14 kommunizieren kann.
-
Der Computer oder Server 18 kann einer von einer Anzahl von Computern sein, die über ein privates oder öffentliches Netzwerk zugänglich sind, wie beispielsweise das Internet. Jeder solche Computer 18 kann für einen oder mehrere Zwecke, wie einen Webserver verwendet werden, der von dem Fahrzeug über die Telematikeinheit 30 und das Drahtlosträgersystem 14 zugänglich ist. Beispiele für andere solch zugängliche Computer 18 können sein: ein Computer im Kundendienstzentrum, der über die Telematikeinheit 30 Diagnoseinformationen und andere Daten vom Fahrzeug empfangen kann; ein Clientcomputer, der vom Fahrer oder einem anderen Teilnehmer für den Zugriff/Empfang auf/von Fahrzeugdaten oder zur Einstellung oder Anpassung von Teilnehmerpräferenzen oder zur Steuerung von Fahrzeugfunktionen verwendet wird; oder ein Speicher eines Fremdanbieters für den Zugriff/Empfang auf/von Fahrzeugdaten oder andere(n) Informationen durch Kommunikation mit dem Fahrzeug 12 und/oder dem Rechenzentrum 20. Ein Computer 18 kann auch für das Bereitstellen von Internetkonnektivität wie DNS-Dienste oder als ein Netzwerkadressenserver verwendet werden, der DHCP oder ein anderes geeignetes Protokoll verwendet, um dem Fahrzeug 12 eine IP-Adresse zuzuweisen. Ein oder mehrere Rechner 18 kann/können über ein Netzwerk mit dem Rechenzentrum 20 verbunden sein, während das für andere Computer 18 nicht der Fall sein muss.
-
Das Rechenzentrum 20 ist dafür konzipiert, eine Anzahl von unterschiedlichen Backend-Systemfunktionen für die Fahrzeugelektronik 28 bereitzustellen und beinhaltet gemäß dem gezeigten Ausführungsbeispiel allgemein einen oder mehrere Switche(e) 80, Server 82, Datenbanken 84, Live-Berater 86 sowie ein automatisiertes Sprachausgabesystem (VRS) 88, alles unter Fachleuten bekannt. Diese verschiedenen Komponenten des Rechenzentrums sind bevorzugt miteinander über ein verdrahtetes oder drahtloses lokales Netzwerk 90 verbunden. Der Switch 80, der ein Nebenstellenanlagen(PBX)-Switch sein kann, leitet eingehende Signale weiter, sodass Sprachübertragungen gewöhnlich entweder zu dem Live-Berater 86 über das reguläre Telefon oder automatisiert zu dem Sprachausgabesystem 88 unter Verwendung von VoIP gesendet werden. Das Live-Berater-Telefon kann auch VoIP verwenden, wie durch die gestrichelte Linie in 1 angezeigt. VoIP und andere Datenkommunikation durch den Switch 80 werden über ein Modem (nicht gezeigt) implementiert, das zwischen dem Schalter 80 und Netzwerk 90 verbunden ist. Datenübertragungen werden über das Modem zu dem Server 82 und/oder der Datenbank 84 weitergegeben. Die Datenbank 84 kann Kontoinformationen wie Teilnehmerauthentisierungsinformationen, Fahrzeugbezeichner, Profilaufzeichnungen, Verhaltensmuster und andere entsprechende Teilnehmerinformationen speichern. Datenübertragungen können auch durch drahtlose Systeme wie z. B. 802.11x, GPRS und dergleichen erfolgen. Obwohl die dargestellte Ausführungsform der Beschreibung nach mit einem bemannten Rechenzentrum 20 mit Live-Beratern 86 verwendet werden würde, kann das Rechenzentrum offensichtlich stattdessen ein VRS 88 als automatisierten Berater, oder eine Kombination aus VRS 88 und dem Live-Berater 86 verwenden.
-
Verfahren –
-
Nun mit Bezug auf 2 werden ein böswilliger Angreifer 94 (z. B. dargestellt durch ein Computergerät) und ein Mobilgerät 96 gezeigt, die an einem Man-in-the-Middle Angriff auf die Konstellation von GNSS-Satelliten 60 und das Fahrzeug 12 beteiligt sind. Der dargestellte Angreifer 94 und das Mobilgerät 96 dienen nur als Beispiel (Angreifer 94 und Mobilgerät 96 könnten zusammen ein Mobiltelefon, ein drahtloses Notebook oder dergleichen sein). Die 2 zeigt den Angreifer 94 beim Empfang eines authentischen (also ursprünglichen oder legitimen) GNSS-Signals 98 über das Mobilgerät 96, welches er dann als Spoofing-GNSS-Signal 98 (z. B. ungenau, gefälscht oder anderweitig illegitim) überträgt. Es ist zu beachten, dass der Angreifer in vielen Fällen nicht erst ein legitimes GNSS-Signal 98 zur Übermittlung des illegitim Signal 98' empfangen muss. Während das Fahrzeug 12 (bzw. das GNSS-Modul 40) auch ein oder mehrere authentische(s) GNSS-Signal(e) 98 empfangen kann, können ebenso gut auch ein oder mehrere illegitime(s) GNSS-Signal(e) 98' vom Angreifer 94 darunter sein. Zusätzlich können auch andere GNSS-Geräte (also andere als das Modul 40) die gespooften GNSS-Signale(s) 98' empfangen, wie aus der nachfolgenden Beschreibung noch deutlich wird. Somit können gespoofte GNSS-Signale 98 auch das lokale GNSS oder GNSS Geräte beeinflussen.
-
Zu den hier verwendeten illegitimen GNSS-Signalen gehören die bösartigen Signale 98, welche das authentische Signal 98 (das ebenfalls vom Fahrzeug 12 empfangen werden würde) überlagern können. Das illegitime Signal 98' kann gezielt auf das Fahrzeug 12 (z. B. mit Richtantennen) oder breit gestreut übertragen werden kann (z. B. mit omnidirektionalen Antennen). Auch andere bösartige Techniken werden bei Fachleuten bekannt sein.
-
Mit Bezug nun auf die 3A und 3B wird ein Verfahren 300 zur Verbesserung der Positionsdienste für einen Benutzer eines Fahrzeuges dargestellt, welches Elemente oder Komponenten außerhalb des Fahrzeugs 12 verwendet (z. B. eine systemgestützte oder externe Lösung). So können moderne GNSS-Chipsätze, wie der GNSS-Chipsatz 39, beispielsweise dafür konfiguriert sein, einen böswilligen Angriff bei Ausführung zu entdecken. Allerdings können moderne GNSS-Chipsätze bei der Entdeckung die illegitimen Daten der GNSS-Satelliten einfach ignorieren; d. h. sie können während der Dauer des bösartigen Angriffs den Standort des GNSS-Gerätes nicht anderweitig bestimmen. Das Verfahren 300 beschreibt einen Prozess, der diese Einschränkung überwindet und Positionsdienste für einen Fahrzeugbenutzer auch während eines bösartigen Angriffs bereitstellt. Wie nachfolgend genauer beschrieben, verwendet das Verfahren 300 ein oder mehrere Elemente oder Komponente(n) des Kommunikationssystems 10, um Positionsdienste zu bieten, anstatt ausschließlich auf das GNSS-Modul 40 zu vertrauen. Das Verfahren 300 beginnt bei Schritt 305.
-
Bei Schritt 305 wird ein Zustand festgestellt, der mit einem bösartigen Angriff assoziiert wird. Gemäß einem Aspekt kann das beim Fahrzeug 12 eintreten. 3B stellt den Schritt 305 ausführlicher dar und zeigt viele Beispiele für Techniken, durch die das Fahrzeug 12 (bzw. das GNSS-Modul 40) den Zustand ermitteln kann. Die in 3B dargestellten Techniken können einzeln oder in Kombination miteinander verwendet werden. Beispielsweise bestimmt die Technik 305a die absolute Stärke eines GNSS-Signals. Ein authentisches GNSS-Signal (98) hat erwartungsgemäß eine Signalstärke unterhalb eines vorgegebenen Schwellenwertes (z. B. könnte der Schwellenwert für einen GNSS-Kanal –153 dBW sein; für einen anderen GNSS-Kanal –155 dBW und für noch einen weiteren GNSS-Kanal –158 dBW). Bei mindestens einer Umsetzung hat das illegitime GNSS-Signal (98') eine Steigerung der Signalstärke von mindestens 3 dB (d. h. 3 dB größer als der Schwellenwert von jeweils –153 dBW, –155 dBW und –158 dBW). So kann GNSS-Modul 40 durch Vergleich der absoluten Signalstärke eines empfangenen GNSS-Signals mit einem vorbestimmten Schwellenwert (der mit mindestens einem der Kanäle des GNSS-Modul 40 assoziiert ist) feststellen, ob eine Bedingung auf einen GNSS-Angriff hindeutet.
-
Zum Verfahren 305b gehört die Feststellung der Veränderung der Signalstärke eines empfangenen GNSS-Signals. Die Änderungsrate der Signalstärke eines GNSS-Signals wird allgemein für eine kurze Zeitspanne als konstant angesehen. Diese Annahme beruht auf dem Kriterium, dass der Satellit etwa 20.000 Kilometer vom Fahrzeug 12 entfernt ist und ein relativ kleiner Winkel zwischen Fahrzeug 12 und Satellit (60) liegt. Genauer gesagt ist der überstrichene Winkel aus der Perspektive des Fahrzeugs 12 gegenüber den beiden Positionen des Satelliten (60) klein – die erste Satellitenposition steht in Verbindung zu einer Ausgangszeit (t0) des Intervalls und die zweite Position des Satelliten zu einer Abschlusszeit (tF) des Intervalls. Ist jedoch der böswillige Angreifer 94 die Quelle des GNSS-Signals (98'), dann kann die Änderungsrate während der gleichen Zeitspanne erheblich abweichen. Das kann aufgrund der sich ändernden Position des böswilligen Angreifers 94, der sich ändernden Position des Fahrzeugs 12, oder von beiden geschehen. Somit kann ein vorbestimmter Schwellenwert, bezogen auf die Änderungsrate der Signalstärke für ein authentisches GNSS-Signal, für einen gegebenen Zeitraum verwendet werden, um zu bestimmen, ob das empfangene GNSS-Signal authentisch oder illegitim ist. Wenn die Änderungsrate des empfangenen Signals die Schwelle überschreitet, kann das GNSS-Modul 40 einen Zustand konstatieren, der auf einen böswilligen Angriff hindeutet.
-
Zum Verfahren 305c gehört die Bestimmung einer relativen Signalstärke eines GNSS-Signals (z. B. verglichen mit mindestens einem anderen empfangenen GNSS-Signal). Beispielsweise kann das GNSS-Modul 40 ein erstes GNSS-Signal mit einer Stärke A empfangen, ein zweites GNSS-Signal mit einer Stärke B, ein drittes GNSS-Signal mit einer Stärke C sowie ein viertes GNSS-Signal mit einer Stärke D, und das Modul 40 kann die relativen Stärkeverhältnisse berechnen (z. B. A/B, A/C, A/D, B/A, B/C, B/D, C/A, C/B, C/D, D/A, D/B und D/C). Basierend auf diesen Verhältnissen kann ein relativer Bereich bestimmt werden. Liegt eines der relativen Stärkeverhältnisse außerhalb des relativen Bereiches, kann das GNSS-Modul 40 einen Zustand konstatieren, der auf einen böswilligen Angriff hindeutet. Bei anderen Umsetzungen kann der relative Bereich vorbestimmt anstatt berechnet werden; zudem haben die Verhältnisse (und die Anzahl der verwendeten GNSS-Signale) lediglich exemplarischen Charakter. Andere Mengen und Verhältnisse können ebenso verwendet werden.
-
Zum Verfahren 305d gehört die Begrenzung und der Vergleich von GNSS-Bereichsraten. Genauer gesagt gehört dazu das Korrelieren des Code-Bereiches und des Phasen-Bereiches des empfangenen GNSS-Signals zu einer Phasenbereichsrate. Code-Bereiche, Phasen-Bereiche, Phasenbereichsraten und die Techniken und dazugehörige Berechnungen bei Verwendung derartiger Bereiche und Raten sind für den Fachmann bekannte Größen. Bei einem Angriff kann der bösartige Angreifer jedoch den/die Phasen-Bereich(e) spoofen; wenn sich das GNSS-Modul 40 (oder das Fahrzeug 12) bewegt, kann die Phasenbereichsrate geopfert werden und das GNSS-Modul 40 kann erkennen, dass die Phasenbereichsrate außerhalb eines vorbestimmten oder erwarteten Schwellenwertes liegt (z. B. durch den Vergleich von Werten für Code- und Phasen-Bereich). Somit kann das GNSS-Modul 40 durch die Begrenzung und den Vergleich von GNSS-Bereichsraten einen Zustand konstatieren, der auf einen böswilligen Angriff hindeutet.
-
Und das Verfahren 305e umfasst die Überprüfung auf Dopplerverschiebung. Es versteht sich, dass das GNSS-Modul 40 Daten für die Positionen des Fahrzeugs und des Satelliten bestimmen kann (z. B. eine Fahrzeugposition relativ zu einer Satellitenposition). Somit kann das GNSS-Modul 40 eine relative Geschwindigkeit des GNSS-Moduls 40 (bzw. des Fahrzeugs 12) in Bezug auf übertragende Satelliten (60) ermitteln und aus diesen Daten eine Dopplerverschiebung ableiten. Dieser Vorgang und die Technik sind unter Fachleuten bekannt. Da es für den böswilligen Angreifer schwierig ist, alle GNSS-Satelliten zu imitieren, die GNSS-Signale an das Fahrzeug 12 übertragen, können Ausreißer (die Spoofer) durch Vergleiche der jeweiligen Dopplerverschiebungen entdeckt werden. Wird ein Ausreißer bestimmt, so kann eine Bedingung für einen bösartigen Angriff bestimmt werden. Wenn das GNSS-Modul 40 eine berechnete Dopplerverschiebung mit einer entsprechenden Bereichsrate vergleicht, so kann eine Abweichung oder fehlende Korrelation ein zusätzlicher Hinweis auf einen bösartigen Angriff sein.
-
Es sollte beachtet werden, dass diese und andere Erkennungstechniken von Fachleuten zur Bestimmung von Hinweisen auf einen bösartigen Angriff verwendet werden können. Diese Techniken stellen keine Einschränkung dar. Beispielsweise kann das GNSS-Modul 40 Kreuzkorrelationen, Residualanalysen, Erkennung von Bereichsdifferenzen durch ikonosphärische Effekte, Vergleiche von Ephemeris-Daten, Sprungerkennung und dergleichen durchführen.
-
Der Schritt 305 könnte auch unter anderen Umständen eintreten. Beispielsweise könnte das Backend-System 17 mit dem Fahrzeug 12 (und anderen Fahrzeugen in der Nähe) kommunizieren, um den Angriff anzuzeigen. Oder das Fahrzeug kann die Daten zur Anzeige des Angriffs von der lokalen Infrastruktur 13 empfangen. Auch dies sind lediglich Beispiele und stellen keine Einschränkung dar. Nach Schritt 305 fährt das Verfahren 300 mit Schritt 310 fort (3A).
-
Bei Schritt 310 kommuniziert das Fahrzeug (über die Telematikeinheit 30) mit dem Backend-System 17 und unterrichtet das Backend-System 17 über die Bedingung des bösartigen Angriffs aus Schritt 305. Die weitere Kommunikation kann eine Anforderung von Standortdaten für das Fahrzeug 12 durch das Fahrzeug 12 selbst beinhalten. Das kann durch Senden einer Nachricht vom Fahrzeug 12 an das Backend-System 17 geschehen – z. B. eine paketvermittelte Nachricht, eine SMS, Senden der Nachricht (Daten) über einen Anruf (z. B. unter Verwendung eines Vocoders) usw. Bei einer Implementierung leitet das Fahrzeug 12 die Kommunikation ein; das muss jedoch keine Aktion des Fahrers einschließen (z. B. kann das Fahrzeug automatisch mit dem Backend-System 17 kommunizieren, wenn die Bedingungen für einen bösartigen Angriff entdeckt wurden; also ohne den Benutzer). Bei anderen Ausführungsformen kann das Backend-System 17 die Kommunikation einleiten. Beispielsweise kann das System 17 den GNSS-Status vom Fahrzeug 12 abfragen und Fahrzeug 12 kann durch Abgabe einer Statusnachricht reagieren (z. B. periodische Abfragen oder dergleichen). Nach Schritt 310 fährt das Verfahren mit Schritt 315 fort.
-
Bei Schritt 315 fragt das Backend-System 17 Informationen zum Fahrzeugstandort vom Mobilfunkanbieter-System (WCS) 14 ab. WCS 14 kann die Standortinformationen für das Fahrzeug über eine oder mehrere Techniken ermitteln. Beispielsweise können die Funkbasisstationen (oder eNodeB (eNB) in LTE-Architekturen) eine Position des Fahrzeugs 12 durch die Kommunikation zwischen dem WCS 14 und der Telematikeinheit 30 triangulieren. Techniken und Rechenwege der Triangulation sind allgemein bekannt und werden hier nicht näher erläutert. Ein weiteres Beispiel für die mögliche Ermittlung der Standortinformationen für das Fahrzeug durch das WCS 14 verwendet die erweiterte Funkzellenkennung (E-Cell ID). Wie für Fachleuten ersichtlich, ermöglicht E-Cell ID die Verengung des Bereichs bei der Standortbestimmung für das Fahrzeug 12 auf eine Funkzelle im Bereich eines speziellen Funkmasts. Genauer gesagt kann die Bereichsbegrenzung durch Erwägungen der Signalstärke, Signalqualität (z. B. SNR), Zeitdifferenz bei Empfangen/Senden (RX-TX) und dergleichen festgelegt werden. Ein weiteres Beispiel für die mögliche Ermittlung der Standortinformationen für das Fahrzeug durch das WCS 14 umfasst die Verwendung von Zeitdifferenzen beim Empfang eine Technik, bei der ein Gerät ein Referenzsignal mit Zeitdifferenz auf einem Downlink von mehreren Basisstationen empfängt (z. B. von einer Basisstation zu einem Nutzergerät). Triangulation, E-Cell ID, und beobachtete Zeitdifferenz bei Empfang können einzeln oder in Kombination miteinander zur Standortbestimmung des Fahrzeugs 12 verwendet werden.
-
Es versteht sich, dass auch andere Techniken vom WCS 14 eingesetzt werden können. Allerdings würden Techniken, die Standortdaten des betreffenden Fahrzeugs (bzw. vom GNSS-Modul 40) benötigen, als nicht vorteilhaft unberücksichtigt bleiben, da (im Schritt 305) für das Fahrzeug festgestellt wurde, dass die GNSS-Signaldaten verfälscht/illegitim sind. Insofern würden zellulare Infrastrukturen, die auf GNSS-Daten des Fahrzeugs beruhen (z. B. Dienste wie Notrufabfragestellen), durch das WCS 14 nicht abgefragt oder anderweitig verwendet werden. Somit fragt das Backend-System 17 bei zumindest einer Implementierung von Schritt 315 die Informationen vom WCS 14 ab, was keinerlei Beteiligung des GNSS-Moduls 40 im Fahrzeug 12 erfordert. Nach Schritt 315 fährt das Verfahren 300 mit Schritt 320 fort.
-
Bei Schritt 320 meldet das WCS 14 die ermittelten Standortdaten für das Fahrzeug an das Backend-System 17 (z. B. über Mobilfunk, Festnetz 16, oder beide). Zu den Standortinformationen können Daten zum Breitengrad, Längengrad, Zeitstempel usw. gehören. Sollten bestimmte Werte nur vage vorliegen, kann die Information auch als Schätzung oder Näherungswert abgegeben werden. Es folgt Schritt 325.
-
Bei Schritt 325 meldet das Backend-System 17 an das Fahrzeug 12 die ermittelten Standortdaten des Fahrzeugs – z. B. als eine paketvermittelte Nachricht, eine SMS, Senden der Nachricht (Daten) über einen Anruf (z. B. unter Verwendung eines Vocoders) usw. Diese Standortinformation kann von der Telematikeinheit 30 im Fahrzeug 12 empfangen und dann an das GNSS-Modul 40 weitergegeben werden.
-
Als nächstes wird bei Schritt 330 die im Schritt 325 empfangene Information durch Daten aus der Koppelnavigation (DR) vervollständigt. Beispielsweise kann das Fahrzeug 12 seine aktuelle Position durch Verwendung der letzten bekannten Ortsdaten (vor dem bösartigen Angriff) und der empfangenen Ortsdaten bestimmen (z. B. basierend auf Fahrzeuggeschwindigkeit(en) und der vergangenen Zeit). DR-Daten können vom GNSS-Modul 40, der Telematikeinheit 30 oder jedem anderen geeigneten VSM 42 ermittelt werden. DR-Techniken und -Anwendungen sind unter Fachleuten allgemein bekannt und werden hier nicht näher erläutert. Bei einigen Implementierungen kann das Verfahren 300 den Schritt 330 überspringen oder darauf verzichten. Demnach fährt das Verfahren nach dem Schritt 325 (und/oder 330) mit dem Schritt 335 fort.
-
Bei Schritt 335 bestimmt das Fahrzeug, ob der bösartige Angriff (erkannt in Schritt 305) noch eine Bedrohung darstellt (z. B. ob geeignete bordeigene Mittel dem GNSS-Modul 40 die Bestimmung einer genauen Position und/oder Richtung ermöglichen d. h. ohne die Unterstützung durch das Backend-System (17). Somit kann das Fahrzeug 12 bei einer Ausführungsform überprüfen, ob die Bedingungen für einen bösartigen Angriff weiterhin gegeben sind (z. B. durch die Wiederholung von Schritt 305). Bei einigen Implementierungen kann diese Überprüfung kontinuierlich stattfinden. In anderen Fällen kann diese Überprüfung periodisch stattfinden (z. B. in regelmäßigen Abständen auf die Existenz der bösartigen Bedrohung abprüfen). Bei mindestens einer Implementierung bestimmt das Fahrzeug 12 (bzw. das Modul 40), ob der bösartige Angriff vorüber ist (d. h. für eine vorgegebene Zeitspanne nicht existent war). In einer anderen Implementierung bestimmt das Fahrzeug 12 (bzw. das Modul 40), ob der bösartige Angriff noch eine Bedrohung darstellt (d. h. der Angriff ist noch aktiv; das Spoofing stellt jedoch keine Bedrohung mehr dar, weil es die bordeigene Standortbestimmung nicht nachteilig beeinflusst). Und in einer anderen Implementierung bestimmt das Fahrzeug 12 (bzw. das Modul 40), dass die vom WCS 14 erhaltenen Informationen zum Standort den Ortsdaten vom GNSS-Modul 40 entsprechen. Diese Übereinstimmung kann innerhalb von einer vorbestimmten Toleranz oder Grenzwerten liegen (d. h. für Fachleute wäre ein Wert nahe genug an dem Bereich ein Hinweis auf das Ende der bösartigen Bedrohung). Die Techniken können einzeln oder in Kombination miteinander verwendet werden. Wenn der bösartige Angriff noch eine Bedrohung darstellt, kehrt das Verfahren mindestens zum Schritt 325 zurück. Wenn der bösartige Angriff keine weitere Bedrohung darstellt, fährt das Verfahren 300 mit Schritt 345 fort.
-
Kehrt das Verfahren 300 zu Schritt 325 zurück, kann das Backend-System 17 neue oder aktualisierte Standortinformationen für das Fahrzeug liefern. Dazu kann eine Wiederholung der Schritte 315 und/oder 320 gemäß der vorstehenden Beschreibung gehören.
-
Bei Schritt 345 beendet das Backend-System 17 die Anfragen an das WCS 14 und gibt keine Standortinformationen mehr an das Fahrzeug 12 (über Mobilfunk, SMS usw.). Das kann eine Reaktion auf eine Meldung vom Fahrzeug 12 (z. B. eine Beendigungsanforderung) an das Backend-System 17 sein (z. B. weil der bösartige Angriff keine Bedrohung mehr ist). Dann fährt das Verfahren 300 mit Schritt 350 fort.
-
Bei Schritt 350 verwendet das Fahrzeug 12 (bzw. das GNSS-Modul 40) wieder authentische GNSS-Signale von den Satelliten 60 zur Bestimmung des eigenen Standortes. Das kann bis zur nächsten bösartigen Bedrohung fortgesetzt werden. Es ist zu beachten, dass die Schritte 305–350 nahtlos ohne Einwirkung durch den Benutzer ablaufen können. Somit werden aus Sicht des Fahrers die Positionsdienste für das Fahrzeug angeboten, als gäbe es keine Attacke (z. B. Empfang von genauen Richtungsangaben, Information zu Sehenswürdigkeiten oder anderes im Rahmen der Navigation usw.). Bei anderen Umsetzungen wird der Benutzer von einer Einschränkung der Dienste informiert (z. B. über die Anzeige 38 oder ein Audiosystem im Fahrzeug). Und in mindestens einer Implementierung kann die OBD-Funktion des Fahrzeugs den Vorfall erfassen und an das Backend-System 17 melden.
-
Es versteht sich, dass durch das zuvor beschriebene Verfahren 300 die Probleme während eines bösartigen Angriffes via GNSS-Signal nicht durch Lösungen der Bereiche V2I (Fahrzeug-zu-Infrastruktur) und V2V (Fahrzeug-zu-Fahrzeug) überwunden werden können. Beispielsweise können V2I-Lösungen lokale Transceiver nutzen (z. B. drahtlose Zugangspunkte), um Positionsdaten für das Fahrzeug 12 bereitzustellen; allerdings benötigen V2I-Lösungen dafür existierende lokale Infrastrukturen 13 in der Nähe des Fahrzeugs 12. Fachleute werden verstehen, dass diese Infrastruktur 13 in vielen Städten, Kleinstädten und ländlichen Bereiche so nicht vorhanden ist zumindest nicht zur gegenwärtigen Zeit. Daher ist für viele Problemstellungen V2I nicht die gewünschte Lösung. Im Fall von V2V-Lösungen muss sich das Fahrzeug 12 evtl. auf andere Fahrzeuge stützen, um Standortdaten zu erhalten (z. B. Daten von GNSS-Satelliten von diesen Fahrzeugen), falls das Fahrzeug 12 einen bösartigen Angriff erleiden sollte, werden auch andere Fahrzeuge in relativer Nähe zum Fahrzeug 12 mit einiger Wahrscheinlichkeit durch den gleichen Angriff betroffen sein. Daher wären von diesen anderen Fahrzeugen an das Fahrzeug 12 gelieferte Daten ebenso illegitim, wie die von dem Fahrzeug 12 empfangenen Daten.
-
Wie zuvor erörtert, nutzt das Verfahren 300 das Backend-System 17 (und WCS 14) zur Gewinnung von Daten, die unabhängig von GNSS-Signalen sind, es muss sich daher nicht auf V2I- oder V2V-Informationen stützen. Es versteht sich jedoch, dass V2I Informationen in einigen Implementierungen als Ergänzung der Standortinformation vom Backend-System 17 dienen können.
-
Somit wurde ein Verfahren zur Verbesserung von Positionsdiensten für einen Nutzer eines Fahrzeugs während eines bösartigen Angriffes beschrieben (z. B. wenn das Fahrzeug illegitime GNSS-Signaldaten empfängt). Zum Verfahren gehören das Fahrzeug, das eine bösartige Bedrohung erkennt und ein Backend-System (dem Fahrzeug zugeordnet), das ein Mobilfunkanbieter-System (WCS) nutzt, um Standortdaten für das Fahrzeug zu ermitteln, das mit dem WCS assoziiert ist. Bei dem Verfahren liefert das Backend-System die Standortinformationen (vom WCS) an das Fahrzeug, bis der bösartige Angriff für die Bestimmung des Fahrzeugstandortes unter Verwendung des GNSS-Systems im Fahrzeug keine Gefahr mehr darstellt.
-
Es versteht sich, dass es sich bei dem Vorstehenden um eine Beschreibung einer oder mehrerer Ausführungsformen der Erfindung handelt. Die Erfindung ist nicht auf die besonderen hierin offenbarten Ausführungsform(en) beschränkt, sondern wird ausschließlich durch die folgenden Patentansprüche definiert. Darüber hinaus beziehen sich die in der vorstehenden Beschreibung gemachten Aussagen auf bestimmte Ausführungsformen und sind nicht als Einschränkungen des Umfangs der Erfindung oder nicht als Definition der in den Ansprüchen verwendeten Begriffe zu verstehen, außer dort, wo ein Begriff oder Ausdruck ausdrücklich vorstehend definiert wurde. Verschiedene andere Ausführungsformen und verschiedene Änderungen und Modifikationen an der/den ausgewiesenen Ausführungsform(en) sind für Fachkundige offensichtlich. Alle diese anderen Ausführungsformen, Änderungen und Modifikationen sollten im Geltungsbereich der angehängten Patentansprüche verstanden werden.
-
Wie in dieser Spezifikation und den Patentansprüchen verwendet, sind die Begriffe „z. B.”, „beispielsweise”, „zum Beispiel”, „wie z. B.” und „wie” und die Verben „umfassend”, „einschließend” „aufweisend” und deren andere Verbformen, wenn sie in Verbindung mit einer Auflistung von einer oder mehreren Komponenten oder anderen Elementen verwendet werden, jeweils als offen auszulegen, was bedeutet, dass die Auflistung andere zusätzliche Komponenten oder Elemente nicht ausschließt. Andere Begriffe sind in deren weitesten vernünftigen Sinn auszulegen, es sei denn, diese werden in einem Kontext verwendet, der eine andere Auslegung erfordert.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- IEEE 802.11-Protokollen [0016]
- 802.11x [0029]
