D2.3 EnviroGRIDS sensor data use and integration guideline

enviroGRIDS – FP7 European project
Building Capacity for a Black Sea Catchment
Observation and Assessment supporting Sustainable Development

EnviroGRIDS sensor data use and integration guideline

Title EnviroGRIDS sensor data use and integration guideline
Creator Karel Charvat (CCSS)
Creation date 01.09.2009
Date of revisions 1.09.2009: G. Giuliani
13.09.2009: K. Charvat
11.10.2009: A. Lehmann
1.11.2009: N. Ray
Subject Sensors, Sensors Network, Data transition, Interoperability, Spatial Data
Infrastructure, Standards.
Status Validated
Type Word document
Description Guideline explaining how in situ data could be collected, what are the
sensors, network and how the sensor measurement could be integrated
into SDI
Contributor(s) Karel Charvat, Jan Jezek, Marek Musil, Zbynek Krivanek
Rights Public
Identifier EnviroGRIDS sensor data use and integration guideline (D.23)
Language English
Relation EnviroGRIDS interoperability guideline (D.21)
EnviroGRIDS data storage guideline (D.22)
EnviroGRIDS remote sensing data use and integration guideline (D.24)

Abstract
The document describes current state-of-the-art in sensor technologies, Wireless Sensor Network and Web
Sensor. It also analyses different solutions to integrate sensor measurements into Grid-enabled Spatial Data
Infrastructures (GSDI).

-1-


Content

ENVIROGRIDS SENSOR DATA USE AND INTEGRATION GUIDELINE ............................................................. 1
1 EXECUTIVE SUMMARY ........................................................................................................................... 5
2 INTRODUCTION ...................................................................................................................................... 7
2.1 THE ENVIROGRIDS PROJECT .............................................................................................................................. 7
2.2 WP2: GRID-ENABLED SPATIAL DATA INFRASTRUCTURE ..................................................................................... 7
2.3 TASK 2.3: SENSOR DATA INTEGRATION ............................................................................................................... 7
2.4 SCOPE AND PURPOSE OF THIS DELIVERABLE......................................................................................................... 8
2.5 THE ROLE OF SENSOR MEASUREMENT IN SDI ...................................................................................................... 8
2.6 THE UNIFORM RESOURCE MANAGEMENT (URM) GEOPORTAL ........................................................................... 9
3 SENSORS AND SENSOR NETWORKS ...................................................................................................... 10
3.1 SENSORS........................................................................................................................................................... 10
3.2 WIRELESS SENSOR NETWORK ........................................................................................................................... 11
3.2.1 Principles .................................................................................................................................................. 11
3.3 WINSOC APPROACH .......................................................................................................................................... 12
3.4 WIRELESS SENSOR TECHNOLOGY COMPANIES ................................................................................................... 12
3.5 VLIT NODE TECHNOLOGY ............................................................................................................................... 13
4 SENSOR WEB ........................................................................................................................................ 13
4.1 WHAT IS THE SENSOR WEB? ............................................................................................................................. 13
4.2 SENSORS WEB ENABLEMENT ............................................................................................................................ 13
4.3 EXISTING IMPLEMENTATION OF SWE [12] ........................................................................................................ 14
4.3.1 NASA........................................................................................................................................................ 14
4.3.2 Northrop Grumman’s PULSENet ............................................................................................................. 14
4.3.3 SANY Sensors Anywhere ......................................................................................................................... 15
4.3.4 52 North .................................................................................................................................................... 15
4.3.5 HMA in Europe......................................................................................................................................... 15
4.3.6 Web Services for Unified Access to U.S. Hydrologic Data ...................................................................... 15
4.3.7 Support of Sensor Observation Service in MapServer [13]....................................................................... 16
4.4 CCSS IMPLEMENTATION................................................................................................................................... 16
4.4.1 Sensor Observation Service ...................................................................................................................... 16
5 A GAP BETWEEN SENSOR TECHNOLOGIES AND SENSOR WEB .......................................................... 17
5.1 WHAT IS THE GAP BETWEEN THE SENSOR WEB AND THE SENSOR TECHNOLOGY? .............................................. 17
5.2 HOW COULD WE FILL THE GAP BETWEEN THE SENSORS WEB AND THE SENSOR TECHNOLOGY? - THE CCSS
SOLUTION ................................................................................................................................................................... 17

6 RECOMMENDATIONS ........................................................................................................................... 23
7 CONCLUSION ........................................................................................................................................ 24

-2-


List of Figures

Figure 1. Sensor Web concept (OGC) ................................................................................. 7
Figure 2. GMES scheme (GMES source) ............................................................................. 8
.
Figure 3. The URM GeoPortal components (URM definition for EnviroGrid purposes) .... 9
Figure 4. Basic scheme for integration of sensor network with Geospatial database
management (Winsoc design for forest fire scenario). .................................................... 18
Figure 5. Basic scheme for integration of sensors network with Geospatial database
management for forest fire scenario (Winsoc design for forest fire scenario). ............... 19
Figure 6. Mobile Communication Unit ............................................................................. 20
.
Figure 7. Client based on Google Earth ............................................................................ 21
Figure 8. HTML based client ............................................................................................. 22
.
Figure 9. HSlayers client .................................................................................................... 23
Figure 10. Examples of crop conditions monitoring [19] ................................................. 24

-3-


Abbreviations and Acronyms

CCSS Czech Centre for Science and Society
FHSS Frequency Hopping Spread Spectrum technology
GENESIS FP7 IP project in area of ICT for Environment
GEOSS Global Earth Observation System of Systems
GMES Global Monitoring for Environment and Security
GSDI Grid enabled Spatial Data Infrastructure
INSPIRE Infrastructure for Spatial Information in the European Community
NASA National Aeronautics and Space Administration
NCAP Network Capable Application Processor
O&M Observations & Measurements
OGC Open Geospatial Consortium
OSIRIS FP7 CT project with focus on Sensor Development
RFID Radio-frequency identification
SANY SANY Sensor Anywhere, 6.FP project
SAS Sensor Alert Service
SDE ESRI extension for Oracle and MS SQL for Spatial Data
SDI Spatial Data Infrastructure
SML Sensor Model Language
SOAP Simple Object Access Protocol
SOS Sensor Observations Service
SPS Sensor Planning Service
STIM Smart Transducer Interface Module
SWE Sensor Web Enablement
TLC Telecommunication
TML Transducer Model Language
URM Uniform Resource Management
VLIT Very Long range Identification Tag
WCS Web Coverage Service
WFS Web Feature Service
WINSOC 7th FP project, Contract number 33914
WNS Web Notification Services
WSN Wireless Sensor Network
XML Extensible Markup Language

-4-


1 Executive summary
The objective of this deliverable is to analyse the state-of-the-art in sensor technologies, Wireless Sensor
Network and Web Sensor. It also analyses different solutions on how to integrate sensor measurements into
Grid-enabled Spatial Data Infrastructures (GSDI).
The first chapter analyses the role of the sensors in the international observation systems such as GEOSS,
GMES and INSPIRE. GEOSS objective is the development and implementation of the future Earth
observing systems, including satellite, airborne, and in-situ observations. GMES defines in situ
observations as one of the pillars of its infrastructure (one of the two groups of Core services). In situ
observation is therefore an essential part of GMES and GEOSS. However, in comparison with the remote
sensing, in situ observations are not well integrated. For example in INSPIRE, in situ monitoring is not
included. Although several FP6 and FP7 projects are dealing with in situ monitoring (e.g. SANY, Osiris,
Winsoc, Genesis), one example of the integration of in situ monitoring with SDI is the Uniform Resource
Management GeoPortal (URM), which is based on INSPIRE, GMES and GEOSS principles. The URM
concept divides in situ observations into three relatively independent blocks: Sensor technologies including
networks of wireless sensors, sensor measurement integration, and Sensor Web. The problem of current
research in the field is that most projects target these three parts separately and until now there is a large
integration gap at the low level of Sensor Web protocols.
A sensor measures a physical quantity and converts it into a signal that can be read by an observer or by an
instrument. Sensors are most commonly used to make quantifiable measurements. For the sensor selection
there are four criteria: what do we need to measure; in which environment is measurement being done;
what is the required accuracy of the measurement; is the whole system calibrated or certified. These four
aspects can influence the selection of sensors, but also their costs. Every sensor is described by the
following characteristics: transfer function, sensitivity span or dynamic range, accuracy or uncertainty,
hysteresis nonlinearity, noise, resolution and bandwidth.
Wireless Sensor Network is an emerging technology made up from tiny, wireless sensors - nodes. Each
node is a tiny computer with a power supply, one or more sensors, and a communication system. Sensor
networks are receiving a significant attention because of their numerous potential civilian and military
applications. The main features that a sensor network should have are: each node should have a very low
power consumption, each node should be allowed to go in stand-by mode, the estimation/measurement
capabilities of the system as a whole should significantly outperform the capabilities of each sensor, a
sensor network is ultimately an event-driven system, congestion around the sink nodes should be avoided
by introducing some form of distributed access and processing the information should flow through the
network in the simplest way. WINSOC developed very innovative concept where the whole network is
achieved by introducing a suitable coupling among adjacent and low cost sensors. The sensors are enabling
a global distributed detection or estimation more accurately than is achievable by each single sensor and
without the need for sending all data to a fusion centre.
Several examples of Wireless Sensor technologies can be mentioned: Cirronet, which has created high-
performance components for industrial wireless applications; MeshNetics, which is a leading provider of
short-range wireless sensor technologies; Moteiv is a venture-funded company that provides wireless
sensor networking solutions to enterprises worldwide; MaxStream is a premier manufacturer of high-
performance wireless device networking solutions; IntelliSensing LLC is a young technology company that
stems from a solid footing in the aerospace market; Vulcain, a leader in the gas detection industry, designs
and manufactures technologically superior products in order to provide clear solutions to ensure clear air;
Crossbow Technology, Inc. is the leading end-to-end solutions supplier in wireless sensor networks. As for
latest novelties, VLIT-NODE technology, which is a Wireless Sensor Network based on RFID of second

-5-


generation allowing communication on distance around one kilometre. This solution will open new
possibilities for large scale deployment of Wireless Sensor Network.
For the integration of sensor measurements with SDI we can use the concept of Sensor Web introduced by
NASA. OGC started to release the Sensor Web Enablement (SWE) as a standard for integrating a variety of
sensors into one communication language and a well defined web environment. The goal of SWE is to
create web-based sensor networks and to make all sensors and repositories of sensor data discoverable,
accessible and, where applicable, controllable via the Internet. OGC members have developed and tested
the following standards and candidate specifications: Observations & Measurements (O&M), Sensor
Model Language (SensorML), Transducer Model Language (TransducerML or TML), Sensor Observations
Service (SOS), Sensor Planning Service (SPS), Sensor Alert Service (SAS) and Web Notification Services
(WNS).
The first existing implementations are decribed in this article. NASA has adopted the vision of sensor as
advance sensor web technology for satellites. Northrop Grumman’s PulseNet has been using the SWE
standards in a major internal research and development project called Persistent Universal Layered Sensor
Exploitation Network, which is a real-world testbed to prototype a global sensor web. SANY Sensors
Anywhere recognises the OGC’s SWE suite of standards as one of the key technologies that can eventually
lead to development of self-organising, self-healing, ad-hoc networking of in-situ and Earth observation
sensor networks. The German organization 52North provides a complete set of SWE services under GPL
license. The European Space Agency and various partner organizations in Europe are collaborating on the
Heterogeneous Mission Accessibility (HMA) project. HMA’s high level goals include, among other things,
consolidating Earth imaging and other geospatial interoperability requirements; defining interoperable
protocols for cataloguing, ordering and mission planning; and addressing interoperability requirements
arising from security concerns. CUAHSI has been researching, prototyping, and implementing Web
services for discovering and accessing different hydrologic data sources, and developing online and
desktop applications for managing and exploring hydrologic time series and other hydrologic data. This is
a first attempt to define what will be supported in MapServer to be able to deploy a Sensor Observation
System (SOS). SOS provides several operations divided into core mandatory operations (GetCapabilities,
DescribeSensor and GetObservation) and optional transactional and enhanced operations. CCSS
implemented Sensor Observation Service based on Java Architecture for XML Binding.
The development of standards on sensor technologies and the development of Sensors Web standard run in
parallel, without any synergies. There is no direct integration of sensors with SDI. Winsoc project
suggested a solution based on the utilisation of two levels sensors. Level 1, which is focused on terrain data
collection, level 2 guarantees IP communication with the Web environment using OGC SWE standard.
The sensors on the level 2 are represented by mobile units that are a type of industrial computers, which
allow limited implementation of SOS standard or easy integration of measurement with databases.
One task of the enviroGRIDS project is to analyse the needs for sensor measurements, including the
definition of the observed phenomena, the definition of the accuracy of measurement and the definition of
the frequency of measurement. This project task will test different approaches for integrating standards of
observation sensors with wireless sensors network. It will further explore the development of hardware and
software solution to plug sensors into SDI. It will pursue the implementation of SWE standards and their
integration with SDI and grid technologies.

-6-


2 Introduction
2.1 The enviroGRIDS project
EnviroGRIDS @ Black Sea Catchment aims at building capacities in the Black Sea region to use new
international standards to gather, store, distribute, analyze, visualize and disseminate crucial information on
past, present and future states of this region, in order to assess its sustainability and vulnerability.

2.2 WP2: Grid-enabled Spatial Data Infrastructure
The aim of WP2 is to create a Grid-enabled Spatial Data Infrastructure (GSDI) so that the data necessary
for the assessment of GEO Societal Benefit Areas, as well as the data produced within the project can be
gathered and stored in an organized form on the Grid infrastructure and distributed across the Grid in order
to provide a high performance and reliable access through standardized interfaces. Using the standardized
technologies of the Grid we can provide a Single Information Space for environmental data in the Black
Sea Catchment.

2.3 Task 2.3: Sensor data integration
This task consists mainly of providing interfaces so that any kinds of sensors can publish their data on the
SDI and Grid, as well as providing SDI and Grid tools to access sensors, and finally store the gathered data.
Integration of the data generated by active sensors with the Grid environment is a prerequisite for the
handling of this data and for the integration with the Grid middleware.

Figure 1. Sensor Web concept (OGC)

-7-


2.4 Scope and purpose of this deliverable
The objective of EnviroGRIDS sensor data use and integration guideline is to support EnviroGRIDS
partners by informing them about current sensor technologies, new development in the area of the Wireless
Sensor Network and integration of sensors using Web Sensor standards. The deliverable analyses the role
of a sensor in monitoring by using the current GMES Earth Observation model (Fig. 2). A part of the
description is also the analysis of the possibilities on how to integrate sensors with Grid Enabled SDI.
An important part of this document focuses on the description of the current solutions developed in the
previous projects by Czech Centre for Science and Society (CCSS). These solutions will be extended for
future utilisation in the EnviroGRIDS Black See project.

2.5 The role of Sensor measurement in SDI
The Global Earth Observation System of Systems (GEOSS) is a coordinated and integrated network of
Earth observing and information systems to support informed decision making for society, including the
implementation of international environmental treaty obligations. There is a contribution on a voluntary
basis by Members and Participating Organizations of the intergovernmental Group on Earth Observations
(GEO). One of the goals of GEOSS is to ensure the fully-coordinated development and implementation of
future Earth observing systems, including satellite, airborne, and in-situ systems, as well as a transition of
research systems into operational systems [1]. In situ observations represent therefore one of the essential
components of the GEOSS system. The Global Monitoring for Environment and Security (GMES)
programme defines also in situ observation as one of the two basic pillars of its infrastructure [2].

Figure 2. GMES scheme (GMES source)

-8-


From the point of view of GMES and GEOSS, in situ observations are an essential part of Earth
monitoring. In comparison with remote sensing, in situ observations are still not very well integrated. In the
INSPIRE directive, for instance, in situ monitoring is not yet included as a part of the proposed Spatial
Data Infrastructure (SDI). Nonetheless, there are several FP6 and FP7 projects dealing with in situ
monitoring (e.g. SANY, Osiris, Winsoc, Genesis), and different approaches exist already to integrate in situ
observations into SDI.

2.6 The Uniform Resource Management (URM) GeoPortal
One example where all components of in situ monitoring are integrated into an SDI is the Uniform
Resource Management (URM) GeoPortal. The basic components of the URM GeoPortal, which are based
on INSPIRE, GMES and GEOSS principles and standards, are shown in figure 3.

Figure 3. The URM GeoPortal components (URM definition for EnviroGrid purposes)

In the URM, the integration of in situ observations was divided into three relatively independent blocks:

-9-


• Sensors technologies, including wireless sensor networks;
• Sensor measurement integration;
• Sensor Web.
The problem of the current research is that most projects are focusing either on sensor technologies
development or on Sensors Web. Until now, there was a large gap in the integration of low level protocols
with Sensor Web. The Sensor Web community expects some standardisation at the level of sensors
themselves, which in reality is not happening.

3 Sensors and sensor networks
3.1 Sensors
A sensor is a device that measures a physical quantity and converts it into a signal that can be read by an
observer or by an instrument. Many kinds of sensors for surveillance and intrusion detection exist including
infrared, other optical, microwave-based, or other types. They can be effectively used to support manned
surveillance, e.g. video cameras. There are also video-based systems that sense changes in the image and
trigger an alert. Since every sensor used for this kind of applications can be characterised by its location –
space and time coordinates, the spatial extension and near-real-time availability of sensor-originated
information layers in geospatial applications represent a great potential.
Sensors are most commonly used to make quantifiable measurements, as opposed to qualitative detection
or presence sensing. For the sensor selection there are four criteria:
1. What do we need to measure? Sensors can measure almost everything, but every phenomena
needs a different type of sensors.
2. In which environment will we measure? There are different needs for outdoor and indoor sensors,
and there are also specific requirements for sensors working in extreme conditions.
3. What is the required accuracy of the measurement?
4. Is the whole system calibrated or certified?
These four aspects can influence the selection of sensors, but also their costs.
Every sensor is described by the following characteristics:
• Transfer Function - the functional relationship between physical input signal and electrical output
signal
• Sensitivity - relationship between input physical signal and output electrical signal
• Span or Dynamic Range - range of input physical signals that may be converted by the sensor to
electrical signals
• Accuracy or Uncertainty - largest expected error between actual and ideal output signals
• Hysteresis - width of the expected error in terms of the measured quantity
• Nonlinearity - maximum deviation from a linear transfer function over the specified dynamic
range
• Noise - sensors produce some output noise in addition to the output signal
• Resolution - minimum detectable signal fluctuation
• Bandwidth - response times to an instantaneous change in physical signal
When we are talking about sensor, we usually consider both parts - sensor and transducer. A sensor is a
device that receives a signal or stimulus and responds with an electrical signal, while a transducer is a
converter of one type of energy into another. From a signal conditioning viewpoint it is useful to classify
sensors as either active or passive. The active sensor requires an external source of excitation. The passive

- 10 -


(or self-generating) sensor generates its own electrical output signal without requiring external voltages or
currents [3].

3.2 Wireless Sensor Network
3.2.1 Principles
The current innovation in sensor technologies is mainly focused on development of Wireless Sensor
Network. This is a new solution based on small nodes (sometimes called smart dust - mote). The ultimate
goal is to have nodes or motes as small as pin heads. Each node is a small computer with a power supply,
one or more sensors, and a communication system. Each mote contains a network independent module -
Smart Transducer Interface Module (STIM). It contains the transducers, signal conditioning circuitry and a
standard interface. The other part of the mote is a network specific module - Network Capable Application
Processor (NCAP). It implements the interface to the desired control network and also implements the
standard interface of the transducer module. Sensor networks are receiving a significant attention because
of their many potential civilian and military applications. The design of sensor networks faces a number of
challenges resulting from very demanding requirements on one side (such as high reliability of the decision
taken by the network and robustness to node failure), and very limited resources on the other side (such as
energy, bandwidth, and node complexity) [4].
Sensor Network Systems provide a novel paradigm for managing, modelling and supporting complex
systems requiring massive data gathering with pervasive and persistent detection/monitoring capabilities.
Therefore it is not surprising that in recent years a growing emphasis has been steered towards the
employment of sensor networks in various technological fields, e.g. aerospace, environment monitoring,
homeland security, smart buildings. A significant amount of resources has been allocated for national
(USA, France, Germany) and international (e.g. European Commission) research programmes targeted at
developing innovative methodologies and emerging technologies in different application fields of wireless
sensor network. The main features of a sensor network are the following:
i) each node should have a very low power consumption, the capability of recharging its battery or
scavenging energy from the environment, and very limited processing capabilities;
ii) each node should be allowed to go in stand-by mode (to save as much battery as possible) without
severely degrading the connectivity of the whole network and without requiring complicated
re-routing strategies;
iii) the estimation/measurement capabilities of the system as a whole should significantly outperform
the capabilities of each sensor and the performance should improve as the number of sensors
increases, with no mandatory requirement on the transmission of the data of each single
sensor toward a centralised control/processing unit; in other words, the network must be
scalable and self-organising, i.e. capable of maintaining its functionality (although modifying
the performance) when the number of sensors is increased;
iv) a sensor network is ultimately an event-driven system, it is necessary to guarantee that the
information about events of interest reach the appropriate control nodes, possibly through the
simplest propagation mechanism, not necessarily bounded to the common OSI protocol stack
layer;
v) congestion around the sink nodes should be avoided by introducing some form of distributed
processing;
vi) the information should flow through the network in the simplest way, not necessarily relying on
sophisticated modulation or multiplexing techniques.
In summary the fundamental requirements for the sensor network are:

- 11 -


• Very low complexity of elementary sensors, associated with a low power consumption and low-
costs;
• High reliability of the decision/estimation/measurement of the network as a whole;
• Long network life-time for low maintenance and stand-alone operation;
• High scalability;
• Resilience to congestion problems in peak traffic conditions [5].

3.3 Winsoc approach
The WINSOC [6] project introduced a new concept of WSN which is very different from previous
solutions. The network could be compared with principles of neural networks, where every node of neural
network is represented by low cost sensors with limited memory and computing capacity. The network
supports distributed detection or estimation. This approach is more accurate than the observation reached
by each single sensor. The advantage is also that it is not necessary to send every observation into fusion
centre. The whole network is hierarchical and composed of two levels. A lower level, composed of the low
cost sensors. The lower level network provides observation and guarantees a consensus. A higher level
guarantees communication with the fusion centre. The key point is the interaction among the low cost
sensors that increases the overall reliability. It also insures a scalability and a tolerance against failure
and/or stand-by of some sensors, (e.g. battery recharge and energy saving). The Winsoc solution supports
distributed processing capabilities. It was tested on environmental risk management (forest fire and
landslides) using heterogeneous networks with various degrees of complexity and capabilities.

3.4 Wireless Sensor Technology companies
Since 1987, the Atlanta-based Cirronet company has created high-performance components for industrial
wireless applications. They started with their own frequency hopping spread spectrum (FHSS) technology,
which has been continually optimized. They have also focused on emerging standards, incorporating the
best of them into their product mix. Their line of products today encompasses the industry’s broadest range
of technologies and options, ensuring that they meet their customers’ needs precisely. Cirronet was
acquired in 2006 by RF Monolithics (RFM) and is now a wholly owned subsidiary of this 25 year-old
leader in low-power wireless sensor networks and high performance RF components (NASDAQ: RFMI).
MeshNetics is a leading provider of short-range wireless sensor technology. They offer market-ready
solutions for wireless sensing applications that are based on IEEE802.15.4 / ZigBee standards. Their goal is
to help their partners establish a solid footprint in the emerging M2M market with their MeshNeticsTM
product family. The MeshNeticsTM product portfolio includes wireless ad-hoc mesh-networks software,
hardware designs, and customization services that enable M2M applications, based on open systems and
standards. MeshNetics offers low power, high sensitivity ZigBee Modules adding wireless connectivity to a
sensor device. The platform-independent ZigBee Embedded Software configurations that provide various
levels of ZigBee Standard compatibility for the wireless sensor products. The ZigBee Evaluation Kit and
ZigBee Development Kit contain hardware and software that you need to quickly prototype and test
wireless sensor network (WSN) applications.
Moteiv is a venture-funded company that provides wireless sensor networking solutions to enterprises
worldwide. They sell hardware, software and services to innovative companies. Their customers leverage
wireless sensor networks to create business value and expand market leadership. Moteiv's mission is to
accelerate the integration of physical world data and processes into the enterprise, by removing the existing
barriers to mass wireless sensor adoption. Moteiv's founding team has several decades of collective
experience leading the implementation of the world's largest wireless sensor network deployments from UC
Berkeley. They have leveraged their domain and technology expertise to build innovative solutions that

- 12 -


address the real-world problems and barriers they've encountered working with customers around the
globe.
MaxStream is a premier manufacturer of high-performance wireless device networking solutions.
MaxStream’s patent-pending wireless designs have garnered multiple awards and thousands of design wins
for the innovative technological advances. MaxStream’s highly reliable data radios are deployed worldwide
in an array of industrial and commercial applications, creating easy-to-implement wireless connectivity
IntelliSensing LLC is a young technology company that stems from a solid footing in the aerospace market.
With a strong background in sensing instrumentation design, embedded development and information
technology, they combine the trusted methods of physical measurement with advanced wireless technology
to produce sensors that interface directly with control and measurement systems, using no external power
or wiring. Their mission is to design, manufacture and support wireless sensor products that enable
advanced applications in demanding markets. Their slogan, The Network is the Sensor, highlights their
commitment to provide a system solution not only incorporating sensors, but also the infrastructure
responsible for transporting the measurement data to the destination.
Vulcain, a leader in the gas detection industry, designs and manufactures technologically superior products
in order to provide clear solutions to ensure clear air.
Crossbow Technology, Inc. is the leading end-to-end solutions supplier in wireless sensor networks.
Crossbow provides a scalable product portfolio comprised of hardware and software development
platforms, complete product designs, manufacturing and professional services that enable OEMs and
system integrators to bring end-to-end wireless sensor network systems to market quickly [7].

3.5 VLIT Node Technology
VLIT NODE technology is a new solution for Wireless Sensor Network developed by Cominfo (Czech
SME company) in cooperation with Czech Centre for Science and Society (CCSS). The solution is based
on RFID of second generation allowing communication on distance around one kilometre. This solution
will open new possibilities for large scale deployment of Wireless Sensor Network.

4 Sensor Web
4.1 What is the Sensor Web?
The concept of the sensor web was introduced by NASA. The sensor web was introduced as a link
connecting together ground and space-based instruments to enable autonomous collaborative observation
collections. These observations can be triggered via a variety of sources. Typically, scientific events of
interest trigger observation campaigns in an ad hoc sensor constellation and supply multiple data
acquisitions as rapidly as possible and in as much depth as possible in a given time period. This is
accomplished through a seamless set of software and communications interactions in a system of linked
sensors [9].

4.2 Sensors Web Enablement
As the communication of sensors with GIS tools is becoming necessary, the OGC is starting to release the
Sensor Web Enablement (SWE) that should become a standard in integrating of variety kind of sensors into
one communication language and well defined web environment. Open geospatial consortium SWE is
intended to be a revolutionary approach for exploiting Web-connected sensors such as flood gauges, air
pollution monitors, satellite-borne Earth imaging devices, etc. The goal of SWE is the creation of web-

- 13 -


based sensor networks. That is, to make all sensors and repositories of sensor data discoverable, accessible
and where applicable controllable via the Internet. Open geospatial consortium defines a set of
specifications and services for this goal. Short descriptions of these services are shown below [10].
OGC members have developed and tested the following candidate specifications. Others are planned.
1. Observations & Measurements (O&M) - Standard models and XML Schema for encoding
observations and measurements from a sensor, both archived and real-time.
2. Sensor Model Language (SensorML) - Standard models and XML Schema for describing
sensors systems and processes associated with sensor observations; provides information needed
for discovery of sensors, location of sensor observations, processing of low-level sensor
observations, and listing of taskable properties, as well as supports on-demand processing of
sensor observations.
3. Transducer Model Language (TransducerML or TML) - The conceptual model and XML
Schema for describing transducers and supporting real-time streaming of data to and from sensor
systems.
4. Sensor Observations Service (SOS) - Standard web service interface for requesting, filtering,
and retrieving observations and sensor system information. This is the intermediary between a
client and an observation repository or near real-time sensor channel.
5. Sensor Planning Service (SPS) - Standard web service interface for requesting user-driven
acquisitions and observations. This is the intermediary between a client and a sensor collection
management environment.
6. Sensor Alert Service (SAS) - Standard web service interface for publishing and subscribing to
alerts from sensors.
7. Web Notification Services (WNS) - Standard web service interface for asynchronous delivery of
messages or alerts from SAS and SPS web services and other elements of service workflows [11].

4.3 Existing Implementation of SWE [12]

4.3.1 NASA

The US National Aeronautics and Space Administration (NASA) has adopted the vision of sensor webs as
a strategic goal and has thus funded a variety of projects to advance sensor web technology for satellites. A
number of these projects have recently adopted the OGC’s Sensor Web Enablement (SWE) suite of
standards. The focus of many of these efforts has been the collaboration between the NASA Jet Propulsion
Lab and the NASA Goddard Space Flight Center using the Earth Observing 1 (EO-1) and assorted other
satellites to create pathfinder sensor web applications that have evolved from prototype to operational
systems. GSFC, Vightel Corporation, and Noblis initiated a wildfire sensor web scenario using EO-1 and
recently prototyped the preliminary transformation to SWE implementation using the Open Source
GeoBliki framework that was developed for the OGC’s OWS-4 interoperability testbed. Both JPL and
GSFC are in the process of changing the remaining interfaces to OGC SWE compatibility.

4.3.2 Northrop Grumman’s PULSENet
Northrop Grumman Corporation (NGC) has been using the SWE standards in a major internal research and
development (IRAD) project called Persistent Universal Layered Sensor Exploitation Network
(PULSENet™). This real-world testbed’s objective is to prototype a global sensor web that enables users
to:

- 14 -


• Quickly discover sensors (secure or public), task them, and access their observations in ways that
meet user needs.
• Obtain sensor descriptions in a standard encoding that is understandable by a user and the user’s
software.
• Subscribe to and receive alerts when a sensor measures a particular phenomenon.
In its first year, PULSENet was successfully field tested under a real-life use case scenario that fused data
from four unattended ground sensors, two tracking cameras, 1,800 NOAA weather stations and NASA’s
EO-1 satellite.

4.3.3 SANY Sensors Anywhere
SANY IP is an FP6 Integrated Project co-funded by the Information Society and Media Directorate General
of the European Commission. SANY IP intends to contribute to GMES (Global Monitoring for
Environment and Security, a major European space initiative) in the area of in-situ sensor integration, by
developing a standard open architecture and a set of basic services for all kinds of sensors, sensor networks
and other sensor-like services.
The SANY Consortium recognises the OGC’s SWE suite of standards as one of the key technologies that
can eventually lead to development of self-organising, self-healing, ad-hoc networking of in-situ and earth
observation sensor networks.

4.3.4 52 North
The German organization 52North provides a complete set of SWE services under GPL license. This open
source software is being used in a number of real world systems, including a monitoring and control system
for the Wupper River watershed in Germany and a forest fire monitoring system in South Africa.

4.3.5 HMA in Europe
The European Space Agency and various partner organizations in Europe are collaborating on the
Heterogeneous Mission Accessibility (HMA) project. HMA’s high level goals include, among other things,
consolidating earth imaging and other geospatial interoperability requirements; defining interoperable
protocols for catalogueing, ordering and mission planning; and addressing interoperability requirements
arising from security concerns. HMA involves a number of OGC standards, including the Sensor Planning
Service, which supports the feasibility analysis requirements of Spot Image optical satellite missions.

4.3.6 Web Services for Unified Access to U.S. Hydrologic Data
CUAHSI (Consortium of Universities for the Advancement of Hydrologic Science, Inc.) is an organization
founded to develop cyber infrastructure to support advanced hydrologic research and education. CUAHSI
represents more than 100 U.S. universities and is supported by the U.S. National Science Foundation.
CUAHSI’s Hydrologic Information System (HIS) project involves several research universities and the San
Diego Supercomputer Center as the technology partner. For three years, the CUAHSI HIS team has been
researching, prototyping, and implementing Web services for discovering and accessing different
hydrologic data sources, and developing online and desktop applications for managing and exploring
hydrologic time series and other hydrologic data.
The core of the HIS design is a collection of WaterOneFlow SOAP services for uniform access to
heterogeneous repositories of hydrologic observation data. SOAP is a protocol for exchanging XML-based
messages over computer networks. SOAP forms the foundation layer of the Web services stack, providing
a basic messaging framework where more abstract layers can be build on. The services follow a common
XML messaging schema named CUAHSI WaterML, which includes components for transmitting

- 15 -


observation values and time series, as well as observation metadata including information about sites,
variables and networks.

4.3.7 Support of Sensor Observation Service in MapServer [13]
This is the first attempt to define what will be supported in MapServer to be able to deploy a Sensor
Observation System (SOS). SOS provides several operations divided into core mandatory operations
(GetCapabilities, DescribeSensor and GetObservation) and optional transactional and enhanced operations.
The first implementation of SOS in MapServer will only address the core operations:
• GetCapabilities Request
• GetCapabilities returned document
• GetObservation Request
• Get Observation Response
• Describe Sensor

4.4 CCSS implementation
This section describes specific implementations that were recently developed by CCSS using XML and
JAXB standards.

4.4.1 Sensor Observation Service
The SOS is an OGC standard that defines a web service interface for discovery and retrieval of real time or
archived data. Data are produced by many sensors, including mobile, stationary, in-situ or remote sensors.
Data can be observations or descriptions of the sensor (calibration information, positions, etc.).
Observations are returned encoded as an O&M Observation and the information about the sensor are
returned encoded in SensorML or TML.
The operations of the SOS are separated in four profiles:
- core profile – three basic operations, provided by every SOS implementation
- transactional profile – operations to register sensors and insert observations into SOS
- enhanced profile – additional optional operations
- entire profile – implements all operations
Core profile has three mandatory core operations that provide its basic functionality:
- GetCapabilities – returns a service description containing information about the service interface
and the available sensor data.
- DescribeSensor – returns a description of one specific sensor, sensor system or data producing
procedure. The response returns information like position of sensor, calibration, input- and outputs
encoded in SensorML or in TML.
- GetObservation – provides access to sensor observations and measurement-data.
Our recent work was focused on creating an SOS implementation which contains core operations.
Communication between consumer and implementation is based on xml documents. An XML schema
describes the structure of an XML document. An XML Schema:
• defines elements that can appear in a document;
• defines attributes that can appear in a document;
• defines which elements are child elements;
• defines the order of child elements;

- 16 -


• defines the number of child elements;
• defines whether an element is empty or can include text;
• defines data types for elements and attributes;
• defines default and fixed values for elements and attributes.

For reading and parsing XML document, JAXB utilities that are core a part of JAVA are used. JAXB
constitutes a framework for processing XML documents.
JAXB accesses the XML document from a Java program by presenting the XML document to the program
in Java format. The first step in this process is to bind the schema for the XML document. Binding a
schema means generating a set of Java classes that represents the schema. All JAXB implementations
provide a tool called binding compiler to bind a schema.
The compiler is called by command:
xjc –d <dir> –p <package> –b <binding.xjb> schema.xsd

The -p option identifies a package for the generated classes, and the -d option identifies a target directory.
Binding file (*.xjb) is used for customization, JAXB allows you to annotate a schema with binding
declarations that override or extend the default binding behaviour. This customization is useful by
compiling a complex set of schemas to prevent collisions of attribute names or method names.
Unmarshalling an XML document means creating a tree of content objects that represents the content and
organization of the document. The content objects are instances of the classes produced by the binding
compiler. Marshalling is the opposite of unmarshalling. It creates an XML document from a content tree.
We have successfully generated all required classes so we can handle now all SOS related XML
documents. Next work is to add a convenient API to deal with specific requirements of SOS more
comfortably [14], [15], [16], [17], [18].

5 A Gap between Sensor Technologies and Sensor Web
5.1 What is the gap between the Sensor Web and the Sensor Technology?
The previous chapters described the main sensors technology and Sensors Web implementations. For
practical utilisation, there are still several gaps that introduce problems for integration of sensors with
Spatial Data Infrastructure. The development of standards on the level of sensor technologies and
development of Sensors Web standard run for instance in parallel, without any synergies. So there is no
direct way to integrate sensors with SDI. It is therefore necessary to build a proprietary interface that
supports the plug in of sensors into SDI. The most commonly used solution is to store sensor measurements
into a database, and then to build SWE interfaces for this database.

5.2 How could we fill the gap between the Sensors Web and the Sensor
Technology? - the CCSS solution
CCSS participates in the WINSOC project and suggested general scheme for integration of sensor networks
with SDI.

- 17 -


W eb W eb
Brow ser B row se r

internet
IP
CI

L2 Sensor
network
GI

OGC SWE
PD A
Services LI
AI GPS
Sensor L2

Base Station BI
For level II

Sensor level I

Figure 4. Basic scheme for integration of sensor network with Geospatial database management
(Winsoc design for forest fire scenario).

The general scheme presented in Figure 4 represents two levels of sensors. A level 1 is focused on terrain
data collection and a level 2 guarantees IP communication with Web environment using OGC SWE
standard. A pilot solution proposed in WINSOC for Forest fire scenario is presented in Figure 5.

- 18 -


Figure 5. Basic scheme for integration of sensors network with Geospatial database management for
forest fire scenario (Winsoc design for forest fire scenario).

The sensors in the level 2 are represented by mobile units developed inside CCSS with a type of industrial
computers allowing limited implementation of SOS standard or easy integration of measurement with
databases.
Mobile Communication Unit device is using AT91RM9200 Main board as a central unit, Wavecom Fast
track modem as a GPRS communication device. Power supply for all parts is provided by underlying
power board, backed-up by reachable battery. Main power source is external 230V plug, which is stabilized
by switched power supply built in separate box mounted sideway to the main box.
Simple board is used as a sensor interface device that allows connection of RS485 sensors with its own
communication proprietary protocol. It allows also the connection of sensors that are sending data by
modulating power line, and sensors with generic digital or analogue signals.
Data from this interface card are transferred into the main processor by RS485 through our protocol and
with these properties:
• Modular bus system
• Automatic configuration of all devices
• Individual addressing and identification of each module
• Address collision solving
• Immunity to interference
• Short circuit and collision
• Immunity to OOB (out of band) traffic on the same bus
• Hot-plug support

- 19 -


The computational part of the mobile unit is based on ARM processor. Communication is supported using
GPRS protocol.

Figure 6. Mobile Communication Unit

The main role of the server is to store measured data and publish them though the proper service. The
database that is used in our case is PostgreSQL with PostGIS extension. The GPRS can call a proprietary
web service that stores the data into the database or OGC compliant SOS transactions can be performed. In
this way the measurements are inserted into the database. The sensor position (continually measured by
GPS) is also stored in the database in real time using again the proprietary web service or transactional
WFS.
Once the data are in the database we have many possibilities how to present them to the clients. For
instance:
• Direct connection to PostGIS by common GIS viewer - as far as PostGIS is compliant with OGC
Simple Feature Specification, we can connect directly to the database by various kinds of GIS
desktop applications (uDig, QGIS, Jump etc...).
• Set up WFS or WMS (by Geoserver or UMN Mapserver) and access the data by whichever web or
desktop client. The measured values can be represented by feature attributes.
This solution allows publishing the position or the track of the sensor and some of the measurements. To
publish the measurements in a better way, we will be able to access the data by SOS service (still in
development). We have also implemented a web service that generates charts from database query.

- 20 -


Figure 7. Client based on Google Earth

One of the offered possibilities is to access the data through Google Earth (Figure 7). Figure 8 demonstrates
the generation of graphs based on Senor Observation Services.
For the purpose of Winsoc project a special client based on HSLayers library was also developed
(extension of popular Open layers library developed by Help Service Remote Sensing member of CCSS)
(Figure 9).

- 21 -


Figure 8. HTML based client

- 22 -


Figure 9. HSlayers client

The sensor position can be visualized by any WFS client. Observed values are available in the form of chart
(PNG image) through web service (http GET) where one of the parameters is the ID of the feature
representing the sensor position.
There are many possibilities to deal with sensor measurements using free and open source software. The
described approach can be easily used for tasks like car monitoring and many others by using almost free
technologies.
Nevertheless, the complex and interoperable solution that will be able to deal with all sensor-based tasks
(e.g. alerts, sensor processing,...) is still an open issue, even though the OGC initiative put a lot of efforts
into this task recently. The reason is that the support by concrete implementations of these specifications is
still low. It is probably necessary that the GIS and sensor communities reach some conformity to bring
sensors and measurements topic to the same level of interoperability than for example spatial data sharing
with WMS, WFS and WCS standards [19].

6 Recommendations
From our review of the state-of-the-art in Sensors and Sensor Web technologies, we can derive some
recommendations for the EnviroGRIDS project in the Black Sea:
• To analyse the needs for sensor measurements in pilot areas. This includes:
o Define the phenomena to be observed
o Define the accuracy of measurement

- 23 -


o Define the frequency of measurement
• To test different approaches for observation standard sensors and Wireless Sensor Network.
• To continue the development of hardware and software solution for plugging in sensors into SDI.
• To continue the implementation of SWE standards and integration of sensor measurement with
SDI and Grid technology.
From the current models and also from previous experiences of CCSS, it seems that the most promising
implementation of sensor technology in the enviroGRIDS project should be focused on climate change
model and catchment hydrological model (see Figure 10).
The research challenges for the climate change model could be the comparison of classical sensors
measurement with Wireless Sensor Networks for the purpose of local climatic conditions modelling. The
future potential large scale deployment of WSN seems to open new possibilities in climatic changes
modelling. The locals models are currently missing and they are very important in many areas like risk
management, agriculture, etc.
For hydrological models, sensor or sensor network could be used for river water quality data collection and
also for monitoring.

Figure 10. Examples of crop conditions monitoring [19]

The integration of this measurement technology into SDI and Grid technology could introduce new
possibilities for modeling that could be reused in other regions and other disciplines. Generally, the focus
should be on improving the methods for integrating sensors measurement with SDI and finally with Grid
technologies. Current Grid and OGC standards do not support direct integration.

7 Conclusion
In the near future, sensors and Wireless Sensor Network will be an integrated part of both GEOSS and
GMES. The fast development of sensor technologies, Wireless Sensor Network and Web Sensors allows to
start the integration of sensor technologies within the enviroGRIDS infrastructure. There are still gaps in

- 24 -


the integration of sensors measurement into Sensors Web, but previous results from CCSS research could
help overcome these barriers. The report recommends to focus on two scenarios:
• Climatic changes
• Hydrological model
The main research tasks should to be:
• Exact definition of use cases
• Selection of sensor technology
• Integration of sensors measurements with Sensor Web
• Integration of sensors with Grid technologies

References
1. GEO-V, 19-20 November 2008, Strategic Targets: GEOSS Implementation by 2015,
Document 10
2. Mauro Facchini. Global Monitoring for Environment and Security (GMES), State-of-play,
European Commission, GMES Bureau, 2009
3. Sensor Technology Handbook Editor-in-Chief Jon S. Wilson, 2005, Elsevier Inc., ISBN:
0-7506-7729-5
4. Karel Charvat, Petr Kubicek, Vaclav Talhofer, Milan Konecny, Jan Jezek. SPATIAL
DATA INFRASTRUCTURE AND GEOVISUALIZATION IN, EMERGENCY
MANAGEMENT in Resilience of Cities to Terrorist and other Threats, Learning from
9/11 and further Research Issues, Proceedings of NATO Advanced Research
Workshop on Urban Structures Resilience under Multi-Hazard Threats: Lessons of
9/11 and Research Issues for Future Work © 2008 Springer Science + Business
Media B.V. Moscow, Russia ISBN 978-1-4020-8488-1 (PB), ISBN 978-1-4020-8487-
4 (HB), ISBN 978-1-4020-8489-8 (e-book)
5. Winsoc Contract 33914, Description of the Work
6. WINSOC, Wireless Sensor Networks with Self-Organisation Capabilities for Critical and
Emergency Applications Specific Targeted Research Project, PUBLISHABLE FINAL
ACTIVITY REPORT
7. IST-2005-2.5.12-WINSOC, D2.2 Components for sensor nodes and transducers
8. http://eo1.gsfc.nasa.gov/new/extended/sensorWeb/sensorWeb.html
9. Karel Charvat, Ota Cerba, Josef Fryml, Martin Pospisil, Petr Horak, Jan Jezek, Petr
Kubicek, Marek Musil, Zbynek Krivanek, Avi Gal, Paolo Capodieci, Maris Alberts
Forestry in situ monitoring and data management, IAALD AFITA WCCA, 2008, Tokyo
10. http://www.opengeospatial.org/projects/groups/sensorweb
11. Sam Bacharach, New Implementations of OGC Sensor Web Enablement Standards,
Article for December 2007 Sensors Magazine
12. http://mapserver.org/development/rfc/ms-rfc-13.html#rfc13
13. http://www.ogcnetwork.net/SOS_Intro
14. http://www.w3schools.com/schema/schema_intro.asp
15. http://en.wikipedia.org/wiki/XML_Schema_%28W3C%29
16. http://java.sun.com/developer/technicalArticles/WebServices/jaxb/
17. https://jaxb.dev.java.net/
18. IST-2005-2.5.12-WINSOC, D6.1 v1.0 ,Pre-deployment Analysis
19. Pavel Gnip, Karel Charvat Maris Alberts2, Marek Musil, Jan Jezek, Zbynek Krivanek5
and Luigi Fusco In situ sensors and Prefarm systém, IAALD AFITA WCCA, 2008,
Tokyo

- 25 -

D2.3 EnviroGRIDS sensor data use and integration guideline

Recommended

Recommended

More Related Content

What's hot

What's hot (10)

Viewers also liked

Viewers also liked (13)

Similar to D2.3 EnviroGRIDS sensor data use and integration guideline

Similar to D2.3 EnviroGRIDS sensor data use and integration guideline (20)

More from envirogrids-blacksee

More from envirogrids-blacksee (17)

Recently uploaded

Recently uploaded (20)

D2.3 EnviroGRIDS sensor data use and integration guideline