Download - Going Bezirk: Things Plus Cloud Do Not Equal IoT · Bezirk. IoT that tastes better. Things plus Cloud does not equal IoT. IoT by default. Saturn 2016, San Diego

Bezirk

IoT that tastes better

Things plus Cloud does not equal IoT

IoT by default

Saturn 2016, San Diego

Bezirk

Sousa | 5/04/2016© 2016 Robert Bosch LLC and affiliates. All rights reserved.

2

problemArchitecting the IoT (experienced by people)

personalized experienceeverywhereTurn lights onWhy are they red?Get me a coffee!

search Q&A Q&AThings Web

Bezirk


3

problemArchitecting the IoT

device hub

By default raw data pumped to the cloud

for processing and analytics

Reality check responsiveness

multi-vendor fragmentation

rampant threats to privacy

cloud-centric IoT

Bezirk


4

IoT by defaultresponsiveness

cloud-centric IoT

device hub

Reality check

Bezirk


5

IoT by defaultmulti-vendor fragmentation

cloud-centric IoT

device hub

Bosch

Phillips

Google

BMW

mainstream business modelsrevolve on the value of datafor service providers

Data becomes a business asset:little incentive to share

Reality check

Bezirk


6

IoTnot all Data is created equal

Public & corporate data:weather, traffic,shopping, customer support…

Social networks:friends, pictures…

Owned devices:energy usage,maintenance diagnostics…

User experience:how did you sleep?what are you doing?what are you asking?

shared

owned

things you

Bezirk


7

IoTnot all Data is created equal

what does that mean to you?

but it all goes to the cloud

Bezirk


8

IoT by defaultrampant loss of privacy

Reality check

Bezirk


9

Bezirk to the IoT what bio/organic is to agricultural productsIoT that tastes betteris

reclaim user-defined boundaries

shared

owned Who knows about this? Just you

and I.

Bezirk


10

Architecting the IoTHub-and-spoke System of Systems

Sphere: Bob’s car

Bob’s Home Systems

Bob’s HomeEntertainment

Bob’sDoctor

Sphere:Bob’s personal

Pipe to cloud

boundaries of confidentialitySecurity model Pipes between spheres / to cloud

secure channels for data & events requested by services,

authorized by users policy enforced by middleware

only authorized exchanges go through

Spheres of trust bring security to realm of users

create sphere, join device…

easy user experiencepromote usability of security

Bezirk


11

Architecting the IoTHub-and-spoke System of Systems

boundaries in topology Internet: successful apps

run on general purpose computersand access remote servicese.g. email, web browsing

IoT: must a sensor/appliance shoulderthe burden of a peer on the internet?e.g. access control…

a sensor/appliance does not communicateprimarily with remote services

device hub

our claim

IoT topology should recognize and support two kindsof communication scopes: local and remote

IoT ≠ give every device an IP(v6) address

Bezirk


12

Architecting the IoTTopology addressing a Thing

address applications who receives

nodee.g.172.16.254.1 (IPv4)

Internet routing:IPv4 (1981), IPv6 (1998)

LANs: Bluetooth, WiFi…

identified node

geoe.g.(40.426, -79.965, 500)(lat, long, radius)

sensor networks,safety & disaster response,transportation

whoever is in the area

topic labele.g.“user location”

pub/sub: Java Messaging Service (message centric),Data Distribution Service (data centric)

whoever subscribesto the topic

sender must know recipient’s address

appl

icat

ion

defin

edne

twor

k de

f.

different addressing schemas solve different problems

landscape of addressing schemas

Bezirk


13

Architectural PracticeAddressing by IntentionCommunication within topological boundaries

how a request is resolved depends on the status of the environment no need to scale unique internet addressing to every device

App

UserLocation

UserRegistry

UserLocation

(locateUser).(Bob)

(getFace).(Bob)

(userFace).(Bob,)

(userLocation).(Bob,<here>)

Dishwasher

trace 1

(locateUser).(Bob)

(getFace).(Bob)

(userLocation).(Bob,<here>)

trace 2

Bezirk


14

Architectural PracticePromote decentralized IoT

dynamic & resilientprivate & secure

impromptu comms.no single-point-of failure

brokerless pub-sub

Addressing by intentionSpheres & Pipes

Interoperation Protocols open, multivendor

personalized experienceeverywhereTurn lights onWhy are they red?Get me a coffee!

I know about my

userI know

about myuser

Bezirk


15

Architectural Practicedecentralized emphasizes Protocols

Dragonfly Penguin

• External service observes the user’s lighting choices (e.g., yellow lights on),and the context in which the choices occurred

• External service shares these observations within the network (and with U)

example: learning how user engages the environment

Bezirk


16

Architectural Practicedecentralized emphasize Protocols

example: tailored user profile upon request

Penguin• Receive request - service requests the profile of a user• Filter knowledge - U decides what user knowledge is relevant for the service.• Encode knowledge - U encodes the relevant knowledge into a profile

and sends to the requesting service

Bezirk


17

Architectural PracticeAddr. by Intention Rich forms of request-reply

Bezirk


18

Open developers’ communityhttp://www.bezirk.com

Bezirk middlewareDragonfly

UPe

rson

aliz

atio

n

Penguin

open

end-users:• access cloud services• up/download content

InfoDB

...

Part

yph

oto

shar

ing

code over• services / apps• protocols

try outnew services& use cases

you maydownload

Hue

driv

er

WiP

inin

door

lo

caliz

atio

n

cloud services

loca

l ser

vice

s

…

planned

???

Bezirk

developer portal

SDKbinaries docsplanned Bezirk

…

planned