It’s all about time: Zeitkritische Netze
Wir sind es gewohnt TV- oder Radiostreams in Echtzeit aus dem Internet anzusehen oder anzuhören oder aber mit unseren Freunden oder Kollegen über diverse Messenger zu telefonieren oder Videokonferenzen abzuhalten. Doch wie sieht es aus, wenn das Video auf fünf verschiedenen Videowalls auf einem Festival gezeigt werden soll? Stört es hier, wenn das Video nicht absolut zeitgleich erscheint? Ja, auf jeden Fall. Hier stellt sich also die Frage: Wie „echt“ muss Echtzeit sein?
Wie „echt“ muss Echtzeit sein?
Bei der oben beschriebenen „Echtzeit“ sind wir in Wirklichkeit fernab von Echtzeit. Der Videostream eines TV-Senders legt zum Konsumenten einige Stationen auf dem Weg zurück, die Zeit kosten. Das Bild wird von einer Kamera eingefangen, digitalisiert, codiert bzw. komprimiert und, ohne weitere Modifikationsschritte einzubeziehen, an einen Streaming-Server gesendet. Je nach eingesetztem System oder CDN (Content Delivery Network) wird dieser Stream vervielfältigt und weiteren Servern zur Verfügung gestellt, von denen der Konsument den Stream schließlich herunterlädt.
Bei allen Schritten kommen Puffermechanismen zum Einsatz, welche die Weiter- und Wiedergabe des Videos künstlich verzögern um bei kurzzeitigen Transferschwankungen oder -Unterbrechungen dem Konsumenten trotzdem ein unterbrechungsfreies Video darstellen zu können. In diesem Beispiel können einige 100 Millisekunden oder gar Sekunden zusammenkommen, bis das ursprünglich von der Kamera eingefangene Bild am Zieldisplay angezeigt wird.
Übernimmt man dieses Beispiel auf die Internettelefonie bzw. Voice-over-IP (VoIP) schlussfolgert man zwangsweise, dass sich dies nicht zum Telefonieren eignet.
Ziel der Internettelefonie ist es also, die Zeit zwischen dem Gesprochenem und der Wiedergabe auf ein Minimum zu reduzieren.
Ein Daumenwert besagt, dass die One-Way-Latency, also die „Zeit von Mund zu Ohr“, nicht größer als 150 ms sein sollte.
Gehen wir nun einen Schritt weiter und nehmen eine Mund-zu-Ohr-Latenz von 50 ms im LAN an und klammern alle Variablen des Internets aus. Man stellt fest, das Telefonat läuft hervorragend. Ist dies nun wirklich „genug“ Echtzeit?
Nehmen wir nun zwei Beispiele, die anspruchsvoller sind als ein Mensch an einer Seite des Telefonats: Eine Zweiachsige CNC-Fräse und eine Musikfestival.
Beispiel CNC-Fräse
An der CNC-Maschine (Abb. 1) werden zwei Motoren angesteuert, einer für die X- und ein anderer für die Y-Bewegung des Fräskopfes. Das Ziel ist das Fräsen eines 45° Winkels in das Werkstück. Hierzu steuern wir beide Motoren gleichzeitig für drei Sekunden an und lassen den Fräskopf mit einer Geschwindigkeit von 1 cm/s nach unten und nach links fahren. Das Ergebnis ist ein gefräster 45° Winkel, bei dem beide Achsmotoren gleichzeitig zum Stillstand kommen. Abbildung 2 illustriert die Positionen des Fräskopfes zu den Zeitpunkten t1 = 1 s, t2 = 2 s und t3 = 3 s.
Nehmen wir nun an, dass der Motor für die X-Achse um 50 ms später angesteuert wird, so ergibt sich zwar auch ein 45° Winkel im Werkstück, jedoch mit einem Versatz sowie einem 0,5 mm langen vertikalen Einschnitt zu Beginn und einem ebenso langen horizontalen Einschnitt am Ende. Abbildung 3 (nicht maßstabsgetreu) zeigt den Soll-Fräsweg (grün) sowie den Ist-Fräseweg (rot). Dies resultiert aus dem Stehen des X-Achsmotors zu Beginn und dem Stehen des Y-Achsmotors am Ende des Vorgangs. In diesen 50 ms fährt einer der Motoren eine Strecke von 0,5 mm. Bei Genauigkeitsanforderungen von einem Hundertstelmillimeter ist dies kein akzeptables Ergebnis.
Beispiel Festival
Ein Sänger auf der Bühne nimmt zurecht an, dass sein Gesang in genau dem Moment aus seinen Monitorlautsprechern sowie aus den Hauptlautsprechern tönt, wenn die Schallwellen aus seinem Mund sein Mikrofon erreichen
Natürlich treten auch auf diesem Weg Latenzen auf. Je nach eingesetzter Technik wandelt das Mischpult das Mikrofonsignal in ein digitales Signal um, führt es über diverse Wege durch eine Nachbearbeitung (z. B. Audioprozessoren), schickt es zu den Endstufen, welche schließlich das Signal zu den Lautsprechern verstärken. Auf diesem Weg durchläuft das Signal diverse Prozesse, Puffer, A/D- und D/A-Wandler, von welchen jeder einzelne Latenzen erzeugt. Für den Menschen sind diese Latenzen aber so gering, dass er sie nicht wahrnehmen kann.
Betrachten wir nun aber die Akustik, können Latenzen schwerwiegende Auswirkungen haben. Angenommen wird, dass die Lautsprecher links und rechts der Bühne von jeweils unterschiedlichen Endstufen angesteuert werden und diese das Audiosignal über das Netzwerk zugestellt bekommen.
Ein Audiosignal mit einer Frequenz von 1 kHz hat eine Periodendauer von 1 ms.
Wird das Audiosignal nun auf dem linken Lautsprecher nur 0,5 ms früher oder später wiedergegeben als auf dem rechten, führt dies zu einer Phasenverschiebung von 180° der beiden wiedergegebenen Schallwellen zueinander, was in Addition eine vollständige Auslöschung bewirkt.
Man sieht hier, dass es in diesem Anwendungsfall noch deutlich kritischer ist, die Latenzen im Griff zu haben.
Keine Latenz vs. Determinismus
Der wohl naheliegendste Gedanke scheint, die Latenzen so weit zu minimieren, dass diese überhaupt keinen Einfluss mehr haben können. Dieses Vorhaben ist technisch so nicht möglich. Latenzen werden immer Bestandteil eines Signalweges sein.
Erinnern wir uns kurz an das Mischpult. Wie schon beschrieben, treten auch hier Latenzen auf. Wie schafft es die Audioindustrie dann aber die Signale dennoch problemlos an weitere Geräte abzugeben?
Die Lösung liegt darin zu wissen, welcher Vorgang welche Latenzen erzeugt und hier Abstimmungen vorzunehmen. Als Beispiel nehmen wir ein Mikrofon an Mischpultkanal 1 und einen CD-Player an Kanal 2. Das Mikrofonsignal schicken wir im Mischpult durch einen Equalizer und einen Dynamikprozessor. Das CD-Signal bleibt unbearbeitet. Senden wir nun das Mikrofonsignal und das CD-Player-Signal absolut zeitgleich in das Mischpult, könnte das CD-Signal das Mischpult früher wieder verlassen als das Mikrofonsignal, denn letzterem werden zusätzliche Latenzen angehängt.
Das Hauptziel hierbei ist nicht, die Latenz gegen Null zu optimieren, sondern dafür zu sorgen, dass beide Signale das Mischpult gleichzeitig verlassen. Ein Lösungsansatz ist zu wissen, dass selbst bei Nutzung aller Möglichkeiten des Mischpults, die Latenz nie mehr als 3 ms betragen kann. Hierbei werden die Signale mit einer festen Verweildauer von 3 ms versehen. Benötigt ein Signal diese 3 ms nicht, wird es zurückgehalten bis die Zeit abgelaufen ist. Somit verweilt auch das CD-Player-Signal 3 ms im Mischpult und die beiden Signale können zeitgleich ausgespielt werden.
Die Lösung
Die Lösung unseres Problems liegt somit in erster Linie nicht in der Eliminierung der Latenzen, auch wenn dies natürlich ein sekundäres Ziel ist, sondern in der Festlegung (Determinismus) bzw. Absehbarkeit von auftretenden Latenzen, so dass diese schlussendlich mit einer Gegenmaßnahme ausgeglichen werden können.
Zeitsynchronisation
Um für das Problem eine Gegenmaßnahme vorzunehmen, wie z. B. das o. g. „künstliche Zurückhalten“ von Signalen, bedarf es einer einheitlichen Zeit.
Im Beispiel des Mischpultes ist dies noch recht einfach. Hier wird dem eingehenden Signal ein Eingangszeitpunkt und ein errechneter Ausgangszeitpunkt angeheftet – aber relativ zur internen Zeit des Mischpultes. Wie sieht es nun aus, wenn das Signal das Mischpult verlässt und an 10 Endstufen weiterleitet? Jede Endstufe kann das Ausspielen des Signals natürlich wiederum um eine bestimmte Zeit verzögern. Die Schwierigkeit hierbei liegt aber darin, dass alle Endstufen die identische Ausspielzeit haben müssen, obwohl die Eingangszeit unterschiedlich sein kann.
Ein Lösungsweg ist, dass das Mischpult den Ausspielzeitpunkt festlegt. Dann müssen aber die internen Uhren der Endstufen mit der Uhr des Mischpultes synchronisiert werden.
Grundsätzlich kein Problem – Netzwerkprotokolle wie NTP (Network Time Protocol) sind quasi in jedem Netzwerkgerät vom PC über Switche bis hin zum Smartphone integriert. Problem hierbei ist die Genauigkeit. NTP schafft es eine Synchronisierung von Uhren mit einer Abweichung von ca. +/- 1 ms, manchmal auch genauer, zu erreichen. Reicht doch, oder?
Treiben wir das Audiobeispiel kurz ins Extrem. Professionelle Audiogeräte arbeiten mit Samplingraten von bis zu 96 kHz. Das heißt, dass eine Sekunde Audio aus 96.000 Abtastwerten besteht, also ein Wert ca. alle 10 Mikrosekunden.
Soll ein solches Audiosignal absolut phasensynchron an mehrere Geräte verteilt werden, heißt dies, dass die Geräte zueinander eine Zeitabweichung von weit weniger als 10 Mikrosekunden, also 0,01 Millisekunden haben müssen. Die µs-Genauigkeit (oder noch genauer) mit NTP zu erreichen ist nahezu unmöglich. Hierzu hat sich ein weiteres Protokoll etabliert – das Precision Time Protocol, kurz PTP.
Software und Hardware
Das Problem scheint doch nun gelöst – ein Lösungsweg und die nötigen Protokolle sind verfügbar. Nicht ganz.
Abb. 4 zeigt einen vereinfachten Hardwareaufbau eines Switch- oder Netzwerkkartenports zusammen mit dem darüberliegenden Software-Layer. Ein Netzwerkpaket geht am physischen Port ein, wird vom PHY (Physical Layer) gelesen und anschließend vom MAC-Layer als Ethernet-Paket interpretiert. Dieser übergibt die Daten an den integrierten Schaltkreis, welcher die Daten schlussendlich dem Betriebssystem präsentiert. Das Betriebssystem vergibt dem Paket nun einen Stempel mit der aktuellen Uhrzeit. Das Senden eines Pakets verläuft in die umgekehrte Richtung.
Problem dabei ist, dass die Übertragungszeit vom PHY bis zum Betriebssystem schwanken kann und per se überhaupt existiert. Der jetzt vergebene Zeitstempel stimmt also nur mäßig genau mit dem tatsächlichen Empfangszeitpunkt überein. Beim Versenden eines Pakets ist die Ungenauigkeit noch größer, denn ein vom Betriebssystem vergebener Zeitstempel bezeichnet den Zeitpunkt der Datenübergabe an den obersten Hardware-Layer. Zu diesem Zeitpunkt bekommt die Hardware aber noch keinen Medienzugang, sprich das Paket ist zu diesem Zeitpunkt noch nicht bereit „auf das Kabel gelegt zu werden“.
Wie soll auf dieser Basis überhaupt erst eine genaue Zeitsynchronisation der Uhren stattfinden?
Die Lösung besteht darin, den Zeitgeber nicht nur dem Betriebssystem zu präsentieren, sondern auch dem PHY. Die Aufgabe des Timestampings kann somit dem PHY auferlegt werden (Abb. 5) und die Latenz sowie die Schwankungen auf dem Weg bis zum Betriebssystem werden unwichtig.
Da diese Funktionalität tatsächlich in Hardware abgebildet sein muss, lohnt sich bei Netzwerkkarten und Switchen ein Blick ins Datenblatt, ob die verbauten Chips eine PTP- bzw. IEEE 1588-Unterstützung implementiert haben.
Ein Blick auf das Ethernet
Nun sind bereits viele Themen abgehandelt – widmen wir uns dem Datentransport über Ethernet, dem am meisten verwendeten Netzwerkstandard.
Ethernet ist ein nicht-deterministisches Netzwerk. Betrachten wir den Transport eines Ethernet-Pakets, so durchläuft dieses Netzwerkkarten und Switche/Bridges. Zu der variablen Durchlaufzeit in der Sende- und Empfangsnetzwerkkarte kommt ein weiterer variabler Faktor – ein Switch oder gar mehrere Switche.
Je nach Typ (Store-and-Forward, Cut-Through) und angewandten Funktionen, wie z. B. ACLs oder QoS, werden die Verweil- bzw. Weiterleitungszeiten eines Pakets beeinflusst. Dazu kommt, dass selbst bei Bekanntsein der Verweilzeit, der Absender nicht weiß, wie viele Switche bis zum Ziel zu passieren sind. Schlimmster Fall zum Schluss – ein überlastetes Netzwerk. Ethernet ist und bleibt also nicht deterministisch.
Mit den bereits benannten Möglichkeiten der Zeitsynchronisation und dem vorab absolut festgelegten Zeitpunkt der „Aktionsausführung“ erreichen wir nun schon eine sehr zuverlässige und präzise Lösung. Jedoch fehlt noch eine Hürde – ein überlastetes Netzwerk.
In einem solchen Fall werden selbst die „wohlberechneten Ausführungszeitpunkte“ irrelevant, denn das Paket könnte erst nach der „Aktionszeit“ am Ziel eintreffen – oder noch schlimmer – gar verworfen werden.
Eventuell leidet sogar die Zeitsynchronisation unter einer Überlastung.
Ein Netzwerktechniker mag nun sagen, QoS sei die Lösung. Damit hat er nicht unrecht. Jedoch sprechen wir gerade über exemplarische Anwendungsszenarien in der Industrie und der Audiotechnik. Bei Betreuern solcher Anlagen besteht kein Anspruch Netzwerkexperte zu sein. Es muss also eine Art Auto-Config her – welche bereits seit einiger Zeit existiert.
AVB/TSN
Audio-Video-Bridging (AVB) bzw. Time-Sensitive Networking (TSN) wurde bereits in IEEE 802.1 spezifiziert und besteht im Wesentlichen aus Erweiterungen des IEEE 802.1Q Standards. Dahinter verbirgt sich ein ganzes Framework von Teilspezifikationen, die in Summe dazu führen, dass ein Gerät seinen Datenstream ankündigen und sich die Netzwerkinfrastruktur darauf einstellen kann. Das heißt, Switche können ihre QoS-Richtlinien und Forwarding-Strategien so anpassen, dass der vom Sender angekündigte Bandbreitenbedarf sowie der Allgemeinbedarf in Bezug auf Latenz und Zuverlässigkeit erfüllt werden kann.
Bestandteil von AVB/TSN ist ebenso die Zeitsynchronisation über gPTP – einem allgemeineren oder generalisierten PTP-Standard.
Umsetzungen
Momentan existieren von vielen Herstellern bereits Implementierungen für AVB/TSN, doch fehlt es vor allem bei industriellen Anwendungen an Standards. Nur weil ein Roboter von Hersteller A TSN-fähig ist, heißt dies nicht, dass die Applikation von Hersteller B diesen auch steuern kann. Hier finden sich häufig proprietäre Implementierungen, welche sich der TSN-Standards bedienen aber noch nicht herstellerübergreifend anwendbar sind.
Einen branchenweiter Standard könnte sich aus den Protokollen OPC-UA over TSN oder Profinet over TSN entwickeln.
Der professionelle Audiomarkt ist hier bereits weiter. Unter der Schirmherrschaft der Avnu Alliance wurde der Milan-Standard entwickelt. In diesem marktreifen Standard sind alle Protokolle, Paketformate, Datenformate sowie Audio- und Videoprofile beschrieben, die zur Übertragung von Audio und Video unter der Nutzung von AVB/TSN notwendig sind. Zudem lassen sich auch Steuerungsinformationen übertragen, über welche Matrizen für das gesamte Signalrouting realisierbar sind.
Fazit
AVB/TSN ist ein hochinteressantes Thema, das Ethernet branchenübergreifend für weitere Anwendungsgebiete interessant und nutzbar machen wird. Die erfolgreiche Implementierung und Nutzung sowie die Lösungsentwicklung hängen hier maßgeblich von einem interdisziplinärem Verständnis der unterschiedlichen involvierten Teilbereiche sowie auch von Branchenwissen ab.
Wir sind an allen Erfahrungen, Problemen und Implementierungen interessiert. Bitte melden Sie sich per E-Mail bei uns.