Past, Present and Future of IoT Device Prototyping Bjoern Hartmann - - PowerPoint PPT Presentation

past present and future of iot device prototyping
SMART_READER_LITE
LIVE PREVIEW

Past, Present and Future of IoT Device Prototyping Bjoern Hartmann - - PowerPoint PPT Presentation

Past, Present and Future of IoT Device Prototyping Bjoern Hartmann Intel/NSF CPS-Security Final PI Meeting Stanford, CA July 13, 2018 How Technologies Take Off: The Web Source:Pingdom/Linda Carroll What Made the Web Take Off? Lots of


slide-1
SLIDE 1

Past, Present and Future of IoT Device Prototyping

Bjoern Hartmann Intel/NSF CPS-Security Final PI Meeting Stanford, CA July 13, 2018

slide-2
SLIDE 2

How Technologies Take Off: The Web

Source:Pingdom/Linda Carroll

slide-3
SLIDE 3

What Made the Web Take Off?

  • Lots of people could create web pages and apps, not just 


Stanford/Berkeley/Michigan/UPenn/Duke PhDs

  • People with domain expertise (+CS undergrads) could create 


truly useful apps for their domain, within an established technology “genre”


slide-4
SLIDE 4

The Web Development Stack

Client-side logic (JS) Declarative Layout (HTML/CSS)

Browser / User

Server-side logic (*) External stores/ APIs/Infrastructure logic etc. start low, work your way up

slide-5
SLIDE 5

Platform support for success

  • Gradual on-ramp: Good prototyping tools 


+ low initial development complexity

  • A large corpus of exemplars: “View Source” (only works for client)
  • Inspection/debugging tools built into browsers
  • Moving to higher levels of abstraction 


(AppEngine, WordPress, etc.)

slide-6
SLIDE 6

Technologies Taking Off, Part 2?

IoT Hockeystick Graphs Everywhere…

slide-7
SLIDE 7

…Or Not?

slide-8
SLIDE 8

The IoT Stack

Circuits Sensors Actuators

Physical World / User

Embedded Code Gateway Cloud

slide-9
SLIDE 9

The IoT Stack

Circuits Sensors Actuators

Physical World / User

Embedded Code Gateway Cloud

EE Mechatronics Low-level languages High-level languages

start low, work your way up

slide-10
SLIDE 10

Interaction Mechanical Electronics Software

slide-11
SLIDE 11

How might we enable a similar cambrian explosion of useful IoT applications in the face

  • f these difficulties?
slide-12
SLIDE 12

Prototyping is Key

…it’s how designers work through ideas

Early digital camera exploration, IDEO Apple IPhone Prototype

slide-13
SLIDE 13

We build a lot of these…

slide-14
SLIDE 14

Personal Environmental Control System (PECS) Michael Andersen, Joseph Bynoe

slide-15
SLIDE 15

Anthony Sutardja Maxwell Micali Christine Dierk Zachary Gima

slide-16
SLIDE 16

Sunita Venkatesh Lucy Corippo Adarsh Mani (w/ UCSF)

slide-17
SLIDE 17

Simon Scott, Will Porter, Yi Tong, Mitchell Karchemsky

slide-18
SLIDE 18

Michelle Nguyen Eldon Schoop

Augmented Power Tools

slide-19
SLIDE 19

Laser Projector Distance Sensors Computation

slide-20
SLIDE 20
slide-21
SLIDE 21

What did we learn over 
 the past decade?

slide-22
SLIDE 22

The Past

Add a wireless module with serial abstraction

Tx Rx

Configure and run 
 server on your own hardware Custom protocol Design circuit Connect to an 
 8-bit MCU Custom gateway

slide-23
SLIDE 23

How to support IoT prototyping

  • Strategy #1: 


Help people reason about and bridge boundaries in the current approach.
 


slide-24
SLIDE 24

The More-Recent Present

Design circuit Sever on Azure, Amazon, etc IoT vendor-managed cloud Custom messaging

  • n

pre-defined channel Connect to
 32-bit SOC/SOM w/ on-board radio

Examples: Particle, ElectricImp

slide-25
SLIDE 25

How to support IoT prototyping

  • Strategy #1: 


Help people bridge boundaries in the current approach

  • Strategy #2: 


Replace past practice with new tools offering a 
 higher level of abstraction or integration.

slide-26
SLIDE 26

How to support IoT prototyping

  • Strategy #1: 


Help people bridge boundaries in the current approach

  • Strategy #2: 


Replace past practice with new tools offering a 
 higher level of abstraction or integration.

slide-27
SLIDE 27

Bridging Boundaries

Circuits Sensors Actuators

Physical World / User

Embedded Code Gateway Cloud

ToastBoard BiFröst WiFröst

slide-28
SLIDE 28

Bridging Boundaries

Circuits Sensors Actuators

Physical World / User

Embedded Code Gateway Cloud

ToastBoard BiFröst WiFröst

slide-29
SLIDE 29

Toast board

  • Point measurements (Multimeter, Scope) require

hypothesis about circuit problem.

  • Non-experts are bad at generating reasonable

hypotheses.

  • Replace point measurements with ubiquitous

instrumentation (measure everything, all the time)

  • Combine circuit model with real-world

measurements to diagnose problems.

slide-30
SLIDE 30
slide-31
SLIDE 31
slide-32
SLIDE 32
slide-33
SLIDE 33
slide-34
SLIDE 34

Client: Checker Functions

Overcoming the debugging knowledge barrier by preemptively providing important information


slide-35
SLIDE 35

Client: Checker Functions

Can diagnose errors: Or provide information:

slide-36
SLIDE 36

Bridging Boundaries

Circuits Sensors Actuators

Physical World / User

Embedded Code Gateway Cloud

ToastBoard BiFröst WiFröst

slide-37
SLIDE 37

Trace

37

Digital Signals Analog Signals Variable Values Code line at current time User Program Time-linked console

The BiFröst IDE

slide-38
SLIDE 38

38

Example: ADC Variable Overflow

slide-39
SLIDE 39

Trace

39

User Program Time-linked console Trace View

Trace ⇔ Code ⇔ Console linkage

slide-40
SLIDE 40

40

Code-based navigation

slide-41
SLIDE 41

How to support IoT prototyping

  • Strategy #1: 


Help people bridge boundaries in the current approach

  • Strategy #2: 


Replace past practice with new tools offering a 
 higher level of abstraction or integration.

slide-42
SLIDE 42

Raising Abstraction Levels

Circuits Sensors Actuators

Physical World / User

Embedded Code Gateway Cloud

Embedded Design Generation Fabryq Ravel

slide-43
SLIDE 43

Raising Abstraction Levels

Circuits Sensors Actuators

Physical World / User

Embedded Code Gateway Cloud

Embedded Design Generation Fabryq Ravel

slide-44
SLIDE 44

EDG: Embedded Design Generation

  • Goal: Given a higher-level specification of an embedded system,

automatically generate the hardware necessary to run the code.

  • What should the specification look like? We investigated 2 options:
  • Code that the hardware should run
  • High-level block diagram
slide-45
SLIDE 45

Generating Hardware from Code

Ramesh et al, SCF 2017

slide-46
SLIDE 46

Option 2: Block Diagram Specs

Interesting research: Explore Pareto front of design alternatives - optimize for cost, part availability at different quantities, community documentation, etc.

Student: Richard Lin

slide-47
SLIDE 47

Design Inspiration:
 Interview Study of 15 HW Designers

OVLFY3C7 Part Number Size APG1005SYC-T 5988140107F 5mm 0402 0805 Vf 2 V 2.05 V 2 V LED Button Micro- controller

System Architecture Physical Device Parts Selection Iteration

Micro- controller ATmega32u4 Part Number Core LPC1549 FE310-G000 AVR ARM CM3 RV32IMAC +3.3v D0 D1 GND ATmega ...

Ideas and Requirements Prototype PCB Hand-built Prototypes Final PCB

U1 SW1 R1 J1 R2 D1

Schematic Capture

  • or -

paper, drawing software parts libraries, catalogs, spreadsheets Tools Used fi fi more abstract, high-level more concrete, low-level fi Design Flow breadboards EDA suites: Altium, EAGLE, KiCAD

Unsupported or under-supported by current tools

slide-48
SLIDE 48

Related

Trigger-Action Circuits, 
 Autodesk 2017 Scanalog - Analog circuits via FPAAs
 Strasnick et al, Stanford 2017

slide-49
SLIDE 49

Raising Abstraction Levels

Circuits Sensors Actuators

Physical World / User

Embedded Code Gateway Cloud

Embedded Design Generation Fabryq Ravel

slide-50
SLIDE 50

Fabryq

  • Enable rapid prototyping of BLE sensor logging devices that stream

data to the web

  • Motivation: Personalized medicine and home care - send patient

home with monitoring device while medical team can read data remotely

  • Domain experts know about sensing, data transformation and

interpretation, not the stack in the middle

slide-51
SLIDE 51

Fabryq

slide-52
SLIDE 52

Core Idea: Bridge Layers!

Circuits Sensors Actuators

Physical World / User

Embedded Code Gateway Cloud

slide-53
SLIDE 53

Security Implications

  • A perhaps inevitable consequence of many more people building

ever more services/apps/devices: They don’t consider security in the way this room would. Many impactful breaches are not at all “sophisticated”:

  • Mirai: default username/password
  • Trendnet cameras: plaintext credentials transmitted
  • LocationSmart: Simple JSON edit exposes location of any cell

phone in US

slide-54
SLIDE 54

How can these tools help?

  • Tools that help you inspect and debug your IoT device can

proactively check for problems

  • Example: WiFröst router detects unencrypted login/password

passed over HTTP

  • Tools that raise the abstraction level can avoid these problems by

design (application developers don’t write the critical code).

slide-55
SLIDE 55

Open Steps

  • Today’s consumer IoT devices are largely single device-to-device-

specific cloud. However, major value (and risk) is in interconnection.

  • Current Split: low-power systems (e.g., BLE, wearables) vs. full Linux

systems (i.e., smartphone level or higher) when using audio/vision/ 3d point clouds, etc. But this is changing:
 ML co-processors are emerging in embedded space - yet another boundary - code split between general purpose and ML models.

  • How might we help designers and develop create these

applications?

slide-56
SLIDE 56

Q&A