Kompatibilität auf fünf Ebenen prüfen
Beschreiben Sie zunächst die Aufgabe, etwa die Prüfung eines Bekleidungsbestands mit einem vorhandenen Handheld-Lesegerät oder das Öffnen eines Produktlinks auf dem vorgesehenen Smartphone. Prüfen Sie danach die folgenden fünf Ebenen getrennt, damit die Funkerkennung eines Tags nicht mit der Abnahme des gesamten Projekts gleichgesetzt wird.
- Frequenzbereich und Einsatzregion: Eignen sich die regionale Geräteversion und Konfiguration für den Projektstandort?
- Luftschnittstellenprotokoll: Unterstützen Lesegerät und Tag dasselbe für die Aufgabe benötigte Kommunikationsprotokoll?
- Funktionen und Speicher: Werden die erforderlichen Lese-, Schreib- und Prüfvorgänge sowie die zugehörigen Befehle unterstützt?
- Datenformat: Entspricht die Ausgabe den festgelegten Kennungen, Inhalten und Codierungsregeln?
- Software und Geschäftsablauf: Kann die Anwendung die Daten dem richtigen Objekt zuordnen und die gewünschte Aktion ausführen?
Mit genauen Angaben zu den vorhandenen Geräten beginnen
Dokumentieren Sie die vollständige Modellbezeichnung, regionale Version, Firmware, Antenne und Verbindungsart des Lesegeräts sowie die Versionen von Anwendung, Betriebssystem und SDK. Ein verkürzter Modellname, das Aussehen oder die Angabe „unterstützt RFID“ ersetzt keine Gerätedokumentation. Erfassen Sie außerdem das Tag-Protokoll, die Chip-Unterlagen und die benötigten Funktionen. Lassen Sie diese Angaben jeweils vom Geräte- und Tag-Lieferanten bestätigen.
NFC arbeitet mit 13,56 MHz. Daraus folgt jedoch nicht, dass jeder HF-Tag mit derselben Frequenz für das vorgesehene Smartphone geeignet ist. Prüfen Sie die konkrete Tag-Technologie, das Datenformat und die Unterstützung durch die Anwendung. Bei UHF-Projekten sind die Protokolle von Gerät und Tag sowie die regionale Gerätekonfiguration für das Einsatzland zu prüfen. Derselbe Frequenzbereich oder dieselben Leistungseinstellungen können nicht für jede Region vorausgesetzt werden.
- Bestätigte Angaben: Speichern Sie das Datenblatt und Gerätehandbuch für das genaue Modell einschließlich der Versionsdaten.
- Noch offene Angaben: Kennzeichnen Sie diese als „noch zu bestätigen“ und nennen Sie Gerätemodell und Anforderungen an den Geschäftsablauf, statt Kompatibilität anzunehmen.
Lesen, Schreiben und Datenbedeutung getrennt abnehmen
Die Einhaltung eines Protokollstandards bedeutet nicht, dass alle optionalen Befehle implementiert sind. Wenn das Projekt Schreibzugriff, Zugriff auf einen bestimmten Speicherbereich oder eine Sperrfunktion erfordert, prüfen Sie die Unterstützung durch Lesegerät, Tag und Software für jede Anforderung einzeln. Die Erkennung eines Tags bestätigt diese Funktionen nicht.
Prüfen Sie bei Smartphone-Anwendungen den benötigten NDEF-Inhalt und die Seite oder Anwendung, die auf dem vorgesehenen Telefon tatsächlich geöffnet wird. Bei UHF sind die vom System benötigten EPC- oder anderen Daten, das Codierungsschema und die Zuordnung zu den Objekten zu prüfen. Kommunikationsprotokoll und Datenformat sind getrennte Prüfpunkte. Ein Screenshot mit der Meldung „Tag gelesen“ reicht nicht aus.
- Erwartete Daten: Dokumentieren Sie für den Geschäftsablauf freigegebene Testkennungen oder Inhaltsbeispiele und die Formatvorgaben.
- Tatsächliche Daten: Dokumentieren Sie den ausgelesenen Speicherbereich, die Rohdaten und Prüfergebnisse. Prüfen Sie anschließend die Zuordnung zum richtigen Objekt.
- Erwartete Aktion: Prüfen Sie den vollständigen vom Projekt geforderten Vorgang, etwa eine Bestandsaktualisierung oder das Öffnen einer Seite.
Den Ablauf mit Mustern am tatsächlichen Objekt prüfen
Prüfen Sie zunächst ein einzelnes Muster in einem klar abgegrenzten Testbereich. Testen Sie danach je nach tatsächlicher Aufgabe hängende, gefaltete, verpackte oder gestapelte Artikel sowie benachbarte Objekte. Dokumentieren Sie Montagematerial, Position, Ausrichtung, Leseposition und Geräteeinstellungen, damit sich der nächste Test reproduzieren lässt.
GS1 TIPP betrachtet die Leistung des mit einem Tag versehenen Objekts. Auch Beschaffungstests vor Ort sollten den Tag am tatsächlichen Objekt bewerten. Die folgenden Empfehlungen zur Projektdokumentation sind kein TIPP-Labortestverfahren. Musteranzahl, Testdurchläufe und Abnahmeschwellen müssen von beiden Projektparteien vereinbart werden.
- Muster: Kennung, Version, Chip- oder Protokollunterlagen, Montagematerial und Position.
- Geräte: Lesegerät, Firmware, Antenne, regionale Konfiguration sowie Anwendungs- und Betriebssystemversionen.
- Ablauf: Zielbereich, Leseposition, Ausrichtung, Objektanordnung, Testdurchläufe und Schritte.
- Ergebnisse: Erwartete und tatsächliche Daten, Aktionen im Geschäftsablauf, nicht erfasste Tags, Lesungen außerhalb des Zielbereichs und Fehlerbehandlung.
Anhand des Fehlers die nächsten Prüfschritte bestimmen
Die folgenden Punkte geben Hinweise zur Fehlersuche, keine eindeutige Ursachenbestimmung. Ändern Sie jeweils nur eine dokumentierte Bedingung und wiederholen Sie denselben Ablauf. Geben Sie das Problem zusammen mit den ursprünglichen Ergebnissen an den Geräte- oder Tag-Lieferanten weiter.
- Keine Lesung möglich: Technologie, Protokoll, regionale Geräteeinstellungen, Gerätestatus und tatsächliche Montagebedingungen prüfen.
- Tag erkannt, aber Inhalt stimmt nicht: Ausgelesenen Speicherbereich, geschriebenen Inhalt, Datenformat und Objektzuordnung prüfen.
- Daten korrekt, aber keine Aktion in der Anwendung: Verbindung, Anwendungskonfiguration, Schnittstellenverarbeitung und Geschäftsdatensätze prüfen.
- Gelegentlich nicht erfasste Tags oder Lesungen außerhalb des Zielbereichs: Tag-Position, Objektanordnung, Antenne, Lesebereich und Bedienablauf prüfen.
Bestätigte Ergebnisse als Beschaffungsgrundlage dokumentieren
Speichern Sie die freigegebene Musterversion, Modellunterlagen, Geräteeinstellungen, Druckvorlagen, Codierungsbeispiele, Montageart, Testschritte und Abnahmekriterien. Einkauf, Technik und Lieferanten sollten dieselbe Dokumentation nutzen, damit Tags für die Serienproduktion nicht erneut allein nach ihrem Aussehen ausgewählt werden.
Prüfen Sie nach Änderungen an Chip, Gehäuse, Abmessungen, Montageposition, Gerätefirmware oder Software zunächst die betroffenen Anforderungen und legen Sie dann den Umfang der Wiederholungsprüfung fest. Für eine Angebotsanfrage können Sie Gerätemodell, Einsatzland, Datenbeispiele und Musterprotokoll Ihrer bestehenden Beschaffungscheckliste beifügen. Unbekannte Parameter bleiben als „noch zu bestätigen“ gekennzeichnet.
Quellen
Häufige Fragen
Sind Lesegeräte und Tags mit derselben Frequenz immer kompatibel?
Die Frequenz allein reicht nicht aus. Prüfen Sie das konkrete Kommunikationsprotokoll, die benötigten Funktionen, das Datenformat, die regionale Geräteversion und die Unterstützung durch die Anwendung. Testen Sie anschließend die vollständige Aufgabe mit Mustern unter den vorgesehenen Montagebedingungen.
Warum funktioniert das System trotz gelesener UID oder EPC nicht?
Die Erkennung eines Tags, das Lesen der für den Geschäftsablauf benötigten Daten und die Ausführung einer Systemaktion sind unterschiedliche Schritte. Speichern Sie die tatsächliche Ausgabe und prüfen Sie den ausgelesenen Speicherbereich, das Codierungsformat, die Objektzuordnung und die Verarbeitung in der Anwendung. Eine gelesene Kennung bestätigt keine abgeschlossene Systemintegration.
Reicht die maximale Lesereichweite als Prüfung für die Musterabnahme aus?
Testen Sie die tatsächlichen Montagebedingungen und den vollständigen Geschäftsablauf. Vereinbaren Sie außerdem den gewünschten Lesebereich und die Bewertung nicht erfasster Tags sowie von Lesungen außerhalb dieses Bereichs. Musteranzahl, Testdurchläufe und Abnahmeschwellen richten sich nach dem konkreten Projekt.
Ist nach einem Chipwechsel oder einer Änderung der Gerätefirmware eine Prüfung nötig?
Vergleichen Sie zunächst die Auswirkungen auf Protokolle, Befehle, Daten, Gerätekonfiguration und Anwendung. Prüfen Sie anschließend die betroffenen Bereiche erneut. Speichern Sie die neue Version und Testprotokolle, statt die Kompatibilitätsbewertung der bisherigen Lösung unverändert zu übernehmen.
