**1. Introduction**

RFID provides a way to connect the real world to the virtual world. An RFID tag can link a physical entity like a location, an object, a plant, an animal, or a human being to its avatar which belongs to a global information system. For instance, let's consider the case of an RFID tag attached to a tree. The tree is the physical entity. Its avatar can contain the type of the tree, the size of its trunk, and the list of actions a gardener took on it.

When designing an RFID-based application, a system architect must choose between three locations to store the information: a centralized database, a database locally attached to the device hold by each user of the application, or the tag itself. Each location leads to an RFIDbased architectural pattern1 . But how to choose the right architectural pattern? What are the application attributes which must be taken into account in order to make the right choice?

The state of the art does not bring satisfactory answers. Indeed, when an article describes a RFID-based architectural pattern, it does not mention the application attributes which lead to choose this architectural pattern. On the other hand, some books or articles present the qualities of architectural patterns. But they do not take into account specificities of RFID. For instance, EPCglobal provides a standardized answer [2]: the centralized architectural pat‐ tern. A mobile device, NFC-enabled for example, reads an identifier on the RFID tag, then sends a message to a server which associates the identifier to the avatar stored in a central database. Thanks to its simplicity, this architectural pattern is used by several applications. But, it requires a global computer network: Such requirement increases operational costs. Moreover, it does not withstand an important number of simultaneous RFID read opera‐ tions. Thus this pattern does not fit all RFID-based applications. [3] presents the stakes of introducing RFIDs inside an enterprise. But it does not contain any system architecture

<sup>1 .</sup> An. architectural. pattern. is. a. description. of. element. and. relation. types. together. with. a. set. of. constraints. on. how. they. may. be. used. [1].

© 2013 Simatic; licensee InTech. This is an open access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. © 2013 Simatic; licensee InTech. This is a paper distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

thoughts. In a survey about RFID in pervasive computing, [4] presents several application examples. Depending on the application, avatars are stored either in a central database or in the tags themselves. But the authors do not give any clues on why an application has chosen to store its avatars in a given location. On the other hand, [1] lists the attributes which must be accommodated in a system architecture. Above all, there are the functionalities which are required from the system. Then, orthogonal to these functionality attributes, there are quali‐ ty attributes. The authors distinguish system quality attributes (availability, modifiability, performance, scalability, security, testability, and usability), business qualities (time to mar‐ ket, cost and benefits, and projected lifetime), and qualities about the architecture itself (e.g. conceptual integrity). But the authors do not focus on RFID specific features.

The second aspect concerns the possibility of knowing the value (or having an order of idea of the value) of the avatar of a remote tag. By "remote", we mean that the user is not physi‐ cally near the tag: The user is not able to put her reader on the tag. All she has is the identifi‐

Choosing the Right RFID-Based Architectural Pattern

http://dx.doi.org/10.5772/54069

29

The third aspect is the staleness issue of the avatar of a remote tag. If the user is able to know the avatar of a remote tag, is it guaranteed that the returned avatar has indeed the last

The scalability criteria category evaluates how each architectural pattern behaves when

Its first aspect is the maximum number of tags which can be handled by the architectural

The second aspect characterizes the sensitivity of the architectural pattern to the number of

The cost attribute groups all of the aspects which have an influence on the installation costs

The first cost aspect concerns the requirement for a global network: do RFID readers have to be able to access at any time and any place to a specific computing machine (for instance, a server in the case of the centralized architectural pattern)? To fulfill this requirement, the readers may be equipped with a wired connection. In that case, the mobility of the readers is limited. The readers may also rely on Bluetooth® or Wi-Fi gateways. Both of these gateways may introduce installation costs. Moreover some readers may not be Wi-Fi enabled. For in‐ stance, the Nokia 6212 mobile phone is NFC-enabled, but has no Wi-Fi capabilities. Finally the reader may rely on a mobile data connection (e.g. UMTS, HSDPA, etc.). Such solution

The second cost aspect concerns the RAM requirement on each tag. The more RAM there is on the tag, the more expensive the tag is. Notice that RAM may actually be prohibited on tags for technical reasons and not for cost reasons. For instance, application may require the use of low-frequency tags (e.g. 125 kHz), so that readers can interact with tags even though there is a liquid between tags and readers. In this case, the throughput is too low for a tag to

The third cost aspect concerns the introduction of a new tag in the environment. For each architectural pattern, we determine the sequence of operations which is required in order to introduce a new tag in the environment. Knowing this sequence, we can determine how long this sequence lasts. Because this initialization procedure is executed by a human or a

er of the remote tag.

values associated to the tag?

there are numerous tags or numerous readers.

or the operational costs of the RFID-based application.

introduces operational costs because of data plans.

robot operator, its cost is proportional to the time spent.

host information other than its identifier.

simultaneous RFID tag read operations.

**2.2. Scalability attribute**

pattern.

**2.3. Cost attribute**

So we have analyzed several existing industrial or experimental RFID-based applications. Moreover, we have developed RFID-based applications. From this experience, we identify the relevant attributes to compare RFID-based architectural patterns. We present them in section 2. With these identified attributes and their different aspects, we analyze four RFIDbased architectural patterns, used by applications to access the avatar of a tagged entity. In the *centralized architectural pattern*, the mobile device reads an identifier on the RFID tag; then it contacts a server which associates this identifier to the avatar stored in a central data‐ base or in a database distributed between several companies [2]. With the *semi-distributed ar‐ chitectural pattern*, each mobile device holds a local copy of a central database associating RFID identifiers to avatars [5]. In the *distributed architectural pattern*, each RFID tag holds the avatar [6]. With the *RFID-based Distributed Shared Memory*, RFID tags hold the avatar and a replica of the avatar of other tags [7]. Sections 3 to 6 detail all of these architectural patterns: they present application examples and analyze the architectural pattern with the attributes identified in section 2. Thanks to this analysis, in section 7, we are able to provide guidelines to choose the convenient RFID-based architectural pattern. Finally, section 8 concludes this chapter and proposes perspectives for this work.
