Durchgehende SMPTE-ST-2110-Flows über Systemgrenzen

Die Herausforderungen

Eine Automatisierung auf der Basis von Software bietet für Broadcaster viele Vorteile. Aber sie führt auch dazu, dass der operative Betrieb stark von der Funktionsfähigkeit dieser Software abhängt. Die Frage, die sich vor allem dann stellt, wenn die technische Infrastruktur eines großen Medienproduktionsstandorts vollständig und nachhaltig transformiert werden soll: Wie lassen sich die Auswirkungen von Betriebsunterbrechungen – etwa durch einen spontanen Fehler oder geplante Wartungsarbeiten – in den zentralen Steuerungskomponenten begrenzen?

Da sind zunächst die bekannten Maßnahmen auf unterster und mittlerer Hardware-Ebene mit redundanten Komponenten (z. B. Netzteile, Lüfter und Netzwerkanbindung) und Teilsystemen (Server und Switches). Aber welche Vorkehrungen lassen sich auf Software-Ebene treffen?

Die üblicherweise eingesetzten Cluster-Systeme decken vor allem Hardware-Fehler ab. Vor Programmier- oder Konfigurationsfehlern schützen sie jedoch nur in geringem Maße – diese werden durch den Installationsprozess (oder die automatische Replikation) auf den oder die Cluster-Partner übertragen. Eine Möglichkeit zu verhindern, dass Softwarefehler den Standort eines Medienunternehmens komplett lahmlegen: Der direkte Einflussbereich der einzelnen Systeme wird begrenzt, und voneinander getrennte Systeme steuern verschiedene Bereiche vor Ort.

Dieses Vorgehen steht aber im Widerspruch zu den mit der Umstellung auf IP-basierte Systeme gewünschten durchgängigen Workflows. Ein Lösungsansatz ist, dass die einzelnen Systeme miteinander kommunizieren. Entscheidend ist dabei, eine zu enge Kopplung und damit eine zu enge Abhängigkeit zwischen den einzelnen Systemen zu vermeiden. Fehlfunktionen in einem System dürfen sich nicht gravierend auf ein anderes System auswirken.

Es ist auch nicht sinnvoll, alle Quellen (Sender) und Senken (Empfänger) in allen Bereichen verfügbar zu machen. Einzelne Bereiche sollten so zugeschnitten sein, dass möglichst wenige Signale zwischen ihnen ausgetauscht werden müssen. Oft wird es sinnvoll sein, die Grenzen anhand der durch die Organisation vorgegebenen Parameter zu ziehen. Dann lässt sich auch die Bandbreite der Querverbindungen zwischen den Bereichen vernünftig begrenzen. Gleichzeitig können die in anderen Bereichen zur Verfügung gestellten Signale auf Basis der jeweiligen organisatorischen Zuständigkeit bestimmt werden.

Dafür ist ein Mechanismus erforderlich, der Quellen oder Senken einem anderen System bekannt macht. Idealerweise geschieht das dynamisch: Quellen, die nicht ständig in einem anderen System benötigt oder abwechselnd von verschiedenen Systemen verwendet werden, können passend bereitgestellt werden.

Zumeist werden Quellen anderen Bereichen zur Verfügung gestellt, damit diese die entsprechenden Signale weiterverarbeiten können. Es gibt allerdings auch Anwendungsfälle, in denen Senken von anderen Systemen benutzt werden sollen. Zum Beispiel dann, wenn von einem Hauptschaltraum und für einen Regie eine Rückleitung bereitgestellt werden soll, die mit einem beliebigen Signal zu beschalten ist.

Die Steuerungsebenen in SMPTE-ST-2110-Netzwerken

Drei Steuerungsebenenn lassen sich in SMPTE-ST-2110-Netzwerken identifizieren:

1. BROADCAST-CONTROL
Diese Ebene stellt die Oberfläche für den Benutzer bereit. Sie beinhaltet alle Funktionen, mit denen Benutzer so einfach wie möglich auf Quellen und Senken zugreifen können:

• Sprechende Namen
• Zusammenfassung von Quellen und Senken, die gleichzeitig geschaltet werden sollen (Assoziationen)
• Ordnungsstrukturen

Darüber hinaus bieten die meisten Broadcast-Controller (BC) weitere Funktionen wie z. B. Tally, Salvos und Logik; sie sind in unserem Kontext aber nicht relevant.

2. STREAM-CONTROL 
Diese Ebene ist für die Konfiguration der Quellen und Senken innerhalb des SMPTE-ST-2110-Systems verantwortlich.

3. NETWORK-CONTROL 
Diese Ebene berechnet die Pfade durch das Netzwerk und gibt die entsprechenden Kommandos an die Netzwerkgeräte.

Je nach System- und Anwendungsdesign können diese Ebenen auf drei verschiedene Software-Produkte verteilt sein. Alternativ sind zwei oder alle drei Ebenen in einem Software-Produkt kombiniert.

In unserer Betrachtung für dieses Whitepaper gehen wir von einem System aus, in dem die Ebenen zwei und drei in einem Software Defined Networking Controller (SDNC) vereint sind. Der SDNC wiederum wird durch einen Broadcast-Controller angesteuert. Generell lassen sich die Erkenntnisse auch auf andere Systemdesigns übertragen.

Umsetzung des Ebenen-Modells in komplexen Systemen

Wenn wir komplexe Systeme betrachten, hat es sich bewährt, die Systeme in Schichten einzuteilen (vgl. OSI- oder IETF-Schichten-Modell). Alle Schichten-Modelle haben eines gemeinsam: Jede Schicht stellt auf derselben Instanz oder in demselben System Dienste für die darüber liegende Schicht bereit – und nutzt Dienste der darunter liegenden Schicht. Zwischen verschiedenen Instanzen oder Systemen findet eine Kommunikation nur auf derselben Ebene statt. Dadurch bleibt die Anzahl der Kommunikationsbeziehungen und Abhängigkeiten relativ gering.

In unserem konkreten Fall bedeutet das: Zwischen den unterschiedlichen Bereichen findet nur eine Kommunikation von BC zu BC und von SDNC zu SDNC statt – der BC in einem Bereich kommuniziert nicht mit dem SDNC in einem anderen Bereich.

Voraussetzungen im Netzwerk

Voraussetzung für durchgehende IP-Verbindungen ist ein umfassendes Netzwerk, das alle Bereiche verbindet. Die Alternative wären durch Baseband- oder NAT-Gateways getrennte Inseln – das aber würde zu einer noch strengeren Trennung und geringerer Flexibilität führen. Je nach Größe und Erfordernissen des jeweiligen Bereichs können die einzelnen Systeme unterschiedliche Topologien haben. Wie auch innerhalb der Systeme wird die Bandbreite auf den Netzwerkleitungen durch die SDNC verwaltet.