Keynote at YAPC::NA::2015, June 10, 2015.

1. Implementing a Rule Language
for the Internet of Things
Phil Windley
Office of the CIO
Brigham Young University

2. The great question
(about power) is who
should have it.
– John Locke

4. The Web (circa 1996)

5. Client
Space
Server
Space
Google FacebookiCloud
Web 2.0

6. Client
Space
Server
Space
Google FacebookiCloud
Web 2.0

7. Client
Space
Server
Space
Google FacebookiCloud
Web 2.0

8. So long as we are merely
clients of servers,
we cannot be independent

15. Internet of Things

16. Lorem Ipsum Dolor

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

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

19. What will its architecture be?

20. Trillion node networks

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

22. Lorem Ipsum Dolor
From Trillions by Maya Design

23. From Trillions by Maya Design

24. The Current IoT Model
Won’t Scale

25. Me

26. Me

28. GE

29. Internet of
My Things
Me
GE

30. • decentralized
• heterarchical
• interoperable

31. 1. Distributed transaction processing and
applications
2. Peer-to-peer messaging and sharing
3. Autonomous coordination and contracts
between peers

32. picos

33. Picos are online computers
• persistent—retain state based on past operations.
• unique—identity that is immutable.
• online—available on the Internet and respond to events and
queries.
• concurrent—operate independently of one another and process
events and queries asynchronously.
• event-driven—respond to events by changing state and sending
new events.
• rule-based—behavior is expressed as rules that pattern-match
against incoming events.

34. http://joinfuse.com

36. Owner
Pico
Fleet Pico
Vehicle
Pico
Vehicle
Pico
Vehicle
Pico

37. Owner
Pico
Fleet Pico
Vehicle
Pico
Vehicle
Pico
Vehicle
Pico
Owner
Pico

40. Phil's Pico
owner

41. Phil's Pico
owner
Lynne's Pico
owner

42. Phil's Pico Tom's Pico
owner
Lynne's Pico
owner

43. Phil's Pico Tom's Pico
owner
Lynne's Pico
owner

44. Phil's Pico Tom's Pico
owner
Lynne's Pico
owner

45. Phil's Pico Tom's Pico
owner
Lynne's Pico
owner
borrower

46. Domain-Specific Languages

48. devices standardsidentityAPIsprotocols

49. devices standardsidentityAPIsprotocols
architecture

50. devices standardsidentityAPIsprotocols
architecture
framework

51. devices standardsidentityAPIsprotocols
architecture
framework
notation

55. Events vs Requests

56. “this happened”
vs
“do this”

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

60. Web
Application
Application
Data
Browser

61. Web
Application
Application
Data
Browser

63. Vehicle's
Pico
iCalendar
Web
Mobile

64. Rather than a model
where a system
presents an API for
a collection of
resources….

65. Rather than a model
where a system
presents an API for
a collection of
resources….
Picos present a
model wherein each
pico presents it’s
own, customizable
API

67. CloudOS
• Pico Lifecycle
• Subscriptions
• Ruleset management
• Notifications
• Files

69. KRL

70. Event-Condition-Action
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 initial_carvoyant_subscriptions;
}
}

71. Event-Condition-Action
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 initial_carvoyant_subscriptions;
}
}

72. Event-Condition-Action
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 initial_carvoyant_subscriptions;
}
}

73. Event-Condition-Action
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 initial_carvoyant_subscriptions;
}
}

74. Event-Condition-Action
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 initial_carvoyant_subscriptions;
}
}

75. select when
web pageview re#/support/(d+)#
setting(issue_number)
before (phone inboundcall or
email received
subj.match(re#issue_number#)
)

76. select when
web pageview re#/support/(d+)#
setting(issue_number)
before (phone inboundcall or
email received
subj.match(re#issue_number#)
)
1
2
3

77. select when
web pageview re#/support/(d+)#
setting(issue_number)
before (phone inboundcall or
email received
subj.match(re#issue_number#)
)
1
2
3

78. Persistent Variables
rule name_trip {
select when fuse trip_name
pre {
tid = mkTid(event:attr("tripId"));
tname = event:attr(“tripName”).defaultsTo(“”, “no trip name”);
tcategory = event:attr(“tripCategory”).defaultsTo(“”, “no trip category”);
trip = ent:trip_summaries{tid}.defaultsTo({});
start = reducePrecision(trip{"startWaypoint"});
end = reducePrecision(trip{"endWaypoint"});
}
if(not trip{"startWaypoint"}.isnull() && not trip{"endWaypoint"}.isnull()) then
send_directive("Named trip") with
tripId = tid and
start = start and
end = end;
fired {
set ent:trip_names{[end, start]} mkTripMeta(tname, tcategory);
}
}

79. Persistent Variables
rule name_trip {
select when fuse trip_name
pre {
tid = mkTid(event:attr("tripId"));
tname = event:attr(“tripName”).defaultsTo(“”, “no trip name”);
tcategory = event:attr(“tripCategory”).defaultsTo(“”, “no trip category”);
trip = ent:trip_summaries{tid}.defaultsTo({});
start = reducePrecision(trip{"startWaypoint"});
end = reducePrecision(trip{"endWaypoint"});
}
if(not trip{"startWaypoint"}.isnull() && not trip{"endWaypoint"}.isnull()) then
send_directive("Named trip") with
tripId = tid and
start = start and
end = end;
fired {
set ent:trip_names{[end, start]} mkTripMeta(tname, tcategory);
}
}

80. Persistent Variables
rule name_trip {
select when fuse trip_name
pre {
tid = mkTid(event:attr("tripId"));
tname = event:attr(“tripName”).defaultsTo(“”, “no trip name”);
tcategory = event:attr(“tripCategory”).defaultsTo(“”, “no trip category”);
trip = ent:trip_summaries{tid}.defaultsTo({});
start = reducePrecision(trip{"startWaypoint"});
end = reducePrecision(trip{"endWaypoint"});
}
if(not trip{"startWaypoint"}.isnull() && not trip{"endWaypoint"}.isnull()) then
send_directive("Named trip") with
tripId = tid and
start = start and
end = end;
fired {
set ent:trip_names{[end, start]} mkTripMeta(tname, tcategory);
}
}

81. persistent variables (cont)
ent:trips -> {“39.369,-111.456” : {“39.034,-110.915”: {“name” : “home/school”,
“category” : “other”}},
“40.010,-111.456” : {“39.144,-112.324”: {“name” : “doctor’s office”,
“category” : “medical”}},
…
}

82. persistent variables (cont)
tripMeta = function(start, end) {
ent:trip_names{[reducePrecision(end), reducePrecision(start)]}
}

83. tripsByDate = function(start, end){
utc_start = common:convertToUTC(start);
utc_end = common:convertToUTC(end);
ent:trip_summaries.query([], {
'requires' : '$and',
'conditions' : [
{ ‘search_key' : [ 'endWaypoint', 'timestamp'],
'operator' : '$gte',
'value' : utc_start
},
{ 'search_key' : [ 'endWaypoint', 'timestamp' ],
'operator' : '$lte',
'value' : utc_end
}
]},
‘return_values’)
};
persistent variables (cont)

84. tripsByDate = function(start, end){
utc_start = common:convertToUTC(start);
utc_end = common:convertToUTC(end);
ent:trip_summaries.query([], {
'requires' : '$and',
'conditions' : [
{ ‘search_key' : [ 'endWaypoint', 'timestamp'],
'operator' : '$gte',
'value' : utc_start
},
{ 'search_key' : [ 'endWaypoint', 'timestamp' ],
'operator' : '$lte',
'value' : utc_end
}
]},
‘return_values’)
};
persistent variables (cont)

85. rulesets

87. pico engine
(kre)

88. Pico container is
implemented as
Apache module in
Perl

89. We’ve got both kinds:C & Perl!

90. Open standards
Open source
http://github.com/kre

91. Picos Support A Familiar Model
Kynetx Rules Engine
Other
Data
Sources
Web
Services
APIs
Rulesets
Persistent
Data
APIs
engine

92. Picos Support A Familiar Model
Kynetx Rules Engine
Other
Data
Sources
Web
Services
APIs
Rulesets
Persistent
Data
APIs
engine
Persistent Compute Object
containers

93. Picos Support A Familiar Model
Kynetx Rules Engine
Other
Data
Sources
Web
Services
APIs
Rulesets
Persistent
Data
APIs
engine
Persistent Compute Object
containers
CloudOS
Configuration
Management
CloudOS
Service
Notification
Service
PersonalData
Service
UISupport
File
Social
Social
Fuse
Library
Guard
Tour
Library
libraries

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

95. Picos Are Decentralized & Networked
pico
pico
Hosting
Space
Pico
Space
Hosting
Company A
Hosting
Company B
Self
Hosted
pico
pico
pico
pico
pico
pico
pico
KRE KRE KRE
Pico
Containers

96. Apache as an
Application Server

97. Modules are NOT CGI Programs
• Modules run inside the Apache process architecture
• Modules have access to and can replace all Apache services
• Uses the server API - not an embedded interpreter
• Access to every part of the HTTP request lifecycle

98. Apache Server
Lifecycle

99. Apache HTTP
Request Lifecycle

100. Apache Application Services
• Configuration
• Process and thread management
• Security
• Logging
• Interprocess communication
• Request dispatching

101. Implementation
• LOTS of libraries (~90)
• Any::Event
• DateTime
• Data::Diver
• Cache::Memcached
• WWW::Mechanize
• Test::More
• Parser
• Operators

102. • Good support for shards
• Documents are JSON
• Capped collections
• TTL indexes

103. wait
decode
event
schedule
rules
eval
rules
assemble
response
receive
event
explicit
event
directive
document
schedule
object
javaScript or
JSON
event
object
Pico Event Evaluation Cycle
event
directives
API interactions
external events

104. wait
decode
event
schedule
rules
eval
rules
assemble
response
receive
event
explicit
event
directive
document
schedule
object
javaScript or
JSON
request
env
Pico Event Evaluation Cycle
with container actions
event
directives
API interactions
external events
establish
context event
object
establish identity
load rulesets (parse/optimize)
calculate RIDs
calculate salience graph

105. Quickstart
http://developer.kynetx.com

107. Lessons Learned
• Understand language feng shui
• Parsing
• Don’t optimize too early
• Orthoganility
• Breadth first
• Languages evolve
• Leverage underlying language
• Build the language you want to
use
• Use your language
• Picos are a decent abstraction

109. Implementing a Rule Language
for the Internet of Things
Phil Windley
pjw@byu.edu
www.windley.com
@windley
windley