The document discusses challenges facing the Internet of Things (IoT). It notes that while IoT promises connectivity between devices, current approaches are not scalable as they rely on engineers and customized solutions for each product. For IoT to scale, standards and common semantics are needed to allow interoperability and automation. The future of IoT requires horizontal platforms that can support many applications rather than today's vertical platforms for individual domains.

1. Humans don’t scale
The future of the Internet of Things
Pilgrim Beart
pilgrim@beart.org.uk
SN31

2. Today: my perspective on IoT
• What is it?
• Why is it (not) happening now?
• Interesting problems
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi! 2

3. My background
Smart Energy Analytics Smart Heating Smart Appliances Smart Home
Information Remote Control
Analysis on how I & when I use energy • Heating • Appliances • Lights
to help understand my bill and advice • Cooling • Locks
on how to save. • Hot water • Security
• Cameras
3

4. “Smart” => Connected
+
=
4
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi!

5. Every day seems brings a new
internet-connected thing/service
5
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi!

6. IoT means more than just
“internet-connected-things”

7. Why now?
• Trend: from Products->Service
– Enduring service relationship (vs. one-time sell)
– Easier UX – SmartPhone App
– Remote access & control (for humans & machines)
• Barriers falling
– Increasing availability of Internet dial-tone
– Falling costs of connecting
• ARM: huge growth in embedded licenses
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi! 7

8. Why hasn’t IoT taken-off yet?
• Everyone solving just their own problems
– 1:1 applications (for that one product only)
– Machine-to-human applications
• Everyone building complete architectures
• “The nice thing about standards is that you have
so many to choose from”
– 3rd-party parts today don’t just interoperate
• Humans (engineers) still have to get involved in
making services & things work together
... and humans don’t scale
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi! 8

9. 9
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi!

10. 10
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi!

11. “me-centric”
approach
inhibits multiple API’s
different from everyone else’s
scaling inhibits network-effect
Tech:MB/s,
People:Dev’t,
Commercial:Lock-in
11
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi!

12. “It’s not what’s in the boxes that matters,
it’s how they are connected”
Toby Jaffey
12
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi!

13. 13
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi!

14. Thing
Thing
Thing
Thing Thing
Thing
Thing Thing
Thing Thing
14
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi!

15. API representations & paradigms
• Data representations
– JSON
– XML
– database schema
• API paradigms
– RESTful
– PubSub (topic broker)
• Broker-centric
– AMQP (RabbitMQ etc.)
– MQTT (mosquitto)
• Distributed
– ØMQ POLLING
– Socket.IO
• Available open source
• Available as Cloud
– Cloud.IO, Iron.IO, PubNub…
• … plus many proprietary ones
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi! 15

16. Unlikely everyone will agree on a single
standard/framework for IoT connectivity
…but they don’t need to
• Can glue different API’s together automatically
iff they share common semantics
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi! 16

17. “Connected” at what layer?
• At layer 7 we have the
application, by definition unique
since it’s where the value is added
• Somewhere in layer 6-7 is where
some common IoT conventions could
really help.
• Layers 3 & 4 are TCP/UDP/IP by
definition, since we are talking about
the Internet of Things
• Layers 1 & 2 will vary, and we want
to insulate App writers completely
from that
17
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi!

18. Minimum semantic connectivity
(not an ontology)
• A lingua franca for machines
• Can’t possibly envisage all uses
– So inventing a superset is doomed to failure
• So identify minimum common subset
– i.e. the intersection of sets, not the union!
Common to all applications… Common to all PHYs…
COM COM
MON MON
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi! 18

19. Common problems =>
Common semantics
• For Data
– Enumerate data “channels” of a Thing
– (name, type, value)
– Data rates, push vs. pull etc.
• For Managing Things
– ID
– Commissioning
• Securely attaching to LAN, WAN & services
– Topology (child devices)
– Upgrades
• …ideally all built on a small set of canonical types
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi! 19

20. Semantics isn’t just for connectivity
Comms stack: DB stack: Rules:
Application Application Rules
Common Common Common
Semantics Semantics Semantics
JSON BSON Rules Engine
MQTT Storage
SSL
TCP
IP
20
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi!

21. Today we have vertical platforms
… Security Lighting Energy Heating Telecare …
UI’s UI’s UI’s UI’s UI’s
Apps Apps Apps Apps Apps
Scale Scale Scale Scale Scale
Testing Testing Testing Testing Testing
Device Device Device Device Device
Mgmt Mgmt Mgmt Mgmt Mgmt
Data Data Data Data Data
Warehouse Warehouse Warehouse Warehouse Warehouse
Device Device Device Device Device
Persistence Persistence Persistence Persistence Persistence
Skyhooks Skyhooks Skyhooks Skyhooks Skyhooks
Gateways Gateways Gateways Gateways Gateways
Devices Devices Devices Devices Devices
21
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi!

22. IoT requires horizontal platforms
… Security Lighting Energy Heating Telecare …
Directory Directory Directory Directory Directory
& Auth & Auth & Auth & Auth & Auth
UI’s UI’s UI’s UI’s UI’s
Apps Apps Apps Apps Apps
Scale Scale Scale Scale Scale
Testing Testing Testing Testing Testing
Device Device Device Device Device
Mgmt Mgmt Mgmt Mgmt Mgmt
Data Data Data Data Data
Warehouse Warehouse Warehouse Warehouse Warehouse
Device Device Device Device Device
Persistence Persistence Persistence Persistence Persistence
Skyhooks Skyhooks Skyhooks Skyhooks Skyhooks
Gateways Gateways Gateways Gateways Gateways
Devices Devices Devices Devices Devices
22
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi!

23. I’m an engineer, so…
REDUCING IT TO PRACTICE
23
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi!

24. Start with the customer:
What do IoT customers want?
1. Scale to millions (of users & of sensors) - cost-effectively
– i.r.o. $0.10/user/month or $0.01/sensor/month with per-minute updates
2. Easy to manage
– subset of 1): scaling practical only if cost-effectively managed*
3. Reduced Time- and Cost-to-market
– minimal engineering time, minimal NRE costs*
4. 3rd-party enablement (ecosystem)
– end-devices and gateways can be added without IoT core code changes*
– agnostic (no lock-in)
5. Reliable
6. Secure
7. Rapid evolution of every part (but stable architecture)
*because Humans Don’t Scale
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi! 24

25. To prove it, build it
Component Implementation
Directory & Auth (Ab)use DNS?
UX HTML+Websockets?
Data representation JSON/BSON
API paradigm MQTT/AMQP/ØMQ?
Data warehousing & TempoDB & MongoDB
Persistence
Device Mgmt, Apps Async (node.js?)
Device Raspberry Pi? mBed?
PHY 6LoWPAN?
Important principle:
Every part of this can be swapped-out for an alternative (proves it’s open).
Ideally, prove that by implementing 2 alternatives for each.
25
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi!

26. What next
• IoTA, led by ARM, to break down IoT silos.
– Current focus:
• Semantics
• Security
• Management
– Bidding for TSB-funding
• Any CL projects of relevance to our bid?
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi! 26

27. Interesting problems (to me!)
Most aren’t unique to IoT. But we need automation because Humans Don’t Scale
• General Semantics (what existing frameworks can we ride on?)
• Scaling++: see what breaks & fix it
– Fun Hobby: run client+server on “infinitely elastic cloud” and let them rip each other apart!
– Memcached doesn’t help writes (REDIS, Mongo etc.)
– Sharding good for writes, but manually precomputing reduces
• Debugging distributed systems
– e.g. Google’s Dapper
• Getting data to the right place automatically
– Gossip protocols
– Migration as the norm
• Constantly take advantage of latest Cloud services
• Backup as an intrinsic property of the architecture, not of a particular database technology
• “Rules” that move automatically to run in the right place
– Even partition automatically too
• Energy efficiency
• Nodes in a Pubsub graph start to look like neurons…
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi! 27

28. Thanks for listening
• Please do introduce relevant colleagues
Pilgrim Beart
pilgrim@beart.org.uk
SN31
I’m in CUCL room SN31 Mondays & Tuesdays – come & say hi! 28