institut für...
TRANSCRIPT
Arbeitsbericht Nr. 15/2006 Hrsg.: Matthias Schumann
Thomas Diekmann / Svenja Hagenhoff
Ubiquitous Computing-Technologien zur Integration der realen Welt in betriebliche Informationssysteme
Georg-August-Universität Göttingen
Institut für Wirtschaftsinformatik Professor Dr. Matthias Schumann
Platz der Göttinger Sieben 5 37073 Göttingen Telefon: + 49 551 39 - 44 33 + 49 551 39 - 44 42 Telefax: + 49 551 39 - 97 35 www.wi2.wiso.uni-goettingen.de
© Copyright: Institut für Wirtschaftsinformatik, Abteilung Wirtschaftsinformatik II, Georg-August-Universität Göttingen.
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des
Urhebergesetzes ist ohne Zustimmung des Herausgebers unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen,
Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Alle Rechte vorbehalten.
Inhaltsverzeichnis II
Inhaltsverzeichnis
Abbildungsverzeichnis .........................................................................................................................III
Abkürzungsverzeichnis ....................................................................................................................... IV
1 Einleitung ...........................................................................................................................................1
2 Ausgewählte Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld.2
2.1 Embedded Devices......................................................................................................................2
2.2 RFID.............................................................................................................................................6
2.3 Basisfunktionalitäten von Embedded Devices und RFID..........................................................10
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme.................................................................................................14
3.1 Datenorientierte Integration von Ubiquitous Computing-Technologien.....................................14
3.1.1 Speicherung in Netzwerken..............................................................................................16
3.1.2 Objektbegleitender Datentransport...................................................................................19
3.1.3 Integrierte Sichtweise .......................................................................................................23
3.1.4 Zusammenfassung und Beurteilung.................................................................................25
3.2 Funktionsorientierte Integration von Ubiquitous Computing-Technologien...............................25
3.2.1 Web Services zur Integration von Embedded Devices ....................................................27
3.2.2 Eignung ausgewählter Web Service Standards ...............................................................29
3.2.2.1 SOAP..................................................................................................................... 29
3.2.2.2 WSDL .................................................................................................................... 30
3.2.2.3 UDDI ...................................................................................................................... 31
3.2.2.4 BPEL4WS.............................................................................................................. 32
3.2.3 Zusammenfassung und Beurteilung.................................................................................32
4 Zusammenfassung und Ausblick..................................................................................................35
Literaturverzeichnis .............................................................................................................................36
Abbildungsverzeichnis III
Abbildungsverzeichnis
Abbildung 2-1: Grundaufbau eines Embedded Device ............................................................4 Abbildung 2-2: Meilensteine der RFID-Entwicklung .................................................................6 Abbildung 2-3: Grundaufbau eines RFID-Systems ..................................................................8 Abbildung 2-4: Aufbau des EPC.............................................................................................10 Abbildung 2-5: Taxonomie für Embedded Devices ................................................................11 Abbildung 2-6: Basisfunktionalitäten von RFID und Embedded Devices...............................13 Abbildung 3-1: Abbildung der realen Welt in ein Informationsystem......................................15 Abbildung 3-2: EPC-Infrastruktur ...........................................................................................18 Abbildung 3-3: Architektur des objektbegleitenden Datentransports .....................................22 Abbildung 3-4: Architektur zur Integration von Daten aus Ubiquitous Computing-Systemen 24 Abbildung 3-5: Vorgehen bei der Entwicklung einer SOA......................................................26 Abbildung 3-6: Einordnung von Web Service Standards in die WSA ....................................29 Abbildung 3-7: Integration von Embedded Devices in eine SOA mittels Web Services ........33
Abkürzungsverzeichnis IV
Abkürzungsverzeichnis
ALE Application Level Events
BPEL4WS Business Process Execution Language for Web Services
CGI Common Gateway Interface
DARPA Defense Advanced Research Projects Agency
DNS Domain Name System
EAN European Article Number
EEPROM Electrically Erasable Programmable Read-Only Memory
EPC Electronic Product Code
ESP Elektronisches Stabilitätsprogramm
FRAM Ferroelectric Random Access Memorie
GPS Global Positioning System
HTML HyperText Markup Language
IEEE Institute of Electrical and Electronics Engineers
IrDA Infrared Data Association
ONS Object Naming Service
PAN Personal Area Network
RFID Radio Frequency Identification
SMTP Simple Mail Transfer Protocol
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SRAM Static random access memory
UDDI Universal Description, Discovery and Integration
UPC Universal Product Code
WLAN Wireless Local Area Network
WSA Web Service Architecture
WSDL Web Service Description Language
XML Extensible Markup Language
1 Einleitung 1
1 Einleitung
Ubiquitous Computing-Technologien sollen zukünftig in alle Lebensbereiche Einzug halten. Somit
stellt sich auch für Unternehmen die Frage, welche Ubiquitous Computing-Technologien für sie
relevant sind. Die im Ubiquitous Computing-Zeitalter erwartete große Gerätediversifikation (vgl.
Hansmann 2003, S. 18) macht es für Unternehmen schwierig, relevante Technologien zu
identifizieren. Ziel der folgenden Ausführungen ist es daher, ausgewählte Kategorien von Ubiquitous
Computing-Technologien darzustellen, die als besonders relevant für das betriebliche Umfeld erachtet
werden. Als Grundlage für weitergehende Untersuchungen, soll anhand der verschiedenen
Gerätemerkmale eine Taxonomie der dargestellten Ubiquitous Computing-Technologien entwickelt
werden. Anschließend werden Basisfunktionalitäten für das betriebliche Umfeld dargestellt, die durch
Ubiquitous Computing-Technologien ermöglicht werden.
Während prototypische Umsetzungen von Ubiquitous Computing-Anwendungen auf der „grünen
Wiese“ erfolgen, müssen bei dem Unternehmenseinsatz bestehende Strukturen beachtet werden. So
stellt sich speziell die Frage, wie Ubiquitous Computing-Technologien in die bestehenden
betrieblichen Informationssysteme integriert werden. In Kapitel 3 wird diese Frage aus zwei
Perspektiven betrachtet. Zum Einem soll die Integration aus einer datenorientierten, zum anderen aus
einer funktionsorientierten Sichtweise beleuchtet werden.1
Den Abschluss der Untersuchung bilden eine Zusammenfassung der Ergebnisse der Untersuchung
und ein Ausblick auf zukünftige Forschungsfragen.
1 Zwar findet in Unternehmen heutzutage zumeist eine objektorientierte Perspektive Anwendung, die Verwendung der funktionsorientierten und der datenorientierten Perspektive steht aber nicht im Widerspruch dazu, da die beiden Perspektiven inhärent mit der objektorientierten Perspektive verbunden sind. In der Objektorientierung stellt ein Objekt eine Zusammenfassung von Aufgabeobjekt (Daten) und Aufgaben (Funktionen) dar. (vgl. Jung 2006, S. 41 ff.). Die objektorientierte Perspektive wird in der Untersuchung also implizit berücksichtigt.
2 Ausgewählte Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld 2
2 Ausgewählte Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld
Im Folgenden werden Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld
vorgestellt. Mit Embedded Devices wird eine Geräteklasse dargestellt, die die im Ubiquitous Computing
verfolgte Verschmelzung der physischen mit der digitalen Welt ermöglichen soll. Sie stellen die
technologische Grundlage der von Weiser formulierten Vision des Ubiquitous Computing dar und sollen
relativ abstrakt aus Sicht des Ubiquitous Computing als Forschungsbereich erläutert werden. Während
Embedded Devices, wie sie im Folgenden beschrieben werden, noch am Anfang der Entwicklung
stehen, steht mit RFID eine marktreife Technologie zur Verfügung, mit der viele Ubiquitous Computing-
Szenarien bereits heute realisiert werden können. Abschließend wird gezeigt, dass es sich bei den
beiden erläuterten Technologien nicht um verschiedene, sondern um komplementäre Technologien
handelt. Es wird eine Taxonomie vorgestellt, die es ermöglicht verschiedene Ausprägungen der beiden
Technologien zu systematisieren und es werden Basisfunktionalitäten beschrieben, die im betrieblichen
Umfeld von Embedded Devices und RFID übernommen werden.
2.1 Embedded Devices
Eine der Grundideen des Ubiquitous Computing ist es, Gegenstände mit Computern zu kombinieren
um sie so „smart“ werden zu lassen. Die Computer werden in die physische Welt quasi „eingebettet“,
weshalb sie auch als Embedded Devices bezeichnet werden. Die mit den Embedded Devices
ausgestatteten Gegenstände werden als smarte Gegenstände oder hybride Artefakte bezeichnet (vgl.
Fleisch/Mattern/Billinger 2003, S. 7). In der Ubiquitous Computing-Literatur werden vielfältige
Einsatzszenarien dieser Embedded Devices beschrieben, die sehr unterschiedliche Anforderungen an
die Hardware und die Software der Embedded Devices stellen. Eine der Grundideen des Ubiquitous
Computing ist es, anstelle von „Universal-Geräten“, die die Anforderungen aller Anwendungen
gleichzeitig erfüllen, Geräte einzusetzen, die speziell auf die Anforderungen der jeweiligen Anwendung
zugeschnitten sind. Dieses impliziert eine starke Diversifikation bspw. hinsichtlich der Rechnerleistung
und der Baugröße (vgl. Hansmann 2003, S. 18 ff.). Neben dem eigentlichen Computer, sind
insbesondere die Schnittstellen des Embedded Devices von Interesse (vgl. Leimeister/Krcmar 2002, S.
1288). Netzwerkschnittstellen sollen es Embedded Devices ermöglichen mit anderen Embedded
Devices bzw. mit anderen Computern zu kommunizieren. In vielen Ubiquitous Computing-Szenarien ist
vorgesehen, dass verschiedene Gegenstände bzw. die dazugehörigen Embedded Devices zur Lösung
einer Aufgabe kooperieren. Dazu ist eine Vernetzung notwendig, über die die notwendige
Kommunikation abgewickelt wird. Sind die Gegenstände an denen die entsprechenden Embedded
Devices gebunden sind mobil, sind kabelgebundene Netzwerkschnittstellen im Regelfall
unzweckmäßig. Die meisten in der Literatur beschriebenen Embedded Devices verfügen daher über
eine funkbasierte oder eine optische Netzwerkschnittstelle, über die eine schnelle und spontane
2 Ausgewählte Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld 3
Vernetzung der Embedded Devices untereinander erfolgen kann. Als besonders geeignete
Technologien werden in der Literatur der Bluetooth- und der IrDA-Standard angeführt, die eine
Vernetzung über relativ kleine Distanzen (< 1m bei IrDA und 10 bzw. 100 m bei Bluetooth) ermöglichen.
Als besonderer Vorteil werden die große Verfügbarkeit, die geringen Kosten, die kleine Baugröße und
der vergleichsweise geringe Energieverbrauch genannt. Für Vernetzungen über größere Distanzen
eignen sich die verschiedenen IEEE 802.11x-WLAN-Standards, die allerdings einen relativ hohen
Energieverbrauch haben (vgl. Want/Borriello/Farkas 2002, S. 37 f.).
Eine weitere wichtige Schnittstelle von Embedded Devices stellt die zur physischen Umwelt dar.
Verschiedenen Sensoren (Beschleunigung, Helligkeit, Temperatur) ermöglichen es Embedded Devices
Daten aus der physischen Umwelt zu sammeln. Die Entwicklungen im Bereich
mikroelektromechanischer Systeme haben in der Sensortechnologie neue Möglichkeiten eröffnet. Bei
dieser Technologie werden mechanische Sensoren mit Technologien der Halbleiterindustrie aus
Silizium realisiert. Die so gefertigten Sensoren sind extrem klein, sehr robust, kostengünstig und zudem
sehr messgenau. Mikroelektromechanische Sensoren werden im großen Stil in Kraftfahrzeugen
eingesetzt. Sie kommen dort beispielsweise als Beschleunigungssensoren für Airbags und
elektronische Stabilitätsprogramme (ESP) zum Einsatz (vgl. Borriello/Want 2000, S. 63). Die mit den
Sensoren gewonnenen Daten sollen Embedded Devices in die Lage versetzen, den Kontext in dem sie
sich befinden zu erfassen. Auf Basis des Kontextes ist es dann möglich, dezentral Entscheidungen zu
treffen bzw. Aktionen auszulösen. Um Aktionen in der physischen Umwelt auszulösen, benötigen
Embedded Devices Aktuatoren (vgl. Fleisch/Mattern/Billinger 2003, S. 6).
Da die Kommunikation von Mensch zu PC bisher vom Benutzer als zu aufwendig und somit oftmals als
störend empfunden wird, soll im Ubiquitous Computing die Kommunikation zwischen Menschen und
Computern weitgehend implizit erfolgen (vgl. Tennenhouse 2000, S. 43 ff.). Die Kommunikation
zwischen und Mensch und Computer soll auf ein Minimum reduziert werden. Es ist angedacht, dass
Computer anhand des Kontextes erkennen, welche Aufgaben sie zu erfüllen haben. Ist dennoch eine
Kommunikation notwendig, so sollte diese so natürlich wie möglich sein. Die Benutzerschnittstellen von
Embedded Devices müssen also möglichst an die menschliche Kommunikation angelehnt sein (vgl.
Mark 1999, S. 677 ff.).
Abbildung 2-1 fasst die grundlegenden Komponenten eines Embedded Device zusammen.
2 Ausgewählte Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld 4
Physisches Objekt
Embedded Device
Netzwerkschnittstelle Sensoren/AktuatorenBenutzerschnittstelle
Sprache, Bilder, Text, Gesten …
Kontext/Aktionen010101010001011000101010011
andere EmbeddedDevices/Computer Benutzer Umwelt
Smarter G
egenstand/H
ybrides Artefakt
Abbildung 2-1: Grundaufbau eines Embedded Device
Neben der hohen Gerätediversifikation ergeben sich aus den vielfältigen Einsatzszenarien von
Embedded Devices weitere Herausforderungen für die Entwicklung von Embedded Devices. Die
größten Herausforderungen sind der Preis, die Größe und die Energieversorgung (vgl. Ammer et al.
2005, S. 301):
- Preis: Da Embedded Devices massenhaft eingesetzt werden sollen, dürfen diese nicht zu teuer
sein.
- Größe: Um Embedded Devices quasi unsichtbar in die Umwelt integrieren zu können, müssen
sie sehr klein sein.
- Energieversorgung: Aufgrund der inhärenten Mobilität vom Embedded Devices, müssen sie
über eine autarke Stromversorgung verfügen. Herkömmliche Energiespeicher (Batterien etc.)
sind wegen ihrer geringen Energiedichte i. d. R. nicht geeignet.
Starke Impulse haben Embedded Devices aus der militärischen Forschung erhalten. Im militärischen
Bereich sind Konzepte angedacht, in denen Embedded Devices eingesetzt werden, um in
Kriegsgebieten dezentral Informationen zu sammeln. Sie sollen als „Smart Dust“ von Flugzeugen
abgeworfen werden, am Boden Daten über die physische Umgebung sammeln, sich untereinander
vernetzen und die Daten zu einem Gesamtbild am Boden zusammensetzen. So könnten beispielsweise
anhand von Erschütterungen Bewegungen feindlicher Truppen erfasst werden. Vor diesem Hintergrund
hat die in den USA für die militärische Forschung zuständige Defense Advanced Research Projects
Agency (DARPA) erhebliche Mittel in die Entwicklung von Embedded Devices gesteckt (Mattern 2003,
S. 20).
Der Aufwand Hardware speziell für eine bestimmte Anwendung zu entwickeln ist sehr hoch. Einige
wissenschaftliche Einrichtungen haben sich deshalb als Ziel gesetzt, generische Hardwareplattformen
zu entwerfen, mit denen verschiedene Anwendungsszenarien realisiert werden können (vgl. Ammer et
al. 2005, S. 303 ff.). Die entwickelten Plattformen sind im Grundaufbau sehr ähnlich. Sie sind zumeist
2 Ausgewählte Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld 5
modular aufgebaut und verfügen über ein Prozessorboard, eine Sensoreinheit zur Erfassung des
Kontexts, eine eigene Stromversorgung und eine Netzwerkschnittstelle um ad-hoc mit anderen Geräten
zu kommunizieren. Anfänglich waren die Testplattformen zumeist noch relativ groß (etwa 10 cm³),
verfügten aber über vergleichsweise hohe Rechenkapazitäten (z. B. „WINS“ der UCLA (vgl.
Lin/Sanchez/Kaiser 1998), „PicoNodeI“ aus Berkley (vgl. Rabaey et al. 2000, S. 42 ff.), „µAmps-I“ des
MIT (vgl. Min et al. 2000, S. 581 ff.)). Folglich war der Stromverbrauch dieser Plattformen für den
Einsatz in realitätsnahen Anwendungsszenarien signifikant zu hoch. Spätere Entwicklungen
vernachlässigten deswegen die Prozessorleistung zugunsten der oben erläuterten Herausforderungen
Preis, Größe und Energieversorgung. An der UC Berkeley wurde beispielsweise mit „COTS“ eine
Plattform aus elektronischen Standardkomponenten entwickelt, die eine geringe Baugröße mit einem
geringem Preis und einem sehr kleinen Energieverbrauch verbindet (vgl. Hollar 2000, S. 6 ff.).
Die in den vorangegangenen Ausführungen beschriebenen Prototypen werden in der Literatur unter
dem Begriff „Wireless Sensor Nodes“ zusammengefasst. Sie dominieren die Literatur zu Embedded
Devices, was sicherlich nicht zuletzt an der o. a. Smart Dust-Inititiative der DARPA liegt. In der Literatur
wird aber auch immer wieder darauf hingewiesen, dass in den meisten Anwendungsszenarien Wireless
Sensor Nodes alleine nicht ausreichend sind. Aufgrund ihrer sehr begrenzten Energieversorgung und
den damit verbundenen Restriktionen hinsichtlich der Rechenkapazität, ist oftmals eine
Zusammenarbeit mit leistungsfähigeren Embedded Devices notwendig. Systematisiert man die zum
Einsatz kommenden Embedded Devices hinsichtlich der Größe, der Energieversorgung und der
Mobilität, so kann man drei Kategorien unterscheiden (vgl. Snijders 2005, S. 260):
- „Autonomous micro devices“ sind sehr klein und müssen über ihren gesamten Lebenszyklus
autonom agieren (z. B. Daten sammeln) können. D. h. sie müssen die für den Betrieb benötigte
Energie aus ihrer Umwelt gewinnen (Solarzellen, Vibrationen, elektromagnetische Felder). Da
sie vornehmlich mit anderen Embedded Devices kommunizieren, werden sie in der Regel über
keinerlei Benutzerschnittstelle verfügen. Die oben beschriebenen Wireless Sensor Nodes sind
ein Beispiel für diese Geräteklasse.
- „Portable mini devices“ sind mobile Geräte, die über ausreichend Rechenleistung verfügen um
komplexe Aufgabenstellungen lösen zu können. Viele der dieser Geräte werden über eine
Benutzerschnittstelle verfügen. Die Stromversorgung erfolgt mit Batterien, Brennstoffzellen o. ä.
und erlaubt einen mehrtägigen unterbrechungsfreien Betrieb. In diese Geräteklasse fallen u. a.
die sog. Personal Information Devices (Mobiltelefone, PDAs).
- „Static Maxi Devices“ sind ortsgebunden und hinsichtlich der Rechenleistung und der
Stromversorgung nicht eingeschränkt. Es handelt sich bei diesen Geräten beispielsweise um
Server oder aber auch um andere Infrastruktur wie Bildschirme
2 Ausgewählte Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld 6
2.2 RFID
Die Ursprünge von RFID reichen in die 1940er Jahre zurück (vgl. hierzu und zum Folgenden Landt
2005, S. 8 ff.). Das Militär suchte eine Möglichkeit feindliche Flugzeuge von eigenen Flugzeugen zu
unterscheiden. Ein sog. Transponder – eine Zusammensetzung aus den englischen Begriffen
Transmitter (Empfänger) und Responder (Antwortsender) – im Flugzeug empfängt ein codiertes Signal
und übermittelt daraufhin seine eigene verschlüsselte Identifikation. Das Grundprinzip wird bis heute
vom Militär angewendet. In den letzten Jahrzehnten sind noch eine Reihe weiterer Einsatzgebiete von
RFID - weitgehend unbemerkt von der breiten Öffentlichkeit – erschlossen worden. Seit den 1970er
Jahren finden einfache RFID-Systeme zur Diebstahlsicherung Anwendung. Auf einem an dem zu
sichernden Artikel befestigten Transponder wird gespeichert, ob die Ware bezahlt wurde. Bei Verlassen
des Geschäftes kann diese Information ausgelesen werden. Seit den 1980er Jahren wird RFID
zunehmend zur Identifikation von Tieren in der Landwirtschaft genutzt. In den 1990er Jahren wurde
RFID beispielsweise für Wegfahrsperren, Skitickets und Tankkarten eingesetzt. Mit der
Jahrtausendwende wurde durch Entwicklung eines global gültigen Standards zur Warenidentifikation
(EPC) die Grundlage für den massenhaften Einsatz der RFID-Technologie gelegt.
Neben der technischen Entwicklung von RFID erfolgten parallele Entwicklungen, die letztendlich den
Einsatz der RFID-Technologie ebneten. Abbildung 2-2 fasst die Entwicklung von RFID und die
wichtigsten parallelen Entwicklungen zusammen (vgl. Kern 2006, S. 9 und Melski 2006, S. 7).
1940 1950 1960 1970 1980 1990 2000
• FlugzeugerkennungFreund-Feind
• Warensicherung
RFI
D
Pa
ralle
le E
ntw
ickl
unge
n
• Tieridentifikationbei Nutztieren
• Mautgebühren-system
• Wegfahrsperre
• Zugangskontrolle
• Zeitmessung beiSportveranstaltungen
• Behältermanage-ment
• Personal-ausweis
• Bibliotheken
• Stockmans„Communicationsby Means ofReflected Power“
• Supply ChainManagement
• Erster RFID-Patentantrag durchCardullo
Steigerung der Leistungsfähigkeit der Computer (Miniaturisierung)
Telekommunikation (digitalisierte Datenübertragung, drahtlose Kommunikation)
Globale Vernetzung (Internet)
Fortschritte in Materialwissenschaften (Siliziumchip, Polymertechnologie)
Betriebswirtschaftliche Konzepte (Supply Chain Management etc.)
Abbildung 2-2: Meilensteine der RFID-Entwicklung
Wenn man der Bezeichnung RFID folgt, handelt es sich dabei um eine Technologie, mit der man
Gegenstände über Funkwellen identifizieren kann. Damit konkurriert RFID mit anderen Verfahren der
automatischen Identifikation (vgl. Pflaum 2001, S. 33 f.):
- Optical Character Recognition-Verfahren
- Biometrik
2 Ausgewählte Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld 7
- Chipkarten
- Barcode-Systeme
Der Barcode in Verbindung mit den verschiedenen Standards (EAN etc.) hat sich in den letzten Jahren
in vielen Bereichen etabliert. Für Barcodes sprechen die geringen Kosten, die bei dem Einsatz von
Barcodes entstehen und die große Verbreitung dieser Technologie. Nachteilig sind die fehlende
Möglichkeit sie zu verändern und die geringe Speicherkapazität. Chipkarten haben zwar einen
veränderbaren Datenspeicher mit vergleichsweise hoher Speicherkapazität, um sie auszulesen muss
man aber einen galvanischen Kontakt herstellen. Die weiteren Darstellungen werden zeigen, dass
RFID die Vorteile von Barcodes und Chipkarten verbindet.
Es gibt vielfältige Ausprägungen von RFID-Systemen. Als kleinsten gemeinsamen Nenner kann man
festhalten, dass sich ein RFID-Systems aus mindestens zwei Komponenten zusammensetzt: Der RFID-
Transponder enthält das Identifikationsmerkmal; ein RFID-Lesegerät kann über Funkwellen diese
Identifikation auslesen.
Entsprechend ihres Aufbaus werden vier verschiedene Typen von Lesegeräten unterschieden: Sog.
Gate-Reader sind stationär - bspw. an Verladetoren - montiert, Compact Reader und Mobile Reader
repräsentieren dagegen Kombinationen von Antenne und Lese-/Schreibgerät in kompakten, tragbaren
Gehäusen. Fahrzeuggebundene Reader werden schließlich fest bspw. im Kühlraum eines
Kühltransporters montiert (vgl. Bitkom 2005, S. 26)
Insbesondere über die Ausprägung der Transponder lassen sich die verschiedenen RFID-Systeme
systematisieren (vgl. hierzu und zum folgenden Pflaum 2001, S. 33 ff., Finkenzeller 2002, S. 11 ff.,
Penttilä/Engels/Kivikoski 2004, S. 143 ff. und Bundesamt für Sicherheit in der Informationstechnik
2004). Im Grundaufbau besteht ein Transponder aus einem Chip und einer Antenne. Über die Antenne
wird der Transponder vom Lesegerät ausgelesen. Bei den sog. passiven Transponder dient die
Antenne darüber hinaus zur Stromversorgung. Dazu wird ein vom Lesegerät generiertes magnetisches
oder elektromagnetisches Feld von dem Transponder mittels der Antenne als Koppelelement
(Induktionsschleife, Dipol) in Strom induziert. Außerhalb der Reichweite eines Lesegerätes verfügen die
Transponder über keinerlei Stromversorgung und sind deshalb passiv. Die passive Stromversorgung
schränkt im Vergleich zur aktiven Stromversorgung die Reichweite des Transponders zwar ein, für eine
passive Stromversorgung sprechen aber die tendenziell kleinere Baugröße und niedrigere Kosten eines
solchen Transponders. Aktive Transponder verfügen über eine eigene Stromversorgung. Zumeist
werden für die aktive Stromversorgung heutzutage Batterien eingesetzt. Zukünftig ist aber auch
denkbar, dass neue Energieversorgungen wie z. B. Brennstoffzellen eingesetzt werden. Eine
Zwischenform stellen die sog. semi-aktiven Transponder dar. Sie verfügen zwar über eine eigene
Energiequelle, diese wird allerdings nicht zum Senden von Daten genutzt. Dafür wird weiterhin die aus
dem elektromagnetischen Feld des Lesegeräts gewonnene Energie genutzt. Abbildung 2-3 zeigt den
Grundaufbau eines (passiven) RFID-Systems (vgl. Finkenzeller 2002, S. 7).
2 Ausgewählte Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld 8
Energie, Takt, Daten
Identifikation/DatenLesegerät Datenträger
Kopplungselement
Applikation
Abbildung 2-3: Grundaufbau eines RFID-Systems
In RFID-Systemen werden verschiedene Frequenzspektren verwendet, die zumeist weltweit oder
regional lizenzfrei genutzt werden können. Das verwendete Frequenzspektrum ist eines der
Hauptdeterminanten für die Reichweite der Funkübertragung. Darüber hinaus schränkt die zumeist
gesetzlich regulierte Sendeleistung die Reichweite ein. Tabelle 2-1 fasst die wichtigsten Frequenzen,
ihre Anwendung und die typische Reichweite zusammen (in Anlehnung an Bitkom 2005, S. 14 und
Lampe/Flörkemeier/Haller 2005, S. 78).
Frequenz Anwendung typische Reichweite
135 kHz
(Niederfrequenz, LF)
weltweit standardisierte und freigegebene
Frequenz, die zumeist für passive RFID-Tags zur
Tieridentifikation genutzt wird
< 1,5 m
13,56 MHz
(Hochfrequenz, HF)
weltweit standardisierte und freigegebene Fre-
quenz, die für passive RFID-Tags zur
Identifikation von einzelnen Objekten genutzt wird
< 1,0 m
868 MHz
(Ultrahochfrequenz,
UHF)
in Europa standardisierte und freigegebene
Frequenz für aktive und passive RFID-Tags in der
Logistik
< 3 m (bei erlaubten 0,4
Watt Sendeleistung)
3-5 m (bei (geplanten) 2
Watt Sendeleistung)
915 MHz
(Ultrahochfrequenz,
UHF)
analog verwendete Frequenz in den USA. RFID-
Tags unterstützen i. d. R. beide Frequenzen um
globale Logistikanwendung zu ermöglichen
5-7 m (bei erlaubten 4
Watt Sendeleistung)
2,45 GHz
(Mikrowelle, MW)
weltweit freigegebenes lizenz- und anmeldefreies
Frequenzband für Industrie, Wissenschaft und
Gesundheit. Wird für aktive Transponder (GPS,
Temperatursensoren) eingesetzt
keine Angabe möglich
Tabelle 2-1: RFID-Frequenzbereiche und ihre Anwendung
2 Ausgewählte Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld 9
Ein weiteres Unterscheidungsmerkmal von Transpondern ist die Fähigkeit Daten zu speichern. Die
einfachsten Transponder können ein Bit speichern. Mit solchen Transpondern können beispielsweise
Diebstahlsicherungen (s. o.) realisiert werden. Andere Transponder enthalten ausschließlich ein
Identifikationsmerkmal (Seriennummer), das i. d. R bereits während der Produktion des Chips
aufgebracht wird und später nicht mehr veränderbar ist. Sollen die auf dem Chip gespeicherten Daten
veränderbar sein, so werden drei verschiedene Technologien eingesetzt. Bei passiven Transpondern
kommen hauptsächlich EEPROMs (Electrically Erasable Programmable Read-Only Memories) zum
Einsatz. EEPROMs können zwar vergleichsweise günstig hergestellt werden, jedoch haben sie eine
relative lange Schreibzeit und die Leistungsaufnahme während des Schreibens ist sehr hoch. Eine
Alternative sind FRAMs (Ferroelectric Random Access Memories), die jedoch Probleme in der
Herstellung bereiten. Als dritte Möglichkeit können SRAMs (static random access memories) eingesetzt
werden, die zum Datenerhalt eine unterbrechungsfreie Stromversorgung benötigen und deshalb nur in
aktiven Transpondern eingesetzt werden. Mit diesen drei Verfahren ist es möglich Transponder mit
mehreren kBytes Speicherkapazität zu verwirklichen (vgl. Finkenzeller 2002, S. 307 ff.).
Um die auf den Transponder gespeicherten Daten vor unberechtigten Zugriff zu schützen, muss eine
Logik auf dem Chip vorhanden sein, die den Lese- und Schreibzugriff steuert. Im einfachsten Fall kann
dies durch Zustandsautomaten realisiert werden, die als Schaltung bei der Herstellung des Chips
realisiert werden. Da diese Logik aber fest „ins Silizium gegossen“ ist, kann sie nicht umprogrammiert
werden. Bei komplexeren Chips wird deshalb eine von-Neumann-Architektur realisiert, die es erlaubt,
dass die Logik anwendungsspezifisch angepasst werden kann. Neben primitiven (proprietären)
Maschinensprachen ist es auch denkbar, dass höhere (offene) Programmiersprachen zum Einsatz
kommen (vgl. Finkenzeller 2002, S. 281 ff.).
Die Bauform eines Transponders lässt sich sehr variabel gestalten. Üblicherweise werden Transponder
in Glaszylindern, Etiketten, Kunststoffhüllen oder in metallischen Behältern integriert. Die Bauform
hängt stark von dem geplanten Einsatzgebiet der Transponder ab. So sind beispielsweise Etiketten für
die Kennzeichnung von Produkten im Einzelhandel und Glaszylinder für den Einsatz unter widrigen
Umweltbedingungen (chemische Einflüsse) besonders gut geeignet.
Wie die vorangegangenen Ausführungen zeigen, können die Ausprägungen von RFID-Systemen sehr
vielfältig sein. Mit dem Ziel Standards und Normen für Transponder, Lesegeräte und die unterstützende
Infrastruktur zu entwickeln, wurde 1999 das Auto-ID Center gegründet. Einheitliche Standards sollen
ein globales „Internet der Dinge“ ermöglichen, in dem jeder Gegenstand eindeutig identifiziert und über
Unternehmens- und Ländergrenzen hinweg lokalisiert werden kann (vgl. Sarma/Brock/Ashton 2000, S.
4). Zentrales Element der Bemühungen des Auto-ID Center (bzw. der Nachfolgeorganisation
EPCGlobal) ist die Standardisierung eines global gültigen Identifikationscodes, des sog. Electronic
Product Codes (EPC). Der EPC ist ein reines Identifikationsmerkmal und lässt im Gegensatz zu
anderen Standards keine Integration von Objektattributen (z. B. Preis, Gewicht) zu. In seiner jetzigen
Form umfasst der EPC 96 Bit. Um die Skalierung zu gewährleisten, ist eine Unterteilung in Header,
EPC Manager, Object Class und Serial Number vorgesehen. Im Header wird die Version des EPC-
Standards codiert. Über den EPC Manager kann die Organisation bzw. das Unternehmen identifiziert
2 Ausgewählte Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld 10
werden, das für die Vergabe der folgenden Felder verantwortlich ist. Anhand des Felds Object Class
lassen sich verschiedene Objektklassen bzw. verschiedene Artikel (z. B. 1-Liter-Flasche Apfelsaft)
unterscheiden. Mit dem Feld Serial Number wird eine eindeutige Seriennummer zugeordnet. Abbildung
2-4 stellt den Aufbau des EPCs dar (vgl. Machemer 2004, S. 29).
Electronic Product Code (EPC)
Header(8 Bit)
EPC Manager(28 Bit)
Object Class(24 Bit)
Serial Number(36 Bit)
Abbildung 2-4: Aufbau des EPC
Ursprünglich war angedacht, dass der beschriebene EPC universell eingesetzt wird. Um die
Kompatibilität zu bestehenden Standards zu wahren, wurden aber auch domänenspezifische EPC-
Typen entwickelt. Beispielsweise wurde ein EPC-Typ entwickelt, der die bestehenden European Articel
Number (EAN) bzw. den Universal Product Code (UPC) um eine Seriennummer und einen sog. Filter
Value erweitert. Der Filter Value enthält Informationen darüber, ob es sich bei dem betreffenden Objekt
um einen Einzelartikel, eine Kiste oder eine Palette handelt. Anhand des Filter Value kann ein
Lesegerät so beispielsweise auf das Auslesen von Paletten beschränkt werden (vgl. Flörkemeier 2005,
S. 90 f.).
2.3 Basisfunktionalitäten von Embedded Devices und RFID
In Kapitel 2.1 wurde eine Systematisierung von Embedded Devices in drei Gerätekategorien vorgestellt,
die auf die Gerätemerkmale Größe, Energieversorgung und Mobilität beruht. Wie die Ausführungen zu
Embedded Devices aber gezeigt haben, resultiert die angesprochene Gerätediversifikation aus
wesentlich mehr Gerätemerkmale. Im Folgenden soll eine Taxonomie vorgestellt werden, die eine
Systematisierung, die wesentlich mehr Gerätemerkmale berücksichtigt, ermöglichen soll.
Die Gerätemerkmale ergeben sich direkt aus den Ausführungen in Kapitel 2.1 und sollen hier nicht
noch einmal erläutert werden. Lediglich der Aspekt der eindeutigen Identifizierung eines Embedded
Device wurde, wie in der gängigen Literatur zu Embedded Devices auch, stark vernachlässigt. Wie die
Ausführungen zu RFID aber gezeigt haben, ist ein Identifikationsmerkmal ein sehr wesentlicher Aspekt.
Verfügt ein Embedded Device über ein eindeutiges Identifikationsmerkmal, so kann auch das
dazugehörige Objekt eindeutig identifiziert werden. In dem Klassifizierungsrahmen soll deshalb
unterschieden werden, ob das Identifikationsmerkmal nur lokal, also innerhalb einer bestimmten
Domäne oder global, wie bei dem im Kapitel 2.2 erläuterten EPC, gültig ist.
2 Ausgewählte Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld 11
Identifikation global gültiglokal gültigohne
Bauform/-größe isoliertmit physischem Objekt kombiniert
in physisches Objekt integriert
Netzwerkschnittstelle kabellos(PAN/WAN)kabelgebundenohne
Energieversorgungintern (Batterie, Brennstoffzelle,
kinetisch)induktivüber Stromnetz
Sensorik komplex (GPS)einfach
(Temperatur, Helligkeit, ...)
ohne
Datenspeicher veränderbarunveränderbarohne
Programmierbarkeit mit offener Programmiersprache
mit proprietärerProgrammierspracheohne
Aktuatorik über proprietäreSchnittstelle
über Standardschnittstelleohne
Benutzerschnittstelle natürlich(Sprache, Gesten etc.)
technisch(Tastatur/Display)ohne
Abbildung 2-5: Taxonomie für Embedded Devices
Während Embedded Devices eher eine abstrakte, z. T. visionär anmutende Geräteklasse für eine
Vielzahl verschiedener Geräte darstellt, handelt es sich bei RFID um eine sehr konkrete, teilweise
sogar schon marktreife Technologie. Vergleicht man die Ausführungen zu Embedded Devices und zu
RFID, so kann man zu dem Schluss kommen, dass auch RFID-Transponder eine Form von Embedded
Devices darstellen. Insbesondere wenn man die Zukunftsperspektiven von RFID einiger Autoren
betrachtet – bspw. die Ausstattung von RFID-Transpondern mit Sensoren und zusätzlichen Speichern
(vgl. z. B. Strassner/Fleisch 2005, S. 46) – fällt es schwer Embedded Devices und RFID voneinander
abzugrenzen. RFID-Transponder sollen deshalb im Folgenden als Embedded Devices behandelt
werden, die über bestimmte Merkmale verfügen. RFID-Transponder
- haben ein global eindeutiges Identifikationsmerkmal,
- werden mit physischen Objekt kombiniert,
- sind über eine kabellose Netzwerkschnittstelle erreichbar und
- werden induktiv (passive Transponder) oder intern (aktive Transponder) mit Energie versorgt.
Optional verfügen sie über einen veränderbaren Datenspeicher und Sensorik.
2 Ausgewählte Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld 12
Bisher wurden Embedded Devices und RFID völlig losgelöst von der Anwendung im betrieblichen
Umfeld beschrieben. Grundsätzlich können Embedded Devices und RFID Aufgaben an der
Schnittstelle zwischen der realen Welt und den betrieblichen Informationssystemen automatisieren und
somit kostengünstiger gestalten. Bei den Aufgaben, die Embedded Devices und RFID übernehmen
sollen, handelt es sich zumeist um Routineaufgaben, die permanent anfallen und bei manueller
Ausführung sehr kostenintensiv sind. Oftmals werden diese sog. Basisaufgaben deshalb bisher nur
sporadisch durchgeführt, wodurch die Qualität der betriebswirtschaftlichen Prozesse u. U. negativ
beeinflusst wird. Neben einer Substitution der manuellen Durchführungen von Aufgaben, werden die
Aufgaben aufgrund der geringe Kosten auch öfter durchgeführt (vgl. Fleisch/Mattern/Billinger 2003, S.
615 f.). Trotz der Vielfalt der Aufgaben, die Embedded Devices und RFID im betrieblichen Umfeld
übernehmen sollen, werden sie grundsätzlich durch fünf Basisfunktionalitäten ermöglicht (vgl
Schoch/Strassner 2003, S. 28 f.):
- automatische Identifikation
- Ortsverfolgung
- Überwachung
- Notifikation
- Aktion
In den Ausführungen zu RFID wurde die besondere Bedeutung einer eindeutigen automatischen Identifikation von Objekten bereits hervorgehoben. Zwar gibt es andere automatische
Identifikationstechnologien, die eine ähnliche Funktionalität bieten, mit den neuen Technologien können
viele Prozesse, die eine automatische Identifikation voraussetzen, aber effizienter gestaltet werden. Da
die automatische Identifikation auch in Bereichen eingesetzt werden kann, in denen herkömmliche
Technologien bspw. aufgrund von widrigen Umweltbedingungen ungeeignet sind, kann es darüber
hinaus zu einer Verbesserung der Effektivität solcher Prozesse kommen (vgl. Strassner 2005, S. 112).
Verknüpft man die automatische Identifikation mit einem geographischen Ort, so kann man eine
Ortsverfolgung eines Objekts durchführen (Track & Trace). Bspw. können so die Bewegungen eines
physischen Objekts im Fertigungsprozess in einem Informationssystem abgebildet werden. Technisch
wird die Lokalisierung eines über eine funkbasierte Netzwerkschnittstelle erreichbaren Objekts bspw.
mittels Signalstärkemessung, Fingerprinting oder Signallaufzeitmessungen realisiert. Die Ortung über
ein GPS-Signal ist nur für Anwendungen außerhalb von Gebäuden geeignet (vgl. Wilcox 2005, S. 33
ff.). Als nützlicher Nebeneffekt eines umfassenden Track & Trace wird in der Literatur immer wieder der
Diebstahlschutz hervorgehoben (vgl. z. B. Tellkamp/Quiede 2005, S. 147).
Über die Sensoren kann ein Embedded Device den Zustand der physischen Umwelt - dazu gehört auch
der Zustand des physischen Objekts, mit dem es möglicherweise kombiniert ist - erfassen. So ist eine
permanente Überwachung der Umwelt möglich. Die gesammelten Umweltdaten werden ggf.
zwischengespeichert und dahingehend analysiert, ob bestimmte Umweltzustände eintreten. Ein viel
zitiertes Beispiel für die Überwachungsfunktion ist das Embedded Device, das über einen
Temperatursensor die Einhaltung einer Kühlkette überwacht (vgl. Barginda et al. 2005, S. 17).
2 Ausgewählte Ubiquitous Computing-Technologien für den Einsatz im betrieblichen Umfeld 13
Die Notifikationsfunktion erlaubt es Embedded Devices bei Eintreten bestimmter Ereignisse – z. B.
erreichen bestimmter Umweltzustände - Nachrichten abzusetzen. Dazu müssen im Embedded Device
Regeln hinterlegt werden, wie das Embedded Device auf bestimmte Ereignisse reagieren soll (vgl.
Panoff 2005, S. 41). Verfügt das Embedded Device über Aktuatoren so kann es auch eine
Aktionsfunktion wahrnehmen, indem es auf bestimmte Ereignisse nicht nur Notifikationen absendet,
sondern selbst Maßnahmen ergreift.
Um diese Basisfunktionalitäten erfüllen zu können, müssen Embedded Devices über bestimmte
Fähigkeiten verfügen. Für die Identifikationsfunktion muss die Möglichkeit bestehen, auf dem
Embedded Device ein Identifikationsmerkmal zu speichern. Um ein Objekt orten zu können
(Fremdortung), muss es über ein Identifikationsmerkmal und eine kabellose Netzwerkschnittstelle
verfügen. Eine Überwachung von Umweltzuständen setzt Sensoren und ggf.
Datenspeicherungskapazitäten voraus. Um Notifikationsnachrichten generieren zu können, muss ein
Embedded Device über einen Datenspeicher für die Regeln und eine Datenverarbeitungskomponente
für die eigentliche Generierung verfügen. Aktionen können über Aktuatoren durchgeführt werden.
Abbildung 2-6 fasst die technischen Voraussetzungen der Basisfunktionalitäten zusammen.
Identifikation ÜberwachungOrtsverfolgung Notifikation Aktion
Identifikations-merkmal
Netzwerkschnittstelle (kabellos) Sensoren
DatenspeicherDatenverarbeitungs-
komponente
Aktuatoren
Abbildung 2-6: Basisfunktionalitäten von RFID und Embedded Devices
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 14
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme
Mit den in den vorangegangenen Ausführungen dargestellten Technologien werden physische Objekte
um informationstechnische Einheiten ergänzt. Aus Sicht der betrieblichen Informationsverarbeitung
bedeutet dies, dass Daten und Funktionen, die vorher zentral in betrieblichen Informationssystemen
vorlagen, physisch verteilt werden. Im Folgenden soll untersucht werden, wie die physische Verteilung
von Daten und Funktionen überwunden werden kann und sie als logische Einheit wiederhergestellt –
sprich integriert - werden können. Die Betrachtungen erfolgen aus zwei Perspektiven: Die daten-
orientierte Perspektive betrachtet, wie die von Ubiquitous Computing-Technologien erzeugten bzw.
benötigten Daten mit den Datenbeständen in den Informationssystemen integriert werden können
(Kapitel 3.1). In der funktionsorientierten Perspektive wird untersucht, wie durch Ubiquitous Computing-
Technologien ermöglichte Funktionen mittels Web Services in die betrieblichen Informationssysteme
integriert werden können (Kapitel 3.2).
3.1 Datenorientierte Integration von Ubiquitous Computing-Technologien
Daten und die daraus gewonnenen zweckgerichteten Informationen dienen Unternehmen als
Grundlage für Entscheidungen (vgl. Mertens et al. 2005, S. 53). Aufgrund der hohen Bedeutung der
Daten, verfolgt man das Ziel der Datenintegration. „Datenintegration ist der Zustand, bei dem
Aufgabenträger innerhalb eines Untersuchungsbereichs Zugriff auf die Informationsobjekte haben, die
für die Aufgabenerfüllung erforderlich sind. Die Informationsobjekte müssen dabei den aufgaben-
aufgabenträgerspezifischen Qualitätsanforderungen genügen“ (Jung 2006, S. 45). Betrachtet man die
Datenintegration als Vorgang, so werden ursprünglich verteilte Datenbestände entweder zu einem
gemeinsamen Datenbestand zusammengeführt (Datenintegration durch gemeinsame Datenbanken)
oder die verteilten Datenbestände werden verbunden (Datenintegration durch automatische
Datenweitergabe) (vgl. Mertens 2004, S. 1 und Jung 2006, S. 39). Durch eine omnipräsente
Vernetzung nahezu aller IT-Ressourcen ist es heutzutage in der Regel völlig unproblematisch, mittels
Middleware auf verteilte Datenbestände zuzugreifen bzw. von verteilten Anwendungen auf zentrale
Datenbestände zuzugreifen. Die Daten „verhalten“ sich so, „als würden sie sich in konsistenter, d. h.
widerspruchsfreier Form in einer Datenquelle befinden“ (Jung 2006, S. 46). Integrierte
Informationssysteme verschaffen Entscheidungsträgern einen transparenten Datenbestand.
Durch die Speicherung von Daten in Informationssystemen entsteht ein abstraktes Modell der Realität.
Objekte der Realwelt werden in Informationssystemen durch Symbole (Namen, Bezeichnungen)
abstrahiert. Die Abstraktion führt dazu, dass die Realwelt nicht in ihrer Gesamtheit, sondern nur die
relevanten Realitätsausschnitte gespeichert werden. Die offensichtliche Schwierigkeit besteht darin,
dass die laufenden Veränderungen der Realwelt in dem abstrakten Modell abgebildet werden müssen,
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 15
bzw. Änderungen in dem abstrakten Modell zu einer Veränderung der Realwelt führen müssen (vgl.
Hansen/Neumann 2001, S. 992 ff.). Die in dem vorangegangenen Kapitel erläuterten
Basisfunktionalitäten tragen dazu bei, dass dieser Abgleich zwischen der realen Welt und dem
abstrakten Modell vereinfacht wird (vgl. Fleisch/Mattern/Billinger 2003, S. 12). Die Identifikations-, die
Überwachungs- und die Notifikationsfunktion helfen, Veränderungen der realen Welt in das abstrakte
Modell und die Aktionsfunktion hilft Veränderungen des abstrakten Modells in die reale Welt zu
überführen. Durch Ubiquitous Computing-Technologien kann man ein wesentlich genaueres Abbild der
realen Welt generieren. Bildlich gesprochen erhält man durch herkömmliche Technologien ein Schatten
und mit Ubiquitous Computing-Technologien ein Spiegelbild der Realität. Daten, die zur Beschreibung
der realen Welt dienen, werden auch als Nutzdaten bezeichnet. Sie helfen, die betrieblichen
Gegebenheiten und Abläufe zu beschreiben und analysieren. Unter den Begriff Steuerungsdaten fasst
man grundsätzlich Daten zusammen, die den Informationsprozess steuern. Im Folgenden sollen unter
Steuerungsdaten aber auch Daten verstanden werden, die zu Änderungen der realen Welt, also zu
Aktionen führen (vgl. Hansen/Neumann 2001, S. 10). Abbildung 3-1 stellt den Zusammenhang
zwischen der realen Welt und des digitalen Abbilds abstrakt dar.
Reale Welt
Informationssystem
Nutzdaten Steuerungsdaten
Abbildung 3-1: Abbildung der realen Welt in ein Informationsystem
Die Detailliertheit, mit der die Abbildung der realen Welt stattfinden kann, führt aber auch dazu, dass
das Datenvolumen extrem ansteigt. Das bisherige Vorgehen alle Daten in zentralen Datawarehouses
zu speichern um sie dort zu verarbeiten ist mit den zukünftigen Datenvolumen nicht mehr handhabbar.
Vielmehr muss mit Ubiquitous Computing-Technologien dazu übergegangen werden, Daten vor Ort zu
speichern und auch zu verarbeiten (vgl. Heinrich 2005, S. 45 ff.). Um Daten dezentral zu speichern, gibt
es sich grundsätzlich zwei Vorgehensweisen (vgl. Lange 2004, S. 24):
1. Speicherung in Netzwerken (Data-on-Network): Ubiquitous Computing-Technologien wie
RFID und Embedded Devices erlauben eine Echtzeitabbildung der realen Welt in die digitale
Welt (vgl. Heinrich 2005, S. 24 f.). Aufgrund der hohen Datenvolumen werden die gesammelten
Daten in dezentralen Datenbanken gespeichert und verarbeitet. Wie auf diese Daten
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 16
transparent in Netzwerken zugegriffen werden kann, soll am Beispiel der EPC-Infrastruktur im
Kapitel 3.1.1 dargestellt werden.
2. Objektbegleitender Datentransport (Data-on-Tag): Die Grenzen zwischen der realen Welt
und den digitalen Daten verschwimmen zunehmend. Die digitale Welt wird zunehmend in die
reale Welt integriert, was Hinsichtlich der o. a. Datentransparenz verschiedene Implikationen
mit sich zieht. So werden die Daten, die zur Bildung des abstrakten Modells im
Informationssystem benötigt werden, nicht zwangsläufig „online“ gesammelt. Sie werden
vielmehr am „Ort des realen Geschehens“ gesammelt, der nicht unbedingt in Reichweite von
Netzwerken sein muss. Auch ist es nicht immer möglich die Änderungen des abstrakten
Modells „online“ in die reale Welt zu übertragen. Die zur Änderung der realen Welt benötigten
Daten müssen u. U. physisch an dem Ort, an dem die Aktion in der realen Welt durchgeführt
werden soll, vorhanden sein. Es bietet sich also an die Daten an die Objekte, die am
„Geschehen“ beteiligt sind, zu binden. Der sog. objektbegleitende Datentransport soll in Kapitel
3.1.2 dargestellt werden.
Den beiden angeführten Datenspeicherungskonzepten liegen völlig gegensätzliche Herangehens-
weisen zugrunde. Sie sind trotzdem nicht als konkurrierende, sondern als komplementäre Konzepte zu
betrachten. In Kapitel 3.1.3 wird beschrieben, wie die beiden Konzepte kombiniert werden können.
3.1.1 Speicherung in Netzwerken
In Kapitel 2.2 wurde mit dem EPC ein global gültiger Identifikationscode vorgestellt. Er stellt die
Grundlage einer vom AutoID Center bzw. EPCglobal entwickelten, in der Literatur immer wieder als
Internet der Dinge bezeichneten Architektur dar. In dieser Architektur werden RFID-Tags ausschließlich
mit einem EPC-Code ausgestattet. Weitere Speichermöglichkeiten auf dem RFID-Tag sind nicht
vorgesehen. Dadurch sollen die Kosten für einen RFID-Tag auf ein Minimum reduziert werden und ein
Einsatz in großer Breite ermöglicht werden. Ein zweiter wesentlicher Aspekt, den man bei der
Entwicklung der EPC-Infrastruktur im Auge hatte, ist die Speicherung aller objektbezogener Daten in
Netzwerken. Die objektbezogenen Daten sollen über den EPC, der quasi als Zeiger fungiert,
referenziert werden. Im Folgenden sollen die für das Speichern und das Finden bzw. Lesen der Daten
entwickelten Komponenten der EPC-Infrastrukur vorgestellt werden. Anschließend werden die Vor- und
Nachteile dieses Ansatzes diskutiert.
Die Rohdaten der EPC-Infrastruktur werden von den RFID-Lesegeräten erfasst. Sie überprüfen
permanent oder zyklisch, ob sich RFID-Tags in ihrer Nähe befinden. Zwar benötigen RFID-Lesegeräte
im Gegensatz zu Barcodes keinen Sichtkontakt zu den RFID-Tags um sie lesen zu können, durch
Abschirmungen und Reflexionen der Funksignale ist die Zuverlässigkeit des Lesevorgangs u. U. nicht
sehr hoch. So bedeutet das Ausbleiben des Signals eines RFID-Tags nicht zwangsläufig, dass das
entsprechende Objekt sich nicht mehr im Lesebereich des RFID-Lesegeräts befindet. Die Rohdaten
des RFID-Lesegeräts müssen demnach „mit Vorsicht genossen werden“. Filter in den Lesegeräten
sollen die Rohdaten vorverarbeiten und solche Ereignisse herausfiltern. So könnte beispielsweise
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 17
definiert werden, dass erst das Ausbleiben eines Signals für mehr als 3 Sekunden auf ein Entfernen
des entsprechenden Objekts aus dem Lesebereichs des Lesegerätes schließen lässt. Mit solchen
einfachen Regeln kann verhindert werden, dass fehlerhafte Daten in die Datenbasis aufgenommen
werden (vgl. Sarma 2004, S. 55). Auf der nächsten Ebene müssen die Rohdaten der einzelnen
Lesegeräte untereinander abgeglichen werden. Für diesen Zweck wurden die sog. Savants entwickelt.
Savants haben die Aufgabe, die Datenströme der RFID-Lesegeräte zu filtern und zu Ereignissen zu
aggregieren. Die Lesegeräte liefern als Datensätze einfache 3er-Tupel, die Informationen zu dem
erfassten Tag (in Form des EPC), Informationen zu dem Lesegeräts (Identifikationsmerkmal, ggf.
ebenfalls ein EPC) und einen Timestamp enthalten (vgl. De/Basu/Das 2004, S. 175). Es ist
vorgesehen, dass die Lesegeräte diese Informationen in einem Standardformat codieren (z. B. PML
Core) und über offene Internet-Standards wie TCP/IP an die Savants weiterreichen. Die etwa 15.000
Ereignisse, die ein Lesegerät u. U. pro Sekunde generiert, müssen von den Savants gefiltert und
aufbereitet werden (vgl. Palmer 2004, S. 51). Den Savants obliegt es beispielsweise die mehrfache
Erkennung eines RFID-Tags von mehreren Lesegeräten zu einem Ergebnis zu aggregieren um so z. B.
einen Wareneingangereignis zu generieren. Das Ergebnis des Filterns und der Aggregation sind sog.
Application-Level-Events (ALEs), die an andere Applikationen (z. B. ERP-Systeme) weitergegeben
werden können (vgl. Flörkemeier 2005, S. 94). Alternativ können diese Daten auch einen sog. EPC
Information Service weitergegeben werden, der speziell für objektbezogene Daten konzipiert wird.2
Eine Kernaufgabe von EPC Information Services wird die Objektrückverfolgung (Track & Trace) sein.
Sie werden aber auch instanzbezogene Daten zu Objekten, die von allgemeinem Interesse sind, wie z.
B. Herstellungsdatum und Mindeshaltbarkeitsdatum, in EPC Information Services vorgehalten werden
(vgl. Ranasinghe et al. 2005, S. 11 f.).
Die zwischen den Komponenten der EPC-Infrastruktur ausgetauschten Daten sollten ursprünglich in
einem speziell entwickelten XML-Standard - der sog. Product Markup Language (PML) – codiert
werden. Mit PML sollte es möglich sein, Attribute von Objekten (Aufenthaltsort, Besitzer) einheitlich zu
beschreiben. Da sich die Entwicklung eines einheitlichen Standards für alle Anwendungsgebiete als zu
aufwendig herausstellte, erarbeitete man zunächst unter der Bezeichnung PML Core einen Standard,
zum Austausch von Daten, die Lesegeräte generieren (s. o.). Durch die Verwendung von XML können
die Entwickler entsprechender Anwendungen von den weit verbreiteten Werkzeugen zur Generierung
und Überprüfung von XML-Dokumenten profitieren, was den Entwicklungsprozess stark vereinfacht
(vgl. Flörkemeier 2005, S. 95).
Um die gespeicherten Informationen über den EPC referenzieren zu können, wurde der sog. Object
Naming Service (ONS) entwickelt. Der ONS ist sehr stark an den vom Internet bekannten Domain
Name System (DNS) angelehnt. Eine ONS-Anfrage liefert zu einem EPC eine oder mehrere
Internetadressen (URLs), unter der/denen Informationen zu dem entsprechenden Objekt zu finden
ist/sind. Der ONS basiert, somit auf den DNS. Neben den o. a. EPC Information Services können auch
herkömmliche HTML-Seiten referenziert werden. Da der potenzielle Adressraum des EPC (96 Bit)
2 Zurzeit liegt noch keine endgültige Spezifikation vor.
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 18
wesentlich größer ist, als der Adressraum des Internets (32 Bit), waren bei der Entwicklung des ONS
insbesondere Skalierungsfragen von großer Relevanz (vgl. Engels et al. 2001, S. 76 f.).
Abbildung 2-1 fasst die Komponenten der EPC-Infrastruktur zusammen (vgl. Flörkemeier 2005, S. 89).
RFID-Transponder
Lesegerät
Savant
EPC InformationService
Externe Softwareanwendungen
ObjectNamingService(ONS)
PML
PML
PMLDNSProtokoll
Reader-Interface-Protokoll & PML Core
RFID-ProtokolleUHF Class 0/1 &
HF Class 1RFID-Transponder
Abbildung 3-2: EPC-Infrastruktur
Die Speicherung von objektbezogenen Daten in einem Netzwerk, wie es das AutoID Center bzw.
EPCglobal vorsehen, führt zu einer Abkopplung des Objekts von den dazugehörigen Daten. Die Daten
sind also auch verfügbar, wenn das betreffende Objekt nicht vor Ort ist. Die Daten sind jederzeit
zugreifbar und können ggf. verändert werden (vgl. Henrici/Müller 2004, S. 233 ff.). Es bedeutet aber
auch, dass sobald objektspezifische Daten benötigt werden, eine Netzwerkinfrastruktur zwingend
verfügbar sein muss. Die Anforderung dürfte aber selbst in einer stark vernetzten Umwelt, wie man sie
heute vorfindet nicht immer der Fall sein. Da die objektbezogenen Daten u. U. nicht in einer zentralen
Datenquelle, sondern über mehrere Datenquellen hinaus verteilt sind, führt die Suche nach
objektbezogenen Daten zu einem sehr hohen Datenverkehr in den Netzwerken. Es ist daher kritisch zu
hinterfragen, ob eine solche Architektur hinreichend skalierbar ist, dass die Daten in einem 96 Bit
großen Adressraum performant gefunden werden können.
Ein weiterer Problembereich ist die Zugriffssicherheit. In der oben beschriebenen Infrastruktur werden
die Daten in verschiedenen Datenbanken gespeichert und über den EPC referenziert. Es wird kein
standardisiertes Verfahren beschrieben, mit dem der Zugriff auf die Daten reglementiert wird. In der
öffentlichen Diskussion um RFID kommt deswegen auch immer wieder die Angst der Verbraucher zum
Ausdruck, dass Unberechtigte auf die Daten eines im Besitz des Verbrauchers befindlichen Objekts
zugreifen können (vgl. Müller/Handy 2005, S. 1161). Auch aus Sicht von Unternehmen ist der freie
Zugriff auf alle objektbezogenen Daten als kritisch einzustufen. Beispielsweise kann über eine
Objektrückverfolgung betriebswirtschaftliches Know-how ausspioniert werden. Die Datenbanken mit
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 19
den objektbezogenen Daten werden deshalb i. d. R. mit einem spezifischen Zugriffsmechanismus
versehen werden. So kann über den EPC zwar die Datenbanken mit den entsprechenden
Informationen gefunden werden, der Zugriff auf die Daten kann aber verwehrt werden. Sind diese
Zugriffsmechanismen nicht einheitlich gestaltet, so wird die automatische Nutzung der objektbezogenen
Daten erschwert. Es ist daher zu überlegen, ob es nicht sinnvoller ist, Daten am Objekt zu belassen
und somit dem Besitzer des Objektes zentral zur Verfügung zu stellen (s. Kapitel 3.1.2).
3.1.2 Objektbegleitender Datentransport
In der Literatur zu RFID dominiert der Ansatz Daten - wie im vorherigen Abschnitt dargestellt - im
Netzwerk zu speichern (vgl. Henrici/Müller 2004, S. 223 ff.). Zumeist wird dies damit begründet, dass
die RFID-Tags möglichst einfach gehalten werden sollen, damit die Kosten für sie möglichst gering sind
(vgl. z. B. Sarma 2004, S. 52). Es ist aber zu erwarten, dass die Technologie weiterreift und die Kosten
für komplexere RFID-Tags mittelfristig fallen werden. Es ist also zu untersuchen, an welchen Stellen
eine Speicherung von Daten, die über die reine Identifikation hinausgehen, auf dem RFID-Tag sinnvoll
ist.
Im Konzept des objektbegleitenden Datentransports wird die Trennung von physikalischen Objekten
und den dazugehörigen objektbezogenen Daten, wie sie bei herkömmlichen Technologien und
Informationssystemen zu finden ist, aufgehoben. Die Daten, die das physische Objekt in der digitalen
Welt repräsentieren bleiben am Objekt. Möglich wird dies durch RFID-Tags, die über einen eigenen
wieder beschreibbaren Datenspeicher verfügen. Das AutoID-Center bzw. EPCglobal hat sich vor
diesem Hintergrund dazu entschlossen auch Transponder mit erweiterten Funktionalitäten zu
unterstützen. Es sind drei Klassen vorgesehen (vgl. Flörkemeier 2005, S. 96):
- Class 2-Transponder sind passiv und haben einen Speicher mit Sicherheitsfunktionen,
- Class 3-Transponder sind semiaktiv und verfügen ebenfalls über einen Speicher mit
Sicherheitsfunktionen,
- in Class 4-Transponder sind zusätzlich Sensoren integriert.
Durch den objektbegleitenden Datentransport, können Ereignisse in der realen Welt, die eine
Anpassung der digitalen Abbildung des Objekts erforderlich machen, unmittelbar „am Ort des
Geschehens“ erfasst werden, auch wenn keine Netzwerkinfrastruktur vorhanden ist. Die Änderungen
der realen Welt können somit jederzeit in Echtzeit in die digitale Welt übernommen werden. Eine
Verarbeitung dieser Daten am Objekt kann zur Generierung von Nachrichten oder zur Einleitung von
Aktionen führen. Insbesondere in Anwendungsfällen, in denen große Datenmengen simultan anfallen,
kann eine solche dezentrale Vorverarbeitung der Daten zu einer Entlastung zentraler Systeme führen
(vgl. Jansen 2004, S. 64 f.). Die digitale Welt wird so in die Lage zu echtzeitnaher Funktionalität
versetzt.
Ein objektbegleitender Datentransport impliziert aber auch, dass die am Objekt gespeicherten Daten
nur zur Verfügung stehen, wenn das korrespondierende Objekt greifbar, d. h. in Reichweite einer
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 20
entsprechenden Infrastruktur ist. Aus diesem Grund und der Tatsache, dass die Speicherkapazität des
am Objekt angebrachten Datenträgers voraussichtlich auch zukünftig zu klein sein wird, um alle
objektrelevanten Daten am Objekt speichern zu können, werden viele Daten – auch aus
Datensicherungsgründen – in zentralen Systemen redundant gespeichert (vgl. Jansen 2004, S. 65).
Somit kann der objektbegleitende Datentransport als Zwischenspeicherung verstanden werden. Die
Zwischenspeicherung ist für alle Daten sinnvoll, die
- durch das Objekt erfasst werden, wenn sich das entsprechende Objekt außerhalb der
Reichweite einer Netzwerkinfrastruktur befindet (Nutzdaten) oder
- die benötigt werden, um Aktionen, die das Objekt betreffen außerhalb der Reichweite einer
Netzwerkinfrastruktur durchführen zu können (Steuerungsdaten).
Es stellt sich nun die Frage, wie die Daten in den zentralen Datenbeständen mit den
zwischengespeicherten Daten konsistent gehalten werden können. Dazu soll kurz das Konzept des
„Personal Servers“ vorgestellt werden, in dem eine sehr ähnliche Problemstellung vorliegt.
Personal Servers sind mobile Systeme, die die persönlichen Daten eines Anwenders verwalten. Der
Anwender soll in die Lage versetzt werden, jederzeit ortsunabhängig und völlig transparent auf seine
persönlichen Daten zuzugreifen. Die Geräte verfügen über einen Datenspeicher, auf dem die gesamten
oder Teile der persönlichen Daten gespeichert werden können. Im Unterschied zu anderen mobilen
Geräten verfügen Personal Server über keinerlei Benutzerschnittstelle. Vielmehr nutzen sie
Nutzerschnittstellen, die im aktuellen Kontext des Benutzers zur Verfügung stehen. Aus
Datensicherheitsgründen und aus Kapazitätsgründen, ist es notwendig, dass die persönlichen
Datenbestände redundant in zentralen Datenspeichern gehalten werden (vgl. Want et al. 2002, S. 194
ff.). Vergleicht man dies mit dem objektbegleitenden Datentransport, so entspricht die Speicherung der
persönlichen Daten auf einem mobilen Endgerät - dem Personal Server - der Speicherung von
objektbezogenen Daten auf einem RFID-Transponder am Objekt. Man könnte daher von einer
„personenbegleitenden“ Datenspeicherung sprechen.
In der von Helal et al. 2001 entworfenen 3-Schichten-Architektur werden die im Netzwerk gespeicherten
persönlichen Daten des Users (Datenquellen) in einem zentralen Data Warehouse als sog. Working
Sets zusammengeführt. Auf dem mobilen Endgerät wird eine Kopie des Working Sets abgelegt, mit
dem der Anwender arbeiten kann, wenn er sich außerhalb der Reichweite eines Netzwerkes befindet.
Sobald das mobile Endgerät des Anwenders über eine Netzwerkverbindung verfügbar ist, werden diese
Daten mit den Daten im Data Warehouse synchronisiert. Änderungen an den persönlichen Daten, die
während der Netzwerkunterbrechung im Netzwerk bzw. auf dem mobilen Endgerät (Personal Server)
vorgenommen wurden, müssen abgeglichen werden. Um Änderungen an den persönlichen Daten im
Netzwerk zu registrieren, muss im Data Warehouse ein Mechanismus integriert werden, der die
entsprechenden Daten permanent überwacht. Die registrierten Änderungen an den Daten werden in
einem Versionierungssystem im Data Warehouse gespeichert. Der Abgleichvorgang wird durch
Datenquellen-spezifische Regeln gesteuert und nur wenn ein nicht lösbarer Konflikt vorliegt, wird der
Benutzer in den Abgleichvorgang mit einbezogen (vgl. Helal et al. 2001, S. 177 ff.).
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 21
Für den objektbegleitende Datentransport kann eine ähnliche Architektur verwendet werden. An dem
Objekt werden alle objektbezogenen Daten gespeichert, die benötigt bzw. erfasst werden, wenn das
korrespondierende Objekt sich außerhalb der Reichweite einer Netzwerkinfrastruktur befindet. Um
diese Daten mit den in anderen Informationssystemen gespeicherten Daten effizient abgleichen zu
können, werden in zentralen Data Warehouses sämtliche objektbezogenen Daten zusammengeführt.
Anhand eines Versionssystems wird bestimmt, welche Daten wann und wie geändert wurden. Anhand
von Abgleichregeln werden die ggf. inkonsistenten Daten in einen konsistenten Datenbestand
überführt. Da es i. d. R. keine allgemeingültigen Abgleichregeln für alle Daten geben wird, müssen die
Daten im Vorfeld kategorisiert werden und es müssen spezifische Abgleichregeln definiert werden.
Grundsätzlich sind für die beiden o. a. Datenkategorien (Nutzdaten, Steuerungsdaten) folgenden
Abgleichregeln anzuwenden:
- Daten, die ausschließlich vom Objekt gesammelt werden und später grundsätzlich nicht
geändert werden, können von dem Objekt direkt in die zentralen Systeme übernommen
werden.
- Temporäre Daten, die vom Objekt gesammelt werden, können aus dem objektbegleitenden
Datenspeicher gelöscht werden (z.B. Fehlerdaten, die nach einer erfolgreichen Nacharbeit und
Qualitätssicherung nicht mehr am Objekt benötigt werden).
- Daten, die benötigt werden, um Aktionen am Objekt durchführen zu können (Steuerungsdaten),
basieren i. d. R. auf Entscheidungen, die auf Basis der zentralen Daten gefällt wurden. Die
Steuerungsinformationen entstehen also in zentralen Systemen und sollten in die
objektbegleitenden Datenspeicher übernommen werden.
Diese Abgleichregeln sind nicht als Manifeste, sondern vielmehr als Heuristiken zu verstehen; im
Einzelfall kann es sinnvoll sein, von ihnen abzuweichen. Abbildung 3-3 fasst die Grundelemente der
skizzierten Architektur des objektbegleitenden Datentransports zusammen.
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 22
Data Warehouse
Working Sets
Sensordaten/Aktionen
Sensordaten/Aktionen
Netzwerk
Abgleichregeln
Versionssystem
Sensordaten/Aktionen
Sensordaten/Aktionen
Sensordaten/Aktionen
Sensordaten/Aktionen
Sensordaten/Aktionen
Sensordaten/Aktionen
Nut
zdat
enSt
euer
ungs
date
n
Abbildung 3-3: Architektur des objektbegleitenden Datentransports
Durch den objektbegleitenden Datentransport ergeben sich auch neue Aspekte für den Datenschutz
und für die Datensicherheit. Da die am Objekt gespeicherten Daten nur zugreifbar sind, wenn man im
Besitz des Objektes ist, an dem die Daten gespeichert sind, ist der Besitzer des Objekts grundsätzlich
auch der Besitzer der dazugehörigen Daten. Dies ist i .d. R. für allgemeine objektbezogene Daten (z. B.
Herstellungsdatum, Mindesthaltbarkeitsdatum, Handlungsanweisungen zum Umgang mit dem Objekt)
völlig unproblematisch und sogar wünschenswert. Problematischer sind beispielsweise Daten, die bei
der Herstellung des Objekts angefallen und Aufschluss über betriebswirtschaftliches Know-how
enthalten. Ist der aktuelle Besitzer des Objekts nicht der Hersteller des Objekts, so sollten ihm diese
Daten nicht zugänglich sein. Sollen bei einem Besitzerwechsel die Daten nicht mit weitergegeben
werden, so müssen sie entweder gelöscht werden oder geeignet verschlüsselt werden, damit der neue
Besitzer diese nicht lesen kann. In der Praxis ist der Datenspeicher von RFID-Tags deshalb in Bereiche
eingeteilt, die einzeln verschlüsselt werden können. So ist es beispielsweise möglich, dass an
Objekten, die entlang einer Wertschöpfungskette den Besitzer wechseln, von den Unternehmen Daten
gespeichert werden können, ohne der Gefahr ausgesetzt zu sein, dass betriebswirtschaftliches Know-
how ungewollt weitergegeben wird. Auch wird über Zugriffsmechanismen sichergestellt, dass
Personen, die nicht Besitzer des Objekts sind, sich aber in der Nähe des Objekts befinden, unberechtigt
Zugriff auf die Daten erhalten. Mit solchen Zugriffsmechanismen kann auch der in der öffentlichen
RFID-Diskussion im wieder angeführten Gefahr, dass auf RFID-Tags gespeicherte personenbezogene
Daten des Verbrauchers unbemerkt von Dritten ausgelesen werden können (vgl. Müller/Handy 2005, S.
1153 f.), entgegengewirkt werden.
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 23
3.1.3 Integrierte Sichtweise
Folgende Tabelle fasst die wesentlichen Charakteristika der beiden in den vorangegangenen
Ausführungen dargestellten Speicherungsansätze zusammen (vgl. Tabelle 3-1).
Speicherung in Netzwerken objektbegleitender
Datentransport
Konzept Abkopplung der Daten vom
Objekt
Integration der Daten mit dem
Objekt
Voraussetzung für Datenzugriff Netzwerk-Infrastruktur Präsenz des Objekts
Speicherort der Objekt-Daten zentral (Datenbanken) dezentral (Objekt)
Inhalt der Daten auf dem Tag ID (EPC) objektbezogene Daten
Art der Daten auf dem Tag statisch dynamisch
Zusatzfunktionalitäten nicht möglich möglich
Erforderliche Speicherkapazität
auf dem Tag gering hoch
Transponderkosten gering hoch
Standards EPC class 0 und 1 EPC class 2, 3, 4
Datensicherheit Zugriffsmechanismen in DB Verschlüsselung auf dem Tag
Tabelle 3-1: Charakteristika der Speicherungsansätze
Wie aus dem Vergleich ersichtlich, liegen den beiden angeführten Datenspeicherungskonzepten völlig
gegensätzliche Herangehensweisen zugrunde. Beide besitzen Vor- und Nachteile, die sie je nach
Anwendungsfall vorteilhaft erscheinen lassen können. Sie sollten deshalb nicht als konkurrierende
sondern vielmehr als komplementäre Konzepte betrachtet werden, die ggf. parallel eingesetzt werden.
Im Folgenden soll eine integrierte Sichtweise auf die Speicherung von RFID-Daten - bzw. allgemeiner
formuliert von Ubiquitous Computing-Daten – vorgestellt werden.
In der Literatur werden diverse Schichtenmodelle für die Organisation von betrieblichen
Anwendungssystemen zur Verarbeitung von RFID-Daten beschrieben (vgl. z. B. Bitkom 2005, S. 9 und
30 ff.). Obwohl die verschiedenen Architekturmodelle auf den ersten Blick sehr unterschiedlich
aufgebaut sind, ähneln sie sich in ihrer Grundstruktur sehr stark. Ein Hauptgrund für die scheinbare
Heterogenität der Architekturmodelle ist die verwendete Sprache. Mertens 2005 spricht in diesem
Zusammenhang von einer „Fuzzyfizierung“ der Sprache, d. h. Termini werden zunehmend
„missbraucht“ und verlieren ihre Trennschärfe. Auch die häufigen Änderung der verwendeten
Terminologien erschweren das Verständnis (vgl. Mertens 2005, S. 1744 f.).
In den aus der Literatur bekannten Architekturmodellen sollen einfache RFID-Transponder mit denen
Objekte über den EPC eindeutig identifiziert werden können dazu beitragen, dass das Abbild der realen
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 24
Welt in den Informationssystemen aktueller und genauer ist. Dazu müssen die Rohdaten der RFID-
Lesegeräten zu aussagekräftigen Daten aggregiert werden und sie müssen über die Auflösung des
EPC einem Datenobjekt in dem Informationssystem zugeordnet werden. Die aggregierten Daten
können entweder in zentralen Systemen gespeichert werden oder direkt an die Geschäftslogikschicht
weitergegeben werden.
Bei dem objektbegleitenden Datentransport werden die Nutzdaten quasi asynchron mittels eines
Zwischenspeichers erhoben. Die Nutzdaten werden am Objekt gesammelt und sobald eine
Netzwerkinfrastruktur in Reichweite ist, mittels einer Synchronisationskomponente in die zentralen
Datenbestände übernommen.
Auf Basis der Daten, die in der zentralen Datenhaltung zur Verfügung stehen, können die
Geschäftslogik bzw. die Entscheider Entscheidungen treffen, die in Steuerungsdaten resultieren. Die
Steuerungsdaten werden an Terminals weitergeleitet, die beispielsweise papierbasierte Anweisungen
generieren, Anweisungen am Bildschirm anzeigen oder Steuerungsdaten an Betriebsmittel (Maschinen
etc.) weitergeben. Bei dem objektbegleitenden Datentransport können diese Steuerungsdaten am
Objekt zwischengespeichert werden und stehen somit auch zur Verfügung, wenn eine
Netzwerkinfrastruktur nicht zur Verfügung steht.
Werden komplexe Embedded Devices verwendet, so ist es auch denkbar, dass diese direkt mit der
Geschäftslogik kommunizieren. Dieser Ansatz wird in Kapitel 3.2 dargestellt.
AbbildungSpeicherung
Reale W
eltZentrale Datenspeicherung
Datensammlung und Aggregation
Netzwerk
EPC
EPC
EPC EPCEPC
DataWarehouse DBEPC Information
Service
Geschäftslogik
aggregierte Daten
Steu
erun
gsda
ten
Ereignisse
Nutzdaten
Steuerungsdaten
Objekte mit EPC ODT/Embedded Devices
Terminal
ReaderReader
Nut
zdat
en
Datensynchronisierung
Data Warehouse
Working Sets
Abgleichregeln
VersionssystemDatensynchronisierung
Data Warehouse
Working Sets
Abgleichregeln
Versionssystem
Abgleich
Nutzdaten
Steuerungsdaten
Sensordaten/Aktionen
Sensordaten/Aktionen
Sensordaten/Aktionen
Sensordaten/Aktionen
Sensordaten/Aktionen
Sensordaten/Aktionen
Abbildung 3-4: Architektur zur Integration von Daten aus Ubiquitous Computing-Systemen
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 25
Abstrahiert man von dem gewählten Datenspeicherungsansatz (Data-on-Tag bzw. Data-on-Network),
so können drei aufeinander aufbauende Schichten unterschieden werden. Die Abbildungsschicht
ordnet die Gegebenheiten und Abläufe der Realität den digitalen Informationsobjekten zu. Es werden
also automatisiert Nutzdaten generiert, auf deren Basis Entscheidungen getroffen werden können. Die
Nutzdaten werden in einer Datenspeicherungsschicht persistent gespeichert und der Geschäftslogik
transparent zur Verfügung gestellt. Auch die von der Geschäftslogik generierten Steuerungsdaten
werden in dieser Schicht gespeichert. Im Falle des Data-on-Tags können die Steuerungsdaten der
realen Welt zur Durchführung von Aktionen bereitgestellt werden.
3.1.4 Zusammenfassung und Beurteilung
In den vorangegangen Ausführungen wurden zwei verschiedene Datenspeicherungskonzepte
berücksichtigt: Datenspeicherung in Netzwerken (Data-on-Network) und objektbegleitender
Datentransport (Data-on-Tag). Anders als in der Literatur wurden diese beiden
Datenspeicherungskonzepte nicht als gegensätzliche, sondern als komplementäre Ansätze dargestellt.
Der objektbegleitende Datentransport kommt als Zwischenspeicher zum Einsatz, wenn Daten offline
gesammelt oder benötigt werden. Man könnte nun argumentieren, dass mit heutigen
Netzwerktechnologien eine ubiquitäre Netzwerkinfrastruktur in greifbare Nähe gerückt ist und Offline-
Szenarien der Vergangenheit angehören. Jedoch ist der Zugang zu einer Netzwerkinfrastruktur alleine
nicht ausreichend. So sind Zugriffe auf die Informationssysteme eines Unternehmens von Außerhalb i.
d. R. problematisch. Werden Daten beispielsweise entlang der Wertschöpfungskette in verschiedenen
Unternehmen benötigt, so muss für jedes Unternehmen ein Zugriff auf die zentral gespeicherten Daten
gewährt werden. Auch kann der stetige Zugriff auf die zentralen Informationssysteme um
beispielsweise Steuerungsdaten abzurufen, zu einem nicht handhabbaren Netzwerkverkehr führen. Der
objektbegleitende Transport kann also immer dann begründet eingesetzt werden, wenn ein Zugriff auf
die zentralen Daten nicht möglich bzw. nur unter nicht vertretbaren Aufwand möglich ist.
3.2 Funktionsorientierte Integration von Ubiquitous Computing-Technologien
Mit der Einführung der Objektorientierung versprach man sich wiederverwendbare, wartbare und
erweiterbare Software. Doch konnte die Objektorientierung dieses Versprechen einhalten? Betrachtet
man die verschiedenen Verfahren für den Entwurf eines objektorientierten Systems, so verlaufen sie
alle nach dem gleichen Muster (vgl. Schäfer 1994, S. 23 ff.):
1. Identifizieren der Klassen und Objekte
2. Zuweisen von Attributen und Methoden
3. Identifizieren der Beziehungen zwischen Klassen und Objekten
4. Implementieren des Entwurfs
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 26
In dem Paradigma der Objektorientierung konzentriert man sich also vorwiegend auf die Frage aus
welchen Objekten eine Anwendung zu bestehen hat. Dem gegenüber steht die prozessorientierte Sicht
heutiger Unternehmen, die nicht an der Struktur des Unternehmens interessiert sind, sondern vielmehr
daran wie es „funktioniert“. Die SOA soll das Bindeglied zwischen der objektorientierten Sicht der DV-
Abteilungen und der prozessorientierten Sicht der Fachabteilungen sein. Sie baut auf die
objektorientierte Architektur auf, indem sie den vorhandenen objektorientierten Komponenten die
Möglichkeit gibt ihre Funktionalität zu veröffentlichen und Funktionen anderer Komponenten zu finden
und zu nutzen. Funktionalitäten können als so genannte Services über Netzwerke jedermann, egal wo
er sich befindet, angeboten werden. In den Services einer SOA wird in der Regel keine Funktionalität
neu implementiert, sie fungieren vielmehr als Wrapper, die bei Aufruf die Funktionalität bereits
bestehender Applikationen aufrufen, die Ergebnisse sammeln und schließlich zurückgeben (vgl. Alonso
et al. 2004, S. 144). Die Applikationslogik, die die Services kapseln, muss dabei nicht zwangsläufig
objektorientiert programmiert sein, es ist auch eine Kapselung bestehender Legacy-Systeme, wie sie
noch in vielen Betrieben vorhanden sind, möglich.
Durch den Einsatz der SOA wird eine weitere Abstraktionsschicht zwischen die Use Cases und die
Platform Dependent Models eingefügt. Abbildung 3-5 illustriert das Vorgehen bei der Entwicklung einer
SOA (vgl. Bloomberg 2003, S. 22 ff.).
Geschäfts-prozessmodell
plattform-abhängiges
ModellService Modell
Prozess-Sicht
Implementierungs-Sicht
Use-Case Sicht
Geschäftsprozess-analysten
service-orientierte Architekten
Entwickler
Abbildung 3-5: Vorgehen bei der Entwicklung einer SOA
Das Konzept der SOA zeichnet sich also durch eine strikte Aufgabenteilung aus, bei der
Geschäftsprozesse im Vordergrund stehen und die technischen Details immer mehr in den Hintergrund
rücken. Der Top-Down-Ansatz soll garantieren, dass die Geschäftsprozesse die Services bestimmen
und die Services die konkrete Implementierung. Man erhofft sich, dass dadurch das Business Process
Reengineering flexibler und effizienter gestaltet werden kann (vgl. Burkhard/Laures 2003, S. 16 f.).
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 27
Erst in jüngster Zeit hat die Diskussion über die SOA mit der Einführung von Web Services als
Technologie zur Umsetzung von SOAs einen neuen Aufschwung erfahren. Das World Wide Web
Consortium (W3C) entwickelt zurzeit eine Web Service Architecture (WSA), die eine konkrete
Umsetzung der SOA auf Basis von Web Services darstellt. Das W3C versteht unter der SOA „[…] a
spezific type of distributed system in which the agents are „services“. […] a service is a software agent
that performs some well-defined operation and can be invoked outside of the context of a larger
application. […] the users of that server need to be concerned only with the interface description of the
service. Furthermore, most definitions of SOA stress that “services” have a network-adressable
interface and communicate via standard protocols and data formats“ (Booth et al. 2003).
Das W3C hat eine Reihe von Standards und Konzepte entwickelt, die die Umsetzung einer SOA bzw.
WSA ermöglichen sollen, es gibt aber noch eine Reihe offener Problemstellungen (vgl. z. B. Burghardt
2004, S. 75 ff.). Auch wird die Gefahr gesehen, dass Unternehmen sich aufgrund der sehr
technikorientierten SOA/WSA-Diskussion erhoffen, dass sie durch den alleinigen Einsatz der
Technologie Web Services bereits die Vorteile einer SOA realisieren können. Man kann diese Vorteile
aber nur erlangen, wenn das o. a. Top-Down-Vorgehen konsequent im Unternehmen umgesetzt wird
(vgl. Bakker 2006). Trotz dieser momentanen Defizite erscheint der breite Einsatz von SOAs und
speziell von WSAs nur eine Frage der Zeit zu sein. Es ist also zu überlegen, wie Embedded Devices in
SOAs bzw. WSAs zu integrieren sind.
3.2.1 Web Services zur Integration von Embedded Devices
Aus betriebswirtschaftlicher Sicht können die Dienste (Web Services), die Funktionen darunter
liegender Informationssysteme kapseln, auf Basis der WSA zu Prozessen kombiniert werden. Man
verfolgt mit der WSA also eine Prozessintegration3. Es lassen sich dabei verschiedene
Funktionen/Prozesse unterscheiden. Zum einem gibt es Funktionen/Prozesse die sich vollständig
digital abbilden lassen. Z. B. kann die Funktion „Absatz prognostizieren“ durch Informationssysteme
ohne Interaktion mit der realen Welt durchgeführt werden. Zum anderen gibt es Funktionen/Prozesse,
die nur in Interaktion mit der realen Welt durchgeführt werden können. Für die Funktion „produziere Teil
XYZ“ muss das Informationssystem einer Maschine oder einem Mitarbeiter eine entsprechende
Anweisung geben. Die Maschine bzw. der Mitarbeiter führt daraufhin die Produktion physisch aus.
Diese Funktionen sind also nicht vollständig digital abbildbar. Durch die „Digitalisierung physischer
Objekte“ wie sie im Ubiquitous Computing vollzogen wird, werden physische Objekte durch
Informationssysteme „ansprechbar“. Die Funktionalitäten der physischen Gegenstände können durch
Informationssysteme genutzt werden. Es stellt sich nun die Frage, ob es mit Ubiquitous Computing-
Technologien möglich ist, vormals nur teilweise digital abbildbare Funktionen, nun vollständig digital
abzubilden, um sie so in Prozessen nutzbar und in eine SOA integrierbar zu machen. Im Folgenden soll
untersucht werden, inwieweit es möglich und sinnvoll ist, die Funktionalität von physischen
Gegenständen über Web Service zur Verfügung zu stellen.
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 28
Die Idee, Embedded Devices über standardisierte Internettechnologien anzusprechen, ist nicht neu.
Gegenstände sollten mit kleinen Web Servern ausgestattet werden, die über TCP/IP und HTTP
angesprochen werden. Somit wird es möglich mit einzelnen Gegenständen über einen herkömmlichen
Web-Browser zu kommunizieren. Wenn der in den Gegenstand integrierte Web Server über eine CGI-
Schnittstelle o. ä. verfügt, könnte er dynamisch HTML-Seiten generieren, die Information aus
Sensordaten enthalten oder man könnte den Gegenstand über HTML-Formulare „Befehle“ geben und
ihn somit kontrollieren (vgl. Borriello/Want 2000, S. 59 ff.). Damit aber Gegenstände andere
Gegenstände kontrollieren können, ist eine HTML-Schnittstelle völlig unzureichend. Für die Maschine-
Maschine-Kommunikation hat sich XML bzw. die darauf aufbauenden Web Service Standards bereits
etabliert. Es ist also nahe liegend Web Services auch auf Embedded Devices zu portieren. Die
Portierung von Web Services auf Embedded Devices stellt besondere Anforderungen an die Web
Service-Implementierung. Aufgrund der Restriktionen bezüglich Rechenleistung und Speicher, die ein
Embedded Device mit sich bringt, ergeben sich spezielle Design-Kriterien für eine Web Service-
Implementierung (vgl. van Engelen/Gallivan 2002):
- Minimierung von Speicheroperationen
- Minimierung von Speicherbedarf
- Effizientes XML-Parsen
- Plattformunabhängigkeit
Beachtet man diese Designkriterien spricht aus Sicht der Web Service Implementierung nichts gegen
die Portierung auf Embedded Devices. Es sind mittlerweile auch schon Web Service
Implementierungen für Smartphones und Personal Digital Assistants (PDAs) entwickelten worden, die
den obigen Anforderungen genügen.
Wenn man Web Services auf Embedded Devices portiert, gewinnt man die gleichen Vorteile, wie man
sie schon bei herkömmlichen verteilten Systemen durch Web Services gewonnen hat (vgl. Burghardt
2004, S. 33):
- lose Kopplung
- Plattform- und Programmiersprachenunabhängigkeit
- Offenheit bezüglich der Standards
Trotzdem bleibt zu zeigen, dass die Web Service Standards auch mit den Besonderheiten von
Embedded Devices, wie temporäre Erreichbarkeit, wechselnde Netzwerkadressen zurechtkommen. In
Bezugnahme auf die oben beschriebene SOA für betriebliche Anwendungssysteme wird dies im
nächsten Abschnitt geschehen.
3 Zum Begriff der Prozessintegration vgl. Mertens 2004, S. 1 und Jung 2006, S. 35 ff.).
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 29
3.2.2 Eignung ausgewählter Web Service Standards
Die o. a. WSA definiert eine SOA, die auf XML basiert. Sie legt sich aber nicht auf bestimmte Standards
wie beispielsweise SOAP oder WSDL fest. Trotzdem haben sich für die verschiedenen
Problemstellungen des Service Models verschiedene Standards etabliert. Abbildung 3-6 ordnet die
bekanntesten Standards in das Service Model der WSA ein.
WSDL
SOAPBPEL
UDDI
Web Service Implementierung
Abbildung 3-6: Einordnung von Web Service Standards in die WSA
3.2.2.1 SOAP
Das Simple Object Access Protocol ist ein XML-basiertes und dadurch einfaches, sprach- und
plattformunabhängiges zustandsloses one-way Kommunikationsprotokoll zum Austausch strukturierter
Informationen. SOAP-Nachrichten alleine eignen sich für lose gekoppelte Anwendungen, die über
asynchrone one-way Nachrichten interagieren. Andere Kommunikationspattern wie das synchrone
Request-/Response-Pattern für Remote Procedure Calls müssen durch darunter liegende Systeme
realisiert werden. SOAP soll zukünftig nicht an ein bestimmtes Transportprotokoll gebunden sein.
Zurzeit unterstützt es aber nur HTTP und SMTP. Aber selbst mit dieser Beschränkung auf zwei
Transportprotokolle, ist SOAP in Hinblick auf die realisierbaren Kommunikationspattern sehr flexibel
(vgl. Alonso et al. 2004, S. 155 ff.). In Hinblick auf Embedded Devices in betrieblichen
Anwendungssystemen sind somit auch Szenarien denkbar in denen einzelne Services nicht permanent
erreichbar sind, da sie beispielsweise aus Energiespargründen nur temporär online sind oder sich
temporär in einem Bereich ohne Netwerkinfrastruktur befinden.
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 30
Mit der Wahl von XML als Standard für die Datenstrukturierung, ist der Einsatz von generischen
Parsern möglich, die die Kosten senken und eine höhere Robustheit gewährleisten. Es bedeutet aber
auch, dass man einen hohen Performance-Overhead in Kauf nimmt, der mit dem Wunsch nach
Generalität einhergeht. Aber gerade in ubiquitären Systemen ist die Performance ein kritischer Faktor,
da sie zum einem durch die Baugröße und zum anderen durch die geringe Batteriekapazität von
Embedded Devices eingeschränkt ist.
Ein großes Problem bei Embedded Devices ist die Adressierung der Services. Da Embedded Devices
mobil sein können, müssen sie sich spontan in verschiedene Netzwerkinfrastrukturen integrieren und
haben somit unter Umständen ständig ändernde Netzwerkadressen. SOAP umgeht dieses Problem,
indem es die Adressierung den Transportprotokollen überlässt. Es stellt sich also die Frage, wie die
bereits in SOAP berücksichtigten Transportprotokolle HTTP und SMTP mit wechselnden
Netzwerkadressen umgehen können. Durch den asynchronen Charakter von SMTP wird das
beschriebene Problem umgangen. Die Embedded Devices können eine feste Adresse haben und
können die für sie bestimmten SOAP-Nachrichten von einem Mail-Server periodisch abrufen. Auch
HTTP bietet für diese Problemstellung theoretisch eine Lösung. Jedes Embedded Device bekommt
eine URL, die bei einem Domain Name System (DNS) einer Netzwerkadresse zugeordnet wird. So
kann ein Embedded Device über seine gleich bleibende URL angesprochen werden, die dann
dynamisch als Netzwerkadresse aufgelöst wird. Das Problem bei DNS ist aber, dass die Zuordnung der
URL auf Netzwerkadressen stark zeitverzögert stattfindet. Zudem kann das Problem, dass Embedded
Devices temporär nicht erreichbar sind, auch durch den Einsatz von DNS nicht gelöst werden.
Zusammenfassend lässt sich feststellen, dass SOAP grundsätzlich für die Portierung auf Embedded
Devices geeignet ist, es aber Probleme im Bereich der Performance und der Adressierung geben kann.
3.2.2.2 WSDL
Die Web Service Description Language (WSDL) ist vergleichbar mit Interface Definition Languages in
koventionellen Middleware-Plattformen. Neben der einfachen Beschreibung der Service Schnittstelle
(Service Name, Input- und Output-Parameter) wie sie konventionelle IDLs machen, muss WSDL
beispielsweise auch Angaben zum Transportprotokoll machen, da die Nutzung von SOAP nicht an ein
bestimmtes Protokoll gebunden ist (s. Kapitel 3.2.2.1). Auch die Adressierung des Services ist Teil
eines WSDL-Dokuments und führt somit zu der schon bei SOAP beschriebenen Problemen mit
Embedded Devices. Da es bei Web Services keine zentrale Instanz gibt, die wie bei konventionellen
Middleware-Plattformen Interaktionsmuster für Web Service Aufrufe mit mehreren (evtl. sogar
asynchronen) Nachrichtentransaktionen vorgibt, definiert WSDL eine Reihe von möglichen
Interaktionsmustern.
WSDL-Dokumente werden in der Regel von den Web Service Implementierungen automatisch
generiert. Aus den WSDL-Dokumenten können wiederum Stub-Klassen generiert werden, die die
SOAP-Kommunikation in programmiersprachenspezifischen Klassen kapseln. Der Aufruf eines Web
Services ist somit völlig transparent und ähnelt dem Aufruf eines lokal verfügbaren Services.
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 31
Die Stärken und Schwächen von WSDL ähneln denen von SOAP. WSDL eignet sich einerseits durch
seine große Flexibilität gut für Embedded Devices in betrieblichen Anwendungssystemen, andererseits
gibt es Probleme im Bereich der Performance (da auch WSDL XML nutzt) und im Bereich der
Adressierung.
3.2.2.3 UDDI
Die Universal Description Discovery and Integration (UDDI) Spezifikation widmet sich dem Beschreiben
und Finden von Web Services. In zentralen UDDI-Registries sollen die Beschreibung und die
Spezifikation der Schnittstellen von Web Services hinterlegt werden. Web Services werden in UDDI-
Verzeichnissen nach drei verschiedenen Systematisierungsansätzen klassifiziert. In den Yellow Pages
werden Web Services bestimmten Kategorien zugeordneten, in den White Pages werden sie Anbietern
zugeordnet und in den Green Pages werden die Schnittstellen in Form von Referenzen zu WSDL-
Dokumenten hinterlegt. Dadurch können Web Services gefunden werden, die zu einer bestimmten
Kategorie gehören, von einem bestimmten Anbieter kommen oder eine bestimmte Schnittstelle haben.
Das Auffinden von Web Services kann entweder manuell durch den Entwickler geschehen oder
dynamisch zur Laufzeit durch ein Programm, das einen bestimmten Web-Service benötigt. Es ist leicht
nachvollziehbar, dass der dynamische Ansatz wegen der großen Probleme die mit der Semantik von
Daten einhergehen nur schwer zu erfüllen ist. Wenn beispielsweise ein einfacher Web Service
gefunden werden soll, der den Wechselkurs von einer Währung zu einer anderen Währung
zurückgeben soll, dann kann man das als Mensch manuell durch iteratives Durchgehen durch die
Yellow/White/Green Pages in einem UDDI-Verzeichnis evtl. schaffen. Ein Software-Agent, der das
dynamisch zur Laufzeit bewerkstelligen soll, würde wahrscheinlich schon an der Namensgebung
scheitern, weiß er beispielsweise doch nicht, dass Währungsrechner und Wechselkursrechner
eigentlich das Gleiche sind.
Bei Ubiquitous Computing Anwendungen kann die Beschreibung von Web Services noch wesentlich
komplizierter werden. Wenn man zum Beispiel einen Web Service sucht, der etwas druckt, so möchte
man nicht irgendeinen Web Service mit der gewünschten Funktionalität haben, sondern einen, der
einen Drucker in der Nähe ansteuert. Die Ortstransparenz, die man bei herkömmlichen verteilten
Systemen und somit auch bei Web Services als erklärtes Ziel hat, muss bei Ubiquitous Computing also
aufgegeben werden.
Wenn man sich Szenarien vorstellt, in denen sich Gegenstände, die Ihre Ressourcen über Web-
Service-Schnittstellen zur Verfügung stellen, spontan zur Bewältigung einer Aufgabe vernetzen sollen,
so muss die Unterstützung durch UDDI-Verzeichnissen grundlegend erweitert werden. UDDI eignet
sich in seiner jetzigen Form nur für Szenarien, die ex ante bekannt sind und somit die benötigten Web
Services vor der Nutzung manuell gesucht werden können. Dies ist, um auf betriebliche
Anwendungssysteme zurückzukommen, nur bei Geschäftsprozessen der Fall, die planbar und
beschreibbar sind. Dies ist beispielsweise bei produktionsnahen Geschäftsprozessen oftmals der Fall.
Bei Geschäftsprozessen, die die Ideenfindung beschreiben, hat man mit der Formalisierbarkeit in der
Regel aber Probleme.
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 32
3.2.2.4 BPEL4WS
Mit den bis hierhin erläuterten Standards SOAP, WSDL, UDDI ist es möglich einzelne
Geschäftsprozesse eines betrieblichen Anwendungssystem auszuführen, zu beschreiben und zu
veröffentlichen. Fast man mehrere Web Services zu komplexeren Web Services zusammen, so spricht
man von Komposition oder Orchestrierung von Web Services. Eine der bekanntesten Sprachen zur
Komposition von Web Services ist die Business Process Execution Language for Web-Services
(BPEL4WS), die wie nahezu alle Web-Service-Standards auf XML basiert. Bei der Komposition, wird
zunächst ein BPEL-Dokument erstellt, in dem die beteiligten Web Services, die zeitliche
Ausführungsreihenfolge und die Beziehungen zwischen den Web Services definiert wird. Um den so
komponierten Web Service zu beschreiben, wird analog zu „primitiven“ Web Services WSDL
verwendet, wobei natürlich auf die Bindung an eine bestimmte Implementierung verzichtet wird. Die
Kontrolle über die Ausführung des komponierten Web Services übernimmt eine BPEL-Engine (vgl.
Burghardt et al. 2003, S. 61 ff.).
Verwendet man BPEL4WS für die Implementierung von betrieblichen Anwendungssystemen, so kann
man analog zur Geschäftsprozessmodellierung verschiedene Abstraktionsniveaus für die Web Services
verwenden. Komplexe Geschäftsprozesse können in kleine, handhabbare Geschäftsprozesse herunter
gebrochen werden und kleine Geschäftsprozesse können zu komplexen Geschäftsprozesse
zusammengefasst werden.
Es ist allerdings zu beachten, dass man die so gewonnene verbesserte Handhabbarkeit der
Komplexität möglicherweise durch einen großen Performanceverlust bei der Ausführung erkauft, da ein
erheblicher Kontroll-Overhead durch die Komposition entsteht.
Geht man davon aus, dass die anderen Standards (SOAP, WSDL, UDDI) für Embedded Devices in
betrieblichen Anwendungssystemen geeignet sind oder entsprechend angepasst wurden, so ist
BPEL4WS für ebenfalls uneingeschränkt einsetzbar.
3.2.3 Zusammenfassung und Beurteilung
Den vorangegangenen Ausführungen lag die Grundidee zugrunde, dass durch die Portierung von Web
Services auf Embedded Devices die Integration von physischen Prozessen in eine SOA bzw WSA
ermöglicht wird. Die Embedded Devices sollen die Funktionalitäten von physischen Objekten des
betrieblichen Umfelds als Web Services zur Verfügung stellen. Auf Basis von
Geschäftsprozessmodellen mit verschiedenen Detaillierungsgraden können diese Web Services
zusammen mit Web Services der betrieblichen Informationssysteme orchestriert werden (vgl. Abbildung
3-7).
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 33
Physische Prozesse
Web ServiceOrchestrierung
Geschäfts-prozessmodell
fräsen gefräst bohren einlagernProduktionstarten
fertig-gestellt eingelagert
...
WS 1
WS 2 WS 3 WS 4
WS 5
1
11
1
1
1
EmbeddedDevice
EmbeddedDevice
Abbildung 3-7: Integration von Embedded Devices in eine SOA mittels Web Services
Durch die Möglichkeit physische Prozesse in die Geschäftsprozessmodellierung und Orchestrierung mit
einzubeziehen, werden die Vorteile einer SOA verstärkt (vgl. zu den Vorteilen Hofmann 2003, S. 29 f.).
Es wird möglich Prozesse durchgehend zu modellieren und einer Segmentierung des Kontrollflusses
entgegenzuwirken. Durch die integrierte Sichtweise kann auf Änderungen wesentlich flexibler reagiert
werden.
Es wurde dargstellt, dass aus technischer Sicht die beschränkten Ressourcen von Embedded Devices
als eine große Herausforderung der Portierung zu sehen sind. Es ist aber zu erwarten, dass durch die
technologische Entwicklung die Relevanz dieses Problems sinken wird. Hinsichtlich der Web Service-
Standards wurde für die gängigsten Standards untersucht, inwieweit sie mit den Besonderheiten von
Embedded Devices – z. B. die temporäre Verfügbarkeit und die wechselnde Netzwerkadressierung –
zurechtkommen. Folgende Tabelle fasst die Stärken und Schwächen der Web Service-Standards bei
der Portierung auf Embedded Devices zusammen (vgl. Tabelle 3-2).
3 Technische Überlegungen zur Integration von Ubiquitous Computing-Technologien in betriebliche Informationssysteme 34
Standard Stärken Schwächen
SOAP - Problem der Adressierung wird Trans-portprotokoll überlassen
- Flexible Kommunikationspattern (syn-chron/asynchron)
Die bei SOAP berücksichtigten Trans-portprotokolle lösen das Adressierungs-problem z. T. nicht
WSDL Unterstützt nahezu beliebige Interaktions-muster
Keine Lösung des Adressierungsproblems
UDDI Ermöglicht die Katalogisierung der im Be-trieb verfügbaren Web Services
- Unzureichende Kategoriesierungsmöglichkeiten
- „Semantik-Problem“
BPEL4WS - Komplexitätsreduzierung
- Wenn SOAP, WSDL und UDDI ein-setzbar, dann ist auch BPEL4WS ein-setzbar
Erhöhter Kontroll-Overhead
Alle - Plattform- und Programmiersprachen-unabhängig
- Einfache Verarbeitung durch generische Parser, da XML-basiert
Durch die Verwendung von XML ent-stehen Performanceverluste
Tabelle 3-2: Stärken und Schwächen der Web Service-Standards
Insgesamt haben die Standards zwar Schwächen, grundsätzlich sind sie aber für die Portierung auf
Embedded Devices geeignet. Die Verwendung von XML lässt eine plattform- und
programiersprachenübergreifende Verwendung der Standards zu, was bei der hohen Diversifikation
hinsichtlich Hard- und Software bei Embedded Devices einen entscheidenden Faktor darstellt.
4 Zusammenfassung und Ausblick 35
4 Zusammenfassung und Ausblick
Es wurden mit Embedded Devices und RFID zwei Gerätekategorien des Ubiquitous Computing
vorgestellt, die als besonders relevant für den betrieblichen Einsatz erachtet werden. Embedded
Devices sollen die im Ubiquitous Computing verfolgte Verschmelzung der physischen mit der digitalen
Welt ermöglichen. Sie stellen die technologische Grundlage der von Weiser formulierten Vision des
Ubiquitous Computing dar und wurden relativ abstrakt aus Sicht des Ubiquitous Computing als
Forschungsbereich erläutert. Mit RFID steht eine marktreife Technologie zur Verfügung, mit der viele
Ubiquitous Computing-Szenarien bereits heute realisiert werden können. Abschließend wurde gezeigt,
dass es sich bei den beiden erläuterten Technologien nicht um verschiedene, sondern um
komplementäre Technologien handelt. Es wurde eine Taxonomie vorgestellt, die es ermöglicht,
verschiedene Ausprägungen der beiden Technologien zu systematisieren und es wurden
Basisfunktionalitäten beschrieben, die im betrieblichen Umfeld von Embedded Devices und RFID
übernommen werden. Mit den gewonnenen Erkenntnissen wird dazu beigetragen, dass Unternehmen
in die Lage versetzt werden, anhand der Taxonomie relevante Technologien und anhand der
Basisfunktionalitäten relevante Einsatzszenarien zu identifizieren.
Aus Sicht der betrieblichen Informationsverarbeitung bedeutet der Einsatz der erläuterten Ubiquitous
Computing-Technologien, dass Daten und Funktionen, die vorher zentral in betrieblichen
Informationssystemen vorlagen, physisch verteilt werden. Es wurde daher untersucht, wie die
physische Verteilung von Daten und Funktionen überwunden werden kann und sie als logische Einheit
wiederhergestellt – sprich integriert - werden können. Die Untersuchung erfolgte aus zwei
Perspektiven: Die datenorientierte Perspektive analysierte, wie die von Ubiquitous Computing-
Technologien erzeugten bzw. benötigten Daten mit den Datenbeständen in den Informationssystemen
integriert werden können. In der funktionsorientierten Perspektive wurde untersucht, wie Funktionen,
die durch Ubiquitous Computing-Technologien ermöglicht werden, mittels Web Services in die
betrieblichen Informationssysteme integriert werden können
Die Untersuchung erfolgt insgesamt aus einer technik-orientierten Perspektive und auf einem sehr
abstrakten Niveau. Um Unternehmen Ubiquitous Computing für den betrieblichen Einsatz näher zu
bringen, muss die Darstellung des Beitragspotenzials dieser Technologien in verschiedenen
Anwendungsgebieten konkreter erfolgen. Auch muss eine Bewertung des Einsatzes erfolgen, um der
Gefahr die Technologie zum reinen Selbstzweck einzusetzen, entgegenzuwirken.
Literaturverzeichnis 36
Literaturverzeichnis
Alonso et al. 2004: Alonso, G./Casati, F./Kuno, H./Machiraju, V.: Web services: concepts, architectures
and applications, Berlin [u.a.] 2004.
Ammer et al. 2005: Ammer, J./Burghardt, F./Lin, E./Otis, B./Shah, R./Sheets, M./Rabaey, J. M.: Ultra-
Low Power Intgrated Wireless Nodes for Sensor and Actuator Networks. In: Weber, W./Rabaey,
J. M./Aarts, E.: Ambient intelligence, Berlin [u.a.] 2005, S. 301-325.
Bakker 2006: Bakker, L.: SOA for Dummies?, http://www.computerwoche.de/soa-expertenrat/wp-
content/uploads/2006/08/soa-for-dummies-apr-2006-v11.pdf, Abruf am 30.08.2006.
Barginda et al. 2005: Barginda, K./Cichorowski, G./Assmann, R./Führ, M.: Potentiale 'smarter'
Produktkennzeichnung: technische Entwicklung und Anforderungen des Elektro-Gesetzes:
Vorstudie, Darmstadt 2005.
Bitkom 2005: Bitkom: White Paper RFID: Technologie, Systeme und Anwendungen,
http://www.bitkom.org/files/documents/White_Paper_RFID_deutsch_11.08.2005__final.pdf, Abruf
am 18.11.2005.
Bloomberg 2003: Bloomberg, J.: Principles of SOA. In: Application Developement Trends 10 (2003) 3,
S. 22.
Booth et al. 2003: Booth, D./Haas, H./McCabe, F./Newcomer, E./Champion, M./Ferris, C./Orchard, D.:
Web Service Architecture, W3C Working Draft 8 August 2003, http://www.w3.org/TR/2003/WD-
ws-arch-20030808/, Abruf am 08.08.2003.
Borriello/Want 2000: Borriello, G./Want, R.: Embedded Computation meets the World Wide Web. In:
Communication of the ACM, No. 5, Vol. 43 (2000) S. 59-66.
Bundesamt für Sicherheit in der Informationstechnik 2004: Bundesamt für Sicherheit in der
Informationstechnik: Risiken und Chancen des Einsatzes von RFID-Systemen: Trends und
Entwicklungen in Technologien, Anwendungen und Sicherheit, Bonn 2004.
Burghardt 2004: Burghardt, M.: Web Services: Aspekte von Sicherheit, Transaktionalität, Abrechnung
und Workflow, 1, Wiesbaden 2004.
Burghardt et al. 2003: Burghardt, M./Gehrke, N./Hagenhoff, S./Schumann, M.: Spezifikation und
Abwicklung von Workflows auf Basis von Web-Services. In: HMD - Praxis der
Wirtschaftsinformatik 234 (2003) S. 61-69.
Burkhard/Laures 2003: Burkhard, B./Laures, G.: SOA - Wertstiftendes Architektur-Paradigma. In:
Objektspektrum (2003) 6, S. 16-22.
De/Basu/Das 2004: De, P./Basu, K./Das, S. K.: An Ubiquitous Architectural Framework and Protocol for
Object Tracking Using RFID Tags. First Annual International Conference on Mobile and
Ubiquitous Systems: Networking and Services (MobiQuitous'04), Boston 2004, S. 174-182.
Literaturverzeichnis 37
Engels et al. 2001: Engels, D./Foley, J./Waldrop, J./Sarma, S./Brock, D.: The Networked Physical
World: An Automated Identification Architecture. Proceedings of the Second IEEE Workshop on
Internet Applications (WIAPP ’01), San Jose 2001, S. 76-77.
Finkenzeller 2002: Finkenzeller, K.: RFID-Handbuch: Grundlagen und praktische Anwendungen
induktiver Funkanlagen, Transponder und kontaktloser Chipkarten, 3., aktualisierte und erw.
Aufl., München [u.a.] 2002.
Fleisch/Mattern/Billinger 2003: Fleisch, E./Mattern, F./Billinger, S.: Betriebswirtschaftliche Applikationen
des Ubiquitous Computing. In: HMD - Praxis der Wirtschaftsinformatik (2003) 229, S. 5-15.
Flörkemeier 2005: Flörkemeier, C.: EPC-Technologie - vom Auto-ID Center zu EPCGlobal. In: Fleisch,
E.: Das Internet der Dinge: Ubiquitous Computing und RFID in der Praxis: Visionen,
Technologien, Anwendungen, Handlungsanleitungen, Berlin [u.a.] 2005, S. 87-100.
Hansen/Neumann 2001: Hansen, H. R./Neumann, G.: Wirtschaftsinformatik, 8, Stuttgart 2001.
Hansmann 2003: Hansmann, U.: Pervasive computing: the mobile world, Berlin [u.a.] 2003.
Heinrich 2005: Heinrich, C. E.: RFID and beyond: growing your business through real world awareness,
Indianapolis, IN 2005.
Helal et al. 2001: Helal, S./Hammer, J./Zhang, J./Khushraj, A.: A Three-tier Architecture for Ubiquitous
Data Access. Proceedings of the FIRST ACS/IEEE International Conference on Computer
Systems and Applications, Beirut, Lebanon 2001, S. 177-180.
Henrici/Müller 2004: Henrici, D./Müller, P.: Sicherheit und Privatsphäre in RFID-Systemen.
Tagungsband VDE Kongress, Berlin 2004, S. 223-228.
Hofmann 2003: Hofmann, O.: Web Services in serviceorientierten IT-Architekturkonzepten. In: HMD -
Praxis der Wirtschaftsinformatik (2003) 234, S. 27-33.
Hollar 2000: Hollar, S.: COTS Dust, Berkeley 2000.
Jansen 2004: Jansen, R.: Integration der Transpondertechnologie zur Erhöhung der Leistungsfähigkeit
der operativen Produktionssteuerung, Chemnitz 2004.
Jung 2006: Jung, R.: Architekturen zur Datenintegration: Gestaltungsempfehlungen auf der Basis
fachkonzeptueller Anforderungen, Wiesbaden 2006.
Kern 2006: Kern, C. J.: Anwendung von RFID-Systemen, Berlin [u.a.] 2006.
Lampe/Flörkemeier/Haller 2005: Lampe, M./Flörkemeier, C./Haller, S.: Einführung in die RFID-
Technologie. In: Fleisch, E.: Das Internet der Dinge: Ubiquitous Computing und RFID in der
Praxis: Visionen, Technologien, Anwendungen, Handlungsanleitungen, Berlin [u.a.] 2005, S. 69-
86.
Landt 2005: Landt, J.: The history of RFID. In: Institute of Electrical and Electronics Engineers: IEEE
potentials 24 (2005) 4, S. 8-11.
Lange 2004: Lange, V.: RADIO FREQUENCY IDENTIFICATION - Perspektiven für die Nutzung der
RFID-Technologie in Supply Chain Management und Logistik. In: IM 19 (2004) 4, S. 20-26.
Leimeister/Krcmar 2002: Leimeister, J. M./Krcmar, H.: Ubiquitous Computing. In: Das
Wirtschaftsstudium 31 (2002) 10, S. 1284-1294.
Literaturverzeichnis 38
Lin/Sanchez/Kaiser 1998: Lin, T./Sanchez, H./Kaiser, W.: Wireless Integrated Network Sensors (WINS)
for Tactical Information Systems. Proceedings of the 1998 Government Microcircuit Applications
Conference, 1998.
Machemer 2004: Machemer, I.: Radio Frequency Identification - Die Vernetzung des Alltags. In: IM 19
(2004) 4, S. 27-30.
Mark 1999: Mark, W.: Turning Pervasive Computing into Mediated Spaces. In: IBM Systems Journal 38
(1999) 4, S. 677-692.
Mattern 2003: Mattern, F.: Vom Verschwinden des Computers. In: Mattern, F.: Total vernetzt:
Szenarien einer informatisierten Welt, Berlin [u.a.] 2003, S. 1-41.
Melski 2006: Melski, A.: Grundlagen und betriebswirtschaftliche Anwendung von RFID. Arbeitsberichte
der Abteilung Wirtschaftsinformatik II, Universität Göttingen, Nr. 11/2006, Göttingen 2006.
Mertens 2004: Mertens, P.: Integrierte Informationsverarbeitung 1: Operative Systeme in der Industrie,
14., überarb. Aufl., Wiesbaden 2004.
Mertens 2005: Mertens, P.: Gefahren für die Wirtschaftsinformatik - Risikoanalyse eines Faches. In:
Ferstl, O. K./Sinz, E. J./Eckert, S./Isselhosrt, T.: Wirtschaftsinformatik 2005 - eEconomy,
eGovernment, eSociety, Heidelberg 2005, S. 1733-1754.
Mertens et al. 2005: Mertens, P./Bodendorf, F./König, W./Picot, A./Schumann, M./Hess, T.: Grundzüge
der Wirtschaftsinformatik, 9. überarb. Aufl., Berlin [u.a.] 2005.
Min et al. 2000: Min, R./Bhardwaj, M./Cho, S./Sinha, A./Shih, E./Wang, A./Chandrakasan, A.: An
Architecture for a Power-Aware Distributed Microsensor Node. IEEE Workshop on Signal
Processing Systems, 2000, S. 581-590.
Müller/Handy 2005: Müller, J./Handy, M.: RFID als Technik des Ubiquitous Computing - Eine Gefahr für
die Privatsphäre? In: Ferstl, O. K./Sinz, E. J./Eckert, S./Isselhorst, T.: Wirtschaftsinformatik 2005
- eEconomy, eGovernment, eSociety, Heidelberg 2005, S. 1145-1164.
Palmer 2004: Palmer, M.: Aufbau einer effektiven RFID-Architektur. In: Objektspektrum 2004 (2004) 3,
S. 51-52.
Panoff 2005: Panoff, R.: Best practice - Erprobt bei Ski-Ticktes - optimal für Supply Chains - Radio
Frequency Identification. In: New management 74 (2005) 3, S. 38-41.
Penttilä/Engels/Kivikoski 2004: Penttilä, K./Engels, D./Kivikoski, M.: Radio Frequency Identification
Systems in Supply Chain Management. In: International journal of robotics automation 19 (2004)
3, S. 143-151.
Pflaum 2001: Pflaum, A.: Transpondertechnologie und Supply-Chain-Management: elektronische
Etiketten - bessere Identifikationstechnologie in logistischen Systemen? Hamburg 2001.
Rabaey et al. 2000: Rabaey, J. M./Ammer, M. J./da Silva, J. L./Patel, D./Roundy, S.: PicoRadio
Supports Ad Hoc Ultra-Low Power Wireless Networking. In: IEEE Computer 33 (2000) 7, S. 42-
48.
Ranasinghe et al. 2005: Ranasinghe, D. C./Leong, K. S./Ng, M. L./Engels, D. W./Cole, P. H.: A
Distributed Architecture for a Ubiquitous RFID Sensing Network. Proceedings of the 2005
Literaturverzeichnis 39
Intelligent Sensors, Sensor Networks & Information Processing Conference, Melbourne 2005, S.
7- 12.
Sarma 2004: Sarma, S.: Integrating RFID. In: Queue 2 (2004) 7, S. 50 - 57.
Sarma/Brock/Ashton 2000: Sarma, S./Brock, D. L./Ashton, K.: The Networked Physical World:
Proposals for Engineering the Next Generation of Computing, Commerce & Automatic-
Identification, http://archive.epcglobalinc.org/publishedresearch/MIT-AUTOID-WH-001.pdf, Abruf
am 20.11.2005.
Schoch/Strassner 2003: Schoch, T./Strassner, M.: Wie smarte Dinge Prozesse unterstützen. In: HMD -
Praxis der Wirtschaftsinformatik (2003) 229, S. 23-31.
Schäfer 1994: Schäfer, S.: Objektorientierte Entwurfsmethoden: Verfahren zum objektorientierten
Softwareentwurf im Überblick, Bonn [u.a.] 1994.
Snijders 2005: Snijders, F.: Ambient Intelligence Technology: An Overview. In: Weber, W./Rabaey, J.
M./Aarts, E.: Ambient intelligence, Berlin [u.a.] 2005, S. 255-269.
Strassner 2005: Strassner, M.: RFID im Supply Chain Management: Auswirkungen und
Handlungsempfehlungen am Beispiel der Automobilindustrie, Wiesbaden 2005.
Strassner/Fleisch 2005: Strassner, M./Fleisch, E.: Innovationspotenzial von RFID für das Supply-Chain-
Management. In: Wirtschaftsinformatik 47 (2005) S. 45-56.
Tellkamp/Quiede 2005: Tellkamp, C./Quiede, U.: Einsatz von RFID in der Bekleidungsindustrie -
Ergebnisse eines Pilotprojekts von Kaufhof und Gerry Weber. In: Fleisch, E.: Das Internet der
Dinge: ubiquitous computing und RFID in der Praxis: Visionen, Technologien, Anwendungen,
Handlungsanleitungen, Berlin [u.a.] 2005, S. 143-160.
Tennenhouse 2000: Tennenhouse, D.: Proactive Computing. In: Communications of the ACM, 43(5)
(2000) S. 43-50.
Want et al. 2002: Want, R./Pering, T./Danneels, G./Kumar, M./Sundar, M./Light, J.: Sharing and
Accessing Information -- Public and Private - The Personal Server: Changing the Way We Think
About Ubiquitous Computing. In: Lecture notes in computer science 2498 (2002), S. 194-209.
Want/Borriello/Farkas 2002: Want, R./Borriello, G./Farkas, K. I.: Disappearing Hardware. In: Pervasive
Computing 1 (2002) 1, S. 36-47.
Wilcox 2005: Wilcox, M. S.: Techniques for predicting the performance of Time-of-Flight based local
positioning systems, London 2005.
van Engelen/Gallivan 2002: van Engelen, R./Gallivan, K. A.: The gSOAP Toolkit for Web Services and
Peer-To-Peer Computing Networks. Proceedings of the 2nd IEEE International Symposium on
Cluster Computing and the Grid (CCGrid2002), Berlin 2002.