Sage Journals: Discover world-class research

Abstract

Radio frequency identification (RFID) technology and electronic product code (EPC) technology have been widely used to identify and keep track of physical objects. EPCglobal proposed the EPC network which consists of several components such as application level events (ALE) and EPC information service (EPCIS) to deal with the captured data from different layers. Many studies mostly concentrated on dealing with the RFID tag data in ALE, as well as querying and sharing EPCIS events in EPCIS. However, there is no well-known study on specifying how to generate higher level EPCIS events. The event types and semantic event fields are both uncertain for the capturing application to generate EPCIS events. Therefore, this paper proposes the flexible capturing application (FCA) to solve the problem that the event types and semantic event fields are both uncertain. FCA specifies generation rules about the four EPCIS event types. All the generation rules are matched for the incoming tag data to determine the event types. Event fields are generated with tag data and other sources of data after deciding event types. Thus, FCA can generate EPCIS events arising from supply chain activity. We evaluate our approaches by means of simulation and real experiments. Our experimental results indicate that FCA can be effective in processing EPCIS events data. We conclude with suggestions for future work.

1. Introduction

Radio frequency identification (RFID) [1–3] is a technology that allows an electronic product code (EPC) [4, 5] tag attached to an item to carry an identity for that item. Due to the reductions in cost and size of device components, RFID technology has been widely used to identify and keep track of physical objects in many RFID applications [6–9]. Industrial enterprises and government organizations such as Wal-Mart [10], Tesco, and even the US Department of Defense gain practical benefits by using RFID technology.

EPCglobal [11] proposed EPC network [12–14] to provide real-time data on physical objects by using RFID technology. Figure 1 shows the simple architecture of EPC network, which includes several components to deal with the captured data from different layers. A reader protocol [12, 15] specifies how to collect raw tag data from readers and delivers them as physical events. The application level events (ALE) [12, 16] filters and collects raw tag data read and delivers them as logical events. The capturing application [12, 17] generates high level EPC-related business events and delivers them as EPCIS events. EPCIS events differ from low level RFID tag data by providing dynamic semantic tracking information about items as they move through the supply chains. Thus, business applications know how and why physical events occurred and what state the physical objects are in by using EPCIS events. The EPC Information Services (EPCIS) [12, 17] stores and retrieves EPCIS events generated by capturing cpplication. Thus, EPCIS events can be shared both within and across enterprises.

Figure 1

The simple architecture of EPC network [12].

Example 1.

Consider Figure 1 which shows a generation and flow of RFID events through the EPCglobal framework. After producing a RFID tagged item, manufacturer A sent the item to wholesaler B. Suppose that the item is being tagged with RFID tag with EPC number “epc:1200.123.1123.” A RFID reader collects the tag information when it passes through according to steps of reader protocol. Then ALE will transform a physical event, which is “epc:1200.123.1123,” into a logical event by adding a logical reader name and timestamp. ALE also filters and smoothes duplicated physical events. Next, a capturing application generates an EPCIS event. The business logic information is added to the EPCIS event. The values of action, bizLocation, and bizStep are “OBSERVE,” “manufacturer A,” and “sending,” respectively. Lastly this EPCIS data is stored into EPCIS and shared to the partners of manufacturer A.

Suppose wholesaler B is expecting the delivery from manufacturer A. When the item arrives, it will pass through the RFID reader in the vicinity of wholesaler B. A physical event containing “epc:1200.123.1123” is generated and then it is transformed into a logical event with a logical reader name and timestamp. An EPCIS event is generated as the same way with the business information. At this time, the values of action, bizLocatio, and bizStep are “OBSERVE,” “wholesaler B,” and “receiving,” respectively.

Since the goal of RFID system is to collect and share tracking information about physical objects, the capturing application should generate correct EPCIS events for all the incoming RFID tag data. However, the problem of capturing application is that the event types and semantic event fields are both uncertain when a capturing application tries to generate EPCIS events after receiving RFID tag data and time information from ALE. The capturing application does not know how to get the semantic fields which cannot be obtained from the incoming RFID tag data either. Therefore, a proper capturing application is of great importance to generate correct event types with desired event fields.

Many studies mostly concentrated on dealing with the low level RFID tag data in ALE [18, 19], as well as querying and sharing EPCIS events in EPCIS [20, 21]. There are few studies on capturing application to generate EPCIS events. Several papers [22–25] mapped ALE ECReports to an EPCIS event type for each logical reader and configured the event fields. However, these existing methods cannot generate EPCIS events flexibly. Different EPCIS event types for different incoming ECReports cannot be generated at a specific reader. APDL (AspireRFID process description language) [26] generated EPCIS events based on the newly defined XML schema. However, the condition and timing for generating each event type are unknown.

In this paper, we propose the flexible capturing application (FCA) system to generate EPCIS events flexibly, which solves the problem that the event types and semantic event fields are both uncertain. The key contributions of our work are summarized as follows.

(i)

Modeling of EPCIS Events. We formally define the modeling of transaction data, business context data, and situation context data to represent the RFID semantic data required to generate EPCIS events. Since our model supports user defined EPCIS event, we can handle product return cases of the supply chain.

(ii)

Flexible Capturing Application. The event generation rules are proposed based on ECReports, RFID semantic data, and other related data to generate EPCIS events. In our proposed FCA, the event types for the incoming ECReports are determined automatically and flexibly by matching the specified event generation rules on four EPCIS event types. We have provided the detailed algorithms for generating different EPCIS event types.

(iii)

Proofs for Correctness. We also proved the completeness of our FCA approach. The event fields are automatically generated with ECReports and RFID semantic data if an EPCIS event generation rule is satisfied. One or more EPCIS event types are generated for one ECReport. All generated EPCIS events are delivered to EPCIS repository after all the four EPCIS event generation rules are matched.

(iv)

Experimental Evaluation. We have presented a detailed experimental evaluation to verify the proposed FCA. For this purpose, we defined the flexibility for evaluation. The experiments results show that FCA can generate correct EPCIS events more flexibly than the previous approach.

The remainder of the paper is organized as follows. Section 2 provides the background and motivation. Section 3 proposes modeling of RFID semantic data. Section 4 proposes the flexible capturing application. Section 5 presents the experiments. Section 6 introduces the related work. Section 7 concludes the paper.

2. Background and Motivation

In this section, we first explain the background knowledge of a RFID system and then describe the problem definition and motivations of our work.

2.1. RFID System Architecture

A general RFID system architecture which consists of (RFID) tags, (RFID) readers, application level event (ALE), capturing application, and EPC information service (EPCIS) is depicted in Figure 2. A tag is an identification device attached to the physical object we want to track. A reader is a device that can recognize the presence of RFID tags and read the information stored on them. The reader can inform another system such as reader protocol (RP) about the presence of the tagged physical objects. After RP collects the raw tag data from readers, ALE filters these raw tag data. For receiving RFID tag data from ALE, capturing application sends ECSpec to ALE; then ALE reports the tag data with ECReports. ECSpec is used to specify which RFID tag data from ALE are to be sent to capturing application. ECReports are the output of ALE and the input of capturing application, which includes the RFID tag data described in ECSpec. Then capturing application generates EPCIS events with the ECReports from ALE and delivers the EPCIS events to EPCIS repository. EPCIS stores and retrieves EPCIS events. Business partners can share the EPCIS events by retrieving EPCIS events.

Figure 2

RFID system architectures.

2.2. EPCIS Events

In this subsection, we will explain the details of EPCIS events since they have key roles in RFID system. EPCIS events differ from low level RFID tag data by providing semantic information. For this purpose, four event types are specified as a subclass of EPCIS event in the EPCIS standard as shown in Figure 3. A user can also define a new event type if needed.

Figure 3

Event types of EPCIS events.

The four EPCIS events describe how and why RFID tag data occurred and what state the physical objects are in. ObjectEvent describes events pertaining to one or more EPCs in a supply chain from birth (ADD) through middle life (OBSERVE) to death (DELETE). AggregationEvent explains events that child EPCs have been physically aggregated to a parent EPC, including EPCs from an aggregation (ADD); see EPCs in an aggregation (OBSERVE) or remove EPCs from an aggregation (DELETE). QuantityEvent describes events pertaining to a specified quantity of an object class. TransactionEvent describes the association (ADD) or disassociation (DELETE) of physical objects to one or more business transactions. The verbs in the parenthesis mean action fields of EPCIS events which are explained in the following paragraph.

Event fields of an EPCIS event carry descriptive information for the event in detail. Table 1 summarizes the event fields specified in the EPCIS standard which can be divided into four dimensions named what, when, where, and why, as well as the action field. EPC can be an epcList or parentID/childEPC. EPCClass and quantity are the class and quantity of object in QuantityEvent, respectively. BusinessTransactionList includes the business transactions with a type and a number. EventTime is the time when an event took place. RecordTime is the time when the event was received through the EPCIS capture interface. ReadPoint indicates the location where an event occurred. BusinessLocation describes the place where the object is immediately after the event occurs. BusinessStep is the business operation occurring at the time of the event. Disposition is the business state of the object immediately after the event occurs. The action field has three values: ADD, OBSERVE, and DELETE, describing how the event relates to the lifecycle of the EPCs in an ObjectEvent, how the event relates to the aggregation in an AggregationEvent, or how the event relates to the business transaction in a TransactionEvent.

Table 1

Summarized fields of EPCIS events.

Category	Fields
What	EPC
	EPCClass + quantity (QuantityEvent)
	BusinessTransactionList (TransactionEvent)

When	EventTime
When	RecordTime

Where	ReadPoint
Where	BusinessLocation

Why (business context)	BusinessStep
Why (business context)	Disposition

Other	Action

2.3. Motivation

In this subsection, we explain motivation and the problem definition of our work.

For digging out the problem, let us consider two different cases: simple single reader case and general multiple readers case.

Example 2 (a single reader case).

Figure 4 shows a simple single reader case of a RFID system. Three heterogeneous items with different object classes and a case are coming through reader D. In some cases, we just use the case to deliver the item. Thus, there is no aggregation between the items and the case. Therefore,ObjectEvent should be generated here. In some other cases, we want to pack the items as a set for further usage. Thus, the items are aggregated into the case. In this case,AggregationEvent should be generated here. A capturing application should generate correct EPCIS events with incoming ECReports from ALE. However, it is impossible for a capturing application to decide whether to generate ObjectEvent or heterogeneous AggregationEvent without further semantic and business information.

Figure 4

A single reader case.

The problems of general multiple readers case are explained in the following example.

Example 3 (multiple readers case).

Consider again Figure 1 which shows a manufacturer-wholesaler supply chain including multiple readers. Each of two trading partners has its own EPCIS repository. With all the incoming ECReports from ALE, all capturing applications should generate correct EPCIS events for readers in each trading partner. However, the capturing application cannot decide to generate which event types correctly for each reader since it cannot obtain exact business steps information such as “receiving” and “sending.” The values of action fields are unknown to capturing application either.

Our Motivation. As explained in Examples 2 and 3, a capturing application cannot determine which types of EPCIS events will be generated. The reason is that the incoming ECReports from ALE exclude the semantic event fields such as action, bizLocation, bizStep, disposition, and bizTransactionList. These shortcomings have motivated us to propose a flexible capturing application system that generates EPCIS events effectively based on the semantic and business context data.

Thus, we can formally state a flexible capturing application problem as follows.

Given a set of ECReports R which include RFID tag data from ALE and a set of context data C, generate a set of EPCIS events e with desired event fields for each $r \in R$ .

3. Modeling of RFID Semantic Data

In this section, we describe a RFID semantic data model employed in our flexible capturing application (FCA). The RFID semantic data model can be categorized into context data and transaction data.

3.1. Context Data

Context data is used to provide some semantic information. We define and explain two context data: situation context data and business context data.

3.1.1. Situation Context Data

We describe the necessity of situation context first by using an example. A RFID system handles various types of products. For example, consider two situations in Figure 5. In Figure 5(a), four items are being packaged into a case under reader D. For this, we can generate an “ADD” AggregationEvent for the packaged case and five “OBSERVE” ObjectEvents for items and case. However, we think that an “ADD” AggregationEvent is enough for describing the jobs that happened and five ObjectEvents are unnecessary. Figure 5(b) describes another situation. Assume that two cases come through reader D in turn. The case under the reader D contains the same types of items and the other case contains three heterogeneous items as a set. Here, we need heterogeneous AggregationEvent rules. In other words, a capturing application must understand the situation difference between these packaged cases and items.

Figure 5

Necessity of situation context data.

Before introducing a definition of situation context data, we begin by summarizing some of key notational conventions used in our discussion in the remainder of the paper in Notation Section. Additional notation will be introduced when necessary.

Situation context data is used to define extra situation rules for whether generating some event types or not according to the users’ requirements. It is represented as a list of event generation rules, where each rule can have time, epcList, readPoint, bizLocation, bizStep, and disposition fields. More formally, situation context data SCD is described as $SCD =$ (oe, ae, qe, te, and ne). Definition 4 shows more details of the situation context data.

Definition 4 (situation context data).

The situation context data is represented as a list of event generation rules ( $o e$ , $a e$ , $q e$ , $t e$ , and $n e$ ), where

(i)

oe is an ObjectEvent generation rule in 2 tuples (isOE, fieldList);

(ii)

ae is an AggregationEvent generation rule in 3 tuples (isAE, hePattern, and fieldList);

(a)

hePattern=(parent, children) is to generate heterogeneous AggregationEvent;

(1)

parent represents a parent ID;

(2)

children are a set of child EPCs;

(iii)

qe is a QuantityEvent generation rule in 3 tuples (bSList, actionList, and fieldList);

(iv)

te is a TransactionEvent generation rule in 2 tuples (isTE, fieldList);

(v)

ne is a new event type generation rule in 3 tuples (isExist, eventType, and fieldList);

(a)

eventType is the type name of the new event type.

Here, the values of parent and children fields should be object class EPC based on the schema specified in the TDS standard [5]. The values in bSL field should be the business step values specified in the CBV standard [27]. The values of an action field should be ADD or OBSERVE.

The situation context data is the extra generation rules. Thus, it is optional for the FCA, which means there can be no situation context data for an FCA. If some rule fields of situation context data are null or incomplete or there is no situation context data for FACA, then default values of each rule field are used. Table 2 specifies the default value of each field. That is, FCA does not generate unnecessary OBSERVE ObjectEvent and there are no extensible fields in ObjectEvent. FCA does not generate unnecessary OBSERVE AggregationEvent and heterogeneous AggregationEvent. There is no extensible field in AggregationEvent either. FCA generates QuantityEvent if “ADD” AggregationEvent is generated for the incoming ECReports or if bizStep is storing or retail_selling. There is no extensible field in QuantityEvent either. FCA does not generate OBSERVE TransactionEvent and there are no extensible fields in TransactionEvent. FCA does not generate new event type.

Table 2

Default value of situation context data.

Rule field	Subfield	Default value
oe	isOE	False
oe	fieldList	Null

ae	isAE	False
	hePattern	Null
	fieldList	Null

qe	bSL	Storing, retail_selling
	actionL	ADD
	fieldList	Null

te	isTE	False
te	fieldList	Null

ne	isExist	False
	eventType	Null
	fieldList	Null

An example of situation context data is shown in Figure 6.

Figure 6

An example of situation context data.

Example 5.

As Figure 6(a) shows, a user wants to pack the three heterogeneous items as a set. That is, a heterogeneous AggregationEvent for a set should be generated and unnecessary AggregatEvent for each item should not be generated here. Then we can use situation context data shown in Figure 6(b), which specifies the heterogeneous AggregationEvent rules. The parent ID class is in the pattern of urn: epc: id: sscc: 0652642, while the child EPCs classes are in the pattern of urn: epc: id: sgtin: 1234567. 123456, urn: epc: id: sgtin: 1234567. 223456, and urn: epc: id: sgtin: 2234567. 123456.

In order to generate EPCIS events, the situation context data needs to provide a function for checking errors. Table 3 shows the function.

Table 3

The functions in business context data.

Function	Descprition
c heckSCD()	If the field values of situation context data are valid, return true.

copySCDFileds(e, scd.e)	After checking the validity of scd.e, then copy fields of scd.e into appropriate fields of an event e.

3.1.2. Business Context Data

Business context data is used to obtain the bizLocation, bizStep, and disposition fields for a specific logical reader. It is represented in the format of 4 tuples $b c d =$ ( $r e a d e r$ , $b i z L o c$ , $b i z S t e p$ , and $d i s p o s i t i o n$ ). Definition 6 shows more details of the business context data. Here, the value of bizStep field should be the business step values specified in the CBV standard [27]. The values of disposition field should be the disposition values specified in the CBV standard [27].

Definition 6 (business context data).

Business context data is represented as 4 tuples $b c d =$ ( $r e a d e r$ , $b i z L o c$ , $b i z S t e p$ , and $d i s p o s i t i o n)$ , where

(i)

$r e a d e r$ is a name of the reader;

(ii)

$b i z L o c$ is a bizLocation;

(iii)

$b i z S t e p$ is a bizStep;

(iv)

$d i s p o s i t i o n$ is a disposition.

In order to generate EPCIS events, the business context data needs to provide several functions. Table 4 shows the functions.

Table 4

The functions in business context data.

Function	Description
obtainBCDFields(e, bcd)	Obtain the bizLocation, bizStep, and disposition fields of EPCISEvent e from bizLoc, bizStep, and disposition fields of business context data bcd.

getBCD(r, bcd)	Get the bizLoc, bizStep, and disposition fields from a business context data set bcd for ECReports r.

checkBCD()	If the field values of all the business context data are valid, return true. Otherwise, return false.

Business context data is mandatory information for the FCA. All the elements of business context data for an FCA must be specified in an XML file.

Example 7.

Figure 7 shows an example of a business context data. There are four readers in an imaginary manufacturer supply chain in Figure 7(a). The corresponding business context must be specified for the four readers in an XML file. Figure 7(b) depicts only two business context data for reader A and reader D.

Figure 7

An example of business context data.

3.2. Transaction Data

Transaction data determines TransactionEvent type and provides the action field and bizTransactionList field of TransactionEvent. It is represented in the format of $t d =$ ( $t y p e$ , $i d$ , $e p c L i s t$ , $r e a d e r$ , and $s r$ ). Definition 8 shows the specification of transaction data. Here, the value of a type field should be obtained from the business transaction type values described in the core business vocabulary (CBV) standard [27]. The value of an epcList field should be based on the schema specified in the EPC tag data (TDS) standard [5].

Definition 8 (transaction data).

Transaction data is represented as 4 tuples $t d =$ ( $t y p e$ , $i d$ , $e p c L i s t$ , $r e a d e r$ , and $s r$ ), where

(i)

$t y p e$ is a transaction type;

(ii)

$i d$ is a transaction ID number;

(iii)

$e p c L i s t$ is a set of EPCs;

(iv)

$r e a d e r$ is a name of the reader;

(v)

$s r$ specifies whether the reader is the start (S), end (E), or intermediate reader (I) of the transaction.

Transaction data is optional for the FCA, which means there can be no transaction data for an FCA if there is no business transaction existing. All the transaction data for an FCA can be included in an XML file.

Example 9.

Here is an example of transaction data. In a wholesaler supply chain as shown in Figure 8(a), two cases are picked up at reader Who-C when associated with the transaction order from a retailer. Figure 8(b) shows the corresponding transaction data.

Figure 8

An example of transaction data.

In order to generate EPCIS events, transaction data needs to provide several functions. Table 5 shows the functions.

Table 5

The functions in transaction data.

Function	Description
isRelevant(r, td)	If the transaction data td is related to ECReports r, then return true. Otherwise, return false.

addBizTran(td, t)	Obtain the transaction type and ID of transaction data td and add them to the bizTransactionList of TransactionEvent t.

checkTD()	If the field values of all the transaction data are valid, return true. Otherwise, return false.

4. Flexible Capturing Application

In this section, we present our flexible capturing application (FCA) for generating correct EPCIS events. We first describe the architecture of FCA (Section 4.1) and then explain how our approach can generate correct EPCIS events and provide the correctness of our approach (Section 4.2). We also provide a running example of FCA (Section 4.3).

4.1. Architecture

Figure 9 shows the proposed architecture of the FCA. FCA consists of three principal components: ALE accessor, event generator, and EPCIS accessor.

Figure 9

The architecture of FCA.

ALE accessor deals with ECSpec and ECReports related to ALE. ECSpec manager configures one or more ECSpecs to request ECReports from ALE, and then ECReports handler processes the received ECReports.

After receiving ECReports from ALE, event generator generates EPCIS events with the processed ECReports and other sources of data such as context data, transaction data (TD), and relevant AggregationEvent in EPCIS repository. TD manager deals with the input transaction data. BCD manager and SCD manager deal with input context data, which can be divided into business context data (BCD) and situation context data (SCD). Event generation rules about the four EPCIS event types are specified with ECReports, situation context data, transaction data, and relevant AggregationEvent in EPCIS repository. Type decider matches all event generation rules to decide the event types for the incoming ECReports. If an event generation rule is satisfied, fields generator generates the event fields with ECReports, business context data, transaction data, and relevant AggregationEvent in EPCIS repository. After matching all the four event generation rules, event generator generates all EPCIS events for the current ECReports.

EPCIS accessor provides the communication with EPCIS. Query processor retrieves the relevant AggregationEvent in EPCIS repository queried by event generator to generate AggregationEvent. HttpPost delivers all generated EPCIS events to EPCIS repository. Return generator returns the verified information of EPCIS events format from ECPIS. After delivering the generated EPCIS events for the current ECReports, event generator turns to deal with the next incoming processed ECReports.

4.2. Event Generation

In this subsection, we will explain the ECPIS event generation algorithm of FCA.

4.2.1. Event Generation Algorithm

The event generation algorithm first checks the context data and tries to generate appropriate EPCIS events by invoking all EPCIS event generation algorithms. The detailed steps of event generation algorithm are described in Algorithm 1. With the incoming ECReports (r), all the transaction data, the business context data, and the situation context data, the algorithm generates EPCIS events (e). If the incoming ECReports include epcs in line 2, then event generation starts to match each event algorithm to generate all possible EPCIS events in lines 3–11. The events generated in each event algorithm are added into the final EPCIS events in lines 7–11. TheObjectEvent generation algorithm is matched after the other three EPCIS events for the reason that an ObjectEvent is generated if none of other three EPCIS event generation rules are satisfied.

Algorithm 1: Event generation algorithm.

Input: ${r$ , td, bcd, $s}$ -r is ECReports; td is a set of Transaction Data;

bcd is a set of Business Context Data;

s is Situation Context Data;

Output: ${e}$ -e is a set of EPCIS events;

procedure EventGeneration(r, td, bcd, s)

(1) $e \leftarrow n u l l$

(2) if r includes epc then

(3) CheckTD();

(4) CheckBCD();

(5) CheckSCD();

(6) $bc \leftarrow g e t BCD (r, bcd)$ ;

(7) e.add(AggregationEventGeneration $(r, bc, s)$ );

(8) e.add(QuantityEventGeneration $(r, bc, s)$ );

(9) e.add(TransactionEventGeneration $(r, td, bc, s)$ );

(10) e.add(ObjectEventGeneration $(r, bc, s)$ );

(11) e.add(NewEventTypeGeneration $(r, bc, s)$ );

end if

(12) return e;

4.2.2. AggregationEvent Generation

An AggregationEvent occurs when one or more items physically aggregated to each other. It establishes a parent-child relationship between shipping containers such as case and the items which are included within it. Thus we need to divide the incoming EPCs into containers (EC) and objects (EO) according to the encoding schema and epcClass.

In a supply chain, there exist five cases for the AggregationEvent as shown in Figure 10.

Figure 10

The cases for AggregationEvent.

Case 1. This includes the first aggregation of item(s) and a container.

Since this is the first time of aggregation, there is no previous AggregationEvent for EC and EO. We generate an “ADD” AggregationEvent if the bizStep is not receiving which indicates that EO and EC are aggregated.

Case 2. This includes the first observation at a different business partner.

This is similar to Case1; the difference is due to BizStep. In a supply chain, whenever a wholesaler receives item(s) and a container, it is the first observation at wholesaler. Since it is already aggregated before the different business partner, we generate an “OBSERVE” AggregationEvent.

Case 3. A container and several items are recognized.

Since only one EPC is included in EC and the relevant previous AggregationEvent of EC is also found, we generate an “OBSERVE” AggregationEvent setting the parent ID and child EPCs to EC and EO, respectively.

Case 4. Several containers and items are recognized.

Since EC includes many EPCs of containers, we need to search all relevant AggregationEvents for each element $E C_{i}$ in EC. Then, we can generate an OBSERVE AggregationEvent after setting the parent ID and child EPCs to $E C_{i}$ and the child EPCs of previous aggregation event of $E C_{i}$ , respectively.

Case 5. Items are removed from the container (disaggregation).

At this case, only EO is read and there exists a relevant previous AggregationEvent of EO. Then, we generate DELETE AggregationEvent. The child EPCs and parent ID are set to EO and the parent ID of the relevant (previous) AggregationEvent, respectively.

Algorithm 2 shows the AggregationEvent generation. It first divides EPCs into EC and EO and then generates a corresponding AggregationEvent according to five cases. The exact fields for the generated AggregationEvent are provided by EC, EC, relevant (previous) AggregationEvent, bizStep, situation context data, and business context data.

Algorithm 2: AggregationEvent generation algorithm.

Input: ${r, bc, s}$ -r is ECReports; bc is Business Context Data;

s is Situation Context Data;

Output: ${a}$ -a is (a set of) AggregationEvent;

Procedure AggregationEventGeneration $(r, bc, s)$

(1) $a \leftarrow n u l l$ ;

(2) divide r into container (EC) and objects (EO);

(3) if $E C \neq n u l l$ and $E O \neq n u l l$ then

(4) if $E C . s i z e = 1$ and findAggregationEvent(EC) = $n u l l$ and

findAggregationEvent(EO) = $n u l l$ then

(5) if getBizStep(bc) ≠ receiving then $a . a c t i o n \leftarrow A D D$ ; // Case 1

(6) else a.action ← OBSERV E; // Case 2

(7) a.parentID $\leftarrow E C$ ;

(8) a.childEPCs $\leftarrow E O$ ;

(9) obtainBCDFields(a, bc);

(10) copySCDFields(a, s.ae);

end if

(11) if s.ae.isAE = true then

(12) if EC.size = 1 and findAggregationEvent(EC) ≠ $n u l l$ then // Case 3

(13) a.action ← OBSERV E;

(14) a.parentID $\leftarrow E C$ ;

(15) a.childEPCs $\leftarrow E O$ ;

(16) obtainBCDFields(a, bc);

(17) copySCDFields(a, s.ae);

end if

(18) if EC.size > 1 then // Case 4

(19) for each epc ${E C}_{i}$ in EC do

(20) if $f i n d A g g r e g a t i o n E v e n t ({E C}_{i}) \neq n u l l$ then

(21) generate AggregationEvent sub;

(22) sub.action ← OBSERV E;

(23) sub.parentID ← ${E C}_{i}$ ;

(24) sub.childEPCs ← $f i n d A g g r e g a t i o n E v e n t ({E C}_{i})$ .getchildEPCs();

(25) obtainBCDFields(a, bc);

(26) copySCDFields(sub, s.ae);

(27) a.add(sub);

end if

end for

end if

(28) if $E C = n u l l$ and $E O \neq n u l l$ and findAggregation(EO) ≠ $n u l l$ then // Case 5

(29) a.action ← DELETE;

(30) a.parentID ← findAggregation(EO).getParentID();

(31) a.childEPCs $\leftarrow E O$ ;

(32) obtainBCDFields(a, bc);

(33) copySCDFields(a, s.ae);

end if

(34) return a;

4.2.3. QuantityEvent Generation

A quantity event provides information on the number of items identified by RFID readers. But it does not give the individual identities of recognized items.

There exist two cases in a supply chain as shown in Figure 11. A wholesaler would like to know the quantity of boxes/items to expect upon receiving the shipment. This is an independent usage case of the QuentityEvent. For this case, although no situation context data is given, our FCA generates a QuantityEvent by using the default values of situation context data. On aggregating items into containers, a manufacturer would like to check the number of aggregated objects. FCA first checks an action field of situation context data. If the situation context data includes proper bizStep and action field (value of “ADD”), then FCA generates a QuantityEvent.

Figure 11

The cases for QuantityEvent.

Algorithm 3 shows the QuantityEvent generation algorithm which deals with two usage cases of the QuantityEvent.

Algorithm 3: QuantityEvent generation algorithm.

Input: ${r, bc, s}$ -r is ECReports; bc is Business Context Data;

s is Situation Context Data;

Output: ${q}$ -q is QuantityEvent;

procedure QuantityEventGeneration $(r, bc, s)$

(1) $q \leftarrow n u l l$ ;

(2) if $s . q e = n u l l$ then

(3) if (bc.bizStep is storing or receiving) then // Case 1

(4) obtain the epcClass and quantity fields of q from r;

(5) obtainBCDFields(q, bc);

end if

else

(6) if s.qe.bSList.contains(bc.bizStep) or s.qe.actionList.contains(ADD) then // Case 2

(7) obtain the epcClass and quantity fields of q from r;

(8) obtainBCDFields(q, bc);

(9) copySCDFields(q, s.qe);

end if

(10) return q;

4.2.4. TransactionEvent Generation

A TransactionEvent occurs when an EPC-tagged item becomes associated or disassociated with a business transaction such as a purchase order.

As shown in Figure 12, each business transaction consists of three stages: (1) start, (2) intermediate, and (3) end. However, a TransactionEvent is generated for the start and end stages. A value “ADD” is set to the action value of a start transaction and “DELETE” is set to the action value of an end transaction. FCA obtains bizLocation, bizStep, and disposition fields from business context data and a bizTransactionList field from the relevant transaction data $t d_{i}$ . Details of TransactionEvent generation algorithm are described in Algorithm 4.

Algorithm 4: TransactionEvent generation algorithm.

Input: ${r, td, bc, s}$ -r is ECReports; td is a set of transaction data;

bc is business context data;

s is situation context data;

Output: ${t}$ -t is a set of TransactionEvent;

procedure TransactionEventGeneration $(r, td, bc, s)$

(1) $t \leftarrow n u l l$ ;

(2) for each transaction data ${t d}_{i}$ in $t d$ do

(3) if $i s R e l e v a n t (r, {t d}_{i}) = t r u e$ and s.te.is $T E = t r u e$ then

(4) if ${t d}_{i} . s r! = I$ then // notCase 2

(5) if ${t d}_{i} . s r = S$ then sub.action ← ADD; // Case 1

(6) if ${t d}_{i} . s r = E$ then sub.action ← DELETE; // Case 3

(7) sub.epcList ← r.epcList;

(8) obtainBCDFields(sub, bc);

(9) addBizTran( ${td}_{i}$ , sub);

(10) copySCDFields(sub, s.te);

(11) t.add(sub);

end if

end for

(12) return t;

Figure 12

The cases for TransactionEvent.

4.2.5. ObjectEvent Generation

Basically, an ObjectEvent applies to one or more objects identified by an EPC. However, when considering objects identification in a supply chain, there might be three different cases for ObjectEvent as shown in Figure 13. If bizStep is commissioned such as Case1, it means that an object is just identified at this time (birth of the object). Thus we will assign the value “ADD” to the action field. If bizStep is decommissioned such as Case 2, it means the end of life for an object. Thus we will assign the value “DELETE” to action field. Otherwise, it means that an object has not been changed and has been just recognized. The value “OBSERVE” will be assigned to an action field.

Figure 13

The cases for ObjectEvent.

Algorithm 5 shows theObjectEvent generation algorithm. At the first step, ObejctEvent type is decided by a situation context data, bizStep, and other event types. If a condition is satisfied, then, at the second step, the action field is obtained from by bizStep and other fields are obtained from ECReports, business context data, and situation context data.

Algorithm 5: ObjectEvent generation algorithm.

Input: ${r, bc, s}$ -r is ECReports; bc is Business Context Data; s is Situation

Context Data;

Output: ${o}$ -o is ObjectEvent;

procedure ObjectEventGeneration $(r, bc, s)$

(1) $o \leftarrow n u l l$ ;

(2) if no other event type generates or s.oe.isOE = true or bc.bizStep = shipping or receiving then

(3) if bc.bizStep = commissioning then o.action ← ADD; // Case 1

(4) else if bc.bizStep = decommissioning then o.action ← DELETE; // Case 2

(5) else o.action ← OBSERV E; // Case 3

(6) o.epcList ← r.epcList;

(7) obtainBCDFields(o, bc);

(8) copySCDFields(o, s.oe);

end if

(9) return o;

Theorem 10.

Giving the ECReports r, business context data $b c$ , and situation context data s, algorithm ObejctEvent correctly generates ObejctEvent o.

Proof.

In algorithm ObejctEvent generation, if no other event types are generated, if s.oe.isOE=true which means generate unnecessary OBSERVE ObjectEvent, if bc.bizStep=shipping or receiving which means to identify shipped objects, or if bc.bizStep=commissioning or decommissioning which means to commission or decommission EPCs to objects, we generate ObejectEvent. If bizStep is commissioned such as Case 1, then action value is ADD. If bizStep is decommissioned such as Case 2, then action value is DELETE. Otherwise, action value is OBSERVE such as Case 3. The epcList field can be obtained from ECReports. We generate the bizLocation, bizStep, and disposition fields from business context data. We generate extensible fields if s.oe.fieldList is not null.

4.2.6. New Event Type Generation

Although the EPCglobal provides core event types such ObjectEvent, AggregationEvent, QunatityEvent, and TransactionEvent, a user defined event type is needed to meet the requirements of an industry or application area. For example, a manufacturer wants to quickly find returned items events; then it can define a new event type for returned items.

Example 11.

A manufacturer ships the cases to a wholesaler. However, if the wholesaler finds out that the received case is a wrong product, then it sends the case back to the manufacturer. When the manufacturer receives the returned case, it generates the new event type named ReturnCaseEvent as shown in Figure 14(b) depending on situation data in Figure 14(a). The epcList field means the returned case. The bizLocation, bizStep, and disposition fields can be obtained from business context data. There is an extensible field with the name “reason” and the value “wrong product,” which can be obtained from situation context data.

Figure 14

New event type generation.

Algorithm 6 shows how new event type generation algorithm works. First, it defined the exact fields for a new event type from situation data. Then, it obtains the values of fields from ECReport, business context data, and situation context data.

Algorithm 6: New event type generation algorithm.

Input: ${r, bc, s}$ -r is ECReports; bc is Business Context Data; s is Situation

Context Data;

Output: ${n}$ -n is New Event Type;

procedure NewEventTypeGeneration $(r, bc, s)$

(1) $n \leftarrow n u l l$ ;

(2) if s.ne.isExist = true then

(3) n.name ← s.ne.eventT ype;

(4) n.epcList ← r.epcList;

(5) obtainBCDFields(n, bc);

(6) copySCDFields(n, s.ne);

end if

(7) return n;

Theorem 12.

Given an ECReport r, business context data, $b c$ and situation context data s, algorithm new event type correctly generates new event type n.

Proof.

In algorithm new event type generation, if $s . n e . i s E x i s t$ is true, we generate the new event type. The name of the new event type is obtained from SCD.getNEType.getEventType. The epcList field can be obtained from ECReports. We generate the bizLocation, bizStep, and disposition fields from business context data. We generate extensible fields if s.ne.fieldList is not null.

4.3. A Running Example for Event Generation

After specifying the event generation rules in four EPCIS event generation algorithms, we present how FCA works to generate EPCIS events by using a manufacturer supply chain and business context data in Figure 15. There are no transaction data and situation context data for manufacturers FCA. Thus, transaction data is null here and the default values for situation context data are used.

Figure 15

A running example of EPCIS events generation.

A reader Man-A reads a number of items carrying EPC tags. FCA starts to generate EPCIS events after receiving the ECReports from ALE. Use the AggregationEvent generation algorithm to match each generation rule. After dividing the incoming epcs, only EO is read. EO is the items. However, there is no relevant AggregationEvent about EO in manufacturers EPCIS repository, so no AggregationEvent generation rule is satisfied. Use the QuantityEvent generation algorithm to match each generation rule. No “ADD” AggregationEvent is generated and the bizStep is not storing or retail_selling, so no QuantityEvent generation rule is satisfied. Use the TransactionEvent generation algorithm to match each generation rule. There is no transaction data here, so no TransactionEvent generation rule is satisfied. Use the ObjectEvent generation algorithm to match each generation rule. The bizStep is commissioned, so generate ADD ObjectEvent. The epcList is the EPCs of items. The bizLocation, bizStep, and disposition fields can be obtained from manufacturers business context data. Thus, only ObjectEvent is generated. FCA delivers the generated ObjectEvent to manufacturers EPCIS repository.

Similarly, only ObjectEvent is generated when reader Man-B reads an EPC-equipped case. AggregationEvent and QuantityEvent are generated when reader Man-C reads a number of items carrying EPC tags and an EPC-equipped case. Only ObjectEvent is generated when reader Man-D reads a number of items carrying EPC tags and an EPC-equipped case.

Table 6 summarizes the generated EPCIS event types of the manufacturer supply chain by using FCA.

Table 6

Generated event types for the manufacturer supply chain example.

Reader	Generated event types	Action
Man-A	ObjectEvent	ADD
Man-B	ObjectEvent	ADD
Man-C	AggregationEvent	ADD
	QuantityEvent	X
Man-D	ObjectEvent	OBSERVE

5. Experimental Results

To demonstrate the flexibility of FCA, we implemented the FCA according to the architecture in Figure 9 and defined the equation of flexibility. We selected BizAF [25] as the naive approach to be compared with FCA. We used two different datasets in the performance evaluation of FCA: (1) a synthetically generated dataset and (2) a real dataset.

5.1. Implementation

We implemented FCA in Java language using Eclipse 3.6 and complied the code using JDK 1.6. All experiments were conducted on an Intel Core 2 Duo 3.00 GHz machine with 2 GB Ram running Windows 7 in 32 bits.

Figure 16 shows the GUI of the implemented FCA. ECSpecs, business context data, situation context data, and transaction data should be provided. The ECSpecs file includes the name and path of all readers ECSpec. The user can input the path of required data, as well as loading them in the load tab. What is more is that the user can draw his own data about ECSpecs, business context data, and transaction data in the panel of draw tab. When the user clicks the start button, FCA starts working. After ECSpecs are sent to ALE, ECReports are received from ALE. Then, FCA handles the incoming ECReports and generates EPCIS events for incoming ECReports. At last FCA delivers the generated events to EPCIS repository and the EPCIS returns the verified information of generated events format to FCA.

Figure 16

The GUI of implemented FCA.

5.2. Evaluation Metric

We selected two factors to compute flexibility. One factor is the total number of tag records in generated EPCIS events. The other factor is the number of tag data involved in event generation. We want to generate more tag records in generated EPCIS events for all tag data. Therefore, we compute the flexibility f as shown in (1). Here, $\sum_{i = 1}^{n} N_{i}$ is total number of tag records in generated EPCIS events, n is the number of generated events, $N_{i}$ is the number tags included in a generated event, and $N_{T}$ is the number of tag data involved in event generation:

\begin{matrix} f = \frac{\sum_{i = 1}^{n} N_{i}}{N_{T}} . \end{matrix}

(1)

5.3. Experiments with Synthetic Data

In this section, we analyze the performance of FCA.

5.3.1. A Synthetic Dataset

Since the collection for RFID tag data from multiple readers is time-consuming and money-consuming, we generated the virtual tag data using a synthetic RFID data generator developed by us. For this purpose, we made an imaginary manufacturer-wholesaler-retailer supply chains scenario shown in in Figure 17. We assume that each enterprise has its own flexible capturing application and EPCIS. Thus, three virtual tag data sets are used to evaluate the FCA.

Figure 17

Supply chains scenario for the synthetic data.

The first data set consists of 10000 tag data in the retailer supply chain as shown in Figure 18(a). The tags can arrive at a reader in one ECReport at once or be divided into several ECReports for multiple reads at a reader. There are R ( $R < 10000$ ) item tags in reader Ret-B in the format of urn:epc:id:sgtin:1234567.123456.X; X is from 1 to R. There are 10000-R case tags in reader Ret-C in the format of urn:epc:id:sscc:0641414.12345X; X is from 00001- to 10000-R.

Figure 18

Data sets in retailer/manufacturer/wholesaler supply chains.

The second data set consists of 20000 tag data in the manufacturer supply chain as shown in Figure 18(b). The tags can arrive at a reader in one ECReport at once or be divided into several ECReports for multiple reads at a reader. There are M ( $M < 20000$ ) item tags in reader Man-A in the format of urn:epc:id:sgtin:1234567.123456.X; X is from 1 to M. There are 20000-M case tags in reader Man-B in the format of urn:epc:id:sscc:0641414.12345X; X is from 00001- to 20000-M.

The third data set consists of 30000 tag data in the wholesaler supply chain as shown in Figure 18(c). The tags can arrive at a reader in one ECReport at once or be divided into several ECReports for multiple reads at a reader. For each reader in the wholesaler supply chain, there are W ( $W < 30000$ ) item tags in the format of urn:epc:id:sgtin:1234567.123456.X; X is from 1 to W. There are 30000-W case tags in the format of urn:epc:id:sscc:0641414.12345X; X is from 00001- to 30000-W.

5.3.2. Performance Analysis

Figure 19(a) shows the performance comparison in terms of the flexibility. The flexibility of FCA is higher than BizAF, which means that our proposed FCA provides more flexibility for generating EPCIS events. For the data set in the retailer supply chain, FCA generates ObjectEvent for identifying the tags, AggregationEvent for aggregation between items and case, and TransactionEvent for transaction at reader Ret-A. FCA generates AggregationEvent for disaggregation and QuantityEvent for storing at reader Ret-B, while BizAF generates only one event type at each reader. Thus, the flexibility of FCA is higher than BizAF for the data set in the retailer supply chain. For the data set in the manufacturer supply chain, FCA generates AggregationEvent and QuantityEvent at reader Man-C and AggregationEvent and TransactionEvent at reader Man-D, while BizAF generates only one event type at each reader. Thus, the flexibility of FCA is higher than BizAF. For the data set in the wholesaler supply chain, FCA generates ObjectEvent and AggregationEvent at reader Who-A, AggregationEvent and QuantityEvent at reader Who-B, TransactionEvent and AggregationEvent at reader Who-C, and ObjectEvent and AggregationEvent at reader Who-D. Thus, the flexibility of FCA is higher than BizAF.

Figure 19

Experimental results.

Tag data are included in an ECReport as the input of capturing application to be processed. The relationship between the number of ECReports $N_{c}$ and the number of tag data involved in event generation $N_{T}$ is as in shown (2). Here $N_{t}$ is the number of tags (item and case should be both included) which arrive at a reader at the same time. $N_{r}$ is the number of readers. For example, 9 item tags and 1 case tag arrive at reader Who-A at the same time; then $N_{t}$ is 10. There are four readers in the wholesaler supply chain; thus $N_{r}$ is 4. If $N_{T}$ is 30000, then value of $N_{c}$ is 12000:

\begin{matrix} N_{c} = \frac{N_{T}}{N_{t}} * N_{r} . \end{matrix}

(2)

Figure 19(b) shows the comparison of execution time using the wholesaler supply chain. 9 item tags and 1 case tag are included in one ECReport. We used 25000, 50000, 75000, and 100000 tag data to obtain 10000, 20000, 30000, and 40000 ECReports, respectively. FCA matches event generation rules to decide the event types and processes semantic data to obtain some event fields, while BizAF configures the event type and event fields. Therefore, our FCA takes a little more time than BizAF.

The memory is around a specific value while running FCA and BizAF. Thus, we listed the value of memory usage for comparison in Table 7. There is no so big difference in memory usage. The memory of our FCA is a little smaller than BizAF.

Table 7

The comparison of memory usage.

	Memory usage
BizAF	120 MB
FCA	100 MB

From the above comparison, we can know that FCA can generate EPCIS events more flexibly with a little more time.

5.4. Experiments with Real Data Set

In this subsection, we conducted experiments to verify flexibility of FCA using real RFID data set.

5.4.1. Real Dataset

To obtain the real data from the real RFID devices, we designed a virtual manufacturer's scenario and installed a belt conveyor as shown in Figure 20(a), a roller conveyor as shown in Figure 20(b), and three RFID readers (two Alien 9800 readers and one Intermec reader) according to the scenario.

Figure 20

Installed devices.

Details of the virtual manufacturer's scenario in Figure 21 are as follows.

(i)

Conveyor Belt A. It includes putting 2 separated items and 2 items of product at the start position (belt A).

(ii)

Passing Read Point 1 (Reader 1). The antenna will read and transmit the EPC tags of the items to ALE (application level event) and pass them to FCA (flexible capturing application) for generating object event.

(iii)

Passing Round-Belt. The product will be aggregated and packed together in a box (containing 4 items) and then moves on to belt B.

(iv)

Passing Read Point 2 (Reader 2). The antenna will read and transmit the EPC tags of the items to ALE and pass them to FCA for generating aggregation event.

(v)

To Roller Conveyor. After passing through belt B, the box will be moving on to a roller conveyor.

(vi)

Passing Read Point 3 (Reader 3). The antenna will read and transmit the EPC tags again and transmit them to ALE and pass them to FCA for generating transaction event.

Figure 21

A virtual manufacturer's scenario.

5.4.2. Experimental Results

Algorithm 7 shows the generated EPCIS events of reader 2. As we expected, the reader detected the 5 items (1 box in $s s c c$ format and 4 items in $s g t i n$ format) and generated an ObjectEvent for 5 items. It generated an AggregateEvent describing information about 4 tag items. It also generated a QuantityEvent containing the number of included items.

Algorithm 7: The generated EPCIS events of reader 1.

<?xml version=“1.0” encoding=“UTF-8” standalone=“yes”?>

⋯

<epc>urn:epc:id:sgtin:2234567.223456.11</epc>

<epc>urn:epc:id:sgtin:2234567.223456.3</epc>

<epc>urn:epc:id:sgtin:2234567.223456.2</epc>

<epc>urn:epc:id:sgtin:2234567.223456.15</epc>

</epcList>

<bizStep>commissioning</bizStep>

<disposition>active</disposition>

<readPoint> <id>BeltA</id> </readPoint>

<bizLocation> <id>Belt-commission</id> </bizLocation>

</ObjectEvent>

<epc>urn:epc:id:sgtin:2234567.223456.11</epc>

<epc>urn:epc:id:sgtin:2234567.223456.3</epc>

<epc>urn:epc:id:sgtin:2234567.223456.2</epc>

<epc>urn:epc:id:sgtin:2234567.223456.15</epc>

</childEPCs>

<bizStep>commissioning</bizStep>

<disposition>active</disposition>

<readPoint> <id>BeltA</id> </readPoint>

<bizLocation> <id>Belt-commission</id> </bizLocation>

</AggregationEvent>

<epcClass>urn:epc:id:sgtin:2234567.223456</epcClass>

<bizStep>commissioning</bizStep>

<disposition>active</disposition>

<readPoint> <id>BeltA</id> </readPoint>

<bizLocation> <id>Belt-commission</id> </bizLocation>

</QuantityEvent>

</EventList>

</EPCISBody>

</ns2:EPCISDocument>

The results of the virtual manufacturer's scenario are summarized in Table 8. We can perform automatic event generation according to various actions that happened during the virtual manufacturer's scenario by providing business context data and situation context data.

Table 8

The experimental results.

Description	Number of events	Generated event types
Reader 1	3	ObjectEvent, AggregationEvent, QuantityEvent
Reader 2	1	ObjectEvent
Reader 3	2	AggregationEvent, QuantityEvent

6. Related Work

The RFID technology is widely used to track and trace objects. Due to the scenario diversity and EPCIS events generation complexity, there are few studies on capturing application [22–26, 28, 29] to generate EPCIS events arising from supply chain activity.

Fosstrak et al. [22, 23] provide a custom capturing application and a generic capturing application to generate EPCIS events for an EPCIS repository. The custom capturing application can only generate ObjectEvent in the specified scenario, which is not appropriate for diverse supply chains to generate four EPCIS event types. In the generic capturing application case, a user must define and implement a set of JBoss rules (Drools) for generating EPCIS events.

WebSphere [24] uses an EPCIS connector to generate EPCIS events from incoming ECReports. When the EPCIS connector receives an ECReport, it creates an EPCIS event with the incoming ECReports and the metadata in a specified table. The metadata contains the event type and event fields to be generated, which is configured by the user.

BizAF [25] is proposed to develop RFID business applications cost-effectively in the EPC network. The capturing service in BizAF can play the role of capturing application to generate EPCIS events with RFID tag data. The user should define the condition and dataset to specify the event types and event fields. Thus, the capturing service collects real-time RFID tag data and generates EPCIS events according to the specific event type and event fields. However, the existing configuration method such as BizAF has the limitation that one event type is mapped to one reader name. That is, only one event type is generated at a specific logical reader. Different EPCIS event types cannot be generated for different incoming ECReports flexibly at a specific reader. Problems occur when different EPCIS event types are required.

The RSN tool [28, 29] can be used to simulation of RFID middleware by extending Petri nets. Users can virtually test RFID environments by setting the physical parameters of RFID readers. However, the RSN tool does not provide the functionalities for EPCIS events.

APDL [26] system can generate the EPCIS events based on the newly defined language. The BEG module in APDL plays the role of a capturing application. BEG automates the mapping between reports stemming from ALE and EPCIS events. APDL describes a business process in a coherent way that combines the ECSpec, LRSpec, and master data together. APDL captures the data and semantics of RFID processes. Several ECReports are defined at any ECSpec for generating the four EPCIS events. Thus, BEG generates EPCIS events and stores the generated events at the EPCIS repository. The BEG in APDL only specifies how to generate event fields for each EPCIS event. However, the condition and timing for each event type are unknown. That is, BEG does not know on which condition to generate which event type. The action field is complex for each event type; BEG does not specify how to get the value of the action field either.

7. Conclusion

There is no well-known study on specifying how to generate high level EPCIS events. Capturing application does not know to generate which EPCIS event types and how to get each semantic field value for an incoming ECReport. That is, the event types and semantic event fields are both uncertain.

In this paper, the FCA is proposed to solve the problem. FCA specifies generation rules about the four EPCIS event types with ECReports, situation context data, and transaction data to decide the event types for the incoming ECReports. If an event type generation rule is satisfied, event fields are generated with the ECReports, business context data, transaction data, and relevant AggregationEvent. After matching all the four EPCIS event type generation rules, FCA sends the generated EPCIS events to the EPCIS repository and turns to deal with the next incoming ECReports.

The incoming RFID tag data may be wrong due to the read problem caused by device. The event cycle defined to communicate between ALE and capturing application may also cause some tag data lost. Thus the generated EPCIS events are wrong due to the wrong incoming RFID tag data. However, after generating EPCIS events and delivering to EPCIS repository, capturing application cannot delete or modify EPCIS events. The only way is to generate subsequent EPCIS events. In future work, we plan to extend our work to generate subsequent EPCIS events for retracting or correcting prior to EPCIS events.

Footnotes

Notation

Disclosure

This paper is an extended version of a master thesis [

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

Acknowledgment

This research was supported by Bioindustry Technology Development Program,Ministry for Food,Agriculture,Forestry,and Fisheries,Republic of Korea.

References

Bhatt

Glover

RFID Essentials 2006

Sebastopol, Calif, USA

O’Reilly

Ahson

Ilyas

RFID Handbook: Applications, Technology, Security and Privacy 2008

Boca Raton, Fla, USA

CRC Press

Kim

Garrison

Understanding users' behaviors regarding supply chain technology: determinants impacting the adoption and implementation of RFID technology in South Korea

International Journal of Information Management 2010 30 5 388 398

2-s2.0-77955658251

10.1016/j.ijinfomgt.2010.02.008

Sarma

Brock

Engels

Radio frequency identification and the electronic product code

IEEE Micro 2001 21 6 50 54

2-s2.0-0035517988

10.1109/40.977758

EPCglocal

Gs1 epc tag data standard 1.6

2011, http://www.gs1.org/gsmp/kc/epcglobal/tds/

Martínez-Sala

A. S.

Egea-López

García-Sánchez

García-Haro

Tracking of returnable packaging and transport units with active RFID in the grocery supply chain

Computers in Industry 2009 60 3 161 171

2-s2.0-60549103020

10.1016/j.compind.2008.12.003

Chen

J.-L.

Chen

M.-C.

Chen

C.-W.

Chang

Y.-C.

Architecture design and performance evaluation of RFID object tracking systems

Computer Communications 2007 30 9 2070 2086

2-s2.0-34250667545

10.1016/j.comcom.2007.04.003

Gao

Yang

Ning

RFID application in tire manufacturing logistics

Proceedings of the 2nd IEEE International Conference on Advanced Management Science (ICAMS ′10)

July 2010

109 112

2-s2.0-77957276665

10.1109/ICAMS.2010.5553275

Yue

Bai

RFID application framework for pharmaceutical supply chain

Proceedings of the IEEE International Conference on Service Operations and Logistics, and Informatics (IEEE/SOLI ′08)

October 2008

1125 1130

2-s2.0-58149139229

10.1109/SOLI.2008.4686568

10.

Bustillo

Wal-mart radio tags to track clothing

2010, http://online.wsj.com/article/SB10001424052748704421304575383213061198090.html

11.

EPCglocal http://www.gs1.org/epcglobal/

12.

EPCglocal

The epcglobal architecture framework epcglobal final version 1.4

2010, http://www.gs1.org/gsmp/kc/epcglobal/architecture/

13.

Thiesse

Floerkemeier

Harrison

Michahelles

Roduner

Technology, standards, and real-world deployments of the EPC network

IEEE Internet Computing 2009 13 2 36 43

2-s2.0-63349085809

10.1109/MIC.2009.46

14.

Sundaram

Zhou

Piramuthu

Pienaar

Knowledge-based RFID enabled Web Service architecture for supply chain management

Expert Systems with Applications 2010 37 12 7937 7946

2-s2.0-77957829338

10.1016/j.eswa.2010.04.041

15.

EPCglocal

The reader protocol standard, version 1.1

2006

16.

EPCglocal

The application level events (ale) specification, version 1.1.1 part I: core specification

2009, http://www.gs1.org/gsmp/kc/epcglobal/ale/

17.

EPCglocal

Epc information services (epcis) version 1.0.1 specification

2007, http://www.gs1.org/gsmp/kc/epcglobal/epcis/

18.

Wang

Liu

A temporal RFID data model for querying physical objects

Pervasive and Mobile Computing 2010 6 3 382 397

2-s2.0-78049417415

10.1016/j.pmcj.2009.10.001

19.

Zhang

Kwon

Hong

A graph model based simulation tool for generating rfid streaming data

Proceedings of the 13th Asia-Pacific Web Conference

2011

290 300

20.

Nguyen

Lee

Y.-K.

Jeong

B.-S.

Lee

Event query processing in epc information services

Proceedings of the 3rd IEEE International Conference on Signal Image Technologies and Internet Based Systems (SITIS ′07)

December 2007

159 166

2-s2.0-57849121145

10.1109/SITIS.2007.50

21.

Guinard

Mueller

Pasquier-Rocha

Giving RFID a REST: building a web-enabled EPCIS

Proceedings of the 2nd International Internet of Things Conference (IoT ′10)

December 2010

1 8

2-s2.0-78751692818

10.1109/IOT.2010.5678447

22.

Floerkemeier

Roduner

Lampe

Rfid application development with the accada middleware platform

Systems Journal 2007 1 2 82 94

23.

Fosstrak http://code.google.com/p/fosstrak/wiki/AleCapturingApp/

24.

WebSphere

Websphere premises server v6.1 epcis support

2008

25.

Nam

Yeom

Business-aware framework for supporting RFID-enabled applications in EPC Network

Journal of Network and Computer Applications 2011 34 3 958 971

2-s2.0-79952451561

10.1016/j.jnca.2010.04.021

26.

Kefalakis

Soldatos

Konstantinou

Prasad

N. R.

Apdl: a reference xml schema for process-centered definition of rfid solutions

Journal of Systems and Software 2011 84 7 1244 1259

27.

EPCglocal

Core business vocabulary standard

2010, http://www.gs1.org/gsmp/kc/epcglobal/cbv/

28.

Ryu

Kwon

Hong

A simulation network model to evaluate RFID middlewares

International Journal of Software Engineering and Knowledge Engineering 2011 21 6 779 801

2-s2.0-83455200004

10.1142/S0218194011005517

29.

Ryu

Kwon

Hong

Generation of RFID test datasets using RSN tool

Personal and Ubiquitous Computing 2013 17 7 1409 1419

2-s2.0-84862668718

10.1007/s00779-012-0576-4

30.

Jia

Flexible cpaturing application for generating extensible epcis events [M.S. thesis] 2012

Busan, Korea

Pusan National University

Flexible Capturing Application for Enhanced Generation of EPCIS Events

Abstract

1. Introduction

Example 1.

2. Background and Motivation

2.1. RFID System Architecture

2.2. EPCIS Events

2.3. Motivation

Example 2 (a single reader case).

Example 3 (multiple readers case).

3. Modeling of RFID Semantic Data

3.1. Context Data

3.1.1. Situation Context Data

Definition 4 (situation context data).

Example 5.

3.1.2. Business Context Data

Definition 6 (business context data).

Example 7.

3.2. Transaction Data

Definition 8 (transaction data).

Example 9.

4. Flexible Capturing Application

4.1. Architecture

4.2. Event Generation

4.2.1. Event Generation Algorithm

Algorithm 1: Event generation algorithm.

4.2.2. AggregationEvent Generation

Algorithm 2: AggregationEvent generation algorithm.

4.2.3. QuantityEvent Generation

Algorithm 3: QuantityEvent generation algorithm.

4.2.4. TransactionEvent Generation

Algorithm 4: TransactionEvent generation algorithm.

4.2.5. ObjectEvent Generation

Algorithm 5: ObjectEvent generation algorithm.

Theorem 10.

Proof.

4.2.6. New Event Type Generation

Example 11.

Algorithm 6: New event type generation algorithm.

Theorem 12.

Proof.

4.3. A Running Example for Event Generation

5. Experimental Results

5.1. Implementation

5.2. Evaluation Metric

5.3. Experiments with Synthetic Data

5.3.1. A Synthetic Dataset

5.3.2. Performance Analysis

5.4. Experiments with Real Data Set

5.4.1. Real Dataset

5.4.2. Experimental Results

Algorithm 7: The generated EPCIS events of reader 1.

6. Related Work

7. Conclusion

Footnotes

Notation

Disclosure

Conflict of Interests

Acknowledgment

References