design patternsforiot

Design Pa*erns for an

Internet Of Things Architecture, Infrastructure, Models, and

Protocols

Michael J Koster ARM

Design Pa*ern

•  A Structured Collec?on of Design Pa*erns that solves a Par?cular Set of Problems

10/19/14 2

•  A Reusable Solu?on to a Commonly Occurring Problem

Architecture

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

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

IoT Local System View Based On Things Interac?ng With Other Things

LOCAL NETWORK

IoT System View For Big Data™

COLLECT

FILTER

ANALYZE

System View For Diverse Use Cases

Things

People So.ware

Inform

Command

Inform Actuate

Autonomic Feedback Loop

Cyberne>c Feedback Loop

Observe

Control

Abstract Design Pa*erns

Connected Intelligence Disrupts Embedded Intelligence

Thing

So^ware

Connected Intelligence

Embedded Intelligence

Network

Virtualiza?on of Things

Thing

So^ware

Network

So^ware Abstrac?on

(Network)

Firmware, Middleware

Device

Applica?on

Virtualiza?on Enables Many-‐to-‐Many So^ware Applica?ons to Things

Thing

So^ware

So^ware Abstrac?ons Middleware

So^ware So^ware

Thing Thing

Data Model

Thing

So^ware

Data Model

So^ware So^ware

Data Model

Thing

So^ware

Middleware

So^ware So^ware

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

Interac?on Pa*erns

Applica?on

Sensor/Actuator Device

Service e.g. LWM2M

Device with Embedded Applica?on

Applica?on Web

Applica?on

Client Server

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

Device Server Middleware

BLE Device

Web App

Web Browser,

Smartphone App

APP

Proxy Device

Device Server

h*p

h*p/REST

CoAP

BLE

So^ Endpoints

IP Device

IP Device

IP Device Endpoints

Middleware Services

Device Applica?on So^ware

REST API Service

Resource Directory

Message Broker

IP Reachable Web Services

REGISTER DISCOVER

PUB/SUB PUB/SUB

UPDATE GET/NOTIFY

More Constrained Less Reachable

Less Constrained Less Reachable

Infrastructure

Device NAT

Applica?on So^ware

NAT

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

Example Configura?on using local REST Gateways Pub/Sub Updates

Device NAT

Applica?on So^ware

NAT

REST GW

REST GW

Resource Directory

Message Broker

PUB/SUB PUB/SUB

REGISTER DISCOVER

REST REST

Internet and Web Design Pa*erns

Layered Architecture, Narrow Waist

Applica?on So^ware

IPSO Objects

LWM2M

CoAP HTTP

6LowPAN IPV4/IPV6

MCU – 16KiB RAM MPU

802.15.4 WiFi, Ethernet

Hardware

HW Network

Rou?ng

REST Protocol

API for data and metadata

Data Models

Applica?on

HTTP REST Server

24 10/19/14

Device Management

REST API •  Client-‐Server •  Resource Oriented •  CRUD Seman?cs •  Hypermedia Driven

Object Encapsula?on •  Path Hierarchy -‐ Inclusion •  Linking – Transclusion •  Transclusion links shared resources

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

Object Encapsula?on

Data Models

Data Models

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

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

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

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

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’!

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

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

Protocols

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

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

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

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

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

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

design patternsforiot

Documents