www.nabto.com Carsten Rhod Gregersen, Founder

Using peer-to-peer and distributed technologies to solve the IoT challenges

Presentation at ”Living bits and things 2013”

Installation Quality assurance

Support Accounting Customers

PRODUCT

CONTEXT: WHY DEVICE INTERNET?

?

ESSENTIAL NEEDS

IOT Device

Device Firmware

GUI HTML5/

APP

Data Acquisition

Analysis & Monitoring

End users

Translates into two major requirements: Graphical GUI - interact directly with the device

Data acquisition - monitor and analyze data

THREE TYPES OF IOT

FS

(RT)OS

HTTPD

TCP/IP

DB

Fat Webserver Device

GUI LOGIC

Data acquisition and push logic

(RT)OS

Cloud

Virtual Device

Virtual cloud device

Client reachable P2P/VoIP device

(Skype)

Connect API

(RT)OS

Client

Remote Connect API

Graphics, Javascript, Templates, Stylesheets

Firewall Firewall

Client

Data Analysis

CLOUD DEVICE IOT APPROACH

End users Data

Acquisition Backend

HTTP Web frontend

Data storage layer Data push protocol

At firmware creation time: What, When, Where to push data?

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

Device Connect

API

GUI or Data

Collector

Basestation VoIP : SIP server

Skype : Supernode

P2P connection for Data acquisition or GUI

Client Connect

API

Connect request Identification & Awareness

• 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

Device Logic

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

Firmware

IOT Device

Connect API

PC, Tablet, Smartphone, etc.

P2P HTML5

GUI

Data Acquisition

Back office

P2P

• 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

PC/Mobile/Tablet

Direct P2P connection Low bandwidth raw data

Browser Protocol Plugin

Firmware

HTML Device Driver (English)

HTML Device Driver (German)

HTML Device Driver (OEM A)

HTML Device Driver (OEM B)

Device

DISTRIBUTED HTML5 COMPUTATION

Plugin Data cache

• Downloaded automatically on first device connect

• Alternatively distributed on DVD/USB etc.

Plugin technology enables distributed GUI computation – high autonomy Full autonomy, scaling, flexibility and GUI differentiation based on client version/model/language etc.

EXAMPLE APPLICATION: DANFOSS SOLAR

IOT Device

OBSERVATION: ADAPTIVE DATA-ACQUISITION

Since the cloud initiates the P2P connect, it can easily be configured to do adaptive Data acquisition

Data Acquisition

P2P

External Trigger

Acquisition Timer

Embedded Logic

Nabto Data API

Example: Weather forecast

OBSERVATION: MULTIPLE DAQ FLOWS

Embedded Logic

IOT Device

P2P Data API

Multiple P2P connections for multi-flow data acquisition

P2P Data Acquisition

DAQ system 1

P2P Data Acquisition

DAQ system 2

P2P Data Acquisition

DAQ system 3

P2P

P2P

P2P

DIFFERENT DATA-FLOW AND PRIVACY NEEDS

DAQ A

R&D / QA

Production

OEM Customer

Co

nn

ect

AP

I

DAQ B

Co

nn

ect

AP

I

DAQ OEM

Co

nn

ect

AP

I

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.

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.

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 data-analysis. OEM want full data control – cannot share data

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 Virtual device P2P/VoIP

Identification and addressability Depends

Authentication and privacy Transmission only

Adaptable data flow Through central services

Autonomy, robustness and stability

Autonomy – no Single point of service

Flexible to changing needs Only if data collection need doesn’t change

Ease-of-use, easy adoption Pure internet environments - yes

Scalability DATA x TIME x DEVICES DEVICES ()

Time-to-market Data-needs to be known at firmware creation

Cost See scalability

Latency 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