Rifidi Edge Server Product Distribution Sine 10/2009 Release: Over 10,000 Downloads Across 119 Countries

 

Country Downloads
1. China 2,616
2. Brazil 1,063
3. India 898
4. United States 769
5. Italy 311
6. Germany 230
7. France 213
8. Spain 211
9. Colombia 194
10. United Kingdom 162
11. Canada 145
12. Malaysia 145
13. Korea 137
14. Taiwan 133
15. Venezuela 117
16. Thailand 111
17. Portugal 100
18. Viet Nam 99
19. Netherlands 97
20. Egypt 84
21. Turkey 78
22. Philippines 76
23. Poland 74
24. Mexico 71
25. Indonesiatd> 69
26. Argentina 62
27. Greece 55
28. Iran 50
29. Tunisia 49
30. Peru 48
31. Singapore 47
32. Belgium 46
33. Hong Kong 44
34. Australia 41
35. Algeria 40
36. Lebanon 38
37. Iraq 36
38. Morocco 35
39. Ireland 35
40. Japan 35
41. Russia 33
42. Saudi Arabia 32
43. Romania 32
44. Pakistan 30
45. Chile 28
46. Slovakia 26
47. South Africa 24
48. Finland 20
49. Lithuania 19
50. Trinidad and Tobago 19
51. Nigeria 18
52. United Arab Emirates 17
53. Denmark 17
54. Croatia 17
55. Kenya 15
56. Latvia 15
57. Serbia 15
58. Europe (specific country unknown) 13
59. Satellite Provider 13
60. Norway 12
61. Sweden 12
62. Switzerland 12
63. Uruguay 12
64. Czech Republic 11
65. Anonymous Proxy 11
66. Slovenia 10
67. New Zealand 10
68. Benin 10
69. Nicaragua 10
70. Austria 10
71. Ivory Coast 8
72. Estonia 8
73. Jordan 8
74. Macedonia 8
75. Ethiopia 7
76. Ukraine 7
77. Brunei Darussalam 7
78. Panama 7
79. Asia/Pacific Region (specific country unknown) 7
80. Nepal 7
81. Israel 7
82. Sri Lanka 7
83. Namibia 7
84. Bolivia 6
85. Bosnia and Herzegovina 6
86. Bulgaria 6
87. Hungary 6
88. Malta 6
89. Syria 6
90. Uganda 5
91. Kuwait 5
92. Myanmar 5
93. Bangladesh 4
94. Martinique 4
95. Jamaica 3
96. Palestinian Territory 3
97. Cuba 3
98. Dominican Republic 3
99. Libya 3
100. Mozambique 3
101. Ecuador 3
102. Belize 3
103. Sudan 3
104. Cambodia 2
105. Oman 2
106. Rwanda 2
107. Bahrain 2
108. Congo – Kinshasa 2
109. Cyprus 2
110. Ghana 1
111. Guatemala 1
112. Afghanistan 1
113. Senegal 1
114. Andorra 1
115. Puerto Rico 1
116. Isle Of Man 1
117. Iceland 1
118. Zambia 1
119. Guadeloupe 1
10,887

The Art of Turning an Idea Into a Solution in an Emerging Market

The challenge many are faced with when new technologies emerge in the market place is always centered around how to use the technology to solve a business problem, demonstrate this to a business sponsor within a limited budget, where to acquire or build the skill set and what technology to use. Many times because the fact a technology is emerging  there are a limited number of experiences in the market place to leverage,  limited selection, proprietary, difficult to access  and the question on how stable, flexible, scalable, viable and cost effective is the technology needs to be answered.

The approach to be taken is very much a art form. Just like painting a picture there are many perspectives, techniques and potential outcomes with not just one being correct. The key is to enable the creative spirit but as a group converge upon a answer that leverages each members unique skill set and create a solution which makes a statement having impact. When a new technology comes about such as the personal computer, internet, smart phones and RFID alike there are many ideas on how this technology can be applied to solve existing business challenges, create new business opportunities and revolutionize our society. The keys to enabling an emerging market to be success is to make adoption of and access to the technology as simple and seamless as possible, provide a forum where people can collaborate on their innovative ideas, rapidly demonstrate the power of the technology to bring a solution to life and most importantly provide business value where all in community can benefit from the overall capital return (intellectual, monetary, partnerships, impact on society….).

Pramari has been focused on these principles for over 5 years now by being the key sponsor’s of Rifidi. During this period of time we have seen many ideas evolve now into pilot and production systems where the business is beginning to see value. We are seeing the realization of the importance of bringing solutions to the market place rapidly and as a collaborative effort. This is typical in a emerging market place where there are many companies each with their core competencies that need to work closely together to deliver a solution.

For those who are attending the RFID Journal Live 2011 Event in Orlando, FL April 12-14 feel free to stop by the Pramari Powered by Rifidi booth # 242 and Argo Wireless booth # 449 to see a couple examples of production solutions brought to life through a collaborative effort powered by the Rifidi Open Source RFID platform. These solutions will demonstrate how the Rifidi community can work with you to bring your idea for a sensor based RFID business solution to life.

RFID Middleware: Build vs. Buy

Early on in any IT project architects need to decide which software
products best solve their business problems. “Build versus Buy”, and if
“Buy” what are the best and most efficient products. In principal any IT
problem could be solved and coded using even Assemblers. In the early
90s, people used C/C++ for their early internet systems. Yes, no one
would even think about such choices anymore. We long have learned to
rely on Java, Web Servers, and Application Servers. They are geared
towards Internet problems and come with much functionality out of the box.

Looking at RFID business problems, it has not been so clear in the past.
Many existing systems are “Build” type solutions for which developers
use .Net or Java and are accessing RFID readers’ API directly, trying
to build a minimum level of infrastructure code to address some key
technical requirements. I bet there are thousands of those individual
“infrastructure” implementations being used right now. Some of them
present an enormous maintenance burden.

What are our key requirements for RFID platforms products? Surely, they
have to address connectivity to RFID readers, also sensors if possible.
Data come in real time, often in volumes that are not predictable in a
reliable way. RFID data are basically read events that need to be
filtered and transformed into business events. This is similar to
processing requirements of high volume financial systems. Credit card
processing systems that obtain a high volume of events need to correlate
such basic events into business events and trigger actions. RFID systems
are inherently event-driven. They can very much benefit from
event-processing engines such as Esper. Those systems allow to filter
and process RFID events in memory and in real-time. They provide event
correlation, for easy detection of business events from low-level RFID
events. Esper, for instance, provides time-based queries, making it easy
to detect for example if an item has been in a zone for too long.

Another key requirement is based on the light-weight environments we
typically want to build. RFID systems are on the edge on the enterprise,
and as such need to run and perform on inexpensive hardware. Heavy
application server architectures are a fundamentally wrong approach. The
IT industry recognized this problem several years ago and defined OSGi
as a common standard for such appliances. It is being used in
refrigerators, and many day-to-day appliances that are produced in high
volumes; a nice, light-weight and flexible industry standard that avoids
the burden of for example having to run application servers on a small
appliance.

In summary, requirements for RFID platform products being used for IT
projects have many clear and common characteristics. Sufficient and
appropriate RFID Reader adapters, being able to handle high volumes of
load, event processing engines are some key criteria. In addition, the
product needs to be open enough so developers can use their trusted
development environments. A last, but very important criteria is the
light-weight approach that RFID systems and appliances can use in order
to keep hardware cost to a minimum. After all, appliances should run on
the edge of the enterprise, easy to maintain, and with low hardware
costs, but in high volumes. RFID systems that meet those requirements
will help the industry advance and become standard software. No need to
build your own RFID platform anymore.

One man’s view on the definition of Edge in RFID middleware

Being in the RFID industry for 5 plus years and in the middeware space for over 10 years I have seen many definitions and usages of the term edge in reference to RFID middleware. After speaking with many clients and system integrators as well as being part of and developing RFID/sensor based solutions I have come up with what edge is today and what it will mean as the market continues to grow and mature.

The pure definition of edge used as a noun is “a line determining the limits of an area“ and used as a verb is “to provide with a border that can be useful and be reached within a duration of time“ . Using these definitions as a foundation and applying these definitions to the RFID/sensor marketplace with a focus on creating business value I have formulated my vision of an edge server.

First I will start with the noun portion, boundaries of an edge server. The boundaries of an edge server depends on the sensor area you are attempting to monitor, filter and provide business value to a consumer. A consumer could be a user interface, device, enterprise system, repository etc…It’s basically at the point where you are able to leverage sensor information to orchestrate sensor events necessary to provide business events within the consuming applications domain. For example, a edge boundary could exist strictly at the point of sale system device or could go as far as looking at information across a multitude of sensors in a cloud. The factors in my opinion that go into determining what are the limitations of an edge depend of the volume of data to be processed, the richness of data required across sensors and at what point do you converge on translating this information into valuable business events such as answering the who, what, when, where and why questions required by the consuming application.

Secondly now I will look at from the vantage point of the verb aspect, “to provide with a border that can be useful and reached within a duration of time ”. So once you have defined your edge boundaries now the key element is to provide useful information to your consuming application and the useful information is obtainable within some duration of time. I firmly believe this is a key aspect to an edge server is that it must be able to process information in a timely manner as defined by your edge boundary and turn this information into something that can be used to trigger or make a business decision.

Is RFID Finally Hitting the Masses?

By Juan Carlos Ramírez (IDLink Solutions)

As an RFID entrepreneur I’ve followed closely probably all of the RFID and sensor technologies in the last 3 years of my life. Being part of this exciting emerging technology makes you think about how “smart” things and objects will change the world and the way we live our everyday lives.

Among all of the potential RFID uses, I guess it’s natural to wonder which one of those will be the one to impact the end user in a greater and most significant way. In my opinion I think NFC technology, which is pretty much RFID for the mobile phones, is the one poised to dramatically change the RFID landscape. Giving access to product information to the end consumer could be huge. Your mobile phone could now be your credit card, your car keys and more. What about using it to access information about products in your preferred store? Wouldn’t that be great.

Last week, the most important Telco companies in the US made a major announcement. They decided to join efforts to push towards NFC adoption by creating a payment services company. This announcement was followed by Google’s CEO presentation of the next Android NFC enabled phone, not to mention Apple’s and RIM’s plans towards the same direction.

Now, this opens a whole new debate and a very interesting one by the way. NFC operates under in HF instead of UHF, which is probably the most popular RFID technology for industrial and supply chain operations. Will NFC make HF win over Near Field UHF for item level applications?

In the end, I think we are evolving towards a smarter world. Things will be interconnected and big streams of information will flow in all directions. How are we supposed to handle all that information? That’s where RFID middleware will come into place.

Dataflow and the Rifidi Edge Server

This is the first in a series of blog posts that give a technical overview of the architecture of the Rifidi Edge Server.

The most basic (and important) function of the Rifidi Edge Server is to collect data from sensors, filter them, and deliver them to systems that use the data for business processes.  This diagram gives a high-level depiction of how data are collected and flow through the edge server.  The data begin their journey as they are produced by sensors.  While these sensors are normally hardware RFID readers, such as an Alien 9800, Symbol XR400, etc, data might also be produced by a legacy barcode reader, a database, or even another edge server.  The Sensor Abstraction Layer provides a way for users to develop their own plugins for their custom sensors.

As data are collected from the sensors, they are pumped into a high speed internal message bus through which other internal edge server components can access them.  Because sensors have the ability to produce an enormous number of events, users normally want to filter them.  The Application Layer Events (ALE) specification from EPCglobal provides a standard API for collecting and filtering RFID data.  The Rifidi Edge Server has an implementation of the ALE 1.1 specification.  Internally, the ALE layer uses an event stream processor called Esper to collect data according to the ALE rules.

Some users will decide that they do not want to use ALE in their solution.  Because the Rifidi Edge Server is built on an extremely flexible architecture, they can create a custom data collection layer and hook it up directly to the internal message bus.

Future architecture posts will describe other aspects of the Rifidi Edge Server in more detail.