Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Rule Language for IoT

1,237 views

Published on

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

Published in: Internet
  • Be the first to comment

Rule Language for IoT

  1. 1. Implementing a Rule Language for the Internet of Things Phil Windley Office of the CIO Brigham Young University
  2. 2. The great question (about power) is who should have it.
 – John Locke
  3. 3. The Web (circa 1996)
  4. 4. Client Space Server Space Google FacebookiCloud Web 2.0
  5. 5. Client Space Server Space Google FacebookiCloud Web 2.0
  6. 6. Client Space Server Space Google FacebookiCloud Web 2.0
  7. 7. So long as we are merely clients of servers, we cannot be independent
  8. 8. Internet of Things
  9. 9. Lorem Ipsum Dolor
  10. 10. But it’s bigger than that… Everything will have an online representation.
  11. 11. But it’s not just about manufactured things...
  12. 12. What will its architecture be?
  13. 13. Trillion node networks
  14. 14. Imagine a mountain representing today’s billion node network...
  15. 15. Lorem Ipsum Dolor From Trillions by Maya Design
  16. 16. From Trillions by Maya Design
  17. 17. The Current IoT Model Won’t Scale
  18. 18. Me
  19. 19. Me
  20. 20. GE
  21. 21. Internet of My Things Me GE
  22. 22. • decentralized • heterarchical • interoperable
  23. 23. 1. Distributed transaction processing and applications 2. Peer-to-peer messaging and sharing 3. Autonomous coordination and contracts between peers
  24. 24. picos
  25. 25. 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.
  26. 26. http://joinfuse.com
  27. 27. Owner Pico Fleet Pico Vehicle Pico Vehicle Pico Vehicle Pico
  28. 28. Owner Pico Fleet Pico Vehicle Pico Vehicle Pico Vehicle Pico Owner Pico
  29. 29. Phil's Pico owner
  30. 30. Phil's Pico owner Lynne's Pico owner
  31. 31. Phil's Pico Tom's Pico owner Lynne's Pico owner
  32. 32. Phil's Pico Tom's Pico owner Lynne's Pico owner
  33. 33. Phil's Pico Tom's Pico owner Lynne's Pico owner
  34. 34. Phil's Pico Tom's Pico owner Lynne's Pico owner borrower
  35. 35. Domain-Specific Languages
  36. 36. devices standardsidentityAPIsprotocols
  37. 37. devices standardsidentityAPIsprotocols architecture
  38. 38. devices standardsidentityAPIsprotocols architecture framework
  39. 39. devices standardsidentityAPIsprotocols architecture framework notation
  40. 40. Events vs Requests
  41. 41. “this happened” vs “do this”
  42. 42. Event System Properties • Events are autonomous • Event-driven system are more loosely coupled • Downstream (receiver) driven flow control • Near real-time propagation
  43. 43. Web Application Application Data Browser
  44. 44. Web Application Application Data Browser
  45. 45. Vehicle's Pico iCalendar Web Mobile
  46. 46. Rather than a model where a system presents an API for a collection of resources….
  47. 47. 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
  48. 48. CloudOS • Pico Lifecycle • Subscriptions • Ruleset management • Notifications • Files
  49. 49. KRL
  50. 50. 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; } }
  51. 51. 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; } }
  52. 52. 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; } }
  53. 53. 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; } }
  54. 54. 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; } }
  55. 55. select when web pageview re#/support/(d+)# setting(issue_number) before (phone inboundcall or email received subj.match(re#issue_number#) )
  56. 56. select when web pageview re#/support/(d+)# setting(issue_number) before (phone inboundcall or email received subj.match(re#issue_number#) ) 1 2 3
  57. 57. select when web pageview re#/support/(d+)# setting(issue_number) before (phone inboundcall or email received subj.match(re#issue_number#) ) 1 2 3
  58. 58. 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); } }
  59. 59. 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); } }
  60. 60. 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); } }
  61. 61. 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”}}, … }
  62. 62. persistent variables (cont) tripMeta = function(start, end) { ent:trip_names{[reducePrecision(end), reducePrecision(start)]} }
  63. 63. 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)
  64. 64. 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)
  65. 65. rulesets
  66. 66. pico engine (kre)
  67. 67. Pico container is implemented as Apache module in Perl
  68. 68. We’ve got both kinds:C & Perl!
  69. 69. Open standards Open source http://github.com/kre
  70. 70. Picos Support A Familiar Model Kynetx Rules Engine Other Data Sources Web Services APIs Rulesets Persistent Data APIs engine
  71. 71. Picos Support A Familiar Model Kynetx Rules Engine Other Data Sources Web Services APIs Rulesets Persistent Data APIs engine Persistent Compute Object containers
  72. 72. 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
  73. 73. 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
  74. 74. 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
  75. 75. Apache as an Application Server
  76. 76. 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
  77. 77. Apache Server Lifecycle
  78. 78. Apache HTTP Request Lifecycle
  79. 79. Apache Application Services • Configuration • Process and thread management • Security • Logging • Interprocess communication • Request dispatching
  80. 80. Implementation • LOTS of libraries (~90) • Any::Event • DateTime • Data::Diver • Cache::Memcached • WWW::Mechanize • Test::More • Parser • Operators
  81. 81. • Good support for shards • Documents are JSON • Capped collections • TTL indexes
  82. 82. 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
  83. 83. 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
  84. 84. Quickstart http://developer.kynetx.com
  85. 85. 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
  86. 86. Implementing a Rule Language for the Internet of Things Phil Windley pjw@byu.edu www.windley.com @windley windley

×