Fachbeitrag Verkaufsautomaten einfacher bauen

SECO Northern Europe GmbH

Bild: Garz & Fricke
13.06.2014

Wer heute einen Verkaufsautomaten entwickelt, sieht sich einigen Herausforderungen gegenüber gestellt. Er wird bestrebt sein, einen kundenfreundlichen Automaten zu gestalten, der so viele Zahlungsmittel wie möglich akzeptiert, komfortabel und intuitiv zu bedienen ist. Dabei helfen können auf dem Markt erhältliche Embedded-Human-Machine-Interface-Systeme, insbesondere solche mit integrierter Multi-Drop-Bus-Schnittstelle.

Sponsored Content

Allen Verkaufsautomaten gemeinsam ist, dass Ware gegen Bezahlung automatisch ausgegeben wird. Früher erfolgte die Benutzerführung über am Automaten angebrachte Aufkleber, später wurden diese ergänzt um ein numerisches Display für die Anzeige des aktuellen Kredits. Heute erfolgt bei Bestandsautomaten die Benutzerführung in der Regel über alphanumerische Displays. Für die Steuerung des Verkaufsablaufs – Warenauswahl, Bezahlung und Warenausgabe – kommen in der Regel Boards mit kleinen kostengünstigen Mikrocontrollern ohne Betriebssystem zum Einsatz.

Bei Neu- und Weiterentwicklungen wird versucht, durch den Einsatz neuster Technologien den Automaten für Kunden interessanter zu machen und um schlussendlich mehr Umsatz zu erzielen. Die Tendenz ist deshalb stark dahingehend, Geräte mit einem grafischen Farbdisplay in Kombination mit einem Touchpad auszustatten – vorzugsweise mit einem fertig aufgebauten Human-Machine-Interface(HMI)-System mit Display, Touch, Rechner, Betriebssystem und Gehäuse. Auf solchen Einheiten lässt sich mit einfachen Mitteln eine moderne intuitive Bedienerführung realisieren.

HMI-System integrieren

Wie aber wird nun so ein HMI-System in einen Verkaufsautomaten integriert. Der derzeit wohl am häufigsten verwendete Ansatz ist, das HMI-System als reinen Ersatz für Tastatur und alphanumerisches Display zu verwenden. Es wird eine Schnittstelle mit einem proprietären Kommunikationsprotokoll definiert. Dieses wird dann sowohl auf dem Controllerboard als auch auf dem HMI-System umgesetzt. Die Warenausgabe, die Unterstützung der Bezahlsysteme sowie die Steuerung des Verkaufsablaufs erfolgt dann nach wie vor auf dem Controllerboard. Sofern schon Erfahrungen in der Realisierung von Verkaufsautomaten vorliegen und Controllerboards mit Software für die Unterstützung von Warenausgabe und Bezahlsystemen existieren, führt dieser Ansatz in der Regel auch am schnellsten zu einem Ergebnis. Diesem Ansatz folgend, bleibt allerdings sehr viel Rechenleistung ungenutzt, die ein HMI-System heute üblicherweise mitbringt.

Folglich stellt sich also die Frage, warum dem HMI-System nicht noch mehr Aufgaben zugeordnet werden – zum Beispiel die Unterstützung der Bezahlsysteme. Auf dem Markt sind eine Vielzahl von Bezahlsystemen wie Münzwechsler, Banknotenleser und Kartenzahlungssysteme erhältlich, die mit einer MDB-Schnittstelle ausgestattet sind. MDB ist die Abkürzung für den Multi-Drop-Bus. Standardisiert wird MDB durch die NAMA (National Automatic Merchandising Association).

MDB-Schnittstelle

Vor diesem Hintergrund ist die Idee entstanden, Systeme mit Touch-Display und MDB-Schnittstelle zu entwickeln. Der MDB funktioniert nach dem Master-Slave-Prinzip. Die Bezahlsysteme sind dabei als Slave ausgeführt und die Automatensteuerung, in diesem Fall dann das HMI, ist als Master ausgelegt. Die Kommunikation zwischen den Geräten erfolgt bitweise seriell über eine Master-Sende- und eine Master-Empfangsleitung. Die Kommunikationsleitungen sind auf der Slave-Seite mittels Optokoppler galvanisch voneinander getrennt. Der Master muss beim Senden die LED des Optokopplers eines Slaves mit dem notwendigen Strom versorgen. Zu beachten ist hier, dass laut Spezifikation bis zu 32 Slaves angeschlossen werden dürfen, die auch alle gleichzeitig Daten empfangen möchten. Auf der Seite des Masters erfolgt der Empfang dagegen nach dem Open-Collector-Prinzip. Im ersten Schritt muss so ein HMI-System also um einen entsprechenden Konverter erweitert werden, der aus einer einfachen seriellen Schnittstelle physikalisch einen MDB-Master macht.

Im zweiten Schritt muss dann die Software, respektive das Betriebssystem des HMI-Systems um die MDB-Funktionalität erweitert werden. Diese teilt sich in zwei Bereiche auf. Zum einen gibt es den allgemeinen Teil, der die grundsätzliche Kommunikation zwischen dem Master und einem beliebigen Slave bereitstellt, den sogenannten MDB-Low-Level-Treiber. Dieser Teil ist ganz unten im Betriebssystem verankert und spricht direkt den UART (Universal Asynchronous Receiver Transmitter) des HMI-Systems an. Nachrichten, die an die Slaves verschickt werden sollen, werden mit einem Adressbyte versehen und es wird eine Checksumme hinzugefügt. Beim Versenden der so erstellten vollständigen Nachricht über den UART wird dann noch ein neuntes Bit, das Mode-Bit, hinzugefügt. Über dieses Bit wird unterschieden, ob es sich um ein Adressbyte oder ein Datenbyte handelt. Nach dem Versand der Nachricht wartet der MDB-Low-Level-Treiber auf eine Antwort von dem adressierten Slave. Beim Empfang von Nachrichten wird über das Mode-Bit erkannt, ob es sich um das letzte Byte einer Nachricht handelt. Ist das der Fall wird die Checksumme der Nachricht überprüft und die Nachricht an die höheren Softwareschichten weitergeleitet.

Über ein so genanntes Acknowledge wird der Slave darüber informiert, dass die Nachricht erfolgreich eingegangen ist. Auch eine entsprechende Fehlerbehandlung ist implementiert. Ist zum Beispiel die Checksumme der eingegangenen Nachricht fehlerhaft, so wird dies den höheren Softwareschichten ebenfalls mitgeteilt und es wird ein negatives Acknowledge an den Slave geschickt. Unvollständige Nachrichten werden über Timeouts erkannt und behandelt.

Der MDB-Manager

Der zweite Bereich der softwareseitigen MDB-Unterstützung steht in Form einer Funktionsbibliothek zur Verfügung, die ebenfalls Teil des Betriebssystems ist. Diese Funktionsbibliothek wird im Folgenden auch MDB-Manager genannt. Dieser ist umfangreicher ausgelegt als der MDB-Low-Level-Treiber. Die MDB-Spezifikation unterscheidet zwischen verschiedenen Typen von Slaves, auch Peripheriegeräte genannt. Beispiele für unterschiedliche Typen von Peripheriegeräten sind Münzwechsler, Banknotenleser, Kartenzahlungssystem, Communication Gateway und andere. Jedes Peripheriegerät hat seinen eigenen Kommando/Nachrichten-Satz. Für ein HMI-System mit Unterstützung für Bezahlsysteme genügt aber in der Regel die Unterstützung von Münzwechsler, Banknotenleser und Kartenzahlungssystem. Diese Systeme werden durch den MDB-Manager dann auch entsprechend berücksichtigt.

Einmal gestartet und parametrisiert, kümmert sich die MDB-Funktionsbibliothek um die Initialisierung der Peripheriegeräte, das Polling und die Auswertung der empfangenen Nachrichten. Die darüber liegende Anwendung steuert die MDB-Kommunikation über Funktionsaufrufe, ohne die MDB-Spezifikation im Detail kennen zu müssen. Die Anwendung erhält Informationen darüber, welche Gerätetypen am MDB-Bus angeschlossen sind. Auch Informationen über Hersteller, Hardware- und Softwareversion werden bereitgestellt. Peripheriegeräte, die zur Laufzeit an den MDB-Bus angeschlossen werden, werden erkannt und das Gerät wird automatisch initialisiert. Die Informationen, die der MDB-Manager über die Auswertung der von den Peripheriegeräten erhaltenen Nachrichten sammelt, werden über eine Softwareschnittstelle (API) zur Verfügung gestellt. Wird etwa eine Münze eingeworfen, dann erkennt dies der Münzwechsler. Dieser prüft die Münze auf Echtheit und Wert und teilt das Ergebnis dem MDB-Master mit – hier das HMI-System mit MDB-Manager. Der MDB-Manager inkrementiert den aktuellen Kredit. Die Anwendung kann in einfacher Weise abfragen, wie viel Kredit sich im System aktuell befindet und auch, aus welchen Teilbeträgen er sich zusammensetzt, also wie viel davon über Münzen oder Banknoten zugeführt wurde oder ob sich zum Beispiel auch eine Karte mit Guthaben im Kartenzahlungssystem befindet. Über die API besteht dann auch die Möglichkeit, einen Kredit, der sich im System befindet, wieder vollständig auszuzahlen oder einen Teil zu kassieren und nur den Rest auszuzahlen. Die Anwendung ruft dazu entsprechende API-Funktionen auf und der MDB-Manager kümmert sich um die dafür notwendige MDB-Kommunikation. Soll eine Zahlung über Karte abgewickelt werden, wird auch diese über die API angestoßen. Über den Ausgang der Zahlung wird die Anwendung entsprechend informiert.

Verkaufsautomaten einfacher entwickeln

Ein HMI-System mit MDB-Schnittstelle und einem entsprechend im Betriebssystem verankerten MDB-Manager bietet dem Hersteller von Verkaufsautomaten viel Flexibilität. Der Leistungsumfang von bisherigen eingesetzten Controllerboards kann reduziert werden, sie können gegebenenfalls vollständig entfallen, wenn auch die Ansteuerung der Warenausgabe über das HMI-System realisiert wird. Den Herstellern, die neu in dem Bereich Verkaufsautomaten agieren, wird es mit einem solchen System einfacher gemacht, einen Verkaufsautomaten serienreif zu entwickeln. Zumindest Spezialkenntnisse über die Protokolle der einzelnen Bezahlsysteme sind damit nicht mehr notwendig.

Bildergalerie

  • Abbildung 1: Schematischer Aufbau eines Verkaufsautomaten mit HMI-System

    Abbildung 1: Schematischer Aufbau eines Verkaufsautomaten mit HMI-System

    Bild: Garz & Fricke

  • Abbildung 2: HMI-System mit Unterstützung des Multi-Drop-Bus (MDB)

    Abbildung 2: HMI-System mit Unterstützung des Multi-Drop-Bus (MDB)

    Bild: Garz & Fricke

Firmen zu diesem Artikel
Verwandte Artikel