Digital Signage: TCO senken!

Sorry, this post is available in German only. If you’re interested in large-scale digital signage solutions and reducing their total cost of ownership, feel free to contact me. (Or buy me a plane ticket together with a dictionary…)

Eines der spannendsten Projekte, an dem ich im Zuge des Neubaus der WU Wirtschaftsuniversität Wien arbeite, ist das im Konzept als Door Display bezeichnete elektronische Türschild vor sämtlichen Hörsälen, Projekt- und Seminarräumen. Das Display soll aktuelle Raumbelegungen visualisieren und ist in einer Stückzahl von über 200 geplant.

Bei einer Recherche zu derartigen, als digital signage bezeichneten, Anwendungsfällen stößt man auf ziemlich Marketing-lastigen Content. In Hochglanz-Manier wird von Features geschwärmt, wenig lässt sich hingegen zu den Systemarchitekturen herausfinden.

Die Produktwelt der Anbieter dreht sich um das jeweilige Content Management System (CMS), also um die Software, die den redaktionellen Inhalt verwaltet und schließlich auf die Schirme wirft. Die Gruppenpraxis um die Ecke lizenziert also das Kernsystem und besorgt sich dann zwei, drei Rechner samt Bildschirm für die eigentliche Anzeige. Die Wartung der dezentralen Hardware liegt in diesem Fall vielleicht bei der Ordinationsassistentin, die auch zu Hause hin und wieder ein Windows 7 installiert. Bei den angesprochenen Stückzahlen von 200+ wird’s aber irgendwann langweilig das so zu tun…

Die Größenordnung ändert Prioritäten

Eine simple Kostenrechnung für unseren Anwendungsfall ergab, dass die Gesamtkosten weniger im Redaktionssystem, sondern vielmehr in der Hardware und vor allem im laufenden Betrieb liegen. Das hat offensichtlich damit zu tun, dass das CMS – sofern das Lizenzmodell nicht kriminell durchdacht ist – problemlos von einer auf 200 Installationen skaliert. Was weniger gut skaliert, ist der Mitarbeiter mit der Windows-CD, der für sämtliche Updates über einen sehr weiträumigen Campus laufen müsste. Und bei 200 Rechnern inklusive Bildschirm ist auch jeder gesparte Euro ein spürbarer Vorteil. Unsere Anforderungen daher nochmal im Detail:

  • Möglichst wartungsfreier Betrieb
  • Niedrige Hardwarekosten
  • Content aus bestehenden Systemen

Im Brainstorming wurden viele Alternativen diskutiert. Da konkurrierten chinesiche iPad-Nachbauten, digitale Bilderrahmen oder Industrie-Panels mit waschechten PC-Systemen im Kampf um die niedrigsten Gesamtkosten.

Nach einigen Tests steht unser vorläufiger Sieger fest: ein embedded System auf ARM-Architektur mit integriertem, resistiven Touchscreen – so eine Art Smartphone im 7 Zoll Format. Erhältlich ist ein derartiges Ding beispielsweise beim deutschen Hersteller Garz & Fricke.

Power over Ethernet und Stromverbrauch allgemein

PoE ist nicht gleich PoE: Ethernet zerlegt!

Das oben beschriebene Device benötigt lediglich 4-8 Watt aus der Dose, was selbst bei einer Stückzahl von 200 ungefähr dem Stromverbrauch meines Heizstrahlers im Badezimmer entspricht! Die Möglichkeit das Device mit Power over Ethernet (PoE), also mit Stromversorgung über das Netzwerkkabel zu betreiben, macht eine separates Netzgerät und die entsprechende Verkabelung überflüssig.

Ein paar anfängliche Probleme mit der Nicht-Standardisierung von Power over Ethernet ließen uns zwar an der Machbarkeit dieser Stromversorgung zweifeln, aber inzwischen scheint’s zu klappen. (Und man kennt jetzt ein LAN-Kabel von innen.)

Software auf ein Minimum reduziert

Die im Test befindliche Hardware läuft unter Windows, Linux oder auch Android. Kosten und internes Know-How sprechen jedenfalls klar für die Linux-Variante. Deutlich mehr Qual der Wahl gab es da schon bei der eigentlichen Visualisierung der Raumbelegungen. Spätestens seit meinem Ausflug in die Welt der Apps weiß ich, wieviel mehr Aufwand es bedeutet, eine Client-Applikation zu erstellen, als dummes HTML an einen Browser zu übergeben.

Webseite dient zur Visualisierung

Das geschilderte Problem inkorporiert allerdings auch bereits die Lösung: am embedded Device wird lediglich ein Browser gestartet, der eine Webseite aufruft. Das bedeutet, dass sämtliche Daten und Logik zentral am Server liegen und auch dort – vergleichsweise günstig – gewartet werden.

Wer’s ausprobieren möchte, hier liegt die Webseite: http://bach.wu.ac.at/3ksd/displays/

Bisher war unsere Bilanz vielversprechend:

  • Hardware vergleichsweise günstig bei Industrie-Qualität
  • Client-Applikation (weitestgehend) durch Webseite ersetzt

Einzig das Problem mit den Software-Updates schien noch nicht gelöst. Das Einspielen eines neuen Betriebssystems müsste durch einen Mitarbeiter vor Ort erfolgen; jedenfalls keine gute Idee bei österreichischen Personalkosten…

Das Gesamtsystem im “Mission Control Center” Modus

Architektur: Alle Daten und Programme liegen zentral

Mit Red Boot haben wir ein Bootstrap-Environment, das sich Betriebssystem und Konfiguration selbst zusammenstückelt. Der Boot-Vorgang sieht also wie folgt aus:

  1. Das Door Display bekommt Strom und Connectivity durch das LAN-Kabel
  2. Der DHCP-Server vergibt eine IP-Adresse.
  3. Red Boot hat eine Server-Adresse fix konfiguriert. Diese IP-Adresse ist der einzige Punkt, der lokal und einmal in der Lebensdauer der Hardware konfiguriert werden musste. (< 5 Minuten)
  4. Von der Server-Adresse wird der Linux-Kernel, das Betriebssystem, über das Netzwerk in den Speicher geladen.
  5. Das Dateisystem wird ebenso über das Netzwerk angebunden.

Von hier aus geht’s wie schon zuvor weiter: Starten des Browsers, Aufruf der Webseite mit den Raumdaten. Da die Klonarmee der Displays keine individuelle Konfiguration – etwa einen URL pro Raum – besitzt, entscheidet schließlich der Webserver anhand der IP-Adresse, welche Raumdaten angezeigt werden.

Sämtliche Änderungen der Software am Display können zentral durchgeführt werden. Ein SSH-Skript startet die Armada innerhalb weniger Sekunden neu.

Betriebsbereit

Die Zeichen stehen folglich gut für diese, meines Erachtens nach, wunderschöne Lösung. Wir starten demnächst den Probebetrieb vor ausgewählten Hörsälen, um die tatsächlichen Probleme im Betrieb kennenzulernen.

Bereit für den Outdoor-Test

Da man die spannenden, aber vor allem die erfolgreichen Projekte nicht alleine schafft, gebührt großer Dank Gregor und Florian (LaGentz) für den Hardware- und Qt-Input, Alfred und Peter (PoE), Simon (Grafik), Roland (TFTP/NFS) und insbesondere Dennis und Seán, die das Door Display von der Idee zum Produktiveinsatz tragen.

6 Comments

  • MSc
    May 14, 2011 - 2011-05-14 6:51:29 | Permalink

    Voi leiwand 🙂

  • Pingback: Mathias' Blog » Digital Signage: done right

  • Pingback: Mathias' Blog » Kiosk-Terminal mit schnellem Login

  • Pingback: Mathias' Blog » Campus WU: Drei Jahre in drei Minuten

  • Franky
    October 23, 2013 - 2013-10-23 1:28:25 | Permalink

    auch wenns ein alter post ist … bei dem http://bach.wu.ac.at/3ksd/displays/ sample laufen jedenfalls bei mir die zeit und “next” langsam auseinander: zweiteres tickt merklich schneller. Wahrscheinlich http://stackoverflow.com/questions/6129166/countdown-clock-issue … warum nicht das “next” einfach aus der jclock-zeit berechnen anstatt nen separaten timer aufzusetzen?

    • Mathias
      October 23, 2013 - 2013-10-23 1:37:45 | Permalink

      JavaScript und Zeit sind so eine Sache. Danke für den Hinweis!

      Die verlinkte Seite hat’s jedenfalls & ohnehin nicht in die Produktion geschafft (Zeit wird ua serverseitig synchronisiert).

  • Leave a Reply

    Your email address will not be published. Required fields are marked *