=Paper=
{{Paper
|id=None
|storemode=property
|title=Patterns for Managing Data in Complex Automatic Identification and Data Capturing Environments
|pdfUrl=https://ceur-ws.org/Vol-610/paper08.pdf
|volume=Vol-610
|dblpUrl=https://dblp.org/rec/conf/europlop/Bienhaus08
}}
==Patterns for Managing Data in Complex Automatic Identification and Data Capturing Environments==
https://ceur-ws.org/Vol-610/paper08.pdf
Patterns for Managing Data in Complex Automatic
Identification and Data Capturing Environments
Diethelm Bienhaus
Institute of Nanostructure Technologies and Analytics / Technological Electronics
University of Kassel, D-34132 Kassel, Germany
and
Department of Systems Engineering
University of Cooperative Education Nordhessen, D-35066 Frankenberg, Germany
bienhaus@uni-kassel.de, d.bienhaus@ba-nordhessen.de
Keywords: Automatic Identification and Data Capture (AIDC), Automatic Identification (Au-
toID), Radio Frequency Identification (RFID), Internet of Things, Unique Identifiers, Data-On-
Tag, Data-On-Network, Middleware, Edgeware
1. Introduction
Nowadays production and distribution processes are controlled to a large extent by information
processes. Interconnecting the flow of material and information promises to increase efficiency
and quality of business activities while reducing costs. Production planing and control systems
and enterprise resource planning systems can optimize processes within companies.
Supply chain management comprises the whole process of planning, implementing, and control-
ling the operations within a supply chain. The overall goal is to satisfy customer requirements as
efficiently as possible while saving time and resources on the other hand. Controlling all logistic
processes from raw materials suppliers to manufacturers and retailers to the consumer needs
transparency of the process steps. Managing the whole product life cycle from point-of-origin to
the point-of-consumption and disposal or recycling needs accurate information about products
in each process state and at the appropriate location.
Automatic Identification and Data Capture (AIDC) or Automatic Identification (AutoID) com-
prise techniques to automatically identify objects, to collect associated product data, and to
propagate that data to back-end software applications like Enterprise Resource Planning sys-
tems. Typical automatic identification technologies are bar codes, Radio Frequency Identifica-
tion (RFID) and smart cards. These techniques identify assigned properties while biometrics,
optical character and voice recognition utilize natural properties.
RFID has its origins more than fifty years ago. But due to recent developments this technique
is now available with higher quality and more functionality at lower costs. Especially in logistics
a large-scale commercial application is expected. In [Hen09] an worldwide market increase of
25% p.a. is expected.
RFID technology comprises several aspects: infrastructure and architecture, hardware like tags
or transponders and readers, integration on the physical layer up to IT system integration: SCM,
ERP, MES and warehouse management systems.
System architects, technology integrators, process designers and engineers in charge of implemen-
tation and system integration face several challenges. On the physical level first of all ”material
things” have to be identified. Then the captured data can be processed, filtered and forwarded
to applications which perform planning and controlling tasks. Questions concerning appropriate
data formats, efficient data transfer, data integration, lookup mechanisms, and others arise in
AutoID environments. This pattern collection introduces patterns dealing with aspects of those
problems.
This collection is a continuation and extending of a work starting with ”A Pattern Language
for Process Optimization with Smart Object Identification“ at EuroPLoP 2005 [Bie05] and
“Patterns for Unique Product Identification” [Bie08].
2. Overview
Figure 1 illustrates the relationships among the patterns presented in this collection. Starting
point of this collection is the need for centralized product data management as a basis for
planning and controlling systems. The pattern Identifiers Point To Data introduces a
solution to that problem. Applying the pattern may result in situations where new challenges
arises: capturing identification data of each individual product at many process steps and at
several times bears the risk of producing a large amount of data at low information level. A
solution for that problem is described in the pattern Business Events.
A decentralized data storage has benefits in applications where access to a network infrastructure
is temporarily or in principle not available. In such scenarios Data Accompanying Products
is an appropriate solution. Storing product data decentralized attached to the product and at
the same time centralized on servers can easily result in data inconsistencies. Synchronised
Data Location explains how to cope with that problem.
Production automation and logistic processes
Need for centralized Need for decentralized
product data management data access
Identifiers Point To Data Data Accompanying Products
Cope with large Avoid inconsistency when
storing data centralized Problem
amount of raw data
and decentralized
Business Event Manager Synchronized Data Location Pattern
Figure 1 – Overview Graph
Identifiers Point To Data
Context Identifiers Point To Data is necessary to enable seamless access to product
data within a single company's internal production processes as well as in case of
supply chains where several companies are involved.
Problem How to give access to detailed product data in distributed production and
logistic networks while only an identifier is attached to the product?
Forces In production and distribution processes several partners needs to gain access
to detailed product data. If the product data representation is attached to the
product itself the describing information can only be obtained when the product
is present.
Product data not only has to be accessible but also has to be updated and main-
tained during the whole product life cycle from raw material suppliers to customers
and finally to disposal or recycling. Optical data representations are printed once
and afterwards unchangeable. Modifications can only be done by replacing an old
label or product accompanying description by a newer one.
Machine readable data has to be stored in such a way that it is assigned to the
describing product. Typically a label is fixed on a product or it’s packaging.
Alternatively the product itself is marked (Direct Part Marking) e.g. by means of
laser engraving. Relatively cheap RFID transponders store about a hundred Bits
(EPC specifies a 96 Bit encoding) up to one or two kBits. The amount of data is
restricted.
An unique identifier allows distinction of product types or even individuals. But
this is not sufficient if a detailed product description is necessary e.g. for customers
or due to documentation reasons.
Increasing complexity of several companies spanning production processes and
deep supply chains raise the demand for product data accessible beyond company
internal and isolated IT systems like Production Planing Systems (PPS) and
Enterprise Resource Planning (ERP) Systems.
Solution Establish a network-based infrastructure that consists of components pro-
viding services for registering resources with an associated data lookup
service which enables storage and query of data along with their iden-
tifiers (keys). The services may be be folded into one single piece of
software or can be distributed over the Internet.
In real world physical objects populate the environment. Products or transport units
are a specific type of physical objects as results of planed and controlled production
processes or as part of such processes or as elements of transportation and storage.
Information technology supports controlling of technical or administration processes.
Processing and storing data about the real world needs abstract model of reality.
Objects of the real world are abstracted in the information systems through the use
of symbols (names, labels).
Abstraction is necessary because the real world cannot be represented in each detail,
but relevant sections of reality have to be chosen. Data describing properties of the
physical objects may be extensive. Often several parts of organisations or individuals
especially customers and users are interested in the data belonging to a product or
transport unit, even if the physical object itself is not present.
Rationale Accessibility to product data can be gained by saving and processing the data in
decentralized databases. If these databases can be accessed over the Internet most
of the involved partners will find the data easily. An identifier has to be assigned
to products or transport units and to be carried along with them which works as a
”pointer” to it’s belonging data. In this sense the identifier externalises the identifier
that is necessary internally in databases to mark each entry uniquely. RFID is seen
as an enabler so that things of the real world have a representation in the “virtual”
world of the Internet [KBM+ 00], [Bie05].
Consequences
Benefits Product data can be accessed independently of the products presence.
Only the identification number has to be represented or stored. Hence printed
labels or inexpensive passive RFID tags are sufficient.
Generation, representation and assignment of identifiers for products or transport
units is well standardized. The standards specified for reading devices, middle-
ware, and data manipulation grant compatibility and ensure a long-term use of
AIDC technologies like barcode, two-dimensional symbologies and in an increas-
ingly regarding RFID.
Liabilities Data accessibility is highly dependent on the availability of network infrastructure.
Centralized data storage and processing has to be reachable from every decision
point within the production or logistic processes. Failure of the centralized IT
system or network components result in a stop of the process. Redundancy can
reduce the risk of system standstills, but raises costs.
Network traffic increases with the number of items which are stored and have
to been searchable. The effort of resolving identifiers, searching the data and
delivering it to the requester grows proportional to the amount of item records.
Centralized data processing induces demands for data access regulations. Secu-
rity issues may be raised by producers and customers as well: To avoid business
espionage producers need to hide product details from their competitors. On
the other hand customers have concerns that their consumer’s behaviour may be
recorded and then misused by unauthorized parties.
Known Uses
A well known use are cash registers at checkout points in supermarkets which scan
the bar code on products to obtain data like price or weight. The data can be stored
decentralized at the cash register itself or is stored on a centralized system for the
reason of easier updates.
In logistics nearly each returnable transport item like pallets or containers are as-
signed a global shipping item number such that the transport units can be tracked.
Interoperability and ease of use need standardisation. Global Standard 1 (GS1) has
defined a scheme for globally applicable identifiers for trade items (products and
services), the Global Trade Item Number GTIN. A whole family of data structure
are specified for different application areas. In case of consumer products the EAN-
13 bar code is very popular especially in Europe [GS1]. The symbol encodes 13
numbers and is divided into four parts:
System code: two or three digits representing the country where the manufacturer
is registered. To cover the International Standard Book Number ISBN and the
International Standard Serial Number ISSN the starting three numerals 978 resp.
979 are used.
Manufacturer code: four or five digits such that system code and manufacturer
code are 7 numerals in sum.
Product code: five digits given by the manufacturer (normally the serial number).
Check digit: one digit for the check sum.
Figure 2 gives an example of a EAN bar code (code generator available on the
Internet: http://www.barcoderobot.com)
Figure 2 – Example of an EAN-13 Bar Code
The EAN identifier can be scanned to look up product information especially a
description and the product price in a database. As a service for consumers GS1
provides a web site on the Internet (http://directory.gs1.org/gtin/search)
where the product code owner and item information can be searched for.
Figure 3 shows the result of looking up the EAN number 4006381105262 which
the author found on a pen. (The Look-up tool is available on the Internet: http:
//directory.gs1.org/gtin/search)
Figure 3 – EAN-13 Item Number Resolved
Several courier-, express- and parcel (CEP) service provider offer customers freight
tracking services. In each relevant step in the logistic chain from sender to handler
and finally the the recipient is documented by capturing identification data and asso-
ciating it to the fulfilled transaction. As a service customer can look up information
about their shipments.
Data Accompanying Products
Also Known As: Data-on-Tag
Context Application of Data Accompanying Products enables process automation where
data about physical objects like products or pallets is necessary.
Problem How to provide machines access to product data without presence of a
network infrastructure?
Forces A centralized data storage allows data access from several distributed decision
points in production and logistic processes. If the necessary network is not avail-
able or if the centralized data storage and processing system fails the whole process
stops.
Identifiers attached to physical objects in the real world operate as pointers to
resource in the “virtual ” world. If the only information carried along with a
physical object is the identifier then no detailed data can be obtained between
points with no network access.
But in case of unplanned events more detailed data like product contents may be
necessary which cannot be obtained abroad from the normal process paths.
Network traffic and lookup times increase with the amount of items for which
detailed data is requested.
Solution Use a machine readable representation or storage technique carried along
with the product itself such that product related data accompanies the
physical object.
In order to attach data to a physical object in a machine readable manner an ap-
propriate representation is necessary which is capable to store data and allows at
least a reading access.
Read only techniques can be distinguished due to the used storage media and com-
munication method. The most common solutions are:
Optical representation with transfer in the frequency range of visual light. Data is
encoded as linear or two dimensional arranged geometrical patterns like rectangles,
squares or circles. The encoding is based on the shape of the geometrical element
and/or it’s location.
Typically the patterns are printed on adhesive labels which are then attached
to the physical object. Alternatively a direct part marking by means of Laser
engraving or other surface processing is applied to prevent removing of the data.
Data storage in digital memories and communication devices on chips. Data
transfer is performed via radio frequencies. On principle, storage capacities of
digital memories can be very large but data transfer then is time consuming. While
printed or directly marked symbologies are immutable except for replacing the
label or modifying the marked surface, digital memories provide the opportunity
of not only reading from but also writing to the chip.
Rationale Product data accompanying the the product itself grant access to information with-
out a network infrastructure and a centralized data processing [DMS07].
Attaching human readable information to products is well established for decades.
Examples are product sheets or instructions for use which are printed separately
and packaged together with the product. Shorter instructions and descriptions are
printed on labels and fixed on the product. Textual representations are not obsolete
and to be replaced by machine readable data. In fact machine readable information
augments the “audience” such that devices can get read the data which is then
can be exploit to automatically control process steps or is displayed to humans.
Attachment of data beyond simple identifiers raise the demand for higher storage or
representation capacities. In case of optical identification techniques data capacity
was stepwise enhanced in the evolution from linear codes – bar codes – to stacked
codes and then to two-dimensional symbologies. A widely used two-dimensional
symbology is the Data Matrix code which can contain up to 3116 numeric or 2335
alpha-numeric characters.
The digital memory integrated in RFID transponders feature a capacity of typically
about 100 Bit sufficient for identifiers up to several kBit. It is guessed that Moore’s
Law just begins regarding RFID transponders.
Consequences
Benefits Access to product data can be accessed independently of the products presence.
In case of re-writeable data storage labels like RFID transponders relevant data
can be collected on the path a product is undergoing.
Object related data allows managing of processes without a centralized controlling
system.
Data is available without an IT infrastructure and without the need for a central-
ized storage and processing system.
Liabilities Detailed data is only accessible when the described physical object is present.
Data storage capacities limit the amount of information. The level of details hence
is restricted and not all relevant data might be kept.
Known Uses
Automation of Production Processes
Siemens Amberg produces transformers which can be individually customized. Fig-
ure 4 shows a transport unit used in the transformer production process at Siemens
Amberg. Individual configuration data and necessary production steps are stored
in the transponder at the beginning of the production line. After that the trans-
port unit is directed through the production and the specified steps are performed
automatically without a centralized production execution system.
Figure 4 – Transponder storing configuration and production related
data attached to transport unit. (Source: Siemens)
Further applications of RFID in process automation are Ford’s manufacturing pro-
cess at the Essex Engine Plant in Windsor, Ontario, and the aircraft maintenance
at Boeing and Airbus [ZGYP03], [ZGP03].
Tracking and Tracing of Pharmaceutical Products
In the United States the Food and Drug Administration (FDA) forces the intro-
duction of a so called ePedigree for pharmaceutical products. In California by law
prescription drugs have to be accompanied by an electronic pedigree.
In the US RFID is the preferred tracking technology. Due to problems of wide spread
application of RFID transponders, hybrid pedigree systems incorporating paper and
automatic identification technologies like RFID or optical codes are in use as shown
in figure 5.
Figure 5 – RFID label attached to a pharmaceutical package
Synchronized Data Location
Context Synchronized Data Location is needed if data is alterable at both the data
carrier attached to the product and in centralized storage.
Problem How to avoid data inconsistencies if product data accompanying a physi-
cal object itself and the mirrored data on centralized servers are changed
independently?
Forces
A centralized data storage allows data access from several distributed decision
points in production and logistic processes. But if the infrastructure is not avail-
able or if the centralized data storage and processing system fails the whole process
stops.
Carrying product data along with the product itself provides access to that infor-
mation independently from a network infrastructure – stand-alone reader devices
are sufficient. But due to the decentralized storage technique necessary informa-
tion is not permanently and accurately available for tasks on a system wide level
like production planning and controlling.
Integration of all reader devices in a network infrastructure can help to forward
product related data to centralized processing services. In this case data is pushed
forward each time a physical reading process happens. On the level of business-
logic applications the need for information about the status of physical compo-
nents is triggered by software execution. Hence, data generation and information
processing are not synchronized. But the ability to react immediately to physical
events needs accurate process data.
Storing product data in both ways – attached to the product itself and on central-
ized servers – often results in data inconsistency. E.g. updating the product data
attached to the product at each process steps provides detailed information about
a product's history at any time and anywhere just having a mobile reader device
at hand. But that information tends to differ increasingly from the centralized
stored data.
Solution Synchronize product data carried along with the product and the central-
ized stored data by means of synchronization rules.
Such rules define actors and execution details of data interchange processes. Impor-
tant actors are data producer and consumers who are assigned updating and writing
access rights. Synchronisation with the centralized system is mostly based on data
versioning and event-based rules.
Rationale
In automation and logistics planning and controlling applications need data related
to products and process progress. Modern AutoID technologies support those ap-
plications. The overall aim is efficiency based process transparency: to know as
much as needed about state and location of products or transport units. Tradi-
tional identification data like Barcode labels or imprints are unchangeable. Hence
no data inconsistency can occur (expect in case of damage or replacement of the ID).
Radio-frequency identification allows storage of data far beyond simple identification
numbers. Data Accompanying Products explains benefits of decentralized data
storage. The resulting risk of inconsistent contents between separately located data
not only arises in the case of modern automated identification and data capturing
technologies: it is a general problem that occurs in backup scenarios and distributed
systems. Hence AutoID infrastructures can benefit from solutions established in
other IT application areas.
Consequences
Benefits Centralized stored data can more accurate represent the actual state of physical
things within the monitored process.
Decision and controlling systems can react more promptly to occurring changes
within processes.
In case of writeable storages attached to products like writeable RFID transpon-
ders central data updates can be downloaded and deployed to the de-centralized
memories on-site.
Liabilities Data consistency is determined by the completeness of the synchronization rules.
Unaccounted exceptions may still result in data inconsistencies.
If the necessary network infrastructure is not available no synchronisation can
be performed. Data accuracy and hence quality on the centralized storage is
dependent on refresh periods.
Known Uses
Based on [Sch02] researchers at University of Bremen / BIBA developed the concept
of “Data Contracts” for AutoID applications. Data Contract specify how to update
and match data between locally and centralized stored data during a product's life
cycle.
Updating and synchronisation of product data during its whole life cycle is the aim
of Product Lifecycle Management PLM. From production to distribution, reselling,
consumption and recycling all generated and necessary data about the products of a
company have to be managed consistently and have to be provided to controlling and
planning systems [AG06]. Automatic identification techniques contribute to PLM
on the narrow layer of plant automation and production or distribution logistics.
Business Event Manager
Context Business Event Managers bridge the gap between streams of raw sensor data
and applications on the business-logic level.
Problem How to perform process controlling efficiently while on-site reading de-
vices can only deliver raw sensor data which might even be redundant?
Forces Automatic identification techniques sense physical properties of things like given
properties or attached identifiers. Controlling of production and logistic processes
is based on logical rules which determine control flows.
Auto-ID technologies will enable businesses to move from linear and manual sup-
ply chain planning and execution to an event-driven, adaptive supply network.
But devices like bar code scanner and RFID readers can generate multiple read-
ings of the same physical object.
The occurrence of a reading event is not necessarily a business relevant event.
Propagation of each single reading event to the planning system may result in
high network traffic.
Solution Augment the automatic identification and data capturing infrastructure
by additional on-site software that performs a preprocessing of the raw
data and propagates business relevant events to the process controlling
applications. Such software components act as business event managers.
Business event managers have to react on real-time events and information, to prop-
agate alerts, and to provide services for essential reading and - if applicable – writing
of information to other information systems. As shop-floor near components they
have to provide interfaces for reader devices like scanners or RFID readers and
other devices like sensors. To be easily integrable those components need standard-
ised network interfaces. To be accessible from the business-logic level business event
managers have to support standard communication protocols like Simple Object
Access Protocol (SOAP).
Possible field of applications raise with abilities of general-purpose event routing,
collating, and filtering.
Rationale Business event extractors and managers hide hardware specific interfaces and exten-
sive streams of raw data. Furthermore, they can accomplish hardware configuration
tasks and maintenance related services.
From the physical layer consisting of hardware devices like scanners and readers only
physical signals can be obtained. Devices on this layer have to been managed e.g.
by providing appropriate software like drivers.
Signals have to be transformed into data due to specific protocols and grammars
in order to be transferred to the next layer. So at least two tasks have to be done
on the hardware layer: device management and data extraction and communication
[GH06].
The top layer of business process management can be seen as the opposite of
the hardware related layer on the bottom. Back-end systems like Enterprise Re-
source Planning (EAI) solutions, Manufacturing Execution Systems (MES) or Sup-
ply Chain Management (SCM) systems need to know the status of the underlying
processes from a business perspective. Hence business process relevant events or
alerts are necessary for decision making and then commands are sent down to the
active process elements to control progress. So extraction of business relevant events
and command propagation are the tasks to link the business controlling layer and
the layer of process near sensors like readers and actors.
Consequences
Benefits Assignment of specific tasks and functionality to specialized components supports
flexibility and re-usability. Especially in case of multi-tier architectures the necessary
processing power is at the point where the relevant data has to be captured and pre-
processed.
Liabilities The increasing amount of components and communication overhead are time costly
and decrease performance. Since more processing power is allocated at distributed
hardware components the installation costs of the whole infrastructure grow.
Known Uses
In case of complex production processes or supply chains several distributed and
heterogeneous components have to be integrated. This is the task of middleware
which is referred to as Enterprise Application Integration (EAI). In between of those
layers several functionality is necessary:
Preprocessing of the raw data received from devices,
data filtering and aggregation,
context-based event extraction,
propagation of business relevant events and
connectivity components for communication.
This intermediate layer, which might be subdivided, is known as “edgeware”. On
the edgeware layer several tasks have to be done. Devices are distributed at decision
relevant points of the process. Often inhomogeneous hardware components are in
use. Software components specialized in those different tasks and adapted for the
different hardware devices are the constituent parts of the edgeware layer.
Edgeware software is a good example where to apply the Layers [BMR+ 96] and
Pipes and Filters [BMR+ 96] architectural patterns.
Distinct parts work different levels and specific protocols can be used to access the
services contained at each layer.
In case of a single tier architectural approach all software functionality for data
and device management is integrated as a single software component with a layered
internal structure. Figure 6 illustrates a single-tier edgeware architecture.
EAI / ERP MES Application 1 Application n
Middleware
Events Commands
Device and Data Management
Routing / Middleware Connectivity Middleware Connectivity
Command
Context-based Event Extraction Interpretation
Device
Management
Data Filtering and Aggregation Command
Transformation
Hardware Connectivity Hardware Connectivity
Raw Data Raw Commands
Reader 1 Reader n
Figure 6 – Single-tier Edgeware Architecture
In production plant automation and in logistic applications reading devices are dis-
tributed. In such a setting a multi-tier architecture is more appropriate, as shown
in figure 7. In this architecture an additional service bus separates command in-
terpretation and event extraction from hardware specific functionality. The latter
consists of command transformation into device specific formats as well as data fil-
tering and aggregation. In [Lea04] several industrial applications of one-tier and
multi-tier architectures are introduced.
EAI / ERP MES Application 1 Application n
Middleware
Events Commands
Device and Data Management
Routing / Middleware Connectivity Middleware Connectivity
Context-based Event Extraction Command Interpretation
Connectivity Connectivity
Domain Specific Protocol
Service Bus
Domain Specific Protocol
Routing / Middleware Connectivity Connectivity Routing / Middleware Connectivity Connectivity
Device Command Device Command
Data Filtering and Aggregation Management Transformation Data Filtering and Aggregation Management Transformation
Hardware Connectivity Hardware Connectivity Hardware Connectivity Hardware Connectivity
Raw Data Raw Commands Raw Data Raw Commands
Reader 1 Reader n
Figure 7 – Multi-tier Edgeware Architecture
GS1 aims on a standardisation of integration architectures. That standardisation
defines the The Savant Architecture [LNE05], [CTAO03] where interface compo-
nents on the hardware near layer perform simple data processing in order to extract
Application Level Events from raw sensor data.
Figure 8 – Event Manager Software Components in RFID Middleware
Left: Sun’s RFID Middleware (Source: Sun Microsystems)
Right: Microsoft’s BizTalk Architecture (Source: Microsoft)
The architectural approach of extracting business events is implemented in middle-
ware platforms like Microsoft BizTalk [Sch06] or Sun's RFID middleware [Sun05].
In both architectures specialized software components (“Event Managers”) gather
information from the RFID Readers, filter the information, and provide information
as messages to systems on the business layer like ERP systems. Figure 8 illustrate
how the Event Manager and Information Server fit into a network-based AutoID
architecture.
3. Acknowledements
I'd like to thank my EuroPLoP 2008 shepherd Christian Kohls for his helpful feedback and
inspiring suggestions.
References
[AG06] Abramovici, M. and M. Ghoffrani: PLM - ein Thema auch für KMUs. Digital
Engineering, 2006.
[Bie05] Bienhaus, Diethelm: A Pattern Language for the Network of Things. In Pro-
ceedings of 10th European Conference on Pattern Languages of Programs (EuroPlop
2005), Irsee, Germany, 2005.
[Bie08] Bienhaus, Diethelm: Patterns for Unique Product Identification. In Proceedings
of 12th European Conference on Pattern Languages of Programs (EuroPlop 2007),
(to be published) 2008.
[BMR+ 96] Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad and M. Stal:
Pattern-Oriented Software Architecture: A System of Patterns. Wiley, New York,
1996.
[CTAO03] Clark, Sean, Ken Traub, Dipan Anarkat and Ted Osinski: Auto-ID Savant
Specification 1.0, 2003. http://www.nepc.gs1.org.sg/epcglobal/stdsdocs/WD_
savant_1-0_20030911.doc (17.02.2009).
[DMS07] Diekmann, Thomas, Adam Melski and Matthias Schumann: Data-on-
Network vs. Data-on-Tag: Managing Data in Complex RFID Environments. In
HICSS ’07: Proceedings of the 40th Annual Hawaii International Conference on
System Sciences, page 224a, Washington, DC, USA, 2007. IEEE Computer Society.
[GH06] Gillert, Frank and Wolf-Rüdiger Hansen: RFID für die Optimierung von
Geschäaftsprozessen: Prozess-Strukturen, IT-Architekturen, RFID-Infrastruktur.
Hanser, München, 2006.
[GS1] GS1: EAN Specification. Available on the internet: www.gs1.org.
[Hen09] Heng, Stefan: Heng, Stefan,RFID Chips: Enabling the Efficient Exchange of In-
formation(February 6, 2009). Deutsche Bank Research Paper. Available at SSRN:
http://ssrn.com/abstract=1339543. Deutsche Bank Research Paper, February 6
2009. Available at SSRN http://ssrn.com/abstract=1339543.
[KBM+ 00] Kindberg, Tim, John Barton, Jeff Morgan, Gene Becker, Debbie
Caswell, Philippe Debaty, Gita Gopal, Marcos Frid, Venky Krishnan,
Howard Morris, John Schettino and Bill Serra: People, Places, Things:
Web Presence for the Real World. WMCSA 2000, Monterey, USA, December 2000.
[Lea04] Leaver, Sharyn: Evaluating RFID Middleware. Technical Re-
port, Forrester Research, Inc., 2004. Available on the Internet:
http://www.bauer.uh.edu/rfid/ForresterRFIDwave.pdf (18.02.2008).
[LNE05] Leong, Kin Seong, Mun Leng Ng and Daniel W. Engels: EPC Network Ar-
chitecture. Technical Report, Auto-ID Labs, Massachusetts Institute of Technology
and Adelaide, 2005.
[Sch02] Schichtel, M.: Produktdatenmodellierung in der Praxis. Carl Hanser Verlag,
München et al., 2002.
[Sch06] Schwartz, Karen D.: BizTalk RFID: Making RFID Deployments Easy, Sim-
ple and Economical, June 2006. http://msdn.microsoft.com/en-us/library/
aa479354.aspx (17.02.2009).
[Sun05] Sun Microsystems: The Sun Java System RFID Software Architecture - A Tech-
nical White Paper, March 2005. http://www.sun.com/solutions/documents/
white-papers/re_EPCNetArch_wp_dd.pdf (17.02.2009).
[ZGP03] Zhekun, Li, Rajit Gadh and B.S. Prabhu: A Study of RFID Smart Parts.
Technical Report, University of California, Los Angeles, Wireless Internet for the
Mobile Enterprise Consortium, 2003.
[ZGYP03] Zhekun, Li, Rajit Gadh, Fan Yujin and B.S. Prabhu: Study of potential of
Wireless Internet Technologies in Manufacturing. In The Third International Con-
ference on Electronic Commerce Engineering (ICeCE2003), 2003.
Copyright © 2009 Diethelm Bienhaus