This document discusses design patterns for Internet of Things (IoT) architectures. It describes patterns for connecting smart devices and enabling them to interact and share data over networks. Some key patterns discussed include using REST APIs to expose device data and functions, object models and data models to describe devices and standardize data formats, and protocols like CoAP, HTTP, and MQTT to facilitate communication between devices and applications. The document provides examples of how these patterns can be applied to build IoT systems and interfaces to connect diverse devices.

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