RFID-Framework für intelligente Prozesssteuerung
Von Volker Knapp
Applikationsentwicklung auf Basis von RFID-Technologie kann mitunter ein schwieriges Unterfangen sein. Es gilt unterschiedlichste Hardware anzusteuern, die Datenkommunikation zu verwalten, Workflow-definierte Prozesse auszulösen und die gewonnenen Informationen dem Benutzer, möglichst einfach aufbereitet, darzustellen. Gleichzeitig soll das System ausfallsicher sein, beliebig skalierbar und möglichst auch mit völlig neuer (gewechselter, getauschter) Hardware und minimalen Konfi gurationsaufwand ohne Stillstand funktionieren. Um all diesen Anforderungen gerecht zu werden ist ein Middleware-Framework unerlässlich.
Anbindung der Hardware
Die Ansteuerung der RFID-Hardware erfolgt über den Low Level Reader Protocol Standard. Mittlerweile sind bereits viele Reader der gängigsten Hersteller implementiert und stehen applikationsseitig zur Verfügung. Es ist ein Leichtes zukünftige Reader mit anzubinden, ohne in der bestehenden Applikation Änderungen vornehmen zu müssen. Selbst ein Technologietausch innerhalb UHF, HF und LF kann auf diese Weise vonstatten gehen, ohne die Qualität des Systems zu mindern.
Zentrale Datenaufarbeitung
In der darüber liegenden Abstraktionsschicht findet die Datenaufbereitung statt. Sämtliche von den einzelnen Readern übermittelten Daten, wie Transponderlesungen oder Schaltung von digitalen Input Ports, werden zentral gesammelt und in Form gebracht. Je nachdem welchen Bereichen (Logical Reader) die Lesegeräte zugewiesen sind, ergibt sich so bereits ein erstes Bild über die Verteilung der Datenerfassungen. Durch die Zusammenfassung einzelner Lesegeräte zu definierten Bereichen ist es möglich, im laufenden Betrieb einen Bereich durch weitere Lesegeräte zu erweitern, zu verstärken oder einfach nur defekte Geräte auszuwechseln.
Filterung in der Reporting Engine
Nachdem die Gesamtheit dieser gesammelten Daten für einzelne Bereiche der Applikation unerheblich ist, müssen die Daten erst auf deren Relevanz gefiltert werden. Die Reporting Engine übernimmt diese Aufgabe, indem sie einzelnen Berichte anfordernden Stellen (Subscriber) nur die Informationen zur Verfügung stellt, welche diese auch im Vorfeld angefordert haben. Dadurch müssen die Daten nur in dieser Schicht geprüft werden, weitere Filterung in der Applikation kann entfallen, wodurch die Performance deutlich gesteigert wird.
Aufgaben der Workflow Engine
Ebenso wichtig wie die Aufbereitung der Daten ist die Interpretation derselben und anschließende Steuerung der Prozessabläufe. Um nun diese bereits gefilterten Daten weiterzuverarbeiten, gibt es die Workflow-Engine. Anhand im Vorfeld definierter Prozessabläufe werden die Daten abgearbeitet und lösen Ereignisse aus. Hinter der Workflow-Engine verbirgt sich eine State Of The Art Interpreter-Umgebung, welche es ermöglicht sogenannte SmartScripts, also intelligente Skripte, zur Laufzeit zu ändern und Programmfunktionalitäten frei zu erweitern. Somit ist es möglich für die unterschiedlichen Reader-Events (Tag Arrive, Tag Depart, Tag Report) Prozessabläufe in Form von Skripten zu definieren, welche bei Eintreten der Events ausgelöst werden. Je nach Anforderung werden auf diese Weise Daten weiterverarbeitet und optische und akustische Signalgeber geschaltet. Der Interpreter integriert sich in Microsofts CL Runtime Engine, wodurch komplexere, in DLLs ausgelagerte Funktionen, integriert werden können.
Um die Daten möglichst effizient für den Benutzer aufzubereiten, stehen unterschiedliche Benutzerschnittstellen zur Verfügung. Die Palette reicht je nach Anforderung von Rich Client Applikationen bis zu Web 2.0 Interfaces. Durch die Möglichkeit der Web Darstellung können viele Benutzer gleichzeitig in ihrem Internet Browser auf denselben Datenstand zugreifen, ohne dass aufwendige Installationen und Konfigurationen am Client Rechner notwendig wären.
RFIDInnovations: skalierbare Middleware
