A few weeks ago I could manage to deliver a surprisingly good presentation at BT labs in Ipswitch. OGC's standards which I explained in one of my posts much earlier are actually quite good in order to provide a generic way of communication for sensors in general. But the primary issue is how to integrate those standards into resource-constraint sensors.
Apart from the operating system that I personally think is meaningless when it comes to sensors, middlware has to be mainly in charge of all processing and activities within sensor platforms.
Now, what makes it more challenging is the fact that OGC's standards and middleware have to be combined together, with all those limitations in mind, regardless of the hardware specifications.
What I proposed was, instead of having all the standards together in one layer, they can be split into two categories.
This in fact sounds quite awkward and not doable, but with a bit of brain storming you'll be convinced of its feasibility.
let's get cracking:
There are seven types of encoding for the SWE standards.
1. O&M
2. SensorML
3. TML
4. SOS
5. SPS
6. SAS
7. WNS
The upper three are the descriptive XML-based encoding that deal with sensors or transducers directly. Since these three don't take much processing, they can be done within the framework of my proposed middleware. The lower four are standard web services and they make it very inconvenient for the middleware to deal with these concurrently.
Therefore the upper three are in one layer and the lower ones in another.
The abstract design of my middleware looks like the above figure.
