Flexible Capturing Application for Enhanced Generation of EPCIS Events

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.


Introduction
Radio frequency identification (RFID) [1][2][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][7][8][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][13][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. 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][23][24][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.

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.

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. 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, ECPIS     or how the event relates to the business transaction in a TransactionEvent.

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.
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 biz-TransactionList. 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.
International Journal of Distributed Sensor Networks 5 Thus, we can formally state a flexible capturing application problem as follows.
Given a set of ECReports which include RFID tag data from ALE and a set of context data , generate a set of EPCIS events with desired event fields for each ∈ .

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.

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.

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.
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 ( , , , , and ), 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); (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. An example of situation context data is shown in Figure 6.  After checking the validity of scd. , then copy fields of scd. into appropriate fields of an event .
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 In order to generate EPCIS events, the situation context data needs to provide a function for checking errors. Table 3 shows the function.

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 = ( , , , and ). 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 = ( , , , and ), where is a name of the reader; (ii) is a bizLocation; (iii) is a bizStep; (iv) is a disposition. In order to generate EPCIS events, the business context data needs to provide several functions. Table 4 shows the functions.
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.

Transaction Data.
Transaction data determines Transac-tionEvent type and provides the action field and bizTrans-actionList field of TransactionEvent. It is represented in the format of = ( , , , , and ). 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].   (iii) is a set of EPCs; (iv) is a name of the reader; (v) 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.
In order to generate EPCIS events, transaction data needs to provide several functions. Table 5 shows the functions.

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). Figure 9 shows the proposed architecture of the FCA. FCA consists of three principal components: ALE accessor, event generator, and EPCIS accessor. 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.

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

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 Aggrega-tionEvent as shown in Figure 10.
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. 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. 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.     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.

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.
Algorithm 3 shows the QuantityEvent generation algorithm which deals with two usage cases of the Quanti-tyEvent.

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 . Details of TransactionEvent generation algorithm are described in Algorithm 4.

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.

Theorem 10. Giving the ECReports , business context data , and situation context data , algorithm ObejctEvent correctly generates ObejctEvent .
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.

New Event Type Generation.
Although the EPCglobal provides core event types such ObjectEvent, Aggregation-Event, 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. 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.

Theorem 12.
Given an ECReport , business context data, and situation context data , algorithm new event type correctly generates new event type .
Proof. In algorithm new event type generation, if . . 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.

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.
Input: { , td, bc, }is ECReports; td is a set of transaction data; bc is business context data; is situation context data; Output: { }is a set of TransactionEvent; procedure TransactionEventGeneration( , td, bc, ) if . = then sub.action ← ADD; / / Case 1 (6) if . = then sub.action ← DELETE; / / Case 3 (7) sub.epcList ← r.epcList; (8) obtainBCDFields(sub, bc); (9) addBizTran(td , sub); (10) copySCDFields(sub, .te); (11) .add(sub); end if end if end for (12)  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 EPCequipped case. Table 6 summarizes the generated EPCIS event types of the manufacturer supply chain by using FCA.

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.

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 as shown in (1). Here, ∑ =1 is total number of tag records in generated EPCIS events, is the number of generated events, is the number tags included in a generated event, and is the number of tag data involved in event generation:

Experiments with Synthetic Data.
In this section, we analyze the performance of FCA.

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-wholesalerretailer 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. <SituationContextData> <ne> <isExist>true</isExist> <eventType>ReturnCaseEvent</eventType> <fieldList> <field> <name>reason</name> <value>wrong product</value> </field> </fieldList> </ne> </SituationContextData> <?xml version="1.0" encoding="UTF-8"?>

16
International Journal of Distributed Sensor Networks 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 ( < 10000) item tags in reader Ret-B in the format of urn:epc:id:sgtin:1234567.123456.X; X is from 1 to . There are 10000-case tags in reader Ret-C in the format of urn:epc:id:sscc:0641414.12345X; X is from 00001-to 10000-.
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 ( < 20000) item tags in reader Man-A in the format of urn:epc:id:sgtin:1234567.123456.X; X is from 1 to . There are 20000-case tags in reader Man-B in the format of urn:epc:id:sscc:0641414.12345X; X is from 00001-to 20000-.
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 ( < 30000) item tags in the format of urn:epc:id:sgtin:1234567.123456.X; X is from 1 to . There are 30000-case tags in the format of urn:epc:id:sscc:0641414.12345X; X is from 00001-to 30000-. 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.

Performance Analysis.
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 Aggregation-Event 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 Aggrega-tionEvent and QuantityEvent at reader Man-C and Aggre-gationEvent 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. Tag data are included in an ECReport as the input of capturing application to be processed. The relationship between the number of ECReports and the number of tag data involved in event generation is as in shown (2). Here is the number of tags (item and case should be both included) which arrive at a reader at the same time. is the number of readers. For example, 9 item tags and 1 case tag arrive at reader Who-A at the same time; then is 10. There are four readers in the wholesaler supply chain; thus is 4. If is 30000, then value of is 12000: (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.
From the above comparison, we can know that FCA can generate EPCIS events more flexibly with a little more time.

Experiments with Real Data Set.
In this subsection, we conducted experiments to verify flexibility of FCA using real RFID data set.

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

Experimental
Results. Algorithm 7 shows the generated EPCIS events of reader 2. As we expected, the reader detected the 5 items (1 box in format and 4 items in 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.
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.

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

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. Notation oe/ae/qe/te/ne: ObjectEvent/AggregateEvent/ QuantityEvent/TransactionEvent/ NewEvent generation rule isOE/isAE/isTE: a variable for generating unnecessary OBSERVE ObjectEvent/Aggregation/ TransactionEvent/or not isExist: a variable for generating a new event type fieldList: a set of extensible fields and each field has a pair of name and value actionList: a set of actions bSList: a set of bizSteps.

Disclosure
This paper is an extended version of a master thesis [30].