-
Die vorliegende Erfindung betrifft ein Verfahren zum Betreiben einer Recheneinheit, die zur Kommunikation an einen Bus angebunden ist, innerhalb eines Software-definierten Netzwerks, sowie eine solche Recheneinheit, ein System mit einer solchen Recheneinheit und ein Computerprogramm zu dessen Durchführung.
-
Stand der Technik
-
Moderne E/E-Architekturen in Fahrzeugen werden immer komplexer. Insofern kann ein sog. Software-definiertes Netzwerk (auf engl.: „software designed network“ oder SDN) zum Einsatz kommen. SDN trennt eine Steuerebene bzw. Netzwerksteuerebene von einer Netzwerkdatenebene und ermöglicht somit einer insbesondere zentralen Steuerebene die Konfiguration einer einfachen Datenebene unter Ausnutzung ihres globalen Wissens über das Netzwerk und den entsprechenden Daten-Verkehr. Der Begriff Konfiguration kann hier alles bedeuten, was vom Auffüllen der Weiterleitungstabellen in Ethernet-Switches bis zum Blockieren des Sendens bestimmter CAN-IDs durch Steuergeräte reicht.
-
In einem Software-definierten Netzwerk kann die Steuerebene ihre globale Sicht auf das Netzwerk (erfasst durch Überwachung des Netzwerks) ausnutzen und bessere Entscheidungen zur Netzwerkverwaltung treffen. So kann beispielsweise der kürzeste Pfad auf einer lokalen Kopie einer Netzwerktopologie berechnet werden, anstatt verteilte Algorithmen wie OSPF (Open Shortest Path First) für dieselbe auszuführen. Da die Steuerebene außerhalb der zu kontrollierenden Netzwerkkomponenten gehostet wird, kann sie außerdem leicht geändert oder ersetzt werden, ohne die Netzwerkkomponenten zu beeinträchtigen.
-
Für eine nähere Erläuterung des SDN sei auch auf z.B.
„D. Kreutz, F. M. V. Ramos, P. E. Verissimo, C. E. Rothernberg, S. Azodolmolky and S. Uhlig, „Software-Defined Networking: A Comprehensive Survey", Proceedings of the IEEE, Jan 2015." verwiesen.
-
SDN ist an sich jedoch für die Verwaltung von Netzwerken großer Daten- oder Rechenzentren vorgesehen bzw. entwickelt worden, sodass es für die Verwendung in Fahrzeugen bzw. in Netzwerken in Fahrzeugen, die typischerweise aus heterogenen Netzwerktechnologien bestehen, die von langsamen Bussen wie Controller Area Network (CAN) bis zu schnellem Automobil-Ethernet reichen, angepasst werden muss.
-
Aus „M. Doering and M. Wagner, „Retrofitting SDN to classical in-vehicle networks: SDN4CAN“, 1. KuVS Fachgespräch „Network Softwarization“ - From Research to Application, Oct. 2017.“ ist eine Anpassung des SDN für einen CAN-Bus bekannt und wird dort als SDN4CAN bezeichnet. Hierbei wird vorgeschlagen, ein sog. „forwarding device“, eine Art interne Schnittstelle im Steuergerät, zu verwenden, das als Brücke zwischen den Anwendungen, die auf dem Steuergerät ausgeführt werden, und der eigentlichen CAN-Schnittstelle fungiert. Dieses „forwarding device“ überprüft die von den Anwendungen gesendeten Nachrichten und blockiert oder verzögert die Nachricht bei Bedarf basierend auf von einer Steuerungsebene des SDN (typischerweise auf einem anderen, leistungsfähigen Steuergerät, auch als SDN-Controller, bezeichnet) programmierten Regeln. Diese Regeln sind im Grunde Listen, in denen die CAN-Nachrichten-IDs gespeichert sind, die über den CAN-Bus gesendet und/oder empfangen werden können, sowie eine Datenrate, mit der sie gesendet oder empfangen werden können.
-
Offenbarung der Erfindung
-
Erfindungsgemäß werden ein Verfahren zum Betreiben einer Recheneinheit, sowie eine solche Recheneinheit, ein System mit einer solchen 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.
-
Die Erfindung beschäftigt sich mit einem Verfahren zum Betreiben einer Recheneinheit wie z.B. einem Steuergerät in einem Fahrzeug, die zur Kommunikation an einen Bus wie z.B. einen CAN-Bus angebunden ist, innerhalb eines Software-definierten Netzwerks (sog. SDN, wie eingangs schon erwähnt), bei dem eine oder mehrere Anwendungen auf der Recheneinheit ausgeführt werden. Dabei werden die eine oder mehreren Anwendungen (hierbei kann es sich z.B. um eine Anwendung zur Steuerung eine Brennkraftmaschine handeln, denkbar sind aber auch verschiedene andere Anwendungen, wie sie in Fahrzeugen zum Einsatz kommen, z.B. zur Bremsregelung oder zur Fahrerassistenz) auf der Recheneinheit ausgeführt, und diese eine oder mehreren Anwendungen versenden Nachrichten auf dem Bus und/oder empfangen Nachrichten über den Bus. Dabei wird anhand wenigstens einer in der Recheneinheit hinterlegten Liste für jede Nachricht entschieden, ob und/oder wie (z.B. mit welcher Datenrate) sie versendet bzw. empfangen wird. Dies kann z.B. mit einer internen Schnittstelle oder dergleichen erfolgen, wie sie z.B. eingangs für den CAN-Bus mit dem „forwarding device“ erwähnt wurde.
-
Diese Listen enthalten als Einträge z.B. die IDs der Nachrichten (z.B. CAN-Nachrichten-IDs, die über den Bus gesendet oder empfangen werden dürfen (oder nicht gesendet oder empfangen werden dürften). Zusätzlich können diese Einträge die maximale Rate (Datenrate) enthalten, mit der die entsprechenden Nachrichten gesendet bzw. empfangen werden können (also die Art, wie sie gesendet bzw. empfangen werden). Wenn Nachrichten diese Rate nicht erfüllen, können sie z.B. verzögert oder gelöscht werden (dies kann konfigurierbar ausgestaltet sein). Normalerweise haben Recheneinheiten, die an einen Bus oder Feldbus mit geringer Leistung wie z.B. den CAN-Bus angeschlossen sind, eine begrenzte Rechenleistung und Speicherkapazität (diese ist typischerweise durch den verwendeten Mikrocontroller limitiert). Dies begrenzt die Anzahl und den Umfang der einzelnen Listen bzw. Regeln, die von diesen Recheneinheiten implementiert werden können.
-
Beim erweiterten CAN-Frame-Format z.B. wird die Nachrichten-ID (Nachrichtenkennung) mit 29 Bit dargestellt. Dadurch kann (theoretisch) eine sehr große Anzahl von CAN-Nachrichten (229 ≈ 500 Mio.) im Netzwerk verwendet werden. In einem komplexen Netzwerk z.B. in einem Fahrzeug mit mehreren Anwendungen und Steuergeräten können in der Praxis immer noch mehrere Tausend solcher CAN-Nachrichten nötig sein. Aufgrund der Speicherbeschränkungen in typischen Steuergeräten stehen jedoch nur einige Einträge zum Speichern der für die Kombination von Bus und SDN (z.B. SDN4CAN) erforderlichen Listen zur Verfügung, d.h. ein großer Teil des Speicherplatzes für die Nachrichtenkennung muss statisch konfiguriert werden und kann nicht von der Programmierbarkeit, die das SDN ermöglicht, profitieren.
-
Vor diesem Hintergrund wird nun vorgeschlagen, die wenigstens eine Liste unter Verwendung eines Bloom-Filters zu implementieren (dies kann insbesondere mittels einer weiteren Recheneinheit erfolgen, die zur Kommunikation an den Bus angebunden ist und auf der eine Steuerungsebene des Software-definierten Netzwerks ausgeführt wird, z.B. ein leistungsfähiges Steuergerät im Fahrzeug), wobei dann für jede Nachricht, die von der betreffenden Recheneinheit versendet und/oder empfangen werden soll, unter Verwendung des Bloom-Filters überprüft wird, ob sie in der wenigstens einen Liste enthalten ist.
-
Bei einem sog. Bloom-Filter handelt es sich um eine probabilistische Datenstruktur, die einen Satz von Elementen in einem kompakten Bitvektor (der insbesondere deutlich kleiner als die Liste selbst ist) darstellt. Um diesen Bitvektor zu erzeugen, wird jedes Element aus einer vorhandenen Menge (im vorliegenden Fall z.B. die IDs der Nachrichten) als Eingabe für eine Menge von Hash-Funktionen (Streuwertfunktionen) verwendet, von denen jede einen Index oder eine Position für den Bitvektor ausgibt. Diese Indizes im Bitvektor werden auf 1 gesetzt. Geeignete Hash-Funktionen sind z.B. aus der Gruppe der FNV-Funktionen (Fowler-Noll-Vo) oder Murmur-Hash.
-
Basierend auf diesem Bitvektor kann ein Bloom-Filter die Zugehörigkeitsabfrage für ein Element effizient auflösen. Das zu untersuchende Element (im vorliegenden Fall z.B. die ID der aktuell zu sendenden oder zu empfangenden Nachricht) wird (erneut) mit denselben Hash-Funktionen geprüft. Der Ausgabebitvektor wird mit dem Bloom-Filter (dem zuvor erstellten Bitvektor, der einer Liste der zulässigen Elemente entspricht) verglichen. Wenn eine durch eine Hash-Funktion getroffene Position des getesteten Elements im Bloom-Filter Null ist, so ist die Antwort auf die Zugehörigkeitsabfrage „falsch“. Die Antwort „falsch“ (bzw. „false“) auf die Abfrage (Überprüfung, ob das Element in der Liste enthalten ist) bedeutet, dass das Element definitiv nicht im Bloom-Filter (bzw. der Liste) enthalten ist.
-
Die Antwort „wahr“ (bzw. „true“) hingegen impliziert nur, dass das Element wahrscheinlich in der Liste der Elemente enthalten ist, die durch den Bloom-Filter dargestellt wird, d.h. die Abfrage bzw. Überprüfung kann falsch-positiv sein. Die falsch-positiv-Rate in einem Bloom-Filter kann im Voraus berechnet und anhand der Anzahl der Bits im Bitvektor, der Anzahl der verwendeten Hash-Funktionen und der Anzahl der Elemente, die voraussichtlich durch den Bitvektor dargestellt werden, angepasst werden. Im vorliegenden Fall kann also z.B. die erwähnte weitere Recheneinheit, auf der die Steuerungsebene des Software-definierten Netzwerks ausgeführt wird, den Bloom-Filter und die Hash-Funktionen derart wählen, dass die falsch-positiv-Rate möglichst gering ist. Das globale Wissen, das mit der Steuerungsebene verfügbar ist, ermöglicht es, diesen Mangel des Bloom-Filters (zumindest weitestgehend) zu umgehen.
-
Auf diese Weise kann also die von der betreffenden Recheneinheit noch aufzuwendende Rechen- und/oder Speicherleistung, um zu prüfen, ob bzw. wie eine Nachricht zu senden bzw. empfangen ist, bedeutend reduziert werden, da durch einfache Anwendung des Bloom-Filters auf die betreffende(n) Nachricht(en) entschieden werden kann, ob bzw. wie sie zu empfangen ist bzw. sind.
-
Solche Listen können für jede Recheneinheit im Netzwerk individuell ermittelt werden. Grundsätzlich kann eine solche Liste für eine Recheneinheit ausreichend sein, zweckmäßig können aber auch mehrere sein, z.B. für die Prüfung, ob eine Nachricht gesendet oder empfangen wird und mit welcher Datenrate sie gesendet oder empfangen wird.
-
Während es relativ einfach ist, Elemente zu einer Liste, die durch einen Bloom-Filter dargestellt wird, hinzuzufügen, ist es hingegen typischerweise nicht möglich, Einträge aus einer solchen Liste zu entfernen. Das Setzen der Indizes, die dem zu entfernenden Element im Bitvektor entsprechen, auf „falsch“ kann auch dazu führen, dass andere Elemente unbeabsichtigt aus dem Bitvektor bzw. der Liste entfernt werden.
-
Lösungen für dieses Problem wie ein sog. zählender Bloom-Filter (CBF bzw. „counting Bloom filter“) oder ein sog. invertierbarer Bloom-Filter (IBF bzw. „invertible Boom filter“) erhöhen zwar den Platzbedarf des Bloom-Filters bzw. der Listen, ermöglichen aber das Entfernen von Einträgen. Für z.B. den CBF verwaltet die Steuerebene einen Zähler für jedes Bit des Bitvektors, der die Anzahl von Elementen in der Menge darstellt, die durch das bestimmte Bit repräsentiert werden. Wenn dieser Zähler Null wird, wird das Bit auf null gesetzt. Ein IBF kann zusätzlich die ID des in die Liste aufgenommenen Elements wiederherstellen.
-
Für minimalen Speicherplatzverbrauch und Rechenleistung in einer Recheneinheit kann der Bloom-Filter von der Recheneinheit, auf der die Steuerungsebene des Software-definierten Netzwerks ausgeführt wird (sog. SDN-Controller), von Grund auf neu berechnet werden (d.h. der Bloom-Filter wird neu erzeugt, wenn ein Element zu entfernen ist), oder der SDN-Controller kann intern einen CBF oder IBF verwenden, um ein Element effizient aus der betreffenden Liste zu löschen.
-
Dabei ist zu beachten, dass der SDN-Controller die vollständigen Listen zusammen mit den Bloom-Filtern für alle Recheneinheiten bzw. Steuergeräte im Netzwerk in seinem nichtflüchtigen Speicher speichern sollte. Dies ist jedoch wenig problematisch, da der SDN-Controller typischerweise auf einer leistungsstarken (mikroprozessorbasierten) Plattform, z. B. der „Vehicle Computer“ gehostet bzw. ausgeführt wird.
-
Gegenstand der Erfindung ist außerdem eine Recheneinheit wie z.B. ein Steuergerät eines Fahrzeugs, die dazu eingerichtet ist, an einen Bus wie z.B. einen CAN-Bus angebunden zu werden und darüber zu kommunizieren, die weiterhin dazu eingerichtet ist, eine oder mehrere Anwendungen innerhalb eines Software-definierten Netzwerks auszuführen, und hierbei Nachrichten auf dem Bus zu versenden und/oder über den Bus zu empfangen, die weiterhin dazu eingerichtet ist, anhand wenigstens einer in der Recheneinheit hinterlegten, unter Verwendung einer durch einen Bloom-Filter implementierten Liste für jede Nachricht zu entscheiden, ob und/oder wie sie versendet und/oder empfangen wird, und die weiterhin dazu eingerichtet ist, für jede Nachricht, die versendet und/oder empfangen werden soll, unter Verwendung des Bloom-Filters zu überprüfen, ob sie in der wenigstens einen Liste enthalten ist.
-
Gegenstand der Erfindung ist außerdem ein System mit einer solchen (ersten) Recheneinheit und einer weiteren Recheneinheit, die mittels des Busses mit der (ersten) Recheneinheit verbunden oder verbindbar ist, auf der eine Steuerungsebene des Software-definierten Netzwerks ausführbar ist, und die dazu eingerichtet ist, die wenigstens eine Liste unter Verwendung des Bloom-Filters zu erzeugen und auf der (ersten) Recheneinheit zu hinterlegen.
-
Das erfindungsgemäße System ist bevorzugt, 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. Geeignete 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.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
-
Die Erfindung ist anhand eines Ausführungsbeispiels in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
-
Figurenliste
-
- 1 zeigt schematisch ein Fahrzeug mit erfindungsgemäßen Recheneinheiten in bevorzugten Ausführungsformen.
- 2 zeigt schematisch eine erfindungsgemäße Recheneinheit in einer weiteren bevorzugten Ausführungsform.
- 3 zeigt schematisch einen Ablauf eines erfindungsgemäßen Verfahrens in einer weiteren bevorzugten Ausführungsform.
-
Ausführungsform(en) der Erfindung
-
In 1 ist schematisch und beispielhaft ein Fahrzeug 100 mit erfindungsgemäßen Recheneinheit 110, 120 und 130 in bevorzugten Ausführungsformen dargestellt. Die Recheneinheit 110 ist z.B. als Motorsteuergerät zum Betrieb der Brennkraftmaschine 105 ausgebildet, die übrigen Recheneinheiten 120 und 130 können ebenfalls als Steuergeräte, z.B. für ein Bremsregelsystem und ein Getriebe, ausgebildet sein. Die Recheneinheiten 110, 120 und 130 sind an einen gemeinsamen Bus 150, z.B. einen CAN-Bus, angebunden und können darüber Nachrichten senden und Nachrichten empfangen.
-
Zudem ist eine weitere Recheneinheit 140 vorgesehen, die ebenfalls (mittels einer entsprechenden Schnittstelle) an den Bus 150 angebunden ist, zudem aber auch an ein weiteres Kommunikationssystem wie z.B. Ethernet 155. Bei der Recheneinheit 140 soll vorliegend eine Steuerungsebene 141 eines Software-definierten Netzwerks (SDN) ausgeführt werden, worunter das gesamte Netzwerk im Fahrzeug, umfassend die Recheneinheiten, den Bus 140 und das Ethernet 155, verstanden werden kann. Bei der weiteren Recheneinheit 140 kann es sich um ein leistungsfähiges Steuergerät wie z.B. ein „Vehicle Computer“ handeln.
-
Hinsichtlich einer näheren Erläuterung von SDN sei auf die eingangs genannte Literatur verwiesen, ebenso für die Verwendung des SDN mit einem Bus in z.B. einem Fahrzeug. Auch wenn in der eingangs genannten Literatur oder in der Figur explizit auf den CAN-Bus abgestellt wird, lässt sich das Prinzip für verschiedene Arten von Bussen verwenden und ist nicht auf den CAN-Bus beschränkt. Ebenso ist die vorliegende Erfindung nicht auf Fahrzeuge und deren Steuergeräte beschränkt, auch wenn es sich hierbei um eine besonders bevorzugte Verwendung handelt. Denkbar ist auch die Verwendung in Industrieanwendungen, dort insbesondere mittels Feldbussen verbundenen speicherprogrammierbaren Steuerungen (sog. SPS) oder dergleichen oder auch Netzwerk-Gateways.
-
In 2 ist schematisch eine erfindungsgemäße Recheneinheit in einer weiteren bevorzugten Ausführungsform dargestellt. Beispielhaft handelt es sich um die Recheneinheit 110 aus 1, die zugehörigen Erläuterungen gelten aber entsprechend für die anderen Recheneinheiten.
-
Mittels einer (physischen) Schnittstelle 111 ist die Recheneinheit 110 an den Bus 150 angebunden. Intern sind eine Art interne Schnittstelle 112, eine Zwischenanwendung (bzw. „middleware“) 113 sowie beispielhaft drei Anwendungen 114 vorgesehen, die auf der Recheneinheit 110 ausgeführt werden.
-
Die Anwendungen 114 können nun - über die Zwischenanwendung 113 und die Schnittstelle 111 - Nachrichten (z.B. CAN-Nachrichten, auch als Botschaften bezeichnet), auf dem Bus 150 versenden und vom Bus 150 empfangen. Hierzu ist in der Schnittstelle 112 z.B. eine unter Verwendung eines Bloom-Filters (z.B. mittels der Recheneinheit 140) implementierte Liste 210 vorgesehen, wobei für jede Nachricht, die versendet und/oder empfangen werden soll, unter Verwendung des Bloom-Filters überprüft wird, ob sie in dieser Liste 210 enthalten ist. Damit kann entschieden werden, ob eine bestimmte Nachricht, wie beispielhaft mit 200 bezeichnet, von der Recheneinheit 110 empfangen bzw. versendet werden kann bzw. darf oder nicht.
-
In 3 ist schematisch ein Ablauf eines erfindungsgemäßen Verfahrens in einer weiteren bevorzugten Ausführungsform dargestellt. Zunächst wird eine Liste 210 mittels eins Bloom-Filters implementierte (je nach Bezeichnung kann auch die Liste selbst als Bloom-Filter bezeichnet werden). Bei der Liste 210 handelt es sich um einen Bitvektor, also eine Reihe von Bits, die zunächst alle 0 sind. Die Anzahl der Bits soll n sein, die Positionen bzw. Indizes der Bits sollen mit i=0 bis i=n-1 bezeichnet werden.
-
Nun werden nach und nach Einträge hinzugefügt, die für diejenigen Nachrichten (oder IDs der Nachrichten) stehen, die in der Liste 210 enthalten sein sollen, z.B. um festzulegen, dass diese Nachrichten von der Recheneinheit (wenn sie auf der Liste stehen) empfangen werden sollen. Es versteht sich, dass auf die gleiche Weise auch weitere oder andere Listen erzeugt werden können.
-
Beispielhaft soll die Nachricht 200 bzw. deren ID der Liste 210 hinzugefügt werden. Hierzu werden auf die Nachricht 200 bzw. deren ID eine oder mehrere Hash-Funktionen 220 angewendet. Beispielhaft sollen hierbei für die Nachricht 200 die Positionen i=0 und i=n-2 erhalten werden, die in der Liste 210 dann vom Wert 0 zum Wert 1 geändert werden.
-
Beispielhaft soll dann die Nachricht 201 bzw. deren ID der Liste 210 hinzugefügt werden. Hierzu werden auf die Nachricht 201 bzw. deren ID dieselben Hash-Funktionen 220 angewendet. Beispielhaft sollen hierbei für die Nachricht 201 die Positionen i=1 und eine hier nicht dargestellte Position erhalten werden, die in der Liste 210 dann vom Wert 0 zum Wert 1 geändert werden. Wenn an einer Position schon der Wert 1 vorhanden ist, wird diese nicht mehr geändert.
-
Auf diese Weise können auch weitere Nachrichten bzw. deren IDs der Liste 210 hinzugefügt werden. Eine solche Liste kann dabei individuell für jede relevante, z.B. am Bus angebundene, Recheneinheit erstellt werden. Ebenso können für jede Recheneinheit weitere Listen erstellt werden, wie vorstehend schon erwähnt.
-
Wenn nun während des regulären Betriebs eine Recheneinheit z.B. eine Nachricht empfangen will, wird geprüft, ob diese in der Liste 210 vorhanden ist. Dies erfolgt wieder unter Verwendung des Bloom-Filters und derselben Hash-Funktionen. Beispielhaft soll hier die Nachricht 200 überprüft werden. Hierzu werden auf die Nachricht 200 bzw. deren ID wieder die Hash-Funktionen 220 angewendet, deren Ergebnis die Positionen i=0 und i=n-1 liefert. Wenn nun in der Liste 210 an diesen Positionen der Wert 1 vorhanden ist, so ist die Nachricht 200 bzw. deren ID zumindest mit gewisser Wahrscheinlichkeit in der Liste 210 enthalten. Da im vorliegenden Beispiel die Nachricht 200 bzw. deren ID der Liste 210 hinzugefügt wurde, ist das Ergebnis der Überprüfung hier entsprechend positiv. Wie schon erwähnt, können die Liste (also die Länge des Bitvektors) und die Art und Anzahl der Hash-Funktionen derart gewählt werden, dass bei einem (an sich bekannten) Netzwerk diese Wahrscheinlichkeit nahe 100% liegt.
-
Beispielhaft soll auch für eine Nachricht 205 geprüft werden, ob diese in der Liste 210 vorhanden ist. Dies erfolgt ebenso unter Verwendung des Bloom-Filters. Hierzu werden auf die Nachricht 205 bzw. deren ID wieder die Hash-Funktionen 220 angewendet, deren Ergebnis beispielhaft die Positionen i=2 und i=n liefert. In der Liste 210 ist an diesen Positionen der Wert 0 vorhanden, was bedeutet, dass die Nachricht 205 bzw. deren ID sicher nicht in der Liste 210 enthalten ist, da dann nämlich an beiden Positionen der Wert 1 vorliegen müsste.
-
Um zu entscheiden, dass eine Nachricht bzw. deren ID sicher nicht in der Liste enthalten ist, ist es ausreichend, wenn an einer Position keine 1, sondern eine 0 vorhanden ist. Die Nachricht 205 wird dann entsprechend nicht empfangen.
-
Bei einer festen Anzahl von Listen und Hash-Funktionen erfolgt diese Suche bzw. Überprüfung immer in konstanter Zeit, unabhängig von der Anzahl der vom Bloom-Filter dargestellten Regeln bzw. Listen. Dies ist insofern von Vorteil, als ein Echtzeitverhalten des Systems erreicht werden kann. Um die zulässigen Datenraten für jede der Nachrichten-IDs zu speichern, können mehrere Bloom-Filter bzw. Listen verwendet werden, die jeweils eine bestimmte Grenze einer Datenrate darstellen, z.B. 10.000, 100.000 Nachrichten pro Sekunde usw. Alternativ könnten die erwähnten IBFs verwendet werden, um die Grenze der Datenrate (oder Bandbreitenbeschränkungen) direkt in dem Bloom-Filter bzw. der Liste für eine feinere granulare Steuerung zu speichern, und zwar auf Kosten einer erhöhten Speichergröße des Bloom-Filters. In diesem Fall müsste das in der Liste mittels der Hash-Funktionen hinzugefügte Element erweitert werden, um nicht nur die ID zu enthalten, auf die reagiert werden soll, sondern auch die Regel (mit der Grenze der Bandbreite) zu codieren. Beispielsweise kann die Regeldarstellung in SDN4CAN sehr kompakt sein mit z.B. 3 Byte für kleine Regeln, aber mit z.B. 8 Byte für komplexere Regeln, wodurch die Größe der ID-Summenfelder bestimmt wird. IBFs erfordern mehr Rechenleistung und Speicher auf der Recheneinheit, können jedoch Regeln explizit codieren.
-
Wie bereits erwähnt, hängt die Falsch-Positiv-Rate eines Bloom-Filters von der Anzahl der zum Filter bzw. der Liste hinzugefügten Elemente ab und kann durch Anpassen der Größe der Liste (bzw. des Bitvektors) gesteuert werden. Ein Falsch-Positiv-Ergebnis bedeutet, dass eine Regel auf eine Nachrichten-ID angewendet wird, obwohl die Anwendung dieser Regel nicht beabsichtigt war.
-
Wenn eine Kollision gefunden wird, d.h. ein Falsch-Positiv-Ergebnis auftritt, kann der SDN-Controller die Menge (k) oder die Art der Hash-Funktionen ändern oder die Größe (m) des Bloom-Filters (Länge des Bitvektors) anpassen und erneut auf Falsch-Positiv-Ergebnisse prüfen.
-
Eine Reduzierung oder gar Nullierung einer Falsch-Positiv-Rate ist z.B. auch durch den Einsatz von Ausschlusslisten (sog. „Blacklists“) möglich. Auf der Ausschlussliste vorhandene Einträge werden dann grundsätzlich abgelehnt, auch wenn sie durch den Bloom-Filter akzeptiert werden. Eine Ausschlussliste kann insbesondere durch Testen aller Möglichkeiten gegen den Bloom-Filter und Ermitteln der Falsch-Positiv-Ergebnisse erzeugt werden. Dies ist z.B. bei Protokollen mit einem kleinen ID-Bereich wie dem (normalen) CAN mit nur 11 Bit für die IDs möglich, was bedeutet, dass nur 2048 Elemente überprüft werden müssen. Für 29-Bit-CAN-IDs müssten hingegen in etwa 500 Millionen Einträge überprüft werden, was auch einen leistungsstarken SDN-Controller überfordern dürfte.
-
Da in der Praxis, wie z.B. in einem Fahrzeug, jedoch nicht alle 500 Millionen möglichen IDs verwendet werden und üblicherweise auch alle verwendeten IDs bekannt sind (dies sind in der Regel maximal wenige zehntausend), kann ein Test nur der verwendeten IDs gegen den Bloom-Filter und ein Ermitteln der Falsch-Positiv-Ergebnisse hier dennoch meist durchgeführt werden. Dies schützt jedoch nicht vor Falsch-Positiv-Ergebnissen bei IDs außerhalb des erwarteten ID-Raumes (z.B. durch Attacken oder Fehler).
-
Eine andere Option ist, den ID-Raum auf einen zulässigen Teilbereich einzuschränken. Werden am Beispiel des obigen 29-Bit-CAN nur bis zu 16 Bit (65536) Signale benötigt, so können 13 Bit der CAN ID (z.B. der Prefix) auf einen festen Wert angenommen werden. Alle IDs, deren 13 Bit-Präfix nicht dem definierten Wert entspricht, werden bedingungslos blockiert, auf die anderen 16 Bit wird ein umfassender Falsch-Positiv-Test durchgeführt und das hier beschriebene Verfahren angewendet.
-
Das Grundprinzip der vorliegenden Erfindung ist aber weiterhin erhalten, nämlich, dass aufgrund der geringen Falsch-Positiv-Rate eines Bloom-Filters die Speichermenge für diese Listen viel kleiner ist als das direkte Speichern der Regellisten.
-
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
-
- „D. Kreutz, F. M. V. Ramos, P. E. Verissimo, C. E. Rothernberg, S. Azodolmolky and S. Uhlig, „Software-Defined Networking: A Comprehensive Survey“, Proceedings of the IEEE, Jan 2015.“ [0004]
