-
Die vorliegende Erfindung betrifft ein Verfahren zur Einbindung von Schnittstellenvorrichtungen in ein Netzwerk sowie eine Recheneinheit und ein Computerprogramm zu dessen Durchführung.
-
Hintergrund der Erfindung
-
Computernetzwerke sind heute in allen Bereichen der Technik zu finden. Auch im Automobilbereich geht die Entwicklung der Fahrzeugsteuerung zunehmend hin zu einer Vielzahl vernetzter Komponenten, wie etwa verschiedene Steuergeräte, Sensoren, Benutzerschnittstellen und Fahrzeugfunktionen. Dazu werden verschiedene Bussysteme und Technologien genutzt, wie z.B. CAN-Bus oder Ethernet, die auch im Fahrzeug kombiniert werden können.
-
Während für stationäre Computernetzwerke eine gewisse Flexibilität bei Ausstattung, redundanten Komponenten und ähnlichem gegeben ist, spielen im Fahrzeug begrenzte Ressourcen bei gleichzeitig hohen Anforderungen an Geschwindigkeit und Sicherheit der Kommunikation über das Netzwerk eine große Rolle. Um die vorhandenen Ressourcen effizient zu nutzen, werden daher zunehmend Konzepte verwendet, die es ermöglichen, Aufgaben zwischen verschiedenen Steuergeräten zu verteilen und möglichst flexibel zuzuordnen. Dazu zählen beispielsweise die logische Partitionierung des Netzwerks durch mehrere Virtuelle LANs (VLAN) oder das „Software Defined Networking“ (SDN), bei dem Datenebene und Steuerebene durch Verwendung eines zentralen softwarebasierten Controllers entkoppelt werden und die Steuerung zentralisiert wird. Die Steuerebene bestimmt, wohin Daten übermittelt werden sollen, während die Datenebene physisch für die Übermittlung an das festgelegte Ziel dient. Zur Kommunikation zwischen dem Controller und weiterleitenden Netzkomponenten auf der Steuerebene, wie z.B. Switches oder Router, können bei SDN festgelegte Protokolle verwendet werden, wie etwa das OpenFlow-Protokoll.
-
Viele dieser Technologien wurden jedoch ursprünglich unter anderen Voraussetzungen entwickelt und können nicht einfach auf die Anwendung im Fahrzeug und die geforderten Bedingungen übertragen werden.
-
Offenbarung der Erfindung
-
Erfindungsgemäß werden ein Verfahren zur Einbindung von Netzwerkteilnehmern bzw. Schnittstellenvorrichtungen in einem Fahrzeugnetzwerk sowie eine Recheneinheit und ein Computerprogramm zu dessen Durchführung mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
-
Ein solches Verfahren kann insbesondere in einem Netzwerk angewandt werden, welches mindestens einen zentralen softwarebasierten Controller aufweist, welcher eine Datenebene von einer Steuerebene mit mehreren Schnittstellenvorrichtungen logisch trennt. Die Erfindung schafft eine einfache und effiziente Lösung für ein Fahrzeugnetzwerk.
-
Dabei umfasst das Verfahren zunächst ein Empfangen einer ersten Erkennungsnachricht des zentralen Controllers an einem Anschluss einer Schnittstellenvorrichtung. Anschließend wird geprüft, ob innerhalb einer vorgegebenen Zeitspanne vor dem Empfang der ersten Erkennungsnachricht eine frühere Erkennungsnachricht an einem anderen Anschluss der Schnittstellenvorrichtung empfangen wurde, und die erste Erkennungsnachricht wird an alle mit der Schnittstellenvorrichtung verbundenen Netzteilnehmer weitergeleitet, falls keine frühere Erkennungsnachricht innerhalb der vorgegebenen Zeitspanne an einem anderen Anschluss empfangen wurde. Mit diesem Verfahren wird es möglich, eine Broadcast-Nachricht ohne sonstige Adressierung zu verwenden, um neue Teilnehmer in einem SDN-Netzwerk einzubinden, ohne dabei durch redundante Weiterleitungen die Funktionsfähigkeit des Netzwerks zu gefährden. Ein solches Verfahren eignet sich insbesondere für ein Protokoll, welches nur die zweite Schicht des OSI-Modells verwendet, so dass keine höheren Schichten angesprochen werden müssen. Damit kann die erforderliche Komplexität der verwendeten Software, z.B. zwischen Steuergeräten im Fahrzeug, deutlich verringert werden.
-
Gemäß einer bevorzugten Ausführungsform kann der oben beschriebene Prüfungsschritt das Abrufen eines abgespeicherten Zeitpunkts, zu dem die frühere Erkennungsnachricht empfangen wurde, und das Bestimmen einer Zeitspanne umfassen, die zwischen dem abgespeicherten Zeitpunkt und einem Zeitpunkt, zu dem die erste Erkennungsnachricht empfangen wurde, vergangen ist. Entsprechend kann immer dann, wenn eine Erkennungsnachricht weitergeleitet wird, auch der Zeitpunkt abgespeichert werden, zu dem diese Erkennungsnachricht empfangen wurde. Durch einfaches Erfassen und Abspeichern des Empfangszeitpunkts wird es möglich, alle innerhalb eines festgelegten kurzen Zeitfensters empfangenen Erkennungsnachrichten zu verwerfen, um redundante Weiterleitungen zu verhindern.
-
Zusätzlich oder alternativ kann beim Empfangen einer Erkennungsnachricht ein Timer bzw. Zeitglied mit der Dauer der vorgegebenen Zeitspanne gestartet werden. Zur beschriebenen Prüfung des Zeitfensters kann dann einfach geprüft werden, ob momentan ein aktiver Timer einer früheren Erkennungsnachricht vorhanden ist.
-
Ebenso ist es möglich, beim Empfangen einer Erkennungsnachricht einen Timer für die Dauer der vorgegebenen Zeitspanne zu starten und außerdem einen Hinweis auf die empfangene Erkennungsnachricht abzuspeichern. Nach Ablauf des Timers kann dieser gespeicherte Hinweis wieder gelöscht werden. Zur Prüfung, ob innerhalb einer vorgegebenen Zeitspanne vor dem Empfang der ersten Erkennungsnachricht eine frühere Erkennungsnachricht an einem anderen Anschluss der Schnittstellenvorrichtung empfangen wurde, kann dann geprüft werden, ob momentan ein gespeicherter Hinweis auf eine frühere Erkennungsnachricht vorliegt. Falls dies der Fall ist, wurde die neuere Erkennungsnachricht innerhalb des vorgegebenen Zeitfensters empfangen und kann verworfen werden; andernfalls kann sie wie üblich als Broadcast weitergeleitet werden.
-
Falls sich bei der Prüfung ergibt, dass die aktuelle Erkennungsnachricht nicht weitergeleitet werden soll, kann der Timer deaktiviert werden und/oder der gespeicherte Hinweis auf die Erkennungsnachricht gelöscht werden. So wird sichergestellt, dass jeweils das Zeitfenster seit dem ersten Empfangen und Weiterleiten der Erkennungsnachricht geprüft wird.
-
Darüber hinaus kann das Verfahren optional auch das Erfassen des Anschlusses bzw. Ports der Schnittstellenvorrichtung umfassen, auf dem die erste neue Erkennungsnachricht empfangen wurde. Bei der Prüfung des Zeitfensters kann dann beispielsweise auch geprüft werden, ob eine frühere Erkennungsnachricht auf demselben Anschluss eingegangen ist, und falls dies der Fall ist, kann die aktuelle Erkennungsnachricht unabhängig davon weitergeleitet werden, ob sie innerhalb der vorgegebenen Zeitspanne empfangen wurde.
-
Im Übrigen können die Erkennungsnachrichten, die an einer Schnittstelleneinrichtung empfangen und erfasst werden, das Einrichten einer Kommunikationsverbindung zwischen dem zentralen Controller und der Schnittstellenvorrichtung auslösen. Es versteht sich, dass dies vor allem dann gilt, wenn bisher keine gültige Kommunikationsverbindung zu dem Controller aufgebaut wurde. Das Einrichten der Verbindung kann einen Austausch geeigneter Unicast-Nachrichten umfassen und informiert den Controller über das Vorhandensein der Schnittstellenvorrichtung und der angebundenen Netzknoten.
-
Die hier beschriebene Erkennungsnachricht kann dabei mindestens ein Datenelement umfassen, welches angibt, dass die Erkennungsnachricht zur Weiterleitung an andere Netzwerkteilnehmer vorgesehen ist, d.h. dass es sich um eine Broadcast-Nachricht handelt.
-
Eine erfindungsgemäße Recheneinheit, z.B. ein Steuergerät eines Kraftfahrzeugs bzw. ein Switch oder Router in einem Fahrzeugnetzwerk, ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.
-
Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn ein ausführendes Steuergerät noch für weitere Aufgaben genutzt wird und daher ohnehin vorhanden ist. Schließlich ist ein maschinenlesbares Speichermedium vorgesehen mit einem darauf gespeicherten Computerprogramm wie oben beschrieben. Geeignete Speichermedien bzw. Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich. Ein solcher Download kann dabei drahtgebunden bzw. kabelgebunden oder drahtlos (z.B. über ein WLAN-Netz, eine 3G-, 4G-, 5G- oder 6G-Verbindung, etc.) erfolgen.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
-
Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
-
Figurenliste
-
- 1 zeigt ein beispielhaftes Netzwerksystem, in dem Ausführungsformen der Erfindung zur Anwendung kommen können,
- 2 zeigt ein beispielhaftes Sequenzdiagramm für einen Aufbau einer Verbindung zwischen einem Controller und einer Schnittstellenvorrichtung,
- 3 zeigt ein beispielhaftes Sequenzdiagramm für die Überprüfung von Erkennungsnachrichten, und
- 4 zeigt eine Kombination der Schritte aus den 3 und 4.
-
Ausführungsformen der Erfindung
-
1 zeigt ein System, in dem Ausführungsformen der Erfindung angewendet werden können. Dabei sind in einem Kommunikationsnetzwerk 100 mehrere Netzknoten miteinander verbunden. Es kann sich dabei beispielsweise um ein Netzwerk in einem Fahrzeug handeln, mit dem verschiedene Steuergeräte, Sensoren, oder andere Endgeräte für die unterschiedlichsten Fahrzeugfunktionen miteinander zur Datenübertragung und Steuerung verbunden sind, ist jedoch nicht auf ein Fahrzeugnetzwerk beschränkt. Insbesondere kann ein solches Netzwerk auf Grundlage des Ethernet-Standards aufgebaut sein und mittels kabelgebundenen Verbindungselementen mehrere Netzknoten zur Kommunikation miteinander verbinden. Jeder Netzknoten kann eine eindeutige Kennung aufweisen, z.B. eine MAC (media access control)-Adresse im bekannten Format. Diese Kennung kann wiederum unter anderem zur Adressierung in dem Netzwerk verwendet werden.
-
Um verschiedene Netzwerke, Netzwerksegmente oder einzelne Knoten miteinander zu verbinden, können auf bekannte Weise Schnittstellenvorrichtungen verwendet werden, die beispielsweise Daten auf bestimmte Weise an einen oder mehrere Netzknoten oder andere Schnittstellenvorrichtungen weiterleiten können. Zu diesem Zweck werden beispielsweise Hubs, Switches, Bridges oder Router verwendet. Hubs und Repeater dienen als einfache Verteiler auf der Bitübertragungsschicht (Schicht 1) des OSI-Modells, die eingehenden Datenverkehr an angeschlossene Netzknoten weiterleiten, wobei ein Hub als Repeater für mehrere angeschlossene Netzknoten dient. Eine Bridge verbindet zwei Netzwerksegmente auf der Sicherungsschicht (Schicht 2) des OSI-Modells und filtert den über die Bridge geleiteten Datenverkehr, so dass jedes Netzwerksegment nur die Daten empfängt, die für einen Netzknoten innerhalb dieses Segments bestimmt sind. Dadurch wird die Last in den übrigen Segmenten verringert. Switches sind im wesentlichen Bridges, die jedoch mehrere Netzsegmente auf der Sicherungsschicht miteinander verbinden und sind üblicherweise wie Hubs mit mehreren Anschlüssen (Ports) für Netzknoten ausgestattet. Damit sind Switches üblicherweise in der Lage, den Datenverkehr adressbasiert jeweils nur auf den Verbindungen und Anschlüssen weiterzuleiten, für welche die jeweiligen Daten vorgesehen sind. Außerdem können Daten zwischengespeichert werden und nach vorgegebenen Verfahren zu bestimmten Zeiten oder in bestimmter Reihenfolge übermittelt werden, so dass Kollisionen vermieden werden können. Router leiten dagegen Daten auf der Vermittlungsschicht (Schicht 3 des OSI-Modells) weiter und können auch Daten unter Verwendung von TCP/IP- und/oder UDP/IP-Protokollstapeln an andere bzw. von anderen Netzwerksegmenten übermitteln und damit auch mehrere heterogene Netzwerke miteinander verknüpfen. Schnittstellenvorrichtungen können auch mehrere dieser Funktionen übernehmen; beispielsweise kann ein Layer-3-Switch in der Lage sein, sowohl als Switch auf der Sicherungsschicht als auch als Router auf der Vermittlungsschicht zu dienen.
-
Im vorliegenden Beispiel in 1 sind in einem Netzwerk 100 drei oder mehr Schnittstellenvorrichtungen 110, 112, 114 wie Switches oder Router vorgesehen, die miteinander über geeignete Verbindungen kommunizieren können, und die zur Anbindung von Netzwerksegmenten mit einem oder mehreren Netzknoten bzw. Endknoten 130, 132, wie etwa Steuergeräten oder netzfähigen Sensoren in einem Fahrzeug, vorgesehen sind. Insbesondere kann auch jeder Netzknoten einen eigenen Switch 110, 114 aufweisen; ebenso können aber auch an einem Switch mehrere Netzknoten über mehrere Ports verbunden sein. Auf den Netzknoten 130, 132 können optional verschiedene Anwendungen oder Dienste 131, 133 ausgeführt werden. Die Endknoten senden und empfangen zu diesem Zweck über die Schnittstellenvorrichtungen 110, 112, 114 Daten von bzw. an andere Teilnehmer des Netzwerks. Für das Weiterleiten von Daten können die Schnittstellenvorrichtungen über festgelegte Regeln verfügen, die beispielsweise als Tabellen (Switch-Tabelle) definiert und abgespeichert sind. In solchen Tabellen können unter anderem die Adressen bzw. Kennungen angeschlossener Geräte, die Weiterleitungsregeln für bestimmte Daten, und ähnliche Vorgänge festgelegt werden.
-
Das Netzwerk soll dabei nach dem Prinzip des „Software Defined Networking“, SDN, aufgebaut sein, so dass Datenebene (data plane) 140 und Steuerebene (control plane) 150 durch Verwendung eines zentralen softwarebasierten Controllers bzw. einer zentralen Steuereinheit 120 entkoppelt werden und die Steuerung zentralisiert wird. Die Steuerebene bestimmt, wohin Daten übermittelt werden sollen, während die Datenebene physisch für die Übermittlung an das festgelegte Ziel dient.
-
Die Verbindungsrichtungen bzw. logischen Schnittstellen für Steuerebene 150 und Datenebene 140 über den zentralen Controller 120 werden dabei üblicherweise auch in „Southbound“ und „Northbound“ unterschieden, wobei in diesem Fall die Southbound-Schnittstelle 142 die Kommunikation des zentralen Controllers 120 zu den Elementen der Datenebene 140 umfasst, d.h. die Kommunikation mit Schnittstellenvorrichtungen wie Switches/Bridges und Routern 110, 112, 114 des Netzwerks, während die Northbound-Schnittstelle 152 sich auf die Kommunikation auf der Steuerebene 150 zwischen dem zentralen Controller 120 und den Netzknoten 130, 132 bezieht, d.h. die Kommunikation des Controllers 120 mit Anwendungen und das Bereitstellen von Diensten über geeignete Anwendungsschnittstellen 131a, 131b, 133a, 133b (application interface, API) der jeweiligen Netzknoten. Dabei können grundsätzlich auch mehr als ein zentraler SDN-Controller vorhanden sein, die wiederum mit einem Teil der Netzwerkteilnehmer oder mit allen Netzwerkteilnehmern verbunden sein können. Somit kann die zentrale Steuerung auch von mehreren parallelen Controllern übernommen werden, auch wenn im vorliegenden Beispiel nur ein Controller 120 gezeigt ist. Über eine Schnittstellenvorrichtung können statt einzelner Netzknoten 130, 132 auch mehrere Endgeräte, weitere Teil-Netzwerke oder weitere Schnittstellenvorrichtungen angebunden sein. Beispielsweise kann ein zentrales Ethernet-Netzwerk mit mehreren Schnittstellenvorrichtungen vorliegen, wobei eine oder mehrere der Schnittstellenvorrichtungen über geeignete Adapter eine Schnittstelle in ein Netzwerk anderen Typs bieten, z.B. zur Anbindung an einen lokalen CAN-Bus im Fahrzeug. Weitere Details des Software Defined Networking zur Umsetzung der hier beschriebenen Verfahren können beispielsweise dem Artikel „Software Defined Networking (SDN): A Survey“, Security and Communication Networks 2016, S. 5803-5833, John Wiley & Sons Ltd. entnommen werden. Gemäß der vorliegenden Erfindung soll nun in einem solchen SDN-Netzwerk 100 für den Datenverkehr der Southbound-Schnittstelle 142 und die Funktionen der Datenebene 140 ein Protokoll erfolgen, welches bevorzugt vollständig auf der Sicherungsschicht bzw. OSI-Schicht 2 beruhen soll und damit keinen TCP/IP- und/oder UDP/IP-Protokollstapel oder andere Protokolle höherer Schichten benötigt. Die folgenden Ausführungen beziehen sich daher insbesondere auf die Kommunikation der Datenebene 140 bzw. der Southbound-Schnittstelle 142.
-
Der Datenaustausch zwischen dem Controller und den Schnittstellenvorrichtungen kann auf einem Request-Response-Verfahren beruhen. Dabei sendet jeweils eine der beiden Seiten eine Anfrage bzw. Anforderungsnachricht, auf welche von der anderen Seite eine entsprechende Antwortnachricht folgt. Danach kann die nächste Anfrage übermittelt werden. Auf jede Anforderungsnachricht eines Teilnehmers, z.B. des Controllers, wird von der Schnittstellenvorrichtung eine entsprechende Antwortnachricht übermittelt, wobei vor dem Übermitteln der Antwort auch optional weitere Schritte ausgeführt werden können.
-
Dabei können Daten in vorgegebenen Formaten ausgetauscht werden, insbesondere z.B. in Datenframes gemäß dem bekannten Ethernet-Standard IEEE 802.3. Somit kann für einen Datenframe beispielsweise eine feste Größe oder eine feste Maximalgröße festgelegt sein, wobei der Datenframe in verschiedene Datenfelder zu verschiedenen Zwecken aufgeteilt sein kann. Die Datenfelder können ebenso mit fester oder flexibler Länge vorgesehen sein.
-
Außerdem können verschiedene Nachrichtentypen definiert werden, die zu unterschiedlichen Zwecken dienen. Auch für diese Nachrichtentypen können bestimmte Formate und Längen basierend auf den vordefinierten Datenframes festgelegt sein. Beispielsweise können Nachrichten zum Aufbau einer Kommunikationsverbindung ebenso vorgesehen sein wie Fehlernachrichten, Nachrichten zum Verändern von festgelegten Abläufen in der Schnittstellenvorrichtung oder Informationsnachrichten.
-
Die Schnittstellenvorrichtung, die zur Weiterleitung von Datenpaketen in dem Netzwerk vorgesehen sind, können dabei mit Tabellen versehen sein, in denen Einträge für vorgesehene Weiterleitungsabläufe angelegt sind. Diese Einträge können durch den SDN-Controller angewiesen werden und in Reaktion auf eine entsprechende Anforderungsnachricht vom Controller an die Schnittstellenvorrichtung durch die Schnittstellenvorrichtung neu angelegt, gelöscht oder modifiziert werden. Eintreffende Datenpakete können dann, z.B. anhand ihres Headers oder anderer vorgegebener Datenfelder, mit den Einträgen dieser Tabelle verglichen werden, so dass ein Datenpaket, das an einem bestimmten Teilnehmer adressiert ist, korrekt an diesen weitergeleitet werden kann. Ebenso können beim Eintreffen eines Pakets an einer Schnittstellenvorrichtung dynamisch durch Kommunikation mit dem Controller die korrekten Weiterleitungsabläufe abgefragt und festgelegt werden. Damit können beispielsweise die Ports einer Schnittstellenvorrichtung den MAC-Adressen oder ähnlichen Teilnehmerkennungen von Empfängern zugeordnet werden. Solche Tabellen sind beispielsweise aus dem OpenFlow-Protokoll bekannt. Grundsätzlich kann die Verwendung von Weiterleitungsregeln aber auf beliebige Art und Weise stattfinden.
-
Die Anschlüsse (Ports), die von einer Schnittstellenvorrichtung zum Empfang und zur Weiterleitung von Datenpaketen verwendet werden können, können sowohl durch physische Ports der verwendeten Hardware als auch durch logische Ports gebildet werden.
-
Die übrigen Merkmale einer Netzwerk-Kommunikation gemäß dem Ethernet-Standard bzw. dem „Software Defined Networking“ sind im Fach bekannt und werden hier nicht näher beschrieben, z.B. Feldlängen in Datenfeldern, Mechanismen der Paketübertragung, Fehlernachrichten, die Integration von mehreren VLANs oder andere Details. Eine Schnittstellenvorrichtung, welche die hier vorgestellten Verfahren unterstützt, kann dabei zusätzlich auch dazu eingerichtet sein, die Verfahren anderer Protokolle zu unterstützen, z.B. OpenFlow, VLANs oder herkömmliche Ethernet-Switching-Verfahren. Es ist auch möglich, dass bestimmte Anschlüsse bzw. Ports einer solchen Schnittstellenvorrichtung für die Verwendung mit den hier dargestellten Verfahren eingerichtet sind und andere nicht. Außerdem können auch andere als die hier erwähnten Protokolle angewendet oder entwickelt werden.
-
Um Geräte bzw. Netzknoten über ihre zugehörigen Schnittstellenvorrichtungen neu in das Netzwerk einzubinden und eine Kommunikation über die Sicherungsschicht auf Basis der eindeutigen Teilnehmerkennung zu ermöglichen, muss der zentrale Controller in der Lage sein, diese Schnittstellenvorrichtungen automatisch zu erkennen. Zu diesem Zweck kann ein Erkennungsverfahren vorgesehen sein, bei dem über eine Broadcast-Nachricht von dem zentralen Controller an alle Netzwerkteilnehmer eine Erkennungsnachricht übermittelt wird.
-
Abhängig von der verwendeten Netzwerktopologie, d.h. von den Verbindungen der Netzwerkteilnehmer und insbesondere der Schnittstellenvorrichtungen untereinander, könnte dabei jedoch durch die Broadcast-Nachricht eine zumindest teilweise Überlastung des Netzwerks auftreten, da diese definitionsgemäß von jeder Schnittstellenvorrichtung dupliziert und auf allen Ausgängen bzw. Ports weitergeleitet wird. Bei einer redundanten Verbindung zwischen mindestens zwei Schnittstellenvorrichtungen entsteht damit ein sogenanntes Flooding bzw. Fluten, welches zur Überlastung der Switches bzw. Schnittstellenvorrichtungen führt.
-
Zwar existieren im Ethernet-Standard verschiedene Methoden, um ein Flooding zu verhindern, wie etwa das „Spanning Tree Protocol“ (STP) oder verschiedene Varianten davon. Dabei wird dafür gesorgt, dass zu jedem Switch nur ein gültiger Pfad existiert. Da ein großer Teil der Netzkommunikation in einem Fahrzeug jedoch zeit- und sicherheitskritisch ist, sind dadurch entstehende Verzögerungen nicht akzeptabel, so dass diese Protokolle im Fahrzeugbereich nicht eingesetzt werden.
-
Daher wird im Folgenden ein abgeändertes Broadcast-Verfahren erläutert.
-
2 zeigt ein Sequenzdiagramm für eine beispielhafte Ausführungsform eines Erkennungsverfahrens mit einer noch nicht eingebundenen Schnittstellenvorrichtung 210. Dabei wird zunächst von dem zentralen Controller 220 eine Erkennungsnachricht 260 in Form einer Broadcast-Nachricht versendet. Die Einordnung als Broadcast-Nachricht kann dabei beispielsweise, wie im Ethernet-Standard vorgesehen, durch Verwendung einer Broadcast-Adresse (z.B. FF-FF-FF-FF-FF-FF) im MAC-Adressierungsfeld angezeigt werden, es können aber auch andere Methoden genutzt werden, um den Teilnehmern die Erkennung als Broadcast-Nachricht zu ermöglichen. Als Broadcast-Nachricht soll dabei eine Nachricht verstanden werden, die dazu vorgesehen ist, ohne zielgerichtete Adressierung an alle Teilnehmer eines Netzwerks oder Teilnetzwerks übermittelt zu werden.
-
Die Erkennungsnachricht wird dann an jeder der an den Controller 220 angebundenen Schnittstellenvorrichtungen empfangen und verarbeitet.
-
In dem Sequenzdiagramm ist die Kommunikation mit einer dieser Schnittstellenvorrichtungen 210 beispielhaft gezeigt, wobei die Schnittstellenvorrichtung in diesem Fall bisher noch keine aktive Kommunikationsverbindung zu dem SDN-Controller 220 aufweist. Falls die Schnittstellenvorrichtung, die eine Erkennungsnachricht 260 als Broadcast empfangen hat, mit dem hier vorgeschlagenen Protokoll vertraut ist, kann sie die Erkennungsnachricht in Schritt 290 als gültig identifizieren und daraufhin eine Verbindung mit dem Controller 220 aufbauen.
-
Zum Aufbau der Verbindung kann die Schnittstellenvorrichtung zunächst einen neuen Eintrag in der Switch-Tabelle der Schnittstellenvorrichtung mit einer statischen Adressierungsregel erzeugen und anschließend eine der Erkennungsnachricht 260 zugehörige Antwortnachricht 262 von der Schnittstellenvorrichtung 210 zurück an den zentralen Controller 220 senden. Damit wird der Controller über das Vorhandensein der kompatiblen Schnittstellenvorrichtung informiert. Nun kann der Controller 220 aufgrund der empfangenen Eigenschaften der Schnittstellenvorrichtung, z.B. anhand übermittelter Teilnehmerkennungen, in Schritt 292 entsprechende Tabelleneinträge erzeugen, die dann von allen an den Controller angebundenen Teilnehmern genutzt werden können. Bevorzugt kann die Verbindung zwischen der Schnittstellenvorrichtung und dem Controller als reine Unicast-Verbindung eingerichtet werden und geeignete Anforderungs- und Antwortnachrichten 264, 266 umfassen.
-
Um eine Überlastung des Netzes durch mehrfach duplizierte Erkennungsnachrichten zu verhindern, kann jede Schnittstellenvorrichtung, die in der Lage ist, auch Nachrichten weiterzuleiten, prüfen, ob innerhalb einer festgelegten Zeitspanne bereits eine frühere Erkennungsnachricht auf einem anderen Port empfangen wurde. Falls dies der Fall ist, kann die Schnittstellenvorrichtung davon ausgehen, dass es sich um ein Duplikat der bereits erhaltenen Nachricht handelt, und kann festlegen, dass diese Nachricht trotz der Eigenschaft als Broadcast-Nachricht nicht auf ihren übrigen Ports weitergeleitet wird.
-
3 zeigt ein Diagramm mit einem beispielhaften Verfahrensablauf. Dabei wird erneut eine Erkennungsnachricht 360 als Broadcast-Nachricht übermittelt und von der Schnittstelleneinrichtung 310 empfangen. Hier ist vereinfacht nur die Nachricht gezeigt, die von der betrachteten Schnittstellenvorrichtung empfangen wird; es versteht sich aber, dass die Nachricht von dem Controller 320 an alle angeschlossenen Teilnehmer als Broadcast übermittelt wird.
-
Die Schnittstelleneinrichtung 310 kann dann den Eingangsport, auf dem die Erkennungsnachricht eingegangen ist, und/oder den Zeitpunkt des Empfangs der Erkennungsnachricht erfassen und geeignet zwischenspeichern. Dann kann durch Vergleich mit bisher gespeicherten Daten geprüft werden, ob bereits eine frühere Erkennungsnachricht innerhalb der vorgegebenen Zeitspanne empfangen wurde.
-
Falls dagegen bisher keine Erkennungsnachricht empfangen wurde oder falls diese vor längerer Zeit empfangen wurde, kann die Erkennungsnachricht als Broadcast wie üblich dupliziert und über alle Ports oder zumindest über einen definierten Teil der Ports der Schnittstellenvorrichtung als duplizierte Erkennungsnachricht 360a, 360b, 360c weitergegeben werden.
-
Um in den Schritten 394, 395, 396 jeweils zu prüfen, ob eine Erkennungsnachricht innerhalb einer vorgegebenen Zeitspanne mehrfach auf verschiedenen Ports empfangen wurde, kann in Schritt 395 beispielsweise der Zeitpunkt t1 des Empfangs einer aktuellen Erkennungsnachricht 370 mit einem früheren Zeitpunkt t0 einer früheren Erkennungsnachricht 360 verglichen werden, der zu diesem Zweck abgespeichert wurde. Falls zwischen diesen beiden Zeitpunkten t0 und t1 eine Zeitspanne liegt, die kürzer als die vorgegebene Zeitspanne Δt ist, wird das Weiterleiten der Erkennungsnachricht 370 durch die Prüfung in Schritt 395 verhindert und kein weiterer Schritt vorgenommen. Falls zwischen diesen beiden Zeitpunkten dagegen eine Zeitspanne liegt, die größer als die vorgegebene Zeitspanne T ist, kann die Erkennungsnachricht als neue Erkennungsnachricht behandelt werden und entsprechend auf allen anderen Anschlüssen weitergeleitet werden. Dieser Fall ist als weitere Erkennungsnachricht 380 dargestellt, wobei in Schritt 396 geprüft wird, ob die Zeitspanne Δt = t2 - t0 größer ist als eine vorgegebene Zeitspanne T. Da dies hier der Fall sein soll, wird die Erkennungsnachricht 380 erneut dupliziert und die duplizierten Nachrichten 380a, 380b werden an die übrigen Schnittstellenvorrichtungen 312 und 316 weitergeleitet. Entsprechend kann zu diesem Zweck jeweils der Zeitpunkt to, t1, t2 abgespeichert werden, zu dem eine weitergeleitete Erkennungsnachricht empfangen wurde.
-
Alternativ ist es zur Überprüfung der Zeitspanne zwischen zwei Erkennungsnachrichten in den Schritten 394, 395, 396 auch möglich, beim Empfang einer Broadcast-Erkennungsnachricht 360 einen Timer zu starten, welcher der vorgegebenen Zeitspanne entspricht. Falls eine weitere Erkennungsnachricht 370 auf einem anderen Port eintrifft, kann dann geprüft werden, ob aktuell ein aktiv laufender Timer vorliegt, und falls dies der Fall ist, kann die Erkennungsnachricht 370 fallen gelassen und nicht weiter übermittelt werden. Falls dagegen kein Timer aktiv ist, kann die Erkennungsnachricht 380 weitergeleitet werden.
-
Abgewandelt könnte bei Verwendung eines Timers auch vorgesehen sein, dass ein Hinweis auf eine empfangene Erkennungsnachricht 360 abgespeichert wird, und dass nach Ablauf des Timers der Hinweis auf die empfangene Erkennungsnachricht 360 wieder gelöscht wird. Der Hinweis kann in diesem Fall beliebig ausgestaltet werden; beispielsweise kann der Eingangsport der Erkennungsnachricht abgespeichert werden, es eignet sich aber auch jeder andere Dateneintrag, der einen Abgleich zulässt. Auf diese Weise kann beim Eintreffen einer neuen Erkennungsnachricht 370 ohne Zeitstempel geprüft werden, ob momentan ein Hinweis auf eine Erkennungsnachricht abgespeichert vorliegt. Falls dies der Fall ist, ist der Timer noch nicht abgelaufen, so dass also die neue Erkennungsnachricht 370 innerhalb der festgelegten Zeitspanne angekommen ist und wiederum nicht weitergeleitet werden soll. Falls dagegen zu diesem Zeitpunkt kein gespeicherter Eintrag vorliegt, kann die neue Erkennungsnachricht 380 wie vorgesehen als Broadcast auf allen übrigen Ports weiter übermittelt werden.
-
Falls der Eingangsport für die Überprüfung berücksichtigt werden soll, kann zusätzlich geprüft werden, ob die frühere Erkennungsnachricht auf demselben oder auf einem anderen Eingangsport empfangen wurde, und falls die frühere Erkennungsnachricht auf demselben Eingangsport eingegangen ist, kann die neue Erkennungsnachricht unabhängig vom Ablauf der Zeitspanne weitergeleitet werden.
-
Bei diesen Varianten kann der Timer auch jeweils unmittelbar nach dem Empfang einer Broadcastnachricht durch die Schnittstellenvorrichtung gestartet werden und wieder deaktiviert werden, falls die Erkennungsnachricht anschließend nicht weitergeleitet werden soll. Auch ein vorübergehend gespeicherter Hinweis auf eine Erkennungsnachricht kann wieder gelöscht werden, falls nach dem Empfang entschieden wird, dass die Nachricht nicht weitergeleitet werden soll. Damit wird sichergestellt, dass nur Zeiträume seit der ersten Weiterleitung einer Erkennungsnachricht überprüft werden.
-
Die Prüfung der Schnittstellenvorrichtung, ob eine Weiterübermittlung stattfinden soll, kann dabei im Wesentlichen unabhängig von dem in Zusammenhang mit 2 beschriebenen Aufbau einer Unicast-Kommunikation mit dem Controller stattfinden, falls bisher keine solche Kommunikationsverbindung besteht. 4 zeigt beispielhaft beide Teilverfahren kombiniert. Dabei wird analog zu dem Beispiel aus 2 in Reaktion 490 auf eine Erkennungsnachricht 460 durch Übermitteln einer Antwortnachricht 462 eine Verbindung zwischen dem Controller 420 und einer Schnittstellenvorrichtung 410 aufgebaut, wobei der Controller in Schritt 492 zugehörige Tabelleneinträge erzeugen kann, die dann für weitere Nachrichten 464, 466 genutzt werden können. Zusätzlich kann die Schnittstellenvorrichtung 410 die empfangene Erkennungsnachricht 460 in Schritt 494 überprüfen und bei erfolgreicher Prüfung als duplizierte Nachrichten 460a, 460b, 460c an die übrigen Schnittstellen 412, 414, 416 übermitteln.
-
Somit kann die Weiterleitung 460a, 460b, 460c im Wesentlichen parallel stattfinden, oder es kann zuerst zur Verhinderung von Verzögerungen die Prüfung auf Weiterleitung der Broadcast-Nachricht und die bedingte Weiterleitung an andere Teilnehmer stattfinden, und anschließend die weiteren Schritte (z.B. das Übermitteln der Antwortnachricht 462) zum Aufbau der Kommunikationsverbindung mit dem Controller 420 vorgenommen werden. Zur Weiterleitung auf allen Ports als Broadcast müssen der Schnittstellenvorrichtung noch keine Informationen des Controllers vorliegen. Die Prüfung später empfangener Broadcast-Nachrichten 470, 480 in den Schritten 495 und 496 sowie die bedingte Weiterleitung als weitergeleitete Nachrichten 480a, 480b an andere Teilnehmer 412, 416, falls die Zeitspanne seit der ersten Broadcast-Nachricht 460 größer als die vorgegebene Zeitspanne ist, bzw. das Stoppen der Weiterleitung im Fall der Nachricht 470, die innerhalb der vorgegebenen Zeitspanne empfangen wurde, kann analog zu dem mit 3 beschriebenen Beispiel stattfinden und ist hier nur zur Vervollständigung gezeigt.
-
Die vorgegebene Zeitspanne, die für die Prüfung der Weiterleitung der Broadcast-Erkennungsnachricht festgelegt ist, kann optional auch durch die Schnittstellenvorrichtung, durch einen anderen Netzwerkteilnehmer oder durch den SDN-Controller verändert werden, beispielsweise durch eine entsprechende Steuerungsnachricht. Dabei können auch Merkmale wie die Anzahl der Netzteilnehmer oder die erwarteten Verzögerungszeiten beim Empfangen von Nachrichten mitberücksichtigt werden, um die vorgegebene Zeitspanne festzulegen. Insbesondere soll die vorgegebene Zeitspanne einerseits lange genug sein, um auch die Weiterleitung von Broadcast-Nachrichten zu stoppen, die erst nach mehreren anderen Weiterleitungen ankommen; andererseits soll keine Broadcast-Nachricht blockiert werden, bei der es sich möglicherweise bereits um eine neue Broadcast-Nachricht handelt. Falls die Erkennungsnachrichten von dem zentralen Controller in vorgegebenen Zeitabständen ausgesendet werden, kann die vorgegebene Zeitspanne für die Prüfung empfangener Erkennungsnachrichten entsprechend angepasst werden.
-
Optional kann die Schnittstellenvorrichtung in allen Fällen so eingerichtet sein, dass eine weitere Erkennungsnachricht, die auf demselben Port innerhalb der festgelegten Zeitspanne eintrifft, dennoch unabhängig vom Zeitabstand weitergeleitet wird, so dass nur Erkennungsnachrichten verfallen, die innerhalb der vorgegebenen Zeitspanne auf anderen Ports empfangen wurden. Alternativ kann aber auch festgelegt sein, dass Erkennungsnachrichten innerhalb der festgelegten Zeitspanne unabhängig von ihrem Eingangsport nie weitergeleitet werden.
-
Mit den hier beschriebenen Schritten kann also sichergestellt werden, dass eine Erkennungsnachricht so schnell wie möglich alle angeschlossenen Teilnehmer eines Netzwerks erreicht, ohne dabei das Netzwerk durch unnötige Doppelungen zu überlasten.
-
Es versteht sich, dass das hier beschriebene Verfahren auch für andere Broadcast- oder Multicast-Nachrichten in einem solchen Netzwerk angewendet werden kann, falls solche Nachrichten in einem Protokoll für andere Zwecke als zur Erkennung von Teilnehmern vorgesehen sind. Auch die beschriebenen Netzwerkteilnehmer, die verwendeten Protokollstrukturen und Nachrichten sind nur beispielhaft zu verstehen und können im Rahmen der beschriebenen Idee abgewandelt werden. In den vorliegenden Beispielen wurden nur jeweils ein Controller und wenige Schnittstellenvorrichtungen gezeigt; selbstverständlich kann das Verfahren aber auf eine Vielzahl von Schnittstellenvorrichtungen und mehrere Controller in beliebigen Topologien übertragen werden. Während in allen Beispielen zunächst der Empfang einer Broadcast-Nachricht unmittelbar vom Controller beschrieben wurde, kann diese Nachricht natürlich auch indirekt über einen Pfad mit einer oder mehreren dazwischenliegenden Schnittstellenverbindungen erhalten werden.
