Pittsburgh
28 de January
2010
escrito por Mario Berges

This is the first post in English in this blog. Let’s see if it works out.

Sensor Andrew, one of the projects I’ve been working on for the past two years, is an experiment on the interoperability and semantic capabilities of cyber-physical systems. In essence, it’s a collection of hardware and software elements that together form a virtual instrument for large-scale sensing and actuation. But I don’t want to spend time explaining it. The interested reader can refer to our webpage or the techincal report.

What I do want to talk about is the relative ease with which new applications, that make use of the available sensor data, can be created.

Today, for example, I decided to write a simple program that would notify me via e-mail if a sensor has stopped reporting for longer than it should. This is a farily common problem as you may expect. There were two ways I could think of easily implementing this. But before I describe them, let me first provide you with a little bit of context.

The Energy Detective (TED)Sensor Andrew allows any sensor or actuator that can be connected to an Internet-enabled computing device, to be discovered, shared and re-used. That is the basic principle. The best way to explain it, however, is by using an example. Let’s say you just purchased a new home energy meter like “The Energy Detective” (TED). You notice that the display has a USB port on the side, and you wonder if you can use it to access the data and play with it. You go to the Sensor Andrew website, look for the available software adapters (code that is created for this purpose, using our libraries) trying to find if someone has created one for the TED. You find an adapter that fits your operating system and hardware, and proceed to set it up. After registering your sensor with Sensor Andrew (which involves creating an account, describing the sensor’s make and model, the update rate, its location, what it is measuring, etc.) you are given a unique identifier which you will use when publishing data, and an “Event-Node” to which the sensor will be publishing. The event node will be something like “myTED@sensor.andrew.cmu.edu”.

To make the long story short, you can now configure the adapter you downloaded with the information you were given (account, Event-Node, etc.), connect the TED to your computer using a USB cable, and run it. The data from your TED will be periodically published, using a standard XML format, to an internet-addressable resource (the event-node myTED@sensor.andrew.cmu.edu). Behind the scenes, Sensor Andrew is leveraging the eXtensible Messaging and Presence Protocol (XMPP), which you have most probably used even without realizing it. XMPP is the backbone of Google Talk, for example. More especifically, we created a Sensor Over XMPP (SOX) library, that uses the XMPP PubSub (publish and subscribe) protocol extension for this purpose.

I think that this may be enough context. Let me return to the main point of this post. So, now imagine that for some reason your sensor data stops being published. What do you do? How can you tell? Given that any user with appropriate permissions can subscribe to myTED@sensor.andrew.cmu.edu, we can create a simple software agent that subscribes to this event-node, and notifies the user if there has been no message published in the last x minutes. The SOX library, in this case the C library, will help us do this by using only a few functions, namely:

1) Creating the connection:

xmpp_connection = start_xmpp_client (username,
                  password,
                  xmpp_server,
                  xmpp_server_port,
                  xmpp_ssl_fingerprint, pubsub_server, NULL);

2) Subscribing to the event-node:

subscribe_to_node(xmpp_connection, event_node);

3) Then parsing the incoming XML in some way (using expat here), to catch a significant change in timestamps that may indicate a fault, and then trigger an alarm:

static void XMLCALL startElement(void *data,
                  const char *element_name,
                  const char **attr) {

...

   if(strcmp(element_name,"TransducerValue")==0) {
    for(i=0;attr[i];i+=2) {
      const char* attr_name = attr[i];
      if(strcmp(attr_name,"timestamp")==0)
        sensor_timestamp = attr[i+1];
    }

    timestamp_sec_new = convert_to_seconds(sensor_timestamp); 

    if(timestamp_sec_old) {
      if(timestamp_sec_new - timestamp_sec_old > typical_interval)
         alarm(event_node, email);
    }

    timestamp_sec_old = timestamp_sec_new;

    ...

}

Obviously I am ommitting some of the details, and the code is not at all commented, but I guess you can get the point. The alarm function will basically send out an e-mail informing me that my event-node has stopped publishing for longer than the typical_interval.


Etiquetas: ,

blog comments powered by Disqus