CCNA-Open-Platform-IoT
3 likes1,737 views
The document discusses the need for an open horizontal platform to enable interoperability in the Internet of Things (IoT). It describes some of the current challenges with separate vertical application stacks that use different protocols and APIs, trapping devices, code, user experiences, and data in isolated "silos". The proposed solution is an open platform that enables any application to connect to any connected thing via any M2M protocol, using common data models, semantic models, and a model-driven architecture to achieve interoperability. Key aspects of this open platform approach include breaking down silos, enabling "network effect" applications, and achieving "write once, run anywhere" software interoperability.
CCNA-Open-Platform-IoT
- 1. Open Horizontal Pla/orm Web Scale Interoperability for the Internet of Things Michael J Koster Open Source Internet Of Things
- 2. M2M – Things Connected to Apps Separate end-‐to-‐end ver7cal applica7on stacks Applica7on So9ware Pla3orms M2M Protocols Devices, Data Sources App API CoAP App API MQ App API HTTP App • Each app runs on it’s own service – SPOF SDK • Each app wriLen to a custom API SOA • Apps are not network-‐ effect enabled • Diverse M2M is somePmes required but can inhibit interoperability • SoRware, User data, and Things are trapped in Silos
- 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 • 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 ApplicaPons Discovery Common Abstrac7ons Web Objects, Data Models REST API + Events M2M CoAP • Web Objects • REST + Event Model • M2M Abstrac9ons • Model Driven M2M M2M HTTP M2M MQTT SOA Models Connected Things, Sensors, Actuators, Data Sources
- 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 Web protocol interfaces, also M2M e.g. MQTT, XMPP, … Encapsulates local soRware components and handlers Event Model Links data with acPons Pub-‐Sub and event handlers Smart Object 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 PropertyOfInterest (Object Data) ObservableProperty… Descrip7on (Data Model Metadata) Agent Observers (Event Model Metadata) Handler Instance Publisher Daemon Subscriber Handler
- 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. SemanPc and Protocol Interoperability • Separate Control Plane and Data Plane – Common Data Models Enable Diverse M2M Protocols Between Smart Objects Applica7on Smart Object API DM Any M2M Protocol Anywhere Applica7on Smart Object API Common DM Abstrac7ons • Any Original Catalog or Seman7c Format – Smart Object stores RDFModel Format, translates others using a SemanPc Proxy Seman7c Proxy • Applica7ons see one API – With suitable metadata representaPon TSB IPSO SSN Seman7c Models: Catalogs, Repositories, Diverse Metadata
- 11. Model Driven Architecture Event Driven CommunicaPon Gateways Endpoints • Sensors • Devices CoAP Server Cloud SO MQTT SO MQTT HTTP SO HTTP XMPP ApplicaPon Components And Resources CoAP Registry -‐ Instances • Discovery • Persistence • ReplicaPon • Resource Access Repository -‐ Models Models • Data Models • Sensor Models • Machine Models • Templates Object Metadata Databases
- 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 Connects REST Resource to MQTT Topic Publish and Subscribe PUT GET REST Endpoint ObservableProperty mqLObserver Publish From REST API Publish from data producer SUB MQTT Broker Publish to REST API Publish to Other Subscribers
- 15. MQTT Observer Publisher Publishes REST Resource updates to the broker PUT GET REST Endpoint ObservableProperty mqLObserver Publish From REST API Publish from data producer SUB MQTT Broker Publish to REST API Publish to Other Subscribers
- 16. MQTT Observer Subscriber Makes last published data available at the REST endpoint PUT GET REST Endpoint ObservableProperty mqLObserver Publish From REST API Publish from data producer SUB MQTT Broker Publish to REST API Publish to Other Subscribers
- 17. MQTT Observer Pub+Sub Repeats data updates in both direcPons PUT GET REST Endpoint ObservableProperty mqLObserver Publish From REST API Publish from data producer SUB MQTT Broker Publish to REST API Publish to Other Subscribers
- 18. MQTT Bridge to mulPple REST endpoints PUT GET REST Endpoint ObservableProperty mqLObserver MQTT Broker mqLObserver REST Endpoint ObservableProperty Publish from data producer PUT GET Publish to Other Subscribers
- 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 Cyberne7c Feedback Loop Model Informs Informs View Updates Autonomic Feedback Loop Actuates Controller
- 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 Catalogs and Repositories IPSO TSB SSN Sensors, Things, MQTT, CoAP, HTTP REST API + Events IoT Toolkit • Model – Object Models, Data Models – Storage, Discovery, Formats, Protocols, Binding to Objects • Controller Node Builder • Resource Discovery and Linkage • Builds Smart Object Nodes • Manages, stores Flow Graph Node-‐RED Dojo Dashboard HTML5, Mobile Web – 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
- 27. ApplicaPon Development Workflow Node Builder Node-‐RED • Discovers Resources • Builds Applica9on • Makes Object Instances Flow Graphs Dashboard • UI Construc9on Data Models and Catalogs IPSO TSB SSN Model Controller View
- 28. Run Time Deployment Example Personal Service Data Models and Catalogs SSN HTTP/LD IPSO TSB CoAP/RD Local Control Gateway HTTP + MQTT Node-‐RED IoT Toolkit CoAP Node-‐RED IoT Toolkit CoAP CoAP IoT Provider HTTP HTTP HTTP UI Devices IoT Toolkit Gateway as a Service CoAP
- 29. Weather sensor example Client (Xively) Xively acts as client applicaPon and receives updates from the cloud service acPng as GaaS Internet Sensor Hardware • Wind Speed • Wind DirecPon • Rainfall • Temperature • Humidity • Barometer Cloud Server Cloud Server acts as Gateway-‐as-‐a-‐Service for Xively Receives updates from the gateway, Observers Send periodic updates to Xively feed Internet Gateway (Rpi) Gateway runs Smart Object API and exposes HTTP interface, adds descripPonand other resources, Observers send updates to cloud server Local Ethernet Sensor (Arduino) Reads sensor elements and creates sensor output values to update Smart Object in the Gateway using a simple hLp client
- 30. IoT Toolkit Interoperability Demo ec2-‐54-‐200-‐106-‐25.us-‐ west-‐2.compute.amazonaws.com HTTP MQTT Node-‐RED smartobjectservice.com ED Node-‐R CoAP MQTT
- 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/