EPCglobal TDT 1.4 Leitfaden zur RFID-Datenübersetzung

August 18, 2024 1145 Kommentare

Download  EPCglobal Tag Data Translation Standard



EPCglobal TDT 1.4 Datenübersetzungsleitfaden für Anwendungen mit RFID-Standards und Protokollen aus einer klaren Seitenansicht dargestellt.





Was definiert EPCglobal TDT 1.4?

EPCglobal Tag Data Translation 1.4, kurz EPCglobal TDT 1.4, ist ein Standard zur Übersetzung von Electronic Product Code-Daten zwischen verschiedenen Formaten, die in RFID-Tags, Leserinfrastrukturen, Middleware und Unternehmensanwendungen verwendet werden. Der Standard erzeugt keine neuen Produktkennungen, sondern beschreibt, wie bestehende EPC- und GS1-basierte Identifikatoren einheitlich validiert und in maschinenlesbare Formate umgewandelt werden können. Für RFID-Projekte ist dies entscheidend, da dieselbe Objektidentität beispielsweise als Binärwert im Tagspeicher, als Tag-Encoding-URI in einem Low-Level-System, als Pure-Identity-URI in einer Geschäftsanwendung oder als serialisierter Legacy-Code in einer Datenbank auftreten kann.

Der Standard steht in engem Zusammenhang mit den EPC Tag Data Standards, löst jedoch eine andere Aufgabe. TDS beschreibt Bedeutung und Struktur von EPC-Codierungsschemata, während TDT eine strukturierte Methode bereitstellt, mit der Software diese Übersetzungsregeln ausführen kann. Praktisch ermöglicht TDT die Darstellung von Codierungs- und Decodierungslogiken über XML-Strukturen, Felderdefinitionen, Muster, Grammatikregeln, Validierungsanforderungen und Verarbeitungsvorgaben. Dadurch wird verhindert, dass unterschiedliche Systeme denselben EPC-Wert unterschiedlich interpretieren.

Zentrale Rolle bei EPC- und RFID-Datenübersetzungen

EPCglobal TDT 1.4 ist besonders wichtig, wenn Daten über mehrere Ebenen einer RFID-Architektur hinweg übertragen werden müssen. Ein Tag kann aufgrund begrenzter Speicherkapazität eine kompakte Binärdarstellung speichern, die für schnelles Auslesen optimiert ist. Middleware muss diesen Wert möglicherweise in eine URI-Darstellung für Filterung und Ereigniserfassung umwandeln. Eine Geschäftsanwendung benötigt dagegen häufig eine Pure-Identity-URI, da sie keine Informationen über Tag-Länge, Partitionswert oder Filterwert benötigt. In anderen Prozessen müssen serialisierte Legacy-Identifikatoren wie SGTIN, SSCC, SGLN, GRAI, GIAI, GSRN oder GDTI aus EPC-Darstellungen erzeugt oder wieder zurückübersetzt werden.

Der Standard hilft außerdem dabei, sogenannte „Impedance Mismatches“ zwischen Systemen zu vermeiden. Beispielsweise arbeitet eine RFID-Leseschicht direkt mit Binärwerten, während EPCIS- oder Datenbankanwendungen häufig URIs erwarten. Ohne eine einheitliche Übersetzungsmethode müssten Entwickler für jede Ebene eigene Logiken erstellen, was zu uneinheitlicher Validierung, falscher Seriennummernformatierung oder fehlerhafter Verarbeitung von GS1 Company Prefix-Längen führen kann. TDT definiert hierfür einen gemeinsamen, regelbasierten Übersetzungsprozess, der in Lesegeräten, Middleware, Validierungstools oder Unternehmensanwendungen für RFID Tags integriert werden kann.

Von TDT unterstützte Übersetzungsebenen

Binäre Darstellung

Die binäre Ebene ist die Form, die normalerweise im EPC-Speicherbereich eines RFID-Tags abgelegt wird. Sie ist kompakt und effizient und enthält Informationen wie Header, Filterwert, Partitionswert und Datenfelder. Diese Ebene ist für das Schreiben und Lesen von Tags entscheidend, eignet sich jedoch normalerweise nicht als langfristiger Identifikator für Geschäftssysteme.

Tag-Encoding-URI

Die Tag-Encoding-URI steht in direkter Beziehung zum Binärwert auf dem Tag. Sie beschreibt das EPC-Codierungsschema, die Tag-Länge und den Filterwert in einer strukturierten Textform. Diese Darstellung ist besonders für Low-Level-Software geeignet, die exakt verstehen muss, wie ein Tag codiert oder decodiert wird.

Pure-Identity-URI

Die Pure-Identity-URI stellt die Objektidentität ohne tagspezifische Details wie Bitlänge oder Filterwert dar. Dadurch eignet sie sich für Unternehmensanwendungen, Datenaustausch und EPCIS-Ereignisse. Zwei Tags mit unterschiedlichen Binärdarstellungen können auf dieser Ebene dennoch dieselbe Objektidentität repräsentieren, wenn die zentralen Identitätsfelder identisch sind.

Serialisierter Legacy-Code

Die Ebene für serialisierte Legacy-Codes verbindet EPC-Daten mit bestehenden GS1-Identifikationsschlüsseln. Beispiele sind serialisierte GTIN, SSCC, GLN-basierte Standortkennungen, Mehrweg-Asset-Identifikatoren und individuelle Asset-Kennungen. TDT wandelt keine beliebigen Geschäftskennungen ineinander um, sondern übersetzt Darstellungen innerhalb unterstützter Codierungsschemata.

Funktionsweise des TDT 1.4 Prozesses

Ein TDT-Prozess beginnt mit einem Eingabewert, einer gewünschten Zielrepräsentation und gegebenenfalls zusätzlichen Parametern zur Auflösung der Übersetzung. Die Software erkennt die Eingangsrepräsentation und das Codierungsschema, validiert die Felder, extrahiert Werte aus dem Eingabeformat, wendet Regeln an und erstellt die Ausgabe entsprechend der gewählten Darstellungsebene. Bei GS1-Partitionsschemata ist die Länge des GS1 Company Prefix besonders wichtig, da sie die Aufteilung und Validierung der Datenfelder beeinflusst.

TDT 1.4 beschreibt Formate mithilfe regulärer Ausdrücke und ABNF-Grammatik. Reguläre Ausdrücke erkennen und analysieren Eingabewerte, während Grammatikregeln die Struktur der Ausgabewerte definieren. Die XML-Beschreibungen enthalten außerdem Informationen zu Feldlängen, numerischen Bereichen, Zeichenbeschränkungen, Auffüllregeln, abgeleiteten Feldern und Kernfunktionen. Dadurch bleibt die Übersetzungslogik besser wartbar als individuell programmierte Lösungen für jedes einzelne Schema.

Der Standard trennt die Regelverarbeitung in zwei wichtige Phasen: EXTRACT und FORMAT. EXTRACT-Regeln werden nach der Analyse des Eingabewerts ausgeführt und helfen dabei, Felder abzuleiten oder zu normalisieren. FORMAT-Regeln bereiten die benötigten Felder für die Erstellung der Zielrepräsentation vor. Diese Trennung ist wichtig, da die Informationen zum Lesen eines EPC-Werts nicht immer identisch mit den Informationen zur Ausgabe in einem anderen Format sind.

Praktischer Nutzen für RFID-Projekte

Für Lösungsanbieter bietet TDT 1.4 eine strukturierte Methode, um EPC-Codierung und -Decodierung über Geräte, Middleware, Cloud-Plattformen und Datenbanken hinweg konsistent zu halten. Der Standard ist relevant für Lagerverfolgung, Artikelidentifikation im Handel, Asset Management, Logistiktransparenz, Mehrwegtransportbehälter, Dokumentenidentifikation und Servicebeziehungsmanagement. Gleichzeitig unterstützt er zukunftssichere Systeme, da aktualisierte TDT-Dateien neue oder geänderte Codierungsregeln beschreiben können, ohne dass alle Anwendungskomponenten vollständig neu entwickelt werden müssen.

Bei der Systemplanung sollte TDT als Bestandteil der Datenarchitektur betrachtet werden und nicht nur als technische Tag-Funktion. Unternehmen, die RFID Lesegeräte, Middleware oder EPCIS-Software auswählen, sollten prüfen, welche EPC-Schemata unterstützt werden, wie Validierungsfehler behandelt werden, ob Prefix-Längen korrekt verarbeitet werden und ob die erforderlichen Ausgabeformate für nachgelagerte Geschäftsanwendungen verfügbar sind. Auch identifikationsbasierte Produkte wie Plastic Cards profitieren von diesem Prinzip: Ein Datenträger ist nur dann wertvoll, wenn die gespeicherte Identität vom gesamten System zuverlässig interpretiert werden kann.

FAQ zu EPCglobal TDT 1.4

Wofür wird EPCglobal TDT 1.4 verwendet?

EPCglobal TDT 1.4 wird zur Übersetzung von EPC-Daten zwischen Binärformat, Tag-Encoding-URI, Pure-Identity-URI, serialisiertem Legacy-Code und verwandten Ausgabeformaten eingesetzt. Der Standard unterstützt RFID-Software bei der Validierung von EPC-Werten, der Erkennung unterstützter Schemata, der Anwendung von Feldregeln und der Erstellung einheitlicher Darstellungen für nachgelagerte Systeme.

Ist TDT identisch mit dem EPC Tag Data Standard?

Nein. EPC Tag Data Standards definieren EPC-Schemata und deren Codierungsregeln, während TDT beschreibt, wie diese Regeln maschinenlesbar für Softwareübersetzungen umgesetzt werden können. TDS ist die Referenz für Bedeutung und Struktur, TDT ist der Mechanismus zur konsistenten Implementierung dieser Regeln in Anwendungen.

Warum unterstützt TDT sowohl Binär- als auch URI-Formate?

RFID-Tags benötigen normalerweise kompakte Binärdaten, während Softwaresysteme häufig lesbare und stabile URI-Formate verwenden. Binärformate sind effizient für Tagspeicher und Leservorgänge. URI-Formate erleichtern den Austausch zwischen Middleware, EPCIS, Datenbanken und Geschäftsanwendungen, ohne von physischen Tag-Eigenschaften abhängig zu sein.

Kann TDT jede Kennung in jede andere Kennung umwandeln?

Nein. TDT übersetzt zwischen verschiedenen Darstellungen innerhalb eines bestimmten EPC-Codierungsschemas. Beispielsweise kann eine unterstützte SGTIN-Darstellung von Binärformat zu Pure-Identity-URI konvertiert werden, jedoch nicht beliebig ein SSCC in eine SGTIN umgewandelt werden. Die geschäftliche Bedeutung der Kennung muss erhalten bleiben.

Welche Änderungen bringt EPCglobal TDT 1.4 gegenüber früheren Versionen?

Version 1.4 ist auf TDS 1.4 abgestimmt und erweitert die Unterstützung für Schemata wie GSRN und GDTI. Außerdem wurden Schema-Definitionen aktualisiert, Auffüllregeln für Binärausgaben präzisiert, Funktionen wie Datumsverarbeitung ergänzt und die Beschreibung von Feldattributen sowie Referenzen für Übersetzungssoftware verbessert.

Wer sollte diesen Standard kennen?

RFID-Softwareentwickler, Systemintegratoren, Lösungsanbieter, Middleware-Hersteller und Unternehmen mit EPC-basierter Identifikation sollten TDT verstehen. Besonders wichtig ist der Standard, wenn mehrere Systeme EPC-Werte lesen, schreiben, validieren, speichern oder austauschen und dabei eine einheitliche Interpretation über technische Ebenen hinweg gewährleisten müssen.

Benötigt TDT eine aktive Internetverbindung?

Nein. TDT-Markup-Dateien und zusätzliche Tabellen können lokal zwischengespeichert werden. Ein System kann regelmäßig nach aktualisierten Definitionsdateien aus einer autorisierten Quelle suchen, aber Übersetzung und Validierung funktionieren ohne dauerhafte Netzwerkverbindung, sobald die erforderlichen Definitionen lokal verfügbar sind.

Bestätigungscode