Information-billing via Fosstrak and jBilling

June 11, 2012

Information has value! However, it is difficult to measure the value of information which is provided through the EPCglobal architecture. How do you calculate the value of supply chain visibility for example? Surely there are numerous calculations, but these are mostly based on “educated guessing”. Additionally the value of information is spread across multiple stakeholders, but costs and benefits are not evenly distributed. Mandating has failed in most industries as a means to push information suppliers into using RFID and the EPCglobal architecture. Alternative Cost Benefit Sharing approaches are limited in their scalability and fail to quantify the real value of RFID and the EPCglobal architecture, as there are many intangible benefits that are difficult to measure.

There is an alternative approach though to quantify the value of IT-investments apart from cost- or benefit-based value estimations – a market driven value calculation that uses the sales value of information as a definite financial measure. Considering the low individual value of product information, such as a ‘best before date’, there have to be simple technical means to measure and aggregate these micro values to a billable amount. This leads to certain paradigm shifts:

Figure 1: Paradigm shifts from information exchange to information trade

In a prototypic installation Fosstrak and jBilling have been used to connect information queries and information prices, thus providing a technical infrastructure to evaluate and bill product-related information. jBilling is an open source billing solution that is used, for example, in telecommunication industries.

And this is what it looks like. First a combined login procedure for Fosstrak and jBilling has been developed.

Figure 2: Integrated login procedure for Fosstrak and jBilling (Dieter Uckelmann, Quantifying the Value of RFID and the EPCglobal Architecture Framework in Logistics. Berlin, Germany: Springer 2012, p. 120)

The model of a billing-enabled EPCglobal Architecture has been verified through a lab-based scenario for the beverage industry.

Figure 3: Premium query and acceptance confirmation (Dieter Uckelmann, Quantifying the Value of RFID and the EPCglobal Architecture Framework in Logistics. Berlin, Germany: Springer 2012, p. 131)

If for example the wholesaler queries the EPCIS of the bottler, some of the retrived information (e.g. sales data) has to be paid for as shown in the figure above. These values can be charged individually or they can be combined with other payments such as deposits in the beverage scenario.

Figure 4: Example list of orders as shown in jBilling (Dieter Uckelmann, Quantifying the Value of RFID and the EPCglobal Architecture Framework in Logistics. Berlin, Germany: Springer 2012, p. 132)

If the willingness to pay for information increases, the suggested solution provides improved measurability, quantification and optimisation of information value, thus enabling new business models based on product- and supply network-related information sales in the EPCglobal architecture. In the long run this would allow an (r-) evolutionary process change from an “information exchange model” to an “information trade model”.

As mentioned this solution has only been used in a prototypic scenario as part of a dissertation thesis, so there is no source code available for the connection between Fosstrak and jBilling. If your interested in further information, please contact Dieter Uckelmann at HFT Stuttgart.


LLRP Toolkit For Java Released

April 18, 2012

I assume lots of Fosstrak users are also using the LLRP Toolkit for Java that was originally developed by the Fosstrak team and contributed to the LTK project. We just released a new version of the LTK for Java that is now available from sourceforge. The new release features a number of bug fixes. See the changelog for details.

Simplifying RFID App Development with Cloud Computing and Mashups

April 8, 2012

Check out this interesting presentation by Dominique Guinard where he illustrates how the Fosstrak components can be virtualized in the cloud and applications can be realized as web mashups.

Fosstrak EPCIS used in Norwegian Food Chain RFID Tracking

January 24, 2011

The RFIDJournal is reporting today about an RFID deployment in Norway by Hrafn that uses the Fosstrak EPCIS:

NLP was established in 2006 as an organization for reducing the environmental footprint of the logistics operations within the Norwegian fast-moving consumer goods (FMCG) supply chain. The RFID pilot is being managed by Hrafn (the Norse word for raven, symbolizing the two birds of Odin), an RFID consultancy and the pilot’s chief architect. The RFID infrastructure includes fixed readers provided by Impinj, antennas from Intermec and handheld readers supplied by Nordic ID, as well asTag Acquisition Processor (TAP) middleware from Reva Systems. Hrafn is also hosting Electronic Produce Code Information Services (EPCIS) software used to store RFID data and make it available to supply chain participants, employing the open-source EPCIS software known as Fosstrak (seeOpen-Source EPCIS Catching On). Lexit Group is installing and integrating the hardware and providing software that links a user’s back-end information, such as the order number and ship-to-location Global Location Number (GLN) code, with the pallets’ tag ID numbers, while Telenor Ojects‘ Shepherd platform links data from read events to the EPCIS software, while also providing hardware monitoring by detecting errors such as connectivity problems with a reader or antennas out of service.

Read full article on RFIDJournal.

LLRP Commander Applications: RFID Based Sensing

September 23, 2010

I’ve been developing ultra low-cost wireless sensor nodes using the RFID tag antenna as a sensing mechanism. Essentially, that involves relating a change in a physical parameter of interest to a corresponding change in the RFID tag’s electrical properties.For an LLRP compliant reader, that entails extracting quantities like log time, EPC, Channel Index, Tag Count and Peak RSSI level. For this purpose, I’ve found the LLRP Commander and associated MATLAB extensions to be an invaluable resource in seamlessly extracting the sensor-tag data for further processing.

The LLRP Commander has a useful tabular view to parse incoming RO_ACCESS_REPORT messages and display tag data as we can see in Fig 1. For example, by looking for a specific EPC we can infer if the reader is continually observing a tag over time. Similarly, by observing gross changes in the Peak RSSI, we can discern whether a change in some physical parameter is changing RFID tag antenna performance.

Fig 1: The ROAccessReport Table View

As an example, here’s a design of an RFID temperature alarm sensor that makes use shape memory polymer actuation to trigger an alarm when the temperature exceeds 7 C. For those who are unfamiliar with the name, a Shape Memory Polymer (SMP) is a polymer which retains a deformed position when cooled below a specific temperature and which gradually actuates and returns to the un-deformed position when heated above it. The specific temperature of actuation can be controlled by varying the chemistry of the polymer. Naturally, this makes for a great temperature dependent actuation technique. Fig 2. shows the sensor prototype while Fig 3. illustrates the sensor working.

Fig 2: The temperature sensor prototype

Fig 3: The temperature sensing mechanism

As we can see from Fig.3 the sensor is initialized by cooling the sensor below 7 C and deforming the polymer in such a way that the attached detuning metal plate is behind the lower tag. Thus in this state, the lower tag responds with a lower backscatter response power than the top tag. Now if the sensor is placed in a zone above 7 C, the polymer starts to actuate and the metal plate takes up a position behind the upper tag. Thus the upper tag now responds with a worse backscatter power response. By observing a flip in relative signal strength performance (as seen in Fig.4(a)), we can infer that a critical temperature threshold has been violated.

LLRP Commander’s MATLAB integration allows us leverage MATLAB’s computational capabilities to create very illustrative figures and graphs. For example, Fig. 4(b) demonstrates how MATLAB was used to generate the temperature tag-sensor response graph by
using the tag data recorded from LLRP Commander.

Fig 4(a): Tag RSSI as a state indicator

Fig 4(b): MATLAB code accessing LLRP SQL database

Scope for Feature Addition

I think the versatility of the LLRP Commander would be boosted by including the following features:

1)      Tag Population Analysis: A sweep to detect all tags in the vicinity of the reader. The user could then select tags that matter and choose to only display content from them. Also it would be nice to associate an EPC with a tag name like “Bottom Tag” or “Metal Tag” for convenience.

2)      Filtering by Channel Index: For example, if I am interested in displaying RSSI values from a certain EPC at 902 MHz only – this would be very useful in frequency sweeps.

I’d be happy to make additional posts on how I used LLRP Commander to implement different types of sensing techniques. Thanks to Chris and Sam for implementing features like the ROAccessReports table!

You can read more about Tag Antenna Based Sensing at:



Maximum reads per second?

December 15, 2009

For one of our experiments, we have been trying to maximize the number of reads per second from a single RFID tag using an Impinj Speedway reader. At the moment, the best we are able to do is about 1 read per second (if there are more tags in range, we’ll get more reports per second). Has anyone in the community managed to get a higher sampling rate (=higher read rates) and could share their ADD_ROSPEC message?  Our ADD_ROSPEC is posted below .


<?xml version=”1.0″ encoding=”UTF-8″?>
<llrp:ADD_ROSPEC xmlns:llrp=”; Version=”1″ MessageID=”4″>

SQL Database Integration in Fosstrak LLRP Commander/ALE Middleware

December 12, 2009

In a previous blog post, I already mentioned a new feature of Fosstrak that allows users to log tag reads reported in LLRP RO_ACCESS_REPORTS to a SQL DB. Here are a few screenshots that illustrate this functionality.

Specify DB connection in Fosstrak LLRP Commander

LTKJava – the (hidden) Fosstrak module

December 9, 2009

I was checking the other day the download numbers of LTKJava, the Java implementation of a Codec for the LLRP protocol which the Fosstrak team contributed to the LLRP toolkit project. The Java implementation has been downloaded more than 600 times since we released the latest version at the end of July. The usage of LTKJava by major reader vendors and reader middleware such as Intermec and OatSystems underlines the contribution open source software can make to the field of RFID and the adoption of standardized protocols.

At Fosstrak, we are using LTKJava in our Fosstrak LLRP Commander, a tool to control and manage RFID readers via LLRP.

Mark Roberti of the RFIDJournal writes about Fosstrak

November 5, 2009

Mark Roberti, editor of the RFIDJournal, writes about Fosstrak and the adoption of open source EPCIS on his blog.

New Feature of Fosstrak LLRP Commander: Log LLRP tag reads to SQL database

November 5, 2009

This is a quick post about a really cool feature Samuel, the Fosstrak lead on the LLRP Commander, added in the last release that allows users to specify the database to which LLRP messages are logged. Previously, we used a database that was built-in into the LLRP Commander. With the new feature, users can specify a (remote) SQL database server of their choice to which they want the data to be logged. This makes data analysis really trivial. Setup an open source database such MySQL or PostgresQL, install the Fosstrak LLRP Commander, connect to your reader or readers of choice and then analysis your data via SQL. The Fosstrak LLRP Commander logs all messages, but also parses the individual RO_ACCESS_REPORTs for TAG_REPORT_DATA on each tag read and lists each TAG_REPORT_DATA parameter as a new row in the SQL table.

This is great for data analysis purposes. No need to write any code to get RFID data such as IDs or RSSI values from one or more readers. At the MIT Auto-ID Lab, we are now using Matlab to query the database and visualize the data captured.