Download Web Services for Intelligent Devices

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
Bringing it All Together: Embedded Services Platform
Developers: Joshua Kwan <[email protected]> and Matt Jones <[email protected]>
Justification
SML - The Service Model Language
 We recognized that every one of our embedded projects
exported a set of useful functions (accessors and mutators)
 What if we made it easy to harvest the functionalities of any
number of motes at once?
 What if we wanted to easily access data on a mote to perform
complex post-processing on the numbers using a real PC?
 The answer: a service model that provides a programmatic,
master-slave relation between PC and motes
 All communication is encapsulated in an XML schema called
SML (Service Model Language)
 SML provides for three response models
 IDENTIFY: Provides function manifest in response
 GET: Functions that retrieve data (returns ‘read response’)
 SET: Functions that actuate device components and
mutate mote data or behavior (returns ‘write response’)
“ASSOCIATE” (UDP)
Mote asks to register with master
Overview
 Python-based UDP/TCP/HTTP aware server that allows any
mote to ‘register’ with it with a UDP protocol
 Server asks for and mote sends a ‘manifest’ containing all the
services it provides (GET functions and SET functions)
 Server collects all these manifests and allows user to write a
plug-in that controls all the motes at once using the power of
Python
“MASTER” (UDP)
Master confirms registration
REST call: “identify” (SML/TCP)
Master downloads function manifest
Embedded Mote
(e.g. coffee pot, toaster,
kitchen sink, etc.
Now the server can control the mote
over REST/HTTP using all of its
exposed functions!
Server
(Running our Python code)
SML Example - Coffee Pot Project
Identify
Read Response (int)
<sml>
<idrsp>
<set>
<cmd name="hotplate" args="1"
arg1="bool" />
<cmd name="boiler" args="1" arg1="bool" />
</set>
<get>
<cmd name="hotplatepower" args="0"
returns="bool" />
<cmd name="boilerpower" args="0"
returns="bool" />
<cmd name="coffeetemperature" args="0"
returns="int" />
<cmd name="coffeevolume" args="0"
returns="int" />
<cmd name="tankvolume" args="0"
returns="int" />
</get>
<shortname>coffeepot</shortname>
<name>Coffee on Rails</name>
<api>1</api></idrsp>
</sml>
<sml>
<rdrsp>
<status type=”int”
source=”temperature”>30</status></rdrsp>
</sml>
Write Response (bool)
<sml>
<wtrsp>
<status type=”bool”
source=”hotplate”>true</status></wtrsp>
</sml>
Example uses of our service model
 One day, most household electronics could be networked
together using Bluetooth, LoWPAN, etc.!
 Bob drives home from work and the proximity of his car to the
garage triggers the opening of the door
 The opening of the garage is noticed by the coffee pot, which
starts brewing coffee, and the television, which switches to
Bob’s favorite channel
 The lighting of his living room is regulated by a sensor mote
that sets it depending on the ambient outside light.
 His computer notices he’s home and preloads all the web
pages he usually visits.
 If all these devices were internetworked like what you see
today, all this could in theory be orchestrated by a single
Python plugin to our service model in something like 300 lines
of code.
1