Institut für...

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


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.


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


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.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


- 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).


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


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


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.


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.


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).


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,


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


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


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.


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


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


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.).


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.


Data Warehouse

Working Sets

Sensordaten/Aktionen


Netzwerk

Abgleichregeln

Versionssystem







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.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


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







Abbildung 3-4: Architektur zur Integration von Daten aus Ubiquitous Computing-Systemen


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


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.).


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.


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.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.


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.


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.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).


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).


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.


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.


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


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.

Date post:	15-Feb-2019
Category:	Documents
Upload:	lambao
View:	213 times
Download:	0 times

Institut für...

Documents