Die heute übliche große Menge an Steuergeräten im Fahrzeug, die in der Oberklasse immerhin 70 Stück beträgt, und der weiter anwachsende Software-Umfang, der bei ca. 100 MByte liegt, erzwingen größere Datenraten beim Software-Update, um die Dauer des Update-Vorgangs in einem akzeptablen Bereich zu halten. Die gängigste Methode, die Zeiten zu verringern, ist die Parallelisierung des Update-Prozesses, bei der die Steuergeräte gleichzeitig mit Software versorgt werden. Dabei kann die maximale Datenrate auf den Bussen vom zentralen Gateway zu den Steuergeräten ausgereizt werden. Die mögliche Gesamtdatenrate beläuft sich in diesem Fall auf die Summe der Datenraten der einzelnen CAN- und FlexRay-Busse, die vom zentralen Gateway ausgehen. Limitiert wird dieses Szenario durch den Datentransfer vom Tester zum Gateway, der klassischerweise nur durch einen CAN-Bus realisiert wird. Die Nettoübertragungsrate beträgt maximal 17 Kbyte/s bei einem High-Speed-CAN-Bus mit 500 Kbit/s [6, 2]. MOST-Steuergeräte werden daher in den meisten Fahrzeugplattformen noch über einen Datenträger und die Head Unit mit neuer Software versorgt. Dadurch wird der normale Diagnosezugang umgangen.
Der Ethernet-Bus (IEEE 802.3) hat sich seit seiner Entstehung 1980 verbreitet und dominiert heute den Bereich der Heim- und Firmennetzwerke [3]. In der üblichen Ausführung als Fast Ethernet beträgt die Brutto-Übertragungsrate 100 Mbit/s. Als Netto-Übertragungsrate bleiben 6,25 Mbyte/s, wobei der TCP/IP-Overhead grob geschätzt 50 % ausmacht. Diese hohe Bandbreite und die weite Verbreitung machen Ethernet zu einer attraktiven und zukunftssicheren Alternative für die bis heute üblichen Wege des Fahrzeugzugangs.
Diagnoseprotokoll ist zeitkritisch
Um die besonderen technischen Herausforderungen bei der Verbindung der Fahrzeugdiagnose und den Internet-Protokollen zu verstehen, sind ein paar grundlegende Erläuterungen notwendig. Bei dem zur Fahrzeugdiagnose verwendeten Diagnoseprotokoll UDS (Unified Diagnostic Services, ISO 14229-1) handelt es sich im Wesentlichen um ein Client-Server-Protokoll. Der Diagnose-Tester (Client) stellt eine Anfrage in Form eines Datenpakets (Request) an die Steuergeräte (Server). Das Steuergerät antwortet seinerseits mit einem positiven oder im Fehlerfall negativen zurückfließenden Datenpaket. UDS-Datenpakete unterliegen strengen Protokoll- und Timing-Anforderungen. Beispielsweise muss ein Steuergerät innerhalb von 50 ms (konfigurationsabhängig) auf einen UDS-Request mit einer Antwort reagiert haben. Dies stellt also zeitkritische Anforderungen an die Latenz des Netzwerkes und an die Protokolle, die damit umgehen müssen.
Bei Feldbussen stellen diese Timing-Anforderungen kein Problem dar, da sie per Konstruktion echtzeitfähig sind. Ethernet ist allerdings von Haus aus nicht echtzeitfähig. Auch die Internetprotokollfamilie wurde gezielt robust konzipiert, um bezüglich großer Latenzzeiten oder Netzwerkausfälle tolerant zu reagieren. Für zeitkritische Anwendungen ist das Internet-Protokoll nicht ausgelegt. Echtzeitfähige Erweiterungen zu Ethernet existieren insbesondere in der Automatisierungstechnik, z.B. in Form von Profinet, Powerlink oder EtherCAT und im Flugzeugbau (AFDX). Dies sind jedoch aufwendige Technologien, die die Einfachheit und den Kostenvorteil der bestehenden Ethernet/IP-Lösungen aufheben. Zurzeit kommen sie daher nur in Bereichen vor, in denen die Kosten pro Geräteeinheit nicht ausschlaggebend sind. Trotz allem wird Ethernet als Echtzeit-Bus für zeit- und ereignisgesteuerte Steuergeräte-Anwendungen im Automobil im Rahmen der Forschung untersucht [4, 5].