Glossar

• AUTOSAR

  Die AUTomotive Open System ARchitekture (AUTOSAR) ist ein internationaler Verbund von OEMs und Zulieferern der Automobilindustrie, mit dem Ziel, einen offenen Standard für Software-Architekturen in Kraftfahrzeugen zu etablieren.

  Mitglieder dieses Konsortiums sind unter anderem Daimler und BMW auf Seiten der OEMs sowie Bosch und Continental auf Seiten der Automobilzulieferer. Insgesamt umfasst AUTOSAR zehn Core Partner, 51 Premium Members, 44 Associate Members und drei Development Members.

  Die Architektur der AUTOSAR-basierten Software wird aus Funktionsmodulen zusammengesetzt, die unabhängig von unterschiedlichen Herstellern entwickelt und in einem weitgehend automatisierten Konfigurationsprozess zu einem Projekt zusammengeführt wurde.

  AUTOSAR versteht sich nur als Standardisierungsgremium, das Spezifikationen erarbeitet, allerdings keine verbindlichen Regeln zur Implementierung vorschreibt. Diese wird den einzelnen Anbietern im freien Wettbewerb überlassen.

• CAN-Bus

  CAN ist das am weitesten verbreitete Bussystem im Automobilbereich und wird auch in der Automatisierungstechnik eingesetzt. Der CAN-Bus unterstützt Datenraten von bis zu 1 MBit/s, jedoch werden üblicherweise nur 500 KBit/s genutzt.

  Die Entwicklung begann Anfang der 1980er Jahre bei Bosch, um den Verkabelungsaufwand bei der Vernetzung verschiedener Steuergeräte und Sensoren zu reduzieren. Bisher wurden alle Geräte direkt verkabelt, was riesige Kabelbäume zur Folge hatte. Der CAN-Bus ist speziell auf die Anforderungen der Automobilindustrie abgestimmt (sehr sichere Datenübertragung, geringe Kosten). Seit 1994 ist CAN durch die ISO-Normen 11898-1 bis -3 standardisiert. Diese beschreiben zwei unterschiedliche Physical Layer, CAN High-Speed und CAN Low-Speed. CAN High-Speed unterstützt Datenübertragungsraten von bis zu 1 MBit/s und ist für die Anwendung im Antriebs- und Fahrwerksbereich ausgelegt. CAN Low-Speed ist maximal 125 KBit/s schnell und wird eher für die Komfortelektronik im Innenraum eingesetzt.

  Die Kommunikation über CAN ist ereignisgesteuert, d.h. Nachrichten werden dann gesendet, wenn sie anfallen. Grundsätzlich hat jeder Knoten die gleichen Zugriffsrechte auf den Bus und darf jederzeit senden. Die Priorisierung steckt in der Nachricht. Wichtige Nachrichten erhalten niedrige IDs, weniger wichtige Nachrichten höhere IDs. Kommt es zu Kollisionen, so ist die Nachricht mit der niedrigeren ID und deshalb höheren Priorität bevorzugt (der Knoten mit der höheren ID zieht sich zurück). Ist die Buslast sehr hoch, kann es passieren, dass niederpriore Nachrichten stark verzögert gesendet werden.

  Übertragungstechnik

  Die Signalübertragung in CAN untergliedert sich in zwei Übertragungsarten; diese sind zum einem CAN High-Speed und zum anderen CAN Low-Speed. Beide Übertragungsarten basieren dabei auf einem Differenzsignal bestehend aus zwei Pegeln, der CAN High- und der CAN Low-Datenleitung.

  Bei CAN High-Speed liegt dabei die logische Eins bei ca. 0V differentiell, die logische Null bei 2 V differentiell. CAN Low-Speed verwendet für die logische Eins ca. 5 V differentiell und für die logische Null ebenfalls 2 V differentiell. Bedingt durch die unterschiedlichen Spannungspegel ist eine Kommunikation zwischen CAN High-Speed und CAN Low-Speed jedoch nicht möglich.

• FIBEX

  FIBEX (FIeld Bus Exchange Format) ist ein von ASAM (association for standardization of automation and measuring systems) definiertes XML Datenbank Format zur Beschreibung nachrichtenorientierter Kommunikationssysteme im Automobil.

  FIBEX ermöglicht den Datenaustausch zwischen Softwarewerkzeugen, die mit nachrichtenorientierten Bus-Kommunikationssystemen arbeiten. Es enthält alle Informationen zur Beschreibung kompletter Bordnetze eines Fahrzeuges. Es ist durch die ASAM standardisiert und frei verfügbar. Mit Hilfe von FIBEX können komplexe Kfz-Kommunikationssysteme in einer XML Datei beschrieben werden. Dabei unterstützt es die Beschreibung der folgenden Bussysteme:

  • CAN
  • TTCAN
  • LIN
  • FlexRay
  • MOST

  Durch die Vielseitigkeit von FIBEX, wird die Kommunikation und der Datenaustausch zwischen allen Projektteilnehmern vereinfacht.

• Restbussimulation

  Bei der Entwicklung eines Steuergerätes ist der Test der korrekten Funktionsweise von enormer Bedeutung. Allerdings steht für den Test des Steuergerätes in den wenigsten Fällen das komplette System zur Verfügung. Deshalb ist es notwendig, die Daten der fehlenden Steuergeräte anhand einer sogenannten Restbussimulation (RBS) zu simulieren.

  Die Einsatzmöglichkeiten und Einsatzzeitpunkte einer Restbussimulation in der Fahrzeugentwicklung sind vielseitig. Sie kann bereits zu einem frühen Zeitpunkt für rudimentäre ECU-Tests verwendet werden bis hin zu Teilintegrationstests von Kfz-Netzwerken. Immer dann, wenn nur Teile eines Netzwerkes vorhanden sind und der Rest simuliert werden soll, ist eine Restbussimulation ideal. Fehlende Funktionalitäten jedes beliebigen Steuergerätes können in der RBS simuliert werden.

  Üblicherweise liefert hierfür der OEM das globale Design und die Beschreibung des Systems bis zu der Partitionierung der ECUs. Da ein solches System aus einer Vielzahl von Signalen mit allen Arten von Eigenschaften und Werten besteht, ist es wichtig, die damit zusammenhängende Komplexität zu verringern. Deshalb müssen an erster Stelle die relevanten Signale mit Auswirkung auf die ECU-Anwendung identifiziert werden. Außerdem muss die Konfiguration ein adäquates Timing-Verhalten bieten, um das Echtzeit-Verhalten des gewählten Systems zu ermöglichen.

  FLEXRAY-RESTBUSSIMULATION

  Im Vergleich zu früheren Bussystemen hat FlexRay höhere Übertragungsraten und durch das zeitgesteuerte Zugriffsprinzip (Time Division Multiple Access) ist es zugleich echtzeitfähig. Dies stellt jedoch deutlich höhere Ansprüche an die Entwicklung und den Aufbau eines FlexRay Netzwerkes, wovon auch die FlexRay Restbussimulation (RBS) betroffen ist. Bei einer RBS mit FlexRay müssen Nachrichten zu fest definierten Zeiten gesendet werden. Voraussetzung hierfür ist ein echtzeitfähiges Scheduling.

  Damit ein FlexRay Steuergerät überhaupt Daten sendet, müssen verschiedene Randbedingungen erfüllt sein. Hierzu zählen z.B. das Vorhandensein von mindestens 2 Start-up-Knoten, korrekt berechnete CRC-Algorithmen, originalgetreu gesendete Netzwerkmanagement-Botschaften und Message (Alive)-Counter. All dies muss von einer FlexRay-RBS in Echtzeit berücksichtigt werden. Anders als bei CAN macht es deshalb bei FlexRay deutlich mehr Sinn eine RBS auf einer dedizierten Hardware laufen zu lassen. Durch eine echtzeitfähige Hardwareplattform ist sichergestellt, dass FlexRay Botschaften in ihren vorgesehenen Zeitschlitzen (Slots) gesendet werden.Ein Beispiel für so eine Art von Hardware ist das FlexDevice-L. Durch die vielfältigen Anschlussmöglichkeiten (CAN, FlexRay, LIN, RS232, SPI, CAN-FD, Ethernet, BroadR-Reach) ist diese Hardware in vielen Anwendungsgebieten einsetzbar.

• FlexRay-Bus

  Das FlexRay-Protokoll besteht aus einem statischem und dynamischen Segment, wodurch die Vorteile aus beiden Kommunikationsvarianten TDMA und FTDMA vereint werden. Dabei verwendet der FlexRay-Bus drei unterschiedliche Differenzsignale: Idle, High und Low.

  Bei Bussystemen wird zwischen zeitgesteuerter und ereignisgesteuerter Kommunikation unterschieden. Zeitgesteuerte Kommunikation arbeitet nach dem Prinzip des Time Division Multiple Access (TDMA), bei dem jedem Teilnehmer ein bestimmtes, sich in festen Abständen wiederholendes Zeitfenster (sogenannte Slots) auf dem Bus gewährt wird. Dies garantiert eine deterministische Übertragung der Nachrichten, hat jedoch den Nachteil, dass die Bandbreite nicht effizient genutzt wird: Jedes Zeitfenster ist für einen bestimmten Teilnehmer reserviert, selbst wenn dieser keine Daten überträgt. Hier ist eine ereignisgesteuerte Kommunikation von Vorteil, bei der Teilnehmer nur dann senden, wenn ein Ereignis eintritt, zum Beispiel neue Daten zur Übertragung bereitstehen.

  Eine Abwandlung zeitgesteuerter Kommunikation in Richtung Ereignissteuerung ist das Flexible Time Division Multiple Access (FTDMA) Verfahren, bei dem kurze Slots mit fortlaufender Nummerierung den Teilnehmern zugewiesen werden. Wenn ein Teilnehmer in seinem Slot senden möchte, so vergrößert er diesen Slot, wodurch nachfolgende Slots zeitlich nach hinten verschoben werden. Auf diesem Weg wird eine effizientere Nutzung der Bandbreite erreicht.

  Der FlexRay-Bus setzt beide zeitgesteuerten Kommunikationsvarianten TDMA und FTDMA ein und vereint so die Vorteile beider Konzepte: Deterministische Datenübertragung in einem statischen, sowie Nutzung der zur Verfügung stehenden Bandbreite in einem dynamischen Segment.

  Die Datenübertragung auf einem FlexRay-Bus findet auf zwei physikalisch voneinander getrennten Kanälen mit einer Datenübertragungsrate von je 10 Mbit/s statt. Wenn beide Kanäle redundant betrieben werden, also identische Daten senden, ist sichergestellt, dass bei Ausfall eines Kanals die Kommunikation aufrecht erhalten wird. Alternativ hierzu besteht die Möglichkeit, auf beiden Kanälen unterschiedliche Daten zu übertragen um so Datenraten theoretisch bis zu 20 Mbit/s zu realisieren.

  Übertragungstechnik

  Der FlexRay-Bus benutzt ein Differenzsignal mit drei Pegeln: Idle, High und Low. Die Spannung ist im Idle-Zustand 0 V differentiell. Idle besagt, dass sich keine Nachrichten auf dem Bus befinden. Die logische Eins liegt bei ca. 2 V differentiell, die logische Null bei -2 V differentiell. FlexRay wird an den Enden der Busleitung zwischen Bus Plus und Bus Minus jeweils mit dem Leitungswellenwiderstand terminiert, also ca. 90 Ω. Ein FlexRay-Bus verfügt über zwei Kanäle, wobei eine Übertragung zwischen Kanal A und B nicht möglich ist aufgrund der unterschiedlichen Prüfsumme (CRC) im Nachrichtenheader.

• XML

  Die Extensible Markup Language, abgekürzt XML, ist ein Standard zur Erstellung maschinen- und menschenlesbarer Dokumente in Form einer Baumstruktur. XML definiert dabei die Regeln für den Aufbau dieser Dokumente.

  Für eine konkrete XML-Anwendung müssen die Details der jeweiligen Dokumente spezifiziert werden. Dieses betrifft insbesondere die Festlegung der Strukturelemente und ihre Anordnung innerhalb des Dokumentenbaums.

  XML ist damit ein Standard zur Definition von beliebigen, in ihrer Grundstruktur jedoch stark verwandten Auszeichnungssprachen. Somit kann ein XML-Element ganz unterschiedliche Daten, wie z.B. Texte, Grafiken oder auch abstraktes Wissen beschreiben.

  Ein Grundgedanke hinter XML ist es, Daten und ihre Repräsentation zu trennen, also beispielsweise Wetterdaten einmal als Tabelle und einmal als Grafik auszugeben, aber für beide Anwendungen die gleiche Datenbasis im XML-Format zu nutzen.

Kurzeinführung in FlexRay

• Was ist FlexRay?

  FlexRay ist ein schnelles, deterministisches und fehlertolerantes Bussystem für den Automobileinsatz. Seit dem Jahre 2000 wurde von den Core-Partnern des FlexRay-Konsortiums - BMW, DaimlerChrysler, Motorola (Freescale), Philips Semiconductors (NXP), Bosch, General Motors und Volkswagen - die FlexRay-Spezifikation vorangetrieben, welche derzeit in einen ISO-Standard überführt wird.

  Der Datenaustausch zwischen den verbauten Steuergeräten im Fahrzeug wird heute hauptsächlich über ein CAN-Netzwerk durchgeführt. Die Einführung neuer Technologien sowie stets wachsende Datenaufkommen führen jedoch zu steigenden Anforderungen, insbesondere in Bezug auf die Fehlertoleranz und die Zeitsteuerung bei der Nachrichtenübertragung. FlexRay erfüllt diese erhöhten Anforderungen durch eine Nachrichtenübertragung in festen Zeitfenstern und durch eine fehlertolerante und redundante Übertragung auf zwei Kanälen.

• Physical Layer

  FlexRay arbeitet nach dem Prinzip von TDMA, bei dem die Knoten oder Nachrichten feste Zeitfenster ("Slots") zugeteilt bekommen, in denen sie einen exklusiven Buszugang haben. Diese Zeitfenster wiederholen sich in einem bestimmten Zyklus. Der Zeitpunkt, an dem sich eine Nachricht auf dem Bus befindet, kann dadurch exakt vorausgesagt werden.
  

  

  Abb. 1: Mögliche FlexRay-Topologie mit 2 Kanälen

  Die feste Zuordnung der Knoten oder Nachrichten zu festen Zeitfenstern hat jedoch den Nachteil, dass die Bandbreite nicht voll ausgeschöpft wird. Aus diesem Grund unterteilt FlexRay den Zyklus in statische und dynamische Abschnitte. Am Anfang eines Kommunikationszyklus' befindet sich das statische Segment, in dem jeder Botschaft ein fixes Zeitfenster zugeteilt ist, in dem ein Knoten immer senden muss. Wenn keine Daten vorliegen, wird in diesem Zeitfenster eine leere Nachricht (sogenannter „Nullframe“) gesendet.

  Im nachfolgenden dynamischen Abschnitt werden die Zeitfenster dynamisch zugeteilt. Ein exklusiver Buszugang ist immer nur für eine kurze Zeit möglich (sogenannte "Minislots"). Dieses Zeitfenster wird dann zum Senden einer Nachricht um die dazu benötigte Zeit erweitert. Darauf folgende Nachrichten verschieben sich dadurch nach hinten. Nicht versendete Nachrichten blockieren damit nicht den nachfolgenden Datenaustausch, weil kein Zeitfenster dafür reserviert wird und die weiteren Nachrichten dementsprechend vorrücken.

  

  Abb. 2: Typischer FlexRay-Kommunikationszyklus
  

• Datenübertragungsgeschwindigkeit

  FlexRay kann über zwei physikalisch getrennte Kanäle (A + B) mit einer Datenübertragungsgeschwindigkeit von jeweils 10 Mbit/s kommunizieren. Heute wird in der Praxis allerdings lediglich der Kanal A genutzt. Beide Kanäle sind hauptsächlich für eine redundante und daher fehlertolerante Nachrichtenübertragung geplant. Sie können aber auch unterschiedliche Nachrichteninhalte übertragen; in diesem Fall verdoppelt sich der Datendurchsatz..

• Knoten-Synchronisation

  Zur Umsetzung des Buszugriffsverfahrens benötigen die im Kommunikationsnetzwerk verteilten Knoten eine gemeinsame Zeitbasis. Um die lokalen Uhren der einzelnen Knoten aufeinander abzustimmen, und damit eine globale Zeitbasis zu gewinnen, werden Synchronisationsnachrichten im statischen Teil des Kommunikationszyklus übertragen.

• Struktur eines FlexRay-Knotens

  Ein FlexRay-Knoten besteht aus einem Host-Prozessor, dem FlexRay Communication Controller (CC), dem Bus Guardian (BG) und je Kanal einem Bustreiber (BD). Der FlexRay Communication Controller ist für die Synchronisierung des Knotens mit dem Restnetzwerk zuständig

  

• Topologie eines FlexRay-Netzwerks

  Die Topologie des FlexRay-Netzwerks ist weitestgehend offen. Allerdings findet im Fahrzeug nur die Daisy-chain-Verbindung und der Aktive Stern Verwendung.

  Der Aktive Stern ist ein aktiver Knotenpunkt, der Nachrichten an einem Zweig erhält und diese per Broadcast, ähnlich einem Hub, an die anderen Zweige verteilt.

  Unter einer Daisy-Chain Verbindung versteht man lediglich das Durchschleifen einer FlexRay-Leitung von einem Knoten zum anderen.

• WakeUp, StartUp

  Ein Wakeup kann entweder über das FlexRay-Netzwerk oder lokal durch das Einschalten eines Knoten geschehen, wodurch sich dieser initialisiert.

  Anders wie beim CAN-Netzwerk startet die Kommunikation des FlexRay-Netzwerks nicht direkt nach dem Wakeup. Zum Aufstarten eines FlexRay-Netzwerks muss zuerst ein Startup-Vorgang durch sogenannte Coldstart Knoten (dies sind Knoten, welche einen FlexRay-Netzwerkstart initiieren dürfen) mit Startup-Nachrichten durchlaufen werden.

• Datenbankformat

  Beim CAN-Netzwerk nutzt man üblicherweise eine *dbc-Datei als Kommunikationsmatrix. Das FlexRay-Netzwerk mit allen seinen Knoten einschließlich deren Kommunikation wird entweder in FIBEX oder AUTOSAR beschrieben.

  Beim FIBEX Format handelt es sich um eine XML-Datei zur Beschreibung von kompletten Fahrzeugnetzwerken, einem freien Standard, definiert durch ASAM e.V., Das FIBEX-Format ermöglicht die vollständige Beschreibung von FlexRay-, CAN-, MOST- sowie LIN-Netzwerken, inklusive aller Gateway-Verbindungen im Fahrzeug untereinander, in einer Datei.

  AUTOSAR beschreibt ebenfalls die Kommunikation ähnlich dem FIBEX Standard, ergänzt dies jedoch um weitere Informationen zu Funktionen und Verhalten der Steuergeräte. Daher ist auch eine Konvertierung von AUTOSAR nach FIBEX möglich.

Kurzeinführung automobiles Ethernet

• Herausforderung Ethernet als automobiler Bus

  Ein neuer Trend in der Vernetzung von Steuergeräten in Kraftfahrzeugen ist die Verwendung von Ethernet. Klassische Bussysteme im automobilen Umfeld, wie beispielsweise MOST, FlexRay und CAN werden durch Ethernet abgelöst. Das neue Bussystem ist für Entwickler von Vernetzungslösungen im Kraftfahrzeugbereich mit einigen Herausforderungen verbunden. Das beginnt mit der physikalischen Übertragungsschicht, die sich vom klassischen Ethernet unterscheidet und endet mit der Einführung von neuen Übertragungsprotokollen auf höheren Schichten.

  Der Umstieg auf Ethernet in der Fahrzeug-Vernetzung hat mehrere Vorteile. Zum einem werden Kosten gesenkt. Dies betrifft unter anderem die Ausgaben für Bauteile im Fahrzeug. So ist die Verkabelung für eine Ethernet-Verbindung günstiger als eine optische Leitung für den Einsatz von MOST. Zum anderen kann auf vorhandene, günstige Tools aus der bestehenden PC- und Industrie-Ethernet-Welt zurückgegriffen werden. Ein weiterer Vorteil ist die größere Datenübertragungsrate, die einige neue Anwendungsfelder ermöglicht.

• Anwendungsfälle für Ethernet in der automobilen Vernetzung

  Für Ethernet im automobilen Umfeld gibt es verschiedene Anwendungsfälle. Eine der ersten Einsatzoptionen wird die Übertragung von Fahrzeug-Kameradaten. Der Vorteil von Ethernet ist, dass Netzwerkkameras (IP-Kameras) nicht nur mit einem Steuergerät verbunden werden, sondern dass mehrere Steuergeräte auf die Datenströme der Fahrzeug-Kameras zugreifen können. Das Netzwerk wird dadurch sehr flexibel und ist für die Zukunft gut gerüstet. So kann eine Anwendung entwickelt werden, die über mehrere Kameras ein Top-View-Bild der Fahrzeug-Umgebung liefert.

  Für spätere Erweiterungen können zusätzliche Steuergeräte ebenfalls auf die bereits vorhandenen Kameradaten zugreifen. Toolhersteller im Bereich der Busanalyse stehen im Fall von IP-Kameras vor neuen Herausforderungen. Bisher muss für klassische Bussysteme wie CAN eine Datenbank eingebunden werden, um die Rohdaten auf dem Bus zu dekodieren und damit für den Menschen lesbar zu machen.

  Für Ethernet-Daten, die von Fahrzeug-IP-Kameras kommen, muss der Datenstrom analysiert werden, um das zugehörige Bild darstellen zu können (Bild 1).

  Das heißt: Ab dem Anfang eines Bildes müssen alle Ethernet-Nachrichten bis zum Ende des Bildes zwischengespeichert werden. Anschließend lässt sich aus allen zwischengespeicherten Ethernet-Nachrichten das Bild des automobilen Umfelds generieren.

  

  Bild 1:Busanalysesoftware Caromee mit der Darstellung von Bildern die von IP-Kameras kommen. Zusätzlich können noch weitere Busse wie CAN und FlexRay analysiert werden.

  Ein weiterer wichtiger Anwendungsfall ist das schnelle Flashen von Steuergeräten. Durch das Flashen über Ethernet verkürzen sich die Flash-Zeiten signifikant. Kann ein CAN-Bus nur Daten mit einer maximalen Länge von 8 Bytes pro Nachricht übertragen, weisen Ethernet-Nachrichten eine Länge von über 1500 Bytes auf. Dadurch steigt die Nutzdatenrate, sprich: In einer kürzeren Zeitspanne lassen sich deutlich umfangreichere Nachrichtenpakete übertragen.

  Weitere Anwendungsfälle wie die Steuergeräte-Kommunikation, die Vernetzung von Fahrzeugen mit der Umwelt und Diagnoseeinsätze werden die Bedeutung von Ethernet zusätzlich steigern. Insgesamt lässt sich vorhersagen, dass in Zukunft Komplexität und Größe von Nachrichten weiter zunehmen. Ethernet – als sehr performante, kostengünstige Technik – ist daher die beste Lösung, um auf diese Anforderungen zu reagieren.

  Zusätzliche Potentiale für eine Kostenreduktion ergeben sich noch in weiteren Bereichen: So verringern sich beispielsweise Gewicht und Verdrahtungsumfänge durch Ethernet im Fahrzeug.

• Zugriffsmöglichkeiten auf Ethernet-Busse

  Auf physikalischer Ebene wird beim automobilen Ethernet nicht auf das Ethernet aus der PC-Welt gesetzt. Ziel der Entwicklung war eine physikalische Übertragung der Datenströme über ungeschirmte, zweiadrige Leitungen. Dies wurde durch den Ethernet Standard „BroadR-Reach®" erreicht. Er ist auch für die harten Anforderungen – Stichwort Störsicherheit – im automobilen Umfeld ausgelegt. Übertragungsraten von 100 MBit werden dabei problemlos erreicht. Nachteilig ist aber, dass nicht mit dem klassischen Tooling auf dieses Ethernet zugegriffen werden kann. So ist es nicht möglich, per PC mit eingebautem Ethernet-Controller Daten aus dem automobilen Ethernet des Fahrzeugs zu lesen. Für diesen Anwendungsfall ist ein Umsetzer von automobilem Ethernet auf Standard-Ethernet nötig. Dies sind entweder Eins-Zu-Eins Umsetzer, die so genannten Mediaswitches oder Switches, die einen Standard-Ethernet Anschluss haben.

  In der klassischen Steuergeräte-Entwicklung (mit CAN und FlexRay, etc.) bestand die Möglichkeit, Daten einfach über eine Messhardware abzugreifen. Dies ist mit dem automobilen Ethernet nicht so simpel möglich. Die sonst übliche Option, das Übertragungskabel aufzutrennen, um eine Messhardware anzuschließen, lässt sich nicht realisieren. Um Daten abzugreifen, rücken andere Lösungen in den Fokus. Allerdings haben sie auch Nachteile, da sie das Laufzeitverhalten von Nachrichten verändert.

  Der einfachste Weg, den Ethernet-Datenverkehr aus einem Fahrzeug abzugreifen, sind Switches. Da die Nachrichten im Switch für einige Zeit verarbeitet und dann erst weitergeleitet werden, beeinflusst der Switch das Laufzeitverhalten. Diese Latenzzeit ist nicht konstant, sondern von den Verarbeitungsalgorithmen im Switch abhängig.

  Eine andere Methode, um Daten von einer Ethernet-Leitung abzugreifen, ist ein TAP (Test Access Point). Ein TAP greift die Daten direkt auf der physikalischen Schicht ab und leitet sie mit einer geringen konstanten Latenzzeit weiter.

  

  Bild 2: Messaufbau für die Analyse von CAN und Ethernet mit der Busanalysesoftware Caromee, der FlexCard USB als CAN Hardware-Interface und die Standard-PC-Schnittstelle für Ethernet.

• Zeitliche Anforderungen

  Ein Entwickler einer Anwendung stellt sich immer die Frage, welche zeitlichen Vorgaben das Tooling für eine Analyse erfüllen muss. Für einfache Anwendungsfälle, in denen der Jitter zwischen Ethernet und einem anderen Bussystem nur eine untergeordnete Rolle spielt, würde ein Aufbau für die Busanalyse wie in Bild 2 ausreichen. In diesem Fall schwankt der Zeitstempel im Bereich von bis zu 20ms. Dies würde aber ausreichen, um Bilder – beispielsweise aus der Fahrzeug-Umgebung – in einem zeitlichen Zusammenhang mit einer CAN-Nachricht, die nur einmal pro Bild kommt, zu analysieren. Bei einer Bilddatenrate von 25 Bildern pro Sekunde würde eine Übertragung eines Bildes theoretisch 40ms beanspruchen. Die Messgenauigkeit wäre also ausreichend hoch.

  

  Bild 3: Messaufbau für die Analyse von CAN und Ethernet mit der Busanalysesoftware Caromee und der FlexCard PMCII für hochgenaue zeitliche Anforderungen.

  Soll eine sehr genaue zeitliche Korrelation zwischen einem Ethernet-Bus und einem klassischen Bus erfüllt werden, müsste der Messaufbau für die Analyse wie in Bild 3 aussehen. In diesem Fall wird die FlexCard PMC II von Eberspächer Electronics als Messaufnehmer für Ethernet und CAN verwendet. Die FlexCard PMC II sorgt dabei für eine zeitsynchrone Zeitstempelung der einzelnen Nachrichten. Die Genauigkeit der Zeitstempel liegt dabei im Mikrosekunden-Bereich. Beide Messaufbauten eignen sich nicht nur für das Aufzeichnen einer Fahrzeug-Probefahrt. Mit der Analysesoftware Caromee ist es sogar möglich, die Daten wieder zeitsynchron abzuspielen. Das erlaubt, Algorithmen von Steuergeräten mit einer bestimmten Aufzeichnung immer wieder zu testen.

• ISO/OSI Schichtenmodell

  

  Bild 4: ISO/OSI Schichtenmodell

  Beim ISO/OSI Schichtenmodell (Bild 4) wird die Schicht eins, das sogenannte automobile Ethernet, im Moment in vielen Anwendungsfällen über BroadR-Reach® abgedeckt. Auf Schicht zwei im Modell wird auf das bisherige Ethernet MAC und VLAN gesetzt. Bei VLAN ist aber auch schon Double-VLAN implementiert. Auf der Netzwerkschicht (Schicht drei) finden mehrere Standards Anwendung. So wird für Video-Anwendungen häufig auf IEEE 1722 gesetzt. Im Diagnosebereich kommt auf der Netzwerkschicht IP (DoIP) zum Einsatz und auf der Transportschicht (Schicht vier) TCP. Für die Kommunikation von Steuergeräten untereinander wird die Netzwerkschicht durch IP abgedeckt. Auf Transport-Ebene finden die Protokolle TCP oder UDP Anwendung. Auf höherer Ebene, wie bei der Steuergerätekommunikation, gibt es Protokollstandards wie Some-IP und Service-Discovery.

  Für die Kommunikation von Steuergeräten untereinander wird auf das Protokoll Some-IP gesetzt. Dieses Protokoll ist eine Abkehr von der typischen zyklischen Kommunikation im automobilen Umfeld. Some-IP ist ein RPC-Verfahren. Grundsätzlich ist Some-IP ein Client-Server-Modell. Zu Beginn einer Kommunikation sendet der Client eine Anfrage an einen Server. In dieser Anfrage wird beschrieben, was der Server ausführen soll und wie die Antwort auszusehen hat. Der Server bearbeitet die Anfrage und sendet ein Ergebnis zurück. In der Client-Server-Kommunikation sind verschiedene Verfahren für die Fehlerbehandlung und dem Nachrichtenaufbau hinterlegt.

• Integration von Ethernet in eine klassische Autovernetzung

  Bei der Integration von Ethernet in eine klassische Autovernetzung gibt es einige Herausforderungen. Da der Übergang zu Ethernet fließend und ohne harten Schnitt erfolgt, muss die Kommunikation von klassischen automobilen Bussystemen mit Ethernet-Steuergeräten sichergestellt werden. Dies lässt sich meist über Gateways realisieren. Die Gateway-Funktionalität wird dann durch ein größeres, zentrales Steuergerät bereitgestellt. Um die Last auf Ethernet zu verringern, lassen sich mehrere CAN-Nachrichten zu einer Ethernet-Nachricht paketieren. Dadurch kann die größere Nachrichtenlänge von Ethernet-Nachrichten ideal ausgenutzt werden. In diesem Fall besteht die Möglichkeit, von 8 Byte Datenlänge bei CAN auf bis zu über 1500 Byte bei Ethernet zu kommen. Grundsätzlich ist davon auszugehen, dass sich die Komplexität des Nachrichtenaufbaus in automobilen Fahrzeug-Netzwerken vergrößert. Es wird Standards geben, die Dateninhalte auf mehrere Ethernet-Nachrichten verteilen. Es wird aber auch Standards geben, die mehrere klassische Dateninhalte in eine Ethernet-Nachricht verpacken.

  Weitere Herausforderungen für die Zukunft ergeben sich durch die Bestrebung, die Übertragung auf ein ungeschirmtes Gigabit-Ethernet als physikalische Übertragungsschicht zu erweitern – allerdings ohne, dass bis dato alle Fragen zu harten Echtzeitanforderungen geklärt sind.