RFID Middlewares at 2021

Skip to first unread message

Mikk Leini

Sep 24, 2021, 4:25:51 AM9/24/21
to fosstrak

I have been going through several FOSS RFID middlewares and I can't help wondering why all those projects are dead (2-10 years without updates and using old SW stacks). E.g. Fosstrack, Oliot, Rifidi, AspireRFID, CUHK.
I also found 8 commercial RFID Middlewares, but there's very little public info about them. Only few seem to be actively developed.
And then I looked at GS1 certified SW programs:
There's no new ALE SW in 10 years, except Harting Ha-VIS in 2014, but Harting has discontinued RFID products saying that there's a market change.

I find it hard to believe such SW is ready and doesn't need any update. Can somebody, who is in the business, explain what's the status and future of GS1 standardized RFID Middlewares? I can't disclose my project details, but I appreciate references to future-proof enterprise RFID SW solutions.

Best regards,
Mikk Leini


Sep 24, 2021, 6:44:07 AM9/24/21
to fosstrak
Hi Mikk,

I was unaware Harting had discontinued their involvement in RFID!

My own area of interest is in automatic vehicle identification (AVI) of rail vehicles using RFID, and there are still a number of suppliers of GS1 UHF RFID hardware aimed at that specific environment.

In terms of software, however, I think a lot of hardware suppliers are doing their own in-house software, at least that is the impression I get. I have made some changes to the Fosstrak project, specifically the EPCIS repository module, which is something I was using as a demonstration data repository for a while. However, more recently, even the changes I've proposed for the Fosstrak EPCIS repository have not been merged in, so I wonder whether I'm the only one looking at it at all now! More importantly, the repository is only EPCIS 1.0 (or is it 1.1?) compliant, certainly not 1.2 - and 2.0 is now on the horizon!

I've not used the other components (such as ALE) at all.

BTW, another project in the Fosstrak suite is the webadapter, but this doesn't actually work, at least not when you have a reasonable amount of data in your repository (since it starts off by reading the entire repository, using EPCIS-compliant queries, to determine all the different options for reader, etc, for the user to be able to select one for filtering!) Again, no further development has occurred on this - it really needs rewriting differently.

I thought the OLIOT project was still ongoing though?

Reply all
Reply to author
0 new messages