Part 1: Cloud & REST | Part 2: HTML5 WebSockets | Part 3: Physical Mashups
Since last summer, I had the chance to work at the MIT Laboratory for Manufacturing and Productivity (LMP) in the Auto-ID Labs sub-group, working with the lab associate director Christian Floerkemeier and Prof. Sanjay Sarma. Six month after the beginning of the project we reached a fist milestone and thought it would be good to wrap up what we did there.
The idea of the project is to study how Web and Web of Things blueprints (i.e., architectural patterns) can help to foster the adoption of the EPC Network by making it simpler to deploy and develop upon.
The EPC (Electronic Product Code) Network is probably one of the most comprehensively standardized IoT (Internet of Things) infrastructures: it offers standards that address every steps from encoding unique number on RFID tags, to reading them with standardized readers (LLRP), aggregating events (ALE) to persiting events in their business context and make them available for applications (EPCIS).
Recently, RFID is getting a second youth, its hype phase passed, it is now slowly coming to maturity in a number of applications. A lot of which combine RFID with other sensors and actuators. Not to forget the recent announcements of Google to boost the adoption of NFC (Near Field Communication, another type of RFID tags) by adding native Android OS support for NFC readers embedded in mobile phones (e.g., in the Nexus S).
However, while the adoption the hardware (EPC tags and LLRP readers) is progressing significantly, the adoption of the software standards is yet to take off especially for SMEs.
We believe that part of the reasons for this lack of adoption is the complexity of EPC Network infrastructures. As an example, the leading open-source implementation of the EPC software standards, Fosstrak, requires a total of 12 software components to be installed, configured and maintained. This was our starting point: what if Web and Web of Things architectural blueprints would make the EPC Network simpler to deploy, maintain and develop upon.
After looking a little more a the pain-points of EPC Network deployments we discovered that we could help on at least three of them with Web (of Things) remedies. We came up with 4 different remedies. In this post we look at two of them and will look at the others in a next post.
Cloud Computing and Virtualization to Reduce Installation, Configuration and Maintenance Costs/Hassle
We used virtualization (sometimes called Private Cloud) to create a development virtual machine, instead of hours of installation, the EPC dev virtual machine lets you test and develop with the EPC software stack within a few minutes.
We then used Cloud Computing (Utility Computing in a Public Cloud) to create an Amazon EC2 instance of a whole EPC back-end called EPC Cloud Appliance. Instead of weeks of installation by domain-experts, you now
- buy an (LLRP) standard reader,
- log onto Amazon EC2, select the EPC Cloud virtual machine fire it up on any number of appliances and off you go, you are ready to create your RFID applications, backed by a scalable, standard, EPC software infrastructure.
RESTful Interfaces to Simplify Application Development
Next, we wanted to simplify the currently rather complex interfaces to enable new types of apps using the EPC Network such as mobile apps, apps on sensor nodes or Web applications. The pattern we used for this is REST. Like in most Web of Things projects, we developed a RESTful architecture for the EPC Network in order to provide interfaces to RFID data and devices that are lightweight, easy to use, and easy to integrate with existing services on the Web.
Our first step in this space was to RESTify the information service of the EPC Network (the EPCIS) in a component called: EPCIS Webadapter as described here open-source software framework here. Using the Webadapter, every tagged product, reader, location, etc. gets a unique and resolvable URL.
Try it for yourself on live data by clicking the link below:
restepc.webofthings.com/location/urn:ch:sap:regensdorf:frc/reader/urn:ch:sap:regensdorf:frc:shopfloor/time/2010-12-28T12:23:28.000Z/event
With this interface, RFID data can be consumed by any Web client such as browsers, mobile phones, sensor nodes, etc.
In part 2 of this post we talk about how we used the Real-Time Web and Physical Mashups blueprints to further help easy Web development on top of the EPC Network.
You can also sneak into the presentation of the full project below.
