IoT Interoperability: 
A Hub Based Approach 
Michael Blackstock, Rodger Lea 
Human Communication Technologies Lab 
Electrical and Computer Engineering Department 
University of British Columbia 
1
Motivation 
• Connection of things to the internet is not enough 
• Realize potential of the IoT by providing ability to find, 
access, manage and (inter)connect things 
• Logical next step is to exploit the web - HTTP, JSON, 
RESTful web services - a “Web of Things” 
• MAGIC Broker at IoT 2010; WoTKit at IoT 2012 
• Today, large scale hubs store thing data, support 
search and interaction 
2
IoT Hubs 
• General purpose and product-specific 
hubs aggregate representation of 
things and their (meta) data 
• easier for app developers 
• can include related data & resources 
• Do not (typically) interoperate with 
each other 
• Standardization process necessary to 
avoid islands of things 
• Early standardization may stifle 
innovation 
• Need a balanced path toward 
Interoperability 
3
Path to Hub Interoperability 
Model Hub Profiles 
4 
IoT Core 
Expose things and 
associated metadata 
using web protocols. 
Minimal interoperability 
leaving app and tool 
developers to do more 
of the work. 
Agreement on 
approaches and 
models 
e.g. catalogs, things, 
groups of things 
Eases adapter 
development. 
Implementation 
decisions on 
resources, 
representations, 
access control and 
security for hubs. 
Direct adapter code 
reuse is possible. 
Ontologies and 
semantics of things 
and data. Deeper 
integration is possible 
and little or no 
adaptation required. 
from experience, refine models, 
implementation and profiles
IoT Ecosystem Demonstrator 
• UK Technology Strategy 
Board Funded 8 IoT Hubs 
• Stimulate development of IoT 
applications and services 
• All 8 in different clusters/ 
domains 
• A key goal - interoperability 
between clusters 
DISTANCE 
5 
Small IoT Interop 
Highways 
Airports 
Smart Buildings 
Transportation 
Smart Campus 
Vehicles 
Schools and Education 
IoT-Bay
Approach 
• Web technologies at the 
core, often using existing 
IoT platforms 
• Each consortium 
implements one or more 
‘hubs’ 
• Hubs communicate with 
things to expose them to 
applications 
6 
AApppplilcicaatitoionn Application 
IoT Hub 
Things and data 
Other 
Hubs 
Other 
Hubs 
Other 
Hubs
TSB Project Interop API 
• Provide access to “thing” data 
and information about what 
that data represents. 
• Focus on interface between 
applications and hub. Use 
data from at least one other 
hub. 
• Lightweight, minimal 
requirements for exchanging 
catalogs of things - HyperCat 
7 
AApppplilcicaatitoionn Application 
IoT Hub 
Things and data 
Other 
Hubs 
Other 
Hubs 
Other 
Hubs 
1 
2 
3
HyperCat 
• Open catalogue format for 
collections of web resources 
• not just IoT resources 
• JSON format where ‘things’ 
identified as resources 
(URLs) 
• RDF-like relationship/value 
pairs describe what thing 
resources represent or 
data associated with things 
• defines CRUD operations 
• basic search, security 
8
Simple Catalogue 
Catalogue 
Description 
{ "item-metadata":[ 
{ “rel”:”urn:X-tsbiot:rels:isContentType", 
"val":"application/vnd.tsbiot.catalogue+json" }, 
{ “rel":"urn:X-tsbiot:rels:hasDescription:en", 
"val":"Bare catalogue" } 
], “items":[ 
! 
{ "href":"http://hub.com/resource1", 
“i-object-metadata”: [ 
{ “rel":"urn:X-tsbiot:rels:hasDescription:en", 
"val":"The first resource" } ] 
}, 
! 
{ "href":"http://hub.com/resource2", 
“i-object-metadata”:[ 
{ “rel":"urn:X-tsbiot:rels:hasDescription:en", 
"val":"The second resource”}] 
} 
] } 
9 
Item 
Descriptions
HyperCat for open data 
Catalogue supports “Simple Search” 
Dataset Item URL 
Mandatory meta data - description 
and content type 
{ "item-metadata" : [ { "rel" : "urn:X-tsbiot:rels:isContentType",! 
"val" : "application/vnd.tsbiot.catalogue+json"! 
},! 
{ "rel" : "urn:X-tsbiot:rels:hasDescription:en",! 
"val" : "Smart Streets data catalogue that contains static resources."! 
},! 
{ "rel" : "urn:X-tsbiot:rels:supportsSearch",! 
"val" : "urn:X-tsbiot:search:simple"! 
}! 
],! 
"items" : [ ! 
{ "href" : “/cat/data/average-temperature-and-rainfall-england-and-wales",! 
"i-object-metadata" : ! 
[ { "rel" : "urn:X-smartstreets:rels:lastUpdate",! 
"val" : "2013-06-19T00:00:20.761429"! 
},! 
{ "rel" : "urn:X-smartstreets:rels:hasId",! 
"val" : "3f952707-b04e-4a32-a807-a53b6fa0ee58"! 
},! 
{ "rel" : "urn:X-smartstreets:rels:hasLicense",! 
"val" : "UK Open Government Licence (OGL)"! 
},! 
{ "rel" : "urn:X-smartstreets:rels:hasName:en",! 
"val" : "average-temperature-and-rainfall-england-and-wales"! 
},! 
{ "rel" : "urn:X-tsbiot:rels:hasDescription:en",! 
"val" : "Average temperature and total rainfall in England and Wales : 1845 to 2010"! 
},! 
{ "rel" : "urn:X-smartstreets:rels:tags",! 
"val" : "average-rainfall,average-temprature,england,new-tag-1,new-tag-2,wales"! 
},! 
{ "rel" : "urn:X-smartstreets:rels:hasVisibility",! 
"val" : "public"! 
},! 
{ "rel" : "urn:X-tsbiot:rels:isContentType",! 
"val" : "application/vnd.tsbiot.catalogue+json"! 
},! 
{ "rel" : "urn:X-tsbiot:rels:supportsSearch",! 
"val" : "urn:X-tsbiot:search:simple"! 
},! 
{ "rel" : "urn:X-tsbiot:rels:containsContentType",! 
"val" : "application/vnd.ms-excel"! 
}! 
]! 
},! 
{ ... additional items ... }! 
]! 
} 
exact match on rel or value
Smart Streets Hub 
• WoTKit IoT Platform at the 
core 
• Static data management: 
CKAN Open Data Portal 
• HyperCat API Proxy 
• Landing site and Hub ‘App 
Store’ 
11 
HyperCat API Proxy 
CKAN Open 
Data Portal 
Static 
Data 
Files 
Landing Site 
Apps Apps Apps 
WoTKit IoT Platform 
Sensor 
Gateways 
Sensor 
networks and 
real time 
updates
WoTKit 
• Web-centric IoT Toolkit - IoT 2012 
• Thing data manager and 
aggregator 
• 2 way: sense or control 
• Visualizations 
• Finding & sharing things 
• Access control and search by 
organizations, groups, tags, meta 
data 
• Real time processing and alerts 
• Commercialized by Sense 
Tecnic Systems 
12
Architecture 
• Management and 
visualization UI 
• Processing engine 
• RESTful API 
• Shared Thing Data Model 
• Time series data store, 
meta data index for search, 
message broker for real 
time data processing 
13
WoTKit Processor 
• multi-user real time IoT 
data and service 
mashup tool. 
• Visual data flow 
language for sensors 
and services. 
• See Web of Things 
Workshop paper for 
details 
14
CKAN Data Portal 
• Driven by need for related 
static data storage 
• CKAN Open Data portal 
platform used by many 
governments 
• publishers upload datasets 
consisting of data resources 
• API for search, up/ 
downloading data 
• extensible with plugins 
15
HyperCat API Proxy 
• Static Implementation - Imports 
catalogues from underlying 
systems to Solr. 
• Out of date between imports 
• Security: visibility and access 
control logic 
• Dynamic Implementation - Get 
underlying catalogue on request 
and filter as needed. 
• Unify access control 
• Address mismatch between 
search semantics 
• Scale of catalogue - paging 
needed 
16
Smart Streets Experience 
• In operation for 1 year ~64,000 
sensor feeds 
• Private and public data about 
transportation and highways, 
fixed assets and live sensors. 
• Live road traffic, gully levels, air 
quality, weather, flooding, fixed 
asset: signs, roads, barriers, 
parking locations, planned 
roadworks. 
• Sensors upload automatically via 
APIs. Assets uploaded manually. 
17
Hub Applications 
• ‘App store’ on the hub 
landing site 
• Developed by partner 
companies and hackathon 
• Catalog Explorer 
• Roadworks Mashup 
• Cycle Spot 
• Accident reporter 
• Pothole Prediction 
• School Run … 
https://smartstreets.sensetecnic.com/app-browse/ 
18
Lessons 
• UK project successful - innovation maintained while achieving a 
minimal degree of interoperability 
• Too early to standardize everything, need more experience and 
to establish best practices first 
• balance (proprietary) innovation and open standardization 
• Cloud-hosted web-based hubs allow abstraction of connectivity 
details and allowed us to pull together variety of sub-systems 
and data services. 
• Simple catalogue spec made it easier to agree, and provided 
flexibility on the type and scope of ‘things’ exposed by hubs 
19
Conclusions 
• Interoperability is critical to achieving widest variety of 
applications and services in the IoT 
• A web-centric, hub-based approach is a logical first step 
toward allowing web developers to access ‘things’ and 
associated data 
• A key challenge is to unify hub catalogues, then thing data. 
HyperCat is a good first step toward catalogue interoperability 
• Tools such as the API Proxy can be used to address catalogue 
and data interoperability while standards like HyperCat evolve 
20
More Information 
• HyperCat: 
http://www.hypercat.io/ 
http://wiki.1248.io/doku.php?id=hypercat! 
• Smart Streets: 
https://smartstreets.sensetecnic.com/ 
• WoTKit: 
! ! http://wotkit.sensetecnic.com/! 
• Sense Tecnic Systems: http://sensetecnic.com/ @sensetecnic! 
• See demo and paper on distributed data flow at WoT Workshop 
Thanks to Mark Duppenthaler, Daniel Yuen, Smart Streets IoT project Team - In Touch, Lancaster 
University, Other 8 IoT hub projects - HyperCat specification, UK TSB, Canada NSERC 
21

IoT Interoperability: a Hub-based Approach

  • 1.
    IoT Interoperability: AHub Based Approach Michael Blackstock, Rodger Lea Human Communication Technologies Lab Electrical and Computer Engineering Department University of British Columbia 1
  • 2.
    Motivation • Connectionof things to the internet is not enough • Realize potential of the IoT by providing ability to find, access, manage and (inter)connect things • Logical next step is to exploit the web - HTTP, JSON, RESTful web services - a “Web of Things” • MAGIC Broker at IoT 2010; WoTKit at IoT 2012 • Today, large scale hubs store thing data, support search and interaction 2
  • 3.
    IoT Hubs •General purpose and product-specific hubs aggregate representation of things and their (meta) data • easier for app developers • can include related data & resources • Do not (typically) interoperate with each other • Standardization process necessary to avoid islands of things • Early standardization may stifle innovation • Need a balanced path toward Interoperability 3
  • 4.
    Path to HubInteroperability Model Hub Profiles 4 IoT Core Expose things and associated metadata using web protocols. Minimal interoperability leaving app and tool developers to do more of the work. Agreement on approaches and models e.g. catalogs, things, groups of things Eases adapter development. Implementation decisions on resources, representations, access control and security for hubs. Direct adapter code reuse is possible. Ontologies and semantics of things and data. Deeper integration is possible and little or no adaptation required. from experience, refine models, implementation and profiles
  • 5.
    IoT Ecosystem Demonstrator • UK Technology Strategy Board Funded 8 IoT Hubs • Stimulate development of IoT applications and services • All 8 in different clusters/ domains • A key goal - interoperability between clusters DISTANCE 5 Small IoT Interop Highways Airports Smart Buildings Transportation Smart Campus Vehicles Schools and Education IoT-Bay
  • 6.
    Approach • Webtechnologies at the core, often using existing IoT platforms • Each consortium implements one or more ‘hubs’ • Hubs communicate with things to expose them to applications 6 AApppplilcicaatitoionn Application IoT Hub Things and data Other Hubs Other Hubs Other Hubs
  • 7.
    TSB Project InteropAPI • Provide access to “thing” data and information about what that data represents. • Focus on interface between applications and hub. Use data from at least one other hub. • Lightweight, minimal requirements for exchanging catalogs of things - HyperCat 7 AApppplilcicaatitoionn Application IoT Hub Things and data Other Hubs Other Hubs Other Hubs 1 2 3
  • 8.
    HyperCat • Opencatalogue format for collections of web resources • not just IoT resources • JSON format where ‘things’ identified as resources (URLs) • RDF-like relationship/value pairs describe what thing resources represent or data associated with things • defines CRUD operations • basic search, security 8
  • 9.
    Simple Catalogue Catalogue Description { "item-metadata":[ { “rel”:”urn:X-tsbiot:rels:isContentType", "val":"application/vnd.tsbiot.catalogue+json" }, { “rel":"urn:X-tsbiot:rels:hasDescription:en", "val":"Bare catalogue" } ], “items":[ ! { "href":"http://hub.com/resource1", “i-object-metadata”: [ { “rel":"urn:X-tsbiot:rels:hasDescription:en", "val":"The first resource" } ] }, ! { "href":"http://hub.com/resource2", “i-object-metadata”:[ { “rel":"urn:X-tsbiot:rels:hasDescription:en", "val":"The second resource”}] } ] } 9 Item Descriptions
  • 10.
    HyperCat for opendata Catalogue supports “Simple Search” Dataset Item URL Mandatory meta data - description and content type { "item-metadata" : [ { "rel" : "urn:X-tsbiot:rels:isContentType",! "val" : "application/vnd.tsbiot.catalogue+json"! },! { "rel" : "urn:X-tsbiot:rels:hasDescription:en",! "val" : "Smart Streets data catalogue that contains static resources."! },! { "rel" : "urn:X-tsbiot:rels:supportsSearch",! "val" : "urn:X-tsbiot:search:simple"! }! ],! "items" : [ ! { "href" : “/cat/data/average-temperature-and-rainfall-england-and-wales",! "i-object-metadata" : ! [ { "rel" : "urn:X-smartstreets:rels:lastUpdate",! "val" : "2013-06-19T00:00:20.761429"! },! { "rel" : "urn:X-smartstreets:rels:hasId",! "val" : "3f952707-b04e-4a32-a807-a53b6fa0ee58"! },! { "rel" : "urn:X-smartstreets:rels:hasLicense",! "val" : "UK Open Government Licence (OGL)"! },! { "rel" : "urn:X-smartstreets:rels:hasName:en",! "val" : "average-temperature-and-rainfall-england-and-wales"! },! { "rel" : "urn:X-tsbiot:rels:hasDescription:en",! "val" : "Average temperature and total rainfall in England and Wales : 1845 to 2010"! },! { "rel" : "urn:X-smartstreets:rels:tags",! "val" : "average-rainfall,average-temprature,england,new-tag-1,new-tag-2,wales"! },! { "rel" : "urn:X-smartstreets:rels:hasVisibility",! "val" : "public"! },! { "rel" : "urn:X-tsbiot:rels:isContentType",! "val" : "application/vnd.tsbiot.catalogue+json"! },! { "rel" : "urn:X-tsbiot:rels:supportsSearch",! "val" : "urn:X-tsbiot:search:simple"! },! { "rel" : "urn:X-tsbiot:rels:containsContentType",! "val" : "application/vnd.ms-excel"! }! ]! },! { ... additional items ... }! ]! } exact match on rel or value
  • 11.
    Smart Streets Hub • WoTKit IoT Platform at the core • Static data management: CKAN Open Data Portal • HyperCat API Proxy • Landing site and Hub ‘App Store’ 11 HyperCat API Proxy CKAN Open Data Portal Static Data Files Landing Site Apps Apps Apps WoTKit IoT Platform Sensor Gateways Sensor networks and real time updates
  • 12.
    WoTKit • Web-centricIoT Toolkit - IoT 2012 • Thing data manager and aggregator • 2 way: sense or control • Visualizations • Finding & sharing things • Access control and search by organizations, groups, tags, meta data • Real time processing and alerts • Commercialized by Sense Tecnic Systems 12
  • 13.
    Architecture • Managementand visualization UI • Processing engine • RESTful API • Shared Thing Data Model • Time series data store, meta data index for search, message broker for real time data processing 13
  • 14.
    WoTKit Processor •multi-user real time IoT data and service mashup tool. • Visual data flow language for sensors and services. • See Web of Things Workshop paper for details 14
  • 15.
    CKAN Data Portal • Driven by need for related static data storage • CKAN Open Data portal platform used by many governments • publishers upload datasets consisting of data resources • API for search, up/ downloading data • extensible with plugins 15
  • 16.
    HyperCat API Proxy • Static Implementation - Imports catalogues from underlying systems to Solr. • Out of date between imports • Security: visibility and access control logic • Dynamic Implementation - Get underlying catalogue on request and filter as needed. • Unify access control • Address mismatch between search semantics • Scale of catalogue - paging needed 16
  • 17.
    Smart Streets Experience • In operation for 1 year ~64,000 sensor feeds • Private and public data about transportation and highways, fixed assets and live sensors. • Live road traffic, gully levels, air quality, weather, flooding, fixed asset: signs, roads, barriers, parking locations, planned roadworks. • Sensors upload automatically via APIs. Assets uploaded manually. 17
  • 18.
    Hub Applications •‘App store’ on the hub landing site • Developed by partner companies and hackathon • Catalog Explorer • Roadworks Mashup • Cycle Spot • Accident reporter • Pothole Prediction • School Run … https://smartstreets.sensetecnic.com/app-browse/ 18
  • 19.
    Lessons • UKproject successful - innovation maintained while achieving a minimal degree of interoperability • Too early to standardize everything, need more experience and to establish best practices first • balance (proprietary) innovation and open standardization • Cloud-hosted web-based hubs allow abstraction of connectivity details and allowed us to pull together variety of sub-systems and data services. • Simple catalogue spec made it easier to agree, and provided flexibility on the type and scope of ‘things’ exposed by hubs 19
  • 20.
    Conclusions • Interoperabilityis critical to achieving widest variety of applications and services in the IoT • A web-centric, hub-based approach is a logical first step toward allowing web developers to access ‘things’ and associated data • A key challenge is to unify hub catalogues, then thing data. HyperCat is a good first step toward catalogue interoperability • Tools such as the API Proxy can be used to address catalogue and data interoperability while standards like HyperCat evolve 20
  • 21.
    More Information •HyperCat: http://www.hypercat.io/ http://wiki.1248.io/doku.php?id=hypercat! • Smart Streets: https://smartstreets.sensetecnic.com/ • WoTKit: ! ! http://wotkit.sensetecnic.com/! • Sense Tecnic Systems: http://sensetecnic.com/ @sensetecnic! • See demo and paper on distributed data flow at WoT Workshop Thanks to Mark Duppenthaler, Daniel Yuen, Smart Streets IoT project Team - In Touch, Lancaster University, Other 8 IoT hub projects - HyperCat specification, UK TSB, Canada NSERC 21