Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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