Time Sensitive Networking (TSN) wird branchenübergreifend als die Basis zukünftiger konvergenter Echtzeit-Netzwerke gesehen. Bisherige Echtzeit-Lösungen sind typischerweise geschlossene und für spezifische Anwendungen ausgelegte All-in-one Systeme von der Hardware über die Software bis zum Applikationsprofil. Anders TSN: Es ist schlichtweg eine Sammlung von Erweiterungen des Ethernet-Standards, die verschiedene Funktionen für eine deterministische Kommunikation zur Verfügung stellen.

Die relevantesten Mechanismen sind die Zeitsynchronisation nach 802.1AS, das Traffic Shaping auf Zeitbasis (802.1Qbv) oder Credit-Basis (802.1Qav), die Möglichkeit des Unterbrechens von Frames (Frame-Preemption, 802.1Qbu) sowie Standards zur Redundanz und zur Konfiguration des Netzwerkes.

Welche dieser Mechanismen in welcher Kombination und Konfiguration und mit welchen Performance-Eigenschaften – wie Genauigkeiten oder Speichergrößen – für eine bestimmte Anwendung genutzt werden sollen, ist in den TSN-Basisstandards nicht weiter festgelegt. Für individuelle Applikationen lassen sich typischerweise verschiedene Lösungen finden. Die Auswahl hat allerdings signifikanten Einfluss auf die benötigte Hardware und Software von Infrastruktur und Endpunkten, sowie auf die Interoperabilität zwischen diesen. Geräte, die alle Standards in maximaler Ausgestaltung mit allen Konfigurationsoptionen unterstützen würden, wären sehr aufwendig und teuer. Applikationsspezifische Lösungen hingegen haben immer den Grundgedanken von Standard-Hardware und günstiger Hardware. Der Markt hat daher ein großes Interesse, Profile für bestimmte Anwendungsklassen zu definieren. Im TSN-Umfeld haben sich für verschiedene Branchen Gruppen gefunden, insbesondere für die Branchen Industrial, Automotive, ProAV sowie Aviation, die sich daran gemacht haben, Profile zu definieren. Diese unterscheiden sich in den technischen Details. Sie unterscheiden sich aber auch hinsichtlich der Frage, ob ein Profil lediglich vorgibt, was Infrastruktur und Endpunkte unterstützen müssen oder ob das Profil auch für die Interoperabilität zwischen daraufbasierender Applikationen sorgt.

Wie weit sind nun die einzelnen Profil-Arbeiten gediehen? Mitarbeiter und Spezialisten der Fachkreise fassen die bisherigen Ergebnisse und den Status quo der jeweiligen Aktivitäten zusammen.

Milan – Das TSN-Profil der ProAV Industrie

Die Hersteller der Audio/Video-Branche erarbeiten auf der Basis von TSN ein Systemnetzwerk namens Milan. Zum aktuellen Status der Arbeiten bezieht Henning Kaltheuner Stellung. 
 

Henning Kaltheuner, Head of Strategic Business Development and Market Intelligence bei dbaudio: »Als Netzwerk, welches besonders auch mobil genutzt wird, muss Milan Plug and Play unterstützen.«

© dbaudio

Herr Kaltheuner, welche Motivation liegt den Milan-Arbeiten zugrunde?

Henning Kaltheuner: Milan wurde auf Initiative einiger führender Hersteller der ProAudio Industrie im Herbst 2016 ins Leben gerufen. Die hauptsächliche Motivation liegt in der Notwendigkeit, bisher einzeln betrachtete und vermarktete Produkte – Lautsprecher, Verstärker, Processing/Mixing – zukünftig nur noch in einem vernetzten Systemkontext sinnvoll posi-tionieren zu können. ‚Everything will be networked‘ ist in der ganzen Breite der ProAV Industrie eine unumstrittene Perspektive, das ‚Wann‘ und ‚Wie‘ war jedoch lange Zeit offen.

Entscheidend ist dabei, wenn System und Netzwerk wesentliche Teile des Kundennutzens in der Applikation darstellen, dann müssen Hersteller diese Aspekte selbst beherrschen und in kreative Lösungen umsetzen können. Dies ist auf der Basis proprietärer Protokolle nicht möglich, sondern erfordert Zusammenarbeit an offenen Standards. TSN ist dabei zukunftsweisend.

Was wäre ein typischer Use-Case der durch das Profil abgedeckt ist? Können Sie typische KPIs benennen?

Milan wird als Systemnetzwerk Anwendung finden auf Veranstaltungen aller Art, großen Konzerten und Festivals, in Medieninstallation in Theatern, Opernhäusern, Konzertsälen, Kirchen und Konferenzzentren sowie für Medien in allgemeinen Gebäudeinstallationen für kommerzielle Anwendungen wie Shops und Unternehmen.

Als Netzwerk, welches besonders auch mobil genutzt wird, muss Milan Plug and Play unterstützen. Solche Netzwerke umfassen Komponenten von sehr verschiedener Komplexität und Bandbreite. Skalierung des Standards von kleinen Endpoints bis hin zu Einheiten mit tausenden von Audiokanälen ist ein essenzieller KPI.

Welche Standards nutzt Milan in welcher Ausprägung?

Milan basiert im Wesentlichen auf IEEE 802.1BA-2011, 802.1Q-2014, 802.1AS-2011, IEEE 1722-2016 und IEEE 1722.1-2013. Dabei spezifiziert Milan über-wiegend, welche Teile dieser Spezifikationen in welcher Weise verwendet werden, um einen tatsächliche End-to-End Interoperabilität zu erzielen.

Darüber hinaus spezifiziert Milan selbst ein optionales Redundanzschema für Endpoints, welches zwei Netzwerk-Ports als Primary und Secondary mit nahtloser Umschaltung bei Netzwerk-Ausfällen definiert.

Es ist wichtig zu beachten, dass Milan Endpoints als Switche alle Avnu-zertifizierten AVB-Switche verwenden können.

Ist Interoperabilität von auf dem Profil basierenden Anwendungen ein Ziel?

ProAV Systeme bestehen aus heterogenen Komponenten und werden je nach Use Case zusammengestellt. Nahtlose Interoperabilität auf der Netzwerk-Ebene ist unabdingbar und dies schließt grundlegende Funktionalität bezüglich Stream Connectivity, Device Enumeration & Control und Redundanz ein. Milan als Interoperability Profile deckt diese Aspekte auf Basis der IEEE-TSN-Standards ab. Die meisten Hersteller haben dennoch überwiegend eigene Applikationen, die meist keine Allgemeingültigkeit beanspruchen, sondern die Grundlage für die spezielle Value Proposition des Herstellers bilden. Dies ist jedoch kein Widerspruch, sondern verdeutlicht die Möglichkeiten einer Systemstruktur, wo ein gemeinsam vereinbarter Netzwerk-Layer Raum bietet für individuelle Innovation und Kooperationen. Netzwerk soll und darf keine Zwangsjacke einengender Regeln sein, sondern muss Raum für technische und geschäftliche Möglichkeiten bieten.

In welchem Entwicklungsstand ist das Profil? Wann ist ein Release zu erwarten?

Milan existiert in einer ersten Version bereits seit 2019. Ein erster Zertifizierungsprozess läuft seitdem an der UNH in Boston und etliche Produkte sind bereits erfolgreich zertifiziert und im praktischen Einsatz. Dazu gehört auch ein Prozess für zertifizierte Module, sodass Hersteller diese als schnellen Einstieg in Milan ohne großen Entwicklungs- und Zertifizierungsaufwand in ihren Produkten nutzen können.

Im Herbst 2021 startet die Avnu Alliance ein neues Zertifizierungsprogramm auf der Basis eines neuen vereinfachten automatisierten Testtools und mit neuen internationalen Testlaboren als Partner. Dies wird es den vielen kleinen Herstellern in der ProAV Industrie zukünftig wesentlich einfacher machen, ihre Produkte zertifizieren zu lassen.

Wo liegen noch die größten Herausforderungen?

Unternehmen in der ProAV Industrie sind meist mittelständisch und haben beschränkte Ressourcen, um komplexe Technologiestandards zu entwickeln. Milan ist strategisch betrachtet eine technische und geschäftliche Notwendigkeit und dennoch gerade in Pandemiezeiten für eine arg beeinträchtigte Industrie eine große Herausforderung. Zum Glück hat sich zwischen den Firmen ein Klima sehr konstruktiver Zusammenarbeit entwickelt, die weit über die technischen Aspekte hinaus die Bedeutung und Notwendigkeit von Netzwerken im ganz allgemeinen Sinne verdeutlicht.

P802.1DG – Das TSN-Profil für die Automotive In-Vehicle Ethernet Kommunikation

Die Automobilindustrie erarbeitet auf der Basis von TSN das Profil IEEE P802.1DG. Zum aktuellen Status der Arbeiten bezieht Max Turner Stellung. 

Max Turner, Automotive Network Architect bei Ethernovia BV: »Die größte Herausforderung liegt darin, dass wir nicht genau wissen, wie zukünftige Mobilitätskonzepte aussehen sollen.«

© Ethernovia

Herr Turner, für welche Anwendungen wird das Profil P802.1DG entwickelt?

Max Turner: Wir entwickeln IEEE P802.1DG für die Automobilbranche. Das heißt, in erster Linie für den Einsatz in privaten Personenkraftwagen. Auch wenn zu erwarten ist, dass Pkw zunehmend mit ADAS-Funktionen ausgestattet sein werden, halte ich es für interessant zu untersuchen, wie dieselben Technologien auf tatsächlich selbstfahrende Robo-Taxis angewendet werden könnten.

Was wäre ein typischer Anwendungsfall, den das Profil abdeckt? Was sind typische KPIs?

Das Profil soll alle fahrzeuginternen Netzwerk-Architekturen abdecken, das heißt von domänenbasiert bis zonal. Allgemeine Auffassung ist, dass ein Ethernet-basiertes Netz der Branche am dienlichsten ist, da mehrere Dienste wie Steuerung, Audio/Video und Webverkehr über dasselbe Kabel übertragbar sind. Dies hat sich als ‚Triple-Play‘ in der Heim- und Büroumgebung schon seit einigen Jahren durchgesetzt, nur im Auto verwenden wir bis dato noch meist spezialisierte Bussysteme für verschiedene Anwendungsbereiche.

Was die KPIs anbelangt, so stehen an erster Stelle die Latenzzeit und dann die Latenzschwankungen und der Pufferbedarf bei Switches.

Welche Standards verwendet das Profil P802.1DG und in welchem Umfang?

Ich möchte insbesondere IEEE Std. 802.1AS für die Zeitsynchronisation erwähnen, sowie IEEE 802.1Q im Allgemeinen. Der Credit Based Shaper – kurz CBS – des IEEE Std. 802.1Qav ist bereits seit etwa zehn Jahren in einigen Fahrzeugen im Einsatz und wird sicherlich ebenfalls abgedeckt. Eine ganz ähnliche Funktionalität bietet der Asynchronous Traffic Shaper – kurz ATS – in IEEE Std. 802.1Qcr, der das Per-Stream Filtering and Policing – kurz PSFP – von IEEE Std. 802.1Qci voraussetzt, das natürlich auch für andere Funktionen interessant ist. Die Ähnlichkeiten mit bekannten zeitgesteuerten Systemen setzen den Time Aware Shaper  – IEEE Std. 802.1Qbv: Scheduled Traffic –  auf die Liste. Für bestimmte Audioanwendungen ist sicherlich Frame Preemption – IEEE Std. 802.1Qbu und IEEE Std. 802.3br – im Gespräch.

Die weitere Liste ist leider recht lang, wenn man sich auch einige der Konfigurations- und Netzwerk-Management-protokolle – im IT-Sinn, nicht im automobilen Sinn – ansieht.

Ist die Interoperabilität von Anwendungen auf der Grundlage des Profils ein Ziel?

Interoperabilität auf der Schicht-2-Ebene, auf der diese Protokolle spielen, ist definitiv das Ziel und einer der wichtigsten Punkte, die Normungsgremien wie die IEEE anstreben. Abgesehen davon ist die Anwendungsentwicklung im Automobilbereich nicht sehr homogen. Viele OEMs haben Autosar mit ihren eigenen Funktionen und Merkmalen angereichert. Das P802.1DG-Profil ist eher auf die Infrastruktur und die zugrundeliegenden Netzwerk-Technologien ausgerichtet als auf anwendungsspezifische Schnittstellen.

Wie ist der Entwicklungsstand des Profils? Wann kann mit einer Freigabe gerechnet werden?

Das Profil befindet sich noch in einem sehr frühen Entwicklungsstadium. Mit dem Wachstum des TSN-Toolsatzes, wie oben aufgeführt, ist es eine ziemliche Herausforderung, die richtigen Tools für den Anwendungsfall im Automobilbereich auszuwählen. Viele von ihnen wurden für sehr spezifische Anwendungen in Telekommunikations- oder Rechenzen-trumsnetzen entwickelt, und die Analyse der Unterschiede und Gemeinsamkeiten nimmt mehr Zeit in Anspruch als vielleicht ursprünglich erwartet wurde. Wir streben nach wie vor an, innerhalb der nächsten zwei Jahre einen guten Entwurf des Dokuments vorlegen zu können. Die Unsicherheiten im Automobilsektor im Allgemeinen und die Unterbrechung des regulären IEEE-Tagungskalenders aufgrund von Covid-19 haben ebenfalls eine verzögernde Rolle gespielt.

Wo liegen noch die größten Herausforderungen?

Sie liegen in der Ungewissheit über zukünftige Mobilitätskonzepte. Meiner persönlichen Meinung nach werden sich die Architekturen stark unterscheiden: erstens in Pkw, die sich stark auf Fahrerassistenzsysteme, sprich ADAS, der Stufe 2 konzentrieren, zweitens in Pkw, die in bestimmten Szenarien oder ODDs ein gewisses Maß an Automatisierung der Stufe 3 oder sogar 4 bieten wollen, sich aber auf den menschlichen Fahrer als Hauptbediener des Fahrzeugs konzentrieren, und drittens in flottenbetriebenen Robo-Taxis, die im täglichen Betrieb nicht einmal mehr einen menschlichen Fahrer haben, sondern sich vollständig auf das ADAS verlassen, um sie in einer sehr begrenzten Umgebung zu steuern. Es gibt unterschiedliche Meinungen darüber, welches dieser drei Modelle den Markt in zehn oder 20 Jahren dominieren wird. Die OEMs wollen ihre Produktstrategien nicht offenlegen. Sie glauben, dass diese abgeleitet werden könnten, wenn sie ihre Netzwerk-Architekturen detaillierter beschreiben.

IEEE P802.1DP/SAE AS6675 – Das TSN-Profil der Luft- und Raumfahrtindustrie

Die Luft- und Raumfahrtindustrie arbeitet an dem IEEE P802.1DP/SAE AS6675 TSN-Profil. Zum aktuellen Status der Arbeiten bezieht Abdul Jabbar Stellung. 

Abdul Jabbar, Senior Engineer bei GE Research: »Die Luft- und Raumfahrt steht an einem Wendepunkt: Sie braucht einen offenen Netzwerk-Standard für die nächste Flugzeug-Generation.«

© GE Research

Herr Jabbar, für welche Branche und welchen Nutzer wird das Profil entwickelt?

Abdul Jabbar: Das IEEE P802.1DP/SAE AS6675 TSN-Profil wird gemeinsam von IEEE und SAE für die gesamte Luft- und Raumfahrtindustrie entwickelt. Dazu gehören kommerzielle und militärische Flugzeuge, unbemannte Flugzeuge, Satelliten und andere Raumfahrzeuge. Da das bordeigene Netzwerk mehr als nur die Netzwerkschnittstellen betrifft, würde sich dieses Profil auf viele Beteiligte in der Lieferkette der Luft- und Raumfahrt auswirken.

Was wäre ein typischer Anwendungsfall, der von diesem Profil abgedeckt wird? Was sind typische KPIs?

Die Arbeitsgruppe hat in enger Zusammenarbeit mit der Industrie insgesamt elf Anwendungsfälle und deren Anforderungen gesammelt und einen Bericht veröffentlicht, der auf der Projekt-Homepage verfügbar ist. Ein Beispiel für den Einsatz dieses Profils ist die Flugzeugsteuerungsdomäne – kurz ACD – für das Avioniknetz in Verkehrsflugzeugen oder das Fahrzeugmanagement-Netz in Militärflugzeugen. Diese Anwendungsfälle erfordern Determinismus, hohe Verfügbarkeit und Zuverlässigkeit. Es überrascht nicht, dass die KPIs in diese Kategorien fallen und Latenzgrenzen, Jitter und Paketverluste umfassen. Eine Anforderung, die über die traditionellen KPIs hinausgeht, ist die Sicherheitszertifizierbarkeit des entstehenden Netzes. Während die Zertifizierung durch eine bestimmte Regulierungsbehörde über den Rahmen des Profils hinausgeht, achtet die gemeinsame Arbeitsgruppe genau auf die Aspekte des Profils – etwa die Komplexität und die Nachweisbarkeit, die für die Zertifizierung eine entscheidende Rolle spielen.

Welche Standards werden verwendet und in welchem Umfang?

Wie alle 802.1-Profile basiert auch das TSN-Profil für die Luft- und Raumfahrt auf den Standards IEEE 802.1 und IEEE 802.3. Insbesondere verwendet das Profil TSN-Standards zur Zeitsynchronisation, Ingress-Policing und -Filterung, Egress-Shaping, Frame-Replikation und Elimination für Redundanz und letztlich für die Konfiguration. Obwohl das Ziel darin besteht, diese Standards vollständig zu nutzen, erlaubt das Profil je nach Anwendungsbereich in der Luft- und Raumfahrt einen enger gefassten oder auch limitierten Einsatz der Netzwerk-Features. Beispielsweise sind Netz-werke in der Luft- und Raumfahrt in der Regel hinsichtlich der Anzahl der Knoten und der Anzahl der Hops begrenzt.

Ist die Interoperabilität von Anwendungen auf der Grundlage des Profils ein Ziel?

Interoperabilität ist eines der Hauptziele des TSN-Profils für die Luft- und Raumfahrt. Bisher fehlte es in der Luft- und Raumfahrtindustrie an der Inter-operabilität der Netze zwischen Geräten, Anbietern und Plattformen. Das Ziel dieses Profils ist es, eine nahtlose Interoperabilität zwischen Endsystemen und Switches zu ermöglichen, sodass Systemintegratoren Systeme effizienter aufbauen können. Die Interoperabilität von Anwendungen ist kein Ziel dieses Profils.

Wie ist der Entwicklungsstand des Profils? Wann kann mit einer Frei-gabe gerechnet werden?

Die Entwicklung eines IEEE-Profils umfasst in der Regel drei Schritte: Sammlung von Anwendungsfällen, Ableitung von Anforderungen aus Anwendungsfällen und Entwicklung einer Profilspezifikation, die die Anforderungen der Anwendungsfälle erfüllt. Im Falle des TSN-Profils für die Luft- und Raumfahrt sind die ersten beiden Schritte bereits abgeschlossen. Die Gruppe arbeitet nun an einer Profilspezifikation mit TSN-Merkmalen, die den Anforderungen der Anwendungsfälle in der Luft- und Raumfahrt entsprechen. Der voraussichtliche Fertigstellungstermin gemäß dem Projektgenehmigungsantrag ist der April 2023. Das Profil sollte aber schon
deutlich früher technisch fertig sein. In Übereinstimmung mit dem IEEE-Standardentwicklungsprozess werden Entwürfe auf der Projekt-Homepage verfügbar sein, sobald der Standard ausgereift ist.

Wo liegen die größten Herausforderungen?

Zwar stehen noch einige wichtige Aufgaben im Zusammenhang mit der theoretischen Analyse von Traffic Shapern und Policern für Luft- und Raumfahrtnetze an, doch die größte Herausforderung ist der Zeitmangel der Experten für TSN und die Luft- und Raumfahrt. Und das zu einer Zeit, in der die Luft- und Raumfahrtindustrie an einem Wendepunkt steht und einen offenen Netzwerk-Standard für die nächste Generation von Fahrzeugen, die gerade entwickelt werden, einführen möchte.

Die Norm IEC/IEEE 60802 – Das TSN-Profil für die Industrie-Automation

Die Automatisierungsbranche arbeitet an der Norm IEC/IEEE 60802 für ein TSN-Profil. Zum aktuellen Status der Arbeiten bezieht Ludwig Winkel Stellung. 
 

Ludwig Winkel, Consultant für Standards & Regulations: »Wir erwarten ein erstes Release der 60802 bis Ende 2022.«

© Ludwig Winkel

Herr Winkel, für welche Branche und Anwender wird das Profil entwickelt?

Ludwig Winkel: Die Norm IEC/IEEE 60802 ist für die Industrie-Automation gedacht. Sprich: Für Anwender überwiegend aus den Fertigungs- und Prozesstechnik-Industrien.

Die IEEE 802.1 Task Group TSN hat in den letzten Jahren einen Baukasten von vielfältigen technischen Möglichkeiten erarbeitet, der in sich nicht als System betrachtet werden kann und sich zum Teil gegenseitig ausschließt. Diese Standards wurden primär von der Informations- und Kommunikationsbranche erzeugt. Aus Sicht des OSI-Modells sind nur die Schichten 1 und 2 im Scope der IEEE 802. Ein oder mehrere ‚Time-sensitive networking‘-Profile – sprich TSN-Profile – sind für die Industrie-Automation notwendig für den sinnvollen Einsatz der vielfältigen technischen Möglichkeiten, die die verschiedenen Standards der Arbeitsgruppen in IEEE 802 bieten.

Was wäre ein typischer Use-Case, der durch das Profil abgedeckt ist? Können Sie typische KPIs benennen?

Ein wesentlicher Use Case der Norm ist der Ansatz des konvergenten Netzwerkes. Sprich: Die Endanwender wollen die Real-time Ethernet-Kommunikationsprofile der Norm IEC 61784-2 nebeneinander auf einer gemeinsamen Infrastruktur – gemeinsame Switches und eine Verkabelung – betreiben. Zudem wollen sie Teile der Standards in IEEE 802.1 Task Group TSN gemeinsam benutzen. Es werden vermutlich nicht alle 25 Profile die Norm 60802 unterstützen, jedoch die am Markt meist verbreiteten Konsortien, wie PNO, ODVA, OPC-F, CC-Link und Ethercat, unterstützen 60802 durch die aktive oder passive Teilnahme ihrer Experten.

Welche Standards werden in welcher Ausprägung genutzt?

Die Norm 60802 konzentriert sich auf vier Nutzungsbereiche, was natürlich auch Auswirkungen auf die verwendeten beziehungsweise zu generierenden Standards hat:

Erstens: das konvergente Netzwerk. Diesen Ansatz prägen im Wesentlichen zwei IEEE 802-Standards: die Uhrzeitsynchronisation auf Basis von IEEE 802.1AS und der Preemption-Mechanismus für Übertragungsgeschwindigkeiten von 10, 100 und 1000 MB/s, der die kleinen Latenzzeiten mit geringem Jitter gewährleistet.

Zweitens: die Planung und Parametrierung der TSN-Kommunikations-Domänen: Ein konvergentes Netzwerk, das Komponenten unterschiedlicher Hersteller aufweisen soll, benötigt ein genormtes Modell und eine genormte Schnittstelle für die Planung und Parametrierung. Deshalb laufen hierzu mehrere IEE 802.1-Erweiterungsprojekte.

Drittens: Die Systemeigenschaften der TSN-Kommunikations-Domänen: Systemeigenschaften waren in der Vergangenheit bei IEEE 802 selten bis nicht existent. Die Devise war, dass die Standards per device normative Elemente beinhalten. Betrachtungen wie etwa „Wie lange dauert die Übertragung über 64 Switches“ wurden nicht beantwortet. Seit Juli 2020 hat sich die 60802 Joint Working Group gegenüber der IEEE 802.1 durchgesetzt, auch die Systemeigenschaften zu betrachten.

Viertens: die Sicherung der Übertragung: Die Anforderungen der Industrie-Automation an das konvergente Netzwerk bedingt insbesondere einen konvergenten Cybersecurity-Ansatz. Im Rahmen von 60802 sollen die hierfür notwendigen Voraussetzungen geschaffen werden.

Ist Interoperabilität von auf dem Profil basierenden Anwendungen ein Ziel?

Die Anwendungen der Industrie-Automation verlangen eindeutig nach Interoperabilität.

In welchem Entwicklungsstand ist das Profil? Wann ist ein Release zu erwarten?

Laut den ersten Planungen sollte das Projekt in 2021 schon abgeschlossen sein. Die Verheiratung von IEC mit IEEE ist ein Grund für die Verzögerung, weil die Prozesse von IEC und IEEE durchlitten werden müssen.

Der Entwicklungsstand des 60802-Projektes ist, dass ein viertes Committee Draft Dokument bei IEC zirkuliert zur Kommentierung. Das Dokument ist identisch mit dem D1.3 Dokument bei IEEE 802.1, das als ‚TSN-Task Group ballot‘ abgestimmt wurde. Ein erstes Release der 60802 ist Ende 2022 zu erwarten. Die Publikation der Edition 1 ist für 2023 geplant.

Wo liegen die größten Herausforderungen?

Die Systemaspekte, die für die Industrie-Automation eine Selbstverständlichkeit in der Normungsarbeit waren, sind in diesem gemeinsamen Projekt erst seit Juli 2020 eingezogen. Die Interoperabilitätsanforderungen gehen in der Industrie-Automation so weit, dass auch die Mengengerüste von Ressource in den Geräten eine Rolle spielen. Dieser Punkt ist seit Jahren ein Zankapfel, aber wir sind auf einem guten Weg, auch dieses Problem in der zukünftigen Norm 60802 zu lösen.