The internet of things requires a different architectural model than what we've used to build Web 2.0. This presentation makes a proposal for what that architecture could look like and presents a working example based on the connected car platform Fuse (http://joinfuse.com)

1. Connecting Everything
Phillip J. Windley, PhD
Enterprise Architecture, BYU
CTO, Kynetx, Inc.
@windley

2. Internet of Things

3. The Internet of Things will
lead to a computing
experience that is immersive
& pervasive.

4. Ambient Computing

5. vs

8. But it’s bigger than that…
Everything will have an online
representation.

9. Connections Everywhere
The things you own
The things you don't
Different types of connections

10. What will its architecture be?

11. Personal: Clients working on behalf
of the user
Real-time events and alerts
Access to data through APIs
Context

12. Imagine a mountain
representing today’s billion
node network...

13. From Trillions by Maya Design

14. From Trillions by Maya Design

15. Events and Requests

16. “this happened” vs “do this”

17. Static Data & Dynamic Queries

20. Dynamic Data & Static Queries

25. Event System Properties
Events are autonomous
Event-driven system are more loosely coupled
Downstream (receiver) driven flow control
Near real-time propagation

26. The Current #IoT Model
Won’t Scale

27. Me

29. GE

30. Internet
of
My Things
Me
GE

31. The Internet of My Things

32. The Internet of My Things
leads to
The API of Me

33. Fuse is Three Things
http://joinfuse.com

36. Social Products

37. "The car needs to become your friend. How does the
car speak to me? How does the car integrate with the
dealership and the factory? How does the car help me
get to the service station? ... I want a relationship with
the car in the same way I have a relationship with my
friends. ... The car is going to become social. All our
products are going to become social."
—Marc Benioff

38. But it’s not just about
manufactured things...

39. We give each thing a
persistent compute object,
or pico

40. Picos are online computers
Identity—they represent a specific entity
Storage—they persistently encapsulate both structured
and unstructured data
Open event network—they respond to events
Processing—they run applications autonomously
Event Channels—they have connections to other picos
APIs—they provide access to and access other online
services

41. Picos Are Decentralized & Networked

42. Built on open standards
Built on open source

43. Phil's Cloud Tom's Cloud
1
2
3
4
owner
borrower
Lynne's Cloud
1
owner
Picos Ease Modeling

44. Picos support a new Web
programming model

45. Web
Application
Application
Data
Browser

46. Web
Application
Application
Data
Browser

47. Picos Use an Event Query Model
pico
functions
rules
persistent
storage
or CancelDone
User Interface
name
email
phone
query API
event API
user makes change in UI
resulting in an event
UI updates presentation
using query API
rules validate and process event,
often updating model
functions return results based
on persistent data

48. Picos Support A Familiar Model
CloudOS
Kynetx Rules Engine
Kernel
Space
Configuration
Management
CloudOS
Service
Services &
Libraries
User
Space
Notification
Service
Forevr.us
(contact)
Timeline
(social)
ToDo&
Reminders
Vehicle
Manangement
Applications
PersonalData
Service
UISupport
Other
Data
Sources
Web
Services
APIs
Home
Management
Intentcasting
File
Social
Rulesets
Persistent
Data
...
...
APIs
Social
Persistent Compute Object
Fuse
Library
Fuse
Guard
Tour
Library
Guard
Tour

49. Programming Model
Program in any language you like
OAuth access to pico
Pico provides
user data
processing
API and inter-pico communications

50. Microservices
Organized around a single business
capability
Small, generally less than 1000 lines and
code and usually much smaller
Event-based and asynchronous
Run in their own process
Independently deployable
Decentralized data storage

52. Healing Subscriptions
rule check_subscriptions {
select when fuse subscription_check
pre {
vid = carvoyant:vehicle_id();
my_subs = carvoyant:getSubscription(vid);
should_have = required_subscription_list.length();
}
if(my_subs.length() < should_have) then
send_directive("not enough subscriptions")
fired {
log ">>>> vehicle #{vid} needs subscription check";
raise fuse event need_initial_carvoyant_subscriptions;
}
}

53. Healing Subscriptions
rule check_subscriptions {
select when fuse subscription_check
pre {
vid = carvoyant:vehicle_id();
my_subs = carvoyant:getSubscription(vid);
should_have = required_subscription_list.length();
}
if(my_subs.length() < should_have) then
send_directive("not enough subscriptions")
fired {
log ">>>> vehicle #{vid} needs subscription check";
raise fuse event need_initial_carvoyant_subscriptions;
}
}

54. Healing Subscriptions
rule check_subscriptions {
select when fuse subscription_check
pre {
vid = carvoyant:vehicle_id();
my_subs = carvoyant:getSubscription(vid);
should_have = required_subscription_list.length();
}
if(my_subs.length() < should_have) then
send_directive("not enough subscriptions")
fired {
log ">>>> vehicle #{vid} needs subscription check";
raise fuse event need_initial_carvoyant_subscriptions;
}
}

55. Healing Subscriptions
rule check_subscriptions {
select when fuse subscription_check
pre {
vid = carvoyant:vehicle_id();
my_subs = carvoyant:getSubscription(vid);
should_have = required_subscription_list.length();
}
if(my_subs.length() < should_have) then
send_directive("not enough subscriptions")
fired {
log ">>>> vehicle #{vid} needs subscription check";
raise fuse event need_initial_carvoyant_subscriptions;
}
}

56. Healing Subscriptions
rule check_subscriptions {
select when fuse subscription_check
pre {
vid = carvoyant:vehicle_id();
my_subs = carvoyant:getSubscription(vid);
should_have = required_subscription_list.length();
}
if(my_subs.length() < should_have) then
send_directive("not enough subscriptions")
fired {
log ">>>> vehicle #{vid} needs subscription check";
raise fuse event need_initial_carvoyant_subscriptions;
}
}

57. KRL
Runs in picos
Built for microservices
Complex event expressions
Persistent variables
Side-effects are quarantined

58. This can get complex…
Institution
Tour
Index
Location
Index
Report
Index
Tour
"LUFX"
Tour
"KUFF"
Location
"R7RK"
Report
"1"
Location
"G5YH"
Report
"current"
Location
"T67G"
Managers
Guards
Guard
"Frank"
Subscriptions
permanent
temporary
Report
"2"Report
"2"Report
"2"Reports
Tours
Tours
Tours
Tours
Locations
Locations
Locations
Locations

59. Why do this?
Orthogonality and modularity are
powerful: network effects!
More flexible
Can be less work
More private

60. What Technology Wants

61. Recommended Reading
Mirror Worlds, David Gelernter
Snowcrash, Neal Stevenson
Rainbow's End, Vernor Vinge
The Intention Economy, Doc Searls
Trillions, Peter Lucas, Joe Ballay & Mickey McManus

62. My book on
how this can
be built now

63. CloudOS White Papers
www.windley.com

64. Contact info:
Phil Windley
pjw@kynetx.com
www.windley.com
@windley
Connecting Everything