Here at Sense PlaNet, we like to share ideas about architecture that can help lump together wireless sensors with web technologies.
Lately, we’ve been working on a data aggregating services that allows our wireless sensors to communicate easily with social networks such as Facebook and Twitter ( similar to a service like Ping.fm, but for sensors)
This prototyping has led to a modular design to support future social networks as well as other output streams ( messaging, RSS, … )
For that matter, the plugin architecture with a RESTFul API has been deemed to be the most relevant. Please refer below for a high-level design:
socialEnergy: a service design
By relying on this architecture, we could tie each sensor to a list of social networks with which to interact.
The unique identifier to differentiate each sensor is the MAC address.
The web services client should be running either on the sensor or ported out on the smart home gateway ( refer to previous post ).
The plugin interface translates the data coming from the sensor into 3rd party API calls.
The work queue can be simply a Java messaging system.
Overall, this design enables social capabilities to sensor network. More importantly, the system can roll out new plugins without impacting the software running on the sensor side.
NOTE: You can see how the admin page of our server looks like here: socialgrid.senseplanet.com
Hi there,
I see one problem here but maybe that’s only becauseI tend to be a security freak: anyone can spoof the MAC address of your sensor and contact the WebServices API to upload false information.
I would say that you really need to include some security at the very beginning of the design. Maybe a simple shared secret between a sensor and the WS API (a simple authentication for instance)
Again, I’m a security freak these days ;o) See ya!
yep, you’re right!…What kind of authentification tool do you recommend..ideally one that is easy to ramp up with? OAuth?
I’m not that familiar with any authentication tool or framework but basically there are two ways of doing it: at application level or at transport level.
At application level, you can have a front authentication module that rely on local user directory (a file, a SQL table, an LDAP directory roughly depending on the volume of users and requests). On a Tomcat (or a J2EE App Server) that’s a filter you had in the configuration, on a PHP server, that is a check to include at the begginning of all pages requiring authentication.
At transport level, you use SSL client authentication to encapsulate your HTTP flow and yay! that becomes HTTPS, you can then benefit from a encrypted connection to enable confidentiality over your data.
Hi,
2 cents here:
- transport-specific security in case devices do not have directly http or ip for that matter on board. This can rely on bluetooth/zigbee mecanisms, but then gateways need to know about each device specifically…
- the encryption on embedded devices, sensor nodes have very limited cpu, so i see complex encoding quite heavy to be computed each time, especially when this happens at a the app level.
An option would be to have a second chip that takes care only of computing the encoding…
anyway, I’m not an expert here, so I can’t say what’s best, but it’s just a matter of adding the limited cpu in the security vs. algo complexity tradeoff.
oh there is this though…
http://research.microsoft.com/en-us/um/people/zhao/pubs/secureTWS_IPSN09.pdf
voilà
At application level, you can have a front authentication module that rely on local user directory (a file, a SQL table, an LDAP directory roughly depending on the volume of users and requests). On a Tomcat (or a J2EE App Server) that’s a filter you had in the configuration, on a PHP server, that is a check to include at the begginning of all pages requiring authentication.
+1