IoT Toolkit and the Smart Object API - Architecture for Interoperability
•
0 j'aime•454 vues
Recommandé
Contenu connexe
Tendances
Tendances (17)
Similaire à IoT Toolkit and the Smart Object API - Architecture for Interoperability
Similaire à IoT Toolkit and the Smart Object API - Architecture for Interoperability (20)
Plus de Michael Koster
Plus de Michael Koster (11)
Dernier
Dernier (9)
IoT Toolkit and the Smart Object API - Architecture for Interoperability
- 1. IoT Toolkit and the Smart Object API Architecture For Interoperability Michael J Koster michaeljohnkoster@gmail.com
- 2. IoT Toolkit Goals • Interoperability – Any ApplicaDon, any connected object, using any M2M protocol • Simple API arDculated through data models and high level informaDon models • PlaIorm-‐as-‐a-‐Service and gateway enabled • Open Source, IPR-‐free • Distributed, event-‐driven applicaDon soNware runs anywhere in the network • Web standard protocols and best pracDces
- 3. API IoT 1.0 – Things Connected to Apps M2M CoAP M2M MQ M2M XMPP M2M HTTP App API App API App API App • App runs on single service – Single Points Of Failure • Each app wriWen to a custom API • Diverse M2M is someDmes required but can inhibit interoperability • SoNware, User data, and Things are trapped in Silos • Difficult to connect new types of things and deploy new plaIorms • Very difficult to share resources or connect across plaIorms • Apps are not network-‐ effect enabled Connected Things, Sensors, Actuators, Data Sources
- 4. IoT 2.0 – Interoperability M2M CoAP M2M MQTT M2M XMPP M2M HTTP Smart Object API IoT Toolkit Discovery ApplicaDons Data Models • Object Model • REST + Event Model • M2M Abstrac9ons IoT Toolkit Connected Things, Sensors, Actuators, Data Sources Model Database • Easy to deploy new things and applicaDons using data models • Write once, run anywhere soNware • Any app to any thing via any M2M, use-‐ case appropriate M2M • Network effect enabled Machine Models
- 5. Graph-‐Structured, Event-‐Driven, Real Time Distributed ApplicaDons SO SO SO Gateways Server Cloud Endpoints • Sensors • Devices ApplicaDon Components And Resources Databases Registry -‐ Instances Repository -‐ Models Models • Discovery • Persistence • ReplicaDon • Resource Access • Data Models • Sensor Models • Machine Models • Templates HTTP MQTT CoAP XMPP HTTP CoAP MQTT Smart Objects
- 6. What Is The Smart Object API? • Virtual RepresentaDon of a physical Smart Object • Object Model – Web Object EncapsulaDon of properDes • REST API using JSON, XML, RDF, core-‐link-‐format representaDons • Data Models – Linked Data descripDons, Resource Discovery and Linkage • Event Model – Asynchronous M2M and applicaDon soNware event handlers
- 7. Object Model Web Object EncapsulaDon Smart Object Web protocol interfaces, also M2M e.g. MQTT, XMPP, … Event Model Links data with acDons Pub-‐Sub and event handlers Encapsulates local soNware 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. API – DescripDon (Data Model) • Contains graphs describing the resource data model • RDF triples in many popular representaDons – create (POST) loads a graph into the descripDon delete (DELETE) removes a graph or subgraph from the descripDon – set (PUT) updates a graph or subgraph – get (GET) returns a graph or subgraph • SemanDc Proxy for core-‐link-‐format compaDbility
- 9. API – Observable Property • Represents sensor data or a data feed • Can be JSON, xml, text, or other content type – create (POST): make new observable property – delete (DELETE) remove observable property – set (PUT) update ObservaDon Value or data feed – get (GET) returns the current ObservaDon Value • Formats for embedded Dme + locaDon data
- 10. API – Agent • Container for Event Handlers, soNware components invoked within the local context of a Smart Object • Observer class invokes Event Handler code in the Agent • Reference ImplementaDon – create (POST) make a new code object instance • handler or daemon – delete (DELETE) remove code instance – set (PUT) updates sefng of a code instance – get (GET) returns sefng of a code instance
- 11. API – Observers • Contains graphs which define the nodes and endpoints of event driven processing • Publish, Subscribe, and Event Handler paWerns • Reference ImplementaDon – create (POST) make a new Observer – set (PUT) update an Observer’s sefngs – get (GET) return an Observer’s sefngs – delete (DELETE) remove an Observer
- 12. Smart Object Structure – Object Model Smart Object DescripDon ObservableProperty ObservableProperty… Agent Publisher Subscriber Handler PropertyOfInterest DescripDon Observers Handler Instance Daemon Default Property
- 13. REST API • Python API – Local SoNware, Agents and Handlers – Resources (objects) are hierarchical properDes of other resources – self.indoorTempValue = sensors.weather.indoor_temp.get()! • Web API – HWp and CoAP REST Client access, MQTT topics – Resources are organized in hierarchical path – GET http:my_server:8000/sensors/weather/indoor_temp! – GET coap:my_server:5683/sensors/weather/indoor_temp! – MQTT subscribe my_server:1883 /sensors/weather/indoor_temp! • Default Property – Returns a resource associated with a higher level resource – GET of Smart Object returns it’s DescripDon; GET of Observable Property returns it’s ObservaDon Value
- 14. Protocol Bridge Examples • MQTT Endpoints and Bridge using Observer • CoAP Server Endpoint and link-‐data Proxy
- 15. MQTT Observer MQTT Broker REST Endpoint ObservableProperty mqWObserver 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
- 16. MQTT Observer MQTT Broker REST Endpoint ObservableProperty mqWObserver 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
- 17. MQTT Observer MQTT Broker REST Endpoint ObservableProperty mqWObserver 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
- 18. MQTT Observer MQTT Broker REST Endpoint ObservableProperty mqWObserver 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 direcDons
- 19. MQTT Bridge to mulDple REST endpoints MQTT Broker REST Endpoint ObservableProperty mqWObserver PUT GET Publish from data producer Publish to Other Subscribers REST Endpoint ObservableProperty mqWObserver PUT GET
- 20. CoAP Server Endpoint Smart Object JSON JSON JSON RDF SemanDc Proxy RDF link-‐format • CompaDble Object Models • Observer paWern • Standard JSON Resources • SemanDc Proxy exposes stored RDF via core-‐link-‐format GET/POST operaDons
- 21. IoT Toolkit Protocol Interoperability CoAP MQTT MQTT HTTP smartobjectservice.com ec2-‐54-‐200-‐106-‐25.us-‐ west-‐2.compute.amazonaws.com
- 22. IoT Toolkit • IoT Toolkit is a reference implementaDon of the Smart Object API and related tools • REST API with real-‐Dme event model for the Internet of Things • Lightweight server that can run on small computers e.g. Raspberry Pi, ARM/Linux PC, AWS t1.micro • M2M using HTTP, MQTT, and CoAP, others
- 23. IoT Toolkit Project Status • Smart Object API is complete and stable • IoT Toolkit Demo • M2M interoperability: MQTT, CoAP, HTTP interfaces • Development Roadmap Examples – Object model, Data model namespaces and ontologies – Programming model UI: Node Red integraDon – Graph-‐based resource access control – Harden code, excepDon handling, API Tests – Scalable server, mulD-‐tenancy – XMPP endpoint and proxy for XEP-‐0060, XEP-‐0323, XEP-‐0325 – Web UI for debug and demo, applicaDons • Navigator, Dashboard, AnalyDcs, Graphs and Charts
- 24. Code Examples • Arduino Sketch that updates SmartObject in the gateway • Server startup code • Example Resources • Event Model Examples – Observers • Based on the Weather Sensor Demo
- 25. Weather sensor example Sensor (Arduino) Gateway (Rpi) Sensor Hardware • Wind Speed • Wind DirecDon • Rainfall • Temperature • Humidity • Barometer Reads sensor elements and creates sensor output values to update Smart Object in the Gateway using a simple hWp client Gateway runs Smart Object API and exposes HTTP interface, adds descripDonand 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 applicaDon and receives updates from the cloud service acDng as GaaS
- 26. Arduino Sketch PString jsonObject(objectBuffer, sizeof(objectBuffer));! ! if(nextPushPoint==0) {! nextPushPoint=1;! /* use Pstring.print to format JSON string from integer */! jsonObject.println(daily_rain,1); ! /* PUT update to Smart Object server property using JSON */! client.print("PUT ");! client.print(serverPath);! client.print(”daily_rain");! client.println(" HTTP/1.1");! client.println("Content-Type: application/json");! client.print("Content-Length: ");! client.println(jsonObject.length()-2);! client.println("Connection: close");! client.println();! client.println(jsonObject);! }!
- 27. Demo Code for Weather Sensor – Smart Object and Service CreaDon baseObject = SmartObject() # create a Smart Object to serve as the base container for other Smart Objects and resources server = SmartObjectService(baseObject) # make an instance of the service, baseObject is the object root server.start(8000) # forks a server thread to listen on port 8000 print 'hCpd started at', baseObject.Proper9es.get('hCpService’) # top level object container for sensors, class is SmartObject sensors = baseObject.create({'resourceName': 'sensors', 'resourceClass': 'SmartObject'}) #weather sensor Smart Object under sensors for the weather sensor weather = sensors.create({'resourceName': 'rhvWeather-‐01', 'resourceClass': 'SmartObject’}!
- 28. Data Model – DescripDon for object discovery and linkage # make a reference to the weather sensor object DescripDon and build an example graph (could use the built-‐in reference as well) weather.descripDon = weather.Resources.get('Descrip9on') weather.descripDon.set((URIRef('sensors/rhvWeather-‐01/outdoor_temperature'), RDFS.Resource, Literal('sensor'))) weather.descripDon.set((URIRef('sensors/rhvWeather-‐01/outdoor_temperature'), RDF.type, Literal('temperature'))) weather.descripDon.set((URIRef('sensors/rhvWeather-‐01/outdoor_humidity'), RDFS.Resource, Literal('sensor'))) weather.descripDon.set((URIRef('sensors/rhvWeather-‐01/outdoor_humidity'), RDF.type, Literal('humidity'))) weather.descripDon.set((URIRef('sensors/rhvWeather-‐01/sealevel_pressure'), RDFS.Resource, Literal('sensor'))) weather.descripDon.set((URIRef('sensors/rhvWeather-‐01/sealevel_pressure'), RDF.type, Literal('pressure')))!
- 29. EncapsulaDon: Observable Property, Observer, and Subscriber sealevel_pressure = weather.create({'resourceName': 'sealevel_pressure', 'resourceClass': 'ObservableProperty'}) sealevel_pressure.Observers.create({'resourceName':'demoServiceObserver', 'resourceClass': 'hCpPublisher', 'targetURI': 'hCp://smartobjectservice.com: 8000/sensors/rhvWeather-‐01/sealevel_pressure'}) # make a named subscriber resource outdoor_humidity.Observers.create({'resourceName': 'humiditySubscriber', 'resourceClass': 'hCpSubscriber', 'observerURI': 'hCp://localhost:8000/sensors/rhvWeather-‐01/ indoor_humidity', 'observerName': 'humiditySubObserver' })
- 30. Event Model: MQTT Observer • Publish, Subscribe, or Pub+Sub using the mqWObserver resource class • Prototype opens a connecDon 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 })!
- 31. Event Model – Xively Publisher -‐ Observer sealevel_pressure.Observers.create({'resourceName': 'xivelyObserver', 'resourceClass': 'xivelyPublisher', 'apiBase': 'hCps://api.xively.com/v2/feeds', 'feedID': '2141862995', 'streamID': 'sealevel_pressure’, 'apiKey’:'QYourApiKeyGoesHEresjhgrjgo56', 'updateInterval': pushInterval })
- 32. Event Model – Handler and Callback NoDfier #addHandler class adds 2 properDes values together and stores in a third weather.Agent.create({'resourceName': 'addHandler', 'resourceClass': 'addHandler', 'addendLink1':'sensors/rhvWeather-‐01/indoor_temperature', 'addendLink2': 'sensors/rhvWeather-‐01/indoor_temperature', 'sumOutLink': 'sensors/rhvWeather-‐01/outdoor_humidity'}) # now create a callback observer endpoint indoor_temperature.Observers.create({'resourceName': 'callbackTempObserver', 'resourceClass': 'callbackNo9fier', 'handlerURI': 'callback:///sensors/rhvWeather-‐01/Agent/ addHandler'})