Ethernet Protokolle – Eigenschaften und Funktionen

Die Wahl eines Ethernet-fähigen Lichtstellpults ist heute nicht ausschließlich von den Pultfunktionen abhängig, sondern immer mehr auch von den Funktionen, die über das Netzwerk zur Verfügung gestellt werden können. Hier ist die Grundkenntnis der wichtigsten Unterscheidungsmerkmale der Netzwerke erforderlich, wenn man eine richtige Systementscheidung treffen will.

Die unterstützten Funktionen reichen von einfachem Übertragen von DMX-Universen und Dimmerrückmeldungen, über die Übertragung von kompletten Showdaten oder Dezentralisierung der Rechenleistung, bis hin zur hierarchische Mehrbenutzer-Anwendungen oder framegenauer Steuerung von Medienservern, verzögerungsfreier Ausgabe auch bei sehr großer Kreisanzahl, geschweige denn die Anbindung an andere Protokolle und deren Funktionalitäten wie VGA, MIDI. Oder Anbindung von Steuerungssystemen für Architektur oder Mediensteuerungen oder gar Integration der Bühnen und Tontechnik wie es z. B. ACN erlauben würde.

Da jedes Systemhaus Funktionalität mit unterschiedlicher Priorität behandelt, sind dementsprechend verschiedene Protokolle mit unterschiedlichem Funktionsumfang auf dem Markt. Somit müsste bei der Auswahl einer Lichtsteueranlage nicht ausschließlich das Pult betrachtet werden, sondern vielmehr die Möglichkeiten, die durch das Netzwerk geschaffen werden können. Bei der Entscheidung handelt es sich um einen Systementscheid, denn die Anbindung von Fremdprodukten anderer Hersteller ist oftmals nicht mit gleichem Funktionsumfang möglich.

Auch hier kann man Parallelen mit der Zeit vor DMX 512 erkennen, als jeder Hersteller sich mit seinem eigenen Protokoll der Konsole auch die Bindung an seine Dimmersysteme und Zubehöre sicherte. Heute jedoch sind über Zusatzgeräte wie Medienserver, Visualisierung, LED-Matrizes, Dimmer- oder sonstige Rückmeldungen, Hausfunktions-Anbindung und vieles mehr wesentlich größere Auswirkungen im Bereich des Systementscheids spürbar und sollten dementsprechend Gewichtung erhalten.

Broadcast, Unicast, Multicast

Jeder Hersteller kann eines der herausragenden Merkmale seines Protokolls mit einem Schlagwort wie z. B. Echtzeit beschreiben. Nur was bedeutet das für den Anwender? Zum Beispiel wird oft von Multicast gesprochen.

Zunächst muss man wissen, dass im Ethernet ein Gerät zu einem anderen Kontakt aufnehmen kann. Dann kann ein Gerät auch alle anderen ansprechen. Anschließend merkt man jedoch, dass es aus Performancegründen durchaus sinnvoll wäre, auch nur bestimmte Gruppen von Geräten anzusprechen. So wurde Multicast entwickelt, das Informationen innerhalb von Gruppenzugehörigkeiten versendet. Hier werden also Gruppen definiert und das Netzwerk regelt bzw. ist verantwortlich, dass eine Zustellung an jedes einzelne Gerät innerhalb der Gruppe erfolgt. Dies ist bei größeren Verbünden besonders interessant, bei denen viele Daten ausgetauscht werden müssen, so wie bei Video- oder Audio-Files – damit eignet sich Multicast bestens für die Anforderungen in der Veranstaltungsbranche.

Dagegen wird mit Broadcast immer an alle gesendet. Dabei werden alle mit dem Datenpaket konfrontiert und dementsprechend sind auch alle Leitungen blockiert. Dies hat allerdings den Vorteil, dass nicht direkt adressierte Geräte mithören und gegebenenfalls diese Informationen verwerten können. Aus diesem Grund wird Broadcast gerne eingesetzt, um Netzwerk-Konfigurationen durchzuführen.

Ein Unicast ist im Gegensatz dazu eine Sender-/Empfänger-Beziehung für jedes Gerät bzw. wenn Teilnehmer direkt untereinander Daten austauschen, kann man auch von Peer-to-Peer sprechen oder von private Transmission.

 

Diese Adressierungsarten können auch Auswirkungen auf das Verhalten von Switches, Routern oder Bridges haben. So werden z. B. bei Broadcast die Datenpakete an alle Ports gesendet, wodurch alle Ports eines Switches belegt sind und somit keine anderen Geräte über den Switch parallel verbunden werden können.

 

 

 

 

 

UDP, TCP

Die Eigenschaften von UDP und TCP, die beide auf der Schicht 4 des ISO/OSI-Modells angesiedelt sind, bzw. warum Multicast eigentlich nur über UDP gut arbeiten kann, erklären sich wie folgt:

TCP (Transport Control Protocol) garantiert eine fehlergesicherte, zuverlässige Transportverbindung zwischen zwei Rechnern. Weiterhin werden die Paketempfänge bestätigt, um bei verloren gegangenen Paketen erneut das Datenpaket zu senden. Das erfolgt im sogenannten „Three Way Handshake“. Zur Verdeutlichung:

Sender: Ich sende Daten
Empfänger: Ja, sende Daten zu mir
Sender: Gut, es geht sofort los

→ Sender sendet die Daten →

Sender: Ich habe fertig
Empfänger: Alles erhalten
Sender: Ich kappe nun die Kommunikation
Empfänger: Mach doch!

Wenn dann ein Paket verloren gegangen ist – was bei großen Datenaufkommen und sehr geringem Headroom vermehrt auftritt – dann wird das verlorene Paket noch einmal gesendet, was das System jedoch zusätzlich belastet. Diese Art von Feedback und wiederholten Sendungen ist nicht ideal, wenn an viele Stationen gesendet werden soll.

UDP (User Datagram Protocol) ist wesentlich einfacher aufgebaut und verzichtet auf Bestätigungen für erfolgreiche oder nicht erfolgreiche Versendung. So gesehen könnte UDP bei verlorenen Datenpaketen ein Problem werden. Dem muss aber nicht so sein, denn die Fehlerberichtigung kann dann in der Applikationsschicht 7 stattfinden. Der Vorteil von UDP ist der schnelle Datendurchsatz, weil er auf den ganzen Overhead verzichtet. So ist der Datentransport mit UDP gerade bei sehr großen Datenmengen enorm schnell.

Vergleich TCP und UDP

Eigenschaft	TCP	UDP
Ende zu Ende Kontrollrolle	ja	nein
Zeitüberwachung der Verbindung	ja	nein
Flow Control (über das Netz)	ja	nein
Reihenfolgerichtige Übertragung	ja	nein
Erkennung von Duplikaten	ja	nein
Fehlererkennung	ja	einstellbar
Fehlerbehebung	ja	nein
Adressierung der höheren Schichten	ja	ja
Three Way Handshake	ja	nein
Größe der Header	20 bis 60 Byte	8 Byte
Geschwindigkeit	langsam	schnell
Belastung der Ressourcen	normal	gering
Unicast	ja	ja
Broadcast	nein	ja
Multicast	In Entwicklung	ja

 

Tracking – Full Tracking Backup

Full Tracking zwischen mehreren Konsolen bedeutet einen ständigen Datenabgleich, damit die Konsolen zu jeder Zeit auf dem aktuellen Stand sind, inklusive aller Showdaten. Im Havariefall ist so die zweite Konsole sofort auf dem aktuellen Stand, ohne die Show erst laden oder auf den entsprechenden Cue-Übergang innerhalb einer Überblendung nachgeregelt werden zu müssen. Nebenbei bemerkt, sollte man hier den Begriff Tracking nicht mit dem Begriff Tracking-Mode verwechseln, der die Aufzeichnungsart des Lichtstellpults beschreibt. Während die deutschen Lichtstellanlagen immer alles aufgezeichnet haben, wenn Record bzw. Speichern gedrückt wurde (im englischen Sprachraum als Cue-Only-Mode bekannt), wird beim Tracking-Mode nur das Speichern von Veränderungen vorgenommen. Dies ist wesentlich Speicherplatz sparender, und zudem viel besser geeignet, um das von Moving Lights benötigte LTP-Vorgehen optimal widerspiegeln zu können. Nun aber zurück zum Thema.

In einem Full Tracking Backup aufbauenden Master/Slave-System ist die Hierarchie im Vorfeld so geklärt, dass bei Ausfall der Hauptkonsole unbemerkt die Havarie die Show übernimmt. Allerdings werden bereits einige Kritiken an dieser Technik laut: Wenn man bedenkt, dass beide Pulte genau das Identische ausführen, dann kann es auch vorkommen, dass ein durch den Ablauf generierter Fehler sich dann naturgemäß auf der zweiten Havariekonsole fortsetzt. Somit hätte man nichts gewonnen.

 

Multitasking – Multiuser

Das „Multitasking Konzept“ wird im Zusammenhang von Lichtstellprotokollen auch als Funktion beschrieben, bei der z. B. der Programmer an der Show arbeiten kann, während die Techniker ihre Wartungsarbeiten durchführen. Dass dabei von verschiedenen Eingabegeräten aus gearbeitet werden kann und derselbe Dimmerschrank reagieren muss, unterscheidet sich zu den bisherigen Systemen in der Art, dass beim Hochziehen eines Kreises und dem Abspeichern der Cue dieser Kreis selbstverständlich als Showkreis mitgespeichert wurde. Beim Multitasking kann der Designer seine Arbeit fortführen, während der Techniker ebenfalls seine Arbeit vollrichtet, ohne dass sie sich ins Gehege kommen bzw. der zu testende Kreis beim Designer mit in der Cue abgespeichert wird.

Multioperator oder Multi User bezeichnet die Fähigkeit eines Systems, bei der mehrere Programmierer auf mehreren Konsolen gleichzeitig an einer Show arbeiten können, die dann in einem einzigen Show-File gespeichert wird und dann z. B. auch nur von einer Konsole aus wiedergegeben werden kann. Dazu definiert man eine Session, zu der alle Geräte, die zu dieser Show gehören sollen, eingeladen werden („Join the session“) oder wieder entfernt werden können („Leave the session“), wenn z. B. die Programmierphase abgeschlossen ist und nun die Show gefahren wird. Dabei kann man die Zuständigkeiten eines Operators auch definieren und sie z. B. in verschiedene „Welten“ aufsplitten: Dabei kann einem Bediener ein bestimmter Bereich von Scheinwerfern zugeordnet werden, für den er dann verantwortlich ist. Damit ist auch ausgeschlossen, dass er z. B. auf andere Bereiche, die sein Kollege betreut, zugreift und manipuliert, ob gewollt oder ungewollt. Es können auch Scheinwerfern mehrere Welten zugeordnet werden, dabei hilft für die Klarheit wieder der Einsatz von Hierarchien.

Anzeige der verfügbaren Pulte im Netzwerk, IP-Adressierung, Prioritätenfestlegung; hier in drei Klassen und Session-Bildung

Echtzeit – Echtzeitfähig

Echtzeitsysteme bzw. Real-Time-Systeme definieren sich so, dass bestimmte Reaktionen innerhalb eines vorgegebenen Zeitintervalls erfolgen oder Berechnungen innerhalb einer bestimmten Frist abgeschlossen sein müssen. Im Gegensatz zu nicht-echtzeitfähigen Systemen kann das Nicht-Eintreten des Ereignisses dazu führen, dass das System vollständig verloren geht oder es zu einem schwerwiegenden Unfall kommt. Im Bereich der Hebezeuge ist dies sehr leicht nachzuvollziehen: Bei einer synchronisierten Fahrt von einer Gruppe von Motoren, müssen die Antriebe ihre Position untereinander nachregeln, um eine bestimmte Toleranzgrenze nicht zu überschreiten. Dazu müssen sie die aktuelle Position eines jeden Zugs den anderen Zügen oder einer zentralen Überwachungseinheit übermitteln. Liegen die zum Vergleich benötigten Positionsstände nicht rechtzeitig zum Vergleich vor, muss von einer Störung ausgegangen werden, da man nun nicht mehr sicher sein kann, ob alle Züge noch innerhalb der Toleranz liegen. Deshalb ist bei Bühnensteuerungen eine Echtzeitfähigkeit normal. Das dennoch „echtzeitfähige“ Übertragungen mit einer Busstruktur und dem Zugriffsverfahren CSMA/CD erfolgen können, wird in der Form realisiert, indem man eine sehr überhöhte Übertragungsgeschwindigkeit anwendet, die Teilnehmeranzahl begrenzt, die übertragenen Daten in feste Protokollschemata presst und keine anderen Geräte Zugriff auf diese Leitung haben.

Unter diesen Voraussetzungen kann man mit extrem hoher Wahrscheinlichkeit davon ausgehen, dass die Daten innerhalb der benötigten Zeitspanne dem Empfänger übermittelt wurden. Anhand dieses Beispiels wird aber deutlich, dass die Topologie alleine nicht ausreicht, um alle Vor- und Nachteile erkennen zu können. Es spielt die Art der Zugriffsmöglichkeiten bzw. der Zugriffsteuerung und der verwendeten Protokolle eine ebenso wichtige Rolle für die Performance der Netzwerktopologie.

Die Marketingfachleute der Eventbranche dehnen den Begriff noch ein wenig und meinen unter echtzeitfähig, wenn das DMX-Signal genauso schnell über Ethernet wiederholt wird wie es auch ohne Netzwerk vorher war. Das ist eigentlich kein Kunststück bei einer Übertragungsgeschwindigkeit eines 10BaseT-Netzwerks, die ca. 40-mal so hoch ist wie die des DMX-512-Protokolls auf RS485-Basis und immerhin 400-mal schneller bei einem 100-Mbit/s-Netzwerk. Durch ein angewendetes Komprimierungsverfahren ist es sogar bei einem 10-Mbit/s-Netz noch möglich, 60 Universen ohne Zeitverzug zu übertragen, jedoch wird empfohlen bei über 20 Universen bereits ein 100-Mbit/s-Backbone zu verwenden.

Unter Backbone versteht man die Haupt-Datenübertragungsstrecke bzw. das Rückgrat eines Netzwerks. Man versucht, um Fehlerauswirkungen möglichst klein zu halten, vom Backbone aus kleinere Segmente zu bilden, innerhalb derer dann die Endgeräte angeschlossen sind und erst auf den Backbone gelangen, wenn eine Verbindung von einem Segment zum nächsten erfolgen muss. Somit sind Fehler wesentlich schneller einzukreisen als wenn jedes Endgerät direkt an der Backbone angeschlossen wäre. Weiterhin kann der Informationstransfer innerhalb der Segmente bereits stattfinden, ohne dass der Backbone belastet wird. Außerdem versucht man den Backbone so schnell wie möglich zu gestalten, um so einen möglichst reibungslosen ganzheitlichen Datentransfer zu ermöglichen – denn wie gesagt: der Backbone ist so etwas wie die Stadtautobahn in Berlin. Aus diesem Grunde wird der Backbone oft auch als Glasfaserleitung ausgeführt, wobei ganz nebenbei auch längere Strecken problemlos bewältigt werden können.

In der Praxis hat sich gezeigt, dass Lichtleitfaserkabel sich als Verbindung FOH zur Bühne sehr bewährt haben, da auch mechanische Extrembelastungen wie Überfahren mit einem Gabelstapler dem Kabel im ausgerollten Zustand keine Beschädigung hervorrufen können. Gleichzeitig ist man zum FOH potenzialfrei und kann sich keine elektromagnetischen Störungen einfangen. Nur das Ein- und Ausrollen sollte man Stagehands seines Vertrauens machen lassen oder selber zur Hand gehen, denn die Steckverbinder sind mit Vorsicht zu genießen und das Kabel ist empfindlich gegen Knicken. Und zu guter Letzt kann man die Frage mit ja beantworten, wenn es heißt „Darf es etwas mehr an Wegstrecke bis zum FOH sein?“

Es werden aber heute bereits schon wesentlich größere und DMX-Universen verschlingende Installationen gefahren. Hierbei tritt ein anderer Effekt auf, wenn dann mal 40 DMX-Universen in der Show eine Überblendung fahren müssen. Nutzt man nur einen Zentralrechner, der in der Regel das Lichtstellpult ist, so ist verständlich, dass – je mehr Kreise er bei einer 16-Bit-Überblendung berechnen und auf das Ausgabeboard schicken muss – die Zeitdifferenz, wo der erste Kreis von null auf 100 % springt, gegenüber dem 20.480-ten Kreis länger wird. Es entsteht eine Verzögerung, die in der Show sehr unschön anzusehen ist, wenn das erste Moving Light sich bereits in Fahrt befindet, während das letzte Moving Light, ungünstig auf der gegenüberliegenden Bühnenseite platziert, sich erst später anschickt, in die Gänge zu kommen.

Richtig auffällig wird dies jedoch bei den kanalhungrigen LED-Bitmap-Walls, wenn das Bild sich eben nicht schlagartig ändert, obwohl dies die Designanforderung war. Abhilfe schafft dabei nicht der Einsatz des 100-Mbit/s-Netzwerks, da der Rechner ja die Informationen nicht rechtzeitig ausgeben kann. Zur Lösung solcher Aufgaben benötigt man parallele Rechnerkerne oder dezentrale Rechnersysteme. Werden dezentrale Strukturen eingesetzt, so ist es wieder entscheidend, ob das Netzwerk diese eine skalierbare Erweiterung der Rechnerleistung zulässt. Jedoch muss auch sichergestellt werden, dass bei Einbindung von z. B. Medienservern zusammen mit den Bitmap-LED-Wänden das Gesamtbild synchron agiert. Dazu kann man über das Ethernet noch einen Zeitstempel senden bzw. diesen Zeitstempel in das Lichtstellprotokoll mit einbinden. Daraufhin können sich die Maschinen synchronisieren und man könnte dann auch mehrere Videoserver framegenau steuern.

 

---

Mehr Themen zu Netzwerktechnik und Protokollen werden auf folgenden Seiten behandelt:

• Kabel und Leitungen
• Simplex, Dublex, Analog- oder Digitalsignal
• DMX 512 – Merger und Splitter
• DMX 512 mit dem Oszi gemessen
• RDM
• ACN
• Weitere Protokolle in der Lichttechnik
• Architekturprotokolle
• Ethernet, Topologie, CSMA/CA-Verfahren, Token, Osi-Schichtenmodel, V-Lan, Spanning Tree, Geräte
• MAC-Adressierung, IP
• Fehlersuche im Ethernet

Eine Übersicht aller Themen finden Sie Hier.