Living bits and things 2013 - Using peer-to-peer and distributed technologies (Nabto) to solve the IoT challenges
Upcoming SlideShare
Loading in...5
×
 

Living bits and things 2013 - Using peer-to-peer and distributed technologies (Nabto) to solve the IoT challenges

on

  • 692 views

The traditional approach of both "Big fat webserver device" and "Virtual cloud device" has some inherent challenges not easily solved. These are privacy, autonomy, latency, establishing multiple and ...

The traditional approach of both "Big fat webserver device" and "Virtual cloud device" has some inherent challenges not easily solved. These are privacy, autonomy, latency, establishing multiple and adaptable dataflows after deployment.

Statistics

Views

Total Views
692
Views on SlideShare
558
Embed Views
134

Actions

Likes
0
Downloads
6
Comments
1

2 Embeds 134

http://www.scoop.it 131
https://twitter.com 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Living bits and things 2013 - Using peer-to-peer and distributed technologies (Nabto) to solve the IoT challenges Living bits and things 2013 - Using peer-to-peer and distributed technologies (Nabto) to solve the IoT challenges Presentation Transcript

  • Using peer-to-peer and distributed technologies to solve the IoT challenges Presentation at ”Living bits and things 2013” www.nabto.com Carsten Rhod Gregersen, Founder
  • CONTEXT: WHY DEVICE INTERNET? PRODUCT Installation Quality assurance Customers Support ? Accounting
  • ESSENTIAL NEEDS Translates into two major requirements: Graphical GUI - interact directly with the device Data acquisition - monitor and analyze data GUI HTML5/ APP Device Firmware Data Acquisition IOT Device End users Analysis & Monitoring
  • THREE TYPES OF IOT Fat Webserver Device Virtual cloud device Client reachable P2P/VoIP device (Skype) Client Client Virtual Device Graphics, Javascript, Templates, Stylesheets Cloud Remote Connect API Firewall GUI LOGIC DB FS HTTPD TCP/IP (RT)OS Firewall  Data acquisition and push logic Connect API (RT)OS (RT)OS
  • CLOUD DEVICE IOT APPROACH At firmware creation time: What, When, Where to push data? Data Analysis End users Data storage layer HTTP Web frontend Data Acquisition Backend Data push protocol Device Logic Data push logic
  • SOME OBSERVATIONS • No internet -> No GUI – Low autonomy • Data requirements changes over time – Firmware has to be upgraded continuously • Firmware decides data push – Firmware has limited resources and knowledge, so normally simplistic algorithms for push are chosen • Scales : O(<DEVICES> x <TIME> x <DATAFOOTPRINT>) • Postulate: 95% of all data is ”normal” and not relevant – Two standard deviations – You don’t need full population knowledge to do statistics
  • P2P/VOIP IOT APPROACH - SCHEMATIC Connect request GUI or Data Collector Client Connect API Basestation VoIP : SIP server Skype : Supernode P2P connection for Data acquisition or GUI Identification & Awareness Device Connect API Device Logic • Basestation act as an internet “PABX” for devices • Basestation knows current internet “status” of devices and can mediate connections from clients to devices • Technology is similar to VoIP/Skype etc
  • NABTO PLATFORM Every device is given and identified by a unique identification <serial>.<vendordomain>.net Total device footprint typically about 10 kB of flash and 2 kB of RAM Direct interaction with device through peer-to-peer connection (with local (offline) support) Strong security, integrity and authentication Full privacy - No device data stored in cloud solution (data-acquisition and storage is optional) Provides full, interactive web experience – even on very limited devices with no HTTP/TCP stack • Platform abstraction layer is 12 functions • 36 different platforms supported via FreeRTOS partnership
  • P2P CLIENT REACHABLE DEVICE APPROACH • P2P connection is a generic data connection • Possible CoAP and DTLS support • Authenticated clients can access device data • No decisions upon firmware creation! • Usage both HTML5-GUI and/or Data acquisition IOT Device PC, Tablet, Smartphone, etc. HTML5 GUI P2P Back office Connect API Data Acquisition Firmware P2P
  • DISTRIBUTED HTML5 COMPUTATION PC/Mobile/Tablet Device Direct P2P connection Low bandwidth raw data Browser Protocol Plugin Firmware Plugin Data cache HTML Device Driver HTML Device Driver (English) Plugin technology enables distributed GUI computation – high autonomy (German) HTML Device Driver HTML Device Driver (OEM A) (OEM B) • Downloaded automatically on first device connect • Alternatively distributed on DVD/USB etc. Full autonomy, scaling, flexibility and GUI differentiation based on client version/model/language etc.
  • EXAMPLE APPLICATION: DANFOSS SOLAR
  • OBSERVATION: ADAPTIVE DATA-ACQUISITION Since the cloud initiates the P2P connect, it can easily be configured to do adaptive Data acquisition Nabto Data API Embedded Logic IOT Device P2P Data Acquisition Acquisition Timer External Trigger Example: Weather forecast
  • OBSERVATION: MULTIPLE DAQ FLOWS Multiple P2P connections for multi-flow data acquisition DAQ system 1 P2P P2P Data Acquisition DAQ system 2 P2P Data API P2P Embedded Logic IOT Device P2P Data Acquisition DAQ system 3 P2P P2P Data Acquisition
  • DIFFERENT DATA-FLOW AND PRIVACY NEEDS Reason and requirements: OEM buy the XYZ product/component. It’s used in a larger complex composite product. The data from XYZ component is used in a larger system of control and dataanalysis. OEM want full data control – cannot share data Connect API DAQ A Production Connect API Reason and requirements: We have observed that systems in which temperatures in the “ABC” part rises over long terms will at some point fault. We generally only coarsely monitor, but devices reaching a certain temperature threshold we switch to monitoring and storing very fine grained and of course inform our customers about potential issues. R&D / QA DAQ B OEM Customer Connect API Reason and requirements: We need to very fine-grained monitor and store data of devices in batch 482 and 593, because we are investigating a possible production error. Also serial 482934, 84992, 84932 we need to observe closely, they have been flashed with a new firmware going into production soon. DAQ OEM
  • IOT CHALLENGES Generic: • Identification and addressability • Authentication and privacy • Adaptable data flow • Autonomy, robustness and stability Operational • Future proof solution • Ease-of-use, easy adoption • Scalability • Time-to-market • Cost
  • CLOUD VIRTUAL VS. P2P/VOIP - DEVICE Challenge Identification and addressability Authentication and privacy Adaptable data flow Autonomy, robustness and stability Flexible to changing needs Ease-of-use, easy adoption Scalability Time-to-market Cost Latency Virtual device P2P/VoIP Depends Through central services    Autonomy – no Single point of service  Only if data collection need doesn’t change  Pure internet environments - yes  DATA x TIME x DEVICES DEVICES () Data-needs to be known at firmware creation  See scalability   Transmission only Moderate
  • EXAMPLE PRODUCTS Danfoss Solar Inverters: Monitoring / Control solution Cosesy: Residential Alarm system WindowMaster (Velux): Skylights and Window Controller
  • EXAMPLE APPLICATION: ”INDUSTRIAL CONTROL”
  • OTHER CURRENT USES OF PLATFORM STREAMING APPLICATIONS - Serial link gateway (RS232/RS485) - Video streaming (DVRs, cameras) - Audio streaming (hearing aids) - Firmware updates - Remote desktop (VNC tunnelling) VPN APPLICATIONS - Honeywell EBI BACnet building automation - Ritzau News Agency DATA ACQUISITION - Water heaters - Wind turbine production data - Indoor climate statistics
  • www.nabto.com Founder, Carsten Rhod Gregersen – crg@nabto.com