pdf -Dokument - Lehrstuhl für Fördertechnik Materialfluss Logistik

Transcription

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.
I
II
Rui Wang
Konzeption und Entwicklung eines EPC-basierten
Datennetzwerkes in der Lebensmittel-Supply-Chain
fml – Lehrstuhl für Fördertechnik Materialfluss Logistik
Technische Universität München
III
Herausgegeben von:
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, insbesondere 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
IV
Danksagung
Die vorliegende Arbeit entstand während meiner Tätigkeit am Lehrstuhl für Fördertechnik 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 Koreferats 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 Hilfsbereitschaft 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 Angestellten des Lehrstuhls, die mir stets hilfsbereit zur Seite standen.
Mein besonderer Dank gilt auch Frau Dr. Lina Riedl, die die sprachlichen Korrekturen meiner Arbeit sehr sorgfältig durchgeführt hat.
Der größte Dank gilt meinen Eltern für die langjährige bedingungslose und uneingeschrä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 liebe Euch!
V
VI
Kurzzusammenfassung
Die Lebensmittelindustrie gehört zu den bedeutendsten und größten Industriebranchen. Aufgrund des wachsenden Wettbewerbs- und Preisdrucks auf dem EULebensmittelmarkt haben viele Unternehmen der Lebensmittelindustrie ihre Aufmerksamkeit auf die Optimierung oder das Reengineering ihrer Logistikprozesse
gelegt, um sich dadurch Wettbewerbsvorteile zu sichern. Eine entscheidende Bedeutung kommt dabei der Verbesserung der Informationslogistik zu. Im Vergleich zu
anderen Branchen stellt die Lebensmittelindustrie höchste Anforderungen an Produktsicherheit und Rückverfolgbarkeit, welche eine durchgängige Informationslogistik durch Einsatz von modernen Informations- und Kommunikationstechnologie benö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 entscheidende Voraussetzung für eine weite Verbreitung des Auto-ID-Einsatzes. Im
Vergleich zu Barcode ist die Standardisierung bei RFID noch unzureichend umgesetzt. Dies erschwert die Implementierung kettenübergreifender Anwendungen.
Vor diesem Hintergrund hat die Arbeit zum Ziel, ein auf dem Elektronischen Produktcode (EPC) basierendes Datennetzwerk-Konzept zu entwickeln, um die Transparenz 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 entwickelt, 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ältermanagementsystems die Integration des Netzwerks in bestehende/andere IT-Landschaften veranschaulicht.
VII
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 companies are starting to pay attention to the optimization or reengineering of their logistics 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 information 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 developed, 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.
VIII
Inhaltsverzeichnis
Danksagung
V
Kurzzusammenfassung
VII
Abstract
VIII
Inhaltsverzeichnis
Abkürzungsverzeichnis
Verwendete Formelzeichen
1
IX
XIII
XVII
Einleitung
1
1.1 Motivation
1
1.2 Zielsetzung und Aufbau der Arbeit
3
2
7
Informationslogistik und Auto-ID-Einsatz in der Lebensmittel-Supply-Chain
2.1 Einführung
7
2.2 Überblick über die aktuelle IT-Systemlandschaft in der Lebensmittel-SupplyChain
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
IX
Inhaltsverzeichnis
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
4
44
Konzept eines EPC-basierten Datennetzwerkes in der Lebensmittel-SupplyChain
47
4.1 Das Konzept der Auto-ID gestützten Identifikation in der LebensmittelSupply-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
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 EPCISEreignissen
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
X
59
76
Inhaltsverzeichnis
5
Umsetzung des Konzepts
5.1 Generierung realistischer EPCIS-Ereignisse durch Ablaufsimulation
79
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
99
Integration des EPC-Netzwerkes in vorhandene/andere IT-Landschaften
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
119
Zusammenfassung und Ausblick
7.1 Zusammenfassung
119
7.2 Ausblick
121
Literaturverzeichnis
123
Verzeichnis betreuter Studienarbeiten
136
Abbildungsverzeichnis
137
Tabellenverzeichnis
140
XI
Inhaltsverzeichnis
XII
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
XIII
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
XIV
URI
Uniform Resource Identifier
URL
Universal Resource Locator
WMS
Warehouse Management System
WSDL
Web Services Description Language
XML
Extensible Markup Language
XV
XVI
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ückverfolgungsdiensts
𝜌
[-]
 𝜇
XVII
XVIII
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 Jahrzehnten haben einen schweren Imageschaden der Lebensmittelindustrie mit Umsatzrückgang verursacht und das Vertrauen der Verbraucher drastisch erschüttert.
Dafür sind die BSE-Krise (Bovine Spongiforme Enzephalopathie) [SPI-01], der Melamin-Fall (veruneinigten Milchpulverprodukten) in China [SPI-08], die mit EHEC (Enterohämorrhagische Escherichia coli) verseuchte Sprossen [aer-11] sowie der jüngste Rindfleischskandal in Deutschland [DIE-13] eindrucksvolle Beispiele.
Anhand der Krisen und Skandalen wird deutlich, dass die schnelle und gezielte Rekonstruktion von Warenflüssen entlang der Lieferkette von entscheidender Wichtigkeit 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 Verordnung (EG) Nr. 178 /2002 erlassen, die in Deutschland zum 1. Januar 2005 in Kraft
getreten ist. Diese Verordnung verpflichtet alle an einer der Lebensmittelkette Beteiligten, Warenein- und -ausgänge zu dokumentieren, damit die Rückverfolgbarkeit
ihrer Materialflüsse gewährleistet werden kann. Hierzu sollten Systeme und Verfahren etabliert werden, mit Hilfe derer die dokumentierten Informationen den zuständigen 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 Verordnung 178/2002 markiert einen Meilenstein für die Lebensmittelsicherheit in der EU.
Mit ihrer Veröffentlichung haben die betroffenen Unternehmen angefangen zu überlegen, wie sie ihre Dokumentationssysteme aufbauen können, um einerseits die gesetzlichen Anforderungen zu erfüllen und um andererseits Mehrwert für Ihre Unternehmensprozesse 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 Unternehmen 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 zeitlichen Verzögerungen bei der Problementdeckung führt und Rückrufaktionen ent1
1 Einleitung
sprechend schwierig macht [Bec-08]. Darüber hinaus macht die Uneinheitlichkeit
der Systeme der Beteiligten die Verkettung von Informationen über die gesamte Lieferkette zusätzlich schwierig.
Die Entwicklung von Auto-ID-Technologien, vor allem die RadiofrequenzIdentifikationstechnologie (RFID), bringt heutzutage neue Möglichkeiten zur Verbesserung 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 gespannt 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 einzelnen 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 weltweite eindeutige Kennzeichnung von Objekten ermöglicht. Um einen effizienten Austausch 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 diversen Komponenten und Kommunikationsschnittstellen besteht und die Vision des
„Internets der Dinge“ in einem engeren Sinn realisiert1. Bevor der Standard eingesetzt wird, ist er allerdings je nach Anwendungsbranche anzupassen und zu erweitern. Die Rückverfolgbarkeit in der Lebensmittelkette betrifft in der Regel viele Beteiligte, 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 betrachtet.
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]
2
Zielsetzung und Aufbau der Arbeit
1.2 Zielsetzung und Aufbau der Arbeit
Das Ziel der Arbeit liegt in der Konzeption und Entwicklung eines EPC-basierten Datennetzwerkes, das dazu beitragen soll, die Transparenz in der LebensmittelSupply-Chain zu erhöhen und die Rückverfolgbarkeit zu erleichtern. Dabei wird anhand eines Beispielsszenarios die Anpassung und Erweiterung des EPCISStandards in der Lebensmittelkette diskutiert. Zudem wird ein Rückverfolgungsdienst 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 gesamten Lieferkette effizient realisiert werden kann. Das Ziel des EPC-basierten Datennetzwerkes soll darin liegen, die vorhandene IT-Landschaft der Unternehmen zu
ergänzen statt zu ersetzen, damit der Kostenaufwand bei der Einführung des Netzwerkes 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 Lebensmittellogistik, 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 AutoID-Technologie über die gesamte Lieferkette ist aber die Entwicklung und Einführung von einheitlichen Standards. Dazu wird das EPCglobal-Netzwerk schwerpunktmäßig in Kapitel 3 vorgestellt. Es wird insbesondere auf die wichtigen Komponenten 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 Lebensmittellogistik 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.
3
1 Einleitung
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 Umgebung aufgebaut wird, folgt zuletzt die Simulation einer möglichen Netzwerkverzögerung zur Evaluation der Machbarkeit des Systems.
In Kapitel 6 wird diskutiert, wie man das EPC-basierte Datennetzwerk in die bestehende IT-Landschaft der Unternehmen integrieren kann. Die Integration wird mittels
einer Demonstration über ein RFID-basiertes Behältermanagementsystem veranschaulicht.
Abschließend erfolgen in Kapitel 7 eine Zusammenfassung der Arbeit sowie der
Ausblick auf zukünftige Entwicklungsbedarfe.
4
Motivation und Zielsetzung
Einleitung
·
Motivation
·
·
·
·
Kap. 1
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. 2
Grundlagen und Stand der Technik
·
·
·
·
Vision und Architektur des Netzwerkes
Wichtige Komponenten zum kettenübergreifenden Datenaustausch
Stand der Forschung
Konkretisierung der Forschungsziele
Kap. 3
·
·
·
·
Hauptteil
Konzeption eines EPC-basierten Datennetz-werkes für
die Lebensmittellogistik
Das Konzept der Auto-ID-gestützten Identifikation in der Lebensmittel-SupplyChain
Nummernsystem
Einsatz und Erweiterung des EPCIS-Standards
Konzeption eines Rückverfolgungsdiensts
Kap. 4
·
·
Generierung realistischer EPCIS-Ereignisse durch Ablaufsimulation
Aufbau eines Informationssystems als „Proof of Concept“
·
Evaluation
·
·
Kap. 5
Integration des EPC-Netzwerkes in vorhandene/andere
IT-Landschaften
Integrationskonzept
Darstellung der Integration am Beispiel eines Behältermanagementsystems
Kap. 6
·
·
Zusammenfassung
Ausblick
Kap. 7
Abbildung 1-1: Struktur und Vorgehensweise der Arbeit
5
1 Einleitung
6
Einführung
2
Informationslogistik und Auto-ID-Einsatz in der
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üllung dieses Ziels spielt die Informationslogistik eine entscheidende Rolle.
Die Informationslogistik befasst sich als Teilgebiet des gesamten Informationsmanagements mit Informationsflüssen in unternehmensinternen Prozessen oder in unternehmensübergreifenden Ketten und Netzwerken. Sie hat die Aufgabe, relevante Informationen in geeigneter Form und Qualität für die Planung, Steuerung und Kontrolle der Unternehmensprozesse bereitzustellen [Gün-07]. Für die Implementierung
der Informationsflüsse sind die Speicherung und Aufbereitung von Daten erforderlich. Um diese zu realisieren, sollten adäquate und unterstützende Informationssysteme eingerichtet werden [Din-08].
Aufgrund des wachsenden Wettbewerbs- und Preisdrucks auf dem EULebensmittelmarkt haben viele Unternehmen der Lebensmittelindustrie ihre Aufmerksamkeit auf die Optimierung oder das Reengineering ihrer Logistikprozesse
gelegt, um sich Wettbewerbsvorteile dadurch zu sichern [Fea-99]. Eine entscheidende Bedeutung kommt dabei der Verbesserung ihrer Informationslogistik zu [Ghi01]. Im Vergleich zu anderen Branchen bestehen höchste Anforderungen an Produktsicherheit und Rückverfolgbarkeit, welche eine durchgängige Informationslogistik durch Einsatz von modernen Informations- und Kommunikationstechnologie benötigen [Man-05]. Vor diesem Hintergrund werden IT-Systeme heutzutage zunehmend in der Lebensmittelbranche eingesetzt.
Diese Arbeit handelt von der Konzeption und Entwicklung eines EPC-basierten Datennetzwerkes, welches zum Ziel hat, die Informationslogistik in der LebensmittelSupply-Chain zu verbessern. In diesem Kapitel wird daher zunächst der Status Quo
der Informationslogistik in der Lebensmittel-Supply-Chain vorgestellt. Dazu wird zuerst ein Überblick über die häufig eingesetzten IT-Systeme in der LebensmittelSupply-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
7
2 Informationslogistik und Auto-ID-Einsatz in der Lebensmittel-Supply-Chain
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 Datenaustausches in der Lebensmittelkette erläutert (Abschnitt 2.4).
2.2 Überblick über die aktuelle IT-Systemlandschaft in der Lebensmittel-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 Ressourcen (Kapital, Material, Betriebsmittel oder Personal) möglichst effizient zu gestalten und somit die Steuerung von Geschäftsprozessen zu optimieren [Gro-10].
Um diese Aufgabe zu erfüllen, werden heute in vielen Unternehmen die sogenannten ERP-Systeme eingesetzt. Als ERP-Systeme bezeichnet man hierbei integrierte
Informationssysteme, die alle möglichen Geschäftsprozesse abbilden und ihre Planung 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 Integrierten Softwareplattform geworden, welche fast alle Aspekte in der Geschäftsoperationen 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 verstrickt sind. Andererseits sollte jedes Modul auch selbstständig betrieben und erweitert werden können [FML-12a]. In der Logistikbranche kann beispielsweise das Lagerverwaltungssystem (WMS), das Tourenplanungssystem oder das Behältermanagementsystem 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.
8
Überblick über die aktuelle IT-Systemlandschaft in der Lebensmittel-Supply-Chain
Analytics
Strategic
Enterprise
Management
Financials
Financial Supply
Chain
Management
Human Capital
Management
Talent
Management
Procurement &
Logistics
Execution
Product
Development &
Manufacturing
Procurement
Production
Planning
Sales &
Service
Corporate
Services
Real Estate
Management
Sales Order
Management
Enterprise Asset
Management
Treasury
End-User Service Delivery
Inventory &
Warehouse
Management
Financial
Analytics
Financial
Accounting
Operations
Analytics
Workforce
Analytics
Workforce
Process
Management
Corporate
Governance
Aftermarket
Sales and
Service
Inbound &
Outbound
Logistics
Management
Accouting
Workforce
Deployment
Project and
Portfolio Mgmt.
Manufacturing
Execution
Transportation
Management
Envionment,
Health and Safty
Compliance
Mgmt.
Product
Development
Life-Cycle Data
Management
Travel
Management
ProfessionalService Delivery
Quality
Management
Global Trade
Services
SAP Netweaver
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 Unternehmen in der Prozessindustrie, wozu die Lebensmittelbranche gehört, ERPStandardsysteme eingesetzt. Nur 6,9% der Befragten haben noch keine ERPLösungen eingeführt. 33,4% haben eine Eigenentwicklung statt Standardsysteme
verwendet und die Speziallösungen liegen bei 20,1%. Der Grund liegt einerseits darin, dass die Standardsysteme oft zeit- und kostenaufwendig einzuführen sind. Andererseits sind nach Meinung der Befragten nicht alle individuellen Anforderungen mit
den Standardlösungen zu erfüllen.
9
keine ERP-Lösung
6,9%
mind. eine ERP-Standardlösung
79,3%
mind. eine Eigenentwicklung
mind. eine Spezial-/Einzellösung
33,4%
20,1%
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 umfangreichere 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 kommen 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 Kommunikationstechnologien 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 Einzelprozesse unterteilen: den Konvertierungsprozess und den Kommunikationsprozess. Im
Konvertierungsprozess werden die zu übertragenen Daten in standardisierte Nachrichtenformate ü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 schematisch dargestellt.
10
Überblick über die aktuelle IT-Systemlandschaft in der Lebensmittel-Supply-Chain
Geschäftsanwendung
(z. B. ERP-Systeme)
Übersetzung
EDINachricht
Konverter
Netzwerk
Unternehmen A
Konverter
Unternehmen B
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 EDIFACTNormen richtungsweisend. Um die Komplexitäten bei der Anwendung von EDIFACT-Standards zu reduzieren, wurden für einzelne Branchen die sogenannten
Subsets von EDIFACT entwickelt. Für die Konsumgüterwirtschaft, wozu die Lebensmittellogistik 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 Investitionsvolumen vom traditionellen EDI abgehalten [Wed-03].
11
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öglichkeit, 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 WebEDI Nachteile. Zum einen führt die Nutzung von Web-EDI wieder zu manuellem Aufwand, da die erhaltenen Daten manuell ins ERP-System übertragen werden müssen.
Zum anderen können zusätzliche Kosten durch die Anbindung an mehrere Unternehmensgruppen 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ückverfolgbarkeit spielt nicht nur für das Vertrauen und das Sicherheitsbedürfnis der
Verbraucher, sondern auch für das betriebliche Risikomanagement von Lebensmittelunternehmen eine wichtige Rolle [Lie-11].
Die BSE-Krise in den 90er Jahren zeigte, dass die Informationen, die für eine schnelle 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 allgemeinen Grundsätze und Anforderungen des Lebensmittelrechts, zur Errichtung
der Europäischen Behörde für Lebensmittelsicherheit und zur Festlegung von Verfahren zur Lebensmittelsicherheit“ von der Europäischen Union entworfen. Am Anfang 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 „Systeme und Verfahren“ eingerichtet werden, die diese Informationen den zuständigen
Behörden nach Aufforderung zur Verfügung stellen [Eur-02]. In dieser Verordnung
12
Einsatz von Auto-ID-Technologien in der Lebensmittel-Supply-Chain
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 Umsetzung der Rückverfolgbarkeit: entweder verkettete Systeme oder integrierte Systeme [Gam-06].
Bei verketteten Systemen dokumentiert jedes Lebensmittelunternehmen in der Lieferkette 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 vorund nachgelagerten Stufen erfragen. Die Rückverfolgbarkeit in der gesamten Kette
kann aber nur durch Informationsverkettung gewonnen werden. Die verketteten Systeme werden in der Praxis häufig verwendet, da diese Lösung geringen Organisationsaufwand mit sich bringt. Die Nachteile sind offensichtlich: die Informationsverkettung 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 andere Anforderungen an Datensicherheit stellen. Weiterhin bieten die bisherigen integrierten Systeme auf dem Markt meist nur Insellösungen jeweils für einen speziellen Teilaspekt der Kette in einem kleinen Umfang. Die mangelnde Standardisierung
hat zur Folge, dass das Anbinden von neuen Geschäftspartnern oft zeit- und kostenaufwendig ist.
2.3 Einsatz von Auto-ID-Technologien in der LebensmittelSupply-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 Informationslogistik 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
13
Jahren auch zunehmend an Bedeutung, da sie viel mehr Möglichkeiten für die Optimierung 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 24 gibt eine Übersicht der wichtigsten Auto-ID-Technologien.
Barcode
FingerabdruckVerfahren
Optical
Character
Recognition
(OCR)
Biometrische
Verfahren
Auto-ID
SprachIdentifizierung
ChipKarten
RFID
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 2DBarcodes, 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ührungslos und ohne Sichtverbindung lesen/schreiben zu können“ [Gün-12b].
14
Optical Character Recognition (OCR) bezeichnet Verfahren zu automatischen Identifizierung von Objekten durch spezielle Schrifttypen, die nicht nur von Maschinen
sondern im Notfall oder zur Kontrolle von Menschen gelesen werden können. Wegen der teureren und komplizierten Lesegeräte ist Anwendung von OCR in der Industrie nicht verbreitet.
Chipkarten sind spezielle Karten (meistens aus Plastik) mit einem eingebauten elektronischen 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 Identifikationstechnik. 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 USAmerikaner haben in diesem Jahr ein Strichcodesystem entwickelt, das zum Ziel hat,
die automatische Abfrage von Produktdetails an der Supermarktkasse zu ermöglichen. 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 Jahren, 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 heutzutage 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 gefärbten Strichen und farblosen Lücken grafisch dar“ [Han-94]. Gelesen wird Barcode
durch ein optisches Datenerfassungsgerät, wie zum Beispiel einen Scanner (1DBarcode) oder ein Kamerasystem (2D-Barcode). Für unterschiedliche Farben bzw.
15
Breiten der Striche im Barcode werden elektrische Signale mit unterschiedlichen
Stärken bzw. Dauern generiert. Die Signale werden anschließend von einem Decoder 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 verwendet, das eindimensionale (1D) Barcode und das zweidimensionale (2D) Barcode. Das
2D-Code lässt sich wiederum in Stapelcode und Matrixcode unterteilen (siehe Abbildung 2-5).
1D- Barcode
Barcode
Stapelcode
2D-Barcode
Matrixcode
Abbildung 2-5: Klassifizierung von Barcodes
In der Lebensmittelbranche wird 1D-Barcode (Strichcode) schon seit langem eingesetzt. Dazu ist die EAN (European Article Number) das am weitesten verbreiteten
Nummerierungssystem. Durch den Zusammenschluss der NummernvergabeOrganisationen 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 Produktpackung aufgedruckt und kann durch Barcodescanner beispielsweise an den Kassen
gelesen werden (siehe Abbildung 2-6). Die 13 Ziffern des Codes bedeuten: Länderprefix (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 Artikeln gleicher Spezifikationen. Allerdings können Einzelprodukte aufgrund der fehlenden Seriennummer nicht dadurch eindeutig identifiziert werden.
16
Länderprefix Unternehmensnummer
Artikelnummer
Prüfziffer
Abbildung 2-6: EAN-13-Code
In der Lebensmittellogistik wird neben dem EAN-13/GTIN-13-Code der GS1-128Barcode (die ehemalige EAN-128) häufig verwendet. Mit Hilfe der sogenannten Datenbezeichner 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 Datenbezeichner 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.) angebracht ist (siehe Abbildung 2-7). Der Strichcode ermöglicht die automatische Erfassung der NVE mittels Scanner. In Verbindung mit EDI können die Prozesse sowie die
Datenpflege bei Warenversand und -empfang in der Lieferkette dadurch beschleunigt sowie zuverlässiger gestaltet werden.
17
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üsselte Daten. In Abbildung 2-8 wird ein Beispiel der Anwendung des QR-Codes, einer
speziellen Form eines Matrixcodes, gezeigt. Der Ketchup-Hersteller Heinz verwendet 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 gelangen 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 Lebensmittelbranche, es ist aber beobachtbar, dass sie zunehmend eingesetzt werden.
18
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ässigkeit den Markt der Auto-ID Systeme dominiert, wird er in der heutigen Lebensmittellogistik vielen Anforderungen nicht mehr gerecht. Er bietet nur begrenzten Informationsgehalt und kann nicht umprogrammiert werden. Außerdem ist seine Lesereichweite 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 ITInfrastruktur, die die erfassten Daten verarbeitet und interpretiert [Gün-12a].
19
Transponder
Funkwelle
Antenne
Schreib-/Lesergerät
IT-Infrastruktur
Abbildung 2-9: Hauptkomponenten eines RFID-Systems
Der Transponder, der eigentliche Datenträger des RFID-Systems, besteht üblicherweise aus einem Computerchip und einer damit verbundenen Antenne. Er kann im
Regelfall berührungslos gelesen und/oder programmiert werden. Die RFIDTransponder 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 Umweltbedingungen werden Transponder in Kunststoffgehäusen verwendet. In Transponder 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 Aufgabe, die Informationen aus einem Transponder auszulesen und ggf. Daten auf einen Transponder zu schreiben. Das SLG besteht üblicherweise aus einem Hochfrequenzmodul (Sender und Empfänger), einer Steuereinheit, einem Koppelelement
20
zum Transponder sowie Schnittstellen, die die Daten an die übergeordnete ITInfrastruktur 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 mehrere Antennen am Reader angeschlossen werden. Die Verbindung über diverse
Schnittstellen (RS232, USB oder Ethernet etc.) erleichtert die Integration in bestehende ü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 DockingStation übertragen werden [Bro-12] (vgl. Abbildung 2-11).
RFID-Gate am Lehrstuhl fml
Beispiel für stationäre SLG
RFID-Handheld
Beispiel 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 Parameter (Richtgewinn, Frequenzbereich, Öffnungswinkel, Polarisation, Stehwellenverhältnis) einteilen. Je nach Anwendungsanforderungen können verschiedene Antennen 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 besteht 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 RFIDDaten bereinigt, aggregiert, in geeignete Datenformate transformiert und dann an
21
übergeordnete IT-Applikation weiterleitet [Tam-10]. Die IT-Applikation kann entweder ein bestehendes Informationssystem im Unternehmen sein wie zum Beispiel das
ERP-System oder ein spezielles RFID-Anwendungsprogramm sein, das die RFIDDaten nach Anforderungen interpretiert und darstellt, um ihr Potenzial zur Optimierung 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 Frequenzbereichen arbeiten. Grundsätzlich werden die Arbeitsfrequenzen von RFIDSystemen 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 HFBereichen 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 elektromagnetische 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 Frequenzbereiche in Deutschland sowie ihre typischen Anwendungen dargestellt. Es ist zu beo22
bachten, dass UHF-Systeme bei Logistikanwendungen überwiegend eingesetzt
werden.
Abbildung 2-12: Überblick über nutzbare RFID-Frequenzen in Deutschland und dazugehörige beispielhafte Anwendungen [Wag-09]
Energieversorgung: Hinsichtlich der Energieversorgung der RFID-Transponder unterscheidet man zwischen passiven, aktiven und semi-passiven Transpondern. Passive RFID-Transponder haben keine eigene Stromversorgung und müssen die Energie, 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 relativ 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 Batterien 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ässigkeit. 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 Bei23
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 ReadOnly- und Read-Write-Systemen unterschieden. Bei Read-Only-Systemen werden
die Daten (meist eine Seriennummer) vom Hersteller auf die Transponder programmiert, die danach von RFID-Readern nur gelesen, also nicht geändert werden können. Aufgrund des einfachen Aufbaus sind Read-Only-Transponder kostengünstig in
der Herstellung. Bei Anwendungen ohne Datenspeicherung sind Read-OnlyTransponder 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 kostenintensiver [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äften 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 Datenmengen vor allem bei kurzen Verweilzeiten im Lesefeld übertragen werden können. Im Vergleich dazu verfügen aktive Transponder normalerweise über eine höhere
Speicherkapazität aufgrund ihrer eigenen Energieversorgung und ihrer größeren Lesereichweite. 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. Allerdings wird RFID gleichzeitig auch kritisch betrachtet, da sie störungsanfälliger gegenü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 entsprechend seiner elektrischen Eigenschaften die Resonanzfrequenz des Transponders verändern kann [Gün-11b]. Außerdem ist es bei UHF-Systemen üblich, dass
die elektromagnetischen Wellen von den Applikationsmaterialien, vor allem bei
24
metallischen Oberflächen, absorbiert und reflektiert werden, wodurch die Systemleistung stark beeinflusst werden kann. Eine beispielhafte Messung der Lesereichweite 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 Datenaustausch 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 Transponder auszuwählen. Die RFID-Hersteller bieten eine Vielfalt von RFID-Transpondern
an, die unter verschiedenen thermischen, chemischen oder physikalischen Rahmenbedingungen eingesetzt werden können.
25
2.3.4 Vergleich von RFID mit Barcode
Der Einsatz von RFID ist ein Megatrend der Logistikbranche. Die zunehmende Einführung von RFID wird die traditionellen Barcodes allerdings auf keinen Fall vollständig ersetzen. In Tabelle 2-2 werden die Merkmale der beiden Technologien vergleichend 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 Applikationsmaterialien (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 Barcode 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 Erfassung mehrerer Transponder (Pulkerfassung). Dies kann z.B. durch Beschleunigung zur Optimierung von Logistikprozessen beitragen.
26
·
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 beeinflusst werden, vor allem von Metall. Außerdem wird die Lesereichweite eingeschrä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 RFIDTransponder, sind im Verhältnis höher. Obwohl der Preis in Zukunft vermutlich
sinken wird, stehen die Anwender einer item-Level-Identifikation durch RFID wegen 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 missbraucht werden könnten. Deswegen ist Datenschutz und –sicherheit ein wichtiges Thema, das man bei der Anwendung von RFID-Systemen berücksichtigen
muss.
·
Eine entscheidende Voraussetzung für den erfolgreichen Einsatz der Auto-IDTechnologie in der unternehmensübergreifenden Logistikbranche ist die Entwicklung und Anwendung einheitlicher Standards. In der Industrie ist Barcode weit
verbreitet und eine weltweite Standardisierung ist weit fortgeschritten. Im Vergleich 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öglichkeiten der Prozessoptimierung entstehen, welche mit dem herkömmlichen
Barcode nur schwer realisierbar sind. Im folgenden Abschnitt wird näher betrachtet, welche Potenziale durch RFID-Einsatz in der Lebensmittel-SupplyChain entstehen.
27
2.3.5 Potenzial durch RFID-Einsatz in der Lebensmittel-Supply-Chain
Der Einsatz von RFID bietet zahlreiche Möglichkeiten, Logistikprozesse in der Lebensmittelkette zu verbessern. Im Folgenden sind die Hauptpotenziale des RFIDEinsatzes innerhalb der Warenstromkette der Lebensmittelindustrie zusammengefasst [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 Datenaustausch in der Lieferkette, der die Warenflüsse mit den Informationsflüssen synchronisiert. 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 unterstützen und die maximale Transparenz der Lebensmittelkette zu realisieren. Dafür
spielt die Standardisierung des Datenaustausches über Unternehmensgrenze hinweg 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 Frischfleisch, 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 Einsatz. Die Kombination von RFID und Sensorik ist ein neues Einsatzgebiet der RFIDTechnologie, das rezent in Forschung und Industrie untersucht wird. Abbildung 2-14
zeigt ein Beispiel eines auf dem Markt erhältlichen RFID-Transponders mit integrierten Temperatursensoren. Es ist ein semi-passiver Transponder, der im UHFFrequenzbereich arbeitet. Dieser Transponder verfügt über eine eindeutige Identifikationsnummer und kann bis zu insgesamt 8192 Temperatur-Samples speichern
[CAE-12].
28
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ührungslose Identifikation vor allem bei Wareneingangs-, Warenausgangs- und Inventurkontrolle steigern. Durch den Einsatz von RFID-Lesegeräten wie zum Beispiel RFIDToren 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 entnommen 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 Distributionszentren oder in Lagerhäusern ist es möglich, eine automatische und fehlerfreie 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 Bereichen im Lager aktiviert werden. Die Antwortsignale der Transponder werden wiederum 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].
29
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 Jahren zunehmend an Bedeutung. RFID bietet dabei enormes Potenzial, Rückverfolgbarkeitssysteme durch automatische Datenerfassung deutlich effizienter zu gestalten. Außerdem können die Prozesskosten und der Zeitaufwand bei eventuellen
Rückrufaktionen dadurch erheblich reduziert werden [Kel-07]. Obwohl die ProduktLevel-Identifikation durch RFID aufgrund der relativ hohen Transponderkosten heutzutage noch selten ist, ist die Idee, Transporthilfsmittel (Paletten, Behältern) durch
RFID zu identifizieren, in Forschung und Industrie schon verbreitet. Die Rückverfolgbarkeit 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 kettenübergreifender Prozess, an dem alle Unternehmen in der Lieferkette beteiligt sind.
Deswegen sollte man bei der Einführung von RFID-basierten Rückverfolgbarkeitssystemen 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 betrachtet wird.
30
Notwendigkeit zur Standardisierung des Auto-ID-basierten Datenaustausches in der
Lebensmittelkette
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 [Ele12]. In der Lebensmittelindustrie ist die Anwendung von Barcode basierend auf dem
EAN-System seit langem hoch standardisiert. Im Vergleich dazu ist die Standardisierung bei RFID-Anwendungen in der Industrie noch unzureichend, was die Implementierung ü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ückverfolgbarkeit in der gesamten Wertschöpfungskette ist die Unterstützung einer einheitlichen Datenstandards, wie bereits in Abschnitt 2.3.5 vorgestellt, zwingend erforderlich. Das EPCglobal, eine Non-Profit-Organisation unter GS1, entwickelt seit
2003 Standards für die weltweit einheitliche Nutzung der RFID-Technologie, vor allem für das UHF-System, das heute überwiegend in der Logistik und im SupplyChain-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 Nummernsystem zur weltweit eindeutigen Kennzeichnung von Objekten und gilt als Basis des gesamten Netzwerkes. Darauf basierend werden weitere Netzwerkkomponente und Schnittstellen vorgeschlagen, um die Vision des „Internet der Dinge“ zu
realisieren. Die Standardisierung der jeweiligen Komponenten hat in den letzten Jahren Interesse sowohl in der Industrie als auch in der Forschung geweckt. Einerseits
müssen die bestehenden Standards für unterschiedliche Anwendungsszenarien angepasst und erweitert werden, andererseits ist die Standardisierung noch nicht abgeschlossen und muss weiter entwickelt werden.
Im folgenden Kapitel wird das EPCglobal-Netzwerk vorgestellt. Es wird insbesondere auf die wichtigen Komponenten zum kettenübergreifenden Datenaustausch eingegangen. Aus der Untersuchung des Stands der Technik werden die Anforderungen an die Forschungsarbeit abgeleitet und die Forschungsziele konkretisiert.
31
32
Die Vision des EPCglobal-Netzwerkes
3
3.1 Die Vision des EPCglobal-Netzwerkes
Das EPCglobal-Netzwerk wurde ursprünglich am Auto-ID Center des MIT (Massachusetts Institute of Technology) wissenschaftlich konzipiert. Im Jahr 2003 wurde
die Non-Profit-Organisation EPCglobal als Nachfolgeorganisation des Auto-ID Centers gegründet. Zwei Jahre später wurde EPCglobal als Tochterunternehmen von
GS1, der international größten Organisation für Entwicklung von Standards zur Verbesserung von Wertschöpfungskette, übernommen, um das Konzept weiter zu entwickeln 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 Informationstransparenz 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 werden können. Daher ist es notwendig, die Standardisierung der Komponenten und
Schnittstellen mit Plattform-neutralen Sprachen oder Technologien wie zum Beispiel XML, SOAP, usw. zu beschreiben.
33
3 Das EPCglobal-Netzwerk
·
Offenes System
Die resultierenden Dokumentationen der Standardisierung sind offen und stehen
jedem zur Verfügung. Alle Unternehmen sowie Forschungsorganisationen können 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 Standardisierungen anwendungsspezifisch angepasst bzw. mit der Zeit immer weiter vervollstä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 Softwarekomponenten, deren Standards jeweils separat erarbeitet werden können. Dazu entwickelt
EPCglobal Spezifikationen sowohl für die Low-Level-Kommunikation wie zum Beispiel 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 Bedeutung:
·
Der Elektronische Produktcode
·
Der EPC Information Service
·
Der Object Name Service
·
Der Discovery Service
Im Folgenden werden diese Komponenten jeweils näher betrachtet.
34
Der Elektronische Produktcode
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 Datenträger für den EPC wird in der Regel ein UHF- oder ein HF-RFID-Transponder verwendet, 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, zusammengefasst.
35
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 Transporteinheiten 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 Lagerbereich 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 kennzeichnet, 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 Konsumartikel).
·
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 beträgt 44 Bits.
·
EPC-Manager: Kennzeichnung des Nummerngebers wie zum Beispiel des Herstellers, wird von GS1 vergeben.
·
Objektklasse: Kennzeichnung von Objektklassen und Typen.
·
Seriennummer: Eindeutige Kennzeichnung individueller Teile.
36
Der EPC Information Service
44 Bit
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 spezifiziert, sondern auch die Schnittstellen zur Erfassung bzw. zur Abfrage der Ereignisse definiert.
Die erfassten Transponder-Daten, die in EPCIS gespeichert sind, werden als EPCISEreignisse 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 „Wareneingangszone“.
·
Warum: Den Kontext der Datenerfassung wie zum Beispiel „geliefert“.
Der Standard hat insgesamt vier Ereignisse-Typen für unterschiedliche Anwendungsfälle definiert: das Objektereignis (ObjectEvent), das Aggregationsereignis
(AggregationEvent), das Quaititätsereignis (QuantityEvent) und das Transaktionsereignis (TransactionEvent). Jeder Ereignistyp erhält obligatorische und optionale
Attribute, in denen die „Was, Wann, Wo, Warum” Informationen abgespeichert werden. Neben den definierten Ereignissen und Attributen bietet der Standard noch Erweiterungsmöglichkeiten, damit neue Ereignisse und Attributen für unterschiedliche
Anwendungsszenarien eingefügt werden können.
37
Im EPCIS-Standard werden, wie schon vorgestellt, auch die Kommunikationsschnittstellen sowie ihre Bindungen nämlich ihre Umsetzungsmöglichkeiten spezifiziert (siehe Tabelle 3-2).
Die Erfassungsschnittstelle wird genutzt, um die EPC-Informationen von einer Erfassungsapplikation beispielsweise RFID-Middleware zur EPCIS-Datenbank (EPCISRepository) 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 EPCIS-Abfrage- und Steuerungsschnittstelle verwendet wird. Im Vergleich dazu arbeitet der asynchrone Modus mittels periodischer Abfrage. Das Abonnieren der Abfrage wird durch die EPCIS-Abfrage- und -Steuerungsschnittstelle etabliert. Die Übermittlung der periodisch generierten Antwort erfolgt mittels der EPCISRückmeldeschnittstelle. Zudem kann diese Rückmeldeschnittstelle verwendet werden, 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], [Kik11]}
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 EPCglobalNetzwerkes und ist vergleichbar mit dem Domain Name System (DNS) des Internets.
Über den DNS können Internet-Hostnamen mit den dazugehörigen IP-Adressen verknüpft werden. Eine ähnliche Funktion erfüllt der ONS im Rahmen des EPCglobalNetzwerkes. Über den ONS werden die Objektkennzeichnungen mit den entsprechenden EPCIS-Adressen der EPC-Manager (zum Beispiel Hersteller) verknüpft.
38
Der Discovery Service
Durch die Abfrage des Hersteller-EPCIS können Informationen zum Objekt abgerufen 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 EPCManagers 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 Identifier) 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, welcher 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 EPCISAdresse des EPC-Managers wie zum Beispiel des Herstellers, sondern auf alle EP39
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 Bedeutung.
Die Spezifikation für den Discovery Service ist bei EPCglobal noch unter Entwicklung. 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 diese zu implementieren sind.
Client
ONS
Discovery Service
Hersteller
EPCIS
Händler
EPCIS
Kunde
EPCIS
Abbildung 3-3: ONS vs. Discovery Service
3.7 Stand der Forschung
Das EPCglobal-Netzwerk bietet eine Standardisierungsplattform, die einen einheitlichen Einsatz von RFID-Technologien entlang der gesamten Lieferkette ermöglicht.
Die Softwarekomponenten, die in diesem Kapitel vorgestellt sind, spielen eine entscheidende 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-
40
Stand der Forschung
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 Forschungsarbeiten 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 Montageprozesse 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 Automobilbranche eingesetzt und untersucht.
Für die pharmazeutische Branche: GS1 in Großbritannien hat im Rahmen eines Pilotprojekts unter dem Forschungsverbund „BRIDGE“ [BRI-09] RFID und 2DBarcodes 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 verbessern 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 gestartet [GS1-12a]. Das Projekt hat zum Ziel, die pharmazeutischen Unternehmen auf die
„2015 state drug pedigree requirements“ vorzubereiten, die die eindeutige Identifikation von Medikamenten und Visibilität in der pharmazeutischen Kette in den USA
fordern. EPCIS hat eine zentrale Rolle im gesamten Informationssystem. Simulationsverfahren werden verwendet, um das System zu testen und zu evaluieren.
Für die TextilBranche: Im Rahmen des Arbeitspakets 7 unter dem Forschungsverbund „BRIDGE“ wurden die technischen Anforderungen für den Einsatz von RFID
41
und EPCIS in der Textilbranche analysiert [BRI-07a]. Dabei wurden Handlungsempfehlungen für die Implementierung des EPCIS entlang der gesamten Lieferkette,
vom Hersteller bis zur Verkaufsfläche, erarbeitet. Die dadurch gewonnenen Kenntnisse 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/RFIDTechnologie in Verbindung mit EPCIS zur Unterstützung der Lagerbewegungen sowie 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 elektronischen 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 beschä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 EPCISEinsatzes wird durch das Pilotprojekt getestet, außerdem haben die Projektergebnisse gezeigt, dass die verbesserte Visibilität in der Supply-Chain das Verbrauchervertrauen 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 (Selbstbedienungsfleisch) und Wurstwaren [PRO-07].
42
Stand der Forschung
Myhre stellt ein EPCIS-basierendes Rückverfolgungskonzept für die LebensmittelSupply-Chain vor [Myh-09]. In diesem Konzept wird das EPCIS „TransactionEvent“ 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ückverfolgbarkeitsinformationen mit EPCIS und UML-Statecharts [Tha-11]. Dabei werden zwei Szenarien in
der Lebensmittelindustrie, nämlich die Produktionsprozesse der gefrorenen Makrelen sowie die Nassmahlprozesse von Mais, als Beispiele verwendet, um diese Methodik zu veranschaulichen.
Die oben genannten Vorarbeiten zeigen, dass EPCIS großes Potenzial zur Steigerung der Transparenz und Rückverfolgbarkeit in der Lebensmittel-Supply-Chain bietet. Allerdings befassen sich die meisten Arbeiten meist noch auf konzeptionelle
Ebene mit speziellen Insellösungen. Der Aufbau und die Infrastruktur eines EPCISbasierenden 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 verteilten EPC-Informationen zu entdecken bzw. zu verketten. Im Rahmen des EPCglobalNetzwerkes spielt der Discovery Service, wie bereits im Abschnitt 3.6 erläutert, eine
entscheidende Rolle für diese Aufgabe. In den letzten Jahren wurden Forschungsarbeiten 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 Implementierung des Discovery Service präsentiert. Die vorgeschlagene Infrastruktur arbeitet
nach dem „Directory Look-up Approach“ [Lor-11]. Um das Konzept zu veranschaulichen, 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“ Mo43
dell, das „Notification-of-Clients” Modell und das „Query Propagation“ Modell als
mögliche Kandidaten zur Umsetzung des Discovery Service ausgewählt. Die Autoren 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 vorgestellt [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, verglichen. 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 Service, 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 Kontrollund 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 Service muss branchenspezifisch eingesetzt und nach Anwendungsbedarf angepasst
werden. Im aktuellen Projekt „RAN“ (RFID-based Automotive Network) wird ein kettenübergreifendes Informationssystem, der sogenannte „Infobroker“, für das RFIDbasierte Automobilnetzwerk aufgebaut. Die Konzipierung des „Discovery Service“ steht genau als zentrale Aufgabe für den Aufbau des „Infobroker“ und ermöglicht das Auffinden von verteilten EPC-Informationen in der Automobilkette [Pat-10].
Für die Lebensmittelbranche gibt es zurzeit allerdings noch kaum Forschungsarbeiten, 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 Forschungsziele dieser Arbeit wie folgt festgelegt:
·
Der EPCIS-Standard soll für die Lebensmittel-Supply-Chain angepasst und erweitert werden. Anhand eines Beispielszenarios wird verdeutlicht, welche EPCIS-
44
Konkretisierung der Forschungsziele
Events in der Logistikkette zu erzeugen sind und welche Erweiterungsmöglichkeiten bestehen.
·
Im Rahmen dieser Arbeit wird ein kettenübergreifendes Datennetzwerk für Tracking & Tracing in der Lebensmittelbranche konzipiert. Dabei wird ein Netzwerkdienst 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 konzipierten Netzwerkkomponenten für Tracking & Tracing in der LebensmittelSupply-Chain implementiert.
·
Das Ziel des EPC-basierten Netzwerkes besteht darin, die bestehende ITLandschaft in den Unternehmen zu ergänzen statt zu ersetzen, damit der Kostenaufwand gering gehalten wird. Im Rahmen dieser Arbeit ist es noch zu untersuchen, wie das EPC-Netzwerk in vorhandene/andere IT-Landschaften integriert
werden kann.
45
46
Das Konzept der Auto-ID gestützten Identifikation in der Lebensmittel-Supply-Chain
4
Konzept eines EPC-basierten Datennetzwerkes in
der Lebensmittel-Supply-Chain
Im Mittelpunkt der Arbeit steht die Konzeption eines EPC-basierten Datennetzwerkes 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 Beispielsszenarios das Konzept der Auto-ID gestützten Identifikation in der Lebensmittel-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 (Abschnitt 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 Lebensmittel-supply-Chain ausführlich beschrieben (Abschnitt 4.4). Um verteilte EPCIS-Daten
zu ermitteln bzw. zu verketten, wird im Rahmen dieser Arbeit ein Rückverfolgungsdienst 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
Den Ausgangspunkt eines durchgängigen Datennetzwerkes bildet die echtzeitige
Erfassung von Daten, die mittels geeigneten Identifikationssystemen in der Logistikkette 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 aufgebaut 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 Anforderungen an die Logistik, da die Kühlung auf dem gesamten Distributionsweg
47
4 Konzept eines EPC-basierten Datennetzwerkes in der Lebensmittel-Supply-Chain
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 entwickelt [Wan-11].
Zur Kostenreduktion und damit Effizienzsteigerung werden Kundenaufträge der Tiefkü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 CrossDocking. Unter Cross-Docking versteht man „einen Prozess innerhalb der logistischen 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 werden, 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ühlwaren besteht normalerweise aus drei bis vier Stufen. Dazu gehören: ein Hersteller
der Waren, ein Zentrallager, in dem die Waren kommissioniert werden, ein Regionallager 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 Distributionslager 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 normalen Transporthilfsmittel (THM) wie Palette oder Rollbehälter verwendet. Stattdessen sind isolierte THM wie zum Beispiel Tiefkühlbehälter notwendig.
Vollgut:
Leergut:
Filiale
Hersteller
Zentrallager
Regionallager
(Cross-Docking)
Abbildung 4-1: Beispielszenario der Tiefkühlkette
48
Filiale
Folgende Schwachstellen der herkömmlichen Tiefkühlkettelogistik lassen sich identizieren [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, verschwundene THM wieder zu finden. Außerdem besteht Unklarheit über die jeweiligen THMBestände an verschiedenen Lagerstandorten. Dadurch ist es nicht möglich, einen
optimierten Bestand zu halten und einen effizienten Austausch der THM zwischen verschiedenen Lagerorten zu ermöglichen. Die mangelnde Transparenz
der Materialflüsse führt letztlich zu höherem Bestandskosten, unnötigen Transportkosten, höherem Manuellaufwand, sowie dabei entstehenden Fehlerfolgekosten.
2. Ineffiziente und teilweise lückenhafte Kühlkettenführung
Die lückenlose Einhaltung der Kühlung und deren Überwachung sind entscheidende Voraussetzungen zur Sicherung der Lebensmittelqualität. Die Lebensmittelhändler haben sich bemüht, die gesetzlichen Anforderungen zu erfüllen, was
mit Mehraufwand wie z.B. manueller Temperaturkontrolle und Protokollen in Papierform 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 Informationsflü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 Ungleichheit 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 vorgenommen. Dazu gehören vor allem die Identifikations- und Kontrollvorgänge. So wird
beispielsweise die Vollständigkeit der Waren einer Lieferung von Mitarbeitern
49
manuell geprüft. Weiterhin werden erhobene Informationen papiergebunden protokolliert und erst später durch manuelle Eingabe in einem IT-System wie z.B.
SAP digitalisiert. Manuelle Arbeitsvorgänge sind nicht nur zeitaufwändiger sondern auch fehleranfälliger, woraus höhere Kosten resultieren.
5. Ineffiziente Rückverfolgbarkeitssysteme
Gemäß der EU-Verordnung (EG) Nr. 178/2002 sind alle Lebensmittelunternehmen 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 Warenein- und -ausgänge eines Unternehmens meistens in Papierform oder mit
internen Informationssystemen erfolgt und die Verkettung von Informationen entlang der gesamten Lieferkette lange Zeit dauern kann. Außerdem kann der Umfang einer Rückrufaktion wegen der fehlenden Identifikation von THM bzw. von
Verpackungskartons nur bedingt eingeschränkt werden. Falls Waren einer bestimmten 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 Arbeit ein Konzept der Auto-ID-gestützten Identifikation in der LebensmittelSupply-Chain vorgeschlagen. Dazu werden zunächst die zu identifizierenden Objekte 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 Ebenen 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 Identifikationssystems. Um eine vollständige Transparenz und eine komplette Rückverfolgbarkeit zu erzielen, ist die Identifikation auf Produktebene zu realisieren, das
heißt, jedes Produkt ist durch eine eindeutige Identifikationsnummer zu kennzeichnen. Da die bisherige Kennzeichnung aller Produkte in der Lebensmittelbranche
durch EAN-Artikelnummer und Chargennummer erfolgt, wird der Wechsel auf eine
50
Produktebene-Identifikation zu erheblichen Kosten wegen Informationsverwaltung
und Systemersatz führen [Kel-07].
In dieser Forschungsarbeit wird die Identifikation der Objekte in der Lebensmittellogistik 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 Konsumgü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 interessant, 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ückenlosen Überwachung der Umgebungstemperaturen entlang der logistischen Kette eingesetzt 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 Umverpackungsebene gelingt, ist noch offen. Die METRO Group testet seit Jahren die Verwendung 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
51
überbetrieblichen Koordination erhofft [Sma-12b]. Allerdings stehen beim Kartonebene-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ägliche Anwendung zu beheben sind [Bun-05]. Als Alternative können Verpackungskartons 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 Aufbau der Auto-ID-gestützten Supply-Chain ist die Festlegung der Identifikationspunkte 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 werden.
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 RFIDTemperaturlogger für die Tiefkühlbehälter eingesetzt werden, um Temperaturwerte
während des Transports mit aufzeichnen zu können. Die Identifikationspunkte werden durch RFID-Gate und Auto-ID Handheld umgesetzt. Während RFID-Gates für
automatische Warenannahme- und Versandt bei Wareneingangs- und Ausgangszonen eingesetzt werden, werden Auto-ID Handhelds im Konzept hauptsächlich verwendet, um die Beziehungen zwischen den logistischen Objekten zu kennzeichnen.
Die heutigen Auto-Handhelds auf dem Markt sind in der Lage, unterschiedliche Da52
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 Palette 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öglichen. In einer realen Umsetzung können die Identifikationspunkte auch durch andere als die hier im Konzept vorgeschlagenen Auto-ID Lösungen implementiert werden. Beispielsweise können Kartons auch mit RFID gekennzeichnet werden und der
Lesevorgang kann somit durch stationäre RFID-Reader statt Handhelds automatisiert werden. Trotz der Implementierungsunterschiede bleiben die zu erfassenden
Daten jedoch unverändert, was in den folgenden Abschnitten noch weiter diskutiert
wird.
53
Abbildung 4-3: Wichtige Identifikationspunkte in der Lebensmittel-Supply-Chain am Beispiel einer
Tiefkühlkette
54
Nummernsystem
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 Datenformate des EPC-Nummernsystems vorgestellt. Darauf basierend werden die zu verwendenden 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.
Informationssystem
Nur-Identitäts-URI
urn:epc:id:sgtin:4000001.000001.12345
Middleware-System
Transpondercodierungs-URI
urn:epc:tag:sgtin-96:0.4000001.000001.12345
RFID-Reader
Hexadezimalwert
3014F4240400004000003039
RFID-Transponder
Hexadezimalwert
3014F4240400004000003039
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
55
Darstellung wird der EPC in der Abbildung in Form von Hexadezimalwert statt Binärwert angezeigt.
Der Transpondercodierungs-URI ist für Low-Level-Anwendungen wie z.B. die RFIDMiddleware-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, erhalten 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 Darstellungsformat stellt nur die reinen Identifikationsinformationen zur Verfügung und wird in
Informationssystemen benutzt.
Da diese Arbeit sich mit dem Aufbau eines High-Level-Informationssystems beschäftigt, wird der Nur-Identitäts-URI im Rahmen dieser Arbeit als Datenformat verwendet, 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 Ablaufdatum identifiziert, was in der heutigen Lebensmittelindustrie zur Kennzeichnung
von Produkten weit verbreitet ist.
56
Nummernsystem
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 Objektklasse 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 Lieferung 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 SerialReference hat immer 17 Stellen.
57
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 unverä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 identifizierenden 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 Logistikkette überschneidungsfrei zu kennzeichnen. Die physische Lokation kann ein Unternehmensstandort 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.
58
Einsatz und Erweiterung des EPCIS-Standards für die Lebensmittelkette
4.3 Einsatz und Erweiterung des EPCIS-Standards für die Lebensmittelkette
Zum Aufbau eines EPC-basierten Datennetzwerkes spielt der Einsatz von EPCIS
eine zentrale Rolle. EPCIS hat die Aufgabe, erfasste Auto-ID-Daten mit Prozesskontext zu verknüpfen, in standardisierter Form zu speichern und zu High-LevelAnwendungen zur Verfügung zu stellen. Somit kann einerseits der Auto-ID-basierte
Datenaustausch zwischen Geschäftspartnern ermöglicht sowie erleichtert und andererseits 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 betrachtet. 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 EPCIS-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 erfasst werden.
2. Aggregationsereignis (AggregationEvent):
Ein Aggregationsereignis beschreibt die Aggregation bzw. die Trennung von Parent-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.
59
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 bestimmten Produkts zu erfassen.
4. Transaktionsereignis (TransactionEvent):
Ein Transaktionsereignis wird verwendet, um die Verknüpfung bzw. die Trennung
von physikalischen Objekten zu Businesstransaktionen dazustellen. Beispielsweise könnten einige Versandeinheiten, die jeweils durch einen EPC gekennzeichnet sind, mit einer Lieferung verknüpft werden.
Abbildung 4-6: UML-Diagramm für EPCIS-Ereignistypen [EPC-07b]
60
Neben den oben genannten vier Ereignistypen bietet der Standard noch die Möglichkeit, neue Ereignistypen nach Bedarf zu entwickeln. In der Automobilindustrie
wird beispielsweise ein neues Ereignis, nämlich das „AssemblyEvent“, vorgeschlagen [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 aufgehoben werden kann. Ein typisches Beispiel ist das Beladen und Entladen der Paletten 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 Fertigungsprozess 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 „ProductionEvent“ für die Lebensmittelproduktion einzuführen.
Da sich die Forschungsarbeit nicht mit den Produktionsprozessen in der Lebensmittelindustrie 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 Identifikationspunkten 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 EPCIS-Standard hat sowohl obligatorische als auch optionale Attribute definiert, die in
Tabelle 4-1 zusammengefasst und beschrieben werden.
61
Tabelle 4-1: Standardisierte EPCIS-Ereignisattribute
In der Lebensmittel-Supply-Chain werden die im Standard definierten Attribute weiter benutzt. Allerdings sind noch neue Attribute einzuführen, um branchenspezifische Anforderungen zu erfüllen. Im Folgenden werden die in dieser Forschungsarbeit vorgeschlagenen Attribute je nach Anforderung in der Lebensmittellogistik erläutert.
·
Produktkennzeichnung
Eine eindeutige Identifikation von Produkten in der Lebensmittel-Supply-Chain,
wie bereits diskutiert, ist wirtschaftlich noch nicht realisierbar. Die Produkte werden im Rahmen dieser Forschungsarbeit weiterhin mit der EAN-Nummer gekennzeichnet, die in der Industrie weit verbreitet ist. Des Weiteren werden noch
Chargennummer bzw. Ablaufdatum verwendet, um die Rückverfolgung von Produkten zu ermöglichen und gegebenenfalls den Umfang von Rückrufaktionen zu
beschränken. Da die EAN-Nummer (EAN_Number), die Chargennummer (lotNumber) 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“.
·
62
Temperaturüberwachung
Die Temperaturüberwachung spielt eine sehr wichtige Rolle für die Qualitätssicherheit 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 eingesetzt werden wie Tiefkühlbehälter, mit RFID-Temperaturlogger zu versehen.
RFID-Temperaturlogger können in der Regel in zwei unterschiedlichen Modi arbeiten: im kontinuierlichen Modus oder im Threshold-Modus. Während die Temperaturwerte im kontinuierlichen Modus in vordefinierten Intervallen ständig gemessen und abgespeichert werden, werden sie im Threshold-Modus nur bei
Überschreitung einer vordefinierten Grenze aufgezeichnet. Um die Temperaturbezogenen Werte bei beiden Modi zu integrieren, werden die folgenden Attribute
vorgeschlagen:
Temp, TempTime, TempOverThreshold, TempOverthresholdTime,
wobei die ersten beiden Attribute die Temperaturwerte und die Erfassungszeitpunkte 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 annehmen, 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 EPCIS-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 grundlegende Vokabelelemente und ihre möglichen Werte. Zudem gestattet der CBVStandard des Weiteren die Definition von neuen branchenspezifischen Vokabelelementen und die Einführung von neuen Werten für vorhandene Vorkabelelemente
[EPC-10]. In Tabelle 4-2 sind die in dieser Arbeit verwendeten Vokalbelelemente sowie ihre möglichen Werte für die Attribute „bizStep“ und „disposition“ dargestellt
und beschrieben.
63
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 Transparenz 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.
64
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 erfassenden EPCIS-Ereignissen anhand des Beispielsszenarios, das in Abschnitt 4.2.3 dargestellt 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 Lebensmittelkette spezifischen Prozesse wie die Rückverfolgung der Produkte und die
Temperaturüberwachung wird der EPCIS-Standard, wie bereits in Abschnitt 4.4.2
65
diskutiert, um die entsprechenden „Extensions“ erweitert, die ebenfalls in der Tabelle dargestellt sind.
4.4 Konzept eines Rückverfolgungsdiensts für die Lebensmittellogistik
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-LevelAnwendungen 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 EPCISDaten 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ückverfolgbarkeit 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 EPCglobalNetzwerks 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 stufenweise aufgerufen werden, damit das Tracking & Tracing ermöglicht wird.
66
Konzept eines Rückverfolgungsdiensts für die Lebensmittellogistik
Im Vergleich zu ONS verweist der Discovery Service nicht nur auf die EPCISAdresse des EPC-Managers, sondern auf alle EPCIS mit Informationen zum angefragten EPC.
Der Unterschied zwischen den beiden Methoden ist in Abbildung 4-7 illustriert. Daraus 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ückverfolgungsprozess nicht weiter fortgesetzt werden. Im Gegensatz dazu beeinflusst ein solches
Problem das Tracking & Tracing mittels Discovery Service weniger stark. Ist ein EPCIS ausgefallen, kann der Discovery Service doch noch die anderen EPCIS auffinden und erreichen [BRI-07b].
Im Rahmen dieser Forschungsarbeit wird daher ein Rückverfolgungsdienst aufgebaut, 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
67
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 Forschungseinrichtungen 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 bekommen.
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
68
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 vorgeschlagen, 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 Discovery Service“ Design, vorgestellt [Mül-10]. Bei diesem Ansatz werden die gefragten Informationen nicht von EPCIS-Server direkt an Client geschickt. Stattdessen werden sie zuerst im Discovery Service zusammengeführt, anschließend
werden die aggregierten Informationen werden gemeinsam an den Client zurückgesendet. Abbildung 4-8 zeigt die detaillierten Arbeitsschritte des „Aggregating Discovery Service“.
Service.
2. Der Discovery Service findet die entsprechenden EPCIS-Adressen und leitet
die Abfrage an die EPCIS-Server weiter.
69
zulässig, werden gefragte Informationen an den Discovery Service zurückgeschickt.
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 folgenden 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 Daten seiner eigenen EPCIS-Server besitzen. Dazu gehören EPCIS-Adresse, EPCIS-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.
70
·
Vertraulichkeit der Clientabfragen
Die Abfragedetails der Benutzer sollten nicht an unbeteiligte Dritte weiter gegeben 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 kontinuierlich 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 werden, 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 Kriterien wird in Tabelle 4-4 angezeigt (vgl. [Kür-08], [Mül-10], [Lor-11]).
71
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 jeweiligen EPCIS-Server. Das größte Problem bei diesem Design besteht darin, dass EPCIS-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 Discovery Service Zugangsrechte auf ihren EPCIS-Server einräumen, was zu erheblichem
administrativen Aufwand führen könnte, da sich die Geschäftsbeziehungen zwischen Unternehmen häufig ändern und somit die Zugangsrechte, die beim Discovery 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 schicken, 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 behalten Unternehmen Zugangskontrolle über ihre Daten. Der Nachteil besteht darin,
72
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 informiert 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 Kandidaten nicht nur einen sicheren Zugangsmechanismus, sondern bietet darüber hinaus geringe Client-Komplexität, da sowohl die Abfrage als auch die Aggregation
von Ergebnissen vom Discovery Service übernommen werden. Ein Problem bei diesem Design (auch bei dem Query Relay Design) besteht darin, dass die Vertraulichkeit der Clientabfragen nicht garantiert werden kann. Die Abfragedetails und das
Interesse von Clients können dadurch an Dritte übermittelt werden. Weiterhin besteht Unklarheit, welche Abfragen für Clients von Interessen sind und wie die Ergebnisse aggregiert werden können. Die bisherigen Forschungsarbeiten in der Wissenschaft haben sich mit diesen Fragestellungen noch nicht beschäftigt.
In dieser Forschungsarbeit wird ein Rückverfolgungsdienst für die LebensmittelSupply-Chain konzipiert [Wan-12]. Dieser Dienst basiert hauptsächlich auf dem Design des Aggregating Discovery Service, welcher erweitert bzw. für die Lebensmittelkette adaptiert wurde. In den folgenden Abschnitten wird sein Aufbau beschrieben.
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 EPCISServer 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 Informationen, wann das angefragte Objekt welche beteiligten Unternehmen verlassen hat
und wann es von welchen Unternehmen erhalten wurde. Das heißt, die sogenannten „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ückschicken, damit die Benutzer anhand der Adressen nach weiteren Informationen direkt bei den EPCIS-Servern abfragen können (Ressource-Abfrage).
73
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 Unternehmen in der Supply-Chain erfasst wird, überprüft der EPCIS-Server des Unternehmens, ob dieser EPC in seiner Datenbank zum ersten Mal auftaucht. Falls ja,
wird der EPCIS-Server diesen EPC beim Rückverfolgungsdienst über die Registrierungsschnittstelle registrieren. In der Datenbank des Rückverfolgungsdiensts werden EPCs zusammen mit den entsprechenden EPCIS-Adressen gespeichert. Sobald
eine Client-Abfrage für einen bestimmten EPC eingegangen ist, ermittelt der Rückverfolgungsdienst zuerst die entsprechenden EPCIS-Serveradressen, unter denen
der abgefragte EPC aufgetaucht ist. Anschließend bearbeitet der Dienst die ClientAbfrage und sendet Subqueries an die ermittelten EPCIS-Server basierend auf der
Abfrage- und Aggregationslogik. Nachdem alle Antworten von den jeweiligen EPCIS-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ückverfolgungsdienst. Benutzer könnten interessiert sein, ein Produkt, eine Karton (Umverpackung) 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. Produkte werden weiterhin durch EAN-Nummer, Chargennummer und Ablaufdaum gekennzeichnet, was heute in der Industrie weit verbreitet ist. Jedoch werden sie mit
74
den Verpackungskartons verknüpft werden, so dass Produkte auch durch das EPCNetzwerk rückverfolgt werden können.
Start
Tracing-Ebene?
Produktebene
Lokalen EPCIS abfragen
(z.B. Handel)
Abfrageparameter:
EQ_EAN_Number = <EAN_Number>,
EQ_Lot_Number = <Lot_Number>,
EQ_Expiry_Date = <Expiry_Date>
c
Erhaltene EPCs werden
mit Hilfe des Ermittlungsdiensts
weiter rückverfolgt
Kartonebene
THM-Ebene
Datenbank nach beteiligten EPCISURLs abfragen
Datenbank nach beteiligten EPCISURLs abfragen
Jeden beteiligten EPCIS abfragen
Jeden betreffenden EPCIS abfragen
Abfrageparameter:
eventType = AggregationEvent,
Match_epc = <epc>.
Parameter für die erste Abfrage:
MATCH_epc = <epc>,
EQ_bizStep = shipping.
Auf alle Antworten warten
ParentIDs als neue EPCs ermitteln
Jeden der EPCs rückverfolgen
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
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 empfangen 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 aggregiert und anschließend an die Clientanwendungen zurückgeschickt.
75
Um Kosten so gering wie möglich zu halten, erfolgt die Identifizierung auf Kartonebene in der Regel mittels Barcode statt mittels RFID. Zur Steigerung der Effizienz
der Logistik werden die Barcodes auf Verpackungskartons nicht bei jedem Warenein- 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 gekennzeichnet 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 abgefragten EPCs zu ermitteln. Die Parameter für die Abfrage sind: eventType = AggregationEvent, 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 vollstä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 gesamte Historie des abgefragten Objekts entlang der Lieferkette erhalten, ohne
selbst Abfragen zu organisieren und Antworten zu analysieren bzw. zu kombinieren.
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 RessourceAbfrage. 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önnen. Somit können die Vorteile des Discovery Service mit dem „Directory LookUp Design“ kombiniert werden.
4.5 Fazit
In den vorangegangenen Abschnitten wird ein Konzept für ein EPC-basiertes Datennetzwerk entwickelt. Nachdem das Nummernsystem anhand eines Beispielsszenarios festgelegt wird, wird auf den Einsatz und die Anpassung des EPCIS näher ein76
Fazit
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 EPCIS-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 Identifikation auf Umverpackungs- und Transporthilfsmittelebene erfolgt. Die Produkte werden dagegen weiterhin durch EAN-Artikelnummer und Chargennummer gekennzeichnet, weil der Wechsel auf eine eindeutige Identifikation der Produkte zu erheblichen Kosten führen kann und daher noch nicht realistisch ist.
77
78
5
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 Kundenabfragen visualisiert.
Bevor das Informationssystem aufgebaut wird, sind zunächst Testdaten zu erzeugen, 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 Evaluationszweck die mögliche Netzwerkverzögerung simuliert und analysiert (Abschnitt
5-3). Abschließend werden die Ergebnisse und Erkenntnisse dieses Kapitels zusammengefasst (Abschnitt 5.4).
5.1 Generierung realistischer EPCIS-Ereignisse durch Ablaufsimulation
5.1.1 Ziel der Ablaufsimulation
Um die Entwicklung von Informationssystemen zu unterstützen und ihren Prototypen zu testen, ist die Generierung von Testdaten von großer Bedeutung. Da die
konzipierten Auto-ID-gestützten Identifikationspunkte in der Lebensmittel-SupplyChain noch nicht existieren, ist es notwendig, realistische Daten (EPCIS-Ereignisse)
zu erzeugen, um so die Entwicklung eines EPC-basierten Datennetzwerkes zu ermöglichen.
Datengenerator ist ein häufig verwendetes Werkzeug für die Erzeugung von Testdaten in der Computerwissenschaft. Der Nachteil des Datengenerators darin, dass die
zeitlichen und räumlichen Abhängigkeiten der Logistikprozesse nicht dargestellt
werden können.
79
5 Umsetzung des Konzepts
Im Rahmen dieser Forschungsarbeit werden Methoden entwickelt, mittels derer realistische EPCIS-Ereignisse durch Ablaufsimulation generiert und in die ITInfrastruktur 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 implementiert werden muss.
2. Die zeitlichen und räumlichen Prozessabhängigkeiten können durch die Ablaufsimulation 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 vergleichbaren Ablaufsimulationen in der Forschung wurden bisher dazu verwendet, die
Leistungskennzahlen der Supply-Chains vor und nach dem Einsatz von Auto-IDTechnologie 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
DiskreteEreignissimulation in Simul8 beleuchtet [Bot-08]. Der EPC-Datenfluss wurde durch
dieses Simulationsmodell generiert und für eine Analyse der LogistikLeistungskennzahlen verwendet. Ein anderer Forschungsansatz hat mit Hilfe der
Ablaufsimulation realitätsnahe EPCIS-Ereignisse für die pharmazeutischen SupplyChains 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 realistische EPCIS-Ereignisse nach dem vorgeschlagenen Konzept in der LebensmittelSupply-Chain zu generieren. Außerdem werden die generierten EPCIS-Ereignisse
durch eine in diese Arbeit entwickelte Methode in Echtzeit an das Informationssystem weitergeleitet, so dass der Informationsaustausch dadurch besonders realitätsnah abgebildet wird und somit die Entwicklung funktionsfähiger Software-Module
unabhängig von der Hardwareinfrastruktur ermöglicht werden kann.
80
5.1.2 Entwicklung des Simulationsmodells
5.1.2.1 Simulationsumgebung
Zur Generierung realistischer EPCIS-Ereignisse wird im Rahmen dieser Forschungsarbeit 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 Modellierung 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 Grundbausteinen 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 Standardbausteine 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 Simulation für individuelle Erweiterungen offen und die Integration in andere Informationssysteme sind dadurch möglich.
81
5.1.2.2 Modellaufbau
Ziel des Simulationsmodells soll sein, wie bereits beschrieben, realistische EPCISEreignisse 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 Stufen 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 erfüllt. Das Netzwerk ist Grundlage aller Modelle. Durch die Verwendung des Netzwerkes sind Supply-Chain-Beteiligte in der jeweiligen Stufe nur einmal zu implementieren. 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 Änderung an dem Basisnetzwerk automatisch auf alle abgeleiteten Netzwerkkomponenten übertragen wird. So können im Nachhinein Prozesse in allen abgeleiteten Komponenten 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 Funktionsbereichen 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 programmiert, 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 mittels Standardbausteinen modelliert. Weiterhin werden Identifikationspunkte wie
82
das RFID-Gate durch den Baustein „Einzelstation“ dargestellt und in den Prozessen 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 EPCISServer neue erfasste EPCs zusammen mit ihren EPCIS-Adressen beim Rückverfolgungsdienst 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 EPCIS-Ereignisse wird im folgenden Abschnitt ausführlich eingegangen.
83
Abbildung 5-1: Das Simulationsmodell in Plant Simulation
84
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 bilden.
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 Standardbaustein Quelle generiert. Die Bezeichnung CompanyPrefix wird als globale Variable umgesetzt, 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 verwendet. Um eine eindeutige SGTIN für jeden Karton zu vergeben, wird eine Einzelstation verwendet und eine Methode programmiert, die den Etikettierungsprozess
abbildet. Sobald ein Karton die Einzelstation verlassen hat, wird die Methode aufgerufen, 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 Anwendungsfall nachträglich angepasst werden.
85
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 identifiziert. Weiterhin werden sie bei jeder Lieferung jeweils mit einer SSCC (NVE) versehen. 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 unterscheiden. Da die Gesamtlänge aus CompanyPrefix und AssetType immer zwölf Stellen 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 verwendet.
Abbildung der Identifikationspunkte
Die Identifikationspunkte werden in der Simulation mittels des Grundbausteins „Einzelstation“ abgebildet. Eine Basisklasse wird dafür erstellt, von der alle Identifikationspunkte abgeleitet werden können.
Abbildung 5-3: Benutzerdefinierte Attribute für den Baustein „Identifikationspunkt“
86
Zur Generierung standardkompatibler EPCIS-Ereignisse enthält jeder Identifikationspunkt-Baustein folgende benutzerdefinierte Attribute: action, bizLocation, bizStep, 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 Attribute werden in der Basisklasse definiert und können in den abgeleiteten Bausteinen 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 Methodenbausteine erstellt, die die XML-Schnittstelle aufrufen und alle relevanten Daten in eine XML-Datei serialisieren. Sobald ein Objekt einen IdentifikationspunktBaustein 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 EPCISEreignisse werden dadurch Zeile für Zeile geschrieben. Dabei ist die XMLSchnittstelle zum Schreiben zuerst zu öffnen, woraufhin die XML-Elemente zeilenweise geschrieben werden. Dazu gehören zunächst die Kopfdaten, die den verwendeten 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 Hierarchiestufe, wie beispielsweise die Kartons, die auf die Palette geladen werden. Im Vergleich 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.
87
Start
Start
Start
XML-Schnittstelle öffnen
XML-Kopfteil schreiben
(Namespace, CreationDate,
SchemaVersion)
XML-Kopfteil schreiben
SchemaVersion)
XML-Kopfteil generieren
SchemaVersion)
XML-Datenteil generieren
„AggregationEvent“ als
Elemente schreiben
„ObjektEvent“ als Elemente
schreiben
„QuantityEvent“ als Elemente
schreiben
„ParentID“ als Elemente
schreiben
„epcList“ als Elemente
schreiben,
i-er EPC schreiben
(Anfangswert i=1)
i=i+1
„epcClass“ als Elemente
schreiben
„ChildEPCs“ als Elemente
schreiben,
i-er ChildEPC schreiben
(Anfangswert i=1)
i=i+1
i <=n?
(n=Anzahl der
EPCs)
Ja
Nein
i <=n?
(n=Anzahl der
ChildEPCs)
Ja
„Quantity“ als Elemente
schreiben
Quantity = Anzahl der BEs im
Lager
Nein
Andere EPCIS-Attribute als
Elemente einfügen
Elemente schreiben
Elemente schreiben
Ja
Ja
Ja
Weitere Attribute
vorhanden?
Weitere Attribute
vorhanden?
Weitere Attribute
vorhanden?
Nein
Nein
Nein
XML-Schnittstelle schließen
b) AggregationEvent
c) QuantityEvent
a) ObjectEvent
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 AutoID-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 generierten EPCIS-Ereignisse ist in Abbildung 5-4 dargestellt.
88
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 Umgebung umsetzt. Die Architektur des Systems ist in Abbildung 5-5 skizziert.
89
Abbildung 5-6: Architektur des Informationssystems
Das System besteht aus einem Rückverfolgungsdienst, mehreren EPCIS-ServerInstanzen 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 eingesetzt. 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 implementiert wurde und die die EPCIS-Ereignisse abspeichert; b) einer Erfassungsschnittstelle, die die EPCIS-Ereignisse in der Datenbank erfasst; c) einer Abfrageschnittstelle, über die Kundenabfragen nach EPCIS-Ereignissen erfolgen können.
Die Komponenten sind standardkonform implementiert und werden daher zum Aufbau jeder EPCIS-Instanz eingesetzt.
Um generierte EPCIS-Ereignisse durch Plant Simulation an das Informationssystem
weiterzuleiten, wurde im Rahmen dieser Arbeit ein Schnittstellenprogramm entwickelt. Die Softwarelogik überträgt die EPCIS-Ereignisse direkt an die Erfassungs90
schnittstelle von EPCIS per HTTP/Post, sobald diese in der Simulation erzeugt werden (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 aufgebaut und somit die Entwicklung funktionsfähiger High-Level-Applikationen unabhä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öpfungskette 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 Programm, das als Registrierungsdienst bezeichnet wird, im Rahmen dieser Arbeit entwickelt.
Der Ablauf des Registrierungsprozesses ist in Abbildung 5-7 dargestellt. In der Simulation wird der Registrierungsdienst in einem vordefinierten Zeitabstand in der
Simulation aufgerufen, der je nach Anwendungsbedarf nachträglich angepasst werden kann. In einer realen Umsetzung können Unternehmen entscheiden, zu welcher
Zeit sie ihre Daten beim Rückverfolgungsdienst registrieren. Der Registrierungs91
dienst fragt die einzelnen EPCIS nach neuen erfassten EPCs ab. Falls neue EPCs im
vorangegangenen Zeitintervall in einen EPCIS aufgenommen wurden, wird der Registrierungsdienst diese EPCs zusammen mit dem entsprechenden EPCIS-URL in
eine XML-Datei serialisieren und an den Rückverfolgungsdienst weiterleiten. Die Daten werden per Registrierungsschnittstelle aufgenommen und geparst. Danach werden 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
EPCs und EPCIS-URL in eine XML-Datei serialisieren
Daten registrieren
XML parsen
Daten abspeichern
Bestätigung
Abbildung 5-8: Ablauf des Registrierungsprozesses beim Rückverfolgungsdienst
5.2.3 Clientapplikation
Der Rückverfolgungsdienst wurde nach dem Konzept implementiert, das in Abschnitt 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 weiterzuleiten. Andererseits akzeptiert sie die aggregierten Antworten des Rückverfolgungsdiensts und stellt sie auf Google-Maps-Karten dar. Google Maps bietet eine Vielzahl
92
von APIs (Application Programming Interface), mit denen man Google-Karten in eigene Webseite und eigene Anwendungen einbetten kann. Die APIs werden in JavaScript 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ückverfolgung, die unterste und komplizierteste Verfolgungsebene aufweist, angezeigt.
Nutzer werden aufgefordert, die EAN-Nummer, die Chargennummer und das Ablaufdatum 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 Abfrage- und Aggregationslogik, die in Abschnitt 4.5.4 beschrieben wurde, und die zurückkommenden Ergebnisse werden auf Google-Maps in der Clientapplikation visualisiert. 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 Informationen abgerufen werden.
93
Abbildung 5-9: Screenshots von der Clientapplikation
94
Evaluation
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ögerung 𝑑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 (normalerweise in der Größenordnung von Mikrosekunden oder noch darunter) ist und hier
vernachlässigt werden kann. Die gesamte Netzwerkverzögerung 𝑑 ist daher mit folgender Formel zu berechnen:
𝑑 = 𝑑p + 𝑑t + 𝑑q
(5-1)
Die Ausbreitungsverzögerung resultiert aus der Entfernung zwischen Rückverfolgungsdienst und EPCIS-Server (𝐷) sowie aus der Geschwindigkeit mit der sich Datenpakete ausbreiten (𝐶):
𝑑p = 𝐷/𝐶
(5-2)
Die Übertragungsverzögerung ist durch die Bandbreite 𝐵 und die Paketgröße 𝐿p bestimmt:
𝑑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 Subquery 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.
95
Strategie (First In, First Out) arbeitet, wird die Warteschlagenverzögerung durch die
folgende Formel berechnet:
𝑑q =
1   


2  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 Ausbreitungsgeschwindigkeit gleich der Lichtgeschwindigkeit ist, die 2.998 x 108 m/s
beträgt. Zudem wird angenommen, dass die Entfernung zwischen Rückverfolgungsdienst 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 EPCISServern für einzelne Abfragen
Wie Abbildung 5-9 zeigt, hängt die Netzwerkverzögerung von der Zugangsbandbreite des Rückverfolgungsdiensts und der Anzahl der Abfragen pro Zeiteinheit ab. Laut
einem Netzwerkmodell hat der Rückverfolgungsdienst maximal 1000 Clientabfragen
96
Fazit
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 Informationssystem 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 Lebensmittelkette 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 Lieferkette 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.
97
98
Integrationskonzept
6
Integration des EPC-Netzwerkes in vorhandene/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ängig zu unterstützen und andererseits gleichzeitig die entsprechenden Wartungskosten 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 Lebensmittel-Supply-Chain. Durch seine beschränkten Funktionalitäten kann es allerdings 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öglichkeit des EPC-Netzwerks in vorhandene/andere IT-Landschaften schwerpunktmäßig untersucht. Dazu wird zunächst das Konzept für die Integration vorgestellt.
Darauf basierend wird die Integration am Beispiel eines Behältermanagementsystems veranschaulicht. Zum Schluss werden die Erkenntnisse dieses Kapitels zusammengefasst.
6.1 Integrationskonzept
Das EPC-Netzwerk, vor allem der EPCIS Standard, bietet eine Möglichkeit, detaillierte 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 bestehende ERP-Systeme basierend auf den EPC-Daten komplett umzubauen, da traditionelle 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
99
6 Integration des EPC-Netzwerkes in vorhandene/andere IT-Landschaften
beispielsweise Bestellungsprozesse oder Prognosen durch EPCIS-Ereignissen nicht
oder nur schwierig zu realisieren.
Als Integrationskonzept wird daher vorgeschlagen, neben der vorhandenen ITInfrastruktur ein EPCIS-Repository im Unternehmen aufzubauen, das die EPCInformationen 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 EDIKommunikation zwischen Geschäftspartnern, die in Abschnitt 2.3.2 bereits vorgestellt, beibehalten werden. EPCIS bietet die Möglichkeit, Auto-ID-basierte Daten auf
einem standardisierten Weg auszutauschen. Allerdings erhält er keine Geschäftsdaten 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
EDI
Andere Geschäftspartner
ERP-Systeme
EPC-Netzwerk
EPCIS
Rückverfolgungs
-dienst
Middleware
Auto-ID Infrastruktur
Abbildung 6-1: Konzept zur Integration des EPC-Netzwerkes in Unternehmens-IT
100
Für die Integration spielt die Middleware eine entscheidende Rolle. Middleware existiert als „Ebene in einem komplexen Softwaresystem, die als Dienstleister anderen
ansonsten entkoppelten Softwarekomponenten Services bereitstellt und den Datenaustausch 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ältermanagementsystems
Um die Integration darzustellen, wurde daher im Rahmen der vorliegenden Arbeit als
Beispiel ein RFID-basiertes Behältermanagementsystem entwickelt, das in folgenden 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 [Gum06] (nachstehend einfach „Behälter“ genannt), das eine äußerst wichtige Aufgabe
und Herausforderung im Supply-Chain-Management darstellt. Gerade in der Lebensmittel-Supply-Chain werden für den Transport von Lebensmittelprodukten verschiedene 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 Versorgungssicherheit häufig trotz alledem nicht gewährleistet werden kann [Hof-06].
Um Behälterkreisläufe besser zu steuern, kommt das IT-gestützte Behältermanagementsystem (BMS) zum Einsatz. Die Hauptaufgabe des BMS liegt darin, Behälter101
bewegungen im IT-System möglichst genau abzubilden und dadurch eine effiziente
Steuerung und Überwachung von Behälterflüssen zu erzielen. BMS lassen sich verschieden einsetzen. Entweder wird das BMS direkt in den bestehenden ERPSystemen der beteiligen Unternehmen abgebildet, oder es wird als eigene ITAnwendung umgesetzt, die in der Regel Daten über Schnittstellen mit den ERPSystemen austauschen kann. Traditionelle BMS haben zwar die Funktionen, Behälterbewegungen zu erfassen, allerdings erfolgt die Erfassung meist per manueller
Eingabe, was nicht nur zeitintensiv und fehleranfällig ist, sondern auch zu Unterschieden 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öglicherweise auch Sonderfahrten verursacht. Um die oben genannten Probleme zu
vermeiden, sollten entsprechende Identifikationssysteme und IT-Infrastrukturen eingesetzt werden, die eine eindeutige Identifikation der Behälter sowie eine rechtzeitige 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 ITLandschaften wurde daher im Rahmen der vorliegenden Arbeit als Beispiel ein
RFID-basiertes Behältermanagementsystem entwickelt. Zudem wurde ein Demonstrationsmodell 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
102
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älterbewegungen 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 automatisch zu aktualisieren. Ein BMS soll außerdem in der Lage sein, Bestände der Ladungsträ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älterschwund vermieden werden und die Identifikation sowie die Lokalisierung von Behä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 verschiedener 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 technische Anforderungen zu berücksichtigen. Die Behälterflüsse werden im Rahmen dieser vorliegenden Arbeit, wie bereits im letzten Abschnitt erwähnt, durch ein Demonstrationsmodell illustriert, um die Funktionalitäten des BMS anschaulich darzustellen. Allerdings soll das BMS offene Schnittstellen nach außen bieten und unabhä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 einsetzbar sein. Des Weiteren wird EPCIS in diese Software integriert, um einerseits die
Integration des EPC-Netzwerkes zu illustrieren und andererseits das Tracking & Tracing der Behälter zu vereinfachen, um das BMS zu optimieren. Letztendlich sollen
Nutzerfreundlichkeit und die Erweiterbarkeit des Systems bei der Entwicklung berücksichtigt werden. In Tabelle 6-1 sind die oben diskutierten funktionalen und technischen Anforderungen zusammengefasst.
103
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 beschrieben, 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 notwendig, da alle Funktionalitäten der Software über Webbrowser angezeigt und benutzt werden. Die Software wird mit Java implementiert und als konkrete Technologie 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 Applikationsframework anzubieten und die Komplexität der Entwicklung von Java-Anwendungen zu reduzieren (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 Datenbankinhalten objektorientiert zu arbeiten (Siehe: http:// www.hibernate.org).
104
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ändern, Achsen usw.) bietet Lego Mindstorms eine ideale Lösung für den Aufbau des
Demonstrationsmodells. Um eine flexible Programmierung der Bausteine zu ermöglichen, wird anstelle der vorinstallierten Lego Firmware die Open-Source Alternative
leJOS verwendet. LeJOS bietet die Möglichkeit, die Legosteine mit Java zu programmieren. Dadurch können einerseits verschiedene Funktionalitäten des Systems
flexibel eingesetzt und andererseits der Datenaustausch mit außenstehenden Komponenten oder Softwares ermöglicht werden.
Das Modell enthält drei Stationen, die über einen LKW Behälter untereinander verschicken 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 einbzw. ausgelagert werden. Abbildung 6-3 zeigt das fertiggestellte Demonstrationsmodell. Die Einzelheiten zu seinem Aufbau werden in Kapitel 6.3.5 noch näher betrachtet.
Zum Demonstrationszweck werden Behälterflüsse durch das Lego-Modell illustriert.
Das BMS kann prinzipiell mit anderen RFID-Hardwares interagieren, da die Kommunikation 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.
105
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 illustriert darstellen.
Der Zentralserver, der die Aufgabe hat, die Geschäftslogik zur Abwicklung der
Transportaufträge sowie anderer Funktionalitäten des BMS zu implementieren, bietet 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.
106
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 Kommandos über die USB-Verbindung an die Hardware weiterleitet und sich beim ZentralServer 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
107
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 demonstrierten System übernehmen die einzelnen StationServer die Aufgabe der Edgeware
und der ZentralServer die Aufgabe der Middleware. Die Middleware verknüpft einerseits 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 verbesserte Tracking & Tracing der Behälter, allerdings werden die anderen Funktionalitä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 unternehmensü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 vorgestellt, mittels Lego implementiert. Das Demonstrationsmodell besteht aus drei
Stationen, die untereinander Behälter transportiert von einem LKW verschicken können. Das Modell wurde modular aufgebaut und daher ist ein Hinzunehmen weiterer
Stationen durch Konfigurationsänderungen ohne große Änderung der Programmiercodes 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örderbänder zu steuern und dadurch Behälter automatisch einbzw. 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.
108
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 werden, ob sich der LKW vor der Station befindet. Durch Kombination mit dem Infrarot-Sensor kann der LKW an geeigneten Stellen in Bezug auf entsprechende
Transportaufträge gestartet und gestoppt werden. Des Weiteren kann der Ladevorgang 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 RFIDSensor, der von einem Dritthersteller für Lego-Mindstorms produziert wird, verwendet. 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 andererseits 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 softwareseitig 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) Behälter. Je nach Farbe werden entsprechende Temperaturdaten während des
Transports im System simuliert. Es wird davon ausgegangen, dass die Temperaturdaten in der Praxis durch integrierte Sensoren im RFID-Transponder an jedem
Behälter aufgezeichnet werden.
109
1
3
4
3
3
2
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 Transportaufträ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 transportierende 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 „Warenausgang“. 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 Wareneingangsprozess werden die Behälter wiederum durch einen RFID-Reader erfasst
und dabei entsprechende Leseereignisse erzeugt. Der Transportauftragsstatus ändert sich zu „Wareneingang“. Sind alle Behälter richtig und vollständig eingelagert,
ist der Transportauftrag abgeschlossen.
110
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
·
·
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.
111
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 werden 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 besteht 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 werden, 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 Benutzer aufgefordert wird, die Ausgangsstation und die Zielstation auszuwählen. Zudem 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 werden.
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).
112
Aktueller Zustand des
Transportauftrags
Manuelle Zustandsänderung möglich
Abbildung 6-9: Transportauftragsübersicht
Abbildung 6-10: Anlegen von neuen Transportaufträgen
113
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 Station 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
114
Tracking & Tracing
Unter „Tracking & Tracing“ kann der Benutzer die integrierte EPCIS-Datenbank abfragen, um eine Übersicht über die „Was, Wann, Wo, Warum“ Informationen des
betreffenden Behälters zu erhalten. Dazu wählt der Benutzer zunächst die EPCNummer des Behälters (GRAI) aus. Zusätzlich kann der Zeitraum der Datenabfrage
weiter eingegrenzt werden. Durch Klick auf „Abfrage ausführen“ werden die EPCISDaten 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 ermöglicht (Abbildung 6-13).
Abbildung 6-13: Tracking & Tracing der Behälter durch EPCIS
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).
115
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 anpassen. Dazu gehören die EPC-Nummer des Behälters, der zugehörige Standort,
der Behältertyp, der Zustand (einwandfrei, defekt oder verschmutzt) sowie die Abmessungen des Behälters (Abbildung). Unter „Stationsdaten“ werden die Daten der
Behälterstandorte verwaltet. Dazu kann der Benutzer sowohl neue Standorte anlegen, wie auch Änderung für vorhandene Standorte nach Klick auf ihre Namen vornehmen (Abbildung 6-15).
Abbildung 6-15: Stammdatenverwaltung - Behälterdaten
116
Fazit
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 Lebensmittel-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 Kommunikationsschnittstelle 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.
117
118
Zusammenfassung
7
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 beschäftigt die Lebensmittelindustrie mehr als vier Millionen Menschen in rund 310 000
Unternehmen [Man-13]. Wegen des großen Konkurrenzdrucks sind viele Unternehmen heute gezwungen, nach innovativen Lösungen zur Optimierung ihrer Produktions- und Logistikprozesse zu suchen, um sich dadurch Wettbewerbsvorteile zu sichern. Die Verbesserung der Informationslogistik ist hier von großer Bedeutung.
Im Vergleich zu anderen Branchen stellt die Lebensmittelindustrie höchste Anforderungen an Produktsicherheit und –qualität. Lebensmittelskandale in den letzten Jahren haben massive Umsatzeinbußen und einen Imageschaden der Lebensmittelindustrie verursacht und die Verbraucher zutiefst verunsichert. Anhand von Lebensmittelkrisen lässt sich erkennen, dass ein effizientes Rückverfolgbarkeitssystem und
eine verbesserte Informationstransparenz eine entscheidende Rolle spielen, um einen schnellen und gezielten Warenrückruf zu ermöglichen, um das Ausmaß von Lebensmittelkrisen einzuschränken bzw. zu verhindern.
Viele Unternehmen haben zwar Rückverfolgbarkeitssysteme eingerichtet, die Dokumentation sowie die Informationsweitergabe finden bei vielen Systemen noch in Papierform statt, was zu Fehlern und Zeitverlust bei der Problemsuche und bei Rückrufaktionen 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 weite Verbreitung des Auto-ID-Einsatzes. Im Vergleich zu Barcode ist die Standardisierung bei RFID noch unzureichend umgesetzt, was die Implementierung kettenübergreifende Anwendungen erschwert.
Das im Rahmen dieser Arbeit konzipierte Datennetzwerk hat zum Ziel, den oben genannten Problemen zu begegnen. Der Elektronische Produktcode (EPC) wurde als
Nummernsystem eingesetzt, was die Basis für den Aufbau des gesamten Netzwerkes bildet.
119
7 Zusammenfassung und Ausblick
Zum Aufbau des Datennetzwerkes spielt der Einsatz des EPC Information Service
(EPCIS) eine zentrale Rolle. EPCIS hat die Aufgabe, erfasste Auto-ID-Daten mit Prozesskontexten zu verknüpfen, in standardisierter Form abzuspeichern und zu HighLevel-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 Einsatz des EPCIS-Standards in der Lebensmittel-Supply-Chain näher betrachtet. Dabei wurde die einzusetzenden EPCIS-Ereignistypen, -Attributen und –
Vokabelelemente sowie ihre Erweiterungsmöglichkeiten in der Lebensmittel-SupplyChain 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 Beitrag dazu leisten, die Anwender bei der Implementierung von EPCIS in der Lebensmittelbranche 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übergreifende EPCIS-Daten zu entdecken bzw. zu verketten, welche die Rückverfolgbarkeit und die Transparenz in der Lebensmittel-Supply-Chain erhöhen.
Das in dieser Arbeit erstellte Konzept wurde in einer simulierten Umgebung implementiert, um ein „Proof of Concept“ zu erstellen. Das aufgebaute Informationssystem 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 Lebensmittelkette effizient zu verfolgen und die „Wann, Was, Wo, Warum“ Informationen
über die Objekte auf einzelnen EPCIS-Servern zu ermitteln. Da das System auf lokalen 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 Erkenntnisse dieser Arbeit dem Fachpublikum in Form von Liveführungen vorgestellt werden. Eine Umsetzung des Konzepts in der Industrie setzt voraus, dass RFID zur eindeutigen Identifikation der Objekte in der Lebensmittelbranche umfassend eingesetzt wird, was in der Zukunft durchaus vorstellbar ist.
120
Ausblick
7.2 Ausblick
Das EPC-basierte Datennetzwerk kann einen wichtigen Beitrag leisten, Auto-IDDaten 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 bewä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ückverfolgungsdienst hinterlegen darf, bedarf der Entwicklung.
Wie bei vielen anderen Technologien besteht auch hier die Notwendigkeit, eine Kosten-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 entsprechende 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 Lebensmittel-Supply-Chain betrachtet. Bei zukünftiger Forschung könnten Produktionsprozesse mitberücksichtigt werden, um das Konzept zu erweitern.
Das in dieser Arbeit konzipierte EPC-basierte Datennetzwerk ist prinzipiell auf andere 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 erweitern, wie beispielsweise die Abfrage- und Aggregationslogik des Rückverfolgungsdiensts. Ein industrieller Einsatz setzt des Weiteren die Etablierung einer gemeinsamen 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.
121
7 Zusammenfassung und Ausblick
122
[aer-11]
aerzteblatt.de:
Deutsche Bauern fordern wegen EHEC-Krise 16 Millionen Euro,
2011. URL: http://www.aerzteblatt.de/nachrichten/46677/DeutscheBauern-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 Networks. In: International Conference on Management of Data, COMAD 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 Research, 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 Environment. 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/rfidlesegeraet.html (Aufruf am 15.11.2012).
123
[Buc-11]
Buck, T.:
Wirtschaftlichkeitsvergleich zwischen RFID vs. WBS für eine Hallenneuplanung 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.dhldiscoverlogistics.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/Fleischskandalbetrifft-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).
124
[Ele-12]
Electronic Commerce Network:
Standardisierung der RFID Systeme, 2012. URL: http://www.ecnet.de/EC-Net/Navigation/Themen/radiofrequenzidentifikation,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. Herausgegeben von: GS1, 2007.
[EPC-09a]
EPCglobal:
The EPCglobal Architecture Framework - Final Version 1.3. Herausgegeben von: EPCglobal, 2009.
[EPC-09b]
EPCglobal:
EPC-Informationsservices (EPCIS) und Umsetzung im EPCShowcase. 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 Anforderungen 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/flaechendeckendeerfassung-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.
125
[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 induktiver 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 SupplyChain in der Lebensmittelindustrie durch einen Intelligenten Behälter" im Forschungsverbund FORFood. Herausgegeben von: Lehrstuhl 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. Betreut 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.
126
[Gam-06]
Gampl, B.:
Rückverfolgbarkeit von Lebensmitteln. 1 Auflage. Göttingen: Cuvillier, 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 - ProzessStrukturen, IT-Architekturen, RFID-Infrastruktur. München [u.a.]:
Hanser, 2007.
[Gro-10]
Gronau, N.:
Enterprise resource planning - Architektur, Funktionen und Management von ERP-Systemen. 2 Auflage. München: Oldenbourg,
2010.
[GS1-12a]
GS1 US:
2015 Readiness Pilots - Preparing for serialization and visibility within the U.S. pharmaceutical supply chain. Herausgegeben von: GS1
US, 2012. URL: http://www.gs1us.org/industries/healthcare/gs1healthcare-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 (Aufruf am 23.06.2013).
[Gun-11]
Gunnlaugsson, V. N.; Thakur, M.; Foras, E.; Ringsberg, H.; GranLarsen, Ø.; 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.
127
[Gün-11a]
Günthner, W. A.; Borrmann, A.:
Digitale Baustelle - innovativer Planen, effizienter Ausführen - Werkzeuge 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 UHFRFID-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. Maschinenwesen, 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; Lehrstuhl für Rechnernetze, Technische Universität Dresden, 2008. Betreut durch Dipl.-Medien-Inf. Eberhard Oliver Grummt.
[Hof-06]
Hofmann, E.; Bachmann, H.:
Behälter-Management in der Praxis - State of the Art und Entwicklungstendenzen bei der Steuerung von Ladungsträgerkreisläufen ;
[die St. Galler Behälter-Management-Studie]. Hamburg: Dt. Verkehrs-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 Lifecycle of Electronic Products. In: EU RFID Forum 2007. Brussels,
Belgium, 2007.
128
[Jan-04]
Jansen, R.; et al.:
Integration der Transpondertechnologie zur Erhöhung der Leistungsfä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. Herausgegeben von: RFID im Blick, 2010. URL: http://www.rfid-imblick.de/20100601644/rfid-standard-in-der-lebensmittelbranche-istsinnvoll.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-imblick.de/20100924786/rewe-und-mars-kooperieren-in-rfidprojekt.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 Kommunikationssystems für die Baulogistik. Dissertation; Lehrstuhl fml, Technische 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 Anwendungen. 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.
129
[Kut-08]
Kutz, M.:
RFID-Technologie: Einsatz und Implementierung in einem Handelsunternehmen. München: GRIN Verlag GmbH, 2008.
[Lau-10]
Laudon, K. C.; Laudon, J. P.; Schoder, D.:
Wirtschaftsinformatik - Eine Einführung. 2 Auflage. München, Boston, Mass. [u.a.]: Pearson Studium, 2010.
[Leb-03]
Lebensmittel Zeitung:
Streit um Pflicht- und Kürprogramm Rückverfolgbarkeit. Herausgegeben 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): Designing 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 intelligent 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ördermittel, 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. Herausgegeben 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/L
de/index.html (Aufruf am 18.02.2013).
130
[Met-09]
Metro Group:
RFID – Vom Pilot in den Alltag, 2009. URL:
http://metrobetriebsrat.wordpress.com/2009/08/06/rfid-vom-pilotin-den-alltag/ (Aufruf am 18.02.2012).
[Met-2008]
Metro Group:
Transparenz für die digitale Gesellschaft –RFID beschäftigt Wirtschaft und Politik. In: Metro Group, 2008.
Miles, S.; Sarma, S.; Williams, J.:
Modeling supply chain network traffic. In: RFID Technology and Applications: Cambridge University Press, 2008.
[Mil-08]
[mob-11]
mobile-tagging.blogspot.de:
Heinz Tomato Ketchup mit QR-Codes, 2011. URL: http://mobiletagging.blogspot.de/2011/09/heinz-tomato-ketchup-mit-qrcodes.html (Aufruf am 09.11.2012).
[Mot-12]
Motorola AG:
MC9090-Z RFID Handheld-Lesegerät, 2012. URL:
http://www.motorola.com/Business/XCDE/Business+Product+and+Services/Bar+Code+Scanning/Scanequipped+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 Realistic Test Data. In: First International Conference on Advances in System 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. Hawaii, 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 Technologies (RFID SysTech 2009). Bremen, Germany, 16 - 17 Jun., 2009.
[Ora-99]
Oracle Corporation:
Middleware und Integration. Herausgegeben von: Oracle Corporation, 1999.
[Pat-10]
Patocka, M.:
RAN-Newsletter. Herausgegeben von: RAN-Projektbüro, 2010.
131
[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 (ItemTagging 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. Herausgegeben 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/rfidlesegeraete-reader.html (Aufruf am 15.11.21012).
[San-06]
Sander, M.; Stieler, K.:
RFID, Geschäftsprozesse mit Funktechnologie unterstützen - Anwendungsbeispiele 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_ER
P_Operations.pdf (Aufruf am 25.09.2012).
[Sau-08]
Sauser, J.:
Gestaltung eines transponderbasierten Datennetzwerkes in der automobilen Supply Chain. Frankfurt am Main: Deutscher Fachverlag,
2008.
132
[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ährungswirtschaft, 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 Projekt; Lehrstuhl fml – wissenschaftlich / inhaltlich angeleitet und betreut 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. Verkehrs-Verl., 2005.
[Sma-12a]
SmaRTI:
Smart Reusable Transport Items, 2012. URL: http://www.smartrti.de/ (Aufruf am 18.12.2012).
[Sma-12b]
Smart NRW:
RFID auf Umverpackungen soll Konsumgüterindustrie revolutionieren, 2012. URL: http://www.exzellenz.nrw.de/iktneu/noth/clusterinfo/news/view/data/39861/backpid/11/ (Aufruf am
21.02.2013).
[Spe-01]
Spechtl, J.:
Electronic Commerce - Einsatzpotential in kleinen und mittleren Unternehmen. 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-chronologieder-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-inchina-13-000-kinder-nach-verzehr-verseuchter-milch-imkrankenhaus-a-579540.html (Aufruf am 02.12.2013).
[Tam-10]
Tamm, G.; Tribowski, C.:
RFID. Berlin, Heidelberg: Springer, 2010.
133
[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 EPCglobalkonformen Erweiterungen. Diplomarbeit; Fachbereich Design Informatik Medien, Fachhochschule Wiesbaden, 2006. Betreut durch
Prof. Dr. Werntges.
[Ulb-10]
Ulbrich, A.:
Simulationgestützte Grobplanung von Kommissioniersystemen. Dissertation; 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: Oldenbourg Verlag, 2012.
[VDI-4472 ]
VDI-4472:2010:
Blatt 12: Anforderungen an Transpondersysteme (RFID) zum Einsatz
in der Supply Chain - Einsatz der Transpondertechnologie zur Unterstützung der Rückverfolgbarkeit am Beispiel der Automobilen
Supply-Chain. VDI - Verein Deutscher Ingenieure.
[Wag-09]
Wagner, J.:
Technische Konzepte zur RFID-gestützten Bauzustandsdokumentation in der Automobilindustrie. Dissertation; Lehrstuhl fml, Technische Universität München. Garching, 2009. Betreut durch Günthner,
W. A.
[Wal-10]
Walenta, C. E.:
Die Bedeutung des Informationsaustausches innerhalb von Kooperationen. Institut für Transportwirtschaft und Logistik, Wirtschaftsuniversitä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.
134
[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 Automation 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, September 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 intelligenter Behälter in der Lebensmittel-Supply-Chain auf Basis logistischer
Prozessaufnahmen. Diplomarbeit; Lehrstuhl fml, TU München. Garching, 2011.
[Woo-52]
Woodland, N.; Silver, B.:
Classifying apparatus and method - US Patent 2,612,994. United
States Patent Office, 1952.
135
Verzeichnis betreuter Studienarbeiten
Im Zuge dieser Dissertation wurden verschiedene Studienarbeiten unter wissenschaftlicher und inhaltlicher Anleitung des Autors erarbeitet, aus denen teilweise Inhalte für diese Forschungsarbeit entstanden sind. Bei direktem Bezug der Inhalte
dieser Arbeit mit einer der Studienarbeiten, wird auf die entsprechende Studienarbeit 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-SupplyChain. Interdisziplinäres Projekt; Lehrstuhl fml – wissenschaftlich /
inhaltlich angeleitet und betreut von Rui Wang, TU München. Garching, 2011.
[Sch-12]
Schwaiger, S.; Stemplinger, M.:
Entwicklung und Demonstration eines RFID- und EPCIS-basierten
Behältermanagementssystems mittels Lego. Interdisziplinäres Projekt; Lehrstuhl fml – wissenschaftlich / inhaltlich angeleitet und betreut von Rui Wang, TU München. Garching, 2012.
136
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 [Gil07], [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
137
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 RFIDbasiertes BMS ................................................................................................. 102
Abbildung 6-3: Das Lego-basierte Demonstrationsmodell ..................................... 106
Abbildung 6-4: Gesamte Systemlandschaft des BMS ........................................... 107
138
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
139
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 [EPC11]) ..................................................................................................................... 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 EPCISEreignissen ........................................................................................................ 65
Tabelle 4-4: Vergleich verschiedener Discovery Service Design-Varianten .............. 72
140

pdf -Dokument - Lehrstuhl für Fördertechnik Materialfluss Logistik

Transcription

Documents pareils

Schöne neue Welt

3MKonvertierungsstation Modell 812

RFID in Reverse-Logistics-Systemen

Ausgabe 2/2011

Gibt es in einer total informatisierten Welt noch eine

Descriptif (fichier PDF)

Datenblatt - Sato Europe

Aktuelle Situation der RFID-Standardisierung

PPP Literaturgeschichte Neue Sachlichkeit.ppt