Rundfunkanstalt Bild 1. Vereinfachtes Blockdiagramm des Steuer- und Signalflusses Teil VI: OpenMedia und das Bricking-Konzept Technische Sendeplanung – ein Kinderspiel? Bei ARD-aktuell geht fast nichts ohne OpenMedia: Ob in den News-Räumen oder in der Regie, die Redaktionssoftware ist omnipräsent. Hier entstehen zum einen die redaktionellen Inhalte, die Beiträge und Ablaufpläne der Sendungen, hier fängt zum anderen aber auch die technische Gestaltung der Sendungen an: Clips aus dem Quantel- und Grafiken aus dem Orad-System werden verknüpft, Kamerawechsel oder externe Schalten eingetragen (Bild 1). Alle Informationen, die in OpenMedia auftauchen, werden 1:1 und ohne zusätzliche Schritte an die MosartSendeautomation (Bild 2) weitergereicht. Dafür sorgt der sogenannte Bricking-Prozess, der die richtigen von mehr als 600 möglichen Automationskommandos zusammensetzt und parametrisiert. Doch hochkomplex wird es für den Redakteur trotzdem nicht, das ist es nur unter der Haube. Als bei ARD-aktuell die Bauarbeiten rund um das Nachrichten- und Sendeplanungssystem OpenMedia gestartet wurden, waren die Planungen für das neue Studio schon weit fortgeschritten: Das neue Design und die neue Regie, die Video-, Audio-, Grafik-, Steuerungs- und Automationssysteme, alles war bereits konzipiert, beschafft oder wurde gerade bestellt. Die Herausforderung bestand darin, OpenMedia mit diesen Komponenten zu verbinden, ohne dabei die bisherigen Workflows bei ARD-aktuell in Frage zu stellen. OpenMedia ist schon lange in den Redaktionen und Regien im Einsatz und genießt eine hohe Akzeptanz in allen Bereichen. Mehrmals schon hatte ARD-aktuell die Firma Vincent Delbaere entwarf und implementierte für die Annova Systems GmbH das Bricking-System in OpenMedia Orad Maestro Orad ActiveX OpenMedia Client Protokoll MOS-MO Mosart Corba Quantel Daten-Austausch Playout Annova darum gebeten, Anpassungen vorzunehmen, damit die Software den sich permanent veränderten Arbeitsabläufen gerecht wird. Leitlinie war und ist dabei immer die Forderung der Redaktion, jederzeit die Kontrolle über die Herstellung, den Ablauf und die Gestaltung der Sendung zu behalten. Produktionsabläufe müssen sich der redaktionellen Freiheit bei der Gestaltung der Beiträge unterordnen – und der Redaktionsschluss beginnt wenige Sekunden, bevor der Beitrag „On Air“ ist. Denn bei ARD-aktuell geht es vor allem um eine schnelle Reaktionsfähigkeit, ohne dabei die Qualität aus den Augen zu verlieren. Aus diesem Grund wurde schon Jahre davor das Modul „eRegie“ in Auftrag gegeben. Die zentrale Idee war: Die Redaktion kann bis zur letzten Sekunde eine Position oder die Reihen- folge der Positionen in der Sendung ändern, und die Regiemannschaft muss diese Änderung sofort wahrnehmen sowie die technisch notwendigen Anpassungen für den Ablauf der Sendung vornehmen können. Vor der eRegie arbeitete jedes Gewerk mit massenhaft ausgedruckten Sendungsabläufen und Beiträgen. So ziemlich jeder in der Regie war gezwungen, auf seinem Ausdruck technische Parameter (Quelle, Kanal, Schnitt, DVEs usw.) handschriftlich zu ergänzen. Jede Änderung der Redaktion führte immer wieder zu hektischen Aktivitäten bei Kommunikation, beim Ausdrucken, Sortieren, Verteilen und Einarbeiten der technischen Änderungen. Die zentrale Anforderung an die eRegie war es daher, weitgehend papierlos zu senden. OpenMedia wurde damals so erweitert, dass jeder Techniker direkt am Bildschirm Brick-GUI Transitionstabelle = f (visueller Einstieg & Ausstieg) Brick-Designer Sendeformen = f (Sendung, Regie) MOS-RO OpenMedia-Server Client-Server Protokoll CII OpenMedia Brick-Prozess Umbricktabelle = f (Kamerakompatibilität) Brick a = Brick n f (SF, Kamera, Regie) Medienobjekte Clip + PlatzHalter = f (SF) Grafik MW + PH f (SF, Kamera, Mod-Größe,) Live-Schalte= f (SF, Mosart-Cmd) Grafik VG+ PH F (SF) Kamera = f (SF, Mosart-Cmd) Grafik Insert F (SF) Regelprüfung für Clips, Grafik, Kamera, Live, CMD´s: Spielorliste f (MW, VG, Insert, Clip) Must, Strong-Musts Dont´s Can´s Wrong-Spielorte, Ignore-Spielorte Brick-Publish Brick-Validierung Transitionsprüfer SF Brick e Sendeplan MOD-Größe Beitrag 1 Videoclip Brick b Brick b Brick c Brick c Trans. OK? Beitrag n Videoclip Kamera Grafik ORAD Active X Grafik MW + PH f (SF, Kamera, Mod-Größe,) Playliste Mosart-MOS-Plug-in Dipl.-Ing. Ronald Entlinger (NDR) arbeitet in der Projektleitung des Redaktionssystems OpenMedia Mosart Regieautomation Echtzeitgrafik Mosart MOS-Gateway CII Bild 2. Brickkonzept in Verbindung mit der Regieautomation 32 xx/2014 FKT ##SUS##mnertd##1946##SUS##2013##HP_PORTAL## Kuhlmann_neu.indd 32 30.10.14 16:31 Rundfunkanstalt Schneiden von Videos Agenturen Texte Sendungsplanung Auswahl brick” “ Auswählen und Befüllen von Grafikvorlagen Active X ActiveX Active X ActiveX MOS MO Videos Orad Or a d Ac t i v eXActiveXPl ug- i n Plug-in Maestro Ma es t r o Pl a y out Playout CII MOS RO Viz Mosart MOS MO MOS MO Inserts, VG-Grafiken, Medienwandgrafik OpenMediaClient Bild 3. Blockschaltbild der MOS-Steuerung seine Notizen und technischen Angaben in die Abläufe eintragen konnte, ohne die Arbeit der Redaktion zu stören. Dafür wurden die handgeschriebenen Notizen durch sogenannte „Direktiven“ ersetzt. Es gab Ton-/ Bild-Direktiven, Direktiven für Licht, Kamera, Live-Quellen sowie allgemeine Regie- und Redaktionsdirektiven. Diese Anweisungen waren eine Art Vorstufe zu den später für die Automation benötigten maschinellen „Primitiven“. Aber sie wurden eben nicht von Software und Robotern ausgeführt, sondern manuell von den Ingenieuren und Technikern der Regie. Diese Direktiven machten aus dem redaktionellen Ablauf einen technischen Rundown, der den Anforderungen und den Änderungen der Redaktion folgte. Radikale Veränderungen Das neue Studio brachte weitere radikale Veränderungen. Waren vorher aufgrund der Blue-Screen-Technologie die dramaturgischen Möglichkeiten begrenzt, lässt das neue Design mit einer Real-Deko und einer fast 18 Meter langen Medienwand eine Vielzahl an Gestaltungselementen sowie Einstellungen zu. Und die Anforderung der Redaktion war es, die neuen Möglichkeiten des Studios mit dem bisherigen Redaktionssystem umzusetzen. Denn OpenMedia ist bei ARD-aktuell das gesetzte System, in dem redaktionelle Inhalte entstehen und die Inhalte eine technische Form bekommen sollen. Man hätte dafür die eRegie mit ihren technischen Direktiven ausbauen können. Und auf die Frage, wie OpenMedia mit der Automationssoftware Mosart kommuniziert, um den „technischen Rundown“ zu übergeben, hätte man als Antwort die Mosart-Primitiven1,2) gehabt; schließlich waren die Direktiven der eRegie nicht sehr weit davon entfernt (Bild 3). Die eigentliche Herausforderung war eine o Bild 4. Blockdiagramm der Integration zwischen OpenMedia, Orad, Quantel und Mosart OpenMediaOpenMedi a S er v er Server MOS MO MOS MO Corba Quantel ActiveXPlug-in weitere Anforderung: Die Redaktion selbst sollte in die Lage versetzt werden, alle Positionen der Sendung komplett zu gestalten – und das bedeutet, dass sowohl der redaktionelle als auch der technische Rundown aus einer Hand stammen sollen. Dafür gab es mehrere Gründe: Durch den Einsatz einer Studioautomation verändert sich die Arbeit in der Regie nachhaltig. Insbesondere verschwindet die Möglichkeit für die Regietechnik, sich „Notizen“ zu machen. Noch wichtiger war der Wunsch, dass die Redakteure mehr Einfluss auf den Ablauf der Sendung sowie die Dramaturgie der Studio- und Live-Positionen haben wollten. Die Redaktion weiß genau, wie ein Studiobeitrag aufgebaut ist, welche Kameras eingesetzt werden, welche Gänge der Moderator gehen kann, welche Grafiken oder Bilder erscheinen sollen und welches Timing für die gesamte Position sinnvoll ist. Das gilt besonders für die Magazin-Formate wie Tagesthemen und Nachtmagazin. Und man wollte neben der Qualität auf keinen Fall auf Schnelligkeit verzichten. Die Qualität ist gegeben, wenn die Redaktion alle Positionen der Sendungen frei und kreativ gestalten kann. Schnelligkeit ist aber nur möglich, wenn diese Gestaltung ohne Zwischenschritt an die Automation weitergereicht werden kann. Eine nachträgliche Prüfung und „Nachprogrammierung“ der Ablaufpositionen durch einen Mosart-Spezialisten wurde deshalb ausgeschlossen. Diese „Nachbearbeitung“ wäre aber unvermeidlich, wenn eine 1) Mosart-Templates enthalten XML-konforme Anweisungen zur Steuerung von Mosart 2) Mosart-Primitive: Basis-Template ohne Medieninhalt sQ-Server Integration zwischen OpenMedia und Mosart (Bild 4) auf Basis von Automationsprimitiven erfolgt wäre. Analyse der Anforderungen Eine Frage war deshalb: Kann ARD-aktuell weiterhin mit OpenMedia arbeiten oder muss ein neues Werkzeug her? Um eine Antwort zu finden, wurde Annova gebeten, sich an der Analyse der Anforderungen zu beteiligen und konkrete Vorschläge für deren Umsetzung zu unterbreiten. Das erklärte Ziel des NDR war es, OpenMedia weiterhin einzusetzen. Zum einen wird das System flächendeckend im Sendegebiet genutzt – sowohl für alle Fernsehprogramme als auch für die Hörfunk-Wellen – und zum anderen waren die Anwender bei ARD-aktuell mit dem System vertraut. Die ersten Schritte waren dann, Anforderungsdokumente zu schreiben und das Produktmanagement der Firmen Mosart und Annova zunächst zu „Brainstorming“-Sitzungen einzuladen. Kurz darauf wurde das „BrickKonzept“ geboren. Der Begriff „Brick“ hat sich spontan durchgesetzt, da es die Einfachheit des Konzeptes unterstreicht: Wie bei einem Baukastensystem werden einfach Steine aufeinander gesteckt und damit können komplexe Strukturen gebaut werden. Genau das wird von einen Redaktionssystem verlangt: Mit ihm muss es einfach sein, komplexe Sendesituationen zu erzeugen. In der ersten Phase der Diskussion war noch nicht klar, welche Eigenschaften die Bricks haben und in welchen Systemen sie sich befinden müssen. Sollen Bricks ein Konstrukt in Mosart sein, eine Art Konglomerat xx/2014 FKT 33 ##SUS##mnertd##1946##SUS##2013##HP_PORTAL## Kuhlmann_neu.indd 33 30.10.14 16:31 Rundfunkanstalt von Primitiven, die vom Redaktionssystem aufgerufen werden können? Oder sollen sie in OpenMedia implementiert werden – als eine Art Plug-in in der GUI, die OpenMediaAngaben in Mosart-Primitiven übersetzt? Ziel der ersten Besprechungen war es, zu klären, wie sich einerseits Mosart steuern lässt, was einem Redakteur andererseits zu-gemutet werden kann und letztendlich, welche Möglichkeiten ein „Bricking-Prozess“ bieten soll. Das Mosart-Automationssystem basiert auf folgenden Prinzipien: – Templates: Das sind die Steuerungsprimitiven des Systems. Diese orientieren sich an der zu steuernden Hardware (Kreuzschiene, Kamera, Roboter, Videoserver, Grafikmaschinen usw.) und sind deshalb technisch relativ komplex. In Mosart können „wandlungsfähige“ BasisTemplates gebaut werden. Diese bestehen dann aus einer Sammlung an „Einzel“Templates, die einander beeinflussen. Alles in allem können die Mosart-Templates nur von Spezialisten korrekt angewendet werden. – Stories: Wie das Planungssystem zerlegt Mosart eine Sendung in einzelne Stories. In einer Story werden alle Templates zusammengeführt, die für die Realisierung der Position notwendig sind (Text, Medien, Steuerungsparameter) – Primaries und Secondaries: Mosart kennt Primary- und Secondary-Events. Ein Primary-Event ist ein visuelles Hauptereignis, wie zum Beispiel eine Kamera oder eine Vollbildsequenz. Die Secondary-Events sind von den Primaries abhängig und nur sinnvoll, wenn sie im Rahmen eines Primary-Events eingesetzt werden. Das sind zum Beispiel Bauchbinden (Lower-Thirds) oder Effekte. Um herauszufinden, was der Redaktion im Bezug auf die technische Gestaltung der Sendung zumutbar ist, wurde den Redakteuren die Rolle als „erfahrener Zuschauer“ übertragen. Im Prinzip vertraut ein Redakteur bei der Gestaltung einer Sendungsposition auf seine visuelle Fähigkeiten: Er kann beschreiben, was er sehen will, und aus Erfahrung kann er auch sagen, welche Medien und Mittel er dafür einsetzen möchte: Kameras, Live-Quellen, Grafiken, Clips. Und er kann auch über die Frage entscheiden, wie und wo diese Mittel eingesetzt werden sollen. Für eine Kamera kann er sowohl eine feste Position als auch eine eventuelle Bewegung wählen, bei Live-Quellen, Videomaterial und Grafiken kann er festlegen, ob diese Elemente im Studio an der Medienwand oder im Bild 5. Darstellung der Layer und Aufbau des Systems Brick-Layer” ” MasteringVideoGraphics Bildmischpult Vollbild erscheinen. Weiterhin kann er Tonquellen unterscheiden und weiß, ob der Ton von einem Mikrofon oder einem gemischten Clip kommt – oder ob der Ton zwei Quellen haben kann und live gemischt werden muss. Für diese Angaben braucht der Redakteur keinerlei Kenntnis über die verwendete Technik. Er muss nicht verstehen, wie die Kamera-Automation funktioniert, was Bildoder Audiomischpulte können, welche Kreuzschienen angesprochen werden oder welche Parameter das Grafiksystem benötigt. Er ist gleichsam wie ein Zuschauer, der den Aufbau einer Story kennt und die vorhandenen Mittel gezielt in Bezug auf die Gestaltung der Position und der Sendung einsetzt. Eines wurde während der ersten Beratungsgespräche schnell klar: Der Redakteur will auf keinen Fall die Paradigmen von Mosart kennenlernen und damit zurechtkommen. Brick als Übersetzer Der Bricking-Prozess (Bild 5) musste daher zu einer Art Übersetzungsschicht zwischen dem, was der Redakteur angeben kann (seine Betrachtungen als erfahrener Zuschauer) und BroadcastSystem Tonmischpult LichtLeveller Kreuzschienen pult dem, was Mosart zum Funktionieren braucht (Templates und Parameter), entwickelt werden. Nach diesen Erkenntnissen wurde eine Arbeitsgruppe gegründet, die prüfen sollte, wie in der OpenMedia-Anwenderoberfläche Angaben durch die Redakteure überhaupt erfolgen könnten. Die Redakteure von ARDaktuell hatten schon Erfahrungen mit dem selbstständigen Umgang mit „technischen“ Schritten: So konnten sie Clips und Grafikobjekte anlegen und mit dem Beiträgen verknüpfen, zum Beispiel Bauchbinden, Hintergrund-Illustrationen oder Vollbildgrafiken. Sie hatten die Position von Kameraschnitten oder -fahrten in den Text der Beiträge eingetragen und Direktiven für eine Live-Quelle selbst positioniert. So gesehen waren die Redakteure und OpenMedia schon in der Lage, die notwendigen Medien korrekt zu wählen und darzustellen. Aus den Ergebnissen der Arbeitsgruppe konnte man ablesen, dass der Software zwei zentrale Eigenschaften fehlen, die es der Redaktion ermöglichen, automationskonforme Angaben zu machen. Bild 6. Brick-Definition für eine Schalte: Dieser Brick wird im Bild 7 verwendet und führt konkret zum Ergebnis im Bild 8. 34 xx/2014 FKT ##SUS##mnertd##1946##SUS##2013##HP_PORTAL## Kuhlmann_neu.indd 34 30.10.14 16:31 Rundfunkanstalt mäßig geringem Aufwand in Form von Plugins zu integrieren, ohne Änderungen im Kern der Software vornehmen zu müssen. Diese Eigenschaften waren die Wegweiser für die Entscheidung: Der Bricking-Prozess wird in OpenMedia implementiert. Bild 7. Benötigte Angaben zu einer Schalte in OpenMedia – Zum einem mussten die Redakteure signalisieren können, wie ein Medium zu verwenden ist: Ist zum Beispiel ein Video für die Medienwand bestimmt oder soll es im Vollbild gespielt werden? Wie ist der Ton zusammengesetzt: gemischt oder mit Stimme aus dem Off? – Dann musste eine Lösung dafür gefunden werden, wie „Mehrmedien“-Ereignisse, also technische Ereignisse, bei denen mehr als ein Medium eingesetzt wird, angegeben werden können. Ein typisches Beispiel dafür ist eine Studioschalte an der Medienwand (Bild 6). Es werden zwei Medien benötigt: die Live-Quelle und der grafische Rahmen für die Medienwand. Die Lösung zu beiden Punkten wurde so formuliert: Es muss in OpenMedia eine einfache Möglichkeit geben, den Spielort eines Mediums zu definieren. OpenMedia soll dafür nur die Spielorte anbieten, die zu einem Medium passen und bei speziellen Spielorten ermöglichen, dass neben dem von der Redaktion gewählten Mediaobjekt zusätzliche Objekte automatisch generiert werden. Diese dafür notwendigen Änderungen in der GUI (Bild 7) waren in OpenMedia problemlos machbar – und damit war es grundsätzlich möglich, den Bricking-Prozess in OpenMedia als Nachrichtensystem zu implementieren. Offen blieb zunächst die Frage, wo die Übersetzungslogik ihren Platz finden soll – in Mosart oder in OpenMedia? Für OpenMedia sprachen mehrere Gründe: das flexible Datenmodell, die anpassbare GUI und die Fähigkeit, neue Funktionen mit verhältnis- Wie funktioniert der Bricking-Prozess? Der Bricking-Prozess hat zwei zentrale Aufgaben. Er muss dem Redakteur einen Rahmen für die Erstellung des technischen Rundowns bieten, diese Angaben anschließend in Mosart-Primitiven übersetzen und synchron zum Automationssystem übertragen. Die Spezifikationsarbeit wurde von Herstellern (Mosart und Annova) parallel erledigt. Es dreht sich im Grunde um die folgende Problematik: Fände man einen praktikablen Weg, wie technische Parameter eingetragen werden, dann hätte man damit nahezu automatisch eine einfache Übersetzungsmöglichkeit in die Automationsprimitiven. Es wurde entschieden, dass ein Brick eine Art Korsett um eine Sendeposition bilden soll. Jeder Beitrag wird auf diese Weise mit Attributen versehen, die beschreiben, was technisch in dieser Position passiert. Demzufolge muss das System so viele Bricks anbieten, wie es technische Gestaltungen in den Sendungen gibt. Wo eine Position anfängt und wo sie endet, ist nicht in allen Fällen einfach festzulegen, insbesondere im Falle von umfangreichen Themen, bei denen mehrere Studiopositionen aufeinander folgen können. Folgende Kriterien wurden festgelegt: – Jeder Wechsel des redaktionellen Themas hat eine neue Position zur Folge. – Eine Position darf nicht zu viele visuelle Übergänge enthalten. Wenn viele visuelle Übergänge notwendig sind, muss das Thema auf mehrere Positionen verteilt werden. Insbesondere darf mitten in einer Position nur einziges Mal ein Kameraschnitt oder eine Kamerafahrt stattfinden. – Für Ausnahmesituationen muss ein Brick definiert werden, der es ermöglicht, die Position komplett in Mosart manuell zu fahren. Anhand dieser Vorgaben machte sich die Projektgruppe an die Arbeit, alle möglichen Standardsituationen zu ermitteln und zu beschreiben. Jede Standardsituation sollte als Brick definiert werden. Die Beschreibung der Standardsituationen und der Bricks erfolgte mithilfe folgender Elemente: – MUSTs: Wie der Name verrät, handelt es sich dabei um Gestaltungselemente der Position, die unbedingt dabei sein müssen – zum Beispiel muss bei einer OFFPosition ein Video vorhanden sein und bei einer Studioposition eine Wandgrafik eingebaut werden. – DON’Ts: Das sind Gestaltungselemente, die in einer Position verboten sind. Zum Beispiel darf es während einer klassischen Studiosituation keine Vollbildgrafik geben. – CANs: Das sind alle Gestaltungselemente, die erlaubt, aber nicht unbedingt notwendig sind. Ein Gestaltungselement ist hier als die Kombination eines Mediums (Video, Grafik, Live-Quelle, Kamera) mit einem Spielort (VG, Wand usw.) zu verstehen. Hunderte Standardsituationen Es wurden mehrere Hundert Standardsituationen identifiziert. Diese wurden in Unterkategorien eingeordnet. Zu einem wurden sie nach Sendungstyp (Tagesschau, Tagesthemen, Nachtmagazin usw.) und nach Grundtyp der Position (Studio, Live, Film usw.) unterteilt (Bild 8a bis 8c). Die Unterteilung nach Sendungstyp entsprach dem Konzept von „Sendeform“, das schon im Rahmen der Aufteilung der GrafikTemplates entstanden war. Mithilfe der Sendeform ist es möglich, den Inhalt eines Mediums von der Form zu trennen. So können zum Beispiel Bauchbinden problemlos für andere Sendeformate verwendet werden. Die Unterteilung nach Positionstyp war schon lange Bestandteil der Arbeiten der Redaktionen mit dem Redaktionssystem. Schon immer wurden die Beiträge in fünf Haupttypen verteilt, damit entsprechende Bild 8a–c. Verschiedene Segmente einer Schalte mit Studioset (a) (links), Mediawand (b) (Mitte) und Partner am entfernten Produktionsstandort (c) (rechts) xx/2014 FKT 35 ##SUS##mnertd##1946##SUS##2013##HP_PORTAL## Kuhlmann_neu.indd 35 30.10.14 16:32 Rundfunkanstalt Tabelle II. Im System berücksichtigte Sicherheitschichten mehrere MOS-Mosart Schnittstellen unabhängige, reconnect-fähige MOS-Schnittstellen zu Mosart Ermöglicht dem Anwender, die zentrale technische Schnittstelle in Selbsthilfe zu wechseln. Produktionssystem als Cluster Das Haupt-OpenMedia-System besteht aus einem Zwei-Knoten-MS-Cluster Garantiert Fail-Over-Fähigkeiten ohne Unterbrechungen für die Anwender. „HotStandBy“-Link Ein zweites Cluster-System wird sekundengenau Garantiert einfache Wartungen des Hauptsystems durch repliziert geplanten Systemwechsel. Im Havarie-Fall wird eine schnelle Weiterführung des Betriebs sichergestellt – verlangt aber danach einen Reconnect der User und der Schnittstellen. Replikationssever Ein Stand-Alone-System bekommt live Agenturmeldungen, die produktiven Daten aber nur einmal am Tag Metadaten mit den Positionen verbunden werden konnten. Das Metadatenmodell von OpenMedia ließ sich leicht erweitern, ebenso wie die Visualisierung der Daten in Form von sogenannten Ansichten. Damit konnte in OpenMedia ein Brick-Design-Modul implementiert werden, ohne dass eine spezielle SoftwareLösung dafür nötig wurde. Mit diesem Modul werden alle Bricks erstellt und modelliert. Es entstanden ungefähr 580 solcher BrickDefinitionen. Nachdem die genauen Eigenschaften der Brick-Definitionen modelliert waren, war es möglich, den tatsächlichen „Bricking-Prozess“ in OpenMedia zu implementieren. Der Bricking-Prozess besteht aus zwei OMIS3)Plug-ins. Zum Teil erlauben diese den Einsatz von Skript-Sprachen, wie zum Beispiel VBS4). Dadurch ist es möglich, die Logik des Bricking-Prozesses leicht anzupassen, ohne dass diese Änderungen kompiliert werden und den Release-Zyklus der Software-Verwaltung von Annova durchlaufen müssen. Diese Skript-Fähigkeit von OpenMedia bietet einen enormen Vorteil, wenn es darum geht, die gesamten Funktionen des Bricking-Prozesses bis zum kleinsten Detail zu modellieren und zum Leben zu erwecken. Schritt für Schritt, agil vom Groben ins Feine, reiften die Funktionen aus, die im Einzelnen die Folgenden sind: – Setzen von Standard-Bricks bei neuen Positionen in Sendungen. – „Umbricken“ von Positionen, wenn diese kopiert oder in eine andere Sendung verschoben werden. In diesem Fall wird vom System anhand einer Tabelle ermittelt, 4) OMIS: OpenMedia Interface Services VBS: Visual Basic Script – – – Vom Groben ins Feine 3) – – Praktisch als Integrationssystem für kurzfristige Tests: Dieses System könnte vor allem die letzte Rettung im Falle von einer Datenkorruption auf Haupt- und HotStandBy-System sein. welcher Brick in der Ziel-Sendeform die meisten Ähnlichkeiten mit dem Brick aus der Quell-Sendeform hat und setzt diesen ein. Dabei wird darauf geachtet, welche MUSTs, DON’Ts und CANs ihre Richtigkeit haben. Neutralisieren der DON’Ts. Das heißt unerlaubte Gestaltungselemente werden auf ungültig gesetzt. Dafür wurde mit Mosart ein neues Kommando namens „Ignore“ vereinbart. Neutralisierte Medien werden mit diesem Befehl an Mosart geschickt und von der Automation dann völlig ignoriert. Der Vorteil dabei ist, dass diese Medienobjekte in der Story nicht gelöscht und somit eventuell noch mit einem gültigen Spielort umgesetzt werden können. Darstellung der MUSTs in Form von Platzhaltern. Der Benutzer ist durch diese Platzhalter informiert, dass er ein gültiges Gestaltungselement einsetzen muss. Ein MUST-Platzhalter kann nur gelöscht werden, wenn seine Bedingungen erfüllt sind. Ist das nicht der Fall oder wird der Platzhalter versehentlich gelöscht, kommt dieser automatisch wieder. Bei gültigen Gestaltungselementen wird das aussagekräftige Symbol ermittelt und vor allem das passende Mosart-Kommando eingesetzt. Setzen von Metadaten der Story wie zum Beispiel Flags wie „text goes to teleprompter“ oder „story duration calculated according to the text duration“, aber auch Mosart-Kommandos auf Story-Ebene. Die wichtigsten dieser Metadaten sind aber die visuellen Start- und Endpunkte (die Kameraeinstellung). Diese werden für die Transitionspprüfung der Sendung benötigt. Darstellung eines aussagekräftigen Piktogramms im Kopf der Story: Zu jedem Brick besteht eine grafischen Illustration der Nutzung. Diese Illustration kann im Kopf der Stories angezeigt werden. – Anzeige eines Beschreibungstextes zur Verwendung des gewählten Bricks. Neben diesen primären Funktionen wurden weitere Hilfsfunktionen eingebaut: – Ermittlung der sogenannten „WrongGraphics“. Es handelt sich um Grafiken für die Medienwand, die „nicht im Bild passen“, da sie an einer Portion der Wand erscheinen, die mit den Kameras des Bricks nicht kompatibel ist (geschnittenes Bild oder zu großes Bild usw.) – Setzen von Default-Text und Default-Multimedia-Objekten. – Setzen von sogenannten „Strong-MUSTs“: Dabei handelt es sich um Instanzen von Multimedia-Objekte, die für die Position unverzichtbar sind (zum Beispiel sendeformspezifische Jingles). Wird ein „StrongMUST“ gelöscht, kommt es von selbst wieder. – Ermittlung der Darstellungsparameter für die Wandgrafiken (X-Offset, Y-Offset, Trapez usw.) abhängig von der Größe des Moderators. – Ermittlung der Audiodatei, die am Anfang der Sendung ausgespielt wird, um die Sendung und den Namen des Moderators anzusagen. – Ermittlung der Filterparameter für das Orad-ActiveX: Wenn das Orad-ActiveX aus OpenMedia aufgerufen wird, werden nicht alle möglichen Grafik-Templates des Systems gezeigt, sondern nur die, die für die Position relevant bzw. erlaubt sind. Zusätzlich wurde auch eine wichtige Kontrollfunktion implementiert, die Transitionsprüfung. Sie signalisiert, wenn zwei Positionen visuell nicht aufeinander folgen können. Das Ganze funktioniert, da die visuellen Startund Endpunkte jeder Position codiert sind und durch den Brick gesetzt werden. Eine Tabelle beschreibt, welche Endpositionen mit welchen Startpositionen kompatibel sind. Im Falle eine Inkompatibilität werden die Positionen vom System markiert. Das System 36 xx/2014 FKT ##SUS##mnertd##1946##SUS##2013##HP_PORTAL## Kuhlmann_neu.indd 36 30.10.14 16:32 Rundfunkanstalt versucht allerdings nicht selbst Änderungen vorzunehmen, sondern zeigt nur eine Warnung an. Entsprechend können die Benutzer reagieren, indem sie die Postionen verschieben oder einen anderen, kompatiblen Brick einsetzen. Die Kommunikation zwischen OpenMedia und Mosart erfolgt mithilfe einer MOSSchnittstelle in der Version 2.84, Profiles 0, 1, 2 & 4. Wenn neue Mosart-Templates in Mosart erzeugt werden, leitet das System diese über die MO-Schnittstelle an OpenMedia weiter. Daraus extrahiert OpenMedia das nötige Kommando für den Aufruf des MosartTemplates und stellt es für eine Verwendung in den Brick-Definitionen zur Verfügung. Über die RO-Kommunikation sendet OpenMedia alle Multimedia-Objekte und die entsprechenden Mosart-Kommandos an Mosart. Der Text wird durch den Befehl „roStorySend“ übermittelt. Die Playliste in Mosart folgt allen Änderungen im Redaktionssystem. Kommunikation mit Orad Zu Orad nutzt OpenMedia eine vereinfachte MOS-Schnittstelle über ActiveX. Zusätzlich läuft auch eine MO-Schnittstelle, aber diese wird nur als Absicherung verwendet und kann gegebenenfalls abgeschaltet werden. Eine RO-Schnittstelle zwischen OpenMedia und Orad-Maestro wurde ebenfalls implementiert, doch diese wird nur in Havariefällen aktiviert. Orad bekommt sonst seine Befehle nur von Mosart über die CII-Schnittstelle. Die MOS-ActiveX-Schnittstelle hingegen spielt eine zentrale Rolle und wurde um eine Funktion erweitert. Dadurch kann OpenMedia Initialisierungsparameter an das Orad-ActiveX senden. Einerseits wird die Sendeform geschickt, wodurch die angebotenen Grafik-Templates gefiltert werden und sich das Preview im Layout der Ziel-Sendung darstellt. Anderseits werden sowohl der Typ der zu erstellenden Grafik (Vollbild, Bauchbinde, Medienwand usw.) als auch die visuellen Start- und Endpunkte der Position übergeben. Durch diese Parameter werden nur passende Grafik-Templates vom ActiveX für den Anwender angeboten. Indirekt gelangen über Mosart aber auch andere Parameter aus OpenMedia an Orad. Insbesondere bei Wandgrafiken werden sämtliche Kalibrierungsparameter abhängig von der Größe des Moderators ermittelt und geliefert. Für den Vorspann der Sendungen, bei denen Orad auch für das Ausspielen der Ansage zuständig ist, sendet OpenMedia auch die Referenz auf die richtige Audiodatei mit der Vorstellung des jeweiligen Moderators. Ungewöhnlich wurde auch das Problem des sogenannten House-Keepings der Grafikobjekte gelöst. In einer klassischen MOSIntegration kommt die Initiative, um ein Objekt zu löschen, vom Mediasystem. Es ist aber so, dass eigentlich nur das Nachrichtensystem wissen kann, wenn ein Grafikobjekt nicht mehr gebraucht wird: entweder es ist nicht oder nicht mehr mit einer Story verlinkt oder die Story selbst ist alt genug, damit eine direkte Wiederverwendung ausgeschlossen ist. In diesen Fällen dürfen die Grafikobjekte sowohl im Nachrichten- als auch im Grafiksystem gelöscht werden. OpenMedia ermittelt diese überflüssigen Grafikobjekte und markiert sie entsprechend, indem ihr Titel geändert wird. Einige Tage später werden die Objekte aus Orad und OpenMedia gelöscht. Abgerundet wird die Schnittstellen-Umgebung von OpenMedia mit einer klassischen MOS-Profile-1-Schnittstelle zum QuantelSystem. Diese Schnittstelle ist schon vor neun Jahren entstanden und ermöglich die Sichtung, Wahl und Verlinkung des richtigen Videomaterials in OpenMedia. einem dritten „MS-Zwei-Knoten“-OMIS-Cluster gehalten. Das OMIS-Cluster wird ebenfalls im Fail-Over-Modus betrieben. Um das Sicherheits- und Betriebskonzept zu vervollständigen, wurde die Installation zusätzlich mit einem 24 Stunden „nachhinkenden“ Replikationssystem ergänzt. Der Replikationsserver ist ein Stand-Alone-Server, der nur einmal am Tag mit den Daten des produktiven Systems repliziert wird. Er wird zudem mit eigenen Agenturmeldungen versorgt. Dieses System soll als Havarie eigentlich nie zum Einsatz kommen – aber sicher ist sicher: Sollten korrupte Daten sowohl das Haupt- als auch das HotStandBy-System außer Kraft setzen, wäre das Replikationssystem die letzte Rettung. Ein solcher Fall ist in der Geschichte von OpenMedia allerdings noch nie eingetreten. Die virtuelle Umgebung selbst besteht aus sechs raumredundanten ESX-Servern und Lefthand-iSCSI-Storage. Im Falle eines Updates werden zusätzliche virtuelle Maschinen installiert. Sicherheitsschichten Architektur des OpenMedia-Systems Das OpenMedia-System von ARD-aktuell wurde auf Basis von virtuellen Servern realisiert. Das Hauptsystem besteht aus einem Zwei-Knoten-Windows-Cluster. Auf diesem Cluster laufen zwei MS-SQLServer-Instanzen und in jeder diese Instanzen laufen drei Datenbanken. Die Cluster laufen nicht im Load-Balancing, sondern im Fail-OverModus. Bekanntlich setzt OpenMedia den OpenText-Fulcrum-SearchServer ein, um die Lese-Performanz des Systems zu garantieren. Neben diesem Hauptsystem gibt es ein sekundäres System. Es handelt sich um eine Kopie des ersten und besteht ebenfalls aus einem Zwei-Knoten-Cluster. Dieses sekundäre System ist über ein „Annova-HotStandBy-Link“ mit dem ersten verbunden. Diese Technologie garantiert eine sekundengenaue Replikation der Daten des Hauptsystems. Das sekundäre System befindet sich im Read-Only-Modus, kann aber jederzeit die Rolle des primären Systems übernehmen (Fail-Over). In diesem Fall werden automatisch alle technischen Schnittstellen des Hauptsystems umgeleitet. Die Clients melden sich dann am „neuen“ primären System an und der Anwender findet alle replizierten Daten sofort wieder. Damit sich die technischen Schnittstellen, insbesondere die MOS-Schnittstellen, wahlweise mit dem einen oder mit anderen Hauptsystem verbinden können, werden diese auf Vertrauen ist gut... Automation, Bricking-Prozess, Transitionsprüfer – noch nie in der Geschichte von ARD-aktuell haben Computer, Software und Automatismen so prägnante Rollen bei den Sendungen gespielt. Doch auch bei den Rollen der Mitarbeiter, die das System bedienen, hat sich einiges bewegt. Im Zentrum der Nachrichten-Produktion spielen die Redakteure die Hauptrolle. Es sind aber auch zwei neue Funktionen durch dieses Projekt entstanden, die im Hintergrund dafür sorgen, dass technisch immer alles glatt über die Bühne geht. Eine der neu entstandenen Funktionen ist die des „OpenMedia Operators“ (OMOP), der aus dem bisherigen Mediengestalter hervorgegangen ist. Er prüft, ob das, was die Redaktion im Ablauf vorbereitet hat, auch tatsächlich technisch umsetzbar ist. Am Ende gibt der OMOP alle Gestaltungselemente frei. Diese Freigabe ist allerdings nicht zwingend erforderlich, damit Positionen auch ohne Kontrolle in letzter Minute noch eingetragen und ausgespielt werden können. Um diese Aufgaben zu lösen, hat der OMOP vielerlei automatische Indikatoren zur Verfügung. Hilfe bekommen sie zudem vom BrickingProzess. Dieser prüft, ob bedeutende Änderungen an der Story seit der Freigabe stattgefunden haben, und meldet diese durch eine Statusanzeige an den OMOP. Die zweite neue Funktion sind die „Brick- xx/2014 FKT 37 ##SUS##mnertd##1946##SUS##2013##HP_PORTAL## Kuhlmann_neu.indd 37 30.10.14 16:32 Rundfunkanstalt Planung Quantel Mosart Orad Steuerung ActiveX ActiveX Clips OpenMedia Trigger Orad Regisseur Rundown OpenMedia Schnitt ActiveX Grafiken Redaktion ActiveX Grafik Am Ende entscheidet der Mensch Sendung Mosart Quantel Steuerung Sendepilot Bild 9. Akteure des Systems bei der Planung und der Sendung designer“. Diese arbeiten im Vorfeld an der Produktion und sind für das gesamte technische Skelett verantwortlich. Sie fühlen sich sowohl bei Mosart als auch bei OpenMedia zu Hause. Sie sind in der Lage, die Steuerungs-Templates in Mosart zu implementieren und die Brick-Definitionen in OpenMedia zu erstellen. Sie pflegen allerlei technische Tabellen zu den Transitionen, Orad-Parametern und andere Automatismen. Schon früh haben sich einige „Brickdesigner“ in das Projekt mit eingebracht und entwickelten viele der zentralen Konzepte mit. Ihre Kenntnisse der Regieumgebung (alle Brickdesigner sind in der Regel Bildmischer oder Produktionsingenieur) und ihre Fähigkeit, Sendeabläufe sowohl technisch als auch organisatorisch sowie logisch in Form von Bricks zu gestalten, machen sie unverzichtbar. Nach wenigen Wochen realem Betrieb war klar, dass das neue System die Ansprüche an Qualität und Schnelligkeit voll erfüllt – die Erweiterungen von OpenMedia sind also ein Erfolg. Der Mensch produziert und kontrolliert die Inhalte (Bild 9) – nur so wird Qualität erreicht, doch am Ende müssen Maschinen schnell alle Inhalte ausspielen und nur so ist ARD-aktuell in einer angemessenen Zeit reaktionsfähig. Die Redakteure sollten selbst und ohne Zwischenakteure die Maschinen steuern können, darum ging es in diesem Projekt. Deshalb musste eine Steuerungsgrammatik entwickelt werden, die sowohl Redakteure als auch Automationskomponenten gemeinsam nutzen können. Und genau das wurde geschaffen und setzt wichtige Impulse im Gesamtkunstwerk des neuen Studios von ARD-aktuell. ı| 38 xx/2014 FKT ##SUS##mnertd##1946##SUS##2013##HP_PORTAL## Kuhlmann_neu.indd 38 30.10.14 16:32
© Copyright 2024 ExpyDoc
