Transcends Announces Rifidi Edge Integration with Cloud Computing and Social Media

Transcends now delivers to the Rifidi Community integration with Cloud and Social Media Jumpstarting your Sensor Solutions

Through numerous responses to our Rifidi Product Roadmap Survey we have delivered several jumpstarts for your Sensor based Solutions:

Rifidi Edge Social Media Integration Jumpstart

Rifidi Edge Cloud Computing Integration Jumpstart

Rifidi Edge Database Integration Jumpstart + example application

As the Rifidi Community continues to grow and the Industry Leading Open Source Platforms Rifidi is built on evolves (Spring – Application Framework, Esper – Sensor Event Engine, Eclipse – IDE, OSGI – Lightweight Middleware Container capable of running on a device as small as the Rasberry PI) Transcends is enabled to bring more powerful Soluitions to market lowering the overall TCO for everyone envolved.  Come learn about the Transcends Powered by Rifidi

Transcends Announces Update to Rifidi Edge Server 1.3.1

What’s new:

Transcends Now Offers Extended Rifidi Consulting and Support for your
Solution –  Our Team and Partner Community can help…

  • Looking to prepare a Demostration/prototype of you hardware and need a richer solution
  • Want to turn your idea into a Business Solution you can bring to the Global marketplce
  • Have a business problem and need to effectively turn around an implementation leveraging the Rifidi Open Source Community

Contact Us For Asssitance in Bringing your Solution to Reality.

Transcends Announces Rifidi Edge Server 1.3.1 Public Release Global Leader
in RFID Open Source Solutions.

Many of the features released here were based on input from the Rifidi
Forums Community – The Rifidi Support team Thanks You and Asks for You to
Keep the Feedback Coming!!

Contribute to Transcends Product Roadmap by Filling Out This Survey

The Rifidi Edge 1.3.1 Release includes improvements to the LLRP Support
(GPIO and Increased Performance)

Complete 1.3.1 Release  Notes –

Download Rifidi Edge 1.3.1 Latest Version –

Thanks, The Transcends Support Team -Powered by Rifidi – Community Sponsors – Rifidi Platform – Edge Server (Edge), Load Testing (TagStreamer), Prototyping (Prototyper), Emulation (Emulator) – Product Documentations and HowTOS – Rifidi Community Product Forum

How You Can Contribute to the Rifidi Roadmap

Transcends, the Lead Contributor to the Rifidi Platform, is in progress of planning our next major release. We are reaching out to the Rifidi Community to provide input to our roadmap by completeing the following survery. The survery should take no more than a few minutes (Six questions) and will be valuable in helping us provide more value to the RFID Open Source Community

Rifidi Community Roadmap Survey click here

The questions address social media, cloud computing, smart phones, sensors adapters, roles and community solutions/support. This feedback will be critical in determining the Rifidi Platform Roadmap direction as the community is what makes Rifidi powerful.

Transcends Officially Releases Rifidi Edge 1.3 to Public – News Release

Global Leader in RFID Open Source Solutions –  Delivering Sensor based Business Solution for the Next Generation Better, Faster and Cost Effective

The Rifidi Edge 1.3 Release includes updates to the latest version of Spring 3.0.5 and Esper 4 (The open source sensor event processlng language). These updates have show in performance testing  3x increase in ability to process sensor events on equilvalent hardware. The release is fully compatable with the Rifidi Platform (Workbench, Emulator, TagStreamer-Sensor Load Testing Tool and Prototyper).

Looking to become a Partner click here
Download Rifidi Edge 1.3 Latest Version

Note: Workbench has been modified to interoperate with current release. ALE support has been removed but is planned to be added back in the next release as we are in the process of refactoring.

RFID, Recession and Globalization Are Crossing Roads … With Challenges Are Opportunities

More than ever I now realize the importance of learning from life’s sessions.  Who could have ever predicted in the past 10 years we would have globalized as much as we have and in the past three years have been faced with the most challenging economic conditions in all our generations. As part of my six year journey in the RFID industry, I have had the opportunity to travel around the globe and be introduced to more cultures and ways of thinking than ever before. You look around both here at home (which for me is between North and South America) and globally to realize how much of impact we have had on each other, how much more there is still to learn and the potential opportunity the combination of both these circumstances presents.

So what does this retrospect of thoughts mean to us in RFID?  In general, many market conditions have caused us to get where we are today. The potential of an emerging industry like RFID (and more broadly sensors which are already all around us) is boundless figuratively and literally.  Here is why.

1) The industry started to really grow just a few years before the recession and many industries (if not viable) would have starved and become insignificant.

2) I find myself more than ever being involved in tangible real life solutions globally

3) The globalization our economy and everyday lives has presented us with more than ever a need for us to connect at any time and place with enriching information.

4) We have the internet for people and saw the impact this development has had on our economy and lives.  We are building the internet of things and no other industry other than RFID has presented an answer on how these two technologies converge on one another.

How can we be successful?

1) We must all acknowledge and have an awareness of the world around us. The USA and Europe still have many key decision makers and large market capitals but the reality that is changing.  The other reality is, even when a project is initiated from these markets the actual implementation, support and future development of the solution is happening globally.

2) Continue to work together, learn quickly from our mistakes and innovative solutions adding value today and have relevance towards the future.  Many people speculate when will the industry come  of age (is it this year,  next year or 5 years from now).  I believe we should be less focused on when and more focused on how. As I stated earlier it’s just a matter of timing and making sure you are still relevant when it happens. I was watching a program on CNN earlier last week discussing the state of our economy and the impact globalization has on our and future generations to come.  The comment that caught my interest the most is “Average is no longer good enough”. We are all now competing with the global marketplace therefore we all need to think and work like artisans. This means we need to be so proud of your work you would be willing to engrave your name in the craft.

I’m sure there are many other opinions on why and how we can be successful in RFID and what challenges the crossing roads of the recession and globalization has presented us with. But this should shed some light on my opinion of the business principle with challenges are opportunities……….

Rifidi Edge Server Scalability and Performance Supported By Retail Scenarios

by Mychal Capozzi (RIT Rifidi Coop/Undergrad Comp Sci) and Matt Dean (Rifidi Lead Software Engineer)

This document will give an overview of some basic scalability and performance data for Rifidi Edge and Rifidi Box Appliance


Four tests were run on different levels of hardware to test the load that the Rifidi Edge v1.2 could handle both with and without business-end computational logic.  The tests were set up as follows:

Two different hardware configurations were used to demonstrate scalability, the first being a Asus Model: EEBox B202 (a netbook like device similar to is bundled with the Rifidi Box appliance)  and the second target machine is a Toshiba Satellite laptop Model: Portege r700-S1320 (the more powerful of the two machines running with an Intel Core i5 (Dual Core Hyper Threaded) @2.4ghz ).  Two software configuration scenarios were set up on the machines, the first to demonstrate the performance of the Rifidi Edge Server’s ability to process tag events purely in memory and the second to demonstrate the Rifidi Edge Server’s ability to process tag events and persist to a database (in this case MySQL v5.1) on the same machine. In all the test scenarios a separate machine is used to execute the simulated the virtual LLRP readers and tag rate scenarios. The product used for simulation is Rifidi TagStreamer v1.1.1 and the machine TagStreamer executed on is an dual-core, dual threaded 2.4 GHz processor. The simulated environment contained 4 LLRP readers, each with a single antenna and single read zones.  The throughput time from one reader to the next was set one one millisecond, to simulate each of the four readers receiving their load almost simultaneously. Various numbers of generation two GID96 tags were sent across all four reads in bursts over one second, with a one second cool down between bursts for one to two minutes while data was collected.  The tests were designed to be limited by buffering of tags by either Rifidi Edge Server or MySQL, to verify that a given load could be sustained over long periods of time.

Note: All testing for these four scenarios were over a wired Ethernet 100 MB network. More readers could have been used but for simplicity in setting up the scenario 4 LLRP readers were used with a higher load and frequency of tags within the antenna range.

More details for both hardware configuartions can be found in the summary results table below.


The first machine used an Asus appliance, Atom n2700 single core dual-threaded processor, Ubuntu 10.4 operating system, 1 gig of ram, 160 gig hard drive and is the basic platform recommended for use with the Rifidi Box appliance.  Without the database writes of every tag seen, the edge server on the aforementioned hardware was capable of seeing between 350 and 450 tags per second with minimal buffering. With the database write enabled, the Rifidi Edge was capable of receiving bursts of 75 to 125 tags every second.

The second machine, based around a consumer-level test, was a Toshiba Satellite laptop with an Intel Core i5 @2.4ghz with 4 gigabytes of ram running Linux Mint 10 (based on Ubuntu 10.10). When the database writes were disabled, Rifidi Edge was consistently reading 2200 – 2300 tags per second. With the database writes occurring, the read rate was closer to 600-700 tags per second.

As far as CPU consumption, on the Asus machine with the Rifidi Edge Server processing tag events in-memory, the CPU reached 65-70% consumption. When including the MySQL database, the Rifidi Edge was consuming much less; closer to 45% of the CPU. The database was consuming close to 25% while this test was running.

The Toshiba Satellite machine CPU in-memory test was 80%, but once the database test began, that consumption dropped to 65%, while the database was consuming no more than 35% of the CPU.

Calculating RAM Usage:
RAM usage between the two was minimal, not surpassing 250 Mb.  Additional readers were established to estimate how much RAM would be required to support each additional reader, and it is estimated to be .1 Mb (100 Kb). This value is platform independent.   Additionally, we estimate that tag’s memory usage is variable depending on the tag type, for these tags it was negligible at less than 1KB each.  This estimate was reached by firing 200 tags over 200 milliseconds at the Atom machine and measuring RAM consumption during the test until negligible fluctuations were measured, and then comparing that amount to the Rifidi Edge without receiving any tags.

Scalability with Retail RFID Business Case Scenarios:

Based on the load-tests described above, estimates can be extrapolated to account for various reader and tag rate environments.  Given the following three retail scenarios described in detail below, we were able to size the necessary hardware requirements based on the scalability testing results above prior executing the simulation using Rifidi TagStreamer v1.1.1 on the same constant machine and Rifidi Edge Server v1.2 on the Toshiba Satellite laptop.

The Retail Scenarios:
A Department store has recently been outfitted with RFID readers on it’s dock doors, shelving units, and at the sales counters.  On an average day they process hundreds of thousands of individual items from the dock doors to the sales counters, and with the use of RFID tags, keeping track of inventory has become completely automated.  There are three defined areas where tags should be seen and a defined flow of events, they are:

1) There are five loading dock doors, each receiving 1000  tagged items every 30 seconds to 3 minutes.
2) There are 35 shelving units each receiving 50 tagged items every 15 seconds to 2 minutes.
3)There are ten points of sale, each receiving 10, 25, or 50 tagged items every 30 seconds to 2 minutes.

So using the Rifidi Edge software to process the tags and Tag Streamer to generate the tags on a separate machine, the following data was collected:

Edge Server Data:
-Top CPU usage: 75%
-Top RAM usage: 20%
-Avg CPU: 50%
-Avg RAM: 15%
-Network speed: 100 Mbps
-Total LLRP Readers used in testing: 50
-Test Duration: 18 hours
-Average tag events per second including database persistence: 107
-Peek bursts including database persistence (Tags events/per second): 336
-Total tag events processed by the Edge Server and persisted to MySQL in 18 hrs: 6,621,280

End results:
Based on the performance of the Toshiba Satellite laptop under the strain of the simulated environment, we are able to conclude that the Rifidi Edge can handle the requirements for a real-world deployment, but performance could be notably increased by separating the Database from the Rifidi Edge onto two separate machines, as the Database ended up being a bottleneck during bursts of 1,000 or more tags.

Setting up the Retail Scenario in your Environment:

Hardware Requirements:
One computer (at least an i3 processor) to run three Rifidi TagStreamer instances
One computer (at least equivalent to the Toshiba i5 above) to run the Rifidi Edge Server and MySQL Database

TagStreamer can be leveled across three computers each running one instance of TagStreamer for each test case scenario Note: The Rifidi Edge Server configuration will need to  be configured to connect to three separate IPs. (The first 5 IPs will point to the Tag Streamer instance invoking the Loading Dock scenarios, the next 35 IPs will point to the Tag Streamer instance invoking the Item Level Shelves scenarios and the last 10 IPs will point to the Tag Streamer instance invoking the Point of Sale scenarios).

The MySQL Database can be installed on dedicated Database Server hardware. Note: This will require the Retail Application running on the Edge Server to point to the Database Server IP address. Also make sure you have at least 100MB network bandwidth and on the same sub-net as the Rifidi Edge Server

Software Installation Requirements
MySQL  v5.1 –
Rifidi Edge Server v1.2 –
Rifidi Tag Streamer v1.1.1 –
Retail Rifidi Edge Application (Retail)
Events MySQL table – events.sql – used to store tag events during scenario execution
Rifidi Edge Server configuration (rifidi.xml)
Rifidi Tag Streamer configurations (TS_Retail_5_LoadingDocks.xml, TS_Retail_35_ItemLevelShelves.xml, TS_Retail_10_PointOfSale.xml)
Retail Scenario download:

Setting up the Scenario
Note: More details on how to use the Rifidi platform can be found at

1) Start the first Rifidi Tag Streamer instance and click on File|Load Test Suite to load the TS_Retail_5_LoadingDocks.xml. Note: Make sure to change the IP addresses in the configuration file to the IP address of the computer running this Tag Streamer instance and File|Save Test Suite.

2) Start the second Rifidi Tag Streamer instance and click on File|Load Test Suite to load the TS_Retail_35_ItemLevelShelves.xml.Note: Make sure to change the IP addresses in the configuration file to the IP address of the computer running this Tag Streamer instance and File|Save Test Suite.

3) Start the second Rifidi Tag Streamer instance and click on File|Load Test Suite to load the TS_Retail_10_PointOfSale.xml. Note: Make sure to change the IP addresses in the configuration file to the IP address of the computer running this Tag Streamer instance and File|Save Test Suite.

4) On the computer running the Rifidi Edge sever, place the  rifidi.xml configuration file in the [Rifidi_Edge_Home]/server/config directory.  Note: Make sure to change the IP addresses in the configuration file to the IP address of the computers running this Tag Streamer instance and the equivalent scenarios.

5) Copy the Retail Application into the Rifidi Edge server’s [Rifidi_Edge_Home]/server/applications directory. In the [Rifidi_Edge_Home]/server/application/Retail/ file verify the com.emaise.jdbc.url=jdbc:MySQL://[MySQL_IP_Address]/emaise is set the the ip address of the MySQL 5.5 DB server instance, jdbc.user=root is set to the correct MySQL user and jdbc.pass=rifidi2010 is set to the correct MySQL password.

6) Start the Rifidi Edge Server and verify the MySQL Database Server is running

7) On the MySQL Database Server instance, verify the Retail database has been created, the events table has been created and at the start of each test delete all the records from the events table. Note: For use of the MySQL 5.5 Database please refer to for user documentation. – Use events.sql script to create events table.

8 ) After the Rifidi Edge Server starts, on the Edge Server console type loadApp Retail to start the Retail Application

9) For each Rifidi Tag Streamer instance, click on Test Units then click on TestUnit1  and on the menu bar click the run icon to start the Test case scenario. Note: You will need to repeat these steps for each of the three Tag Streamer instance.

10) To verify that the Retail Scenario is operating correctly, first on the Edge Server console type and readers and all 50 LLRP reader adapters should be in processing status, second monitor the cpu and memory usage on all the computers to verify CPU does not exceed 50% – 90% and memory does not exceed 50% available.

11) After you decide to end the test as the test cases are configured to run indefinitely so you will need to stop execution manually, the results can be analyze by querying the Retail Application MySQL 5.5 database. DB name: Retail. Table name: events. Note: For instructions on how to use MySQL 5.5 please refer to the documentation.

Future Planned Rifidi Edge Server Testing:
Future tests with the Rifidi Edge Server will include scalability and performance writing to a queue (JMS), web services, Software as a Service (SaaS) and in a Cloud.

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

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

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.