Page 1 of 7

ECOEE – Design of a Sustainable Edge Processing Middleware Solution for Supply Chain Scenario

Debi Prasad Pati Niche Technology Delivery Group Tata Consultancy Services Limited

Kolkata,India

debi.pati@tcs.com

ABSTRACT Over last 10 years, there is constant demand on improvement of identification technology and executing/orchestrating business processes or activities at the edge rather than at Data Center. This has been possible because of convergence of the technology like Radio Frequency Identification (RFID) with sensor data under ubiquitous environment .This convergence is emerging very fast and today lots of big and medium corporate houses have either invested or are planning to invest in bringing middleware solutions which would help to achieve a sustainable IT solution

In this context, TCS RFID & Sensor focus area under Niche Technology Delivery Group (NTDG) has developed a product called Edge Controller for Edge Events (ECOEE), a sustainable Edge Middleware solution based on open-source J2EE software suite.

Now industries are involved in mass deployments and looking for running the Edge middleware in hardware appliances as embedded applications. Nowadays even we can see various vendors manufacturing smart readers where one can install and run a Edge middleware as an embedded application. Thinking on the same line, a lighter version of ECoEE, called μECoEE can run in an embedded device having a J2ME platform/Android platform.

This paper describes the considerations to be met in the areas architecture, design, features of ECOEE & μECoEE such that Edge processing IT solution would be part of enterprises sustainable IT solution and strategy.

Key words- RFID, GDSN, EPCGlobal, ALE, EPCIS, ONS

1. INTRODUCTION For more than last 25 years, bar codes with all its limitations have been widely used technology in the industry for automatic identification. With the emergence of RFID, the industry is now finding a better and more powerful alternative of bar codes, which enables considerable ROI for the initial investment on RFID Hardware. A RFID system essentially consists of a tag attached to the object that needs to be identified and an interrogator (reader) which issues requests through RF signals. The tag responds with the data requested for and finally a host running application receives the data from the reader and does further processing.

Hardeep Datta

Niche Technology Delivery Group Tata Consultancy Services Limited

Kolkata,India

Hardeep.datta@tcs.com

Some major advantages of RFID over bar codes are: non-line of sight, simultaneous identification capability, ability to encode additional data apart from the product ID that is, it supports read-write operations instead of read-only. This powerful technology has brought a new era of processing at edge and, it has been for last 10 years. Now, the question is to bring an environment for edge processing to provide sustainability to the overall IT solution for the industries. Hence, in this paper, we are going to discuss the considerations of standards, core design strategy and integration interfaces for scalability, cost and adaptability for new technologies for the same line

After some initial research at MIT auto-ID center, a software stack called EPCGlobal [1] Network and a set of standards for communication between the layers and a sample implementation of the framework is conceived. The motive of EPCGlobal Network was twofold, firstly, to enable using RFID for product identification with all its advantages and secondly, to provide visibility of items throughout the supply chain. RFID along with Electronic Product Code (EPC) are now being thought of as the perfect solution towards realization of Global Data Synchronization Network (GDSN) [3] because they complement each other. Figure 1 presents it diagrammatically. Refer [4] for more details on this aspect.

Figure 1 Relation of GDSN and EPCN

Page 2 of 7

RFID middleware is the main software component in the EPCGlobal Network, which is discussed in detail in Section 2. Big companies such as SUN, IBM, Oracle, SAP, OAT and others from various segments in the IT industry have developed their own RFID Middleware products. Unfortunately, all these are bundled with some of their proprietary products, which result in a quite high licensing cost as well as reduced portability. With this in mind, TCS RFID Center of Excellence has developed ECOEE, a Edge middleware based on open-source technology. Since usage of open-source requires no software licensing cost, the software cost could be minimized. J2EE has been chosen as the core technology because of its versatility, portability, flexibility and inter-operability. The JBoss Enterprise Middleware Suite JEMS [2] has been chosen as the open-source J2EE product for implementation. ECOEE is a configurable, scalable and flexible enterprise class middleware product, which is Application Level Events (ALE) compliant. ECOEE can handle various types of devices and provides management consoles for dynamic monitoring and management of the components and is bundled with utilities such as Simulators. A detail discussion about the architecture and features of ECOEE is presented in Chapter 4 & μECOEE in chapter 5.

2. The EPC Network Before going into the details of Edge Processing Middleware and its functionalities, it is better to have an overview of the EPC Network architecture to have an idea of the big picture (Figure 2).

Figure 2: EPC Network Architecture

As explained earlier, EPCGlobal is set up to help achieving world-wide adoption and standardization of EPC and RFID technology with a vision to automate the supply-chain and thus

providing visibility of the entire life cycle of products throughout the supply chain. The main objectives of the EPC Network are:

Linking all tagged objects through Internet

Managing the voluminous data generated by the readers

Providing a universally accepted form for data transfer and sharing

Broad level functionalities of the major software components are as follows:

Edge Processing Middleware: The middleware is the filtering and collection layer that sits between the devices and the application for processing RFID events. It has two sets of interfaces for communication to the outside world, the Reader Protocol (LLRP – Low Level Reader Protocol [7]) standardizes interfacing to the devices and ALE (Application Level Events [5]) defines the interface with external applications and Electronic Product Code Information Services (EPCIS) [3]. Major functionalities include device management, event filtering and routing. Section 3.1 explains the functionalities of a middleware in detail.

EPCIS: The EPCIS capturing application and the EPCIS Repository constitutes the EPCIS layer. The basic functionality is to capture the data from the middleware, staging it by associating necessary business contexts, storing it for historical purpose and sharing the data through a standard interface for external applications. Physical Markup Language (PML) objects are used to communicate between EPCIS and external application. PML is an XML schema that defines the data exchanged between different components of the EPC Network systems.

ONS: Object Name Service (ONS) [6] is a service that given an Electronic Product Code (EPC) can return a list of end-URLs of services that contain data about the given EPC.

3. Functionalities and Design Constraints There are various RFID Middleware products available in the market from large global companies like IBM, Oracle, SAP, Microsoft etc., whereas niche RFID Middleware products are also available from smaller focused companies like, GlobeRanger, OAT Systems ( now part of Checkpoint), etc.

This section discusses about the details of the functionalities expected from an Edge Middleware (not restricted to RFID events only) and the associated design constraints to provide these functionalities.

Device Integration: An Edge middleware communicates directly to the devices like RFID reader, printers and other input and output devices. Hence, device integration is one of the basic functionalities expected from an Edge middleware. In this context, the following are a few concerns:

Varying Frequency and Protocol: RFID devices can operate in various frequencies and for different frequencies there are different air interface protocols for communication between tags-readers-hosts. For example, ISO-15693 for HF Vicinity Cards, ISO-14443 for contact-less Proximity Cards and ISO-18000 6 for UHF. Similarly printers support XML printing today.

Synchronous or Asynchronous: The operating mode of a device either can be synchronous or asynchronous

Page 3 of 7

depending on the sophistication of the devices and the application requirement. In synchronous mode, the middleware sends a request and waits for the response. Whereas, in the asynchronous mode, the reader keeps on sending data to the middleware when it detects some tag in front of it.

Connectivity: Devices could be connected through TCP/IP or serial connector, which means that the Edge middleware should be able to accommodate different transport mechanisms as well as interface protocols.

Event Data Management: Starting from RFID Tags, apart from their ID, can contain some additional memory where user data can be stored for future use. Different types of tags can have different physical structure for this additional memory. Moreover, sensor tags can send data of temperature, pressure and so on. The middleware should be able to handle these types of data, and should be able to handle the internal memory structure of the tag to read-write user specific data.

Event Data Aggregation and Filtering: Let us consider all RFID applications. The important requirement is to receive clean and filtered data instead of raw RFID data streams. Some important reasons for filtering and aggregation are as follows:

There can be a lot of redundancy because of the high read rate of the RFID readers.

There can be occasional miss of one or more tags, even if they are present in the read-zone of the reader, due to odd environmental and physical conditions.

Multiple devices are sometimes grouped together to avoid potential miss in reading, where 100% read-rate is of critical importance.

Different applications require different kind of notifications. Some applications may require to identify the tags in the reader, whereas some applications may require to identify the tags that have entered and the tags that have left the read-zone.

Event Data Routing and Application Integration: Event Data is sent after filtering from the middleware to external applications based on the following scenarios:

Most of the cases, Edge middleware will be integrated with a diverse set of applications for business needs. For example, WMS, LMS, and ERP.

There can be multiple applications accessing the data, simultaneously.

Different applications might be requesting different types of edge events , generated from either the same or different devices.

The data transfer might be initiated either from the middleware side (push model) or from the external application side (pull model).

This requires a very sophisticated and flexible dispatcher module to handle all the mentioned scenarios.

Compliance to standards: EPCGlobal has standardized a protocol for communication between EPCIS and Edge middleware called Application Level Events (ALE) [5]. This is web service based protocol exchanging SOAP messages for communication. Edge middleware like RFID middleware products are supposed to comply with this standard.

Status Monitoring and Remote Management: Any Edge middleware will be connected to a number of devices. As these devices are being installed at the site, physical verification is nearly impossible. So, Edge middleware should provide a way to remotely monitor and manage these devices.

Data Translation Engine: The raw event data coming from different sources will be in binary or hex format, which is not suitable for usage at the application level. EPCGlobal has standardized a format called Pure Identity Format for information exchange. So it would be a welcome feature for the Edge middleware product to have an inbuilt translation engine from translating between the raw binary (or hex) format and the Pure Identity Format. Since these standards are still evolving, the translation engine should be flexible enough to adopt modifications in the standards without much effort.

4. The Architecture and Design Fundamentals of ECOEE This section describes how ECOEE is designed to handle all the constraints and requirements. Before going to the design, it is better to have an overall view of architecture of ECOEE as illustrated in Figure 3.

Figure 3: System Architecture of ECOEE

ECOEE is implemented as a J2EE component running on a J2EE Application server. JEMS have been chosen for implementation. The modules in the KERNEL are the controlling units, whereas the AFL Chains are the execution units, although the execution is initiated and controlled by the controlling units. The different components shown in the architecture diagram (Figure 3) are discussed in detail in the following sections.

Page 4 of 7

4.1 Device Layer The device layer consists of the Transport layer, State Machine and the Data Interpretation layer. Transport layer encapsulates the actual communication, either through TCP/IP sockets or through RS-232 serial interfaces. The State Machine deals with the mode whether it is Synchronous or Asynchronous or Simulated Asynchronous. The topmost layer that is the Data Interpretation layer is device specific. It actually forms the request for the device from a generic instruction event and parses the response from the reader to form a generic event structure.

Each device and device group contains one JMS Queue. This is used for passing instructions into the device or the device group.

4.2 Filter Layer The filter layer is a consumer of the data pumped into the JMS topic by the device layer. The following are some readymade filters, which are provided as part of ECOEE:

Smoothing Filter: This is a smoothing filter. It smoothes out the occasional missed reads and also removes redundancy by reporting average reads accumulated over a certain period of time.

In/Out Filter: This filter generates an IN event when there is a new tag and an OUT event in case a tag is missing from the list of tags seen in the previous reading cycle. In each read, the reader returns a list of tags that it detects. This list is stored in memory and when the next list comes it matches with the new list with old list. The new tags in the new list are reported as IN events and the tags of the old list, which are not present in the new list, are reported as OUT events. Then the new list is preserved for the next read cycle and the old list is discarded.

Pattern Filter: This filter allows passing a certain pattern of tag IDs, only.

Aggregate Filter: In supply chain world, cases are contained in pallets and both are tagged. When all these are tagged, it becomes necessary to know the association between the different tag IDs. This is achieved by the aggregate filter, which accumulates all the tag IDs collected over a certain period of time and generates a single event by concatenating all these IDs. Now the application identifies the pattern of tag IDs of pallets and cases. After getting the single event extracts, the case IDs and the pallet IDs makes an association between these records.

4.3 Dispatcher Layer The dispatcher layer comes after the filter layer in the AFL chain. The filtered events, pumped into the JMS topic from the filtering layer are consumed and dispatched to external application. The different available dispatchers (or loggers) are:

JDBC Logger: Logs events into a database using a JDBC connection.

PML Logger: Logs events in a file in PML format.

Web Service Logger: Calls a particular service and passes the event as a parameter.

JMS Logger: Makes the data available in a JMS topic. Applications can subscribe to this topic to get the data.

HTTP Logger: Calls a servlet and passes the event as a parameter.

Apart from the inbuilt device adapters, filters and loggers, ECOEE has a framework for developing custom instances of any of these components. Another common feature is that, they are all configurable either statically through the configuration file or dynamically through the management console.

4.4 AFL Chain The AFL chains are basic execution units of ECOEE. An AFL Chain consists of three components: one device group, an array of filters and one logger.

Figure 4: Two Chains Sharing Same Adapter

These components are connected to each other through JMS topics in between and the components are listeners to the preceding topic. Also the chains can share some of the components between them. For example, if two different applications accessed the data from the same reader but filtered in different way, it is possible to have two chains with the same device component as illustrated in figure 4. By connecting the components through JMS topics and by grouping them in chains, the following benefits can be achieved: 1. Better Control: AFL chains exposes management and

monitoring APIs. Using these any specific instance of AFL Chain could be monitored and managed. Starting or stopping a particular component is not meaningful and not always safe also because there is a possibility of data overflow. For example, if a component in between a chain is stopped for some time, data will be accumulated in the preceding pipe, giving rise to a data overflow. In this way, managing the chain as a whole gives better manageability of the overall system.

2. Scalability: The architecture may be scaled up in two ways: a. Point-to-Point: By interconnecting the components

through JMS topics, different components of the same chain or different chains altogether may run in different machines and sharing information through the JMS topics.

b. Hub-and-Spoke: By grouping the components as a separate entity, one can have a potentially distributed hub and spoke architecture where the core components are running on the hub and chains are distributed over the spokes. The core passes the instructions to the device layer through the JMS Queue.

Page 5 of 7

3. Performance: Every component being a message listener, runs its own thread and the whole system becomes event driven, thereby enhancing the overall performance to a great extent.

4.5 KERNEL The kernel of the middleware contains components, which are responsible for initializing and running the system. The Configuration Handler parses the configuration xml file at start-up time to initialize the behavioral parameters for the different components and connectivity topology between these components to form the AFL chains. The Component Handler is responsible for creating different instances of the components. This is also responsible for incorporating new components into the system dynamically. The Chain Handler creates and manages the connectivity between different component instances. This additional layer of abstraction enables to modify the connectivity topology dynamically. The chain handler also enables users to control and manage the chain as a whole, rather than going through individual component instances.

4.6 Utilities Apart from the core components, ECOEE provides the following additional components, which are very useful and frequently required. These are discussed below: 1. Device Simulation Engine: A device simulator is plugged in

to the middleware for generating events. This is very useful for demonstration and testing purpose when a physical reader is not available. Users can configure the tag IDs and other various parameters. The simulator can be configured to behave exactly like some specific device, by configuring the request-response behavior so that testing could be done more accurately.

2. Event Data Translation Engine: When data is written onto a tag, it is written in binary or hex format, which is not meaningful in the application layer. To address this problem, EPCGlobal has published a standard called Tag Data Standard [4], which specifies the format of the data in different layers of the middleware. A tag data translation engine is integrated into ECOEE, which is capable of translating the tag IDs from either raw binary or hex to pure-identity format or vice-versa. Since the standard for the different tag data standard gets updated frequently, so to make this flexible the entire translation logic is encoded as an XSL script. This way the engine becomes flexible and is able to accommodate the additions and modifications in the Tag data standards very easily.

3. Workflow Engine: A workflow engine in ECOEE helps to do local data routing without going back to the server for validation, e.g., motion sensors detecting motion triggers an RFID reader in turn – these situations can be implemented through the workflow engine.

4.7 Middleware Interfaces and Different Integration Scenarios The different integration options of ECOEE are illustrated in Figure 5.

Figure 5: Integration Scenarios

1. Application Integration: To integrate with external application ECOEE provides various types of loggers as part of ECOEE. Categorically there can be two kinds of integration, either push type or pull type. In push scenario, the application registers the destination in the middleware. So when data is received, it is sent to that destination by the middleware. HTTP, WS, PML (Product Markup Language) loggers are of this type. On the other hand, in pull scenario the application pulls data from the middleware whenever it requires. JMS and DB loggers fall into this category. In case some custom loggers are required, for example, adapters for some specific application such as Oracle WMS can also be done very easily using the logger framework.

2. Device Integration: As discussed earlier, the RFID world covers a wide landscape of devices with different kinds of communication protocol and connectivity. On top of this, there may be some non-RFID devices as well. For example, bar code reader, motion sensor, light stacks, and other RFID devices. ECOEE provides ready-made adapters for some of these, but the device framework is such that with minimal effort, the users would be able to create and incorporate adapter for a new device.

3. Management Console: To monitor and manage the components is a necessity, especially in scenarios where hardware components are playing a crucial role in the business process. ECOEE provides JMX compliant management interfaces for monitoring and also dynamically updating the parameters of the components. The advantage of JMX is that either users can use standard JMX clients like browsers or they can create own customized management console, easily. Using one management console multiple instances of ECOEE can be monitored and managed.

4. ALE Integration via Web-Services: Thmoving towards Service Oriented ArcECOEE has an ALE server that exposservices for passing instructions and gettinthe middleware. EPCIS implementations via this ALE server, as well as the process osuch as BPEL can use these processeaccording to their requirement.

4.8 Features and Benefits The following summarizes the major features abenefits of ECOEE:

1. Completely based on J2EE open-souron a JBoss J2EE container - This givadvantages:

Being completely J2EE, it is platf JBoss being an industrially t

server, ECOEE stands on a solid i With JBoss, comes JMX that hav

for making a management consostandards. This also provides dynamically modify the compone

The JBoss AS has a web servicThis is exploited to create WS logservices for passing instructions ienables ECOEE suitable to fit inapplication scenarios.

2. Multithreaded implementation - As the components of the AFL chain aremessage listeners running on their omakes the whole system event driven performance.

3. Device Adapters–ECOEE has a framework that supports a versatile lansupporting varying Radio frequencyand connectivity. It also allows creatiadapters.

4. Filters and Loggers–ECOEE providefor filtering and logging and also acustom filters and loggers.

5. ALE Compliance–ALE is SOAP bacommunication between middlewareother external applications. ECOEE hexposing those services. The argumentthat applications can be middleware agfeature makes ECOEE most suenvironment.

6. Middleware API–ECOEE exposes allows the users to programmaticcustomize from their application.

5. Description of μECOEE Edge middleware instances are not expected running in remote central locations, rather they aphysically placed near the devices, that’s why thas Edge Servers. In certain situations, this becoto install a PC for hosting the middleware.hardware appliances are placed and Edge midd

he world is now chitecture (SOA). ses standard web ng data to & from can be integrated orchestration tools es to orchestrate

and the associated

rce stack and runs ves the following

form independent. tested application infrastructure. ve been leveraged ole based on open the capability to

ent parameters. ce container also. gger and to expose into ECOEE. This nto a SOA based

discussed earlier, e implemented as

own threads. This and enhances the

flexible device ndscape of devices y, protocol, mode ion of new device

es various options allows creation of

ased standard for e and EPCIS or has an ALE server t in favor of this is gnostic. Also, this

uitable in SOA

an API, which cally access and

to be physically are expected to be ey are also known mes very difficult . In these cases,

dleware are hosted

in those appliances. Going one stmanufacturers are now coming up witembedded platform and sufficient resapplications can be installed and run imakes the application extremely scalathe startups like Twinlinx has come which would make Bluetooth enableddevices.

For this reason, an embedded version has been added in to the solution. μECinstance of ECOEE running at the baca standalone application communicatimplemented as a pure Java embeddwith CDC configuration with FP pphones.

5.1 Features of μECOEE μECOEE contains a subset of featureChain constituted by components whothe events pass through the AFL chaininstruction server for facilitating admand a smaller footprint version of achieving local data routing, as exinstructions to the μECOEE instance, iin an XML format. The main loggelogger through which filtered data canECOEE, when installed in an integstandalone installation, web-service lofiltered data to the upper layer compon

5.2 Integration Scenario The different integration scenarios are

Figure 6: Integration Scenarios

If μECOEE is installed in integrated wof ECOEE running at the back-end, th

Page 6 of 7

tep further, RFID reader th smart readers, having an sources so that middleware inside the reader itself. This able. Not only that, some of

up with HF/UHF stickers d smart phones as handheld

of ECOEE called μECOEE COEE can run along-with an

k-end whereas it can run as tion via web-services. It is ded application compatible

profile of J2ME for smart

s of ECOEE. It has a AFL o are message listeners and n as message. It has got an

ministrative communication the workflow engine for

xplained earlier. To send instructions need to be send er in μECOEE is ECOEE n be sent to an instance of grated fashion. In case of oggers are there to send the nent.

shown below in figure:

s with Micro-ECOEE

way, i.e., there is an instance hen there will be a μECOEE

Page 7 of 7

adapter configured in ECOEE to interact with a particular instance of ECOEE. As the AFL chain is started in ECOEE, the corresponding AFL chain in μECOEE will also be automatically started and filtered data will be pushed into ECOEE in XML format which will be dispatched through logger. For other kinds of instructions, the instruction server will be used. In case of standalone installation, 3rd party applications can directly communicate through the instruction server of μECOEE and filtered data from μECOEE will be pushed into the application via web-services.

6. Additional Benefits of ECOEE In this section, some of the features of ECOEE and the associated benefits are highlighted, which are very important for its sustainability 1. Since ECOEE is developed using Open-Source products, the

licensing cost will be much lower as compared to other competitors.

2. ECOEE allows an extremely flexible way to design the AFL

chains through the configuration files. More than one chain can share the same device instance as illustrated in Figure 4, or can have some overlapping components as illustrated in Figure 7. So far, no middleware product allows this kind of flexibility.

Figure 7: Flexible Configuration of AFL Chains

3. The core components of ECOEE have been designed and implemented using JMX standards. This enables a high degree of manageability through the JMX console. ECOEE provides a custom JMX console through which the components can be monitored and the configuration

parameters of these components can be changed dynamically without restarting the server.

4. A set of API functions is exposed from the ECOEE middleware, so that Edge applications can use these directly inside the programming environment for customization. This provides edge middleware extensive flexibility.

5. ECOEE is designed in such a fashion that it can be very

easily deployed in a distributed environment, to handle heavy data flow, as described in section 4.4, point no.2. Very few RFID middleware products allow such a level of scalability.

6. Embedded version of ECOEE provides more flexible and

scalable deployment options.

7. Conclusion In this context, TCS RFID Center of Excellence has developed a middleware named ECOEE (Edge Controller for Edge Events), using Open Source software suite. ECOEE built on top of JEMS, is a scalable, flexible, configurable and standard based enterprise class middleware. This is a very important component for meeting the IOT (Internet of things) vision and helps it to achieve sustainability in future.

8. Acknowledgement Authors would like to thank Sukumar Chakraborty and his team for his contribution in developing this middleware

9. REFERENCES [1] www.epcglobal.org [2] www.jboss.com [3] An Integrated View of the Global Data Synchronization

Network and the Electronic Product Code Network http://www.fmi.org/supply/GCI_IBM_GDS_and_EPC_Network.pdf

[4] EPC Generation 1 Tag Data Standards Version 1.1 Rev.1.27 http://www.epcglobalinc.org/standards_technology/EPC_Tag Data Specification 1.1Rev 1.27.pdf

[5] The Application Level Events (ALE) Specification, Version 1.0 http://www.epcglobalinc.org/standards/ale/ale_1_1_1-standard-core-20090313.pdf

[6] ONS Specification Version 1.0 http://www.epcglobalinc.org/standards_technology/EPCglobal_Object_Naming_Service_ONS_v112-2005.pdf

[7] LLRP – Low Level Reader Protocol http://www.epcglobalinc.org/standards/llrp/llrp_1_0_1-standard-20070813.pdf