Navigating the web of things

Challenges and Applications

Mark Harrisonmark.harrison@cantab.net

Navigating the Web of Thingsphysical objects

move around

handled & ownedby many people /

organizationsat different times

within supply chains

during use

at end-of-life

a collection of fragments of information

multiple contributors,stakeholders,

owners of data

gather multiple fragments to

build the complete picture

remote access

mechanisms to help us find

relevant information

SearchQuery

IndexingLinking

begin our search with a keyword

or the ID of an individual object

Motivations for gathering information

• Product safety / anti-counterfeit– Check for end-to-end traceability

• Better end-of-life re-use, re-manufacturing– Decisions depend on product lifecycle information (design,

manufacture, in-use (sensor data), recently replaced parts, warranty information)

– WEEE, RoHS etc.

• Improved product design / design for providing service– Detect failure trends and performance issues across a fleet,

identify root cause of problems, re-design for better performance and reliability

Information Resources

• Websites (human-readable)– but no universal standard layout

• Web services (machine to machine)– retrieval of information– perform remote methods (operations,calculations)

• EPC Information Services (EPCIS)– open standard interface for retrieving information about tagged

objects– event data (observations, aggregation changes, ...)– meta-data fields (business context)– often implemented via a web service interface

Class-level information:product ratings, reviews, price comparison, availability, technical specifications, instruction manuals, diagnostic tools

Serial-level information:

traceability, authenticity, warranty registration, registration of ownership, customization, configuration (and backup of configuration)

Class-level vs Serial-level information

Lookup services - why ONS isn't enough

• Object Name Service (ONS)– Implemented using DNS with NAPTR records

• Object Name Service (ONS) is of limited use– No client authentication for queries– Mainly stores class-level records (product type)– Points to current address(es) of the manufacturer's information

resources– Not designed for historical traceability information or serial-level– Intended for relatively static records– ONS 1.0 specifies how to query ONS - not how to publish a link

http://www.epcglobalinc.org/standards/ons

Lookup services - why ONS isn't enough

Discovery Service

ObjectName

Service(ONS)

Beyond ONS – Discovery Services

• Discovery Services (DS)– Handle serial-level links for individual IDs– Posted/published by multiple organizations per ID– Will support publishing as well as querying– Will have authentication of query clients and publishers– Will have a framework to interpret and enforce access control policies, to protect

commercially sensitive link information– Will store historical links to previous custodians

- not only current state– Will support standing queries as well as one-off queries

• Status: Currently under development– BRIDGE project( WP2 [Discovery Services], WP4 [Security] )– Solution providers offering Discovery Services– EPCglobal Data Discovery Joint Requirements Group– ESDS activity at Internet Engineering Task Force (IETF)

Specific challenges for the 'search engines' for the web of things

• Serial-level information is commercially sensitive and valuable– often generated within companies rather than by citizens– needs protection against unauthorized access and data mining by competitors

• Scalability– Volume of objects, links and events– Long data retention times for long-lived objects– Need for automated purging and archiving

• Access control– Who can publish? Who can query? For which ID ranges?– Fine-grained access controls to protect individual records

• Complexity / Dynamic supply networks• Privacy and confidentiality• Trust

Some specific challenges

Scalability of access control permissions

Potential number of permissions per objectcould be of order N2

where N is number ofcompanies in chain / lifecycle

Need a more scalable solution

Su

pply

cha

in o

r lif

ecyc

le

Some specific challengesFragility of URLs over time (broken hyperlinks)

• URLs of information resources may change over time– Company takeovers, re-branding, re-naming– Previous address compromised (Denial of Service attacks)– Restructuring of IT architectures within companies

• Need efficient way to apply new URL to existing records– Large volumes of existing records affected– Existing records might be digitally signed - try not to break signatures

• Avoid embedding URL within Discovery Service records– Decouple URL via an opaque reference to a 'Resource Profile'

Some specific challenges

Fragility of URLs over time (broken hyperlinks)

Discovery Service

Resource ProfileURL

serviceType

DS Record

EPC or IDTimestampResourceID

[other metadata]

ResourceID=...

ResourceID

Resourcee.g.EPCIS

Some specific challengesSuppression of information by access policies

- ability to verify digitally signed records

• Access control policies can be used to restrict which clients are allowed to receive links to specific services• Access control policies might not be simply GRANT / DENY

but may require some data fields to be withheld from a client• i.e. client might receive only a subset of the full record that an organization originally published to a Discovery Service• Problematic if original record was digitally signed, since client will be unable to verify signature themselves• A DS may need to verify digital signatures of incoming published records and say whether the record was signed and whether the digital signature was successfully verified

Some specific challengesOvercoming 'deadlock' before trust is established

• A publisher (information provider) may choose to hide their identity from clients with whom they don't yet have a trust relationship.

• How does a client begin negotiations with an information resource that provides no contact address?

• Possible role for a Discovery Service in overcoming deadlock:– Information provider may allow DS to provide an opaque token to clients lacking authorization

– Client sends negotiation request to DS, quoting token, for DS to forward to hidden information provider.

Some specific challengesOvercoming 'deadlock' before trust is established

Discovery Service

QueryClient

Resourcee.g.EPCIS

"I hold information about EPC xyz- but hide my real ID & contact info from unauthorized / unknown clients"

Opaque token0A8274B2845EF

Request for access,Quoting token

Request for accessfrom client with ID...

Co-existence and co-operation of multiple Discovery Services

• Some industry sectors and supply chains might not intersect

• Logical partitioning of scalability problem into multiple DS with well-defined scope (industry sector, geographic region)

• How to find an appropriate DS for an unexpected object?– Use of structured identifiers and scope declaration to find likely DS– Shared high-level index or Multi-cast communication between Discovery Services in a P2P network

Some specific challenges

DS #3

DS #1

DS #2

BRIDGE work on Discovery Services

• User requirements & expectations - surveys• High-level design

– Comparison of different interaction models– Data model and interfaces– ( relevant concepts from ONS, EPCIS + new ideas )

• Software prototype• Contribution to standardization activities• Ongoing work of BRIDGE WP4 (Security)

www.bridge-project.eu

Comparison of different interaction models

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Directory of Resources

Setup

Discovery

Fulfillment

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Notification of Resources

Setup

Discovery

Fulfillment

One-off queries Standing queries

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Query Propagation

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Meta Client

EPC, URL, serviceType EPCIS query, Client ID

EPC, URL, serviceType EPC, Client ID

Eight different architecture models (message-flow sequences) were considered according to various criteria:

• Ability to protect confidentiality of link to resources

• Ability to protect confidentiality of client's query

• Suitability for one-off queries vs standing queries

• Response time, especially for one-off queries

• Data storage load on DS (records, policies, session connections)

• Possible security threats / attacks - and countermeasures• propagation of Denial of Service attacks, Honeypot harvesting

Comparison of different interaction models

Data model and interfaces

The DS design from the BRIDGE project includes:

• Query Interface (one-off and standing queries)• Publishing Interface (for resources to post records to a DS)

Data model for records mostly aligned with EPCIS:• EPC or ID• eventTime (set by publisher), recordTime (set by DS)• optional businessStep metadata• optional storage of aggregation records in DS

Publisher Profile borrows from ONS:• URL• serviceType (indicates kind of service to be found at URL)

N.B. DS does not return entire records back to client.

Software prototype of a Discovery Service

Implemented by AT4 wireless & AIDA

SOAPSOAP

SOAP

SOAP

DS-Query Interface

DS CoreRepository

DS-Publish Interface

Publish Proxy Layer

Query Proxy Layer

Query Application

DS

http

http

http

http

http

http

Sniffer

EPCIS RepositoryAccada

EPCIS Capture InterfaceAccada

PublishApplication

IS-DS Interface

SOAPFiltering

Schedule Checker

DS Std QueryRepository

Event-Manager Interface

Standing Query Inteface

Messaging S

ervice

SOAP

Contribution to standardization activitieson Discovery Services

EPCglobal Data Discovery Joint Requirements Group• Collecting use cases and analyzing for technical requirements• Discussion of alternative architectures / message flow patterns

ESDS at Internet Engineering Task Force ( esds@ietf.org )• Initial internet drafts from members of Afilias• Provided feedback on those drafts• Comparison with BRIDGE data model & interface design• Study of related protocols to check for possible relevance

Beyond Discovery Services - Applications

Discovery Services

Value-added track & trace applications& supply-chain management applications• Retrieve complete end-to-end traceability

• including multiple aggregation changes, relabelling

• Analyze event data from across supply chain / lifecycle

• detect problems (delays, deviations, duplicate IDs)

• identify root cause of problems

• predict ahead (when, where expected next)

• analyze trends and optimize for efficiencies

• Handle / choreograph fine-grained product recalls

• Generate alerts re problems (e-mail, SMS)

help authorized authenticated clients to find one or more

possibly relevantinformation resources

for an EPC or ID

BRIDGE WP3 - Serial-level supply chain control(Enhanced Track & Trace)

• Cambridge Auto-ID Lab led task 3.1– Serial-level Inventory Control model

• Gathering of event data from across supply chain (via Discovery Services and EPC Information Services)

• Supply chain network modeling (as hierarchy of nodes)

• Use of probabilistic algorithms and first-order Markov models to 'learn and predict' the movement of objects

• Technical details reported in public document D3.1 from WP03 (see BRIDGE website http://www.bridge-project.eu )

• Currently involved in collaborative development (together with BT and SAP) of an extensible software prototype to support various pilot and trial activities in various industry sectors across the BRIDGE project

Supply Chain Network Model

Dock #3

Dock #1

Dock #2

Storage Area

Shipping Area

Receiving Area

Shelf #3

Shelf #1

Shelf #2

Door #1

Door #2

Dock #1

Dock #2

Receiving Area

GLN:123456789GLN:567891234

Discovery Services

EPCIS

Overview of database design

Current State

NODESSpatial_Separations

distancesbetween nodes,intrinsic speeds

x kmConnection_Observations

∆taverage transit timesbetween nodes,standard deviations

Pathswhich paths between nodesare permitted?

Transitions

70%

30%branching ratiosfrom historicaldata

Event Log

Algorithms

Non-probabilistic query methods

• Where was it last observed? (tracking)

• Where are all the places it was observed? (trace)

Additional complications: changes of aggregation happen!

• Items packed into cases, cases loaded onto pallets, pallets form shipments / are loaded into containers

• Components being assembled into composite products

• Disaggregation - unloading, disassembly, break down of bulk products into smaller units (e.g. for retail)

Following changes of aggregation

ITEM

CASE

PALLET

AggEvt

Obs

timeItem packed into caseNeed to track case ID

Case packed onto palletNeed to track pallet ID

Case removed from palletNeed to track case ID

Item removed from caseResume tracking item ID

AggEvt

Add

AggEvt

Add

AggEvt

Del

AggEvt

Del

Probabilistic algorithms: Filling in the ‘gaps’

Probabilistic reasoning enables:

• Filtering: Where is it? Estimate current location given observations so far

Location

Observation

99%

1%

• Prediction: Where will it be next? Estimate future location given observations so far

60%

40%

Most likely

• Smoothing: Where has it been? Estimate past location given observations so far

• Where did it go through? Estimate the most likely path that an item has followed given observations so far

99%

1%

Location

Observation

Most likely

Probabilistic algorithms: Filling in the ‘gaps’

Probabilistic algorithms: Models and Algorithms

X t X t+1 X t+2

y t y t+1 y t+2

Variable(Location)

Evidence(Observation)

Transition model

Sensor model

BRIDGEWP3 Prototype

EPC Network

BRIDGE WP3 software prototype for enhanced serial-level track & trace

Discovery Services EPC Information Services

Event Gathering Layer

Non-probabilistictrack & trace algorithms

Probabilistictrack & trace algorithms

High-level Application Programming Interface (API)GraphicalUser Interface

BusinessApplications

internaldatabase

Humanbeings

Application Programming Interface

Goal: Interface to WP3’s Tracking Infrastructure– support wide range of business applications– expose tracking model through API and convenience functions– exception handling & alerting– trigger event collection from distributed sources– choreograph sequence of tracking algorithms

Targeted Recall,

Diversion, Shrinkage,

Lost & Found,

Asset Tracking,

Condition Monitoring,

Reconciliation, ...

BRIDGEWP3 Prototype

EPC Network Discovery Services EPC Information Services

Event Gathering Layer

Non-probabilistictrack & trace algorithms

Probabilistictrack & trace algorithms

High-level Application Programming Interface (API)GraphicalUser Interface

BusinessApplications

internaldatabase

Humanbeings

BRIDGE WP3 software will be able to answer:

• Where was the object observed?(including tracking of parent(s) or children as necessary)

• Where is it likely to be now?

• What is the probability that the object will arrive at location X by time T?

• After how much elapsed time is the probability of arriving at location X greater than threshold probability P?

• Which path is the object likely to have taken?

• Alert me if my shipment is likely to arrive late at its destination

• Alert me to where delays are happening in the supply chain

• Alert me to inconsistencies (e.g. duplicate IDs at distant locations, similar times)

• Alert me to deviations from permitted paths (including 'insertions')

Testing and validation of the WP3 prototype

WP6 (Pharmaceutical traceability pilot) has expressed keen interest in this work - and the possibility of using the software prototype to analyze data gathered from their pilot.

The WP6 pilot is already live and gathering data from 3 supply chain strands, involving 3 manufacturers, a contract packer, storage/distribution, transport, wholesalers and a hospital pharmacy, spread across 3 countries.

WP6 will be deliberately introducing some 'abnormal' incidents into their pilot - e.g. duplicate IDs, IDs not matching ASNs, insertion into the supply chain. WP6 hopes that WP3 and WP5 (anti-counterfeiting) can detect such abnormalities from analysis of the data gathered.

Extensibility of the WP3 software prototype

During the remainder of the BRIDGE project (to 30 June 2009),remaining tasks in WP3 will focus on extensions and additional features to support applications in:

• Manufacturing

• Management of reusable assets

• Serial-level condition monitoring

Task 3.3Serial-level

manufacturingcontrol

Task 3.4Reusable assetmanagement

Task 3.5Application

ProgrammingInterface

Task 3.6Serial-levelConditionMonitoring

WP8(Manufacturing)

WP9(Reusable assets) All business

application WPsWP8

(Manufacturing)

'Enhanced track & trace' - summary• Each company will be able to run their own local instance of the enhanced

track and trace software, which will gather and analyze the event data the company generates internally as well as any event data the company is allowed to receive from its supply chain partners

• The software will take care of interfacing with Discovery Services and EPC Information Services... as well as performing iterative queries and tracking up & down different levels of aggregation (changes of containment hierarchy)to achieve end-to-end tracking

• Probabilistic algorithms are used to 'learn' the flow patterns for various classes of object/product - and to refine the data, to eliminate false positives and false negatives.

• Business will be able to specify high-level queries and alerting rules, in order to be informed about potential problems, so they can investigate or take corrective action

Air

Inte

rfac

e(U

HF

Cla

ss1G

en

2 /

IS

O 1

8000

-6C

)

Tag

s

It does not make sense to connectRFID readers directly to Business Applications

RFID readers (and sensors) may generate too much dataWe don't want to overload applications / network

Business applications need information - not raw event data

Rea

ders

Bus

ines

s A

pplic

atio

ns

Eve

nt C

aptu

re A

pplic

atio

n

Eve

nt R

epos

itorie

s

Dis

cove

ry S

ervi

ces

WP

3 E

nhan

ced

Tra

ckin

g M

odel

s&

App

licat

ion-

spec

ific

exte

nsio

ns

Filt

erin

g M

iddl

ewar

e

Tag

Dat

a S

tan

dar

ds

& T

ran

slat

ion

Rea

der

Pro

toco

l / L

ow

-lev

el R

P

EP

CIS

Qu

ery

Inte

rfac

e

EP

CIS

Cap

ture

Inte

rfac

e

Ap

plic

atio

n L

evel

Eve

nts

(A

LE

)

detect &

identify filter enhance

AP

I for

WP

3 tr

acki

ng m

odel

s

DS

Que

ry In

terf

ace

DS

Pub

lishe

r In

terf

ace

store &

share gather

what, where, when + why, which transactions

which business step(where next)

aggregation changes?

where to find the info

business questionsand alerting

analyze decide

& act

ON

S 1

.0

ON

S

Ratified EPCglobal standards WP2 WP3

EPC Network architecture - with extensions by

Further reading and Acknowledgements

BRIDGE project public deliverables - see WP 2, WP3 & WP4

http://www.bridge-project.eu/index.php/public-deliverables/en/

I would like to acknowledge our partners in the BRIDGE project:

WP2

WP3

Thank you for your attention!

Questions?

mark.harrison@cantab.net