Konzeption und Entwicklung eines EPC-basierten ... · duktcode (EPC) basierendes...

I

DIE TECHNISCHE UNIVERSITÄT MÜNCHEN

Fakultät für Maschinenwesen

Lehrstuhl für Fördertechnik Materialfluss Logistik

Konzeption und Entwicklung eines EPC-basierten

Datennetzwerkes in der Lebensmittel-Supply-Chain

Rui Wang

Vollständiger Abdruck der von der Fakultät für Maschinenwesen

der Technischen Universität München

zur Erlangung des akademischen Grades eines

Doktor-Ingenieurs (Dr.-Ing.)

genehmigten Dissertation.

Vorsitzender: Univ.-Prof. Dr.-Ing. Michael Zäh

Prüfer der Dissertation:

1. Univ.-Prof. Dr.-Ing. Willibald A. Günthner

2. Prof. Dr.-Ing. Dianjun Fang

Tongji University, Shanghai / P.R. China

Die Dissertation wurde am 03.03.2014 bei der Technischen Universität München

eingereicht und durch die Fakultät für Maschinenwesen am 21.05.2014

angenommen.

III

Rui Wang

Konzeption und Entwicklung eines EPC-basierten

Datennetzwerkes in der Lebensmittel-Supply-Chain

fml – Lehrstuhl für Fördertechnik Materialfluss Logistik

Univ.-Prof. Dr.-Ing. Willibald A. Günthner

Technische Universität München

IV

Herausgegeben von:

Univ.-Prof. Dr.-Ing. Willibald A. Günthner

fml – Lehrstuhl für Fördertechnik Materialfluss Logistik

Technische Universität München

Zugleich:

Dissertation, München, TU München, 2014

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, in-

sbesondere die der Übersetzung, des Nachdrucks, der Entnahme von Abbildungen,

der Wiedergabe auf fotomechanischem oder ähnlichem Wege und der Speicherung

in Datenverarbeitungsanlagen bleiben – auch bei nur auszugsweiser Verwendung –

bleiben dem Autor vorbehalten.

Layout und Satz: Rui Wang

Copyright © Rui Wang 2014

ISBN: 978-3-941702-40-0

Printed in Germany 2014

V

Danksagung

Die vorliegende Arbeit entstand während meiner Tätigkeit am Lehrstuhl für Förder-

technik Materialfluss Logistik (fml) der Technischen Universität München.

Mein besonderer Dank gilt meinem Doktorvater, Herrn Prof. Dr.-Ing. Willibald A.

Günthner, für die herzliche Aufnahme in seinen Lehrstuhl, für die Möglichkeit der

Teilnahme an diversen Forschungsprojekten, für das entgegengebrachte Vertrauen

in meine Arbeit und für die stete und engagierte Unterstützung und Betreuung, ohne

die diese Arbeit nicht möglich gewesen wäre.

Zudem danke ich Herrn Prof. Dr.-Ing. Dianjun Fang für die Übernahme des Korefe-

rats sowie Herrn Prof. Dr.-Ing. Michael Zäh für die Übernahme des Vorsitzes der

Prüfungskommission.

Ein herzliches Dankeschön gilt auch Herrn Stefan Kessler für die großzügige Hilfsbe-

reitschaft und die vielen wertvollen Ratschläge in der Zeit der Doktorarbeit.

Weiterhin bedanke ich mich bei meinen Kolleginnen und Kollegen, die mir während

meiner Lehrstuhltätigkeit geholfen und mich dabei unterstützt haben. Ein besonderer

Dank gilt Herrn Gabriel Fischer, Frau Susanne Rinneberg, Frau Eva Klenk, Herrn

Matthias Jung, Herrn Michael Salfer, Herrn Roland Fischer, Herrn Michael Wölfle,

Herrn Frank Hohenstein und Herrn Rainer Ertl für die freundliche Zusammenarbeit

und die allseitige Unterstützung. Ebenso gilt mein Dank meinen Studenten, die zum

Gelingen dieser Arbeit beigetragen haben. Nicht zuletzt danke ich auch allen Anges-

tellten des Lehrstuhls, die mir stets hilfsbereit zur Seite standen.

Mein besonderer Dank gilt auch Frau Dr. Lina Riedl, die die sprachlichen Korrektu-

ren meiner Arbeit sehr sorgfältig durchgeführt hat.

Der größte Dank gilt meinen Eltern für die langjährige bedingungslose und uneinge-

schränkte Unterstützung in allen Bereichen meines Lebenswegs, wodurch es mir

ermöglicht wurde, diesen wichtigen Schritt in meinem Leben abzuschließen. Von

ganzem Herzen bedanke ich mich bei meinem Mann Yan - dass du immer für mich

da bist und mich auch in schwierigen Zeiten mit voller Liebe begleitest. Nicht zuletzt

danke ich meiner Tochter Hanna Yining – dass du mir Kraft und Mut gegeben hast,

diese Arbeit zu vollenden. Ohne Euch hätte die Arbeit nie entstehen können. Ich lie-

be Euch!

VII

Kurzzusammenfassung

Die Lebensmittelindustrie gehört zu den bedeutendsten und größten Industriebran-

chen. Aufgrund des wachsenden Wettbewerbs- und Preisdrucks auf dem EU-

Lebensmittelmarkt haben viele Unternehmen der Lebensmittelindustrie ihre Auf-

merksamkeit auf die Optimierung oder das Reengineering ihrer Logistikprozesse

gelegt, um sich dadurch Wettbewerbsvorteile zu sichern. Eine entscheidende Be-

deutung kommt dabei der Verbesserung der Informationslogistik zu. Im Vergleich zu

anderen Branchen stellt die Lebensmittelindustrie höchste Anforderungen an Pro-

duktsicherheit und Rückverfolgbarkeit, welche eine durchgängige Informationslogis-

tik durch Einsatz von modernen Informations- und Kommunikationstechnologie be-

nötigen.

Die Auto-ID-Technologie, vor allem die RFID-Technologie, besitzt enormes Potential,

die Informationslogistik in der Lebensmittel-Supply-Chain zu verbessern. Wie bei

vielen anderen Technologien, ist die Entwicklung einheitlicher Standards eine ent-

scheidende Voraussetzung für eine weite Verbreitung des Auto-ID-Einsatzes. Im

Vergleich zu Barcode ist die Standardisierung bei RFID noch unzureichend umge-

setzt. Dies erschwert die Implementierung kettenübergreifender Anwendungen.

Vor diesem Hintergrund hat die Arbeit zum Ziel, ein auf dem Elektronischen Pro-

duktcode (EPC) basierendes Datennetzwerk-Konzept zu entwickeln, um die Trans-

parenz in der Lebensmittel-Supply-Chain zu erhöhen und die Rückverfolgbarkeit zu

erleichtern. Dabei werden die Anpassung und Erweiterung des EPCIS-Standards in

der Lebensmittelkette diskutiert. Des Weiteren wird ein Rückverfolgungsdienst ent-

wickelt, der dazu dient, verteilte EPC-Daten zu ermitteln bzw. zu verketten, damit die

Rückverfolgbarkeit in der gesamten Lieferkette effizient realisiert werden kann. Das

konzipierte Datennetzwerk wird in einer simulierten Umgebung im Sinne eines

„Proof of Concept“ implementiert. Zudem wird anhand eines Behältermanagement-

systems die Integration des Netzwerks in bestehende/andere IT-Landschaften ver-

anschaulicht.

VIII

Abstract

The food industry belongs to the most important and the largest industries. Due to

the increasing competition and price pressure on the EU food market, many compa-

nies are starting to pay attention to the optimization or reengineering of their logis-

tics processes, to secure competitive advantages. Particular importance is given to

the improvement of information logistics. Compared to other industries, the food

industry places very high requirements for product safety and traceability, which

also requires well-integrated information logistics through the use of modern infor-

mation and communication technology.

The Auto-ID technology especially the RFID technology has enormous potential for

improving information logistics in the food supply chain. As many other technologies,

the development of uniform standards is a crucial prerequisite for the widespread

adoption of Auto-ID. Compared to the barcode, the standardization of RFID is still

insufficiently implemented, which complicates the information exchange across the

supply chain.

Against this background, this work aims to develop a data network concept based

on the Electronic Product Code (EPC) to increase the transparency and to facilitate

the traceability in the food supply chain. In particular, the adaptation and extension

of the EPCIS standards are discussed. Furthermore, a traceability service is devel-

oped, which is used to discover and concatenate distributed EPC data so that the

traceability can be efficiently realized. The concept is implemented in a simulated

environment in order to provide a proof of concept. In addition, the integration of the

network into existing IT-landscapes is illustrated using the example of a container

management system.

IX

Inhaltsverzeichnis

Danksagung V

Kurzzusammenfassung VII

Abstract VIII

Inhaltsverzeichnis IX

Abkürzungsverzeichnis XIII

Verwendete Formelzeichen XVII

1 Einleitung 1

1.1 Motivation 1

1.2 Zielsetzung und Aufbau der Arbeit 3

2 Informationslogistik und Auto-ID-Einsatz in der Lebensmittel-Supply-Chain 7

2.1 Einführung 7

2.2 Überblick über die aktuelle IT-Systemlandschaft in der Lebensmittel-Supply-Chain 8

2.2.1 Enterprise Resource Planning (ERP)-Systeme 8

2.2.2 Elektronische Daten Interchange 10

2.2.3 Rückverfolgbarkeitssysteme 12

2.3 Einsatz von Auto-ID-Technologien in der Lebensmittel-Supply-Chain 13

2.3.1 Einführung in die Auto-ID-Technologien 14

2.3.2 Die Barcode-Technologie 15

2.3.3 Die RFID-Technologie 19

2.3.3.1 Komponente eines RFID-Systems 19

2.3.3.2 Differenzierung und Charakterisierung von RFID-Systemen 22

2.3.3.3 Einflussfaktoren auf RFID-Systeme 24

2.3.4 Vergleich von RFID mit Barcode 26

2.3.5 Potenzial durch RFID-Einsatz in der Lebensmittel-Supply-Chain 28

2.4 Notwendigkeit zur Standardisierung des Auto-ID-basierten Datenaustausches in der Lebensmittelkette 31

Inhaltsverzeichnis

X

3 Das EPCglobal-Netzwerk 33

3.1 Die Vision des EPCglobal-Netzwerkes 33

3.2 Architektur des Netzwerks 34

3.3 Der Elektronische Produktcode 35

3.4 Der EPC Information Service 37

3.5 Der Object Name Service 38

3.6 Der Discovery Service 39

3.7 Stand der Forschung 40

3.7.1 Einsatz und Anpassung von EPCIS 41

3.7.2 Aufbau EPC-basierter kettenübergreifenden Informationssysteme (Design des Discovery Services) 43

3.8 Konkretisierung der Forschungsziele 44

4 Konzept eines EPC-basierten Datennetzwerkes in der Lebensmittel-Supply-Chain 47

4.1 Das Konzept der Auto-ID gestützten Identifikation in der Lebensmittel-Supply-Chain 47

4.1.1 Betrachtetes Szenario 47

4.1.2 Ermittlung der zu identifizierenden Objekte 50

4.1.3 Festlegung der Identifikationspunkte 52

4.2 Nummernsystem 55

4.2.1 Datenformat 55

4.2.2 Kennzeichnung von logistischen Objekten 56

4.2.3 Kennzeichnung von Lokationen 58

4.3 Einsatz und Erweiterung des EPCIS-Standards für die Lebensmittelkette 59

4.3.1 EPCIS-Ereignistypen 59

4.3.2 EPCIS-Ereignisattribute 61

4.3.3 Vokabelelemente 63

4.3.4 Mapping zwischen Auto-ID-gestützten Logistikprozessen und EPCIS-Ereignissen 65

4.4 Konzept eines Rückverfolgungsdiensts für die Lebensmittellogistik 66

4.4.1 Anforderung 66

4.4.2 Vergleich ONS und Discovery Service 66

4.4.3 Vergleich verschiedener Discovery Service Strukturen 68

4.4.4 Aufbau des Rückverfolgungsdiensts 73

4.5 Fazit 76

Inhaltsverzeichnis

XI

5 Umsetzung des Konzepts 79

5.1 Generierung realistischer EPCIS-Ereignisse durch Ablaufsimulation 79

5.1.1 Ziel der Ablaufsimulation 79

5.1.2 Entwicklung des Simulationsmodells 81

5.1.2.1 Simulationsumgebung 81

5.1.2.2 Modellaufbau 82

5.1.2.3 Generierung realistischer EPCIS-Ereignisse 85

5.2 Aufbau eines Informationssystems als „Proof of Concept“ 89

5.2.1 Systemarchitektur 89

5.2.2 Registrierung beim Rückverfolgungsdienst 91

5.2.3 Clientapplikation 92

5.3 Evaluation 95

5.4 Fazit 97

6 Integration des EPC-Netzwerkes in vorhandene/andere IT-Landschaften 99

6.1 Integrationskonzept 99

6.2 Darstellung der Integration am Beispiel eines Behältermanagementsystems 101

6.2.1 Einleitung 101

6.2.2 Anforderungen an das System 103

6.2.3 Aufbau des Systems 104

6.2.4 IT-Landschaft des Systems 106

6.2.5 Aufbau des Demonstrationsmodells 108

6.2.6 Interaktion zwischen BMS und dem Demonstrationsmodell 110

6.2.7 Funktionalitäten des BMS 111

6.3 Fazit 117

7 Zusammenfassung und Ausblick 119

7.1 Zusammenfassung 119

7.2 Ausblick 121

Literaturverzeichnis 123

Verzeichnis betreuter Studienarbeiten 136

Abbildungsverzeichnis 137

Tabellenverzeichnis 140

Inhaltsverzeichnis

XII

XIII

Abkürzungsverzeichnis

Abkürzung Bedeutung

ADS Aggregating Discovery Service

ALE Application Level Event

AS2 Applicability Statement 2

BSE Bovine Spongiforme Enzephalopathie

CBV Core Business Vocabulary

DLU Directory Look-Up

DNS Domain Name System

EAN European Article Number

EANCOM European Article Number Communication

EDI Electronic Data Interchange

EDIFACT Electronic Data Interchange For Administration, Commerce and Transport

EG Europäischen Gemeinschaft

EHEC Enterohämorrhagische Escherichia coli

EPC Electronic Product Code

EPCIS EPC Information Service

ERP Enterprise Resource Planning

EU European Union

FIFO First In First Out

GIAI Global Individual Asset Identifier

GRAI Global Returnable Asset Identifier

GTIN Global Trade Item Number


XIV

HF High Frequency

HTTP HyperText Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

IT Information Technology

LF Low Frequency

LKW Lastkraftwagen

NRW Nordrhein-Westfalen

NVE Nummer der Versandeinheit

OCR Optical Character Recognition

ONS Object Name Service

PET Polyethylenterephthalat

QR Quick Response

QR Query Relay

RFID Radio Frequency Identification

RTI Returnable Transport Item

RTLS Real-time locating systems

RWTH Rheinisch-Westfaelische Technische Hochschule Aachen

SGLN Serialized Global Location Number

SGTIN Serialized Global Trade Item Number

SHF Super High Frequency

SLG Schreib-/Lesegerät

SOAP Simple Object Access Protocol

SSCC Serial Shipping Container Code

THM Transporthilfsmittel

UHF Ultra High Frequency

UML Unified Modeling Language


XV

URI Uniform Resource Identifier

URL Universal Resource Locator

WMS Warehouse Management System

WSDL Web Services Description Language

XML Extensible Markup Language

XVII

Verwendete Formelzeichen

Formelzeichen Einheit Bedeutung

𝑑 [ms] gesamte Netzwerkverzögerung

𝑑p [ms] Ausbreitungsverzögerung

𝑑q [ms] Warteschlangenverzögerung

𝑑t [ms] Übertragungsverzögerung

𝐵 [Mbps] Bandbreite

𝐶 [m/s] Ausbreitungsgeschwindigkeit der Datenpakete

𝐷 [km] Entfernung zwischen Rückverfolgungsdienst und EPCIS-Server

𝐿p [KB] Paketgröße

𝜆 [-] durchschnittliche Senderate der Subqueries

𝜇 [-] durchschnittliche Servicerate des Rückverfol-gungsdiensts

𝜌 [-] 𝜇

1

1 Einleitung

1.1 Motivation

Das Thema Lebensmittelsicherheit und -qualität zieht immer mehr Aufmerksamkeit

weltweit auf sich. Lebensmittelskandale und Rückrufaktionen in den letzten Jahr-

zehnten haben einen schweren Imageschaden der Lebensmittelindustrie mit Um-

satzrückgang verursacht und das Vertrauen der Verbraucher drastisch erschüttert.

Dafür sind die BSE-Krise (Bovine Spongiforme Enzephalopathie) [SPI-01], der Me-

lamin-Fall (veruneinigten Milchpulverprodukten) in China [SPI-08], die mit EHEC (En-

terohämorrhagische Escherichia coli) verseuchte Sprossen [aer-11] sowie der jüng-

ste Rindfleischskandal in Deutschland [DIE-13] eindrucksvolle Beispiele.

Anhand der Krisen und Skandalen wird deutlich, dass die schnelle und gezielte Re-

konstruktion von Warenflüssen entlang der Lieferkette von entscheidender Wichtig-

keit und somit eine große Herausforderung für die Lebensmittelindustrie darstellt.

Die Informationstransparenz in Lebensmittelketten ist oft mangelhaft, weshalb die

Rückverfolgung von Warenflüssen sehr zeitaufwendig oder gar nicht möglich ist. Um

diese Situation zu verbessern, hat die Europäische Union im Jahr 2002 die Verord-

nung (EG) Nr. 178 /2002 erlassen, die in Deutschland zum 1. Januar 2005 in Kraft

getreten ist. Diese Verordnung verpflichtet alle an einer der Lebensmittelkette Betei-

ligten, Warenein- und -ausgänge zu dokumentieren, damit die Rückverfolgbarkeit

ihrer Materialflüsse gewährleistet werden kann. Hierzu sollten Systeme und Verfah-

ren etabliert werden, mit Hilfe derer die dokumentierten Informationen den zuständi-

gen Behörden nach Aufforderung mitgeteilt werden können. Durch die Verkettung

der zur Verfügung gestellten dokumentierten Informationen aller Beteiligten kann der

gesamte Warenfluss in der Lieferkette nachvollzogen werden [Eur-02]. Die Verord-

nung 178/2002 markiert einen Meilenstein für die Lebensmittelsicherheit in der EU.

Mit ihrer Veröffentlichung haben die betroffenen Unternehmen angefangen zu über-

legen, wie sie ihre Dokumentationssysteme aufbauen können, um einerseits die ge-

setzlichen Anforderungen zu erfüllen und um andererseits Mehrwert für Ihre Unter-

nehmensprozesse durch das System zu schaffen [Leb-03]. Da die Verordnung keine

konkreten bzw. detailierten Vorgabe im Hinblick auf die Ausgestaltung der Systeme

und Verfahren zur Rückverfolgbarkeit enthält, bestand Unsicherheit für die Unter-

nehmen beim Aufbau ihrer Rückverfolgbarkeitssysteme. Laut Bechini und Kollegen

finden die Dokumentation und ihre Übermittlung vieler Rückverfolgbarkeitssysteme

noch analog papierbasiert über Zettel und Formulare statt, was zu erheblichen zeitli-

chen Verzögerungen bei der Problementdeckung führt und Rückrufaktionen ent-

1 Einleitung

2

sprechend schwierig macht [Bec-08]. Darüber hinaus macht die Uneinheitlichkeit

der Systeme der Beteiligten die Verkettung von Informationen über die gesamte Lie-

ferkette zusätzlich schwierig.

Die Entwicklung von Auto-ID-Technologien, vor allem die Radiofrequenz-

Identifikationstechnologie (RFID), bringt heutzutage neue Möglichkeiten zur Verbes-

serung von Tracking & Tracing und könnte somit die Transparenz sowie die Effizienz

in der Supply-Chain stark erhöhen. Die Lebensmittelindustrie beschäftigt sich schon

seit Jahren mit den Nutzungsmöglichkeiten der RFID-Technologie und verfolgt ge-

spannt die Entwicklungen der Technik in dieser Branche. Trotz des Interesses zeigt

ein Blick in der Lebensmittelpraxis, dass der Einsatz von RFID-Technologie meistens

noch in der Pilot-Phase befindet [Kan-10a]. Die mangelnde Lesezuverlässigkeit der

Technologie unter unterschiedlichen Umgebungsbedingungen erweist sich als

schwierig. Ein anderer entscheidender Grund hierfür ist in den noch nicht definierten

Standards für den Austausch der RFID-Daten zu suchen: Insellösungen der einzel-

nen Beteiligten stellen keinen Mehrwert für die gesamte Lieferkette her.

Um die Entwicklung der RFID-Technologie voranzutreiben, wurde EPCglobal im

Jahr 2003 gegründet. EPCglobal ist eine internationale Non-Profit-Organisation, die

Standards für eine einheitliche Nutzung der RFID-Technologie entwickelt [EPC-12].

Kernstück der Standards ist der Elektronische Produktcode (EPC), der eine weltwei-

te eindeutige Kennzeichnung von Objekten ermöglicht. Um einen effizienten Aus-

tausch der EPC-Daten zu gewährleisten, wurde der EPC Information Service (EPCIS)

Standard von EPCglobal entwickelt, der 2007 veröffentlicht wurde [EPC-07]. EPCIS

gilt als einer der wichtigsten Bestandteile des EPCglobal-Netzwerkes, das aus di-

versen Komponenten und Kommunikationsschnittstellen besteht und die Vision des

„Internets der Dinge“ in einem engeren Sinn realisiert1. Bevor der Standard einge-

setzt wird, ist er allerdings je nach Anwendungsbranche anzupassen und zu erwei-

tern. Die Rückverfolgbarkeit in der Lebensmittelkette betrifft in der Regel viele Betei-

ligte, so dass sich die Frage stellt, wie die Informationen ermittelt bzw. verkettet

werden können.

Im Rahmen der vorliegenden Arbeit werden die oben genannten Fragen näher be-

trachtet.

1 Das Internet der Dinge ist „die technische Vision, Objekte beliebiger Art in ein universales digitales Netz zu integrieren. Dabei haben die Objekte eine eindeutige Identität und befinden/bewegen sich in einem ‚intelligenten‘ Umfeld.“ [Gab-10], [Fed-07]

Zielsetzung und Aufbau der Arbeit

3

1.2 Zielsetzung und Aufbau der Arbeit

Das Ziel der Arbeit liegt in der Konzeption und Entwicklung eines EPC-basierten Da-

tennetzwerkes, das dazu beitragen soll, die Transparenz in der Lebensmittel-

Supply-Chain zu erhöhen und die Rückverfolgbarkeit zu erleichtern. Dabei wird an-

hand eines Beispielsszenarios die Anpassung und Erweiterung des EPCIS-

Standards in der Lebensmittelkette diskutiert. Zudem wird ein Rückverfolgungs-

dienst entwickelt, der auf dem Stand der Technik aufbaut und dazu dient, verteilte

EPC-Daten zu ermitteln bzw. zu verketten, damit die Rückverfolgbarkeit in der ge-

samten Lieferkette effizient realisiert werden kann. Das Ziel des EPC-basierten Da-

tennetzwerkes soll darin liegen, die vorhandene IT-Landschaft der Unternehmen zu

ergänzen statt zu ersetzen, damit der Kostenaufwand bei der Einführung des Netz-

werkes gering gehalten werden kann. Deswegen wird in dieser Arbeit untersucht

werden, wie das Datennetzwerk in die bestehende IT-Landschaft integriert werden

kann. Die Arbeit gliedert sich dabei wie in Abbildung 1-1 dargestellt.

In Kapitel 2 wird der Status Quo der IT-Landschaft in der Lebensmittel-Supply-Chain

vorgestellt. Dazu wird zuerst ein Überblick über die häufig eingesetzten IT-Systeme

gegeben. Danach wird schwerpunktmäßig auf die Auto-ID-Technologie, vor allem

auf die Barcode- und RFID-Technologie sowie ihren Einsatz in der Lebensmittello-

gistik, eingegangen.

Durch den Einsatz der Auto-ID-Technologie könnten das Tracking & Tracing sowie

die Effizienz in der Supply-Chain wesentlich verbessert werden. Eine entscheidende

Voraussetzung für einen erfolgreichen Einsatz und eine weite Verbreitung der Auto-

ID-Technologie über die gesamte Lieferkette ist aber die Entwicklung und Einfüh-

rung von einheitlichen Standards. Dazu wird das EPCglobal-Netzwerk schwer-

punktmäßig in Kapitel 3 vorgestellt. Es wird insbesondere auf die wichtigen Kompo-

nenten zum kettenübergreifenden Datenaustausch eingegangen. Die Anforderungen

an die Forschungsarbeit werden aus dem Stand der Forschung abgeleitet und die

Forschungsziele daran konkretisiert.

Kapitel 4 stellt das Konzept des EPC-basierten Datennetzwerkes für die Lebensmit-

tellogistik vor. Es wird anhand eines Beispiels in der Tiefkühlkette verdeutlicht, wie

der EPCIS-Standard eingesetzt und erweitert werden kann. Darauf basierend wird

das Konzept für den Rückverfolgungsdienst dargestellt, durch den die verteilten

EPC-Daten zur Rückverfolgbarkeit in der Lebensmittelkette ermittelt sowie verkettet

werden können.

1 Einleitung

4

In Kapitel 5 wird beschrieben, wie das Konzept umgesetzt wird. Ein Verfahren wird

entwickelt, um realistische EPCIS-Events durch Ablaufsimulation zu generieren.

Darauf basierend wird ein Informationssystem nach dem Konzept implementiert, um

einen „Proof of Concept“ zu erstellen. Da das System in einer simulierten Umge-

bung aufgebaut wird, folgt zuletzt die Simulation einer möglichen Netzwerkverzöge-

rung zur Evaluation der Machbarkeit des Systems.

In Kapitel 6 wird diskutiert, wie man das EPC-basierte Datennetzwerk in die beste-

hende IT-Landschaft der Unternehmen integrieren kann. Die Integration wird mittels

einer Demonstration über ein RFID-basiertes Behältermanagementsystem veran-

schaulicht.

Abschließend erfolgen in Kapitel 7 eine Zusammenfassung der Arbeit sowie der

Ausblick auf zukünftige Entwicklungsbedarfe.

Zielsetzung und Aufbau der Arbeit

5

Motivation und Zielsetzung

Zusammenfassung und Ausblick

Hauptteil

Grundlagen und Stand der Technik

Einleitung· Motivation

· Zielsetzung und Aufbau der Arbeit

Informationslogistik und Auto-ID-Einsatz in der Lebensmittel-Supply-Chain

· Überblick über die aktuelle IT-Systemlandschaft· Einsatz von Auto-ID-Technologien

· Notwendigkeit zur Standardisierung des Auto-ID-basierten Datenaustausches

Kap. 1

Das EPCglobal-Netzwerk· Vision und Architektur des Netzwerkes· Wichtige Komponenten zum kettenübergreifenden Datenaustausch· Stand der Forschung· Konkretisierung der Forschungsziele

Konzeption eines EPC-basierten Datennetz-werkes für die Lebensmittellogistik

· Das Konzept der Auto-ID-gestützten Identifikation in der Lebensmittel-Supply-Chain

· Nummernsystem· Einsatz und Erweiterung des EPCIS-Standards

· Konzeption eines Rückverfolgungsdiensts

Kap. 2

Kap. 3

Kap. 4

Umsetzung des Konzepts· Generierung realistischer EPCIS-Ereignisse durch Ablaufsimulation

· Aufbau eines Informationssystems als „Proof of Concept“

· Evaluation

Integration des EPC-Netzwerkes in vorhandene/andere IT-Landschaften

· Integrationskonzept· Darstellung der Integration am Beispiel eines Behältermanagementsystems

Zusammenfassung und Ausblick· Zusammenfassung

· Ausblick

Kap. 5

Kap. 6

Kap. 7

Abbildung 1-1: Struktur und Vorgehensweise der Arbeit

1 Einleitung

6

Einführung

7

2 Informationslogistik und Auto-ID-Einsatz in der

Lebensmittel-Supply-Chain

2.1 Einführung

Das wichtigste Ziel der Logistik besteht darin, die Verfügbarkeit „des richtigen Gutes,

in der richtigen Menge, im richtigen Zustand, am richtigen Ort, zur richtigen Zeit, für

den richtigen Kunden und zu den richtigen Kosten“ zu sichern [Gün-12a]. Zur Erfül-

lung dieses Ziels spielt die Informationslogistik eine entscheidende Rolle.

Die Informationslogistik befasst sich als Teilgebiet des gesamten Informationsmana-

gements mit Informationsflüssen in unternehmensinternen Prozessen oder in unter-

nehmensübergreifenden Ketten und Netzwerken. Sie hat die Aufgabe, relevante In-

formationen in geeigneter Form und Qualität für die Planung, Steuerung und Kont-

rolle der Unternehmensprozesse bereitzustellen [Gün-07]. Für die Implementierung

der Informationsflüsse sind die Speicherung und Aufbereitung von Daten erforder-

lich. Um diese zu realisieren, sollten adäquate und unterstützende Informationssys-

teme eingerichtet werden [Din-08].

Aufgrund des wachsenden Wettbewerbs- und Preisdrucks auf dem EU-

Lebensmittelmarkt haben viele Unternehmen der Lebensmittelindustrie ihre Auf-

merksamkeit auf die Optimierung oder das Reengineering ihrer Logistikprozesse

gelegt, um sich Wettbewerbsvorteile dadurch zu sichern [Fea-99]. Eine entschei-

dende Bedeutung kommt dabei der Verbesserung ihrer Informationslogistik zu [Ghi-

01]. Im Vergleich zu anderen Branchen bestehen höchste Anforderungen an Pro-

duktsicherheit und Rückverfolgbarkeit, welche eine durchgängige Informationslogis-

tik durch Einsatz von modernen Informations- und Kommunikationstechnologie be-

nötigen [Man-05]. Vor diesem Hintergrund werden IT-Systeme heutzutage zuneh-

mend in der Lebensmittelbranche eingesetzt.

Diese Arbeit handelt von der Konzeption und Entwicklung eines EPC-basierten Da-

tennetzwerkes, welches zum Ziel hat, die Informationslogistik in der Lebensmittel-

Supply-Chain zu verbessern. In diesem Kapitel wird daher zunächst der Status Quo

der Informationslogistik in der Lebensmittel-Supply-Chain vorgestellt. Dazu wird zu-

erst ein Überblick über die häufig eingesetzten IT-Systeme in der Lebensmittel-

Supply-Chain gegeben (Abschnitt 2.2). Anschließend wird schwerpunktmäßig auf

die Auto-ID-Technologie eingegangen, die eine wichtige Voraussetzung sowohl für

eine lückenlose Rückverfolgbarkeit als auch für eine effiziente Informationslogistik

2 Informationslogistik und Auto-ID-Einsatz in der Lebensmittel-Supply-Chain

8

darstellt. Dabei werden vor allem die Barcode- und RFID-Technologie sowie ihren

Einsatz in der Lebensmittellogistik näher betrachtet (Abschnitt 2.3). Im letzten Teil

des Kapitels wird die Notwendigkeit zur Standardisierung des Auto-ID-basierten Da-

tenaustausches in der Lebensmittelkette erläutert (Abschnitt 2.4).

2.2 Überblick über die aktuelle IT-Systemlandschaft in der Le-bensmittel-Supply-Chain

Im Folgenden werden die häufig eingesetzten IT-Systeme vorgestellt.

2.2.1 Enterprise Resource Planning (ERP)-Systeme

ERP bezeichnet die unternehmerische Aufgabe, den Einsatz der vorhandenen Res-

sourcen (Kapital, Material, Betriebsmittel oder Personal) möglichst effizient zu ge-

stalten und somit die Steuerung von Geschäftsprozessen zu optimieren [Gro-10].

Um diese Aufgabe zu erfüllen, werden heute in vielen Unternehmen die sogenann-

ten ERP-Systeme eingesetzt. Als ERP-Systeme bezeichnet man hierbei integrierte

Informationssysteme, die alle möglichen Geschäftsprozesse abbilden und ihre Pla-

nung sowie Steuerung unterstützen. Die ERP-Software wurde ursprünglich in den

1990er Jahren als Erweiterung der MRP-Software (Material Requirements Planning)

und der MRP II-Software (Manufacturing Resource Planning) entwickelt. Über die

Jahre hinweg wurde die Software weiter entwickelt und ist heute zu einer Integrier-

ten Softwareplattform geworden, welche fast alle Aspekte in der Geschäftsoperatio-

nen unterstützt [Cha-08].

ERP-Systeme bestehen meist aus diversen Modulen, zu denen u.a. die klassischen

Module – Finanzen, Personalwesen, Produktion und Logistik – gehören. Abbildung

2-1 zeigt das Solution Map des berühmtesten ERP-Anbieter SAP AG [SAP-12].

ERP-Systeme sollten einerseits in der Lage sein, Informationen zwischen einzelnen

Modulen auszutauschen, da alle Aktivitäten in einem Unternehmen miteinander ver-

strickt sind. Andererseits sollte jedes Modul auch selbstständig betrieben und erwei-

tert werden können [FML-12a]. In der Logistikbranche kann beispielsweise das La-

gerverwaltungssystem (WMS), das Tourenplanungssystem oder das Behältermana-

gementsystem durch eine externe Lösung betrieben und an das ERP-Backbone

über Schnittstellen angebunden werden, was bei Lebensmittelhändlern in der Praxis

häufig der Fall ist.

Überblick über die aktuelle IT-Systemlandschaft in der Lebensmittel-Supply-Chain

9

AnalyticsSales &Service

Product Development & Manufacturing

Procurement &LogisticsExecution

Human Capital Management

Financials

Strategic Enterprise

ManagementSales Order

Management

Production Planning

ProcurementTalent

Management

Financial Supply Chain

Management

Financial Analytics

Aftermarket Sales and Service

Manufacturing Execution

Inventory & Warehouse

Management

Workforce Process

Management

Treasury

Operations Analytics

Professional-Service Delivery

Product Development

Inbound & OutboundLogistics

Workforce Deployment

Financial Accounting

Life-Cycle Data Management

TransportationManagement

ManagementAccouting

CorporateGovernance

Workforce Analytics

Corporate Services

Real Estate Management

Enterprise AssetManagement

Project and Portfolio Mgmt.

Travel Management

Envionment, Health and Safty

Compliance Mgmt.

Quality Management

Global Trade Services

SAP Netweaver

En

d-U

ser S

erv

ice D

eliv

ery

Abbildung 2-1: SAP ERP Solution Map (In Anlehnung an [SAP-12])

Bei großen Unternehmen der Lebensmittelindustrie, sowohl bei Herstellern als auch

bei Händlern, kommen heutzutage meist ERP-Systeme zum Einsatz. Nach einer

ERP-Studie von Konradin in 2011 [Kon-11] haben 79,3% der befragten Unterneh-

men in der Prozessindustrie, wozu die Lebensmittelbranche gehört, ERP-

Standardsysteme eingesetzt. Nur 6,9% der Befragten haben noch keine ERP-

Lösungen eingeführt. 33,4% haben eine Eigenentwicklung statt Standardsysteme

verwendet und die Speziallösungen liegen bei 20,1%. Der Grund liegt einerseits dar-

in, dass die Standardsysteme oft zeit- und kostenaufwendig einzuführen sind. Ande-

rerseits sind nach Meinung der Befragten nicht alle individuellen Anforderungen mit

den Standardlösungen zu erfüllen.


10

Abbildung 2-2: Verbreitung von ERP-Lösungen in der Prozessindustrie in Deutschland [Kon-11]

Die ERP-Systemanbieter sind heutzutage bestrebt, ERP-Systeme um immer um-

fangreichere Funktionalitäten zu erweitern. Die Systeme alleine können noch nicht

alle Anforderungen der Lebensmittellogistik erfüllen, vor allem hinsichtlich der

Transparenz und der Rückverfolgbarkeit in der Lebensmittelkette, wo ein effizienter

Datenaustausch zwischen den Beteiligten vorausgesetzt wird. ERP-Systeme kom-

men heute überwiegend bei Lebensmittelunternehmen zur Planung und Kontrolle

ihrer Geschäftsprozesse zum Einsatz. Um die Transparenz in Echtzeit entlang der

gesamten Lieferkette zu realisieren, müssen noch weitere Informations- und Kom-

munikationstechnologien eingeführt werden.

2.2.2 Elektronische Daten Interchange

Für den elektronischen Datenaustausch zwischen Geschäftspartnern entlang der

Supply-Chain wurde Elektronische Daten Interchange (EDI) bereits in den achtziger

Jahren eingesetzt [Wan-05]. EDI wird definiert als Computer-zu-Computer-

Übertragung von Geschäftsdaten zwischen Betrieben in einem standardisierten

Format [Wal-97]. Zu den Geschäftsdaten gehören z. B. Bestellungen, Rechnungen,

Lieferavis usw.

Die EDI-Kommunikation lässt sich vereinfacht in zwei unterschiedliche Einzelprozes-

se unterteilen: den Konvertierungsprozess und den Kommunikationsprozess. Im

Konvertierungsprozess werden die zu übertragenen Daten in standardisierte Nach-

richtenformate übersetzt und umgekehrt. Im Kommunikationsprozess werden die

EDI-Nachrichten über Kommunikationsnetze vom Sender an den Empfänger über

Protokolle übertragen [Wer-00]. In Abbildung 2-3 ist die Kommunikation schema-

tisch dargestellt.

20,1%

33,4%

79,3%

6,9%

mind. eine Spezial-/Einzellösung

mind. eine Eigenentwicklung

mind. eine ERP-Standardlösung

keine ERP-Lösung

Überblick über die aktuelle IT-Systemlandschaft in der Lebensmittel-Supply-Chain

11

Netzwerk

EDI-Nachricht

Konverter

Unternehmen A

Konverter

Unternehmen B

Übersetzung

Geschäftsanwendung (z. B. ERP-Systeme)

Abbildung 2-3: EDI-Kommunikation (In Anlehnung an [Tho-11])

Eine Grundvoraussetzung für die Ausbreitung von EDI ist die konsequente Nutzung

von einheitlichen Standards. Dabei sind heutzutage die internationalen EDIFACT-

Normen richtungsweisend. Um die Komplexitäten bei der Anwendung von EDI-

FACT-Standards zu reduzieren, wurden für einzelne Branchen die sogenannten

Subsets von EDIFACT entwickelt. Für die Konsumgüterwirtschaft, wozu die Le-

bensmittellogistik gehört, ist die Nutzung des EANCOM Subset in Deutschland am

meisten verbreitet [Vah-12].

EDI bietet gegenüber einer manuellen Prozessabwicklung wie zum Beispiel Fax und

Email folgende Vorteile [Lau-10]:

· Vermeidung von wiederholter Erfassung bereits vorliegender Daten

· Reduktion der Erfassungsfehler

· schnellere Informationsweitergabe und kürzere Bearbeitungszeit

· Aufbau neuer strategischer Geschäftspartnerschaft und damit die Erhaltung

der Wettbewerbsfähigkeit

Der Nachteil von EDI liegt hauptsächlich darin, dass der Einsatz von EDI-Systemen

wegen der Komplexität der Datenformatierung sowie der benötigten Anpassung von

Unternehmensprozessen oft mit erheblichen Kosten verbunden ist. Es führt dazu,

dass EDI meistens in großen Unternehmen aufgrund ihrer vielen Vorteile verbreitet

ist. Kleine und mittlere Unternehmen werden dagegen häufig durch das hohe Inves-

titionsvolumen vom traditionellen EDI abgehalten [Wed-03].


12

Vor diesem Hintergrund entstand der sogenannte Web-EDI, eine alternative Lösung

für kleine und mittlere Unternehmen. Im Vergleich zum klassischen EDI verwendet

Web-EDI das Internet an Stelle privater Netzverbindung als Transportmedium für die

zu übertragenden Geschäftsdaten. Bei dieser Form des Datenaustausches bieten

große Handelsunternehmen (EDI-Betreiber) zumeist kleineren Lieferanten die Mög-

lichkeit, durch einen Webbrowser manuell die Daten der Geschäftstransaktionen

abzurufen oder einzulesen. Diese werden dann in traditionelle EDI-Nachrichten

übersetzt und bei EDI-Betreibern weiterbearbeitet [Spe-01].

Trotz der Reduktion der Implementierungskosten und des Zeitaufwands hat Web-

EDI Nachteile. Zum einen führt die Nutzung von Web-EDI wieder zu manuellem Auf-

wand, da die erhaltenen Daten manuell ins ERP-System übertragen werden müssen.

Zum anderen können zusätzliche Kosten durch die Anbindung an mehrere Unter-

nehmensgruppen entstehen [Wal-10].

2.2.3 Rückverfolgbarkeitssysteme

Wie bereits im Kapitel Motivation ausgeführt gewinnt heutzutage die Thematik der

Rückverfolgbarkeit immer stärker an Bedeutung in der Lebensmittelindustrie. Rück-

verfolgbarkeit spielt nicht nur für das Vertrauen und das Sicherheitsbedürfnis der

Verbraucher, sondern auch für das betriebliche Risikomanagement von Lebensmit-

telunternehmen eine wichtige Rolle [Lie-11].

Die BSE-Krise in den 90er Jahren zeigte, dass die Informationen, die für eine schnel-

le und gezielte Rückverfolgung von Lebensmitteln notwendig sind, häufig schwer zu

generieren waren. Das Thema Sicherheit und Rückverfolgbarkeit von Lebensmitteln

wurde seitdem in Fragen gestellt und in der Öffentlichkeit heftig diskutiert [Sch-07].

Als direkte Folge wurde die Verordnung (EG) Nr. 178/2002 „zur Festlegung der all-

gemeinen Grundsätze und Anforderungen des Lebensmittelrechts, zur Errichtung

der Europäischen Behörde für Lebensmittelsicherheit und zur Festlegung von Ver-

fahren zur Lebensmittelsicherheit“ von der Europäischen Union entworfen. Am An-

fang 2005 ist sie in Kraft getreten.

Nach dieser Verordnung müssen Lebensmittelunternehmer feststellen können, von

wem sie ein Erzeugnis erhalten haben und an wen sie das Erzeugnis geliefert haben.

Dies ist das sogenannte „one step up, one step down“ Prinzip. Dazu sollten „Syste-

me und Verfahren“ eingerichtet werden, die diese Informationen den zuständigen

Behörden nach Aufforderung zur Verfügung stellen [Eur-02]. In dieser Verordnung

Einsatz von Auto-ID-Technologien in der Lebensmittel-Supply-Chain

13

wurden aber keine Implementierungsdetails gemäß der Rückverfolgbarkeitssysteme

festgelegt. Es bleibt offen, wie man die Systeme und Verfahren technisch umsetzt.

In der Praxis gibt es heute grundsätzlich zwei verschiedene Möglichkeiten zur Um-

setzung der Rückverfolgbarkeit: entweder verkettete Systeme oder integrierte Sys-

teme [Gam-06].

Bei verketteten Systemen dokumentiert jedes Lebensmittelunternehmen in der Lie-

ferkette ihre Warenein- und -ausgänge, entweder analog in Papierform oder mit

internen Informationssystemen wie ERP erfolgt. Falls ein Erzeugnis rückverfolgt

werden muss, können die beteiligten Unternehmen jeweils die ihnen unmittelbar vor-

und nachgelagerten Stufen erfragen. Die Rückverfolgbarkeit in der gesamten Kette

kann aber nur durch Informationsverkettung gewonnen werden. Die verketteten Sys-

teme werden in der Praxis häufig verwendet, da diese Lösung geringen Organisati-

onsaufwand mit sich bringt. Die Nachteile sind offensichtlich: die Informationsver-

kettung kann viel Zeit in Anspruch nehmen und die Systeme sind fehleranfällig.

Bei integrierten Systemen wird meistens eine zentrale Datenbank für eine bestimmte

Lieferkette aufgebaut, in die alle Beteiligten ihre Informationen über Warenempfang

und –lieferung übermitteln. Dadurch können die Waren mit einfacher Datenabfrage

in der Datenbank schnell rückverfolgt werden. Die Nachteile liegen darin, dass der

Aufbau und der Betrieb von solchen Systemen durch Administrationsaufwand oft

mit hohen Kosten verbunden sind und Lösungen mit einer zentralen Datenbank an-

dere Anforderungen an Datensicherheit stellen. Weiterhin bieten die bisherigen in-

tegrierten Systeme auf dem Markt meist nur Insellösungen jeweils für einen speziel-

len Teilaspekt der Kette in einem kleinen Umfang. Die mangelnde Standardisierung

hat zur Folge, dass das Anbinden von neuen Geschäftspartnern oft zeit- und kos-

tenaufwendig ist.

2.3 Einsatz von Auto-ID-Technologien in der Lebensmittel-Supply-Chain

Eine zuverlässige Identifikation von Objekten ist eine wichtige Voraussetzung sowohl

für eine lückenlose Rückverfolgbarkeit als auch für eine effiziente Informationslogis-

tik in der Lebensmittel-Supply-Chain. Der Einsatz moderner Auto-ID-Technologien

kann sehr effektiv dazu beitragen, die Identifikation von Objekten intelligenter und

zuverlässiger zu gestalten. Gerade in der Lebensmittelindustrie ist der Einsatz von

Barcodes heutzutage schon sehr weit verbreitet. RFID-Technologien gewinnen seit


14

Jahren auch zunehmend an Bedeutung, da sie viel mehr Möglichkeiten für die Opti-

mierung logistischer Prozesse eröffnen.

2.3.1 Einführung in die Auto-ID-Technologien

Unter Auto-ID versteht man „die automatisierte, d.h. mit Hilfe von technischen

Hilfsmitteln und ohne die unmittelbare menschliche Intelligenz realisierte, Zuordnung

von Objekten zu einer Klasse durch ein Identifikationssystem“ [Jan-04]. Abbildung 2-

4 gibt eine Übersicht der wichtigsten Auto-ID-Technologien.

Auto-ID

Barcode

Chip-Karten

RFID

Bio-metrischeVerfahren

OpticalCharacter

Recognition(OCR)

Finger-abdruck-

Verfahren

Sprach-Identifizie-

rung

Abbildung 2-4: Übersicht über die wichtigsten Auto-ID-Technologien [Fin-06]

Barcode ist ein optisch lesbarer Code, der aus einzelnen Strichen oder Punkten und

dazwischen liegenden Lücken besteht. Die codierten Daten eines Barcodes werden

mit optischen Lesegeräten maschinell eingelesen und elektronisch weiterverarbeitet.

Grundsätzlich lassen sich Barcodes in zwei Gruppen unterteilen: 1D- und 2D-

Barcodes, entsprechend der Dimensionen, in denen die Daten codiert sind.

Das Akronym RFID steht für Radiofrequenz-Identifikation und bezeichnet Verfahren,

„das durch den Einsatz von Frequenzen im Radiowellenbereich des Spektrums die

elektromagnetische oder elektrostatische Kopplung zwischen einem Schreib-

/Lesegerät und einem mobilen Datenträger (Transponder) nutzt, um Daten berüh-

rungslos und ohne Sichtverbindung lesen/schreiben zu können“ [Gün-12b].


15

Optical Character Recognition (OCR) bezeichnet Verfahren zu automatischen Identi-

fizierung von Objekten durch spezielle Schrifttypen, die nicht nur von Maschinen

sondern im Notfall oder zur Kontrolle von Menschen gelesen werden können. We-

gen der teureren und komplizierten Lesegeräte ist Anwendung von OCR in der In-

dustrie nicht verbreitet.

Chipkarten sind spezielle Karten (meistens aus Plastik) mit einem eingebauten elekt-

ronischen Speicher (Chip) und gegebenenfalls mit zusätzlicher Rechenleistung. Zum

Betrieb werden Chipkarten in ein Lesegerät eingesteckt. Der dadurch entstehende

Kontakt dient zur Energieversorgung der Karte sowie zur Datenübertragung.

Unter Biometrischen Verfahren versteht man Identifikationsverfahren, die „Personen

durch den Vergleich von unverwechselbaren und individuellen Körpermerkmalen

identifizieren“ [Fin-06]. Die häufig eingesetzten Biometrische Verfahren in der Praxis

sind die Fingerabdruck-Verfahren und die Sprachidentifizierung.

In der Lebensmittellogistik ist Barcode die am meisten verbreitete Identifikations-

technik. RFID wird seit den letzten Jahren auch zunehmend eingesetzt. Die anderen

Verfahren haben nur wenige Anwendungsfelder in der Logistik und werden daher in

dieser Arbeit nicht mehr weiter betrachtet.

2.3.2 Die Barcode-Technologie

Die Geschichte der Barcode-Technologie beginnt im Jahr 1948. Zwei US-

Amerikaner haben in diesem Jahr ein Strichcodesystem entwickelt, das zum Ziel hat,

die automatische Abfrage von Produktdetails an der Supermarktkasse zu ermögli-

chen. Auf diese Erfindung erhielten sie drei Jahre später ein Patent [Woo-52]. Der

große Durchbruch für Barcode-Systeme erfolgte allerdings erst in den 1970er Jah-

ren, als die US-amerikanische Supermarktkette Wal-Mart ihre Hersteller aufforderte,

ihre Produkte mit einheitlichen Strichcodes zu kennzeichnen [Buc-11]. Mit der Zeit

haben sich unterschiedliche Barcode-Varianten und –Standards etabliert und heut-

zutage ist Barcode die am weitesten verbreitete Identifikationstechnologie in der

Industrie.

„Ein Barcode enthält Informationen, die nach bestimmten Vorschriften verschlüsselt

wurden und stellt diese Informationen innerhalb des Barcodefeldes in Form von ge-

färbten Strichen und farblosen Lücken grafisch dar“ [Han-94]. Gelesen wird Barcode

durch ein optisches Datenerfassungsgerät, wie zum Beispiel einen Scanner (1D-

Barcode) oder ein Kamerasystem (2D-Barcode). Für unterschiedliche Farben bzw.


16

Breiten der Striche im Barcode werden elektrische Signale mit unterschiedlichen

Stärken bzw. Dauern generiert. Die Signale werden anschließend von einem Deco-

der in eine Zeichenfolge umgewandelt und an das nachgeschaltete System wie zum

Beispiel einen PC übertragen.

In der Industrie werden heutzutage grundsätzlich zwei Typen von Barcodes verwen-

det, das eindimensionale (1D) Barcode und das zweidimensionale (2D) Barcode. Das

2D-Code lässt sich wiederum in Stapelcode und Matrixcode unterteilen (siehe Ab-

bildung 2-5).

Barcode

Matrixcode

Stapelcode

1D- Barcode

2D-Barcode

Abbildung 2-5: Klassifizierung von Barcodes

In der Lebensmittelbranche wird 1D-Barcode (Strichcode) schon seit langem einge-

setzt. Dazu ist die EAN (European Article Number) das am weitesten verbreiteten

Nummerierungssystem. Durch den Zusammenschluss der Nummernvergabe-

Organisationen EAN International und Uniform Code Council zu GS1, wurde Anfang

2009 die EAN in GTIN (Global Trade Item Number) umbenannt.

Der EAN-13/GTIN-13-Code ist heutzutage auf fast allen Lebensmittelprodukten in

deutschen Supermärkten zu finden. Er stellt eine international unverwechselbare

Produktkennzeichnung dar. Er wird in der Regel als Strichcode auf die Produktpa-

ckung aufgedruckt und kann durch Barcodescanner beispielsweise an den Kassen

gelesen werden (siehe Abbildung 2-6). Die 13 Ziffern des Codes bedeuten: Länderp-

refix (2-3 Stellen), Unternehmensnummer (3-8 Stellen), Artikelnummer (2-6 Stellen)

und Prüfziffer (1 Stelle). Der EAN-13-Code ermöglicht die Kennzeichnung von Arti-

keln gleicher Spezifikationen. Allerdings können Einzelprodukte aufgrund der fehlen-

den Seriennummer nicht dadurch eindeutig identifiziert werden.


17

Länderprefix Unternehmen-snummer

Artikel-nummer

Prüfziffer

Abbildung 2-6: EAN-13-Code

In der Lebensmittellogistik wird neben dem EAN-13/GTIN-13-Code der GS1-128-

Barcode (die ehemalige EAN-128) häufig verwendet. Mit Hilfe der sogenannten Da-

tenbezeichner in GS1-128, die den Typ und den Aufbau der nachfolgenden Daten

beschreiben, können verschiedene Informationen aneinandergereiht werden. Der

bekannteste Einsatz ist die Kennzeichnung Nummer der Versandeinheit (NVE, auf

Englisch SSCC: Serial Shipping Container Code). Die NVE beginnt mit dem Daten-

bezeichner 00 und identifiziert jede Transporteinheit in der Logistikkette eindeutig.

Visualisiert wird sie durch einen GS1-128-Strichcode auf einem Transportetikett, das

normalerweise auf einer Transportgebinde (Palette, Behälter, Karton etc.) angeb-

racht ist (siehe Abbildung 2-7). Der Strichcode ermöglicht die automatische Erfas-

sung der NVE mittels Scanner. In Verbindung mit EDI können die Prozesse sowie die

Datenpflege bei Warenversand und -empfang in der Lieferkette dadurch beschleu-

nigt sowie zuverlässiger gestaltet werden.


18

Abbildung 2-7: Beispiel Transportetikett mit NVE in GS1-128-Standard [Dru-12]

2D-Barcodes haben im Vergleich zu traditionellen Stichcodes Vorteile, dass deutlich

mehr Daten auf engem Raum codiert können. Außerdem können die Daten fast alle

möglichen Zeichen umfassen: Zahlen, Texte, Sonderzeichen oder auch verschlüs-

selte Daten. In Abbildung 2-8 wird ein Beispiel der Anwendung des QR-Codes, einer

speziellen Form eines Matrixcodes, gezeigt. Der Ketchup-Hersteller Heinz verwen-

det heute die QR-Codes auf seinen PET-Ketchup-Flaschen. Durch das Einscannen

des Codes mit Hilfe eines mobilen Gerätes wie zum Beispiel eines Smartphones ge-

langen die Verbraucher auf eine Website, auf der zusätzliche Umweltinformationen

über die Herstellung der PET-Flasche dargestellt sind [mob-11]. Die Anwendung von

2D-Barcodes ist zwar noch nicht so weit verbreitet wie die Strichcodes in der Le-

bensmittelbranche, es ist aber beobachtbar, dass sie zunehmend eingesetzt werden.


19

Abbildung 2-8: Heinz Tomato Ketchup mit QR-Codes [mob-11]

2.3.3 Die RFID-Technologie

Obwohl der Barcode aufgrund seiner Preisvorteile und seiner technischen Zuverläs-

sigkeit den Markt der Auto-ID Systeme dominiert, wird er in der heutigen Lebensmit-

tellogistik vielen Anforderungen nicht mehr gerecht. Er bietet nur begrenzten Infor-

mationsgehalt und kann nicht umprogrammiert werden. Außerdem ist seine Lese-

reichweite sehr beschränkt und eine Pulkerfassung ist nicht möglich. Im Vergleich

dazu besitzt die RFID-Technologie alle oben genannten Vorteile. Daher nimmt die

Verbreitung der RFID-Technologie in vielen Branchen stetig zu. Viele Unternehmen

in der Lebensmittelbranche erproben die RFID-Technologie derzeit in Pilotprojekten.

Bevor das Potenzial für RFID-Einsatz in der Lebensmittellogistik vorgestellt wird,

werden im Folgenden zunächst die technischen Grundlagen der RFID-Technologie

erklärt.

2.3.3.1 Komponente eines RFID-Systems

Ein RFID-System besteht im Wesentlichen aus den Komponenten, die in Abbildung

2-9 dargestellt sind: Transponder, Schreib-/Lesegerät, Antenne und einer IT-

Infrastruktur, die die erfassten Daten verarbeitet und interpretiert [Gün-12a].


20

FunkwelleTransponder Antenne Schreib-/Lesergerät IT-Infrastruktur

Abbildung 2-9: Hauptkomponenten eines RFID-Systems

Der Transponder, der eigentliche Datenträger des RFID-Systems, besteht üblicher-

weise aus einem Computerchip und einer damit verbundenen Antenne. Er kann im

Regelfall berührungslos gelesen und/oder programmiert werden. Die RFID-

Transponder unterscheiden sich durch Übertragungsfrequenz, Speicherplatz und

Energieversorgungsart. Darauf wird in Abschnitt 2.3.3.2 näher eingegangen. Nach

Verwendungszweck gibt es RFID-Transponder auch in vielen verschiedenen Formen

und Größen. Die am häufigsten eingesetzten Transponder in der Logistik sind RFID

Smart Labels. Smart Labels sind ultraflache passive RFID-Transponder, die samt

Antenne auf selbstklebende Papier- oder Kunststoffmaterialien aufgebracht werden.

Sie können wie bisherigen Etiketten auf eine Palette, einen Karton oder direkt auf ein

Produkt geklebt werden. Im Vergleich zu anderen Bauformen sind Smart Labels

auch kostengünstiger in Massenproduktion. Für Anwendungen unter harten Um-

weltbedingungen werden Transponder in Kunststoffgehäusen verwendet. In Trans-

ponder mit Gehäusen können außerdem Sensoren integriert werden (vgl. Abbildung

2-10).

RFID Smart Labels RFID Transponder in Kunststoffgehäusen

Abbildung 2-10: Häufig verwendete RFID-Barformen

Das Schreib-/Lesegerät (SLG), das häufig als Reader bezeichnet wird, hat die Auf-

gabe, die Informationen aus einem Transponder auszulesen und ggf. Daten auf ei-

nen Transponder zu schreiben. Das SLG besteht üblicherweise aus einem Hochfre-

quenzmodul (Sender und Empfänger), einer Steuereinheit, einem Koppelelement


21

zum Transponder sowie Schnittstellen, die die Daten an die übergeordnete IT-

Infrastruktur weiterleiten [Fin-06].

Es ist zwischen stationären SLG und mobilen SLG zu unterscheiden. Stationäre SLG

werden an festen Identifikationspunkten im Unternehmen aufgebaut und sind die

gängigste Bauform. Über die entsprechenden Schnittstellen können eine oder meh-

rere Antennen am Reader angeschlossen werden. Die Verbindung über diverse

Schnittstellen (RS232, USB oder Ethernet etc.) erleichtert die Integration in beste-

hende übergeordnete Systeme. Mobile SLG haben eine kompakte Bauform, wobei

die Antennen im Gerät integriert sind. Mobile Geräte wie zum Beispiel Handhelds

ermöglichen eine flexible Vorort-Identifikation von Transpondern. Die Daten können

zwischengespeichert und zu einem späteren Zeitpunkt über WLAN oder Docking-

Station übertragen werden [Bro-12] (vgl. Abbildung 2-11).

RFID-Gate am Lehrstuhl fmlBeispiel für stationäre SLG

RFID-HandheldBeispiel für mobile SLG

Abbildung 2-11: Beispiel für RFID Schreib-/Lesegeräte [FML-12b], [RFI-12]

Die Antenne hat die Aufgabe, die Leistung des RFID-Readers möglichst gut in die

Funkstrecke abzustrahlen und wieder aufzunehmen. Die Eigenschaften der Antenne

lassen sich in diverse mechanische (Größe, Typ, Robustheit) und elektrische Para-

meter (Richtgewinn, Frequenzbereich, Öffnungswinkel, Polarisation, Stehwellenver-

hältnis) einteilen. Je nach Anwendungsanforderungen können verschiedene Anten-

nen eingesetzt sowie konfiguriert werden [Gün-11a].

Neben den oben genannten Hardware-Komponenten spielt die IT-Infrastruktur bei

RFID-Anwendungen eine entscheidende Rolle. Die Aufgabe der IT-Infrastruktur be-

steht darin, erfasste Rohdaten von SLG weiterzuverarbeiten und zu interpretieren,

damit der Einsatz von RFID echten geschäftlichen Mehrwert bieten kann [RFI-05].

Eine wichtige Komponente in der IT-Infrastruktur ist die Middleware, die die RFID-

Daten bereinigt, aggregiert, in geeignete Datenformate transformiert und dann an


22

übergeordnete IT-Applikation weiterleitet [Tam-10]. Die IT-Applikation kann entwe-

der ein bestehendes Informationssystem im Unternehmen sein wie zum Beispiel das

ERP-System oder ein spezielles RFID-Anwendungsprogramm sein, das die RFID-

Daten nach Anforderungen interpretiert und darstellt, um ihr Potenzial zur Optimie-

rung von Geschäftsprozessen vollständig nutzen zu können.

2.3.3.2 Differenzierung und Charakterisierung von RFID-Systemen

RFID-Systeme werden in vielen verschiedenen Varianten angeboten. Um einen

Überblick darüber zu geben, werden die Differenzierung und Charakterisierung von

RFID-Systemen im Folgenden erläutert.

Die wesentlichen Unterscheidungsmerkmale von RFID-Systemen sind in Tabelle 2-1

zusammengefasst [Fin-06], [Wag-09].

Tabelle 2-1: Unterscheidungsmerkmale von RFID-Systemen

Frequenzbereich Energieversorgung Speicherzugriff Datenmenge

LF-Bereich passiv Read-Only 1 Bit EAS

HF-Bereich aktiv Read-Write > 1 Bit, bis mehreren

KBytes

UHF-Bereich semi-passiv

SHF-Bereich

Frequenzbereich: Je nach Anwendung können RFID-Systeme in verschiedenen Fre-

quenzbereichen arbeiten. Grundsätzlich werden die Arbeitsfrequenzen von RFID-

Systemen in Deutschland den vier Bereichen LF (Low Frequency, 100 ~ 134 KHz),

HF (High Frequency, 13,56 MHz), UHF (Ultra High Frequency, 868 MHz) und SHF

(Super High Frequency, Mikrowelle, 2,45 und 5,8 GHz) zugeordnet. RFID-Systeme

der verschiedenen Frequenzbereiche haben unterschiedliche Funktionsweisen und

dadurch auch unterschiedliche Eigenschaften hinsichtlich der Lesereichweiten sowie

des Einflusses von Umweltstörungen. Bei RFID-Systemen, die in LF- und HF-

Bereichen arbeiten, erfolgt die Energieübertragung mittels induktiver Kopplung. Die

typische Lesereichweite liegt zwischen wenigen Millimetern und etwa einem Meter.

Bei Systemen, die in UHF- und SHF-Bereichen arbeiten, wird die elektromagneti-

sche Kopplung (Backscatter-Verfahren) genutzt. Die Lesereichweite kann von bis zu

sieben Meter für passive Transponder und von bis zu über 100 Meter für aktive

Transponder erreichen [Fri-10]. In Abbildung 2-12 sind die nutzbaren Frequenzbe-

reiche in Deutschland sowie ihre typischen Anwendungen dargestellt. Es ist zu beo-


23

bachten, dass UHF-Systeme bei Logistikanwendungen überwiegend eingesetzt

werden.

Abbildung 2-12: Überblick über nutzbare RFID-Frequenzen in Deutschland und dazugehörige bei-

spielhafte Anwendungen [Wag-09]

Energieversorgung: Hinsichtlich der Energieversorgung der RFID-Transponder un-

terscheidet man zwischen passiven, aktiven und semi-passiven Transpondern. Pas-

sive RFID-Transponder haben keine eigene Stromversorgung und müssen die Ener-

gie, die sie zum Senden ihrer Daten benötigen, aus den empfangenen Funkwellen

des RFID-Readers ziehen. Passive Transponder sind normalerweise preisgünstig, da

der Einbau einer eigenen Energiequelle entfällt. Der Nachteil liegt in der dadurch re-

lativ geringen Lesereichweite. Im Gegensatz zu passiven Transpondern verfügen

aktive RFID-Transponder über ihre eigene Energiequelle, die sowohl zur Versorgung

des Mikrochips als auch zur Datenübertragung benutzt wird. Mit eingebauten Batte-

rien besitzen aktive Transponder eine deutlich höhere Lesereichweite von bis zu 100

Meter, eine größere Speicherkapazität und auch eine etwas höhere Lesezuverlässig-

keit. Allerdings ist ihr Preis dadurch viel höher als der der passiven Transponder und

ihre Lebensdauer mit maximal fünf bis zehn Jahren relativ kurz. Semi-passive

Transponder, auch als semi-aktive Transponder bezeichnet, haben ebenfalls eine

eigene Energiequelle. Die Batterie wird hier jedoch nur zum Betrieb des Mikrochips

benutzt. Zur Datenübertragung nutzen semi-passive Transponder so wie passive

Transponder die Energie aus den Funkwellen des RFID-Readers. Dadurch besitzen

sie die Lesezuverlässigkeit eines aktiven und die Lesereichweite eines passiven

Transponders. Außerdem können Sensoren in sie integriert werden, wie zum Bei-


24

spiel Temperatursensoren oder Feuchtigkeitssensoren, welche neue Anwendungen

von RFID-Systemen ermöglichen [Mel-06].

Speicherzugriff: Ein weiteres Unterscheidungsmerkmal von RFID-Systemen besteht

im Speicherzugriff der RFID-Transponder. Dabei wird grundsätzlich zwischen Read-

Only- und Read-Write-Systemen unterschieden. Bei Read-Only-Systemen werden

die Daten (meist eine Seriennummer) vom Hersteller auf die Transponder program-

miert, die danach von RFID-Readern nur gelesen, also nicht geändert werden kön-

nen. Aufgrund des einfachen Aufbaus sind Read-Only-Transponder kostengünstig in

der Herstellung. Bei Anwendungen ohne Datenspeicherung sind Read-Only-

Transponder ausreichend. Im Gegensatz dazu können Read-Write-Transponder

durch RFID-Reader mit Daten beschrieben werden. Diese Transponder verfügen

über individuell beschreibbare Speicherbereiche und sind dadurch wesentlich kos-

tenintensiver [Fin-06].

Datenmenge: Die Speicherkapazität eines RFID-Transponders variiert je nach Typ

von einem Bit bis zu mehreren KBytes. Die einfachste 1-bit-Transponder speichern

lediglich eine ja/nein- bzw. 1/0- Information und werden häufig zur Elektronischen

Artikelsicherung (EAS) nämlich der Diebstahlsicherung in Kaufhäusern und Geschäf-

ten eingesetzt [Fin-06]. Die typischen passiven RFID-Transponder besitzen eine

Speicherkapazität zwischen 128 und 2048 Bit, da die Energie zum Betrieb der

Transponder aus dem Feld gewonnen werden muss und dadurch nur geringe Da-

tenmengen vor allem bei kurzen Verweilzeiten im Lesefeld übertragen werden kön-

nen. Im Vergleich dazu verfügen aktive Transponder normalerweise über eine höhere

Speicherkapazität aufgrund ihrer eigenen Energieversorgung und ihrer größeren Le-

sereichweite. Für Transponder mit Sensorintegration können dadurch Messdaten

zusätzlich mit aufgezeichnet werden [Wag-09].

2.3.3.3 Einflussfaktoren auf RFID-Systeme

Der zunehmende Einsatz von RFID ist ein anhaltender Trend in der Logistik. Aller-

dings wird RFID gleichzeitig auch kritisch betrachtet, da sie störungsanfälliger gege-

nüber Umwelteinflüssen im Vergleich zu anderen Auto-ID Technologien ist. Zu den

wichtigsten Einflussfaktoren auf RFID-Systeme zählen [Fru-12]:

· Materialien：Das Objektmaterial, auf das ein Transponder angebracht wird, hat

eine starke Auswirkung auf die Lesereichweite des Transponders, da es entspre-

chend seiner elektrischen Eigenschaften die Resonanzfrequenz des Transpon-

ders verändern kann [Gün-11b]. Außerdem ist es bei UHF-Systemen üblich, dass

die elektromagnetischen Wellen von den Applikationsmaterialien, vor allem bei


25

metallischen Oberflächen, absorbiert und reflektiert werden, wodurch die Sys-

temleistung stark beeinflusst werden kann. Eine beispielhafte Messung der Lese-

reichweite eines UHF-Transponders auf verschiedene Applikationsmaterialien ist

in Abbildung 2-13 dargestellt.

Abbildung 2-13: Vergleich der Lesereichweite eines Transponders (ALL-9460 Omni Squiggle) nach

verschiedenen Applikationsmaterialien

· Elektrische Störquellen: Unter elektrische Störquellen versteht man elektrische

Geräte oder Komponenten wie zum Beispiel Motoren, Anlagen, Netzteile usw.,

die sich in unmittelbarer Nähe der RFID-Antennen befinden und den Datenaus-

tausch von RFID-Systemen beeinflussen können. Solche Störquellen sollten

beim Einsatz von RFID-Systemen möglichst vermieden werden.

· Umgebungszustände: Bei Einführung von RFID-Systemen sollten die jeweiligen

Umgebungsbedingungen Berücksichtigung finden. Feuchtigkeit oder Wasser

kann elektromagnetische Wellen absorbieren und somit die Lesereichweite stark

einschränken. Hohe Temperaturen können normale Transponder beschädigen.

Je nach Anwendungsbedarf sind daher entsprechende Systeme und Transpon-

der auszuwählen. Die RFID-Hersteller bieten eine Vielfalt von RFID-Transpondern

an, die unter verschiedenen thermischen, chemischen oder physikalischen Rah-

menbedingungen eingesetzt werden können.


26

2.3.4 Vergleich von RFID mit Barcode

Der Einsatz von RFID ist ein Megatrend der Logistikbranche. Die zunehmende Ein-

führung von RFID wird die traditionellen Barcodes allerdings auf keinen Fall voll-

ständig ersetzen. In Tabelle 2-2 werden die Merkmale der beiden Technologien ver-

gleichend gegenübergestellt [Fin-06], [Kla-12], [DHL-07].

Tabelle 2-2: Vergleich der Merkmale von RFID und Barcode

Merkmal RFID Barcode

Datenzugriff wiederbeschreibbar nicht wiederbeschreibbar

Typische Datenmenge (Byte) 16 - 64k 1 - 100

Datenübertragung per Funk optisch

Sichtkontakt nicht notwendig notwendig

Lesereichweite 0 -100 m je nach Frequenz und Energieversorgung0

0 - 50 cm

Einfluss von Schmutz kein Einfluss stark

Einfluss von Applikationsmateria-lien (zum Beispiel Metall)

stark gering

Einfluss von Flüssigkeit stark gering

Pulkerfassung ja nein

Lesegeschwindigkeit sehr schnell ( ~ 0.5 s) schnell ( ~ 4 s)

Manipulation schwer leicht

Datenschutz notwendig nicht notwendig

Anschaffungskosten mittel/hoch gering

Standardisierungsgrad niedrig (in Entwicklung) hoch

Der obigen Tabelle ist zu entnehmen, dass die Vorteile von RFID gegenüber Barco-

de hauptsächlich in folgenden Punkten liegen:

· Im Gegensatz zu Barcode verfügen RFID-Transponder über einen Datenspeicher

mit größer Kapazität und der Möglichkeit der Überschreibbarkeit.

· Zur Identifikation ist keine Sichtverbindung notwendig. Die Lesereichweite ist

größer und die Lesegeschwindigkeit ist schneller.

· Ein Hauptvorteil von RFID-Systemen ist die Fähigkeit der gleichzeitigen Erfas-

sung mehrerer Transponder (Pulkerfassung). Dies kann z.B. durch Beschleuni-

gung zur Optimierung von Logistikprozessen beitragen.


27

· RFID-Transponder sind im Vergleich zu Barcodes unempfindlicher gegenüber

Schmutz und leichte Beschädigungen.

· Die Daten auf RFID-Transpondern können nur schwer kopiert und manipuliert

werden, vor allem wenn Verschlüsselungsmechanismen eingesetzt werden.

Den oben genannten Vorteilen stehen folgenden Nachteile gegenüber:

· Die Leistung von RFID-Systemen kann stark von Applikationsmaterialien beeinf-

lusst werden, vor allem von Metall. Außerdem wird die Lesereichweite einge-

schränkt, wenn sich Flüssigkeiten in der Nähe befinden. In solchen Umgebungen

finden spezielle Transponder Anwendung, die vergleichsweise teuer sind.

· Die Anschaffungskosten von RFID, vor allem die Stückkosten der RFID-

Transponder, sind im Verhältnis höher. Obwohl der Preis in Zukunft vermutlich

sinken wird, stehen die Anwender einer item-Level-Identifikation durch RFID we-

gen des Kostenaufwands noch immer kritisch gegenüber.

· Weil RFID mehr Daten speichern und über größere Entfernung übermitteln kann,

besteht die Befürchtung, dass Daten zur Überwachung oder Manipulation miss-

braucht werden könnten. Deswegen ist Datenschutz und –sicherheit ein wichti-

ges Thema, das man bei der Anwendung von RFID-Systemen berücksichtigen

muss.

· Eine entscheidende Voraussetzung für den erfolgreichen Einsatz der Auto-ID-

Technologie in der unternehmensübergreifenden Logistikbranche ist die Entwick-

lung und Anwendung einheitlicher Standards. In der Industrie ist Barcode weit

verbreitet und eine weltweite Standardisierung ist weit fortgeschritten. Im Ver-

gleich dazu ist die Standardisierung von RFID-Anwendungen noch unzureichend,

was die Implementierung kettenübergreifende Anwendungen erschwert.

Aus der obigen Diskussion ist ersichtlich, dass die RFID-Technologie gegenüber

dem in der Industrie am häufig eingesetzten Barcode sowohl Vorteile also auch

Nachteile bietet und deswegen Barcode nicht ersetzten kann. Nachvollziehbar ist

aber, dass durch einen sinnvollen RFID-Einsatz in der Supply-Chain neue Mög-

lichkeiten der Prozessoptimierung entstehen, welche mit dem herkömmlichen

Barcode nur schwer realisierbar sind. Im folgenden Abschnitt wird näher be-

trachtet, welche Potenziale durch RFID-Einsatz in der Lebensmittel-Supply-

Chain entstehen.


28

2.3.5 Potenzial durch RFID-Einsatz in der Lebensmittel-Supply-Chain

Der Einsatz von RFID bietet zahlreiche Möglichkeiten, Logistikprozesse in der Le-

bensmittelkette zu verbessern. Im Folgenden sind die Hauptpotenziale des RFID-

Einsatzes innerhalb der Warenstromkette der Lebensmittelindustrie zusammenge-

fasst [FOR-11]:

· Erhöhung der Transparenz der Lebensmittelkette

Durch die Erhöhung der Transparenz der Materialflüsse können Prozesse effizienter

und nachvollziehbarer gestaltet werden. Dies bedingt einen echtzeitigen Datenaus-

tausch in der Lieferkette, der die Warenflüsse mit den Informationsflüssen synchro-

nisiert. Für diesen Datenaustausch kann die RFID-Technologie eingesetzt werden.

Die eindeutige Identifikation und die automatische Erfassung von Objekten durch

den Einsatz von RFID können helfen, Logistikprozesse mit aktuellen Daten zu un-

terstützen und die maximale Transparenz der Lebensmittelkette zu realisieren. Dafür

spielt die Standardisierung des Datenaustausches über Unternehmensgrenze hin-

weg eine entscheidende Rolle, was in Abschnitt 2.4 weiter diskutiert wird.

· Sicherung der Qualität von Lebensmitteln durch sensorbasierte Überwachung der Umgebungsbedingungen

Verbraucher und Gesetzgeber stellen immer höhere Ansprüche an Produktsicherheit

und –qualität. Da Nahrungsprodukte im Vergleich zu anderen Produkten anfälliger

gegenüber Umgebungsbedingen wie Temperatur, Feuchtigkeit, Erschütterung usw.

sind, ist eine lückenlose Überwachung der Lebensmittelkette von großer Bedeutung.

Dies gilt vor allem für Tiefkühlprodukte und schnell verderbliche Waren wie Frisch-

fleisch, Obst und Gemüse. Die Lebensmittelhändler sind gesetzlich verpflichtet, die

Temperaturen sowie andere Umgebungsbedingungen während der Lieferprozesse

zu protokollieren. Hier kommt RFID mit integrierten Sensoren zunehmend zum Ein-

satz. Die Kombination von RFID und Sensorik ist ein neues Einsatzgebiet der RFID-

Technologie, das rezent in Forschung und Industrie untersucht wird. Abbildung 2-14

zeigt ein Beispiel eines auf dem Markt erhältlichen RFID-Transponders mit integrier-

ten Temperatursensoren. Es ist ein semi-passiver Transponder, der im UHF-

Frequenzbereich arbeitet. Dieser Transponder verfügt über eine eindeutige Identifi-

kationsnummer und kann bis zu insgesamt 8192 Temperatur-Samples speichern

[CAE-12].


29

Abbildung 2-14: Beispiel RFID mit Sensorik: CAEN A927Z RFID-Temperaturlogger [CAE-12]

· Steigerung der Effizienz von Prozessen in der Lebensmittelkette Im Lebensmittelhandel lässt sich die Effizienz der Prozesse durch die berührungslo-

se Identifikation vor allem bei Wareneingangs-, Warenausgangs- und Inventurkont-

rolle steigern. Durch den Einsatz von RFID-Lesegeräten wie zum Beispiel RFID-

Toren in den Warenein- und -ausgangszonen werden die Versandeinheiten (Paletten,

Behälter, etc.) automatisch erkannt. Danach prüft das entsprechende IT-System, ob

die Lieferung der Bestellung entspricht, bevor die Waren ausgeliefert oder entnom-

men werden. Dadurch entfällt das aufwändigere manuelle Scannen der traditionellen

Barcodes, so dass die Lieferungsprozesse beschleunigt werden. Durch den Einsatz

von modernen RFID-Systemen wie zum Beispiel das Mojix-STAR-System in Distri-

butionszentren oder in Lagerhäusern ist es möglich, eine automatische und fehler-

freie Inventur durchzuführen, wodurch Zeitaufwand und Zählfehler bei traditioneller

Inventurprozesse vermieden werden können. Das Mojix-STAR ist ein revolutionäres

UHF-RFID-System, das in Abbildung 2-15 skizziert ist. In diesem System werden die

Sender (enodes) und der Empfänger (STAR) des RFID-Systems getrennt. Durch die

räumliche Verteilung der Enodes können RFID-Transponder in verschiedenen Berei-

chen im Lager aktiviert werden. Die Antwortsignale der Transponder werden wiede-

rum von der einzigen empfindlichen Empfangseinheit, nämlich dem STAR über eine

hohe Distanz empfangen. Dadurch ist eine flächendeckende Erfassung durch RFID

möglich [FML-12b], [Far-09].


30

Abbildung 2-15: Prinzipskizze des Mojix-STAR-System [FML-13]

· Vereinfachte Rückverfolgbarkeit in der Lebensmittelkette

Eine lückenlose und effiziente Produktrückverfolgbarkeit gewinnt in den letzten Jah-

ren zunehmend an Bedeutung. RFID bietet dabei enormes Potenzial, Rückverfolg-

barkeitssysteme durch automatische Datenerfassung deutlich effizienter zu gestal-

ten. Außerdem können die Prozesskosten und der Zeitaufwand bei eventuellen

Rückrufaktionen dadurch erheblich reduziert werden [Kel-07]. Obwohl die Produkt-

Level-Identifikation durch RFID aufgrund der relativ hohen Transponderkosten heut-

zutage noch selten ist, ist die Idee, Transporthilfsmittel (Paletten, Behältern) durch

RFID zu identifizieren, in Forschung und Industrie schon verbreitet. Die Rückverfolg-

barkeit der Ware kann dann dadurch realisiert werden, dass die zu transportierende

Ware den Transporthilfsmitteln eindeutig zugeordnet wird.

Die Rückverfolgung von Waren ist, wie bereits in Abschnitt 2.2.3 erläutert, ein ket-

tenübergreifender Prozess, an dem alle Unternehmen in der Lieferkette beteiligt sind.

Deswegen sollte man bei der Einführung von RFID-basierten Rückverfolgbarkeits-

systemen nicht nur die technische Machbarkeit gewährleisten, sondern auch darauf

achten, dass keine Insellösungen bei der Umsetzung entstehen. Dabei kommt der

Standardisierung eine große Bedeutung zu, was im folgenden Abschnitt näher be-

trachtet wird.

Notwendigkeit zur Standardisierung des Auto-ID-basierten Datenaustausches in der

Lebensmittelkette

31

2.4 Notwendigkeit zur Standardisierung des Auto-ID-basierten Datenaustausches in der Lebensmittelkette

Wie bei vielen anderen Technologien ist die Entwicklung einheitlicher Standards eine

entscheidende Voraussetzung für eine weite Verbreitung des Auto-ID-Einsatzes [Ele-

12]. In der Lebensmittelindustrie ist die Anwendung von Barcode basierend auf dem

EAN-System seit langem hoch standardisiert. Im Vergleich dazu ist die Standardisie-

rung bei RFID-Anwendungen in der Industrie noch unzureichend, was die Implemen-

tierung überbetrieblicher Anwendungen erschwert. Laut einer Teilnehmerbefragung

im Rahmen des 2. Hessischen RFID-Symposiums ist die fehlende Standardisierung

eine der Haupthürden bei der Einführung von RFID-Systemen [San-06].

Für die Gewährleistung der Materialflusstransparenz sowie einer lückenlosen Rück-

verfolgbarkeit in der gesamten Wertschöpfungskette ist die Unterstützung einer ein-

heitlichen Datenstandards, wie bereits in Abschnitt 2.3.5 vorgestellt, zwingend er-

forderlich. Das EPCglobal, eine Non-Profit-Organisation unter GS1, entwickelt seit

2003 Standards für die weltweit einheitliche Nutzung der RFID-Technologie, vor al-

lem für das UHF-System, das heute überwiegend in der Logistik und im Supply-

Chain-Management eingesetzt wird. Das EPCglobal-Netzwerk, das von EPCglobal

vorgeschlagen wird, gilt als eine Ausprägungsform für das sogenannte „Internet der

Dinge“. Dazu handelt sich beim Elektronischen Produkt Code (EPC) um ein Num-

mernsystem zur weltweit eindeutigen Kennzeichnung von Objekten und gilt als Ba-

sis des gesamten Netzwerkes. Darauf basierend werden weitere Netzwerkkompo-

nente und Schnittstellen vorgeschlagen, um die Vision des „Internet der Dinge“ zu

realisieren. Die Standardisierung der jeweiligen Komponenten hat in den letzten Jah-

ren Interesse sowohl in der Industrie als auch in der Forschung geweckt. Einerseits

müssen die bestehenden Standards für unterschiedliche Anwendungsszenarien an-

gepasst und erweitert werden, andererseits ist die Standardisierung noch nicht ab-

geschlossen und muss weiter entwickelt werden.

Im folgenden Kapitel wird das EPCglobal-Netzwerk vorgestellt. Es wird insbesonde-

re auf die wichtigen Komponenten zum kettenübergreifenden Datenaustausch ein-

gegangen. Aus der Untersuchung des Stands der Technik werden die Anforderun-

gen an die Forschungsarbeit abgeleitet und die Forschungsziele konkretisiert.


32

Die Vision des EPCglobal-Netzwerkes

33

3 Das EPCglobal-Netzwerk

3.1 Die Vision des EPCglobal-Netzwerkes

Das EPCglobal-Netzwerk wurde ursprünglich am Auto-ID Center des MIT (Massa-

chusetts Institute of Technology) wissenschaftlich konzipiert. Im Jahr 2003 wurde

die Non-Profit-Organisation EPCglobal als Nachfolgeorganisation des Auto-ID Cen-

ters gegründet. Zwei Jahre später wurde EPCglobal als Tochterunternehmen von

GS1, der international größten Organisation für Entwicklung von Standards zur Ver-

besserung von Wertschöpfungskette, übernommen, um das Konzept weiter zu ent-

wickeln bzw. weltweit voranzutreiben [Gil-07].

Die Vision des EPCglobal-Netzwerkes besteht darin, Informationen über Objekte

und Produkte mit Hilfe des Internets jederzeit verfügbar zu machen. Das Netzwerk

definiert standardisierte Komponente und Schnittstellen, damit die Informations-

transparenz entlang der gesamten Wertschöpfungskette realisiert werden kann.

Der Aufbauprinzip des EPCglobal-Netzwerkes lassen sich im Wesentlichen wie folgt

zusammenfassen [EPC-09a], [Cla-06], [Thu-06]:

· Globale Standards

Die einzelnen Netzwerk-Komponenten werden jeweils international standardisiert,

damit die EPCglobal-Standards überall auf der Welt eingesetzt werden können.

Dadurch sind mehr Unternehmen motiviert, am Netzwerk teilzunehmen. Mit

wachsender Anzahl der Beteiligten steigen die Nutzpotenziale des Netzwerkes

exponentiell.

· Modularer Aufbau

Das Netzwerk wird mit einzelnen Komponenten modular aufgebaut und die

Standardisierung jeweiliger Komponente kann separat erarbeitet werden. Somit

ist es möglich, dass die Standardisierung der RFID-Anwendungen je nach Bedarf

von Unternehmen flexibel und stufenweise umgesetzt wird.

· Plattform-Unabhängigkeit

Die Standards sollen bei verschiedenen Umsetzungsplattformen umgesetzt wer-

den können. Daher ist es notwendig, die Standardisierung der Komponenten und

Schnittstellen mit Plattform-neutralen Sprachen oder Technologien wie zum Bei-

spiel XML, SOAP, usw. zu beschreiben.


34

· Offenes System

Die resultierenden Dokumentationen der Standardisierung sind offen und stehen

jedem zur Verfügung. Alle Unternehmen sowie Forschungsorganisationen kön-

nen die Standardisierung selber umsetzen und auch an der Weiterentwicklung

teilnehmen.

· Skalierbarkeit und Erweiterbarkeit

Neben der Festlegung von Grunddatentypen und Grundfunktionalitäten sollendie

Spezifikationen die Möglichkeiten zur Erweiterung bieten, damit die Standardisie-

rungen anwendungsspezifisch angepasst bzw. mit der Zeit immer weiter vervoll-

ständigt werden können.

3.2 Architektur des Netzwerks

Die Architektur des EPCglobal-Netzwerkes ist in Abbildung 3-1 dargestellt. Auf der

linken Seite der Abbildung sind die wesentlichen Module zum Aufbau RFID-basierter

Anwendungen stufenweise angezeigt. Ihre entsprechenden Komponenten und die

benötigten Kommunikationsschnittstellen innerhalb des EPCglobal-Netzwerkes sind

nach der Broschüre „The EPCglobal Architecture Framework“ [EPC-09a] auf der

rechten Seite in der Abbildung illustriert. Wie bereits vorgestellt, wird das Netzwerk

modular aufgebaut. Es besteht aus verschiedenen Hardware- und Softwarekompo-

nenten, deren Standards jeweils separat erarbeitet werden können. Dazu entwickelt

EPCglobal Spezifikationen sowohl für die Low-Level-Kommunikation wie zum Bei-

spiel die Luftschnittstellen zwischen RFID-Transpondern und –Readern als auch für

die High-Level-Informationsdienste wie zum Beispiel den EPC Information Service

und den Discovery Service.

Für den unternehmensübergreifenden Datenaustausch entlang der Lieferkette sind

die folgenden Komponenten innerhalb des Netzwerkes von entscheidender Bedeu-

tung:

· Der Elektronische Produktcode

· Der EPC Information Service

· Der Object Name Service

· Der Discovery Service

Im Folgenden werden diese Komponenten jeweils näher betrachtet.

Der Elektronische Produktcode

35

Netzwerkdienst(Discovery Service / ONS)

Informationsdienst (EPCIS)

Middleware (ALE)

Schreib-/Lesegerät (Reader-Protokoll)

Transponder(Luftschnittstelle)

Abbildung 3-1: Architektur des EPCglobal-Netzwerkes (In Anlehnung an [EPC-09a])

3.3 Der Elektronische Produktcode

Der Elektronische Produktcode (EPC) ermöglicht eine eindeutige Identifikation von

Objekten und gilt als Grundlage für die gesamten EPCglobal-Standards. Als Daten-

träger für den EPC wird in der Regel ein UHF- oder ein HF-RFID-Transponder ver-

wendet, der an dem zu identifizierenden Objekt angebracht wird. Alternativ kann der

EPC auch in einem Barcode verschlüsselt werden.

Der EPC kann verschiedene Objekte kennzeichnen, von den einzelnen Produkten

über logistische Einheiten bis hin zu Lokationen. In Tabelle 3-1 sind die wesentlichen

EPC-Typen, die in den Logistik-Anwendungen eingesetzt werden, zusammenge-

fasst.


36

Tabelle 3-1: Häufig verwendete EPC-Typen in der Logistik (In Anlehnung an [EPC-11])

EPC-Typ Anwendung

Serialized Global Trade Item Number (SGTIN)

Eindeutige Kennzeichnung von einzelnen Produkten oder Verpackungseinheiten

Serial Shipping Container Code (SSCC) Auf Deutsch: Nummer der Versandeinheit (NVE) Eindeutige Kennzeichnung von Transporteinheiten

Global Returnable Asset Identifier (GRAI) Eindeutige Kennzeichnung von wieder verwendbaren Trans-porteinheiten wie zum Beispiel Palette, Behälter usw.

Global Individual Asset Identifier (GIAI) Eindeutige Kennzeichnung von Inventar wie zum Beispiel Maschinen, Anlagen usw.

Global Location Number (SGLN) Eindeutige Kennzeichnung von physischen Lokationen wie zum Beispiel einer Gebäude, einem bestimmten Lagerbe-reich usw.

Der EPC stellt eine Erweiterung der verbreiteten EAN (heute in GTIN umbenannt)

dar. Im Vergleich zu EAN/GTIN, die Produkte lediglich in Klassen und Typen kenn-

zeichnet, bietet der EPC die Möglichkeit, jedes einzelne Produkt oder die kleinste

Verpackungseinheit durch eine eindeutige Nummer zu identifizieren. Dafür wird eine

Seriennummer an die EAN/GTIN angehängt, wonach der EPC als SGTIN bezeichnet

wird.

Der EPC hat einen festen Aufbau, der in Abbildung 3-2 dargestellt ist. Der häufig

verwendete EPC ist 96 Bit lang und besteht aus mehreren Komponenten:

· Header: Kennzeichnung des nachfolgenden EPC-Typs (In diesem Beispiel

SGTIN-96).

· Filter: Gibt an, um welches Objekt es sich handelt (001 bedeutet hier Konsumar-

tikel).

· Partition: Gibt an, wo die beiden folgenden Felder, nämlich das EPC-Manager

und die Objektklasse, getrennt sind. Die gesamte Länge der beiden Felder be-

trägt 44 Bits.

· EPC-Manager: Kennzeichnung des Nummerngebers wie zum Beispiel des Hers-

tellers, wird von GS1 vergeben.

· Objektklasse: Kennzeichnung von Objektklassen und Typen.

· Seriennummer: Eindeutige Kennzeichnung individueller Teile.

Der EPC Information Service

37

Abbildung 3-2: Aufbau des EPCs am Beispiel einer SGTIN-96 (In Anlehnung an [Gil-07], [Sei-05])

3.4 Der EPC Information Service

Der EPC Information Service (EPCIS) spielt eine zentrale Rolle für Auto-ID-basierten

Datenaustausch in der Wertschöpfungskette. Seine Aufgaben bestehen darin, die

erfassten Transponder-Daten mit Geschäftskontext zu verknüpfen, zu speichern

sowie zur High-Level-Businessapplikationen zur Verfügung zu stellen. Dafür wurde

der EPCIS-Standard von EPCglobal entwickelt und 2007 erstmalig veröffentlicht.

Dieser Standard hat nicht nur die Struktur und den Inhalt von EPC-Ereignissen spe-

zifiziert, sondern auch die Schnittstellen zur Erfassung bzw. zur Abfrage der Ereig-

nisse definiert.

Die erfassten Transponder-Daten, die in EPCIS gespeichert sind, werden als EPCIS-

Ereignisse bezeichnet. Sie enthalten üblicherweise die folgenden Informationen, die

zur Verbesserung der Prozesstransparenz im Unternehmen von großer Bedeutung

sind:

· Was: Die erfassten EPC-Nummer.

· Wann: Den Zeitpunkt der Datenerfassung.

· Wo: Den Identifikationsort der Datenerfassung wie zum Beispiel „Warenein-

gangszone“.

· Warum: Den Kontext der Datenerfassung wie zum Beispiel „geliefert“.

Der Standard hat insgesamt vier Ereignisse-Typen für unterschiedliche Anwen-

dungsfälle definiert: das Objektereignis (ObjectEvent), das Aggregationsereignis

(AggregationEvent), das Quaititätsereignis (QuantityEvent) und das Transaktions-

ereignis (TransactionEvent). Jeder Ereignistyp erhält obligatorische und optionale

Attribute, in denen die „Was, Wann, Wo, Warum” Informationen abgespeichert wer-

den. Neben den definierten Ereignissen und Attributen bietet der Standard noch Er-

weiterungsmöglichkeiten, damit neue Ereignisse und Attributen für unterschiedliche

Anwendungsszenarien eingefügt werden können.

44 Bit


38

Im EPCIS-Standard werden, wie schon vorgestellt, auch die Kommunikations-

schnittstellen sowie ihre Bindungen nämlich ihre Umsetzungsmöglichkeiten spezifi-

ziert (siehe Tabelle 3-2).

Die Erfassungsschnittstelle wird genutzt, um die EPC-Informationen von einer Erfas-

sungsapplikation beispielsweise RFID-Middleware zur EPCIS-Datenbank (EPCIS-

Repository) weiterzuleiten bzw. in der Datenbank abzuspeichern.

Die Abfrage der EPCIS-Ereignisse kann in zwei unterschiedlichen Modi arbeiten:

dem synchronen Modus und dem asynchronen Modus. Im synchronen Modus wir

sofort auf spontane Abfragen des Clients geantwortet, wofür ausschließlich die EP-

CIS-Abfrage- und Steuerungsschnittstelle verwendet wird. Im Vergleich dazu arbei-

tet der asynchrone Modus mittels periodischer Abfrage. Das Abonnieren der Abfra-

ge wird durch die EPCIS-Abfrage- und -Steuerungsschnittstelle etabliert. Die Über-

mittlung der periodisch generierten Antwort erfolgt mittels der EPCIS-

Rückmeldeschnittstelle. Zudem kann diese Rückmeldeschnittstelle verwendet wer-

den, um EPC-Informationen nach ihrer Erfassung sofort zu Clientapplikationen zu

übermitteln (real-time push).

Tabelle 3-2: EPCIS-Kommunikationsschnittstellen und ihre Bindungsmöglichkeiten [EPC-09b], [Kik-

11]}

Schnittstellentyp Bindung

EPCIS-Ereignis, EPCIS-Abfrage XML

EPCIS-Erfassungsschnittstelle Message Queue, HTTP

EPCIS-Abfrage- und Steuerungsschnittstelle SOAP über HTTP via WSDL, AS2

EPCIS-Rückmeldeschnittstelle HTTP, HTTPS, AS2

3.5 Der Object Name Service

Der Object Name Service (ONS) ist ein Auffindungsdienst innerhalb des EPCglobal-

Netzwerkes und ist vergleichbar mit dem Domain Name System (DNS) des Internets.

Über den DNS können Internet-Hostnamen mit den dazugehörigen IP-Adressen ver-

knüpft werden. Eine ähnliche Funktion erfüllt der ONS im Rahmen des EPCglobal-

Netzwerkes. Über den ONS werden die Objektkennzeichnungen mit den entspre-

chenden EPCIS-Adressen der EPC-Manager (zum Beispiel Hersteller) verknüpft.

Der Discovery Service

39

Durch die Abfrage des Hersteller-EPCIS können Informationen zum Objekt abgeru-

fen werden.

Der ONS kann die DNS-Infrastruktur mit benutzen und wird daher auch als eine

Teilmenge des DNS gesehen. Der Aufbau des ONS enthält einen Root-Server, der

ausgehend von der EPC-Managernummer, die entsprechenden IP-Adressen der

Zugriffspunkte für weitere Informationen zur Verfügung stellt. Außerdem betreiben

die einzelnen EPC-Manager wie zum Beispiel die Hersteller ihren eigenen lokalen

ONS, der dann auf Ebene der Objektklasse auf die EPCIS-Adresse des EPC-

Managers verweisen kann. Bei der Implementierung können DNS-Server für den

ONS-Dienst verwendet werden [EPC-06].

Der Ablauf einer typischen ONS-Abfrage wird im Folgenden beschrieben [EPC-06],

[Heg-08]:

1. Die EPC-Nummer auf einem RFID-Transponder wird von einem RFID-Reader

erfasst und in Form von einer Bitsequenz an einen lokalen Server geschickt.

2. Der lokale Server übersetzt die Bitsequenz in URI-Form (Uniform Resource Iden-

tifier) und leitet sie an einen lokalen ONS-Resolver weiter.

Beispiel EPC in URI-Form: urn:epc:id:sgtin:0614141.000024.400

3. Der ONS-Resolver konvertiert das URI in einen Domainnamen und fragt diesen

bei DNS ab.

Beispiel Domainname: 000024.0614141.sgtin.id.onsepc.com

4. Die DNS-Infrastruktur antwortet mit der URL des gesuchten EPCIS zurück.

5. Der lokale ONS-Resolver extrahiert die URL aus der DNS-Antwort und leitet sie

an den lokalen Server weiter.

Beispiel: http://epc-is.example.com/epc-wsdl.xml

6. Der lokale Server kann jetzt mit der erhaltenden URL den richtigen EPCIS nach

weiteren Objektinformationen abfragen.

3.6 Der Discovery Service

Der Discovery Service wird auf Deutsch auch als Ermittlungsdienst bezeichnet, wel-

cher als eine Art Suchmaschine im EPCglobal-Netzwerk fungiert. Durch diesen

Dienst wird es dem Anwender ermöglicht, die Informationen zu einem bestimmten

EPC entlang der gesamten Lieferkette zu finden.

Im Vergleich zu ONS verweist der Discovery Service nicht nur auf die EPCIS-

Adresse des EPC-Managers wie zum Beispiel des Herstellers, sondern auf alle EP-


40

CIS mit Informationen zum abgefragten EPC (siehe Abbildung 3-4). Daher ist der

Discovery Service für das Tracking & Tracing entlang der Lieferkette von großer Be-

deutung.

Die Spezifikation für den Discovery Service ist bei EPCglobal noch unter Entwick-

lung. Sowohl in der Forschung als auch in der Industrie wurde in den letzten Jahren

intensiv untersucht, welche Funktionalitäten dieser Dienst haben sollte und wie die-

se zu implementieren sind.

ONS Discovery Service

Client

HerstellerEPCIS

HändlerEPCIS

KundeEPCIS

Abbildung 3-3: ONS vs. Discovery Service

3.7 Stand der Forschung

Das EPCglobal-Netzwerk bietet eine Standardisierungsplattform, die einen einheitli-

chen Einsatz von RFID-Technologien entlang der gesamten Lieferkette ermöglicht.

Die Softwarekomponenten, die in diesem Kapitel vorgestellt sind, spielen eine ent-

scheidende Rolle für unternehmensübergreifenden Datenaustausch und können

somit die Transparenz in der Supply-Chain erhöhen. Mit dem zunehmenden Einsatz

von RFID-Technologie wächst das Interesse weltweit sowohl in der Industrie als

auch in der Forschung, die Softwarekomponenten zu implementieren, zu testen so-

Stand der Forschung

41

wie weiterzuentwickeln. Die Forschungsaktivitäten in den letzten Jahren haben sich

vor allem auf die folgenden Bereiche konzentriert:

3.7.1 Einsatz und Anpassung von EPCIS

Nach Veröffentlichung des EPCIS-Standards wurde in verschiedenen Forschungs-

arbeiten und Pilotprojekten untersucht, wie dieser Standard in unterschiedlichen

Branchen eingesetzt und ggf. erweitert werden kann.

· Forschungen in anderen Branchen

Für die Automobilbranche: Jürgen Sauser hat in seiner Promotion den Einsatz von

EPCIS in der Automobil-Supply-Chain untersucht [Sau-08]. Ein neuer Ereignisstyp,

nämlich das „AssemblyEvent“ wird als Erweiterung des Standards vorgeschlagen,

weil der vorhandene Standard-Ereignistyp „AggregationEvent“ laut Autor die Mon-

tageprozesse in der Automobilindustrie nicht exakt wiedergeben kann. In VDI 4472

[VDI-4472] werden die Richtlinien für den EPCIS-Einsatz in der Automobilindustrie

dargestellt. Der vorgeschlagene neue Ereignistyp, nämlich das „AssemblyEvent“,

wird als Erweiterung des EPCIS-Standards in diesen Richtlinien übernommen. Im

laufenden Projekt RAN (RFID-based Automotive Network) [RAN-12] wird EPCIS

ebenfalls für den Datenaustausch in RFID-basierten Logistiknetzen in der Automo-

bilbranche eingesetzt und untersucht.

Für die pharmazeutische Branche: GS1 in Großbritannien hat im Rahmen eines Pi-

lotprojekts unter dem Forschungsverbund „BRIDGE“ [BRI-09] RFID und 2D-

Barcodes für die Verfolgung von Medikamenten, die von internationalen Herstellern

zu einem Londoner-Krankenhaus transportiert werden, verwendet [RFI-09]. EPCIS

wurde für den Datenaustausch eingesetzt und die Projektergebnisse haben gezeigt,

dass EPCIS die Rückverfolgbarkeit in der pharmazeutischen Supply-Chain verbes-

sern kann und hilft parallel dabei, gefälschte Produkte zu erkennen. In 2011 wurde

ein großes Pilotprojekt, das „2015 Readiness Pilots“, unter GS1 in den USA gestar-

tet [GS1-12a]. Das Projekt hat zum Ziel, die pharmazeutischen Unternehmen auf die

„2015 state drug pedigree requirements“ vorzubereiten, die die eindeutige Identifika-

tion von Medikamenten und Visibilität in der pharmazeutischen Kette in den USA

fordern. EPCIS hat eine zentrale Rolle im gesamten Informationssystem. Simulati-

onsverfahren werden verwendet, um das System zu testen und zu evaluieren.

Für die TextilBranche: Im Rahmen des Arbeitspakets 7 unter dem Forschungsver-

bund „BRIDGE“ wurden die technischen Anforderungen für den Einsatz von RFID


42

und EPCIS in der Textilbranche analysiert [BRI-07a]. Dabei wurden Handlungsemp-

fehlungen für die Implementierung des EPCIS entlang der gesamten Lieferkette,

vom Hersteller bis zur Verkaufsfläche, erarbeitet. Die dadurch gewonnenen Kenn-

tnisse gelten als Know-how für die Anwendung des EPCIS in der Textilindustrie. Im

Jahr 2008 hat das Kindermode-Unternehmen Lemmi Fashion in Zusammenarbeit

mit Karstadt Warenhaus AG ein Pilotprojekt im Rahmen des Forschungsverbunds

„PROZEUS“ durchgeführt [PRO-08]. Das Projekt verfolgte das Ziel, die EPC/RFID-

Technologie in Verbindung mit EPCIS zur Unterstützung der Lagerbewegungen so-

wie der Transparenz im Warenfluss einzuführen.

Weitere Forschungsansätze: Eine Veröffentlichung beschäftigt sich mit der Frage,

wie man die EPCIS-Ereignisse zur Erleichterung des Tracking & Tracing von elektro-

nischen Produkten über ihren gesamten Lebenszyklus verwenden kann [Hri-07]. Ein

weiteres aktuelles Pilotprojekt, das „SmaRTI – smart Reusable Transport Items“, hat

selbststeuernde Prozesse von Ladungsträgern mittels Auto-ID-Technologien wie

RFID, RTLS und Barcodes zum Thema. Dabei wird eine EPCIS-Cloud entwickelt,

welches die Integration der neuen intelligenten Ladungsträger unterstützt [sma-12a],

[Kan-10b].

· Forschungen in der Lebensmittelbranche

Auch in der Lebensmittelbranche wurde das Potenzial von EPCIS zur Steigerung der

Transparenz und Rückverfolgbarkeit der Lieferkette auch erkannt. In den letzten

Jahren haben unterschiedliche Forschungseinrichtungen angefangen, sich mit dem

Einsatz bzw. der Weiterentwicklung von EPCIS in der Lebensmittelindustrie zu be-

schäftigen.

Das Pilotprojekt „eTrace“, gefördert von der SINTEF-Stiftung für Fischerei und

Aquakultur in Norwegen, befasst sich mit dem Einsatz von EPCIS zur Verbesserung

der Rückverfolgbarkeit in der Rotbarsch-Lieferkette. Der Schwerpunkt des Projekts

liegt in der Entwicklung und Evaluation der EPCIS-Infrastruktur für das Tracking &

Tracing entlang der gesamten Fisch-Supply-Chain. Die Machbarkeit des EPCIS-

Einsatzes wird durch das Pilotprojekt getestet, außerdem haben die Projektergeb-

nisse gezeigt, dass die verbesserte Visibilität in der Supply-Chain das Verbraucher-

vertrauen verstärken und somit zu einer Umsatzsteigerung führen kann [Gun-11].

Die Rewe Group in Deutschland beschäftigt sich seit langem mit dem Thema RFID.

Im Rahmen des Forschungsverbunds „PROZEUS“ testet REWE in Zusammenarbeit

mit GS1 das EPCIS-Datenmodell für die Supply-Chain der SB-Fleisch (Selbstbedie-

nungsfleisch) und Wurstwaren [PRO-07].

Stand der Forschung

43

Myhre stellt ein EPCIS-basierendes Rückverfolgungskonzept für die Lebensmittel-

Supply-Chain vor [Myh-09]. In diesem Konzept wird das EPCIS „Transaction-

Event“ verwendet, um das Input und das Output in der Produktion zu verknüpfen,

somit wird die Rückverfolgbarkeit ermöglicht.

Thakur entwickelt eine Methodik zur Modellierung der Rückverfolgbarkeitsinforma-

tionen mit EPCIS und UML-Statecharts [Tha-11]. Dabei werden zwei Szenarien in

der Lebensmittelindustrie, nämlich die Produktionsprozesse der gefrorenen Makre-

len sowie die Nassmahlprozesse von Mais, als Beispiele verwendet, um diese Me-

thodik zu veranschaulichen.

Die oben genannten Vorarbeiten zeigen, dass EPCIS großes Potenzial zur Steige-

rung der Transparenz und Rückverfolgbarkeit in der Lebensmittel-Supply-Chain bie-

tet. Allerdings befassen sich die meisten Arbeiten meist noch auf konzeptionelle

Ebene mit speziellen Insellösungen. Der Aufbau und die Infrastruktur eines EPCIS-

basierenden Datennetzwerkes in der Lebensmittelkette werden dabei noch nicht

genauer untersucht.

3.7.2 Aufbau EPC-basierter kettenübergreifenden Informationssysteme

(Design des Discovery Services)

Da das Tracking & Tracing in der Regel viele Beteiligte in der Supply-Chain betrifft,

ist es wichtig, kettenübergreifende Informationssysteme aufzubauen, um die verteil-

ten EPC-Informationen zu entdecken bzw. zu verketten. Im Rahmen des EPCglobal-

Netzwerkes spielt der Discovery Service, wie bereits im Abschnitt 3.6 erläutert, eine

entscheidende Rolle für diese Aufgabe. In den letzten Jahren wurden Forschungsar-

beiten zum Design des Discovery Service weltweit durchgeführt, die im Folgenden

repräsentativ vorgestellt werden.

Beier von IBM USA et al. haben [Bei-06] den Aufbau und eine erstmalige Implemen-

tierung des Discovery Service präsentiert. Die vorgeschlagene Infrastruktur arbeitet

nach dem „Directory Look-up Approach“ [Lor-11]. Um das Konzept zu veranschau-

lichen, wurde ein Demonstrator für Tracking & Tracing von Avocados implementiert,.

Im Rahmen des Arbeitspakets 2 unter dem Forschungsverbund „BRIDGE“ wurde

die Infrastruktur vom Discovery Service näher untersucht. Im Forschungsbericht

[BRI-07b] haben die Autoren verschiedene Möglichkeiten zum Aufbau des Discovery

Service vorgestellt, verglichen bzw. evaluiert. Als Ergebnis wurden vier Designs,

nämlich das „Directory-of-Resources“ Modell, das „Notification-of-Resources“ Mo-


44

dell, das „Notification-of-Clients” Modell und das „Query Propagation“ Modell als

mögliche Kandidaten zur Umsetzung des Discovery Service ausgewählt. Die Auto-

ren haben die ersten zwei Modelle weiterhin als „Discovery Service Approach“ und

die beiden letzten als „Query Relay Approach“ zusammengefasst.

Kürschner et al. haben das oben genannte „Query Delay Approach“ im Detail vor-

gestellt [Kür-08]. In der Arbeit wird das Modell mit dem „Directory Look-up Design“,

also dem oben ebenfalls als „Discovery Service Approach“ benannten Modell, ver-

glichen. Die Evaluationsergebnisse zeigen, dass das „Query Delay Approach“ den

Unternehmen eine bessere Kontrolle über ihre Daten bietet.

In der Forschungsarbeit von Müller et al. wird ein neues Design von Discovery Servi-

ce, nämlich das „Aggregating Discovery Service“, vorgeschlagen [Mül-10], [Lor-11].

Mit diesem Design werden die Abfrageergebnisse von verschiedenen EPCIS bei

Discovery Service zuerst aggregiert und dann zum Client weitergeleitet. Nach den

Evaluierungsergebnissen verfügt das „Aggregating Discovery Service“ im Vergleich

mit anderen Architekturen über besseres Daten-Ownership, niedrigeren Kontroll-

und Wartungsaufwand sowie minimale Client-Komplexität.

Wie bereits von Lorenz vorgestellt, sollte es in Zukunft keinen einzigen Discovery

Service geben, der allen Branchen zur Verfügung steht [Lor-11]. Der Discovery Ser-

vice muss branchenspezifisch eingesetzt und nach Anwendungsbedarf angepasst

werden. Im aktuellen Projekt „RAN“ (RFID-based Automotive Network) wird ein ket-

tenübergreifendes Informationssystem, der sogenannte „Infobroker“, für das RFID-

basierte Automobilnetzwerk aufgebaut. Die Konzipierung des „Discovery Servi-

ce“ steht genau als zentrale Aufgabe für den Aufbau des „Infobroker“ und ermög-

licht das Auffinden von verteilten EPC-Informationen in der Automobilkette [Pat-10].

Für die Lebensmittelbranche gibt es zurzeit allerdings noch kaum Forschungsarbei-

ten, die ein EPC-basiertes unternehmensübergreifendes Informationsnetzwerk vor

allem im Design des Discovery Service konzipieren und umsetzen.

3.8 Konkretisierung der Forschungsziele

Nach Analyse der existierenden Forschungsarbeiten sowohl im wissenschaftlichen

Bereich als auch im industriellen Umfeld (siehe Kapitel 3.7) wurden die Forschungs-

ziele dieser Arbeit wie folgt festgelegt:

· Der EPCIS-Standard soll für die Lebensmittel-Supply-Chain angepasst und er-

weitert werden. Anhand eines Beispielszenarios wird verdeutlicht, welche EPCIS-

Konkretisierung der Forschungsziele

45

Events in der Logistikkette zu erzeugen sind und welche Erweiterungsmöglich-

keiten bestehen.

· Im Rahmen dieser Arbeit wird ein kettenübergreifendes Datennetzwerk für Tra-

cking & Tracing in der Lebensmittelbranche konzipiert. Dabei wird ein Netzwerk-

dienst aufgebaut, der auf dem Stand der Technik des Discovery Service basiert

und ihn für die Rückverfolgbarkeit in der Lebensmittel-Supply-Chain erweitert.

· Um einen „Proof-of-Concept“ zu erstellen, wird ein Websystem mit den konzi-

pierten Netzwerkkomponenten für Tracking & Tracing in der Lebensmittel-

Supply-Chain implementiert.

· Das Ziel des EPC-basierten Netzwerkes besteht darin, die bestehende IT-

Landschaft in den Unternehmen zu ergänzen statt zu ersetzen, damit der Kos-

tenaufwand gering gehalten wird. Im Rahmen dieser Arbeit ist es noch zu unter-

suchen, wie das EPC-Netzwerk in vorhandene/andere IT-Landschaften integriert

werden kann.


46

Das Konzept der Auto-ID gestützten Identifikation in der Lebensmittel-Supply-Chain

47

4 Konzept eines EPC-basierten Datennetzwerkes in

der Lebensmittel-Supply-Chain

Im Mittelpunkt der Arbeit steht die Konzeption eines EPC-basierten Datennetzwer-

kes für die Lebensmittel-Supply-Chain. Nachdem die genauen Forschungsziele in

Kapitel 3 konkretisiert wurden, folgt in diesem Kapitel das Konzept zur Gestaltung

des Datennetzwerkes. Zu Beginn des Kapitels wird zunächst anhand eines Bei-

spielsszenarios das Konzept der Auto-ID gestützten Identifikation in der Lebensmit-

tel-Supply-Chain vorgestellt. In diesem Szenario wird festgelegt, welche Objekte zu

identifizieren und welche Identifikationspunkte entlang der Lieferkette zu etablieren

sind (Abschnitt 4.2). Darauf basierend wird ein Nummernsystem vorgeschlagen (Ab-

schnitt 4.3). Da EPCIS eine zentrale Rolle zum Aufbau des Datennetzwerkes spielt,

werden anschließend der Einsatz und die Erweiterung des EPCIS für die Lebensmit-

tel-supply-Chain ausführlich beschrieben (Abschnitt 4.4). Um verteilte EPCIS-Daten

zu ermitteln bzw. zu verketten, wird im Rahmen dieser Arbeit ein Rückverfolgungs-

dienst konzipiert, dessen Struktur in Abschnitt 4.5 näher betrachtet wird. Das Kapitel

schließt mit einem Fazit der gewonnenen Kenntnisse.

4.1 Das Konzept der Auto-ID gestützten Identifikation in der Lebensmittel-Supply-Chain

Den Ausgangspunkt eines durchgängigen Datennetzwerkes bildet die echtzeitige

Erfassung von Daten, die mittels geeigneten Identifikationssystemen in der Logistik-

kette erfolgt. Grundlage für den Einsatz von Identifikationssystemen ist jedoch, dass

zum einen die zu identifizierenden Objekte eindeutig identifizierbar sind und zum

anderen Identifikationspunkte an bestimmten Stellen in den Logistikprozessen auf-

gebaut werden, die die Objektinformationen auslesen bzw. weiterleiten.

4.1.1 Betrachtetes Szenario

Im Rahmen dieser Arbeit wird ein konkretes Szenario der Tiefkühlkette als Beispiel

verwendet, um die Konzeption und Umsetzung des EPC-basierten Datennetzwerkes

in der Lebensmittel-Supply-Chain darzustellen. Unter Tiefkühlkette versteht man den

Transportweg von tiefgekühlten Lebensmitteln von der Produktion bis zum Verkauf.

Im Vergleich zu anderen Lebensmitteln stellt die Tiefkühlkost besonders hohe An-

forderungen an die Logistik, da die Kühlung auf dem gesamten Distributionsweg

4 Konzept eines EPC-basierten Datennetzwerkes in der Lebensmittel-Supply-Chain

48

nicht unterbrochen werden darf. Kommt es zu einer Unterbrechung der Kühlkette,

so werden Qualität und Sicherheit der Produkte beeinträchtigt. Das Beispielszenario

der Tiefkühlkette wurde im Rahmen eines Forschungsprojekts am Lehrstuhl fml ent-

wickelt [Wan-11].

Zur Kostenreduktion und damit Effizienzsteigerung werden Kundenaufträge der Tief-

kühlkette häufig in einem Zentrallager kommissioniert. Filialen die sich in der Nähe

des Zentrallagers befinden, werden von dort aus direkt beliefert. Filialen die zum

Einzugsbereich anderer Regionallager gehören, erhalten ihre Waren oft via Cross-

Docking. Unter Cross-Docking versteht man „einen Prozess innerhalb der logisti-

schen Kette, bei dem die Anlieferung der Waren an den Cross-Docking-Punkt und

die Auslieferung an die Empfänger zeitlich oder mengenmäßig so koordiniert wer-

den, dass Einlagerungsprozesse und die zugehörigen Aktivitäten eines typischen

Bestandslagers entfallen“. Ziel des Cross-Dockings ist es, „Bestände zu reduzieren,

Belieferungszeiten zu verkürzen und Transporte zu bündeln, um somit die Kosten zu

senken“ [Hom-07]. Der Distributionsweg einer bestimmten Packung von Tiefkühl-

waren besteht normalerweise aus drei bis vier Stufen. Dazu gehören: ein Hersteller

der Waren, ein Zentrallager, in dem die Waren kommissioniert werden, ein Regional-

lager als Ort des Cross-Docking und eine Filiale, in der die Waren verkauft werden

(siehe Abbildung 4-1). Während der Tiefkühlwarentransport vom Hersteller zum Dist-

ributionslager in der Regel im tiefgekühlten LKW-Laderaum stattfindet, werden die

Tiefkühlwaren bei der Belieferung der Filialen oft in ungekühlten LKW-Laderäumen

mit Trockensortimenten gemeinsam transportiert. In diesem Fall können keine nor-

malen Transporthilfsmittel (THM) wie Palette oder Rollbehälter verwendet. Stattdes-

sen sind isolierte THM wie zum Beispiel Tiefkühlbehälter notwendig.

Hersteller Zentrallager Regionallager(Cross-Docking)

Filiale

Filiale

Vollgut: Leergut:

Abbildung 4-1: Beispielszenario der Tiefkühlkette


49

Folgende Schwachstellen der herkömmlichen Tiefkühlkettelogistik lassen sich iden-

tizieren [FOR-11], [Win-11]:

1. Mangelnde Transparenz der Materialflüsse

THM in der herkömmlichen Logistikkette werden nicht eindeutig identifiziert.

Werden sie zu einer falschen Ort gebracht, kann es lange dauern, verschwunde-

ne THM wieder zu finden. Außerdem besteht Unklarheit über die jeweiligen THM-

Bestände an verschiedenen Lagerstandorten. Dadurch ist es nicht möglich, einen

optimierten Bestand zu halten und einen effizienten Austausch der THM zwi-

schen verschiedenen Lagerorten zu ermöglichen. Die mangelnde Transparenz

der Materialflüsse führt letztlich zu höherem Bestandskosten, unnötigen Trans-

portkosten, höherem Manuellaufwand, sowie dabei entstehenden Fehlerfolge-

kosten.

2. Ineffiziente und teilweise lückenhafte Kühlkettenführung

Die lückenlose Einhaltung der Kühlung und deren Überwachung sind entschei-

dende Voraussetzungen zur Sicherung der Lebensmittelqualität. Die Lebensmit-

telhändler haben sich bemüht, die gesetzlichen Anforderungen zu erfüllen, was

mit Mehraufwand wie z.B. manueller Temperaturkontrolle und Protokollen in Pa-

pierform und damit Personalkosten verursacht. Weiterhin weist die Tiefkühlkette

Sicherheitslücken auf. So wird z.B. die Temperatur innerhalb der Tiefkühlbehälter

während des Transports nicht kontrolliert. Zudem wird die Temperaturkontrolle

bei Warenannahme meist nur stichprobenartig durchgeführt, was die Gefahr mit

sich bringt, dass verdorbene Waren verkauft werden.

3. Ungleichheit von Material- und Informationsflüssen

Eine weitere Schwachstelle der Prozesse besteht darin, dass die Informations-

flüsse zeitlich nicht mit den verbundenen Materialflüssen synchronisiert sind.

Obwohl THM in der Regel bei jeder Lieferung jeweils mit einer Versandetikette

versehen ist, werden die Informationen darauf oft zeitlich verzögert oder gar nicht

erfasst. Auf diese Weise weiß man nicht, ob eine Liefertour zu vorgegebenen Zeit

gestartet wird und wann die Waren am Zielort angekommen sind. Die Ungleich-

heit von Material- und Informationsflüssen führt direkt zu Fehler und Ineffizienz

der Prozesse.

4. Hoher Anteil manueller Arbeitsgänge

Ein großer Anteil der logistischen Prozesse wird immer noch manuell vorgenom-

men. Dazu gehören vor allem die Identifikations- und Kontrollvorgänge. So wird

beispielsweise die Vollständigkeit der Waren einer Lieferung von Mitarbeitern


50

manuell geprüft. Weiterhin werden erhobene Informationen papiergebunden pro-

tokolliert und erst später durch manuelle Eingabe in einem IT-System wie z.B.

SAP digitalisiert. Manuelle Arbeitsvorgänge sind nicht nur zeitaufwändiger son-

dern auch fehleranfälliger, woraus höhere Kosten resultieren.

5. Ineffiziente Rückverfolgbarkeitssysteme

Gemäß der EU-Verordnung (EG) Nr. 178/2002 sind alle Lebensmittelunterneh-

men verpflichtet, nachweisen zu können, von wem sie welche Waren erhalten

und an wen sie welche Waren versendet haben. Obwohl die Unternehmen schon

Systeme und Verfahren eingerichtet haben, um diese Anforderung zu erfüllen, ist

der Rückruf von Waren zeit- und kostenintensiv, da die Dokumentation der War-

enein- und -ausgänge eines Unternehmens meistens in Papierform oder mit

internen Informationssystemen erfolgt und die Verkettung von Informationen ent-

lang der gesamten Lieferkette lange Zeit dauern kann. Außerdem kann der Um-

fang einer Rückrufaktion wegen der fehlenden Identifikation von THM bzw. von

Verpackungskartons nur bedingt eingeschränkt werden. Falls Waren einer be-

stimmten Charge während einer bestimmten Lieferung verseucht werden, sind

oft Waren mit der gleichen Chargennummer bei allen Märkten zu kontrollieren

und zu prüfen, was zu einem enormen Zeit- und Kostenmehraufwand führt.

Um die oben genannten Schwachstellen zu beheben, wird im Rahmen dieser Ar-

beit ein Konzept der Auto-ID-gestützten Identifikation in der Lebensmittel-

Supply-Chain vorgeschlagen. Dazu werden zunächst die zu identifizierenden Ob-

jekte ermittelt. Darauf basierend wird festgelegt, welche Identifikationspunkte in

der Lebensmittelkette aufzubauen sind.

4.1.2 Ermittlung der zu identifizierenden Objekte

Die zu identifizierenden Objekte in der Logistik lassen sich grundsätzlich in drei Ebe-

nen unterteilen: die Produkt- (Item-), die Umverpackungs- (Case-) und die THM-

(Pallet-) Ebene [Man-06]. Die Genauigkeit der Rückverfolgbarkeit hängt von der

Identifikationsebene ab. Je höher die Auflösung der Identifikation ist, desto genauer

können die Waren rückverfolgt werden, aber zugleich steigen die Kosten des Identi-

fikationssystems. Um eine vollständige Transparenz und eine komplette Rückver-

folgbarkeit zu erzielen, ist die Identifikation auf Produktebene zu realisieren, das

heißt, jedes Produkt ist durch eine eindeutige Identifikationsnummer zu kennzeich-

nen. Da die bisherige Kennzeichnung aller Produkte in der Lebensmittelbranche

durch EAN-Artikelnummer und Chargennummer erfolgt, wird der Wechsel auf eine


51

Produktebene-Identifikation zu erheblichen Kosten wegen Informationsverwaltung

und Systemersatz führen [Kel-07].

In dieser Forschungsarbeit wird die Identifikation der Objekte in der Lebensmittello-

gistik auf THM-Ebene und Umverpackungsebene vorgeschlagen. Abbildung 4-2

zeigt die in der Lebensmittellogistik häufig verwendeten THM. Der Einsatz von RFID

auf THM-Ebene ist heute technisch und wirtschaftlich gut machbar. In der Konsum-

güterindustrie ist die Einführung von RFID-Systemen in die THM-bezogene Prozesse

schon weit gediehen. So wurden beispielsweise bei den Metro Cash & Carry -

Märken in Deutschland bereits bis 2009 durchschnittlich 40 % der gesamten Waren

auf Paletten angeliefert, die mit RFID ausgestattet sind [Met-08], [Met-09]. Gerade

für die Lebensmittelindustrie ist die Kombination von RFID mit Sensoren sehr inter-

essant, da hierdurch nicht nur die eindeutige Kennzeichnung eines Objekts, sondern

auch die Aufzeichnung seiner Zustands- und Umgebungsinformationen ermöglicht

werden können. RFID-Transponder mit integrierten Temperatursensoren, die bereits

in Abschnitt 2.4.5 vorgestellt wurden, können an THM angebracht und zur lückenlo-

sen Überwachung der Umgebungstemperaturen entlang der logistischen Kette ein-

gesetzt werden.

Tiefkühlbehälter Rollbehälter Palette

Abbildung 4-2: Häufig verwendete THM in der Lebensmittellogistik

Die Identifikation auf Umverpackungsebene kann vor allem Kommissionierfehler bei

logistischen Prozessen vermeiden und dadurch entfällt der Kontrollaufwand bei

Warenein- und Ausgängen [Kut-08]. Wieweit der Einsatz von RFID auf Umverpa-

ckungsebene gelingt, ist noch offen. Die METRO Group testet seit Jahren die Ver-

wendung von RFID auf Kartonebene [Met-08]. Ein aktuelles Forschungsprojekt

„smart NRW“ an der RWTH Aachen erforscht seit August 2011 die Nutzung von

RFID auf Umverpackungsebene in der Konsumgüterindustrie, die sich dadurch mehr

Potenzial als das Palettenebene-Tagging in der Optimierung der Logistik und der


52

überbetrieblichen Koordination erhofft [Sma-12b]. Allerdings stehen beim Karton-

ebene-Tagging je nach Anwendung noch eine Reihe von Detailproblemen wie zum

Beispiel die unzureichende Leserate, der noch relativ hohe Transponderpreis bzw.

die Anfälligkeit gegen Störeinflüsse wie Metall und Flüssigkeiten, die für die alltägli-

che Anwendung zu beheben sind [Bun-05]. Als Alternative können Verpackungskar-

tons durch 2D-Barcode identifiziert werden, in dem neben der Seriennummer noch

weitere Informationen wie zum Beispiel die Chargennummer verschlüsselt werden

können. Diese Lösungsmöglichkeit wurde im bereits erwähnten Projekt BRIDGE für

die pharmazeutische Supply-Chain eingesetzt [BRI-08]. Im Vergleich zu RFID ist die

Identifikation auf Umverpackungsebene durch Barcode heute kostengünstiger und

technisch einfacher.

4.1.3 Festlegung der Identifikationspunkte

„Um Prozesse und deren Objekte zu identifizieren, müssen Objektinformationen an

bestimmten Punkten im Arbeitsablauf ausgelesen werden. Diese bestimmten Punkte

in den Prozessen nennen sich Identifikationspunkte“ [Kru-10]. Wichtig für den Auf-

bau der Auto-ID-gestützten Supply-Chain ist die Festlegung der Identifikationspunk-

te zur Datenerfassung entlang der Lieferkette. Ein RFID-basierte Identifikationspunkt

besteht aus einem Auslesegerät und einer oder mehreren Antennen [Gün-11a]. Sie

kann, wie bereits in Abschnitt 2.4.3.1 vorgestellt, entweder durch stationäres SLG

wie RFID-Gate oder durch mobiles SLG wie RFID-fähigen Handheld realisiert wer-

den.

In Abbildung 4-3 wird ein Identifikationskonzept für die Lebensmittel-Supply-Chain

am Beispiel einer Tiefkühlkette, die in Abschnitt 4.2.1 beschrieben wurde, dargestellt.

In dem Konzept werden die Kartons, die die kleinste Packstückeinheit darstellen und

stets chargenrein sind, durch 2D-Barcode identifiziert. Um die Rückverfolgung der

Produkte zu ermöglichen, werden die EAN-Nummer, die Chargennummer sowie das

Ablaufdatum der eingepackten Produkte ebenfalls im Barcode verschlüsselt. Die

THM werden hingegen mittels RFID gekennzeichnet, wobei die RFID-

Temperaturlogger für die Tiefkühlbehälter eingesetzt werden, um Temperaturwerte

während des Transports mit aufzeichnen zu können. Die Identifikationspunkte wer-

den durch RFID-Gate und Auto-ID Handheld umgesetzt. Während RFID-Gates für

automatische Warenannahme- und Versandt bei Wareneingangs- und Ausgangszo-

nen eingesetzt werden, werden Auto-ID Handhelds im Konzept hauptsächlich ver-

wendet, um die Beziehungen zwischen den logistischen Objekten zu kennzeichnen.

Die heutigen Auto-Handhelds auf dem Markt sind in der Lage, unterschiedliche Da-


53

ten zu erfassen: von 1D, 2D-Barcodes und Bildern bis zu RFID-Etiketten [Mot-12].

Beispielsweise kann ein Aggregationsleseereignis durch das Scannen des Barcodes

auf den Kartons und die Erfassung der RFID-Transponder auf der zu beladenen Pa-

lette generiert werden.

Die Identifikationspunkte, die in der Abbildung dargestellt sind, sind die wichtigsten

Stellen in der Lieferkette, die ein effizientes und präzises Tracking & Tracing ermög-

lichen. In einer realen Umsetzung können die Identifikationspunkte auch durch an-

dere als die hier im Konzept vorgeschlagenen Auto-ID Lösungen implementiert wer-

den. Beispielsweise können Kartons auch mit RFID gekennzeichnet werden und der

Lesevorgang kann somit durch stationäre RFID-Reader statt Handhelds automati-

siert werden. Trotz der Implementierungsunterschiede bleiben die zu erfassenden

Daten jedoch unverändert, was in den folgenden Abschnitten noch weiter diskutiert

wird.


54

Abbildung 4-3: Wichtige Identifikationspunkte in der Lebensmittel-Supply-Chain am Beispiel einer

Tiefkühlkette

Nummernsystem

55

4.2 Nummernsystem

Der Aufbau eines unternehmensübergreifenden Datennetzwerks setzt voraus, dass

ein standardisiertes Nummernsystem für den Informationsaustausch etabliert und

eingesetzt wird. Der Elektronische Produktcode (EPC) ermöglicht eine eindeutige

Identifikation von mit Auto-ID gekennzeichneten Objekten und bildet die Basis eines

EPC-basierten Datennetzwerks. In diesem Abschnitt werden zuerst die Datenforma-

te des EPC-Nummernsystems vorgestellt. Darauf basierend werden die zu verwen-

denden Datentypen zur Kennzeichnung von logistischen Objekten und physischen

Lokationen in dieser Arbeit festgelegt.

4.2.1 Datenformat

Je nach Anwendungszweck kann der EPC in verschiedenen Formaten erscheinen.

Die drei Hauptformate sind: Binärcode, Transpondercodierungs-URI (Tag-Encoding

URI) und Nur-Identitäts-URI (pure-identity URI). In Abbildung 4-4 werden sie jeweils

mit einem Beispiel dargestellt.

RFID-TransponderHexadezimalwert

3014F4240400004000003039

RFID-ReaderHexadezimalwert

3014F4240400004000003039

Middleware-SystemTranspondercodierungs-URI

urn:epc:tag:sgtin-96:0.4000001.000001.12345

InformationssystemNur-Identitäts-URI

urn:epc:id:sgtin:4000001.000001.12345

Abbildung 4-4: Verschiedene EPC-Darstellungsformate (In Anlehnung an [GS1-12b])

Der Binärcode wird auf Hardware-Ebene verwendet. Der EPC auf dem Transponder

wird binär abgespeichert und von RFID-Reader ebenfalls in dieser Form gelesen und

weiterverarbeitet. Neben der Identifikationsnummer sind noch weitere Informationen

wie der Datenkopf und der Filter im binären EPC enthalten. Zur übersichtlicheren


56

Darstellung wird der EPC in der Abbildung in Form von Hexadezimalwert statt Bi-

närwert angezeigt.

Der Transpondercodierungs-URI ist für Low-Level-Anwendungen wie z.B. die RFID-

Middleware-Systeme vorgesehen und wird verwendet, um EPC-Nummern auf

Transponder zu schreiben oder Objekte nach Verpackungsebene zu sortieren. Der

Transpondercodierungs-URI wird vom Binärcode eins zu eins umgewandelt, wobei

alle transponderspezifischen Daten, zum Beispiel der Datenkopf und der Filter, er-

halten bleiben.

Im Vergleich zu Transpondercodierungs-URI enthält der Nur-Identitäts-URI keine

datenträgerspezifischen Informationen mehr. Wenn beispielsweise ein Hersteller von

64-Bit-Transponder auf 96-Bit-Transponder für die Identifikation eines bestimmten

Produkts wechselt, bleibt der Nur-Identitäts-URI unverändert. Dieses Darstellungs-

format stellt nur die reinen Identifikationsinformationen zur Verfügung und wird in

Informationssystemen benutzt.

Da diese Arbeit sich mit dem Aufbau eines High-Level-Informationssystems be-

schäftigt, wird der Nur-Identitäts-URI im Rahmen dieser Arbeit als Datenformat ver-

wendet, um EPCs darzustellen.

4.2.2 Kennzeichnung von logistischen Objekten

In diesem Abschnitt wird erläutert, mit welchen Nummern die zu identifizierenden

logistischen Objekte im Rahmen des Konzepts gekennzeichnet werden.

Abbildung 4-5 gibt einen Überblick über die verwendeten Identifikationsnummern

auf verschiedenen Objektebenen.

In dieser Forschungsarbeit wird die eindeutige Identifikation, wie bereits in Abschnitt

4.2.2 erklärt, auf Umverpackungsebene und auf THM-Ebene vorgeschlagen. Die

Produkte werden hier weiterhin mit der EAN-13, der Chargennummer und dem Ab-

laufdatum identifiziert, was in der heutigen Lebensmittelindustrie zur Kennzeichnung

von Produkten weit verbreitet ist.

Nummernsystem

57

Abbildung 4-5: Die verwendeten Identifikationsnummern auf verschiedenen Objektebenen

Die Umverpackungen wie Umkartons werden eindeutig mit SGTIN gekennzeichnet.

SGTIN steht für „Serialized Global Trade Item Number“ und wird für die eindeutige

Kennzeichnung von einzelnen Produkten oder Verpackungseinheiten verwendet. Der

Nur-Identitäts-URI für SGTIN folgt dem Schema:

urn:epc:id:sgtin:CompanyPrefix.ItemReference.SerialNumber.

Das Feld CompanyPrefix gibt die Identifikationsnummer des Unternehmens an, das

den EPC vergeben hat. Das Feld ItemReference bezeichnet eine bestimmte Objekt-

klasse des Unternehmens und das Feld „SerialNumber“ wird für die Kennzeichnung

eines konkreten Objekts verwendet. Die Gesamtlänge aus CompanyPrefix und

ItemReference hat immer 13 Stellen.

Für die Kennzeichnung von THM werden zwei EPC-Typen eingesetzt: der SSCC und

der GRAI. Die Abkürzung SSCC steht für „Serial Shipping Container Code“ und wird

auf Deutsch auch als NVE (Nummer der Versandeinheit) bezeichnet. SSCC wird für

die Kennzeichnung einer Transporteinheit einer bestimmten Lieferung verwendet

und diese Nummer, wie bereits in Abschnitt 2.4.2 vorgestellt, wird normalerweise in

einem Strichcode verschlüsselt und auf ein Transportetikett gedruckt, das auf einem

beladenen THM angebracht ist. Auf einem gleichen THM ist die SSCC bei jeder Lie-

ferung aber unterschiedlich. Das Codierungsschema von SSCC lautet:

urn:epc:id:sscc:CompanyPrefix.SerialReference,

wobei das SerialReference vom EPC-Manager zur eindeutigen Kennzeichnung einer

Versandeinheit vergeben wird. Die Gesamtlänge aus CompanyPrefix und SerialRefe-

rence hat immer 17 Stellen.


58

Der EPC-Typ GRAI steht für „Global Returnable Asset Identifier“ und wird benutzt,

um beispielsweise wieder verwendbare THM zu identifizieren. Im Vergleich zu SSCC

bleibt GRAI für ein bestimmtes THM während seines gesamten Lebenszyklus unve-

rändert. Aus diesem Grund ist es vorteilhaft, THM auch mit einem RFID-Transponder

zu versehen, auf dem der GRAI verschlüsselt ist. Diese Nummer ermöglicht unter

anderem das Tracking & Tracing und dadurch eine effiziente Verwaltung von THM.

Für GRAI folgt der Nur-Identitäts-URI dem folgenden Schema:

urn:epc:id:grai:CompanyPrefix.AssetType.SerialNumber.

Das AssetType wird vom EPC-Manager vergeben, um die Klasse des zu identifizie-

renden Assets anzugeben. Die Gesamtlänge aus CompanyPrefix und AssetType hat

immer zwölf Stellen.

Es ist in der Praxis sinnvoll, den SSCC mit dem GRAI für ein bestimmtes THM im

Informationssystem zu verlinken, damit das Tracking & Tracing von Produkten auch

durch das Tracking & Tracing von THM ermöglicht werden kann.

4.2.3 Kennzeichnung von Lokationen

Der EPC-Typ SGLN wird verwendet, um physische Lokationen entlang der Logistik-

kette überschneidungsfrei zu kennzeichnen. Die physische Lokation kann ein Unter-

nehmensstandort oder eine bestimmte Stelle innerhalb des Unternehmens wie zum

Beispiel eine Wareneingangszone oder sogar ein Lagerplatz sein.

SGLN steht für „Global Location Number with or without Extension“ und hat das

folgende Codierungsschema:

urn:epc:id:sgln:CompanyPrefix.LocationReference.Extension.

Das Feld LocationReference wird vom EPC-Manager vergeben, um eine physische

Lokation eindeutig zu identifizieren. In der Abkürzung steht der Buchstabe „S“ für

„with or without Extension“ statt „Serialized“ und durch das Feld Extension können

Unternehmen ihre internen Lokationen noch feiner identifizieren. Die Gesamtlänge

aus CompanyPrefix und LocationReference hat immer zwölf Stellen.

Einsatz und Erweiterung des EPCIS-Standards für die Lebensmittelkette

59

4.3 Einsatz und Erweiterung des EPCIS-Standards für die Le-bensmittelkette

Zum Aufbau eines EPC-basierten Datennetzwerkes spielt der Einsatz von EPCIS

eine zentrale Rolle. EPCIS hat die Aufgabe, erfasste Auto-ID-Daten mit Prozesskon-

text zu verknüpfen, in standardisierter Form zu speichern und zu High-Level-

Anwendungen zur Verfügung zu stellen. Somit kann einerseits der Auto-ID-basierte

Datenaustausch zwischen Geschäftspartnern ermöglicht sowie erleichtert und ande-

rerseits die Transpanrenz in der gesamten Lieferkette gesteigert werden.

Der EPCIS-Standard ist aber, wie bereits in Kapitel 3 diskutiert, je nach Branche und

Anwendungsgebiet anzupassen und gegebenenfalls zu erweitern. Dazu werden in

diesem Abschnitt die einzusetzenden EPCIS-Ereignistypen, EPCIS-Attributen und

EPCIS-Vokabelelemente sowie ihre Erweiterungsmöglichkeiten jeweils näher be-

trachtet. Darauffolgend wird das Mapping zwischen Identifikationspunkten und den

zu erfassenden EPCIS-Ereignissen anhand unseres Beispielszenarios dargestellt.

4.3.1 EPCIS-Ereignistypen

Die EPCIS-Spezifikation hat, wie bereits in Abschnitt 3.4 vorgestellt, insgesamt vier

Standard-Ereignistypen definiert: das Objektereignis, das Aggregationsereignis, das

Quantitätsereignis und das Transaktionsereignis. Das UML-Diagramm für die EP-

CIS-Ereignistypen ist in Abbildung 4-6 angezeigt. Im Folgenden werden sie je nach

Anwendungsfall kurz vorgestellt.

1. Objektereignis (ObjectEvent):

Ein Objektereignis wird verwendet, wenn eine oder mehrere Objekte an einem

Identifikationspunkt beobachtet werden. Beispielweise wird ein Objektereignis

generiert, wenn mehrere leere Paletten bei der Durchfahrt durch ein RFID-Tor er-

fasst werden.

2. Aggregationsereignis (AggregationEvent):

Ein Aggregationsereignis beschreibt die Aggregation bzw. die Trennung von Pa-

rent-IDs und Child-EPCs beim Lesevorgang. Ein Beispiel hier ist die Identifikation

einer beladenen Palette (Parent-ID) mit mehreren Kartons (Child-EPCs), die alle

gekennzeichnet sind.


60

3. Quantitätsereignis (QuantityEvent):

Dieses Ereignis findet statt, um die Menge von einer bestimmten Objektklasse zu

registrieren. Es wird zum Beispiel verwendet, um die Lagerbestände eines be-

stimmten Produkts zu erfassen.

4. Transaktionsereignis (TransactionEvent):

Ein Transaktionsereignis wird verwendet, um die Verknüpfung bzw. die Trennung

von physikalischen Objekten zu Businesstransaktionen dazustellen. Beispiels-

weise könnten einige Versandeinheiten, die jeweils durch einen EPC gekenn-

zeichnet sind, mit einer Lieferung verknüpft werden.

Abbildung 4-6: UML-Diagramm für EPCIS-Ereignistypen [EPC-07b]


61

Neben den oben genannten vier Ereignistypen bietet der Standard noch die Mög-

lichkeit, neue Ereignistypen nach Bedarf zu entwickeln. In der Automobilindustrie

wird beispielsweise ein neues Ereignis, nämlich das „AssemblyEvent“, vorgeschla-

gen [Sau-08], [VDI-4472]. Dieser Ereignistyp wird für den Montageprozess in der

Fertigung eingeführt, da der standardisierte Ereignistyp „AggregationEvent“ den

Montageprozess nicht richtig darstellen kann. Das AggregationEvent beschreibt die

Aggregation von Objekten in einem begrenzten Zeitraum, die später wieder aufge-

hoben werden kann. Ein typisches Beispiel ist das Beladen und Entladen der Palet-

ten mit Kartons. Im Gegensatz dazu wird das „AssemblyEvent“ verwendet, um das

Zusammenbauen von Objekten zu beschreiben, die nach dem Einbaun nicht mehr

getrennt werden. Beispielsweise wird ein Motor nach dem Einbau in ein Auto nicht

mehr als ein eigenständiges Objekt betrachtet.

In der Lebensmittelindustrie kann ein ähnlicher Ereignistyp eingeführt werden, der

„ProductionEvent“ genannt werden soll. Dieser wird verwendet, um den Fertigungs-

prozess von Lebensmittelprodukten zu beschreiben. Da verschiedene Zutaten in der

Herstellung häufig gemischt werden und eine Trennung später nicht mehr möglich

ist, kann das „AggregationEvent“ diese Prozessschritte auch nicht richtig darstellen.

Darüber hinaus kann sich die Form der Zutaten während des Herstellungsprozesses

ändern und daher können die Zutaten später nicht mehr als eigenständige Objekte

betrachtet werden. Aus diesem Grund macht es Sinn, den neuen Ereignistyp „Pro-

ductionEvent“ für die Lebensmittelproduktion einzuführen.

Da sich die Forschungsarbeit nicht mit den Produktionsprozessen in der Lebensmit-

telindustrie beschäftigt, wird der vorgeschlagene Ereignistyp „ProductionEvent“ hier

nicht weiter diskutiert. Die im Standard definierten Ereignistypen können sämtliche

Prozesse in der Lebensmittellogistik abdecken. Das Mapping zwischen Identifikati-

onspunkten und EPCIS-Ereignissen wird in Abschnitt 4.4.4 näher betrachtet.

4.3.2 EPCIS-Ereignisattribute

In den EPCIS-Ereignistypen sind jeweils unterschiedliche Attribute enthalten, die die

„Was, Wann, Wo, Warum” Informationen darstellen (siehe Abbildung 4-6). Der EP-

CIS-Standard hat sowohl obligatorische als auch optionale Attribute definiert, die in

Tabelle 4-1 zusammengefasst und beschrieben werden.


62

Tabelle 4-1: Standardisierte EPCIS-Ereignisattribute

In der Lebensmittel-Supply-Chain werden die im Standard definierten Attribute wei-

ter benutzt. Allerdings sind noch neue Attribute einzuführen, um branchenspezifi-

sche Anforderungen zu erfüllen. Im Folgenden werden die in dieser Forschungsar-

beit vorgeschlagenen Attribute je nach Anforderung in der Lebensmittellogistik er-

läutert.

· Produktkennzeichnung

Eine eindeutige Identifikation von Produkten in der Lebensmittel-Supply-Chain,

wie bereits diskutiert, ist wirtschaftlich noch nicht realisierbar. Die Produkte wer-

den im Rahmen dieser Forschungsarbeit weiterhin mit der EAN-Nummer ge-

kennzeichnet, die in der Industrie weit verbreitet ist. Des Weiteren werden noch

Chargennummer bzw. Ablaufdatum verwendet, um die Rückverfolgung von Pro-

dukten zu ermöglichen und gegebenenfalls den Umfang von Rückrufaktionen zu

beschränken. Da die EAN-Nummer (EAN_Number), die Chargennummer (lot-

Number) und das Ablaufdatum (ExpiryDate) nicht durch einen EPC eindeutig

dargestellt werden können, werden sie zum Zweck der Produktkennzeichnung

als neue Attribute eingeführt. Sie haben alle den Typ „String“.

· Temperaturüberwachung


63

Die Temperaturüberwachung spielt eine sehr wichtige Rolle für die Qualitätssi-

cherheit von Lebensmittelprodukten in der Kühlkette. Daher ist es notwendig,

Temperaturbezogene Attribute in ein EPC-basiertes Datennetzwerk einzuführen.

Im Rahmen des Forschungskonzepts sind die THM, die für die Kühlkette einge-

setzt werden wie Tiefkühlbehälter, mit RFID-Temperaturlogger zu versehen.

RFID-Temperaturlogger können in der Regel in zwei unterschiedlichen Modi ar-

beiten: im kontinuierlichen Modus oder im Threshold-Modus. Während die Tem-

peraturwerte im kontinuierlichen Modus in vordefinierten Intervallen ständig ge-

messen und abgespeichert werden, werden sie im Threshold-Modus nur bei

Überschreitung einer vordefinierten Grenze aufgezeichnet. Um die Temperatur-

bezogenen Werte bei beiden Modi zu integrieren, werden die folgenden Attribute

vorgeschlagen:

Temp, TempTime, TempOverThreshold, TempOverthresholdTime,

wobei die ersten beiden Attribute die Temperaturwerte und die Erfassungszeit-

punkte der Temperatur im kontinuierlichen und die beiden Letzteren die im

Threshold-Modus darstellen.

4.3.3 Vokabelelemente

Vokabelelemente werden verwendet, um den Datentyp von EPCIS-Attributen wie

z.B. bizStep zu beschreiben. Jedes Vokabelelement kann verschiedene Werte an-

nehmen, die allerdings vor dem Einsatz mit allen Beteiligten an der Supply-Chain

abgestimmt werden sollen, da nur dadurch ein effizienter Datenaustausch zwischen

verschiedenen Unternehmen und eine unmissverständliche Interpretation von EP-

CIS-Ereignissen ermöglicht werden können.

Der Standard Core Business Vocabulary (CBV), der in 2010 von GS1/EPCglobal

veröffentlicht wurde, bietet einen branchenübergreifenden Katalog für die grundle-

gende Vokabelelemente und ihre möglichen Werte. Zudem gestattet der CBV-

Standard des Weiteren die Definition von neuen branchenspezifischen Vokabelele-

menten und die Einführung von neuen Werten für vorhandene Vorkabelelemente

[EPC-10]. In Tabelle 4-2 sind die in dieser Arbeit verwendeten Vokalbelelemente so-

wie ihre möglichen Werte für die Attribute „bizStep“ und „disposition“ dargestellt

und beschrieben.


64

Tabelle 4-2: Mögliche Werte der Vokalbelelemente für die Attribute „bizStep“ und „disposition“

Neben den in CBV definierten Werten werden einige neue Werte als Erweiterungen

eingeführt. In der Lebensmittelindustrie werden verschiedene THM zum Transport

und zur Lagerung verwendet, die regelmäßig gereinigt und gegebenenfalls repariert

werden sollen. Um ein effizientes THM-Management zu erreichen, spielt die Trans-

parenz nicht nur über die Lagerbestände sondern auch über den aktuellen Zustand

von THM eine wichtige Rolle. Zur echtzeitigen Erfassung des THM-Zustands werden

neue Werte „cleaning“ für bizStep sowie neue Disposition-Werte „under_repair“ und

„under_cleaning“ eingeführt. Weiterhin wird hier der neue Wert „in_storage“ genutzt,

um den Zustand der Objekte zu beschreiben, die sich im Lager befinden.


65

4.3.4 Mapping zwischen Auto-ID-gestützten Logistikprozessen und

EPCIS-Ereignissen

Nachdem in den letzten Abschnitten die Einsatz- und Erweiterungsmöglichkeiten

des EPCIS-Standards in der Lebensmittelkette diskutiert wurden, wird in Tabelle 4-3

das Mapping zwischen Auto-ID gestützten Logistikprozessen und den zu erfassen-

den EPCIS-Ereignissen anhand des Beispielsszenarios, das in Abschnitt 4.2.3 dar-

gestellt ist, illustriert.

Tabelle 4-3: Mapping zwischen Auto-ID gestützten Logistikprozessen und EPCIS-Ereignissen

Die echtzeitige Datenerfassung der Prozesse, die in Tabelle 4-3 angezeigt sind, ist

Voraussetzung für ein effizientes und präzises Tracking & Tracing. Durch die direkte

Verknüpfung zwischen den eingelesenen Daten und den Geschäftsprozessen mittels

EPCIS-Ereignissen erhöht sich die Transparenz in der Supply-Chain. Für die Le-

bensmittelkette spezifischen Prozesse wie die Rückverfolgung der Produkte und die

Temperaturüberwachung wird der EPCIS-Standard, wie bereits in Abschnitt 4.4.2


66

diskutiert, um die entsprechenden „Extensions“ erweitert, die ebenfalls in der Tabel-

le dargestellt sind.

4.4 Konzept eines Rückverfolgungsdiensts für die Lebensmit-tellogistik

4.4.1 Anforderung

Durch den Einsatz von EPCIS werden die erfassten Auto-ID-Daten mit Prozess- und

Geschäftskontexten verknüpft und in einem standardisierten Format zur High-Level-

Anwendungen zur Verfügung gestellt. Jeder Teilnehmer in der Wertschöpfungskette

verfügt über einen (oder) mehrere eigene EPCIS und dieser Dienst wird in der Regel

unternehmensintern oder von einem Dienstleister betrieben.

Das Problem ist aber, dass an unternehmensübergreifenden Anwendungen v.a. am

Tracking & Tracing meist viele Teilnehmer beteiligt sind und die gesamten EPCIS-

Daten dezentral über mehrere Firmen verteilt und nicht gemeinsam in einer zentralen

Datenbank gespeichert werden. Deshalb ist es notwendig, einen Netzwerkdienst

aufzubauen, der die verteilten Informationen entdeckt und aggregiert, um die Rück-

verfolgbarkeit und die Transparenz in der gesamten Lieferkette zu realisieren. Um

diese Anforderung zu erfüllen, wird in diesem Abschnitt der Aufbau eines solchen

Netzwerkdiensts für die Lebensmittel-Supply-Chain ausführlich erläutert.

4.4.2 Vergleich ONS und Discovery Service

Zur Auffindung von verteilten EPC-Daten werden im Rahmen des EPCglobal-

Netzwerks zwei Komponenten vorgeschlagen, der ONS und der Discovery Service.

Die beiden Komponenten können genutzt werden, um das Tracking & Tracing in der

Supply-Chain zu ermöglichen.

Der ONS verweist nur auf die EPCIS-Adresse des EPC-Managers wie zum Beispiel

des Herstellers. Um weitere verteilte EPC-Daten aufzufinden, sind weiterführende

Links in jedem EPCIS, die auf die benachbarten EPCIS-Adressen verweisen, zur

Verfügung zu stellen. Durch die weiterführenden Links können die EPC-Daten stu-

fenweise aufgerufen werden, damit das Tracking & Tracing ermöglicht wird.

Konzept eines Rückverfolgungsdiensts für die Lebensmittellogistik

67

Im Vergleich zu ONS verweist der Discovery Service nicht nur auf die EPCIS-

Adresse des EPC-Managers, sondern auf alle EPCIS mit Informationen zum angef-

ragten EPC.

Der Unterschied zwischen den beiden Methoden ist in Abbildung 4-7 illustriert. Dar-

aus ist zu ersehen, dass das Tracking & Tracing mittels ONS leicht unterbrochen

werden kann. Falls ein EPCIS in der Kette außer Betrieb ist, geht der Verweis auf

darauffolgende EPCIS ebenfalls verloren. Dadurch kann der Rückverfolgungspro-

zess nicht weiter fortgesetzt werden. Im Gegensatz dazu beeinflusst ein solches

Problem das Tracking & Tracing mittels Discovery Service weniger stark. Ist ein EP-

CIS ausgefallen, kann der Discovery Service doch noch die anderen EPCIS auffin-

den und erreichen [BRI-07b].

Im Rahmen dieser Forschungsarbeit wird daher ein Rückverfolgungsdienst aufge-

baut, der auf dem Stand der Technik des Discovery Service basiert und ihn für die

Rückverfolgbarkeit in der Lebensmittel-Supply-Chain adaptiert.

Abbildung 4-7: Vergleich ONS und Discovery Service für Tracking & Tracing


68

4.4.3 Vergleich verschiedener Discovery Service Strukturen

Wie bereits in Abschnitt 4.7.2 vorgestellt, wird der Aufbau von Discovery Service seit

Jahren in der Wissenschaft kontrovers diskutiert. Die von verschiedenen For-

schungseinrichtungen vorgeschlagen Discovery Service Strukturen lassen sich

grundsätzlich in die folgenden drei Design-Varianten einordnen.

1) Das „Directory Look-Up“ Design

Das „Directory Look-Up“ Design wurde ursprünglich in der Arbeit von Beier et al.

vorgeschlagen [Bei-06]. Mit diesem Design arbeitet der Discovery Service in den

folgenden Schritten, die in Abbildung 4-7 illustriert sind.

1. Ein Client sendet eine Abfrage mit einem bestimmten EPC an den Discovery

Service.

2. Der Discovery Service findet die entsprechenden EPCIS-Adressen mit Hilfe

seiner Look-Up-Tabelle und sendet diese an den Client zurück.

3. Mit den zurückgesendeten Adressen sendet der Client selbst Abfragen an die

jeweiligen EPCIS-Server, um detailierte Informationen für den EPC zu be-

kommen.

4. Die EPCIS-Server überprüfen jeweils das Zugangsrecht des Clients. Soweit

zulässig, werden detailierte EPCIS-Ereignisinformationen je nach Abfrage an

den Client zurückgeschickt.

Abbildung 4-8: Directory Look-Up Design


69

2) Das „Query Relay” Design

In der Arbeit von Kürschner et al. [Kür-08] wurden die Nachteile des „Directory

Look-Up“ Designs analysiert und eine neue Discovery Service Struktur vorge-

schlagen, das „Query Relay“ Design. Die Arbeitsschritte dieses Designs sind in

Abbildung 4-8 dargestellt.


Service.

2. Der Discovery Service findet die entsprechenden EPCIS-Adressen und leitet

die Abfrage an die EPCIS-Server weiter.


zulässig, werden gefragte Informationen an den Client zurückgeschickt.

Abbildung 4-9: Query Relay Design

3) Das „Aggregating Discovery Service” Design

Müller et al. haben ein neues Discovery Service Konzept, das „Aggregating Dis-

covery Service“ Design, vorgestellt [Mül-10]. Bei diesem Ansatz werden die ge-

fragten Informationen nicht von EPCIS-Server direkt an Client geschickt. Statt-

dessen werden sie zuerst im Discovery Service zusammengeführt, anschließend

werden die aggregierten Informationen werden gemeinsam an den Client zu-

rückgesendet. Abbildung 4-8 zeigt die detaillierten Arbeitsschritte des „Aggrega-

ting Discovery Service“.


Service.

2. Der Discovery Service findet die entsprechenden EPCIS-Adressen und leitet

die Abfrage an die EPCIS-Server weiter.


70


zulässig, werden gefragte Informationen an den Discovery Service zurückge-

schickt.

4. Der Discovery Service aggregiert alle Antworte der jeweiligen EPCIS-Server

und schickt sie gemeinsam an den Client zurück.

Abbildung 4-10: Aggregating Discovery Service Design

Um verschiedene Design-Varianten zu vergleichen, werden bei Kürschner die fol-

genden entscheidenden Anforderungskriterien an den Discovery Service definiert

[Kür-08]:

· Vollständige Kontrolle über eigene Daten

Jeder Teilnehmer an der Supply-Chain sollte vollständige Kontrolle über die Da-

ten seiner eigenen EPCIS-Server besitzen. Dazu gehören EPCIS-Adresse, EP-

CIS-Ereignisinformationen, Stammdaten sowie Zugangsrechte zu Clients.

· Möglichkeit zur Nachverfolgung der Verwendung von Daten

Jedes Unternehmen sollte in der Lage sein, die Verwendung ihrer Daten mittels

Discovery Service nachverfolgen zu können.

· Vertraulichkeit der EPCIS-Daten

EPCIS-Daten der einzelnen Unternehmen sollten nicht an unberechtigte Benutzer

weiter gegeben werden.


71

· Vertraulichkeit der Clientabfragen

Die Abfragedetails der Benutzer sollten nicht an unbeteiligte Dritte weiter gege-

ben werden.

· Verfügbarkeit und Zuverlässigkeit

Der Discovery Service sollte immer bereit sein, Clientabfragen zu beantworten

(Verfügbarkeit). Weiterhin sollte er den Service über einen langen Zeitraum konti-

nuierlich anbieten (Zuverlässigkeit).

· Unabhängigkeit von Geschäftsbeziehungen

Der Discovery Service sollte unabhängig von Geschäftsbeziehungen zwischen

den Unternehmen sein. Sollten Geschäftsbeziehungen geändert werden, werden

Zugangsrechte bei einzelnen EPCIS-Servern lokal neue reguliert. Der Discovery

Service sollte dadurch nicht beeinflusst werden.

· Ermutigung zur Teilnahme

Je mehr Unternehmen am Netzwerk teilnehmen, desto größer wird der Nutzen

des Netzwerkes für alle Teilnehmer. Dafür sollte einerseits die Schwelle für den

Beitritt ins Netzwerk wie z.B. die Kosten und der administrative Aufwand niedrig

gehalten werden, damit mehr Unternehmen ermutigt werden, sich am Netzwerk

zu beteiligen.

· Niedrige Client-Komplexität

Der Implementierungsaufwand für Clientanwendung sollte gering gehalten wer-

den, damit mehr Unternehmen den Discovery Service benutzen können.

· Skalierbarkeit

Unter Skalierbarkeit versteht man die Fähigkeit vom Discovery Service, Abfragen

und Daten in großen Mengen zu handhaben.

· Servicequalität

Der Discovery Service sollte so aufgebaut werden, dass die Ergebnisse der

Clientabfrage möglichst vollständig und korrekt sind.

Ein Vergleich zwischen den drei Design-Varianten nach den oben genannten Krite-

rien wird in Tabelle 4-4 angezeigt (vgl. [Kür-08], [Mül-10], [Lor-11]).


72

Tabelle 4-4: Vergleich verschiedener Discovery Service Design-Varianten

Der Discovery Service im "Directory Look-Up Design" sendet Clients die ermittelten

EPCIS-Adressen zurück und Clients schicken danach selbst Abfragen an die jeweili-

gen EPCIS-Server. Das größte Problem bei diesem Design besteht darin, dass EP-

CIS-Server sensible Geschäftsinformationen enthalten können und Unternehmen

daher aus Sicherheitsgründen ihre EPCIS-Adressen nicht an unberechtigte Clients

weitergeben möchten. Um das Problem zu lösen, können Unternehmen dem Disco-

very Service Zugangsrechte auf ihren EPCIS-Server einräumen, was zu erheblichem

administrativen Aufwand führen könnte, da sich die Geschäftsbeziehungen zwi-

schen Unternehmen häufig ändern und somit die Zugangsrechte, die beim Discove-

ry Service gespeichert sind, entsprechend häufig zu aktualisieren sind. Außerdem ist

dieses Design mit hoher Komplexität und großem Implementierungsaufwand der

Clientanwendungen verbunden, da Clients selbst zuständig sind, Abfragen zu schi-

cken, Ergebnisse zu empfangen bzw. zu aggregieren.

Im Vergleich dazu leitet der Discovery Service im "Query Relay Design" Abfragen

von Clients direkt an betroffene EPCIS-Server weiter und Clients sind dadurch nur

zuständig, Ergebnisse zu empfangen bzw. zu aggregieren. Bei diesem Design behal-

ten Unternehmen Zugangskontrolle über ihre Daten. Der Nachteil besteht darin,


73

dass Clients nicht wissen, wie viele Antworten insgesamt zu erwarten sind. Sollte ein

oder mehrere EPCIS-Server außer Betrieb sein, können Clients nicht darüber infor-

miert werden. Dadurch ist die Qualität der Ergebnisse nur mäßig gewährleistet mit

gleichzeitig hoher Client-Komplexität.

Das Aggregating Discovery Service hat im Vergleich zu den beiden anderen Kandi-

daten nicht nur einen sicheren Zugangsmechanismus, sondern bietet darüber hi-

naus geringe Client-Komplexität, da sowohl die Abfrage als auch die Aggregation

von Ergebnissen vom Discovery Service übernommen werden. Ein Problem bei die-

sem Design (auch bei dem Query Relay Design) besteht darin, dass die Vertraulich-

keit der Clientabfragen nicht garantiert werden kann. Die Abfragedetails und das

Interesse von Clients können dadurch an Dritte übermittelt werden. Weiterhin be-

steht Unklarheit, welche Abfragen für Clients von Interessen sind und wie die Ergeb-

nisse aggregiert werden können. Die bisherigen Forschungsarbeiten in der Wissen-

schaft haben sich mit diesen Fragestellungen noch nicht beschäftigt.

In dieser Forschungsarbeit wird ein Rückverfolgungsdienst für die Lebensmittel-

Supply-Chain konzipiert [Wan-12]. Dieser Dienst basiert hauptsächlich auf dem De-

sign des Aggregating Discovery Service, welcher erweitert bzw. für die Lebensmit-

telkette adaptiert wurde. In den folgenden Abschnitten wird sein Aufbau beschrie-

ben.

4.4.4 Aufbau des Rückverfolgungsdiensts

Der Rückverfolgungsdienst erfüllt die folgenden Funktionen:

1. Ermittlung der beteiligten EPCIS-Server;

2. Absenden von aufeinanderfolgenden Abfragen (Subqueries) an beteiligte EPCIS-

Server entsprechend einer bestimmten Logik;

3. Aggregation der zurückkommenden Antworten, um die Rückverfolgbarkeit von

Objekten in der Supply-Chain zu erreichen. Clients erhalten dadurch Informatio-

nen, wann das angefragte Objekt welche beteiligten Unternehmen verlassen hat

und wann es von welchen Unternehmen erhalten wurde. Das heißt, die soge-

nannten „One Step Up, One Step Down“-Rückverfolgbarkeitsinformationen in

der gesamten Wertschöpfungskette können durch diesen Dienst automatisch

ermittelt und verkettet werden.

4. Berechtigten Benutzern können Unternehmen ihre EPCIS-Adressen zurückschi-

cken, damit die Benutzer anhand der Adressen nach weiteren Informationen di-

rekt bei den EPCIS-Servern abfragen können (Ressource-Abfrage).


74

Abbildung 4-11: Aufbau des Rückverfolgungsdiensts

Der Aufbau des Rückverfolgungsdiensts ist in Abbildung 4-10 skizziert. Der Dienst

besteht aus einer Datenbank, einem Computing-Modell für Abfrage und Aggregation

sowie einigen Web-Service-Schnittstellen.

Sobald ein Objekt, das mittels EPC identifiziert ist, bei einem bestimmten Unter-

nehmen in der Supply-Chain erfasst wird, überprüft der EPCIS-Server des Unter-

nehmens, ob dieser EPC in seiner Datenbank zum ersten Mal auftaucht. Falls ja,

wird der EPCIS-Server diesen EPC beim Rückverfolgungsdienst über die Registrie-

rungsschnittstelle registrieren. In der Datenbank des Rückverfolgungsdiensts wer-

den EPCs zusammen mit den entsprechenden EPCIS-Adressen gespeichert. Sobald

eine Client-Abfrage für einen bestimmten EPC eingegangen ist, ermittelt der Rück-

verfolgungsdienst zuerst die entsprechenden EPCIS-Serveradressen, unter denen

der abgefragte EPC aufgetaucht ist. Anschließend bearbeitet der Dienst die Client-

Abfrage und sendet Subqueries an die ermittelten EPCIS-Server basierend auf der

Abfrage- und Aggregationslogik. Nachdem alle Antworten von den jeweiligen EP-

CIS-Servern zurückgekommen sind, werden sie analysiert und zusammengeführt.

Am Ende wird das Ergebnis an die Client-Anwendung zurückgeschickt.

Die Abfrage- und Aggregationslogik spielt eine wichtige Rolle für den Rückverfol-

gungsdienst. Benutzer könnten interessiert sein, ein Produkt, eine Karton (Umverpa-

ckung) oder ein THM wie eine Palette oder einen Behälter zurück zu verfolgen. Je

nach Rückverfolgungsebene wird die Abfrage unterschiedlich bearbeitet. Wie bereits

in Abschnitt 4.2.2 diskutiert, wird im Rahmen dieser Forschungsarbeit die eindeutige

Identifikation der Objekte auf THM-Ebene und Kartonebene vorgeschlagen. Produk-

te werden weiterhin durch EAN-Nummer, Chargennummer und Ablaufdaum ge-

kennzeichnet, was heute in der Industrie weit verbreitet ist. Jedoch werden sie mit


75

den Verpackungskartons verknüpft werden, so dass Produkte auch durch das EPC-

Netzwerk rückverfolgt werden können.

c

Start

Tracing-Ebene?

Kartonebene THM-Ebene

Datenbank nach beteiligten EPCIS-URLs abfragen

Jeden beteiligten EPCIS abfragen

Abfrageparameter: eventType = AggregationEvent,Match_epc = <epc>.

Auf alle Antworten warten

Datenbank nach beteiligten EPCIS-URLs abfragen

Jeden betreffenden EPCIS abfragen

Parameter für die erste Abfrage: MATCH_epc = <epc>, EQ_bizStep = shipping.

Parameter für die zweite Abfrage: MATCH_epc = <epc>, EQ_bizStep = receiving.

Auf alle Antworten warten

Antworten aggregieren,nach Recordzeit ordnen

Ergebnisse zum Client schicken

ParentIDs als neue EPCs ermitteln

Jeden der EPCs rückverfolgen

Produktebene

Lokalen EPCIS abfragen(z.B. Handel)

Abfrageparameter: EQ_EAN_Number = <EAN_Number>,EQ_Lot_Number = <Lot_Number>, EQ_Expiry_Date = <Expiry_Date>

Erhaltene EPCs werden mit Hilfe des Ermittlungsdiensts

weiter rückverfolgt

Abbildung 4-12: Flussdiagram für die Abfrage- und Aggregationslogik

Das Flussdiagramm für die Abfrage- und Aggregationslogik ist in Abbildung 4-11

dargestellt. Um die Rückverfolgung von Objekten in der Lieferkette zu ermöglichen,

ist es wichtig zu ermitteln, wann und wo das abgefragte Objekt geliefert oder emp-

fangen wurde. Daher werden an alle beteiligten EPCIS-Servers Subqueries gesendet

werden, die die Standardkompatiblen Parameter MATCH_epc = <epc>, EQ_bizStep

= shipping/EQ_bizStep = receiving enthalten. Die zurückkommenden Antworten aus

den jeweiligen beteiligten EPCIS-Servern werden nach zeitlicher Reihenfolge aggre-

giert und anschließend an die Clientanwendungen zurückgeschickt.


76

Um Kosten so gering wie möglich zu halten, erfolgt die Identifizierung auf Karton-

ebene in der Regel mittels Barcode statt mittels RFID. Zur Steigerung der Effizienz

der Logistik werden die Barcodes auf Verpackungskartons nicht bei jedem Ware-

nein- und -ausgang einzeln gescannt. Da die Kartons bei der Kommissionierung

durch AggregationEvent den beladenen THM zugeordnet sind, kann die Verfolgung

von Kartons durch die Verfolgung von ihren „Eltern“, nämlich den THM, mit denen

die Kartons geliefert wurden, erreicht werden. THM werden mit RFID gekennzeich-

net und daher bei jedem Warenein- und –ausgang automatisch erfasst. Sobald eine

Client-Abfrage auf Kartonebene eingegangen ist, sendet der Rückverfolgungsdienst

zuerst Subqueries an die beteiligten EPCIS-Server, um die Eltern-EPCs des abge-

fragten EPCs zu ermitteln. Die Parameter für die Abfrage sind: eventType = Aggre-

gationEvent, MATCH_epc = <epc>. Nachdem die Eltern-EPCs erhalten worden sind,

werden sie durch den Rückverfolgungsdienst mit dem oben beschrieben Verfahren

für THM weiter verfolgt. Dadurch kann die Rückverfolgbarkeit auf Kartonebene voll-

ständig erreicht werden.

Der Rückverfolgungsdienst baut auf dem Aggregating Discovery Service auf und

hat neben den Vorteilen des Aggregating Discovery Service noch folgende weitere

Vorteile:

1. Benutzer können mit einer einzelnen Abfrage einen klaren Überblick über die ge-

samte Historie des abgefragten Objekts entlang der Lieferkette erhalten, ohne

selbst Abfragen zu organisieren und Antworten zu analysieren bzw. zu kombinie-

ren.

2. Es besteht kein Vertraulichkeitsproblem für die Benutzer, da in Benutzerabfragen

keine detaillierten Parameter enthalten sind.

3. Für berechtigte Benutzer besteht außerdem die Möglichkeit zur Ressource-

Abfrage. EPCIS-Server können berechtigten Benutzern ihre URL-Adressen durch

den Rückverfolgungsdienst mitgeben, damit die Benutzer mit den Adressen die

entsprechenden EPCIS-Server nach weiteren Details eigenständig abfragen kön-

nen. Somit können die Vorteile des Discovery Service mit dem „Directory Look-

Up Design“ kombiniert werden.

4.5 Fazit

In den vorangegangenen Abschnitten wird ein Konzept für ein EPC-basiertes Daten-

netzwerk entwickelt. Nachdem das Nummernsystem anhand eines Beispielsszena-

rios festgelegt wird, wird auf den Einsatz und die Anpassung des EPCIS näher ein-

Fazit

77

gegangen. Dazu werden die eingesetzten EPCIS-Ereignistypen, die EPCIS-Attribute

und die Vokabelelemente vorgeschlagen. Zudem wird das Mapping zwischen den

typischen Logistikprozessen und den EPCIS-Ereignissen dargestellt. Des Weiteren

wird ein Rückverfolgungsdienst aufgebaut, der dazu dient, kettenübergreifende EP-

CIS-Daten zu entdecken bzw. zu aggregieren, um die Rückverfolgbarkeit und die

Transparenz in der Supply-Chain zu ermöglichen. Zum Aufbau des EPC-basierten

Datennetzwerkes wird in dieser Arbeit vorgeschlagen, dass die eindeutige Identifika-

tion auf Umverpackungs- und Transporthilfsmittelebene erfolgt. Die Produkte wer-

den dagegen weiterhin durch EAN-Artikelnummer und Chargennummer gekenn-

zeichnet, weil der Wechsel auf eine eindeutige Identifikation der Produkte zu erheb-

lichen Kosten führen kann und daher noch nicht realistisch ist.


78

Generierung realistischer EPCIS-Ereignisse durch Ablaufsimulation

79

5 Umsetzung des Konzepts

Nachdem das Konzept für ein EPC-basiertes Datennetzwerk erstellt wurde, gilt es

im nächsten Schritt, ein Informationssystem im Sinne eines „Proof of Concept“ zu

entwickeln. Da die Auto-ID-gestützte Lebensmittel-Supply-Chain in der Realität

noch nicht existiert, wird das Informationssystem in einer simulierten Umgebung

implementiert. Das Informationssystem besteht aus mehreren EPCIS-Instanzen, die

EPC-Daten abspeichern und diese für weitere Anwendungen zur Verfügung stellen,

einem Rückverfolgungsdienst, der die Ermittlung und die Aggregation von verteilen

EPCIS-Server ermöglicht, und einer Clientapplikation, die die Ergebnisse von Kun-

denabfragen visualisiert.

Bevor das Informationssystem aufgebaut wird, sind zunächst Testdaten zu erzeu-

gen, die die Entwicklung von Informationssystemen unterstützen. Dazu wird im

Rahmen dieser Arbeit ein Verfahren entwickelt, das mit Hilfe von Ablaufsimulationen

realistische EPCIS-Ereignisse generiert (Abschnitt 5.1). Darauffolgend werden die

Implementierungsdetails des Informationssystems vorgestellt (Abschnitt 5.2). Da das

Informationssystem in einer lokalen Umgebung implementiert wird, wird zum Eva-

luationszweck die mögliche Netzwerkverzögerung simuliert und analysiert (Abschnitt

5-3). Abschließend werden die Ergebnisse und Erkenntnisse dieses Kapitels zu-

sammengefasst (Abschnitt 5.4).

5.1 Generierung realistischer EPCIS-Ereignisse durch Ablauf-simulation

5.1.1 Ziel der Ablaufsimulation

Um die Entwicklung von Informationssystemen zu unterstützen und ihren Prototy-

pen zu testen, ist die Generierung von Testdaten von großer Bedeutung. Da die

konzipierten Auto-ID-gestützten Identifikationspunkte in der Lebensmittel-Supply-

Chain noch nicht existieren, ist es notwendig, realistische Daten (EPCIS-Ereignisse)

zu erzeugen, um so die Entwicklung eines EPC-basierten Datennetzwerkes zu er-

möglichen.

Datengenerator ist ein häufig verwendetes Werkzeug für die Erzeugung von Testda-

ten in der Computerwissenschaft. Der Nachteil des Datengenerators darin, dass die

zeitlichen und räumlichen Abhängigkeiten der Logistikprozesse nicht dargestellt

werden können.


80

Im Rahmen dieser Forschungsarbeit werden Methoden entwickelt, mittels derer rea-

listische EPCIS-Ereignisse durch Ablaufsimulation generiert und in die IT-

Infrastruktur weitergeleitet werden können. Unter Ablaufsimulation versteht man die

Simulation von über- und innerbetrieblichen Logistikprozessen bei der Planung,

Realisierung und im Betrieb [Ulb-10]. Die Datenerzeugung durch Ablaufsimulation

hat folgende Vorteile:

1. Die Identifikationspunkte entlang der gesamten Lieferkette im vorgeschlagenen

Soll-Konzept können dadurch leichter abgebildet. So kann die IT-Infrastruktur

entwickelt werden, ohne dass vorher Hardware in die realen Prozesse implemen-

tiert werden muss.

2. Die zeitlichen und räumlichen Prozessabhängigkeiten können durch die Ablauf-

simulation dargestellt werden, was mit einem konventionellen Daten-Generator,

wie oben bereits erwähnt, schwer zu realisieren wäre.

Die in dieser Arbeit entwickelte Idee zur Datengenerierung ist neu. Die meisten ver-

gleichbaren Ablaufsimulationen in der Forschung wurden bisher dazu verwendet, die

Leistungskennzahlen der Supply-Chains vor und nach dem Einsatz von Auto-ID-

Technologie zu vergleichen. Zur Erzeugung von realitätsnahen Leseevents durch

Ablaufsimulation findet man nur wenige Arbeiten. So wurde die Modellierung der

RFID-basierten Lagerprozesse für Fast-Moving-Goods durch Diskrete-

Ereignissimulation in Simul8 beleuchtet [Bot-08]. Der EPC-Datenfluss wurde durch

dieses Simulationsmodell generiert und für eine Analyse der Logistik-

Leistungskennzahlen verwendet. Ein anderer Forschungsansatz hat mit Hilfe der

Ablaufsimulation realitätsnahe EPCIS-Ereignisse für die pharmazeutischen Supply-

Chains erzeugt, sodass die Daten für Testzwecke zur Verfügung gestellt und die zu

erwartende Datenmenge dadurch geschätzt werden konnte [Mül-09].

Im Rahmen dieser Forschungsarbeit wird die Ablaufsimulation verwendet, um realis-

tische EPCIS-Ereignisse nach dem vorgeschlagenen Konzept in der Lebensmittel-

Supply-Chain zu generieren. Außerdem werden die generierten EPCIS-Ereignisse

durch eine in diese Arbeit entwickelte Methode in Echtzeit an das Informationssys-

tem weitergeleitet, so dass der Informationsaustausch dadurch besonders realitäts-

nah abgebildet wird und somit die Entwicklung funktionsfähiger Software-Module

unabhängig von der Hardwareinfrastruktur ermöglicht werden kann.


81

5.1.2 Entwicklung des Simulationsmodells

5.1.2.1 Simulationsumgebung

Zur Generierung realistischer EPCIS-Ereignisse wird im Rahmen dieser Forschungs-

arbeit das Simulationsprogramm Plant Simulation verwendet. Plant Simulation ist

eine Software der Firma Siemens zur Simulation komplexer Produktionsprozesse

und Logistikabläufe. Die folgenden wesentlichen Merkmale von Plant Simulation

sind für die Modellbildung dieser Arbeit besonders geeignet:

· Objektorientierung

Simulation in Plant Simulation ist vollständig objektorientiert. Somit ist die Model-

lierung hierarchischer Strukturen und die Vererbung von Objekten möglich.

Durch die Objektorientierung bei Plant Simulation werden Benutzerfreundlichkeit

sowie eine effiziente Simulation von komplexen Systemen ermöglicht.

· Bausteinkonzept

Die Simulationsumgebung in Plant Simulation stellt eine Palette von Grundbau-

steinen zur Verfügung, mit Hilfe derer Anwender beliebige Bausteine erstellen

und wiederverwenden können. Dadurch können eine große Anwendungsbreite

und eine hohe Effizienz bei der Simulation erreicht werden.

· Flexible Programmiermöglichkeit

Zur Realisierung spezieller Steuerungen sowie zur Erweiterung der Standard-

bausteine bietet Plant Simulation eine integrierte Programmiersprache: SimTalk.

Sie ist objektorientiert und hoch flexibel. Außerdem steht ein leistungsfähiger

Debugger zur Fehlersuche zur Verfügung. Mit SimTalk können Anwender eigene

Steuerungsmethoden programmieren, um spezielle und individuelle Funktionen

zu realisieren.

· Offene Schnittstelle

Plant Simulation bietet verschiedene Schnittstellen für den Datenaustausch und

die Interprozesskommunikation nach außen. Über die Schnittstellen ist Plant Si-

mulation für individuelle Erweiterungen offen und die Integration in andere Infor-

mationssysteme sind dadurch möglich.


82

5.1.2.2 Modellaufbau

Ziel des Simulationsmodells soll sein, wie bereits beschrieben, realistische EPCIS-

Ereignisse nach dem vorgeschlagenen Konzept, das in Abschnitt 4.2.3 und 4.4.4

beschrieben wurde, zu generieren. Da die Supply-Chain nach dem Konzept vier Stu-

fen enthält, wurden vier Netzwerkkomponente in Plant Simulation entwickelt: der

Hersteller, das Zentrallager, das Regionallager (Cross-Docking) und die Filiale. Unter

Netzwerk in Plant Simulation versteht man einen anwenderspezifischen Baustein,

der aus verschiedenen Grundbausteinen besteht und eine höhere Funktionalität er-

füllt. Das Netzwerk ist Grundlage aller Modelle. Durch die Verwendung des Netzwer-

kes sind Supply-Chain-Beteiligte in der jeweiligen Stufe nur einmal zu implementie-

ren. Anschließend kann das erstellte Netzwerk beliebig dupliziert werden, wodurch

ein Logistiknetzwerk mit beliebigen Beteiligten entsprechend schnell abgebildet wird.

Weiterhin liegt der Vorteil der Verwendung von Netzwerken darin, dass eine Ände-

rung an dem Basisnetzwerk automatisch auf alle abgeleiteten Netzwerkkomponen-

ten übertragen wird. So können im Nachhinein Prozesse in allen abgeleiteten Kom-

ponenten mit geringem Aufwand angepasst werden.

Innerhalb des jeweiligen Netzwerkes werden die Logistikprozesse des Konzepts mit

Hilfe von Grundbausteinen und Steuerungsmethoden abgebildet. Um einen klaren

Überblick über den Modellaufbau zu bekommen, werden die verwendeten Bausteine

und Steuerungsmethoden im Simulationsmodell nach den folgenden Funktionsbe-

reichen gruppiert dargestellt:

· Prozesssteuerung

Dieser Bereich beinhaltet Elemente, die die Materialflüsse in der Simulation

steuern bzw. sicherstellen. Dabei wird beispielsweise der Baustein Generator

verwendet, um Kundenbestellungen täglich auszulösen und die entsprechenden

Kommissionierungsprozesse zu starten. Weiterhin wird eine Methode program-

miert, die das Beladen und Entladen von Waren nach Vollständigkeit prüft und

anschließend den Versand per LKW anstößt.

· Abbildung der Materialflüsse

In diesem Bereich werden die Materialflüsse zusammen mit der physischen

Struktur in der Lieferkette abgebildet. Dabei werden die Logistikprozesse wie das

Ein- und Auspacken von Produkten, die Etikettierung der Verpackungskartons,

die Kommissionierung mittels THM sowie das Laden und Entladen der LKW mit-

tels Standardbausteinen modelliert. Weiterhin werden Identifikationspunkte wie


83

das RFID-Gate durch den Baustein „Einzelstation“ dargestellt und in den Prozes-

sen eingeführt.

· Generierung der EPCIS-Ereignisse

Zur Generierung realistischer EPCIS-Ereignisse werden integrierte Schnittstellen

ins Simulationsmodell eingesetzt. Dabei werden spezielle Steuerungsmethoden

programmiert, die durch die Identifikationspunkte aufgerufen werden und die

entsprechenden EPCIS-Ereignisse standardkonform erzeugen.

· Registrierung beim Rückverfolgungsdienst

Um kettenübergreifendes Tracking & Tracing zu ermöglichen, müssen EPCIS-

Server neue erfasste EPCs zusammen mit ihren EPCIS-Adressen beim Rückver-

folgungsdienst registrieren. Dafür werden in der Simulation Methoden entwickelt,

durch die die Registrierung erfolgen kann.

Abbildung 5-1 zeigt Screenshots des Simulationsmodells in Plant Simulation. Auf die

Umsetzung der in dieser Arbeit entwickelten Idee zur Generierung realistischer EP-

CIS-Ereignisse wird im folgenden Abschnitt ausführlich eingegangen.


84

Abbildung 5-1: Das Simulationsmodell in Plant Simulation


85

5.1.2.3 Generierung realistischer EPCIS-Ereignisse

Bildung der EPCs zur Objektkennzeichnung

Bevor auf die Methodik zur Generierung der EPCIS-Ereignisse eingegangen wird,

sind die verwendeten EPCs zur Objektkennzeichnung im Simulationsmodell zu bil-

den.

Die Verpackungskartons werden, wie bereits in Abschnitt 4.3.2 vorgestellt, jeweils

mit einer SGTIN eindeutig gekennzeichnet, die dem folgenden Schema folgt:

urn:epc:id:sgtin:CompanyPrefix.ItemReference.SerialNumber.

In der Simulation werden Kartons im Netzwerk Hersteller durch den Standardbaus-

tein Quelle generiert. Die Bezeichnung CompanyPrefix wird als globale Variable um-

gesetzt, da sie in allen EPCs zufinden ist und ihr Wert dadurch einfach angelegt

werden kann. Beispielsweise wird in der Simulation 1000001 als CompanyPrefix für

das Netzwerk Manufacturer1 vergeben2.

Die Kartons werden durch bewegliche Elemente (BEs) dargestellt und verfügen über

folgende benutzerdefinierte Attribute: ItemReference, SGTIN, EAN, Chargennummer

und Ablaufdatum. In der Simulation wird 123456 als ItemReference für Kartons ver-

wendet. Um eine eindeutige SGTIN für jeden Karton zu vergeben, wird eine Einzel-

station verwendet und eine Methode programmiert, die den Etikettierungsprozess

abbildet. Sobald ein Karton die Einzelstation verlassen hat, wird die Methode aufge-

rufen, die die Werte für CompanyPrefix, für ItemReference und für SerialNumber in

einen String zusammenführt, um eine SGTIN für den Karton zu generieren. Darüber

hinaus erhöht sich der Wert der SerialNumber um eins, wodurch eine eindeutige

Identifikation für jeden Karton garantiert werden kann (siehe Abbildung 5-2).

Abbildung 5-2: Methode zur Generierung der SGTIN (in SimTalk)

Um die Rückverfolgbarkeit von Produkten zu ermöglichen, wird in der Simulation für

jeden Produkttypen eine feste EAN generiert. Die Abbildung von Chargennummer

2 Die in dieser Arbeit verwendeten Werte sind exemplarisch zu verstehen, können aber je nach An-wendungsfall nachträglich angepasst werden.


86

und Ablaufdatum erfolgt durch eine Methode, in der diese Nummer in Bezug auf das

Datum und die Uhrzeit aus dem Ereignisverwalter generiert werden.

Wie bereits in Abschnitt 4.3.2 vorgestellt, werden THM durch GRAI eindeutig identi-

fiziert. Weiterhin werden sie bei jeder Lieferung jeweils mit einer SSCC (NVE) verse-

hen. Die Codierungsschemata sind:

urn:epc:id:grai:CompanyPrefix.AssetType.SerialNumber.

urn:epc:id:sscc:CompanyPrefix.SerialReference.

Die Abbildung von GRAI und SSCC in der Simulation erfolgt ähnlich wie die von

SGTIN. Die Bezeichnung AssetType wird verwendet, um die Art des THMs zu unter-

scheiden. Da die Gesamtlänge aus CompanyPrefix und AssetType immer zwölf Stel-

len behält und die Bezeichnung CompanyPrefix in der Simulation stets aus sieben

Ziffern besteht, soll der Wert für AssetType fünf Ziffern umfassen. Dafür werden in

der Simulation exemplarisch 11111 für Palette und 22222 für Tiefkühlbehälter ver-

wendet.

Abbildung der Identifikationspunkte

Die Identifikationspunkte werden in der Simulation mittels des Grundbausteins „Ein-

zelstation“ abgebildet. Eine Basisklasse wird dafür erstellt, von der alle Identifikati-

onspunkte abgeleitet werden können.

Abbildung 5-3: Benutzerdefinierte Attribute für den Baustein „Identifikationspunkt“


87

Zur Generierung standardkompatibler EPCIS-Ereignisse enthält jeder Identifikati-

onspunkt-Baustein folgende benutzerdefinierte Attribute: action, bizLocation, bizS-

tep, disposition, readpoint (siehe Abbildung 5-3). Diese Attribute stellen, wie bereits

in Abschnitt 4.4.2 vorgestellt, die „Was, Wann, Wo, Warum” Informationen dar und

sind in jedem generierten EPCIS-Ereignisse aufzufinden. Die URI-Schemata der At-

tribute werden in der Basisklasse definiert und können in den abgeleiteten Baustei-

nen je nach Prozesskontext leicht angepasst werden.

Erfassung der EPCIS-Ereignisse

Um standardisierte EPCIS-Ereignisse mit XML-Bindung zu generieren, kommt die

integrierte XML-Schnittstelle in Plant Simulation zum Einsatz. Weiterhin werden Me-

thodenbausteine erstellt, die die XML-Schnittstelle aufrufen und alle relevanten Da-

ten in eine XML-Datei serialisieren. Sobald ein Objekt einen Identifikationspunkt-

Baustein verlassen hat, wird die entsprechende Methode innerhalb des Bausteins

aufgerufen und dabei ein EPCIS-Ereignis erzeugt.

Nach dem vorgeschlagenen Konzept werden, wie bereits diskutiert, insgesamt drei

Arten von EPCIS-Ereignissen ausgelöst: das ObjectEvent, das AggregationEvent

und das QuantityEvent. Dafür werden drei Basis-Methodenbausteine erstellt, deren

Ablaufdiagramme in Abbildung 5-3 dargestellt sind. Mit der XML-Schnittstelle in

Plant Simulation werden XML-Daten sequentiell verarbeitet und die EPCIS-

Ereignisse werden dadurch Zeile für Zeile geschrieben. Dabei ist die XML-

Schnittstelle zum Schreiben zuerst zu öffnen, woraufhin die XML-Elemente zeilen-

weise geschrieben werden. Dazu gehören zunächst die Kopfdaten, die den verwen-

deten Namensraum, das Erstellungsdatum und die Schema-Version deklarieren.

Nach den Kopfdaten sind die EPCIS-Attribute eins nach dem anderen einzufügen,

die die „Was, Wann, Wo, Warum“ – Informationen darstellen. Während die erfassten

EPCs beim ObjectEvent unter dem Attribut „epcList“ aufzufinden sind, werden sie

beim AggregationEvent unter dem „ParentID“ bzw. dem „ChildEPCs“ eingetragen.

Dabei gibt das „ParentID“ den EPC oder den Identifikator für das Objekt der oberen

Hierarchiestufe bei einer Aggregation an, wie beispielsweise eine beladene Palette.

Die „ChildEPCs“ enthält dagegen die EPCs für die Objekte der unteren Hierarchie-

stufe, wie beispielsweise die Kartons, die auf die Palette geladen werden. Im Ver-

gleich dazu enthält das QuantityEvent keine EPCs zur eindeutigen Kennzeichnung

von Objekten. Stattdessen wird das Attribut „epcClass“ verwendet, um die Anzahl

von Objekten einer bestimmten Klasse anzugeben.


88

Start

XML-Schnittstelle öffnen

XML-Kopfteil schreiben(Namespace, CreationDate,

SchemaVersion)

XML-Datenteil generieren

„ObjektEvent“ als Elemente schreiben

Andere EPCIS-Attribute als Elemente schreiben

Weitere Attribute vorhanden?

XML-Schnittstelle schließen

Nein

Ja

Start


XML-Kopfteil schreiben(Namespace, CreationDate,

SchemaVersion)


„AggregationEvent“ als Elemente schreiben

Andere EPCIS-Attribute als Elemente schreiben



Nein

„ParentID“ als Elemente schreiben

Ja

Start


XML-Kopfteil generieren(Namespace, CreationDate,

SchemaVersion)


„QuantityEvent“ als Elemente schreiben

Andere EPCIS-Attribute als Elemente einfügen



Nein

„epcClass“ als Elemente schreiben

Ja

„ChildEPCs“ als Elemente schreiben,

i-er ChildEPC schreiben(Anfangswert i=1)

i <=n?(n=Anzahl der ChildEPCs)

Nein

i=i+1

Ja

„epcList“ als Elemente schreiben,

i-er EPC schreiben(Anfangswert i=1)

i <=n?(n=Anzahl der

EPCs)

i=i+1

Ja

Nein

„Quantity“ als Elemente schreiben

Quantity = Anzahl der BEs im Lager

a) ObjectEvent b) AggregationEvent c) QuantityEvent

Abbildung 5-4: Ablaufdiagramme für die Generierung von EPCIS-Ereignissen mit XML-Bindung in

Plant Simulation

Die EPCIS-Ereignisse, die nach den oben genannten Verfahren in Plant Simulation

generiert werden, sind realistisch und gleichen den EPCIS-Ereignissen, die die Auto-

ID-Middleware in der Praxis erstellt. Daher können sie zum Aufbau und Testen von

EPC-basierten Informationssystemen gut verwendet werden. Ein Beispiel für die ge-

nerierten EPCIS-Ereignisse ist in Abbildung 5-4 dargestellt.

Aufbau eines Informationssystems als „Proof of Concept“

89

Abbildung 5-5: Beispiel für die generierten EPCIS-Ereignisse

5.2 Aufbau eines Informationssystems als „Proof of Concept“

5.2.1 Systemarchitektur

Um ein „Proof of Concept“ zu erstellen, wird ein Informationssystem entwickelt, das

das Konzept des EPC-basierten Informationsnetzwerkes in einer simulierten Umge-

bung umsetzt. Die Architektur des Systems ist in Abbildung 5-5 skizziert.


90

Abbildung 5-6: Architektur des Informationssystems

Das System besteht aus einem Rückverfolgungsdienst, mehreren EPCIS-Server-

Instanzen und einer Clientapplikation. Als Programmiersprache wird Java verwendet,

da sie sich durch ihre Plattformunabhängigkeit auszeichnet und sich somit als die

am weitesten verbreiteten Netzwerkprogrammiersprache durchgesetzt hat. Zudem

wird das Softwareplattform Fosstrak zur Implementierung von EPCIS-Instanzen ein-

gesetzt. Fosstrak [Fos-13] ist ein Opensource-Framework für RFID-Anwendungen,

das von der ETH Zürich initiiert und in Java entwickelt wurde. Die Implementierung

vom Fosstrak-EPCIS entspricht dem EPCIS-Standard und wurde von EPCglobal

zertifiziert. Der Fosstrak-EPCIS besteht aus a) einer Datenbank, die mit MySQL im-

plementiert wurde und die die EPCIS-Ereignisse abspeichert; b) einer Erfassungs-

schnittstelle, die die EPCIS-Ereignisse in der Datenbank erfasst; c) einer Abfrage-

schnittstelle, über die Kundenabfragen nach EPCIS-Ereignissen erfolgen können.

Die Komponenten sind standardkonform implementiert und werden daher zum Auf-

bau jeder EPCIS-Instanz eingesetzt.

Um generierte EPCIS-Ereignisse durch Plant Simulation an das Informationssystem

weiterzuleiten, wurde im Rahmen dieser Arbeit ein Schnittstellenprogramm entwi-

ckelt. Die Softwarelogik überträgt die EPCIS-Ereignisse direkt an die Erfassungs-


91

schnittstelle von EPCIS per HTTP/Post, sobald diese in der Simulation erzeugt wer-

den (Abbildung 5-6). Auf diese Weise kann einerseits die Standardkonformität der

Daten geprüft und Ausnahmen bei der Datenerfassung gleich behandelt werden.

Andererseits kann der Informationsaustausch dadurch besonders realitätsnah auf-

gebaut und somit die Entwicklung funktionsfähiger High-Level-Applikationen unab-

hängig von der Hardwareinfrastruktur ermöglicht werden.

Abbildung 5-7: Weiterleitung der generierten EPCIS-Ereignisse an das Informationssystem durch ein

Schnittstellenprogramm

5.2.2 Registrierung beim Rückverfolgungsdienst

Um die Informationen zu einem bestimmten EPC in der gesamten Wertschöpfungs-

kette finden zu können, sind der EPC zusammen mit den EPCIS-Adressen beim

Rückverfolgungsdienst zu registrieren (vgl. Abschnitt 4.5.4). Hierfür wurde ein Prog-

ramm, das als Registrierungsdienst bezeichnet wird, im Rahmen dieser Arbeit ent-

wickelt.

Der Ablauf des Registrierungsprozesses ist in Abbildung 5-7 dargestellt. In der Si-

mulation wird der Registrierungsdienst in einem vordefinierten Zeitabstand in der

Simulation aufgerufen, der je nach Anwendungsbedarf nachträglich angepasst wer-

den kann. In einer realen Umsetzung können Unternehmen entscheiden, zu welcher

Zeit sie ihre Daten beim Rückverfolgungsdienst registrieren. Der Registrierungs-


92

dienst fragt die einzelnen EPCIS nach neuen erfassten EPCs ab. Falls neue EPCs im

vorangegangenen Zeitintervall in einen EPCIS aufgenommen wurden, wird der Re-

gistrierungsdienst diese EPCs zusammen mit dem entsprechenden EPCIS-URL in

eine XML-Datei serialisieren und an den Rückverfolgungsdienst weiterleiten. Die Da-

ten werden per Registrierungsschnittstelle aufgenommen und geparst. Danach wer-

den sie in der Datenbank des Rückverfolgungsdiensts abgespeichert und stehen zu

kettenübergreifenden Clientanwendungen zur Verfügung.

Registrierungsdienst EPCIS Rückverfolgungsdienst

nach erfassten EPCs abfragen

neue erfasste EPCs zurückgeben

Daten registrieren

Bestätigung

Daten abspeichern

EPCs und EPCIS-URL in eine XML-Datei serialisieren

XML parsen

Abbildung 5-8: Ablauf des Registrierungsprozesses beim Rückverfolgungsdienst

5.2.3 Clientapplikation

Der Rückverfolgungsdienst wurde nach dem Konzept implementiert, das in Ab-

schnitt 4.5.4 beschrieben wurde. Um die Abfrageergebnisse zu visualisieren, wurde

eine Web-basierte Clientapplikation entwickelt. Die Clientapplikation hat die Aufgabe,

einerseits Nutzeranfragen anzunehmen und an den Rückverfolgungsdienst weiterzu-

leiten. Andererseits akzeptiert sie die aggregierten Antworten des Rückverfolgungs-

diensts und stellt sie auf Google-Maps-Karten dar. Google Maps bietet eine Vielzahl


93

von APIs (Application Programming Interface), mit denen man Google-Karten in ei-

gene Webseite und eigene Anwendungen einbetten kann. Die APIs werden in Ja-

vaScript angesprochen und sind für Entwickler frei zugänglich.

Mit der Clientapplikation können Nutzer Objekte auf verschiedene Ebene (siehe

4.2.2) rückverfolgen. In Abbildung 5-8 werden Screenshots für die Produktrückver-

folgung, die unterste und komplizierteste Verfolgungsebene aufweist, angezeigt.

Nutzer werden aufgefordert, die EAN-Nummer, die Chargennummer und das Ab-

laufdatum des Produktes, das sie rückverfolgen möchten, anzugeben. Anschließend

werden über den lokalen EPCIS-Server die Kartons ermittelt, in denen die Produkte

mit den angegebenen Informationen verpackt sind. Der Rückverfolgungsdienst

übernimmt darauffolgend den Rückverfolgungsprozess der Kartons nach der Abfra-

ge- und Aggregationslogik, die in Abschnitt 4.5.4 beschrieben wurde, und die zu-

rückkommenden Ergebnisse werden auf Google-Maps in der Clientapplikation vi-

sualisiert. Jeder Marker in der Karte stellt einen Beteiligten an der Lieferkette dar.

Berechtigte Nutzer können über ein Info-Fenster auf einen Hyperlink-Verweis „See

more details“ gelangen, der sie zur Abfrageschnittstelle der lokalen EPCIS-Server

führt, wo weitere interne EPCIS-Daten je nach Interesse abgefragt werden können.

Beispielsweise können EPCIS-Ereignisse mit anderen „bizStep“ wie „packing“ or

„loading“ gelesen werden. Weiterhin können Temperaturdaten oder andere Informa-

tionen abgerufen werden.


94

Abbildung 5-9: Screenshots von der Clientapplikation

Evaluation

95

5.3 Evaluation

Das im letzten Abschnitt vorgestellte Informationssystem wurde in einer simulierten

Umgebung mit lokalen Rechnern umgesetzt. Bei der Implementierung in der Realität

ist eine mögliche Netzwerkverzögerung zu berücksichtigen, die die Leistung des

Informationssystems stark beeinflussen kann. Im Rahmen dieser Arbeit wird die

Netzwerkverzögerung mit analytischen Methoden zur Evaluation der Machbarkeit

des vorgestellten Konzepts berechnet und simuliert.

Nach der Theorie der Computernetzwerke [Kur-12] sind die Ausbreitungsverzöge-

rung 𝑑p , die Übertragungsverzögerung 𝑑t , und die Warteschlangenverzögerung 𝑑q

die Hauptquellen von Netzwerkverzögerungen. Es ist davon auszugehen, dass im

modernen Computernetzwerk die Verarbeitungsverzögerung sehr gering (normaler-

weise in der Größenordnung von Mikrosekunden oder noch darunter) ist und hier

vernachlässigt werden kann. Die gesamte Netzwerkverzögerung 𝑑 ist daher mit fol-

gender Formel zu berechnen:

𝑑 = 𝑑p + 𝑑t + 𝑑q (5-1)

Die Ausbreitungsverzögerung resultiert aus der Entfernung zwischen Rückverfol-

gungsdienst und EPCIS-Server (𝐷) sowie aus der Geschwindigkeit mit der sich Da-

tenpakete ausbreiten (𝐶):

𝑑p = 𝐷/𝐶 (5-2)

Die Übertragungsverzögerung ist durch die Bandbreite 𝐵 und die Paketgröße 𝐿p be-

stimmt:

𝑑t = 𝐿p/𝐵 (5-3)

Die Warteschlangenverzögerung ist die Zeit, die das Paket in einer Warteschlange

eines Hosts verbringt, bis es auf der Verbindungsleitung übertragen wird. Mit der

Software Wireshark3 wurden die Datenpakete erfasst und analysiert. Jedes Subque-

ry hat eine durchschnittliche Größe von ein KB und jede Subresponse von zwei KB.

Die Warteschlange von Datenpaketen beim Rückverfolgungsdienst folgt daher dem

M/D/1-Modell. Angenommen der Rückverfolgungsdienst arbeitet nach der FIFO-

33 Wireshark ist ein Tool zur Netzwerkanalyse, mit Hilfe dessen man Datenpakete im Netzwerkverkehr aufzeichnen und über eine grafische Oberfläche darstellen und analysieren kann.


96

Strategie (First In, First Out) arbeitet, wird die Warteschlagenverzögerung durch die

folgende Formel berechnet:

𝑑q =

12

1 (5-4)

𝜌 = 𝜇 (5-5)

𝜆 ist die durchschnittliche Senderate der Subqueries und 𝜇 ist die durchschnittliche

Servicerate des Rückverfolgungsdiensts. Es ist davon auszugehen, dass die Aus-

breitungsgeschwindigkeit gleich der Lichtgeschwindigkeit ist, die 2.998 x 108 m/s

beträgt. Zudem wird angenommen, dass die Entfernung zwischen Rückverfol-

gungsdienst und EPCIS-Server durchschnittlich 1000 km lang ist. Nach den oben

genannten Berechnungsformeln wurde die Netzwerkverzögerung in Matlab simuliert.

Die Ergebnisse sind in Abbildung 5-9 dargestellt.

Abbildung 5-10: Simulierte Netzwerkverzögerung zwischen dem Rückverfolgungsdienst und EPCIS-

Servern für einzelne Abfragen

Wie Abbildung 5-9 zeigt, hängt die Netzwerkverzögerung von der Zugangsbandbrei-

te des Rückverfolgungsdiensts und der Anzahl der Abfragen pro Zeiteinheit ab. Laut

einem Netzwerkmodell hat der Rückverfolgungsdienst maximal 1000 Clientabfragen

Fazit

97

pro Sekunde zu bearbeiten [Mil-08]. Mit einer Zugangsbandbreite von 200 Mbps

beträgt die Netzwerkverzögerung 6,88 ms, welche für Endbenutzer akzeptierbar ist.

5.4 Fazit

In den vorangegangenen Abschnitten wird der Aufbau eines Informationssystems

vorgestellt, der das Konzept des EPC-basierten Datennetzwerkes umsetzt. Das In-

formationssystem wird in einer simulierten Umgebung implementiert und gilt als ein

Prototyp für das in dieser Arbeit erarbeitete Konzept. Das System ermöglicht den

Benutzern, Objekte in der Lebensmittelkette effizient zu verfolgen und die „Wann,

Was, Wo, Warum“ Informationen über die Objekte auf einzelnen EPCIS-Servern zu

ermitteln. Dadurch werden die Rückverfolgbarkeit und die Transparenz in der Le-

bensmittelkette gesteigert. Da das System auf lokalen Rechnern implementiert wird,

wird am Ende dieses Kapitels die mögliche Netzwerkverzögerung durch analytische

Methoden simuliert und evaluiert.

Das in dieser Arbeit erarbeitete Konzept und das implementierte Prototyp sind

grundsätzlich auf andere Anwendungsgebiete und Branchen übertragbar, sofern

eine durchgehende Kennzeichnung von Objekten mittels EPC in der gesamten Lie-

ferkette erfolgt. In einer realen Umsetzung sind die EPCIS-Server der Unternehmen

an die eigene Prozessumgebung zu adaptieren. Weiterhin ist eine gemeinsame

Sprache der beteiligten Unternehmen zu etablieren wie beispielsweise die Einigung

auf die Vokabelelemente, um kettenübergreifende Anwendungen zu ermöglichen.


98

Integrationskonzept

99

6 Integration des EPC-Netzwerkes in vorhande-

ne/andere IT-Landschaften

In vielen Unternehmen sind die IT-Systeme unkoordiniert gewachsen. Dies führt zu

erheblichen Wartungskosten, was wiederum einen Innovationsstau zur Folge hat, da

Unternehmen nur einen verhältnismäßig kleinen Teil des für die IT zur Verfügung

stehenden Budgets für zukunftsorientierte Technologien investieren [Bux-06]. Vor

diesem Hintergrund ist es wichtig, wie die IT-Integration erfolgen kann, bevor neue

IT-Systeme eingeführt werden. Der Integration vorhandener und neuer IT-Systeme

kommt eine bedeutende Rolle zu, um einerseits Unternehmensprozesse durchgän-

gig zu unterstützen und andererseits gleichzeitig die entsprechenden Wartungskos-

ten niedrig zu halten.

Das EPC-basierte Datennetzwerk (nachstehend EPC-Netzwerk genannt) ermöglicht

eine verbesserte Rückverfolgbarkeit und damit eine erhöhte Transparenz in der Le-

bensmittel-Supply-Chain. Durch seine beschränkten Funktionalitäten kann es aller-

dings nicht alle Geschäftsprozesse in den Unternehmen unterstützen. Das Ziel des

EPC-Netzwerks soll darin liegen, die vorhandene IT-Landschaft zu ergänzen statt zu

ersetzen. Aus diesem Zusammenhang wird in diesem Kapitel die Integrationsmög-

lichkeit des EPC-Netzwerks in vorhandene/andere IT-Landschaften schwerpunkt-

mäßig untersucht. Dazu wird zunächst das Konzept für die Integration vorgestellt.

Darauf basierend wird die Integration am Beispiel eines Behältermanagementsys-

tems veranschaulicht. Zum Schluss werden die Erkenntnisse dieses Kapitels zu-

sammengefasst.

6.1 Integrationskonzept

Das EPC-Netzwerk, vor allem der EPCIS Standard, bietet eine Möglichkeit, detail-

lierte Informationen über Objektbewegungen in Echtzeit zur Verfügung zu stellen

und zwischen den Geschäftspartnern auszutauschen. Dadurch wird eine maximale

Transparenz in der Lebensmittel-Supply-Chain erreicht, die mittels traditioneller

ERP-Systeme nur schwer realisierbar ist. Es ist allerdings unrealistisch, die beste-

hende ERP-Systeme basierend auf den EPC-Daten komplett umzubauen, da tradi-

tionelle ERP-Systeme üblicherweise nicht darauf ausgelegt sind, mit EPC-basierten

Ereignisdaten umzugehen, und der Umbau daher zu enormem Anpassungs- und

Customizing-Aufwand führen würde. Weiterhin sind viele Geschäftsfunktionen wie

6 Integration des EPC-Netzwerkes in vorhandene/andere IT-Landschaften

100

beispielsweise Bestellungsprozesse oder Prognosen durch EPCIS-Ereignissen nicht

oder nur schwierig zu realisieren.

Als Integrationskonzept wird daher vorgeschlagen, neben der vorhandenen IT-

Infrastruktur ein EPCIS-Repository im Unternehmen aufzubauen, das die EPC-

Informationen in Echtzeit zur Verfügung stellt und Tracking & Tracing Applikationen

ermöglicht. Das Repository kann von verschiedenen ERP-Anwendungen bei Bedarf

abgefragt werden, was zum einen Datenredundanz vermeidet und zum anderen den

Einfluss auf vorhandene IT-Systeme einschränkt. Weiterhin sollte die bisherige EDI-

Kommunikation zwischen Geschäftspartnern, die in Abschnitt 2.3.2 bereits vorges-

tellt, beibehalten werden. EPCIS bietet die Möglichkeit, Auto-ID-basierte Daten auf

einem standardisierten Weg auszutauschen. Allerdings erhält er keine Geschäftsda-

ten wie Bestellung, Verkauf, Rechnungen usw., die typischerweise via EDI zwischen

den Geschäftspartnern ausgetauscht werden. Daher soll EPCIS idealerweise mit EDI

zusammenarbeiten und sich ergänzen. Das Integrationskonzept ist in Abbildung 6-1

illustriert.

Unternehmens-IT

EPC-Netzwerk

Auto-ID Infrastruktur

Middleware

ERP-Systeme

EPCISRückverfolgungs

-dienst

Andere GeschäftspartnerEDI

Abbildung 6-1: Konzept zur Integration des EPC-Netzwerkes in Unternehmens-IT

Darstellung der Integration am Beispiel eines Behältermanagementsystems

101

Für die Integration spielt die Middleware eine entscheidende Rolle. Middleware exis-

tiert als „Ebene in einem komplexen Softwaresystem, die als Dienstleister anderen

ansonsten entkoppelten Softwarekomponenten Services bereitstellt und den Daten-

austausch ermöglicht“ [Ora-99] und wird daher auch als EAI (Enterprise Application

Integration)-Werkzeug gesehen. Die Middleware verknüpft einerseits die erfassten

Auto-ID-Daten mit Kontextinformationen und leitet sie an das EPCIS-Repository

weiter, andererseits kommuniziert sie über Schnittstellen mit den ERP-Systemen,

damit viele Funktionenalitäten der Systeme automatisiert werden können, die ohne

Auto-ID und die entsprechende IT-Infrastruktur nur manuell zu erledigen sind. Dabei

werden auch Regeln und Aktionen in den Middleware-Systemen definiert, durch die

die Geschäftsprozesse sowie ihre Bearbeitungsstatus automatisch aktiviert bzw.

aktualisiert werden können.

6.2 Darstellung der Integration am Beispiel eines Behälterma-nagementsystems

Um die Integration darzustellen, wurde daher im Rahmen der vorliegenden Arbeit als

Beispiel ein RFID-basiertes Behältermanagementsystem entwickelt, das in folgen-

den Abschnitten näher betrachtet wird.

6.2.1 Einleitung

In den vergangenen Jahren hat das Thema Behältermanagement zunehmend an

Bedeutung gewonnen. Unter Behältermanagement versteht man die systematische

Planung, Steuerung und Überwachung von Kreisläufen der Mehrweg-THM [Gum-

06] (nachstehend einfach „Behälter“ genannt), das eine äußerst wichtige Aufgabe

und Herausforderung im Supply-Chain-Management darstellt. Gerade in der Le-

bensmittel-Supply-Chain werden für den Transport von Lebensmittelprodukten ver-

schiedene Behälter wie z.B. Palette, Tiefkühlbehälter, Rollbehälter usw. verwendet

(vgl. Kapitel 4.2). Die Verfügbarkeit bzw. die Funktionszuverlässigkeit der Behälter

gelten als Voraussetzung für eine effiziente und sichere Lebensmittellogistik. Trotz

der Wichtigkeit werden bei vielen Unternehmen die Behälter unsystematisch und

ineffizient verwaltet, was oft zu unnötig hohen Sicherheitsbeständen führt, woraus

eine unnötig hohe Kapitalbindung resultiert und die erforderliche Versorgungssi-

cherheit häufig trotz alledem nicht gewährleistet werden kann [Hof-06].

Um Behälterkreisläufe besser zu steuern, kommt das IT-gestützte Behältermanage-

mentsystem (BMS) zum Einsatz. Die Hauptaufgabe des BMS liegt darin, Behälter-


102

bewegungen im IT-System möglichst genau abzubilden und dadurch eine effiziente

Steuerung und Überwachung von Behälterflüssen zu erzielen. BMS lassen sich ver-

schieden einsetzen. Entweder wird das BMS direkt in den bestehenden ERP-

Systemen der beteiligen Unternehmen abgebildet, oder es wird als eigene IT-

Anwendung umgesetzt, die in der Regel Daten über Schnittstellen mit den ERP-

Systemen austauschen kann. Traditionelle BMS haben zwar die Funktionen, Behäl-

terbewegungen zu erfassen, allerdings erfolgt die Erfassung meist per manueller

Eingabe, was nicht nur zeitintensiv und fehleranfällig ist, sondern auch zu Unter-

schieden zwischen Materialfluss und Informationsfluss der Behälterkreisläufe führt.

In der Praxis kommt daher häufig vor, dass die Behälterbestände nicht richtig oder

nicht rechtzeitig gebucht werden, was unmittelbar Korrekturbuchungen oder mögli-

cherweise auch Sonderfahrten verursacht. Um die oben genannten Probleme zu

vermeiden, sollten entsprechende Identifikationssysteme und IT-Infrastrukturen ein-

gesetzt werden, die eine eindeutige Identifikation der Behälter sowie eine rechtzeiti-

ge und genaue Erfassung von Behälterbewegungen ermöglichen. Hierfür bietet sich

die RFID-Technologie aufgrund ihrer vielen Vorteile an.

Zur Darstellung der Integration des EPC-Netzwerkes in vorhandene/andere IT-

Landschaften wurde daher im Rahmen der vorliegenden Arbeit als Beispiel ein

RFID-basiertes Behältermanagementsystem entwickelt. Zudem wurde ein Demons-

trationsmodell gebaut, das mit dem Behältermanagementsystem verknüpft wird und

die Behälterflüsse veranschaulicht [Sch-12]. Abbildung 6-2 zeigt eine Skizze des

angestrebten Demonstrationsmodells.

Abbildung 6-2: Skizze des angestrebten Demonstrationsmodells für ein RFID-basiertes BMS


103

6.2.2 Anforderungen an das System

Ein IT-gestütztes BMS soll die Möglichkeit bieten, Transportaufträge der Behälter

anzulegen, zu überwachen bzw. zu quittieren. Idealerweise sollen Behälterbewegun-

gen in Echtzeit erfasst werden, um die Informationsflüsse mit den Behälterflüssen zu

synchronisieren. Um das zu erreichen, wird RFID im System eingesetzt, das heißt,

jeder Behälter wird mit einem RFID-Transponder versehen und eindeutig identifiziert.

Zudem sollen Identifikationspunkte an wichtigen Logistikstellen wie Warenein- und –

ausgangszonen eingerichtet werden, um den Status der Transportaufträge automa-

tisch zu aktualisieren. Ein BMS soll außerdem in der Lage sein, Bestände der La-

dungsträger zu führen. Es soll transparent machen, welche Ladungsträger sich in

welcher Anzahl an welchem Standort befinden. Von Softwareanwendungen wird

erwartet, eine Behälterverfolgung zu ermöglichen. Dadurch kann unnötiger Behälter-

schwund vermieden werden und die Identifikation sowie die Lokalisierung von Be-

hältern vereinfacht werden. In der Lebensmittelindustrie ist es von großer Bedeutung,

Behälterzustand wie beispielsweise die Temperaturen im Behälter während des

Transports zu überwachen. Zusätzlich soll die Software die Möglichkeit bieten,

Stammdaten zu verwalten. Dabei sollen Anwender alle wichtigen Daten verschiede-

ner Ladungsträger eintragen und anpassen können. Ebenso sollen sich die Daten

der Behälterstandorte sich hinterlegen lassen.

Neben den oben genannten funktionalen Anforderungen sind noch einige techni-

sche Anforderungen zu berücksichtigen. Die Behälterflüsse werden im Rahmen die-

ser vorliegenden Arbeit, wie bereits im letzten Abschnitt erwähnt, durch ein De-

monstrationsmodell illustriert, um die Funktionalitäten des BMS anschaulich darzus-

tellen. Allerdings soll das BMS offene Schnittstellen nach außen bieten und unab-

hängig von der Demonstrationshardware aufgebaut werden, damit die Software mit

anderer RFID-Hardware in der Praxis benutzt werden kann. Zusätzlich soll das BMS

plattformunabhängig gestaltet werden und in verschiedenen Betriebssystemen ein-

setzbar sein. Des Weiteren wird EPCIS in diese Software integriert, um einerseits die

Integration des EPC-Netzwerkes zu illustrieren und andererseits das Tracking & Tra-

cing der Behälter zu vereinfachen, um das BMS zu optimieren. Letztendlich sollen

Nutzerfreundlichkeit und die Erweiterbarkeit des Systems bei der Entwicklung be-

rücksichtigt werden. In Tabelle 6-1 sind die oben diskutierten funktionalen und tech-

nischen Anforderungen zusammengefasst.


104

Tabelle 6-1: Funktionale und technische Anforderungen an das BMS

Funktionale Anforderungen

· Anlegen / Aktualisieren / Quittieren von Transportträgern

· RFID-basierte eindeutige Identifikation von Behältern

· Bestandsverwaltung

· Behälterverfolgung

· Zustandsüberwachung wie beispielsweise die Temperaturüberwachung

· Stammdatenverwaltung

Technische Anforderungen

· Plattformunabhängigkeit

· Offene Schnittstelle

· Hardwareunabhängigkeit

· Integration von EPCIS

· Nutzerfreundlichkeit

· Erweiterbarkeit

6.2.3 Aufbau des Systems

Nachdem die Anforderungen an das System feststehen wird im Folgenden be-

schrieben, wie das System aufgebaut ist.

Um die Plattformunabhängigkeit des Systems zu gewährleisten, wird das BMS als

Webanwendung umgesetzt. Dadurch ist keine Installation auf Client-Geräten not-

wendig, da alle Funktionalitäten der Software über Webbrowser angezeigt und be-

nutzt werden. Die Software wird mit Java implementiert und als konkrete Technolo-

gie kommt Spring1 in Kombination mit Hibernate2 zum Einsatz, welche eine effiziente

Entwicklung von Webanwendungen ermöglichen. Als Datenbanksystem wird das

Open-Source System MySQL von Oracle verwendet. Zur Implementierung der EP-

1 Spring ist ein Open-Source-Framework für Java. Es hat zum Ziel, ein leichtgewichtiges Applikati-onsframework anzubieten und die Komplexität der Entwicklung von Java-Anwendungen zu redu-zieren (Siehe: http://www.springsource.org).

2 Hibernate ist auch ein Open-Source-Framework für Java. Seine Hauptaufgabe besteht darin, das Object-Relational Mapping (ORM) zu realisieren. Dies ermöglicht es Entwicklern, mit Datenbankin-halten objektorientiert zu arbeiten (Siehe: http:// www.hibernate.org).


105

CIS wird weiterhin die Open-Source-Plattform Fosstrak eingesetzt, die die offenen

Schnittstellen von EPCIS bereits standardkonform implementiert und zur Verfügung

stellt, was die Erfassung sowie die Abfrage der EPCIS-Ereignisse vereinfacht (vgl.

Kapitel 5.3.1).

Zur Entwicklung des Demonstrationsmodells kommt Lego Mindstorms NXT 2.0 zum

Einsatz. Lego Mindstorms ist eine programmierbare Produktserie des dänischen

Spielwarenherstellers Lego. Mit einem Mikrokontroller-basierten Legostein (NXT)

sowie Elektromotoren, Sensoren und Lego-Technik-Teilen (Zahnrädern, Förderbän-

dern, Achsen usw.) bietet Lego Mindstorms eine ideale Lösung für den Aufbau des

Demonstrationsmodells. Um eine flexible Programmierung der Bausteine zu ermög-

lichen, wird anstelle der vorinstallierten Lego Firmware die Open-Source Alternative

leJOS verwendet. LeJOS bietet die Möglichkeit, die Legosteine mit Java zu prog-

rammieren. Dadurch können einerseits verschiedene Funktionalitäten des Systems

flexibel eingesetzt und andererseits der Datenaustausch mit außenstehenden Kom-

ponenten oder Softwares ermöglicht werden.

Das Modell enthält drei Stationen, die über einen LKW Behälter untereinander ver-

schicken können. Jede Station besteht aus einem NXT Baustein zur Steuerung und

einem Lager, mit zwei Förderbändern. Dadurch können Behälter automatisch ein-

bzw. ausgelagert werden. Abbildung 6-3 zeigt das fertiggestellte Demonstrations-

modell. Die Einzelheiten zu seinem Aufbau werden in Kapitel 6.3.5 noch näher be-

trachtet.

Zum Demonstrationszweck werden Behälterflüsse durch das Lego-Modell illustriert.

Das BMS kann prinzipiell mit anderen RFID-Hardwares interagieren, da die Kommu-

nikation nach außen per Webservice-basierter Schnittstelle erfolgt. Weiterhin wird

die Funktion implementiert, Transportaufträge manuell zu bestätigen. Dadurch kann

das BMS auch ohne Hardwareanbindung benutzt werden.


106

Abbildung 6-3: Das Lego-basierte Demonstrationsmodell

6.2.4 IT-Landschaft des Systems

Schematisch lässt sich die gesamte Systemlandschaft wie in Abbildung 6-4 illust-

riert darstellen.

Der Zentralserver, der die Aufgabe hat, die Geschäftslogik zur Abwicklung der

Transportaufträge sowie anderer Funktionalitäten des BMS zu implementieren, bie-

tet das Kernstück des BMS. Zudem enthält er die Frontend-Daten zur Darstellung

der Weboberfläche und die Zugriffslogik auf die Datenbanken, die BMS-Datenbank

und das integrierte EPCIS-Repository.


107

Abbildung 6-4: Gesamte Systemlandschaft des BMS

Zur Steuerung des Demonstrationsmodells und der Kommunikation mit dem BMS

wurde für jede Station ein StationServer implementiert, der die versendeten Kom-

mandos über die USB-Verbindung an die Hardware weiterleitet und sich beim Zent-

ralServer wieder zurückmeldet. Die erfassten RFID-Daten werden auch hier über die

Webservice-Schnittstelle an den Zentralserver zur Weiterverarbeitung geschickt.

In Abbildung 6-5 ist das Konzept zur Integration des EPC-Netzwerkes in das BMS

dargestellt.

Abbildung 6-5: Integration des EPC-Netzwerkes in das BMS


108

Um die Integration zu ermöglichen, spielt das Middleware, wie in Kapitel 6.2 bereits

vorgestellt, eine entscheidende Rolle. Die RFID-Daten werden durch RFID-Reader

erfasst und an das Edgeware bzw. das Middleware weitergegeben. In dem demons-

trierten System übernehmen die einzelnen StationServer die Aufgabe der Edgeware

und der ZentralServer die Aufgabe der Middleware. Die Middleware verknüpft einer-

seits die EPC-Nummer mit den Kontextinformationen wie der Erfassungszeit und

dem Erfassungsort und leitet die Daten in geeigneter Form an das EPCIS-Repository

weiter. Andererseits kommuniziert sie mit dem BMS-Backbone, damit der Status der

Transportaufträge aktualisiert wird. Die Integration von EPCIS ermöglicht eine ver-

besserte Tracking & Tracing der Behälter, allerdings werden die anderen Funktionali-

täten wie die Abwicklung der Transportaufträge und die Stammdatenverwaltung in

dem BMS-Backbone realisiert. Für den Aufbau des Systems wurde der Einfachheit

halber ein zentrales EPCIS-Repository eingesetzt. In der Praxis kann man allerdings

nach Bedarf auch verteilte EPCIS bei den einzelnen Standorten aufbauen. Für unter-

nehmensübergreifendes Tracking & Tracing kommt der Rückverfolgungsdienst auch

zum Einsatz, der in Kapitel 5 und 6 diskutiert wurde.

6.2.5 Aufbau des Demonstrationsmodells

Um die Behälterflüsse nicht nur in der Software, sondern auch „zum Anfassen“ zu

veranschaulichen, wurde ein Demonstrationsmodell, wie bereits in Kapitel 6.2.3 vor-

gestellt, mittels Lego implementiert. Das Demonstrationsmodell besteht aus drei

Stationen, die untereinander Behälter transportiert von einem LKW verschicken kön-

nen. Das Modell wurde modular aufgebaut und daher ist ein Hinzunehmen weiterer

Stationen durch Konfigurationsänderungen ohne große Änderung der Programmier-

codes möglich.

Der Aufbau jeder einzelnen Station ist in Abbildung 6-6 angegeben. Das Kernstück

jeder Station bildet der Lego-Baustein NXT, der über vier Eingänge für Sensoren und

drei Ausgänge für Motoren verfügt. Die Motoren werden verwendet, um zwei För-

derbänder zu steuern und dadurch Behälter automatisch ein- bzw. auszulagern. Die

vier Sensoren werden in Abbildung 6-6 mit Nummern markiert und im Folgenden

vorgestellt.

1. Infrarotsensor

Der Infrarotsensor wird benutzt, um den LKW zu steuern. Der Sensor besteht aus

einem IR-Sender und einem Infrarot-Empfänger. Der LKW wurde durch Umbau

aus einem Lego-City-Zug gefertigt und verfügt über einen Infrarot-Empfänger.


109

Durch die Infrarot-basierte Kommunikation kann der LKW gestartet und gestoppt

werden. Die Fahrgeschwindigkeit kann so ebenfalls reguliert werden.

2. Ultraschallsensor

Der Ultraschallsensor dient dazu, den LKW zu detektieren. So kann geprüft wer-

den, ob sich der LKW vor der Station befindet. Durch Kombination mit dem Infra-

rot-Sensor kann der LKW an geeigneten Stellen in Bezug auf entsprechende

Transportaufträge gestartet und gestoppt werden. Des Weiteren kann der Lade-

vorgang erst beginnen, wenn der LKW vor der Station hält.

3. RFID-Sensor

Zur Identifikation der Behälter kommt RFID zum Einsatz. Dabei wird der RFID-

Sensor, der von einem Dritthersteller für Lego-Mindstorms produziert wird, ver-

wendet. Er arbeitet im LF-Bereich und jeder dazugehörige RFID-Transponder

besitzt eine ID-Nummer mit sechs Bytes. Der Grund für die Auswahl des Sensors

liegt darin, dass er einerseits einfach in den NXT zu integrieren ist, und er ande-

rerseits eine kleine Lesereichweite hat, was das Lesen von ungewünschten

Transpondern bei anderen Stationen im Demonstrationsmodell vermeidet. Es ist

allerdings anzunehmen, dass in der Praxis UHF-RFID eingesetzt wird und jeder

Behälter eine EPC-Nummer besitzt. Für die Demonstration wird daher software-

seitig jede ID-Nummer in eine EPC-Nummer gewandelt.

4. Farbsensor

Zu Demonstrationszwecken wird an jeder Station ein Farbsensor eingesetzt, der

dazu dient zu bestimmen, ob der Inhalt des Behälters während des Transportes

zu warm wurde. Dazu repräsentiert rot defekte (warm) und blau intakte (kalt) Be-

hälter. Je nach Farbe werden entsprechende Temperaturdaten während des

Transports im System simuliert. Es wird davon ausgegangen, dass die Tempera-

turdaten in der Praxis durch integrierte Sensoren im RFID-Transponder an jedem

Behälter aufgezeichnet werden.


110

Abbildung 6-6: Aufbau der Lego-Station

6.2.6 Interaktion zwischen BMS und dem Demonstrationsmodell

Die Interaktion zwischen BMS und Lego-Modell bzw. die Abwicklung der Transport-

aufträge sind in Abbildung 6-6 illustriert.

Nach Erhalt eines Transportauftrags fährt der LKW zur Ausgangsstation. Sobald der

LKW angekommen ist, beginnt der Warenausgangsprozess. Jeder zu transportie-

rende Behälter wird bei der Warenausgangszone durch einen RFID-Reader gelesen

und gleichzeitig wird ein EPCIS-Ereignis zum ZentralServer geschickt. Parallel dazu

ändert sich der Zustand des Transportauftrags von „vorgemerkt“ zu „Warenaus-

gang“. Nachdem alle Behälter auf den LKW geladen sind, startet der LKW durch

eine Anweisung des Benutzers und fährt zur Zielstation. Der Zustand des Auftrags

wird entsprechend auf „versendet“ aktualisiert. Ist der LKW angekommen, werden

die Behälter entladen und zur Wareeingangszone der Zielstation gebracht. Im War-

eneingangsprozess werden die Behälter wiederum durch einen RFID-Reader erfasst

und dabei entsprechende Leseereignisse erzeugt. Der Transportauftragsstatus än-

dert sich zu „Wareneingang“. Sind alle Behälter richtig und vollständig eingelagert,

ist der Transportauftrag abgeschlossen.

1

3

2

4

3

3


111

Abbildung 6-7: Abwicklung der Transportaufträge

6.2.7 Funktionalitäten des BMS

Im letzten Teil des Kapitels werden die gesamten Funktionalitäten des BMS jeweils

durch Screenshots angezeigt und erklärt.

Insgesamt bietet die entwickelte BMS-Software folgende Funktionalitäten:

· Transportauftragsverwaltung

· Bestandsverwaltung

· Tracking & Tracing

· Temperaturüberwachung

· Stammdatenverwaltung: Behälterdaten/Standortdaten

Abbildung 6-8 zeigt die Startseite des RFID-basierten BMS. In der Leiste links sind

die verschiedenen Funktionalitäten des BMS aufgelistet. Neben den allgemeinen

Informationen zur Software besteht hier noch die Möglichkeit, die Sprache zwischen

Deutsch und Englisch umzuschalten.


112

Abbildung 6-8: Startseite des BMS

Transportauftragsverwaltung

Mit der Software können Benutzer Transportaufträge anlegen, überwachen bzw.

verfolgen. In der Transportauftragsübersicht erhalten Benutzer einen Überblick über

alle laufenden und abgeschlossenen Transportaufträge (Abbildung 6-9). Dabei wer-

den die Details der Transportaufträge wie die Ausgangsstation, die Zielstation, der

aktuelle Zustand, die Anzahl der transportierten Behälter, der Behältertyp sowie der

Füllstand angezeigt. Der Zustand des Transportauftrags wird durch RFID-Erfassung

der Behälter am Warenein- und –ausgang automatisch aktualisiert. Weiterhin be-

steht die Möglichkeit, den Zustand manuell durch Klick auf ein kleines Häkchen in

der Spalte rechts zu aktualisieren. Dadurch kann die Software auch verwendet wer-

den, wenn RFID nicht eingesetzt wird oder nicht funktioniert.

Das Anlegen eines neuen Transportauftrags ist in Abbildung 6-10 dargestellt. Durch

Klick auf „neuen Transportauftrag anlegen“ öffnet sich ein Dialogfenster, wo der Be-

nutzer aufgefordert wird, die Ausgangsstation und die Zielstation auszuwählen. Zu-

dem soll der Typ, die Anzahl und der Füllstand der zu transportierenden Behälter

angegeben werden. Der Füllstand kann zwischen Vollgut und Leergut gewählt wer-

den.

Durch Klick auf die Transportauftragsnummer öffnet sich ein Dialogfenster, das dem

Benutzer einen Überblick über den Status und die Uhrzeit aller Bearbeitungsschritte

des Transportauftrags bietet (Abbildung 6-11).


113

Abbildung 6-9: Transportauftragsübersicht

Abbildung 6-10: Anlegen von neuen Transportaufträgen

Manuelle Zustandsän-derung möglich

Aktueller Zustand des Transportauftrags


114

Abbildung 6-11: Bearbeitungsgeschichte eines Transportauftrags

Bestandsübersicht

Unter „Bestandsübersicht“ können Behälterbestände an verschiedenen Lagerorten

(Stationen) abgefragt werden. Dazu wählt der Benutzer zuerst die gewünschte Stati-

on aus. Durch Klick auf „Abfrage ausführen“ erhält der Benutzer eine Übersicht über

alle an dieser Station vorhandenen Behälter. Dabei werden sowohl die Anzahl als

auch Zustand und Typ der Behälter angezeigt (Abbildung 6-12).

Abbildung 6-12: Bestandsübersicht


115

Tracking & Tracing

Unter „Tracking & Tracing“ kann der Benutzer die integrierte EPCIS-Datenbank ab-

fragen, um eine Übersicht über die „Was, Wann, Wo, Warum“ Informationen des

betreffenden Behälters zu erhalten. Dazu wählt der Benutzer zunächst die EPC-

Nummer des Behälters (GRAI) aus. Zusätzlich kann der Zeitraum der Datenabfrage

weiter eingegrenzt werden. Durch Klick auf „Abfrage ausführen“ werden die EPCIS-

Daten angezeigt. Dazu gehören das Datum, das bizStep und das bizLocation des

Events. Des Weiteren werden die Transportnummer und der Füllstand mit dargestellt.

Für Vollgut-Transporte findet der Benutzer auch die NVE, welche die Behälter mit

den transportierten Waren verknüpft und daher eine Nachverfolgung von Waren er-

möglicht (Abbildung 6-13).

Abbildung 6-13: Tracking & Tracing der Behälter durch EPCIS

Temperaturüberwachung

Für Vollgut-Transporte in der Kühlkette macht es Sinn, die Temperaturen in jedem

Behälter während des Transports durch RFID-Logger aufzuzeichnen. Die

Temperaturdaten werden in Form erweiterter Attribute im EPCIS-Repository

gespeichert und stehen für spätere sicherheitbezogene Nutzung und Kontrolle zur

Verfügung. Nach Auswahl des gewünschten Transportauftrags und Klick auf

„Abfrage ausführen“ werden die Temperaturdaten jedes Behälters innerhalb des

Transportauftrags angezeigt und visualisiert. Beim Überfahren der Erfassungspunkte

in den Temperaturkurven mit der Maus werden die Informationen detailiert

dargestellt. Dazu gehören der Erfassungszeitpunkt, der EPC des Behälters und der

genaue Temperaturwert (Abbildung 6-14).


116

Abbildung 6-14: Temperaturüberwachung

Stammdatenverwaltung

Das BMS bietet Benutzern die Möglichkeit, Stammdaten inklusive Behälterdaten

und Stationsdaten flexibel zu verwalten. Unter „Behälterdaten“ kann der Benutzer

nicht nur neue Behälter anlegen, sondern auch die Daten vorhandener Behälter an-

passen. Dazu gehören die EPC-Nummer des Behälters, der zugehörige Standort,

der Behältertyp, der Zustand (einwandfrei, defekt oder verschmutzt) sowie die Ab-

messungen des Behälters (Abbildung). Unter „Stationsdaten“ werden die Daten der

Behälterstandorte verwaltet. Dazu kann der Benutzer sowohl neue Standorte anle-

gen, wie auch Änderung für vorhandene Standorte nach Klick auf ihre Namen vor-

nehmen (Abbildung 6-15).

Abbildung 6-15: Stammdatenverwaltung - Behälterdaten

Fazit

117

Abbildung 6-16: Stammdatenverwaltung - Stationsdaten

6.3 Fazit

Das EPC-basierte Netzwerk bietet die Möglichkeit, Auto-ID-Daten standardisiert

auszutauschen und somit die Transparenz bzw. die Rückverfolgbarkeit in der Le-

bensmittel-Supply-Chain zu erhöhen. Allerdings macht das Netzwerk nur Sinn, wenn

es sich in vorhandene/andere IT-Landschaften integrieren lässt. In diesem Kapitel

wurde vorgestellt, wie die Integration erfolgen kann. Dafür wurde beispielhaft ein

RFID-basiertes BMS entwickelt. Das System bietet offene Kommunikationsschnitt-

stelle und kann daher nicht nur mit dem Demonstrationsmodells, sondern auch mit

anderer RFID-Hardware angeschlossen werden. Die Voraussetzung dafür ist, dass

die Middleware entsprechend der eingesetzten RFID-Technologie angepasst ist.

Die in dieser Arbeit entwickelten Funktionalitäten des BMS können in der Praxis

nach Bedarf erweitert werden. Beispielsweise können in der Software Funktionen für

die Verrechnung von Behältermieten eingesetzt werden. Eine genaue Ortung der

Behälter innerhalb eines Standortes durch beispielsweise das Mojix-System ist

denkbar.


118

Zusammenfassung

119

7 Zusammenfassung und Ausblick

7.1 Zusammenfassung

Ohne Nahrung können die Menschen nicht leben. Die Lebensmittelindustrie gehört

daher zu den bedeutendsten und größten Industriebranchen. Allein in Europa be-

schäftigt die Lebensmittelindustrie mehr als vier Millionen Menschen in rund 310 000

Unternehmen [Man-13]. Wegen des großen Konkurrenzdrucks sind viele Unterneh-

men heute gezwungen, nach innovativen Lösungen zur Optimierung ihrer Produkti-

ons- und Logistikprozesse zu suchen, um sich dadurch Wettbewerbsvorteile zu si-

chern. Die Verbesserung der Informationslogistik ist hier von großer Bedeutung.

Im Vergleich zu anderen Branchen stellt die Lebensmittelindustrie höchste Anforde-

rungen an Produktsicherheit und –qualität. Lebensmittelskandale in den letzten Jah-

ren haben massive Umsatzeinbußen und einen Imageschaden der Lebensmittelin-

dustrie verursacht und die Verbraucher zutiefst verunsichert. Anhand von Lebens-

mittelkrisen lässt sich erkennen, dass ein effizientes Rückverfolgbarkeitssystem und

eine verbesserte Informationstransparenz eine entscheidende Rolle spielen, um ei-

nen schnellen und gezielten Warenrückruf zu ermöglichen, um das Ausmaß von Le-

bensmittelkrisen einzuschränken bzw. zu verhindern.

Viele Unternehmen haben zwar Rückverfolgbarkeitssysteme eingerichtet, die Doku-

mentation sowie die Informationsweitergabe finden bei vielen Systemen noch in Pa-

pierform statt, was zu Fehlern und Zeitverlust bei der Problemsuche und bei Rück-

rufaktionen führt. Des Weiteren macht die Vielfalt der Systeme die Verkettung von

Informationen über die gesamte Lieferkette zusätzlich schwierig.

Die Auto-ID-Technologie vor allem die RFID-Technologie besitzt enormes Potential,

die Rückverfolgbarkeit und damit die Transparenz sowie die Prozesseffizienz in der

Lebensmittel-Supply-Chain zu steigern. Wie bei vielen anderen Technologien ist die

Entwicklung einheitlicher Standards eine entscheidende Voraussetzung für eine wei-

te Verbreitung des Auto-ID-Einsatzes. Im Vergleich zu Barcode ist die Standardisie-

rung bei RFID noch unzureichend umgesetzt, was die Implementierung kettenüber-

greifende Anwendungen erschwert.

Das im Rahmen dieser Arbeit konzipierte Datennetzwerk hat zum Ziel, den oben ge-

nannten Problemen zu begegnen. Der Elektronische Produktcode (EPC) wurde als

Nummernsystem eingesetzt, was die Basis für den Aufbau des gesamten Netzwer-

kes bildet.


120

Zum Aufbau des Datennetzwerkes spielt der Einsatz des EPC Information Service

(EPCIS) eine zentrale Rolle. EPCIS hat die Aufgabe, erfasste Auto-ID-Daten mit Pro-

zesskontexten zu verknüpfen, in standardisierter Form abzuspeichern und zu High-

Level-Anwendungen zur Verfügung zu stellen. Somit kann einerseits der Austausch

von Auto-ID-Daten zwischen Geschäftspartnern erleichtert und andererseits die

Transpanrenz in der Lieferkette erhöht werden. In dieser Arbeit wurde daher der Ein-

satz des EPCIS-Standards in der Lebensmittel-Supply-Chain näher betrachtet. Da-

bei wurde die einzusetzenden EPCIS-Ereignistypen, -Attributen und –

Vokabelelemente sowie ihre Erweiterungsmöglichkeiten in der Lebensmittel-Supply-

Chain jeweils diskutiert und vorgeschlagen. Es folgte eine Darstellung des Mapping

zwischen Identifikationspunkten und den zu erfassenden EPCIS-Ereignisse anhand

eines Beispielsszenarios. Da die EPCIS-Spezifikation ein offener Standard ist und je

nach Branche und Anwendungsgebiet anzupassen ist, kann diese Arbeit einen Bei-

trag dazu leisten, die Anwender bei der Implementierung von EPCIS in der Lebens-

mittelbranche anzuleiten bzw. ihnen Hilfestellungen zu bieten.

Um kettenübergreifendes Tracking & Tracing zu ermöglichen, wurde im Rahmen

dieser Arbeit ein Rückverfolgungsdienst konzipiert. Der Rückverfolgungsdienst baut

auf den Stand der Technik des Discovery Service auf und dient dazu, kettenüber-

greifende EPCIS-Daten zu entdecken bzw. zu verketten, welche die Rückverfolgbar-

keit und die Transparenz in der Lebensmittel-Supply-Chain erhöhen.

Das in dieser Arbeit erstellte Konzept wurde in einer simulierten Umgebung imple-

mentiert, um ein „Proof of Concept“ zu erstellen. Das aufgebaute Informationssys-

tem besteht aus mehreren EPCIS-Instanzen, einem Rückverfolgungsdienst sowie

einer Clientapplikation, in der die Benutzerabfragen abgeschickt und die Ergebnisse

visualisiert werden. Das System ermöglicht den Benutzern, Objekte in der Lebens-

mittelkette effizient zu verfolgen und die „Wann, Was, Wo, Warum“ Informationen

über die Objekte auf einzelnen EPCIS-Servern zu ermitteln. Da das System auf loka-

len Rechnern implementiert wurde, wurde die mögliche Netzwerkverzögerung auch

simuliert und damit die Machbarkeit des Systems validiert.

Das Ziel des EPC-Netzwerkes liegt darin, vorhandene/andere IT-Landschaften zu

ergänzen statt zu ersetzen. Dafür wurde im Rahmen dieser Arbeit ein RFID-basiertes

Behältermanagementsystem (BMS) entwickelt, um die Integration zu verdeutlichen.

Mit Hilfe der umgesetzten Demonstratoren konnten das Konzept und die Erkenn-

tnisse dieser Arbeit dem Fachpublikum in Form von Liveführungen vorgestellt wer-

den. Eine Umsetzung des Konzepts in der Industrie setzt voraus, dass RFID zur ein-

deutigen Identifikation der Objekte in der Lebensmittelbranche umfassend einge-

setzt wird, was in der Zukunft durchaus vorstellbar ist.

Ausblick

121

7.2 Ausblick

Das EPC-basierte Datennetzwerk kann einen wichtigen Beitrag leisten, Auto-ID-

Daten unter kooperierenden Teilnehmern in der Wertschöpfungskette auf einem

standardisierten Weg auszutauschen, um die Rückverfolgbarkeit und somit die

Transparenz in der Lebensmittel-Supply-Chain zu steigern. Vor einem verbreiteten

Industriellen Einsatz des Datennetzwerkes sind diverse Herausforderungen zu be-

wältigen.

So ist zunächst eine raffinierte Sicherheits-Infrastruktur zu gestalten, um die Gefahr

des Missbrauchs sensibler Unternehmensdaten zu vermeiden. Ein differenziertes

Recht- und Rollenkonzept mit einer klaren Definition, welche Teilnehmer auf welche

Daten Zugriff haben und wer welche Daten zu welchen Objekten im Rückverfol-

gungsdienst hinterlegen darf, bedarf der Entwicklung.

Wie bei vielen anderen Technologien besteht auch hier die Notwendigkeit, eine Kos-

ten-Nutzen-Analyse vor Einführung des Netzwerks durchzuführen. Zugleich ist dafür

Sorge zu tragen, eine Kosten-Nutzen-Ungleichheit zu vermeiden. Hierfür sollen ent-

sprechende Verfahren oder Modelle entwickelt werden, mit denen die Verteilung der

Kosten mit der Nutzung der Informationen gekoppelt werden kann.

Das EPC-Nummernsystem wird von GS1 betrieben und verwaltet. Es ist zu erwarten,

dass das Netzwerk wirtschaftlich neutral eingesetzt und nicht monopolisiert wird,

um mehr Unternehmen zu motivieren, sich am Netzwerk zu beteiligen.

Im Rahmen dieser Arbeit werden schwerpunktmäßig die Logistikprozesse in der Le-

bensmittel-Supply-Chain betrachtet. Bei zukünftiger Forschung könnten Produkti-

onsprozesse mitberücksichtigt werden, um das Konzept zu erweitern.

Das in dieser Arbeit konzipierte EPC-basierte Datennetzwerk ist prinzipiell auf ande-

re Anwendungsgebiete und Branchen übertragbar. In der Praxis ist der Einsatz von

EPCIS je nach Prozess und Identifikationskonzept zu adaptieren. Zudem ist eine

eindeutige Identifikation auf Produktebene möglich, je nachdem, in welcher Branche

das Netzwerk eingesetzt wird. In diesem Fall ist das Konzept entsprechend zu er-

weitern, wie beispielsweise die Abfrage- und Aggregationslogik des Rückverfol-

gungsdiensts. Ein industrieller Einsatz setzt des Weiteren die Etablierung einer ge-

meinsamen Sprache wie z.B. die Verwendung von EPCIS-Vokabelelemente durch

alle Beteiligte voraus, um einen effizienten Datenaustausch zu gewährleisten und

somit unternehmensübergreifende Anwendungen zu ermöglichen.


122

123

Literaturverzeichnis

[aer-11] aerzteblatt.de: Deutsche Bauern fordern wegen EHEC-Krise 16 Millionen Euro, 2011. URL: http://www.aerzteblatt.de/nachrichten/46677/Deutsche-Bauern-fordern-wegen-EHEC-Krise-16-Millionen-Euro (Aufruf am 02.12.2013).

[Bec-08] Bechini, A.; Cimino, M.; Marcelloni, F.; Tomasi, A.:

Patterns and technologies for enabling supply chain traceability through collaborative e-business. In: Information and Software Technology, Jg. 50 (2008)4, S. 342–359.

[Bei-06] Beier, S.; Grandison, T.; Kailing, K.; Rantzau, R.:

Discovery Services—Enabling RFID Traceability in EPCglobal Net-works. In: International Conference on Management of Data, COM-AD 2006. Delhi, India, 2006.

[Bot-08] Bottani, E.:

Reengineering, simulation and data analysis of an RFID system. In: Journal of Theoretical and Applied Electronic Commerce Re-search, Jg. 3 (2008) 1, S. 13–29.

[BRI-07a] BRIDGE: Supply Chain Management in the European Textile industry - Textile Industry Requirements, 2007.

[BRI-07b] BRIDGE: High level design for Discovery Services, 2007.

[BRI-08] BRIDGE: WP06 - Pilot Deployment Report. Herausgegeben von: BRIDGE, 2008.

[BRI-09] BRIDGE: Buiding Radio Frequency Identification Solutions for the Global Envi-ronment. Herausgegeben von: BRIDGE, 2006-2009. URL: http://www.bridge-project.eu/

[Bro-12] Brooks Automation GmbH: RFID Lesegerät, 2012. URL: http://www.brooks-rfid.com/rfid-lesegeraet.html (Aufruf am 15.11.2012).


124

[Buc-11] Buck, T.:

Wirtschaftlichkeitsvergleich zwischen RFID vs. WBS für eine Hallen-neuplanung in der Logistik. Studienarbeit,Hochschule Furtwangen, 2011.

[Bun-05] Bundesministerium für Bildung und Forschung (BMBF):

RFID in der Logistik - Chancen für den Standort Deutschland, 2005.

[Bux-06] Buxmann, P.; Steinmetz, R.: Interoperabilität und IT-Integration. In: Wirtschaftsinformatik, Jg. 48 (2006)3, S. 153.

[CAE-12] CAEN RFID:

A927Z Temperature Logger UHF Semi-Passive Tag, 2012. URL: http://www.caenrfid.it/en/CaenProd.jsp?idmod=781&parent=65 (Aufruf am 27.11.2012).

[Cha-08] Chang, M.; Cheung, W. C.; Cheng C.H.; Yeung, H.: Understanding ERP system adoption from the user's perspective. In: International Journal of Production Economics, Jg. 13 (2008)2, S. 928–942.

[Cla-06] Clasen, M.: Das EPCglobal-Netzwerk – Ein Werkzeug zur Rückverfolgung in Echtzeit. In: elektronische Zeitschrift für Agrarinformatik eZAI, Jg. 1 (2006) 1, S. 3–15.

[DHL-07] DHL Innovation Center: Der Megatrend als mögliche Revolution der Logistik, 2007. URL: http://www.dhl-discoverlogis-tics.com/cms/de/course/technologies/connection/rfid.jsp (Aufruf am 21.11.2012).

[DIE-13] DIE WELT: Fleischskandal betrifft Deutschland flächendeckend, 2013. URL: http://www.welt.de/wirtschaft/article115201703/Fleischskandal-betrifft-Deutschland-flaechendeckend.html (Aufruf am 02.12.2013).

[Din-08] Dinter, B.; Winter, R.:

Integrierte Informationslogistik. Berlin: Springer, 2008.

[Dru-12] Druckerdoktor GmbH: Nummer der Versandeinheit, 2012. URL: http://www.druckerdoktor.de/NVE.htm (Aufruf am 06.11.2012).


125

[Ele-12] Electronic Commerce Network:

Standardisierung der RFID Systeme, 2012. URL: http://www.ec-net.de/EC-Net/Navigation/Themen/radiofrequenz-identifikation,did=260932.html (Aufruf am 06.12.2012)

[EPC-06] EPCglobal: EPC Pilotprojekte. Herausgegeben von: GS1, 2006.

[EPC-07] EPCglobal: EPC Information Services (EPCIS) Version 1.0.1 Specification. He-rausgegeben von: GS1, 2007.

[EPC-09a] EPCglobal: The EPCglobal Architecture Framework - Final Version 1.3. Heraus-gegeben von: EPCglobal, 2009.

[EPC-09b] EPCglobal: EPC-Informationsservices (EPCIS) und Umsetzung im EPC-Showcase. Herausgegeben von: GS1, 2009.

[EPC-10] EPCglobal: Core Business Vocabulary Standard. Herausgegeben von: GS1, 2010.

[EPC-11] EPCglobal:

EPC Tag Data Standard. Herausgegeben von: GS1, 2011.

[EPC-12] EPCglobal: EPCglobal Homepage. Herausgegeben von: EPCglobal, 2012. URL: http://www.gs1.org/epcglobal (Aufruf am 02.09.2012).

[Eur-02] Europäische Union: Die Verordnung (EG) Nr. 178/2002 des Europäischen Parlamentes und des Rates zur Festlegung der allgemeinen Grundsätze und An-forderungen des Lebensmittelrechts, zur Errichtung der Europä-ischen Behörde für Lebensmittelsicherheit und zur Festlegung von Verfahren zur Lebensmittelsicherheit. In: Europäische Union, 2002.

[Far-09] Farjah, M.: Flächendeckende Erfassung durch RFID, 2009. URL: http://www.rfid-im-blick.de/20091125423/flaechendeckende-erfassung-durch-rfid.html (Aufruf am 02.09.2012).

[Fea-99] Fearne, A.; Hughes D.: Success factors in the fresh produce supply chain: insights from the UK. In: Supply Chain Management: An International Journal, Jg. 4 (1999)3, S. 120–131.


126

[Fed-07] Federal Ministry of Economics and Technology:

Abschlussdokument 'European Policy Outlook' der Konferenz der Deutschen Ratspräsidentschaft 2007, Towards the Internet of Things, 2007.

[Fin-06] Finkenzeller, K.: RFID-Handbuch - Grundlagen und praktische Anwendungen induk-tiver Funkanlagen, Transponder und kontaktloser Chipkarten. 4. Auflage. München [u.a.]: Hanser, 2006.

[FML-12a] FML: Skript zum Praktikum “ERP-Systeme am Beispiel SAP“. Lehrstuhl fml, Maschinenwesen, Technische Universität München, 2012.

[FML-12b] FML: RFID-Systeme am Lehrstuhl fml. Lehrstuhl fml an der Technische Universität München. Garching, 2012. URL: http://www.fml.mw.tum.de/fml/index.php?Set_ID=371 (Aufruf am 15.11.2012).

[FML-13] FML: Das Mojix-STAR-System - FML Grafikpool, 2013.

[FOR-11] FORFood: Zwischenbericht des Teilprojekts 6 "Sichere und effiziente Supply-Chain in der Lebensmittelindustrie durch einen Intelligenten Behäl-ter" im Forschungsverbund FORFood. Herausgegeben von: Lehr-stuhl fml an der Technische Universität München, 2011.

[Fos-13] Fosstrak: fosstrak - Open Source RFID Platform, 2013. URL: www.fosstrak.org (Aufruf am 12.06.2013).

[Fri-10] Friedewald, M.:

Ubiquitäres Computing - Das "Internet der Dinge" - Grundlagen, Anwendungen, Folgen. Berlin: edition sigma, 2010.

[Fru-12] Fruth, A.: Methodik für die Durchführung von RFID-Implementierungsprojekten in der Logistik bei mittelständischen Unternehmen. Dissertation; Lehrstuhl fml, Technische Universität München. Garching, 2012. Be-treut durch Günthner, W. A.

[Gab-10] Gabriel, P.; Gaßner, K.; Lange, S.: Das Internet der Dinge - Basis für die IKT-Infrastruktur von morgen, 2010.


127

[Gam-06] Gampl, B.:

Rückverfolgbarkeit von Lebensmitteln. 1 Auflage. Göttingen: Cuvil-lier, 2006.

[Ghi-01] Ghisi, F.; Silva, A.: The information technology on food supply chain management. In: The information technology on food supply chain management, 2001, S. 169.

[Gil-07] Gillert, F.; Hansen, W.-R.: RFID für die Optimierung von Geschäftsprozessen - Prozess-Strukturen, IT-Architekturen, RFID-Infrastruktur. München [u.a.]: Hanser, 2007.

[Gro-10] Gronau, N.: Enterprise resource planning - Architektur, Funktionen und Mana-gement von ERP-Systemen. 2 Auflage. München: Oldenbourg, 2010.

[GS1-12a] GS1 US: 2015 Readiness Pilots - Preparing for serialization and visibility with-in the U.S. pharmaceutical supply chain. Herausgegeben von: GS1 US, 2012. URL: http://www.gs1us.org/industries/healthcare/gs1-healthcare-us/2015-readiness-pilots

[GS1-12b] GS1:

EPC/RFID – Die Zukunft hat begonnen. Herausgegeben von: GS1 Germany, 2012.

[Gum-06] Gumbrecht, A.; Banzer, F.: Einführung eines Behältermanagementsystems, 2006. URL: http://www.banzer.info/downloads/behaeltermanagement.pdf (Auf-ruf am 23.06.2013).

[Gun-11] Gunnlaugsson, V. N.; Thakur, M.; Foras, E.; Ringsberg, H.; Gran-Larsen, Ø.; Margeirsson, S.: EPCIS standard used for improved traceability in the redfish value chain. In: 13th International Conference on Modern Information Technology in the Innovation Processes of industrial enterprises (MITIP 2011). Trondheim, Norwegen, 22 – 24 Jun. 2011.

[Gün-07] Günthner, W. A.; Heptner, K.: Technische Innovationen für die Logistik. 1 Auflage. München: Huss, 2007.


128

[Gün-11a] Günthner, W. A.; Borrmann, A.:

Digitale Baustelle - innovativer Planen, effizienter Ausführen - Werk-zeuge und Methoden für das Bauen im 21. Jahrhundert. Heidelberg, New York: Springer, 2011.

[Gün-11b] Günthner, W. A.; Atz, T.; Klaubert, C.; Salfer, M.: Forschungsbericht für Projekt "RFID-MachLog: Methodik für UHF-RFID-Machbarkeitsstudien". Herausgegeben von: Lehrstuhl fml an der Technische Universität München, 2011.

[Gün-12a] Günthner, W.: Förder- und Materialflusstechnik. Skript zur Vorlesung. Maschinen-wesen, Technische Universität München, 2012.

[Gün-12b] Günthner, W.: Materialfluss und Logistik. Skript zur Vorlesung. Maschinenwesen, Technische Universität München, 2012.

[Han-94] Hansen, H.-G.; Lenk, B.: Codiertechnik - Der Schlüssel zum Strichcode. 3., verb. Aufl., 4. Tsd. Auflage. Neuss: Ident-Verl., 1994.

[Heg-08] Hegewald, S.: Konzeption und Realisierung eines mehrseitig sicheren verteilten Auffindungsdienstes für Auto-ID-Anwendungen. Diplomarbeit; Lehr-stuhl für Rechnernetze, Technische Universität Dresden, 2008. Be-treut durch Dipl.-Medien-Inf. Eberhard Oliver Grummt.

[Hof-06] Hofmann, E.; Bachmann, H.: Behälter-Management in der Praxis - State of the Art und Entwick-lungstendenzen bei der Steuerung von Ladungsträgerkreisläufen ; [die St. Galler Behälter-Management-Studie]. Hamburg: Dt. Ver-kehrs-Verl., 2006.

[Hom-07] Hompel, M. t.; Schmidt, T.; Nagel, L.: Materialflusssysteme - Förder- und Lagertechnik ; mit 36 Tabellen. 3 Auflage. Berlin, Heidelberg, New York: Springer, 2007.

[Hri-07] Hribernik, K. A.; Schnatmeyer, M.; Plettner, A.; Thoben, K. D.: Application of the Electronic Product Code EPC to the Product Life-cycle of Electronic Products. In: EU RFID Forum 2007. Brussels, Belgium, 2007.


129

[Jan-04] Jansen, R.; et al.: Integration der Transpondertechnologie zur Erhöhung der Leistungs-fähigkeit der operativen Produktionssteuerung. Wissenschaftliche Schriftreihe, Heft 38,Technische Universität Chemnitz. Chemnitz, 2004.

[Kan-10a] Kandel, D.: RFID-Standard in der Lebensmittelbranche ist sinnvoll. Herausgege-ben von: RFID im Blick, 2010. URL: http://www.rfid-im-blick.de/20100601644/rfid-standard-in-der-lebensmittelbranche-ist-sinnvoll.html (Aufruf am 20.09.2012).

[Kan-10b] Kandel, D.: Forschungsvorhaben „SmaRTI" nimmt Fahrt auf. Herausgegeben von: RFID im Blick, 2010. URL: http://www.rfid-im-blick.de/20100924786/rewe-und-mars-kooperieren-in-rfid-projekt.html (Aufruf am 18.12.2012).

[Kel-07] Kelepouris, T. P. K. D. D.: RFID-enabled traceability in the food supply chain. In: Industrial Management & Data Systems, Jg. 107 (2007)2

[Kik-11] Kikidis, E.:

Mehr Lieferkettentransparenz durch EPCIS. In: Jahrbuch Logistik 2011, S. 89–94.

[Kla-12] Klaubert, C.: Entwicklung eines RFID-basierten Informations- und Kommunikati-onssystems für die Baulogistik. Dissertation; Lehrstuhl fml, Techni-sche Universität München. Garching, 2012. Betreut durch Günthner, W. A.

[Kon-11] Konradin Mediengruppe::

ERP Studie 2011: Einsatz von ERP-Lösungen in der Industrie, 2011.

[Kru-10] Krupp, M.; et al.: SimoBIT- Leitfaden Marktbarrieren & Geschäftsmodelle mobiler An-wendungen. Herausgegeben von: BMBF, 2010.

[Kür-08] Kürschner, C.; Condea, C.; Kasten, O.; Thiesse, F.: Discovery Service Design in the EPCglobal Network - Towards Full Supply Chain Visibility. In: Floerkemeier, C. (Hrsg): The Internet of things. Berlin, , New York: Springer, 2008, S. 19–34.

[Kur-12] Kurose, J. F.; Ross, K. W.: Computernetzwerke - Der Top-Down-Ansatz. 5 Auflage. München: Pearson Studium, 2012.


130

[Kut-08] Kutz, M.: RFID-Technologie: Einsatz und Implementierung in einem Handels-unternehmen. München: GRIN Verlag GmbH, 2008.

[Lau-10] Laudon, K. C.; Laudon, J. P.; Schoder, D.: Wirtschaftsinformatik - Eine Einführung. 2 Auflage. München, Bos-ton, Mass. [u.a.]: Pearson Studium, 2010.

[Leb-03] Lebensmittel Zeitung: Streit um Pflicht- und Kürprogramm Rückverfolgbarkeit. Herausge-geben von: Lebensmittel Zeitung, 2003. URL: http:// www.lebensmittelzeitung.net (Aufruf am 16.10.2003).

[Lie-11] Liebl Sabine; Woortman, V.: Rückverfolgbarkeit als Marketinginstrument. Seminararbeit; Fakultät für Agrar- und Gartenbauwissenschaften, Technische Universität München. Weihenstephan, 2011.

[Lor-11] Lorenz, M.; Müller, J.; Schapranow, M.-P.; Zeier, A.; Plattner, H.: Discovery Services in the EPC Network. In: Turcu, C. (Hrsg): Design-ing and Deploying RFID Applications: IN-TECH, 2011, S. 110–130.

[Man-05] Mangina, E.; Vlachos I.P.:

The changing role of information technology in food and bever-age logistics management: beverage network optimisation using intelli-gent agent technology. In: Journal of Food Engineering, Jg. 70 (2005)3, S. 403–420.

[Man-06] Mannel, A.; Finger, M.: RFID auf Item-, Case- und Pallet-Ebene. In: Hebezeuge und För-dermittel, Jg. 46 (2006), 1-2, S. 38–39.

[Man-2013] Manzini, R.; Accorsi, R.: The new conceptual framework for food supply chain assessment. In: Journal of Food Engineering, Jg. 2013 (2013)115, S. 251–263.

[Mel-06] Melski, A.: Grundlagen und betriebswirtschaftliche Anwendung von RFID. He-rausgegeben von: Matthias Schumann, 2006.

[Met-08] Metro Group: METRO Group weitet RFID-Einsatz nach Europa aus, 2008. URL: http://www.metrogroup.de/internet/site/metrogroup/node/151707/Lde/index.html (Aufruf am 18.02.2013).


131

[Met-09] Metro Group: RFID – Vom Pilot in den Alltag, 2009. URL: http://metrobetriebsrat.wordpress.com/2009/08/06/rfid-vom-pilot-in-den-alltag/ (Aufruf am 18.02.2012).

[Met-2008] Metro Group: Transparenz für die digitale Gesellschaft –RFID beschäftigt Wirt-schaft und Politik. In: Metro Group, 2008.

[Mil-08] Miles, S.; Sarma, S.; Williams, J.: Modeling supply chain network traffic. In: RFID Technology and Ap-plications: Cambridge University Press, 2008.

[mob-11] mobile-tagging.blogspot.de: Heinz Tomato Ketchup mit QR-Codes, 2011. URL: http://mobile-tagging.blogspot.de/2011/09/heinz-tomato-ketchup-mit-qr-codes.html (Aufruf am 09.11.2012).

[Mot-12] Motorola AG: MC9090-Z RFID Handheld-Lesegerät, 2012. URL: http://www.motorola.com/Business/XC-DE/Business+Product+and+Services/Bar+Code+Scanning/Scan-equipped+Mobile+Computers/MC9090-Z+RFID+Handheld+Reader (Aufruf am 23.02.2013).

[Mül-09] Müller, J.; et al.: A Simulation of the Pharmaceutical Supply Chain to Provide Realis-tic Test Data. In: First International Conference on Advances in Sys-tem Simulation, 2009, S. 44–49.

[Mül-10] Müller, J.; Oberst, J.; Wehrmeyer, S.; Witt, J.; Zeier, A.; Plattner, H.: An Aggregating Discovery Service for the EPCglobal Network. In: The 43rd Hawaii International Conference on System Sciences. Ha-waii, USA, 2010.

[Myh-09] Myhre, B.; Netland, T.; Vevle, G.: The footprint of food – A suggested traceability solution based on EPCIS. In: 5th European Workshop on RFID Systems and Technolo-gies (RFID SysTech 2009). Bremen, Germany, 16 - 17 Jun., 2009.

[Ora-99] Oracle Corporation: Middleware und Integration. Herausgegeben von: Oracle Corpora-tion, 1999.

[Pat-10] Patocka, M.: RAN-Newsletter. Herausgegeben von: RAN-Projektbüro, 2010.


132

[PRO-07] PROZEUS: EPC/RFID in der Mehrweg-Frischelogistik. Herausgegeben von: PROZEUS, 2007.

[PRO-08] PROZEUS: EPC/RFID auf allen Stufen der Supply Chain bis zum POS (Item-Tagging in der Bekleidungswirtschaft), 2008. URL: http://www.prozeus.de/prozeus/praxis/lemmi/index.htm (Aufruf am 18.12.2012).

[RAN-12] RAN: RFID-Based Automotive Network, 2012. URL: http://www.autoran.de/projekt.html (Aufruf am 18.12.2012).

[RFI-05] RFID-Journal: RFID System Components and Costs. Herausgegeben von: RFID Journal, 2005. URL: http://www.rfidjournal.com/article/view/1336/3 (Aufruf am 15.11.2012).

[RFI-09] RFID-Journal: EPCIS, RFID Effective in European Pharmaceutical Pilot. Herausge-geben von: RFID Journal, 2009. URL: http://www.rfidjournal.com/article/view/7110 (Aufruf am 18.12.2012).

[RFI-12] RFID ready - Informationsportal für RFID-Technologie: RFID-Lesegeräte-Reader, 2012. URL: http://www.rfid-ready.de/rfid-lesegeraete-reader.html (Aufruf am 15.11.21012).

[San-06] Sander, M.; Stieler, K.: RFID, Geschäftsprozesse mit Funktechnologie unterstützen - An-wendungsbeispiele und Planungsleitfaden. Wiesbaden: Hessisches Ministerium für Wirtschaft, Verkehr und Landesentwicklung, 2006.

[SAP-12] SAP AG: SAP ERP Operations – Solution Overview, 2012. URL: http://www.extendtechnologies.com.au/uploads/SAP_ERP/SAP_ERP_Operations.pdf (Aufruf am 25.09.2012).

[Sau-08] Sauser, J.: Gestaltung eines transponderbasierten Datennetzwerkes in der au-tomobilen Supply Chain. Frankfurt am Main: Deutscher Fachverlag, 2008.


133

[Sch-07] Schmolke, T.: Rückverfolgbarkeit und Qualitätssicherung - Gesetzliche Grundlagen und ihre Umsetzung am Beispiel von frischem Obst und Gemüse. Bachlorarbeit; Lehrstuhl für Marktlehre der Agrar- und Ernährungs-wirtschaft, Technische Universität München. Weihenstephan, 2007.

[Sch-12] Schwaiger, S.; Stemplinger, M.: Entwicklung und Demonstration eines RFID- und EPCIS-basierten Behältermanagementssystems mittels Lego. Interdisziplinäres Pro-jekt; Lehrstuhl fml – wissenschaftlich / inhaltlich angeleitet und be-treut von Rui Wang, TU München. Garching, 2012.

[Sei-05] Seifert, W.: RFID in der Logistik - Erfolgsfaktoren für die Praxis ; Dokumentation des BVL-Arbeitskreises "RFID in der Logistik". Hamburg: Dt. Ver-kehrs-Verl., 2005.

[Sma-12a] SmaRTI: Smart Reusable Transport Items, 2012. URL: http://www.smart-rti.de/ (Aufruf am 18.12.2012).

[Sma-12b] Smart NRW: RFID auf Umverpackungen soll Konsumgüterindustrie revolutionie-ren, 2012. URL: http://www.exzellenz.nrw.de/ikt-neu/noth/clusterinfo/news/view/data/39861/backpid/11/ (Aufruf am 21.02.2013).

[Spe-01] Spechtl, J.: Electronic Commerce - Einsatzpotential in kleinen und mittleren Un-ternehmen. 1 Auflage. s.l: GRIN Verlag, 2001.

[SPI-01] SPIEGEL ONLINE: Rinderseuche: Die Chronologie der BSE-Krise, 2001. URL: http://www.spiegel.de/politik/ausland/rinderseuche-die-chronologie-der-bse-krise-a-105210.html (Aufruf am 02.12.2013).

[SPI-08] SPIEGEL ONLINE: Melamin-Skandal in China: 13.000 Kinder nach Verzehr verseuchter Milch im Krankenhaus, 2008. URL: http://www.spiegel.de/panorama/gesellschaft/melamin-skandal-in-china-13-000-kinder-nach-verzehr-verseuchter-milch-im-krankenhaus-a-579540.html (Aufruf am 02.12.2013).

[Tam-10] Tamm, G.; Tribowski, C.: RFID. Berlin, Heidelberg: Springer, 2010.


134

[Tha-11] Thakur, M.; Sørensen, C.-F.; Bjørnson, F. O.; Forås, E.; Hurburgh, C. R.: Managing food traceability information using EPCIS framework. In: Journal of Food Engineering, Jg. 103 (2011)4, S. 417–433.

[Tho-11] Thomas Setzer: Skript zur Vorlesung "Internetbasierte Geschäftssysteme". Institut für Informatik, Technische Universität München, 2011.

[Thu-06] Thumser, J.: Implementierung eines webbasierten EPCIS-Clients mit EPCglobal-konformen Erweiterungen. Diplomarbeit; Fachbereich Design Infor-matik Medien, Fachhochschule Wiesbaden, 2006. Betreut durch Prof. Dr. Werntges.

[Ulb-10] Ulbrich, A.: Simulationgestützte Grobplanung von Kommissioniersystemen. Dis-sertation; Lehrstuhl fml, Technische Universität München. Garching, 2010. Betreut durch Günthner, W. A.

[Vah-12] Vahrenkamp, R.; Kotzab, H.; Siepermann, C.: Logistik: Management und Strategien. 7. Auflage. München: Olden-bourg Verlag, 2012.

[VDI-4472 ] VDI-4472:2010: Blatt 12: Anforderungen an Transpondersysteme (RFID) zum Einsatz in der Supply Chain - Einsatz der Transpondertechnologie zur Un-terstützung der Rückverfolgbarkeit am Beispiel der Automobilen Supply-Chain. VDI - Verein Deutscher Ingenieure.

[Wag-09] Wagner, J.: Technische Konzepte zur RFID-gestützten Bauzustandsdokumenta-tion in der Automobilindustrie. Dissertation; Lehrstuhl fml, Techni-sche Universität München. Garching, 2009. Betreut durch Günthner, W. A.

[Wal-10] Walenta, C. E.: Die Bedeutung des Informationsaustausches innerhalb von Koope-rationen. Institut für Transportwirtschaft und Logistik, Wirtschafts-universität Wien, Wien, 2010.

[Wal-97] Walton, S. V.; Marucheck, A. S.: The relationship between EDI and supplier reliability. In: , Jg. 33 (1997)3, S. 30–35.

[Wan-05] Wannenwetsch, H.: Vernetztes Supply-Chain-Management - SCM-Integration über die gesamte Wertschöpfungskette. Berlin [u.a.]: Springer, 2005.


135

[Wan-11] Wang, R.; Prives, S.; Fischer, R.; Salfer, M.; Günthner, W. A.:

Data analysis and simulation of Auto-ID enabled food supply chains based on EPCIS standard. In: IEEE International Conference on Au-tomation and Logistics (ICAL), 2011. Best Paper Award. S. 58–63.

[Wan-12] Wang, R.; Günthner, W. A.: Design and development of a Traceability Service for EPC-enabled food supply chains. In: SoftCOM 2012, 20. International Conference on Software, Telecommunications & Computer Networks, Split, Sep-tember 11 - 13, 2012. S. 1–6.

[Wed-03] Weder, J.: Betriebliche Anwendungen der Informatik - Industrie. Norderstedt, Books on Demand, 2003.

[Wer-00] Werner, H.: Supply-chain-Management - Grundlagen, Strategien, Instrumente und Controlling. 1 Auflage. Wiesbaden: Gabler, 2000.

[Win-11] Windels, P.: Erstellung und Bewertung von Konzepten für den Einsatz intelligen-ter Behälter in der Lebensmittel-Supply-Chain auf Basis logistischer Prozessaufnahmen. Diplomarbeit; Lehrstuhl fml, TU München. Gar-ching, 2011.

[Woo-52] Woodland, N.; Silver, B.: Classifying apparatus and method - US Patent 2,612,994. United States Patent Office, 1952.

136

Verzeichnis betreuter Studienarbeiten

Im Zuge dieser Dissertation wurden verschiedene Studienarbeiten unter wissen-

schaftlicher und inhaltlicher Anleitung des Autors erarbeitet, aus denen teilweise In-

halte für diese Forschungsarbeit entstanden sind. Bei direktem Bezug der Inhalte

dieser Arbeit mit einer der Studienarbeiten, wird auf die entsprechende Studienar-

beit verwiesen. Mein Dank gilt den Studenten für ihre erbrachten Arbeiten, die im

Folgenden aufgelistet sind:

[Sul-12] Suleman, K.; Dobi, S.: EPCIS-based Tracking & Tracing in Auto-ID enabled Food-Supply-Chain. Interdisziplinäres Projekt; Lehrstuhl fml – wissenschaftlich / inhaltlich angeleitet und betreut von Rui Wang, TU München. Gar-ching, 2011.

[Sch-12] Schwaiger, S.; Stemplinger, M.: Entwicklung und Demonstration eines RFID- und EPCIS-basierten Behältermanagementssystems mittels Lego. Interdisziplinäres Pro-jekt; Lehrstuhl fml – wissenschaftlich / inhaltlich angeleitet und be-treut von Rui Wang, TU München. Garching, 2012.

137

Abbildungsverzeichnis

Abbildung 1-1: Struktur und Vorgehensweise der Arbeit ............................................ 5

Abbildung 2-1: SAP ERP Solution Map (In Anlehnung an [SAP-12]) ........................... 9

Abbildung 2-2: Verbreitung von ERP-Lösungen in der Prozessindustrie in

Deutschland [Kon-11] ........................................................................................ 10

Abbildung 2-3: EDI-Kommunikation (In Anlehnung an [Tho-11]) ............................... 11

Abbildung 2-4: Übersicht über die wichtigsten Auto-ID-Technologien [Fin-06] ........ 14

Abbildung 2-5: Klassifizierung von Barcodes ........................................................... 16

Abbildung 2-6: EAN-13-Code ................................................................................... 17

Abbildung 2-7: Beispiel Transportetikett mit NVE in GS1-128-Standard [Dru-12] .... 18

Abbildung 2-8: Heinz Tomato Ketchup mit QR-Codes [mob-11] .............................. 19

Abbildung 2-9: Hauptkomponenten eines RFID-Systems ........................................ 20

Abbildung 2-10: Häufig verwendete RFID-Barformen............................................... 20

Abbildung 2-11: Beispiel für RFID Schreib-/Lesegeräte [FML-12b], [RFI-12] ........... 20

Abbildung 2-12: Überblick über nutzbare RFID-Frequenzen in Deutschland und

dazugehörige beispielhafte Anwendungen [Wag-09] ......................................... 23

Abbildung 2-13: Vergleich der Lesereichweite eines Transponders (ALL-9460 Omni

Squiggle) nach verschiedenen Applikationsmaterialien ..................................... 25

Abbildung 2-14: Beispiel RFID mit Sensorik: CAEN A927Z RFID-Temperaturlogger

[CAE-12] ............................................................................................................. 29

Abbildung 2-15: Prinzipskizze des Mojix-STAR-System [FML-13] ........................... 30

Abbildung 3-1: Architektur des EPCglobal-Netzwerkes (In Anlehnung an [EPC-09a])

........................................................................................................................... 35

Abbildung 3-2: Aufbau des EPCs am Beispiel einer SGTIN-96 (In Anlehnung an [Gil-

07], [Sei-05]) ....................................................................................................... 37

Abbildung 3-3: ONS vs. Discovery Service ............................................................... 40

Abbildung 4-1: Beispielszenario der Tiefkühlkette .................................................... 48

Abbildung 4-2: Häufig verwendete THM in der Lebensmittellogistik ........................ 51


138

Abbildung 4-3: Wichtige Identifikationspunkte in der Lebensmittel-Supply-Chain am

Beispiel einer Tiefkühlkette ................................................................................ 55

Abbildung 4-4: Verschiedene EPC-Darstellungsformate (In Anlehnung an [GS1-12b])

.......................................................................................................................... 55

Abbildung 4-5: Die verwendeten Identifikationsnummern auf verschiedenen

Objektebenen .................................................................................................... 57

Abbildung 4-6: UML-Diagramm für EPCIS-Ereignistypen [EPC-07b] ....................... 60

Abbildung 4-7: Vergleich ONS und Discovery Service für Tracking & Tracing ......... 67

Abbildung 4-8: Directory Look-Up Design................................................................ 68

Abbildung 4-9: Query Relay Design .......................................................................... 69

Abbildung 4-10: Aggregating Discovery Service Design .......................................... 70

Abbildung 4-11: Aufbau des Rückverfolgungsdiensts.............................................. 74

Abbildung 4-12: Flussdiagram für die Abfrage- und Aggregationslogik ................... 75

Abbildung 5-1: Das Simulationsmodell in Plant Simulation ...................................... 84

Abbildung 5-2: Methode zur Generierung der SGTIN (in SimTalk) ........................... 85

Abbildung 5-3: Benutzerdefinierte Attribute für den Baustein „Identifikationspunkt“86

Abbildung 5-4: Ablaufdiagramme für die Generierung von EPCIS-Ereignissen mit

XML-Bindung in Plant Simulation ...................................................................... 88

Abbildung 5-5: Beispiel für die generierten EPCIS-Ereignisse ................................. 89

Abbildung 5-6: Architektur des Informationssystems ............................................... 90

Abbildung 5-7: Weiterleitung der generierten EPCIS-Ereignisse an das

Informationssystem durch ein Schnittstellenprogramm .................................... 91

Abbildung 5-8: Ablauf des Registrierungsprozesses beim Rückverfolgungsdienst . 91

Abbildung 5-9: Screenshots von der Clientapplikation ............................................ 94

Abbildung 5-10: Simulierte Netzwerkverzögerung zwischen dem

Rückverfolgungsdienst und EPCIS-Servern für einzelne Abfragen ................... 96

Abbildung 6-1: Konzept zur Integration des EPC-Netzwerkes in Unternehmens-IT

........................................................................................................................ 100

Abbildung 6-2: Skizze des angestrebten Demonstrationsmodells für ein RFID-

basiertes BMS ................................................................................................. 102

Abbildung 6-3: Das Lego-basierte Demonstrationsmodell ..................................... 106

Abbildung 6-4: Gesamte Systemlandschaft des BMS ........................................... 107


139

Abbildung 6-5: Integration des EPC-Netzwerkes in das BMS ................................ 107

Abbildung 6-6: Aufbau der Lego-Station ................................................................ 110

Abbildung 6-7: Abwicklung der Transportaufträge ................................................. 111

Abbildung 6-8: Startseite des BMS ......................................................................... 112

Abbildung 6-9: Transportauftragsübersicht ............................................................ 113

Abbildung 6-10: Anlegen von neuen Transportaufträgen ....................................... 113

Abbildung 6-11: Bearbeitungsgeschichte eines Transportauftrags ........................ 114

Abbildung 6-12: Bestandsübersicht ........................................................................ 114

Abbildung 6-13: Tracking & Tracing der Behälter durch EPCIS .............................. 115

Abbildung 6-14: Temperaturüberwachung ............................................................. 116

Abbildung 6-15: Stammdatenverwaltung - Behälterdaten ...................................... 116

Abbildung 6-16: Stammdatenverwaltung - Stationsdaten ...................................... 117

140

Tabellenverzeichnis

Tabelle 2-1: Unterscheidungsmerkmale von RFID-Systemen .................................. 22

Tabelle 2-2: Vergleich der Merkmale von RFID und Barcode ................................... 26

Tabelle 3-1: Häufig verwendete EPC-Typen in der Logistik (In Anlehnung an [EPC-

11]) ..................................................................................................................... 36

Tabelle 3-2: EPCIS-Kommunikationsschnittstellen und ihre Bindungsmöglichkeiten

[EPC-09b], [Kik-11]} ........................................................................................... 38

Tabelle 4-1: Standardisierte EPCIS-Ereignisattribute ............................................... 62

Tabelle 4-2: Mögliche Werte der Vokalbelelemente für die Attribute „bizStep“ und

„disposition“ ...................................................................................................... 64

Tabelle 4-3: Mapping zwischen Auto-ID gestützten Logistikprozessen und EPCIS-

Ereignissen ........................................................................................................ 65

Tabelle 4-4: Vergleich verschiedener Discovery Service Design-Varianten .............. 72

Konzeption und Entwicklung eines EPC-basierten ... · duktcode (EPC) basierendes...

Documents

Transcript of Konzeption und Entwicklung eines EPC-basierten ... · duktcode (EPC) basierendes...