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  

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  

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  

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  

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