Validierung von IP-Netzelementen

Bild 1: Ausschnitt aus einer heterogenen Netzwerkarchitektur mit Ethernet-Netzwerken.Vector Informatik

Ethernet auf Basis von BroadR-Reach ist im Fahrzeug bei Kameraanwendungen schon Realität und wird weitere Anwendungsbereiche erobern. Spezialisierte Entwicklungswerkzeuge ermöglichen sogar die zeitsynchrone Darstellung der Kommunikation heterogener Netzwerke. Um Bandbreiteneffizienz zu ermöglichen, sind automobile IP-Netzwerke – im Unterschied zur statischen CAN-Kommunikation – dynamisch und dienstorientiert aufgebaut. Die Entwicklungswerkzeuge müssen daher auch dienstorientierte Protokolle wie SOME/IP unterstützen.

Einsatz von Dienstprotokollen am Beispiel von SOME/IP

Die Auswahl an Protokollen im Ethernet- und IP-Umfeld ist riesengroß, und es kommt schnell der Gedanke auf, dass es für alle denkbaren Anwendungsbereiche bereits direkt nutzbare Protokolle gibt. Da die Vernetzung im Fahrzeug nicht bei null anfängt, ergeben sich daraus schnell spezifische Anforderungen. Beispielsweise müssen sich die verwendeten Protokolle in bestehende Systeme einfügen. Dazu zählen insbesondere eine gute Integration in Autosar und schnelle Reaktionszeiten, um Verzögerungen im Fehlerfall kurz zu halten. Die BMW AG hat mit SOME/IP ein offenes Protokoll entwickelt und spezifiziert, das die automobilen Anforderungen erfüllt. Eine SOME/IP-Implementierung für den Einsatz in Steuergeräten ist – inklusive TCP/IP-Stack, Service Discovery und BroadR-Reach Ethernet-Treiber – von Vector erhältlich.

Bild 2: SOME/IP bietet eine Schnittstelle zur Applikation.Vector Informatik

SOME/IP bietet Schnittstellen für die dienstorientierte Kommunikation an (Bild 2). Dies unterscheidet es von der reinen Signalkommunikation, die beispielsweise bei CAN üblich ist. SOME/IP unterteilt sich grob in drei Bereiche: Service Discovery (SD), Remote Procedure Call (RPC) und Zugriff auf die Prozessdaten. Das SD erlaubt es, dass Steuergeräte ihre Dienste im Netzwerk finden beziehungsweise anbieten. Die von SD angebotenen Methoden nutzt der Anwender per RPC (Bild 3, Teil A). Zudem besteht die Möglichkeit sich über bestimmte Ereignisse benachrichtigen zu lassen (Bild 3, Teil B). Auf einzelne Prozessdaten greift die Applikation aber frei wählbar mithilfe von Schreib- und Lesefunktionen zu (Bild 3, Teil C). Ziel von SOME/IP ist es, die zur Verfügung stehende Bandbreite optimal zu nutzen und damit eine sehr flexible Kommunikation zu realisieren. Die Beschreibung der Kommunikation und der Signale erfolgt mithilfe von FIBEX 4.1 oder später auch mit den Autosar-Formaten ab der Version 4.1.

Bild 3: SOME/IP bietet verschiedene Zugriffsarten wie RPC, Benachrichtigungen sowie Schreib- und Lesefunktionen.Vector Informatik

Für die Restbussimulation bedeutet SOME/IP das Bereitstellen eines komplexen Protokolls sowie der Middleware mit all seinen Freiheitsgraden. Um die Komplexität für den Anwender so gering wie möglich zu halten, erfolgt die Konfiguration der Restbussimulation weitgehend selbstständig. Dazu kommen die standardisierten Beschreibungsformate wie FIBEX 4.1 oder Autosar zum Einsatz. Dies ermöglicht den direkten Zugriff auf die Signale durch den Anwender. Für das Durchführen von Tests ist aber auch ein manuelles Überschreiben der Konfiguration wünschenswert, um zum Beispiel Fehlerfälle zu provozieren.

Flexibler Netzzugang für das Testwerkzeug

Um die komplexen Aufgaben eines Testwerkzeugs – wie zum Beispiel eine Restbussimulation – möglichst gut auf dem physikalischen Medium umzusetzen, ist ein flexibler und performanter Zugang für die Applikation erforderlich (Bild 4, Restbussimulation). Dabei muss der Entwickler auch Fehlerfälle (zum Beispiel CRC-Fehler) auf dem Netzwerk erzeugen können. Steht die Analyse einer Verbindung zwischen zwei Knoten im Vordergrund, so müssen besondere Maßnahmen ergriffen werden, um einen transparenten und rückwirkungsfreien Zugang zu ermöglichen. Dies ist erforderlich, da Open Alliance BroadR-Reach (OABR) zwar logisch ein Bussystem, elektrisch aber eine Punkt-zu-Punkt-Verbindung ist.

Ein naheliegender Weg ist hierbei das Verwenden eines zusätzlichen Monitorports an den eingesetzten Switches im System. Dieser kann jedoch aus Kostengründen im Seriensystem nicht immer vorgehalten werden. Beim sogenannten Mirroring leitet der Switch alle empfangenen Pakete an den Monitorport weiter. Nachteil dieser Lösung ist zum einen, dass die empfangenen Datenpakete in keinerlei zeitlichem Bezug zueinander stehen, da es keine Zeitstempel gibt. Zum anderen werden oftmals nur gültige Pakete an den Monitorport weitergeleitet, wodurch eine Fehleranalyse schwer fällt.

Ein Medienzugang mit geringem Einfluss auf das zu analysierende Netzwerk stellt ein sogenannter TAP (Test Access Point) dar. Durch diesen TAP lässt sich ein Ethernet-Netzwerk – anders als ein Standard-Switch – transparent analysieren, ohne die Kommunikation zwischen zwei Knoten logisch zu beeinflussen (Bild 4, flexibler TAP). Abhängig von den Anforderungen lässt sich der TAP in zwei unterschiedlichen Modi betreiben:

• Der rein passive Betriebsmodus garantiert eine kurze und konstante Latenzzeit, ermöglicht jedoch lediglich das Mithören auf dem Medium.
• Im aktiven Modus können zusätzliche Daten in eine bestehende Verbindung eingebracht werden. Die aktive Verbindung kann jedoch nicht auf dem Physical Layer (OSI-Schicht 1) erfolgen, da eine zusätzliche Flusskontrolle notwendig ist. Diese ist aber erst ab der Schicht 2 verfügbar. Durch die Flusskontrolle kann jedoch keine konstante Latenzzeit garantiert werden.
• Unabhängig von der gewählten Methode sind für eine genaue Analyse der Paketdaten genaue Zeitstempel notwendig, die möglichst nah am Physical Layer genommen werden. Diese Zeitstempel müssen mit anderen Interfaces synchronisiert werden, da oftmals mehr als nur eine Ethernet-Strecke sowie andere automobile Netzwerke im Fokus der Netzwerkanalyse stehen.
• 

  Bild 4: Das Interface VN5610 kommt in verschiedenen Anwendungsfällen zum Einsatz.Vector Informatik

Auswahl des Entwicklungswerkzeugs

Aufgrund der obigen Überlegungen sollte sich jeder Entwickler bei der Auswahl des Entwicklungswerkzeugs fünf Fragen stellen: Unterstützt das Entwicklungssystem dienstorientierte Kommunikation wie SOME/IP? Verfügt das Entwicklungssystem über Logging und kontrollierte Stimulation mit und ohne Protokollverletzung? Bietet das Entwicklungssystem Zugriff auf typische automobile Netzwerke wie zum Beispiel OABR, CAN, FlexRay und MOST? Ist das Interface flexibel als TAP für Mirroring sowie als Konverter und Switch einsetzbar? Ist das Interface zur Unterstützung von heterogenen Netzwerken mit allen gebräuchlichen Bussystemen und IP-Netzwerken synchronisierbar?

Alle diese Funktionen unterstützt das Entwicklungswerkzeug CANoe.IP mit dem Ethernet/CAN-Interface VN5610 von Vector. Daher ist es bereits bei einigen Fahrzeugherstellern und Zulieferern im Einsatz.

(av)