\documentclass[%
   pdftex,%
   a4paper,%                                            % DIN A4
   oneside,%                                            % einseitiger Druck
   headsepline,%                                        % Strich unter der Kopfzeile
   12pt,%                                               % 12pt Schriftgröße
   halfparskip,%                                        % Europäischer Satz: Abstand zwischen Absätzen
   bibtotoc,%                                           % Literaturverzeichnis im Inhaltsverzeichnis
]{article}
%---------------------------------------------------------------------------------------------------
%\documentclass[%
%  BCOR5mm,%                                            % Bindungskorrektur
%  pagesize,%                                           % flexible Auswahl des Papierformats
%]{scrreprt}                                            % KOMA-Scriptklasse Report
%---------------------------------------------------------------------------------------------------

\usepackage{hawhhcs}

\hawtyp{Seminarausarbeitung} % default: 'Laborbericht'

\hawauthor{Martin Stein}

% Titel für Deckblatt
\hawtitel{Mit RFID-Technologie zum Internet der Dinge}
%\hawtitle{Cooperative Storage: Weaknesses and Countermeasures}

% Betreuer
\hawprof{Prof. Dr. Kai v. Luck}
%\hawkoprof{Prof.\ Dr.-Ing.\ Martin Hübner}

% Ort und Datum
\hawdatum{\today} % default: \today
\hawort{Hamburg} % default: 'Hamburg'

% Titel für Zusammenfassungsseiten (Abstract) (Deutsch und Englisch)
\hawzftitel{Mit RFID-Technologie zum Internet der Dinge}
\hawzftitle{Development of an ePayment-System based on mobile devices}

\hawstichworte{RFID, Radio Frequency Identification, EPC, Electronic Product Code, EPCglobal Network, NFC, Near Field Communication, SOA, Service-Oriented Architecture, WebServices, HardwareServices, SoftwareServices, UDDI, Filesharing, Peer2Peer}
\hawkeywords{Network Persistence Storage}

% Zusammenfassungsseite - Zusammenfassung(de)
\hawzusammenfassung{Dieses Papier befasst sich mit der Transpondertechnologie RFID im Allgemeinen und dem EPCglobal Network im Speziellem. Zudem wird die Nahfeldkommunikationstechnik NFC kurz vorgestellt. Am Ende des Papiers wird schließlich in einer Thesis-Outline auf die Möglichkeit hingewiesen, wie man Software zur Interaktion mit Geräten aus dem Home-Electronics-Bereich mit RFID finden könnte, um anschließend ebenfalls über RFID die Interaktion mit den Home-Electronics-Geräten stattfinden zu lassen.}

% Zusammenfassungsseite - Zusammenfassung(Abstract)(en)
\hawabstract{(none)}%Place the english abstract here

% Titeldruck: farbig mit Logo / ohne Logo
\hawlogo{true}  %% true = farbig; false = ausdruck (ohne balken und logo)

\begin{document}

\hawdeckblatt % kein standard Titelblatt mit \maketitle ! Ansonsten kommt das
             % Seitenlayout durcheinander.Das Deckblatt ist hier die Titelseite

\hawzf
%{\parskip=4mm \hawzf}

{\parskip=0mm \tableofcontents}
%\tableofcontents

\section{Einleitung}
%\label{sec:intro}

%\subsection{Das Problem}
%\label{ssec:intro:problem}

Wenn man im Moment über RFID redet, kommt man geradezu zwangsläufig auch auf das Thema \textit{EPCglobal Network} zu sprechen. Doch was ist dieses \textit{EPCglobal Network}? Warum nennt man es auch das \textit{Internet der Dinge}? Und wie schafft es dieses \textit{Internet der Dinge}, dass man plötzlich von "`allen Dingen dieser Welt"' wissen können soll, wo sie sich gerade aufhalten\footnote{Und ggf. zusätzlich auch noch welche Sensorwerte sie gerade erfassen.}? Bevor wir uns diesen Fragen stellen, beziehungsweise bevor wir uns mit diesem weltumspannenden Netzwerk, welches das \textit{EPCglobal Network} irgendwann einmal darstellen soll, derart widmen, dass sich der Leser die soeben gestellten Fragen hoffentlich selber beantworten kann, hiervor also soll erst einmal eine kleine Einführung in die Transpondertechnologie RFID erfolgen.

Die Transpondertechnologie RFID stellt quasi die Schnittstelle der realen Welt zur virtuellen Welt des EPCglobal Networks dar. Die Abkürzung RFID steht für \textit{Radio Frequency Identification}, was auf Deutsch soviel wie Funkerkennung heißt. Diese Namensgebung bringt jedoch nur einen einzelnen, wenn auch sehr wichtigen Aspekt dieser Technologie zum Ausdruck. Einsatzmöglichkeiten der RFID-Transpondertechnologie, die auch über das eindeutige Erkennen von Objekten hinausgehen, werden später in diesem Papier angesprochen. Zuvor soll jedoch erstmal ein kurzer Blick auf die elektrotechnischen Aspekte der RFID-Transpondertechnologie geworfen werden.

\begin{figure}[h]
	\centering
		\includegraphics[width=0.25\textwidth]{graphics/tag-it.png}
	\caption{RFID-Transponder}
	\label{fig:tag-it}
\end{figure}

\section{Die elektrotechnischen Aspekte von RFID}

Die Grundidee hinter der RFID-Technologie ist es, Siliziumchips\footnote{Es sei hier nur am Rande erwähnt, dass es RFID-Transponder ebenso auf Polymerbasis wie auch aus Piezokeramiken gibt.} zur Speicherung von Daten zu haben, welche ihre Daten kontaktlos zu einem Lesegerät übertragen können. Zudem sollen diese Datenspeicher möglichst ohne eigene Energiequellen wie Batterien oder Netzteile auskommen können. Stattdessen soll die Energie, die zum Betrieb des elektronischen Datenträgers benötigt wird, ebenfalls kontaktlos durch das jeweils zugreifende Lesegerät bereitgestellt werden. Darüber hinaus sollen die aufkommenden Hardwarekosten für die kabellose Datenschnittstelle zwischen RFID-Lesegerät und RFID-Transponder soweit wie möglich auf Seiten des RFID-Lesegerätes liegen, um die Kosten für die RFID-Transponder möglichst gering zu halten. Die typischen RFID-Transponder, welche auch Tags ([t$\epsilon$k, tæg], Plural: [t$\epsilon$ks, tægz]) genannt werden, kann man sich als eine Art kontaktlose Smartcard vorstellen, welche durch ihre Datenübertragung per Funk einem gegenüber den herkömmlichen Smartcards drastisch reduziertem Verschleiß unterliegen. Zudem bietet diese Funkübertragung entgegen kontaktbehafteter Smartcards- oder auch optischen Barcode-Verfahren den großen Vorteil einer demgegenüber deutlich reduzierten Abfertigungszeit, da ein Einstecken oder Ausrichten für das Lesegerät entfällt.

Der prinzipielle Aufbau der Kommunikationsschnittstelle zwischen RFID-Lesegerät und RFID-Transponder ist in der Abbildung 2 "`Prinzip der Datenübertragung über Lastmodulation"' zu sehen. Bei der Lastmodulation\footnote{An dieser Stelle soll nur grob das Verfahren der amplitudenmodelierten Lastmodulation angedeutet werden. Um ein erstes Verständnis für die RFID-Technik zu bekommen, sollte dieser vereinfachte Blick auf die elektrotechnische Seite reichen. Dem interessierten Leser sei an dieser Stelle jedoch wärmstens die Lektüre des RFID-Handbuchs (ISBN 3446220712) von Klaus Finkenzeller empfohlen. Zu beachten ist auch, dass bei Transpondern im UHF-Bereich keine induktive Kopplung vorliegt, sondern eine elektromagnetische, sodass das Backscatter-Verfahren zur Anwendung kommt, wobei zur Kommunikation von Transponder zu Lesegerät der Rückstrahlquerschnitt des Transponders variiert wird.} sind die Antennenspule des Lesegerätes und die Antennenspule des RFID-Transponders wie ein Transformator induktiv gekoppelt. Der resonante RFID-Transponder entzieht dem magnetischen Wechselfeld der Lesegerätantenne Energie. Durch das Ein- und Ausschalten eines Lastwiderstandes an der Antenne des RFID-Transponders, kann die entzogene Energie verändert werden. Je nach entzogener Energie stellt sich an der Antenne des Lesegerätes eine andere Spannung ein. Durch eine Amplitudenmodulation der Spannung in der Antenne des Lesegerätes kann so die Information, die der Transponder zum Lesegerät senden möchte, transportiert werden.

\begin{figure}[h]
	\centering
		\includegraphics[width=0.70\textwidth]{graphics/Abbildung2-4.png}
	\caption{Prinzip der Datenübertragung über Lastmodulation}
	\label{fig:tagmod}
\end{figure}

Neben den sogenannten \textit{passiven Transpondern} - das sind die RFID-Transponder, welche keinerlei eigene Stromversorgung besitzen und ihre gesamte Energie aus dem Feld, welches das Lesegerät erzeugt, beziehen - gibt es auch noch die \textit{semi-passiven} beziehungsweise \textit{semi-aktiven Transponder}\footnote{Es würde wahrscheinlich Sinn machen die Begriffe "`semi-passive"' und "`semi-aktive"' Transponder semantisch unterschiedlich zu belegen. Die Praxis zeigt aber, dass  zumindest bis heute die meisten Autoren keine Unterscheidung zwischen den beiden Begriffen machen. Da an dieser Stelle nur eine kleine Begriffseinführung getätigt werden soll, damit der Leser hiernach einfacher Zugang zu weiterer Literatur finden kann, soll an dieser Stelle keine Präzisierung des aktuell häufig verwendeten Sprachgebrauchs erfolgen.}. Diese semi-passiven/semi-aktiven Transponder transportieren ebenso ihre Informationen zurück zum Lesegerät wie die rein passiven Transponder, indem sie ebenfalls das Hochfrequenzfeld des Lesegerätes beeinflussen. Die Transponder besitzen auch hier keine eigene Hochfrequenzerzeugung, sodass die Transponder besonders kostengünstig hergestellt werden können, da ein Großteil der sonst notwendigen Bauteile wegfallen. Zudem ermöglicht diese parasitäre Mitnutzung des Hochfrequenzfeldes des Lesegerätes dem Transponder die Leistungsaufnahme im eigenen "`Sendebetrieb"' möglichst gering zu halten. Im Unterschied zu den rein passiven Transpondern, besitzen diese "`semi"'-Transponder nun aber noch eine zusätzliche Batterie, um ihre elektrische Schaltung mit Energie zu versorgen. Auf diese Weise kann zum einen die Reichweite des Systems vergrößert werden - aktuell bis zu 15 Meter. Zum anderen ergibt sich so auch die Möglichkeit, die elektrische Schaltung auch außerhalb des Lesegerätfeldes mit Energie zu versorgen, sodass beispielsweise durchgängige Sensormessungen möglich werden.

Eine weitere Kategorie von RFID-Transpondern stellen die \textit{aktiven Transponder} dar. Aktive Transponder besitzen ebenso wie die semi-passiven/semi-aktiven Transponder eine eigene Energiequelle. Zudem erzeugen sie jedoch zur Kommunikation zurück zum Lesegerät ein eigenes Hochfrequenzsignal, um dieses dann mit den zu übertragenen Informationen zu modulieren.

Es ist im Zusammenhang mit den Begrifflichkeiten passiver, semi-passiver/semi-aktiver und aktiver Transponder darauf zu achten, dass in älterer Literatur nur zwischen passiven und aktiven Transpondern unterschieden wird. Hierbei stellen passive Transponder die selben Transponder dar, wie die soeben beschriebenen passiven Transponder. Die frühere semantische Belegung des Begriffes aktiver Transponder zielte jedoch auch in vielen Fällen auf die Funktionalität ab, die soeben unter dem Begriff semi-passiver/semi-aktiver Transponder eingeführt wurde. Einen extra Begriff für die heutigen aktiven Transponder gibt es in derartiger Literatur dann häufig nicht. 

\section{Die Pulkerfassung}

Eine Besonderheit der RFID-Technik ist die sogenannte Pulkerfassung. Dabei kann sich eine große Anzahl von RFID-Transpondern gleichzeitig im Lesebereich eines Lesegerätes befinden und das Lesegerät ist dennoch in der Lage, jedes von ihnen einzeln zu erfassen. Hierbei ist zu beachten, dass RFID-Transponder normalerweise beim Betreten eines HF-Lesegerätfeldes sofort anfangen ihre ID auszusenden. Das geschieht auf diese Weise, da ansonsten ein Lesegerät überhaupt nicht wissen würde, dass sich von nun ab ein Transponder mit einer bestimmten ID in seinem Lesebereich befindet. Aus diesem Grund müssen zur Pulkerfassung Antikollisionsverfahren zur Anwendung kommen, welche dafür sorgen, dass sich die RFID-Transponder nicht gegenseitig stören. Nun folgend sind zwei typische Verfahren kurz vorgestellt:

\textit{Slotted Aloha} kommt zum Einsatz, wenn sich nur wenige RFID-Transponder gleichzeitig in Lesegerätreichweite befinden. Bei diesem Verfahren stehen den RFID-Transpondern mehrere Timeslots zur Aussendung ihrer ID zur Verfügung. Jeder Transponder in Reichweite wählt sich nun zufällig einen dieser Slots aus und sendet in diesem seine ID aus. Wenn in einem der Slots nur ein Transponder seine Adresse aussendet, hat das Lesegerät diesen Transponder erkannt. Daraufhin schickt ihm das Lesegerät einen adressierten Befehl, mit welchem dem Transponder gesagt wird, dass er nun erstmal nicht mehr seine Adresse aussenden soll. Das Aussenden der IDs in den einzelnen Timeslots wiederholt sich nun so lange, bis alle Transponders erkannt und stummgeschaltet sind. 

Das zweite hier nur kurz vorgestellte Verfahren basiert auf einem \textit{Binärer Suchbaum}. Dieses deterministische Verfahren hat den Vorteil, dass es immer funktioniert, egal wie viele Transponder sich in Reichweite befinden. Der Nachteil ist jedoch, dass es zumeist langsamer ist als \textit{Slotted Aloha}. Bei diesem zweiten Verfahren senden die Transponder nun nicht mehr "`ungefragt"' ihre ID einfach los, stattdessen sendet das Lesegerät einen adressierten Befehl aus, der besagt, dass der angesprochene Transponder seine ID (=Adresse) aussenden soll. Da das Lesegerät ja noch nicht die Adresse kennen kann, schickt es zusammen mit dem adressierten Befehl eine Bitmaske aus, welche besagt, welche von den Adressbits von den Transpondern ausgewertet werden sollen. Wenn sich nun mehrere Transponder gleichzeitig angesprochen fühlen, kommt es bei der Antwort zur Kollision und das Lesegerät muss die Bitmaske anpassen. So tastet sich das Lesegerät langsam an die richtige Adresse heran, so dass es zu einer bitgenauen Kollisionserkennung kommt. Wenn nun irgendwann ein einzelner Transponder selektiert werden konnte, wird diesem ein adressierter Befehl zum Stummschalten geschickt und die Suche nach den übrig gebliebenen Adressen wird fortgesetzt.

\section{Die eindeutige ID als Verweis in eine Datenbank}

Die Anwendungsbereiche für RFID sind vielfältig. In Handel- und Logistik-Bereich erhofft man sich weitreichende Optimierungsmöglichkeiten in der Warenlogistik. Das heute eingesetzte EAN-Strichcode-Systems gibt zum Beispiel nur an, dass es sich bei dem vorliegenden Produkt um ein Tiefkühlhuhn der Firma X handelt. Ob das Suppenhuhn vielleicht kurz vor Ablauf seines Haltbarkeitsdatums steht oder gar schon darüber hinaus ist, kann durch das heutige Strichcode-System nicht ermittelt werden. RFID soll dieses Problem lösen, indem jedes einzelne Produkt (in diesem Beispiel also jedes einzelne Huhn) seine eigene ID bekommt. Um das Haltbarkeitsdatum zu speichern, soll das RFID-Transponder diese Information jedoch nicht in sich selber tragen. Dazu wäre nämlich zusätzlicher Speicherplatz in den Transpondern nötig, was hingegen höhere Kosten für die einzelnen Transpondern zur Folge hätten. Um das Haltbarkeitsdatums zu speichern, soll diese Information unter Verwendung der eindeutigen ID des Artikels in einer externen Datenbank abgelegt werden. Der Vorteil für diese Vorgehen ist ganz klar, dass auf diese Weise quasi beliebig viele Informationen zu einem Produkt abgelegt werden können - ganz unabhängig davon, was vielleicht ein RFID-Transponder an Speicherkapazität haben würde. So könnte zum Beispiel die gesamte "`Reise-Historie"' individueller Produkte durch die gesamte Supply Chain gespeichert werden, egal wie lang diese Reise auch immer sein möge. Zudem hat man auch noch die Möglichkeit auf diese Historie zurückzugreifen, selbst wenn dieses Produkt samt ihres RFID-Transponders abhanden gekommen sein sollte.

\section{Datenspeicherung in den RFID-Transponder}

Anders als "`nur"' eine eindeutige Identifizierung von Objekten durch die einzigartige Seriennummer der RFID-Transponder zu ermöglichen, können viele Transponder auch weitere Informationen direkt in sich selber speichern. In der ursprünglichen Idee des EPCglobal Networks, wie sie vom Auto-ID Center ausgearbeitet wurde, war diese Möglichkeit nicht berücksichtigt worden. Mittlerweile wurde aber in diesem Punkt zumindest in Ansätzen nachgebessert. Der Vorteil, der durch diese Erweiterung erzielt werden soll, liegt in der Möglichkeit das Netzwerk und die daran angeschlossenen Server von häufigen Anfragen mit gleichen Antworten zu entlasten. Als ein Beispiel sei hier eine Kiste mit Einzelartikeln genannt, bei der überprüft werden soll, ob noch alle Einzelartikel in der Kiste sind. Hierbei könnte ein "`Kisten-Transponder"' Auskunft darüber erteilen, welche "`Einzelartikel-IDs"' mit dieser Kiste in Beziehung stehen. Ein weitere Vorteil in der Datenspeicherung innerhalb der RFID-Transponder liegt ganz klar auch darin, dass nicht vom Grundsatz her bereits immer eine Netzverbindung zu den entsprechenden Datenquellen am Ort des Lesegerätes sein muss.

\section{RFID-Sichtungen als Trigger}

Ein weiterer interessanter Einsatzzweck für RFID ist auch, dass die Sichtung eines RFID-Transponder direkt bestimmte Aktionen auslösen kann. Im Rahmen des EPCglobal Networks dürfte eine RFID-Sichtung wohl primär als Trigger für einen neuen Eintrag in die Traceverfolgungsdatenbank dienen. Denkbar ist aber auch, dass zum Beispiel eine Sensor-RFID-Transponder-Sichtung, die nötigen Daten für die neue Information liefert, dass für eine bestimmte Kiste mit Fisch die Kühlkette nicht eingehalten werden konnte. Wenn diese Sensor-Sichtung innerhalb der Supply Chain erfolgt, könnte dieses dann ein Trigger zur automatischen Nachbestellung der Ware sein, um die verdorbene Ware möglichst schnell durch frische Ware ersetzen zu können.

\section{RFID als kostengünstiges Dateninterface}

Ein anderer Anwendungsbereich für RFID ist der "`Missbrauch"' der Technik als kostengünstiges und kabelloses Dateninterface. Innerhalb des EPCglobal Networks wird dieser Idee bisher keine Rechnung getragen. Zwar hat sich EPCglobal dazu entschlossen zukünftig auch Transponder mit erweiterter Funktionalität anzubieten - darunter Fallen Transponder mit Speicher und Sicherheitsfunktionen (Class 2), semi-aktive Transponder (Class 3) und Transponder mit integrierten Sensoren (Class 4) - jedoch konnte man sich bei EPCglobal wohl bisher noch nicht vorstellen, dass die Transponder nicht nur ausschließlich von außen auf die Waren angebracht werden, sondern auch schon direkter Bestandteil der Produkte sein könnten. 

Man kann sich heute zu vielerlei Gerätschaften im Niedrigstpreissegment kaum vorstellen, dass es sich kosten-/nutzentechnisch irgendwie rentieren könnte, ein Dateninterface in diese einzubauen. So besitzen beispielsweise viele Menschen einen kleinen und billigen 2 Euro Taschenrechner, den sie immer wieder mal für kleine Berechnungen benutzten. Kein Hersteller solcher Billigtaschenrechner würde auf die Idee kommen, ab Werk ein kostspieliges Dateninterface, wie eine Bluetooth-Schnittstelle in ein solches 2 Euro Produkt einzubauen. Der Benutzer bräuchte mit so einem Bluetooth-Interface zwar zum Beispiel nicht mehr das Ergebnis des Taschenrechners in den PC abzutippen, sondern könnte das Ergebnis direkt in die Zwischenablage kopieren (das passende Programm dafür vorausgesetzt), aber die Mehrkosten für so ein Dateninterface, welche auf den Kunden umgelegt werden müssten, wären mit diesem "`Service"' auf keinen Fall zu rechtfertigen. Wenn man jedoch als Hersteller solcher Taschenrechner die Möglichkeit hätte, ein RFID-Transponder-Dateninterface für nur wenige Cent in so ein "`Billigprodukt"' einzubauen, könnte man schon eher geneigt sein, dem Kunden so ein Zusatz-Gimmick anzubieten. Viele weitere derartige Einsatzmöglichkeiten für RFID-Dateninterfaces sind denkbar. In einem Fall solch einer kreativen Umnutzung des RFID-Systems zu einem Dateninterface hat man sich sogar entschlossen, einen ganz eigenen Namen dafür zu kreieren: Es handelt sich dabei um die \textit{Near Field Communication} - kurz \textit{NFC}. Verwendung findet die NFC beispielsweise in einem Pilotprojekt des Rhein-Main-Verkehrsverbundes in Kooperation mit Nokia und Philips bei dem NFC-Mobiltelefone zum Handy Ticketing eingesetzt werden. NFC arbeitet auf 13,56 MHz, hat eine Reichweite von etwa 10 cm, bietet aktuell Übertragungsgeschwindigkeiten von 106, 212 und 424 kbit/s (848 kbit/s und 1,70 Mbit/s sind zudem geplant) und die Gegenstation zum Lesegerät kann sowohl als passiver wie auch aktiver Transponder auftreten. NFC soll auch in der Lage sein, andere kabellose Verbindungen wie zum Beispiel über Bluetooth oder WLAN automatisch und sicher (verschlüsselt) zu etablieren. Der Vorteil läge hierbei, dass die reichweitenarme NFC-Verbindung nur kurzzeitig benötigt wird, um den Verbindungswunsch zu dem berührten Gerät zu signalisieren, um dann anschließend auf eine ggf. schnellere, aber vor allem reichweitenhöhere Verbindung transparent umzuschwenken. Das größte Problem bei NFC liegt zur Zeit meiner Meinung nach in einer eher bescheidenen Informationspolitik der beteiligten Unternehmen. Der Physical-Layer, wie auch der Data-Link-Layer sind zwar bereits standardisiert, doch über die konkreten Pläne, wie die restliche Architektur oberhalb dieser beiden unteren Schichten aufgebaut sein soll und welche Anwendungen konkret geplant sind, ist im Moment nicht besonders viel herauszufinden. Primär werden die Möglichkeiten des bargeldlosen Bezahlens, die Interaktion mit Werbeplakaten (Web-Links), die Nutzung von "`Datenkiosken"' und die Musik/Video-Übertragung von Handy zu Handy angepriesen. Aber welche (hoffentlich) generische Architektur dieses ermöglichen soll, bleibt bisher leider eher im Dunklen.

\section{Das EPCglobal Network}

Nach dieser Einführung in die RFID-Transpondertechnologie kommen wir endlich etwas konkreter auf das Thema EPCglobal Network zu sprechen. 

\begin{figure}[h]
	\centering
		\includegraphics[width=0.50\textwidth]{graphics/autoID.png}
	\caption{EPC Network Architektur}
	\label{fig:epcnet}
\end{figure}

Das Kernstück dieser ursprünglich in den AutoID-Centern entwickelten Technologie stellt der \textit{Electronic Product Code (EPC)} dar. Neben der Hersteller- und Produktnummer, wie sie auch schon in den Barcodes auf den Verpackungen im Einzelhandel zu finden waren, beinhaltet der EPC zudem noch eine eindeutige, individuelle Seriennummer. Hierdurch lässt sich nun jeder Gegenstand, der mit einem jeweiligen Transponder assoziiert wird, eindeutig identifizieren. Wenn nun ein Lesegerät so einen Transponder erkennt, wird diese Sichtung an den angeschlossenen \textit{Savant} gemeldet. Der Savant ist eine RFID-Middleware mit vielfältigen Funktionen. So filtert er zum Beispiel eingehende Reader-Events und versorgt angeschlossene Anwendungen, wie zum Beispiel Warenwirtschaftssysteme mit entsprechend aufbereiteten Daten. Der Ort an dem die Daten eines Objektes verwaltet werden, kann über eine Anfrage an den \textit{Object Naming Service (ONS)} unter Angabe des EPC herausgefunden werden. Der Ort der eigentlichen Datenverwaltung ist schließlich das \textit{EPC Information System (EPC IS)} (Siehe auch Abbildung 3 und 4). Die vorgesehene Sprache zur Beschreibung der Objekte und zur Speicherung der Daten über diese Objekte ist die XML-basierte Markup-Sprache \textit{PML (Physical Markup Language)}. 

\begin{figure}[h]
	\centering
		\includegraphics[width=0.50\textwidth]{graphics/epc-net.png}
	\caption{EPC Network Überblick}
	\label{fig:epcnetoverview}
\end{figure}

Das besondere im Zusammenhang mit den RFID-Standardisierungsbemühungen rund um das EPCglobal Network ist, dass man sich nicht nur darauf beschränken wollte, die RFID-Luftschnittstelle und das Kommunikationsprotokoll zwischen Lesegerät und Transpondern festzuschreiben, sondern sich auch gleich daran machte, eine unternehmensübergreifende - ja, weltweite Kommunikationsarchitektur zu entwerfen. Das gesamte Konzept dieser Architektur zielte darauf ab, dass es auf dieser Basis möglich sein sollte, die unterschiedlichsten Anwendungen zu implementieren - und zwar soweit es möglich ist mit Hilfe bereits vorhandener Technologien. Hier kommen wir auch gleich auf den Spitznamen zu sprechen, der sich im Zusammenhang mit dem EPCglobal Network eingebürgert hat: \textit{Das Internet der Dinge}. Sehen wir uns mal eine Tabelle an, in welcher Analogien zwischen dem Internet und dem EPCglobal Network gezogen werden:

\begin{figure}[h]
	\centering
		\includegraphics[width=0.80\textwidth]{graphics/tabelle.png}
%	\caption{}
	\label{fig:tabelle}
\end{figure}

Zudem kommen im EPCglobal Network solche bekannten Technologien wie XML und WebServices zur Anwendung.

Das EPCglobal Network Szenario sieht vor, dass in Zukunft jedes individuelle Objekt eine eigene Homepage besitzt, welche wiederum aus dem EPCglobal Network aufgerufen werden kann. Diese Homepage soll irgendwo im Internet liegen und wird nach aktueller Sichtweise normalerweise vom Produzenten des Objektes unterhalten - es ist aber auch vorgesehen, dass der ONS gleich mehrere Verweise auf unterschiedliche Homepages für eine Objekt-ID zurückliefern kann, sodass auch noch andere als nur der Produzent/Hersteller eines Objektes eine Homepage einrichten können. Mögliche Informationen auf solch einer Homepage könnten sein: Produktbeschreibungen, Haltbarkeitsdatum, Verkaufs- und Versanddaten, Wartungsanweisungen, Gebrauchsanweisungen, Signaturen- und Echtheitszertifikate, die aktuelle Position in der Supply Chain und vieles mehr. Die Summe der Homepages aller Objekte ergibt dann schließlich den gesamten Informationsgehalt dieses "`Internet der Dinge"'. Um ehrlich zu sein, sollte es wohl besser "`Internet über die Dinge"' heißen, da die Dinge dort selber nicht vertreten sind, sondern nur die Beschreibungen und Informationen über sie. Die Dinge selber (in der realen Welt) lösen primär nur das Eintragen neuer Datensätze in ihre Homepage aus oder verweisen wie ein Link aus der realen Welt in die virtuelle Welt, um dort Informationen abrufen zu können. Konkret stellt das EPCglobal Network in der heute beabsichtigten Form also nur eine Untermenge der Eigenschaften dar, die man sich unter einen Begriff wie "`Internet der Dinge"' vorstellen kann. Eine Einbindung "`intelligenterer"' Objekte die direkt und selbständig im "`Internet der Dinge"' interagieren könnten, fehlt zum Beispiel völlig. Man bedenke auch, dass nicht nur das EPCglobal Network den Spitznamen "`Das Internet der Dinge"' für sich in Anspruch nimmt - auch andere Projekte, wie zum Beispiel das Cooltown-Projekt (initiiert durch Hewlett-Packard), erheben zurecht Anspruch auf diesen Beinamen.

Trotzdem muss auch der lesende und schreibende Zugriff auf "`nur"' eben diese Daten innerhalb des EPCglobal Networks irgendwie geregelt werden. Dazu sind die EPC Security Services angedacht. Aber wie vieles im Rahmen des EPCglobal Networks sind diese bei weitem noch nicht fertig spezifiziert. Dazu möchte ich Christian Flörkemeier von der ETH Zürich zitieren [floerk]: "`Zusammenfassend lässt sich festhalten, dass die Standardisierungsbemühungen des Auto-ID Centers bzw. der Nachfolgeorganisation EPCglobal zum jetzigen Zeitpunkt noch nicht abgeschlossen sind. Am weitesten fortgeschritten sind dabei die Protokolle, die die Kommunikation zwischen Lesegerät und den Transpondern sicherstellen. [...] Weit fortgeschritten sind ebenfalls die Standardisierungsversuche bzgl. der EPC-Datenstruktur und des ONS-Systems. [...] Um die Vision zu realisieren, mit RFID-Transpondern gekennzeichnete Objekte überall automatisch verfolgen zu können, ist es noch ein weiter Weg. [...] Nicht zu unterschätzen ist dabei der Datenschutzaspekt, der sich durch eine Allgegenwertigkeit der RFID-Transpondertechnik ergeben dürfte [...]."'

\section{Thesis Outline: Das Internet \underline{mit} Dingen}

Treten wir jetzt erstmal wieder zwei Schritte zurück und vergessen das EPCglobal Network und alle anderen Techniken rund um RFID. So - stellen wir uns nun vor, dass wir ein ganz normaler privater Konsument sind, der gerade in seinem Wohnzimmer sitzt. Es ist Abend. Die 19 Uhr heute-Nachrichten sind gerade vorbei. Um uns herum liegt eine große Anzahl an elektronischen Geräten und wenn wir ehrlich sind, wissen wir eigentlich gar nicht, was wir alles damit anstellen können. Theoretisch könnte es für das eine oder andere Gerät hier um uns herum sogar eine Software geben, mit der wir einen weiteren Nutzen - einen Mehrwert - aus eben diesem Gerät ziehen könnte. Aber wir wissen es nicht. Wir wissen weder, dass es da etwas geben könnte, noch wissen wir, wie wir eigentlich im Internet danach suchen sollte. Schön wäre es, wenn wir jetzt mit unserem PDA den einen oder anderen Gegenstand berühren könnte, um nach einigen Sekunden auf dem Display des PDAs eine Liste von Softwareprodukten sehen zu können, die jedes für sich versprechen würden, mit eben diesem berührten Gegenstand irgendetwas sinnvolles anstellen zu können. Besonders schön wäre es natürlich, wenn diese Liste nach irgendwelchen Maßstäben sortiert, in Kategorien unterteilt und womöglich sogar gefiltert wäre. Aber wir wollen es ja nicht gleich übertreiben. Ersteinmal freuen wir uns schon darüber, dass wir überhaupt eine kompakte Liste an in Frage kommender Software präsentiert bekommen - zudem sogar mit einer jeweils kurzen Erläuterungen, was die Software angeblich so alles macht können soll.

Nun kommt der nächste Schritt: Wir haben in der Liste ein Stück Software gefunden, welches unser Interesse geweckt hat. Wir klicken also auf den Button gleich unter der kurzen Programmbeschreibung. Auf diesem Button steht: \textit{"`Kostenloses Trial-Angebot"'}. Und wir wissen - bei kostenlos kann man eigentlich nie etwas so richtig falsch machen... Schon nach wenigen Sekunden ist die Software heruntergeladen bzw. ein Teil davon. Denn wie ein guter Freund uns mal erzählt hat, wird bei diesem neuen System nicht mehr die komplette Software aus dem Internet geladen, sondern nur noch ein "`Kernbestandteil"'. Einzelne Teile bzw. Methoden bleiben beim Softwarehersteller und werden von diesem "`Kernbestandteil"' über das Internet abgerufen - durch sogenannte WebServices. Der Softwarehersteller kann nun entscheiden, ob diese WebServices für den jeweiligen Kunden nur "`Trail-Funktionalitäten"' bieten oder aber den vollen Funktionsumfang.
Aber zurück zu diesem "`Kernbestandteil"', den wir gerade heruntergeladen haben. Unser PDA fragt uns nun, ob wir der Person oder Firma vertrauen, die dieses Stück Software signiert hat und ob wir die Software zur Ausführung bringen wollen. Wir bestätigen sogleich mit \textit{"`Ja"'}.

Wie uns unser Freund bereits erzählt hat, ruft dieses Stück Software jetzt immer, wenn es eine Funktion nicht selber bereithält, diese WebServices beim Hersteller auf, um weiterarbeiten zu können. Aber das ist nicht alles. Über den selben Weg, wie der PDA das Gerät erkannt hat, für welches diese Software nun bestimmt ist - der Weg heißt nebenbei gesagt RFID-Lesegerät - kommuniziert nun der PDA bzw. dieser "`Kernbestandteil"' mit eben diesem Gerät. Dazu "`übersetzt"' das RFID-Lesegerät die RFID-Hardwaredatenschnittstelle in einzelne WebServices, sodass es für den Programmierer des "`Kernbestandteils"' vollkommen transparent ist, ob er nun auf einen "`HardwareService"' des Gerätes oder einen "`SoftwareService"' des Softwareherstellers zugreift.

Nach einigen Minuten des Ausprobierens der soeben heruntergeladenen Software sind wir nun überzeugt. Die Software gefällt uns und wir wollen den vollen Funktionsumfang nutzen. Also drücken wir auf den kleinen Button unter dem "`Trial-Button"': \textit{"`Vollversion jetzt kaufen"'} steht dort. Nun werden wir aufgefordert unser Mobiltelefon mit dem PDA zu berühren, um den Bezahlvorgang einzuleiten. Gesagt getan und schon piept unser Mobiltelefon und wir bekommen auf dem Telefon die Aufforderung angezeigt den gewünschten Bezahlvorgang über 12,50 Euro zu bestätigen. Nach einer kurzen Bedenkzeit, in der es darum geht, wie man am Ende des Monats der besseren Hälfte diese 12,50 Euro Position in der Telefonrechnung am Besten verständlich machen könnte, drücken wir auf \textit{"`Geldtransfer bestätigen"'}. Nur einige Sekunden später meldet auch schon der PDA, dass die Software nun im vollen Umfang genutzt werden kann. Und schon wieder ein Abend nach dem wir zufrieden ins Bett gehen können...

Nun wollen wir uns aber mal genauer anschauen, was da gerade passiert ist - zumindest etwas genauer, denn das eben beschriebene soll das Szenario sein, in dem sich meine Master-Thesis im nächsten Semester bewegen soll. Was zur Realisierung dieses Szenarios nötig ist, soll Gegenstand dieser Master-Thesis sein.

Im ersten Schritt haben wir ein Objekt, welches mit einem RFID-Dateninterface ausgestattet ist, mit unserem PDA berührt. Der PDA soll dabei über ein RFID-Lesegerät die ID des Gegenstandes auslesen. Unter der Annahme, dass das Format der ID einem der EPC ID Formate entspricht, wissen wir nun, was für ein Gerät dort vor uns liegt. Nehmen wir einmal an, es sei ein digitaler Satellitenempfänger der Firma Humax mit der Typenbezeichnung VACI-5300rf. Tatsächlich gibt es nur einen Satellitenempfänger mit der Typenbezeichnung VACI-5300, das "`rf"' am Ende soll nur andeuten, dass es sich um eine neue (leider nicht tatsächlich existierende) Version handeln soll, die statt des RS232-Interfaces ein RFID-Interface besitzt. Anhand der ausgelesenen ID könnten wir nun also im EPCglobal Network beim Hersteller des Gegenstandes nach der genauen Typenbezeichnung suchen, um diese alsdann auf dem Display unseres PDAs anzeigen zu lassen\footnote{Mit etwas Glück findet man beim Hersteller nicht nur die Typenbezeichnung des Objektes, sondern auch gleich noch ein Anleitung, Angebote für passendes Zubehörmaterial und wenn ggf. nötig einen Hinweis auf eine Rückrufaktion auf Grund eines Serienfehlers, der in einer Vertragswerkstatt kostenlos nachbesserbar ist.}. 

Aber in dem beschriebenen Szenario soll ja nicht nur angezeigt werden, was für ein Gerät dort vor einem liegt, sondern zudem auch welche Software es für dieses Gerät gibt. Hier gibt es verschiedene Ansatzmöglichkeiten, die ich in der Master-Thesis beleuchten möchte:

Zum einen besteht die Möglichkeit, dass beim Hardware-Hersteller neben der Typenbezeichnung auch noch eine Auflistung von Softwareprodukten heruntergeladen werden kann, welche mit dem Hardwareprodukt kompatibel sein sollen. Dazu müssten die Software-Hersteller ihre Software beim Hardware-Hersteller eintragen lassen. Desweiteren bestünde aber auch die Möglichkeit, dass der ONS-Server auf die Anfrage mit der ausgelesenen ID nicht nur die Adresse des Servers des Hardware-Herstellers zurück liefern würde, sondern auch die Adressen der Server der passenden Software-Hersteller. 

Ein ganz anderer Ansatz wäre es, dass man einen erweiterten UDDI-Verzeichnisdienst betreibt, der die Suche nach WebServices derart unterstützt, dass man die zu findenden Services so einschränken kann, dass die Services zu bestimmter Hardware kompatibel sein müssen (bzw. dass die Software-"'Kernbestandteile"', den dieser Service dann zurückliefern würde, zu bestimmter Hardware kompatibel sein müssen). Von diesem Blickwinkel aus gesehen, wäre unter anderem die hausinterne Arbeit von Herrn Preuß [Preuss2005], welche sich mit der Erweiterung von UDDI mit OWL-S beschäftigt, auszuwerten.

Eine dritte Möglichkeit bestünde in einem Filesharing-Suchsystem. Hierbei müssten dann die Software-Hersteller sogenannte Konfigurations-Dateien in das Netzwerk stellen, in denen beschrieben steht, welche Company-Prefixes und Item-References in der Geräte-ID vorkommen müssen, damit ihre angebotene Software zusammen mit dem Gerät funktioniert (Hier sei angenommen, dass das Format der IDs dem EPC SGTIN Format entspricht). Wenn man nun eine Suchanfrage an das Filesharing-Netz stellen würde, welche aus der ID des Gerätes bestünde (ggf. gekürzt um die Seriennummer), würden die passenden Konfigurations-Dateien gefunden und heruntergeladen werden können. In den Konfigurations-Dateien könnte dann beschrieben sein, was die Software machen kann und wie und wo man die Software bzw. den "`Kernbestandteil"' herunterladen kann - zum Beispiel von einem FTP-Server oder auch gleich aus dem selben Filesharing-System.

Nun aber weiter: Wir bekommen nun eine Liste an passenden Softwareprodukten, die uns interessieren könnten, präsentiert. In unserem Beispiel mit dem digitalen Satellitenempfänger ist eins dieser Softwareprodukte möglicherweise ein Sendertabelleneditor, der uns verspricht die vielen hundert Fernsehkanäle, die wir mit unserer Anlage empfangen können, auf einfache Weise zu sortieren und in Bouquets zu unterteilen. Als besonderes Highlight bietet uns das Programm sogar an, zusätzliche Kanäle, die bei normalen Suchläufen nicht gefunden werden können\footnote{Sogenannte Feedkanäle}, ebenfalls in unsere Sendertabellen einzupflegen. Dieses Programm wollen wir testen! Also fordern wir die Trial-Version an. 

Dieses Stück Software - dieser "`Kernbestandteil"' - sollte zur Erhöhung des Schutzes vor böswillig schadhaftem Code signiert sein. In welchem Umfang auch dieses Thema in meiner Master-Thesis behandelt wird, steht noch nicht fest.

Dieses Stück Software soll nun über WebServices mit dem über das RFID-Interface angeschlossene Gerät kommunizieren. Hier stellen sich nun gleich wieder zwei neue Frage:
\begin{enumerate}
\item In welchem Gerät soll diese Übersetzung vom RFID-Dateninterface zu WebServices stattfinden?
\item Woher sollen die Informationen stammen, die besagen, wie die Übersetzung stattzufinden hat?
\end{enumerate}


Zur ersten Frage möchte ich in meiner Master-Thesis drei verschiedene Ansätze beleuchten:
\begin{enumerate}
\item Das RFID-Lesegerät beinhaltet ein embedded System welches die Übersetzung vollzieht.
\item Innerhalb des Gerätes, auf dem der "`Kernbestandteil"' zur Ausführung kommt, wird auch die Übersetzung vorgenommen.
\item Ein Dienst innerhalb des privaten Teils des virtuellen Service-Busses übernimmt die Übersetzung.
\end{enumerate}


Zur zweiten Frage, woher die Informationen kommen sollen, wie die Übersetzungen stattzufinden haben, sehe ich zur Zeit drei primär mögliche Ansätze:

\begin{enumerate}
\item Der Hardware-Hersteller liefert die komplette WebService-Software inklusive WSDLs und stellt diese auf der Objekt-Homepage des EPCglobal Networks zur Verfügung.
\item Es existiert vom Hardware-Hersteller ausschließlich eine standardisierte Beschreibung der Register im inneren des RFID-Dateninterfaces. Dort würde zum Beispiel stehen, dass Register A aus 8 Bytes besteht, nur gelesen werden kann und bei neuen Daten ein Interrupt erzeugt, wobei in Register X eingetragen wird, welches Register diesen Interrupt erzeugt hat. Aus solchen Beschreibungen müssten dann automatisiert passende WebServices generiert werden.
\item Die Software-Hersteller liefern zusammen mit ihrer Software die passende WebService-Software oder beziehen diese von anderen Software-Herstellern.
\end{enumerate}

\begin{figure}[h]
	\centering
		\includegraphics[width=0.80\textwidth]{graphics/ueberblick-martin-2.png}
	\caption{Der virtuelle Service-Bus}
	\label{fig:servicering}
\end{figure}

Desweiteren möchte ich beleuchten, inwieweit es sinnvoll wäre, eine Möglichkeit vorzusehen, dass ein "`Kernbestandteil"' von einem Ausführungsgerät zu einem anderen Ausführungsgerät innerhalb des privaten Teils des virtuellen Service-Busses während der Ausführungszeit verschiebbar ist.

Im Rahmen der Master-Thesis soll auch ein für den Benutzer intuitives Bedienkonzept zur gleichzeitigen Interaktion mit mehreren Geräten erarbeitet werden. Dieses Konzept soll auch der Tatsache Rechnung tragen, dass die Reichweite des RFID-Interfaces nicht weiter als 10 cm betragen soll.

Auf Seiten der RFID-Hardware möchte ich evaluieren, inwieweit bereits NFC die Möglichkeiten bietet, die ich für ein Dateninterface über einen passiven Transponder für nötig halte. Unter anderem stellt sich die Frage, ob auch ein passiver Transponder bei NFC in der Lage ist Interrupts an das Lesegerät zu senden.

Sollte zu guter Letzt noch Zeit bleiben, bestünde noch die Möglichkeit einen ersten Technologie-Demonstrator zu entwickeln. Der Demonstrator sollte dann folgendes leisten können: Ein durch ein RFID-Interface angereicherter Taschenrechner soll durch ein mobiles RFID-zu-Service-Bus-Gateway-Gerät erkannt werden. Daraufhin soll eine erfolgreiche Suche nach kompatiblen Software-Produkten durchgeführt werden. Eine der gefundenen Software-Produkte soll es schlussendlich ermöglichen den Taschenrechner als Nummern-Tastaturblock eines PCs/PDAs zu nutzen.

\nocite{bitkom}
\nocite{borrie}
\nocite{cho}
\nocite{ecma}
\nocite{finken}
\nocite{floerk}
\nocite{gs1}
\nocite{heinri}
\nocite{pering}
\nocite{preuss}
\nocite{siegem}
\nocite{smith}

\bibliographystyle{dinat}
\bibliography{bibliography/references}


\end{document}

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: t
%%% End: 



