In modernen Fahrzeugen sind immer mehr Geräte und Systeme miteinander vernetzt. Viele der Anwendungen, die auf Netzwerkfunktionen innerhalb des Fahrzeugs beruhen, wirken zwar recht unscheinbar – dennoch sind sie von zentraler Bedeutung. Durch die stetig wachsende Zahl elektronischer Steuergeräte (ECU) für Funktionen wie adaptive Geschwindigkeitsregelung, Antiblockiersystem oder Zentralverriegelung haben immer neue Netzwerkstandards und Topologien Einzug in unsere Autos erhalten. Das hat zur Folge, dass verschiedene Standards für die interne Kommunikation zwischen den ECUs berücksichtigt werden müssen, beispielsweise CAN, CAN-FD, FlexRay, LIN, MOST, USB oder LVDS. Dank verschiedener Busvernetzungen ist eine gemeinsame Nutzung von Sensordaten möglich: Bekannte Standards wie CAN oder LIN arbeiten als gemeinsamer Bus, ohne dass ein Wechsel auf Geräteebene (Forwarding) nötig ist. Spätestens bei den komplexen Funktionen, die mit fortschrittlichen Fahrerassistenzsystemen (ADAS) einhergehen, wird aber deutlich, dass heutzutage ein höheres Niveau bei der Datenanbindung nötig ist: Mehr Datendurchsatz bei möglichst geringer Latenz im Netzwerk.
Ethernet als De-facto-Netzwerkprotokoll
Auf der Suche nach dem bestmöglichen Netzwerkansatz für neue Automotive-Plattformen hat sich Ethernet als De-facto-Netzwerkprotokoll herauskristallisiert. Außerhalb der Automotive-Umgebung kann Ethernet auf eine langjährige Erfolgsgeschichte zurückblicken. Zudem reduziert es ganz augenscheinlich die Komplexität von Automotive-Netzwerken. Da die alten Netzwerkprotokolle aber voraussichtlich noch eine Weile in Gebrauch sein werden, müssen diese innerhalb des Ethernet-Ökosystems unterstützt werden. Hier bietet der Standard IEEE1722 die Möglichkeit, bestehende Kommunikationsstandards wie CAN oder LIN in Ethernet-Pakete einzubinden – mit dem Ziel, Ethernet zum primären Automotive-Netzwerk zu machen.
Dank der Anbindung moderner Autos ans Internet können mehr Netzwerkfunktionen innerhalb des Ethernet-Switch bereitgestellt werden. Auf der anderen Seite ergeben sich durch die Anbindung völlig neue Angriffsflächen für Hacker – entsprechend hoch sind die Sicherheitsanforderungen. Um den erforderlichen Schutz zu gewährleisten oder um zusätzliche Funktionen bereitzustellen, müssen die Datenpakete anhand vorher festgelegter Regeln überprüft werden. Die Überprüfung geschieht auf der Basis bestimmter Datenwerte oder Bedingungen.
Ergänzung der IEEE-Standards
In einem herkömmlichen Ethernet-Switch wird die Entscheidung, an welchen Port ein Datenpaket weitergeleitet werden soll, auf der zweiten Ebene (L2) des OSI-Netzwerkmodells getroffen. Falls die Quelladresse (Source Address, SA) des eingehenden Frames zuvor noch nicht bekannt war, wird sie zusammen mit der Eingangsportnummer des Frames in die Adressdatenbank aufgenommen. Befindet sich die Zieladresse (Destination Address, DA) bereits in der Nachschlagetabelle der Bridge, wird das Datenpaket entsprechend weitergeleitet. Anderenfalls findet ein Flooding des Frames statt.
Im Laufe der Jahre haben sich die IEEE-Standards, welche L2-Protokolle wie 802.1 MAC Bridges, VLANs oder die Port-basierte Netzwerkzugangskontrolle steuern, auf die ersten 16 Byte eines Ethernet-Frames konzentriert. Die jüngsten Ergänzungen enthalten zeitkritische Audio-/Video-Broadcast-Netzwerkstandards wie 802.1AS. Darüber hinaus wurden erweiterte Funktionen eingeführt, um die Überprüfung von OSI-L3-Informationen wie IPv4/IPv6-Paketpriorität oder IPv4/IPv6-Snooping zu erleichtern.
Mehr Flexibilität als bisher
Während die genannten Techniken lange genügten, um Ethernet-basierte Automotive-Anwendungen zu entwickeln, ist heute mehr Flexibilität gefragt. Um eine fortschrittliche Paketklassifizierung, Debugging-, Diagnose- und Sicherheitstools implementieren zu können, müssen die Datenpakete in Echtzeit (Wire-Speed) untersucht werden – Stichwort Deep Packet Inspection (DPI). In der Vergangenheit waren Wire-Speed-Paketklassifizierungen auf eine Reihe rechenintensiver Schaltkreise angewiesen, die wertvollen Leiterplattenplatz belegten. Neuere Bauteile, die ursprünglich für Unternehmensvernetzungen entwickelt wurden, sind jedoch in der Lage, solche Klassifizierungen äußerst platzsparend auszuführen – mit Hilfe einer DPI-Engine, die in einem kompakten Gehäuse untergebracht ist.
Die DPI-Engine im Switch-IC 88Q5050 von Marvell basiert auf einem sogenannten Ternary Content-Addressable Memory (TCAM). Bei dieser Technik wird der Inhalt der Paketdaten mit einem vordefinierten Filter verglichen, um mögliche Übereinstimmungen zu finden. Dabei kann für jedes Bit der Wert 0, 1 oder X (für egal) festgelegt werden. Der X-Wert ist nützlich für das Einrichten von Masken, wodurch sich ganze Datenbereiche sehr einfach überprüfen lassen. Je nach Vergleichsergebnis entscheidet die DPI-Engine, welche Aktion ausgeführt werden soll. Typische DPI-Aktionen sind: den Zielport des Pakets ändern, einen Frame verwerfen, einen Frame auf einen anderen Port spiegeln, die Frame- oder Warteschlangenpriorität ändern.
Wird TCAM mit einer breiten parallelen Gatteranordnung innerhalb der Bridge-Pipeline implementiert, unterstützt die Technik eine Wire-Speed-Datenklassifizierung und -modifikation über mehrere Ports hinweg. Abhängig von der Implementierung kann TCAM mit einer festgelegten Anzahl von Bytes innerhalb des Paket-Headers und des Payload-Bereichs arbeiten.
DPI für Debugging und Diagnose
In der Folge werden drei Automotive-Anwendungsfälle für DPI genauer erläutert. Erstes Beispiel: Debugging und Dia-
gnose. Eine Ethernet-basierte On-Board-Diagnose (OBD) wird mit einem 100BASE-TX-Port bei einer Geschwindigkeit von
100 MBit/s durchgeführt. Auf den ersten Blick scheint diese Bitrate für die meisten Anwendungen auszureichen – in der Praxis werden Daten aber mit weit mehr als 100 MBit/s durch voll ausgelastete Switch-Konfigurationen geschleust! Folglich kann die Leistungsfähigkeit des realen Datenflusses nur aufrechterhalten werden, indem nicht alle Frames im Switch gespiegelt und Pakete verworfen werden. In einem alternativen DPI-Setting werden nur diejenigen Frames identifiziert und klassifiziert, die tatsächlich von Interesse sind. Beispielsweise kann man eine DPI-Regel festlegen, wonach alle Ports mit PTP-Nachrichten (Precision Time Protocol) auf den OBD-Port gespiegelt werden – entweder durch den EtherType (0x88F7) oder durch die MSG ID.
Identifizierung gültiger Ethernet-Pakete
Eine weitere DPI-Anwendung ist die Identifizierung gültiger Ethernet-Pakete. Diese Aufgabe kann umfangreiche Rechenressourcen einer im Datenpfad befindlichen CPU beanspruchen. Mit Hilfe von TCAM lässt sich jedoch ganz leicht überprüfen, ob ein beim Ethernet-Switch ankommendes Datenpaket das richtige Format für das Netzwerk aufweist.
In der entsprechenden Abbildung sind die TCAM-Masken so eingestellt, dass sie nur eingehende Pakete mit bestimmten MAC DAs, SAs und VLAN-IDs zulassen. Die Ziele sind 00:01:02:XX:XX:XX (alle MAC-DA-Adressen von 00:01:02:00:00:00 bis 00:01:02:FF:FF:FF); die Quelladressen sind 00:11:22:XX:XX:XX (alle MAC-SA-Adressen im Bereich 00:11:22:00:00:00 bis 00:11:22:FF:FF:FF); die VLAN-IDs sind 0x0XX (alle VLAN-IDs im Bereich 0x000 bis 0x0FF). Pakete, die den Abgleich nicht bestehen, werden entweder gelöscht oder können andere Aktionen auslösen. Übrigens nutzt das gezeigte Beispiel nur L2-Paketinformation. Je nach TCAM-Implementierung können jedoch auch Informationen der L3-, L4- oder noch höherer Ebenen verwendet werden.
Effiziente Routing-Entscheidungen
Im letzten Beispiel sorgt DPI für Routing-Entscheidungen bei Ethernet-Paketen, die Daten mit verschiedenen Standards enthalten. Um bestehende Netzwerkprotokolle wie LIN und CAN in Ethernet-Umgebungen einzubinden, gibt es spezielle Gateways. Sobald die Daten jedoch eingebunden sind, müssen Weiterleitungsentscheidungen getroffen werden. DPI ist ein ideales Verfahren zum Treffen solcher Weiterleitungsentscheidungen. Ist das Format der Pakete gemäß des Standards IEEE1722-2016 definiert, kann TCAM die Art des Pakets (zum Beispiel CAN) erkennen und die CAN_BUS_ID und den CAN_IDENTIFIER verwenden, um entsprechende Routing-Aktionen zu initiieren.
