Download as PDF, PPTX
Uploaded byMichael Koster
Open Horizontal Platform - Web Scale Interoperability for IoT - CCNA 2013
The document discusses the need for an open horizontal platform to enable interoperability across the diverse protocols, devices, data sources and software in the Internet of Things (IoT). It proposes addressing this through common data models and abstractions that allow any application to connect to any device via any M2M protocol. This is achieved by representing devices, data and metadata as web objects that encapsulate local software components and expose a self-describing data model and event model through RESTful APIs.
Open Horizontal Platform - Web Scale Interoperability for IoT - CCNA 2013
- 1. Open Horizontal Pla/orm Web Scale Interoperability for the Internet of Things Michael J Koster Open Source Internet Of Things
- 2. API M2M – Things Connected to Apps CoAP MQ SOA HTTP App API App API App SDK App • Each app runs on it’s own service – SPOF • Each app wriLen to a custom API • Apps are not network-‐ effect enabled • Diverse M2M is somePmes required but can inhibit interoperability • SoRware, User data, and Things are trapped in Silos Devices, Data Sources M2M Protocols Pla3orms Applica7on So9ware Separate end-‐to-‐end ver7cal applica7on stacks
- 3. The Interoperability Problem • Each deployment is it’s own end-‐to-‐end system with ad-‐hoc and incompaPble architecture • Difficult to connect new types of things and deploy new pla/orms • Very difficult to share resources or connect across pla/orms • Silos are traps • Devices are trapped • Code is trapped • User experience is trapped • Single Point Of Failure for all these
- 4. SoluPon: Open Pla/orm for IoT • Interoperability = Interchangeability – Any ApplicaPon SoRware – Any Connected Object – Any M2M Protocol • Break The Silos – Allow second sources for devices, pla/orms, soRware, and user experiences • Horizontal IntegraPon – “Network Effect” applicaPons spanning many diverse connected objects and data sources
- 5. IoT 2.0 – Interoperability M2M CoAP M2M MQTT M2M SOA M2M HTTP Common Abstrac7ons Web Objects, Data Models REST API + Events Discovery ApplicaPons • Web Objects • REST + Event Model • M2M Abstrac9ons • Model Driven Connected Things, Sensors, Actuators, Data Sources Models • Any app to any thing via any M2M, use-‐ case decides M2M • Easy to deploy new things and applicaPons using data models • Write once, run anywhere soRware • Network effect enabled
- 6. Data Models Drive Interoperability • Data models enable machine understanding independent of M2M protocols – SoCware uses common abstrac9ons • Enable choice of suitable M2M protocols • Enable reusable soRware components • Ability to reuse and repurpose resources • Ease of integraPng data from diverse sources • Diverse UI pla/orms • Object Models and SemanPc Models
- 7. Object Model – API Interoperability Web Object EncapsulaPon Smart Object Web protocol interfaces, also M2M e.g. MQTT, XMPP, … Event Model Links data with acPons Pub-‐Sub and event handlers Encapsulates local soRware components and handlers Self-‐describing data model For Resource Discovery and Linkage, RDF and core-‐ link-‐format Sensor or other data JSON, XML, data feeds
- 8. Object Model Defines the Structure of the Data and Metadata Smart Object DescripPon ObservableProperty ObservableProperty… Agent Publisher Subscriber Handler PropertyOfInterest (Object Data) Descrip7on (Data Model Metadata) Observers (Event Model Metadata) Handler Instance Daemon
- 9. Data Model – SemanPc Model • SemanPc model describes the meaning of data and informs applicaPon soRware • Enables discovery and linkage by/to applicaPon soRware by selected aLributes of the data and object • Built from common concepts and relaPons • SemanPc triples format: Subject-‐Predicate-‐Object or Subject-‐RelaPon-‐Value • Many data representaPon formats exist for Linked Data compaPbility, S-‐P-‐O graph relaPon is a subset representable in most formats • Represent annotaPons like units=celsius, highlimit=100, also measurement context like Pme and locaPon • Subset of web linking
- 10. DM SemanPc and Protocol Interoperability • Separate Control Plane and Data Plane – Common Data Models Enable Diverse M2M Protocols Between Smart Objects • Any Original Catalog or Seman7c Format – Smart Object stores RDFModel Format, translates others using a SemanPc Proxy • Applica7ons see one API – With suitable metadata representaPon SSN TSB IPSO Seman7c Proxy DM Any M2M Protocol Anywhere Common Abstrac7ons Seman7c Models: Catalogs, Repositories, Diverse Metadata Smart Object API Applica7on Smart Object API Applica7on
- 11. Model Driven Architecture Event Driven CommunicaPon SO SO SO Gateways Server Cloud Endpoints • Sensors • Devices ApplicaPon Components And Resources Object Metadata Databases Registry -‐ Instances Repository -‐ Models Models • Discovery • Persistence • ReplicaPon • Resource Access • Data Models • Sensor Models • Machine Models • Templates HTTP MQTT CoAP XMPP HTTP CoAP MQTT
- 12. Real Time Event Model • IoT Pla/orms need to support real Pme event driven processing • Interoperability through standard abstracPons for events and acPons • Connects REST APIs to Publish-‐Subscribe Protocols and ApplicaPon Event Handlers • ObservaPon PaLerns – CoAP GET+Observe – REST API broker, REST API hooks: Event-‐on-‐update
- 13. Resource Observer • REST hook paLern, create hook as a resource • Resource properPes specify event acPons e.g. MQTT publish, broker and topic, etc. • Publisher – publishes REST updates to broker • Subscriber – updates REST endpoint from broker • Handler – invokes soRware event handler
- 14. Event Model -‐ MQTT Observer MQTT Broker REST Endpoint ObservableProperty mqLObserver PUT GET Publish from data producer Publish From REST API Publish to Other Subscribers SUB Publish to REST API Connects REST Resource to MQTT Topic Publish and Subscribe
- 15. MQTT Observer MQTT Broker REST Endpoint ObservableProperty mqLObserver PUT GET Publish from data producer Publish From REST API Publish to Other Subscribers SUB Publish to REST API Publisher Publishes REST Resource updates to the broker
- 16. MQTT Observer MQTT Broker REST Endpoint ObservableProperty mqLObserver PUT GET Publish from data producer Publish From REST API Publish to Other Subscribers SUB Publish to REST API Subscriber Makes last published data available at the REST endpoint
- 17. MQTT Observer MQTT Broker REST Endpoint ObservableProperty mqLObserver PUT GET Publish from data producer Publish From REST API Publish to Other Subscribers SUB Publish to REST API Pub+Sub Repeats data updates in both direcPons
- 18. MQTT Bridge to mulPple REST endpoints MQTT Broker REST Endpoint ObservableProperty mqLObserver PUT GET Publish from data producer Publish to Other Subscribers REST Endpoint ObservableProperty mqLObserver PUT GET
- 19. Event Model: MQTT Observer • Publish, Subscribe, or Pub+Sub using the mqLObserver resource class • Prototype opens a connecPon to a specified broker for each endpoint Observers.create({'resourceName': 'mqttTestObserver',! ! ! ! ! ! 'resourceClass': 'mqttObserver',! 'connection': 'smartobjectservice.com',! 'pubTopic': ’sealevel_pressure',! 'subTopic': None,! 'QoS': 0,! 'keepAlive': 60 })!
- 20. Resource Access Control • Resources have well defined ownership and access control policy, based on graph connecPons to owner enPPes like people and insPtuPons • Granular, nuanced access control can specify policies and constraints using graph relaPons • Owners and accessors can be idenPfied based on social graph connecPons and connecPons to the physical graph
- 21. Resource Access Control -‐ Social Graph Connected to Physical Graph
- 22. Open Source SoRware • Open Source soRware enables open pla/orms • Community development of relevant soluPons • Creates open parPcipaPon for developers and users, non-‐discriminitory • Can be independently examined and evaluated • Interoperates and integrates more easily with other soRware • Permissive licenses allow embedding code in other soRware
- 23. Open Horizontal + VerPcal Pla/orm • Components are interchangeable in the verPcal pla/orm stack as well as interoperable • Open Stack for IoT • Model-‐View-‐Controller abstracPon • Autonomic Control + Human InteracPon • Devices, protocols, applicaPon pla/orms, UI can be interchanged and customized per use case • Example using Open Source components
- 24. Model-‐View-‐Controller Macro PaLern IoT Feedback Control Loops • Autonomic and cybernePc feedback loops • People’s intenPons take part in the cybernePc feedback loop Model View Controller Informs Updates Informs Actuates Autonomic Feedback Loop Cyberne7c Feedback Loop
- 25. Open Source IoT Components • Open Source Components Available – IoT Toolkit – REST API + Data Models + Events – Node-‐RED – Graphical ApplicaPon Tool – Dojo UI Toolkit – UI tools – MosquiLo MQTT Broker and Client – RDFlib with SPARQL – Graph storage – Neo4J Graph Database – CoAP Clients and Servers • Sufficient to build a complete Pla/orm Stack • Components allow ApplicaPon soRware to run in Local Server, Gateway, and Cloud Service
- 26. Model-‐View-‐Controller Macro PaLern Mapping to Open Source SoRware Components • Model – Object Models, Data Models – Storage, Discovery, Formats, Protocols, Binding to Objects • Controller – Complex Flow Graphs of Event-‐driven modular SW – Python and node.js • View – UI Toolkit For ApplicaPons – Binding of UI Components to Smart Object ProperPes IoT Toolkit Node-‐RED Dojo Dashboard Node Builder IPSO TSB SSN Catalogs and Repositories Sensors, Things, MQTT, CoAP, HTTP REST API + Events HTML5, Mobile Web • Resource Discovery and Linkage • Builds Smart Object Nodes • Manages, stores Flow Graph
- 27. ApplicaPon Development Workflow IPSO TSB SSN Data Models and Catalogs Node Builder Node-‐RED Dashboard Model Controller View • Discovers Resources • Makes Object Instances • Builds Applica9on Flow Graphs • UI Construc9on
- 28. Run Time Deployment Example TSB SSN IPSO Data Models and Catalogs HTTP/LD Node-‐RED Node-‐RED CoAP/RD HTTP HTTP + MQTT CoAP HTTP CoAP HTTP Local Control Gateway Personal Service IoT Provider UI Devices Gateway as a Service IoT Toolkit IoT Toolkit IoT Toolkit CoAP CoAP
- 29. Weather sensor example Sensor (Arduino) Gateway (Rpi) Sensor Hardware • Wind Speed • Wind DirecPon • Rainfall • Temperature • Humidity • Barometer Reads sensor elements and creates sensor output values to update Smart Object in the Gateway using a simple hLp client Gateway runs Smart Object API and exposes HTTP interface, adds descripPonand other resources, Observers send updates to cloud server Local Ethernet Cloud Server acts as Gateway-‐as-‐a-‐Service for Xively Receives updates from the gateway, Observers Send periodic updates to Xively feed Cloud Server Internet Client (Xively) Internet Xively acts as client applicaPon and receives updates from the cloud service acPng as GaaS
- 30. IoT Toolkit Interoperability Demo CoAP MQTT MQTT HTTP smartobjectservice.com ec2-‐54-‐200-‐106-‐25.us-‐ west-‐2.compute.amazonaws.com Node-‐RED Node-‐RED
- 31. Thank You! This PresentaPon: hLp://www.slideshare.net/CCNA-‐Open-‐Pla/orm-‐IoT hLp://www.linkedin.com/pub/michael-‐koster/ 2/36b/317/ hLp://iot-‐datamodels.blogspot.com/