Individuelle Produktentwicklung für Automaten, Kioske und Selbstbedienungsgeräte

Neues Gerät entwickeln und vorhandenen Automaten erneuern

Bei einem neuen Produkt können Display, Platine, Netzteil, Motoren und Produktweg gemeinsam geplant werden. Bei der Erneuerung eines vorhandenen Geräts sind Kabelbaum, Sensoren, mechanische Maße und Schnittstellen der beizubehaltenden Einheiten entscheidend. Nach Prüfung technischer Unterlagen und nutzungsberechtigter Anschlüsse werden die Grenzen der neuen Platine festgelegt. Es wird nicht vorausgesetzt, dass jede Funktion eines undokumentierten Terminals oder geschlossener Software zugänglich ist.

Soll eine gemeinsame Steuerungsplatine in unterschiedlichen Modellen verwendet werden, werden variable Motor-, Kanal-, Display- und Softwareoptionen aufgelistet. Modellkonfiguration und Platinenrevision werden verknüpft. Entwicklungskosten werden getrennt von Material- und Montagekosten wiederholter Fertigung bewertet. Sobald feststeht, welche Modelle und Funktionen der erste Prototyp verifiziert, wird das Angebot zu einem prüfbaren Projektumfang statt nur zu einem PCB-Preis.

• Neues OEM-Gerät oder definierter Modernisierungsumfang
• Beizubehaltende mechanische und elektrische Schnittstellen
• Modelloptionen und Fertigungsrevisionen

Produktausgabemechanismus, Motoransteuerung und Ausgabedetektion

Bei Spirale, Förderband, Schublade oder anderer Produktausgabe ändern sich Last und Bewegung. Motortyp, Ansteuerung, Positionsinformation und Blockierverhalten werden gemeinsam mit der Mechanik bewertet. Der Einfluss von Packungsgröße, Gewicht und Oberfläche auf den Durchlauf wird mit realen Mustern erprobt. Das Verfahren zur Erkennung des Produktfalls oder Erreichens des Ausgabepunkts wird nach dem physischen Geräteaufbau gewählt.

Motorbewegung beweist keine Produktausgabe. Wird kein Produkt ausgegeben, werden Wiederholungsversuch, Kanalsperrung oder Servicemeldung nach Betriebsregeln definiert. Fälle, in denen ein wiederholter Befehl kein zweites Produkt ausgeben darf, werden über den Transaktionsdatensatz gesteuert. Auch Verschmutzung, dauerhaft aktiver Zustand oder Verbindungsunterbrechung des Sensors werden getestet. Die Darstellung einer fehlgeschlagenen Ausgabe für Kunde und Betriebsoberfläche gehört zum Softwareumfang.

• Mechanismus- und Kanaltests mit realen Produkten
• Motor-, Positions- und Produktausgabesensoren gemeinsam bewerten
• Verhalten bei Blockierung, Wiederholung und fehlgeschlagener Ausgabe

Touchscreen und Benutzerablauf auf das Gerät abstimmen

Benutzer müssen erkennen, welches Produkt sie gewählt haben, in welcher Phase der Vorgang ist und wo sie das Produkt entnehmen. Die Displaysoftware wird mit Zuständen für Auswahl, Warten, Abbruch, Abschluss und Fehler entwickelt. Ungenutzte oder nicht verfügbare Optionen werden angemessen behandelt. Es wird geplant, dass eine unvollständige Sitzung nicht auf den nächsten Benutzer übertragen wird und persönliche Transaktionsinformationen nicht unnötig auf dem Bildschirm verbleiben.

Displayposition, Blickwinkel, Touchfläche und Abstand zum Entnahmebereich werden gemeinsam mit dem Industriedesign untersucht. Motortests und Einstellungen im Servicemenü werden von der Benutzeroberfläche getrennt. Berechtigungen für Änderungen an Sprache, Inhalten oder Produktliste werden festgelegt. Mit einem Erscheinungsprototyp wird die physische Nutzung bewertet; anschließend wird der integrierte Ablauf mit realer Platine und Mechanik getestet.

Wir verbinden den Zahlungsanbieter korrekt mit dem Produktausgabeablauf

Die Wahl von Zahlungsterminal oder Anbieter wird gemeinsam mit Geschäftsmodell und unterstützter Integration bewertet. VOMRO verbindet Geräteauswahl, Transaktionskennung und Zustände mit dieser Schnittstelle. Zahlungsstart, Bestätigungskanal und die vom Anbieter bei Abbruch oder Erstattung ausgeführten Schritte werden ausdrücklich definiert. Die Zahlungs- und Autorisierungsverantwortung des Anbieters wird getrennt von der Gerätesteuerung behandelt.

Eine ausbleibende Antwort bedeutet nicht zwangsläufig, dass die Transaktion fehlgeschlagen ist. Das Ergebnis wird über eine unterstützte Statusabfrage oder Benachrichtigung verifiziert; ein unklarer Vorgang wird nicht direkt erneut gestartet. Zahlungsfreigabe und physische Ausgabe bleiben getrennt. Konnte das Produkt nicht ausgegeben werden, geht der Datensatz in den mit dem Anbieter vereinbarten Korrekturablauf des Betriebs über. Angestrebt wird ein Umfang, bei dem Karten- oder Kontodaten nicht unnötig in die Gerätesoftware gelangen; die Integrationsabnahme erfolgt mit realem Terminal und Testumgebung.

Ablauf zur Wahrung der Transaktionskonsistenz bei Verbindungs- und Stromausfall

Es wird festgelegt, welche lokalen Funktionen bei Internetausfall weiterlaufen. Offlinezahlungen werden nur unter vom Zahlungsanbieter unterstützten und vom Betrieb akzeptierten Bedingungen bewertet; gleiche Fähigkeiten aller Terminals werden nicht vorausgesetzt. Lokale Auswahl, Zahlungsstatus und Produktausgabe werden getrennt aufgezeichnet. Es wird definiert, wie Geräte- und Serverdatensätze nach Wiederverbindung abgeglichen werden.

Bei Stromausfall während eines Vorgangs wird getestet, wie beim Start der letzte Zustand ermittelt wird. Das Gerät darf einen unklaren Datensatz nicht erneut als neuen Verkauf ausführen. Kann die physische Ausgabe nicht verifiziert werden, erhält der Bediener einen prüfbaren Zustand. Eine wiederholt eintreffende Nachricht darf weder den Bestand doppelt reduzieren noch zwei Produkte ausgeben. Abgleich bedeutet den Vergleich von Zahlungsdatensatz, Ausgabe- und Bestandsereignissen; eine Erfolgsmeldung auf dem Bildschirm allein schließt ihn nicht ab.

Wir entwickeln Bestand, Telemetrie und Serviceoberfläche nach dem Betriebsablauf

Die Beziehungen zwischen Gerät, Kanal, Produkt und Befüllungsdatensatz werden in der Serveranwendung definiert. Erfolgreiche Ausgabe, fehlgeschlagener Versuch und manuelle Bestandsänderung sind getrennte Ereignisse. Es wird festgelegt, wie der Softwarebestand mit physischer Befüllung und Produktausgabe verifiziert wird. Letzte Verbindungszeit, Kanalfehler und notwendige Wartungsinformationen werden entsprechend dem Serviceplan des Betriebs angezeigt.

Es wird verfolgt, auf welchem Gerät, mit welcher Version und wann ferngesendete Einstellungen angewendet wurden. Bediener, Serviceteam und Administrator können unterschiedliche Rechte haben. Ohne Verbindung werden Ereignisse lokal gespeichert und bei Wiederverbindung nach Regeln für Reihenfolge und Dubletten übertragen. Updates und Fernservice werden nach Energie-, Verbindungs- und Wartungsbedingungen des Geräts geplant. Hat der Kunde bereits Software, werden passende Schnittstellen und Datenverantwortung geprüft, ohne eine neue Plattform vorzuschreiben.

Elektronikplatine, Mechanik und der Weg vom Prototyp zur Fertigungsvorbereitung

Motortreiber, Sensoreingänge, Display- und Kommunikationsanschlüsse werden projektspezifisch auf der individuellen PCB angeordnet. Versorgungsschwankungen, Einfluss der Motorlast auf Messung und Kommunikation, Steckverbinderreihenfolge und Servicezugang werden gemeinsam betrachtet. Die Platinenanordnung wird mit Kabine, Mechanismus und Kabelbaum geprüft. Für benötigte Gehäuse und mechanische Teile werden 3D-Prototypen oder geeignete Fertigungsverfahren gewählt.

Pilottests erproben unterschiedliche Produkte, Füllstände, Blockierungen, Unterbrechungen und Wiederanlauf nach Service. Hardware-Revision und Softwareversion werden dokumentiert. Zur Fertigungsvorbereitung werden BOM, Programmier- und Funktionsprüfschritte erstellt. PCB-Musterfertigung und Bestückungsunterstützung erfolgen ausschließlich im Rahmen der von VOMRO entwickelten Kundenprojekte. Ein funktionsfähiges Einzelmuster und die Prüfung jedes gefertigten Geräts sind unterschiedliche Aufgaben; auch die Fertigungsprüfung wird in den Übergabeplan aufgenommen.

Vertraulichkeit, Quellenübergabe und erstes technisches Gespräch

Auf Ihren Wunsch unterzeichnen wir vor dem Austausch von Produktidee und technischen Details eine NDA. Die Arbeit ist für das eigene Gerät und die Marke des Kunden bestimmt. Für die erste Bewertung genügen zunächst Produktart, Mechanismus, Einsatzumgebung, erwartete Fertigungsmenge und vorhandene Hardwareinformationen. Steht der Zahlungsanbieter noch nicht fest, klären wir die erforderlichen Schnittstellenerwartungen im Umfangsgespräch.

Projektspezifische Quellcodes, elektronische Schaltpläne, PCB-Designquellen, mechanische CAD-Dateien und technische Dokumente werden zum Projektabschluss übergeben. Build-/Programmier-, Anschluss-, Datenmodell- und Testinformationen werden in die zu Beginn definierte Übergabeliste aufgenommen. Lizenzbedingungen von Terminals, Werkzeugen und Bibliotheken Dritter werden gesondert erläutert. Die Abnahme wird nicht nur an das Einschalten des Geräts geknüpft, sondern an das Zusammenspiel definierter Auswahl-, Transaktions-, Ausgabe- und Fehlerszenarien.