Navigating the web of things Challenges and Applications

1. Navigating the web of things Challenges and Applications Mark Harrison mark.harrison@cantab.net

2. Navigating the Web of Things mechanisms to help us find relevant information Search Query Indexing Linking begin our search with a keyword or the ID of an individual object a collection of fragments of information multiple contributors, stakeholders, owners of data gather multiple fragments to build the complete picture remote access physical objects move around handled & ownedby many people / organizationsat different times within supply chains during use at end-of-life

3. 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

4. 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

5. Class-level vs Serial-level information 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)

6. 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

7. Lookup services - why ONS isn't enough ObjectNameService(ONS) Discovery Service

8. 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)

9. 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

10. Some specific challenges Scalability of access control permissions Potential number of permissions per objectcould be of order N2where N is number ofcompanies in chain / lifecycleNeed a more scalable solution Supply chain or lifecycle

11. Some specific challenges Fragility 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'

12. Some specific challenges Fragility of URLs over time (broken hyperlinks) Discovery Service ResourceID=... DS RecordEPC or ID Timestamp ResourceID [other metadata] Resource ProfileURL serviceType ResourceID Resourcee.g.EPCIS

13. Some specific challenges Suppression 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 / DENYbut 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

14. Some specific challenges Overcoming '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.

15. Some specific challenges QueryClient Overcoming 'deadlock' before trust is established Request for access, Quoting token Opaque token 0A8274B2845EF Discovery Service Request for accessfrom client with ID... "I hold information about EPC xyz- but hide my real ID & contact info from unauthorized / unknown clients" Resourcee.g.EPCIS

16. DS #1 DS #2 DS #3 Some specific challenges 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

17. 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

18. Comparison of different interaction models One-off queries Standing queries Directory of Resources Notification of Resources EPC, URL, serviceType EPC, Client ID Intermediarye.g. DS Resourcee.g.EPCIS QueryClient Intermediarye.g. DS Resourcee.g.EPCIS QueryClient Setup Setup Discovery Discovery Fulfillment Fulfillment Query Propagation Meta Client EPC, URL, serviceType EPCIS query, Client ID QueryClient Intermediarye.g. DS Resourcee.g.EPCIS QueryClient Intermediarye.g. DS Resourcee.g.EPCIS

19. Comparison of different interaction models • 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 ofDenial of Service attacks, Honeypot harvesting

20. 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.

21. Software prototype of a Discovery Service Implemented by AT4 wireless & AIDA Query Application SOAP EPCIS Repository Accada DS SOAP SOAP http DS-Query Interface Standing Query Inteface http Query Proxy Layer Sniffer Filtering SOAP Schedule Checker DS Std Query Repository http IS-DS Interface DS Core Repository http EPCIS Capture Interface Accada Messaging Service Publish Proxy Layer http Event-Manager Interface http DS-Publish Interface Publish Application SOAP SOAP

22. 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

23. Beyond Discovery Services - Applications 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) Discovery Services help authorized authenticated clients to find one or morepossibly relevantinformation resourcesfor an EPC or ID

24. 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

25. Supply Chain Network Model GLN:123456789 GLN:567891234 Discovery Services Storage Area Receiving Area Shipping Area Receiving Area EPCIS Dock #3 Door #1 Dock #1 Shelf #3 Dock #1 Shelf #1 Dock #2 Dock #2 Door #2 Shelf #2

26. NODES Connection_Observations Spatial_Separations average transit timesbetween nodes, standard deviations distancesbetween nodes,intrinsic speeds ∆t x km Transitions Paths 30% which paths between nodesare permitted? branching ratiosfrom historicaldata 70% Event Log Current State Overview of database design Algorithms

27. 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)

28. AggEvt AggEvt AggEvt AggEvt AggEvt Add Add Obs Del Del Following changes of aggregation PALLET CASE ITEM Item packed into caseNeed to track case ID Case removed from palletNeed to track case ID time Item removed from caseResume tracking item ID Case packed onto palletNeed to track pallet ID

29. 40% 60% Probabilistic algorithms: Filling in the ‘gaps’ • Probabilistic reasoning enables: • Filtering: Where is it? Estimate current location given observations so far 1% 99% • Prediction: Where will it be next? Estimate future location given observations so far Location Most likely Observation

30. Probabilistic algorithms: Filling in the ‘gaps’ • Smoothing: Where has it been? Estimate past location given observations so far 1% 99% • Where did it go through? Estimate the most likely path that an item has followed given observations so far Location Most likely Observation

31. Probabilistic algorithms: Models and Algorithms Variable(Location) X t X t+1 X t+2 Evidence(Observation) yt yt+1 yt+2 Transition model Sensor model

32. Humanbeings BRIDGEWP3 Prototype BRIDGE WP3 software prototype for enhanced serial-level track & trace BusinessApplications GraphicalUser Interface High-level Application Programming Interface (API) internaldatabase Probabilistictrack & trace algorithms Non-probabilistictrack & trace algorithms Event Gathering Layer EPC Network Discovery Services EPC Information Services

33. BusinessApplications Humanbeings High-level Application Programming Interface (API) GraphicalUser Interface internaldatabase Probabilistictrack & trace algorithms Non-probabilistictrack & trace algorithms BRIDGEWP3 Prototype Event Gathering Layer EPC Network Discovery Services EPC Information Services 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, ...

34. 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')

35. 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.

36. 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 WP8(Manufacturing) WP9(Reusable assets) All businessapplication WPs WP8(Manufacturing) Task 3.3 Serial-levelmanufacturingcontrol Task 3.4 Reusable assetmanagement Task 3.5 ApplicationProgrammingInterface Task 3.6 Serial-levelConditionMonitoring

37. '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

38. what, where, when where to find the info + why, which transactions which business step (where next) aggregation changes? business questionsand alerting EPC Network architecture - with extensions by Ratified EPCglobal standards WP2 WP3 detect & identify filter enhance store &share gather analyze decide& act It does not make sense to connectRFID readers directly to Business Applications ONS ONS 1.0 Air Interface(UHF Class1Gen 2 / ISO 18000-6C) EPCIS Capture Interface Reader Protocol / Low-level RP Tag Data Standards & Translation Application Level Events (ALE) EPCIS Query Interface API for WP3 tracking models WP3 Enhanced Tracking Models& Application-specific extensions Tags Readers Filtering Middleware Event Capture Application Event Repositories Business Applications Discovery Services DS Publisher Interface DS Query Interface RFID readers (and sensors) may generate too much data We don't want to overload applications / network Business applications need information - not raw event data

39. 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

40. Thank you for your attention!Questions? mark.harrison@cantab.net