Web Services for Intelligent Devices
Download
Report
Transcript Web Services for Intelligent Devices
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