«Carles Gómez Josep Paradells José E. Caballero Edita: Fundación Vodafone España Autores: Carles Gómez Montenegro* Universitat Politècnica de ...»
Data collected by sensors can be sent directly to a sink node or to any neighbour in order to process the data from different sources. To save battery and bandwidth, it is convenient to minimise the number of data transmissions41, although this approach may come at the expense of losing capacity to detect any change in the parameters monitored by the WSN. This can be done by comparing the data from different sensor nodes in order to avoid errors or reinforce decisions by sending only relevant data to the sink node. It is also possible to bring the data from different sources together and send them using one single transmission. Some of these optimisations can only be done once the data are processed, which requires application processing at the sensor node.
Note that such intermediate nodes will generally exist in typical deployments.
Chapter 14 shows how local data processing in sensor nodes is preferred rather than data transmissions in order to save energy consumption.
Full categorized data can be stored efficiently in a database (to minimize storage capacity and facilitate data correlation).
This chapter is devoted to WSN data management and encoding. Section
12.1 discusses in-network collaboration storage management techniques.
Section 12.2 focuses on semantic mechanisms to describe the attributes of data collected by a sensor network. Section 12.3 describes a standardisation initiative called “Sensor Web” aiming to provide enhanced descriptions and meaning to sensor data in a broad sense, and facilitating the transport through the Internet. Finally, Section 12.4 gives an overview of the IEEE 1451, a family of standards which includes syntax and semantics for the information exchange between different transducers and a central information system.
12.1. In-network storage management
Sensor network applications exist in which sensed information is not collected in real time. In such applications, the data must be (temporarily) stored within the network and used in response to queries performed by an
observer. Some example applications include :
• Offline monitoring: sensors are deployed to collect detailed information about a phenomenon for later playback and analysis. One example of this kind of application is ZebraNet, where sensors are attached to animals .
• Dynamic augmented reality42: in this type of application, the sensors store data about ongoing events. The data is dynamically queried by users within the network.
In such applications, the data must be stored in the network. The size of the overall data to be stored can be reduced if neighbour nodes collaborate.
Augmented Reality refers to the improvement of certain reality aspects by a combination of “virtual” and real elements. “Virtual” elements are those created on the basis of the sensor data collected from the real environment in order to complement the user perception with extra information. This technology aims at boosting user experience.
Chapter 12. Sensed data management
In addition, the storage can be loadbalanced among collaborating nodes.
Two approaches are possible :
• Aggregation43: neighbouring sensors can exploit the spatial correlation of data to reduce the overall size of the stored data. Data exchange between neighbours is needed.
• Coordination for redundancy control. Coordination between neighbours may allow the redundancy of data sampled to be estimated.
Several collaborative storage protocols are presented in . These protocols are variants of the two protocols mentioned next. The first one is the Cluster Based Collaborative Storage (CBCS) protocol, in which clusters are formed and the cluster head is in charge of receiving the observations of sensors within the cluster and of performing data aggregation and storage.
The second is the Coordinated Local Storage (CLS), where the sensors coordinate periodically and adjust their sampling schedules to reduce the overall redundancy.
In the context of real-time monitoring sensors, aggregation is one of the main techniques applied [3, 4].
12.2. Data interpretation
Sensors encoding of observed phenomena are by nature opaque (often in binary or proprietary formats). Hence, metadata play an essential role in managing sensor data. A semantically rich WSN would provide spatial, temporal and thematic information essential for discovering and analyzing sensor data . These metadata may also be added to the data obtained from sensors once the data have been transmitted through the WSN and received by database or tagging equipment.
Aggregation is defined as any kind of operation performed over a set of data, which leads to a result obtained by taking into consideration the whole set of data.
It is interesting to handle complex data for either processing the data in the network or for storing the information in a central data base. There exist several efforts aimed at providing protocols for exchange of complex structured data information capable of adding enhanced descriptions and meaning to sensor data. One set of protocols are adaptations of the eXtensible Markup Language (XML), the de facto standard for data format to exchange structured information over the Web. These are discussed in subsection 12.2.1. One such example is the Extended Environments Markup Language (EEML), which is introduced in section 12.2.2. A standardisation initiative is carried out by the Open Geospatial Consortium (OGC) , which has developed an enhanced data encoding format also based on XML for metadata description of sensors, called SensorML, which makes any sensor device discoverable and accessible by using a common mechanism. This is presented in subsection 12.2.3.
Finally, the NIST has recently created the Harmonization of Sensor Standards Working Group  in order to develop a common sensor ontology based on data formats of sensors domain, including IEEE 1451 , ANSI N42.42  and CBRN data model , among others.
12.2.1. Use of XML in WSNs
A highly exchangeable and extensible data format is XML, which has become the facto standard for data format for exchanging structured information over the Web. The usage of XML in WSNs may solve the problem heterogeneity and information coding.
Due to the limited resources on sensor nodes, native XML support is not offered. Several proposals tend to simplify the processing and transmission of XML coded data in nodes. This can be achieved with efficient XML compression  or by preparing the software of the node to be optimised for processing XML .
Compact data encodings based on XML have been defined. The W3C specified Efficient XML Interchange (EXI) , a very compact representation for XML information. EXI allows for a simple mode of operation called schema-informed mode, which is suitable for severely con
strained devices. Binary XML (BXML) has also been defined . The main drawback of these kinds of compressed formats is that they may require more resources, in terms of memory and CPU, than the processing of the XML file itself.
EEML  is an XML-based protocol that describes sensors (and actuators) data collected in a structured form. It can be used to facilitate direct connections between any two environments. For example, it has been implemented in the Pachube44 web service , to facilitate many-to-many connections. EEML is in fact a markup language that describes the data output of sensors and actuators according to its geospatial position.
Members of the Open Geospatial Consortium (OGC) have defined a standard XML encoding scheme called Sensor Model Language (SensorML) for metadata describing sensors, sensor platforms, sensor tasking interfaces as sensor generated data. The objective of this initiative is to make any sensor device (from a flood gauge to a heart monitor or a web cam) discoverable and accessible using a common mechanism. As the proposal is originated by OGC, geolocation of the sensor measurements is a key functionality.
Furthermore, ease in publishing the sensor data on a web is also a design objective.
SensorML provides a complete description of the sensor capabilities and gives information on how to process and locate the measured data. It also provides performance characteristics (e.g. accuracy) and facilitates the archiving of the information. Fig. 12.1 shows an example of a sensor using SensorML.
Pachube is a web service that enables people “to connect, tag and share real time sensor data from objects, devices, buildings and environments around the world” .
Fig. 12.1. Example of the SensorML description of a sensor  SensorML uses XML, which is a verbose description language. An example of the coding is provided in Fig. 12.2.
Fig. 12.2. Response Example – YSI45 Wind Speed Sensor  YSI is a developer and manufacturer of sensors, instruments, software, and data collection platforms for environmental monitoring and testing [http://www.ysi.com/]
12.3. Sensor Web The Sensor Web initiative has been created by the OGC and the Semantic Web Activity of the World Wide Web Consortium (W3C) to provide enhanced descriptions and meaning to sensor data and facilitate transport through Internet . In this way, the Sensor Web facilitates access to sensor information and the usage of the information for a different purpose than that originally foreseen. Remarkably, the Sensor Web initiative deals with sensors in a broad sense. For example, complex systems such as satellites are considered as sensors. Note that such a device does not match the characteristics of the nodes making up the WSNs that fall within the scope of this book.
The OGC has established the Sensor Web Enablement (SWE) in order to address the lack of standardization by developing a suite of specifications related to sensors, sensor data models, and sensor Web services that will make sensors accessible and controllable via the Web. This suite includes three types of coding: Observation and Measurement (O&M), Sensor Model Language (SensorML) and Tranducer Model Language (TransducerML). The suite also has four services: Sensor Observation Service (SOS), Sensor Planning Service (SPS), Web Notification Service (WNS) and Sensor Alert Service (SAS).
Formal definitions of the semantics of information are captured in ontologies, making it possible for machines to interpret and relate data content more effectively . The semantic web employs the Resource Description Framework (RDF)  data representation model, the ontology representation languages RDF Schema and the Web Ontology Language (OWL).
12.4. IEEE 1451
The IEEE 1451 is a standard that was not developed with the aim of creating data representation for sensor information. Rather, it tries to facilitate the connectivity of different transducers (sensors or actuators) to a central information system. In support of this, IEEE 1451 has defined a syntax and semantics. The IEEE 1451 also supports remote connectivity, although the main interest of the standard lies in the data encoding.
The integration of a processing unit, a communication interface and a digital or analog sensor or actuator results in a smart transducer. In response to the industry need for a set of sensor interfaces, the IEEE has sponsored the development of IEEE 1451, a suite of standard smart transducer interfaces for sensors and actuators. IEEE 1451 smart transducers have capabilities for self-identification, self-description, self-diagnosis, self-calibration, location awareness, time-awareness, data processing, data fusion, alert notification, standard format presentation and communication protocols. To provide all these functionalities, the smart transducer architecture is divided into modules and interfaces (see Fig. 12.3).
Fig. 12.3. Smart Transducer model with modules and interfaces 
The architecture presented in IEEE 1451 is designed to facilitate the connection of the transducer with the application processor and with a central element through the network. The Transducer Interface Module (TIM) performs signal conditioning and data conversion, and is able to connect up to 255 transducers.
The Transducer Independent Interface (TII) defines the communication medium and the protocol for transferring the information to the application processor
Chapter 12. Sensed data management
located at the Network Capable Application Processor (NCAP). The TII provides a set of commonly used operations, such as read, write and responses.
A key aspect of the IEEE 1451 is the standardisation of the Transducer Electronic Data Sheets (TEDS). The TEDS represents information about the transducer stored in ROM or EEPROM (depending on whether the information can change or not) that enables the specifications of the transducer to be known electronically.
IEEE 1451 defines three possible ways to access sensors and actuators
from a network:
• IEEE 1451.1. The IEEE 1451.1 defines the information model for smart transducers , including the syntax and semantics for the information exchange.
• Using the Hyper Text Transfer protocols defined in IEEE 1451.
• Using some type of Web service.
The physical interfaces between the NCAP and the TIM cover the following options:
• Point to point interface according to IEEE 1451.2.
• Distributed multi-drop interface defined in IEEE 1451.3.
• Wireless interface (WiFi, Bluetooth and ZigBee) as defined in IEEE 1451.5.
The IEEE 1451.5 defines the communication between TIM and NCAP using wireless specific protocols. It defines the usage of IEEE 802.11 (WiFi), IEEE 802.15.
1 (Bluetooth), and ZigBee and 6LoWPAN for using IEEE 802.15.4. Different wireless protocols can be used to talk with one NCAP.