TrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
CCNA-Open-Platform-IoT
1. Open
Horizontal
Pla/orm
Web
Scale
Interoperability
for
the
Internet
of
Things
Michael
J
Koster
Open
Source
Internet
Of
Things
2. M2M
–
Things
Connected
to
Apps
Separate
end-‐to-‐end
ver7cal
applica7on
stacks
Applica7on
So9ware
Pla3orms
M2M
Protocols
Devices,
Data
Sources
App
API
CoAP
App
API
MQ
App
API
HTTP
App
• Each
app
runs
on
it’s
own
service
–
SPOF
SDK
• Each
app
wriLen
to
a
custom
API
SOA
• Apps
are
not
network-‐
effect
enabled
• Diverse
M2M
is
somePmes
required
but
can
inhibit
interoperability
• SoRware,
User
data,
and
Things
are
trapped
in
Silos
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
• 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
ApplicaPons
Discovery
Common
Abstrac7ons
Web
Objects,
Data
Models
REST
API
+
Events
M2M
CoAP
• Web
Objects
• REST
+
Event
Model
• M2M
Abstrac9ons
• Model
Driven
M2M
M2M
HTTP
M2M
MQTT
SOA
Models
Connected
Things,
Sensors,
Actuators,
Data
Sources
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
Web
protocol
interfaces,
also
M2M
e.g.
MQTT,
XMPP,
…
Encapsulates
local
soRware
components
and
handlers
Event
Model
Links
data
with
acPons
Pub-‐Sub
and
event
handlers
Smart
Object
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
PropertyOfInterest
(Object
Data)
ObservableProperty…
Descrip7on
(Data
Model
Metadata)
Agent
Observers
(Event
Model
Metadata)
Handler
Instance
Publisher
Daemon
Subscriber
Handler
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. SemanPc
and
Protocol
Interoperability
• Separate
Control
Plane
and
Data
Plane
– Common
Data
Models
Enable
Diverse
M2M
Protocols
Between
Smart
Objects
Applica7on
Smart
Object
API
DM
Any
M2M
Protocol
Anywhere
Applica7on
Smart
Object
API
Common
DM
Abstrac7ons
• Any
Original
Catalog
or
Seman7c
Format
– Smart
Object
stores
RDFModel
Format,
translates
others
using
a
SemanPc
Proxy
Seman7c
Proxy
• Applica7ons
see
one
API
– With
suitable
metadata
representaPon
TSB
IPSO
SSN
Seman7c
Models:
Catalogs,
Repositories,
Diverse
Metadata
11. Model
Driven
Architecture
Event
Driven
CommunicaPon
Gateways
Endpoints
• Sensors
• Devices
CoAP
Server
Cloud
SO
MQTT
SO
MQTT
HTTP
SO
HTTP
XMPP
ApplicaPon
Components
And
Resources
CoAP
Registry
-‐
Instances
• Discovery
• Persistence
• ReplicaPon
• Resource
Access
Repository
-‐
Models
Models
• Data
Models
• Sensor
Models
• Machine
Models
• Templates
Object
Metadata
Databases
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
Connects
REST
Resource
to
MQTT
Topic
Publish
and
Subscribe
PUT
GET
REST
Endpoint
ObservableProperty
mqLObserver
Publish
From
REST
API
Publish
from
data
producer
SUB
MQTT
Broker
Publish
to
REST
API
Publish
to
Other
Subscribers
15. MQTT
Observer
Publisher
Publishes
REST
Resource
updates
to
the
broker
PUT
GET
REST
Endpoint
ObservableProperty
mqLObserver
Publish
From
REST
API
Publish
from
data
producer
SUB
MQTT
Broker
Publish
to
REST
API
Publish
to
Other
Subscribers
16. MQTT
Observer
Subscriber
Makes
last
published
data
available
at
the
REST
endpoint
PUT
GET
REST
Endpoint
ObservableProperty
mqLObserver
Publish
From
REST
API
Publish
from
data
producer
SUB
MQTT
Broker
Publish
to
REST
API
Publish
to
Other
Subscribers
17. MQTT
Observer
Pub+Sub
Repeats
data
updates
in
both
direcPons
PUT
GET
REST
Endpoint
ObservableProperty
mqLObserver
Publish
From
REST
API
Publish
from
data
producer
SUB
MQTT
Broker
Publish
to
REST
API
Publish
to
Other
Subscribers
18. MQTT
Bridge
to
mulPple
REST
endpoints
PUT
GET
REST
Endpoint
ObservableProperty
mqLObserver
MQTT
Broker
mqLObserver
REST
Endpoint
ObservableProperty
Publish
from
data
producer
PUT
GET
Publish
to
Other
Subscribers
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
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
Cyberne7c
Feedback
Loop
Model
Informs
Informs
View
Updates
Autonomic
Feedback
Loop
Actuates
Controller
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
Catalogs
and
Repositories
IPSO
TSB
SSN
Sensors,
Things,
MQTT,
CoAP,
HTTP
REST
API
+
Events
IoT
Toolkit
• Model
– Object
Models,
Data
Models
– Storage,
Discovery,
Formats,
Protocols,
Binding
to
Objects
• Controller
Node
Builder
• Resource
Discovery
and
Linkage
• Builds
Smart
Object
Nodes
• Manages,
stores
Flow
Graph
Node-‐RED
Dojo
Dashboard
HTML5,
Mobile
Web
– 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
27. ApplicaPon
Development
Workflow
Node
Builder
Node-‐RED
• Discovers
Resources
• Builds
Applica9on
• Makes
Object
Instances
Flow
Graphs
Dashboard
• UI
Construc9on
Data
Models
and
Catalogs
IPSO
TSB
SSN
Model
Controller
View
28. Run
Time
Deployment
Example
Personal
Service
Data
Models
and
Catalogs
SSN
HTTP/LD
IPSO
TSB
CoAP/RD
Local
Control
Gateway
HTTP
+
MQTT
Node-‐RED
IoT
Toolkit
CoAP
Node-‐RED
IoT
Toolkit
CoAP
CoAP
IoT
Provider
HTTP
HTTP
HTTP
UI
Devices
IoT
Toolkit
Gateway
as
a
Service
CoAP
29. Weather
sensor
example
Client
(Xively)
Xively
acts
as
client
applicaPon
and
receives
updates
from
the
cloud
service
acPng
as
GaaS
Internet
Sensor
Hardware
• Wind
Speed
• Wind
DirecPon
• Rainfall
• Temperature
• Humidity
• Barometer
Cloud
Server
Cloud
Server
acts
as
Gateway-‐as-‐a-‐Service
for
Xively
Receives
updates
from
the
gateway,
Observers
Send
periodic
updates
to
Xively
feed
Internet
Gateway
(Rpi)
Gateway
runs
Smart
Object
API
and
exposes
HTTP
interface,
adds
descripPonand
other
resources,
Observers
send
updates
to
cloud
server
Local
Ethernet
Sensor
(Arduino)
Reads
sensor
elements
and
creates
sensor
output
values
to
update
Smart
Object
in
the
Gateway
using
a
simple
hLp
client