Wir sprechen MDB direkt mit dem Automaten
Eine Altersprüfung nützt nur, wenn der Automat sich auch an sie hält. Deshalb sitzen wir nicht neben dem Automaten, sondern in seinem Nervensystem: direkt am Bus, an derselben Leitung, über die er mit Münzprüfer und Kartenleser spricht. Den Protokoll-Stack dafür haben wir selbst geschrieben.
Was MDB ist
MDB steht für Multi-Drop Bus. Seit den 1990er-Jahren ist das der Standard, über den die Steuerung eines Verkaufsautomaten – im Fachjargon VMC – mit ihren Zusatzgeräten redet: Münzprüfer, Banknotenleser, Kartenterminal. Eine Leitung, mehrere Geräte, jedes mit einer festen Adresse. Wir arbeiten mit der Fassung 4.3 der Spezifikation aus 2019.
Die Regeln sind streng. Die Steuerung fragt jedes Gerät reihum ab, alle paar Millisekunden, und erwartet die Antwort innerhalb von etwa 5 ms. Ein Gerät darf nie von sich aus sprechen, es antwortet nur, wenn es gefragt wird. Wer etwas zu melden hat – „Kunde hat bezahlt“, „Alter bestätigt“ –, hängt es an die nächste Abfrage an.
Die MDB-Spezifikation kennt ein eigenes Gerät für unseren Zweck: das Age Verification Device, kurz AVD, auf Adresse 0x68. Die Steuerung meldet ihm, dass ein altersbeschränktes Produkt gewählt wurde, und wartet auf die Freigabe.
Wie wir am Bus hängen
Zwischen unserem Gerät und dem Bus sitzt eine MDB-Schnittstelle, die die harte 5-ms-Taktung hält und die Abfragen der Steuerung aus ihrem eigenen Speicher beantwortet. Unsere Software arbeitet eine Ebene darüber, auf der Ebene von Vorgängen wie „Verkauf angefragt“ oder „Alter geprüft“. Das ist Architektur, nicht Bequemlichkeit: Ein Kaufvorgang verträgt Sekunden, eine einzelne Busantwort nicht – also trennen wir die beiden Zeitskalen sauber.
Am Bus meldet sich unser Gerät in zwei Rollen gleichzeitig an:
- als AVD – das Altersprüfgerät, das die Steuerung nach jeder Wahl eines altersbeschränkten Produkts fragt;
- als bargeldloses Zahlungsgerät (Cashless) – so kann es einen Verkauf selbst auslösen, etwa wenn ein Kunde eine Click-&-Collect-Bestellung abholt. Der Automat glaubt, jemand habe bezahlt; in Wahrheit hat er das längst – online.
Bis zu drei Rollen gleichzeitig, auf demselben Gerät – mehr braucht kein Automat, den wir kennen.
Zwei Plattformen, ein Protokoll
Unsere MDB-Geräte laufen auf zwei völlig verschiedenen Plattformen: auf Android, im Automaten mit Kamera und Chip-Leser, und auf dem Raspberry Pi. Im Feld arbeiten sie auf dem Pi 4 genauso wie auf dem Pi Zero 2 W – einem Rechner kaum größer als ein Kaugummistreifen. Ein Protokoll, zwei Welten – beide sprechen MDB direkt mit dem Automaten.
Die Anmeldung am Automaten
Jedes Gerät durchläuft beim Start dieselbe Abfolge: Die Steuerung schickt RESET, fragt die Konfiguration ab (SETUP), lässt sich die Geräte-Kennung geben (EXPANSION ID) und schaltet das Gerät frei. Erst dann beginnt die normale Abfrage-Schleife. Auf dem Papier ist das einfach. In der Praxis hat jeder Automatenhersteller seine eigene Lesart.
Automaten, mit denen wir laufen
| Ort | Steuerung | Was wir gelernt haben |
|---|---|---|
| Labor Wien | SandenVendo | Will nach RESET ausdrücklich ein „JUST RESET“ und die volle Geräte-Kennung – sonst hängt sie in einer Neustart-Schleife. Fernverkauf über den Bus erst ab Firmware 2.60. |
| Wien 1190, 1040 | TCN | Genau umgekehrt: kein „JUST RESET“, sonst startet sie das Gerät alle ein bis zwei Minuten neu. Und: Bei offener Tür fragt sie den Bus gar nicht ab. |
| Labor Wien | Vendon-Telemetrie | Die Telemetrie-Box ist selbst eine kleine Steuerung am Bus. Fernverkäufe laufen nur über die erste Cashless-Adresse. |
Die offene Tür hat uns in 1040 Stunden gekostet: Unser Gerät sah die Schnittstelle, die Schnittstelle antwortete brav, aber vom Automaten kam nichts. Wir hatten die Verkabelung im Verdacht. Es war die Tür. So etwas steht in keiner Spezifikation, und genau deshalb schreiben wir jede dieser Eigenheiten in eigene Befund-Dokumente pro Automatentyp.
Die Telemetrie-Box haben wir im März eine Woche lang am Bus belauscht: acht Teilversuche, Fernverkauf, Fehlermeldungen, Stromausfall. Ergebnis unter anderem: Nach einem Stromausfall findet sich alles von selbst wieder.
Wir hören alles mit
Neben den Rollen kann ein Mitlese-Modus laufen: Dann sehen wir jede Nachricht auf dem Bus, auch die, die gar nicht an uns gerichtet ist. Für die Werkbank haben wir uns dazu ein eigenes Testwerkzeug gebaut, das jede Rolle einzeln simuliert. Daraus entstehen drei Dinge:
- Eine Busanzeige: Wird unser Gerät abgefragt? Hängt der Automat in einer Neustart-Schleife? Die App zeigt den Zustand der USB-Verbindung und die aktive Rolle getrennt an.
- Eine Ablaufspur: Anmeldung, Verkaufsanfrage, Altersfreigabe, Verkaufsergebnis – mit Zeitstempel, damit wir bei einer Reklamation nachvollziehen können, was der Automat wirklich getan hat.
- Eine Selbstheilung: Fällt die Verbindung weg, etwa weil der Automat kurz stromlos war, baut die App sie selbst wieder auf. Getestet haben wir das mit drei Stromunterbrechungen hintereinander.
Persönliche Daten laufen dabei nicht über den Bus. Der Automat erfährt von uns nur „freigegeben“ oder „nicht freigegeben“ – kein Name, kein Geburtsdatum, kein Bild.
Warum der Aufwand
Man könnte eine Altersprüfung auch als Gerät neben den Automaten stellen und hoffen, dass niemand daran vorbeikauft. Am Bus geht das nicht: Ist das AVD in der Steuerung aktiviert, wartet sie bei altersbeschränkten Produkten auf seine Freigabe und gibt ohne sie nichts aus. Die Prüfung ist dann kein Hinweisschild, sondern Teil des Verkaufs.
Dafür muss man die Sprache des Automaten sprechen – inklusive seiner Dialekte. Wir sprechen sie: mit eigenem Protokoll-Stack, auf zwei Plattformen, gelernt Automat für Automat.