1. Design
Pa*erns
for
an
Internet
Of
Things
Architecture,
Infrastructure,
Models,
and
Protocols
Michael
J
Koster
ARM

2. Design
Pa*ern
• A
Reusable
Solu?on
to
a
Commonly
Occurring
Problem
• A
Architecture
Structured
Collec?on
of
Design
Pa*erns
that
solves
a
Par?cular
Set
of
Problems
10/19/14
2

3. Use
Case
Examples
• Smart
Home
• Smart
Building
• Smart
City
(Parking,
Ligh?ng,
Traffic)
• Wearable
fitness/ac?vity
tracker
• Wearable
Interac?on
Device
• Connected
Vehicles
• Assisted
living
• Environmental
sensing
• Product
Life
Cycle
Management
• Logis?cs
and
Asset
Tracking
• Process
Control
and
Data
Collec?on

4. Some
High
Level
Design
Pa*erns
For
The
Internet
Of
Things
• Things
geYng
smarter
and
smarter
un?l
they
start
bossing
each
other
around…
• Billions
of
sensors
genera?ng
big
data
to
monitor,
analyze,
and
learn
new
stuff
from…
• A
system
of
using
networks
to
connect
things
and
people,
adding
distributed
intelligence
to
things,
to
create
a
so^ware
virtualiza?on
layer
on
top
of
the
physical
world

5. IoT
Local
System
View
Based
On
Things
Interac?ng
With
Other
Things
LOCAL
NETWORK

6. IoT
System
View
For
Big
Data™
ANALYZE
FILTER
COLLECT

7. System
View
For
Diverse
Use
Cases
Things
Control
People
Autonomic
Feedback
Loop
So.ware
Inform
Inform
Command
Actuate
Cyberne>c
Feedback
Loop
Observe

8. Abstract
Design
Pa*erns

9. Connected
Intelligence
Disrupts
Embedded
Intelligence
So^ware
Network
Thing
Connected
Intelligence
Embedded
Intelligence

10. Virtualiza?on
of
Things
So^ware
Applica?on
Network
So^ware
Abstrac?on
(Network)
Thing
Firmware,
Middleware
Device

11. Virtualiza?on
Enables
Many-­‐to-­‐Many
So^ware
Applica?ons
to
Things
So^ware
So^ware
So^ware
So^ware
Abstrac?ons
Thing
Middleware
Thing
Thing

12. Data
Model
So^ware
So^ware
So^ware
Data
Model
Thing

13. Data
Model
So^ware
So^ware
So^ware
Middleware
Thing

14. Design
Pa*erns
for
Network
Topology
–
Discovery
and
Interac?on

15. Interac?on
Pa*erns
Web
Applica?on
Applica?on
Service
e.g.
LWM2M
Sensor/
Actuator
Device
Device
with
Embedded
Applica?on
Applica?on
Server
Client
Peer-­‐Peer
Constrained
Device,
e.g.
16KB
RAM,
128KB
Flash
Smart
Object
Registra?on,
Discovery
and
Data
Layer
Service,
Device
Proxy
and
Cache
Applica?ons
can
Discover
and
Interact
with
devices
using
Peer-­‐Peer
networking
or
through
Services,
using
the
Same
Seman?cs

16. Device
Server
Middleware
Device
Server
BLE
Device
Web
App
Web
Browser,
Smartphone
App
APP
Proxy
Device
h*p
h*p/REST
CoAP
BLE
So^
Endpoints
IP
Device
IP
Device
IP
Device
Endpoints

17. Device
Server
Middleware
Device
Server
BLE
Device
Web
App
Web
Browser,
Smartphone
App
APP
Proxy
Device
h*p
h*p/REST
CoAP
BLE
So^
Endpoints
IP
Device
IP
Device
IP
Device
Endpoints

18. Device
Server
Middleware
Device
Server
BLE
Device
Web
App
Web
Browser,
Smartphone
App
APP
Proxy
Device
h*p
h*p/REST
CoAP
BLE
So^
Endpoints
IP
Device
IP
Device
IP
Device
Endpoints

19. Device
Server
Middleware
Device
Server
BLE
Device
Web
App
Web
Browser,
Smartphone
App
APP
Proxy
Device
h*p
h*p/REST
CoAP
BLE
So^
Endpoints
IP
Device
IP
Device
IP
Device
Endpoints

20. Middleware
Services
Device
Applica?on
So^ware
IP
Reachable
Web
Services
REST
API
Service
Resource
Directory
Message
Broker
REGISTER
DISCOVER
PUB/SUB
PUB/SUB
UPDATE
GET/NOTIFY
More
Constrained
Less
Reachable
Less
Constrained
Less
Reachable

21. Infrastructure
Device
NA
T
Applica?on
So^ware
NA
T
GW,
AP
GW,
AP
IP
Reachable
Web
Services
REST
API
Service
Resource
Directory
Message
Broker
IP
Reachable
or
Non
Reachable
Endpoints
IP
Reachable
or
Non
Reachable

22. Example
Configura?on
using
local
REST
Gateways
Pub/Sub
Updates
Device
REGISTER
DISCOVER
NA
T
Applica?on
So^ware
NA
T
REST
GW
REST
GW
Resource
Directory
Message
Broker
PUB/SUB
PUB/SUB
REST
REST

23. Internet
and
Web
Design
Pa*erns

24. Layered
Architecture,
Narrow
Waist
Applica?on
So^ware
IPSO
Objects
LWM2M
CoAP
Device
Management
HTTP
6LowPAN
IPV4/IPV6
802.15.4
WiFi,
Ethernet
MCU
–
16KiB
RAM
MPU
Applica?on
Data
Models
API
for
data
and
metadata
REST
Protocol
Rou?ng
HW
Network
Hardware
HTTP
REST
Server
10/19/14
24

25. REST
API
• Client-­‐Server
• Resource
Oriented
• CRUD
Seman?cs
• Hypermedia
Driven
Object
Encapsula?on
• Path
Hierarchy
-­‐
Inclusion
• Linking
–
Transclusion
• Transclusion
links
shared
resources

26. Client-­‐Server
Design
Pa*ern
§ Makes each device a lightweight server
that exposes a REST API
§ A CoAP device can be both client and
server
§ Roles can be reversed and the sensor,
as a client, can update a REST API at
another node, device or server

27. Object
Encapsula?on

28. Object
Encapsula?on

29. Data
Models

30. Data
Models
• Applica?on
Seman?cs
and
Hypermedia
• Device
and
Equipment
Models
• Resource
Templates
• Metadata
Schemas
• JSON,
XML,
Seman?c
Link
Formats
• Vocabularies
• Ontologies

31. Resource
Model
• So^ware
understands
the
thing
and
how
to
interact
with
it
through
abstract
models
• REST
is
a
resource
oriented
paradigm
• REST
data
describes
current
state
of
the
thing
–
state
is
external
to
applica?ons
–
enables
shared
state
between
applica?ons
• Metadata
describes
the
thing
and
it’s
context
• Real
?me
event
no?fica?on
using
observers,
and
event
bindings

32. Object
Models
• Web
object
encapsula?on
of
related
resources
within
a
REST
endpoint
• Various
Object
Models
and
resource
encapsula?ons
are
specified
• OMA
LWM2M
&
IPSO
Smart
Objects
use
an
object
template
system
• Core
Interfaces
and
Core-­‐Link-­‐Format
metadata
to
build
seman?c
models
• Hypercat
using
JSON
format
and
catalogs
of
links

33. Abstract
Object
Models
–
Virtual
Composite
Objects
• Constructed
or
composed
of
resources
from
one
or
more
endpoints
• May
be
abstrac?ons
or
filtered
versions
of
the
resource,
e.g.
24
hour
running
averages
• May
have
limited
access
e.g.
read-­‐only
for
publica?on
on
the
web

34. Object
Model
Metadata
• Hyperlinks
for
machines
(sensors
and
so^ware)
• Commonly
use
seman?c
triples
to
describe
links,
e.g.:
</sen/0/temp>;
if=‘sensor’,
rt=‘temperature’
• So^ware
understandable
metadata
enables
automa?c
discovery
and
linkage
of
resources
by
so^ware
• Devices
and
other
data
sources
register
their
resource
endpoints
at
Resource
Directories
or
Catalogs
by
uploading
metadata
• Applica?ons
discover
resources
by
querying
the
Resource
Directories
based
on
rela?ons
and
a*ributes
e.g.:
GET /.well-known/core?if=‘sensor’!

35. Data
(informa?on)
Model
Interoperability
• Point
of
interoperability
is
the
Resource
Directory
or
Catalog
• Applica?ons
can
access
any
sensor,
actuator,
or
data
stream
using
any
protocol
• If
applica?ons
can
use
the
catalog,
they
can
discover
and
interact
with
the
endpoints
of
interest
or
their
proxies
• Interoperability
is
protocol-­‐agnos?c
as
long
as
the
system
supports
the
protocol
endpoints
• Protocol
endpoints
are
mapped
to
resource
endpoints
using
dynamic
bindings
• Protocols
use
data
models,
info
models
are
higher
level

36. Layered
Resources
in
Models
• Object
Model
– Resources
represen?ng
the
generic
object,
i.e.
new
out
of
the
box
• Context
– When
the
object
is
put
to
use,
it’s
loca?on,
it’s
ownership,
what
it’s
measuring
or
controlling
• Bindings
– Other
resources
the
object
is
connected
to,
e.g.
a
light
switch
controlling
a
light
• Resources
may
be
discovered
by
context
and
current
binding
in
addi?on
to
object
a*ributes

37. Protocols

38. Some
Protocols
Protocol
State
Externalized
Event
No>fica>on
Applica>on
Discovery
Syndica>on
Standards
HTTP
REST
WS,
PUT,
Callbacks
Resource
Directory
Server
Group
IETF,
W3C
CoAP
REST
PUT,
GET
+
Observe
Resource
Directory
Server
Group
IETF,
OMA,
IPSO
MQTT
No
Pub/Sub
No
Broker
Oasis

39. CoAP
• CoAP
(RFC7252)
is
a
REST
API
mapped
to
an
efficient
binary
protocol
• Can
use
IPV6,
6LoWPAN,
DTLS
and
UDP
for
underlying
networking
• Can
also
use
IPV4
and
other
bearers,
e.g.
SMS
and
serial
comms
• Observe
op?on
for
asynchronous
streaming
updates
• Real
?me
resource
bindings
to
connect
diverse
protocols
and
event
handlers
• Embedded
core-­‐link-­‐format
metadata
for
discovery
and
linking

40. HTTP/REST
• HTTP
is
used
to
create
a
REST
API
• CoAP
REST
APIs
can
be
mapped
trivially
to
HTTP/REST
• CoAP-­‐HTTP
proxy
allows
standard
web
applica?ons
to
connect
to
CoAP
connected
devices
• HTTP
PUT
and
WebSockets
are
used
to
perform
asynchronous
updates
and
invoke
web
applica?on
handlers

41. MQTT
• MQTT
is
a
binary
message
protocol
that
uses
the
publish/subscribe
pa*ern
• MQTT
server
is
a
message
broker,
accep?ng
subscrip?ons
to
topics
and
republishing
topics
to
subscribers
• Guaranteed
delivery
or
fail
is
ensured
by
op?onal
QOS
seYng
• MQTT
can
syndicate
updates
to
many
subscribers
• Topics
look
like
REST
paths
e.g.
/sensors/
rhvWeather-­‐01/sealevel_pressure

42. Protocol
Binding
• API
Hooks
to
bind
ac?ons
to
resources
• Update
of
resource
triggers
an
ac?on
• External
ac?on
can
update
resource
• One
example
is
binding
REST
API
resources
to
MQTT
topics
• Update
of
REST
resource
causes
MQTT
PUBLISH
ac?on
• MQTT
PUBLISH
can
update
resource
state

43. Design
Pa*ern
Summary
• No
one
Architecture
is
suitable
for
all
IoT
use
cases
• Design
Pa*ern
thinking
brings
modularity
• More
reusability
in
a
modular
system
• Enables
a
range
of
architecture
solu?ons
• Break
down
Silos
of
Thought
• Easier
to
think
about
commonality
and
standards