embedded to connected
TRANSCRIPT
2
Internet Architecture for the Internet of Things
Review of IoT Design Patterns
Design Patterns are recurring solutions to common problems
Design Patterns occur at many levels in system design
Standards – Interoperability and Reusability
3
Design Patterns
Design Patterns are recurring solutions to common problems
Design Patterns occur at many levels in system design
These are some common IoT Design Patterns related to the
tradeoff of embedded vs. connected intelligence in evolving
systems
5
Connected Intelligence Disrupts Embedded Intelligence
Thing
Software
Connected
Intelligence
Embedded Intelligence
Network
Embedded intelligence is tied
to Moore’s law at best and
bothered by power and
productivity issues
Connected intelligence is
limited only by the connection –
the entire internet is available
Connectivity is steadily
improving
6
Connected Intelligence works through Abstraction and
Virtualization
Thing
Software
Network
SoftwareAbstraction
(Network)
Firmware,
Middleware
Device
Application
Software interacts with an abstract
model of the physical thing
Virtualization is the process of
creating a software model of a thing
Products are improved and
upgraded by changing the external
software or by connecting to new
services
Value is shifted to the software
outside the device
7
Common Abstractions enable Many-to-Many interactions
Thing
Software
Software Abstractions
Data Models
Software Software
ThingThing
Data models embody common
abstractions for things
This enables diverse software
to interact with diverse things
Data models provide a
consistent data schema to
enable reuse of software
libraries and protocols
Data models allow the
abstraction of underlying
protocols to enable interaction
over diverse transport layers
9
IoT Design Pattern – Things Interacting over a Network
(using embedded intelligence)
LOCAL NETWORK
11
IoT Design Pattern – Autonomic + Interactive Feedback
Loops
(combining embedded intelligence, local gateways, and
cloud services)
Things
People Software
Inform
Command
InformActuate
Autonomic
Feedback
Loop
Cybernetic
Feedback
Loop
Observe
Control
13
Modular Protocols - Example
Application Software
IPSO Objects
LWM2M
CoAP HTTP
6LowPAN/T
hreadIPV4/IPV6
MCU – 16KiB RAM MPU
802.15.4 WiFi, Ethernet
Hardware
HW Network
Internet Protocol
Wire Protocol + REST
API – Data and Metadata
Data Models
Application
HTTP
REST
Server
Device
Management
14
Client – Server REST Design Pattern
The end device is an origin server
for it’s data state
Application clients initiate
operations to the device
Scales to many clients
The device returns the data and a
hypermedia response describing
the content returned
Devices may also need to be
clients in order to run connected
applications and discover external
resources
15
Layered Services – Local and Remote
Application
Sensor/
Actuator
Device
Service Layer
Device with
Embedded
Application
Application
IoT
Applicatio
n
ClientServer
Peer-
Peer
Constrained
Device, e.g. 16KB
RAM, 128KB
Flash
• Registration and
Discovery
• Device Proxy and Cache
• Local or Cloud/Remote
• Local or Cloud/Remote
• Reuse of web patterns – REST/ JSON
Client
16
Middleware Services
Devic
e
Application
Software
REST
API
Service
Resource
Directory
Message
Broker
Reachable
Services
REGISTER DISCOVER
PUB/SUB PUB/SUB
UPDATE GET/NOTIFY
More Constrained
Less ReachableLess Constrained
Less Reachable
17
Internet Infrastructure Example
Devic
e
N
A
T
Application
Software
N
A
T
GW,
AP
GW,
AP
REST
API
Service
Resource
Directory
Message
Broker
IP Reachable
Web Services
IP Reachable
or
Non Reachable
Endpoints
IP Reachable
or
Non
Reachable
18
IoT Design Patterns
Devices may connect to many different devices and services
Intelligence is layered and connected intelligence can be of higher
value
Data models enable many to many connection of devices to services
Client-server REST enables dynamic sharing of resources
IP network connections are becoming common
Drive connected value in embedded design for IoT devices
Consider a wide range of services and use cases
Implement standard APIs and common data models
Keep interface design simple and follow common patterns like REST
Expose basic device functions
Use IP network connections
20
Standards – Interoperability and Reusability
Interoperability results in a larger ecosystem of devices and
applications
Reusability of technology and designs makes it easier for new
devices and applications to be created
Open standards that provide APIs and data models for IP based IoT
CoAP
OMA LWM2M
IPSO Smart Objects
21
IoT Standards That Build On Each Other
CoAP and related standards from IETF
REST API for constrained networks and devices
HTTP Proxy provides abstraction through standard web APIs
Core-link-format (RFC 6690) provides semantic descriptors in the form of web links
Resource Directory provides an API for scalable discovery and linking using core link-format
mediatype
OMA LWM2M is based on CoAP
Provides a server profile for IoT middleware including Resource Directory and data proxy
Defines a simple reusable object model
Defines management objects and reuses REST API for onboarding and device life cycle
management
IPSO Smart Objects are based on OMA LWM2M
Defines application objects using the LWM2M Object Model
Complex objects can be composed from simple objects
Easy to add new resource and object types as needed
24
CoAP Scope
• Transport– CoAP currently defines:
– UDP binding with DTLS security
– CoAP over SMS or TCP possible
• Base Messaging– Simple message exchange between endpoints
– Confirmable or Non-Confirmable Message
– Answered by Acknowledgement or Reset Message
• REST Semantics– REST Request/Response mapped onto CoAP Messages
– Method, Response Code and Options (URI, content-type etc.) define REST exchanges, very similar to HTTP (HTTP 404 response semantics (not found) mapped to CoAP 4.04 response code)
• Asynchronous Notifications– Observer option for GET allows asynchronous state update
responses from a single request – actually a separate IETF Draft
28
RFC 6690 CoRE Link-Format Example
<4001/0/9002>;rt=“oma.lwm2m”;ct=50;obs=1
Resource Type
Content TypeObservable
29
Local Network Discovery Example Flow
Could return a link-format document:
</3//9>;obs;rt=“urn:X-ipso:batt-level”;ct=”50”,
</3//0>;rt=”urn:X-ipso:dev-mdl”;ct=”50”,
</3//1>;rt=”urn:X-ipso:dev-mfg”;ct=”50”,
</3305/0/5800>;obs;rt=”urn:X-ipso:pwr-w”;ct=”50”,
</3305/0/5805>;obs;rt=”urn:X-ipso:pwr-accum-wh”;ct=”50”,
</3303/0/5700>;obs;rt=”urn:X-ipso:temp-C”;ct=”50”
CoAP
ServerCoAP
Client
DISCOVERY
GET /.well-known/core
2.05 Content
Could use
multicast
30
Resource Directory Discovery
See draft-ietf-core-
resource-directory
• A central directory approach is also useful
– Supports sleeping nodes
– No multicast traffic, longer battery life
– Remote lookup, hierarchical and federated distribution
• CoRE Link Format is used in Resource
Directories
– Nodes register their resource links to an RD
– Nodes refresh the RD periodically
– Nodes may unregister (remove) their RD entry
Application
GET /rd-lookup/ep</nodea/sensor/temp>
</nodeb/actuator/led>
31
Resource Directory Example Flow
See draft-ietf-core-resource-directory
core.rd
serviceREGISTRATION
POST /rd?ep=“235598376”<=19999
</3303/0/5700>;rt=“urn:X-ipso:temp-C”
Endpoint
2.01 Created Location:/rd/235598376
DISCOVERY
GET /rd-lookup?ep&rt=“urn:X-ipso:temp-C”
2.05 Content
</235598376/3303/0/5700>;rt=“urn:X-ipso:temp-C”
Endpoint
33
OMA LWM2M Reference Architecture
• Bootstrap Interface
– Configure Servers & Keying
– Pre-Configured, Smart Card, or Server
Initiated Bootstrap
– CoAP REST API
• Registration Interface
– RFC6690 and Resource Directory
• Management Interface Using Objects
– Management Objects and Resources
– Standard Object Template
– M2M Device is CoAP REST API Server
• Reporting Interface
– Object Instances and Resources Report
– Asynchronous notification using CoAP
Observe
36
IPSO Smart Objects Use the LWM2M Object Model
REST API with a URI template
Objects
Object Instances
Resources
Reusable resource and object
IDs
Common definitions for concepts
Map to semantic terms e.g.
Temperature, Current Value
IDs are registered with the OMNA
Data Types and Access Types
String, Decimal, Boolean
Read, Write, Create, Delete
Execute, Discover
3303/0/5700
Object ID, defines object type
Object Instance, one or more
Resource ID, defines resource
type3303 is Temperature
5700 is Current Value
3303/0/5700 refers to the current
value of temperature sensor
instance 0
38
IPSO Smart Objects
More Smart Object Types are being defined, e.g. sensors for Speed,
Pressure, Weight
Smart Object types are being defined for controls and action
bindings
Defining Composite objects made from basic objects e.g. Motor,
Coffee Maker
Semantic annotation of Smart Objects using Core Link-Format
Freedom to define new objects and register them with OMNA
Smart Objects work with any protocol that provides the basic URI
template, data types, and operations
39
Modular Protocol Stack
Application Software
IPSO Objects
LWM2M
CoAP HTTP
6LowPAN/T
hreadIPV4/IPV6
MCU – 16KiB RAM MPU
802.15.4 WiFi, Ethernet
Hardware
HW Network
Internet Protocol
Wire Protocol + REST
API – Data and Metadata
Data Models
Application
HTTP
REST
Server
Device
Management
40
Summary
Value is shifting to connected software applications
Common data models enable reusable software in devices and
applications
IP networking and related standards provide points of interoperability
with modular protocol stacks
Embedded software can expose standard APIs and data models to
enable IoT value through connected software
41
References
IPSO Smart Object Guideline
http://www.ipso-alliance.org/smart-object-guidelines
OMA LWM2M Specification
http://openmobilealliance.hs-sites.com/lightweight-m2m-specification-from-
oma
IETF CoAP and Related Specifications
CoAP (RFC 7252):
http://tools.ietf.org/html/rfc7252
CoRE Link-Format (RFC 6690):
http://tools.ietf.org/html/rfc6690
CoRE Resource Directory: http://tools.ietf.org/html/draft-ietf-core-resource-
directory-01
CoAP Community Site
http://coap.technology/