RFID Einsatz im herstellerneutralen Umfeld

„Real-World-Awareness“ – aktuelle und fehlerfreie Informationen – sind Fundament der Logistik, und gerade in dieser, durch den massiven Einsatz von Auto-ID und E-Commerce geprägten Logistik-Welt notwendig. Aber die Anbindung heterogen verteilter Erfassungssysteme ist kostspielig und nicht trivial. „UDC/CP“ stellt eine Abstraktionsschicht zur Anbindung verschiedenster Auto-ID-Geräte an beliebige andere Softwaresysteme dar.

Anbieter zum Thema

Zetes GmbH

leogistics GmbH

Körber Supply Chain Software GmbH

COGNID Consulting & Engineering GmbH

Fraunhofer-Institut für Materialfluss und Logistik (IML)

Mit der aktuellen RFID-Welle wird der seit langem bestehende Trend zur automatischen Identifikation und Datenerfassung deutlich verstärkt. Mit RFID lassen sich auch große Datenmengen mit hoher Geschwindigkeit zuverlässig erfassen. Damit spielen solche Transponder-identifikationen eine Schlüsselrolle, wenn es in Logistik-Systemen um die richtigen Entscheidungen geht.

Auch wenn die Situation deutlich besser ist als vor zehn Jahren, gestaltet sich die Anbindung von Auto-ID-Geräten häufig aufwändiger als gedacht. Die Vielfalt der Geräte ist hoch und Standardanwendungen oder -schnittstellen sind zum Beispiel bei EPC-Global in Arbeit, aber noch nicht etabliert.

Zwingend erforderlich ist eine Software-Schicht zwischen Anwendung und Feldebene, die standardisierte Protokolle sowie eine Programmierschnittstelle zur Verfügung stellt. Damit wird nicht nur die Austauschbarkeit von Hardwarekomponenten sondern auch die Interoperabilität verbessert.

Industrielösungen haben meist unterschiedliche Motive

Der Begriff Middleware fällt gerade im Zusammenhang mit logistikrelevanten Auto-ID-Anwendungen in den letzten Jahren immer häufiger. Verschiedene namhafte Unternehmen sind hier aktiv, jedoch mit unterschiedlichen Sichtweisen der Dinge. Diese sind meist ganz offensichtlich vom jeweiligen Kerngeschäft der Anbieter geprägt:

• Cisco beispielsweise bietet mit dem Application-Oriented Networking (AON) intelligente Netzwerkservices als Basis für RFID. Zweifellos wird der volle Nutzen von EPC/RFID erst durch den Datenaustausch mit Partnern realisiert. Der Fokus liegt für Cisco darin, ein offenes, auf Standards basierendes und konvergentes Netzwerk bereitzustellen.
• RFIT Solutions wurde aus dem ehemaligen Geschäftsbereich „RFID1 Systems Solutions“ von Infineon im Juli 2005 gegründet. Bei You-R-Open liegt der Fokus auf einer RFID-Betriebs- und Entwicklungsumgebung (Operating Environment), vergleichbar mit einem PC-Beriebssystem.
• Microsoft setzt auf dem Dotnet-Framework auf und spricht auch nicht von einer Middleware. Die mit RFID-Infrastructure bezeichnete Entwicklung soll auf maschinennaher Ebene im Wesentlichen von Partnerunternehmen realisiert werden, die Schnittstellen im Event-Manager bauen.
• SAP bietet mit Hilfe des Electronic Product Codes (EPC) Lösungen zum Beispiel für zeitnahe und korrekte Produktinformationen etwa beim Kommissionieren. Als Teil des Net-Weavers wird eine Auto-ID-Infrastructure angeboten. Diese ermöglicht, die gelesenen Daten zu speichern und mittels Regelwerk zu aggregieren sowie schließlich an die richtigen Stellen zu verteilen.
• Sun Microsystems befasst sich seit Beginn der EPC-Welle mit einer Auto-ID-Lösung auf Basis von Java. Inzwischen integriert das Sun Java System RFID Software 3.0 die SAP-Auto-ID-Infrastructure. Ziel ist eine durchgängige Lösung des RFID-Datenverkehrs von den RFID-Endgeräten via Jini Technologie bis hinein in die SAP-Produktivumgebung von Unternehmen.

Einstieg soll einfacher werden

Sämtliche Lösungen versuchen, den Einstieg in RFID leichter zu machen. Zudem werden Probleme komplexer Hardware-Infrastruktur und deren Verwaltung abgedeckt. Alle bieten Unabhängigkeit von einzelnen Hardwareanbietern bis hin zu heterogenen, skalierbaren Lösungen über mehrere Standorte.

Die lange Zeit vorhandene Tendenz zu proprietären Lösungen wurde inzwischen weitgehend überwunden. Kunden reduzieren damit die laufenden Betriebskosten und schützen die Investitionen in die Infrastruktur. Historisch ist die Entwicklung der Programmierung von stetig zunehmender Abstraktion gekennzeichnet. Jede Auto-ID-Middleware abstrahiert die Hardwarebasis. So ist es für ein Anwendungsprogramm nicht mehr relevant, mit welchem System es auf unterster Ebene kommuniziert. Dies sorgt für eine erhebliche Vereinfachung bei der Entwicklung und bringt schließlich auch großen Nutzwert. Hardwarenahe Programmierung von Endgeräten entfällt, Softwareentwicklung baut auf eine stabile Schnittstelle.

Standard-Middleware bis heute nicht in Sicht

Die meisten Anbieter unterstützen nur die von ihnen definierten, gebräuchlichsten RFID-Technologien und Standards. Was für eine optimale Auto-ID-Lösung nötig ist, bestimmt der Anbieter. Die Grenzen liegen oft im Partnernetzwerk des Anbieters, der bevorzugten Programmierumgebung (Dotnet, Java, …) oder in der eigenen Hardwareplattform. Zur Zeit ist somit noch keine Standard-Middleware verfügbar und kurzfristig ist auch nicht mit einer Änderung dieser Situation zu rechnen.

Bemerkenswert ist die isolierte Fokussierung auf RFID. Dabei ist das grundsätzliche Problem weder neu, noch sind Lösungsansätze erst in den letzen Jahren entstanden. Schon Mitte der 90er Jahre wurde am Lehrstuhl für Förder- und Lagerwesen der Universität Dortmund ein Ansatz vorgestellt, der auf der Verarbeitung logistischer Datensätze basiert.

Das Ergebnis liegt mit UDC/CP (Unified Data Capture/Communication Protocol) vor. In seiner ersten Version arbeitet UDC/CP mit verschiedenen RFID-Lesegeräten für 125 kHz und 13,56 MHz (ISO 15693) sowie mit unterschiedlichen Barcode-Scannern. Die Erfassung und Verarbeitung von biometrischen Daten ist bereits vorgesehen. Das Protokoll bietet eine Reihe von Eigenschaften, die auf typische Anforderungen von Logistikanwendungen zugeschnitten sind und folgend kurz vorgestellt werden sollen.

Es gibt Situationen, in denen die Zusammenschaltung mehrerer Auto-ID-Geräte und verschiedener, die Auto-ID-Geräte antriggernden Sensoren zu neuen logischen Geräten sinnvoll ist. Zum Beispiel, wenn an einem Transportband, auf dem transponderbelabelte Gegenstände transportiert werden, nicht sichergestellt werden kann, auf welcher Seite des Gegenstandes ein Transponder aufgebracht ist. Da ein Anbringen eines zweiten Transponders zu massiven Synchronisierungsproblemen führen würde, ist es in einem solchen Fall sicherer, eine Schreib-/Lesestation aus mehreren Lesern aufzubauen. Das Protokoll ermöglicht die virtuelle Zusammenschaltung verschiedener Geräte zu logischen Devices und erleichtert damit die Anwendungsprogrammierung enorm.

Eine weitere Anforderung, die immer wieder gestellt wird, ist die nach der Vollständigkeit und Eindeutigkeit von Informationen. Der logistische Datensatz ergibt sich aus den drei W-Fragen:

• Was wurde identifiziert (welches Label/welcher Transponder)?
• Wo wurde identifiziert (an welchem Ort steht der Reader)?
• Wann wurde identifiziert (die Systemzeit des Rechners)?

Dieser Forderung kommt UDC/CP nach, indem die erfassten Identifikations-Daten automatisch vom System durch Ortsangaben und Zeitangaben ergänzt werden.MM

(ID:200183)