Andon Boards: From Lamps to Data the Floor Can Act On

The andon idea is older than the software that sells it, and it is a good idea: when something goes wrong, signal it, and get eyes on it fast. On a Toyota line in the 1970s that meant a rope and a lamp. The lamp part worked because of what surrounded it: a team leader whose actual job was to walk over. A lamp nobody responds to is decoration. Everything about a modern andon board is an attempt to keep the lamp and add the context the responder needs before they arrive.

What a Modern Andon Wall Shows

An andon wall is one screen showing every station on the line at once, each station as a tile. The state lamp is the anchor: green running, red stopped, yellow for attention. Around the lamp, a handful of facts that turn a color into a decision:

That last one matters more than it sounds. A board built on live machine states (the same SCADA ingest that feeds OEE calculation) knows when it last heard from a station, and honesty about a dead feed is what keeps the rest of the board trusted.

Manual Override, Done Honestly

Not every state can come from a machine. A feeding station with no PLC, an operator spotting a quality problem on an otherwise green line, a supervisor consolidating two short stops into one: sometimes a person has to set the state. The honesty rule is simple: an override is an event, not a silent edit.

When a supervisor flips a lamp, the override asks for a reason, and the flip becomes a downtime event in the record with a timestamp and a name attached. No ghost states, no quietly greened tiles before the shift report. This is what separates a board people trust from one they audit: anyone reviewing the day later sees both what the machines reported and what people changed, and why. In practice this pairs directly with downtime tracking with reason codes: the override's reason lands in the same Pareto as machine-reported stops.

Where the Board Lives

A report is andon's opposite. A report describes yesterday to someone in a meeting; an andon board describes now to someone standing close enough to act. The screen belongs at the line, mounted where the operators and the line lead already stand, big enough to read from the far end of the line, refreshed fast enough that the red tile is red while the jam is still jammed. A second view in the supervisor's office is fine; a board that lives only in a browser tab someone opens tomorrow morning is not andon, it is a report with colors.

Refresh speed is a spec, not a nicety. Voltrus MES ships an andon board that reads live station state with a 10-second refresh and supervisor override with a reason, mounted at the line. Ten seconds is the difference between a responder walking over during the stop and walking over after it has already cost the shift its availability.

Frequently Asked Questions

Do we need lamps and a screen?

The screen is the substance; physical lamps are optional. A large display at the line with clear color-coded tiles does the same job, and many factories add a tower light on key machines for cases where nobody can look at a screen. Start with the screen.

Won't operators resent a board that shows their station red?

They resent boards used to blame them. Andon data should route help, not rankings: red means "someone come look," not "someone explain themselves." The moment the board feeds a leaderboard, tiles start staying mysteriously green and the data dies.

How is this different from a SCADA screen?

SCADA shows one machine's internals to a controls engineer. An andon board shows every station's state, job, and output to the whole line at once. Same underlying signals, different audience and altitude, which is why Voltrus MES draws the board from the same keyed SCADA ingest that feeds OEE and downtime records.

Your Line, Live

Voltrus MES is live: an andon board with live station lamps, 10-second refresh, and supervisor override that keeps its receipts. One line to start.

See Voltrus MES