Geräte­kennzeichnung: Mit QR-Code und Data-Matrix-Code zum richtigen Prozesskontext

Was der Code am Gerät identifiziert

Ein QR-Code oder Data-Matrix-Code kann eine betriebsinterne Kennung tragen. Entscheidend ist deren Bezug: Eine Typkennung bezeichnet eine Geräteart, eine Einzelgerätekennung ein bestimmtes Exemplar. Bei Materialien ist entsprechend zwischen Materialart, Charge und Einzelgebinde zu unterscheiden. Beim GS1 DataMatrix folgt der Inhalt den Regeln des GS1-Systems; auch hier muss die Anwendung die Datenstruktur auswerten, um die Identifikationsebene zu erkennen.^[1][2]

Für einzelne Betriebsmittel sieht GS1 den Global Individual Asset Identifier (GIAI) vor. Der Global Returnable Asset Identifier (GRAI) kann bei wiederverwendbaren Betriebsmitteln eine Typkennung mit einer optionalen Serienkomponente verbinden.^[2] Eine interne Gerätekennung ist dadurch nicht automatisch ein GS1-Schlüssel; eine allgemeine Pflicht zur GS1-Nutzung folgt daraus nicht.

Vor der Zuordnung steht die Frage, was die Kennung überhaupt bezeichnet. Bei Handelsartikeln unterscheidet die GTIN die Artikelart; die zusätzliche Chargen- oder Losnummer ordnet sie einer entsprechenden Gruppe zu. Erst GTIN und Seriennummer zusammen identifizieren im hier betrachteten Modell ein einzelnes Exemplar. AI 21 ist daher nicht für sich allein eine weltweit eindeutige Objektkennung.^[2]

Zwei Gebinde derselben Artikelart und Charge können denselben codierten Inhalt tragen, wenn keine unterscheidenden Daten hinzukommen. Der Scan dieses Inhalts verrät dann nicht, welches der beiden Gebinde vor dem Leser steht. Wer einzelne Gebinde unterscheiden muss, benötigt eine dafür geeignete Identifikation.^[2]

Von der Kennzeichnung zum Prozesskontext

Für den Informationszugriff sind zwei Wege zu unterscheiden: Enthält der Code eine Kennung, benötigt die lesende Anwendung eine Zuordnung zu dem bezeichneten Objekt und den hinterlegten Informationen. Enthält er eine URL, kann eine dafür geeignete Scan-Anwendung die Adresse erkennen und den Aufruf anbieten. Die URL kann auf eine objektspezifische Seite führen, aber auch auf eine allgemeine Einstiegsseite.^[4][5]

Auf dem Gerätefoto steht beispielhaft die Adresse https://portal.420-plus.com/devices/DEV-042. Die Kennung DEV-042 im Pfad bezeichnet im Beispiel ein einzelnes Gerät. Eine entsprechend eingerichtete Anwendung kann darüber die zugehörigen Informationen bereitstellen. Welche Informationen oder Arbeitsschritte verfügbar sind, legt die Anwendung fest. Die Adresse ist ein fiktives Beispiel.

Die Identität eines Objekts und die Informationen darüber lassen sich getrennt verwalten. Der GS1-Resolver-Standard beschreibt, wie eine GS1-Identität mit Informationsangeboten wie einer Anleitung verbunden werden kann. Ein solcher Resolver ist eine mögliche Architektur; auch eine GS1-Digital-Link-Adresse muss nicht auf einen GS1-konformen Resolver zeigen.^[5][6]

Für die Prozessarchitektur lässt sich daraus eine Prüffolge ableiten: Zuerst wird die Kennung gelesen und ihre Datenstruktur ausgewertet. Danach wird das bezeichnete Objekt oder Los mit dem erwarteten Kontext verglichen. Erst die fachliche Regel legt fest, welche Handlung daraus folgt und welches Ergebnis dokumentiert wird. Diese Prüffolge ist eine architektonische Ableitung, keine allgemeine GS1-Vorschrift.^[1][2]

Für einen Gerätearbeitsplatz könnte die Anwendung beispielsweise die Einzelgerätekennung zusammen mit dem Auftrag und der Rolle des Mitarbeiters auswerten, bevor sie einen Arbeitsschritt anbietet. Das ist ein Architekturbeispiel, keine zugesicherte Produktfunktion: Das Abrufen einer Anleitung und die Entscheidung, ob ein Arbeitsschritt im konkreten Fall zulässig ist, bleiben unterschiedliche Aufgaben.

QR-Code oder Data Matrix: Was passt zum Einsatz?

Beide gehören zu den zweidimensionalen Codes. Ein QR-Code ist jedoch keine Unterart von Data Matrix. Unterschiede betreffen unter anderem das Suchmuster und die Fehlerkorrektur. Für den Einsatz zählt außerdem, welche Datenstruktur und welche Lesegeräte die Anwendung unterstützt.^[2][4]

Für einen Betrieb beginnt die Auswahl daher mit der Anwendung: Welche Informationen müssen gelesen werden? Welche Datenstruktur erwartet das Zielsystem? Welche Kennzeichnung ist auf dem Objekt möglich und unter den tatsächlichen Bedingungen lesbar? Eine pauschale Rangfolge der beiden Codearten beantwortet diese Fragen nicht.

Data-Matrix-Code: Aufbau, Größe und Lesbarkeit

Data Matrix ist eine Codeart, mit der Daten auf einer quadratischen oder rechteckigen Fläche dargestellt werden. Anders als bei einem linearen Strichcode nutzt die Anordnung beide Dimensionen. Die Variante ECC200 verwendet eine Fehlerkorrektur nach Reed-Solomon, die bestimmte Fehler in den erfassten Daten ausgleichen kann.^[2]

Ein L-förmiges, durchgehend dunkles Suchmuster hilft dem Leser, das Symbol zu lokalisieren und seine Orientierung zu bestimmen. An den gegenüberliegenden Seiten wechseln helle und dunkle Module. Innerhalb dieser Begrenzung liegt der codierte Datenbereich. Bei GS1 DataMatrix muss außerdem auf jeder Seite eine freie Ruhezone von einem Modul Breite bestehen.^[1][2]

Bei der Größenfrage sind zwei Dinge zu unterscheiden: die Anzahl der Module und ihre physische Größe. Wie viele Module benötigt werden, hängt von den zu codierenden Daten und ihrer Codierung ab. Die Modulgröße, auch X-Dimension genannt, richtet sich bei GS1-Anwendungen nach der jeweiligen Anwendungsvorgabe. Eine allgemein gültige Mindestgröße in Millimetern wäre deshalb irreführend.^[1][2]

Das hat eine praktische Konsequenz: Zusätzliche Daten können mehr Module erfordern. Werden diese auf dieselbe verfügbare Fläche gedrängt, werden die einzelnen Module kleiner. Bei der Planung müssen deshalb Datenumfang, Kennzeichnungsfläche, Herstellungsverfahren und Lesebedingungen zusammenpassen. Die Ruhezone gehört zum benötigten Platz.^[1][2]

Fehlerkorrektur ist dabei keine Garantie für beliebige Beschädigungen. Die GS1-Spezifikation beschreibt die Korrekturmöglichkeiten je Symbolgröße anhand von Codewörtern. Daraus lässt sich keine allgemeine Zusage ableiten, ein festgelegter Prozentsatz der sichtbaren Codefläche dürfe fehlen.^[2]

Codes lesen und ihre Qualität prüfen

GS1 unterscheidet beim Scannen die Aufnahme des Symbols und die Decodierung des aufgenommenen Bildes. Die gewonnenen Daten werden anschließend zur weiteren Verarbeitung an ein Informationssystem übergeben. Für GS1 DataMatrix kommen bildbasierte Leser oder entsprechende Kamerasysteme zum Einsatz.^[1][2]

Die Symbolverifikation erfüllt eine andere Aufgabe: Sie bewertet die Qualität des Symbols nach festgelegten Kriterien. Ein erfolgreicher Scan und ein Verifikationsergebnis sind daher unterschiedliche Aussagen. In ihren Hinweisen zur Interpretation von Verifikationsergebnissen stellen die GS1 General Specifications ausdrücklich klar, dass die Richtigkeit des Dateninhalts ohne zusätzliche Software mit Datenbankanbindung nicht bestätigt werden kann. Eine solche Anbindung allein garantiert die Richtigkeit allerdings ebenfalls nicht.^[2]

Ebenso muss geprüft werden, ob Klarschrift und Codeinhalt übereinstimmen. Ein fiktives Beispiel: Auf einem Etikett steht Charge CH-50, während der Code CH-56 enthält. Die Prüfung der Symbolqualität allein klärt diesen Widerspruch nicht. Ein Gesamtsystem kann dafür zusätzliche Prüfungen vorsehen; diese sind von der Symbolverifikation zu unterscheiden.^[2]

Auch ein bei der Herstellung einwandfreies Symbol kann auf dem weiteren Weg beschädigt werden. Eine Stichprobe bestätigt zudem nicht automatisch die Qualität jedes Symbols einer Produktionscharge. Für den Betrieb folgt daraus: Kennzeichnung und Erfassung sollten unter den tatsächlichen Einsatzbedingungen geprüft werden, einschließlich der Fälle, in denen kein verwertbarer Inhalt gelesen wird.^[2]

Was GS1 DataMatrix und GS1 Digital Link ergänzen

GS1 DataMatrix verbindet die Codeart mit einer standardisierten Datenstruktur. Application Identifiers, kurz AIs, geben an, welche Bedeutung die folgenden Daten haben. So steht AI 01 für die GTIN, AI 10 für eine Chargen- oder Losnummer und AI 21 für eine Seriennummer.^[1][2]

Das Steuerzeichen FNC1 an erster Position kennzeichnet die GS1-Verwendung. Bei bestimmten aufeinanderfolgenden Datenfeldern sind zusätzlich Trennzeichen erforderlich. Die Klammern, mit denen AIs in der Klarschrift dargestellt werden, gehören dagegen nicht zu den codierten Daten. Diese Regeln helfen der Software, die Felder richtig auszuwerten; sie belegen keine Echtheit des gekennzeichneten Objekts.^[1][2]

GS1 DataMatrix und Data Matrix mit GS1 Digital Link sind ebenfalls zu unterscheiden. Ersterer verwendet GS1-Elementstrings. Digital Link stellt Identifikationsdaten in einer webkompatiblen URI-Struktur dar, die sowohl in einem Data-Matrix- als auch in einem QR-Code enthalten sein kann. Welche Variante verarbeitet werden kann, muss zur Anwendung passen.^[4]

Nicht jede Webadresse ist damit ein GS1 Digital Link. Dafür muss sie der festgelegten URI-Syntax mit GS1-Identifikationsdaten entsprechen. Eine gewöhnliche Portaladresse ohne diese Struktur wird durch das Einbetten in einen Data-Matrix-Code nicht zu einem GS1 Digital Link.^[5]

Wenn die Zuordnung nicht passt

Ein fiktiver Gerätefall: Zwei baugleiche Geräte tragen jeweils einen Code mit derselben internen Typkennung TYP-08. Für eine allgemeine Bedienungsanleitung kann diese Unterscheidungstiefe genügen. Soll ein Arbeitsschritt dagegen einem bestimmten Gerät zugeordnet werden, reicht der Codeinhalt allein nicht aus: Er unterscheidet die beiden Exemplare nicht. Dafür braucht der Ablauf eine Einzelgeräteidentifikation oder eine zusätzliche eindeutige Zuordnung.

Das folgende Beispiel verwendet ausschließlich fiktive interne Kennungen, keine GS1-Schlüssel. Ein Arbeitsschritt erwartet die Materialart MAT-17. Gelesen wird MAT-19. Der Code wurde erfolgreich decodiert, doch das erkannte Material passt nicht zur Vorgabe. Für diesen Beispielprozess lautet die Regel: Die Materialzuordnung bleibt offen, bis die Abweichung geklärt und die Entscheidung dokumentiert ist. Das ist eine gewählte Prozessregel, keine Funktion, die der Code mitbringt.

Ein zweiter Fall zeigt die Bedeutung der Identifikationstiefe. Zwei Gebinde von MAT-17 gehören zur Charge CH-42. Enthalten ihre Codes nur diese Material- und Chargenkennung, können zwei gleiche Scanergebnisse sowohl zwei Gebinde als auch das zweimalige Lesen desselben Gebindes bedeuten. Aus den Codeinhalten allein lässt sich das nicht entscheiden.

Selbst bei einer eindeutigen Einzelobjektkennung bleibt der Prozesskontext entscheidend: Dasselbe Gebinde kann zuerst im Wareneingang und später bei der Bereitstellung korrekt erneut gelesen werden. Eine Wiederholung am selben Arbeitsschritt kann dagegen eine unbeabsichtigte Doppelbuchung auslösen, wenn jede Erfassung ungeprüft als neuer Vorgang behandelt wird. Die Anwendung braucht deshalb eine Regel, die zur Handlung und zur erwarteten Menge passt; identische Kennungen pauschal zu verwerfen wäre ebenso unzureichend.

Das Ereignismodell EPCIS macht die Trennung von Identifikation und Kontext anschaulich: Es unterscheidet unter anderem Einzelobjekte und Mengen auf Klassenebene und ergänzt Angaben zu Zeit, Ort und Geschäftsschritt. Dabei bezeichnet eventTime den Zeitpunkt, zu dem das Ereignis laut erfassender Anwendung stattgefunden hat; recordTime betrifft die Erfassung im Repository. Auch diese Zeitangaben sind keine aus dem Code selbst gewonnenen Beweise für die physische Ausführung. EPCIS dient hier als Beispiel für die Ebenentrennung, nicht als Voraussetzung für den Einsatz von Data Matrix.^[3]

Vor der Einführung sollte für jeden Erfassungspunkt feststehen: Welche Ebene wird identifiziert, welche Information oder Handlung wird benötigt und was geschieht bei einem unpassenden oder wiederholten Scan? Davon hängen Codeinhalt, Leser und Zuordnung im System ab. Eine allgemeine Portaladresse kann ein Einstieg sein. Den richtigen Prozesskontext liefert sie erst zusammen mit der dafür vorgesehenen Zuordnung und den fachlichen Regeln.