EPC Applications
Generally, real-world IoT systems encompasses several standards and involves several software components. The EPC Network is no exception, usually the EPC software is composed by several software components.
The initial approach was to build a RFID platform that meets the applications needs and constraints of the RFID technology. These constraints are related with reliability issues, tag memory variations, data aggregation, heterogeneous reader landscape, reader collisions and limited communication bandwidth. To address these issues and the application requirements for filtered and aggregated RFID data, the approach was to build a middleware platform that implements the interfaces defined in the EPC Network specifications by EPCglobal. The platform consists of three separate modules: the reader module, the filtering and collecting middleware (ALE) module, and the EPC Information Services (EPCIS) module. The picture above shows the deployment diagram of the RFID platform.
To deploy an application that implements the EPC Network is necessary a complex and heterogeneous software stack. An example is the Fosstrak platform, an open-source platform that implements most of the EPC standards and requires the installation of several different software components to run an application. As a consequence, a full EPC software stack is rather complex to install and deploy. Another consequence is that maintenance of the different components of this software stack increases the complexity of these applications.
In this approach, all the infrastructure required by the applications based on the EPC framework (physical servers, sensors and actuators) was allocated inside the smart places were the application is running. This results that IoT applications that are based in the EPCglobal standards has a high cost related with infrastructure and maintenance, and also have some constraints related with the application performance (scalability, availability, etc.).
In order to solve some of the pain points related with the standard IoT applications, recently IoT applications are taking advantage of the benefits of the Cloud Computing. By virtualizing the software stack of the IoT application, it is possible to reduce installation time, infrastructure costs and to improve some performance aspects of the applications, such as availability and scalability.
However in this approach not all the components of the EPC software stack are virtualized. The ALE module still is deployed in a physical server inside the smart place where the application is running.
An important questions is, why the ALE server is not deployed to the Cloud?
Guinard proposed the EPC Cloud, a cloud-based solution for applications based in the EPC standard. The solution architecture is illustrated as follows:
The proposed solution by Guinard aims to solve some of the pain points identified in the previous approaches. In this solution all the software stack of the EPC Network is cloudified.
Another pain points that these solution aims to solve are:
- EPCIS provides a simple and lightweight HTTP interface for recording EPC events, its query interface is a standardized WebServices interface. WebServices applications are complex systems with high entry barriers and require developer expertise in the domain which is often an issue when considering small to mid-size businesses. Moreover, WebServices are often not well adapted to more light-weight and ad-hoc application scenarios such as mobile or Web applications.
- RFID use-cases generally do not involve RFID readers and tags only they are usually combined with sensors and actuators. In IoT applications, several sensors and actuators are combined together to form the basic use-case. These combinations of RFID, sensors and actuators often occur at a low level, sometimes even at the wiring level. This mainly has two drawbacks. First it requires to combine the complicated and often not homogeneous low-level APIs of (expensive) devices which requires expert knowledge. Then, once installed, these compositions of devices are static and cannot be flexibly reconfigured to integrate new sensors or actuators.
In order to solve these pain points, the remedy adopted by the solution was:
- RESTful Architectures
- Web Mashups:
To evaluate the implementation of the EPC Cloud, a prototype was implemented to proof the presented concept. During the implementation of the prototype a number of challenges was identified:
-
Some standard LLRP readers offer a reader-initiated scheme, most operate on a server-initiated scheme. This means that the EPC Cloud server has to contact the RFID readers in order to start the reading process. While this works fine in places where a direct access to the Internet is available, this is problematic in industrial environments where RFID readers sit behind firewalls and do not feature public IP addresses. To solve this problem, LLRP standard readers should also offer a reader-initiated scheme.
-
To optimize data access, most cloud infrastructures offer highly optimized storage services (e.g., NoSQL databases) that can be easily distributed and load balanced. In the Java world, the implementations of these services is compliant with the Java Data Object (JDO) which abstracts from the actual storage service being used and also allows to easily switch the service. Unfortunately, the current Fosstrak EPCIS is not JDO compliant but uses JDBC and is rather tightly coupled with a MySQL database. Porting the EPCIS to JDA would enable to better leverage the scalability that cloud solutions have to offer.
-
For real-world applications, network delays might be serious drawback as events and actions are sent and triggered in the cloud. While it is unlikely that an EPC Cloud solution will support true real-time use-cases in the near future, our early measurements have shown typical delays of less than a second on average for the described EAS Mashup, from the reader, to the cloud and then to the mobile phone. While this is acceptable for most envisioned applications we still need to extensively evaluate the proposed blueprints and their optimized implementations in real-world deployments.