Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Design patternsforiot


Published on

Design patternsforiot

  1. 1. Design Pa*erns for an Internet Of Things Architecture, Infrastructure, Models, and Protocols Michael J Koster ARM
  2. 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. 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. 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. 5. IoT Local System View Based On Things Interac?ng With Other Things LOCAL NETWORK
  6. 6. IoT System View For Big Data™ ANALYZE FILTER COLLECT
  7. 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. 8. Abstract Design Pa*erns
  9. 9. Connected Intelligence Disrupts Embedded Intelligence So^ware Network Thing Connected Intelligence Embedded Intelligence
  10. 10. Virtualiza?on of Things So^ware Applica?on Network So^ware Abstrac?on (Network) Thing Firmware, Middleware Device
  11. 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. 12. Data Model So^ware So^ware So^ware Data Model Thing
  13. 13. Data Model So^ware So^ware So^ware Middleware Thing
  14. 14. Design Pa*erns for Network Topology – Discovery and Interac?on
  15. 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. 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. 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. 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. 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. 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. 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. 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. 23. Internet and Web Design Pa*erns
  24. 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. 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. 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. 27. Object Encapsula?on
  28. 28. Object Encapsula?on
  29. 29. Data Models
  30. 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. 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. 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. 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. 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. 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. 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. 37. Protocols
  38. 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. 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. 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. 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. 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. 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