RFID im Blick · AutoID/RFID Marktplatz und Presseportal

„Middleware ist traditionell zentralisiert.Typische AutoID-Prozesse sind es nicht.“

Von Frank Wernert, Produkt-Manager bei der Silverstroke GmbH

Im Gegenteil wird AutoID ja gerade eingesetzt, wenn Objekte – Güter, Behälter, Fahrzeuge, Gefahrenstoffe, Wertgegenstände oder andere – ihren Aufenthaltsort und/oder ihren Status verändern. Oder mittels mobilen Geräten überprüft werden sollen. Zentralität auf der einen und Mobilität auf der anderen Seite – das ist auf den ersten Blick schlecht vereinbar und daher Vorgabe für die Hauptanforderungen an Middleware in AutoID-Lösungen. Was zuerst zu der Frage führt, was RFID- oder besser AutoID-Middleware überhaupt ist. Einigkeit herrscht bezüglich ihrer Aufgabe, soll sie doch dabei helfen, die schiere Datenmenge zu verarbeiten und den ausgelesenen Rohdaten Sinn zu verleihen. Weniger einig ist sich die Fachwelt, was Middleware charakterisiert. Ist Middleware eine Edgeware, eine Software, eine Hardwareschicht? Und was tut sie tatsächlich, filtert sie Daten, führt sie Applikationen aus, überwacht und steuert sie Devices, also Geräte und Einheiten innerhalb der AutoID-Lösung? Oder alles zusammen?

„Middleware ist derjenige Bestandteil einer AutoID-Lösung, der dafür sorgt, dass aus Daten Ereignisse werden, die innerhalb eines Prozesses die gewünschten Abläufe auslösen. Und das unabhängig davon, wie dezentral und unterschiedlich die Aktionen ablaufen, die zum Gesamtprozess gehören“, erklärt Frank Wernert, Produkt Manager bei der Ettlinger Silverstroke GmbH. „Deshalb speichert Middleware die Daten persistent, wertet sie aus, filtert, aggregiert diese und stößt durch gezielte Weitergabe weitere Arbeitsschritte an, sogenannte Workflows, deren Einhaltung sie gleichzeitig überwacht. Außerdem gibt sie als Integrationsplattform die aufbereiteten Informationen an die Backend-Systeme weiter, sie ist das Verbindungsglied zwischen dem Datenspeicher auf dem Objekt und Datenbank oder ERP-System.“ Alle Systeme und alle Anwendungen haben über die Middleware Zugriff auf die gleichen Rohdaten. Diese werden nicht einfach gelesen, sondern via Middleware sinnvoll verarbeitet. Aus dem reinen Vorhandensein von Rohdaten wird der komplette Workflow eines Prozesses. Keine triviale Aufgabe, umso mehr, als Middleware die zwei Probleme adressieren muss, mit denen sich RFID-Entwickler früher oder später konfrontiert sehen: Eine überwältigende Menge an zu verarbeitenden Ereignissen und eine nicht minder überwältigende Menge an Geräten und Einheiten innerhalb des Workflows.

Komplexität bleibt im Verborgenen

Damit stellt sich die Frage, an welcher Stelle sich die Middleware innerhalb der Lösungsarchitektur sinnvoller Weise platziert. „Wir haben uns an der klassischen Definition der Middleware orientiert“, sagt Frank Wernert dazu. „Demnach ist es Aufgabe der Middleware, so zwischen Anwendungen vermitteln, dass die Komplexität der Applikationen und ihrer Infrastruktur verborgen wird. Für die Anwender steht im Vordergrund, möglichst komfortabel Nutzen aus den gewonnen Daten zu ziehen, nicht die technische Infrastruktur, die das möglich macht.“ Deshalb hat die Silverstroke GmbH mit dem Produkt Tagpilot eine komplette AutoID-Lösung entwickelt, die ein Device Management, eine workfloworientierte Integrationsplattform – die Middleware – und Portal-Applikationen verbindet. Über das Device Management werden beliebige Daten erfasst, die Portal-Applikationen stellen die Anwendungen, mit denen die Kunden arbeiten, beispielsweise Behälter- oder Asset-Management. Die Middleware verleiht dem Wort „middle“ in doppelter Hinsicht Bedeutung: Sie vermittelt zwischen den Devices und den Anwendungen, und sie steht, wie die Abbildung oben illustriert, in der Mitte der Architektur. Als zentrale Integrationsplattform erfüllt sie folgende Aufgaben:

• Sie bearbeitet die Ereignisse („Events“) aus der Device-Management-Schicht
• Sie speichert alle relevanten Informationen persistent in einer Datenbank
• Sie interagiert mit den Applikationen im Backend
• Sie handhabt Objekte und Tags
• Sie ermöglicht der Applikationsschicht den Zugang zu Informationen

Warum so viele unterschiedliche Aufgaben, obwohl doch neue Generationen von Tags auch schon diverse Daten speichern können? Weil es eben für die Anwender nicht damit getan ist zu wissen, dass sich Behälter X mit Inhalt Y zum Zeitpunkt t in Halle Z befunden hat. Vielmehr möchten die Prozessverantwortlichen beispielsweise sehen, in welchem Zustand der Behälter ist (gereinigt, ungereinigt, in Reparatur), wie lange er schon in Halle Z ist, ob er vorher plangemäß in Halle W war und ob die verantwortlichen Mitarbeiter automatisch alarmiert werden, wenn er mit einem Inhalt Y befüllt sein sollte, mit dem er keinesfalls in Halle Z abgestellt werden darf.

Modularer Aufbau der Middleware

Die Beispiele verdeutlichen, warum die Middleware modular aufgebaut sein sollte: Weil unterschiedliche Kunden in unterschiedlichen Anwendungsfällen unterschiedliche Informationen aus den ausgelesenen Daten generieren wollen. Eine Bäckerei, die lediglich Körbe mit Backwaren zwischen zwei Filialen hin- und herschickt, braucht nur ein Minimum der möglichen Module der Middleware. Ein Großunternehmen, das mit seiner AutoID-Lösung Brandschutzanlagen warten und prüfen will, benötigt andere Module als ein Logistiker für Gefahrenstoffe, der RTLS einsetzen möchte.

Komfortable Bedienbarkeit und Flexibilität

Was alle Anwendungen brauchen, ist eine einfache und komfortable Bedienbarkeit. Doch die erfordert einen umso anspruchsvolleren technischen Hintergrund. Als zentrale Einheit in dezentral ablaufenden Prozessen darf die Middleware wenig bis keine Einschränkungen hinsichtlich der Betriebsinfrastruktur machen. Das bezieht sich zum Beispiel auf die Datenbanken, mit denen die Middleware kommuniziert. Bei Tagpilot hat der „Hibernate Database Abstraction Layer“ Adapter für unterschiedliche Typen von Datenbanken unterschiedlicher Hersteller, zum Standard gehören Microsoft SQL Server 2005 und Oracle 10g. Das Event Handler Modul kommuniziert mit Backends wie SAP, Sun Java CAPS, Oracle, BEA und Messaging-Systemen wie Websphere MQ, Tibco, MS Exchange und anderen E-Mail-Servern. Grundsätzlich erforderlich ist auch die Flexibilität hinsichtlich der Betriebssysteme, auf denen die Middleware läuft, seien das nun Unix-, Windows- oder Linux-Derivate.

Verteilung eingehender Ereignisse

Damit die gewählte AutoID-Technologie frei wählbar ist, spielt technisch gesehen der „Applikation Event Handler“ in Tagpilot eine zentrale Rolle, wie die Abbildung unten illustriert. Er fungiert, anschaulich gesprochen, als eine Art Postzentrale, in der die eingehenden Daten registriert und nach bestimmten Kriterien weiterverteilt werden. Die eingehenden Ereignisse (Daten) können aus drei unterschiedlichen Quellen stammen. Es können also generische Objektereignisse sein, die der „Reader Abstraction Layer“ aus den Daten der technischen AutoID-Geräte – Tags, Barcodes, GPS-Daten etc. – erzeugt hat. Oder Daten, die via Mobile Device Server Adapter ankommen und ursprünglich mit mobilen Lesegeräten (MDE-Geräte, Mobiltelefone etc.) erfasst wurden. Oder Informationen, die über das Webservice Event Interface aus den Applikationen Dritter eintreffen.

Weiterverarbeitung der Daten

Für die Weiterverarbeitung entscheidet der Applikation Event Handler, an welche der Prozessinstanzen die Ereignisse weitergereicht werden. Wie die Abbildung links zeigt, stehen dafür vier Module zur Verfügung, die beliebig kombiniert werden können. Nummer eins ist die „Workflow Engine“, die ihrerseits ein flexibles Workflow-Management enthält. Damit lassen sich spezifische Kundenanforderungen sehr einfach adaptieren. Die Nummer zwei, die „Rule, Time and State Engine“ erlaubt, Objekte zu verfolgen und die zugehörigen Objektattribute automatisch zu verändern. Beispielsweise kann damit überprüft werden, ob bestimmte Objekte definierte Routen und Transportzeiten einhalten oder dass ein Attribut von „in Reparatur“ zu „verfügbar“ wechselt. Das „RTLS/Geo processing and fencing”-Modul verarbeitet geographische Informationen und liefert 3-dimensionale Ortsangaben, während Nummer 4, das „Area Management“, erlaubt, bestimmte Areale zu definieren, um Objekte zu lokalisieren. Von den zahlreichen weiteren Modulen für die interne Verarbeitung und Management sei hier nur eins aufgeführt: das Objektmanagement. Dieses Modul verwaltet einerseits Objekte, beispielsweise Behälter, Fahrzeuge, Werkzeuge, Personen und Wertgegenstände, und „Tag-Objekte“ wie RFID-Tags, Barcodes, Sensorknoten etc. Andererseits steuert das Modul auch die Verbindungen zwischen Objekten und Tags und die Relationen zwischen Objekten und ermöglicht damit Multi-Tag- und Objekt-in-Objekt-Beziehungen.

Beispiel Palettenidentifikation per RFID

Was so technisch klingt, hat sehr anschauliche Anwendungsbeispiele, etwa einen per GPS-überwachten Lkw, der eine Palette geladen hat, auf der sich diverse Waren befinden. Bei Tagpilot wird die Palette beispielsweise per RFID identifiziert, die Waren auf der Palette werden per Barcode-Scanner erfasst und mit der Palette in Beziehung gesetzt. Damit weiß Tagpilot, welche Waren sich auf welcher Palette befinden. Der Lkw trägt eine Box, die mittels GPS die aktuelle Position ermittelt und an Tagpilot sendet. Sobald die Palette verladen wird, wird sie auch mit dem Lkw in Beziehung gesetzt. Implizit werden damit auch alle Waren auf den Lkw „geladen“. In der logischen Folge werden Bewegungen des Lkw als Bewegungen der Waren erkannt, obwohl die Waren selbst nicht physikalisch erfasst werden. Tatsächlich ausgelesen wurden also ein RFID-Tag, einige Barcodes und GPS-Positionen von so unterschiedlichen Objekten wie einer Palette, Gegenständen und einem Lkw. Und am Ende können die Anwender an ihrem Bildschirm verfolgen, dass sich der Gegenstand mit Barcode X gerade auf der Autobahn in Richtung Ort Z befindet. Und das er seit zwei Stunden unterwegs ist. Und von wo er kommt. Und auf welcher Palette er steht, in welchem Lkw. Und, und, und.

Kurz: In AutoID-Lösungen macht Middleware wie Tagpilot aus Rohdaten gezielte, auswertbare Informationen. Denn dafür wurde AutoID entwickelt.