Difference between revisions of "ALE Tag Classes"
From RifidiWiki
(→Writing data to a Tag) |
|||
| Line 1: | Line 1: | ||
| + | ---- | ||
| + | <div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;"> | ||
| + | ---- | ||
| + | =[http://ewefobyme.co.cc Under Construction! Please Visit Reserve Page. Page Will Be Available Shortly]= | ||
| + | ---- | ||
| + | =[http://ewefobyme.co.cc CLICK HERE]= | ||
| + | ---- | ||
| + | </div> | ||
This document describes the design of the edge server tag data layer. | This document describes the design of the edge server tag data layer. | ||
=High Level= | =High Level= | ||
| Line 10: | Line 18: | ||
The point of the physical tag layer is to provide some base abstractions to store data obtained from a tag read. The data at this level is raw -- the bits are not interpreted or encoded. It is intended to be easy to use by developers who are writing code that interacts with RFID readers to obtain tag reads. In addition it is intended to be extensible so that new physical tag models can be developed when needed. Below is a class diagram describing the physical tag layer in the edge server. | The point of the physical tag layer is to provide some base abstractions to store data obtained from a tag read. The data at this level is raw -- the bits are not interpreted or encoded. It is intended to be easy to use by developers who are writing code that interacts with RFID readers to obtain tag reads. In addition it is intended to be extensible so that new physical tag models can be developed when needed. Below is a class diagram describing the physical tag layer in the edge server. | ||
[[Image:PhysicalTagLayer.jpg|none|thumb|600px|Class diagram of Physical Tag Layer]] | [[Image:PhysicalTagLayer.jpg|none|thumb|600px|Class diagram of Physical Tag Layer]] | ||
| − | * The | + | * The <code>TagData</code> class represents a single tag read. It has two main data structures: |
| − | ** The | + | ** The <code>model<code> represents the bits that were read |
| − | ** The | + | ** The <code>metainformation</code> is a hashmap to store other information about the tag read, such as a timestamp, antenna number, and other information not stored on the tag itself, but which may be useful to a higher level application |
| − | * The | + | * The <code>PhysicalTagModel</code> is an abstract class that serves as a base class for various concrete Physical Tag Models. This class does not require many methods to be implemented because it is imagined that tag models can behave in very different ways. For example, while some tags -- such as C1G2 use a "memory bank" paradigm, others might follow a "file access" model. |
| − | *The concrete classes -- | + | *The concrete classes -- <code>C1G1PhysicalTagModel</code> and <code>C1G2PhysicalTagModel</code> provide data structures that mimic the EPC specifications from a data point of view (they do not mimic state changes, such as locking and killing). Data models other than EPCGlobal-specified ones could be introduced at this level |
| − | *The Physical Tag Layer also provides some classes that can be reused across many kinds of PhysicalTagModels, such as a | + | *The Physical Tag Layer also provides some classes that can be reused across many kinds of PhysicalTagModels, such as a <code>BitVector</code> that facilitates storing and manipulating bits as well as a class that helps convert between various representations of numbers (bits to hex, and so forth). |
==EPC Layer== | ==EPC Layer== | ||
The EPC layer is a set of algorithms that convert between various representations of EPC-encoded bits. While the Physical Tag Layer views information only in terms of bits, the EPC layer knows how to encode and decode this information. For example, with the EPC layer can convert this string of bits: | The EPC layer is a set of algorithms that convert between various representations of EPC-encoded bits. While the Physical Tag Layer views information only in terms of bits, the EPC layer knows how to encode and decode this information. For example, with the EPC layer can convert this string of bits: | ||
| − | + | <pre> | |
001100000000100000110011101100101101110111011001000000010100000000110101000001010000000000000000 | 001100000000100000110011101100101101110111011001000000010100000000110101000001010000000000000000 | ||
| − | + | </pre> | |
into this URI, encoded in Tag-URI format: | into this URI, encoded in Tag-URI format: | ||
| − | + | <pre> | |
urn:epc:tag:sgtin-96:0.0867360217.005.889520128 | urn:epc:tag:sgtin-96:0.0867360217.005.889520128 | ||
| − | + | </pre> | |
and can take that URI and convert it into this URI encoded in Pure-URI format: | and can take that URI and convert it into this URI encoded in Pure-URI format: | ||
| − | + | <pre> | |
urn:epc:id:sgtin:0867360217.005.889520128 | urn:epc:id:sgtin:0867360217.005.889520128 | ||
| − | + | </pre> | |
The EPC Layer is based on the Tag Data Specification from EPCGlobal. It relies on the TDT library from the open source Fosstrak project. | The EPC Layer is based on the Tag Data Specification from EPCGlobal. It relies on the TDT library from the open source Fosstrak project. | ||
| − | It is again important to point out that this layer is separate from the Physical Tag Layer -- A | + | It is again important to point out that this layer is separate from the Physical Tag Layer -- A <code>PhysicalTagModel</code> other than a C1G1 or C1G2 PhysicalTagModel could potentially store EPC information. In addition, it is possible that a EPC tag could store data that is not encoded as an EPC. |
==ALE Layer== | ==ALE Layer== | ||
| − | While the ALE layer is contains other classes than those just used by the tag data layer, it does provide interfaces necessary for it to aggregate, filter, and report tag data. The ALE layer defines what contracts a | + | While the ALE layer is contains other classes than those just used by the tag data layer, it does provide interfaces necessary for it to aggregate, filter, and report tag data. The ALE layer defines what contracts a <code>PhysicalTagModel</code> needs to fulfill in order for ALE to be able to use it. In addition the ALE specification defines datatypes, formats, and fields that are used at the ALE level to report tag data. |
[[Image:ALE-Fields.jpg|thumb|none|800px|Class diagram of ALE Layer]] | [[Image:ALE-Fields.jpg|thumb|none|800px|Class diagram of ALE Layer]] | ||
| Line 42: | Line 50: | ||
The ALE Specification defines three data structures that are important with regards to tags: | The ALE Specification defines three data structures that are important with regards to tags: | ||
===Fields=== | ===Fields=== | ||
| − | A field is a specific data item that resides on a tag. The fields define the ALE-Tag interface. If the ALE layer needs some data from a tag, it asks for a certain field. For example, there is the | + | A field is a specific data item that resides on a tag. The fields define the ALE-Tag interface. If the ALE layer needs some data from a tag, it asks for a certain field. For example, there is the <code>epc</code> field, and the <code>userBank</code> field. It is important to note that the meaning of the field depends on the type of tag that is reporting the data. For example, for a gen2 tag, the <code>epc</code> field refers to the toggle bit, the AFI, and the EPC as defined in the gen2 spec. For a gen1 tag, the <code>epc</code> refers to only the epc payload. For a different tag model, it could refer to something completely different. In addition, each field has an associated set of datatypes that are valid for that field. A field also has a default datatype and a default format for that datatype. |
===Data Types=== | ===Data Types=== | ||
| − | The ALE specification defines several built-in datatypes for the use of intrepreting data. Each datatype has an associated set of formats that it can report the data in. For example, the unsigned integer ( | + | The ALE specification defines several built-in datatypes for the use of intrepreting data. Each datatype has an associated set of formats that it can report the data in. For example, the unsigned integer (<code>uint</code>) data type can report data in either <code>hex</code> or <code>decimal</code> format. |
===Formats=== | ===Formats=== | ||
| − | A format defines a syntax for reporting data of a certain format. For example, for the | + | A format defines a syntax for reporting data of a certain format. For example, for the <code>epc</code> datatype, there are four valid formats: <code>epc-tag</code>, <code>epc-pure</code>, <code>epc-hex</code>, and <code>epc-decimal</code>. |
===ALE Physical Tag Model Adapter=== | ===ALE Physical Tag Model Adapter=== | ||
| − | Because the semantics of fields depend on the type of tag that ALE is asking about, the | + | Because the semantics of fields depend on the type of tag that ALE is asking about, the <code>PhysicalTagModel</code> needs to provide that information to the ALE layer. This is done through an adapter. Each concrete implementation of the <code>PhysicalTagModel</code> provides an <code>ALEPhysicalTagModelAdapter</code> to the ALE layer. This adapter knows how to get a specific field from its own kind of <code>PhysicalTagModel</code>. This way the ALE layer does not need to care about what kind of tag model (e.g. C1G1, C1G2, savi, etc) it is dealing with. It simply needs to ask the adapter for the field. |
| − | As an example, suppose a Gen1 tag was read. The ALE layer is interested in knowing the | + | As an example, suppose a Gen1 tag was read. The ALE layer is interested in knowing the <code>epc</code> field from that tag. The abstract super class of the tag model -- <code>PhysicalTagModel</code> provides an adapter to the ALE layer. The ALE layer then calls the <code>getEPC()</code> on the adapter. Since the adapter contains the logic for figuring out that the <code>epc</code> field only refers to the epc payload of memory bank 0 on the Gen1 Tag, the ALE layer does not have to worry about the fact that this tag is a gen1 tag. |
=Packages= | =Packages= | ||
| Line 59: | Line 67: | ||
* EPC Layer - green | * EPC Layer - green | ||
==org.rifidi.tags== | ==org.rifidi.tags== | ||
| − | The | + | The <code>org.rifidi.tags</code> package contains the base classes that can be used by all kinds of different implementations of physical tag models. For example, it contains the <code>PhysicalTagModel</code> abstract class, the <code>TagData</code> class, and the <code>BitVector</code>classes among others |
==org.rifidi.edge.tags.epc== | ==org.rifidi.edge.tags.epc== | ||
| − | The | + | The <code>org.rifidi.edge.tags.epc</code> contains the specific implementations of <code>PhysicalTagModel</code> for Class 1 Gen 1 and Class 1 Gen 2 tags. |
==org.rifidi.tags.encodings.epc== | ==org.rifidi.tags.encodings.epc== | ||
| − | This package has several packages that wrap the | + | This package has several packages that wrap the <code>org.fosstrak.tdt</code> libraries to help convert EPCs between various encodings and formats as defined in the EPCglobal Tag Data Specification. It basically provides an interface into the tdt classes. |
==org.fosstrak.tdt== | ==org.fosstrak.tdt== | ||
| Line 71: | Line 79: | ||
==org.rifidi.edge.ale== | ==org.rifidi.edge.ale== | ||
| − | This package defines the contracts that concrete implementations of | + | This package defines the contracts that concrete implementations of <code>PhysicalTagModel</code> must fulfill in order to be used by ALE. In addition it defines all the necessary datatypes and formats required by ALE. |
==org.rifidi.edge.tags.epc.ale== | ==org.rifidi.edge.tags.epc.ale== | ||
| − | This package provides the ALE adapters for the C1G1 and C1G2 tags. It is separated from | + | This package provides the ALE adapters for the C1G1 and C1G2 tags. It is separated from <code>org.rifidi.edge.tags.epc</code> in order to allow the <code>org.rifidi.edge.tags.epc</code> package to be independent from ALE. |
=Use Cases= | =Use Cases= | ||
==Reading a Tag== | ==Reading a Tag== | ||
| − | The most common usecase for using these classes is when a reader adapter is reading a tag. In this case, a new | + | The most common usecase for using these classes is when a reader adapter is reading a tag. In this case, a new <code>PhysicalTagModel</code> is created for the kind of tag being read (e.g. <code>C1G2PhysicalTagModel</code>). This object will be placed inside an instance of <code>TagData</code>. This class is put on the queue and sent to the receiver. |
==Writing data to a Tag== | ==Writing data to a Tag== | ||
This use case has not been implemented yet. | This use case has not been implemented yet. | ||
Revision as of 23:11, 23 November 2010
This document describes the design of the edge server tag data layer.
High Level
The purpose of the tag data layer serves three main purposes
- To provide a base set of classes that reader adapters can use to store tag reads and send them up to a higher layer in the edge server. In addition the the edge server can use these classes to store tag information which the reader adapters can use to write data to tags. This service is, for now, concerned with C1G2 and C1G1 tags.
- To provide the necessary algorithms to convert between various ID encodings and their representations. Currently this is primarily concerned with the EPC encodings such as SGTIN and GID. This service allows a bit string to be converted to a URN representation, for example.
- To provide hooks that allow some other aggregating, filtering, or reporting services to use the data that has been collected. For now this is primarily concerned with ALE.
It is important to note that these services, while now aimed at an implementation of EPC Gen1 and Gen2 tags and using ALE to aggregate and report data, are general enough to support future extensions. For example, it is possible to use ALE to report non-epc data that is not stored on a physical tag adhering to a EPCGlobal spec. Therefore the three main services are distinct and are loosely coupled.
Physical Tag Layer
The point of the physical tag layer is to provide some base abstractions to store data obtained from a tag read. The data at this level is raw -- the bits are not interpreted or encoded. It is intended to be easy to use by developers who are writing code that interacts with RFID readers to obtain tag reads. In addition it is intended to be extensible so that new physical tag models can be developed when needed. Below is a class diagram describing the physical tag layer in the edge server.
- The <code>TagData</code> class represents a single tag read. It has two main data structures:
- The <code>model<code> represents the bits that were read
- The <code>metainformation</code> is a hashmap to store other information about the tag read, such as a timestamp, antenna number, and other information not stored on the tag itself, but which may be useful to a higher level application
- The <code>PhysicalTagModel</code> is an abstract class that serves as a base class for various concrete Physical Tag Models. This class does not require many methods to be implemented because it is imagined that tag models can behave in very different ways. For example, while some tags -- such as C1G2 use a "memory bank" paradigm, others might follow a "file access" model.
- The concrete classes -- <code>C1G1PhysicalTagModel</code> and <code>C1G2PhysicalTagModel</code> provide data structures that mimic the EPC specifications from a data point of view (they do not mimic state changes, such as locking and killing). Data models other than EPCGlobal-specified ones could be introduced at this level
- The Physical Tag Layer also provides some classes that can be reused across many kinds of PhysicalTagModels, such as a <code>BitVector</code> that facilitates storing and manipulating bits as well as a class that helps convert between various representations of numbers (bits to hex, and so forth).
EPC Layer
The EPC layer is a set of algorithms that convert between various representations of EPC-encoded bits. While the Physical Tag Layer views information only in terms of bits, the EPC layer knows how to encode and decode this information. For example, with the EPC layer can convert this string of bits: <pre> 001100000000100000110011101100101101110111011001000000010100000000110101000001010000000000000000 </pre> into this URI, encoded in Tag-URI format: <pre> urn:epc:tag:sgtin-96:0.0867360217.005.889520128 </pre> and can take that URI and convert it into this URI encoded in Pure-URI format: <pre> urn:epc:id:sgtin:0867360217.005.889520128 </pre>
The EPC Layer is based on the Tag Data Specification from EPCGlobal. It relies on the TDT library from the open source Fosstrak project.
It is again important to point out that this layer is separate from the Physical Tag Layer -- A <code>PhysicalTagModel</code> other than a C1G1 or C1G2 PhysicalTagModel could potentially store EPC information. In addition, it is possible that a EPC tag could store data that is not encoded as an EPC.
ALE Layer
While the ALE layer is contains other classes than those just used by the tag data layer, it does provide interfaces necessary for it to aggregate, filter, and report tag data. The ALE layer defines what contracts a <code>PhysicalTagModel</code> needs to fulfill in order for ALE to be able to use it. In addition the ALE specification defines datatypes, formats, and fields that are used at the ALE level to report tag data.
The ALE Specification defines three data structures that are important with regards to tags:
Fields
A field is a specific data item that resides on a tag. The fields define the ALE-Tag interface. If the ALE layer needs some data from a tag, it asks for a certain field. For example, there is the <code>epc</code> field, and the <code>userBank</code> field. It is important to note that the meaning of the field depends on the type of tag that is reporting the data. For example, for a gen2 tag, the <code>epc</code> field refers to the toggle bit, the AFI, and the EPC as defined in the gen2 spec. For a gen1 tag, the <code>epc</code> refers to only the epc payload. For a different tag model, it could refer to something completely different. In addition, each field has an associated set of datatypes that are valid for that field. A field also has a default datatype and a default format for that datatype.
Data Types
The ALE specification defines several built-in datatypes for the use of intrepreting data. Each datatype has an associated set of formats that it can report the data in. For example, the unsigned integer (<code>uint</code>) data type can report data in either <code>hex</code> or <code>decimal</code> format.
Formats
A format defines a syntax for reporting data of a certain format. For example, for the <code>epc</code> datatype, there are four valid formats: <code>epc-tag</code>, <code>epc-pure</code>, <code>epc-hex</code>, and <code>epc-decimal</code>.
ALE Physical Tag Model Adapter
Because the semantics of fields depend on the type of tag that ALE is asking about, the <code>PhysicalTagModel</code> needs to provide that information to the ALE layer. This is done through an adapter. Each concrete implementation of the <code>PhysicalTagModel</code> provides an <code>ALEPhysicalTagModelAdapter</code> to the ALE layer. This adapter knows how to get a specific field from its own kind of <code>PhysicalTagModel</code>. This way the ALE layer does not need to care about what kind of tag model (e.g. C1G1, C1G2, savi, etc) it is dealing with. It simply needs to ask the adapter for the field.
As an example, suppose a Gen1 tag was read. The ALE layer is interested in knowing the <code>epc</code> field from that tag. The abstract super class of the tag model -- <code>PhysicalTagModel</code> provides an adapter to the ALE layer. The ALE layer then calls the <code>getEPC()</code> on the adapter. Since the adapter contains the logic for figuring out that the <code>epc</code> field only refers to the epc payload of memory bank 0 on the Gen1 Tag, the ALE layer does not have to worry about the fact that this tag is a gen1 tag.
Packages
- ALE Layer - blue
- Physical Tag Layer - pink
- EPC Layer - green
org.rifidi.tags
The <code>org.rifidi.tags</code> package contains the base classes that can be used by all kinds of different implementations of physical tag models. For example, it contains the <code>PhysicalTagModel</code> abstract class, the <code>TagData</code> class, and the <code>BitVector</code>classes among others
org.rifidi.edge.tags.epc
The <code>org.rifidi.edge.tags.epc</code> contains the specific implementations of <code>PhysicalTagModel</code> for Class 1 Gen 1 and Class 1 Gen 2 tags.
org.rifidi.tags.encodings.epc
This package has several packages that wrap the <code>org.fosstrak.tdt</code> libraries to help convert EPCs between various encodings and formats as defined in the EPCglobal Tag Data Specification. It basically provides an interface into the tdt classes.
org.fosstrak.tdt
This package does the heavy lifting of translating tags between various formats.
org.rifidi.edge.ale
This package defines the contracts that concrete implementations of <code>PhysicalTagModel</code> must fulfill in order to be used by ALE. In addition it defines all the necessary datatypes and formats required by ALE.
org.rifidi.edge.tags.epc.ale
This package provides the ALE adapters for the C1G1 and C1G2 tags. It is separated from <code>org.rifidi.edge.tags.epc</code> in order to allow the <code>org.rifidi.edge.tags.epc</code> package to be independent from ALE.
Use Cases
Reading a Tag
The most common usecase for using these classes is when a reader adapter is reading a tag. In this case, a new <code>PhysicalTagModel</code> is created for the kind of tag being read (e.g. <code>C1G2PhysicalTagModel</code>). This object will be placed inside an instance of <code>TagData</code>. This class is put on the queue and sent to the receiver.
Writing data to a Tag
This use case has not been implemented yet.
