1. Open
Horizontal
Pla/orm
Web
Scale
Interoperability
for
the
Internet
of
Things
Michael
J
Koster
Open
Source
Internet
Of
Things

2. API
M2M
–
Things
Connected
to
Apps
CoAP
MQ
SOA
HTTP
App
API
App
API
App
SDK
App
• Each
app
runs
on
it’s
own
service
–
SPOF
• Each
app
wriLen
to
a
custom
API
• Apps
are
not
network-­‐
effect
enabled
• Diverse
M2M
is
somePmes
required
but
can
inhibit
interoperability
• SoRware,
User
data,
and
Things
are
trapped
in
Silos
Devices,
Data
Sources
M2M
Protocols
Pla3orms
Applica7on
So9ware
Separate
end-­‐to-­‐end
ver7cal
applica7on
stacks

3. The
Interoperability
Problem
• Each
deployment
is
it’s
own
end-­‐to-­‐end
system
with
ad-­‐hoc
and
incompaPble
architecture
• Difficult
to
connect
new
types
of
things
and
deploy
new
pla/orms
• Very
difficult
to
share
resources
or
connect
across
pla/orms
• Silos
are
traps
• Devices
are
trapped
• Code
is
trapped
• User
experience
is
trapped
• Single
Point
Of
Failure
for
all
these

4. SoluPon:
Open
Pla/orm
for
IoT
• Interoperability
=
Interchangeability
– Any
ApplicaPon
SoRware
– Any
Connected
Object
– Any
M2M
Protocol
• Break
The
Silos
– Allow
second
sources
for
devices,
pla/orms,
soRware,
and
user
experiences
• Horizontal
IntegraPon
– “Network
Effect”
applicaPons
spanning
many
diverse
connected
objects
and
data
sources

5. IoT
2.0
–
Interoperability
M2M
CoAP
M2M
MQTT
M2M
SOA
M2M
HTTP
Common
Abstrac7ons
Web
Objects,
Data
Models
REST
API
+
Events
Discovery
ApplicaPons
• Web
Objects
• REST
+
Event
Model
• M2M
Abstrac9ons
• Model
Driven
Connected
Things,
Sensors,
Actuators,
Data
Sources
Models
• Any
app
to
any
thing
via
any
M2M,
use-­‐
case
decides
M2M
• Easy
to
deploy
new
things
and
applicaPons
using
data
models
• Write
once,
run
anywhere
soRware
• Network
effect
enabled

6. Data
Models
Drive
Interoperability
• Data
models
enable
machine
understanding
independent
of
M2M
protocols
–
SoCware
uses
common
abstrac9ons
• Enable
choice
of
suitable
M2M
protocols
• Enable
reusable
soRware
components
• Ability
to
reuse
and
repurpose
resources
• Ease
of
integraPng
data
from
diverse
sources
• Diverse
UI
pla/orms
• Object
Models
and
SemanPc
Models

7. Object
Model
–
API
Interoperability
Web
Object
EncapsulaPon
Smart
Object
Web
protocol
interfaces,
also
M2M
e.g.
MQTT,
XMPP,
…
Event
Model
Links
data
with
acPons
Pub-­‐Sub
and
event
handlers
Encapsulates
local
soRware
components
and
handlers
Self-­‐describing
data
model
For
Resource
Discovery
and
Linkage,
RDF
and
core-­‐
link-­‐format
Sensor
or
other
data
JSON,
XML,
data
feeds

8. Object
Model
Defines
the
Structure
of
the
Data
and
Metadata
Smart
Object
DescripPon
ObservableProperty
ObservableProperty…
Agent
Publisher
Subscriber
Handler
PropertyOfInterest
(Object
Data)
Descrip7on
(Data
Model
Metadata)
Observers
(Event
Model
Metadata)
Handler
Instance
Daemon

9. Data
Model
–
SemanPc
Model
• SemanPc
model
describes
the
meaning
of
data
and
informs
applicaPon
soRware
• Enables
discovery
and
linkage
by/to
applicaPon
soRware
by
selected
aLributes
of
the
data
and
object
• Built
from
common
concepts
and
relaPons
• SemanPc
triples
format:
Subject-­‐Predicate-­‐Object
or
Subject-­‐RelaPon-­‐Value
• Many
data
representaPon
formats
exist
for
Linked
Data
compaPbility,
S-­‐P-­‐O
graph
relaPon
is
a
subset
representable
in
most
formats
• Represent
annotaPons
like
units=celsius,
highlimit=100,
also
measurement
context
like
Pme
and
locaPon
• Subset
of
web
linking

10. DM
SemanPc
and
Protocol
Interoperability
• Separate
Control
Plane
and
Data
Plane
– Common
Data
Models
Enable
Diverse
M2M
Protocols
Between
Smart
Objects
• Any
Original
Catalog
or
Seman7c
Format
– Smart
Object
stores
RDFModel
Format,
translates
others
using
a
SemanPc
Proxy
• Applica7ons
see
one
API
– With
suitable
metadata
representaPon
SSN
TSB
IPSO
Seman7c
Proxy
DM
Any
M2M
Protocol
Anywhere
Common
Abstrac7ons
Seman7c
Models:
Catalogs,
Repositories,
Diverse
Metadata
Smart
Object
API
Applica7on
Smart
Object
API
Applica7on

11. Model
Driven
Architecture
Event
Driven
CommunicaPon
SO
SO
SO
Gateways
Server
Cloud
Endpoints
• Sensors
• Devices
ApplicaPon
Components
And
Resources
Object
Metadata
Databases
Registry
-­‐
Instances
Repository
-­‐
Models
Models
• Discovery
• Persistence
• ReplicaPon
• Resource
Access
• Data
Models
• Sensor
Models
• Machine
Models
• Templates
HTTP
MQTT
CoAP
XMPP
HTTP
CoAP
MQTT

12. Real
Time
Event
Model
• IoT
Pla/orms
need
to
support
real
Pme
event
driven
processing
• Interoperability
through
standard
abstracPons
for
events
and
acPons
• Connects
REST
APIs
to
Publish-­‐Subscribe
Protocols
and
ApplicaPon
Event
Handlers
• ObservaPon
PaLerns
– CoAP
GET+Observe
– REST
API
broker,
REST
API
hooks:
Event-­‐on-­‐update

13. Resource
Observer
• REST
hook
paLern,
create
hook
as
a
resource
• Resource
properPes
specify
event
acPons
e.g.
MQTT
publish,
broker
and
topic,
etc.
• Publisher
–
publishes
REST
updates
to
broker
• Subscriber
–
updates
REST
endpoint
from
broker
• Handler
–
invokes
soRware
event
handler

14. Event
Model
-­‐
MQTT
Observer
MQTT
Broker
REST
Endpoint
ObservableProperty
mqLObserver
PUT
GET
Publish
from
data
producer
Publish
From
REST
API
Publish
to
Other
Subscribers
SUB
Publish
to
REST
API
Connects
REST
Resource
to
MQTT
Topic
Publish
and
Subscribe

15. MQTT
Observer
MQTT
Broker
REST
Endpoint
ObservableProperty
mqLObserver
PUT
GET
Publish
from
data
producer
Publish
From
REST
API
Publish
to
Other
Subscribers
SUB
Publish
to
REST
API
Publisher
Publishes
REST
Resource
updates
to
the
broker

16. MQTT
Observer
MQTT
Broker
REST
Endpoint
ObservableProperty
mqLObserver
PUT
GET
Publish
from
data
producer
Publish
From
REST
API
Publish
to
Other
Subscribers
SUB
Publish
to
REST
API
Subscriber
Makes
last
published
data
available
at
the
REST
endpoint

17. MQTT
Observer
MQTT
Broker
REST
Endpoint
ObservableProperty
mqLObserver
PUT
GET
Publish
from
data
producer
Publish
From
REST
API
Publish
to
Other
Subscribers
SUB
Publish
to
REST
API
Pub+Sub
Repeats
data
updates
in
both
direcPons

18. MQTT
Bridge
to
mulPple
REST
endpoints
MQTT
Broker
REST
Endpoint
ObservableProperty
mqLObserver
PUT
GET
Publish
from
data
producer
Publish
to
Other
Subscribers
REST
Endpoint
ObservableProperty
mqLObserver
PUT
GET

19. Event
Model:
MQTT
Observer
• Publish,
Subscribe,
or
Pub+Sub
using
the
mqLObserver
resource
class
• Prototype
opens
a
connecPon
to
a
specified
broker
for
each
endpoint
Observers.create({'resourceName': 'mqttTestObserver',!
! ! ! ! ! 'resourceClass': 'mqttObserver',!
'connection': 'smartobjectservice.com',!
'pubTopic': ’sealevel_pressure',!
'subTopic': None,!
'QoS': 0,!
'keepAlive': 60 })!

20. Resource
Access
Control
• Resources
have
well
defined
ownership
and
access
control
policy,
based
on
graph
connecPons
to
owner
enPPes
like
people
and
insPtuPons
• Granular,
nuanced
access
control
can
specify
policies
and
constraints
using
graph
relaPons
• Owners
and
accessors
can
be
idenPfied
based
on
social
graph
connecPons
and
connecPons
to
the
physical
graph

21. Resource
Access
Control
-­‐
Social
Graph
Connected
to
Physical
Graph

22. Open
Source
SoRware
• Open
Source
soRware
enables
open
pla/orms
• Community
development
of
relevant
soluPons
• Creates
open
parPcipaPon
for
developers
and
users,
non-­‐discriminitory
• Can
be
independently
examined
and
evaluated
• Interoperates
and
integrates
more
easily
with
other
soRware
• Permissive
licenses
allow
embedding
code
in
other
soRware

23. Open
Horizontal
+
VerPcal
Pla/orm
• Components
are
interchangeable
in
the
verPcal
pla/orm
stack
as
well
as
interoperable
• Open
Stack
for
IoT
• Model-­‐View-­‐Controller
abstracPon
• Autonomic
Control
+
Human
InteracPon
• Devices,
protocols,
applicaPon
pla/orms,
UI
can
be
interchanged
and
customized
per
use
case
• Example
using
Open
Source
components

24. Model-­‐View-­‐Controller
Macro
PaLern
IoT
Feedback
Control
Loops
• Autonomic
and
cybernePc
feedback
loops
• People’s
intenPons
take
part
in
the
cybernePc
feedback
loop
Model
View
Controller
Informs
Updates
Informs
Actuates
Autonomic
Feedback
Loop
Cyberne7c
Feedback
Loop

25. Open
Source
IoT
Components
• Open
Source
Components
Available
– IoT
Toolkit
–
REST
API
+
Data
Models
+
Events
– Node-­‐RED
–
Graphical
ApplicaPon
Tool
– Dojo
UI
Toolkit
–
UI
tools
– MosquiLo
MQTT
Broker
and
Client
– RDFlib
with
SPARQL
–
Graph
storage
– Neo4J
Graph
Database
– CoAP
Clients
and
Servers
• Sufficient
to
build
a
complete
Pla/orm
Stack
• Components
allow
ApplicaPon
soRware
to
run
in
Local
Server,
Gateway,
and
Cloud
Service

26. Model-­‐View-­‐Controller
Macro
PaLern
Mapping
to
Open
Source
SoRware
Components
• Model
– Object
Models,
Data
Models
– Storage,
Discovery,
Formats,
Protocols,
Binding
to
Objects
• Controller
– Complex
Flow
Graphs
of
Event-­‐driven
modular
SW
– Python
and
node.js
• View
– UI
Toolkit
For
ApplicaPons
– Binding
of
UI
Components
to
Smart
Object
ProperPes
IoT
Toolkit
Node-­‐RED
Dojo
Dashboard
Node
Builder
IPSO
TSB
SSN
Catalogs
and
Repositories
Sensors,
Things,
MQTT,
CoAP,
HTTP
REST
API
+
Events
HTML5,
Mobile
Web
• Resource
Discovery
and
Linkage
• Builds
Smart
Object
Nodes
• Manages,
stores
Flow
Graph

27. ApplicaPon
Development
Workflow
IPSO
TSB
SSN
Data
Models
and
Catalogs
Node
Builder
Node-­‐RED
Dashboard
Model
Controller
View
• Discovers
Resources
• Makes
Object
Instances
• Builds
Applica9on
Flow
Graphs
• UI
Construc9on

28. Run
Time
Deployment
Example
TSB
SSN
IPSO
Data
Models
and
Catalogs
HTTP/LD
Node-­‐RED
Node-­‐RED
CoAP/RD
HTTP
HTTP
+
MQTT
CoAP
HTTP
CoAP
HTTP
Local
Control
Gateway
Personal
Service
IoT
Provider
UI
Devices
Gateway
as
a
Service
IoT
Toolkit
IoT
Toolkit
IoT
Toolkit
CoAP
CoAP

29. Weather
sensor
example
Sensor
(Arduino)
Gateway
(Rpi)
Sensor
Hardware
• Wind
Speed
• Wind
DirecPon
• Rainfall
• Temperature
• Humidity
• Barometer
Reads
sensor
elements
and
creates
sensor
output
values
to
update
Smart
Object
in
the
Gateway
using
a
simple
hLp
client
Gateway
runs
Smart
Object
API
and
exposes
HTTP
interface,
adds
descripPonand
other
resources,
Observers
send
updates
to
cloud
server
Local
Ethernet
Cloud
Server
acts
as
Gateway-­‐as-­‐a-­‐Service
for
Xively
Receives
updates
from
the
gateway,
Observers
Send
periodic
updates
to
Xively
feed
Cloud
Server
Internet
Client
(Xively)
Internet
Xively
acts
as
client
applicaPon
and
receives
updates
from
the
cloud
service
acPng
as
GaaS

30. IoT
Toolkit
Interoperability
Demo
CoAP
MQTT
MQTT
HTTP
smartobjectservice.com
ec2-­‐54-­‐200-­‐106-­‐25.us-­‐
west-­‐2.compute.amazonaws.com
Node-­‐RED
Node-­‐RED

31. Thank
You!
This
PresentaPon:
hLp://www.slideshare.net/CCNA-­‐Open-­‐Pla/orm-­‐IoT
hLp://www.linkedin.com/pub/michael-­‐koster/
2/36b/317/
hLp://iot-­‐datamodels.blogspot.com/