A display should not be a platform

My company makes displays. So I know this temptation from the inside. Every display maker wants to become a platform.

The pattern is always the same. The vendor arrives with its own content management system. It comes with a cloud service the display will not work without. A sales architect stands between you and the documentation. All of it is presented as added value. In fact it is a dependency.

What an integrator actually needs

Look at what most projects actually have to do. The integrator has a working system. That system knows something: where a vehicle is, what state a production line is in, when a flight departs, which bay has been assigned. That knowledge needs to be shown on a physical display, in the right place, at the right time. That is the whole job.

You do not need a new platform for that. You need HTTP in and content on screen. The system that carries the logic already exists. The integrator built it. The display should be that system’s output, not a new centre.

Where it goes wrong

A display layer usually becomes a problem in one of four ways.

The first is a closed content system. The display only shows what comes through the vendor’s content management system. Your system cannot write to the display directly. You send the data to the vendor’s cloud and the cloud passes it on to the device. You have just taken on a dependency you cannot audit or remove.

The second is a cloud dependency while running. The display needs a connection to the vendor’s servers to work. When the network goes, so does the picture. At a port gate, on a production line or on a railway platform, that is not acceptable.

The third is an API built on the side. The interface exists, but it was made for internal use and documented only under pressure. Edge cases are not described. Behaviour changes without notice. You find this out during integration, not before.

The fourth is consumer hardware in an industrial setting. Everything looks fine in the demonstration. Then come operating temperature, dust and continuous running. A display is a production component and it should be specified like one.

Only the last of these is a hardware question. The other three are questions about who owns the system.

Who owns the capability

This is where my view is sharpest. If your data has to pass through someone else’s cloud to reach the screen, the ability to show it no longer belongs to you. It belongs to the vendor.

You keep paying for a content system you never really control. You train staff on yet another management portal. You keep it running. If the vendor changes the price or the terms, the most visible part of your system is someone else’s decision.

The integrator who built the system should remain its owner. They know the logic. They answer to the client. They are the one who has to work out why the gate display is showing something wrong. If they cannot write from their own system straight to the display, they are responsible for something they do not control.

A chain is as strong as its weakest link. A cloud you did not choose yourself is a link you cannot see.

What a good display layer looks like

A good display layer is boring. It has an HTTP endpoint your system can call. It has a simple set of parameters that map to named areas on the screen. The layout is set up once, at commissioning. After that the system only sends values.

One of the simplest set-ups I have seen was at a port gate. Every truck weighing sent one request to the display. The display showed the weighing result and the unloading bay. One event, one request, the picture changes. Nobody had to log in to a cloud anywhere.

If the display network cannot reach the system, the direction can be reversed. The display then fetches data itself at a set interval. This also works when the source is a third-party feed you do not control.

If the network drops, the display should go on showing the last content it received. It should not go blank, stick on an error screen or need a restart. In a round-the-clock installation this matters more than it first seems.

After commissioning, the vendor should step out of the way.

What I would tell another manager

If you have a system that already carries the logic, do not let the display take it over. Ask the vendor three things. Can my system write to the display directly? What happens when the network drops? Can I evaluate the interface in an afternoon, without a procurement process?

If the answer to any of them is vague, you are not buying a display. You are buying a platform, and a dependency with it.

A display is an output. It should show what your system knows, reliably and without a middleman. Anything beyond that serves someone else’s interests.