IoT Toolkit and the Smart Object API - Architecture for Interoperability
-
Upload
michael-koster -
Category
Internet
-
view
244 -
download
3
Transcript of IoT Toolkit and the Smart Object API - Architecture for Interoperability
IoT Toolkit and the Smart Object API Architecture For Interoperability
Michael J Koster [email protected]
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
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
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
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
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
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
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
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
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
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
Smart Object Structure – Object Model
Smart Object
DescripDon
ObservableProperty
ObservableProperty…
Agent
Publisher Subscriber Handler
PropertyOfInterest
DescripDon
Observers
Handler Instance Daemon
Default Property
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
Protocol Bridge Examples
• MQTT Endpoints and Bridge using Observer • CoAP Server Endpoint and link-‐data Proxy
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
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
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
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
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
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
IoT Toolkit Protocol Interoperability
CoAP
MQTT
MQTT HTTP
smartobjectservice.com
ec2-‐54-‐200-‐106-‐25.us-‐west-‐2.compute.amazonaws.com
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
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
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
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
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);! }!
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’}!
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')))!
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' })
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 })!
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 })
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'})