Executive protocol explained
Before MDB there was Executive — the serial protocol still living inside a huge installed base of coffee and beverage machines. Here is how it works and why a platform has to speak it.
Ask most people about vending protocols and they will mention MDB. But walk through a real fleet of coffee and beverage machines — especially European ones with a few years on them — and you will find a different standard doing the work: Executive. If you plan to modernise an existing fleet, you cannot afford to pretend it does not exist.
Where Executive comes from
Executive is a serial protocol that grew up in the European beverage-vending world, on machines from manufacturers like Necta, Zanussi and Wittenborg. It predates the widespread adoption of MDB and solved the same basic problem — letting a payment system and a machine talk — but with a different design and a different heritage. For a large installed base of hot-drink and combination machines, Executive is simply what is wired in.
That is the first thing to understand: MDB did not replace Executive overnight. The two coexist in the field. A vending operator with a mixed fleet very often has both, sometimes in machines standing side by side.
Master, slave, and a current-loop link
Like MDB, Executive is a master/slave serial protocol carried over a simple electrical link. The machine controller and the payment system exchange framed messages: the machine reports what the customer is doing, the payment system reports available credit and authorises a vend. Where MDB defined a clean set of device classes and reserved addresses, Executive is closer to the machines it grew up on — more tied to the beverage-machine model of operation, and with more vendor-specific behaviour to accommodate.
The most important thing to know about Executive is that it comes in two modes, and they split responsibility for pricing in opposite directions.
Price Holding vs Price Display
In Price Holding mode, the payment system holds the price list. When a customer makes a selection, the machine effectively asks the payment device “what does this cost, and is it approved?” The prices live in the payment system.
In Price Display mode, the machine holds the price list and communicates prices to the payment system. The machine is the source of truth for what a drink costs; the payment device works with the prices it is told.
Why does this matter to an operator? Because it decides where you change a price, and where a mismatch will bite you. A terminal being fitted to an Executive machine has to detect and match the mode the machine expects. Get it wrong and you get the classic symptoms: prices that read as zero, vends that are refused, or a machine that charges the wrong amount. None of that is exotic — it is just the protocol doing exactly what it was told by a device that guessed the mode.
Why a platform must speak both
Here is the operator's real problem. A modern payment terminal — one that takes contactless cards, meal cards and QR — is designed and marketed around MDB, because MDB is the modern standard. But a large share of the machines actually in service, especially beverage machines, speak Executive. If your upgrade path only covers MDB, half your fleet is stranded.
This is why Hero Nexus, the Android software that runs inside the terminal, speaks both MDB and Executive — including both Executive modes. The same terminal, the same cloud, the same fleet view works whether the machine underneath talks the modern bus or the older one. The protocol is an implementation detail we absorb; the operator sees one platform.
That is also what makes a genuine Smart VMC upgrade possible on machines people assume are too old to modernise. An Executive beverage machine from years ago is not a dead end. It has a serial link, a defined pricing model and a vend cycle — everything a terminal needs to join it, take a modern payment, and start reporting telemetry to the cloud.
Executive is not glamorous and it is not new. But it is running inside a great many machines that are still earning money every day. Treating it as a first-class protocol, not a legacy nuisance, is the difference between modernising a whole fleet and modernising the convenient half of it.