Interoperable Data Management - Environmental Monitoring - Pollution - Instrument - Calibration - 24/7 - Big Data

1. Interoperable Data Management and
Instrument Control Experiences at OBSEA
Joaquin del Rio1
, Daniel Mihai Toma1
, Thomas C. O’reilly2
, Arne H. Bröring3
, Antoni Manuel1
, Kent L.
Headley2
, Duane Edgington2
1
Technical University of Catalonia, SARTI – UPC, Spain
2
Monterey Bay Aquarium Research Institute, MBARI, USA
3
52°North, Initiative for Geospatial Open Source Software GmbH, Münster, Germany
Abstract- In this article we describe our experiences
with interoperable data management and
instrument control standards in the Western
Mediterranean Cabled Observatory, OBSEA
(www.obsea.es) (Figure 1). The SARTI research
group of the Technical University of Catalonia in
Vilanova i la Geltrú is in charge of OBSEA
observatory development. SARTI collaborated with
the Monterey Bay Aquarium Research Institute
(MBARI) to explore interoperability issues within
the ESONET project. One of the strong demands of
ESONET is that a real-time data web interface from
online observatories is needed. In order to do so,
online data are urgently needed, and some proposed
standards must be applied to ensure interoperability
between instruments and data of multiple European
observatories.
I. INTRODUCTION
Each ESONET observatory has its own software
architecture and data management processes.
Standard interfaces, protocols, and formats can be
applied on top of each observatory’s data
management infrastructure to access observatory
data via the internet in a uniform way. These
standards include the Open Geospatial
Consortium’s Sensor Web Enablement (SWE),
IEEE 1451.1 and initiatives such as DataTurbine
for high speed real time data streaming.
The use of standard web interfaces can provide
interoperable data access and visualization from
the user point of view. Other issues not directly
related to data access or visualization must be
addressed to achieve interoperability between
observatories at or near the instrument level.
Technologies such as MBARI PUCK protocol
(for RS232 or IP instruments); the Smart Sensor
Board (Ifremer, UPC) and more recently the
Sensor Interface Descriptor (52North.org) are also
being tested at OBSEA.
Figure 1 OBSEA Structure
We are also investigating standard interfaces to
access observatory data archives, taking into
account the experience of previous initiatives such
as SeaDataNet and standards proposed by
INSPIRE for metadata specification (ISO 19115)
and NetCDF for data transport.
Various standards are available for observatory
time synchronization over IP networks. We have
focused on IEEE 1588, also known as Precision
Time Protocol (PTP), which is especially suited to
applications that require sub-millisecond
synchronization accuracy. Some currently
operational observatories were deployed before
IEEE 1588 v2 was released, and their junction
boxes are not equipped with IEEE 1588 v2
Ethernet switches. We have run experiments to

2. test PTP using non-PTP switches in order to
evaluate the time synchronization accuracy for
these older networks. An experimental setup to
provide GPS timing information to an instrument
using an IEEE 1588 synchronization network is
being tested.
II. IEEE 1451 AND OGC SWE
INTEGRATION INTO ACTUAL
OBSERVATORIES
In most cases, actual observatories use a
proprietary data management and instrument
control framework. We can divide the
interoperability problems into different parts from
bottom (instrument or sensor side) to top (user
access to real-time data and archive). In Figure 2 we
can see a simple approach to achieve interoperable
access to real time data.
Sensor Web Enablement and IEEE 1451 provide
standard interfaces at the Internet level, while
“hiding” the details of the underlying non-
standard observatory infrastructure. Thus a single
web client can access many diverse observatories
through these standard interfaces.
O b s e r v a t o r y F r a m e w o r k
C T D _ 1 R B R P u c k E n a b l e
P a y l o a d ( S I A M , S e n s o r M L , I E E E
T E D S )
C T D _ 2 S e a b i r d P u c k E n a b l e
P a y l o a d ( S e n s o r M L , I E E E T E D S )
S W E S O S S e r v e r
S O S C l i e n t W e b I E E E 1 4 5 1 C l i e n t D a t a T u r b i n e C l i e n t
R D V
H T T P I E E E 1 4 5 1 . 0 S e r v e r D a t a T u r b i n e R i n g B u f f e r
O b s e r v a t o r y D a t a M a n a g e m e n t a n d I n s t r u m e n t A r c h i t e c t u r e
InteroperabledataAccesInteroperableInstrumentControl
Figure 2 Access to real-time data using standards such as SWE SOS or IEEE1451
III. PUCK PROTOCOL AND SENSORML
WITH SENSOR INTERFACE
DESCRIPTOR (SID)
Standard protocols such as MBARI PUCK can be
implemented within the physical instruments
themselves. PUCK has been formally proposed as
an OGC Sensor Web Enablement standard from
the Smart Ocean Sensors Consortium (SOSC)
where SARTI participates. PUCK does not itself
fully implement interoperability, but rather
provides the lower tier in a hierarchy of standards
that achieve this goal. PUCK protocol is a simple
command protocol that helps to automate the
configuration process by physically storing
information about the instrument with the
instrument itself. The protocol defines a small
“PUCK datasheet” that can be retrieved from
every compliant instrument; the datasheet includes
a universally unique identifier for the instrument
as well as metadata that includes manufacturer
and model. Additional information called “PUCK
payload” can be stored and retrieved from the
instrument. PUCK protocol was originally defined
for instruments with an RS232 interface. A
proposed revision (rev 1.4) extends the protocol to
Ethernet interfaces; the “IP PUCK” protocol
includes the use of Zeroconf to enable easy
installation and discovery of sensors in an IP
network.
One possible PUCK payload could be a document
known as a Sensor Interface Descriptor (SID).
SID is a proposed extension to OGC SensorML,
and describes an instrument’s command protocol
in a standard way. A generic observatory software
component known as a SID interpreter [9] can
operate any instrument that is described by a SID,

3. thus eliminating the need for instrument-specific
driver software. PUCK and SID serve to automate
the instrument installation and operation process.
The OBSEA team has developed an automatic
algorithm to detect the installation of RS-232
PUCK instruments. The host computer
periodically interrogates the serial ports for a
PUCK enabled instrument. When the host
receives a PUCK response from the serial port, the
host retrieves the UUID to determine if a new
instrument has been installed. If so, the host
retrieves the PUCK payload and uses this
information to collect data from the new
instrument and register it in order to make its data
available using standards like IEEE 1451.1 or
OGC SWE.
The detection algorithm for IP PUCK-enabled
instruments is based on the Zeroconf standard.
When an IP PUCK instrument is plugged into a
local area network (LAN), it automatically gets an
IP address and is registered as a PUCK service via
Zeroconf. An application that runs in the same
LAN can discover the instrument and retrieve the
PUCK payload through PUCK protocol and
automatically register the new instrument in a
standard way in.
IV. OBSEA DATA ACQUISITION
SYSTEM
In Figure 3 is presented the experimental OBSEA
setup using PUCK and SID [9] technologies in
order to provide an automatic SOS registration for
Serial and Ethernet marine instruments.
Figure 3 OBSEA experimental setup working with PUCK protocol and SID
Figure 3 shows the deployment of a Sensor Web
infrastructure. A sensor communicates with a data
acquisition system in its specific sensor protocol
over a transmission technology such as RS232 or
Ethernet. To achieve the plug and play capability
with PUCK protocol it is used the SID payload

4. information attached to each instrument. The SID
payloads describe entirely the functionality of the
instruments in a standard way and are machine
and human readable.
The SID interpreter runs on the data acquisition
system and uses SID instances for the different
sensors of the sensor network to translate between
the sensor specific protocol and the SWE
protocols. The interpreter is responsible to register
a sensor at a SWE service and to upload sensor
data to an SOS (Sensor Observation Service) for
example. Also, it is responsible for the opposite
communication direction and forwards tasks
received by an SPS (Sensor Planning Service) to a
sensor.
V. INTERPRETER IMPLEMENTATION
The implementation of the SID interpreter is done
in Java code and is based on the OSGi framework
which is extendible by pluggable and loosely
coupled components. A central Manager
component controls the workflow. First, the SID
Parser is used to read in the SID document of the
sensor. Depending on the specified addressing
parameters, a particular Data Source Connector
implementation (e.g. for RS232 connections) is
chosen to connect to the sensor. Based on the
protocol definition of the SID, the Protocol
Transformer communicates with the sensor in a
bi-directional way.
The SOS Connector triggers the SOS operation.
RegisterSensor to add the new sensor to the
Sensor Web and executes the InsertObservation
operation to upload sensor data as observations to
an SOS.
CONCLUSIONS & FUTURE WORK
In this paper, we outline the need for mechanisms
to close the interoperability gap between marine
sensors and the Sensor Web. We bridge this gap
by introducing a Data Management System using
PUCK protocol and SID model based on
SensorML standard which enables the declarative
description of sensor interfaces. Based on the SID
model, interpreters can be built, which are
independent of particular sensor technology, and
are able to automatically generate communication
logic to connect sensors to the Sensor Web. The
next step on our implementation and development
of interoperable technologies in OBSEA
observatory is to extend this data acquisition
system to IEEE 1451.1 HTTP standard.
REFERENCES
[1] Arne Broering, Stefan Below, “OpenGIS® Sensor
Interface Descriptors”, Open Geospatial Consortium
Inc. 2010-06-30, OGC 10-134.
[2] George Percivall, Carl Reed "OGC® Sensor Web
Enablement Standards", Sensors & Transducers Journal,
Vol.71, Issue 9, September 2006, pp.698-706, ISSN 1726-
5479.
[3] Joaquín Del Río Fernández, Yves Auffret, Daniel Mihai
Toma et al. “Smart sensor interface for sea bottom
observatories”, Instrumentation Viewpoint, Num.8,
pp96-98, autumn 2009.
[4] Kent L. Headley, Thomas C. O’Reilly, et al, “Managing
Sensor Network Configuration and Metadata in Ocean
Observatories Using Instrument Pucks” Third
International Workshop on Scientific Use of Submarine
Cables and Related Technologies, 25 27 June 2003.
[5] Joaquin del Rio, Tom O'Reilly, Kent Headley, Daniel
Mihai Toma, et al, “Evaluation of MBARI PUCK
protocol for interoperable ocean observatories”,
Instrumentation Viewpoint, Num.8, pp87-91, autumn
2009.
[6] Lee, K., “IEEE 1451: A Standard in Support of Smart
Transducer Networking”, Proceedings of the 17th IEEE
Instrumentation and Measurement Technology
Conference, Baltimore, MD, May 1-4, 2000, Vol. 2,
p.525-528.
[7] Marc Nogueras, Carola Artero, Joquín del Rio, Antoni
Mànuel, David Sarrià, "Control and acquisition system
design for an Expandable Seafloor Observatory", IEEE
OCEANS09, 11-14 May, Bremen, Germany.
[8] O'Reilly, T. [et al.], “Instrument interface standards for
interoperable ocean sensor networks” MTS/IEEE
OCEANS'09 Balancing technology with future needs".
Bremen: IEEE Press. Institute of Electrical and
Electronics Engineers, 2009, p. 1-10.
[9] Bröring, A., S. Below & T. Foerster (2010): Declarative
Sensor Interface Descriptors for the Sensor Web.
WebMGS 2010: 1st International Workshop on Pervasive
Web Mapping, Geoprocessing and Services. ISPRS, 2010,
38. 26.-27. August 2010. Como, Italy.
.