Edge computing and digital signage

The reliability of your digital signs is very important. In the best case they still fully function during network outages or other temporary problems. The info-beamer hosted system can help with that.

Introduction

Recently two articles were posted that I personally found very interesting. The first one was about the display outage at the Gatwick Airport in London. Apparently all their flight information signs relied on a network connection to some offsite service. This connection went down and all their signs stopped working. They were at least somehwat prepared and used whiteboards and lots of manual labor instead. You can see the result in this great picture taken by @TamaraSalem on twitter.

Another interesting blog post was Edge Computing at Chick-fil-A. They describe how they run some of their business logic on a tiny cluster of small machines at each of their restaurants instead of running everything "in the cloud". If you didn't read this blog post, I suggest you do that now.

Reliability and system design

One of the primary goals of info-beamer hosted has always been to be as relible as possible. This is a decision that heavily influences how the info-beamer hosted operating system was designed. You can't just run a stock Raspbian system, modify it a bit and hope for the best. One example are system updates: The info-beamer operating system uses a mechanism called A/B booting that installs any system update into a completely new area on the SD card, marks it as active and then reboots the device. Any interruption during installation doesn't have any effect on the running system as the new version isn't active yet and the installation attempt can be repeated later. If the new version doesn't work properly (which info-beamer autodetects) it can be fully reverted and a device automatically switches back to the previous version.

This also means that every operating system version running on a device is perfectly predictable: There's no leftover files from an earlier version as every installation is completely new.

The result is a runtime environment that is perfectly predictable and a sign that works today will work tomorrow. To help with that, an info-beamer device primarily plays locally cached content and as such doesn't have to rely on a perfect network connection. If you assign new content to a device, the content is downloaded first (optionally from other local devices) and only activated if everything has been cryptographically verified and cached locally.

On top of that each device checks all cached content and its own operating system every 24 hours and automatically repairs any problem it might detect. If a device must repair content for any reason, it can download a fresh copy over the internet or from other local devices using the peer-to-peer feature.

If you have devices that mostly play static content that rarely changes (like menu information in a restaurant), this works really well: Assigned content is fetched by a device and once locally cached it will reliably play this content and doesn't need a perfect internet connection anymore.

Of course that doesn't work for all use cases. Sometimes you have dynamic information that should be up-to-date.

Edge computing?

There are different approaches when building dynamic signs. One of them is to change what a device should display at different times. info-beamer hosted offers a powerful REST API that can help with that.

As an example, you might create two different setups based on the HD Image/Video player package: One with the morning menu playlist and another one with the evening menu playlist. Instead of manually assigning the setups to a device you can use the device update API call. This allows you to automate switching between those two setups.

Every time you assign a new setup to a device or change the configuration of a setup, the info-beamer hosted service has to reach out to the device and initiate a synchronization process: The device has to fetch new assets, update configuration files and make sure that it now plays the newly assigned content.

This of course requires a working internet connection. Usually any change made to the configuration of a setup or to the currently active setup for a device is almost instantly pushed to a device. The info-beamer service has a pretty good track record of being available and you might forget that this approach won't work if network connectivity or the info-beamer hosted service is down for whatever reason.

Of course you shouldn't rely on the happy path alone when designing any system. You should also plan for failure.

The info-beamer operating system already handles a lot of failure cases on a device. Most of what's left is to gracefully handle any kind of connectivity problem.

Let's go back to the morning/evening menu playlist example above: A more robust approach would be to handle the decision of what to display locally on each device. One way to achieve this is to create a package that supports two playlists (the morning and evening playlist) and a configuration option that decides when to play each playlist. You can create a setup, configure both playlists, assign it to a device and the device is then fully self-sufficient and it doesn't need a permanent or reliable internet connection anymore: It can decide on its own what to display depending on the current time.

You can see a real life example of such a package in the day/night branch of the Flexible grid video wall package. It is used in a big video wall installation and automatically shows dark content during the night so neighbours can sleep :-) Since the decision when to toggle night mode is done locally on the devices, switching to night mode works even if the internet connection is temporarily down.

Package services

You can take all this a step further. info-beamer hosted allows you to bundle almost any kind of service with your packages. You can't just decide what to play at what time. Instead you can run almost any program alongside your display code: It can contact outside services (like talking to the Twitter API), handle touch events or anything else really, as you can easily run Python code or (with a bit more effort) any other code. The info-beamer operating system offers a reliable sandboxed execution environment for your code and ensures that your package services are constantly running by restarting them if they ever crash for any reason.

Here's an example of how an info-beamer hosted customer that uses this feature with great success at multiple cinemas: They have a Windows based Point of Sale system running at each location. The system handles ticketing, schedules shows and a lot more. info-beamer devices are used in front of each auditorium and at each ticket booth and display information about the next show and give an overview over what's playing.

Instead of pushing information through the info-beamer hosted service, we took a different approach: Each info-beamer hosted device has been assigned a fixed IP address and runs a package service that acts as an FTP server. Their Point of Sale system is configured to directly upload information about the shows for the current day to each individual device using the local network.

This was easy to implement and their Point of Sale system already supported FTP. Integrating both systems was really simple and the result has been incredible reliable during almost 4 years of operation: If their outside network is down for any reason, their signs are still up to date, as all communication between an info-beamer device and the Point of Sale system is local only and doesn't depend on an internet connection. Assigning new trailer videos or images is done using the info-beamer hosted service as usual. If the network is ever down, the trailer download is delayed, but that isn't really a problem.

Package services are really great for that: They offer a predictable environment to run almost any code on your devices. Once set up, you'll never have to worry about them running: info-beamer OS does all that for you.

Recommendations for your displays

If possible, push as much logic to your devices as possible. Some packages already offer that. For example the Scheduled Player package already has the ability to define multiple playlists and schedule each of them individually.

If you design a new package you should follow these recommendations as well: Any package that is supposed to trigger certain events at precise moments should handle these events locally on the device instead of pushing events to the device using the info-beamer API.

Since info-beamer OS is really light on CPU resources, there's plenty of processing power available for your logic. Make use of it! A good way to start is to have a look at the package services documentation.

Of course you also shouldn't go too far. While certainly possible, it's usually a bad idea to implement a complete parallel synchronization mechanism that fetches videos or other assets from third party servers unless you have "almost realtime" requirements or want to avoid over-the-internet data transfer: You lose most of the benefits that the solid info-beamer hosted synchronization offers: secure and verified transfer, optional peer-to-peer distribution and solid caching combined with automatic expiration of old content and self checks, so your content is guaranteed to survive (random) reboots and even minor storage problems.

All said, sometimes even that can be useful. It really depends on what you're trying to do with your signs. If you need help designing your solution, feel free to get in contact with support. We're happy to help you build solutions that work reliably for many years.