-
Die Erfindung betrifft ein Verfahren und eine Anordnung zum Adressieren von Teilnehmern bei einer Kommunikation zwischen zumindest einem Teilnehmer und einem Backendserver.
-
Bei einer Maschine-zu-Maschine-Kommunikation ist es bekannt, Nachrichten nach dem Publish-Subscribe-Schema auszutauschen. Hierbei werden Nachrichten nicht direkt zwischen einem Sender und einem Empfänger ausgetauscht, sondern die Nachrichten werden von einem Sender, Publisher genannt, in bestimmte Klassen kategorisiert und auf Grundlage dieser Klassen von dem Sender empfangen bzw. von diesem abonniert, ohne dass Sender und Empfänger direkt miteinander kommunizieren müssen. Ein offenes Nachrichtenprotokoll, das nach dem Publish-Subscribe-Schema arbeitet, ist beispielsweise das Message Queuing Telemetry Transport (MQTT)-Protokoll.
-
Problematisch kann dies werden, wenn zur gezielten Adressierung von Teilnehmern Identifikationsmerkmale verwendet werden, über die auch für Außenstehende eine Identifikation des Teilnehmers möglich ist. Handelt es sich bei den Teilnehmern beispielsweise um Fahrzeuge, so wird häufig als Identifikationsmerkmal in den zur Adressierung verwendeten Metadaten die Vehicle Identification Number (VIN) verwendet. Da sich die VIN für ein Fahrzeug relativ leicht ermitteln lässt, beispielsweise durch Ablesen der VIN an der Frontscheibe des Fahrzeugs, kann eine Kommunikation des Fahrzeugs direkt identifiziert werden und an einen Backendserver übermittelte Daten können direkt dem Fahrzeug zugeordnet werden.
-
Der Erfindung liegt die Aufgabe zu Grunde, ein Verfahren und eine Anordnung zum Adressieren von Teilnehmern bei einer Kommunikation zwischen zumindest einem Teilnehmer und einem Backendserver zu schaffen, bei denen die Adressierung auf anonyme Art und Weise durchgeführt werden kann.
-
Die Aufgabe wird erfindungsgemäß durch ein Verfahren mit den Merkmalen des Patentanspruchs 1 und eine Anordnung mit den Merkmalen des Patentanspruchs 10 gelöst. Vorteilhafte Ausgestaltungen der Erfindung ergeben sich aus den Unteransprüchen.
-
Insbesondere wird ein Verfahren zum Adressieren von Teilnehmern bei einer Kommunikation zwischen zumindest einem Teilnehmer und einem Backendserver nach einem Publish-Subscribe-Schema zur Verfügung gestellt, umfassend die folgenden Schritte auf der Seite des zumindest einen Teilnehmers:
- - Erzeugen eines Namensraumes auf Grundlage einer Teilnehmeridentifikationsinformation mittels einer ersten Identifikatorfunktion,
- - Übermitteln des erzeugten Namensraumes an den Backendserver im Rahmen einer Authentifizierung des Teilnehmers bei dem Backendserver,
- - Erzeugen einer Adresse auf Grundlage des erzeugten Namensraumes mittels einer zweiten Identifikatorfunktion, sowie in dem Backendserver:
- - Zuordnen des im Rahmen der Authentifizierung übermittelten Namensraumes zu dem jeweiligen Teilnehmer,
- - Erzeugen der Adresse für den jeweiligen Teilnehmer auf Grundlage des jeweils übermittelten Namensraumes mittels der zweiten Identifikatorfunktion, und Verwenden der jeweils erzeugten Adresse zum Adressieren des zumindest einen Teilnehmers bei der Kommunikation zwischen dem zumindest einen Teilnehmer und dem Backendserver.
-
Ferner wird eine Anordnung zum Adressieren von Teilnehmern bei einer Kommunikation nach einem Publish-Subscribe-Schema geschaffen, umfassend zumindest einen Teilnehmer und einen Backendserver, wobei die Anordnung derart ausgebildet ist, auf der Seite des zumindest einen Teilnehmers einen Namensraum auf Grundlage einer Teilnehmeridentifikationsinformation des zumindest einen Teilnehmers mittels einer ersten Identifikatorfunktion zu erzeugen, den erzeugten Namensraum an den Backendserver im Rahmen einer Authentifizierung des zumindest einen Teilnehmers bei dem Backendserver zu übermitteln, und eine Adresse auf Grundlage des erzeugten Namensraumes mittels einer zweiten Identifikatorfunktion zu erzeugen; und wobei der Backendserver derart ausgebildet ist, den im Rahmen der Authentifizierung übermittelten Namensraum dem jeweiligen Teilnehmer zuzuordnen, und die Adresse für den jeweiligen Teilnehmer auf Grundlage des jeweils übermittelten Namensraumes mittels der zweiten Identifikatorfunktion zu erzeugen, und wobei die Anordnung ferner derart ausgebildet ist, die jeweils erzeugte Adresse zum Adressieren des zumindest einen Teilnehmers bei der Kommunikation zwischen dem zumindest einen Teilnehmer und dem Backendserver zu verwenden.
-
Eine Grundidee der Erfindung besteht darin, die Adressierung der Teilnehmer derart auszugestalten, dass ein Teilnehmer zwar erreichbar, aber im Hinblick auf seine Identität nicht mehr erkennbar ist, d.h. dass für einen Außenstehenden sich auf Grundlage der Kommunikation keine Möglichkeit bietet, den Teilnehmer zu identifizieren. Auf der (Kommunikations)-Seite des Teilnehmers wird hierzu erfindungsgemäß für den Teilnehmer auf Grundlage einer Teilnehmeridentifikationsinformation mittels einer ersten Identifikatorfunktion ein Namensraum, auch als „namespace“ bezeichnet, erzeugt. Die Teilnehmeridentifikationsinformation muss dazu geeignet sein, den Teilnehmer eindeutig zu identifizieren. Üblicherweise wird eine Teilnehmeridentifikationsinformation auch als Node-ID bezeichnet, welche einen Kommunikationsknoten, in diesem Fall den Teilnehmer, eindeutig identifiziert. Im Rahmen einer Authentifizierung des Teilnehmers bei einem Backendserver wird zusätzlich der erzeugte Namensraum an den Backendserver übermittelt. Da dies nicht in Form von bei der Kommunikation sichtbaren Metadaten, sondern im Datenteil einer Nachricht erfolgt, ist der Authentifizierungsprozess, der in der Regel zusätzlich verschlüsselt durchgeführt wird, selbst von einem Außenstehenden nicht einsehbar. Auf Grundlage des erzeugten Namensraumes wird mittels einer zweiten Identifikatorfunktion eine Adresse erzeugt. In dem Backendserver wird der im Rahmen der Authentifizierung übermittelte Namensraum dem jeweiligen Teilnehmer zugeordnet, sodass der Backendserver zu jedem Teilnehmer den zugehörigen Namensraum kennt. Die Zuordnung kann beispielsweise auf Grundlage der ebenfalls übermittelten Teilnehmeridentifikationsinformation oder auf Grundlage weiterer, im Rahmen der Authentifizierung übermittelter Informationen erfolgen. Anschließend wird, analog zu der Maßnahme auf der Seite des Teilnehmers, in dem Backendserver ebenfalls die Adresse auf Grundlage des übermittelten Namensraumes mittels der zweiten Identifikatorfunktion erzeugt. Da die bei diesem Schritt verwendeten Namensräume die gleichen sind, sind auch die jeweiligen Ergebnisse der zweiten Identifikatorfunktion, das heißt die resultierenden Adressen die gleichen. Die erzeugte Adresse kann dem zugehörigen Teilnehmer ebenfalls zugeordnet werden, sodass nicht für jede Kommunikation erneut aus dem Namensraum die Adresse erzeugt werden muss. Bei einer anschließenden Kommunikation nach dem Publisch-Subscribe-Schema wird die Adresse dann zur Adressierung des jeweiligen Teilnehmers, insbesondere in Form eines Topics im Publish-Subscribe-Schema, verwendet.
-
Der Vorteil der Erfindung ist, dass die bei der Kommunikation verwendete Adresse nach Durchlaufen des Verfahrens anonymisiert ist und keinerlei Anhaltspunkte für eine Identität des zugehörigen Teilnehmers geben kann. Nur der jeweilige Teilnehmer und der Backendserver kennen den Namensraum bzw. die daraus erzeugte Adresse. Ein Außenstehender, der der Kommunikation zwischen Teilnehmern und dem Backendserver lauscht, kann keinerlei Zuordnung einzelner Nachrichten zu den jeweiligen Teilnehmern vornehmen. Die Teilnehmer sind nicht mehr erkennbar. Hierdurch wird eine Privatsphäre geschützt und ein Datenschutz, beispielsweise von übermittelten Telemetriedaten, verbessert. Mittels des Verfahrens ist es ferner auch möglich, anonymisierte Schwarmdaten bereitzustellen, beispielsweise Telemetriedaten, welche dann weiter ausgewertet werden können, ohne dass hierbei einzelne Teilnehmer identifizierbar sind.
-
Ein Teilnehmer soll insbesondere einen Kommunikationsteilnehmer bezeichnen. Teilnehmer können insbesondere elektronische Einrichtungen (engl. device), wie beispielsweise Aktoren, Sensoren und/oder Steuerungen, oder auf einer Steuerung ausgeführte Funktionen sein, die Daten erfassen und/oder bereitstellen können oder einen sonstigen Dienst zur Verfügung stellen und hierzu mit dem Backendserver kommunizieren können. Insbesondere muss ein Teilnehmer hierbei nicht notwendigerweise physisch ausgebildet sein, sondern kann auch lediglich virtuell ausgebildet sein, beispielsweise wenn eine Steuerung mehrere Funktionen bereitstellt, welche jeweils als einzelne Teilnehmer kommunizieren können und Daten an einen Backendserver senden und/oder von diesem empfangen können. Jede dieser Funktionen der Steuerung kann dann in der Kommunikation mit dem Backendserver als Teilnehmer auftreten.
-
Das Verfahren und die Anordnung können insbesondere im Rahmen der Vernetzung einer Vielzahl von Sensoren und/oder Aktoren und/oder Steuerungen etc. in Szenarien des Internet-of-Things (loT) eingesetzt werden.
-
Die Teilnehmeridentifikationsinformation ist eine eindeutige Kennzeichnung oder Bezeichnung eines Teilnehmers. Die Teilnehmeridentifikationsinformation kann beispielsweise eine Media Access Control (MAC)-Adresse oder eine Seriennummer etc. des Teilnehmers sein. Ferner kann die Teilnehmeridentifikationsinformation auch eine hieraus erzeugte Information sein.
-
Die erste Identifikatorfunktion ist insbesondere eine Funktion, die eine eindeutige Kennzeichnung des Teilnehmers auf Grundlage der Teilnehmeridentifikationsinformation und einer Zufallsinformation, beispielsweise eines Zeitstempels zum Zeitpunkt der Anwendung der Funktion, ermöglicht. Die erste Indikatorfunktion ist hierbei injektiv. Die erste Indikatorfunktion kann hierbei umkehrbar, das heißt eineindeutig bzw. bijektiv, sein, sodass sich aus dem Ergebnis die Teilnehmeridentifikationsinformation und die Zufallsinformation rekonstruieren lässt. Die erste Indikatorfunktion bedient sich insbesondere zumindest einer Hash-Funktion. Als beispielhafte Funktionen, welche verwendet werden können, seien insbesondere die folgenden genannt: die UUID-Namensraum-Algorithmen, UNIX crypt, Keyed-Hash Message Authentication Codes (HMAC) und PKCS#5 Password-Based Cryptography Specification Version 2.0 (RFC 2898). Es kann auch vorgesehen sein, dass verschiedene Algorithmen miteinander kombiniert werden.
-
Die zweite Identifikatorfunktion ist insbesondere eine Funktion, die einen eindeutigen Identifikator auf Grundlage eines Namensraumes erzeugt. Die zweite Identifikatorfunktion ist hierbei derart ausgebildet, dass ein identisches Element der Urbildmenge stets mit demselben Element der Bildmenge verknüpft ist, d.h. die Funktion ist insbesondere injektiv, sodass das gleiche Element am Eingang stets zu demselben Ergebnis am Ausgang führt. Die zweite Indikatorfunktion darf jedoch nicht als bijektive Abbildung ausgebildet sein. Die zweite Indikatorfunktion bedient sich insbesondere zumindest einer Hash-Funktion. Als beispielhafte Funktionen, welche verwendet werden können, seien insbesondere die folgenden genannt: die UUID-Namensraum-Algorithmen, UNIX crypt, Keyed-Hash Message Authentication Codes (HMAC) und PKCS#5 Password-Based Cryptography Specification Version 2.0 (RFC 2898). Es kann auch vorgesehen sein, dass verschiedene Algorithmen miteinander kombiniert werden.
-
Insbesondere kann vorgesehen sein, dass das Verfahren für sämtliche der Teilnehmer in einem Kommunikationsnetz durchgeführt wird. Der Backendserver hält dann für jeden der Teilnehmer die entsprechende Zuordnung zwischen dem Teilnehmer und der jeweiligen im Verfahren ermittelten Adresse in einer Tabelle vor. Soll mit einem Teilnehmer kommuniziert werden, so kann in der Tabelle nachgeschlagen werden, welche Adresse dem Teilnehmer zugeordnet ist.
-
Es kann hierbei insbesondere vorgesehen sein, dass eine Funktion zum Nachschlagen in dieser Tabelle ausschließlich berechtigten Teilnehmern zur Verfügung gestellt wird. Anderen Teilnehmern bleibt eine Identität der Teilnehmer verborgen.
-
Die Teilnehmer kommunizieren mit dem Backendserver und miteinander über den Backendserver insbesondere über eine drahtlose Kommunikationsverbindung.
-
Insbesondere ist vorgesehen, dass das Verfahren auf der Seite des zumindest einen Teilnehmers mittels einer dem zumindest einen Teilnehmer zugeordneten Steuerung durchgeführt wird.
-
Das Verfahren ist prinzipiell für jede nachrichtenorientierte Vermittlungsfunktion (Message Oriented Middleware, MOM) anwendbar, die einen Publish-Subscribe-Modus unterstützt. Zum Kommunizieren kann insbesondere das Message Queuing Telemetry Transport (MQTT)-Protokoll verwendet werden. Alternativ hierzu können auch das Advanced Message Queuing Protocol (AMQP), das Apache Streaming Text Oriented Messaging Protocol (STOMP) oder ein anderes geeignetes Protokoll verwendet werden.
-
In einer Ausführungsform ist vorgesehen, dass der zumindest eine Teilnehmer in einem Fahrzeug angeordnet ist. Der Backendserver befindet sich dann insbesondere außerhalb des Fahrzeuges. Teilnehmer in dem Fahrzeug können insbesondere Einrichtungen oder Funktionen sein, die Daten erfassen und bereitstellen können oder einen sonstigen Dienst zur Verfügung stellen. Beispiele hierfür sind Sensoren oder Aktoren oder eine Steuerung, welche z.B. Positions- oder Telemetriedaten des Fahrzeugs bereitstellen können.
-
In einer Ausführungsform ist vorgesehen, dass die erste Identifikatorfunktion auf dem Universally Unique Identifier-Standard Version 1 (UUID1) und die zweite Identifikatorfunktion auf dem Universally Unique Identifier-Standard Version 5 (UUID5) basiert. Der Aufbau von UUID1 und UUID5 ist in RFC 4122 spezifiziert. Mittels UUID1 wird ausgehend von der Teilnehmeridentifikationsinformation bzw. Node-ID unter Berücksichtigung eines aktuellen Zeitstempels eine UUID erzeugt. Bei UUID5 wird auf Grundlage eines Namensraumes ein UUID bzw. die Adresse erzeugt. Der Vorteil der Verwendung dieser Identifikatorfunktionen ist, dass diese in der Industrie weitverbreitet sind und deshalb auf einfache und kostengünstige Weise implementiert werden können.
-
In einer weiteren Ausführungsform ist vorgesehen, dass eine Gültigkeitsdauer des erzeugten Namensraumes begrenzt ist oder begrenzt wird. Die Gültigkeitsdauer wird beispielsweise als Zeitraum definiert, beispielsweise mehrere Sekunden, Minuten, Stunden oder Tage. Die Gültigkeitsdauer wird ebenfalls im Rahmen der Authentifizierung bei dem Backendserver an den Backendserver übermittelt. Der Backendserver ordnet die Gültigkeitsdauer dann dem entsprechenden Namensraum zu. Das Definieren einer Gültigkeitsdauer ermöglicht es dem Backendserver, die Zuordnungen der einzelnen Namensräume regelmäßig aufzuräumen. Ist ein Namensraum bzw. die zugehörige Zuordnung nicht mehr gültig, weil der Gültigkeitszeitraum abgelaufen ist, so wird der entsprechende Namensraum bzw. die Zuordnung im Backendserver gelöscht.
-
Durch Zählen der einzelnen Anfragen beim Übermitteln der Namensräume durch einen Teilnehmer kann außerdem eine Begrenzung der möglichen Aliase für diesen Teilnehmer innerhalb eines Zeitraums erreicht werden, wenn mit dem Übermitteln des neuen Namensraums auch eine Autorisierung des neuen Namensraums verbunden wird.
-
In einer weiteren Ausführungsform ist vorgesehen, dass zusätzlich zumindest ein weiterer Namensraum für den zumindest einen Teilnehmer neu erzeugt wird. Insbesondere kann vorgesehen sein, dass für den zumindest einen Teilnehmer vor Ablauf der Gültigkeitsdauer eines Namensraums ein neuer Namensraum erzeugt und im Rahmen einer Authentifizierung an den Backendserver übermittelt wird. Dies kann beispielsweise regelmäßig erfolgen, beispielsweise jedes Mal, wenn der Teilnehmer in Betrieb genommen wird etc. Ist der zumindest eine Teilnehmer beispielsweise in einem Fahrzeug angeordnet, so kann das Verfahren jedes Mal wiederholt werden, wenn das Fahrzeug gestartet wird, das heißt jedes Mal, wenn ein Klemme-15-AN-Ereignis vorliegt.
-
In einer Ausführungsform ist vorgesehen, dass die Teilnehmeridentifikationsinformation des zumindest einen Teilnehmers mittels einer Hashfunktion erzeugt wird. Die Hashfunktion ist praktisch nicht umkehrbar, da die Umkehrfunktion der Hashfunktion nicht eindeutig ist, das heißt es ist praktisch nicht möglich, aus der erzeugten Teilnehmeridentifikationsinformation die Eingangsdaten der Hashfunktion zu rekonstruieren. Hierdurch wird ein Datenschutz weiter verbessert.
-
Insbesondere ist in einer weiterbildenden Ausführungsform vorgesehen, dass die Hashfunktion auf SHA-1 basiert.
-
In einer Ausführungsform ist vorgesehen, dass die Teilnehmeridentifikationsinformation auf Grundlage einer Vehicle Identification Number (VIN) erzeugt wird.
-
In einer weiteren Ausführungsform ist vorgesehen, dass die Teilnehmeridentifikationsinformation auf Grundlage einer Diagnosis Address (DA) des zumindest einen Teilnehmers erzeugt wird.
-
Insbesondere kann vorgesehen sein, dass die Teilnehmeridentifikationsinformation sowohl auf Grundlage der VIN als auch auf Grundlage der DA erzeugt wird. Ein Teilnehmer in einem Fahrzeug lässt sich über die VIN und die DA in der Regel eindeutig identifizieren. Wird die Teilnehmeridentifikationsinformation, welche auch als Node-ID bezeichnet werden kann, auf Grundlage von VIN und DA erzeugt, so kann bei der Kommunikation der entsprechende Teilnehmer direkt adressiert werden. Im Rahmen des Verfahrens kann dann in dem Backendserver eine Zuordnung der einzelnen Namensräume bzw. Adressen für jeden Teilnehmer zu den Tupeln aus VIN und DA der einzelnen Teilnehmer erfolgen. Soll ein Dienst für einen bestimmten Teilnehmer bereitgestellt werden, so kann der Backendserver auf Grundlage des entsprechenden Tupels aus VIN und DA den zugehörigen Namensraum bzw. die zugehörige Adresse (bzw. Topic) ermitteln und den Dienst entsprechend über das Publizieren im Publish-Subscribe-Schema bereitstellen. Das Verfahren ermöglicht demnach das Kommunizieren zwischen Backendserver und Teilnehmern, ohne dass die VIN oder die DA für die Kommunikation in den Metadaten der Nachrichten sichtbar sind. Die Kommunikation erfolgt anonym und lediglich auf Grundlage des mittels der im Verfahren für den entsprechenden Teilnehmer erzeugten Adresse bzw. des erzeugten Topics.
-
Nachfolgend wird die Erfindung anhand bevorzugter Ausführungsbeispiele unter Bezugnahme auf die Figuren näher erläutert. Hierbei zeigen:
- 1 eine schematische Darstellung einer Ausführungsform der Anordnung zum Adressieren von Teilnehmern bei einer Kommunikation;
- 2 ein schematisches Ablaufdiagramm des Verfahrens zum Adressieren von Teilnehmern bei einer Kommunikation zwischen zumindest einem Teilnehmer und einem Backendserver nach einem Publish-Subscribe-Schema.
-
In 1 ist eine schematische Darstellung einer Ausführungsform der Anordnung 1 zum Adressieren von Teilnehmern 2 bei einer Kommunikation 20 zwischen Teilnehmern 2 und einem Backendserver 3 gezeigt. Die Kommunikation 20 zwischen den Teilnehmern 2 und dem Backendserver 3 erfolgt hierbei nach einem Publish-Subscribe-Schema.
-
Die Teilnehmer 2 sind in Fahrzeugen 50 angeordnet, wobei jedes Fahrzeug 50 mehrere Teilnehmer 2 aufweist. Jedem Fahrzeug 50 ist hierbei eine Vehicle Identification Number (VIN) zugeordnet. Innerhalb jedes Fahrzeugs 50 sind den Teilnehmern 2 jeweils eindeutige Diagnoseadressen (Diagnosis Address, DA) zugeordnet. In der Anordnung 1 lassen sich einzelne Teilnehmer 2 über die zugehörige DA und die VIN des jeweils zugehörigen Fahrzeugs 50 eindeutig identifizieren.
-
Die Anordnung 1 ist derart ausgebildet, auf der jeweiligen Seite der Teilnehmer 2 einen Namensraum 10 auf Grundlage einer Teilnehmeridentifikationsinformation 12 des jeweiligen Teilnehmers 2 mittels einer ersten Identifikatorfunktion zu erzeugen und den erzeugten Namensraum 10 an den Backendserver 3 im Rahmen einer Authentifizierung 21 des jeweiligen Teilnehmers 2 bei dem Backendserver 3 zu übermitteln (in 1 ist der Übersichtlichkeit halber jeweils nur die Authentifizierung 21 und die Übermittlung eines einzigen Namensraums 10 für jeweils einen Teilnehmer 2 pro Fahrzeug 50 gezeigt). Ferner wird für jeden der Teilnehmer 2 eine Adresse 11 auf Grundlage des erzeugten Namensraumes 10 mittels einer zweiten Identifikatorfunktion erzeugt. Diese Schritte werden für die einzelnen Teilnehmer 2 jeweils von einer Steuerung 4 durchgeführt, wobei die jeweilige Steuerung 4 in den Fahrzeugen 50 angeordnet ist und den jeweiligen Teilnehmern 2 in diesem Fahrzeug 50 zugeordnet ist.
-
Ferner kann vorgesehen sein, dass eine Gültigkeitsdauer des erzeugten Namensraumes 10 begrenzt ist oder begrenzt wird. Es kann weiter vorgesehen sein, dass in regelmäßigen oder definierten Zeitabständen jeweils ein neuer Namensraum 10 für die Teilnehmer 2 erzeugt wird. Dies erfolgt insbesondere, bevor die Gültigkeitsdauer eines vorher erzeugten Namensraum 10 abgelaufen ist, sodass stets ein aktueller bzw. gültiger Namensraum 10 zur Verfügung steht. Der neue Namensraum 10 wird dem Backendserver 3 im Rahmen einer erneuten Authentifizierung 21 mitgeteilt.
-
Es kann vorgesehen sein, dass die Teilnehmeridentifikationsinformation 12 des zumindest einen Teilnehmers mittels einer Hashfunktion erzeugt wird. Insbesondere kann hierbei vorgesehen sein, dass die Hashfunktion auf SHA-1 basiert.
-
In der in 1 gezeigten Ausführungsform ist vorgesehen, dass die Teilnehmeridentifikationsinformation 12 auf Grundlage der jeweiligen Vehicle Identification Number (VIN) der Fahrzeuge 50 und der jeweiligen DA der Teilnehmer 2 erzeugt wird.
-
Es ist hierbei vorgesehen, dass die erste Identifikatorfunktion auf dem Universally Unique Identifier-Standard Version 1 (UUID1) und die zweite Identifikatorfunktion auf dem Universally Unique Identifier-Standard Version 5 (UUID5) basiert.
-
Der Backendserver 3 ordnet den im Rahmen der Authentifizierung 21 übermittelten und empfangenen Namensraum des jeweiligen Teilnehmers 2 dem jeweiligen Teilnehmer 2 zu. Dies erfolgt beispielsweise durch Zuordnung der ebenfalls im Rahmen der Authentifizierung 21 zu den jeweiligen Teilnehmern 2 übermittelten VINs und DAs zu dem jeweiligen Namensraum 10.
-
Auf Grundlage des jeweils übermittelten Namensraumes erzeugt der Backendserver 3 mittels der zweiten Identifikatorfunktion für jeden Teilnehmer eine Adresse.
-
Sowohl in den Fahrzeugen 50 als auch im Backendserver 3 steht nach Durchführen der beschriebenen Schritte für jeden Teilnehmer 2 in den Fahrzeugen 50 eine eindeutige Adresse 11 für die Kommunikation 20 zur Verfügung. Die jeweils erzeugten Adressen 11 werden anschließend zum Adressieren der jeweiligen Teilnehmer 2 bei der Kommunikation 20 zwischen den Teilnehmern 2 und dem Backendserver 3 verwendet. Da in den Metadaten der Kommunikation 20 nur noch diese Adressen 11 erscheinen, nicht jedoch die VINs und die DAs der einzelnen Teilnehmer 2, kann eine Identität der Teilnehmer 2 bzw. der zugehörigen Fahrzeuge 50 geschützt werden.
-
Obwohl in der gezeigten Ausführungsform die Teilnehmer 2 in Fahrzeugen 50 angeordnet sind, muss dies nicht zwingend der Fall sein. Prinzipiell lässt sich das Verfahren bzw. die Anordnung 1 auch bei einer beliebigen Maschine-to-Maschine-Kommunikation umsetzen. Insbesondere ist ein Einsatz im Rahmen der Vernetzung einer Vielzahl von Sensoren und/oder Aktoren und/oder Steuerungen etc. in Szenarien des Internet-of-Things (IoT) möglich.
-
In 2 ist ein schematisches Ablaufdiagramm des Verfahrens zum Adressieren von Teilnehmern bei einer Kommunikation zwischen zumindest einem Teilnehmer und einem Backendserver nach einem Publish-Subscribe-Schema gezeigt. Ein Teil des Verfahrens wird hierbei auf der Seite des zumindest einen Teilnehmers durchgeführt, ein anderer Teil auf der Seite des Backendservers.
-
Der Verfahrensschritt 100 umfasst die Verfahrensschritte 101 bis 104 und wird auf der Seite des zumindest einen Teilnehmers durchgeführt, beispielsweise mittels einer dem zumindest einen Teilnehmer zugeordneten Steuerung.
-
In einem Verfahrensschritt 101 wird ein Namensraum auf Grundlage einer Teilnehmeridentifikationsinformation des zumindest einen Teilnehmers mittels einer ersten Identifikatorfunktion erzeugt.
-
Es kann hierbei vorgesehen sein, dass die Teilnehmeridentifikationsinformation des zumindest einen Teilnehmers mittels einer Hashfunktion erzeugt wird. Insbesondere kann hierbei vorgesehen sein, dass die Hashfunktion auf SHA-1 basiert.
-
Handelt es sich bei dem zumindest einen Teilnehmer um einen Teilnehmer, der in einem Fahrzeug angeordnet ist, so kann vorgesehen sein, dass die Teilnehmeridentifikationsinformation auf Grundlage einer Vehicle Identification Number (VIN) erzeugt wird.
-
Zusätzlich kann weiter vorgesehen sein, dass die Teilnehmeridentifikationsinformation auch auf Grundlage einer Diagnosis Address (DA) des zumindest einen Teilnehmers erzeugt wird. Der zumindest eine Teilnehmer ist dann über ein Tupel aus VIN und DA bzw. die daraus abgeleitete Teilnehmeridentifikationsinformation eindeutig identifizierbar.
-
Es kann vorgesehen sein, dass die erste Identifikatorfunktion auf dem Universally Unique Identifier-Standard Version 1 (UUID1) basiert. Hierbei wird aus der Teilnehmeridentifikationsinformation und einem aktuellen Zeitstempel ein Identifikator erzeugt, der als Namensraum verwendet wird.
-
In einem Verfahrensschritt 101 wird der erzeugte Namensraum im Rahmen einer Authentifizierung des Teilnehmers bei dem Backendserver an den Backendserver übermittelt. Entsprechend werden im Rahmen der Authentifizierung auch die VI N und die DA des Teilnehmers übermittelt.
-
In einem Verfahrensschritt 103 wird eine Adresse auf Grundlage des erzeugten Namensraumes mittels einer zweiten Identifikatorfunktion erzeugt. Anschließend kommuniziert der zumindest eine Teilnehmer mit Hilfe der erzeugten Adresse.
-
Hierbei kann vorgesehen sein, dass die zweite Identifikatorfunktion auf dem Universally Unique Identifier-Standard Version 5 (UUID5) basiert. Über UUID5 kann aus dem Namensraum ein eindeutiger Identifikator bzw. eine eindeutige Adresse erzeugt werden.
-
Der Verfahrensschritt 200 umfasst die Verfahrensschritte 201 bis 203 und wird im Backendserver durchgeführt.
-
Im Verfahrensschritt 201 ordnet der Backendserver den im Rahmen der Authentifizierung übermittelten Namensraum dem zugehörigen Teilnehmer zu. Für mehrere Teilnehmer entsteht auf diese Weise ein Namensraumregister, das heißt der Backendserver kann den Namensraum für jeden der Teilnehmer ermitteln.
-
Sofern der zumindest eine Teilnehmer eine VIN und eine DA verwendet, werden auch diese im Rahmen der Authentifizierung des Teilnehmers beim Backendserver an diesen übermittelt. In diesem Fall ordnet der Backendserver auch die VIN und die DA dem Namensraum des jeweiligen Teilnehmers zu.
-
Im Verfahrensschritt 202 erzeugt der Backendserver auf Grundlage des übermittelten Namensraumes eine Adresse für den zumindest einen Teilnehmer mittels der zweiten Identifikatorfunktion. Die erzeugte Adresse kann dem zugehörigen Teilnehmer ebenfalls zugeordnet werden, sodass nicht für jede Kommunikation erneut aus dem Namensraum die Adresse erzeugt werden muss.
-
Sofern in Verfahrensschritt 103 UUID5 verwendet wurde, wird diese Funktion auch in Verfahrensschritt 202 verwendet.
-
Anschließend verwendet der Backendserver im Verfahrensschritt 203 die erzeugte Adresse zum Adressieren des zumindest einen Teilnehmers bei der Kommunikation zwischen dem zumindest einen Teilnehmer und dem Backendserver.
-
Es kann vorgesehen sein, dass eine Gültigkeitsdauer des jeweils erzeugten Namensraumes begrenzt ist oder begrenzt wird. Nach Ablauf der Gültigkeitsdauer darf der Namensraum und einer hieraus erzeugte Adresse für den zumindest einen Teilnehmer nicht mehr verwendet werden.
-
Ferner kann vorgesehen sein, dass zusätzlich zumindest ein weiterer Namensraum für den zumindest einen Teilnehmer neu erzeugt wird. Dies kann insbesondere in regelmäßigen Abständen erfolgen, beispielsweise immer, wenn ein Fahrzeug, in dem der zumindest eine Teilnehmer angeordnet ist, gestartet wird (z.B. nach jedem Klemme-15-AN Ereignis). Insbesondere wird ein Namensraum neu erzeugt, bevor die Gültigkeit des vorherigen Namensraum abgelaufen ist. Auf diese Weise steht fortlaufend ein aktueller Namensraum zur Verfügung, aus dem eine aktuelle Adresse zum Kommunizieren mit dem Teilnehmer erzeugt werden kann.
-
Im Folgenden wird eine Ausführungsform des Verfahrens kurz anhand von Segmenten eines Pseudoprogrammcodes erläutert, um die Erfindung zu verdeutlichen. Hierbei wird davon ausgegangen, dass der betrachtete Teilnehmer in einem Fahrzeug angeordnet ist und sich über eine VIN und eine DA eindeutig identifizieren lässt.
-
Aus der VIN und der DA des Teilnehmers wird mittels der bekannten SHA1-Hashfunktion eine Teilnehmeridentifikationsinformation erzeugt, welche als Node-ID bezeichnet wird:
-
Anschließend wird aus der Node-ID mittels des UUID1-Standards als erste Identifikatorfunktion ein Namensraum (namespace) erzeugt:
-
Dieser Namensraum wird wie oben beschrieben im Rahmen der Authentifizierung des Teilnehmers, zusammen mit der VIN und der DA an den Backendserver übermittelt. Dieser ordnet den übermittelten Namensraum im Rahmen einer Authentifizierung dem Teilnehmer bzw. dessen VIN und DA zu.
-
Sowohl auf der Seite des zumindest einen Teilnehmers als auch im Backendserver wird aus dem Namensraum mittels des UUID5-Standards als zweite Indentifikatorfunktion eine Adresse, welche im Publish-Subscribe-Schema als Topic verwendet werden kann, für den Teilnehmer erzeugt:
-
Die erzeugte Adresse bzw. der erzeugte Topic wird anschließend zum Adressieren des Teilnehmers bei der Kommunikation nach dem Publish-Subscribe-Schema verwendet.
-
Der nachfolgende Pseudoprogrammcode zeigt eine beispielhafte Implementierung des Verfahrens mit den entsprechenden Verfahrensschritten in einem Fahrzeug und einem Backendserver, um die Erfindung zu verdeutlichen. Um das Beispiel möglichst einfach zu halten, wird für die zu übermittelnde Nachricht das bekannte JSON-Format verwendet, ohne jedoch den Gegenstand hierdurch einzuschränken. Prinzipiell kann auch ein anderes Format verwendet werden. Die Wahl der Datenrepräsentation in der Nachricht hat keinen Einfluss auf das Verfahren.
-
-
Der oben angegebene Pseudoprogrammcode liefert die folgenden beispielhaften Ergebnisse:
-
Das Ausgabeergebnis des beispielhaften Pseudoprogrammcodes verdeutlicht, dass für den Teilnehmer mit der DA „d0“ im Fahrzeug und im Backend der gleiche Topic („b'43b38368-56be-5e7b-9a1c-88f2684634a5'“) als Adresse erzeugt wird. Nach Erzeugen dieser Adresse kann der Teilnehmer, zu dem das Tupel (VIN = WVWZZZ1JZXW000001, DA = d0) gehört, mittels dieser Adresse bzw. dieses Topics kommunizieren, ohne dass die VIN oder die DA selbst in den Metadaten der Kommunikation erscheint. Die Kommunikation kann anonymisiert stattfinden und ein Außenstehender hat keine Möglichkeit, den Teilnehmer oder das zugehörige Fahrzeug zu identifizieren und der Kommunikation dieses Teilnehmers zuzuordnen.
-
Bezugszeichenliste
-
- 1
- Anordnung
- 2
- Teilnehmer
- 3
- Backendserver
- 4
- Steuerung
- 10
- Namensraum
- 11
- Adresse
- 12
- Teilnehmeridentifikationsinformation
- 20
- Kommunikation
- 21
- Authentifizierung
- 50
- Fahrzeug
- 100-203
- Verfahrensschritte
