state-of-the-art-analysis...the cuteloop project is co-funded by the european commission within the...

The CuteLoop Project is co-funded by the European Commission within the Seventh Framework Programme (2007-2013)

SSttaattee--ooff--tthhee--AArrtt--AAnnaallyyssiiss CCuutteeLLoooopp RReesseeaarrcchh PPrroojjeecctt CCuutteeLLoooopp iiss eexxpplloorriinngg hhooww IInntteelllliiggeenntt NNeettwwoorrkkeedd DDeevviicceess ccaann bbee uusseedd ttoo eeffffeecc--ttiivveellyy ""iinntteeggrraattee ccuussttoommeerrss wwiitthhiinn aann IInntteeggrraatteedd EEnntteerrpprriissee""

PPuubblliicc PPrroojjeecctt RReeppoorrtt

PPrroojjeecctt FFaaccttss:: DDuurraattiioonn:: 3366 MMoonntthhss ((FFeebbrruuaarryy 22000088--JJaannuuaarryy 22001111)) PPrrooggrraammmmee:: FFPP77 –– IICCTT CCaallll 11 WWeebbssiittee:: hhttttpp::////wwwwww..ccuutteelloooopp..eeuu

CuteLoop Authors and CuteLoop Project Partners

CuteLoop State-of-the-Art Analysis - www.cuteloop.eu Page II

Copyright © 2008 by ATB Institut für Angewandte Systemtechnik Bremen GmbH

All rights reserved.

No part of this project report may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, scanning, or otherwise with-out prior written permission of the publisher. Except for quotation of short passages for the pur-pose of criticism and review.

Trademarked names may appear in this report. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.

The CuteLoop project has no influence on the websites mentioned in this report and is not aware of any illegal content on the pages referenced. Moreover, CuteLoop dissociates itself explicitly from all mentioned websites. This statement is valid for all links within this report.


CuteLoop State-of-the-Art Analysis - www.cuteloop.eu Page III

Authors and CuteLoop Project Partners

ATB Institut für angewandte Systemtechnik Bremen GmbH http://www.atb-bremen.de

Bremen Germany

Rheinische Friedrich-Wilhelms-Universität Bonn http://uf.ilb.uni-bonn.de/

Bonn Germany

UNINOVA – Instituto de Desenvolvimento de Novas Tecnologias http://www.uninova.pt/

Libon Portugal

The Open Group http://www.opengroup.org/

Reading UK

ETSI European Telecommunications Standards Institute http://www.etsi.org/

Sophia-Antipolis France

TraceTracker AG http://www.tracetracker.com/

Heddesheim Germany

EuroTeleServ a.s.b.l. http://www.euroteleserv.eu/

Luxembourg

Euro Pool System International B.V. http://www.europoolsystem.com/

Leidschendam The Netherlands

CAPEB - Confédération de l’Artisanat et des Petites Entreprises du Bâtiment http://www.capeb.fr/

Paris France


CuteLoop State-of-the-Art Analysis - www.cuteloop.eu Page V

Public Project Report

CuteLoop State-of-the-Art-Analysis August 2008

CuteLoop Research Project

Customer in the Loop: Using Networked Devices enabled Intelligence for Proactive Customers Integration as Drivers of the Integrated Enterprise

CuteLoop Table of Contents

CuteLoop State-of-the-Art Analysis - www.cuteloop.eu Page VII

Table of Contents

1 Introduction ..........................................................................................................................1

1.1 CuteLoop Outline and Targeted Approach...................................................................1

1.2 Contents ........................................................................................................................2

2 CuteLoop Key RTD Topics .................................................................................................4

2.1 Architectures – Combination of EDA & SOA .............................................................4

2.1.1 Role and Relevance in CuteLoop .................................................................................4

2.1.2 Existing Methods and Tools .......................................................................................10

2.1.3 Key RTD Problems.....................................................................................................16

2.2 Event-Driven Agents ..................................................................................................18

2.2.1 Role and Relevance in CuteLoop ...............................................................................18


2.2.3 Key RTD Problems.....................................................................................................25

2.3 Security .......................................................................................................................27



2.3.3 Key RTD Problems.....................................................................................................34

2.4 Interaction Models ......................................................................................................35



2.4.3 Key RTD Problems.....................................................................................................38

3 Enabling Technologies .......................................................................................................39

3.1 Traceability Services ..................................................................................................39

3.1.1 General definitions of Traceability .............................................................................39

3.1.2 Levels of traceability ..................................................................................................39

3.1.3 Market Drivers and Players ........................................................................................40

3.1.4 Traceability Architectures, Tools and Systems ..........................................................43

3.1.5 Traceability and Standardization ................................................................................48

3.1.6 Conclusions.................................................................................................................49

CuteLoop Table of Contents

CuteLoop State-of-the-Art Analysis - www.cuteloop.eu Page VIII

3.2 Global Navigation Satellite Systems based Services..................................................50



3.2.3 Key RTD Problems.....................................................................................................56

3.3 RFID enabled Services ...............................................................................................57


3.3.2 Basic RFID System Components ...............................................................................59

3.4 Integration of GNSS and RFID Technology ..............................................................60

3.4.1 Combined Hardware...................................................................................................60

3.4.2 Location Based Services.............................................................................................61

3.4.3 Application Examples of integrated GNSS – RFID ...................................................61

4 Networked Devices .............................................................................................................63

4.1 Devices .......................................................................................................................63


4.1.2 Overview on Networked Devices Technology...........................................................65

4.1.3 Key RTD Problems and Challenges/ Barriers ............................................................71

4.2 Sensors........................................................................................................................74

4.2.1 Influences on the product quality during transport.....................................................74

4.2.2 Sensor Technology .....................................................................................................76

4.2.3 Implementation of smart sensor technology for quality monitoring during transport ......................................................................................................................76

4.2.4 Conclusions.................................................................................................................78

4.3 RFID Tags ..................................................................................................................79

5 Conclusions .........................................................................................................................82

6 References ...........................................................................................................................84

7 Annex 1 – Current Solutions in Application Scenarios ..................................................89

7.1 Craftsmen Application Scenario.................................................................................89

7.1.1 Existing projects of reference .....................................................................................91

7.1.2 Conclusions.................................................................................................................94

7.2 Food Chain Application Scenario – RFID based Solutions .......................................95

7.2.1 Overview on the RFID-implementation scenarios in different stages of the food supply chain........................................................................................................95

CuteLoop List of Tables

CuteLoop State-of-the-Art Analysis - www.cuteloop.eu Page IX

7.2.2 RFID-Technology in production processes ................................................................97

7.2.3 RFID in Logistic Processes ........................................................................................98

7.2.4 Conclusions.................................................................................................................99

8 Annex 2 – RFID Technology Application ......................................................................100

8.1 RFID Application Characteristics.............................................................................100

8.2 Current RFID Applications for Selected Scenarios..................................................101

9 Annex 3 – European RTD Projects ................................................................................104

9.1 Selected European RTD Projects in reference to CuteLoop Key RTD Topics ........104

9.2 RTD Projects of General Interest for CuteLoop.......................................................106

List of Tables

Table 1: Comparative table of existing significant agent frameworks. __________ 24 Table 2: Galileo Navigation Services. ___________________________________ 51 Table 3: Overview of RFID application areas for different sectors and fields. ____ 59 Table 4: RFID improvements benefiting from GNSS [ERA06]._______________ 62 Table 5: Optimum storage temperature for fresh fruits and vegetables

[Charalambous93].___________________________________________ 75 Table 6: RFID frequency bands and applications. __________________________ 80 Table 7: Case Studies from different publications [see RFID-ATLAS, RFID-

JOURNAL 2008: Metro06, Migros06, Nortura08, Sachsenmilch06a, Sachsenmilch07b, Schmidt06]. _________________________________ 96

Table 8: Application of RFID in the supply chain by function [Maloni06]. _____ 101 Table 9: RFID uses in construction processes [ERA06].____________________ 102 Table 10: State-of-the-art – closed and running EU projects and European

Technology Platforms._______________________________________ 104 Table 11: Results of currently running or closed RTD projects, which might be

relevant with respect to the CuteLoop RTD objectives. _____________ 106

CuteLoop List of Figures

CuteLoop State-of-the-Art Analysis - www.cuteloop.eu Page X

List of Figures

Figure 1: SOA (left) vs. EDA (right) brokering model. _______________________ 5 Figure 2: Example of an ESB architecture (source – [Papazoglou07]) ___________ 8 Figure 3: Web Service Architecture Stack. ________________________________ 10 Figure 4: SEDA stage (source: [MWe01]).________________________________ 12 Figure 5: Decoupling in Mule (source: [Mule08]). __________________________ 13 Figure 6: JBI High Level Architecture (source: [JBISpec05])._________________ 15 Figure 7: ServiceMix architecture (source: [ServiceMix08]).__________________ 16 Figure 8: General overview of the envisioned CuteLoop event-driven agent system. 20 Figure 9: CuteLoop Security Methodology Overview._______________________ 29 Figure 10: Traceability drivers and players. ________________________________ 41 Figure 11: The Global Traceability Network. _______________________________ 47 Figure 12: Interactions between entities.___________________________________ 60 Figure 13: Classified characteristics of using networked devices from Human

operator perspective. _________________________________________ 63 Figure 14: A Temperature sensor. ________________________________________ 76 Figure 15: Transport monitoring system [WIPO08]. _________________________ 77 Figure 16: Overview of the JEDERMANN et. al approach [Jedermann07]. _______ 78 Figure 17: e-Business Scoreboard 2006. ___________________________________ 89 Figure 18: Overall system architecture of MOBIBAT (Source: Tibco mobile –

http://www.mobibat.fr). _______________________________________ 91 Figure 19: The concept of PROMISE (see also http://www.promise.no). _________ 94 Figure 20: Some important organizations with RFID-applications in the food supply

chain. _____________________________________________________ 95 Figure 21: Tagged Cow-calf ear (right; Agriview08) with RFID-Tag (left;

Allflex08)__________________________________________________ 98 Figure 22: Applications' value [ERA06]. _________________________________ 103

CuteLoop Abbreviations

CuteLoop State-of-the-Art Analysis - www.cuteloop.eu Page XI

Abbreviations API Application Programming Interface ASF Apache Software Foundation BSD Berkeley Software Distribution CERP Cluster of European RFID Projects CP Consumer Products

COMPASS Chinese Satellite Navigation Sys-tem

Cougaar Cognitive Agent Architecture

CRM Customer relationship manage-ment

DC Distribution Centre DNS Domain Name System DoW Description of Work DSA Digital Signature Algorithm

e.g. exempli gratia (engl. = for exam-ple)

EA Enterprise Architecture EC European Commission ECR Efficient Consumer Response EDA Event-Driven Architecture

EGNOS European Geostationary Naviga-tion Overlay Service

EPC Electronic Product Code EPL Event Processing Language ERA European Research Area ERM EMC and Radio Spectrum Matters ERP Enterprise Resource Planning ESB Enterprise Service Bus ETP European Technology Platform

FIPA Foundation for Intelligent Physical Agents

Galileo European Global Navigation Satel-lite System

GIS Geographic Information System

GLONASS Globales Navigations-Satelliten-System

GNSS Global Navigation Satellite Sys-tems

GPS Global Positioning System GPRS General Packet Radio Service

GSM Global System for Mobile Commu-nications

GTNet Global Traceability Network HF High Frequency i.e. id est (engl. = that is to say)

ICT Information and Communication Technology

JAAS Java Authentication and Authoriza-tion Service

JADE Java Agent Development Frame-work

JBI Java Business Interface LE Large Enterprise

MILS Multiple Independent Levels of Security/ Safety/ Separation

MS Milestone

NMEA National Marine Electronics Asso-ciation

OAA Open Agent Architecture PDA Personal Digital Assistant PE Project End PGP Pretty Good Privacy PKI Public Key Infrastructure POS Point of Sale PS Project Start QoS Quality of Services RFID Radio Frequency Identification

RSA “Rivest-Shamir-Adlerman” Algo-rithm

RTD Research and Technological De-velopment

SCOR Supply Chain Operation Refer-ence-Model

SME Small and medium sized enter-prise

SOA Service Oriented Architecture SOAP Simple Object Access Protocol

UDDI Universal Description, Discovery and Integration

UMTS Universal Mobile Telecommunica-tions System

URI Uniform Resource Identifier w.r.t. with respect to WP Work Package

WSDL Web Service Description Lan-guage

WSN Wireless Sensor Network XML eXtensible Markup Language

CuteLoop 1 Introduction

CuteLoop State-of-the-Art Analysis - www.cuteloop.eu Page 1

1 Introduction

A review of existing approaches and technologies was carried out, especially focusing on poten-tials facilitating the coordination of the workflow in the integrated enterprise. The CuteLoop application scenarios from food chain and craftsmen business were serving furthermore for the identification of solutions which are currently in daily operation. The result of this analysis pro-vides a key input for analysing the application scenarios’ requirements and specifically the inno-vations required (i.e. as input for Task 120 Analysis of Application Scenarios’ Requirements) as well as serving as reference when elaborating the CuteLoop concept in Task 130.

1.1 CuteLoop Outline and Targeted Approach

The CuteLoop project intends to explore how to radically improve the interaction of diverse ac-tors in the integrated enterprise, targeting at an approach which will facilitate the inclusion of customers as an integral part of complex relationships in such business networks. A special em-phasis will be put on the elaboration of a new approach for employing a "Networked Devices Enabled Intelligence" for distributed and asynchronous control of business processes. Key issues to be taken into account for such an approach are: − decoupling of decentralised message routing from subsequent processing, − decentralised and multi-layer asynchronous optimisation of tasks in workflows of loosely

coupled actors, − decentralised approach for communities of interest and trust and − innovative interactions among actors (especially with customers).

When aiming at supporting the networked enterprise to provide ICT enabled added-value ser-vices to their actors as well as to realise a new dimension of networked applications and services capable of interoperation across a wide variety of business domains and organisations of all sizes, a key enabler are Intelligent Networked Devices. These "Networked Devices" are provid-ing their own computing capability, becoming more advanced as well as less expensive and can be combined with an increasing number of other devices. Examples are mobile phones, PDAs, notebooks, wearables, digital pens, displays, or even passive/ active RFID tags and many others. They are generally neither easily interconnected nor interoperable, often missing required ICT related environment and infrastructure. Key challenge is to facilitate an industrial uptake as well as to improve the required technology infrastructure and environment for development of busi-ness specific software, service and applications.

From technology point of view, a topic to be specifically dealt with is how to better exploit po-tentials of enhanced RFID-based systems and Global Navigation Satellite Systems (GNSS), starting from the assumption that a combination of these two technologies is a promising way to support the integration of customers in the Integrated Enterprise. The research targets at the re-alisation of an infrastructure and environment which will directly facilitate the realisation of a new dimension of added-value services, which shall support the decentralised and asynchronous interaction in complex networks of the integrated enterprise. In particular a corresponding archi-tecture, agent based software services and a security framework will be elaborated, enabling the effective usage of distributed networked devices usable by any size of acting entity.

It is intended to realise a novel approach for promoting and facilitating the realisation of highly flexible and dynamic business interconnections for agile coordination in business networks, hav-ing customers as key drivers. Specifically, the project is aiming at research on distributed asyn-chronous interaction of actors and exchange of knowledge among Large Enterprises (LEs), Small and Medium Enterprises (SMEs) and customers.



For requirements analysis as well as integration, test and assessment of the envisaged project results, SME driven integrated enterprise scenarios are included in the CuteLoop project. They were selected to provide requirements from heterogeneous business domains as well as to focus on different phases of the general supply chain in the integrated enterprise. Therefore, the food chain application scenario is specifically focusing on the management and information exchange along the chain. The craftsmen application scenario is considering the craftsmen as customer of the supply chain, while providing its services to the consumers, specifically requiring support in the interaction with other craftsmen and as gateway in between the supply chain and the con-sumers.

1.2 Contents

CuteLoop will operate in a highly dynamic environment, where it needs to react and adapt in an agile manner to both, internal and external changes. The network structure of an integrated en-terprise changes frequently and is constituted by independent autonomous service providers and consumers. Moreover, it must integrate a huge number of heterogeneous actors and systems and support asynchronous interactions among them. Principles of service oriented architectures (SOA) are envisaged to help with the creation of flexible business processes and offer the possi-bility to easily integrate legacy systems, which have no means of communicating with each other. Event driven architectures (EDA) enable the highly interaction driven characteristics of complex interactions and supply chains. Therefore it is considered as a promising approach to couple SOA with principles from EDA, as the extremely loose coupling provided by EDA seems to be suitable for massively distributed systems. The current state of the art of both architectural principles are presented in chapter 2.1.

As introduced before the CuteLoop architecture shall be based on EDA and SOA principles. This and the usage of many heterogeneous devices necessitates a technology to interface with various devices. Therefore, the project aims at the development of scalable, open and architecture inde-pendent software to achieve seamless data exchange among networked actors and architectures. Software agents, driven by events generated by the workflow along the supply chain are consid-ered as a key enabler to fulfil those requirements. Chapter 2.2 will present the relevant aspects to be taken into account as well as most promising technologies as reference for starting the con-ception of the CuteLoop solution. Specifically multi-agent based platforms were analysed, since they are considered to specifically support dynamic networks of actors in both vertical integra-tion among plants and business processes as well as horizontal integration for network internal resources planning and scheduling.

The project’s envisaged scenarios include the coupling of diverse actors, often dealing with sen-sitive data (e.g. data of consumers, suppliers, costs, purchasing conditions). As presented in chapter 2.3, CuteLoop envisages to address security and also trust amongst network centric sys-tems involving the integration of embedded devices, information processing and communication. Since it is necessary to support requirements of different systems with heterogeneous abilities and needs concerning trust and security, it is envisaged to develop a security framework using the MILS architecture (Multiple Independent Levels of Security/Safety/Separation), which is an architectural approach designed to build scalable systems.

Traditional interaction models have a certain and thus limited focus, but in today’s constantly changing technical and economical world, such limited views are no longer appropriate and a multi-level approach which builds on a system analysis of actual interaction activities and possi-ble reference models is needed. The envisaged research work within the CuteLoop project is aiming at approaches for the identification and the specification of new interaction models and patterns for the real time enterprise, which serve the dynamic transparency and quality interests



of consumers with their changing needs and lifestyles, and are economically feasible for adop-tion by the SME target group. Basic interaction models and most relevant approaches for realis-ing the interaction in the integrated enterprise are presented in chapter 2.4.

One of CuteLoop’s goals is to establish a connection between product information and the physi-cal product as it moves through the production cycle and the supply chain. This so called whole-chain traceability is the most advanced kind of traceability. It makes it possible to uncover prod-uct origin and production history online. Tracking and tracing products in order to undertake withdrawals if needed, or to document the ingredients as well as their origin. This specifically contributes to ensure product safety & reliability and maintain consumer confidence in the deliv-ered products. Currently applied approaches are presented in chapter 3.1.

Furthermore, accurate and real-time position information can dramatically improve the quality and relevance of all sorts of commercial services (e.g. traceability combined with location and time). There are a diverse application potentials as presented in chapter 3.2, but however current application scenarios are still limited. In the scope of CuteLoop it needs to be further analysed, of how time & place information in combination with massively distributed networked devices could positively affect business processes to enable the delivery of added value services. Possi-ble scenarios as specifically incorporated in the CuteLoop application scenarios were analysed, on ways for including GNSS signals in combination with local intelligence and local or remote databases. Based on basic reference scenarios, it is envisaged to directly identify generic compo-nents and deduce application specific services to generic elements.

In order to track “things” it is necessary to identify them, which can be easily achieved at low costs by Radio-frequency identification (RFID) technology. Extended RFID technology goes even further and offers limited computing and data storing capabilities. Taking into account these references, CuteLoop aims at a secure and trusted usage of RFID tags and of using en-hanced RFID based devices, addressing the support of diverse device complexities, also taking into account general interaction patterns supported by different RFID technologies. Key poten-tials of RFID enabling technology are presented in chapter 3.3.

For realising advanced solutions focusing on disburdening the end-user from administrative tasks, software applications are the key. However, specific scenarios within the integrated enter-prise are imposing diverse requirements on hardware technology in relation to e.g. basic func-tionality, maintainability, availability or performance. Therefore, within chapter 4, the current state of the art of hardware in terms of networked devices, sensors and RFID is presented, while some additional references are provided in the Annex 2 in chapter 8, outlining RFID application characteristics and current applications for selected scenarios.

Finally, in annex 1 in chapter 7 currently available and applied solutions within the CuteLoop application scenarios are presented. Specifically those solutions are outlined which shall be taken into account when realising the test and assessment. Moreover, solution potentials were ana-lysed, which might be integrated as features or as enabling technologies in the envisaged Cute-Loop results, aiming at the realisation of networked device enabled intelligent solutions.

CuteLoop 2 CuteLoop Key RTD Topics


2 CuteLoop Key RTD Topics

2.1 Architectures – Combination of EDA & SOA

2.1.1 Role and Relevance in CuteLoop

The envisioned CuteLoop system will allow an integrated and real-time networked enterprise to operate transparently in a highly dynamic environment, reacting and adapting in an agile manner to not only internal changes but also to external events. For that, CuteLoop must integrate a huge number of distributed heterogeneous stakeholders and systems that interact in the context of the integrated enterprise, and in addition, it must support novel interaction patterns and models among them, including “ad hoc” and asynchronous interactions.

Thus, the CuteLoop system will have to support three fundamental dimensions of the integrated real-time network enterprise, namely, distribution, heterogeneity and the real-time aspects. The first two dimensions are the main source of technological interoperability1 barriers in the context of networked enterprises, which hinders the business efficiency of the overall network. Yet, in the context of CuteLoop, interoperability plays a crucial role in ensuring a seamless interaction and communication among the different parties of the integrated enterprise (especially when us-ing diverse network devices), enabling them to quickly react and adapt to changes in the Cute-Loop’s environment.

Therefore, the CuteLoop system must provide appropriate mechanisms to ensure a seamless in-teroperation of its heterogeneous stakeholders. This entails that the design of the CuteLoop sys-tem architecture must take into account existing and established architectural principles that fa-cilitate and promote interoperability in distributed and heterogeneous environments. Addition-ally, the CuteLoop system must provide support for the real-time enterprise, i.e. it must provide mechanisms that allow the capturing of real-time events and support asynchronous communica-tion among the interacting parties.

To achieve these objectives, CuteLoop intends to define an innovative architecture that combines the principles of SOA and EDA. These two architectural approaches must first be studied and analysed in order to clearly define their roles in the architecture. For instance, there’s a lot of controversy whether these two approaches are mutually exclusive or not, i.e. if they should be considered as separated approaches or if they are just different instantiations of the same princi-ples. Some argue that EDA is in fact a natural evolution of the SOA model and that it represents the new way of how companies should implement SOA in a proper way. Others stress that they are competitive approaches and that enterprises should choose between one or the other [Bloomberg04].

Regardless of the discussion whether they are mutually exclusive or not, the two approaches share a lot of similarities (e.g. modularity, encapsulation etc) in the sense that they are both ar-chitectural approaches to structure distributed systems based on multiple loosely coupled com-ponents. These similarities will be exploited in CuteLoop in order to leverage the strengths of both approaches in the development of the CuteLoop architecture.

1 Interoperability is defined as the ability of two or more ICT assets (hardware devices, communications devices,

or software components) to easily or automatically work together and, in the business sense, expands to include the ability of two or more business processes, or services, to easily or automatically work together [CompTIA04].



2.1.1.1 SOA and EDA

A SOA is a logical way of structuring a software system into a set of loosely coupled compo-nents whose interfaces can be described, published, discovered and invoked over a network. These components are deployed as services with standardised interfaces, independent of any specific platform or implementation technology, and that carry out together a high-level function or business process (e.g. placing an order, making a credit approval on a purchase) [Papazoglou07].

Similarly, EDA defines a methodology for designing and implementing distributed applications and systems, where events trigger asynchronous messages, which are sent between independent software components that need not to have any information about each other (i.e. they are de-coupled). In this context, an event is a notable thing that happens in the real world that causes a change in the state of the system or something relevant for the business of the enterprise, such as a customer order, the arrival of a shipment, or the payment of a bill [Michelson06].

Thus, although EDA focuses on event processing and SOA deals with the services, the two ap-proaches are similar in the sense that they both define a way of structuring large distributed sys-tems into a set of loosely coupled components, whilst separating implementation aspects from interaction specifications. Further, they are both based on the broker architectural pattern, where a central component of the architecture (the broker) acts as an intermediary between the other interacting components. However, the role of the broker in the two approaches is different, as illustrated in the following Figure 1.

ServiceConsumerService

Consumer

ServiceBroker

ServiceBroker

ServiceProviderServiceProvider

Find Publish

Invoke/bind

Reply

EventProducer

EventProducer

EventConsumer

EventConsumer

Register/Emit

EventBrokerEventBroker

EventConsumer

EventConsumer

Notify

SubscribeNotifySubscribe

ServiceConsumerService

Consumer

ServiceBroker

ServiceBroker

ServiceProviderServiceProvider

Find Publish

Invoke/bind

Reply

Invoke/bind

Reply

EventProducer

EventProducer

EventConsumer

EventConsumer

Register/Emit

EventBrokerEventBroker

EventConsumer

EventConsumer

Notify

Subscribe

Notify

SubscribeNotifySubscribe

NotifySubscribe

NotifySubscribe

Figure 1: SOA (left) vs. EDA (right) brokering model.

In SOA the broker acts as a mere searchable repository of service descriptions (interfaces) where service providers publish their services and service consumers find services and obtain binding information for these services. Hence, the broker in the SOA model can be regarded as services yellow pages (analogous to the telephone yellow pages) having a passive role, i.e. not interfering with actual interaction between the consumer and the provider.

Similarly, in the EDA model, the event producer uses the broker to register the type of events that it produces, and the consumers subscribe to the events they want to process. However, in EDA, the broker has an active role where it actually takes part in the interaction, acting as an event manager that is responsible for capturing the events emitted by the event producers and delivering them to the correspondent subscribers.

Thus, the SOA model represents a proactive approach where the service is explicitly declared and published by the component that offers it. The service consumer is responsible for starting the interaction with the service provider, after discovering the desired service contract (interface) published in the broker and performing a binding process to the service provider. Once the inter-action is started, the execution is autonomous and cannot be influenced by any external inputs, including the broker.



EDA, on the other hand, is a reactive approach where an event is transmitted to potentially a large number of components that may decide or not to react and process it, and the interaction is initiated by the event producers. After emitting the event, the producer has no control over the interaction, since it’s the consumer that registers interest, and in addition, the interaction flow may respond to external input (e.g. new events injected by external event sources). This interac-tion pattern is called publish/subscribe, which as the name implies, consists in letting the compo-nents declare their interest for a certain type of events (subscribe) and those events to be distrib-uted to all interested components each time they are emitted (published).

In fact, one fundamental difference between the two approaches is that the invocation semantics behind SOA complies with the request/reply pattern instead of publish/subscribe. In this pattern, the service consumer sends a request message to the provider, and the provider responds with the reply message. Each message travels one direction, from the sender to the receiver, and this is typically realised in a synchronous transmission since the consumer waits for the provider to send a response within a certain fixed time period. The synchronous communication is not al-ways suitable or even possible as it may lead to reliability, latency and quality-of-service degra-dation. In addition, as mentioned before, in SOA, prior to the interaction the consumer has to perform a binding operation in order to establish a communication channel with the provider, whilst in EDA this is not required and the producer is normally completely oblivious to the exis-tence of the consumers. Hence, there remains the need for further decoupling the SOA compo-nents in order to support “ah-hoc” interactions, since consumers initiate services execution and they must therefore know the providers to be used in advance.

For these reasons, SOA is generally coined as a loosely coupled approach and EDA is character-ised as being truly decoupled. In SOA, the dependency between the provider and consumer of a service, which is the contract the provider publishes in a third-party broker, impedes the fully decoupling of the interacting components. Nevertheless, this dependency is part of the funda-mentals principles of SOA, and in fact, it represents an advantage of SOA over other architec-tural approaches, with regard to the support of interoperability between the components. For in-stance, since the dependency is a runtime dependency and not a compile-time dependency, it can be discovered dynamically, and this way the consumer obtains all the information it needs to invoke a service at runtime. Further, besides the interface, the service contract includes the de-scription and format of the messages to be exchanged between the components, and in addition, the location of the service (the service consumer does not know the location of the service until it is needed), hence it provides a mean to support location transparency. Thus, the contract depend-ency promotes interoperability by minimizing the requirements for shared understanding, since a service description and a protocol of collaboration and negotiation are the only requirements for shared understanding between a service provider and a service consumer.

Additionally, another distinct advantage of SOA over other architectural approaches is the fact that it implies the usage of open standards to facilitate not only the services development but also to further enhance interoperability among them. For instance, the underlying Web Services tech-nologies (preferred implementation technology for realising the SOA principles), are based on a widely adopted and universally accepted set of open interoperability standards and protocols (e.g. XML, SOAP, UDDI, WSDL, WS-* standards) for building, describing, cataloguing and managing reusable services.

Thus, interoperability is an intrinsic characteristic of SOA, which eases the integrations of het-erogeneous systems and provides a major enhancement in business agility, which is one of the key drivers of the CuteLoop project. Therefore, the Service Oriented Computing (SOC) princi-ples will be used to structure the CuteLoop’s system architecture into a modular, flexible and loosely coupled SOA, in order to overcome the many distributed, heterogeneity and interopera-



bility computing challenges (e.g. legacy application integration, loose coupling, etc.) imposed by the innovative (and complex) interactions patterns and models that CuteLoop intends to support in the context of the integrated enterprise. For instance, the SOA approach will be exploited in CuteLoop in the following manner: • CuteLoop will provide its functionalities (i.e. units of business) as Services: services will be

used in CuteLoop to provide value propositions (i.e. added-value functions) within the inte-grated enterprise, as a starting point for flexible business processes composition.

• CuteLoop services will be technology neutral (i.e. SOA standards will be used): this means that CuteLoop services will be accessed through standardized lowest common denominator technologies that are widely available, and the CuteLoop functions invocation mechanisms (protocols, descriptions and discovery mechanisms) will comply with widely accepted SOA standards. This will potentiate interoperability within CuteLoop’s environment, contributing for the easy engagement within the integrated enterprise, hence to the self-evolving and adaptability of CuteLoop network.

• The CuteLoop services will enable interoperability of legacy applications: SOA allows leg-acy applications to be exposed as services, and when to structure the CuteLoop architecture as an SOA, a seamless integration between heterogeneous legacy systems will be greatly fa-cilitated. This way, new services can be created and dynamically published and discovered without disrupting the CuteLoop’s environment.

Hence, the CuteLoop system will provide its functionalities as a collection of coarse and large grained services, leveraging the usage of numerous networked devices and legacy systems, al-lowing a CuteLoop user, using any device, to access and integrate the CuteLoop functions in its own business processes or possible in the creation of new business applications. For instance, the basic services provided by CuteLoop will be used to build more sophisticated and complex ser-vices by simply aggregating or encapsulating the basic ones, hence reducing complexity and allowing flexibility, scalability, extensibility and adaptability of the CuteLoop system.

Nevertheless, as mentioned before, CuteLoop intends to provide support not only for an inte-grated enterprise but also for a real-time enterprise, where real-time and asynchronous interac-tions often take place among its stakeholders. This means that the enterprise has to be able to capture and process events as they occur, interpreting their meaning in real time, and that mechanisms must be available to allow asynchronous communication among the business part-ners. Although SOA is a powerful way of designing composite and interoperable applications, SOA alone is not sufficient to model and support real-time and asynchronous business opera-tions, hence to provide the necessary integrity and agility that CuteLoop aims to support in the context of the real-time enterprise.

This calls for extremely (even full) decoupled interaction support, which is incongruous with the request/reply and contract-based loosely coupled interaction model that the SOA principles are based on. Such support is provided, however, by the EDA model, since, as explained before, in the case of EDA, the interacting components (i.e. event sender and receiver) may be completely unaware of each other, hence it allows the creation of extremely (even full) decoupled distributed software systems, where the creator (source) of an event has no knowledge of the event’s subse-quent processing, or the interested parties.

Therefore, since in comparison with SOA, EDA is best suited for asynchronous flows of work and information, as well as for real-time interactions, CuteLoop will also rely on the EDA prin-ciples to complement the CuteLoop system architecture in order to be able to support the agile networked enterprise, for instance, one that is able to react quickly and precisely to rapidly changing conditions. In addition, due to the high level of decoupling that EDA permits, it repre-



sents an appealing approach to tackle one of the RTD challenges in CuteLoop, namely the de-coupling the message routing from subsequent processing.

Thus, the CuteLoop architecture will combine the principles behind EDA and SOA in order to obtain an appealing Event-Driven SOA architecture for supporting the highly dynamic environ-ment envisioned by CuteLoop, based on distributed and completely decoupled services, syn-chronously or asynchronously, executed in an efficient manner. This way, one can take advan-tage of the SOA flexibility to support business interoperability and use the EDA event-driven interaction style to keep applications decoupled from one another as well as reacting to asyn-chronous events.

2.1.1.2 Combination of EDA and SOA

As explained above, both, SOA and EDA, are based on the broker architecture pattern where a broker component of the architecture acts as an intermediary between the other interacting com-ponents. Yet, the broker plays different roles in each approach, being an active player in the EDA model whilst in the SOA model it represents a mere passive service description repository. Nevertheless, the key to combine the two approaches resides in the exploitation of the common broker entity, for instance, to provide a broker that is sophisticated enough to support both inter-action models acting as a middleware infrastructure that integrates services and events.

The Enterprise Service Bus (ESB) is currently the state-of-the-art middleware infrastructure that fulfils the goal of combining the EDA and the SOA approaches in order to simplify integration of business units, bridging heterogeneous platforms and environments. An ESB can be regarded as an intermediary layer that enables the deployment, management and interoperation of inde-pendent components or applications. It supports service, message, and event-based interactions using synchronous or asynchronous communications, hence facilitating interactions between one or many stakeholders (one-to-one or many-to-many communications patterns). The concept is designed to provide interoperability between larger grained applications and other components via standards-based adapters and interfaces. Figure 2 illustrates an example of an ESB architec-ture connecting diverse applications and technologies.

Reliable Asynchronous Secure Messaging

Customapplications Portals Service

orchestration

service interface

Enterpriseapplications

Multi-platformsupport

Data sources

WebSphere,.Netapps

Java apps Mainframe& legacy

apps

Distributedquery engine

MQgateway

JMS/J2EE

WebServicesAdapters

Reliable Asynchronous Secure Messaging

Customapplications Portals Service

orchestration

service interface

Enterpriseapplications

Multi-platformsupport

Data sources

WebSphere,.Netapps

Java apps Mainframe& legacy

apps

Distributedquery engine

MQgateway

JMS/J2EE

WebServicesAdapters

Figure 2: Example of an ESB architecture (source – [Papazoglou07])

Thus, the purpose of an ESB is to facilitate application and process integration by providing ca-pabilities such as distributed processing, intelligent routing, security, and dynamic data transfor-



mation, and acting as an intermediary layer to enable communication between different applica-tions. These features can be intelligently combined and used, so that an ESB can permit the inte-gration of SOA and EDA, providing all the capabilities needed to support both paradigms.

Indeed, since an ESB works by acting as a sort of transit system for carrying data between appli-cations, they are very well suited to function as a container of business events that are made widely available for subscription. For instance, the distributed nature of the ESB architecture allows individual event-driven services to plugged into the bus backbone on an ‘as needed’ basis, highly decentralised and working together in a highly distributed fashion, while they are scaled independently from one another. In this context, an event-driven service is one that once de-ployed into an ESB, its execution can be triggered by either a service consumer or an event thrown by some given event source that is also plugged onto the infrastructure.

In this scenario, such event-driven SOA infrastructure can treat applications and services as ab-stract service endpoints, which can readily respond to asynchronous events. This way, the ser-vices plugged into the bus are not required to understand protocol implementations or have any knowledge on routing of messages to other services. Each plugged application or service can operate independently from the other and is capable of receiving individual tasks or units of work that are processed as asynchronous events. The ESB infrastructure is responsible for cap-turing the events thrown by event sources and for publishing them to the services that have sub-scribed to the events. Thus, the events themselves would represent the messages, for instance, encapsulating an activity, data, or a complete description of a specific action that should be un-dertaken.

One of the benefits of using an ESB infrastructure as explained above is that it allows the deci-sions about the flow of data and the flow of control to move out of the endpoints applications and into the broker. This way, the broker has total control of the message and event routing, hence complex routing algorithms can be implemented transparently from the interacting com-ponents. For instance, content-based routing mechanisms can be put in place, where the mes-sages are examined and routed according to their content. Also rule-based routing can be imple-mented based on explicit configuration files containing declarative rules, as well as topic-based routing, where messages can be grouped into fixed, topical classes, so that subscribers can expli-cate interest in a topic in order to receive messages associated to that topic. In addition, the bro-ker can provide mechanisms that support reliable messaging, guaranteeing that messages are delivered even if the receiver is not available at the time when the message was sent. For exam-ple, the broker can store the message in a local repository and forward it latter when it can be successfully delivered. This can be very useful in supporting the different styles of event proc-essing that can be performed in EDA environments, which are simple2, stream3 and complex4 event processing.

2 In simple event processing, a notable event happens, initiating down-stream action(s). Simple event processing

is commonly used to drive the real-time flow of work—taking lag time and cost out of a business[Michelson06]. 3 In stream event processing, both ordinary and notable events happen. Ordinary events (orders, RFID transmis-

sions) are both screened for notability and streamed to information subscribers. Stream event processing is commonly used to drive the real-time flow of information in and around the enterprise, enabling in time decision making [Michelson06].

4 Complex event processing (CEP) deals with evaluating a confluence of events and then taking action. The events (notable or ordinary) may cross event types and occur over a long period of time. The event correlation may be casual, temporal, or spatial. CEP requires the employment of sophisticated event interpreters, event pat-tern definition and matching, and correlation techniques. CEP is commonly used to detect and respond to busi-ness anomalies, threats, and opportunities[Michelson06].



2.1.2 Existing Methods and Tools

2.1.2.1 Web Services

Web Services are the current most promising technology that realise the principles of SOA. They represent self-contained modular business applications that have open, Internet-oriented, stan-dards-based interfaces. The W3C consortium defines a web service as “applications identified by a URI, whose interfaces and bindings are capable of being defined, described and discovered as XML artefacts. A Web service supports direct interactions with other software agents using XML-based messages exchanged via Internet-based protocols” [W3C08].

In this sense, they provide the basis for the development and execution of business processes that are distributed over the network and available via standard interfaces and protocols. Thus, Web Services enable the integration and interoperability of heterogeneous systems and components which may be geographically dispersed. The vision behind the technology is to transform the internet into an environment where businesses can expose their current and future business ap-plications as Web Services that can be easily discovered and consumed by interested parties.

To realise this vision, the Web Service concept rely on a widely available and strongly supported set of standards and protocols. Figure 3 presents the Web Service Architecture Stack of existing standard specifications and their purpose.

Composition/Orchestration/ChoreographyWS-BPEL, WS-CDI, WS-CDL


ManagementWS-Management, WSRF


SecurityWS-Security, WS-Trust, WS-Policy, WS-SecureConversation, WS-Privacy


TransactionWS-Transaction, WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity


Discovery/DescriptionUDDI, WSDL, WS-Discovery, WS-Inspection, WS-MetadataExchange, WSRF, WSDL-S


ReliabilityWS-ReliableMessaging, WS-Reliability


MessagingSOAP, WS-Addressing, WS-Eventing


NotificationWS-Notification, WS-BaseNotification, WS-BrokeredNotification, WS-Topics


TransportHTTP, HTTPS, SMTP




















Figure 3: Web Service Architecture Stack.

Besides the obvious relevance that the Web Service technology has for CuteLoop, one important aspect to be exploited, is that the technology can be used to implement both SOA and EDA prin-ciples. In fact, some of the specifications in the Web Service stack depicted in Figure 3 resulted from efforts of major standardisation groups such as Advancement of Structured Information Systems (OASIS), World Wide Web Consortium (W3C) and Web Services Interoperability Or-ganization (WS-I), to develop standards that would allow the support of the EDA principles us-ing Web Services. Some of the most relevant are: • WS-Eventing: Web Services Eventing is an IBM, BEA Systems, Microsoft, Computer Asso-

ciates, Sun Microsystems and TIBCO Software specification that provides a protocol that al-



lows Web Services to subscribe to or accept subscriptions for event notification messages. This specification defines a protocol for one Web Service (called an "event sink") to register interest (called a "subscription") with another Web Service (called an "event source") in re-ceiving messages about events (called "notifications") [WSEventing06].

• WS-ReliableMessaging: The Web Services Reliable Messaging is an OASIS specification that describes a protocol which allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. The proto-col is described in this specification in an independent manner allowing it to be implemented using different network transport technologies [OAS081].

• WS-Notification: The Web Services Notification defines a set of specifications that standard-ise the way Web services interact using "Notifications" or "Events". They form the founda-tion for EDAs built using Web services providing a standardized way for a Web service, or other entity, to disseminate information to a set of other Web services, without having to have prior knowledge of these other Web Services, using the publish/subscribe interaction pattern. Three specifications were developed so far by the OASIS group, namely, WS-BaseNotification, WS-BrokeredNotification, WS-Topics [OAS082].

However, most of these standards are currently not in a mature enough status to be readily used in the production implementation of EDA applications. Hence, until these Web Services-based standards are fully validated, EDA based on Web Services technology require extensive engi-neering effort to provide the desired levels of functionalities [MphasiS04].

2.1.2.2 SEDA

The Staged Event-Driven Architecture (SEDA) is a software architecture design framework which is designed to enable high concurrency, load conditioning, and ease of engineering for Internet services. SEDA originated from the fact that the traditional thread-based model used to support high concurrency and variations in service load, which are characteristics of the Internet today, suffer from several limitations, such as limited scalability and huge overheads, which in their turn lead to serious performance degradation (e.g. when the number of threads is large). Therefore, and since event-driven systems tend to be robust to load handling, with little degrada-tion in throughput as offered load increases beyond saturation, SEDA combines aspects of threads and event-based programming models to support massive concurrency, avoiding per-formance degradation, and to manage effectively the resources needed for high concurrent Internet services [MWe01].

SEDA specifies how one can take advantage of the event-driven paradigm to support several features, such as high concurrency, resource management, and performance issues with regard to Internet services, which are all relevant in the context of the distributed and highly interactive environment that CuteLoop aims to support. Thus, SEDA principles should be taken into account and studied in order to see how they can be applied in the structuring of the CuteLoop system’s architecture so that the CuteLoop system can be highly scalable and support massive concur-rency.

One of the most important aspects for CuteLoop, is the fact that SEDA decomposes an applica-tion into a network of loosely coupled stages separated by event queues, and introduces the no-tion of dynamic resource controllers to allow applications to adjust dynamically to changes in the environment, such as variations in load. A stage is the fundamental unit of processing within SEDA, and it represents a self-contained application component consisting of an event handler, an incoming event queue, and a thread pool, as depicted in Figure 4. Each stage is managed by a controller that affects scheduling and threads allocation. The resource controllers automatically



adapt the resource usage of the stage based on observed conditions and they can operate either with entirely local knowledge about a particular stage, or work in concert based on global state.

Event HandlerEvent Handler

Thread Pool

OutgoingEvents

Event Queue

Controller

Event HandlerEvent Handler

Thread Pool

OutgoingEvents

Event Queue

ControllerController Figure 4: SEDA stage (source: [MWe01]).

The core logic for each stage is provided by the event handler, which processes each batch of events, and may enqueue events (i.e. dispatch events) onto another stage by first obtaining a handle to that stage’s incoming event queue (through a system-provided lookup routine), and then invoking an enqueue operation on that queue. Nevertheless, event handlers do not have direct control over queue operations or threads. The separation of core application logic from thread management and scheduling makes it possible for the stage to control the execution of the event handler and to implement various resource-management policies. The stage threads oper-ate by pulling a batch of events off of the incoming event queue and invoking the application-supplied event handler. The introduction of a queue between stages decouples their execution by introducing an explicit control boundary.

Thus, if we establish an analogy between a stage and a service, the SEDA processing model ex-hibits some of the features that are envisioned by CuteLoop, such as the decoupling of message (event) routing from subsequent processing. Further, the use of dynamic control and automatic tuning of applications in SEDA is another feature that should be exploited in the context of CuteLoop, since one of the goals is to support highly interactive and volatile environments.

Several implementations of the SEDA principles exists that can potentially be reused in Cute-Loop, such as the Mule framework, which is an open source ESB-messaging framework and message broker that uses the SEDA concepts to increase the performance of processing events.

2.1.2.3 Mule

Mule is in fact a lightweight Java-based messaging framework structured as a SOA that allows one to quickly and easily connect applications to it, in order to exchange data, regardless of the technologies used by the applications (e.g. JMS, Web Services, JDBC, HTTP, etc) [Mule08]. Mule seamlessly handles the interactions among all applications connected to it, hence enabling an easy integration of existing systems, including legacy applications.

Concerning CuteLoop, an interesting feature of Mule is the fact that it provides support for asyn-chronous, synchronous, and request-response message (events) communication styles, between heterogeneous applications. Moreover, Mule is highly scalable, allowing the continuous increase over time of connected applications, managing all the interactions between them transparently, regardless of their location and underlying technologies.

Mule is based on the principles of ESB architectures, thus, as explained before, it acts as transit system for carrying data between application services within an intranet or even across the Inter-



net. The Mule ESB model drives all services in a system over a decoupled, message-communication backbone. This message bus is the heart of the system and it routes messages between the connected applications. Mule also provides several support functionalities, which further decouples the services from aspects like container management, transport, message trans-formation details, etc, making it easy to register, plug, and interoperate services using the framework. In addition, services plugged into Mule have no knowledge of other registered ser-vices, hence, each service is concerned with processing only the events it receives, which eases the development of highly decentralised systems. Moreover, Mule allows the complete decoup-ling of message routing and subsequent processing as envisioned by CuteLoop. Figure 5 illus-trates how the separation between message routing and message processing is achieved in Mule.

Message

HTTP Transport

Service

Inbound Router

XML toJava ObjectTransformer

MessageJMS Transport

Customer DataService

Component


Component

Outbound Router

Message

HTTP Transport

Service

Inbound Router

XML toJava ObjectTransformer

MessageJMS Transport


Component


Component

Outbound Router

Figure 5: Decoupling in Mule (source: [Mule08]).

As depicted, a service plugged to Mule only contains the business logic for processing the data that arrives in messages, having no information about how to receive or send the messages them-selves. To ensure that the service receives the right messages and routes them properly after processing, a service in Mule is wrapped in a component where an inbound router and an out-bound router are specified. The former specifies which messages should be processed by the service, whilst the latter specifies where a message should be dispatched after being processed. The framework supports dynamic, declarative, content-based, and rule-based message routing.

Additionally, services are completely oblivious with regard to the format of the messages and how to read them. To be able to process them, specific transformers must first transform the messages payload, which are carried by any transport protocol (e.g. HTTP, JMS, etc), to the specific format that the service component can read before the router delivers them. This is an opposite approach to the more conventional approach where all messages are always converted to a single common messaging format. In the case of Mule, messages and their data are trans-formed only as needed for the target component or application where the message is being sent.

Thus, Mule makes all the message handling details, including transporting, transforming and routing, completely transparent to the services (applications) components that are plugged into



the bus. This feature makes Mule a very attractive framework to be used and exploited in the context of CuteLoop. Yet, another important aspect of Mule is the fact that its open source and vendor-neutral, hence it doesn’t restrict the type of application that can plug in to it, and in addi-tion, it can be customized to satisfy the specific CuteLoop requirements.

Nevertheless, Mule and the majority of ESB-based solutions available for application integra-tion, despite many of them being open, fail to comply with any standardised design and imple-mentation specification for the purpose. One example of such standard specification which is becoming popular nowadays, is the Java™ Business Integration (JBI) specification that defines how integration products should look like and how one could actually choose to design an inte-gration product or component.

2.1.2.4 Java Business Interface

Java Business Interface (JBI) specifies a standards-based architecture for integration solutions, where third-party components can be “plugged in” to a standard infrastructure, which allows them to interoperate in a predictable, reliable fashion, even if they are produced by separate ven-dors [JBI05]. This way, the lock-in to a particular vendor of integration technologies can be avoided and the user is free to choose components that provide the particular functions that he or she needs, and be assured that a functional integration solution can be assembled from those pieces. In addition, the kind of standardised infrastructure that JBI potentiates can stimulate the emergence of new and innovative integration models and technologies. For instance, having such infrastructures, innovators can concentrate on a particular technology or problem area, without having to worry about providing all the other pieces needed to build a complete integration solu-tion.

To some degree, one can say that JBI standardizes the main component interfaces and services needed for implementing an ESB. Indeed, JBI is a specification and API that defines a platform for building enterprise-class ESBs using a pluggable, service-based design. One particular inter-esting aspect about JBI is that the standard adopts the SOA approach to maximize the decoupling between components and to create well-defined interoperation semantics founded on standards-based messaging. This is an appealing characteristic from the CuteLoop’s point of view, in the sense that JBI specifies a standard way to define a SOA-based architecture for loosely coupled interoperation of components.

In fact, the interoperation between the components plugged in to the architecture defined by JBI is achieved through the method of mediated message exchange, and the message exchange model is based on the Web Services Description Language (WSDL) [WSDL01]. In this WSDL-based, SOA model, JBI plug-in components are responsible for providing and consuming ser-vices or functions which are modelled as WSDL operations involving the exchange of one or more messages.

Figure 6 exemplifies how JBI realises the mediated message exchange model. As can be seen in the figure the components do not interact with each other directly. Instead, the JBI infrastructure acts as an intermediary to route messages from component to component. This is how JBI achieves the decoupling of service providers from consumers, and this functionality is provided by a JBI component called Normalized Message Routing (NMR). The NMR is responsible for preserving flexibility in a JBI infrastructure, keeping consumers and providers minimally inter-twined, and providing a key point for message processing and monitoring in the infrastructure.



Normalized Message Router

BPELSE

OtherSEs…

WS-IBC

OtherSCs…

Component Framework

MonitoringControl

DeploymentInstallation

JBI Environment

JMX-basedAdminTools

ExternalService

Provider

ExternalService

Consumer

Normalized Message Router

BPELSE

OtherSEs…

WS-IBC

OtherSCs…

Component Framework

MonitoringControl


MonitoringControl


JBI Environment

JMX-basedAdminTools

ExternalService

Provider

ExternalService

Consumer Figure 6: JBI High Level Architecture (source: [JBISpec05]).

Two types of components can be plugged into the bus, namely, Service Engines (SEs) and Bind-ing Components (BCs). An SE encapsulates chunks of business logic, processing, or transforma-tion functionality. It can either be a service consumer or a component that provides a service on the bus. A BC is responsible for the communication with external systems using a communica-tion protocol. Thus, JBI clearly specifies how to decouple message processing from the commu-nication mechanisms using these two types of components. In addition, similar to Mule, the mes-sage processing is inherently asynchronous, which further decouples the components.

One of the key principles that CuteLoop intends to base its development work on is to foster the usage of open systems and standards wherever possible. Therefore, the JBI specification repre-sents a good groundwork to be studied and analysed in order to see how the CuteLoop system architecture can be specified in a standardised manner. Particularly, one of the most prominent JBI implementations, the Apache ServiceMix, should be considered.

2.1.2.5 Apache ServiceMix

ServiceMix is an open-source and standard based ESB, based on the JBI specification, which combines the functionality of both, SOA and EDA, to achieve an agile enterprise ESB, and to facilitate the development and deployment of composite enterprise applications [ServiceMix08]. Thus, ServiceMix provides a fundamental feature foreseen in CuteLoop, which is to support the interoperation of services according to the SOA principles, and at the same time allowing these services to operate in an event-driven way. This means that services connected to the ServiceMix bus are completely decoupled and that they listen to the bus for service requests. Furthermore, ServiceMix supports interactions based on events that can occur both internally or externally to the ESB.

The fact that ServiceMix is based on a standardised specification is another important feature since it allows flexibility, reuse and protection from technology changes (i.e. it protects invest-ment). For instance, it allows the support for any component, as long as it conforms to the JBI standard, which can not only interoperate with each other and external applications, but can also easily be replaced with alternate components that provide the same of enhanced services. Figure 7 depicts the ServiceMix architecture, illustrating the relationship between the framework and JBI.



BPEL XSLT Rules Scripting

SOAPSystems

FileSystem

JCAResources

LegacyApps

ServiceMix Enterprise Service Bus

JBI Services

JBI Binding Components

BPEL XSLT Rules ScriptingBPELBPEL XSLTXSLT RulesRules ScriptingScripting

SOAPSystems

FileSystem

JCAResources

LegacyApps

SOAPSystemsSOAP

SystemsFile

SystemFile

SystemJCA

ResourcesJCA

ResourcesLegacyApps

LegacyApps

LegacyApps

ServiceMix Enterprise Service Bus

JBI Services

JBI Binding Components

Figure 7: ServiceMix architecture (source: [ServiceMix08]).

At the same time, ServiceMix was developed under the umbrella of the Apache Software Foun-dation (ASF) that is perhaps, today, the most accredited community for the development of open-source solutions. In fact, ServiceMix intrinsically integrates with another ASF solution that is attractive and relevant with regard to what CuteLoop intends to develop, called ActiveMQ, which is an open source Message Broker and Java Message Service (JMS) provider, licensed, developed and distributed under the Apache emblem. ActiveMQ provides a very robust and flexible publish-subscribe communication mechanism based on the JMS specification [ActiveMQ08]. JMS defines a standard API for reliable Enterprise Messaging, providing a reli-able, flexible service for the asynchronous exchange of critical business data and events through-out an enterprise [JMS08]. ActiveMQ fully support the JMS specification and in addition it pro-vides support for many cross language clients and protocols such as Java, C, C++, C#, etc. Fur-ther, besides ServiceMix, several other ESB implementations, including Mule, rely on Ac-tiveMQ to provide its routing and message exchange functionalities.

2.1.3 Key RTD Problems

A major RTD challenge that is foreseen in the specification of the CuteLoop architecture is the structuring of the CuteLoop system so as to able to support some of the properties that are char-acteristics of complex systems. According to [Cast79], “a complex system is one whose static structure or dynamic behaviour is counterintuitive or unpredictable”. In this sense, complexity, which is generally considered as a branch of systems, has been used to address the emergence, adaptation, evolution, and self-organization of systems. In particular, it concerns the coupling and interactions of the parts within these systems in a non-linear fashion [Babaoglu06]. Hence, a complex system must be able to adapt, evolve and organize itself, from the static structure per-spective as well as from the dynamic behavioural aspect. Thus, the CuteLoop system can be considered as a sort of complex system, since it’s intended to support a massively distributed networked environment, for instance, one that can adapt, scale, evolve and change topology in a transparent way. Therefore, a big challenge is how to properly combine SOA, EDA and Agent technologies in a unified architecture in order to support these intrinsic characteristics of com-plex systems that is desired for the CuteLoop system. As an example, the architecture must be designed in a way such that the resultant system can transparently support scalability, i.e. that the engagement of new applications or components into to the network does not disrupt the existing environment (e.g. causing unexpected degradation or failure of existing applications).



A special case of this problem is the successful combination of SOA and EDA, in a way that allows one to take advantage of the features of each approach to satisfy CuteLoop requirements. For that, one must clearly define the role that each approach should play in the unified architec-ture. For example, concerning the adaptability aspect of the CuteLoop system, there should be made available mechanisms that allow the adjustment (if possible dynamic) of the level of cou-pling required for given interaction models, as the full decoupling may not be desirable in some situations (e.g. for security reasons). Hence, in some cases the command-and-control SOA style may need to be enforced over the full decoupled interaction style of EDA, which raises the need for mechanisms to balance the level of coupling. This means that the CuteLoop system must some how permit not only oblivious communication, but also direct interactions between the users of the system.

Yet, as mentioned before, CuteLoop intends to support the usage of diverse “Networked De-vices” in the context of the integrated real-time enterprise. In this sense, a key challenge for the unified Event-Driven SOA architecture, besides connecting heterogeneous applications, is to provide multi-channel access to the CuteLoop functionalities, via multiple interacting devices, such as hand held devices (e.g. mobile devices, PDAs, etc. ), and over a variety of network pro-tocols like Internet, WI-FI, UMTS, GPRS, GNSS, and so on. For instance, the CuteLoop archi-tecture must be designed in such a way as to route service interactions through these diverse proto-cols, and to transform from one protocol to another where necessary. Still, with regard to the routing of messages, several types of routing algorithms must be supported, such as content-base, topic-based and rule-base routing.

Another problem that should be tackled is the lack of standardisation in the EDA world, espe-cially what standards for describing and exchanging events are concerned. As mentioned before, some efforts in this direction are being performed by the Web Service community, but there still stands the question on whether Web Services is the best technology to implement EDA. Still, most of the standards are not being widely used, especially in production environments, since they need to be further validated. Currently, EDA application use unstructured information to exchange events, and there-fore, mostly simple event types like alerts or acknowledgements are used.



2.2 Event-Driven Agents

Chapter 2.1, Architectures – Combination of EDA & SOA described the general architecture, as well as the overview of event-processing and service fundamentals relevant for CuteLoop. In turn, chapter 2.2 focuses on event-driven aspects, highlighting the role of the multi-agent system in the proposed architecture, as well as presenting multi-agent systems state of the art and key RTD problems which must be solved in order for the suggested solution to be viable.


CuteLoop intends to have loosely coupled actors cooperate in order to have distributed, but autonomous, control over business processes. The innovative interactions which are envisioned are optimally performed by using an approach which takes the best out of two worlds - Event-Driven Architectures and Service-Oriented Architectures on the one hand, and multi-agent sys-tems on the other hand. This approach has led to the identification of event-driven agents as op-timally suited for the task at hand.

From a generic point of view, event-driven agents have been identified as (semi)autonomous entities which consume events (i.e., detecting and/or processing various events) and propagate the results (notifying subscribers which have opted to be notified of the detected event, initiating certain actions, and so on). In the context of CuteLoop, event-driven agents are perceived as enti-ties which monitor events produced by various devices (PDAs, smart phones, active tags, work-stations, etc), process them (in a simple or complex way, as will be seen later in detail), and then send them to subscribers which have opted to be announced about the events.

Like mentioned above, the proposed architecture is based on a combination of Event-Driven Architectures and Service-Oriented Architectures. In an Event-Driven Architecture (EDA), the stages of processing are the following: important events which occur within the scope of the sys-tem are generated (by event generators, which will usually be services, or RFID tags reading interfaces), sent to the event processing engine (which evaluate events using the defined event processing rules), and then published to all interested parties (subscribers, which do not necessar-ily need to be human users). The subscribers, in turn, make decisions based on the received event notifications and act upon them.

The most relevant features of an EDA, in this context, are its extremely loose coupling and asyn-chronous information flow. In the frame of the project, it is considered that a multi-agent system would be the best choice for introducing these features. Agents would offer, on the one hand, a loosely-coupled, asynchronous publisher-subscriber architecture, while their mobility aspect5 could reduce the overall network load of the system (by moving agents, which are relatively small sized entities, to the source of the data, instead of sending the data to the agent to be proc-essed). (Pre)Processing data close to its source is an important principle in highly distributed systems, where communication bottlenecks are an issue. Especially in a system like the one en-visioned, where limited memory devices, with variable (or, at least, not guaranteed) access to network, are planned to be used, this might prove useful. Agent mobility is also a factor in de-creasing processing time (by doing the processing in situ as explained above and eliminating in this way the roundtrip of request/response), thus bringing the system’s behaviour closer to “real

5 Agent mobility can be exhibited in two ways: by migration – moving the agent instance to another point in the

network, or by cloning – making a copy of the agent instance and moving it to the destination point in the net-work.



time” processing. Furthermore, the resources of limited memory devices are also better used in this way, saving processing power for situations which strongly demand it.

Another feature of multi-agent systems is their scalability. The loose coupling of such a system would enhance its scalability, a very important feature in the envisaged application scenarios (a typical RFID event processing system, in the context of food industry, is expected to be able to perform the reading of hundreds and thousands of RFID tags in a changing environment).

The purpose of the multi-agent system in CuteLoop is the networking of enhanced RFID-based systems. To fill in all the niches in the system of event-driven agents considered (i.e. taking into account the event-processing stages previously described and whose functionalities must be cov-ered), the following categories of event-driven agents have been proposed, in light of the consid-erations above: − monitoring agents, wrapper agents: monitoring agents represent the “first line” of the

EDA. They consume events directly from the event generators, namely services. A similar processing takes place in cases when the event source is, for instance, a legacy system, and it must be “wrapped” so as to offer a more standardised interface to the CuteLoop system. In this case, the so-called wrapper agents are used. From the event processing point of view, the sequence of activities in which monitoring and wrapper agents process the re-ceived events is known as simple event processing.

− negotiation agents: they resemble monitoring agents, but at the same time perform some basic filtering on the consumed events before forwarding them to the event processing en-gine. This process is known as event stream processing.

− event processing agents (EPA): a subset of the general group of event-driven agents, the event processing agents form a distributed event-processing engine (i.e. event broker, see also Figure 1 in Chapter 2.1.1.1). They use event processing rules to deal with the “busi-ness logic” by processing received events. Management agents are a particular type of event-processing agents. They are the ones responsible for aggregating all received events and sending them to their corresponding subscribers. EPA deal with events at the level of complex event processing. This type of event processing is supported by the management agents as an intermediary – enabling negotiation/ monitoring/ wrapper agents to work to-gether in order to recognise patterns of simple events and generate, thus, a complex event.

Figure 8 below illustrates the high level interconnections which will exist between the described agent types, as well as the general envisioned architecture.



Event ProcessingEngine


Monitoring Agent

Monitoring Agent

Monitoring Agent

Monitoring Agent

SubscriberSubscriberPDA

SubscriberSubscriberPhone

Wrapper Agent

Wrapper Agent

NegotiationAgent

NegotiationAgent

Monitoring Agent

Monitoring Agent

EPA: Management

Agent

EPA: Management

Agent

EPAEPA

EPAEPA

EPAEPA

EPA: Management

Agent

EPA: Management

Agent

event

event

event

event

event

event



Monitoring Agent

Monitoring Agent

Monitoring Agent

Monitoring Agent

SubscriberSubscriberPDA

SubscriberSubscriberPhone

Wrapper Agent

Wrapper Agent

NegotiationAgent

NegotiationAgent

Monitoring Agent

Monitoring Agent

EPA: Management

Agent

EPA: Management

Agent

EPAEPA

EPAEPA

EPAEPA

EPA: Management

Agent

EPA: Management

Agent

event

event

event

event

event

event

Figure 8: General overview of the envisioned CuteLoop event-driven agent system.


Starting from the requirements imposed by the envisaged CuteLoop architecture, a number of significant agent frameworks have been investigated. The most important criteria considered for evaluation are agent mobility, event processing related functionalities, support for mobile de-vices, security and white/yellow pages services for naming and remote identification. From the existing frameworks, a preliminary study has led to the selection of three of the most influential and promising ones for the CuteLoop project objectives: JADE, Cougaar and OAA. These will be evaluated in detail.

JADE6 (Java Agent Development Framework) is an open source, Java-based software frame-work which simplifies the creation of agents complying with the FIPA communication model (agents interact with each other by means of sending ACL – Agent Communication Language – messages). JADE allows the “customisation” of the created agents with various behaviours, which explicitly implement the agent’s tasks, or actions that the agent shall perform. An agent can have multiple behaviours running at a certain moment of time. The types of behaviour tim-ing present in JADE are the following: one-shot (only executed once and then terminated), cyclic (executed forever, or at least as long as the agent to whom it belongs is running), composite (made up of child behaviours which are scheduled according to a certain policy), sequential (made up of behaviours which are executed in a sequential fashion), parallel (made up of behav-iours which are executed in a parallel fashion), finite state machine (a composite behaviour where child behaviours are executed corresponding to a finite state machine defined by the user), waker (a one-shot task which is executed only once after a certain timeout has elapsed), and ticker (executed cyclically at a given frequency).

The JADE framework also offers naming functionalities. A so-called “yellow pages” service can be used and which is enabled by the Directory Facilitator agent; also, a “white pages” service is offered, accessible by using the Agent Management System (AMS), which maintains a list of agents’ identifiers and their states. Registered agents can thus be found by querying Directory

6 see JADE website http://jade.tilab.com/ for information and download of the open-source platform.



Facilitator. Mobility of agents is fully supported by the JADE framework, with both moving and cloning an agent available for the user.

These behaviours can become very useful in the context of the CuteLoop project; for instance, monitoring agents need to perform event-driven functionalities such as the reading of an event source cyclically (the event sources envisioned are usually non-agent entities, so the monitoring agents cannot rely on the event source sending an ACL message which they can passively re-ceive and process; the monitoring agents will have to actively and repeatedly read the output of an event source in order to determine whether an event has occurred). Also, the implementation of a negotiation agent used in event stream processing will be supported by customising the agent with a finite state machine behaviour, which enables the negotiation agent to have a more complex reaction to received messages. Waker behaviours can be successfully used, for instance, in situations where a monitoring agent is following the execution of a certain payment within a certain amount of time: the monitoring agent is “woken up” when the deadline for the payment has passed and the lack of a “payment received” event will indirectly signal to the monitoring agent that the money has not been transferred.

The JADE messaging subsystem has been tested for performance and scalability [Vitaglione02], and has been found to perform within the range of Java RMI, for the considered test environ-ments.

JADE is available, through its JADE-LEAP add-on, for mobile devices such as PDAs or smart phones. This is a very useful feature for the envisioned CuteLoop agents, as it is expected to de-ploy them on various mobile devices. However, it must be noted that some limitations exist in this situation, such as, for instance, lack of agent mobility support in the case of using MIDP (Mobile Information Device Profile).

The JADE security add-on allows, among others, the authentication of users (using the JAAS API); agent permissions (agents allowed to create/terminate other agents, for instance); signing and encrypting the ACL Messages exchanged by agents. For the CuteLoop system, security is a highly important aspect, so having at least the basic mechanisms working “out of the box” within the used agent framework is a useful feature. An implementation of persistence in JADE exists in the form of an add-on for agent persistence, but, as of the time of writing, it does not seem stable enough or very well documented.

Within JADE, connecting agents to non-agent entities is not a highly flexible operation. Agents reading and doing various other active operations with non-agent entities is not an issue, since agents are basically Java classes and, as such, they can do anything that a Java object can. How-ever, external (non-agent) entities cannot connect to agents so easily. A special agent must be used (an instance of the “JadeGateway” agent class), which acts as a blackboard for agents and non-agent entities to post their inquiries/messages. This might potentially lead to a bottleneck in the system, especially in the case of CuteLoop where the connections between the multi-agent system and the non-agent parts of the system are expected to be multiple.

JADE also offers a very valuable CuteLoop feature: agents’ integration with web services. This is done by using the WSIG (Web Service Integration Gateway). This JADE add-on provides support for various WSDL2ACL/ACL2WSDL connection situations, such as: agents acting as web service clients; web services published as JADE agent services (and which can be found using the Directory Facilitator, the web service being registered with the WSIG UDDI); agents can even be published as web service endpoints. There are some limitations, though. WSIG is currently designed to work with JADE over J2SE, and has not been yet tested (according to the JADE documentation as of its current status) with the JADE LEAP add-on.



Cougaar7 (Cognitive Agent Architecture) is an open source, Java-based framework which en-ables the user to create distributed and agent-based applications. Cougaar can integrate with the above-mentioned JADE container and also with other, non-agent containers (such as Spring, J2EE). Within CuteLoop, the agents will have to communicate and otherwise interact with vari-ous non-agent entities within the system; having by default the basic ability to connect in a con-figurable way the multi-agent system to other containers is definitely an advantage. Cougaar agents also exhibit mobility, being able to migrate between nodes and even across hosts. One of the most important features is the framework’s high modularisation degree, evident in its flexi-bility of working with plug-ins and the general customisability of the developed components.

Agents developed with this framework use a blackboard-type asynchronous messaging model which uses classic publish-subscribe. The message transport protocol used by default is Java RMI, but support for JMS, IIOP and HTTP is included. Other aspects such as security and com-pression can be configured by adding various plugins to the default configuration. The highly customisable aspect of Cougaar makes it a valuable candidate for CuteLoop, where agents will have to exhibit a high degree of heterogeneity and be able to run in various environments.

Furthermore, the framework offers naming-related services: “white pages” service which maps agent identifiers to network addresses. This functionality mainly supports the message transfer protocol, and it focuses more on relatively rapidly changing names in parallel namespaces rather than relatively slowly changing names in a universal namespace [Helsinger04]. Another offered functionality is a “yellow pages” service, which is a directory service supporting attribute-based queries. Like in the case of JADE, this service allows agents to register themselves, giving their own attributes, and search for other agents.

Cougaar also offers some support for mobile devices deployment. Cougaar Mobile Edition (CougaarME) runs on the Java Micro Edition CLDC (KVM) virtual machine, and as such it has inherited some limitations of the KVM when compared with the standard architecture. However, CougaarME has been designed for as much as possible seamless interaction with Cougaar enti-ties. This becomes apparent when looking at the naming services (for instance, normal agents can act as name servers for CougaarME agents, with a hierarchical naming scheme), or at the task handling approach (a task can be allocated to a CougaarME agent from within any normal Cougaar agent).

The framework has a very high robustness degree. Unexpected loss of agents can be coped with, by using load balancing. Also, security is very well represented, on the one hand, by offering features directly implemented in Cougaar, such as message signing and encryption functionality, and on the other hand by allowing the integration with various state of the art, standard security measures. Additionally, Cougaar uses the Tomcat servlet engine, which supports SSL security (among other options).

Through its “WebServicesService”, this framework also allows components to register a WSDD (Web Services Deployment Descriptor), in order to be able to receive remote Web Service calls. This is one step in the direction of the agent-to-webservice translation necessary for the envi-sioned CuteLoop interactions. However, the implementation does not seem to be (as of the status at the moment of writing) as advanced as that of JADE’s WSIG.

OAA8 (Open Agent Architecture) is a software framework which can be used to integrate het-erogeneous software agents (which form a community) in a distributed environment. At the core

7 see Cougaar website http://cougaar.org/ for information and download of the open-source architecture. 8 see OAA website http://www.ai.sri.com/~oaa/ for further information and providing the download of the frame-

work.



of OAA lie two concepts: distributed cooperation and high-level communication. Within the OAA, agents communicate using a specific Interagent Communication Language.

More relevant for the objectives of the CuteLoop project, OAA agents have the ability to use so-called triggers, which allow the agents to persistently monitor events and then act upon the trig-ger condition becoming true. OAA uses the “publish-subscribe” concept implemented as fol-lows: the Facilitator agent enables the performing of the “yellow pages” service, knowing details about the registered agents (i.e., what tasks they can perform). When a requesting agent needs a task to be solved, it does not need to know which agents can perform this – it only needs to pub-lish its request with the Facilitator, and the Facilitator will find the best match to perform the requested task. The “cooperation among services” philosophy which underlies the OAA agent community can be thought of as very useful for the CuteLoop objectives. Agents which monitor certain events need not be always the same, but could change depending on the particular context of the occurred event; in some cases certain agents might be better suited to deal with the task associated to an event, while in other cases certain other agents might be more appropriate.

Furthermore, a big advantage of the OAA framework, in the sense of its applicability, is the vari-ety of languages which can be used to write agents, the most notable being Java, C, C++, Prolog, Perl and Visual Basic.



Based on the analysis of the three agent frameworks above, the following Table 1 is presenting an overview of the most relevant criteria for compar-ing the frameworks in the scope of the CuteLoop project. Table 1: Comparative table of existing significant agent frameworks.

Framework License Naming Service

Agent Mobility

Event-processing related functionalities

Scalability Mobile devices support Security Particular

features

JADE LGPL

Yes (Agent Man-agement System with agent identi-fiers + Directory Facilitator)

Yes (migration / cloning)

Standard function-alities include cycli-cal reading of a source’s output

Yes (studied for JADE messag-ing)

Yes (Jade-LEAP add-on), with some limitations on standard functionality

Yes ACL2WSDL & WSDL2ACL support

Cougaar

Open source, modelled after the OSI approved BSD License9

Yes Yes (migration) N/A

Yes (more than 1000 agents over more than 100 hosts)

Yes (Cougaar MicroEdition) Yes

Highly modular-ised implemen-tation

Open Agent Architecture LGPL Yes (Facilitator) No Yes (Triggers) Suggestive tests

N/A No No

Multiple lan-guages avail-able for agent implementation

9 see http://www.opensource.org/licenses/bsd-license.php



2.2.2.1 Conclusions

While studying the state of the art in multi-agent system frameworks, it has been noticed that there are no agent frameworks which would offer the kind of “event processing agents“ expected in the CuteLoop project by default, and which would also cater to all of the requirements pre-sented in section 2.2.1, namely agent mobility, event-driven behaviour, support for mobile de-vices, bidirectional interfacing with web services, to name the most important. Thus, event-processing agents will have to be developed specially for the CuteLoop needs and requirements, taking into account the missing features and the characteristics which need some customisation to be in line with the expected functionality of the system (also see Key RTD Problems in the following section 2.2.3).

However, it has been found that several key basic functionalities needed for the envisaged Cute-Loop agents can be found in some of the agent development frameworks which have been inves-tigated: mobility, scalability and basic security mechanisms, as generic features, are present in two of the presented frameworks (JADE and Cougaar). Other two frameworks (JADE, OAA) offer functionalities which are the basic foundation of event-processing entities – reacting to events and performing customised, cyclic behaviours. What the support for deployment to mo-bile devices is concerned, it appears that, out of the considered frameworks, JADE and Cougaar offer a real, usable implementation.

The study and evaluation which was performed has led to the conclusion that JADE and Cougaar are the most promising agent framework candidates for the requirements of the CuteLoop pro-jects.


Identifying the necessary requirements for implementing the event-driven agents as envisioned for the CuteLoop system has helped crystallise some of the technical aspects involved. The study of agent frameworks state of the art has shown the subset of features which are achievable, and has also exposed the required characteristics which are not (fully) implementable when building on the frameworks in their current state. These steps have been crucial in identifying RTD issues which are still to be solved in order to achieve the desired functionalities, such as better scalabil-ity, improved and customised security, the connection between the agent runtime environment and the service runtime environment, as well as certain particular problems related to specific hardware aspects – these issues will be discussed in the following parts.

While multi-agent systems are usually easily scalable in the test environments where they have been tested, they haven’t been applied in real industrial environments for very long. Especially in a context where a high number of RFID tags are set to be monitored by agents, a scalability pla-teau is possible to be reached from a certain size of the system upwards. The scalability problems might manifest at various levels: the number of agents could become too much for the system to handle; the communication with agents deployed on mobile devices with limited memory could create bottlenecks; in some cases, limitations will be stemming from the used frameworks’ own limitations (for instance, the blackboard model of agent-non-agent interaction in JADE discussed previously).

Agent mobility is likely to be hindered by firewalls, various network limitations, and so on. In certain cases (firewalls, for instance), this problem could be attacked “at the source”, by enforc-ing a more flexible filtering in the firewall. However, this is likely to make the network behind the firewall more vulnerable, so it is not an optimal solution and should only be considered as a last resort, if circumvention of this issue can somehow be made possible in another fashion. A



compromise must be found between limiting agent mobility and potential network exposure and vulnerability. In a more indirect way, a robust fallback mechanism is needed for the event-driven agents, in order to allow a greater flexibility with respect to data losses (robust handling of events not published to a waiting subscriber, for instance). This implies using mechanisms such as persistence (e.g., saving agent’s states), message redundancy, multiple communication chan-nels, and so on.

A similar security-related aspect, but working in the “opposite” direction, is the problem of mak-ing certain that the agents are not overstepping their boundaries; that is, not accessing data they are not meant to see, for instance. This is an issue especially in the expected setting of CuteLoop, where agents will, presumably, be deployed on mobile devices which store or have access to sensitive information. Problems could appear either in a passive, unintended way, but, more im-portantly, this aspect could be exploited for malicious purposes. In such cases, maintaining data integrity and performing a certain degree of authentication are indispensable for agents deployed in a potentially insecure environment.

The definition of the gateway between the agent runtime environment and the service runtime environment poses some technical problems itself: agents will have to act as service clients which actively pull information from the services, or will have to be exposed as web services themselves. Even though a degree of support for doing this exists in some of the surveyed frameworks, a certain amount of adapting and/or extending the standard solutions to the necessi-ties of the CuteLoop project will be required.

A particular problem regarding bottlenecks and various other communication problems appears because of the different natures of existing means for connecting to the internet. Thus, for in-stance, one aspect which must be taken into account when connecting to the internet through various solutions (like UMTS – Universal Mobile Telecommunications System) is that a certain degree of volume optimisation is performed on the transferred data, which could pose some in-teroperability problems within the community of event-driven agents deployed on mobile de-vices which connect in different ways to the internet.

For the deployment environments considered in the CuteLoop project, short processing times and quick reactions to events are desirable. A compromise between agent mobility and volume of processed data must be found in every situation (introducing an adaptive aspect of the multi-agent system). Basic context-aware behaviours must, potentially, be considered – for instance, monitoring agents which, depending on the sensitivity of the data involved and its size, will mi-grate to the source of the monitored events or not. Another example would be situations in which the decision for migrating the agent is taken dynamically, based on the network load at the mo-ment.



2.3 Security


A Security Architecture in support of the CuteLoop technologies seeks to ensure a level of in-formation security consistent with the business needs and IT strategy of the extended supply chain enterprise. A successful Security Architecture provides a blueprint to the supply chain or-ganisations involved that articulates how the business requirements can be met in an effective and consistent manner. Security requirements are substantially cheaper and more effective when they are designed into an application, or better still, the underlying technology infrastructure at the start. It’s for this reason the CuteLoop project is structured such that security requirements are identified at the requirements phase of the project and justified, agreed and documented as part of the overall conceptual specification of the CuteLoop technologies.

There is a need to develop and deploy trust and protection standards as part of the CuteLoop technologies and to communicate security requirements to supply actors to ensure that sensitive information remains protected. Traditional security is the management of risk. This involves looking at the information being protected, the threats to the system based on the environment and the security objectives of the system. Appropriate security mechanisms and management controls are then developed and put into place to address these threats.

The planning and implementation of a security infrastructure supporting cooperation and infor-mation sharing along an extended supply chain enterprise covers a wide range of processes and technologies. To be successful a number of key elements must be integrated and addressed by the CuteLoop partners: − controls should be a balance of procedural, management and technology measures. Further,

the selected measures should complement one another at all levels − security measures should reflect both the working practices of the organisation and the

controls required with the minimum possible effort and impact on the users of the system − controls should meet any constraints imposed by the current technical infrastructure (in-

cluding operating systems and networks) and be capable of supporting any planned migra-tion programme

− measures need to be defined correctly for each operating area that both complies with the organisation's standards and meet local business and operational needs

− staff involved at all stages of the process need to be identified and equipped to meet their defined responsibilities for managing security

− procedures and practices need to be documented to allow the successful definition, imple-mentation, management and long term support of the measures.

All of these areas need to be considered to provide a minimal yet balanced set of security mecha-nisms and controls. If each of these areas is not covered in equal depth the overall security of the CuteLoop system will be lowered to the weakest mechanism or control.

The model the CuteLoop project will utilise is Prevent, Detect, Respond. Prevention mechanisms include hardening operating systems, using existing or third party access control mechanisms, and establishing control zones for various information assets. Detection mechanisms include intrusion detection technologies and audit processes. Response mechanisms are the Incident Re-sponse and Business Continuity processes. Not all attacks are preventable, but identifying and responding to attacks is essential and having such facilities builds greater trust amongst potential users within the food and construction industries.



The task of developing a security infrastructure which effectively and consistently applies secu-rity principles and controls has many challenges including: − lack of a comprehensive set of baseline requirements for security along supply chains − lack of a widely accepted security design or methodology along supply chains − complexities of coordinating security specifications amongst vary different types of supply

chain actors (i.e. SME producers, large retailer, mid-size logistics/transport, individual craftsman)

− integration of security mechanisms within the several underlying existing system architec-tures found amongst supply chain actors.

Technologies that are available today that can provide a basis for the CuteLoop partners to ad-dress these challenges are described in the following sections.


The CuteLoop project will utilise existing standards for addressing security within the CuteLoop SOA. The project will utilise a security methodology based on ISO 17799, A Code of Practice for Information Security Management, which is an internationally recognized set of security best practices.

ISO/IEC 17799 specifies guidelines and general principles for initiating, implementing, main-taining, and improving information security management in an organization. The objectives out-lined provide general guidance on the commonly accepted goals of information security man-agement. ISO/IEC 17799 contains best practices of control objectives and controls in the follow-ing areas of information security management: − security policy − organisation of information security − asset management − human resources security − physical and environmental security − communications and operations management − access control − information systems acquisition, development and maintenance − information security incident management − business continuity management − compliance



EnterpriseSecurityStrategy


CorporateSecurityPolicies


BusinessLevel SecurityRequirements


CurrentEnvironment

CurrentEnvironment

Security Design Objectives / Security Architecture Objectives

Security Dom

ains(Zones of control)

Security Architectural Decisions

Product SelectionNodes

ComponentsSecurity Subsystems

FunctionalO PERATIONALOperational

Risk Assessm

ent

Counterm

easures

INPUTS(Utilizing the view from: ISO 17799, ISO 7498-2)

SecurityFunctional

Design

Reference Standards and Architecture(View from: Common Criteria ISO 15408, ISO 7498-2, ETC)







CurrentEnvironment

CurrentEnvironment

Security Design Objectives / Security Architecture Objectives

Security Dom

ains(Zones of control)

Security Architectural Decisions

Product SelectionNodes

ComponentsSecurity Subsystems

FunctionalO PERATIONALOperational

Risk Assessm

ent

Counterm

easures

INPUTS(Utilizing the view from: ISO 17799, ISO 7498-2)

SecurityFunctional

Design

Reference Standards and Architecture(View from: Common Criteria ISO 15408, ISO 7498-2, ETC)

Figure 9: CuteLoop Security Methodology Overview.

The control objectives and controls in ISO/IEC 17799 are intended to be implemented to meet the requirements identified by risk assessment, which, in the CuteLoop project, is embedded within the requirements capture activities involving the analysis of the various scenarios, use cases, actors, and roles within extended enterprise supply chains for the food and construction industries. ISO/IEC 17799 is specifically intended as a common basis and practical guideline for developing organisational security standards and effective security management practices, and to help build confidence in inter-organizational activities.

Companies participating in extended enterprise supply chains need trusted technologies that pro-vide security and which are as flexible and adaptable as their supply chains. Additionally, it’s important that CuteLoop utilises standards-based solutions to ensure that technology choices have long-term market viability and support. Security must not disrupt the supply chain or cause undue burden on and complexity to existing business processes. There are three major challenges that any security framework must address: − Authentication − Data protection − Access control

The current state-of-the-art in each of these areas is described in the following.

2.3.2.1 Authentication mechanisms

Authentication is the process of verifying that a peer entity in a supply chain communication, transaction or information exchange, is who or what it says it is. Authentication is a critical ele-ment of any security framework. Sending sensitive supply chain information across a network



without knowing who is on the other end can create serious risks, including exposure of sensitive supply and demand information to competitors and the risk of regulatory liabilities arising from improper disclosure of information.

Entity authentication today is implemented using three different types of mechanisms: • One-party authentication consists of the identified entity providing a proof of identity such

as a password known only to the entity and the system or network to which entry is sought. One example of use of this mechanism is a user logon to a system or application.

• Two-party authentication consists of mutual proof of identity through knowledge of shared information such as a cryptographic key. This mechanism is appropriate when, for example, two components of a distributed application establish a communication session in order to execute an application function.

• Three-party authentication involves establishing a trusted session between two parties through the certification of each to the other by a mutually trusted third party. Kerberos is one such mechanism. It provides flexibility for managing security in changing, heterogene-ous environments. As resources and users are added or their roles modified, their identities, authentication criteria, and certification parameters can be administered through the third party trusted security server.

A variety of authentication technologies are available in today’s information security technology market. Three well-established mechanisms for authentication are Public Key Infrastructure (PKI), Shibboleth and Kerberos. These are each described in the following.

PKI – Many companies today employ PKI technology to assign and manage verifiable virtual identities. PKI technology has several advantages, including a well-defined trust model and the ability to make users accountable for their actions. Existing web security protocols support PKI-based authentication. Web applications, including browsers, web servers, and web application servers, utilize this PKI support and provide users and enterprises with a rich set of tools for managing identities.

An organization's trusted root certificates can be distributed to all employees so that they can use the company PKI system. It’s also possible for CuteLoop deployment that trusted certificates are established specifically for supply chain cooperation and information sharing and are distributed amongst the actors, providing authentication for them to participate in the transactions and ac-cess product tracking data. PKI also includes facilities for Certificate Revocation List (CRL), an often neglected aspect of PKI systems and one that will be important due to the relatively short and fixed project lengths of cooperation within supply chain actors in the construction industry scenarios and use cases. The IETF-approved way of checking a certificate's validity is the Online Certificate Status Protocol (OCSP). Popular browsers like Internet Explorer and Firefox don't check for certificate revocation by default. The time lag for performing the checking could be one of the reasons.

X.509 is an ITU-T (ITU Telecommunication Standardisation Sector) standard for PKI in cryp-tography, which, amongst many other things, defines specific formats for certificates and the algorithm that verifies a given certificate path is valid under a given PKI (called the certification path validation algorithm).

Shibboleth – an open source implementation of federated identity-based authentication and au-thorization infrastructure designed to exchange information across realms for authentication and authorization. It provides a secure framework for one organization to transmit attributes about a web-browsing individual across security domains to another institution. In the primary usage case, when a user attempts to access a resource at a remote domain, the user's own home security



domain can send certain information about that user to the service provider site in a trusted ex-change. These attributes can then be used by the resource to help determine whether to grant the user access to the resource. The user may have the ability to decide whether to release specific attributes to certain sites by specifying personal Attribute Release Policies (ARP's), effectively preserving privacy while still granting access based on trusted information.

A service provider (SP) protects resources, while an identity provider (IdP) provides information about users from an organisation to service providers. When a user first tries to access a resource protected by a Shibboleth SP, they are redirected to a service which asks the user to specify the organisation from which they want to authenticate. If the user has not yet locally authenticated for that IdP, the user will then be asked to authenticate using any mechanism of that site's choos-ing. After the user authenticates, the Shibboleth IdP at the local institution generates a temporary reference to the user, known as a handle, for the individual and sends this to the SP. The SP can then use the handle to ask for attributes about this individual. Based on these attributes, the SP can decide whether or not to grant access to the resource. The user may then be allowed to access the requested materials.

Kerberos – an authentication protocol that allows individuals communicating over a non-secure network to prove their identity to one another in a secure manner. A suite of free software pub-lished by Massachusetts Institute of Technology (MIT) implements this protocol. Its designers aimed primarily at a client-server model, and it provides mutual authentication — both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks. Kerberos builds on symmetric key cryptography and requires a trusted third party. Extensions to Kerberos can provide for the use of public-key cryptography during certain phases of authentication.

Kerberos uses as its basis the Needham-Schroeder protocol. It makes use of a trusted third party, termed a key distribution center (KDC), which consists of two logically separate parts: an Au-thentication Server (AS) and a Ticket Granting Server (TGS). Kerberos works on the basis of "tickets" which serve to prove the identity of users. The KDC maintains a database of secret keys; each entity on the network — whether a client or a server — shares a secret key known only to itself and to the KDC. Knowledge of this key serves to prove an entity's identity. For communication between two entities, the KDC generates a session key which they can use to secure their interactions.

2.3.2.2 Data Protection

Data protection ensures that information cannot be intercepted or modified by unauthorized par-ties while it is in transit across networks or resident on storage media. Typically this is achieved by encrypting the transmission before it is sent, and decrypting it after it is received. Data integ-rity ensures data has not been changed, destroyed, or lost in an unauthorized or accidental man-ner. It usually implies that there are well-regulated procedures for creating, modifying, and delet-ing data. Data protection can be ensured at two levels. − Confidentiality - Data confidentiality provided by the transport protocol layer (e.g. SSL or

TLS) ensures that the data is visible only to the authorized sending and receiving parties. This ensures that communication is not compromised in transit. Such transport layer secu-rity is only effective while the transport session is active. This technology only ensures end-to-end confidentiality of the data while in transmission.

− Integrity - message integrity ensures that data has not been altered in transit and is from a verifiable authenticated source. Data can be secured even when not in transit, such as be-fore processing is completed.



Existing mechanisms for data protection are described below.

SSL (Secure Sockets Layer) / TLS (Transport Layer Security) protocol enables secure com-munication between applications over internet provides authentication and privacy at endpoint using cryptography. It involves 3 stages: Peer negotiation, Key exchange and authentication, Symmetric cyphers encryption and message authentication. This authentication can be made optional, but is generally required for at least one of the peers. The negotiation of a shared secret is secure: the negotiated secret is unavailable to eavesdroppers, and for any authenticated con-nection the secret cannot be obtained, even by an attacker who can place himself in the middle of the connection. The negotiation is reliable: no attacker can modify the negotiation communica-tion without being detected by the parties to the communication. TLS is based on the Secure Socket Layer (SSL) and one advantage of TLS is that it is application protocol independent. The TLS protocol runs above TCP/IP and below application protocols such as HTTP or IMAP. The HTTP running on top of TLS or SSL is often called HTTPS. The TLS standard does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left up to the judgment of the designers of protocols which run on top of TLS.

Secure Shell or SSH is a network protocol that allows data to be exchanged using a secure chan-nel between two computers. SSH encrypts all traffic (including passwords) to effectively elimi-nate eavesdropping, connection hijacking, and other attacks. Additionally, SSH provides secure tunnelling capabilities and several authentication methods. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if nec-essary. SSH uses the client-server protocol. An SSH client program is typically used for estab-lishing connections to an SSH daemon accepting remote connections. Both are commonly pre-sent on most modern operating systems, including Mac OS X, Linux, FreeBSD, Solaris and OpenVMS. Proprietary, freeware and open source versions of various levels of complexity and completeness exist.

PGP encryption uses public-key cryptography and includes a system which binds the public keys to a user name and/or an e-mail address. PGP supports digital signatures, message authenti-cation and integrity checking. The latter is used to detect whether a message has been altered since it was completed (the message integrity property), and whether it was actually sent by the person/entity claimed to be the sender (a digital signature). In PGP, these are used by default in conjunction with encryption, but can be applied to plaintext as well. The sender uses PGP to cre-ate a digital signature for the message with either the RSA or DSA signature algorithms. To do so, PGP computes a hash (also called a message digest) from the plaintext, and then creates the digital signature from that hash using the sender's private keys. The message recipient uses the sender's public key and the digital signature to recover the original message digest. He compares this message digest with the message digest he computed her/himself from the (recovered) plain-text. If the signature matches the received plaintext's message digest, it must be presumed (to a very high degree of confidence) that the message received has not been corrupted, either deliber-ately or accidentally. As well, since it was properly signed, it is very likely (to a very high degree of confidence) that the claimed sender actually did send it.

IPsec (Internet Protocol Security) is a framework for a set of protocols for security at the net-work or packet processing layer of network communication. Earlier security approaches have inserted security at the application layer of the communications model. IPsec is considered to be especially useful for implementing virtual private networks and for remote user access through dial-up connection to private networks. A big advantage of IPsec is that security arrangements can be handled without requiring changes to individual user computers. IPsec provides two choices of security service: Authentication Header (AH), which essentially allows authentication



of the sender of data, and Encapsulating Security Payload (ESP), which supports both authenti-cation of the sender and encryption of data as well. The specific information associated with each of these services is inserted into the packet in a header that follows the IP packet header. Separate key protocols can be selected, such as the ISAKMP/Oakley protocol.

MILS (Multiple Independent Levels of Security) is an architecture that addresses domain sepa-ration. The rigid process communication and isolation offered by MILS is seen mainly in ultra high reliability software applications. The central idea behind MILS is to partition a system in such a way that: 1) the failure or corruption of any single partition cannot affect any other part of the system or network, or, 2) each partition can be security-evaluated and certified separately, so no partition requires evaluation at a higher level than necessary for that function. MILS com-bines elements of the safety and security worlds. It draws upon FAA DO-178B Level A Safety technology and Common Criteria EAL7 Security technology to enable MILS Web and network services for mission-critical embedded and real-time systems, including high-assurance weapons, training and communications systems and command and control platforms. The principles and technologies behind these highly robust security protection mechanisms can also be applied to commercial or enterprise systems providing systems that can securely address and protect data from multiple domains simultaneously.

2.3.2.3 Access Control

Access control ensures that security-sensitive tasks are performed only by properly authenticated individuals who have also been authorized to perform them. When deployed properly, it limits or grants access to information based on predetermined rules. Access Control mechanisms have four major functions: − Using credentials provided by authentication mechanisms to determine the identities of

each party who tries to perform an operation − Consulting an identity management service to determine the roles or other authorities

granted to an identified party − Determining the sensitivity of the operation requested by an identified party − Consulting an access management service, which evaluates authorization rules defined by

the business to determine whether the identified party’s credentials, roles, and authorities allow that party to perform the requested operation, in light of its sensitivity

Access control technologies today are available to support multiple authentication mechanisms, allowing users to log in using a user ID and password, digital certificates, shared secrets, secure tokens, etc. Access control mechanisms for CuteLoop should also support the auditing of secu-rity events such as authentication and authorization events, including both successful and unsuc-cessful access to resources, password changes, and administration or management events. Some common access control mechanisms are described below.

Access control lists and security labels implement access control and enable authentication by defining and describing the kind and degree of access authorized to individual entities that are granted access to a system resource. Access control lists define what users can access which re-sources and specify what type of access is permitted each user for a particular resource. Types of permitted accesses include for example, read, write, and execute. Security labels classify re-sources according to an organization's security policy definitions, such as "proprietary", "unclas-sified", etc. To gain access to a resource, the user's authority must match the security label con-tents of the particular resource.

RBAC – One of the most challenging problems in managing large networks is the complexity of security administration. Role based access control (also called role based security) has become



the predominant model for advanced access control. RBAC was published as the NIST RBAC model and adopted as an ANSI/INCITS standard in 2004. Today, most information technology vendors have incorporated RBAC into their product lines, and the technology is finding applica-tions in areas ranging from health care to defence, in addition to the mainstream commerce sys-tems for which it was designed.

With role-based access control, access decisions are based on the roles that individual users have as part of an organisation or in CuteLoop an enterprise supply chain. Users take on assigned roles (such as producer, packager, transporter, warehouser, retailer). Access rights are grouped by role name, and the use of resources is restricted to individuals authorized to assume the asso-ciated role. The use of roles to control access can be an effective means for developing and en-forcing enterprise-specific security policies, and for streamlining the security management proc-ess.


The CuteLoop project benefits from an existing base of security technologies representing the state-of-the-art that can form a strong starting point for the research and development of new technologies that provide a secure environment for extended enterprise supply chain actors to exchange information, undertake trusted transactions, and cooperate to deliver better services to customers. However, there are many challenges facing the project. Some of the most significant RTD problems are the following: − The heterogeneous nature of supply chain participants in the food and construction indus-

tries makes the implementation of a common security framework extremely complex. Pro-viding mechanisms that are simple enough to be deployed by an SME, but effective enough to garner the trust of large food retailers will require new combinations of security technologies. Achieving interoperability of differing and largely independent security mechanisms each of which is suitable for the type of actor within the supply chain will be a major challenge.

− Many security mechanisms rely upon a central authority for authentication and access con-trol. Federated mechanisms provide a possible approach for CuteLoop but to date these have been quite complex to administer and probably beyond the capabilities of typical SMEs in the food and construction industry to handle. It’s possible that combining feder-ated security mechanisms with agent technologies to shield the SME user from the com-plexities of federated mechanism administration task might provide a way forward.

− Lack of information consistency will also be a major challenge in that the way information is stored and the ability to tag information for security and access purposes will vary from actor to actor within the supply chain. Providing a common set of procedures and access mechanisms will no doubt be a difficult and challenging area to research for the project.

− The supply chain actors have in place existing systems that represent substantial invest-ments and whatever security and authentication mechanisms are developed by the Cute-Loop project will need to work with several underlying existing system architectures found amongst supply chain actors. These may in fact impose conflicting approaches that will need to be addressed with higher wrappers and other tools that enable interoperability of different systems.

The challenges facing the project in developing a security framework to support extended enter-prise supply chains are substantial. However, there are several avenues that can be explored and substantial experience amongst the partners in addressing enterprise security and inter-enterprise security mechanisms.



2.4 Interaction Models


The modelling of interaction activities has various levels of technological and application orien-tation. Both involve interactions and the exchange of information. The technological orientation deals primarily with interaction between information systems, the application orientation with interactions between system actors; the two are partially overlapping. Interaction models in this chapter focus on the application part and the upper levels of technological considerations directly linked to it, as e.g. the delineation of data clusters, the interchange between these clusters, the interface requirements, and the organization of communication procedures. As such, it supple-ments the interaction discussions in previous sections.

The CuteLoop focus is not restricted on improving enterprise internal information and communi-cation needs. On the level of enterprises, decisions on the introduction of new technologies can build on simple cost-benefit calculations. Processes have to fit operational needs. However, be-yond this first level of technology developments the CuteLoop concept attempts to improve sup-ply chain and network operations. On this level, processes have to fit operational needs as well. In addition, however, processes involve interaction activities of actors that have to fit actors’ strategic interests. Furthermore, the process and interaction systems have to provide supply chain and network controls that assure a best balanced and broadly accepted consideration of interests of actors within the network without compromising operational needs.

As a consequence, the incorporation of new technologies and services follows a development path that involves several levels of agreements which, in turn, usually involve levels of increas-ing complexity. This development is supported by the development of reference models for the different levels which can demonstrate their net benefits without overstretching the compromise ability of those involved.

The reference models (application focused interaction models) would need to incorporate the following levels of development:

1. Reference models for enterprise internal processes

2. Reference models for supply chain processes

3. Reference models for interaction between actors

4. Reference models for supply chain management and control systems

These models complement the technology based interaction models but are crucial for opera-tional acceptance of new technologies and services in industry and the market.


Interaction models build on an infrastructure of processes, information clusters, communication interfaces, system actors and system users.

The infrastructure is determined by a variety of factors including technology, needs of actors, market forces, legal and other environments etc. As an example, the delineation of information clusters (or data bases) as one of the core infrastructural concepts is determined by



a) historical developments,

b) available technologies,

c) efficiency considerations in collection, storage, management, and use,

d) ownership and user rights,

e) legal and other regulations from system environments,

f) customs, and

g) particular interests of system actors and system users.

An existing infrastructure of information clusters represents a balance of considerations. The stability of the balance might be challenged by any changes in the determining factors as, e.g. the emergence of new technologies or changes in regulations or interests of actors. However, as any changes in infrastructure require investments in, e.g. time, equipment, training, or coordination activities, cost benefit considerations usually keep an existing system infrastructure that evolved from historical developments in place beyond optimality. This contributes to system stability and supports adaptations in system parts without principal changes in the system’s infrastructure. An example might be the incorporation of new technologies (as, e.g. RFIDs) in information collec-tion and use within a given system infrastructure of processes, data clusters, interfaces or system actors, etc.

However, if major changes in determining factors of any kind might allow the realization of positive cost benefit effects through changes in system infrastructure (e.g. changes in data base distribution and clustering, changes in communication activities, etc.), even if considering all investment needs, a new infrastructure with a new balance of considerations will eventually de-velop. The project may support to reduce the investment barrier and to facilitate the move to-wards improved processes.

The CuteLoop project builds on the utilization of new sensor (RFID) and communication tech-nology (satellite technology) for improvements in logistics processes. The analysis of the suit-ability of incorporating new technology into established systems, the identification of the poten-tial for new, improved system organizations and services or the identification of barriers and drivers for moving established system organizations towards new and improved alternatives and services all need to build on an analysis and understanding of the functioning and interrelation-ships in present interaction systems as well as on the potential for adaptations and changes.

2.4.2.1 Analysis and communication of interaction system

In complex system environments one needs different views to capture and communicate the complexity of interaction models. The views differ in aggregation and dimensionalities. The principal methods to capture the different views include the various modelling approaches within the UML modelling environment, network models, the supply chain SCOR® modelling ap-proach, process management modelling environments like sycat® and others as well as continu-ous and discrete simulation environments as exemplified by the EXTEND modelling language.

The UML modelling framework provides the basis on which all other modelling opportunities can build. The SCOR modelling approach contributes the link to the application environment. UML and SCOR, both provide a standardized environment which assures easy communication of results beyond the project boundaries. The SCOR modelling approach supports the formula-tion of chain reference process models for wider use.



For the analysis of process capabilities, deficiencies and the modelling of transparencies regard-ing user interests, the project could utilize the FMEA (Failure-Mode-and-Effects-Analysis) framework initially developed for quality management issues and the LCA (Life Cycle Assess-ment) approach which deals with a chain encompassing input-output analysis. The initial LCA approach with its focus on environmental issues has been greatly extended to incorporate all kinds of interests including social, economic, and other issues (e.g. SLCA etc.). The LCA ap-proach and its extensions are the dominant standard in capturing inputs and outputs of processes and their link to needs and objectives of system users.

2.4.2.2 System improvements through new technologies within existing system infrastructures

Improvements within existing system infrastructures concern improvements in information col-lection and communication efficiency through the utilization of RFID and satellite or similar technologies. The main approach is the identification of the appropriate positions and the clarifi-cation of cost/benefit consequences. However, this analysis has to be complemented by an analy-sis of potential new services that could be offered within the existing infrastructure and their ef-fect on the cost and benefit balance.

2.4.2.3 Development of new and improved system organizations

The introduction of new technologies opens opportunities for reaching new levels in efficiency, customer services and consumer support. The identification and evaluation of such opportunities can build on the utilization of the QFD (Quality Function Deployment) and BSP (Business Sys-tem Planning) methodologies as well as on benchmarking studies with developments in other sectors.

The QFD approach links opportunities with expectations and provides judgements on develop-ment strategies and the competitive advantage of new developments in comparison with present situations or potential alternatives. The BSP methodology, initially designed by IBM®, supports the identification and organizational positioning of fitting information clusters.

The results of QFD, BSP, and benchmarking analysis need to be embedded into the framework of factors that determine system acceptance (see above). Prototyping approaches on various lev-els of sophistication and their evaluation with system actors through discussions and experiments as well as simulation studies support the identification of suitable development alternatives as best compromise between conflicting interests that find acceptance and provide the necessary level of net benefit that could induce change.

2.4.2.4 Development of new or improved services

The generation of services builds on a match between needs and available service elements that could be combined to represent certain distinguished services. A service might represent a spe-cific sales support and build on service elements like the provision of certain information and/or of technology for information processing and communication, etc. In this discussion, we do not consider technical services but services that focus on needs of system actors. Furthermore, we will distinguish between

a) initiatives that improve existing services (e.g. through facilitating of data exchange, data de-livery or the search for suitable market partners) without inducing any principal changes in interaction behaviour or changes in system infrastructure and

b) new services that offer new opportunities and might or might not change the system balance.



For a service to be successful, it needs to match certain needs of potential users (actors), consider the quality and technological development level of service elements, the expected development in service elements with consequences for service quality and capability, the consequences for other actors in the system, and the gains in net benefits including gains in the enterprise’s com-petitive situation.

These aspects can be captured in model systems that build on traditional QFD (Quality Function Deployment Analysis) based analysis and extend it to cover consequences that reach beyond those directly concerned.


The key RTD problems relate to the relationships between system organization, system devel-opment, and technology.

New technologies have to be linked to fitting (feasible), optimal and ‘best for use’ organizational process, interaction, management and control systems. Solutions to this difficulty support the timely acceptance of new technologies and the utilization of their benefits. The multi-dimensionality of the problem makes it difficult to solve and requires the incorporation of differ-ent views and their integration into a ‘balanced’ solution approach. The analysis, modelling and simulation of chains and chain developments in a multi-dimensional scenario, a prerequisite for the identification of suitable solutions is not yet well developed and requires the incorporation of tools and approaches from a variety of disciplines. This requires the development and evaluation of a development framework which can be utilized within and beyond the project

A second problem involves the incorporation of system flexibility as a success factor. It is espe-cially the food sector which has to deal with increasing requirements in transparency and the provision of information to customers along the chain as well as towards consumers. A key word is sustainability. Emerging discussions on issues like ‘food miles’ and similar indicators involve future needs for increasing requirements on information transmission and communication. How-ever, the scenarios the food sector will have to face in the future are not yet clear. The competi-tion with bio-energy and other developments might change requirements on information and communication. It is to be expected that developments support the incorporation of new technol-ogy. However, the systems to be developed need to incorporate flexibility to be prepared for the future and to find acceptance in industry. The incorporation of flexibility in system models is a challenge the project will have to deal with.

Further details, references and examples of current solutions realised in the CuteLoop food and craftsmen applications scenarios are presented in Annex 1 in chapter 7.

Moreover, a wide range of research and application projects in Europe have been set up under the 6th and 7th RTD Framework Programmes. They tackle different application fields and different research targets. Some of these projects are listed in the Annex 3 in chapter 9, presenting those whose research areas are relevant for the CuteLoop project, specifically including projects participating in CERP10.

10 Cluster of European RFID Projects – CERP was initiated by the European Commission within the 6th Frame-

work Programme. The cluster comprises EU funded RTD projects related to the research challenges connected to RFID technologies. Its objective is to promote the exchange of information and to leverage the communica-tion between the European RFID research projects. CuteLoop is a member of the CERP.

CuteLoop 3 Enabling Technologies


3 Enabling Technologies

3.1 Traceability Services

As baseline for this analysis it is assumed that potential traceability services which are relevant for CuteLoop shall specifically focus on the interaction of actors along the supply chain, and not only be concerned about pure product characteristics stemming from only one link in the chain. Therefore, the analysis is giving a focus to “Chain Traceability”, which is related to the whole chain perspective and the potentials fully traceable products are providing to the actors along the supply chain.

3.1.1 General definitions of Traceability

The word “traceability” can have slightly different meanings depending on which context and which fields and industries the word is used in. We will mention a few definitions and references and also suggest which definition is most useful within the context of CuteLoop.

3.1.1.1 Traceability – ISO definition

«The ability to trace the history, application or location of an item or activity by means of re-corded identification. When considering product (…), traceability can relate to the origin of ma-terials and parts, the processing history, and the distribution and location of the product after delivery.»

3.1.1.2 Traceability according to the EU Food Law and regulation EC/178/2002

Being part of the EC/278/2002, the context of this definition is the food supply chain. It states that traceability is

«the ability to trace and follow food, feed, and ingredients through all stages of production, proc-essing and distribution»

The EU Food Law [EUFL] is obviously focused on food, but the definition can easily be ex-tended to non-food supply chains.

3.1.2 Levels of traceability

It is useful to distinguish between two main types of traceability. The two have different scopes, completely different challenges, use cases and tools associated. The two types are “Internal Traceability” and “Chain Traceability”.

3.1.2.1 Internal Traceability

Internal Traceability refers to traceability within one single step of a supply chain. For such a step to have “internal traceability”, the following requirements and conditions must be met: − The step must keep track of all received ingredients, raw materials in a way such that they

are able to link each such (received) unit into the first step of their internal process-ing/production chain.

− For each such received unit, they must keep records of whom they receive it from (their “suppliers”)



− They must record links between each step of their internal chain, such that it is possible to track back to the received raw materials which went into production

− The last step of the internal chain results often in a “production batch” from where finished products are made. These links (between the production batch and finished products) must be recorded

− Finally, they must record to whom (“their customers”) the finished products are sold and sent, possibly through intermediate transport etc.

Given the above, the result of internal traceability is that a company has control and records of how received ingredients and raw materials go into their internal production and finished prod-ucts, and they know from whom they received each raw material unit and to whom they sold/sent each unit of finished goods.

To be able to achieve the above, the company needs to use an identification system which uniquely identifies the units they trace and track, and the organizations they trade with.

Unique identification is one of the key challenges of any traceability system. Within the context of internal traceability, the uniqueness scope is inside the single company. As we shall see, this is not so for chain traceability, where the uniqueness scope is “the world and the set of all supply chains”.

The unique identification items associated with traceable units and organizations are often called traceability keys.

3.1.2.2 Chain Traceability

Chain traceability deals with how the units of trade are exchanged between the business partners in the supply chain. A system providing services related to chain traceability, needs to be able to trace across and through the companies in the chain – a completely different challenge than those faced by an internal traceability system.

Apart from this, chain traceability deals with the same basic challenges; the ability to associate unique identification with the traceable units and the organizations in the chain, and the ability to put links on the units when they flow from one step to the next in the chain.

Supply chains of today are truly global, and they often cross each other. A “crossing” means that some traceable unit originating from some chain enters another chain in full or in parts. To be able to trace and track successfully in such scenarios, it is necessary that the uniqueness scope for all involved traceability keys is truly global.

A globally unique identification system is therefore a key requirement within the field of Chain Traceability. In general, standardization together with agreed best practices between the chain participants are two key requirements for successful chain traceability.

Other terms commonly used to denote Chain Traceability: − External Traceability − Global Traceability − Whole Chain Traceability

3.1.3 Market Drivers and Players

The main and still important driver for traceability is related to food safety and the need to do effective recalls in case of food incidents in the supply chain. Good traceability systems can help



to quickly identify possible incident causes and to isolate the possible implications, hence reduce the costs involved and the loss of market reputation for the brand owner.

But other market drivers have slowly gained more momentum. Common to many of these is the fundamental observation that

“internal and external traceability can be used as a tool to get access to very useful information about the products flowing through the supply chain”

Such information has not been easily accessible up to now. The reason is that in a typical B2B scenario, as much as 80% of the information following a product/delivery may get lost in each step along a long supply chain11.

An effective chain traceability system will let the information provider (i.e. “suppliers”) submit the above mentioned information to the system rather than directly to the receiving party, while the receiving party only needs to confirm the receipt of the products and provide information to the system according to what was described as requirements for internal traceability in section 3.1.2.1. If all steps along the chain do the same, the traceability system could potentially provide transparent access to vast amount of information both upstream and downstream from any point in the chain.

There will be a number of both generic and specific applications that could utilize such informa-tion, and there will be different target groups for such applications. The following Figure 10 groups some drivers for traceability and indicates some of the important driving forces behind.

TraceabilityTraceability

Product CharacteristicsTaste, Price, Appearance, Organic, Fresh,

GMO, Sustainable, Carbon Footprint, Healthy, Packaging, Cholesterol, IUU, Cold

Chain Integrity, Shelf Life Management, Counterfeiting, ..

Product CharacteristicsProduct CharacteristicsTaste, Price, Appearance, Organic, Fresh,



Product ComplianceLegal and commercial market access requirements

Product ComplianceProduct ComplianceLegal and commercial market access requirements

Brand ProtectionFood Safety, BSE, e-coli, Recall and Withdrawals

Brand ProtectionBrand ProtectionFood Safety, BSE, e-coli, Recall and Withdrawals

Brand ValueBrand ValueBrand Value

Governm

entsIm

porters

ProducersEU

& FD

A

Consum

ersR

etailers

NG

Os &

Industry O

rganizations

TraceabilityTraceability

Product CharacteristicsTaste, Price, Appearance, Organic, Fresh,



Product CharacteristicsProduct CharacteristicsTaste, Price, Appearance, Organic, Fresh,



Product ComplianceLegal and commercial market access requirements

Product ComplianceProduct ComplianceLegal and commercial market access requirements

Brand ProtectionFood Safety, BSE, e-coli, Recall and Withdrawals

Brand ProtectionBrand ProtectionFood Safety, BSE, e-coli, Recall and Withdrawals

Brand ValueBrand ValueBrand Value

Governm

entsIm

porters

ProducersEU

& FD

A

Governm

entsIm

porters

ProducersEU

& FD

A

Consum

ersR

etailers

NG

Os &

Industry O

rganizations

Consum

ersR

etailersC

onsumers

Retailers

NG

Os &

Industry O

rganizations

Figure 10: Traceability drivers and players.

11 A study conducted by TraceTracker in Norway in 2002.



3.1.3.1 Traceability on Gartner’s Radar

A strong indicator of an emerging market is a Gartner Industry Research report analyzing such a market. Such reports can be a first step in having a new Gartner Magic Quadrant defined. In June 2007 Gartner published such a study on the traceability market in Europe [Gartner07]. Some of the key findings were that:

1. it is necessary to focus on the challenges introduced by Chain Traceability (i.e. the whole chain perspective), and

2. tools are mostly in place, but will and commitment from the industry is needed to move forward

3. they recommend that food manufacturers prepare themselves for more enforcement of the EU Food Law [EUFL] by EU.

The report discusses and compares some traceability models and architectures without conclud-ing very much.

3.1.3.2 IBM Traceability Survey

Another strong indicator of a new emerging market happens when the big IT vendors like IBM, SAP, Microsoft and others identifies the market and starts to customize their offerings to the perceived needs of that market. While this has not happened to a significant extent yet, IBM has started a move that indicates that they see traceability as an opportunity for them. Last year the IBM Institute for Business Value [IBV] published a report named “Establishing Trust through Traceability”. The report is downloadable on the Internet [IBMETT].

The report concludes the findings from a consumer study conducted in the UK & US. Some key findings were (reproduced with permission from IBM): • Concerned: − 50% of U.S. consumers are more concerned about food safety today than they were two

years ago ... two out of every five (42%) have translated that concern into action, buying different brands today because they are looking for safer products.

− The majority (62%) of consumers don't believe the safety of food supply has increased in past two years.

• Distrust: − 39% of consumers fundamentally don't trust CP companies have their best interest mind

during a recall. − Fully three quarters (75%) of consumers do trust that the grocery store has their best inter-

est in mind during a recall. − More than 70% of consumers express limited trust in the environmental, and health and

wellness claims of branded food products. − 65% of consumers trust their primary grocery store to sell quality fresh produce that is

safe. − 63% of consumers trust the information their grocery store provides about the safety of the

food they sell. • Knowledgeable: − Approximately 60% of consumers are already more knowledgeable about the content of

food they buy (vs. two years ago), but 70% would like even more information about the source and content of packaged food products.



− More than 70% of U.S. consumers know the meaning of the terms "Organic" and "All Natural".

• Brand vs. Private Label: − Only 24% of consumers agree that branded food products are more likely to deliver bene-

fits claimed than private label (3/4 of consumers aren't seeing the benefit of buying branded products).

− The majority of consumers perceive the quality (55%) and safety (63%) of private label products as being the same as similar branded products.

The findings are similar to those found in other consumer studies, for instance research con-ducted by ECR Europe [ECR]. As an example of another such study, see [ECRTRA].

3.1.4 Traceability Architectures, Tools and Systems

Seen from a pure IT perspective, it may not be that difficult to design a model and a system which can be used to model internal traceability or even chain traceability. But as with any IT system, it should be easy to adapt the system to the real world processes the system tries to model. Unfortunately, traceability is an extremely complex and challenging issue as seen from inside the supply chain. Some challenges arise from: − vast differences in the level of IT sophistication and the use of IT tools among the trading

partners in the supply chain, − internal as well as B2B processes are often not sufficiently traceable, − little awareness and willingness to see traceability as an opportunity, − no chain is stronger than the “weakest” (i.e. – the “less sophisticated” and “less moti-

vated”) links, − little or no effective standardization in use with respect to

○ product identification, ○ B2B communication and procurement, ○ cross industry processes.

3.1.4.1 General Challenges

The specific challenges are many, but some are more important than others. The three challenges mentioned here are in fact requirements to be able to do effective traceability.

3.1.4.1.1 Traceable Processes

Both internal and external processes must be traceable. In short, a process is traceable if records are kept of relationships or links between inputs and outputs. In many industries, such links are not maintained even if the information is available. In other situations, the process itself has no distinct “start” and “stop” characteristics, making it difficult to create such links. A good exam-ple is a feeding silo at a salmon farming plant where feed is re-filled at top in a continuous man-ner.

It can often be expensive and impractical to change such processes in a way such that they be-come sufficiently traceable. The result can be reduced traceability at this step in the internal or external chain, or even no traceability at all.



3.1.4.1.2 Data Capture

If the processes were traceable, a traceability system needs to get enough data about the proc-esses and involved products to maintain the traceability records. Data will typically include, but not necessarily be limited to: − product identification, − link information, − party identification, − product characteristics, − process characteristics.

As discussed earlier, there may be big differences between the value chain participants with re-spect to their use of IT tools and process automation services. Some small companies may for instance still use pen and paper and keep their production and trading records in binders. On the other hand, even big ERP systems like Navision and SAP may turn out to have difficulties deliv-ering traceability data if they were not set up to record such data in the first place.

As a consequence, the minimum requirements set forth by a traceability system with respect to data input should be few and simple, whereas data capture mechanisms should be flexible and not rely solely on sophisticated protocol stacks.

Fully automated data capture is something to strive for, but will require more consensus, stan-dardization and more affordable technology. Two key information carrier technologies that look promising in this respect are − RFID and Electronic Product Code ([EPCG]) − Barcodes, recently especially two-dimensional barcodes. This technology is also called

Reduced Space Symbology (RSS).

3.1.4.1.3 Unique Identification

Unique identification is at the core of what all kind of traceability is all about. Without unique identification mechanisms, it is impossible to create a traceability link between for instance a trading party and an item, between two parties or between two items.

The need for unique identification systems is well known in day-to-day life, and some such sys-tems are well established in our global world of business and communication. Some examples: − Telephone numbers (with country codes and area codes) − ZIP codes − Domestic or global company identification number systems (Dun & Bradstreet as an ex-

ample) − Internet IP numbers − Number plates on automobiles − Money transfer systems and identification standards (SWIFT, IBAN etc)

It is always a matter of how far the uniqueness scope for such systems should stretch. Most of the systems above are examples of systems with a global uniqueness scope. For an internal traceability system the scope can be limited to “within the company” or “within the system”. But for a chain traceability system, the uniqueness scope must be truly global. This goes for both the identification of trading parties as well as for the identification of the items which should be traced.



For trading parties, there are good identification systems available, and a well designed traceabil-ity system should be capable of using any such identification system, not requiring all companies to use the same. A few examples: − Dun & Bradstreet. A company originally providing credit information about companies.

As a matter of necessity, they had to design an identification system for the companies, re-sulting in the so called D-U-N-S numbers. Many million companies from all over the world are registered with a D-U-N-S number today.

− GS1 and Global Location Numbers (GLN). GS1 offers a global identification system for companies and even sub-locations within a company.

− ISO6523. This ISO standard is a meta system for company identification. Using this stan-dard, most other global company identification schemes can be wrapped, for instance both the two above. The registration authority for ISO6523 is the British Standards Institute (BSI).

For item identification the situation is more complex. While there are some identification sys-tems that could be used, there are challenges to overcome to establish traceability through a chain: − There are many types of items that need to be identified. Both within the same supply

chain, across chains and at different levels and groupings within the chain. Some of the numbering systems available are mostly usable for only a small subset of the above.

− The identification should ideally follow the item through the life time of the item. In most cases, this would require the identification to be physically attached to the item, for in-stance as a barcode or an RFID tag.

− B2B consensus on identification used. To establish a traceability link on an item sent be-tween two parties in the chain, the receiver of the item must refer to the item using the same identification the sender used. This may sound trivial, but gives rise to many prob-lems related to data capture.

At the end of the day, real life traceability always involves many shortcuts and compromises. When it comes to item identification, the compromise often results in a reduction in the level of traceability at some point in the chain.

3.1.4.2 Traceability Systems and Architectures

3.1.4.2.1 Internal Traceability

There are many vendors in this field and a number of systems available for internal traceability purposes. Many of these systems are merely add-ons to ERP systems or existing systems used for various Supply Chain Management (SCM) purposes. Microsoft Navision and Axapta, SAP in different flavours, Lawson’s Movex are all examples of systems that provide different services for internal traceability.

The above are examples of generic traceability systems, but here are also many industry specific systems developed. They are often very functional and adapted to well established processes, nomenclature and data attributes in use within that specific industry. These industry specific sys-tems may be standalone traceability systems, or built on top of SCM systems in use. One exam-ple of the latter is “WiseFish” from Maritech, built on top of Navision.

One of the reasons many internal traceability systems are built on top of existing internal sys-tems, is that these systems already carry a lot of data of relevance to traceability.



Since these systems are primarily built for internal use, they do not usually provide many exter-nal interfaces or different type of client access. Hence, there are no clear common architectures seen among these systems. The most sophisticated of them may provide some data through a web portal, for instance targeted at customers.

3.1.4.2.2 Chain Traceability

Unlike what was the case for internal traceability, there are not many systems available that can be said to provide whole chain traceability. The reason is that such systems are a lot more chal-lenging and complex to develop.

Global problems needs global solutions

The above is not an assumption but a fact, and not only valid for IT systems. A good example of a “global solution” is the public Internet. A system for global traceability can in many ways be compared to the Internet: − it is used for global communication (since supply chains are global), − data must be easily exchanged in various ways and with few and simple requirements to

data formats, − it must be easy and relatively cheap to connect, − security and access control should be built both into the core network (IP routing, IP secu-

rity) and into the application layers on top of the core.

Lessons learned from the Internet vs. OSI debate

At some time in the past, the ISO network model OSI (Open Systems Interconnect) was consid-ered to be a serious competitor to the Internet network model and protocol stack. OSI was gener-ally considered to be functionally superior to the Internet model, but the protocol stack was much more complex. In addition, the “closed loop” ISO standardization process versus the community driven Internet made ISO development and implementations slow and few. Today OSI is nearly forgotten and the globally wired world of business and private communication relies entirely on the public Internet and its core protocols.

Because of the similarity with the Internet, a global traceability system should probably be founded on some of the same and well proven principles: − simplicity more important than nice-to-have functionality, − scalable and redundant infrastructure based on loosely coupled systems, − provide network transparency to applications by hiding physical and topological parame-

ters (i.e. DNS names versus IP addresses), − openness, do not reinvent the wheel, look to de-facto standards and best practices where

available and usable.

A global traceability system will of course need to provide more specific and application centric services than the generic Internet, so the design and infrastructure must also encompass a few other things: − traceability data involves business critical data. Companies will in general not allow con-

nections from the Internet into their internal systems. Therefore, data sharing and data cap-ture should be based on “push” principles rather than “pull” principles,

− support and encourage the use of standards but do not enforce them, allow the “less sophis-ticated” to be part of the network too, their data may be critical to the others.



One known system for global traceability is designed following the above discussed principles, and as this system is intended to be used in CuteLoop, it is briefly presented in the following section.

3.1.4.2.3 The Global Traceability Network (GTNet)

GTNet [GTNET] is created by TraceTracker and offered as a subscription service (Software as a Service) to members of any supply chain. By subscribing to the network and contributing own data to the network, the subscriber gets basic and transparent access to upstream and downstream trading partners in the same supply chain (not only one step up and one step down) that they are members of.

However, all access to data is controlled by the company who contributed the data in the first place. Some default data sharing schemes are offered, but can be altered.

A robust web application is offered for easy access to all GTNet services. Public APIs are avail-able for both data capture and data lookup. These APIs can be used to create custom applica-tions.

GTNet also provides rich and full blown services for internal traceability, and a subscriber may choose to use only this functionality (not sharing data with trading partners).

GTNet is built on top of the public Internet and with building blocks similar to many of those constituting the Internet (i.e. routers, DNS servers, end-nodes etc). The infrastructure is scalable, flexible and robust and can be extended on demand. An overview of the GTNet architecture is depicted in the following Figure 11.

GTNET Internals

ERP system or other

Internal data system

Shopping centre

Web Access Web Access

GTNET Access NodesGTNET InternalsGTNET Internals

ERP system or other

Internal data system

Shopping centre

Web Access Web Access

GTNET Access Nodes

Figure 11: The Global Traceability Network.



3.1.5 Traceability and Standardization

Traceability as a professional field and as a business market is both young and immature. In ad-dition, traceability and its value drivers and application scenarios interfere with nearly all busi-ness processes in a company. These business processes may already have supporting tools and various standards or best practices associated with them. As a result, both the traceability sys-tems and the development of any generic traceability standard should look to these standards.

3.1.5.1 General Frameworks

These frameworks are non technical, focusing on the processes in the supply chain. The three first documents referenced below have many similarities. The GS1 document is probably the most specific and also the newest document.

3.1.5.1.1 GS1 Global Traceability Standard (GTS)

GS1 [GS1] has worked with supply chain standardization for years, and is best known as a pro-vider of globally unique identification systems and barcodes for parties and items which needs globally unique identification.

Their Global Traceability Standard [GTS] is a high-level standard defining and describing how standard supply chain processes should be conducted to ensure traceability. The standard refers to and relies on a lot of other GS1 tools and systems, for instance the numbering systems for identification of trading parties and items.

3.1.5.1.2 CIES

CIES – The Food Business Forum has developed a best practices document called “Implement-ing Traceability in the Food Supply Chain” [CIES]. It has some similarities with the GS1 GTS standard.

3.1.5.1.3 ECR

The ECR (Efficient Consumer Response) Europe has developed a document called “Using Traceability in the Supply Chain to meet Consumer Safety Expectations” [ECRTRA]

3.1.5.1.4 ISO22005:2007

This ISO standard is called “Traceability in the feed and food chain -- General principles and basic requirements for system design and implementation” [ISO22005]. It is very generic, but good as a starting point for companies knowing little or nothing about traceability.

3.1.5.2 Data Formats

3.1.5.2.1 TraceCore XML

The EU project “Trace” [EUTRACE] is currently developing an XML format designed to carry traceability data exchanged between trading partners in the supply chain. Several pilots are al-ready running both in Europe, USA and Asia.



3.1.5.2.2 OASIS UBL

The OASIS Universal Business Language [UBL] defines a set of business documents in the form of XML schemas designed for specific B2B processes in the supply chain. For instance De-spatchAdvice, RequestQuote, Order and more. Data exchanged in many of these documents are identical to the type of data that need to be captured by any traceability system.

3.1.5.3 Identification

3.1.5.3.1 GS1 numbers

GS1 numbers are the most obvious candidate for global and unique identification of trading par-ties and items exchanged in the supply chain. There are other candidates, but few with such mo-mentum as the GS1 numbers.

3.1.5.3.2 EPCglobal

The EPCglobal [EPCG] initiative is responsible for the development of a set of standards related to “Electronic Product Code” – or EPC for short. Unique identification is an important part of the initiative, so is RFID. The interesting thing in terms of traceability is that an EPC code can be embedded in an RFID tag, and that the EPC codes can be assigned so that each individual item of a certain product can be identified separately and uniquely.

GS1 numbers can be used to compose the EPC code, so EPC does not “reinvent the wheel”.

3.1.5.3.3 ISO6523

ISO 6523 – “Structure for the Identification of Organisations” [ISO6523] is a standard for identi-fying organisations. A set of well known other organisation identifiers such as GS1 GLNs and Dun & Bradstreet numbers can be wrapped inside ISO6523.

3.1.6 Conclusions

A promising new data capture technology providing diverse potentials in the scope of the Cute-Loop RTD objectives is Reduced Space Symbology – 2D barcodes [RSS]. Together with RSS, mobile phone technology is offering the possibility to use the build-in camera to scan and inter-pret 2D barcodes.

Moreover, the Global Traceability Network (GTNet) is offering basic traceability services to be taken into account when elaborating the CuteLoop access platform, services and agents.

In the scope of traceability services, a key RTD area will be to study the feasibility of using e.g. mobile phones as access device for the customer for communicating with the traceability infra-structure and as a 2D barcode scanner. Questions like the following need to be addressed: − Do the limitations of current mobile screens impose barriers on consumer adoption for this

kind of information? − How much information could be encoded in the barcode itself and what should be placed

in the traceability system and looked up there using a key in the barcode?



3.2 Global Navigation Satellite Systems based Services


In the interaction between enterprise and customer, time and position are often useful, even es-sential data to be stored or exchanged during business transactions. The reasons can be various. Time plays a role in the order of handling work, in the planning and scheduling of people and machine activities. Position is often essential in the handling of goods, the handling of bins, con-tainers of goods, the retrieval of tools, the tracing of people, etc..

Determining position and time is a discipline in itself that we will call navigation in this docu-ment. Navigation is a major research topic nowadays due to new developments in the area of satellite navigation.

At the infrastructure side, the European Union and ESA are developing their first (EGNOS) and second (Galileo) generation satellite navigation systems, whereas the USA and Russia are up-grading their GPS, resp. GLONASS system. China and India are developing their own satellite navigation systems called KOMPASS and GAGAN.

At the commercial side, many companies are preparing for a major boom in the world of GNSS applications. The first major successes were the automotive and handheld car navigators based on GPS. The technological developments needed for this type of applications go far beyond the construction of satellite navigations receivers. They also include digital map development, corre-lation of positions to street conditions, route optimisation, voice generation, etc..

In the business world, GNSS is also applied for tracking and tracing goods, in trucks, trailers or containers. This application is booming although there are still many technological issues to solve.

The first successes in the area of GNSS applications have lead to a belief that Location Based Services will bring billions of dollars of revenues and will employ thousands of people. This belief has further supported massive investments in GNSS infrastructure and application devel-opments.

GNSS applications and Location Based Services will also find their way in the CuteLoop busi-ness context. There is one important thing to note however:

Most GNSS receivers still require a direct line-of-sight to 4 GNSS satellites in order to receive the GNSS signals to determine position and time in a reliable way. The launch of additional sat-ellites GPS, GLONASS and Galileo improves the chances to detect 4 satellites at a specific point in place. Nevertheless there remains an important receiving problem in urban canyons and in-doors. Therefore navigation cannot be restricted to satellite (GNSS) navigation alone. For ena-bling an “everywhere” navigation it needs to be extended to the discipline of indoor navigation as well.


3.2.2.1 Outdoor Navigation – GNSS Technology

Existing since 1995, GNSS provide autonomous geo-spatial positioning with global coverage. A GNSS allows small electronic receivers to determine their location (longitude, latitude, and alti-tude) to within a few metres using time signals transmitted along a line of sight by radio from satellites. GPS, GLONASS, COMPASS and Galileo are the main systems expected to be fully



functional within the next 5 years, operated respectively by the USA, Russia, China and the European Union.

Satellite-based Augmentation Systems (SBAS) are also operational in some areas that increase the accuracy of the GNSS, for example the “European Geostationary Navigation Overlay Sys-tem” (EGNOS) in Europe, or the Wide-Area Augmentation System (WAAS) in North America, provide via geostationary satellites a substantial increase in the location precision.

Several navigation services are offered, with different accuracies and availability, as shown in Table 2 for Galileo. Table 2: Galileo Navigation Services.

Characteristic Open Service (OS)

Commercial Service (CS)

Public Regulated Service (PRS)

Safety of Life Service (SoL)

Position Accuracy (horizontal, vertical)

h = 4 m v = 8 m < 1 m h = 6.5 m

v = 12 m h = 4m v = 8 m

Integrity No Value-added service Yes Yes

Time to alarm n/a < 10 s < 10 s < 6 s

Certification/Liability No Yes Yes Yes

Encryption No Yes Yes No

Market Mass market Professional National Authorities Safety critical

Today, GPS is by far the most widely used system. The 90% accuracy for longitude and latitude is around 5 meter. The 90% accuracy for altitude is about 8 meter. SBAS (EGNOS) improves the accuracy but is generally only available as outdoor navigation technology.

Satellite navigation receivers on chip are available in many types, according to the application needed.

Companies like Trimble, Garmin, Javad, Magellan, U-blox sell satellite navigation receivers on chip, including the possibility to receive SBAS signals for increased precision and integrity. A typical state-of-the-art satellite navigation receiver chip is e.g. the Trimble Copernicus GPS re-ceiver, which can operate either in traditional GPS mode, or in SBAS (EGNOS) mode.

If we call these receivers-on-chip, shortly GNSS chips, the GNSS chip peripheral circuitry needs to be connected to a small L-band antenna and the circuitry typically delivers position and time strings according to the NMEA (National Marine Electronics Association) protocol on a serial data connection like RS-232.

The position is expressed as longitude, latitude according to the WGS84 (World Geodetic Sys-tem) reference frame. The accuracies of position are indicated in Table 2. The time has an accu-racy between 20 and 200 ns, which is largely sufficient especially for combining time stamps with delivery events in supply chains or for harmonising event-based human interaction in work flows.

Three technical characteristics are important for the GNSS chip: − the sensitivity (e.g. -160 dBm in tracking, -146 dBm in acquisition mode) − the acquisition time (38 sec cold start, 3 sec hot start, 2 sec reacquisition) − the power consumption (from 100 mWatt to 1 Watt)



The high acquisition time from cold start is an inherent problem in GNSS devices. It is an impor-tant aspect to be taken into account in CuteLoop applications. Acquisition threshold and acquisi-tion time are considerable in difficult receiving circumstances like urban environments, indoor environments etc.

Nowadays, power consumption between 100 mWatt-hour and 1 Watt-hour are common. This makes the GNSS chips suited for integration in a handheld RFID card reader, but not yet in a passive RFID tag.

However, in the scope of CuteLoop we consider a major role of GNSS as well as RFID in com-bination with mobile devices like PDA, Smartphone, or notebooks. The combination of RFID tag information and GNSS features will therefore also be enabled in the moment of reading tags, by putting e.g. a passive tag on a business related object (e.g. pallet, crate, car, material) and hav-ing a GNSS chip in the networked mobile device, providing sufficient power. There are already diverse mobile devices providing GNSS functionality (e.g. SpaceChecker SC-200 modem; Nokia N95, Ameo, Blackberry 8800, HTC Touch). While there are diverse trends of combining GNSS devices with RFID readers which are also already available at relatively low prices for the mass market, to be easily connected to computer as well as mobile devices (e.g. Mir:ror from violet; RDL5-HF Mouse from Deister Electronic; MIDEL1000 and Mobile Handreader of Sof-tronica; Nokia 6131 NFC for near field tags). This enables the integration of objects for daily use and business processes in larger application scenarios (i.e. the Internet of Things).

3.2.2.2 Indoor navigation

3.2.2.2.1 Introduction

Inserting time and position data in decentralised transactions that take place in business oriented environments will be often done indoors. Therefore, the location based service issue needs to be studied both outdoors and indoors. For instance, satellite supported navigation (GNSS) is limited for indoor environments. There exist high performance GNSS chips that also operate in some indoor areas, but the power consumption and acquisition time of these chips is quite high and the operation is usually not reliable enough to support a business environment.

Therefore GNSS is complemented with other navigation techniques to allow for indoor naviga-tion. Indoor navigation for business use is not widely applied yet, although there are many R&D projects and many company specific solutions.

A lot of R&D has been done recently on the use of indoor navigation for emergency situations, like fire fighter tracking, evacuation, etc.. The most common navigation techniques that com-plement GNSS for indoor navigation are the navigation techniques listed below: − Assisted GPS − Inertial Navigation Systems − Ultra Wide Band systems − Cell detection or range trilateration based on terrestrial communication systems (DECT,

GSM/GPRS, WiFi) − Terrestrial indoor pseudolites (pseudo-satellite, emulation of satellite positioning) that emit

GNSS-like signals − Dead reckoning algorithms − Waypoint and/or map-matching navigation, possibly RFID supported.

In the next paragraphs, these navigation techniques will be further explained.



A specific issue that needs to be solved concerning ‘Indoor Navigation’ is the navigations coor-dinate reference frame. For outdoor navigation using GNSS, the classical NMEA format using the WGS84 reference frame is sufficient for most outdoor applications. In such case, the coordi-nates are expressed in a decimal notation of degrees. For indoor navigation however, the use of degrees, even including minutes and seconds, is not very practical. Instead, coordinates are pref-erably given in units of meters, referring to Cartesian axes that are aligned with the shape of the building. There are solutions to this ‘conversion’ problem.

3.2.2.2.2 Assisted GPS

As indicated before, there exist high performance GNSS chips that also operate in some indoor areas, but the power consumption and acquisition time of these chips tend to high and the opera-tion is usually not reliable enough to support a business environment.

The effective range of signal levels at which a GPS receiver can operate can be greatly extended if the receiver is not required to extract the navigation message from the signal. Although a sig-nal might be too weak to demodulate the message, it may still be sufficiently strong to enable the receiver to make code measurements. Required data for positioning, such as ephemeris, satellite clock error, and atmospheric error coefficients, can be provided to a GPS receiver over a cellular telephone link. The cellular network could also supply timing information to help the receiver to acquire signals more quickly. This mode of receiver operation is known as assisted GPS (A-GPS).

3.2.2.2.3 Inertial Navigation Systems

Inertial Navigation Systems (INS) are fully autonomous navigation systems for military and civil navigation applications. Navigation solutions provided by INS, however, drift over time. As an aiding sensor, GPS can reduce the drift of INS by providing regular fix updates and INS can bridge the short period gaps where GPS signals are unavailable. Although GPS/INS integration might be an expensive and complicated solution for CuteLoop, depending on the devices used, it might be the only way to bridge GNSS positioning gaps. There are some misconceptions related to the ability of INS to augment GNSS. For example, it has been suggested that the integration of GPS and INS will improve the ultimate positioning. As outlined above, INS can only be used to bridge the position gaps and the continuous positioning accuracy of an integrated system main-tained by INS after the failure of GPS positioning is actually governed by the quality of the final GPS positioning fix. The ability of INS to bridge these gaps with no reduction in the positioning accuracy relies on the quality of both the GPS receiver and the INS device.

The following types of sensors can support an inertial navigation system: • Non-inertial sensors − Compasses (direction) − Magnetometers (earth magnetic field strength) − Pressure sensors or barometers (relative altitude differences)

• Inertial sensors − Accelerometers for linear movements − Gyroscopes for rotations − Accelerometers and Gyroscopes can be combined in a so-called IMU – Inertial Measure-

ment Unit

SARHA – Sensor Augmented EGNOS/Galileo Receiver for Handheld Applications in Urban and Indoor Environments is an FP6 project that specifically focuses on the use of navigation de-



vices by pedestrian users in difficult receiving circumstances like urban and indoor environments (see [Weimann08]).

3.2.2.2.4 Ultra Wide Band Systems

Ultra Wide Band systems are low-power, short-range indoor communication systems, but they can also be used to measure positions, similar like a low-power radar system. They emit wide-band pulses, the spectral density of which can be so low that it can stay below the maximum densities imposed by the frequency regulations. The technology has already been applied in hos-pitals. Standardisation of UWB for Personal Area Networks (IEEE 802.15.3a) has not succeeded yet.

3.2.2.2.5 Cell Detection or Range Trilateration based on Terrestrial Communication Systems (DECT, GSM/GPRS, WiFi)

Indoor workers are usually equipped with some kind of a handheld communication device (DECT phone, GSM/GPRS phone, WiFi handheld device). The position of the devices can be detected by the communications systems’ base stations in two ways: − A rough positioning is always possible by determining the base station to which the de-

vice is connected, or alternatively, the base station that receives the handheld device with the best quality. For GSM/GPRS phones, this localisation is too rough for indoor usage, al-though UMTS phones can now also be supported by very small, business environment base stations called pico-cells. A specific problem with this position determination is the determination of the floor. One can be connected to a base station on a floor above or be-low one’s own floor.

− A fine positioning is possible by measuring the range between the handheld device and three surrounding base stations. By solving 3 (4) equations with 3 (4) unknown variables, one can determine the position of the handheld device. This can already be done with DECT and GSM/GPRS phones (WiFi, WiMAX, OFDM, etc. have to be investigated fur-ther).

3.2.2.2.6 Terrestrial Indoor Pseudolites

In large indoor facilities with a lot of GNSS enabled devices and GNSS users, it makes sense to install a terrestrial pseudolite. This is a device that emits a GNSS – satellite like signal that can be used by a navigation receiver to determine position. Normally, utilisation of the same naviga-tion frequencies is not allowed due to the risk of interference, therefore, other licensed frequen-cies need to be used.

3.2.2.2.7 Dead reckoning algorithms

In case a ‘navigator’ is confronted with complete absence of navigation references (neither GNSS signals nor terrestrial communication signals, nor sensor information), he can still esti-mate his new position by means of a so-called dead reckoning algorithm. The algorithm extrapo-lates a new position based on previous position, speed, direction and curve. This navigation technique is often applied at sea and for vehicles and trains passing through tunnels.

For pedestrian users in indoor environments dead reckoning is not so easy, as movements are less predictable.

There are, however, dead reckoning algorithms for pedestrian users based on average step fre-quency and step size. The algorithms can use inputs from accelerometers integrated in the hand-



held device that is carried by the pedestrian user. The distance covered can be estimated and mapped to the corridor of an indoor building. Practice points out that the error remaining after dead reckoning is still about 10 to 20% of the actual distance covered. This implies that the maximum error of a dead reckoned position of a pedestrian user that walked 10 meters is already 2 meters.

3.2.2.2.8 Waypoints – Map matching RFID assisted

As indicated in reference [Miller06a] and [Miller06b] the error made after dead reckoning and inertial navigation systems can be reduced in two ways: − The pedestrian user can recalibrate his position when passing a fixed ‘waypoint’. This is a

known reference location in the building that can be marked with a transmitter, an RFID reader or an RFID tag. By installing multiple waypoints in the building, the navigation er-ror can always be kept below a certain maximum value. In references [Miller06a] and [Miller06b], the waypoints were implemented by means of RFID tags. In this case, the RFID reader is mobile, the tag is fixed. When the pedestrian user passes the waypoint, his RFID reader detects the waypoint RFID tag and confirms that he is in a circle of x meters around point A. It is important to know the detection radius of the RFID reader and the steepness of the RFID field power-distance curve. Again the waypoint’s floor is important. One has to avoid that the reader detects a waypoint that is actually located at an adjacent floor of the building.

− The estimated position can be mapped to a map of the building. Obviously, the user can’t have walked through walls. His position has to correspond to a realistic position on the building map. This principle is the same as the one applied in common car navigators. The GNSS determined position is always mapped to the nearest realistic road position.

3.2.2.3 Distributed security and trust

3.2.2.3.1 Introduction

GNSS determined position and time can be used to ensure security and trust for business transac-tions that occur in a decentralised way. There are basically two examples: geo-encryption and geo-locks. (Yet other applications may be envisaged though.)

3.2.2.3.2 Geo-encryption

In the concept of GEO-encryption, position and time are detected by a remote user and the posi-tion and time is included in the encrypted business transaction data to make sure the remote user performed the business transaction in a limited position – time frame (e.g. on day x from his known home office). In this way, it can be avoided that someone else tries to perform the same business transaction, which is then expected to be done in a different space-time frame.

If the position – time stamp corresponds to the expected position-time frame, the business trans-action will be accepted. If the position – time stamp does not correspond to the expected position – time frame, the business transaction will be rejected.

GPS signals can be ‘spoofed’. Someone who regenerates an artificial GPS signal can make a GPS receiver believe he is located at a specific position and time. Recent GNSS developments aim at encoding GNSS signals such that they cannot be ‘spoofed’. In other words, Galileo will offer GNSS signals that can’t be imitated to deceive a Galileo receiver and make him believe he is located at a specific time and place.



3.2.2.3.3 Geo-locks

In the concept of Geo-locks, a physical lock can not be opened unless the connected GNSS re-ceiver tells the lock that it is located at an acceptable time and place to open the lock.

This is a useful solution when transporting high value goods or money. Trailers or money cases may be equipped with a geo-lock. During transportation, the GNSS receiver connected to the Geo-lock will notice that position and time do not correspond yet to the expected position and time when the high value goods will be taken out of the cargo space. Neither the trucker nor anybody else will be able to open the lock.

Only when the high value goods arrive at the expected location at the expected time, the geo-lock will ‘unlock’ itself and allow opening.


The main problems concerning navigation in the CuteLoop context are the following: − The problem of urban canyons and indoor navigation − The integration of navigation hardware with RFID hardware − The problems of power consumption, acquisition time and sensitivity − Integration with RFID reader versus integration with RFID tag − Determination of the scenario.

○ Which entities determine position and time? ○ Which entities store position and time? ○ Which entities need position and time of which other entities?

− What is the role/use of location based services / location based publicity?` − How can security be enhanced with GNSS?



3.3 RFID enabled Services


Radio frequency identification (RFID) technology is currently one of the most promising and discussed auto-identification and data capture (AIDC) technologies. The main goal of an RFID system is to carry data on a transponder (tag) that can be retrieved with a transceiver through a wireless connection. The ability to access information without a line-of-sight in a tag can be util-ized for the identification of goods, locations, animals, and even people.

Although RFID is not a new technology, the range of applications is broadening rapidly and new applications which integrate other technologies such as sensors are developing.

By providing a unique identifier to any physical object (it is foreseen that within the next decade any object resulting from a manufacturing process will be equipped with a tag as part of its pro-duction process, most likely based on RFID technology), and by allowing its readability at a dis-tance, an information universe parallel to the physical one can be defined so allowing the crea-tion of the so called “Internet of Things” [ITU05]. RFID technology as a precursor to the Internet of Things will optimise existing processes in various industrial sectors. RFID is also expected to create opportunities for new business models that will take advantage of a global network in which any object can be linked to any context.

Nowadays, it is rather difficult to quantify the impact of the technology, in part because most RFID applications are recent. Market analysis shows rapidly growing markets for RFID systems and, apart from very detailed mainly qualitative evaluations of particular applications, there are few aggregate impact studies. Available aggregate studies show large impacts in terms of bene-fit/cost ratios and productivity gains; however calculations are based largely on current good practice case studies, leading to a potential overestimation of aggregate benefits.

A large number of fields and sectors (such as Manufacturing and production, Environment Pro-tection, Agriculture and Food, Transport and logistics, etc.) have been identified for RFID ap-plications and the number is growing at a fast pace (see Table 3). To structure RFID applica-tions, the following application areas are described below [OECD08; JTC07]: − Asset utilisation:

Mobile assets are tagged for their use along the supply chain. Typical examples are RFID-tagged containers which are used at different production stages. The aim is to optimise processes and attain a more efficient use of capacity.

− Asset monitoring and maintenance: Mostly fixed and high-value assets are tagged to store information, e.g. for maintenance purposes. Examples include tagged machines where the maintenance history and informa-tion on replaced parts are stored on the tag.

− Item flow control in processes: For item flow control, RFID tags are attached to items which are moving along the supply chain. Often information going beyond a simple ID number is stored on the tag to control production processes. This is, for example, the case in the automotive industry or construc-tion industry.

− Localization: The RFID technology can be used for human and target localization and tracking. An ex-ample is the use of the RFID technology for indoor localization in the complicated indoor environment, where the Global Positioning System (GPS) is not available.



− Inventory audit: A prominent application is the use of RFID for inventory audit. Examples include retailers’ warehouses where pallets, sometimes cases and even items are tagged to improve the speed and efficiency of stock taking. First RTD projects were realised by retailers promoting the ‘intelligent shelf’ for perpetual inventory (e.g. CoBIs, SMART).

− Theft control: Item level RFID tags are used to prevent theft along the supply chain or at the point of sale. A simple form is electronic article surveillance (EAS) which can be RFID-based. In this case, low-end RFID systems (e.g. 1-bit tags) are used which communicate when consum-ers leave the shop if they have not been deactivated. Applications for theft control in mail order for high-value products such as mobile phones use more sophisticated tags.

− Authentication: For authentication purposes, RFID is used to provide secure identification mechanisms for persons and objects. Prominent examples of personal authentication are company entry badges, transportation system cards, electronic passports and identity cards. Current fields of application for object authentication include the tagging of drugs in the pharmaceutical sector and high-value goods in the luxury sector to prevent counterfeiting.

− Security: In some cases, RFID technology is used for secure transactions. In this cases, safety re-quirements for tags are very high.

− Privacy: If "live" unique RFID devices pass beyond the point of sale and are carried out into the consumer's world, they pose a strong threat to privacy. The unique ID in a garment or a car could be read silently by any organization and associated with an individual, allowing sub-sequent re-identification by that organization (or indeed by any other organization to which the data was sold). Another example is when a person makes a purchase with a credit or loyalty card. The seller could link his/her identity with the RFID number of any tagged ar-ticles the person is carrying, and use it later or even sell that linking information to other organizations. Vast databases of records of people's movements would become available to telemarketers, government investigators and others, while such a scenario must be avoided.

− Safety: There are a number of practical examples where RFID technology can help ensure the safety of people or objects. For example, RFID can help diabetics maintain proper blood sugar levels, or ensure the efficacy of vaccines and other biologicals in the healthcare envi-ronment. RFID can also help make sure the food is fresh and help to identify the source of contaminants. Another application is to keep the people safer on the highway. Sensors and RFID tags can e.g. report both the age and pressure of tyres on large trucks or passenger vehicles and help prevent tyre failures due to age or excessive heat (which is typically caused by low tyre pressure).

In Table 3, an overview of RFID application areas for different sectors and fields is provided. Those ones that are the most relevant for the two scenarios (construction and food) selected by the CuteLoop project, are marked in green.



Table 3: Overview of RFID application areas for different sectors and fields.

Application types

Field / sector

Asset utilisa-tion

Item flow control in pro-cesses

Asset monito-ring and mainte-nance

Loca-lisation

Inven-tory audit

Theft control

Authen-tication Security Privacy Safety

Manufacturing and production

Environment Protection (recycling, …)

Agriculture and Food

Transport and logistics

Retail and consumer goods

Public trans-port

Anti-counterfeiting

Personal and Object Elec-tronic Identity

ePayment

Leisure

Health care

Additional more detailed examples of current RFID applications for selected scenarios are pre-sented in the Annex in chapter 8.2.

3.3.2 Basic RFID System Components

The specific characteristics and functionalities of the software components of an RFID system vary greatly depending on the applications and other needed requirements. The components can be categorised as follows: − RFID system software: This is needed for the collection of applicable software functions

necessary to effectuate the basic interaction between a tag and reader. The functions are: read/write, Anti-Collision, Error detection/correction, encryption, authorization and au-thentication (security).

− RFID middleware: This consists of software components that acts as a bridge between the RFID system components (tags and readers) and the host application software. It performs two primary functions:



○ Monitors the device (reader) health and status ○ Manages RFID-specific (tag & reader) infrastructure and data flow.

− Host application: This receives processed and normalized data sent from the tag, via the reader and the RFID middleware software.

3.4 Integration of GNSS and RFID Technology

3.4.1 Combined Hardware

There are basically two ways to combine GNSS and RFID technology: − Inserting GNSS chips in RFID tags: it only make sense when cost and power consump-

tion of the RFID tag are of the same order of magnitude as the cost and power consump-tion of the GNSS chip. The actual state of GNSS technology does not seem to allow this yet for the ‘low-end’ passive RFID tags. For the advanced ‘high-end’ active, battery pow-ered RFID tags, such a possibility can be considered. This combination is not widely used yet.

− Inserting GNSS chips in RFID readers: it would make sense for battery powered hand-held RFID readers. The readers could determine their position and time and store this in-formation on active or passive RFID tags (that are connected to goods, vehicles, locations, people or bins) in the moment of reading or forward it after reading the RFID tag to related software applications. When circumstances are particularly bad for GNSS reception, the RFID reader could refuse the time-position stamping of a transaction until the user has de-tected the nearest waypoint RFID tag and read the nearest reference position.

It is important to take notice of the complexity of interaction that is possible.

GoodsGoods LocationsLocations

BinsBins PeoplePeople

VehiclesVehicles

GoodsGoods LocationsLocations

BinsBins PeoplePeople

VehiclesVehicles

Figure 12: Interactions between entities.

In Figure 12, the main entities that could carry an RFID tag or reader are shown. Between these entities, there are interactions that could lead to business transactions that need to be registered using the RFID technology. These business transactions may need a position-time stamp. Among the shown entities, only the locations are not mobile (i.e. having a defined position). All the other entities are mobile and are therefore subject to be able to integrate as single entity or in combina-tion with other entities GNSS type functions and services. A first question is which entities will carry a reader and which entities will carry a tag. The ones carrying a reader are most likely to carry a navigation device. They can write position and time on the other entities, which carry only a tag.



3.4.2 Location Based Services

Location based services are already available in diverse business sectors. Moreover, their initial realisation is also taking into account the hybrid technology of GNSS and RFID to enable the localisation of a unique product or resource in real-time as they are processed and transported in an integrated enterprise scenario to guarantee a more precise level of supply chain operational efficiencies, accuracies, improved operation costs and ensure a viable return on investment (ROI). The GNSS technology for ubiquitous positioning to be taken into account in the Cute-Loop project, notably augmented GPS or EGNOS/Galileo signals, are considered in hybrid net-works (i.e. using satellite signals of different system origin). However, GNSS location based receivers can fill the gap for RFID during external transport phases beyond RFID signal ranges, whereby fulfilling the hybrid model throughout the supply chain in the integrated enterprise. This concept encompasses traceability as a means to limit damages incurred by the sale and dis-tribution of unsafe products and location identification, so this approach can ensure a robust and reliable supply chain, inventory, and logistics management.

The real-time supply of information by combining GNSS and RFID in a hybrid system model can provide great implications in relation to the system reliability, associated costs and deploy-ments of products across the supply chain through all steps of production, distribution and sales. However, it is quite a challenge – the performance of the system especially depend on the con-sideration of the following system requirements: − Required RFID Frequency of operations in all activity scenarios − Environmental impact on RFID devices − Robust and reliable Software to ensure reliability, security and speed of data rate − Security and privacy challenges − Robustness of transmission networks (wireless, ADSL etc) − Standardisation

3.4.3 Application Examples of integrated GNSS – RFID

GNSS and RFID technologies can be used jointly for applications such as tracking (of equip-ment, goods, etc), logistics, teams’ coordination, assets management, etc. Currently they are al-ready being implemented and their effectiveness is being proved, showing their large market potential. Some examples of involved industries are: − Agriculture / Fisheries: Tracking of the livestock and the deployed equipment − Aviation: Airport logistics and security control − Civil engineering: Tracking of equipment and management of operating facilities − Civil protection: Localization and management of aid teams and equipment − Energy: Infrastructure mapping − Environment: Monitoring, tracking and surveillance of goods and animals − Finance / Insurance: Tracking of important goods during transportation

However, logistics as a cross sectorial application domain is acting at the forefront of RFID us-age in diverse business domains. There are first pilots validating the GNSS-RFID combination.

A pilot of the German company Schmitz Cargobull Telematics is piloting solutions for lorries. A combination of GNSS, RFID readers and sensors are installed in the trailer, enabling the online tracking and generation of event-based messages. However, due to the structured trailer envi-ronment, problems concerning energy and costs are not of most importance.



Moreover, the ‘Port of Rotterdam’, currently the world’s third busiest port, has a large active RFID installation used for vehicles and containers tracking. The system helps to locate all vehi-cles and containers that are deployed in the terminal at any point in time. Currently there are over 250,000 vehicles entering the terminal annually, each given an active RFID tag where the Vehi-cle Identification Number (VIN) is stored. The VIN is regularly transmitted to the RFID receiv-ers, some vehicles and containers send it together with their location (calculated via GPS). Such system permits a very effective management of the vehicles realising the transport of containers between terminals, as the containers’ data management, together with quality and security con-trols, can be realised much more automatically and quickly.

When considering different potential areas of improvement in construction processes (see also Table 4 below), especially the combination of GNSS and RFID enables the realisation of several advantages. Table 4: RFID improvements benefiting from GNSS [ERA06].

Areas of improvements Potential Benefits

Tracing of goods Improve traceability of goods as regards their place of origin for fight-ing against counterfeiting and increasing trust in quality and origin.

Tracking delivery of goods Improve traceability of goods and reduce number of disputes on whether goods have been delivered. Improve customer satisfactions.

Asset Management More efficient, effective, and profitable processes.

Locating material in the factory and on site Correct goods located and will save man hours in locating goods.

Facilities / Asset Management

Reduce maintenance inspection times. With increased bandwidth wireless technologies to be used to download data required by op-eratives in real time and improve efficiency, accuracy and reduce number of visits.

Aid in integrating supply chain All of the above

CuteLoop 4 Networked Devices


4 Networked Devices

4.1 Devices


The decentralised coordination of tasks in supply chains as well as the distributed control of un-derlying complex networks is realised in the physical world by a large amount of actors. In clas-sical terms, independent SME actors have defined personal interfaces to other actors in the sup-ply chain. Over the past decades, specifically this underlying supply chain dramatically im-proved concerning efficiency and effectiveness, even spanning globally distributed networks of actors, representing an integrated enterprise. One of the key enablers to improve the interaction along the supply chain was the usage of networked devices like personal computers and tele-phone systems. Especially the dramatic improvement and convergence of e.g. functionality and performance in networked devices promoted this development. Therefore, in the scope of Cute-Loop, a key objective is to explore how networked devices can be further exploited to realise an intelligent support of human operators along the supply chain and specifically within an Inte-grated Enterprise.

Since the CuteLoop project is focusing on integration of customers for becoming a driver of the integrated enterprise, the project partners have analysed the state of the art of networked devices with respect to the key characteristics of using networked devices from human operator perspec-tive. Based on such characteristics, it is envisaged to structure/describe different types of devices as well as to facilitate the selection of an appropriate networked device for enabling an intelligent support of end-users. The following Figure 13 presents an overview of key characteristics for the CuteLoop project scope, which are specifically of importance from Human Operator perspective when aiming at the usage of networked devices.

Explicit Interaction

Mobile usage

Usage at fixedlocation

Connected

Disconnected

Synchronous

Asynchronous

ActiveUsage

PassiveUsage

Characteristics of Using Networked Devices from Human Operator Perspective

Characteristics of Using Networked Devices from Human Operator Perspective

ContinuousUsage

DiscontinuousUsage

Visual User Interface

Tactile UserInterface

Voice UserInterface

Tangible UserInterface

Human-MachineInterfaces

Human-MachineInterfaces

DeviceMobilityDeviceMobility

Connection with other Devices

Connection with other Devices

Interaction of different ActorsInteraction of

different ActorsIntensity of

Device UsageIntensity of

Device Usage

Implicit Interaction

User relatedSensors

Video/PictureRecognition

Ambience rel.Sensors

AutonomousOperation

InterdependentOperation

Figure 13: Classified characteristics of using networked devices from Human operator perspective.



The different characteristics classes, as presented in Figure 13, are described in the following, specifically focusing on the human operator perspective. • Human-Machine Interfaces are split into explicit and implicit interaction of a human opera-

tor with a networked device. This difference is based on the assumption that an implicit in-teraction enables the human operator to experience an activity within a business process without a breakdown [see also Stokic06]. When using an explicit interaction, the user will become explicitly aware of the input to or output from a device.

− Visual user interface: Displaying graphical and textual elements for presenting informa-tion to the user as well as enabling the user to control functionality. Generally operated by mouse and keyboard. They can also be combined with other interfaces like voice and tan-gible user interfaces.

− Voice user interface: Enabling the user to provide input, receive output and/or control a system by voice. Major different types of speech recognition are grammar constrained and natural language recognition. Moreover, a voice user interface generally incorporates both the speech recognition system (SRS) as well as the text to speech system (TTS).

− Tangible user interface: Embedding touch sensitive functionality directly into a device. Key issue is to discover a touch of a human operator, while this can be combined with the information of the location, where the user touched the device, like e.g. represented by a touch screen, which is a combination with a visual user interface.

− Tactile user interface: Providing output to the user by haptic feedback methods, like e.g. vibration of mobile telephones or of video game controllers.

− User related sensors: Measuring autonomously user related conditions, like e.g. the loca-tion by reading an RFID tag with a reader with a defined position or proximity between a sensor and a device carried by a human operator.

− Video/ picture recognition: Using video or picture based information, incorporating in-formation about the ambience and the user. Current examples are e.g. face recognition at airports or video surveillance in assisted living scenarios.

− Ambience related sensors: Using sensors, which are automatically measuring ambience related parameters (see also chapter 4.2.2 for examples of measured ambient conditions) in accordance to the current location of a human operator. Those sensors can be combined with both devices carried by the human operator as well as with specific locations in the ambience.

• Device mobility, expressing the potential of a networked device to be operated independent of its location. This is often combined with further characteristics expressing the degree of mobility like e.g. size, weight, power supply and robustness. It is specifically considered the device ability of mobile operation12.

− Mobile usage: Enabling using and carrying a device independently of a specific location, enabling the decoupling of process design and infrastructure layout, as well as their re-finement.

− Usage at fixed location: Usage of the device is only possible at a specific location. At this location a defined infrastructure is available to enable the operation of the device.

• Connection with other devices identifies the level of dependability of a certain device on the availability of other devices, taking into account content as well as functionality.

12 The ability of a device of being transportable from one fixed location where it was used to another fixed location

where it shall be used is not considered as mobile usage (e.g. a desktop PC is not considered to support the mo-bile usage, even if it is possible to transport it from one office to another, since it operates at the new location as a fixed device. In contrast to this, a laptop is prepared to operate generally anywhere even without external infra-structure.)



− Connected: Generally characterising the availability of a connection in terms of user inter-action. This characteristic might be further detailed with respect to different types of con-nections, specifically taking into account the technical realisation and the level of a real physical connection (e.g. differences between Ethernet based Local Area Networks and de-lay/disruption tolerant networks).

− Disconnected: Impeding the communication of a device with other devices. This charac-teristic can also be further detailed with respect to the “level of disconnection” from a full disconnection by switching off the networking capability (e.g. WLAN, Bluetooth antenna) up to logging out from an application.

− Autonomous operation: Expressing the ability of a device (i.e. including hardware and software) of being able to be used by the human operator without any interoperation with other devices or infrastructure.

− Interdependent operation: Expressing the need of a device for interoperation with other devices or infrastructure in terms of content (e.g. using data stored in data bases external to the device) as well as of functionality (e.g. using functionality like web services, which is located at other devices or in the infrastructure).

• Interaction of different Actors is focusing on the realisation of their working steps in the business processes, taking into account the sequence of work within the related workflow.

− Synchronous: Executing a specific task in a work step with the generation of information or request, which need to be processed immediately by a functionality located on another device or in the overall infrastructure. This will return an output, which is required by the human operator before being able to continue the task execution.

− Asynchronous: Execution and finalisation of a specific task which generates a certain out-put, which can be forwarded to a subsequent task in the workflow, not requiring a direct feedback to continue the task execution in the workflow of the human operator who sent/ generated the output.

• Intensity of device usage expresses the usage behaviour of the human operator over time within the workflow.

− Active usage: Operating the device explicitly with full awareness of the human operator (e.g. using a device for recording information and checking via a visual user interface).

− Passive usage: Using the networked device, not requiring an explicit interaction of the human operator (e.g. carrying a mobile phone connected to the network without an active connection to the device of another actor).

− Continuous usage: Using the networked device continuously within the business process for the accomplishment of the tasks of the human operator as prerequisite to accomplish a specific workflow.

− Discontinuous usage: Using the networked device only for the accomplishment of a spe-cific task within the business process and stopping the usage for executing a task not re-quiring the support of the networked device.

These characteristics were used when analysing currently available networked devices technol-ogy as detailed in the following chapter 4.1.2.

4.1.2 Overview on Networked Devices Technology

The overall objective of the CuteLoop project is to support the realisation of a “networked de-vices enabled intelligence”. This specifically includes the combination of existing basic device technologies with RFID and GNSS type enabling technologies in the scope of supporting user interfaces, which are based on functionality enabled by the four basic CuteLoop RTD results (i.e.



EDA & SOA based architecture; event-driven agents; decentralised security & trust; interaction models).

Therefore, CuteLoop specifically analysed devices which are providing some kind of user inter-face. Those human operator centric devices are presented within the following chapter 4.1.2.1. To enable the networking of devices, they are generally equipped with diverse kind of network-ing technology. Those enabling technologies for networking can be combined with different types of devices, while the continuous convergence of the networked devices technology results in diverse combinations of device and networking technologies (e.g. PDA and mobile phone are already equipped with similar networking technologies, like Bluetooth, Infrared, WLAN). There-fore, the analysis of the networking technology was separated and is presented in chapter 4.1.2.2.

4.1.2.1 Human Operator Centric Devices

4.1.2.1.1 General Personal Computers

Personal Computers (PCs) are the most common devices in home and business environments. Especially “Desktop PCs” are non-mobile devices, designed for static use. They are usually op-erated with a keyboard and a mouse while using a screen and acoustics for output and feedback. Due to numerous interfaces (USB, PCI-(E) slots and more), desktop PCs can be enhanced com-prehensively with input-, output- and connectivity interfaces.

To connect to other devices and networks, the basic configuration usually includes Ethernet only but additional network interfaces are available as accessories. Major advantages of PCs are their performance and storage that exceed many other, especially mobile, devices. The range of oper-ating systems available for PCs includes Windows, Linux and less-spread operating systems.

A more specific variant of a PC is represented by servers, which are similarly non-mobile and static devices that can be operated either locally (keyboard, mouse, screen) or using tools for remote access. Its key characteristics are similar to desktop PCs but optimized for dedicated processing featuring huge storage capacities and/or high performance. For this reason, there are special server operating system editions available that are optimized for e.g. multi-user access, performance or data throughput.

4.1.2.1.2 Notebook

A notebook is a full featured but mobile Desktop PC. With a typical weight between 1.5-3 kg and a screen size around 12-15 inches, notebooks allow comfortable working using the built-in keyboard and touchpad while staying mobile. Most notebooks come with pre-installed Windows XP or Vista operating systems but the choice is, similar to desktop PCs, not restricted to them. Common interfaces on notebooks are USB and PCMCIA slots. To connect to networks and other devices Ethernet, Wireless LAN and Bluetooth technology are usually included as well.

4.1.2.1.3 Tablet PC / Convertible

Tablet PCs are primarily notebooks with a different form factor and control principle. Operated with the touch of a finger or with a stylus, these slate-shaped mobile devices offer a different type of interaction. Their screen size, operating system, functionality and interfaces are quite similar to those of common notebooks. While common notebook operating systems can be used with Tablet PCs, there are special editions like Windows XP Tablet PC Edition with enhanced support for touch or pen-based control.



A special hybrid tablet PC or notebook is the Convertible. It offers functionality and design from both device types with a turnable touch screen converting a notebook into a Tablet PC and vice versa.

4.1.2.1.4 Ultra mobile PC

The ultra mobile PC (UMPC) was introduced in 2006 at CeBIT Hannover. Using modified PC hardware but traditional operating systems this device class supports common software used in ordinary PC’s. With a screen size of approximately 4.5-7 inches UMPC’s are competing with PDAs and subnotebooks. They are operated using touch screen or keyboard and offer support to almost any kind of extension through their standardized interfaces (USB, PCMCIA). Many UMPC’s are equipped with cameras and can be connected to other devices using Ethernet, Wire-less LAN and Bluetooth technology. Its intended use is still not clear but first devices found their niche in the area of navigation systems and media players.

4.1.2.1.5 PDA / Handheld

A personal digital assistant (PDA) is a mobile device with a small form factor, low weight and a small screen typically around 3.5 inches. It is operated using pen or touch based interaction in combination with few buttons or a keypad. There are different operating systems available for PDAs including proprietary systems like Windows Mobile, Palm and Symbian or Linux-based systems. Additional user-defined applications can be stored in internal memory or on external storage (e.g. flash memory cards). To connect to other devices and to the internet PDAs include Wireless LAN and Bluetooth technology. Generally PDAs can be used with a docking station allowing to recharge batteries and to synchronize data with a connected PC.

PDAs used in industrial and commercial environments include further interfaces e.g. to read bar-codes or RFID tags. For the utilization in rough environments industrial PDAs with special rug-gedized casing, resisting shock and dirt, are available.

Many other devices are built upon the PDA concept, featuring a different concept of portability (e.g. wearable, pistol grip handles) and control (e.g. keyboard, speech recognition/ synthesized voice response).

4.1.2.1.6 Mobile Phone

A mobile phone is a small mobile device capable to send and receive voice or data using GSM (2G) or UMTS (3G) based cellular networks. Besides common telephony functionality, it can also be used for text based (SMS) or voice and image based (MMS) messaging using the inte-grated keypad and a possibly available built-in camera. For device interconnection many mobile phones support Bluetooth technology.

The amount of supported functionality drastically increased over the last years, specifically the enabling of multimedia features for private end-users as well as extending the computing per-formance and bandwidth to enable the provision of online services, based on proprietary net-works of specific service providers and based on the internet.

4.1.2.1.7 Smartphone

A mobile phone with additional features is called smart phone. Implementing organizer, email and internet functionalities as well as support for third party applications and software exten-sions, a smart phone becomes a kind of mobile phone/PDA hybrid. It is equipped with better cameras, Wireless LAN, GPS sensor, a keyboard, touch screen as well as speech recognition and



voice response. Key focus of this device is to enable mobile working and versatile usage. Due to more functionalities and an often slightly larger screen, the dimensions of smart phones exceed the size of common mobile phones.

4.1.2.1.8 Head Mounted Display

Head mounted displays (HMD) are visual output devices that are built-in to a helmet or that are similar to eyeglasses. Monocular HMDs are placed in front of one eye and binocular HMDs can be used with both eyes. To show the real and the virtual world, HMDs are using different tech-niques: − Non-see-through:

The real world is being recorded with a camera. Both images, real and virtual world, are presented to the user on a non-see through display.

− See-through: The virtual world image is projected onto the transparent display in front of the eye. Those systems are using tracking sensors to correlate the virtual and the real world image.

To compute the image and to allow interaction HMDs are connected to some portable and possi-bly wearable computer. They can be used in conjunction with all kinds of input interfaces like wearable keyboards or keypads as well as speech recognition and voice response.

Another concept often cited with the use of HMDs are data gloves that can detect user movement and gestures and transform them into commands to control a device.

Recently, a prototype of a retinal scanning display was developed which is displaying images on top of the retina. A low-intensity light is projected on the retina and it is scanned with light at high speed. The resulting image is displayed on top of the eyes.

However, such potentials are far away from market introduction. Anyway, they are promising diverse solution potentials on the long-term.

4.1.2.2 Network Technologies and Protocols

To be able to connect mobile devices to a network or with each other, these devices need to sup-port common network technology and protocols that are available for different mobility scenar-ios differing in available coverage and bandwidth. Devices presented in chapter 4.1.2.1 are pre-pared for the use in the following network environments. • (Wireless) Personal Area Networks (PAN/WPAN): PAN and WPAN networks are primar-

ily used to interconnect devices or device accessories using wired (e.g. USB, FireWire) and wireless network technology (e.g. Bluetooth, IrDA, ZigBee, Wireless USB). Connections are performed in an ad-hoc manner without the need of additional infrastructure (e.g. hubs or base-stations). Coverage of such networks is usually small (up to 100m) and bandwidth var-ies depending on technology used (between e.g. 9.6 kbit/s (IrDA) and 480Mbit/s (Wireless USB)).

• (Wireless) Local Area Networks (LAN/WLAN): In a Local Area Network, devices are con-nected using additional infrastructure such as switches, base-stations or access points and routers. The coverage is enhanced compared to PANs but is usually limited to a building or complex of buildings on a site. De facto technology for wired LANs is IEEE 802.3 Ethernet with a bandwidth up to 10 GBit/s and IEEE 802.11 for WLANs providing e.g. a throughput of 19 MBit/s at a data rate of 54 Mbit/s (IEEE 802.11.g).



• Wireless Wide Area Networks (WWAN): Wireless Wide Area Networks provide coverage all over the country using base-stations to refresh signal strength. These cellular networks (GSM, UMTS) provide connectivity at rather low bandwidth (e.g. from 9.6 kbit/s (GSM) up to theoretically 14.6 Mbit/s (HSDPA)).

Important and widespread wireless network technology that is available on the majority of de-vices described in section 4.1.2.1 is presented below.

4.1.2.2.1 Bluetooth

The Bluetooth standard describes a protocol for wireless personal area networks (WPAN). Pri-marily used for short range communication (1-100m) Bluetooth provides a bandwidth up to 3 Mbit/s. Connections are established in an ad-hoc manner using direct connections between de-vices. The application area for Bluetooth is the connectivity between small mobile devices (smartphone’s, PDAs and notebooks) as well as to connect wireless accessories (headset, key-board, camera). • Network architecture: Bluetooth networks consist of up to eight active nodes that are or-

ganized in a piconet. One node becomes the master node controlling communication with the other nodes (slaves). Several piconets that overlap each other in spatial terms create a scat-ternet. Both networks can operate simultaneously but have to share available bandwidth. Se-lected nodes that participate in several piconets can become bridge nodes allowing to inter-connect two piconets with each other.

• Security: There are three different transmission modes offering different qualities in terms of information security. The non-secure mode does not involve any security mechanism. Nei-ther authentication nor encryption is provided. With service-level enforced security, trans-missions are secured on the application layer allowing different security settings per service or application. Finally link-level enforced security provides authenticated and encrypted transmissions transparent to applications and services.

4.1.2.2.2 Wireless LAN

IEEE 802.11, better known as Wireless LAN, is a very popular technology to connect mobile and static devices. It is used in home, office and public environments and supported by many devices ranging from smartphone’s and PDAs to notebooks and desktop computers. Recent Wireless LAN protocols (i.e. IEEE 802.11g) provide a throughput up to 19 Mbit/s at a data rate of 54Mbit. Currently under work is a new standard (i.e. IEEE 802.11n) with a data rate of up to theoretically 600 Mbit/s allowing transmissions with a throughput of approximately 300 Mbit/s.

The coverage of Wireless LAN depends on the environment and radiated power (the latter is dependent on the corresponding terms and regulations). In Germany, legislation allows a client to send with a maximum of 100 mW providing coverage in the range of up to 300 m (intervisi-bility). • Network architecture: Wireless LAN supports different connection types depending on the

application and available hardware. In infrastructure mode many clients connect to one base station that can act as a bridge between wireless and wired networks. The ad-hoc mode offers clients to communicate with each other without designated access points. The wireless distri-bution system (WDS) can be used to wirelessly connect several access points with each other allowing to cover larger areas without explicitly connecting each base-station to a wired net-work.

• Security: Security for 802.11 based networks is available in form of encryption methods and authentication techniques. State of the Art for encryption of 802.11 based networks is Wi-Fi



Protected Access (WPA) that is being defined in IEEE 802.11i standard. It is using either the Temporal Key Integrity Protocol (TKIP) or the Advanced Encryption Standard (AES) to se-cure the transmissions. Authentication is available by using the Extensible Authentication Protocol (EAP)13 in conjunction with user accounting through e.g. RADIUS14 Services. Small wireless networks however are using shared encryption keys. Another approach for se-curity in wireless networks is to use IPsec15 or higher layer security and VPN16 protocols.

4.1.2.2.3 Cellular Networks

Due to their advanced coverage, cellular networks are another important network technology providing connectivity to mobile devices all over the country. This technology is primarily sup-ported by mobile and smart phones but other devices can be equipped with cellular network in-terfaces, too.

There are two major types of cellular networks supported by devices today. GSM, a second gen-eration network, provides voice and data services with a bandwidth ranging from 9.6 kbit/s to theoretically 473 kbit/s (EDGE17). At the same time UMTS (3G) networks are deployed, provid-ing a bandwidth from 384 kbit/s up to theoretically 14 Mbit/s (HSDPA18). Due to the size of cel-lular networks, roaming different cells and base stations without loosing a connection as well as roaming foreign networks (foreign service provider) was implemented right from the start. • Network architecture: In cellular networks, mobile devices are connected to a base station

that provides one or more radio cells. Several base stations are controlled by a base station controller that is responsible to handle radio negotiations with the connected mobile devices as well as initiating cell handovers if the device is moving out of coverage or if the cells ca-pacity is exhausted.

• Security: GSM and UMTS networks offer authentication using a SIM (subscriber identity module in GSM networks) or USIM (universal subscriber identity module in UMTS net-works) card. The card contains subscriber data used to authenticate a device in the network. To ensure confidentiality both technologies support and use encryption for transmissions.

4.1.2.3 Special Network Protocols

For the use in scenarios with high mobility, poor and intermittent connectivity and possibly no or sparse infrastructure, special protocols are needed to overcome connectivity problems. These protocols can bridge connectivity gaps and simulate seamless connectivity which is sufficient for some situations that do not require a real synchronous connection.

4.1.2.3.1 Mobile IP

Mobile IP19 is a network communication protocol designed by the Internet Engineering Task Force (IETF). With Mobile IP, devices can use and keep the same static IP address regardless of their location and network connection. This is important if a mobile device roaming different networks needs to be directly addressed.

13 Extensible Authentication Protocol (EAP), RFC 3748 14 Remote Authentication Dial-In User Service (RADIUS), RFC 2865-2869 15 Internet Protocol Security (IPsec), RFC 2401 16 Virtual Private Network (VPN). A VPN connects different hosts and/or networks with each using public net-

works. To ensure information security, the connection is established using an encrypted tunnel. 17 Enhanced Data Rates for GSM Evolution (EDGE), A communication method for GSM (2G) networks. 18 High Speed Download Packet Access (HSDPA), A communication method for UMTS (3G) networks. 19 Mobile IP, For IPV4 based networks RFC 3344. For IPV6 based networks RFC 3775.



The Mobile IP architecture consists of the mobile device, a foreign agent (the mobile device it-self or another designated host in the current local network) and a home agent. As long as the mobile device is located in his home network IP traffic is directly delivered to it. If the mobile device is connected to another network all IP traffic is routed using a tunnel between the home agent and the foreign agent. This even allows to keep connections alive while switching net-works. The Mobile IP protocol is transparent to higher network layers therefore common appli-cations do not have to be modified.

4.1.2.3.2 Delay/ Disruption Tolerant Networking

Delay and disruption tolerant networking20 (DTN) is a method to assure connectivity to and be-tween static and mobile devices that do not have a continuous and/or reliable network connec-tion. Initially this approach was developed for space travel and interplanetary networks where traditional routing methods failed due to the lack of continuous connectivity.

The main difference to common routing protocols is that if a direct connection to a host can not be established (yet) the data is sent using data bundles. Using store and forward mechanisms the bundle is being transmitted as far as possible using knowledge about possible routes and other DTN enabled hosts on the way to its destination. This kind of transmission enables communica-tion between hosts even if they will never have a direct connection. Through its characteristics synchronous communication is not possible in DTNs and applications need to be prepared for the asynchronous DTN communication behaviour.

4.1.2.3.3 Mobile Ad-hoc Networking

Mobile ad-hoc networks allow communication between and through nodes in environments with sparse connectivity and infrastructure. Nodes use self-configuration (zeroconf21) protocols to establish a connection with a neighbour node. Communication between nodes without a direct connection is performed using other nodes forwarding data. Single nodes can also operate as a bridge to other wired or wireless networks providing access to distant networks to all connected nodes.

This implies complex routing techniques compared to common hierarchical networks because each node acts as a router and needs to save own routing tables. Especially if a new node enters, moves or leaves the network the other nodes have to adapt and update their routing tables.

4.1.3 Key RTD Problems and Challenges/ Barriers

CuteLoop is aiming at using “networked devices enabled intelligence” for supporting actors of the integrated enterprise. Since it is not an objective of the CuteLoop project to develop new de-vices, a careful selection needs to be made of the most appropriate enabling technologies, cur-rently available in the market, also taking into account future potentials. Therefore, the character-istics of networked devices as presented in chapter 4.1.1 can serve for such a selection from a human operator perspective. They were also used to structure some of the key RTD problems which need to be taken into account along the project realisation.

20 Delay Tolerant Networking Research Group. http://www.dtnrg.org 21 Zeroconf, RFC 3927, Zeroconf protocols enable the dynamic configuration of IPV4 Link-Local addresses with-

out the need of dedicated infrastructure.



4.1.3.1 Human-Machine Interfaces

Specifically the specification, design and implementation of the human-machine interfaces for explicit interaction need to undergo a certain change, due to the heterogeneity of the available interfaces in the different types of devices. This could jeopardise an easy portability of software applications, beyond the recent restrictions of operating systems. New methodologies and strate-gies need to be found for coping with varying display sizes and individual/ user related charac-teristics to be considered for realising upcoming interfaces like voice user interfaces. Moreover, intended usage of tangible and tactile interfaces will impose additional requirements upon the devices as enabling technology. However, especially those technologies require further stan-dardisation for assuring portability as well as maintainability enabling the usage of software ap-plications over several device innovation cycles (e.g. mobile phones are often only used 1-2 years).

The realisation of a “networked devices enabled intelligence” benefits from using information which is generated by an implicit interaction of actors with devices itself or the overall ambi-ence. However, this requires the combination of data generated by e.g. user related or ambience related sensors (see also chapter 4.2). This data fusion faces diverse challenges related to the level of data detail, the time stamps of measured information as well as the need for correlating or enriching the data with a certain semantics. There is still a lack in generally available or used semantic models (i.e. ontologies) as well as the problem of combining information generated asynchronously and in distributed systems/ different networked devices. Also security in terms of authorisation and authentication for implicit interaction needs to be taken into account (i.e. enabling users for real implicit interaction, not requiring an interruption of tasks due to required administrative interaction like request for authorisation or access codes like passwords).

4.1.3.2 Device Mobility

In decentralised environments services and roles are distributed over several nodes or actors. Thus general problems are how to find entry nodes to access such an environment and how to discover services or particular nodes and actors inside. Therefore, even basic functionality like e.g. authentication evolves to a nontrivial task. It requires the finding of nodes responsible and competent to process the request, taking into account security issues e.g. in terms of bad nodes pretending to be responsible (threat of e.g. pharming).

Another challenge is to ensure information security for the participants of decentralized net-works. This includes the confidentiality of transmissions between the sender and receiver, e.g. by using end-to-end encryption, as well as data integrity, to assure that transmissions are not modi-fied by thirds, and availability of services taking into account the special characteristics of decen-tralised networks (e.g. deploying a service on several nodes to achieve redundancy).

Taking into account loosely coupled actors, specifically the authenticity of each needs to be en-sured to enable trusted business interactions. Many of the current trust services available are us-ing certification authorities (CA) for this purpose. Actors can register and identify themselves at a CA and use it to prove authenticity to others. However, those centralised CA need not be avail-able in decentralized environments. Therefore, other ways to ensure trust and authenticity need to be explored, especially when taking into account personal interaction of known actors in a close physical distance.

4.1.3.3 Connection with other Devices and Interaction of Actors

To send and receive information and data, devices need to be able to connect to other devices and networks. Especially to allow mobile users roaming between different networks (different



technology and service provider) is a technological challenge. Hence, another RTD problem, when talking about seamless user-device interaction, is to ensure connectivity taking into ac-count the user’s needs, available networks and periods with no connectivity. From technical point of view, there are four major roaming situations that a mobile user can be confronted with: − No network coverage: In this situation a connection is not possible. Application design

needs to consider such periods with no connectivity and buffer requests for later asynchro-nous transmission when connectivity is restored. If user interaction requires synchronous communication, transparent connection handling is not possible and the user must be noti-fied.

− Roaming the home network: While connected to the home network, roaming is per-formed using a cell handover. Users are assigned to a cell (base-station) taking into ac-count their movement (direction and speed), the cells signal strength and capacity. Trans-parent connection handling is possible.

− Roaming foreign networks (Foreign Service provider): A user leaving the network cov-erage of his home network can use other available networks depending on roaming con-tracts between concerned service providers or by negotiating individual contracts. Trans-parent connection handling is possible but non-technical factors like costs, security issues and trust, as mentioned already above, need to be considered.

− Roaming a network with heterogeneous network technology: Roaming a network with heterogeneous network technology involves inter system handover which is available on two different layers. On the network layer inter system handover allows seamless connec-tivity that is transparent to the user and applications. For instance, in cellular networks inter system handover enables seamless switching between 2G (GSM) and 3G (UMTS) net-works if supported by devices and service providers. Due to a clash of interests, service providers do not allow inter system handover to some networks (e.g. between cellular networks and Wireless LAN). Therefore, the second option to perform roaming is to do it on the application layer. Prepared applications can automati-cally connect and disconnect from supported networks. User interaction is necessary only if there is no known and ‘configured’ network available.

Application design needs to consider these situations and try to find the best trade-off in terms of transparent connection handling and user involvement. Moreover, for enabling sound architec-tural decisions also a careful analysis of the degree of autonomously operating devices versus a highly interdependent operation of peers is required. The devices need to provide the required amount of computing performance, storage and bandwidth in accordance to the amount of lo-cally executed functionality. This can be compared to classical thin and fat client architectural approaches.

4.1.3.4 Intensity of Device Usage

The intensity of device usage generally determines the related consumption of energy. This is of specific importance when using wireless devices with battery power supply. This has to be con-sidered for both extremes: • Active and continuous usage: Generally highest degree of energy consumption. Due to lim-

ited battery life, current devices like e.g. PDA and tablet PC are only offering a usage dura-tion of up to several hours, imposing additional efforts to the user in exchanging battery power supply and for taking care of recharging batteries. Moreover, software development



needs to support the timely breakdown of an application due to a lack of energy supply22, caused by e.g. battery change.

• Passive and discontinuous usage: The passive usage disburdens the user from taking care of devices. Interaction push principles eliminate the requirement of a continuous check of an application by the user (e.g. as realised by SMS and push email applications). However, the “standby operation mode” needs also to be based on a careful analysis of the interaction prin-ciples of the actors, since an application breakdown or a shortage of power supply won’t nec-essarily be noticed by actors specifically in scenarios of a discontinuous usage as well as combined with the absence of users.

Moreover, this characteristic will be further considered concerning the usage of RFID tags. Spe-cifically active RFID tags in passive usage which are using a battery power supply, can be con-fronted with extreme requirements concerning discontinuous usage and life-time. Such examples are currently observed in localisation scenarios, where the active tag will support its localisation by sending radio signals on demand. Those scenarios need also be reflected by careful selection of the device technology to optimise power consumption by selecting most appropriate strategies taking into account active, semi-active and passive operation modes or even combinations of different strategies according to the related application scenario.

4.2 Sensors

The usage of sensors was analysed within the food application scenario of the CuteLoop project, since specifically the food chain is handling fresh products, which are characterised by short time periods for selling the product. Therefore, the deployment of sensors observing the environ-mental area around fresh food products is an important source of information in order to recog-nize and prevent loss of product quality.

Two main consumer requirements are quality and freshness of fruits and vegetables, which have a strong impact on the buying decision. In addition, all kinds of fruits and vegetables should be available independently of the season and with a continuous quality. This chapter discusses first main impacts on quality during postharvest and transport and it gives an overview of sensor technology to measure these.

4.2.1 Influences on the product quality during transport

In the supply chain the quality of fruits and vegetables is influenced by postharvest processes like transport and storage. These processes have different impacts on the product quality. During long transportation and storage processes, the product quality is affected by changes of the envi-ronment of the product. Important impacts on the product quality are high or low temperature, low humidity, intensive light exposure, negative influences by other fruits leading to additional ripening, shrinkage, dehydration and off-flavour. The transport planning has to deal with the risk of quality failures caused by environmental factors [Jedermann06]. Quality failures lead to defi-cits on delivery commitments, which have a negative impact on revenues. All extrinsic factors, e.g. temperature and humidity, have different impacts on the product quality, which is described by intrinsic factors of fruits and vegetables. In this case, the most important intrinsic factors are taste, freshness, color, nutritional value and the size of these products [Balas02]. All intrinsic factors are influenced by extrinsic factors. Meeting the consumer’s expectations, these impacts have to be minimized along the different stages of the supply chain.

22 Also instable availability of WLAN adapters due to low battery power need to be taken into account. Own ex-

perimentation with PDAs showed that no WLAN based connection with an access point was possible already from 25% of remaining battery power and less.



An important extrinsic factor is temperature, which has wide range of influences on the product quality. High temperature has positive impact during the ripening process and some negative effects in the postharvest processing of fruits and vegetables. A consequence of varying tempera-tures during transportation is transpiration of humidity from the product to the environment. Transpiration increases the dehydration process and therefore the freshness of the product is de-creased. Optimal storage temperature ranges for fresh fruits and vegetables are shown in the fol-lowing Table 5.

Table 5: Optimum storage temperature for fresh fruits and vegetables [Charalambous93].

Optimal Storage Tem-peratures Commodity

0-5 °C (cold storage)

Apples, Apricots, Artichokes, Asparagus, Beans (Lima), Beets, Broccoli, Brussels, Sprouts, Cabbage, Cantaloupes, Carrots, Cauliflower, Celery, Cherries, Collards, Corn, Dates, Figs, Grapes, […]

5-10 °C (cool storage)

Avocados (ripe), Beans (Snap), Blueberries, Cranberries, Cucumbers, Eggplant, Melons (Ripe), Okra, Peppers, Pineapples (Ripe), Squash (Summer), Tangerines, […]

10-18 °C (slightly cool storage)

Bananas, Coconuts, Grapefruit, Limes, Lemons, Mangoes, Melons (un-ripe), Nuts, Papayas, Tomatoes, Sweet Potatoes, Pumpkins, […]

18-25°C (room temperature storage)

Avocados (unripe), Nectarines (unripe), Onions (dry), Peaches (unripe), Potatoes, Watermelons

The shown individual preferred temperature ranges have to be considered in the storage and transportation processes to prevent quality losses.

The air humidity is also an extrinsic factor, which has an influence on the product quality. Dur-ing transportation, imbalances between humidity concerning air and product can occur. This im-balance is caused by changing the products environment from a defined storage environment to a different environment in the vehicle. Fruits and vegetables are biologically used to balance their intrinsic humidity with the humidity of the environment. This can also cause dehydration, linked to the impacts of temperature.

The time between the harvest and the arrival at the point of sale has also an influence on the product quality. The biological degradation process starts after the harvest and could be mini-mized by different methods like e.g. cooling and modification of the atmosphere. An indicator of biological degradation is the ethylene concentration in the environment of the products. In higher concentrations, this gas causes damage to the crop. Without cooling and atmosphere control, the degradation will cause quality downslide through the ethylene. Long storage periods can only be realized under controlled atmospheric conditions and temperature control.

Therefore, monitoring of these extrinsic factors is needed to maintaining the product quality. The monitoring during transportation currently takes place without specific technology. The regula-tion of temperature and humidity is not attached to the optimal temperature ranges of fruits and vegetables in due to their requirements. In addition, the orders of retailers often include different kinds of fruits and vegetables with different specific optimal temperature profiles [see Frischelogistik05].

Since 2004 the monitoring of transport parameters is legally required by EU regulations [see Jedermann06]. Currently, there are different technical applications available, which can collect information about the products environment. Data logging of parameters was the first develop-ment to meet these regulations. These data logging devices were attached to the vehicle. The



reporting of this data was managed by print-outs and meter-reading or radio transmission. The main aim of this technology is to give a chance for intervention in critical situations. But it wasn’t reached since the development of real-time quality data transmission realised by wireless sensor networks and high technological communication devices is still not practically realised.

4.2.2 Sensor Technology

A sensor is an electro technical device that measures physical quantities from the environment and converts it into a signal which can be read by an instrument. All measurement systems in-clude different types of sensors, which are able to monitor a wide variety of ambient conditions that include the following [see Akyldiz02]:

− temperature, − humidity, − vehicular movement, − lighting condition, − pressure, − soil makeup,

− noise levels, − the presence or absence of certain kinds of objects, − mechanical stress levels on attached objects, and − the current characteristics such as speed, direction, − and size of an object.

An example of a temperature sensor is shown in Figure 14.

Figure 14: A Temperature sensor.

The difference between a smart sensor and a sensor in the classical meaning is the included abil-ity to communicate its data. Smart sensors are able to link data between them and the object they are attached to. The communication aspect of smart sensors can be used to transfer information between the sensor and a recipient [Haller08].

4.2.3 Implementation of smart sensor technology for quality monitoring during transport

In 2006 the DEUTSCHE TELEKOM AG announced a new patent to the WORLD INTELLEC-TUAL PROPERTY ORGANIZATION (No. WO/2006/072225, see WIPO08) about a transport monitoring system using auto-id technology, identifying the goods in the vehicle in combination with GPS for online track and tracing and GSM for data transmission.



Figure 15: Transport monitoring system [WIPO08].

With this technology the real-time identification and track & tracing of goods is possible. But it doesn’t include the transmission of quality-related data.

[Jedermann07] extended this system deploying a wireless sensor network using the RFID tech-nology for environmental observation in the cargo area. The wireless sensor network (WSN) included an ethylene gas sensor for evaluating the ethylene concentration in the cargo area and a RFID-Tag for transmission. The sensor data is received by a RFID-Reader and transmitted with a linked GSM module. A software agent has access to this data and it compares the received data from the vehicle with critical levels of ethylene concentration for different products. The soft-ware agent calculates the time in which the ethylene has no critical influence on the product quality. This technology enables the intervention in critical situations, online track and tracing and it enables the control of product quality during transport. In Figure 16 this approach is illus-trated in two parts. The first part (“Figure 1”) shows the monitoring process and the usage of different technology. The second part (“Figure 2”) shows the front-end of a software application for observing the goods during transport.



Figure 16: Overview of the JEDERMANN et. al approach [Jedermann07].

The implementation of RFID-technology in wireless sensor networks has some restrictions. The most important restriction is the power supply. Active RFID-Tags, which are used in this ap-proach, need a power source. This power source has to last as long as the transport takes. CHO et. al for example, developed a RFID-Tag Chip with integrated sensors for wireless environment monitoring needing only 5.1 µW.

4.2.4 Conclusions

Sensor Technology combined with RFID-Technology and communication devices enables a real-time observation of vehicles and goods during transport. This real-time observation might be a service for different kinds of organisations. The GSM communication network is not available all over the world. Satellite communication attached to a WSN might be a further development in the CuteLoop project for transmitting real-time data during transport.

Quality-related information is needed to maintain the product quality during transport. The chance for intervention in critical situations rises with real-time data available. This prevents the loss of cargo due to quality deficits. A good example is the transportation of fruits and vegetables from southern Europe states to Germany. The average transport time from Spain to Germany takes about 50 hours. In this time, the product quality decreases under insufficient conditions. In the case of a malfunctioned cooling system the described system sends real-time information to the owner of the cargo. The cargo can brought to a nearby cold storage house until the cooling system of the vehicle is repaired or a replacement is advised.

Alteration of the First-In-First-Out System in warehousing is another aspect of this technology [Jedermann07]. The goods with the highest negative impact, which are still disposable, should be



transferred to the point of sale first. Currently, it is possible that fruits and vegetable can be ex-posed to different negative impacts during transport. The FIFO System provides an order from the first delivered to the latest delivered good. It doesn’t consider the different levels of quality from the different products, which is important for the disposability of fruits and vegetables.

In conclusion, the utilization of wireless sensor technology has to be a part of further research in this project on services in the different stages of the food supply chain.

4.3 RFID Tags

RFID tags can be characterized as passive, semi-passive, or active. Traditional passive tags are typically in “sleep” state until awakened by the reader’s emitted field. In passive tags, the reader’s electromagnetic field acts to charge the capacitor that powers the badge. Due to the strength of the signal that is required, passive tags are most often used for short read-range appli-cations (<1.5 m) and require a high-powered reader with antenna capable of reading the informa-tion. Passive tags are often very light, compact, and have unlimited life spans.

Another category of tags is commonly referred to as semi-passive (also called semi-active and/or battery assisted RFID). These tags communicate with the reader as if they were passive tags but have a battery on board in order to support specific functions, e.g. to store periodic temperature information from an onboard temperature sensor.

The active tags are typically powered by an internal battery (that lasts several years but whose duration strictly depends upon the application) and are utilized for long read-range applications up to 100 m. Active badges can continuously emit a detectable signal and are typically read/write with a higher total memory. Due to these increased capabilities, active tags are heavier, more expensive, and have limited life spans.

Active RFID tags have the opportunity to initiate an event by themselves. Because the communi-cation range is in most cases large enough to cover the entire desired area, tags have the oppor-tunity. In combination with a sensor this provides a powerful tag to communicate data to readers at all times. This kind of tags can be used e.g. in various planning and alert integrated systems that will provide alarms when something is occurring which has not been foreseen by the inte-grated system. In parallel there are action activated tags, which transform the energy of the ac-tion to generate enough power for the tag to respond [Kopti04] (e.g. based on chemical reaction in combination of liquids or by using movement as well as pressure).

Once a tag is placed, the basic components needed to collect the tag information and pass it to the proper application are the readers and the RFID middleware. The readers are the devices ca-pable of activating the tags and having them provide their data. RFID middleware is the software system needed to perform a “sensible” reading, i.e. whenever a contemporary reading of multiple tags is needed it discards duplicates and selects the only data relevant to the application.

Nowadays, each type of tag can by read by dedicated equipment. This means that an HF Reader is needed to read an HF tag and a different reader is needed to read a UHF one.

A characterization of readers for passive and active tags is presented below: − Readers of Passive RFID tags:

○ High power emitted (max. 4W) in order to activate passive RFID tags ○ High power consumption (rank of Watts) ○ Operating ranges of a few meters



○ Passive Readers can read simultaneously a number n of RFID tag with a reading speed of a few seconds (n>100)

○ Reader comprises the antenna, anti-collision systems (microprocessor + software +memory), RF transceiver, network interfaces (Ethernet, Wi-Fi, GSM, etc.)

− Readers of Active RFID tags: ○ Low power emissions (10-20 mW) ○ Reduced power consumption (rank of mW) that allows integration in handheld de-

vices ○ Long ranges (20-100 m) ○ Active readers can read simultaneously different RFID tags (hundreds of RFID tags)

with high reading speed (milliseconds) ○ Readers include an antenna that can be integrated, an anti-collision system (micro-

processor + software + memory), a RF transceiver, network interfaces (Ethernet, Wi-Fi, GSM, etc.).

The capabilities of the RFID system are very dependent on the carrier frequency at which infor-mation is transported. The use of lower frequencies provides larger wavelength and a coupling effect between RFID tag and reader more similar to primary and secondary coupling inside in-ductors. This causes the range to be shorter in LF (~125 kHz) and HF (~13.56 MHz) bands than in UHF (~900 MHz) and microwave bands (>2.45 GHz): for UHF and microwave as a matter of fact, the coupling between tag and reader is performed by backscattering (the electromagnetic wave is propagated from the reader and reflected by the RFID and modulated according to the specific information of RFID tag). The range that can be achieved using the same radiated power as in case of LF is much higher for UHF and microwave RFID system, depending on propaga-tion conditions as well as on regulatory limits.

Due to government regulation, different parts of the electromagnetic spectrum are assigned for different uses. The three frequency ranges that typically distinguish RFID systems are low, in-termediate, and high. There are currently four frequency bands in use around the world for RFID applications (see also [Finkenzeller02]). Within these bands a number of frequencies are ad-dressed by RFID standards and used by manufacturers in proprietary applications.

These frequency ranges and associated information describing typical system characteristics and areas of application are presented in the following Table 6. Table 6: RFID frequency bands and applications.

Frequency Band Characteristics Typical Applications Typical Range

Low Frequency 30-300 kHz ITU Band 5

125-135 kHz Short to medium read range Coupling: Magnetic, Electric Inexpensive Low reading speed

Access control Animal Identification Inventory control Car immobilizer

Few centimetres

High Frequency 3-30 MHz ITU Band 7

13.56 MHz Short to medium read range Coupling: Magnetic, Electric Potentially inexpensive Medium reading speed

Access control Smart Cards

Few centimetres (could be slightly enhanced using particular anten-nas)



Frequency Band Characteristics Typical Applications Typical Range

Ultra High Fre-quency 300-3000 MHz ITU Band 9

433 MHz 860-960 MHz 2.45 GHz Long read range High reading speed Coupling: Electromagnetic Line of sight required for micro-wave backscattering systems Expensive

Railroad car monitoring Toll collection systems

Under 10 meters

Super High Fre-quency 3-30 GHz ITU Band 10

5.8 GHz Long read range Line of sight required for micro-wave backscattering systems Coupling: Electromagnetic Expensive

Toll collection systems UWB Localization

100 m and over

Further explanations concerning the RFID application characteristics are presented in the Annex in chapter 7.

CuteLoop 5 Conclusions


5 Conclusions

The envisaged RTD results of the CuteLoop project shall specifically enable customers within a supply chain relation, to coordinate or “to drive” the interaction within the integrated and net-worked enterprise. To achieve this, the major project idea is to realise a type of infrastructure, which is capable of exploiting the vast potentials of networked devices, RFID technology and Global Navigation Satellite Systems (GNSS). This “type of infrastructure” is considered as a combination of architectural approaches, software applications (i.e. software services and agents), security enablers, interaction models as well as diverse types of basic enabling technolo-gies. These topics were used to structure the analysis of the state-of-the-art, also enabling the distribution of the project work in between the complementary expertise of the CuteLoop project partners. The analysis of the state-of-the-art is summarised in accordance to this structure in the following: • Architectures – Combination of EDA & SOA: The basic prerequisite for achieving such

new visions is the careful realisation of an appropriate architecture. In relation to the envis-aged approach of decoupling workflows, decentralised technology and asynchronous interac-tion there is the special need for mechanisms to balance the level of coupling. This means that the CuteLoop system must somehow permit not only oblivious communication, but also direct interactions between the users of the system. The “Event-Driven SOA” which connects heterogeneous applications needs to provide multi-channel access to the envisaged function-alities, via multiple interacting devices and over a variety of network protocols. Service in-teractions need to be routed through diverse protocols, and need to be transformed from one protocol to another where necessary. On the top of that, there is the need for standardisation in the Event Driven Architecture world, especially for describing and exchanging events. Currently, EDA application use unstructured information to exchange events, and therefore, mostly simple event types like alerts or acknowledgements are used to realise system features and the process related functionalities.

• Event-Driven Agents: When initially analysing the potentials of current software applica-tions, especially software agents were considered as most appropriate alternative to support the achievement of the CuteLoop project objectives. Agent frameworks are available, while even multi-agent systems are usually easy scalable. Nevertheless, most experience is based on research and experimental work. They haven’t been applied in real industrial environ-ments for very long. Problems like firewalls and optimised communication protocols are im-peding the practical realisation of agent based systems. In parallel, compromises must be found between limiting agent mobility and potential network exposure and vulnerability. Furthermore, to establish trust in between collaborating business partners along supply chains, it need to be assured that the agents are not overstepping their boundaries from both functionality and content. Maintaining data integrity and performing a certain degree of au-thentication are indispensable for agents deployed in a potentially insecure environment.

• Security: For realising security and trust, especially mechanisms that are simple enough to be deployed by an SME, but effective enough to garner the trust of e.g. large food retailers will require new combinations of security technologies. To realise an approach for achieving interoperability, possibly the combination of federated security mechanisms with agent tech-nologies to shield the SME user from the complexities of federated mechanism administra-tion task might provide a way forward. Also the lack of information consistency is challeng-ing the possibilities for tagging information for security and access purpose. From a practical point of view, the supply chain actors have in place existing systems that represent substan-tial investments and whatever security and authentication mechanisms that will be developed by the CuteLoop project they will need to work with several underlying existing system in-

CuteLoop 5 Conclusions


frastructures. These may in fact impose conflicting approaches that will need to be addressed with higher wrappers and other tools that enable interoperability of different systems.

• Interaction Models: The existing systems as well as the new technologies need to reflect the needs of the business processes as well as to serve the heterogeneous requirements of the dif-ferent actors, while the multi-dimensionality of the problem is difficult to solve and requires the incorporation of different views and their integration into a ‘balanced’ solution approach. Also the analysis, modelling and simulation of chains and chain developments in a multi-dimensional scenario are not yet well developed. Envisaged reference models and the realisa-tion of a usable approach will require the incorporation of tools and approaches from a vari-ety of disciplines. On top of that, flexibility of systems need to be considered as a key feature for future business interaction to cope with market trends and consumers’ interest. This will be further taken into account by CuteLoop, on how to support the realisation of new govern-ance structures, when realising ICT solutions, spanning several actors and supply chain stages.

• Traceability Services: As soon as product and process related data need to be collected or even being traceable over the chain, further problems arise. To establish a traceability link on an item sent between two parties in the chain, the receiver of the item must refer to the item using the same identification the sender used. This may sound trivial, but in daily business processes gives rise to many problems related to data capture. The actors along the chain are also concerned about their competitiveness and are specifically afraid of intended or also un-intended provision of data related to e.g. their suppliers, schedule or costs. Technical prob-lems related to e.g. interoperability of internal traceability systems are often caused by build-ing them on top of existing internal systems, which are carrying the data relevant for tracking and tracing.

• RFID and GNSS: Upcoming enabling technologies for tracking and tracing are RFID and GNSS as well as their combined usage. There are already a large amount of application ex-amples of those technologies, while several applications of these technologies are already fully established in the market. However, especially GNSS is still facing problems with re-spect to technical availability for indoor positioning, which is also one of the key shortcom-ings in business scenarios. RFID is especially facing problems in reference to privacy, costs and read rates. Especially in comparison to barcodes, there are also shortcomings in reference to locating the specific place of an RFID tag attached to an item within a large amount of other items (e.g. tagged crates on a pallet) as well as the need to have an electronic reader, while a barcode can also be read by the human operator.

• Networked Devices: Future potentials are also imposing additional difficulties and complex-ity on the specification, design and implementation of ICT based solutions. This is also true for the usage of networked devices, which are undergoing very short innovation cycles. New development strategies will also be sought in CuteLoop for coping with e.g. varying display sizes, restrictions of operating systems or individual/ user related characteristics to be consid-ered for realising user interfaces like touch screens and speech recognition. Moreover, it will be further analysed in the food and craftsmen application scenarios, if there are already ap-plication potentials for tangible & tactile interfaces as well as for wearable technologies.

The CuteLoop project is using the analysis of the state-of-the-art especially for the next tasks within the requirements analysis and the conception of the envisaged CuteLoop results. It repre-sents a comprehensive overview which will serve as reference for analysing the food and con-struction analysis scenario requirements as well as baseline for elaborating the technological concept of the CuteLoop project. Moreover, as member of several RTD and industry communi-ties/ clusters, CuteLoop will also search and promote further experience exchange with the re-search and the industrial target audiences.

CuteLoop 6 References


6 References

[Abhisam08] ABHISAM (2008) http://www.abhisam.com/WP.htm (last accessed July, 21st 2008).

[ActiveMQ08] Apache ActiveMQ Homepage. http://activemq.apache.org/.

[Agriview08] AGRIVIEW http://www.agriculture.gov.sk.ca/Agriview_July08_14 (last accessed July, 21st 2008)

[Akyldiz02] AKYLDIZ, SNKARASUBRAMANIAM, CAYIRCI (2001), “Wireless sensor net-works: a survey” in: Computer Networks Nr. 38 (2002) pp. 393–422

[Allflex08] ALLFLEX (2008) http://www.allflex-tierkennzeichnung.de/rind_elektro.htm (last accessed July, 21st 2008).

[Babaoglu06] Babaoglu, O. et al. Complex Systems Research in FP7. s.l. : European Commision, 2006. available at ftp://ftp.cordis.europa.eu/ist/fet/co-16.pdf.

[Balas02] BALAS (2002), „Qualitätskomponenten gartenbaulicher Frischprodukte (Obst)“In: Sammelband zur Jahrestagung 2002 in Klosterneuburg“ der Arbeitsgemeinschaft landwirtschaftlicher Versuchsanstalten

[Banks07] J. Banks, D. Hanny, et al., RFID applied, Wiley, edition 2007

[Bloomberg04] Bloomberg, Jason. 2004. EVENTS VS. SERVICES: THE REAL STORY - BEST PRACTICES IN EVENT-DRIVEN SOA. s.l. : zapthink, 2004.

[Cast79] Cast, .J. 1979. Connectivity, Complexity and Catastrophe in Large-Scale systems. New York : John Wiley, 1979.

[Charalambous93] CHARALAMBOUS (Edt.), FLOROS, J.D. (1993) “The Shelf life of fruits and vege-tables” In: “Shelf Life Studies of Food and Beverages”, Elsevier

[CIES] CIES – «Implementing Traceability in the Food Supply Chain» http://www.ciesnet.com/pfiles/programmes/foodsafety/impl-traceab-doc.pdf

[CompTIA04] CompTIA. 2004. European Interoperability Framework - ICT Industry Recommenda-tions -White paper. http://www.comptia.org. 2004. http://www.comptia.org.

[ECR] Efficient Consumer Response (ECR) Europe http://www.ecrnet.org/

[ECRTRA] «Using Traceability in the Supply Chain to meet Consumer Safety Expectations» http://www.ecrnet.org/04-publications/blue_books/pub_2004_traceability_blue_book.pdf

[EPC08] EPCglobal: http://www.discoverrfid.org/service/about-us.html

[EPCG] EPCglobal http://www.epcglobalinc.org/

[ERA06] ERA-Build Final Report. Review of the current state of RFID Technology, its use and potential future use in Construction; June/July 2006.

[EUFL] EU Food Law http://ec.europa.eu/food/food/foodlaw/index_en.htm

[EUTRACE] The EU «Trace» project http://trace.eu.org/

[Finkenzeller02] Finkenzeller, Klaus; RFID-Handbuch: Grundlagen und praktische Anwendungen in-duktiver Funkanlage, Transponder und kontaktloser Chipkarten. Hanser Verlag, Mün-chen, Wien 2002.



[Frischelogistik05] FRISCHELOGISTIK (2005) “Portrait Dachser Lebensmittel-Logistik” in Frischelo-gistik AUSGABE 3/2005 S.11-14, Agrimedia

[FTK06] FTK (2006) Forschungsinstitut für Telekommunikation in: EC-Net Chancen für den Mittelstand, Dortmund in: „RFID – Eine Chance für kleine und mittlere Unterneh-men“ (Hrsg. Bundesministerium für Wirtschaft)

[Gartner07] Hughes, Andrew; Food Traceability in Europe : Take it seriously for a Competitive Advantage. Gartner Industry Research, ID# G00148894; June 2007.

[GS1] GS1 http://www.gs1.org/

[GTNET] TraceTracker and The Global Traceability Network, http://www.tracetracker.com/

[GTS] The GS 1 Global Traceability Standard http://www.gs1.org/productssolutions/traceability/gts/

[Haller08] HALLER S.; HODGES S. (2003) “The Need for a Universal SmartSensor Network” http://www.autoidlabs.org/whitepapers/ (last accessed July, 15th 2008)

[Helsinger04] Helsinger, A., Thome, M, Wright, T., Cougaar: a scalable, distributed multi-agent architecture, in IEEE International Conference on Systems, Man and Cybernetics, 2004, Volume: 2, pp.1910-1917.

[IBMETT] IBM Traceability Survey and Study – «Establishing Trust through Traceability» http://www-03.ibm.com/press/us/en/presskit/21757.wss

[IBV] IBM Institute for Business Value http://www.ibm.com/iibv

[ISO22005] «Traceability in the feed and food chain -- General principles and basic requirements for system design and implementation» http://www.iso.org/iso/catalogue_detail?csnumber=36297

[ISO6523] Structure for the Identification of Organisations, http://en.wikipedia.org/wiki/ISO_6523

[ITU05] International Telecommunication Union; ITU Internet Reports 2005: The Internet of Things. Geneva, November 2005; www.itu.int/internetofthings/.

[JBI05] JSR 208: Java Business Integration (JBI). 2005. http://jcp.org/en/jsr/detail?id=208.

[JBISpec05] JSR-000208 Java Business Integration Evaluation 1.0 Final Release. 2005. available at http://jcp.org/en/jsr/detail?id=208.

[Jedermann06] JEDERMANN, R.; et. al (2006): Applying autonomous sensor systems in logistics; Combining Sensor Networks, RFIDs and Software Agents. In: Sensors and Actuators A (Physical), 8th November 2006 Vol. 132, Issue 1, Pages 370-375

[Jedermann07] JEDERMANN, R.; et. al (2007) Transport scenario for the intelligent container In: Hülsmann, M.; Windt, K (eds.): Understanding Autonomous Cooperation & Control In Logistics - The Impact on Management, Information and Communication and Ma-terial Flow. Springer, Berlin, 2007, pp 393-404

[JMS08] Java Message Service (JMS). http://java.sun.com/products/jms/.

[JTC07] RFID Technologies: Emerging Issues, Challenges and Policy Options, Institute for Prospective Technological Studies, JTC, European Commission, EUR 22770 EN, 2007.



[Kopti04] Koptioug, Andrei; Jonsson, Peter; Olsson, Torbjörn; Sidén, Johan; Gulliksson, Micke; Nilsson, Hans-Erik; New concepts in RFID: Action- Activated Tags. Poster from Mid-Sweden University, Dept. of Information Technology and Media, Electronic Design and Electronic Production Divisions; 2004. http://www.ite.mh.se/~elektro/forskningsweb/research/groups/system/rfid-filer/Poster_AAT0.pdf; last visited April 2005.

[Maloni06] Maloni, Michael; DeWolf, Frank; Understanding Radio Frequency Identification (RFID) and Its Impact on the Supply Chain. Penn State Erie, The Behrend College, RFID Center of Excellence; July 26th, 2006.

[Melski06] MELSKI, A. (2006) „Grundlagen und betriebswirtschaftliche Anwendung von RFID“ in: Arbeitsberichte Wirtschaftsinformatik Nr.11/2006 (Hrsg. M. Schuhmann), Institut für Wirtschaftsinformatik, Universität Göttingen.

[Metro06] METRO GROUP (2006) http://www.rfidatlas.de/images/stories/RFID_Fallstudien/metro_april2006.pdf (last accessed July, 17th, 2008)

[Michelson06] Michelson, Brenda M.; Event-Driven Architecture Overview: Event-Driven SOA Is Just Part of the EDA Story. s.l. : Patricia Seybold Group, 2006.

[Migros06] MIGROS (OSTSCHWEIZ) (2006) http://www.rfidatlas.de/images/stories/RFID_Fallstudien/migros_april2006.pdf (last accessed July, 17th, 2008)

[Miller06a] L.E. Miller, P.F. Wilson, N.P. Bryner, et al, RFID-Assisted Indoor Localisation and Communication for First Responders. ISART2006 conference http://www.antd.nist.gov/wctg/RFID/ISART06-Assisted-LocCom.pdf

[Miller06b] L.E. Miller, “Indoor navigation for first reponders”, A feasibility study. http://www.antd.nist.gov/wctg/RFID/Report_indoornav_060210.pdf

[MphasiS04] Don't Ask Us, We'll Tell You: Event-Driven Architectures for the Enterprise. s.l. : MphasiS Corporation, 2004. available at http://www.mphasis.com/pdfs/Event_Driven_Architectures.pdf.

[Mule08] Mule Homepage. http://mule.mulesource.org/display/MULE/Home.

[MWe01] SEDA: An architecture for well conditioned, scalable internet services. Welsh, M., Culler, D. e Brewer, E. 2001. Banff, Canada : s.n., 2001. 18th ACM Symposium on Operating Systems Principles.

[Nortura08] NORTURA (2008) http://www.rfidjournal.com/article/articleview/4208/1/1/ (last accessed July, 17th, 2008)

[OAS081] OASIS Web Services Reliable Messaging (WSRM) TC. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm.

[OAS082] OASIS Web Services Notification (WSN) TC. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn.

[OASIS] Organization for the Advancement of Structured Information Standards (OASIS) http://www.oasis-open.org/

[OECD08] OECD, Directorate for Science, Technology and Industry Committee for Information, Computer and Communications Policy; Working Party on the Information Economy, RFID Applications, Impacts and Country Initiatives, DSTI/ICCP/IE(2007)13/FINAL, 18-Apr-2008.



[Papazoglou07] Service Oriented Architectures: Approaches, Technologies and Research Issues. Papa-zoglou, Mike P. e Heuvel, Willem-Jan van den. 2007. 3, s.l. : Springer, 2007, The In-ternational Journal on Very Large Data Bases (VLDB), Vol. 16, pp. 389-415.

[Rizzotto02] Rizzotto, P., Wolfram, G. (2002), "Intelligent tagging – getting supply chain smart!", paper presented at the 2002 Official ECR Europe Conference, ECR Europe, Montjuïc 2 Conference Centre, Barcelona, Spain 22-24 April.

[RSS] Reduced Space Symbology – 2D barcodes and other barcodes http://www.gs1.org/productssolutions/barcodes/

[Sachsenmilch06a] SACHSENMILCH AG (2006a) http://www.rfidatlas.de/images/stories/RFID_Fallstudien/sachsenmilch_dezember2006.pdf (last accessed July, 17th 2008)

[Sachsenmilch07b] SACHSENMILCH AG (2007b) http://www.rfidatlas.de/images/stories/RFID_Fallstudien/sachsenmilch2_januar2007.pdf (last accessed July, 17th, 2008)

[Schmidt06] SCHMITD LEBKUCHEN (2006); http://www.rfidatlas.de/images/stories/RFID_Fallstudien/schmidt_dezember2006.pdf (last accessed July, 17th, 2008)

[Schneider08] Mike Schneider, RFID technology and its applications in the commercial construction industry http://e-pub.uni-weimar.de/volltexte/2004/159/pdf/icccbe-x_014.pdf

[Self03] Self, A., DeLoach, S, A., Designing and Specifying Mobility within the Multiagent Systems Engineering Methodology, in Special Track on Agents, Interactions, Mobil-ity, and Systems (AIMS) at The 18th ACM Symposium on Applied Computing (SAC 2003).

[ServiceMix08] Apache ServiceMix Homepage. http://servicemix.apache.org/home.html.

[SES07] SES ASTRA Tech Com (2007): Development of Advanced Galileo Applications and Services. Study conducted on behalf of the MCESR in collaboration with Telindus, Hitec, Siemens, IEE and P&T Luxembourg. Final Report

[Stokic06] Stokic, Dragan; Kirchhoff, Uwe; Sundmaeker, Harald; Ambient Intelligence in Manu-facturing Industry: Control System Point of View. The Eighth IASTED International Conference on Control And Applications; Montreal, Quebec, Canada, 24-26. May 2006, pp. 63-68.

[Strassner05] STRASSNER (2005), „RFID im Supply Chain Management“, Deutscher Universitäts-Verlag, Wiesbaden

[TRIM] Trimble Copernicus II GPS receiver data sheet http://trl.trimble.com/docushare/dsweb/Get/Document-312772/022542-004C_Copernicus_DS_0907_lr.pdf

[UBL] The Universal Business Language (UBL), http://www.oasis-open.org/committees/ubl/faq.php

[Vitaglione02] Vitaglione, G., Quarta, F., Cortese, E., Scalability and Performance of JADE Message Transport System, in AAMAS Workshop, Bologna, 2002.

[W3C08] Homepage of W3C. http://www.w3.org.



[Weimann08] F. Weimann, Phillip Tomé, et al., SARHA-Development of a sensor-augmented GPS/EGNOS/Galileo receiver for Urban and indoor environments http://www.sarha-project.info/download/SARHA_project_GeomaticWeek2007_v1.0.pdf

[WIKI] Definition of “Traceability” in Wikipedia http://en.wikipedia.org/wiki/Traceability

[WIPO08] INTERNET 1 WIPO – http://www.wipo.int/pctdb/images/PCT-IMAGES/13072006/DE2005001791_13072006_gz_en.x4-b.jpg last accessed on July 11th, 2008.

[WSDL01] Web Services Description Language (WSDL) 1.1. 2001. http://www.w3.org/TR/wsdl.

[WSEventing06] Web Services Eventing (WS-Eventing). 2006. http://www.w3.org/Submission/WS-Eventing/.

CuteLoop 7 Annex 1 – Current Solutions in Application Scenarios


7 Annex 1 – Current Solutions in Application Scenarios

7.1 Craftsmen Application Scenario

Construction is a major sector of any European country and thus of Europe as a whole. Construc-tion represents around 10% GDP and 50.8% of Europe’s gross fixed capital formation. It ac-counts around 2.4 million enterprises (EU22), of which 97% are SMEs with fewer than 20 em-ployees, making construction industry Europe’s largest industrial employer, thus implying sig-nificant responsibility for social issues, in particular training, health and safety. Furthermore, construction industry is of significant importance in generating employment – the so-called “multiplier effect” is that 1 person working in construction rises 2 further jobs in other sectors23. Also, and from an environmental perspective, some 50% of the raw materials taken from the Earth’s crust are used in construction and the built environment produces approximately one third of all greenhouse gas emissions. Therefore, due to these reasons construction was selected as primary industrial target for CuteLoop.

In relation with the level of adoption of ICT tools in the construction sector, this is considered to be very low when comparing with other important sectors. According with the study provided by e-business w@tch 2006, some barriers and also key application areas for ICT adoption in con-struction were identified. The study refers that, the construction sector is considered to be very conservative towards the adoption of ICT technology and the level of integration on the internal business processes is very low. Given the fact that the construction sector is location-bound is also a barrier to the development of the European market. The study also addresses the need to the implementation of collaborative systems and the realisation of productivity gains through ICT.

0

10

20

30

40

50

60

70

80

90

100

0 10 20 30 40 50 60 70 80 90 100

ePro

cure

men

t an

d eM

arke

ting

/ Sal

es

ICT infrastructure & internal processes

Construction

Hospitals

ICT M.

Food

Footwear

Shipbuilding

Tourism

Telecom

CE

Paper

( , )

Figure 17: e-Business Scoreboard 200624.

23 Communication from the Commission “The Competitiveness of the Construction Industry” COM (97) 539 of

04/11/1997, chapter 2. 24 This study was based on 16 ICT indicators (weighted by employment), aggregated into two sub-indices. The

population which represents the study, are firms using computers from 10 EU countries (CZ, DE, ES, FR, IT, HU, NL, PL, FI, UK). The size of the bubble indicates the number of persons employed in a sector (in relation to other sectors), as depicted in the Figure 17. Light blue indicates manufacturing, red indicates services and yellow indicates construction.



Some key application areas where ICT adoption is considered to be relevant are also highlighted in this study. These are: − Productivity, by tackling opportunity and need to realise the potential of efficient and ef-

fective production. − Internal business processes integration of many companies are poorly integrated as most

companies in the construction sector organise work around unique construction projects. − External collaboration, where construction companies usually collaborate around construc-

tion projects, and need to coordinate activities with stakeholders in external environment. − Establishment of a European construction market via e-procurement.

All these application areas where the adoption of ICT technology is considered to be relevant, address the need to couple with networked devices integrating RFID, GNSS. Such devices could be applied to construction applications areas in order to facilitate productivity, collaboration, procurement, etc. Five areas of adoption are considered to be most relevant when applying net-worked devices: − Tracking and tracing of components, vehicles, parcels etc; − Supply Chain Management and Logistics in order to increase efficiency; − Product identification by enabling using the right component and device; − Maintenance of service systems; − Track recording of components25.

The key processes to be addressed by the CuteLoop construction scenario are dealing with main-tenance & refurbishment by craftsmen. They are customers of a supply chain, which provides diverse construction materials, and several interactions between craftsmen, supply chain and consumers take place. The typical craftsman SME as represented by CAPEB (CuteLoop industry representative) has in average 3 employees. According to a FIEC 2006 study, Rehabilitation and Maintenance works represents 24% share of the total construction works.

The current status of the craftsmen processes in which concerns the information exchange sup-ported by IT tools is very poor. The specifications/documentation of construction work rarely exists and if something is available, it is not necessarily correct. The information of construction work is usually not shared between the craftsmen and consumer. There is generally rare and not organised communication in between different types of craftsmen (i.e. focusing on maintenance and refurbishment – not new construction). In that sense, there is the need to facilitate the re-cording and provision of: − Product characteristics (e.g. ingredients, type, producer) during craftsmen work; − The place where the material/product was installed in the house (i.e. for later localisation

of products; hidden pipes; hidden electric installation); − Need for tracking & tracing of the history of work in a building. Covering the specific ob-

jects and installations in a building. Single items/objects to be grouped by e.g. rooms, sys-tems (like heating systems) or critical elements (e.g. piece of wood).

Such a history could also be used for approaches like the “Health book of the house”, as pro-moted in France by CSTB (Centre Scientifique et Technique du Bâtiment; engl.: Scientific and Technical Centre for Building).

25 Source: ERA BUILD Final Report, RFID in construction, December 2006.



7.1.1 Existing projects of reference

7.1.1.1 MOBIBAT

MOBIBAT was developed in the scope of a project initiated by CAPEB based on the real world field experience of its members, 356 000 craftsmen companies around France. The elaborated concept was commercialised and is already operated in France by the service provider tibco mo-bile. It is a PDA based solution for craftsmen, enabling the mobile access to existing craftsmen specific legacy software. Standard interfaces were implemented for the legacy software of the ICT providers APIBAT, CIEL, EBP and SAGE who are largely used by most of the craftsmen all over in France as reference software packages in their daily management of their business (general or dedicated software packages for sales management, proposals, analysis, payrolls, accounting, technical libraries, etc.).

Figure 18: Overall system architecture of MOBIBAT (Source: Tibco mobile – http://www.mobibat.fr).

The mobile solution is providing an online access (i.e. reading and writing) to data in the existing construction specific IT systems. This enables the craftsmen to prepare e.g. offers and invoices at the construction site and even during the discussion and negotiation with their customers (i.e. consumers).

Moreover, it is possible to access catalogues of suppliers, to access the central address book, to use email push service, to manage construction tasks as well as to take pictures on site for further analysis and/or to be added to the offers for the consumer. The consumer can sign on the PDA itself and the information and data can be transferred automatically to craftsman’s server and management software without having to key-in again the data. The PDA is operated with a Win-dows Mobile 5 or 6 operating system.

7.1.1.2 Maintenance of Service Systems – Quality Control (Manufacturing of doors)

A door manufacturing company Swedoor (part of Danish Vest-Wood group) with production in Skåne applies a RFID tag on each and every door. Information about material and processes is stored in a tag and which makes it possible to follow the door through the whole supply chain.



When the door leaves the factory the information in the tag is copied to a database and from that Swedoor can use the information for invoicing, statistic and perhaps reclamation. The tag fol-lows the door out from the factory and can be used both by constructors and later on by caretak-ers of the estates. The technology comes from the American company Escort Memory Systems (EMS) based in Silicon Valley.

The technique offers the opportunity to make every door individual and the information stored in each door makes the invoicing easier. With the information stored within each individual door in the manufacturing the RFID tags can be used continuously throughout the whole supply chain26.

This solution makes use of RFID technology placed on each door which is produced. Informa-tion about the material is stored inside each RFID tag and it should be structured according the craftsmen requirements.

In a maintenance scenario, it is most essential to have the information about the product at the fingertips – for instance, information about the type of material, type of paint used, date of the last maintenance operation, etc.. For a craftsman point of view on a refurbishment scenario, this kind of data could be obtained directly by using a RFID reader.

7.1.1.3 Maintenance of Service Systems – Quality Control (Asset Maintenance)

Using tagging and Wireless Technologies for Asset Maintenance, this project supports the agenda for implementing change & continuous improvements set up by Rethinking Construction and the Strategy for More Sustainable Construction and help reduce waste, transparency within the supply chain and use of innovative technology:

1. Examine technical issues/business benefits of using tagging &wireless technology in the maintenance of buildings;

2. This project builds on previous work by Bovis Lendlease (on iTAG) and a DTI tagging project led by BRE, by using these technologies for maintaining/planning replacement of boilers in homes and fire doors/escalators;

3. Demonstrate how these technologies can be integrated into existing maintenance and as-set management systems by trailing their use in maintaining boilers in homes, and in tracking and maintaining fire doors/escalators.

This project seems to be relevant to explore on how and what kind of product information is stored for asset management to be performed by the craftsmen. Regarding to the boilers in par-ticular, it’s important to investigate the structure of the product information.

7.1.1.4 Product ID – Using the right Component and Device

Use of RFID & TETRA in Pumps and Pump Systems – this project27 aims to transfer and exploit the radical data carrier and item-attendant data management benefits offered by RFID technol-ogy to pump-manufacturers and pump-users. The technology is applicable both to manufactur-ers, where the item attendant data capacity can improve the efficiency and traceability of manu-facturing processes, and to the end users where the RFID tags will provide the capability for en-hanced asset management and maintenance, with the potential for remote monitoring and diag-nostics, intelligent distributed control and energy minimal control strategies through integration

26 see also http://www.oeresundsbron.com/object.php?obj=16402afd 27 Project Description: http://www.ictcarrier.co.uk/pages/0016.html; last visited on September 1st 08.



with TETRA. The BPMA (British Pump Manufacturers Association) has recognised the signifi-cance of AIDC (Automatic Identification and Data Capture) in general and RFID in particular. Applications of RFID in manufacture, particularly in the automotive sector, have pointed to both parallel and innovative applications potential in the pump manufacturing industry and user community. Key areas of application include manufacturing per se, field services/maintenance, predictive monitoring, and energy management systems, pump supply and service strategies. In seeking to establish the potential for RFID, the BPMA has identified the need for a forum to as-sess the attributes and applications base for RFID and associated technologies and formulate both action plans and support materials to assist industry members in the beneficial adoption of RFID data carrier technology.

Added value prospects for end-users through exploitation of RFID supported functions such as condition monitoring and profiling of pump usage. It could be relevant to look in more detail at how the integration model between the monitoring sensors network and the TETRA system was built, and also to try to establish a harmonized product information model to be used by crafts-men and stored inside each RFID tag.

7.1.1.5 Deconstruction of Equipment - Lifecycle

Product Lifecycle Management and Information Tracking Using Smart Embedded Systems.

PROMISE is an endorsed IMS project (IMS project no. 01008) and brings together a large inter-national partnership involving five IMS regions: EU, Switzerland, Japan, Australia and USA. The objective of PROMISE is to develop a new generation of Product Information Tracking and Flow Management system.

PROMISE will develop appropriate technology, including product lifecycle models, Product Embedded Information Devices with associated firmware and software components and tools for decision making based on data gathered through a product lifecycle. This is done to enable and exploit the seamless flow, tracing and updating of information about a product, after its delivery to the customer and up to its final destiny (deregistration, decommissioning) and back to the de-signer and producer.

The main elements of the PROMISE concept are: − Product Embedded Information Devices (PEID) based on a combination of suitable exist-

ing technologies such as bar-code, RFID transponders and short as well as long range wire-less communication technologies

− Local (short distance) connection mode for product data and information exchange − Internet (long distance) product information and knowledge retrieval − Data and information flows − Envisaged decision support software

The breakthrough contribution of PROMISE, in the long term, is to allow information flow man-agement to go beyond the customer, to close the product lifecycle information loops, and to en-able the seamless e-Transformation of Product Lifecycle Information to Knowledge. The PROMISE R&D implementation plan includes fundamental and applied research activities in the disciplines of information systems modelling, smart embedded systems, short and long distance wireless communication technologies, data management and modelling, design and adaptive production management for Beginning Of Life (BOL), statistical methods for preventive mainte-nance for Middle Of Life (MOL) and planning and management of product End Of Life (EOL).



Figure 19: The concept of PROMISE (see also http://www.promise.no).

The PROMISE project covers the product lifecycle information management after its delivery to the customer and up to its final destination and back to the designer and producer, where the vi-sion of CuteLoop is well fitted in.

It’s most of relevant for the CuteLoop to study Product Embedded Information Devices from the component point of view. Devices such as bar-code, RFID transponders and short as well as long range wireless communication technologies, which were exploited inside PROMISE, should also be studied in detail regarding their applicability inside CuteLoop scope.

7.1.2 Conclusions

Most results elaborated in the construction industry are addressing larger organisations taking into account the generation of benefits in the earlier supply chain phases, with respect to produc-tion, transport and warehousing. These references need to be taken into account when analysing the interfaces between the craftsmen work and the earlier phases in the supply chain. Potentials for facilitating information exchange over the complete product life-cycle exist, but need to be operated with technologies which are compatible to the specific requirements of the small craftsmen organisations.



7.2 Food Chain Application Scenario – RFID based Solutions

Radio Frequency Identification (RFID) is announced as a key technology for the Food Supply Chain [Rizzotto02]. The development of this technology, the standardization process and the approval in the environment are in progress. However, the area-wide implementation of the RFID-Technology is still at the beginning. Currently, there are few application scenarios, which are in an advanced state of development.

A survey among small and middle-sized business on the potential of the RFID-Technology showed that approximately 70 percent of the respondents pointed out high potentials in: − container and cargo management, − logistics, − traceability of goods and cargo [FTK06].

The inter-corporate use of Identification techniques is still not applicable [Melski06].

Similarly, this trend is also observed in the food industry.

7.2.1 Overview on the RFID-implementation scenarios in different stages of the food supply chain

The development of different RFID-solutions is also observable in the food supply chain. An overview on the organizations, which enforces the implementation of RFID in their business process are depicted in Figure 20. Some of them are in a advanced stage of development, most of them are currently in the Roll-out stage.

Grower Agriculturalsociety

ProductionIndustry/

manufacturerDistributor Retailer

Service Provider

Nortura

IFCO

Metro GroupSpar

MigrosTESCO

Wal-Mart

Marks & Spencer

Dole

EuroPoolSystem

Carrefour

METRO AG

Nestlé Gerolsteiner

Procter & Gamble

SachsenmilchAG

KraftSchmidt

Lebkuchen

Grower Agriculturalsociety

ProductionIndustry/

manufacturerDistributor Retailer

Service Provider

Nortura

IFCO

Metro GroupSpar

MigrosTESCO

Wal-Mart

Marks & Spencer

Metro GroupSpar

MigrosTESCO

Wal-Mart

Marks & Spencer

Dole

EuroPoolSystem

Carrefour

METRO AG

Nestlé Gerolsteiner

Procter & Gamble

SachsenmilchAG

KraftSchmidt

LebkuchenNestlé Gerolsteiner

Procter & Gamble

SachsenmilchAG

KraftSchmidt

Lebkuchen

Figure 20: Some important organizations with RFID-applications in the food supply chain.

Figure 20 shows that the stages with the highest participation in the development of RFID-applications are in the manufacturer and production industry and the top-selling retailers. There are only a few case studies from the other stages of the food supply chain currently available. However, this doesn’t mean that there are no ideas and current developments for RFID adoption.



Table 7: Case Studies from different publications [see RFID-ATLAS, RFID-JOURNAL 2008: Metro06, Migros06, Nortura08, Sachsenmilch06a, Sachsenmilch07b, Schmidt06].

Organization Metro Group Sachsenmilch AG Sachsenmilch AG Schmidt Lebkuchen

Gerolsteiner Brunnen GmbH & Co. KG

Migros Ostschweiz Nortura

Application area Distribution Warehouse logistics Production Production Track & Tracing

Cold chain manage-ment / Track & Trac-ing

Production

Branch Trade / consumer products Consumer products Consumer products Consumer products Consumer products Trade Consumer products

Products Wide range of goods All goods Cheese Fine German ginger-bread All goods Transport &

all goods different meat prod-ucts

Scope(s)

advanced asset management

lowering of storage costs

decrease of Out-of-Shelf-situations

Increasing the trans-parency in the supply chain Advancing the man-agement of special containers Identification and realization of cost reduction potentials Building a calculation base

Automation of the cheese ripening proc-ess to afford stan-dardization

Improve the Quality management activities in the production process

Reduction of wrong dosing in the produc-tion process

Implementation of legal regulations (VO (EG) 178/2002)

Traceability

Speed up processes

Documentation

Cold chain control

Optimized area man-agement

Advanced time man-agement in logistics

Increase the possibil-ity to take decisions in critical situations

Animal identification

Advanced quality management through transparency in the whole chain

Track and Tracing

Process

Improvement of the goods inward / intake and shipping process

Supply chain man-agement

Logistic processes in the storage Production process Production process

Warehouse logistic

Registration of goods movement

Transport Transport, slaughter, production

Results

Decrease of packag-ing about 17 percent; theft and product loss about 11-18 percent; out-of-stock situations about 9-14 percent

Accelerated and safe registration in the warehouse logistic processes; Increased flexibility;

Currently on evalua-tion

Reduction of (a) Resource short-falls and (b) mistakes in the production process Possibility of full automation

Continuous documen-tation and significant reduction of wrong transportation combi-nations

costs: 300.000 €

cost reduction en-abled by increased efficiency: 180.000 €

ROI < 2 years

Not specified

Transponder Passive Passive Passive Passive Not specified Active Passive EPC Gen2 UHF (Phase 1)

Current status

Complete Roll-Out since 2006 In use In use In use In use In use still testing



Most of these case studies illustrate the fact that the main scopes of the development of RFID-systems are: − traceability of goods, − transparency of transactions, − improvements of processes, mostly logistics and distribution processes, − an advanced asset management, − new possibilities in documenting different activities, like movement of goods.

Table 7 contains different case studies from different stages of the food supply chain. These case studies are examples which can be assigned to other companies or organizations. The main con-clusion of these case studies is, that most of the current RFID-applications are intra-organizational. In food networks, the inter-organizational adoption of RFID-Technology is just at the beginning. It seems that the most organizations concentrate on first experiences with RFID in their environment. The following paragraphs will give a detailed overview of different RFID-applications in different stages of the food supply chain.

7.2.2 RFID-Technology in production processes

NORTURA, the largest food supplier in Norway, started an approach for tracking meat from its butchering and processing plant to the store. The system was developed to meet the consumer requirements in traceability and also the governments and European regulations. The project is currently in the testing phase with few animal harvesters, two processing plants and retail stores. The biggest aim in this development is the implementation of a chain-wide track and tracing sys-tem including every step in their food supply chain. The system contains reusable plastic crates tagged with EPC Gen2 UHF RFID-tags. The butchered animal parts will be placed in this crates – tagged with a unique Identification-Code (ID-Code) – and transported to the NORTURA’s processing plants proceeding to the NORTURA retail stores. The information on the meat and meat products includes the farm origin, type of meat, the animal’s age and the health record. On every step of the supply chain, the time and the date will be added to the tag for observing the time between butchering and the point of sale. In the development of this system several prob-lems occur. In the production process, the meat gets processed into different products, like Ham-burgers, Ham or Sausages. The continuous traceability required a handover of the information linked to the crate with the raw product. The problem was solved by an integrated RFID Reader/Writer system in the production lanes, which adds the new crate ID-Code to the products. This creates a complete history of every product [Nortura08].

This case study shows that the implementation of RFID-technology along all stages of the food supply chain is possible, when the company is mainly horizontally organized and owns different companies along the complete supply chain.

To enable the track and tracing of single animals, different RFID-ear tags are available. These passive tags include an ID-Code for each animal to provide an single identification. This ID-Codes points to a dataset in a database, which contains individual information like age, vaccina-tion or medical records [Abhisam08]. In Figure 21 such a RFID Ear Tag is illustrated.



Figure 21: Tagged Cow-calf ear (right; Agriview08) with RFID-Tag (left; Allflex08)

Alternative identification systems, like necklace coupled RFID-Tags or injectable RFID-Tags, are still available. These identification systems get more and more popular benefited through low tag costs. To provide an example, the Canadian Cattle Identification Agency mandatorily arro-gates the use of such RFID Ear Tags from December, 31st 2009 (AGRIVIEW, 2008).

A different example for adopting RFID-Technology in food production processes is the SCHMIDT LEBKUCHEN company. The technology is implemented in special containers con-taining ingredients for their different fine gingerbread products. In the history, there were prob-lems of wrong dosage of these ingredients, which lead to deficits and higher costs on raw prod-ucts. Their RFID-System contains special containers, tagged with passive RFID-Tags, to identify the ingredient and a reader system at the dosage apparatus, for querying the right dosage for this ingredient in the production process. This system successfully minimized the error rate just by applying the right information at the right time [Schmidt06].

The last example of RFID implementation in the production process is the SACHSENMILCH AG. This company adopts the RFID Technology for controlling the cheese ripening process. This process consists of several ripening stages in different ripening rooms with defined tem-perature and humidity. For optimal ripening, the cheese raw products have to be placed in the different rooms in a defined order and dwell time. The cheese raw products are placed on special dollies tagged with passive RFID-Tags, which contain information about the production date of the first stage of the production process. The staff of SACHENMILCH moves the dollies from one storage room to the next storage room to improve the ripening process. The RFID-Tag is used to identify the dolly and evaluate its remaining time in the storage room. On the entrance of each storage room, an RFID-Reader reads out the Tag and puts data to the record of this dolly. This enables an overview on the whole ripening area, which is important for controlling the pro-duction outputs [Sachsenmilch06a].

In conclusion, the case studies in the production sector [Sachsenmilch06a and Schmidt06] show that there are many opportunities and benefits for the implementation of RFID-Technology in production processes. However, the manufacturer companies currently aren’t forced to imple-ment compatible RFID-solutions for their processes in due to their individual process framework (BMWI). Exceptions can be found in vertical oriented organizations like SACHSENMILCH. The case study of NORTURA was the only inter-organizational case study available, but it is an example for a best practice approach for implementing the RFID-Technology to link the several steps of the food supply chain.

7.2.3 RFID in Logistic Processes

The currently available case studies show that the implementation of RFID-Technology into lo-gistic processes are often introduced by the top-selling retail organizations, like WAL-MART, TESCO, METRO GROUP or REWE. Furthermore, the case studies show examples for intra- and inter-organizational implementation of RFID into logistic processes.



An example for intra-organizational RFID-implementation in logistic processes is the SACH-SENMILCH AG. Their management of dry raw product storages has to secure high quality stan-dards and high requirements in track and tracing of raw products, which are used in the produc-tion of dairy products. For storing these raw products, special containers are used. The scopes for the project were presented in Table 7. The main aim was to trace the special containers along the supply chain, for reaching transparency and enable their return on schedule. Therefore, the spe-cial containers were tagged with passive RFID-Tags. The forklifts were equipped with RFID-Reading devices. The RFID-Technology supports the storage and the delivery processes in due to reach a 100 percent transparency in the warehousing administration and transport task man-agement [Metro06].

A part of the case study from the Metro Group presents another possibility for implementing RFID-Technology to their logistic processes. The METRO GROUP set its main scope on reduc-ing the Out-of-Shelf situations in their retail stores. This was realized in the first step by automat-ing the storage and delivery processes in the Distribution centers (DC) and an advanced cargo-flow-management enabled by RFID-Technology. Automating the goods inward and refilling of the shelves at the point of sale (POS) in the retail stores, build the second step. The RFID-Technology enables a lot of new observation possibilities, for example the observation of the inventory of the shelves at the POS. These “intelligent” shelves recognize every transaction with the consumer. A software framework evaluates the goods in stock and the remaining inventory of the shelf in order to send warnings to the personnel in charge. These applications are currently in the Roll-out phase for every DC and all REAL and EXTRA supermarkets. Inter-organizational, Metro involved their suppliers to adopt the RFID-Technology for their logistic systems, too. The main scope of these projects are the possibility to make all delivery processes transparent and to increase the process efficiency. This case study represents the actions of all top-selling organizations. Many of these organizations are currently working cooperatively with their suppliers to implement the RFID-Technology to their inter-organizational networks (LZ-NET).

7.2.4 Conclusions

The inter-corporate application of RFID-technology internalizes network effects, if the same RFID-Technology is used all over the network (STRASSNER, 2005). Currently only few inter-corporate applications are developed. A future trend is shown in the case studies of METRO GROUP and NORTURA.

The possibilities for RFID-solutions along the whole food supply chain are already established. RFID Ear Tags for animals or RFID Chips for cereal production are developments which can include the first stage of the food supply chain into the RFID-systems of higher food chain stages.

CuteLoop 8 Annex 2 – RFID Technology Application


8 Annex 2 – RFID Technology Application

8.1 RFID Application Characteristics

The selection of the most appropriate operating frequency is of key importance and vital to effec-tuate interaction between the RFID tags and readers’ connection coupling network, and the asso-ciated devices. The existing RFID frequencies ranges from Low Frequency (LF) at 135kHz or less, High Frequency (HF) at 13.56MHz, Ultra High Frequency (UHF), and Microwave Fre-quency at 2.45GHz and 5.8GHz; the higher the frequency, the higher the data rate and vice-versa.

It is important to understand the influence of frequency choice on the detection /communication range. The frequency determines the wavelength of the RFID communication. If the distance between reader and tag is larger than the wavelength, the RFID functions in far field mode and the field strength drops with the square of the distance. If the distance between the reader and the tag is smaller than the wavelength, the RFID functions in near field mode and the field strength drops with the cube of the distance. Therefore, the field strength will drop steeply as function of the distance and the detection range will be strictly limited to the immediate neighbourhood of the reader.

Environmental conditions also play an important critical role in determining the optimal operat-ing performance of frequency for all relevant applications. The substrate materials that tags are attached to and the presence of other RF producing devices can create interference in either the UHF and microwave bands respectively. The degree to which these conditions affect a given RFID systems’ performance depend on the operating frequency. Interference can be caused by proximity to the following: − Liquids, such as water − Metal, foil, or other metallic objects − High humidity − Extreme temperatures – very hot or very cold − Motors or engines − Wireless devices, such as cell phones and PDAs − Wireless computer or communication networks − Cordless phones

Tags have long/short (active/passive) range transmission capabilities and are embedded in plas-tics or other materials without inhibiting their frequencies to withstand harsh environment, and operate effectively in temperature ranging from -40 to 200°C, and prevent interference in both the UHF and higher bands respectively.

The RFID tag infrastructure also enhances the ability to locate objects when used in combination with GNSS for (real-time) tracking. The degree to which these conditions affect a given RFID systems‘ performance depends on the operating frequency. Higher frequency usually means smaller antenna, smaller tag size, greater range and usually more regulatory restrictions. Cur-rently e.g. in the food chain there are no specific standards for RFID wavelength, but most com-mon applications around the world use wavelengths of 125 kHz and 13.56 MHz for all activities and to overcome all environmental issues in food sector. The most commonly used tags are clas-sified as passive low frequency tags with associated readers that may be stationary and posi-tioned at strategic points, such as facility entrance or on a movable assemblies.



However, the industry uses RFID technology to control materials movement and status of the materials and in the business processes involved in the product realisation (see also chapter 8.2). This enables the informing of human operators that either work flows are going smoothly or that there are problems to attend to, this as a result facilitates the improvement of efficiency in the business process, out of stock rate, packaging frequency, information accuracy, better tracking of the products as well as a decline in process errors.

Another interesting application of RFID in mobile equipment, where materials are moved around indoors/out-doors within the process plants, warehouses and transport vehicles, is to use forklifts embedded with an hybrid receiver that encompasses GNSS location based chip for positioning and location information and RFID tags & readers for identification of pallet type, packages con-tents, weight determination and retrieval of other material vital information already stored on decentralised servers synchronised with the RFID tags.

8.2 Current RFID Applications for Selected Scenarios

The intense uptake of RFID technology for industrial application was specifically started in the last years. The elaborated success stories initiated the research, industrial as well as public dis-cussion, with the latter being specifically focused on the risks and threats. However, based on the experience gained, diverse potentials were identified, while many business domains are still in the pioneering phase. Nevertheless, the following Table 8 specifically presents the application potentials of RFID in the supply chain. Table 8: Application of RFID in the supply chain by function [Maloni06].

Functionality Benefits/Application

Buy • Enable automatic reordering (replenishment by consumption) • Enable Vendor Managed Inventory (VMI) - install readers at customers to allow supplier to

monitor consumption • Supports collaborative planning, forecasting, and replenishment (CPFR)

Make • Ensure correct components are included in assembly (using bill of materials) • Track work in process (WIP) inventory • Record, direct workflow

Store • Automate inventory location to improve tracking, routing, accuracy • Automate picking/packing (direct to location, verify correct pick, update inventory) • Detect inventory in wrong place • Identify slow moving, obsolete inventory • Assess if products can be stored together (e.g. haz-mat) • Monitor environment changes (e.g. light, moisture, temp) • Automate inbound freight directly into WMS • Reduce manual inventory recording • Automate reorder point detection • Enable rapid re-stock of fast moving items • Manage inventory remotely • Automate inventory count • Automate inventory valuation • Track assets (reusable/returnable containers such as pallets, racks, trays, etc.) measure

utilization

Ship • Automate shipping process • Verify loading, unloading process (e.g. correct truck) • Confirm arrival of trailer (and all item onboard) • Generate automatic shipping documents • Compare contents to shipping documents (bill of lading)



Functionality Benefits/Application

• Track transportation equipment (containers, bins, etc. • Automate product tracking in transit (including GPS) • Generate alert of late, delayed shipments • Identify shipments as priority (for loading, delivery, etc.) • Detect container tampering

Sell • Automate restocking • Enable theft prevention of products, inventory • Automate order/shipping verification • Track short-life products to reduce spoilage • Generate automatic ship notice (ASN) • Automating check-out • Enable interactive selling of related products • Enable targeted (one-to-one) selling • Track product movement through store • Track customer purchase behaviour • Enable faster product recall • Enable product recall alarms • Improve claim and dispute processing • Track temperature of product • Control authenticity of products • Track product maintenance, repair history, configuration, etc. • Improve returns management • Automate recycling sorting process

The high versatility of RFID technology also permits its use in many of the processes related to construction, as shown in Table 9 below. Table 9: RFID uses in construction processes [ERA06].

Processes related to construction Potential uses and applications of RFID technology

Facilities Management (Service record of plant equipment)

• Facilities management at Frankfurt Airport • Data tagging for maintenance of plant • Service scheduling

Condition record of fixed assets • Asset management

Warning systems • System to track people at location (underground services/ power lines)

Goods received • iTAG - Electronic tagging of materials and components • RFID-based nuclear power plant construction technologies

Logistical operations (track/trace)

• Jobsite logistics (mobile RFID) combined with BIM31 project • RFID more than track trucks to construction site • Tracking large metal pipes • Using RFID to reduce CO2, optimising operations • RFID tracks power tools

Optimising flows and procedures • Manufacturing of doors - track/trace • Improving rental equipment delivery performance using RFID

Location of plant and equipment • Asset management • Path-finding RFID asset tracking • RFID more than track trucks to construction site

Performance/condition of plant and equipment

• Facilities management at Airports



Processes related to construction Potential uses and applications of RFID technology

Operative ID • RFID bolt and digital torque wrench • Embedded RFID: Intelligent concrete

Quality control

• Intelligent tag leaks for hydra • RFID-based nuclear power plant construction technologies • RFID improves testing procedures in concrete • RFID bolt and digital torque wrench • E TJEK delivers dynamic quality control

Security/safety

(theft prevention - access control)

• Access control to construction sites • Construction companies reduce thefts with proximity access control • Tool Tracker, Bosch's safe & sound tracking system keeps a watch-

ful eye on tools • RFID tracks power tools

Based on interviews and questionnaires to the industry, a comparison between the values of those applications mentioned in the table was developed, as shown in the following Figure 22.

Figure 22: Applications' value [ERA06].

CuteLoop 9 Annex 3 – European RTD Projects


9 Annex 3 – European RTD Projects

9.1 Selected European RTD Projects in reference to CuteLoop Key RTD Topics

CuteLoop analysed currently running as well as closed EU funded RTD projects, which were active in areas related to the major RTD field of the CuteLoop project. The analysis was focused on identifying major results of those project, which could be taken into account for the develop-ment of the envisaged project results. The overview as presented in the following Table 10 was mainly based on analysing public project websites, while representing an easy to read and very rough overview to facilitate access to relevant material and a more detailed analysis of potential results. Table 10: State-of-the-art – closed and running EU projects and European Technology Platforms.

Project Interaction Models Event-driven Agents Event-driven Archi-tecture & SOA

Decentralised Secu-rity & Trust

AMI-4-SME

Methodology & 2 new concepts and reference models for production & maintenance for SMEs

SOA and Middleware for RFID usage in the inte-grated enterprise

ATHENA Cross-Organisational Business Processes

Intelligent agent based QoS

Model-Driven and Adap-tive Interoperability Archi-tectures

General security model

BRIDGE Development of EPC global based Look-up and Discovery Services

EPC global Network Architecture

Requirements and Con-cept for RFID tags, read-ers, network infrastructure and RFID services secu-rity

CHINOS

Automatic Container Identification Unit (contai-ner identification, E-seal, damage documentation)

COBIS

Architecture for self con-tained collaboration; rule & predicate based event processing

Transmission security focusing on guaranteed information delivery

COPRAS Using and promoting standards, addressing RFID & interoperability

CoSpaces Collaborative workspaces for project teams within distributed virtual manu-facturing enterprises

Distributed software framework for creation of networks of distributed actors in integrated enter-prises

Trust and security as service on middleware platform

DBE Transferring business process models in build-ing blocks of software services

DBE architecture using service factory, execution environment and evolu-tionary environment

ECOLEAD

Dynamic Virtual Organi-zations & Professional Virtual Communities; Tools for creation & main-taining

Tool for set-up of virtual organisations uses Multi Agent System framework Jade

Realised on a Service based Architecture

Trust for multi-objective, multi-perspective & multi-criteria nature.

E-MULT Distributed decision support system for virtual organisations to support trade relations of SMEs

Monitoring agents super-vise the content of web sites and legacy systems

ETP Food for Life

New approaches for transparency optimisation in complex business networks



Project Interaction Models Event-driven Agents Event-driven Archi-tecture & SOA

Decentralised Secu-rity & Trust

Know Construct

Innovative decision mak-ing support system & consultancy services for SMEs' customers

Internet-based platform for SMEs and their cus-tomers.

LIAISON New hardware for seam-less and personalised location services across heterogeneous network.

MINAMI Event sensitive RF nodes (radio, RFID tags)

PRIME

PRIME toolbox, including communication, policy management, data track-ing.

End-user controlled Iden-tity Management System

PROMISE Product lifecycle, product information tracking and flow management system

SEA FOODplus Seafood traceability

STOLPAN NFC based services for connectivity, transaction and service discovery

Security, legal, privacy and consumer protection issues relevant for RFID-NFC

TRACE New Traceability para-digm, based on unique identifiers

Unique IDs for each transaction.

U-2010

Adaptable recognition based on integration of distributed knowledge of the current network envi-ronment (location infor-mation, RFID messages, recommended trust rela-tions, etc.) into the proto-cols

Availability of information and communication ser-vices in crisis or emer-gency situations



9.2 RTD Projects of General Interest for CuteLoop

There are diverse running and closed EU funded RTD projects, which are providing results that could be of relevance for the CuteLoop project. Therefore, the following Table 11 is listing the major project results which are addressing processes, products, infrastructures or problems which could be relevant for the CuteLoop project. The list outlines a rough summary and for further details the project specific websites, which are also listed, need to be consulted. Table 11: Results of currently running or closed RTD projects, which might be relevant with respect to

the CuteLoop RTD objectives.

Acronym/ Title/Link Project Results

Ami-4-SME Ambient Intelligence Technology for Systemic Innovation in Manufactur-ing SMEs http://www.ami4sme.org/

AMI-4-SME Service Oriented Software Platform Distribution, available free of charge, integrating project results and external sources. AMI-4-SME Methodology for Ambience Intelligence (AmI) Technology based process improve-ment, providing guidelines and document templates for improvement project realisation. Building Blocks for realising AmI based solutions including AmI based features for Speech Recog-nition, legacy system integration and RFID infrastructure installation.

ASPIRE Advanced Sensors and lightweight Programmable middleware for Innovative RFID Enterprise applica-tions http://www.fp7-aspire.eu/

ASPIRE will develop and deliver a lightweight, royalty-free (i.e. open source), programmable, privacy friendly, standards-compliant, scalable, integrated and intelligent middleware platform that will facilitate low-cost development and deployment of innovative fully automatic RFID solutions.

ATHENA Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Appli-cations http://www.athena-ip.org/

Athena Interoperability Framework

BRIDGE Building Radio Frequency IDentification for the Global Environment http://www.bridge-project.eu

Development and implementation of tools to enable the deployment of EPCglobal applications in Europe. Realisation of an EPCglobal infrastructure, which integrates hardware, software, network and security. Provision of diverse deliverables presenting the lessons learnt, the technical specification as well as training and dissemination material.

CASAGRAS Coordination and Support Action (CSA) for Global RFID-related Activities and Standardisation http://www.rfidglobal.eu/

CASAGRAS (Coordination and Support Action (CSA) for Global RFID-related Activities and Stan-dardisation) will provide a framework of foundation studies to assist the European Commission and the global community in defining and accommodating international issues and developments concerning radio frequency identification (RFID) with particular reference to the emerging ‘Internet of Things’.

CATER Computerised Automotive Technology Reconfigura-tion System for Mass Customization http://www.cater-ist.org/

The project realised a semantic notation system for databases design and conceptual models and activity description for automobile design. Key element is the Citarasa Engineering Methodology and Customer Citarasa Needs Database.

CE-RFID Coordinating European Efforts for Promoting the European RFID Value Chain http://www.rfid-in-action.eu/

Coordinating European Efforts for Promoting the European RFID Value Chain. It aims at improving the conditions of competition for RFID technology and its further development in Europe and at reinforcing the political environment of RFID at European level. Development of the RFID reference model to structure the different application fields in order to be able to evaluate requirements in terms of standards, technological components, and data protec-tion for individual applications.




CoBIs Collaborative Business Items http://www.cobis-online.de

Knowing the exact whereabouts of physical objects such as goods or tools in enterprise environ-ments to optimize business processes has been a long-standing desire of several industries. The Collaborative Business Items (CoBIs) project develops a new approach to business processes involving physical objects. We embed business logic directly into the physical entities, therefore making it possible to relate more closely the state of an enterprise as represented in business processes to what is actually happening in the real world and furthermore extending the business process to the "point of action". CoBIs has developed an open platform based on a service-oriented architecture (SOA) that makes it possible to apply networked embedded systems tech-nologies in large-scale business processes and enterprise systems. CoBIs evaluates its approach in real world application trials in two different domains: the petrochemical and retail (apparel) industries.

CO-DESNET/ Collaborative Demand and Supply Networks http://www.codesnet.polito.it/

A European Coordination Action, with the objective to keep in contact research centres and enter-prises, promoting the collaboration among them, by disseminating methods and procedures of Network Re-Engineering (to perform an effective reorganization of the networking services) as well as existing software tools.

COIN Collaboration and INter-operability for networked enterprise http://www.coin-ip.eu/

To design and develop a pervasive, adaptive Service Platform to host Baseline and Innovative COIN services for Enterprise Interoperability (EI) and Enterprise Collaboration (EC) and make them available under innovative on-demand, utility-oriented business models (i.e. the SaaS-U model) to European enterprises (and SMEs in particular) for running their business in a secure, reliable and efficient way. To consolidate and stabilize the ICT results of both EC and EI FP6 research into some Baseline Services which constitute the service foundations for COIN. To further enlarge, extend and improve the baseline services, by developing other more Innovative Services in the EC and EI fields, which could take into account the most recent and promising technology challenges (in the field of Web 2.0, semantic web, space computing) and put them at service of EC and EI purposes. To represent a pathway to convergence for these two fundamental research streams: EI and EC, by integrating in the same project the most prominent stakeholders of the two research fields coming both from industry and from universities and research centers. To demonstrate, experiment, trial and assess the project results into realistic Industrial Scenarios offered by our 6 test cases in Aeronautics, Automotive, Aerospace, Pulp & Paper, Healthcare and ICT.

COMMIUS Community-based Inter-operability Utility for SMEs http://www.commius.eu/

Commius will build such an interoperability solution for SMEs, allowing them to reuse existing and familiar applications for electronic communication. The solution will be downloaded with an SME's consent using automated self-installation routines. Commius will hook into their email infrastructure and collaboration systems such as Microsoft Exchange. It will then proceed to establish interop-erability agreements with the peers of the SME at the levels of system, semantics and even proc-ess. Semantic analysis of actual enterprise data and documents used within and exchanged be-tween pairs of SMEs will form a core part of this process.

COPRAS COoperation Platform for Research And Standards http://www.w3.org/2004/copras/

COPRAS has developed a set of Generic Guidelines facilitating interfacing between research projects and ICT standards organizations. Its ultimate goal is to bring IST research and standardi-zation closer together and to provide research projects as well as other stakeholders in govern-ment, industry, and society with a platform facilitating exchange between research and standardi-zation, and furthering Europe's leading position in ICT development.

CoSpaces Innovative Collaborative Work Environments for Individuals and Teams in Design and Engineering http://www.cospaces.org/

The research advances in CoSpaces will push the state-of-the-art of collaborative work environ-ments in several key areas: New collaboration models addressing the development and deployment of collaborative technolo-gies that empower workers and teams and having a strong human factors and business focus. A practical collaborative software framework for supporting dynamic organisations that are execut-ing complex processes in order to produce complex products. Uncovering and addressing real-world constraints and barriers to bridge the gap between industrial engineers and scientific researchers in collaborative working. Industry workspaces and interfaces based on deploying virtual interface technologies, leading to more practical and usable interfaces for real-world problems and users.

DBE Digital Business Ecosys-tem http://www.digital-ecosystem.org/

The DBE Execution Environment (Swallow [ExE] subprojet) project provided the peer-to-peer middleware on which both the infrastructural and business services run. The ExE has been re-leased under the GNU LGPL. It was based on FADA components (Federated Autonomous Distrib-uted Direchtory Architecture, FADA community) The DBE Studio is the integrated development environment for the DBE, built on the eclipse plat-form. The DBE Studio contains the editors, tools and wizards that support the analysis of business services, as well as the definition, development and deployment of the corresponding software services onto the ExE. The DBE Studio is released under the Eclipse Public License. The Evolutionary Environment [EvE] was released before end 2006 and was an initial references for more modern digital ecosystems architectures (see above).




E4 Extended Enterprise Management for Enlarged Europe http://e4.cognovis.de/

The E4 project's major aim is to specifically support Eastern Europe enterprises to take active part and jointly develop collaboration initiatives with long-tradition Western EU R&D and Innovation Centres for intelligent and extended products development in several sectors of the EU manufac-turing industry; In particular the objectives are: To support the integration of OEM and suppliers (especially SMEs) in the network enterprise; To Achieve higher quality and efficiency in executing distributed processes related to new products design. E4 platform is expected to become a single point tool for complex activities related with a whole collaborative product development cycle. SME’s need to obtain access to data exchange, project management, design and knowledge management functionality since most of the tools they use for such activities at the moment are available for local use only without collaboration interfaces. On the other hand, using a number of different tools instead of a single one will not allow development project processing within partnering network.

ECOLEAD European Collaborative Networked Organisations Leadership Initiative http://www.ecolead.org/

Existing and future Virtual Business Environments, professional associations, universities, re-search institutes, ICT industry, consultancy companies and obviously SMEs will gain great benefits from the adoption of ECOLEAD results: Dynamic VO creation assistance tool which support the phase of a rapid creation of a virtual or-ganization utilizing trust, competency, business process, past performance information of candi-dates its able to rapidly create ready-to-do business new VO; VO collaboration and performance measurement tool will record past collaboration performance of each single member in order to be able to select always the right organization needed in the rising VO; Contract negotiation wizard tool will allow to rapidly define the dues and the rights of the organiza-tions which are going to join together in the VOs; VO management e-service tool will effectively manage an operating VO by means of e-services in ASP modality with a very low impact in the single organization ICT structure; Collaborative problem solving support e-services tool will improve the profitability and quality of VBE’s members allowing to start problem solving processes addressing daily troubles and ineffi-ciencies they experienced; Advanced collaboration platform for PVCs tool will provide the necessary support in order to allow the cooperation of single professional humans, bringing in the business arena their personal and specific competencies.

E-MULT European Multi-threaded Dynamic SME Networks for Market-Driven ELV Recycling http://www.emult.prv.pl/

Providing the E-Mult Concept from the area of end of live vehicle (ELV), including the E-Mult Meth-odology Concept and the E-Mult ICT System Concept. In contains the E-Mult Multilanguage Dic-tionary and a Common Ontology, summarizing scope and shape of project ontology.

FLUID-WIN Finance, Logistic and Production Integration Domain by Web-based Interaction Network http://www.fluid-win.de/

The FLUID-WIN project targets business-to-business (B2B) manufacturing networks and their interactions with the logistics and financial service providers. It aims to develop a platform which can seamlessly integrate and transfer data among all the various partners in order to enhance the competitiveness of the whole business sector in Europe and to make the business processes as efficient as possible. Providing: FLUID-WIN B2(B2B) interdisciplinary model. The model will support the definition of relationships among service providers (logistic and finance) and manufacturing networks, enabling the creation of a new multi-business web-based application where service providers offer their services not to a company but to an entire network. Suite of web based tools specifically designed to be provided on ASP basis, implementing the FLUID-WIN B2(B2B) interdisciplinary model. Specific interoperability framework targeted to enable the electronic data interchange among all players based on the FLUID-WIN B2(B2B) interdisciplinary model.

GRIFS Global RFID Interoperabil-ity Forum for Standards http://www.grifs-project.eu/

Support Action Project funded by the European Commission with the aim to improve collaboration and thereby to maximise the global interoperability of RFID standards.

ILIPT Intelligent Logistics for Innovative Product Tech-nologies http://www.ilipt.org/public

The 5-day car concept brings about a radical innovation and enables the European automotive industry to gain competitive advantage. Being part of the “EU 5-Day Car Initiative”, ILIPT tackles both the conceptual and the practical aspects of the automotive industry’s radical new concept: The delivery to the customer of a bespoke vehicle only several days after placing the order. The ILIPT vision concentrates on future scenarios for new flexible planning and execution proc-esses, new supply network organisation structures, and new supporting technologies in the year 2015, in order to reach the 5-day target. To this end, ILIPT describes potential impacts of the 5-day approach on future scenarios of the automotive industry for the year 2015 and derives from this requirements for processes and ICT infrastructures.




INDISPUTABLE-KEY Intelligent distributed process utilization and blazing environmental key http://www.indisputablekey.com/

Based on RFID technology, Indisputable Key develops a system for complete traceability, including standards for information transfer. The solutions are applied to different types of wood production as soft wood production from harvesting to window components, hardwood products, plywood and poles for powerlines.

iSURF An Interoperability Service Utility for Collaborative Supply Chain Planning across Multiple Domains Supported by RFID De-vices http://www.srdc.com.tr/isurf/

The iSURF Smart Product Infrastructure will be a pervasive, dynamic, intelligent and ubiquitous network and service infrastructure. This infrastructure will allow seamless connection of massively distributed smart products. By this approach, it is possible to create an “Internet of Things” where objects will report their location, identity, and history over wireless connections.

K-NET Services for Context Sen-sitive Enhancing of Knowledge in Networked Enterprises http://140.203.154.228/K-net/

The objective of K-NET is to explore the fundamental problem: how different services to manage social interactions in a networked enterprise can be used to enhance knowledge and knowledge management (KM) services. The key hypothesis of K-NET is that the context under which knowl-edge is collectively generated and managed can be used to enhance this knowledge for its further use within intra-enterprise collaboration.

KNOW-CONSTRUCT Internet Platform for Knowledge-based Cus-tomer Needs Management and Collaboration among SMEs in Construction Industry http://www.know-construct.com/index.htm

The project aims to develop a common internet-based platform for SMEs from the construction sector to provide an effective combination of two general functionalities: Customer Needs Management (CNM) System: an innovative decision making support system regarding the products characteristics, applications and other consultancy services for SMEs' customers applying the "web enabled dialogue" Knowledge Communities Support (KCS) System: a system for SMEs to support an advanced form of co-operation through the creation of Knowledge Communities of SMEs in CI. The system should support the integration, management and reuse of the area specific knowledge via a common knowledge base.

LIAISON LocatIon bAsed servIceS for the enhancement of wOrking enviroNment http://www.liaison-pro-ject.eu/

LIAISON aims at providing a generic and standardized core module and at developing customized turnkey Location Based Services for a wide range of mobile workers communities. The elaborated solutions are intended to prove that the integration of existing technologies is possible and of high value to users, whereas users do not benefit from isolated existing non-interoperable components.

MAPPER Model-based Adaptive Product and Process Engineering http://www.ve-forum.org/ apps/pub.asp?Q=1968&T=Clusters and Projects

MAPPER will enable fast and flexible manufacturing by providing methodology, infrastructure and reusable services for participative engineering in networked manufacturing enterprises, demon-strating practical benefits and scientific values in three industrial pilots.

NET-WMS Towards integrating Virtual Reality and optimisation techniques in a new gen-eration of Networked businesses in Warehouse Management Systems under constraints http://net-wms.ercim.org/

The Net-WMS project proposes a software solution enabling the expected new generation of WMS networked businesses. Net-WMS will handle networked communication and co-operation proc-esses through the integration of decision-making technologies, generic 3D placement primitives, virtual reality for 3D visualisation, interactively-designed packing models and knowledge modelling. The added-value and competitiveness increase of the Net-WMS solution, designed for plant level technicians, will be characterised by shared expertise, easy deployment and maintenance, flexibil-ity, interoperability, better resource handling and access to remote services. Realising the follow-ing: A packing modeller of items based on virtual reality and optimisation techniques. A palletiser tool using optimisation techniques which takes as input existing packing models (car-tons, etc.) and items to pack, and computes the optimal number of each packing model. A dispatcher (vehicle routing) with the virtualisation of a truck load. The tool computes the optimal placement of items in a vehicle whilst taking into account the delivery and the customer con-straints. In addition, it provides means to visualise the content of the vehicle using virtual reality capabilities. An online scheduler tool enabling the user to schedule daily activities in a WMS like picking activi-ties or assignment of vehicles to gates based on results of the packing and dispatcher tools




PRIME Privacy and Identity Man-agement for Europe https://www.prime-project.eu/

PRIME develop a working prototype of a privacy-enhancing Identity Management System. To foster market adoption, novel solutions for managing identities had been demonstrated in challeng-ing real-world scenarios, e.g., from Internet Communication, Airline Passenger Processes, Loca-tion-Based Services and Collaborative e-Learning.

PROMISE Product orientated manu-facturing systems includ-ing RFID technology http://www.promise.no/

The core innovation of PROMISE is the concept of smart products that are able to sense their condition and environment. PROMISE-Product Lifecycle Management (PLM) addresses gaps in information flow and creates better understanding and extends control of products over the lifecy-cle, giving manufacturers effective instruments to create more value to the end users and win market share PROMISE focuses on the complete lifecycle of a product from the Beginning of Life (BOL) to the Middle of Life (MOL) to the End of Life (EOL) with more emphasis in tracking and managing of information at the last two phases of the product’s life cycle. PROMISE's main objectives are 1. To develop new closed-loop life cycle information flow models all three product life-cycle stages, 2. To develop new PLM systems and IT infrastructure exploiting the capabilities of smart product embedded information devices, 3. To develop new standards allowing the technologies and associated tools developed by the PROMISE project to be accepted by the market, enabling market growth by creating a favourable environment for the development of new innovative applications in Product Lifecycle Management systems 4. To develop new business models for innovative technologies to be deployed by all players in the Product Life-Cycle.

SMART Intelligent Integration of Supply Chain Processes and Consumer Services based on Unique Product Identification in a Net-worked Business Envi-ronment http://www.smart-rfid.eu/

The SMART project will provide the infrastructure, electronic services and software applications to enable supply chain collaboration and innovative consumer services. These services will be based on a scalable-distributed-architecture and building on the possibilities provided by peer-to-peer networks, web-service orchestration and choreography, data-stream systems and smart tagging technologies. The SMART collaboration infrastructure shall be in close integration with the EPCglobal Network information infrastructures. It will provide a complete and solid collaboration framework offering innovation to specific supply chain processes and consumer services.

SMMART System for Mobile Mainte-nance Accessible in Real Time http://www.smmart.eu/

The project "System for Mobile Maintenance Accessible in Real Time (SMMART) aims at defining a new integrated concept to answer the maintenance challenges of the transport industry – aero-nautics, road transport, marine transport. It will help to reduce the time and cost for scheduled and unscheduled maintenance inspections of increasingly sophisticated and complex products. SMMART wants to remotely provide the adequate up-to-date information to assist the mobile workers in all their tasks wherever they operate, also minimising the cost penalties of unscheduled downtime on large transport fleets. Lastly, SMMART aims at offering new services for the mainte-nance of vehicles in order to simplify and secure the exploitation.

SPIKE Secure Process-oriented Integrative Service Infra-structure for Networked Enterprises http://www.spike-project.eu/

Development of software platform for the easy and fast setup of business alliances.

SPIDER-WIN Supply Information Dy-namic Exchange and Control by Web-based Interaction Network http://www.spider-win.de/

The goal of SPIDER-WIN was to achieve efficient, simple and context-aware SME co-operation with low-level local software requirements and adapted to the typical availability and quality of resource data in very small enterprises, focussed on the exchange of order status changes. As a value added service, an ASP platform was developed which allows context-aware handling of orders and resource requests.

StoLPaN Store Logistics and Pay-ment with NFC http://www.stolpan.com/

The StoLPaN project intends to turn NFC (Near Field Communication) enabled mobile handsets into multifunction terminals with bi-directional interaction between the wireless NFC interface and mobile communication channels. It will show the use of this generally applicable new technology in the retail logistical value chain, and also in mobile payment, ticketing and other use cases. Mobile NFC services are developed based on their existing contact less use cases and also on the avail-able infrastructure. In addition, their features are enhanced through the functional capabilities of the mobile handsets and the remote application management potential.




SToP Stop Tampering of Prod-ucts http://www.stop-project.eu/

SToP is investigating the economics of the counterfeiting business and propose a technical ap-proach to product authentication that will address important issues regarding product security and anti-counterfeiting. The approach is being embedded into an economic framework that shows how the approach can be efficiently and effectively adopted by companies of different size in various industries. One of the key elements in the project is the development of a prototype system infra-structure and its evaluation in extensive trials demonstrating its potential in the context of a variety of industries and processes.

SYNERGY Supporting Highly Adap-tive Network Enterprise Collaboration Through semantically enabled knowledge services http://www.synergy-ist.eu/

SYNERGY is a research project funded by the European Commission with the aim of developing dynamic and adaptive knowledge management systems and services to enable virtual organisa-tions (VOs) to collaborate more easily. SYNERGY will use semantic ontology-based modelling of knowledge structures about collabora-tive working to create an automatically self-adaptive architecture. This means it will be able to learn continuously from usage and experience and be able to identify new knowledge sources. The result will be a service-oriented set of web-based services that can foster collaboration between enterprises and support best-practice collaboration patterns.

TRACE Tracing the Origin of Food http://www.trace.eu.org/

The TRACE project produces both generic and sector-specific traceability systems building on existing technology. The major aims of this part of the project are to: make traceability easier, quicker and cheaper as well as prove the viability of the real systems (cost-benefit analysis). Standardising schemes for information exchange and developing a “Good Traceability Practice” guide for the food industry. The project aims to provide an infrastructure to ensure complete tracing and tracking of food along the whole production chain. A programme of demonstration activities performed by the food industry will critically appraise of the developed traceability systems to ensure they are cost effective and fit for purpose

TraSer Identity-based Tracking and Web-Services for SMEs http://www.traser-project.eu/

The TraSer project ("Identity-Based Tracking and Web-Services for SMEs"), financed within the EU 6th Framework Program, was started to offer a free, open-source alternative to today’s proprie-tary tracking and tracing solutions. This will help making tracking and tracing beyond company borders affordable for small and medium-sized enterprises (SME). This allows for a low initial systems investment, the applicability with legacy and low-end standard systems and the lean implementation and maintenance, minimising the requirements for IT specialist staff. Thus SME will have easier access to tracking infrastructures and RFID systems of Logistic Service Providers (LSPs).

X-CHANGE Flexible Change Man-agement for the Factory of the Future http://www.x-change-project.net

X-Change aims to provide a breakthrough in the current practices of flexibility calculation and change management of manufacturing systems that are triggered by different change drivers and restricted by multiple disciplines and have an impact from day to day work up to the whole lifecycle. X-Change comprises solutions, which support the handling of manufacturing system adaptation and solutions, which increase the adaptability of manufacturing systems, and lead to more cost-effective, high quality, fault tolerant, eco-friendly, energy-saving, and safe manufacturing. The project developed several innovative, live, 'near-realtime' flexibility measurement methods as part of a flexibility evaluation toolbox with wide applicability range. Integration of the results of the flexibility measures, the flexibility indicators, into existing change management (business) processes. Realisation of this flexibility evaluation toolbox into an open-interface X-Change lifecycle platform able to facilitate lifecycle and change management in production systems and extended enter-prises. X-Change aspires to cover the entire lifespan of production systems while adopting a holistic ap-proach by addressing production and business processes in a multi-level structure.

state-of-the-art-analysis...the cuteloop project is co-funded by the european commission within the...

Documents