Bild 1. Vereinfachtes Blockdiagramm des Steuer- und Signalflusses. OpenMedia. Client. Protokoll. Protokoll

Transkript

1 Teil VI: und das Bricking-Konzept Technische Sendeplanung ein Kinderspiel? Bei ARD-aktuell geht fast nichts ohne Open- Media: 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 - und Grafiken aus dem -System werden verknüpft, Kamerawechsel oder externe Schalten eingetragen (Bild 1). Alle Informationen, die in auftauchen, werden 1:1 und ohne zusätzliche Schritte an die Mosart- Sendeautomation (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 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, mit diesen Komponenten zu verbinden, ohne dabei die bisherigen Workflows bei ARD-aktuell in Frage zu stellen. 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 Bild 1. Vereinfachtes Blockdiagramm des Steuer- und Signalflusses Client Protokoll Protokoll Client-Server Daten-Austausch Playout Brick-GUI Transitionstabelle = f (visueller Einstieg & Ausstieg) Sendeformen = f (Sendung, Regie) Brick-Designer Brick a = Brick n f (SF, Kamera, Regie) Medienobjekte Clip + PlatzHalter = f (SF) Live-Schalte= f (SF, Mosart-Cmd) Kamera = f (SF, Mosart-Cmd) Regelprüfung für Clips, Grafik, Kamera, Live, CMD s: Must, Strong-Musts Dont s Can s Wrong-Spielorte, Ignore-Spielorte Umbricktabelle = f (Kamerakompatibilität) Grafik MW + PH f (SF, Kamera, Mod-Größe,) Grafik VG+ PH F (SF) Grafik Insert F (SF) Spielorliste f (MW, VG, Insert, Clip) Brick-Publish Brick-Validierung Brick-Prozess Brick e kb Brick b c Brick c Maestro -Server MOS-MO Mosart 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 Reihenfolge 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. wurde damals so erweitert, dass jeder Techniker direkt am Bildschirm SF Kamera Playliste Sendeplan MOD-Größe Beitrag 1 Videoclip Beitrag n Videoclip Grafik CII MOS-RO Corba Transitionsprüfer Trans. OK? ORAD Active X Grafik MW + PH f (SF, Kamera, Mod-Größe,) Dipl.-Ing. Ronald Entlinger (NDR) arbeitet in der Projektleitung des Redaktionssystems Mosart-MOS-Plug-in Mosart Regieautomation Mosart MOS-Gateway Bild 2. Brickkonzept in Verbindung mit der Regieautomation Echtzeitgrafik CII 32

2 Schneiden von Videos Agenturen Texte Sendungsplanung X Videos Auswahl brick Auswählen und Befüllen von Grafikvorlagen X MOS MO MOS RO MOS MO Inserts, Viz Mosart VG-Grafiken, Medienwandgrafik Or a d - t i v Pl ug- i n Plug-in MOS MO Maestro e s t r o Playout CII - Client - a - ver Server MOS MO 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 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 mit der Automationssoftware Mosart kommuniziert, um den technischen Rundown zu übergeben, hätte man als Antwort die Mosart-Primitiven 1,2) gehabt; schließlich waren die Direktiven der eregie nicht sehr weit davon entfernt (Bild 3). Die eigentliche Herausforderung war eine Bild 4. Blockdiagramm der Integration zwischen,, und Mosart - Plug-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 MOS MO sq-server Integration zwischen und Mosart (Bild 4) auf Basis von Automationsprimitiven erfolgt wäre. Analyse der Anforderungen Corba Eine Frage war deshalb: Kann ARD-aktuell weiterhin mit 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, 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 Brick- Konzept 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 33

3 von Primitiven, die vom Redaktionssystem aufgerufen werden können? Oder sollen sie in implementiert werden als eine Art Plug-in in der GUI, die - Angaben 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 Basis- Templates 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 Kreuzschienen Mastering- Video- Graphics 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 Tonmischpult Broad- cast- System Brick-Layer Bildmischpult Leveller Lichtpult 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 -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 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

4 Bild 7. Benötigte Angaben zu einer Schalte in 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 eine einfache Möglichkeit geben, den Spielort eines Mediums zu definieren. 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 problemlos machbar und damit war es grundsätzlich möglich, den Bricking-Prozess in Open- Media als Nachrichtensystem zu implementieren. Offen blieb zunächst die Frage, wo die Übersetzungslogik ihren Platz finden soll in Mosart oder in? Für sprachen mehrere Gründe: das flexible Datenmodell, die anpassbare GUI und die Fähigkeit, neue Funktionen mit verhältnismäß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 implementiert. 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 OFF- Position 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 Grafik- Templates 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) 35

5 Tabelle II. Im System berücksichtigte Sicherheitschichten mehrere MOS-Mosart Schnittstellen Produktionssystem als Cluster HotStandBy -Link Replikationssever unabhängige, reconnect-fähige MOS-Schnittstellen zu Mosart Das Haupt--System besteht aus einem Zwei-Knoten-MS-Cluster Ein zweites Cluster-System wird sekundengenau repliziert Ein Stand-Alone-System bekommt live Agenturmeldungen, die produktiven Daten aber nur einmal am Tag Ermöglicht dem Anwender, die zentrale technische Schnittstelle in Selbsthilfe zu wechseln. Garantiert Fail-Over-Fähigkeiten ohne Unterbrechungen für die Anwender. Garantiert einfache Wartungen des Hauptsystems durch geplanten Systemwechsel. Im Havarie-Fall wird eine schnelle Weiterführung des Betriebs sichergestellt verlangt aber danach einen Reconnect der User und der Schnittstellen. 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. Metadaten mit den Positionen verbunden werden konnten. Das Metadatenmodell von ließ sich leicht erweitern, ebenso wie die Visualisierung der Daten in Form von sogenannten Ansichten. Damit konnte in Open- Media ein Brick-Design-Modul implementiert werden, ohne dass eine spezielle Software- Lösung dafür nötig wurde. Mit diesem Modul werden alle Bricks erstellt und modelliert. Es entstanden ungefähr 580 solcher Brick- Definitionen. Nachdem die genauen Eigenschaften der Brick-Definitionen modelliert waren, war es möglich, den tatsächlichen Bricking-Prozess in zu implementieren. Der Bricking-Prozess besteht aus zwei OMIS 3) - Plug-ins. Zum Teil erlauben diese den Einsatz von Skript-Sprachen, wie zum Beispiel VBS 4). 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 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. Vom Groben ins Feine 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, 3) OMIS: Interface Services 4) VBS: Visual Basic Script 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 Wrong- Graphics. 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 Strong- MUST 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 -: Wenn das - aus 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

6 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 Open- Media und Mosart erfolgt mithilfe einer MOS- Schnittstelle 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 weiter. Daraus extrahiert das nötige Kommando für den Aufruf des Mosart- Templates und stellt es für eine Verwendung in den Brick-Definitionen zur Verfügung. Über die RO-Kommunikation sendet 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 Zu nutzt eine vereinfachte MOS-Schnittstelle über. Zusätzlich läuft auch eine MO-Schnittstelle, aber diese wird nur als Absicherung verwendet und kann gegebenenfalls abgeschaltet werden. Eine RO-Schnittstelle zwischen und -Maestro wurde ebenfalls implementiert, doch diese wird nur in Havariefällen aktiviert. bekommt sonst seine Befehle nur von Mosart über die CII-Schnittstelle. Die MOS--Schnittstelle hingegen spielt eine zentrale Rolle und wurde um eine Funktion erweitert. Dadurch kann Open- Media Initialisierungsparameter an das - 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 für den Anwender angeboten. Indirekt gelangen über Mosart aber auch andere Parameter aus an. 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 auch für das Ausspielen der Ansage zuständig ist, sendet 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 MOS- Integration 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. ermittelt diese überflüssigen Grafikobjekte und markiert sie entsprechend, indem ihr Titel geändert wird. Einige Tage später werden die Objekte aus und gelöscht. Abgerundet wird die Schnittstellen-Umgebung von mit einer klassischen MOS-Profile-1-Schnittstelle zum - System. Diese Schnittstelle ist schon vor neun Jahren entstanden und ermöglich die Sichtung, Wahl und Verlinkung des richtigen Videomaterials in. Architektur des -Systems Das -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-Over- Modus. Bekanntlich setzt 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 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 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 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 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 Bricking- Prozess. 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- 37

7 Grafik Redaktion Schnitt Grafiken Planung Open- Media Mosart Clips 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 zu Hause. Sie sind in der Lage, die Steuerungs-Templates in Mosart zu implementieren und die Brick-Definitionen in zu erstellen. Sie pflegen allerlei technische Tabellen zu den Transitionen, -Parametern und andere Automatismen. Schon Steuerung Bild 9. Akteure des Systems bei der Planung und der Sendung Sendung Regisseur Open- Media Rundown Mosart Trigger Sendepilot Steuerung 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. Am Ende entscheidet der Mensch 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 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