Digital Beschilderung in Aufzugsdisplays mit Python Middleware

von Roland Rickborn
Digital Signage mittels Python Middleware

Digital Beschilderung mit PADS4

PADS4 Plattform [1] ist eine modulare, datengetriebene Lösung für digitale Gebäude, die Digital Signage, Workspace Management, Besuchersteuerung und weitere Funktionen in einer einzigen zentralen Umgebung vereint. Der Hersteller NDS beschreibt die Plattform so:

„PADS4 ist eine Software-Plattform zur Verbesserung der Benutzererfahrung in einem intelligenten digitalen Gebäude.“

Die Architektur der PADS4 Plattform folgt dem Client-Server-Modell. Bei den Clients handelt es sich um Fat Clients. Ein Client besteht aus einem vollwertigen Mini-PC mit Betriebssystem, M365-Lizenz und angeschlossenem Display. Die Clients agieren unabhängig voneinander, die Inhalte werden also asynchron auf den Clients abgespielt.

Architektur der PADS4 Plattform

Bei unserem Kunden, einem Unternehmen aus der Pharmabranche mit ca. 55.000 Mitarbeitenden, verteilt auf mehrere Standorte weltweit, kommt die PADS4 Plattform mit dem Modul Digital Signage [2] zum Einsatz. SharePoint ist in die Plattform integriert und dient sowohl als DAM, als auch als Unterstützung bei der Erstellung neuer Inhalte in Form von Listenelementen.
Die Kanäle der Digital Beschilderung orientieren sich größtenteils an Gebäuden (in Verbindung mit Standorten und in Verbindung mit Kategorien von Mitarbeitenden). Alle Displays in „öffentlichen“ Bereichen in Gebäuden, häufig aber auch Displays in „internen“ Bereichen wie z. B. Labore oder Fertigungsräumen, sind bereits in das System der Digital Beschilderung integriert.
Der Wunsch des Kunden war es, möglichst auch alle Aufzugsdisplays in den Gebäuden in die jeweiligen Kanäle der Digital Beschilderung zu integrieren.

Herausforderung Aufzugsdisplays

In und vor den Aufzügen sind flexyPage Displays [3] von ELFIN verbaut. Auf den Displays läuft eine Firmware, die zentral über die flexyPage Software Suite konfiguriert werden kann. Sie stellen damit Thin Clients dar. Die auf den Displays anzuzeigenden Inhalte werden in sogenannten Widgets verwaltet. Mittels flexyPage Software Suite wird definiert, welche Displays welche Widgets mit welchen Inhalten anzeigen. Folgende Widgets kommen für die Verwendung bei der digitalen Beschilderung in Frage:

  • Video Stream Widget
  • RSS Reader Header Widget
  • Web Basic Widget
  • Campaign Basic Widget
  • Diashow Basic Widget
  • Remote Viewer Image Widget

Eine Herausforderung bestand also darin, ein passendes Widget zu finden, das in der Lage ist, alle Inhalte der Digital Beschilderung anzuzeigen. Bei der Digital Beschilderung kommen neben statischen Inhalten in Form von PNG und PDF auch dynamische Inhalte in Form von MP4 zum Einsatz.

Ich habe alle Infrage kommenden Widgets auf Ihre Eignung im obigen Szenario überprüft mit den folgenden Ergebnissen:

  • Video Stream Widget
    Kann entweder lokal abgespeicherte Videos (in bestimmten Formaten) abspielen oder erwartet einen Video-Stream eines Streaming-Servers
  • RSS Reader Header Widget
    Kann nur eine begrenzte Anzahl an Items anzeigen. Jedes Item hat einen kurzen Text und ein Bild. Videos sind nicht möglich.
  • Web Basic Widget
    Kann einfache Webseiten anzeigen, mit JavaScript, aber ohne eingebettete Videoplayer.
  • Alle anderen Widgets
    Können keine Videos abspielen

Die flexyPage Software Suite bietet nicht die Möglichkeit, mehrere Widgets an derselben Position zu konfigurieren und sie dynamisch an- und abzuschalten. Es besteht also nicht die Möglichkeit, zuerst ein Video mit dem Video Stream Widget anzuzeigen, und danach an derselben Stelle eine Diashow mit dem Diashow Basic Widget zu zeigen.

Eine weitere Herausforderung stellen die Thin Clients dar. Sie haben kein Betriebssystem, sondern nur eine Firmware. In der Firmware ist nicht vorgesehen, dass sie sich z. B. gegenüber Microsoft authentifizieren. Es besteht also keine Möglichkeit, von den Displays aus direkt auf eine M365-Ressource, z. B. SharePoint zuzugreifen.

Ziel: Integration aller Aufzugsdisplays in die Digital Beschilderung

Ziel des Projektes war es, alle vorhandenen Displays in den Aufzügen und in den Wartebereichen der Aufzüge ebenfalls in die Digital Beschilderung zu integrieren. Außerdem sollten neu angeschaffte Aufzugsdisplays desselben Herstellers/Modells unkompliziert zum System hinzugefügt werden. Dabei sollten alle Aufzugsdisplays in die bereits bestehenden Kanäle eingeordnet werden und (möglichst) denselben Inhalt anzeigen. Es gab keine Anforderung bzgl. Zeit-Synchronität, siehe oben erwähnte Asynchronität bei den Fat Clients. Außerdem gab es keine Anforderung bzgl. der Anpassung von Inhalten. Die Aufzugsdisplays sollten also die identischen Inhalte anzeigen, die auch auf den „großen“ Displays angezeigt werden.

Mein Lösungsansatz: Python Middleware

Mein Lösungsansatz sieht eine Middleware vor, die eine Brücke zwischen der PADS4 Plattform und den Aufzugsdisplays herstellt. Einerseits übernimmt die Middleware die Verwaltung der anzuzeigenden Inhalte gegenüber PADS4. Andererseits stellt Sie die anzuzeigenden Inhalte, ggf. mit vorheriger Konvertierung, den Aufzugsdisplays in geeigneter Weise zur Verfügung. Bei diesem Lösungsansatz habe ich mich für das Web Basic Widget auf den Aufzugsdisplays entschieden. Die Middleware habe ich mit Python umgesetzt. Das Programm ist auf einem Windows-Server eingerichtet, der in die Domain integriert ist und damit auch Zugriff auf M365-Ressourcen hat. Mein Programm wird regelmäßig per geplante Aufgaben ausgeführt. Auf dem Windows-Server ist der PADS4-Client installiert, der sich um das Herunterladen der anzuzeigenden Inhalte, sowie die Zeitpläne kümmert (Zeitpläne als XML-Datei). Der Windows-Server dient also als Client in der PADS4-Plattform und gleichzeitig als Server in meiner Lösung. Die erweiterte Architektur habe ich in Abbildung 2 dargestellt.

Erweiterte PADS4 Plattform

Mein Programm übernimmt im Wesentlichen diese beiden Aufgaben:

  1. Verwaltung der Medien von PADS4
    • Gibt es neu anzuzeigende Inhalte und, falls ja, sind Aufzugsdisplays davon betroffen?
    • Falls es neu anzuzeigende Inhalte für Aufzugsdisplays gibt, werden diese in einer „Warteschlange“ (in einer Datenbank) erfasst:
      • Wann sollen die Inhalte angezeigt werden?
      • Welche Inhalte sollen angezeigt werden?
      • Wie lange sollen die Inhalte angezeigt werden?
      • Auf welchen Displays sollen die Inhalte angezeigt werden?
      • Müssen die Inhalte ggf. konvertiert werden?
  2. Bereitstellung der Inhalte für die Aufzugsdisplays
    • Wann müssen welche Inhalte für welche Displays wie lange bereitgestellt werden?

Konvertierung

Das ausgewählte Web Basic Widget auf den Aufzugsdisplays kann Webseiten mit JavaScript anzeigen. Außerdem kann es nur „einfache“ Dateiformate wie HTML, JPG, PNG, etc. anzeigen. Deshalb müssen „komplexe“ Dateiformate wie MP4 oder PDF zuerst konvertiert werden. Für die Konvertierung der diversen Dateiformate verwende ich bekannte Open-Source Programme wie z. B. ffmpeg, ImageMagick und GhostScript, die aus Python heraus als Subprozesse aufgerufen werden. Folgende Konvertierungen werden vorgenommen:

  • MP4 -> GIF
  • PDF -> PNG / Seite
  • Web -> PNG des sichtbaren Bereichs im Browserfenster

Die erstellten GIF-Dateien werden in die „Warteschlange“ mitaufgenommen. Als Browser kommt Selenium mit einem headless gestarteten Edge zum Einsatz.

Bereitstellung

Für die Bereitstellung wird die „Warteschlange“ analysiert. Alle demnächst anzuzeigenden Inhalte werden pro Display im individuellen html-Verzeichnis, das zu dem jeweiligen Aufzugsdisplay gehört, zur Verfügung gestellt. Dieses html-Verzeichnis sieht beispielsweise so aus:

  • display01
    • display01.html
    • display01/xyz1.gif
    • display01/xyz2.png
    • display01/xyz3.gif
    • display01/default_ende.jpg

Die HTML-Datei hat in etwa diesen Inhalt:

<html>

<head>
    <title>displayo1</title>
    <meta http-equiv="refresh" content="1800">
</head>

<style>
    body {
        background-color: #123456;
        margin: 0px;
    }

    html,
    body {
        margin: 0;
        height: 100%;
    }

    img {
        display: block;
        width: 100%;
        height: 100%;
        object-fit: cover;
    }
</style>

<body>
    <div>
        <img id="myslideshow" />
    </div>

    <script>
        const imgArray = [
            { "src": "display01/xyz1.gif", "duration": "30000" },
            { "src": "display01/xyz2.png", "duration": "30000" },
            { "src": "display01/xyz3.gif", "duration": "28000" },
            { "src": "display01/default_ende.jpg", "duration": "10000" }

        ];
        let curIndex = 0;
        let duration = 0;

        function slideShow() {
            document.getElementById('myslideshow').src = imgArray[curIndex].src;
            duration = imgArray[curIndex].duration;
            curIndex++;
            if (curIndex == imgArray.length) { curIndex = 0; }
            setTimeout("slideShow()", duration);
        }
        slideShow();
    </script>
</body>
</html>

Im Web Basic Widget dieses Aufzugsdisplays ist die statische URL http://123/display01/display01.html eingestellt. Durch das refresh-Kommando ist sichergestellt, dass das Display den Inhalt des Widget regelmäßig neu lädt. Durch diesen harten Refresh kann es gelegentlich zu Abbrüchen bei der Darstellung von Inhalten auf den Aufzugsdisplays kommen.

Videos als Herausforderungen

Bewegtbilder spielen bei der Digital Beschilderung beim Kunden eine große Rolle. Die Darstellung von Videos auf Aufzugsdisplays ist allerdings aus oben genannten Gründen nicht so einfach. Die Kompromisslösung mit dem Web Basic Widget und der Umwandlung von MP4 in GIF stellte eine Herausforderung dar. Ziel ist, GIF-Dateien mit möglichst hoher Qualität, aber dennoch möglichst kleine Dateigrößen zu erreichen. Zur Konvertierung von MP4-Videos in animierte GIFs habe ich das folgende Kommando verwendet:

ffmpeg -ss 00 -t <duration> -threads 0 -i "<inputfile>" -vf "fps=10,scale=<gifwidth>:-2:flags=lanczos,split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" -loop -1 -y "<outputfile>"

Die Bildwechselfrequenz von 10 Frames/Sekunde führt zu GIF-Dateien mit einer geringen Dateigröße, die aber trotzdem relativ flüssig erscheinen. Der lanczos-Filter sorgt für hohe Skalierungsqualität. Die übrigen Parameter dienen zur Erstellung und Verwendung einer optimierten Farbpalette je Video.

Während der Einführungsphase der Lösung haben wir bemerkt, dass sehr große GIF-Dateien (+100 MB) sowohl bei den Aufzugsdisplays, als auch im Netzwerk zu Problemen führen. Daher stelle ich im Programm sicher, dass GIF-Dateien, die über <maxSizeMb> groß sind, nicht weiterverarbeitet werden, was aber an dieser Stelle in Kauf genommen wird, um Netzwerkprobleme oder die Überlastung der Thin Clients zu vermeiden. Dadurch kann es zu Abweichungen bei der Anzeige von Inhalten auf Aufzugsdisplays im Vergleich zu anderen Displays innerhalb der PADS4 Plattform kommen.

Ergebnis der Integration von Aufzugsdisplays in die Digital Beschilderung

Die hier vorgestellte Lösung läuft seit ca. 1,5 Jahren erfolgreich und ohne größere Probleme im Produktivbetrieb. Videos mit statischen Inhalten werden auf den Aufzugsdisplays als GIF mit sehr hoher Qualität angezeigt. Videos mit dynamischen Inhalten funktionieren auch, haben aber eine geringere Qualität. Neu angeschaffte Aufzugsdisplays müssen händisch hinzugefügt werden, was 2-3-mal pro Jahr der Fall ist und einfach zu bewerkstelligen ist.

Fazit

Angesichts der gegebenen Randbedingungen funktioniert die hier vorgestellt Lösung sehr gut. Wünschenswert wäre eine höhere Qualität der GIF-Dateien bei Bewegtbildern. Dafür müssten aber die aufgetretenen Netzwerkprobleme identifiziert und gelöst werden. Außerdem wären speziell für Aufzugsdisplays (genauer: für kleine Displaygrößen) optimierte Inhalte bei der Digital Beschilderung wünschenswert. Also anstatt eine PowerPoint Folie sowohl auf einem großen Screen, als auch auf einem kleinen Aufzugsdisplay dazustellen, sollte es beispielsweise zwei Folien geben. Eine Folie davon wäre optimiert für einen großen Screen. Die zweite Folie wäre dagegen optimiert für ein kleines Display, mit weniger schriftlichen Informationen. Der PADS4 Designer wäre z. B. eine sinnvolle Ergänzung.

Zurück

© 2006-2026 exensio GmbH
Einstellungen gespeichert
Datenschutzeinstellungen

Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell, während andere uns helfen, diese Website und Ihre Erfahrung zu verbessern.

Sie können Ihre Einwilligung jederzeit ändern oder widerrufen, indem Sie auf den Link in der Datenschutzerklärung klicken.

Zu den gesetzlichen Rechenschaftspflichten gehört die Einwilligung (Opt-In) zu protokollieren und archivieren. Aus diesem Grund wird Ihre Opt-In Entscheidung in eine LOG-Datei geschrieben. In dieser Datei werden folgende Daten gespeichert:

 

  • IP-Adresse des Besuchers
  • Vom Besucher gewählte Datenschutzeinstellung (Privacy Level)
  • Datum und Zeit des Speicherns
  • Domain
×
Irving Tschepke
Irving Tschepke
Dipl.-Wirtsch.-Ing.
Peter Soth
Peter Soth
Dipl.-Inform. (FH)
Wir antworten in wenigen Stunden.
Oder rufen Sie einfach an:
×
Irving Tschepke
Irving Tschepke
Dipl.-Wirtsch.-Ing.
Peter Soth
Peter Soth
Dipl.-Inform. (FH)
Wir antworten in wenigen Stunden.
Oder rufen Sie einfach an:
You are using an outdated browser. The website may not be displayed correctly. Close