Kurzfassung. Abstract. 1 Einleitung

Transkript

1 Echtzeitanalye Ethernet-baierter E/E-Architekturen im Automobil 1 Felix Reimann, Andrea Kern, Chritian Haubelt, Thilo Streichert und Jürgen Teich Hardware/Software Co-Deign, Lehrtuhl für Informatik 12, Univerität Erlangen-Nürnberg, Deutchland Daimler AG Kurzfaung Ethernet it aufgrund der hohen Bandbreite eine intereante Alternative zu proprietären Buen, um ECU im Automobil zu vernetzen. E gibt bereit mehrere Ethernet-Derivate, welche Ethernet um Echtzeiteigenchaften erweitern. Diee Arbeit zeigt, da auch mit Standard-Ethernet Auagen zur Echtzeitfähigkeit von Sytemen möglich ind. Hierzu wird eine Echtzeitanalye von Standard-Ethernet vorgetellt und die Ergebnie an Hand einer Falltudie mit einer Simulation de Sytem verglichen. Abtract A a reult of the higher bandwidth, Ethernet i an intereting alternative to proprietary bue in networking ECU in automobile. In order to be able to provide real-time guarantee everal Ethernet derivative have been propoed. Thi work demontrate that even with tandard Ethernet real-time guarantee can be given. For thi reaon, a real-time analyi of tandard Ethernet i preented and the reult baed on a cae tudy are compared with a imulation of the ytem. 1 Einleitung Elektriche und elektroniche Architekturen (E/E-Architekturen) im Automobil betehen au einer Vielzahl unterchiedlicher Kommunikationyteme mit verchiedenen Eigenchaften. Man untercheidet derzeit zwichen Regel- und Steuerungnetzwerken, wie beipielweie LIN [6], CAN [5] oder FlexRay [2], und Multimedianetzwerken, wie MOST [8] oder LVDS, al reine Direktverbindung, die beipielweie für die Anbindung von Bildchirmen oder Kamera genutzt werden. Da zukünftig die Anzahl und Komplexität der Anwendungen im Fahrzeug weiter teigen wird, ergeben ich auch höhere Anforderungen an die zugrunde liegende Kommunikationinfratruktur. Neben der Forderung nach höheren Bandbreiten nehmen auch die Kommunikationbeziehungen zwichen den verchiedenen Anwendungen deutlich zu. Aufgrund dieer Forderungen werden neben den verfügbaren Löungen au der Automobilbranche auch alternative Kommunikationyteme, wie beipielweie Ethernet [4], al zukünftige Kommunikationtechnologien unterucht. Ethernet it im Bereich der Conumerelektronik und dem Internet weltweit verbreitet. In dieen Domänen pielen Echtzeitanforderungen lediglich eine untergeordnete Rolle und die Kommunikation wird durch Bet-Effort-Kriterien, alo chnelltmöglich, augeführt. In der Indutrieautomatiierung exitieren bereit heute über ein Dutzend Ethernet-baierter Löungen, welche teilweie erweitert wurden, um Echtzeitanforderungen zu untertützen, iehe auch [15, 14]. AFDX [13] baiert ebenfall auf Ethernet und it ein in der 1 Teilweie gefördert durch da BMBF-Projekt Sicherheit in eingebetteten IP-baierten Sytemen (SEIS) [1]. Avionik eingeetzte Kommunikationytem, welche beipielweie im Airbu 380 oder der Boeing 787 eingeetzt wird. Auch in der Automobilbranche lät ich ein Trend beobachten, welcher Ethernet al zukünftige Kommunikationytem im Automobil favoriiert [1]. Heutige und zukünftige Anwendungzenarien ind beipielweie in den Bereichen Reareat-Infotainment, Onboard-Diagnoe oder Laden von E-Fahrzeugen zu finden. Die führt bereit heute zu einer guten Verfügbarkeit Ethernet-tauglicher Hard- und Software, die bereit teilweie automobilpezifiche Anforderungen erfüllt. Um die praktiche Tauglichkeit von Ethernet zeigen zu können, gilt e nun aber vor allem die zeitlichen Anforderungen von fahrzeugkritichen Anwendungen bewerten zu können. Im Folgenden wird eine analytiche Methodik vorgetellt, welche e erlaubt, bereit frühzeitig Abchätzungen für Ethernet-vernetzte Funktionen für Bet und Wort Cae Zielgrößen zu berechnen. E wird gezeigt, da elbt bei der Verwendung von Standard-Ethernet eine Auage zum Echtzeitverhalten möglich it. Da Echtzeitverhalten einer Falltudie wird mit imulativ ermittelten Ergebnien verglichen, um die Genauigkeit der Analye bewerten zu können. Da retliche Dokument gliedert ich wie folgt: Kapitel 2 bechreibt die verwendete analytiche Methodik und darauf aufbauend die notwendigen Erweiterungen, um auf Ethernet baierende Syteme analyieren zu können. Im anchließenden Kapitel wird die umgeetzte Methodik anhand einer Falltudie evaluiert. Da letzte Kapitel fat die gewonnenen Erkenntnie zuammen und gibt einen Aublick für weitere Unteruchungen.

2 Bild 1: Mögliche Aktivierungen eine Tak mit Periode P = 4 und Jitter J = 1. 2 Echtzeitanalye von Ethernet In E/E-Architekturen ind für viele Anwendungen Zeitchranken gegeben. Ziel der Echtzeitanalye it e, die Ende-zu-Ende-Latenzen im Wort Cae zu betimmen. Durch Simulation ind diee Zeiten nicht ermittelbar, da weder die entprechenden Aufrufreihenfolgen der Prozee noch die entprechenden Eingangdaten bekannt ind, die zu einer maximalen Verzögerung de verteilten Sytem führen, beziehungweie eine experimentelle Ermittlung der Größen nicht praktikabel it. Im Folgenden wird zunächt SymTA/S, ein Werkzeug zur analytichen Betimmung de Zeitverhalten verteilter Syteme, eingeführt. Auf dieer Bai wird im Anchlu die Echtzeitanalye von mittel Ethernet kommunizierender Syteme vorgetellt. 2.1 SymTA/S SymTA/S [3] it ein Werkzeug zur analytichen Betimmung der Ende-zu-Ende-Latenzen der Kommunikationpfade eine verteilten, heterogenen Sytem. Im Folgenden werden die für die Echtzeitanalye von Ethernet-baierten Netzwerken nötigen Teile von SymTA/S bechrieben. Für jeden Proze t it eine maximale Rechenzeit l t gegeben und jede Nachricht c hat eine Nachrichtenlänge l c. Die Prozee und Nachrichten, im Folgenden allgemein al Tak benannt, ind durch ogenannte Ereignitröme verbunden, die fetlegen, von welchen Vorgängern der aktuelle Tak abhängt. Ert wenn ämtliche Vorgänger eine Tak ein Datum generiert haben, kann der Tak elbt augeführt werden. Da Aktivierungmodell eine Ereignitrom wird durch da Tupel (P, J) R + R + bechrieben. P gibt die Periode an, in der da Ereigni auftritt. Der Jitter J it die Größe dejenigen Intervall, um da da Auftreten de Ereignie um eine periodiche Aktivierung chwanken kann, vgl. Abbildung 1. Sind mehrere Tak auf eine Reource gebunden, kann der Tak allerding verdrängt werden. Ob und wie lange ein Tak verdrängt wird, hängt von der Schedulingtrategie der Reource ab. Zur Echtzeitanalye unter Berückichtigung de Scheduling tehen unter anderem folgende einfache Strategien zur Verfügung: Prioritätbaierte präemptive Ablaufplanung: Jedem Tak auf einer Reource it genau eine Priorität zugeordnet. Höherpriore Tak werden vor niederprioren augeführt. Läuft ein niederpriorer Tak und ein höherpriorer wird laufbereit, wird der niederpriore unterbrochen. Bild 2: Drei Tak t 1, t 2, t 3 kommunizieren über Ethernet. Zur Echtzeitanalye mu neben den Tak der Softwaretack, die Ethernet-Controller cc owie der Switch modelliert werden. Die Ende-zu-Ende-Latenz wird vom Beginn der Berechnung von t 1 bi zum Ende der Berechnung von t 3 gemeen. Zeitmultiplex: Jedem Tak wird ein Zeitchlitz mit einer betimmten Länge zugeteilt. Im chlechteten Fall wird ein Tak genau dann laufbereit, wenn ein Zeitchlitz gerade vorbei it. Round Robin: Wie beim Zeitmultiplex wird jedem Tak ein Zeitchlitz mit einer betimmten Länge zugeordnet. Statt ungenutzte Zeiten vertreichen zu laen, wird die Reource ofort dem nächten lauffähigen Tak zugeteilt. In SymTA/S wird zunächt jede Reource einzeln analyiert. Die Aktivierungmodelle der augehenden Ereignitröme berechnen ich au den eingehenden Ereignitrömen, der Rechenzeit owie der Ablaufplanung. Die Periode bleibt gleich, während ich der Jitter erhöht. Die maximale Verzögerung wird erzielt, wenn ämtliche höherpriore Tak gleichzeitig laufbereit ind, vgl. [7]. In verteilten Sytemen beeinflut die Aktivierung der Tak auf einer Reource die Aktivierung aller datenabhängigen Tak im Sytem. Bei zyklichen Abhängigkeiten wie ie beipielweie im Switch auftreten, mu die Analye der Antwortzeiten auf jeder Reource o lange iteriert werden, bi ein Fixpunkt gefunden wird. 2.2 Ethernet-Modellierung Abbildung 2 zeigt die einzelnen Komponenten, die im Folgenden modelliert werden, um eine von Tak t 1 zu Tak t 2 über Ethernet verendete Nachricht zu analyieren. Die Nachricht wird zunächt durch den Softwaretack net tx gereicht, der die UDP/IP- und die MAC- Header hinzufügt. Danach wird die Nachricht über einen FIFO auf den Ethernet-Controller cc übertragen, der die Pakete verendet. Im Switch werden ie empfangen und ebenfall in einem FIFO gepeichert. Entprechend der Ablaufplanung auf dem Switch werden ie in den FIFO de Augangport übertragen und verendet, obald die Leitung frei it. Auf der Seite de Empfänger mu die Nachricht durch den Softwaretack entpackt und dann an den empfangenden Tak weitergereicht werden. Außerdem zeigt Abbildung 2 eine Kommunikation von t 2 nach t 3 über den elben Switch.

3 Im Folgenden wird die Modellierung der Ethernet-pezifichen Reourcen cc und witch bechrieben Modellierung de Switche Zentrale Element bei Ethernet tellen die Switche dar. Deren Arbeitweie und Paketcheduling ind im Standard nicht näher pezifiziert, allerding mu für eine Echtzeitanalye die konkrete Umetzung bekannt ein. Man untercheidet im Weentlichen Switche mit Crobar, die dedizierte Punkt-zu-Punkt-Verbindungen zwichen allen Eingang- und Augang-FIFO bieten und Switche mit Backplane-Bu, über den ämtliche Pakete von den Eingang-FIFO zu den entprechenden Augang-FIFO gechickt werden. Im Folgenden ollen die bubaierten Switche betrachtet werden. Bei dieen kommt al einfache und chnelle Buarbitrierungtrategie häufig Round Robin zum Einatz. Mit dieen Vorauetzungen kann der Backplane-Bu de Switche al zentrale Reource modelliert werden, über die ämtliche Nachrichten laufen. Die lauffähigen Nachrichten werden mittel Round Robin geplant. Ein Zeitchlitz f Switch entpricht dabei genau der Zeit, die ein komplette Ethernetpaket benötigt, um übertragen zu werden. Die maximal erlaubte Paketlänge l mtu it 1538 Byte oder ein beliebiger, kleinerer Wert (fetgelegt durch die Maximum Tranmiion Unit, MTU [12]). Für einen Backplane-Bu mit einer gegebenen Bandbreite b Switch ergibt ich damit f Switch = l mtu b Switch. (1) Modellierung de Ethernet-Controller An einem Switch können an jeden Eingangport verchieden chnelle cc angechloen werden. Im Weentlichen gibt e nach IEEE Ethernet-Controller mit b cc = 10 MBit bi hin zu b cc = 10 GBit Bandbreite. Durch die Vollduplexübertragung können Daten gleichzeitig empfangen und geendet werden. Entprechend wird je eine Reource vom und zum Switch pro ECU modelliert. Werden von einer ECU mehrere unterchiedliche Nachrichten verendet bzw. empfangen, wird eine Nachricht olange verzögert, bi alle anderen Nachrichten verendet bzw. empfangen wurden. Daher wird auch hier Round Robin zur Berechnung de Wort Cae al Scheduler verwendet und die Länge der Zeitchlitze, wie beim Switch, au der maximalen Framelänge und der Bandbreite b cc de gewählten Bautein berechnet Modellierung der Nachrichten Ein Ethernetpaket hat inkluive Präambel und Inter Frame Gap (IFG) eine maximale Länge von 1538 Byte, vgl. [4]. Au dem Overhead der Kopfdaten von 38 Byte pro Paket und einer minimalen Nutzlat von 46 Byte ergibt ich beim MAC-Protokoll für n Byte Nutzdaten eine effektive Nachrichtenlänge l mac von: l mac (n) = 38 n n + max{0 ; 46 (n mod 1500)} (2) Zuätzlich zur Nutzlat n kommen alo die Headerdaten pro Paket hinzu owie, fall ein Paket weniger al 46 Byte Nutzdaten beeinhaltet, ein entprechend lange Füllfeld. Werden größere Daten übertragen, wird die Nachricht durch die IP-Schicht in mehrere Ethernetpakete zerlegt. Für ein IPv4-Paket kommen zuätzlich noch 20 Byte IP-Kopfdaten pro Ethernetpaket und 8 Byte UDP-Kopfdaten pro IP-Paket hinzu, vgl. [11, 10]. Damit ergibt ich für n Byte Nutzdaten eine effektive Nachrichtenlänge l udp von: l udp (n) = 58 n n max{0 ; 26 ((n + 8) mod 1472)} (3) Betrachtet man jede Paket einzeln, erhält man eine realitätnahe Modellierung. So können die erten Pakete einer Nachricht bereit durch den Switch übertragen werden, während andere Teile noch durch den oftmal langameren cc verzögert werden. Hierzu modelliert man für eine Nachricht der Länge n Byte ludp (n) 1538 einzelne Nachrichtentröme, die vom Softwaretack de Sendetak über die cc und dem Switch zum Softwaretack de Zieltak geroutet werden. Zur Modellierung von großen Nachrichten, wie ie beipielweie bei Multimedia-Anwendungen auftreten, it aufgrund der großen Anzahl zu betrachtender Pakete die Analye zu komplex. Dehalb it e alternativ möglich, eine große Nachricht durch einen einzelnen Nachrichtentrom zu modellieren, der auf die elben Reourcen wie bei obigem Anatz gebunden wird. Die Länge de Nachrichtentrom berechnet ich au Formel (3). Da die Länge eine Zeitchlitze im Switch und den Controllern entprechend der maximal möglichen Größe eine einzelnen Ethernetpaket gewählt wurde (vgl. Formel (1)), können nach der Übermittlung eine Paket jeweil ein Paket der im Wort Cae gleichzeitig am Switch einlaufenden Nachrichten übertragen werden. Durch diee Art der Modellierung wird die Überapproximation der Wort Cae-Analye zwar vergrößert, allerding laen ich nur o auch ehr große Nachrichten analyieren. Die beiden Arten der Modellierung können gleichzeitig für verchiedene Nachrichten genutzt werden, um für kleinere Nachrichten beere Wort Cae Werte zu erhalten. 3 Falltudie Für die Bewertung de Modell zur Echtzeitanalye von Ethernet-baierten Sytemen wird im Folgenden eine Falltudie auf Bai eine mit Ethernet vernetzten Multikameraytem bechrieben. Hierbei werden die in SymTA/S ermittelten analytichen Zielgrößen mit den Ergebnien eine adaptierten dikreten ereignigeteuerten Simulator [9] verglichen.

4 cam 1 cam 2... cam n Kamera capi enci neti pcami Steuergerät imgi cpui cci witch di Diplay (a) Kamera Bild 3: Der Datenabhängigkeitgraph de Multikameraytem. Die Kamera enden Daten an da Steuergerät, welche wiederum Daten an da Diplay chickt. cami pcami netrx dec int nettx di pint cam 1 cam 2... cam i cpu cc witch Switch (b) Steuergerät di pint netdi vi Bild 4: Die Architektur de Multikameraytem. Die Kamera, da Steuergerät und da Diplay kommunizieren über einen zentralen Switch miteinander. witch ccdi cpudi (c) Diplay di 3.1 Sytemmodell Da betrachtete Multikameraytem beitzt folgende Funktionprinzip: Mehrere am Fahrzeug intallierte Videokamera cam i erfaen definierte Umgebungbereiche de Fahrzeug. Diee werden in einem zentralen Steuergerät aggregiert, zuammengefat und über ein Diplay im Fahrzeug angezeigt. Ziel diee bilddartellenden Fahreraitenzytem it die Untertützung de Fahrer bei der Erfaung von Objekten, welche ich in der Umgebung de Auto befinden. Im Folgenden werden die Architektur, die benötigten Tak, deren Datenabhängigkeiten und die verwendeten Parameterätze bechrieben. Abbildung 3 zeigt den zugrunde liegenden Datenabhängigkeitgraphen. Die Kamera erfaen hierbei Einzelbilder und leiten diee paketiert mittel Ethernet an da Steuergerät weiter. Au den eingehenden Paketen der einzelnen Kamera werden im Steuergerät die Einzelbilder rekontruiert. Liegen alle zuammengehörenden Einzelbilder der angechloenen Kamera vor, wird au den Einzelbildern ein Geamtbild generiert, diee wiederum paketiert und an da Diplay geendet. Da Diplay rekontruiert da Bild und tellt e auf dem Bildchirm dar. Die Architektur it in Abbildung 4 dargetellt und baiert auf einer ternförmigen Vernetzung mittel eine zentral angeordneten Switche. Alle Komponenten können omit auchließlich über den Switch miteinander kommunizieren. Der Switch elbt beitzt bi zu fünf Fat Ethernet Anchlüe mit jeweil 100 MBit Bandbreite und einen Gigabit Ethernet Anchlu, welcher eine maximale Datenrate von 1 GBit beitzt. Der Hochgechwindigkeitbu im Switch beitzt eine Datenrate von 2 GBit. Im Folgenden wird die Funktionweie und der Aufbau jeder Komponente bechrieben. Bild 5: Die Komponenten Kamera, Steuergerät und Diplay. Da Kameramodul nimmt Einzelbilder auf, komprimiert diee und generiert im Anchlu daran UDP- Pakete, welche mittel Ethernet an da Steuergerät verendet werden. Abbildung 5a zeigt den Aufbau eine olchen Kameramodul cam i, welche au den Reourcen Imager img i, Prozeor cpu i und Ethernet-Controller cc i beteht. Der Imager nimmt jeweil ein Einzelbild auf und endet die generierten Daten mittel eine parallelen Interface direkt an den Prozeor. Nach jedem Einzelbild tartet ein Hardware-Interrupt die Verarbeitung auf dem Prozeor. Dieer verarbeitet die Prozee Encoder enc i, welcher die Komprimierung eine Einzelbilde übernimmt, und den Softwaretack net i, der die komprimierten Einzelbilder in Pakete aufteilt und die benötigten Paketköpfe generiert. Die Auführungzeit de Softwaretack untercheidet ich je nach Implementierung und auführender ECU. Anhand von Meungen an einer Referenzimplementierung, kann für den Lee- und Schreibtack folgende Auführungzeit für Nachrichten der Länge n Byte verwendet werden: l neti (n) = t fix + t var (n) n (4) Die beiden Prozee werden mittel präemptivem, prioritätbaiertem Scheduling auf dem Prozeor augeführt. Nachdem net i ein Paket generiert hat, wird diee an den Ethernet-Controller übergeben, welcher da Paket an den Switch endet. Die Verarbeitung der Kamerabilder erfolgt, wie oben bechrieben, zentral im Steuergerät. Der Aufbau de Steuergerät it in Abbildung 5b dargetellt. E beteht au den beiden Reourcen Prozeor cpu und dem Ethernet-Controller cc. Auf dem Prozeor werden

5 Anzahl der Pakete pro Sekunde Switch 100 % 80 % 60 % 40 % 20 % Kamera ECU Diplay Switch Paketgröße[Byte] 0 % Paketgröße[Byte] Bild 6: Die Anzahl der verendeten Pakete pro Sekunde für unterchiedliche Paketgrößen. Bild 7: Die Reourceaulatungen der einzelnen Komponenten für unterchiedliche Paketgrößen. die Prozee net rx, dec, int und net tx ebenfall mittel präemptivem, prioritätbaiertem Scheduling augeführt. Der Proze net rx entpackt empfange Pakete von Kamera und generiert darau die aufgenommenen Einzelbilder. Liegt ein Einzelbild einer Kamera vor, dekomprimiert der Proze dec da Einzelbild, um auf die Rohdaten zugreifen zu können. Liegen alle zuammengehörenden Einzelbilder der angechloenen Kamera decodiert vor, beginnt die Intergration der Bilder durch den Proze int. Anchließend wird da generierte Bild an den Proze net tx übergeben, welcher da generierte Bild in Pakete zerlegt, die Paketköpfe erzeugt und an den Ethernet-Controller endet, welcher diee an da Diplay chickt. Da Diplay übernimmt die Dartellung der generierten Einzelbilder de Steuergeräte. Abbildung 5c zeigt den Aufbau de Diplay, welche au den Reourcen Ethernet-Controller cc di, Prozeor cpu di und Diplay di beteht. Der Proze net di verarbeitet dabei eingehende Pakete vom Ethernet-Controller und erzeugt darau wieder da Geamtbild, welche dann auf dem Diplay angezeigt wird. 3.2 Ergebnie Bei der Evaluierung de Multikameraytem wurden die Anzahl der verendeten Ethernet-Pakete pro Sekunde, die Reourceaulatungen und die Ende-zu-Ende-Latenz de Sytem für unterchiedliche Ethernet- Paketgrößen ermittelt. Abbildung 6 zeigt den imulativ ermittelten Verlauf der Anzahl der zu verarbeitenden Pakete pro Sekunde in Abhängigkeit zur maximalen Framelänge l mtu. Je kleiner l mtu, deto mehr Pakete werden benötigt um die Videodaten zu übermitteln. Da der Softwaretack für jede Paket durchlaufen werden mu, hat l mtu auch Einflu auf die Reourceaulatungen, vgl. Formel (4). Abbildung 7 zeigt die jeweiligen Aulatungen der Reourcen cam i, witch, und di. Außerdem it zu ehen, da da Steuergerät mit abnehmender Paketgröße in die Sättigung läuft, omit konnten nur Paketgrößen bi 600 Byte evaluiert Ende-zu-Ende-Latenz [m] Durchchnittliche Latenz (imulativ) Wort Cae Latenz (analytich) Paketgröße[Byte] Bild 8: Die gemeenen und analyierten Ende-zu- Ende-Latenzen für unterchiedliche Paketgrößen. werden. Bild 8 zeigt die Evaluierung der Ende-zu-Ende-Latenzen, wobei zu erkennen it, da die analytich ermittelten Zeiten um den Faktor 2 größer ind al die imulativ ermittelten Durchchnittzeiten. Die liegt zum einen an der Tatache, da e durch Simulation kaum möglich it, den chlimmtmöglichen Fall zu erreichen. Anderereit führt die hier vorgetellte Analye zu einer Überapproximation, da eine Nachricht tet volltändig an einer Reource empfangen werden mu, bevor der erte Frame geendet wird. Die it au Abbildung 9 erichtlich: Die Nachricht m auf dem Switch wird korrekterweie olange verzögert, bi alle anderen Nachrichten übermittelt wurden. Allerding könnte die Übertragung auf dem Ethernet-Controller bereit beginnen, obald da erte Paket der Nachricht m am Switch übertragen wurde (chwarzer Pfeil). Um die zu analyieren, wäre e nötig, den genaueren paketbaierten Anatz (vgl. Abchnitt 2.2.3) zu verwenden. Auf Grund der großen Anzahl an Paketen (über 200 pro Frame und Bildquelle) im Vergleich zur betrachtenden Periode (betimmt durch die zu erzielenden 30 fp) it dieer feingranulare Anatz mit ei-

6 Bild 9: Überapproximation de Wort Cae bei der Übertragung einer drei Pakete langen Nachricht vom witch zum cc. nem Aktivierungmodell, da auchließlich auf Periode und Jitter zur Modellierung etzt, noch nicht effizient durchführbar. 4 Zuammenfaung und Aublick In dieer Arbeit wurde ein Modell zur Echtzeitanalye von auf Standard-Ethernet baierten Sytemen am Beipiel von SymTA/S entwickelt. Hierzu wurden die Ethernet-Komponenten cc und witch modelliert, o da eine Analye von Ethernet-Netzwerken auch bei großem Nachrichtenaufkommen möglich it. Ein Fallbeipiel für ein Ethernet-baierte Multikameraytem wurde unterucht und mit Ergebnien einer Simulation verglichen. Die reultierende Überapproximation entteht durch die Annahme, da bei der Analye die Weiterverarbeitung de Frame ert beginnt, wenn alle Datenpakete eine Frame übertragen worden ind. Diee Vereinfachung war notwenig, um Ergebnie in akzeptabler Zeit durch die Analye berechnen zu können. Mittel Simulation kann dagegen nicht gewährleitet werden, da der Wort Cae im Simulationlauf auftritt. Ein nächter Schritt it die Integration mehrerer Sytemfunktionen mit Echtzeitanforderungen über eine gemeiname Ethernet-baierte Infratruktur. Da hier die gegeneitige Beeinfluung der Anwendungen auf Netzwerkebene Auwirkungen auf die Echtzeitfähigkeit haben kann, ollen unterchiedliche Mechanimen zur Prioriierung von Ethernet-Paketen unterucht und verglichen werden. Sytem Level Performance Analyi the Sym- TA/S Approach. In: IEE proceeding. Computer and digital technique 152 (2005), S ISSN [4] The Intitute of Electrical and Electronic Engineer, Inc. (Hrg.): Information technology Local and metropolitan area network Specific requirement Part 3: Carrier ene multiple acce with colliion detection (CSMA/CD) acce method and phyical layer pecification. IEEE Std 802.3, Park Avenue, New York, USA: The Intitute of Electrical and Electronic Engineer, Inc., Dezember 2000 [5] ISO und IEC: ISO 11898: Road vehicle Controller area network (CAN) Part 1: Data link layer and phyical ignallingrea network (CAN) for high-peed communication. ISO :2003. November 1993 [6] LIN Adminitration (Hrg.): LIN Specification Package Bernhard-Wicki-Straße 3, Munich, Germany: LIN Adminitration, November [7] Liu., C. L. ; Layland, J. W.: Scheduling algorithm for multiprogramming in a hard real-time environment. (1973), S [8] MOST Cooperation (Hrg.): Media Oriented Sytem Tranport MOST Specification. Rev Karlruhe: MOST Cooperation, Mai 2008 [9] NS 2: The Network Simulator 2. [10] Potel, J.: Uer Datagram Protocol. RFC Admiralty Way, Marina del Rey, California 90291: Information Science Intitute, Univerity of Southern California, Augut 1980 [11] Potel, J.: Internet Protocol DARPA Internet Program Protocol Specification. RFC Admiralty Way, Marina del Rey, California 90291: Information Science Intitute, Univerity of Southern California, September 1981 Literatur [1] E ENOVA Innovationallianz Automobilelektronik: Sicherheit in IP-baierten Sytemen. [2] FlexRay Conortium GbR (Hrg.): FlexRay Communication Sytem Protocol Specification. 2.1 Rev. A. Indutrietraße 6, Stuttgart, Germany: FlexRay Conortium GbR, Dezember 2005 [3] Henia, Rafik ; Hamann, Arne ; Jerak, Marek ; Racu, Razvan ; Richter, Kai ; Ernt, Rolf: [12] Potel, J.: The TCP Maximum Segment Size and Related Topic. RFC Admiralty Way, Marina del Rey, California 90291: Information Science Intitute, Univerity of Southern California, November 1983 [13] SYSGO AG: Avionic Full DupleX Switched Ethernet. [14] EtherCAT Technology Group: EtherCAT. [15] TTTech Computertechnik AG: TTEthernet. Verion: 2008