Einordnung der einzelnen TWGs aus Systemsicht. Mit einer schematischen Darstellung eines Steuergeräts und dessen zur Kommunikation nötigen Bestandteile kann man die Arbeitsgruppen thematisch zuordnen (Bild 2).
Die Beschränkung auf nur eine ECU im Bild dient der Übersichtlichkeit. Beispielsweise beschäftigt sich TWG5 auch mit dem Gesamtmanagement des Netzwerks, welches alle am Netzwerk teilnehmenden ECUs und Switch-ICs miteinschließt.
Ebenso betrachtet TWG2 den gesamten Kommunikationskanal inklusive Gegenstelle, da sich das Link-Budget üblicherweise auf die Transceiver, die Stecker und das Gesamtkabel – eventuell inklusive Zwischensteckern – aufteilt.
Die NAV Alliance verfügt über die drei Mitgliedsstufen:
Promoter-Mitglieder sind Teil des Board of Directors – welches das Steuergremium der Allianz bildet und strategische Entscheidungen trifft (Bild 3).
Contributor-Mitglieder können wie auch Promoter aktiv in Arbeitsgruppen mitwirken und so die Spezifikationen mitgestalten sowie unter bestimmten Voraussetzungen auch im Board vertreten sein. Adopter-Mitglieder können alle freigegebenen Spezifikationen nutzen, sind aber nicht an deren Erstellung beteiligt. Die Marketing-Arbeitsgruppe erarbeitet keine technischen Spezifikationen aber steht ebenso allen Promoter- und Contributor-Mitgliedern offen.
Vor dem Beitritt zur NAV Alliance muss die IPR Policy akzeptiert werden. Diese ist analog zu der IPR Policy der IEEE gestaltet, um an dieser Stelle aus rechtlicher Sicht einen problemlosen Übergang zu gewährleisten. Der Kern der IPR Policy ist die Pflicht zur Lizenzierung eigener, eingebrachter Patente zu fairen, angemessenen und nicht-diskriminierenden Bedingungen gegenüber allen anderen Mitgliedern der Allianz (Reasonable and Non-Discriminatory-Licensing, RAND-Licensing). Einige R&D-lastige Unternehmen argumentieren, dass RAND-Bedingungen im Vergleich zu kostenfreien Bedingungen zur Lizenzierung wie bei RANDz (RAND-zero) zu bevorzugen seien. Durch die möglichen Lizenzgebühren soll der hohe Forschungs- und Entwicklungsaufwand so wenigstens teilweise gedeckt werden können. Sollten Unternehmen im Gegensatz dazu keine Aussicht auf eine Vergütung eingebrachter Patente sehen, erhöht das die Hemmschwelle überhaupt erst neuartige Technologien in Gremien einzubringen.
Das Ziel der NAV Alliance ist es, die Anforderungen an das gesamte Kommunikationssystem automatisierter Fahrzeuge zu erfassen und technische Lösungen dafür zu erarbeiten. Viele andere Organisationen dagegen arbeiten eher Technologie-fokussiert. Beispielsweise beschäftigt sich die OPEN Alliance explizit mit Automotive Ethernet und dem zugehörigen Ökosystem, das benötigt wird, um diese Technologie unabhängig von der Funktion im Fahrzeug zum Einsatz zu bringen. Weil beim Use-Case-getriebenen Ansatz der NAV Alliance viele verschiedene Technolo¬gien und Bereiche im Fahrzeugnetzwerk involviert sind, sind Überschneidungen vor allem mit eher Technologie-fokussierten Organisationen durchaus möglich (Bild 4).
Die im Bild genannten Themenbereiche für Überschneidungen sind abgeschätzt und können sich je nach weiterer Ausrichtung der Allianzen auch verändern. Bei solchen Überschneidungen besteht das Risiko, dass die involvierten Gruppierungen zueinander inkompatible Spezifikationen erarbeiten, die dann schlimmstenfalls auch jeweils von einem Teil des Marktes verwendet werden. Das bedeutet vor allem bei Zulieferern Mehraufwand, weil mehrere Technologien zur selben Zeit unterstützt werden müssen.
Um diesem Szenario entgegenzuwirken, gab es beispielsweise zwischen den Boards der OPEN Alliance und der NAV Alliance eine Abstimmung über die Schnittmengen beider Organisationen. In diesem Zuge wurde bereits die Aufgabe, eine EMV-Spezifikation für die Geschwindigkeitsgrade der IEEE 802.3ch-Gruppe (2.5, 5 und 10 Gbit/s) zu erstellen, in eine Arbeitsgruppe der OPEN Alliance überführt. Ebenso kann die IEEE bei einer eventuellen Standardisierung von Automotive Ethernet mit mehr als 10 Gbit/s auf Erfahrungen zurückgreifen, die in der TWG1 der NAV Alliance bis dahin gesammelt und gegebenenfalls freigegeben wurden.
Eine Standardisierungsorganisation sollte eine breite Masse an Experten aus ihrem Industriezweig vereinen, um sicherzustellen, dass aus der Organisation heraus entstandene Standards auch tatsächlich den Bedarf decken und praktische Anwendung finden. Die NAV Alliance begrüßt daher Anfragen weiterer Industriepartner zur Unterstützung aktueller und zukünftiger Arbeitsgruppen.
Links:
[1] http://www.ieee802.org/3/ch/timeline_3ch_1_0318.pdf
[2] http://ieee802.org/802_tutorials/2017-07/tutorial-Automotive-Ethernet-0717-v02.pdf
[3] https://www.techstreet.com/ieee/standards/ieee-1722-2016?product_id=1901168
Der Autor
Daniel Hopf
beschäftigt sich bei Continental mit Anforderungen an zukünftige Kommunikationsnetze und untersucht diese speziell auf deren Eignung für echtzeit- und sicherheitskritische Anwendungen. Er studierte Informatik an der Ostbayerischen Technischen Hochschule in Regensburg und erlangte dort seinen Bachelor- und Masterabschluss. Im Rahmen seiner Standardisierungsarbeit leitet Daniel Hopf die Marketing Working Group der NAV Alliance.