Methodology for Development and Objective

Methodology for Development and Objective Comparison of Architectures for Networked RFID

Béla Pátkai, Damith Ranasinghe, Mark Harrison, Duncan McFarlane Distributed Information and Automation Lab, Institute for Manufacturing, University of Cambridge, Mill Lane, Cambridge, CB2 1RX, United Kingdom

Abstract The purpose of this paper is to address the problems presented by a heterogeneous environment of networked RFID implementations. These systems have a growing number of applications and these will have varying requirements that need to be modelled and communicated. The use of an ontology-centred methodology is suggested that can represent the entities in the system and also their relationships in a formalized manner. Such a formal methodology can support the planning, design, development, efficient operation and interconnection of various networked architectures.

Introduction Recent developments in Radio Frequency Identification (RFID), sensor technology, wired and wireless networking of computers and other electronic devices – among others – have established the technological opportunity to build the long anticipated “Internet of things”. Even though it is very useful and convenient to use the analogy of the Internet in this area, networking RFID tags, sensors, and various data sources from a network of enterprises is closer to the idea of intranets, extranets and the semantic web. The complexity of design methods necessary to develop industrial strength, secure, trusted and efficient architectures for various industry sectors is a significant challenge. The recent standardization of the EPC Information Services [1] and the concentrated development effort in industry specific architectures in a number of research projects suggests that an abundance of networked architectures will be designed, deployed and will need to interoperate and be compared to each other, especially because the high value and long life cycle of products requires unique identification and Integrated Condition Monitor-

2

Béla Pátkai, Damith Ranasinghe, Mark Harrison, Duncan McFarlane

ing far beyond previously known examples. The aim of this paper is to lay down the foundations of a systematic design method that foresees the necessity for the multiplicity and heterogeneity of solutions, interface definitions, design of customized solutions and the definition of performance metrics for objective comparisons.

Problem Definition Networked information systems have been developed in the last two decades with increasing speed due to the emergence of numerous standards, including the wellknown W3C standards and recommendations – XML, REST, SOAP, WSDL, Corba, WS-*, RPC – the Enterprise Service Bus (ESB), and many other vendordependent, but significant, solutions like Microsoft .Net. The recent development of EPCglobal standards for networked RFID [1] added useful, problem-specific functionality to these. In this paper we take an agnostic view on whether a single standard is going to address all the challenges of the future in this field, and assume that the proliferation of several standards and vendor-dependent solutions is going to happen. This brings up a set of problems such as: • Networked RFID is going to be implemented in a heterogeneous environment – Not following a single standard – Different vendors will provide solutions not conforming to all standards • Heterogeneous systems will have to interface • Ad-hoc solutions will often be built • Services will be technically easy to implement - difficult to deploy & maintain, hence – Solution performance will not foreseeable • Computational burden can become problematic – E.g. sensor data processing • Network load is going to fluctuate • Storage requirements will not be known before deployment of service – Indirect security issues: accessing data allows data mining by third parties • Systematic interfacing and service development work requires a methodology • Efficient communication formalism is necessary for system/services development • Automation of interfacing (or at least part of it) will be very desirable (M2M) In the realm of logistics these problems will be amplified because:

Methodology for Development and Objective Comparison of Architectures for Networked RFID 3

•

• •

Logistic networks are: – Naturally cross-organizational – Very dependent on each other – Use a variety of IT infrastructure – At a different point of IT development – Have different IT outsourcing policy – Their business model may benefit a lot from improved information flow Logistic networks require addressing issues in the previous “Problem Definition” The concept of “logistics” is being naturally extended, as the lifecycle of products can be very long, their value may be very high and unique identification and condition monitoring throughout their lifecycle requires attention.

The purpose of this paper is to suggest a methodology for architecture designers and operators to develop, deploy and maintain networked RFID-based services in the future.

The Design Methodology Man-made systems expected to grow and interact with other systems need to be designed in a systematic manner incorporating robustness in them to enable them to cope with changes, errors and performance problems. Successful examples are the Internet and the Unix operating system that was built on about a dozen elegant design principles [1] and continues to be the most robust and flexible computing and server platform. The simple and well defined interfaces of network architectures currently in development aim at the same robustness, efficiency and simplicity, but either lack functionality to handle complex filtering, querying or access control, or only address a specific industry sector and don’t scale well. The stack of EPCglobal standards relevant in this context address many of the problems foreseen in the future, but it is not reasonable to expect that it will be the only solution in the market. The methodology suggested in Error! Reference source not found. shows an ontology based design method that is meant for a heterogeneous environment. The steps shown in the figure are the following: 1. Define a general ontology that is essentially just a list of entities, without relationships and generalization. This step is necessary because the following steps are already subjective, but the entity list is not. 2. Define a specific ontology including classes (individuals, concepts and roles), attributes and interfaces of the building blocks of networked architectures (RFID tags, sensors, data sinks, computers, databases, network interfaces and protocols, applications).

4

Béla Pátkai, Damith Ranasinghe, Mark Harrison, Duncan McFarlane

3.

4. 5. 6.

Organize in layers, i.e. define a stack of layered protocols (the example in the next chapter uses the ISO Open Systems Interconnection standard to show this). Specify interfaces and protocols – for interoperability of the entities and also different architectures if necessary in a heterogeneous environment Implement and operate – the actual building blocks are implemented and start operation according to current requirements. Define performance metrics – on the basis of class attributes. This provides the basis for any M2M (Machine to Machine) communication and automation of related decision making. E.g. when a request is made by another system then the one providing services is able to use these metrics to determine whether it has suitable resources to satisfy the request.

Y es Add entities?

Define general ontology N o

Define specific ontology (properties) Organize in layers

Communicate and harmonize ontology and tools

Define performance metrics

Specify interfaces and protocols Implement and operate

Request arrives for interoperation Figure 1 Ontology-centered system development

7. 8.

Request arrives for interoperation: either a person to person or M2M request arrives and is evaluated either manually or automatically. Communicate and harmonize ontology and tools: in case both parties use an ontology they can use it for quick and efficient communications and they can also harmonize it.

Methodology for Development and Objective Comparison of Architectures for Networked RFID 5

9.

Add entities: in case there are new ontological entities in any of the involved systems these entities can be added, their relationships and properties can be defined.

This general methodology using ontologies addresses the issues listed in the problem definition and provides tools for interfacing, integrating and operating networked IT systems.

Demonstrative Example

General Ontology Definition The general ontology only provides the most basic relationships between the entities and entity classes, because at this level the preservation of generality is necessary. The more specific the ontology becomes in the following steps, the more disagreement and differentiation between them can be expected. The general hardware ontology for a simple networked RFID system includes the following (list nesting already shows basic hierarchy): • Computers • Functional nodes – RFID tags • Passive tags • Semi-passive tags • Active tags – Sensor node • Wired sensors • Wireless sensors – Sensor tags – Interrogators • RFID readers • Sensor sink The same kind of list can be generated for software entities and extended as required with all the necessary details (e.g. aggregations, generalizations, properties, methods and relationships).

6

Béla Pátkai, Damith Ranasinghe, Mark Harrison, Duncan McFarlane

Specific Ontology Definition Error! Reference source not found. shows the specification of the ontology by an RDF (Resource Description Framework) diagram. UML is also a very useful and usually well understood alternative for communicating a system structure, but it has some limitations – e.g. the lack of syntax for an object to specify the ordering of instances [3] – that require an actual ontology language. RDF and RDFS (RDF Schema) uses XML to define entities and relationships. OWL (Web Ontology Language) is its extension and contains further features not necessary in this

Sensor

includes

max_trs 10^5 Computc trans/sec er (server) connects_to bandwdth

Sensor tag includes

measures Temperature

Network (WLAN)

54Mbps

connects_to RFID tag

Interrogator

max_read 640kbps

is_type

T stamp

can_read

max_write

20bits has_memory 64kbit

Passive (C1G2)

128kbps

work. Figure 2 RDF of Example Networked RFID System Definition of Layers Figure 3 shows how the entities defined earlier can be mapped on a layered hierarchy. The example of the OSI (Open Systems Interconnection) standard is used in this paper even if it’s not the most successful one, mainly because it is well-known in many industries. Such a hierarchic layering assists us in determining the interfaces that need to be defined between interacting systems. This figure provides a different cross section of the system than the RDF model, the first is about the place of entities while the other one is about their functionality and relationships.

Methodology for Development and Objective Comparison of Architectures for Networked RFID 7

Figure 3 Correspondence of OSI Layers and Networked RFID

8

Béla Pátkai, Damith Ranasinghe, Mark Harrison, Duncan McFarlane

Usage of the Ontology Model Let’s consider the following example of a logistic problem: • Two firms have a logistic link with each other, and they: – Use bar codes and ASN (Advance Shipping Notification) on products – Want to introduce RFID on products for track and trace – Want to add condition monitoring features to their system • The systematic process provides the following: – They both have an ontology model – They harmonize it to have a mutual understanding – Derive conclusions from the model • Performance of the integrated system • Bottlenecks • Resource usage and cost From the RDF model it is straightforward to derive that: – In case a shipment arrives with 1000 sensor tags every hour, can we share full temperature history with shipping partners? – Do we need more readers, servers, bandwidth? – Should we delegate sensor data filtering towards From a more extensive model we can see whether: – In case we have full service history of aircraft parts and exchange 500 parts per day with partners, can we sell them information and allow them to query our SQL database? – Should we sell raw data or invest in processing/mining?

Conclusions In this paper a systematic, ontology based methodology was suggested to overcome the foreseeable challenges in heterogeneous networked RFID system interconnection. The proposed ideas will have to be tested in a laboratory environment and the automation of service capacity planning has to be investigated.

References 1. EPC Information Services (Version 1.0) Specification, Ratified Standard April 12, 2007, www.epcglobalinc.org/standards 2. Eric Steven Raymond, The Art of Unix Programming, 2003, www.faqs.org/docs/artu/ 3. Stephen Cranefield and Martin Purvis, UML as an Ontology Modelling Language, IJCAI-99 Workshop on Intelligent Information Integration, 1999.