Als nächster Schritt in der Fahrzeug-Architektur. Neue Werkzeuge für. Automotive Ethernet l ENGINEERING TOOLS

Transkript

1 10lA UTOMOTIVE FLEXIBLE INTERFACES UND SOFTWAREWERKZEUGE FÜR DIE STEUERGERÄTEENTWICKLUNG Neue Werkzeuge für Automotive Ethernet Schon in diesem Jahr kommt in den ersten Serienfahrzeugen Ethernet als Systemnetzwerk zum Einsatz. Für die Integration werden nun dringend Entwicklungs- und Testwerkzeuge benötigt, mit denen man bestehende Bussysteme wie CAN, LIN, FlexRay und MOST zusammen mit Ethernet- Netzwerken analysieren und testen kann. Welche Anforderungen an diese Werkzeuge gestellt werden, zeigt dieser Beitrag. Als nächster Schritt in der Fahrzeug-Architektur steht die Integration von Ethernet mit den in der Automobilbranche etablierten Technologien CAN, FlexRay, LIN und MOST an. Für diese gibt es funktionierende Entwicklungswerkzeuge, mit denen Entwickler auch heterogene Netzwerke einfach analysieren. Auf der Ethernet-Seite hingegen gibt es zwar brauchbare Standardwerkzeuge aus der Bürokommunikation, diese unterstützen aber nicht die speziellen Physical Layer und IP-Protokolle der Automobilwelt. Daher werden hierfür neue Entwicklungs- und Testwerkzeuge benötigt. Es ist bereits Stand der Technik, im Kraftfahrzeug Kamerabilder mit 100 Mbit/s über eine kostengünstige, ungeschirmte Zweidraht-Leitung zu übertragen. Diese Technologie heißt BroadR-Reach und wird vom Konsortium OPEN Alliance SIG standardisiert [1]. Im nächsten Schritt wird Ethernet als Netzwerk bei Infotainment und bei Fahrerassistenzsystemen schon 2015 zum Einsatz kommen. Manche OEMs sehen Ethernet bereits ab 2018 als Backbone- Technologie [2]. Wie bereits mehrfach in Fachbeiträgen beschrieben [3, 4], bringt Ethernet im automobilen Einsatz insbesondere in der Kombination mit ausgewählten Internetprotokollen (Bild 1, [5]) Flexibilität, Skalierbarkeit und Bilder: Vector

2 ENGINEERING TOOLSl AUTOMOTIVE l11 Bild 1: Neben den aus der Bürokommunikation bekannten Protokollen wie UDP, TCP und IP kommen im automobilen Einsatz auch speziell hierfür optimierte Protokolle zum Einsatz. Diese sind in der ISO CD beschrieben. Kostenvorteile. Weiterhin bietet es die Chance, den bewährten automobilen Entwicklungsprozess mit Vorgehensweisen aus der IT-Welt anzureichern. Automotive Ethernet-Test-Lösung Ethernet im Kraftfahrzeug erfordert allerdings ein Umdenken bei Entwicklern und Testingenieuren. Erstens wird künftig eine klare Domänenarchitektur angestrebt (Bild 2). Darin ist der Backbone nicht mehr als ein Bussystem, sondern als geswitchtes Netzwerk mit mehreren Full-Duplex Verbindungen realisiert. Um damit echtzeitkritische Anwendungen zu realisieren, sind Synchronisierungstechniken auf höheren Protokollschichten oberhalb der Bitübertragungsschicht (Physical Layer) erforderlich, zum Beispiel AVB (Audio Video Bridging, Bild 1). Ebenso steigen mit der neuen Architektur die Anforderungen an die Analyse: Möchte der Entwickler den gesamten Datenverkehr auf dem Backbone gleichzeitig analysieren, muss der Zugriff auf alle Strecken synchronisiert werden (Bild 2, a, b, c, d). Zweitens müssen sich die Entwickler mit neuen, geeigneten Filterstrategien auseinandersetzen, um die enormen Datenmengen zu verarbeiten. Das wird sich noch verschärfen, da Übertragungsraten im Gigabit-Bereich bereits auf der Wunschliste der OEMs stehen. Ein hierfür geeigneter Physical Layer ist mit RTPGE (Reduced Twisted Pair Gigabit Ethernet) bereits in der Entwikklung. Anders als bei einem Bussystem müssen besondere Maßnahmen ergriffen werden, um den Einfluss einer Messung auf das System zu vermeiden. Hier sind einerseits die Entwickler gefordert, die Testbarkeit schon im Systemdesign zu berücksichtigen (Design-to- Test). Andererseits muss der Werkzeughersteller den Einfluss des Interfaces minimieren. Im Folgenden werden verschiedene Messaufbauten für Analyse und Testzwecke vorgestellt, unerwünschte Einflüsse beleuchtet, und es wird gezeigt, wie diese Einflüsse minimiert werden können. Grenzen bisheriger Lösungen Ein naheliegender Weg zur Analyse eines Ethernet-Netzwerkes ist das Verwenden eines zusätzlichen Ports (Monitorport) an den eingesetzten Switches im System (Mirroring). An diesen Monitorport werden alle vom Switch emp-

3 12lA UTOMOTIVE Bild 2: Mögliche Domänenarchitektur zukünftiger IP-Netzwerke im Kraftfahrzeug. Um alle Ethernet-Pakete analysieren zu können, muss die Analyse-Software auf alle Ethernet-Strecken syn- fangenen Pakete weitergeleitet. Dadurch wird zwar der Zugriff auf die ankommenden Datenpakete realisiert, jedoch stehen diese Datenpakete in keinerlei zeitlichem Bezug zueinander es gibt keine Zeitstempel. Außerdem werden oftmals nur gültige Pakete an den Monitorport weitergeleitet, wodurch eine Fehleranalyse schwer fällt. Des Weiteren wird aus Kostengründen im Seriensystem kein zusätzlicher Monitorport am Switch für das Mirroring freigehalten [4]. Steht also kein zusätzlicher Port am vorhandenen Switch zur Verfügung, so kann ein zusätzlicher Switch in eine bestehende Verbindung eingefügt werden. Dieser chronisiert zugreifen. zusätzliche Hop ist jedoch nicht transparent und verursacht eine Verzögerung der gesamten Übertragungsstrecke. Bei Netzwerken, die durch das AVB-Protokoll synchronisiert werden, stört diese dynamische Verzögerung unter Umständen die Zeitsynchronisation. Für diesen Messaufbau kann man prinzipiell auf gängige Tools und Switches aus dem IT-Bereich zurückgreifen. Bei den in der Automobilbranche üblichen BroadR-Reach-Netzwerken ist aber eine Medienkonvertierung auf Standard- Ethernet (IEEE 802.3) notwendig. Außerdem sind diese Werkzeuge aus Sicht der automobilen Netzwerkentwicklung meist Insellösungen ohne Bezug zu den nach wie vor wichtigen und gebräuchlichen Bussystemen. Bild 3: Mögliche Verdrahtung von Ethernet-Interfaces für Analyse oder Restbussimulation. Hierbei ist auch die Synchronität zu bekannten automobilen Bussystemen erforderlich. Transparente Ethernet-Analyse Anstatt einen klassischen Switch als Interface zu verwenden, ist es wünschenswert, das Netzwerk mit einer möglichst transparenten Methode zu überwachen. Hierbei steht im Vordergrund, das System möglichst nicht durch zusätzliche Latenzzeit oder das Ausfiltern fehlerhafter Pakete zu beeinflussen. Dies kann durch einen sogenannten TAP (Test Access Point) erreicht werden (Bild 3), der rein passiv auf dem Physical Layer die Daten abgreift und weiterleitet (Pfad 1 in Bild 4). Hierbei ist die Latenzzeit nicht nur sehr kurz, sondern auch konstant, was vor allem bei der Analyse von AVB-Systemen von Vorteil ist. Eine weitere Methode des transparenten Monitorings ist der Einsatz eines Switches mit AVB-Zeitsynchronisationsunterstützung. Die bei der Weitergabe der Pakete auftretende Latenzzeit wird dann über das AVB-Protokoll kompensiert. Unabhängig davon welche Methode gewählt wird, sind für eine genaue Analyse der Paketdaten genaue Zeitstempel notwendig, die möglichst nahe am Physical Layer genommen werden. Diese Zeitstempel müssen mit anderen Interfaces synchronisiert werden, da oftmals mehr als nur eine Ethernet-Strecke im Fokus der Netzwerkanalyse steht (Bild 2). Ein weiterer wichtiger Punkt ist das transparente Verhalten eines inaktiven Interfaces.

4 ENGINEERING TOOLSl AUTOMOTIVE l13 Wird die Interface-Hardware beispielsweise für eine Messfahrt im Fahrzeug verbaut, muss das Interface in der Lage sein, auch ohne aktive Messapplikation selbständig einen vorkonfigurierten Standalone Mode einzunehmen. Andernfalls bleiben bestimmte Ethernet-Strecken während der Fahrt unterbrochen. TAP mit Stimulation Neben der reinen Datenanalyse muss das Netzwerk oft durch gezieltes Versenden von Paketen getestet werden. Dabei soll wie auch bei der reinen Überwachung die Verbindung zweier Knoten möglichst nicht beeinflusst werden. Das Senden dieser zusätzlichen Pakete kann jedoch nicht auf dem Physical Layer (OSI-Schicht 1) erfolgen, da eine zusätzliche Flusskontrolle notwendig wird, die erst ab der Schicht 2 verfügbar ist. Auch hier entstehen dynamische Latenzzeiten, die gegebenenfalls durch eine Protokollunterstützung, wie zum Beispiel AVB, direkt auf dem Interface kompensiert werden können. Eine Anwendung ist das zusätzliche Senden fehlerhafter Daten zu Testzwekken, während die normale Kommunikation beider Knoten läuft (Pfad 3 in Bild 4). Diese Daten werden entweder direkt von einer Testapplikation, beispielsweise von Vector CANoe.IP, bereitgestellt oder über einen Paketgenerator, der direkt auf dem Interface eine definierte Buslast erzeugt (Pfad 2 in Bild 4). Restbussimulation Gerade beim Entwickeln einzelner Steuergeräte ist die Restbussimulation [6] eine flexible Möglichkeit, um beliebige Szenarien zu testen, bevor Bild 4: Das Ethernet/CAN-Interface VN5610 nimmt in Verbindung mit CANoe.IP/CANalyzer.IP passiv und aktiv an der Kommunikation in Ethernet- Netzwerken teil. Durch eine flexible Konfiguration werden verschiedene Messaufbauten für Analyse- und Testzwecke unterstützt.

5 14lA UTOMOTIVE Steuergeräte in ein reales Netzwerk integriert werden. Dafür ist erstens eine Hardware notwendig, die einen uneingeschränkten und leistungsfähigen Netzwerkzugriff erlaubt. Zweitens muss die Applikation aufgezeichnete oder selbst generierte Daten an die Hardware übergeben können (Pfad 4 in Bild 4). Und drittens muss die Kombination aus Hard- und Software Pakete empfangen, verfälschen und die verfälschten Pakete senden können. Damit wird das Verhalten der Steuergeräte bei konkreten Fehlerfällen, wie zum Beispiel Protokollfehlern, getestet. Wichtige Eigenschaften einer flexiblen Interface-/Software-Kombination Die genannten Messaufbauten zeigen, dass die Analyse von Ethernet-Netzwerken unterschiedliche Anforderungen an die Hard- und Software stellt. Um Interface-Wechsel bei den verschiedenen Messaufbauten zu vermeiden, muss das Interface flexibel als TAP, Konverter oder als Switch mit Zusatzfunktionalität einsetzbar sein. Dabei sind folgende Eigenschaften wünschenswert: Im einfachsten Fall, beim Einsatz des Interfaces als TAP, dürfen durch den TAP selbst nur minimale und genau spezifizierbare Latenzzeiten verursacht werden. Das Interface muss zwischen allen gängigen Medien wie beispielsweise BroadR-Reach, Fast Ethernet, Gigabit Ethernet und zukünftig auch RTPGE konvertieren können. Damit entfallen die bisher verwendeten externen Medienkonverter. Für Testfahrten muss das Interface im Fahrzeug verbaubar sein und darf im ungenutzten Fall das Netzwerk nicht unterbrechen (Standalone Mode). Paketgeneratoren auf Soft- oder Hardware-Ebene sind wichtig, da der automobile Entwicklungsprozess neben der Analyse auch kontrollierte Stimulation erfordert. In Verbindung mit der Simulationssoftware muss das Hardware-Interface für einen oder sogar mehrere virtuelle Netzwerkknoten den realen Medienzugriff ermöglichen (Restbussimulation). Das Analyse- und Simulationswerkzeug muss auf allen interessierenden OSI-Schichten und über alle Protokollebenen hinweg Daten analysieren und manipulieren können. Zur Unterstützung von heterogenen Netzwerken muss das Interface mit allen gebräuchlichen Bussystemen synchronisierbar sein. Der Einsatz von leistungsfähigen Analysewerkzeugen aus der Bürokommunikation in Verbindung mit externen Medienkonvertern ist also oft zu kurz gegriffen. Die genannten Anforderungen sind nur mit spezialisierter Hardware realisierbar, die eng mit der Analyse- und Simulationssoftware verzahnt ist. Eine in der Praxis bereits eingesetzte Kombination ist das Ethernet/CAN-Interface VN5610 von Vector zusammen mit dem Entwicklungswerkzeug CANoe.IP. Diese Lösung ist bereits bei einigen Fahrzeugherstellern und Zulieferern im Einsatz. Ausblick In den nächsten fünf bis zehn Jahren werden wie bisher heterogene Netzwerkstrukturen als Cluster aus etablierten Bussystemen im Fahrzeug zu finden sein. Nach der Kameraanwendung wird Ethernet in weiteren Systemdomänen zum Einsatz kommen und zum Teil andere Bussysteme ablösen. Nach dem Einsatz als Backbone werden die Ethernet- und IP-Technologien in weitere Einsatzgebiete im Fahrzeug vordringen. Für die Entwickler von Fahrzeugnetzwerken wird die Bedeutung von Multibus-Fähigkeit, Restbussimulation und hardware-nahen Zeitstempeln für alle Datenpakete weiter steigen. Die nächsten Entwicklungsschritte bei Vector im Ethernet- und IP-Bereich sind die Unterstützung des Anwenders bei der Signaldarstellung über alle IP-Protokollschichten (Bild 1) hinweg sowie das umfassende Überprüfen der Echtzeit- und serviceorientierten Kommunikation, wie beispielsweise AVB und SOME/IP. (oe) Literatur: [1] OPEN Alliance SIG, [2] Das IP-basierte Bordnetz kommt, Elmar Frickenstein, BMW AG, SEIS Statusseminar, , [3] Ethernet und IP im Kraftfahrzeug: Neue Anforderungen an das Entwicklungswerkzeug durch den Ethernet- und IP-Einsatz, Hans-Werner Schaal, Elektronik automotive April 2012 [4] Herausforderungen von Ethernet-Debugging, Helge Zinner, Oktober 2012 [5] ISO CD (E) vom [6] Schnelle Wege zur Restbussimulation: Virtuelle Netzwerke ohne Programmier-Know-how erstellen, Stefan Albrecht und Peter Decker, Automobil Elektronik Juni 2012 Dipl.-Ing. Hans-Werner Schaal ist Business Development Manager im Bereich IP, Car2x und offener CAN-Protokolle wie J1939 und ISO11783 bei der Vector Informatik GmbH. Dipl.-Ing. (FH) Matthias Schwedt ist FPGA- Entwickler für Ethernet, FlexRay und MOST150 Netzwerk-Interfaces sowie Gesamtprojektleiter für die Ethernet Netzwerk-Interface Familie VN56xx bei der Vector Informatik GmbH. Vector