![]() ![]() ![]() ![]() ![]() ![]() ![]() |
The following sections describe the ALEPC API programming components that you use to write tags and include a formal, abstract specification of the ALEPC API. The external interface is defined by the ALEPC
interface (See ALEPC: Main Tag Writing Interface with UML Diagrams). This interface makes use of a number of complex data types that are documented in the sections starting at PCSpec. BEA extensions to the interface are described in BEA Gen2 Write Support.
One or more clients make method calls to the ALEPC
interface. Each method call is a request, which causes the ALE engine to take some action and return results. Thus, methods of the ALEPC
interface are synchronous.
The ALEPC
interface also enables clients to subscribe to events that are delivered asynchronously. You implement this capability by invoking methods that take a URI as an argument. Such methods return immediately, but subsequently the ALE engine within the Edge Server can asynchronously deliver information to the consumer denoted by the URI argument.
In the sections that follow, the API is described by using UML class diagram notation, as shown below:
The box as a whole refers to a conceptual class, having the specified data members and methods.
The ALEPC API is realized in several equivalent forms within WebLogic RFID Edge Server:
Each of these concrete forms of the ALEPC API has a slightly different structure and gives slightly different names to the different conceptual classes, data members, and methods defined in the UML within these sections. This variation is unavoidable, owing to syntactic constraints and stylistic norms within these different implementation technologies.
In most cases, the mapping from conceptual UML to the concrete details of any particular binding is very straightforward; where it is not, the specific documentation for each binding will make clear the relationship to the UML. The UML-level descriptions in these sections should be considered normative.
share/schemas/ALEPCService.wsdl
share/schemas/ALEPC.xsd
See also XML Representations.
ALEPC is the main interface that you use to program tags. The term "tag programming" refers to the act of associating an EPC value with some physical entity, such as an RFID tag or a printed label.
The Java implementation package is com.connecterra.alepc.api. Also see "BEA Gen2 Write Support" on page 5-31.
Table 5-1
A PCSpec
is a complex type that describes a programming cycle. A programming cycle is an interval of time during which a single tag is written and verified.
Java implementation package: com.connecterra.alepc.api.
See also "BEA Gen2 Write Support" on page 5-31.
The following sections provide information about a PCSpec
:
trials
) or as a length of time (duration
).
A PCSpec also contains an optional "application data" string, which is simply copied unmodified into every PCWriteReport
instance generated from this PCSpec
.
For a narrative description of programming cycles and their use of PCSpec instances, see Programming Cycles.
Table 5-2 PCSpec Fields
Java implementation package: com.connecterra.alepc.api
Describes administrative information for a PCSpec
.
Table 5-3
Java implementation package: com.connecterra.alepc.api
Describes how to handle failures in notification delivery. It is used by PCSubscriptionInfo
(see PCSubscriptionInfo) and ALEPC.subscribe(String, URI, PCSubscriptionControls
). Also see ALEPC: Main Tag Writing Interface with UML Diagrams).
Table 5-4 PCSubscriptionControls Fields
Java implementation package: com.connecterra.alepc.api
Describes administrative information about a subscription.
The notification failure controls for this subscription. See PCSubscriptionControls.
|
|
An AccessSpec
contains an ordered list of OpSpec
objects and a name. The list of OpSpecs
represent the sequence of operations to be performed on each tag in field. The base OpSpec
class is abstract; each subclass of OpSpec
refers to a specific command.
The Java implementation package is com.connecterra.alepc.api.See also "BEA Gen2 Write Support" on page 5-31.
The following sections provide information related to an AccessSpec
:
Java and XML Implementation Notes:
An <accessSpec>
element (repeatable) in a PCSpec
describes what commands to issue to each tag in a field, as they are "singulated." An accessSpec
has a name in order to match it with an accessReport
included in a PCWriteReport
.
An accessSpec
can contain a <stopOnError>
subelement, which contains a Boolean value. If stopOnError
is true, for any given tag, any error in an operation will halt processing for that tag. The inventory round then continues to the next tag in the field, and processing starts on that tag with the first operation. If omitted, stopOnError
is assumed to be false
.
A PCSpec
that contains no accessSpec
element acts as if it has a single implicit accessSpec
element with a single write operation. If the PCSpec
contains a cacheName
element, the writeOpSpec
uses that value for its epcCache
. This is the only point at which the top-level cacheName
element is used. Otherwise, the write specifies a param
value of epc
, which will be substituted using the data from the poll
or immediate
ALEPC API call.
If restrictSingleTag
was specified in the PCSpec
, explicitly or implicitly (through the lack of accessSpec
s), the PCWriteReport
contains the epc
element which contains the EPC value of the single tag written. This element is omitted in the PCWriteReport
of any PCSpec
that does not restrict operations to a single tag, whether one more multiple tags were discovered in the field. Additionally, a PCSpec
that contains no accessSpec
element will use the older form of PCWriteReport
, containing no opReport
.
Java implementation package: com.connecterra.alepc.api
The base OpSpec
class is abstract; each subclass of OpSpec
refers to a specific command: LockOpSpec
, KillOpSpec
, PasswordOpSpec
, ReadOpSpec
, WriteOpSpec
.
Each <accessSpec>
element contains an <operations>
subelement, which is the list of opSpecs
that describe the commands to issue to each tag ("operations"). These operations are read
, write
, password
, lock
, and kill
.
There are two URI forms for specifying a memory location on a tag for a read or write operation:
For absolute addressing, the URI needs to include a selection for bank, an offset within the memory bank, and a length of the memory extent, in bits.
urn:connecterra:tagmem:@bankid.length[.offset]
Where bankid
is, in Gen2, one of the four values: epc
, tid
, user
, or reserved
. Length and offset are integer values in bits, specified as decimal. The default offset value is 0.
When referring to a symbolic name, the URI simply includes the name.
urn:connecterra:tagmem:name
In the current implementation, the only valid value for name is epc
.
For a stack light device, the bankid
has one value: stacklight
. The memory bank is 20-bits wide, and each 4-bit segment corresponds to one light. For example, urn.connecterra:tagmem:@stacklight.4.12
and value urn:epc:raw:64.x9
will turn on the amber light.
The following code fragment demonstrates programmatic stack light control. The update value of 092F0
will turn off the White light (0), turn on the Blue light until next update (9), turn on the Green light for 10 seconds (2), do nothing to the Amber light (F), and turn off the Red light (0):
ALEPC alePCClient = new AxisALEPCClient(<alepcServiceURL>);
ALEPCFactory alePCFactory = AxisALEPCFactory.getInstance();
PCSpec pcSpec = alePCFactory.createPCSpec();
pcSpec.addLogicalReaderName("StackLight");
alePCClient.immediate(
pcSpec, new URI("urn:connecterra:stacklight:update=092F0"));
For more information on stack light control, see Configuring and Controlling Stack Lights in the RFID Reader Reference manual.
A <read field="
...
">
element is used to read from a segment of tag memory. The field attribute contains the URI to the tag memory location. The resulting opReport
contains the status and the read memory value. Data is padded as a 64-, 96-, or 128-bit value before being returned. For example, 48 bits of data would be returned as a padded 64-bit value.
A <write field="
...
">
element is used to write a segment of tag memory. The field attribute contains the URI to the segment tag memory location to write. The write operation contains one of three elements that can provide the data to be written to the specified memory. These elements, called data elements, are:
<literal>
dataURI
</literal>
: The dataURI is a raw or EPC URI that provides the data. The length of the data provided must match the length of the field. Note: | For writing, there are two URIs: one is an address, the other is a value. The <literal> element includes the value URI. A value URI is also used to specify access and kill passwords, and lock bits. The address URI is also used to specify additional memory locations which should be read, in PCSpecs and ECSpecs. |
<epcCache>
cacheName
</epcCache>
: Used to retrieve a value from the named EPC Cache.<param>
parameterName
</param>
: Used to perform a lookup in the parameters provided the ALEPC poll()
or immediate()
call to find the value to write.
A <password>
element attempts to transition the tag to secured mode. The password operation contains one of the data elements specified above in the <write>
element description - this data is used as the password in the Gen2 "access" operation. It is an error to use an epcCache
data element for this element.
A <lock>
element contains a mask element and a value element, both of which should contain a raw URI that provides an integer value. These raw URIs should be 10-bits wide when operating with Gen2 tags. For any of the bits in the mask element that are set, the corresponding lock bit on the tag is set to the bit in value at that position.
A 10-bit value is provided for the "mask" and "value" of the lock
command. In the mask, the bits that are set map to the bits in the value, to be applied to the state.
In each field, the high bit represents the "lock" value for that field, while the low bit represents the field's "permalock" value.
For the EPC, TID, and User memory fields:
Note the differences between the meanings for the bits in the two types of fields.
Lock operations are described in fuller detail in EPC Radio-Frequency Identity Protocols Class-1 Generation-2 UHF RFID Protocol for Communications at 860 MHz-960 MHz, Version 1.0.9.
A <kill>
element contains the kill password, which will be used to kill the tag. You specify this password using the same data subelement that the <password>
element uses. It is an error to use an epcCache
data element for this element.
For XML examples, see Gen2 PCSpec Examples.
Java implementation package: com.connecterra.alepc.api
The base DataSpec
class is abstract. Public implementations are: LiteralDataSpec
, EPCCacheDataSpec
, and ParamDataSpec
.
Java implementation package: com.connecterra.alepc.api
A PCWriteReport
describes the tag writing operation of a programming cycle.
The following sections provide information related to a PCWriteReport
:
The status of the programming cycle. See PCStatus.
|
|
The condition that terminated the failed programming cycle activation. See PCTerminationCondition.
|
|
Java implementation package: com.connecterra.alepc.api
An AccessReport
contains the name of the associated accessSpec
. Each <accessReport>
element contains a list of <tag epc="
epc
">
elements, one per tag detected in field.
Name of AccessReport object. See AccessReport.
|
|
List of TagReport objects. See TagReport.
|
Java implementation package: com.connecterra.alepc.api
A TagReport
contains the EPC of the tag, and an ordered list of OpReport
objects. There is a one-to-one correspondence between each OpReport
in the named AccessReport
and each OpSpec
in the corresponding AccessSpec
, and the ordering is preserved.
Java implementation package: com.connecterra.alepc.api
An OpReport
contains a status element that reports the operation was successful or provides failure information. For read and write operations, the opReport
also contains memory operation results. These results include a field element that matches the memory bank URI specified in the original opSpec
, and a value element that gives the value of the memory as a URI.
In the case of a write, the format of the value URI is exactly as provided as input - the literal write value, the parameter value, or the EPC URI provided by the cache. For a read, the value is formatted as described in the includedMemory
Table 5-10 OpReport Fields
Java implementation package: com.connecterra.alepc.api
PCStatus
is an enumerated type that identifies the termination status of a programming cycle.
Table 5-11
Java implementation package: com.connecterra.alepc.api
PCTerminationCondition is an enumerated type that describes the conditions that can cause a programming cycle to terminate with a failure.
Table 5-12 PCTerminationCondition Values
Java implementation package: com.connecterra.alepc.api
An EPCCacheSpec
describes a tag cache.
The following sections provide information related to an EPCCacheSpec
:
Java implementation package: com.connecterra.alepc.api
An EPCCacheReport indicates that an EPC cache is low.
Table 5-14 EPCCacheReport Fields
Describes the remaining content of the EPC cache. See EPCPatterns.
|
|
Java implementation package: com.connecterra.alepc.api
Describes administrative information about an EPC cache.
Table 5-15 EPCCacheSpecInfo
The EPCs in this cache. See EPCPatterns.
|
|
Java implementation package: com.connecterra.alepc.api
Table 5-16
The focal points of the ALEPC tag writing interface from an application perspective are the PCSpec
, PCWriteReport
, EPCCacheSpec
, and EPCCacheReport
objects. The RFID Edge Server provides a standard means of representing instances of these objects in XML. The XML form of PCWriteReport
and EPCCacheReport
is used by most of the asynchronous delivery mechanisms, as described in Asynchronous Notification Mechanisms. The XML forms are also very useful to user applications as a means of interchange, and for persistent storage.
The XML forms are defined by the XSD schema. This schema is in the RFID Edge Server installation in the file share/schemas/ALEPC.xsd
.
The Java binding for ALE provides XML serializer and deserializer classes for translating between the XML representation and the Java representation of the PCSpec
, PCWriteReport
, EPCCacheSpec
, and EPCCacheReport
types. Applications can use these facilities to process reports received via the Edge Server's asynchronous delivery mechanisms, and for other purposes. See Using XML Serializers and Deserializers from Java for more information.
The following sections present examples of PCSpec
, PCWriteReport
, EPCCacheSpec
, and EPCCacheReport
as rendered into XML. These examples include additional line breaks and whitespace for the sake of readability. RFID Edge Server permits (but does not require) this whitespace when reading XML; usually RFID Edge Server omits this whitespace when writing XML.
For PCSpec examples that demonstrate Gen2 capabilities, see Gen2 PCSpec Examples.
<?xml version="1.0" encoding="UTF-8"?>
<PCSpec xmlns="http://schemas.connecterra.com/alepc">
<!-- The name of the EPC cache from which this PCSpec obtains EPC
values for tag programming operations. Optional. -->
<cacheName>mycache</cacheName>
<!-- Specifies a string to be included in PCWriteReport instances
generated by this PCSpec. Optional. -->
<applicationData>application-specific data here</applicationData>
<logicalReaders>
<!-- determines which logical reader(s) will be used by this
PCSpec. Logical reader names are defined in edge.props. -->
<logicalReader>TagWriteStation</logicalReader>
</logicalReaders>
<!-- Specifies name/value pairs to be passed down to reader drivers used
by this PCSpec's programming cycles. Optional. -->
<readerParameters>
<readerParameter name="paramName">paramValue</readerParameter>
<readerParameter name="anotherParamName">another parameter
value</readerParameter>
</readerParameters>
<!-- Determines when this programming cycle starts and stops. -->
<boundarySpec>
<!-- Trigger that starts a programming cycle. Optional -->
<startTrigger> trigger URI here... </startTrigger>
<!-- Trigger that stops a programming cycle. Optional -->
<stopTrigger> trigger URI here... </stopTrigger>
<!-- Specifies maximum number of tag writing trials. Optional,
default is unlimited number of trials. -->
<trials>1</trials>
<!-- Specifies maximum number of milliseconds to spend retrying failed
tag writing operations. Optional, default is no time limit. -->
<duration>1000</duration>
</boundarySpec>
</PCSpec>
<?xml version="1.0" encoding="UTF-8"?>
<PCWriteReport date="2004-05-27T18:56:31.179Z"
savantID="test-edge-server"
specName="testspec"
totalMilliseconds="10"
totalTrials="1"
xmlns="http://schemas.connecterra.com/alepc">
<applicationData>application-specific data here</applicationData>
<wasSuccessful>true</wasSuccessful>
<status>SUCCESSFUL</status>
<physicalReaders>
<physicalReader>tws1</physicalReader>
</physicalReaders>
<failedLogicalReaders/>
<cacheName>mycache</cacheName>
<cacheSize>11</cacheSize>
<epc>urn:epc:tag:gid-64-i:1.5.1</epc>
<successfulLogicalReader>TagWriteStation</successfulLogicalReader>
</PCWriteReport>
<?xml version="1.0" encoding="UTF-8"?>
<EPCCacheSpec xmlns="http://schemas.connecterra.com/alepc">
<!-- Specifies a string to be included in EPCCacheReport instances
generated by this EPCCacheSpec. Optional. -->
<applicationData>cache-specific data here</applicationData>
<!-- Specifies that when this cache's size drops to (or below) the
given number of EPC values, a EPCCacheReport should be issued. -->
<threshold>2500</threshold>
<!-- Specifies that EPCCacheReport instances should include the current
contents of the cache. Optional, default is false. -->
<includeCacheContent>true</includeCacheContent>
</EPCCacheSpec>
<?xml version="1.0" encoding="UTF-8"?>
<EPCCacheReport date="2004-05-27T18:59:32.890Z"
savantID="test-edge-server"
xmlns="http://schemas.connecterra.com/alepc">
<cacheName>mycache</cacheName>
<applicationData>cache-specific data goes here</applicationData>
<cacheSize>10</cacheSize>
<cacheContent>
<pattern>urn:epc:pat:gid-64-i:1.5.[3-12]</pattern>
</cacheContent>
<threshold>2500</threshold>
</EPCCacheReport>
The share/schemas/ALEPC.xsd
file in the RFID Edge Server installation defines an XML representation for PCSpec
, PCWriteReport
, EPCCacheSpec
, and EPCCacheReport
instances, using the W3C XML Schema language.
To use the ALEPC tag writing API, you create an instance of the AxisALEPCClient
class provided in the com.connecterra.alepc.client
package. This class implements the ALEPC
interface as described in ALEPC: Main Tag Writing Interface with UML Diagrams and provides all of the methods described there. It also provides an additional method, getALEPCFactory
, which returns a factory for creating instances of other types, described below. The AxisALEPCClient
interacts with an WebLogic RFID Edge Server over the network using SOAP over HTTP. When you construct an instance of AxisALEPCClient
, you provide a service URL for the Edge Server with which you want to interact.
When using the AxisALEPCClient
class, you need to create instances of PCSpec
, EPCCacheSpec
, and other types described in this chapter. The ALEPCFactory
interface. in package com.connecterra.alepc.api
, provides methods for creating instances of those types. You obtain an instance of the ALEPCFactory
interface by calling the getALEPCFactory
method provided by the AxisALEPCClient
class. When passing arguments to methods of a specific AxisALEPCClient
instance, you must always use the factory instance provided by that AxisALEPCClient
instance.
The Java binding of the ALE API provides some additional utility classes for writing XML representations of the data types used in the ALE API. With these classes, you can convert a Java object representation of a particular data type into XML ("serialization"), and likewise convert an XML representation of a particular data type back into a Java object ("deserialization"). The XML schemas are located in your RFID Edge Server installation directory at:
/share/schemas/EPCglobal-ale-1_0.xsd
/share/schemas/EPCglobal.xsd
/share/schemas/EPCglobal-ale-1_0-RFTagAware-extensions.xsd
/share/schemas/ALEPC.xsd
To read and write XML for types used in the ALE tag writing API, you use an instance of the PCXMLSerializationFactory
provided in the com.connecterra.alepc.encoding
package. There is only one static instance of this class, which you obtain using the static method getInstance()
, with no argument. Using the PCXMLSerializationFactory
instance, you can create instances of PCXMLSerializer
and PCXMLDeserializer
to serialize and deserialize instances of the following classes: PCSpec
, PCWriteReport
, PCSpecInfo
, PCSubscriptionInfo
, PCSubscriptionControls
, EPCCacheSpec
, EPCCacheReport
, and EPCCacheSpecInfo
.
The following sections summarize BEA support for Gen2 command access:
In support of the UHF Generation 2 Air Interface Protocol, BEA provides extensions to the following classes:
com.connecterra.alepc.api.ALEPC
com.connecterra.alepc.api.PCSpec
getAccessSpecs() : List
setAccessSpecs(accessSpecs :List) : void
addAccessSpec(accessSpec :AccessSpec) : void
isRestrictSingleTag() : boolean
setRestrictSingleTag(restrictSingleTag :boolean) : void
accessSpecs
is a list of AccessSpec
objects, defaulting to null. If accessSpecs
is null, restrictSingleTag
is ignored. Only when accessSpecs
is set is the restrictSingleTag
property meaningful: when retrictSingleTag
is set true
, the <restrictSingleTag/>
element is added to the PCSpec
and the Edge Server attempts to detect multiple tags in field (and fails the PCSpec
if it detects that condition before programming). SeePCSpec and AccessSpec for more information.
com.connecterra.alepc.api.AccessSpec
getName() : String
setName(name :String) : void
getOpSpecs() : List
setOpSpecs(opSpecs :List) : void
addOpSpec(opSpec :OpSpec) : void
See AccessSpec and OpSpec for more information.
com.connecterra.alepc.api.WriteOpSpec
getField() : URI
getDataSpec() : DataSpec
WriteOpSpec
specifies a write operation to a memory bank on the tag. It contains the memory bank URI specifying which tag field to write, and a DataSpec
telling the Edge
Server how to calculate the value to write to that memory. See OpSpec for more information.
com.connecterra.alepc.api.PasswordOpSpec
getDataSpec() : DataSpec
PasswordOpSpec
represents an "access" command in the Gen2 tag protocol, which, if successful, moves the tag into "secured" state. The PasswordOpSpec
contains a DataSpec
, which tells the Edge Server how to compute the password for the tag. The provided DataSpec
cannot be an EPCCacheDataSpec
. See OpSpec for more information.
com.connecterra.alepc.api.KillOpSpec
getDataSpec() : DataSpec
KillOpSpec
represents a "kill" command in the Gen2 tag protocol, which, if successful, permanently moves the tag into "killed" state. The KillOpSpec
contains a DataSpec
, which tells the Edge Server how to compute the kill password for the tag. The provided DataSpec
cannot be an EPCCacheDataSpec
. See OpSpec for more information.
com.connecterra.alepc.api.ReadOpSpec
getField() : URI
ReadOpSpec
specifies a read operation from a memory bank on the tag. It contains the memory bank URI that specifies which tag memory to read. The associated OpReport
in the PCWriteReport
will contain the value read. See OpSpec for more information.
com.connecterra.alepc.api.LockOpSpec
getMask() : URI
getValue() : URI
LockOpSpec
specifies a lock operation on the tag. It contains the mask and value for the lock operation. As the Gen2 specification describes, the lock operation attempts to modify the lock bits, using the bits of mask for the mask bits, and the bits of value for the "action" bits. See section 6.3.2.10.3.5 of the EPCglobal Gen2 spec. For Gen2 tags, the mask and value should be 10-bit raw EPC URIs. See OpSpec for more information.
com.connecterra.alepc.api.DataSpec
There are three public implementations of DataSpec
: LiteralDataSpec
, EPCCacheDataSpec
, and ParamDataSpec
.
LiteralDataSpec
holds a URI, either an EPC URI, or a raw URI. EPCCacheDataSpec
names an EPC Cache. The value provisioned by the cache is used.ParamDataSpec
names a parameter. The parameter is looked up in the map provided in the ALEPC poll
or immediate
call, and the associated value is used.getParamName() : Strin
g
The data provided must be compatible with the memory specified. For a specific memory bank range, the data provided by the DataSpec
must be of the same size as the specified memory segment. The associated OpReport
in the PCWriteReport
will contain the value written. See DataSpec for more information.
com.connecterra.alepc.api.ALEPCFactory
createAccessSpec(name :String) : AccessSpec
createPasswordOpSpec(opDataSpec :DataSpec) : PasswordOpSpec
createLiteralPasswordOpSpec(password :URI) : PasswordOpSpec
createParamPasswordOpSpec(paramName :String) : PasswordOpSpec
createKillOpSpec(opDataSpec :DataSpec) : KillOpSpec
createLiteralKillOpSpec(password :URI) : KillOpSpec
createParamKillOpSpec(paramName :String) : KillOpSpec
createReadOpSpec(field :URI) : ReadOpSpec
createWriteOpSpec(field :URI, opDataSpec :DataSpec) : WriteOpSpec
createLiteralWriteOpSpec(field :URI, value :URI) : WriteOpSpec
createEPCCacheWriteOpSpec(field :URI, epcCacheName :String) : WriteOpSpec
createParamWriteOpSpec(field :URI, paramName :String) : WriteOpSpec
createLockOpSpec(mask :URI, value :URI) : LockOpSpec
createLiteralDataSpec(value :URI) : LiteralDataSpec
createEPCCacheDataSpec(epcCacheName :String) : EPCCacheDataSpec
createParamDataSpec(paramName :String) : ParamDataSpec
com.connecterra.alepc.api.PCWriteRepor
tgetAccessReports() : List
An AccessReport
contains a list of TagReports
, each of which represents one tag detected in field. Each TagReport
contains a list of OpReports
, one for each operation performed on the tag. See PCWriteReport and AccessReport for more information.
com.connecterra.alepc.api.AccessReport
getName() : String
getTagReports() : List
An AccessReport
has a name and a list of TagReports
. The name matches the name of the AccessSpec that is associated with this access's AccessReport
. There is one TagReport
for each tag that was processed by the AccessSpec
.
The accessReport
property of the PCWriteReport
is null
if the PCWriteReport
returns no accessReports
. See AccessReport and TagReport for more information.
com.connecterra.alepc.api.TagReport
getEPC() : URI
getOpReports() : List
The TagReport
contains the EPC of the tag, and an ordered list of OpReports
. There is a one-to-one correspondence between OpReports
in the named AccessReport
and OpSpecs
in the corresponding AccessSpec
, and the ordering is preserved. See TagReport and OpReport for more information.
com.connecterra.alepc.api.OpReport
getOperationStatus() : PCStatus
getField() : URI
getValue() : URI
The OpReport
contains the status of an OpSpec
in the AccessSpec
. The OpReports
for ReadOpSpec
and WriteOpSpec
contain a field URI describing the memory that was operated on, and, if the operation was successful, the associated value from the memory. See OpReport for more information.
In Gen2, it becomes meaningful to perform work while multiple tags are in the reader field. For backward-compatibility, a PCSpec
that is not identifiably Gen2 (a PCSpec
that does not contain one or more AccessSpecs
) will require that the field contain only a single tag, while a PCSpec
that contains Gen2 elements will allow multiple tags by default.
A new <restrictSingleTag/>
element has been added to the PCSpec
to restrict a Gen2 PCSpec
to return an error if there are multiple tags in field. This element is implicit in a PCSpec
that contains no AccessSpecs
. This restriction is on a best-effort basis, and does not represent a guarantee. The current release will only work on a single tag in field.
The ALEPC poll()
and immediate()
calls add PCSpec
parameters, providing values for use within the processing of the Programming Cycle. The poll
and immediate
calls accept a parameter map: a map from parameter name to parameter value. The old-style ALEPC calls, which only take a single EPC value, will generate a parameter map from the parameter epc
to the provided value.
The values in this parameter map can be used in three ways:
The write
, password
, and kill
operations can take a <param>
element for the data needed for the operation. The contents of that element are used as the key into the parameter map, and the associated parameter value is used as the data. For example, the PCSpec
can specify the epc cache and a user memory value that indicates the manufacturer, and poll()
can specify a date code.
Users of the readerParameters
of the PCSpec
have been modified to check these parameters for a match before searching the readerParameters
.
The following PCSpec examples demonstrate XML encoding of some Gen2 features:
The following examples are complete: readEPCBank.xml
, writeTagMemory.xml
and PCWriteReport
, and stackLight.xml
. The remaining examples show only the <accessSpec>
portion of the PCSpec. They use the same <logicalReaders>
and <boundarySpec>
elements as readEPCBank.xml
.
For all tags in field, report the EPC value of that tag.
<PCSpec xmlns="http://schemas.connecterra.com/alepc">
<applicationData>application specific data can go here</applicationData>
<logicalReaders>
<logicalReader>ConnecTerra1</logicalReader>
</logicalReaders>
<boundarySpec>
<trials>1</trials>
<duration>4000</duration>
</boundarySpec>
<accessSpec>
<operations>
<operation>
<read field="urn:connecterra:tagmem:epc"/>
</operation>
</operations>
</accessSpec>
</PCSpec>
For all tags in field, read the raw EPC bank including the CRC and control bits, and report that value.
<accessSpec>
<operations>
<operation>
<read field="urn:connecterra:tagmem:@epc.96"/>
</operation>
</operations>
</accessSpec>
For all tags in field, use 0x0000AAAA as the (32-bit) access password and report the first 32 bits of the reserved bank, followed by the next 32 bits. In a Gen2 tag these areas of the tag are the kill password, and the access password, respectively.
<accessSpec>
<operations>
<operation>
<password>
<literal>urn:epc:raw:96.x0000AAAA</literal>
</password>
</operation>
<operation>
<read field="urn:connecterra:tagmem:@reserved.32"/>
</operation>
<operation>
<read field="urn:connecterra:tagmem:@reserved.32.32"/>
</operation>
</operations>
</accessSpec>
For all tags in field, use 0x11111111 as the access password and write the EPC value specified there to the EPC bank.
<accessSpec>
<operations>
<operation>
<password><literal>urn:epc:raw:64.x11111111</literal></password>
</operation>
<operation>
<write field="urn:connecterra:tagmem:epc">
<literal>urn:epc:tag:sgtin-96:1.0037000.123456.1</literal>
</write>
</operation>
</operations>
</accessSpec>
For all tags in field, write 0x00000001 as the kill password and write 0x00000002 as the access password.
<accessSpec>
<operations>
<operation>
<!-- write x00000001 into the KILL password -->
<write field="urn:connecterra:tagmem:@reserved.32">
<literal>urn:epc:raw:64.1</literal>
</write>
</operation>
<operation>
<!-- write x00000002 into the ACCESS password -->
<write field="urn:connecterra:tagmem:@reserved.32.32">
<literal>urn:epc:raw:64.2</literal>
</write>
</operation>
</operations>
</accessSpec>
For all tags in field, write that raw value to the full EPC bank, overwriting the CRC and control bits.
<accessSpec>
<operations>
<operation>
<write field="urn:connecterra:tagmem:@epc.128">
<literal>urn:epc:raw:128.973572063680812240853843738361866</literal>
</write>
</operation>
</operations>
</accessSpec>
<PCSpec xmlns="http://schemas.connecterra.com/alepc">
<applicationData>Write Tag Memory</applicationData>
<logicalReaders>
<logicalReader>ConnecTerra1</logicalReader>
</logicalReaders>
<boundarySpec>
<trials>1</trials>
<duration>4000</duration>
</boundarySpec>
<accessSpec>
<operations>
<operation>
<write field="urn:connecterra:tagmem:epc">
<literal>urn:epc:tag:sgtin-96:1.0037000.123456.1</literal>
</write>
</operation>
</operations>
</accessSpec>
</PCSpec>
<PCWriteReport date="2006-04-04T21:45:55.369Z" savantID="Warren"
specName="write" totalMilliseconds="1141" totalTrials="0"
xmlns="http://schemas.connecterra.com/alepc">
<applicationData>Write Tag Memory</applicationData>
<wasSuccessful>true</wasSuccessful>
<status>SUCCESSFUL</status>
<physicalReaders>
<physicalReader>SimReadr</physicalReader>
</physicalReaders>
<failedLogicalReaders/>
<cacheSize>0</cacheSize>
<accessReport>
<tag epc="urn:epc:tag:sgtin-96:1.0037000.123456.1">
<opReport>
<status>SUCCESSFUL</status>
<field>urn:connecterra:tagmem:epc</field>
<value>urn:epc:tag:sgtin-96:1.0037000.123456.1</value>
</opReport>
</tag>
</accessReport>
</PCWriteReport>
For all tags in field, try to kill the tag with the provided (32-bit) kill password (0x22222222):
<accessSpec>
<operations>
<operation>
<kill>
<literal>urn:epc:raw:64.572662306</literal>
</kill>
</operation>
</operations>
</accessSpec>
For all tags in field, try to perform the specified lock operation with the provided password (0x11111111):
<accessSpec>
<operations>
<operation>
<password>
<literal>urn:epc:raw:64.286331153</literal>
</password>
</operation>
<operation>
<lock>
<mask>urn:epc:raw:64.3</mask>
<value>urn:epc:raw:64.3</value>
</lock>
</operation>
</operations>
</accessSpec>
Write tag memory with stack light information, turning on the Amber stack light indefinitely:
<?xml version="1.0" encoding="UTF-8"?>
<PCSpec xmlns="http://schemas.connecterra.com/alepc">
<applicationData>
Turn on Amber stack light indefinitely
(starting from bit 12, 4 bits)
</applicationData>
<logicalReaders>
<logicalReader>StackLight</logicalReader>
</logicalReaders>
<boundarySpec>
<trials>1</trials>
<duration>4000</duration>
</boundarySpec>
<accessSpec>
<operations>
<operation>
<!-- write EPC memory -->
<write field="urn:connecterra:tagmem:@stacklight.4.12">
<literal>urn:epc:raw:64.x9</literal>
</write>
</operation>
</operations>
</accessSpec>
</PCSpec>
For more information on stack light control, see Configuring and Controlling Stack Lights in the RFID Reader Reference manual.
![]() ![]() ![]() |