Geeks With Blogs
Adam Sills Occasionally I come up with something worthwhile
What is Application Level Events
Overview
Application Level Events (ALE) is a standard created by EPCGlobal, Inc., an organization of industry leaders devoted to the development of standards for the Electronic Product Code (EPC) and Radio Frequency Identification (RFID) technologies. The ALE specification is a software specification indicating required functionality and behavior, as well as a common API expressed through XML Schema Definition (XSD) and Web Services Description Language (WSDL).

The behavior expressed through the ALE specification is a way to provided aggregation and filtering of tag data over a period of time. An ALE server allows you to specify when to start collecting data, when to stop collecting data, how to organize and sort the dataand when to send the data to interested parties. An ALE client allows you to communicate with any compatible ALE server to define data requirements and receive reports.

What Challenges Does ALE Help Overcome?
RFID has the potential to generate a massive amount of data in a typical production environment. If you have an environment with tens or hundreds of readers with each reader reading a number of tags at a low interval (polling at 250 milliseconds or in continuous mode where the reader just streams all tags it sees continually), you can see how the amount of data a business application would have to process can become unwieldy. If an application is not written in a manner to handle this large throughput of data, it can suffer severe scalability problems, perform poorly, or at worst, crash.

This is where the ALE specification comes in. It defines a configurable set of data gathering techniques that higher order business applications can then use to receive more specialized set of tags to process. ALE provides for a standard way to describe and define these data gathering techniques to help decouple a business application from the source of its RFID data.



Architecture
Logical Readers
In addition to decoupling a business application from its data stream, ALE also helps to decouple the data gathering techniques from the physical layout of a business environment through the concept of a logical reader. The logical reader layout is defined as required by the ALE specification, but vendors are allowed to implement in a manner most suitable to their needs (it is an extensibility point).

Regardless of who defines the logical reader, the ALE service would listen for data from DockDoor1 instead of Reader1, thus allowing processing applications to not need to know explicit physical layout of their environment, only an abstracted layout. A system administrator could map DockDoor1 to any number of RFID readers, antennas or handheld scanners and the ALE service would simply know that it was looking for data coming from DockDoor1.

This would also allow an administrator to replace faulty reader hardware or add or remove antennas from a reader without the client application being affected by the change.

Read Cycle
The Read Cycle is defined by the ALE specification but is not governed by the ALE specification and is left up to vendors to define. In essence, a Read Cycle is the smallest unit of interaction between a reader scanning for tags in its field and the reader reporting the data to the ALE service. This area is potentially going to get standardized, but at the moment it is up to vendors to provide an implementation.

Event Cycle
The Event Cycle is the smallest unit of interaction between the ALE interface and a client. It consists of zero or more Read Cycles, from one or more readers that are to be treated as a unit from a client perspective.

Event Cycle Boundary
An Event Cycle consists of a boundary which indicates when to start collecting data and when to stop collecting data. This startand stop conditions can be time-, stability- or trigger-based. A time-based condition is simply a number of milliseconds to wait before starting or stopping the boundary. A stability-based condition is only valid for stopping a boundary and is used to indicate stability in the set of tags detected (no new tags added or removed). A trigger-based condition allows for an external controlling process to start or stop the boundary.Triggers are an expected extension point in the ALE specification as the ALE specification does not define any standard trigger mechanisms.

Reports
After an Event Cycle Boundary has stopped, the data that has been collected during the Event Cycle is filtered and grouped and a set of reports are generated. There are numerous options that dictate what tags get seen in any given report, the following is a short description of each:
  • Output Set
    Whether to use the current set of tags, the set of tags that are new to this Event Cycle, or the set of tags that were seen last Event Cycle but not this one
  • Include and Exclude Filtering
    Apply a set of patterns to the tags being reported to filter them in or out. Filtering is optional and more than one or both types can be used.
  • Grouping
    Apply a set of patterns to the tags being reported to group logical units together. For instance you could group all products by a certain company or all products of a certain type together.
  • Data Format
    This option indicates how you want the data to be reported. You can choose to report only a count of data (very useful for grouping), or you can choose to report the actual tag ID values in one of their supported formats (as defined by the EPC Tag Data Standard).


Event Cycle Specification and Report Specification
The ALE API defines two configuration objects called an Event Cycle Specification (ECSpec or ALE Request) and Report Specification (ECReportSpec). When interacting with the ALE server, you must supply it with information regarding what you want the server to do. This is done by supplying the server with an ECSpec that dictates the boundary, which logical readers to receive data from and one or more ECReportSpecs.

Interaction Modes
Applications may have rules or requirements dictating how they should receive data so the ALE server supports three basic modes of interaction with clients: subscription, polling predefined ECSpecs and polling a new ECSpec.

Immediate Mode
The Immediate mode of interaction with an ALE server allows the client to send an ECSpec and have it be processed and fulfilled immediately, returning the reports when the ECSpecs first Event Cycle Boundary completes. This option requires the client to continually send the ECSpec definition to the server with every request.



Poll Mode
The Poll mode of interaction with an ALE server is similar to Immediate, except the ALE client defines the ECSpec on the server ahead of time. It gives the ECSpec a name which allows the ALE client to request data from it using the name instead of sending the ECSpec every time.



Subscribe Mode
The Subscribe mode of interaction with an ALE server defines the ECSpec ahead of time like Poll, however it doesn’t require the ALE client to continually request data from the server. Instead the ALE client adds a subscription to the ECSpec that the ALE server communicates with instead. One example of an ALE subscription would be an ALE client that opens a TCP port that the server can connect to and send reports through it.

The ALE Specification defines three types of subscriptions that all ALE servers should support: TCP, HTTP and FILE. Other subscription mechanisms are available depending on the vendor of the ALE server (such as MSMQ or MQSeries).



Globeranger iMotion Edgware Platform ALE Implementation
The iMotion Edgeware Platform version 5.0 and above provides an implementation of both an ALE server and client. The ALE server runs inside of the Edge Device Manager Service (EDM) and the ALE client is typically represented through a producer component in the Edge Process Manager (EPM).



Logical Reader
The concept of logical reader is supported in iMotion through the Reader Service, Group Service and the Tag Acquisition Group. The Reader Service defines the physical readers themselves that have the capacity to make up a logical reader. The Group Service is a data broker between the various data producing and consuming services. The Tag Acquisition Group allows a user to create a logical grouping of physical readers and apply various aggregation rules to them.



Event Cycle Specification and Report Specifications
Defining and managing the Event Cycle Specifications on the server is accomplished using the Edge Management Console (EMC). You can also define an Event Cycle Specification in the Event Workflow Editor and allow it to manage the ECSpec(s) it needs at runtime.



Subscriptions
Subscriptions in the iMotion ALE server can be added manually through the EMC or defined by a remote client. Regardless of how they’re created, they can be viewed and managed through the EMC



iMotion Edgeware Platform ALE Extensions
In addition to simply providing an implementation, iMotion supplies a number of extensions.

Scheduling
The iMotion ALE server allows a user to provide a schedule for the valid execution times of a given Event Cycle Specification. This feature allows an Event Cycle Specification to be disabled during periods of inactivity (a 2 shift warehouse for instance may not need the ALE specifications running at night). This also allows for a specific set of subscribers to be added and activated when a schedule is valid (you may have a dock door that performs shipping during the day and receiving at night; you can have those periods of time submit data to different ALE client applications).

As Data Received Event Cycle Stop Condition
There are times where a time-based aggregation may not make sense and you may want to receive reports immediately upon receiving data from a reader.

“Binary” Device Triggers
The ALE specification left triggers open to vendor extension, and the iMotion platform supports triggers based on “binary” devices (devices that are capable of reporting an on or off state such as an electronic eye).

Non-EPC Tag Support
The ALE specification is fully tied to EPC because the same organization creates both standards. The iMotion platform has the ability to support non-EPC tags through a tag encoding adapter layer that allows additional tag type support to be added in between major product releases.

Tag Operations
The iMotion platform supports the ability to send device operation commands (tag writing, tag killing, etc) through the ALE service and publish them to a logical reader name (Reader Command Group). This allows an ALE client to receive data from a logical reader and send a command to the same logical reader which would then get translated into the appropriate physical reader(s).

Gen2 Tag Information
The ALE specification hasn’t been updated to support Gen2 tag information yet (user memory, etc) so the iMotion platform provides support for the Gen2 memory sections of the tag.

Tag Source Information
The ALE specification does not include any information in a report indicating where a given source of data came from (physical or logical). There are scenarios where knowing this information would be useful so the iMotion platform provides the ability to include this additional information in a report.

Tag Extended Lifetime
The potential for RF interference can sometimes cause tags to be missed by a reader. To compensate for this (especially when dealing with Addition and Deletion reports) the iMotion platform provides the notion of an extended lifetime for a tag. If a tag is seen during an Event Cycle but not seen the next Event Cycle, that doesn’t necessarily mean that an Addition or Deletion should happen; your reader may have missed the tag or your reader’s poll interval doesn’t sync up well with your Event Cycle Boundary.

In this case, you can opt into extending the lifetime of tags beyond the Event Cycle they were last seen. This allows you to further smooth your data stream and can help prevent you from having to deal with missed tag reads in your higher order application. Posted on Thursday, December 15, 2005 7:40 AM iMotion Edgeware Platform , RFID , Application Level Events | Back to top


Comments on this post: Application Level Events (ALE) In A Nutshell

# re: Application Level Events (ALE) In A Nutshell
Requesting Gravatar...
It's good to see more on iMotion. Please keep it up.
Left by Anthony Trudeau on Dec 15, 2005 8:38 AM

# re: Application Level Events (ALE) In A Nutshell
Requesting Gravatar...
Very Good Explanation on ALE and it is very much useful to me.Keep adding more input on this ,that would help the vendors/buyers to know more about iMotion.

Bosco

Left by Bosco on Nov 15, 2007 12:10 AM

Your comment:
 (will show your gravatar)


Copyright © Adam Sills | Powered by: GeeksWithBlogs.net