Interoperable data management OBSEA


Published on

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

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Interoperable data management OBSEA

  1. 1. Interoperable Data Management andInstrument Control Experiences at OBSEAJoaquin del Rio1, Daniel Mihai Toma1, Thomas C. O’reilly2, Arne H. Bröring3, Antoni Manuel1, Kent L.Headley2, Duane Edgington21Technical University of Catalonia, SARTI – UPC, Spain2Monterey Bay Aquarium Research Institute, MBARI, USA352°North, Initiative for Geospatial Open Source Software GmbH, Münster, GermanyAbstract- In this article we describe our experienceswith interoperable data management andinstrument control standards in the WesternMediterranean Cabled Observatory, OBSEA( (Figure 1). The SARTI researchgroup of the Technical University of Catalonia inVilanova i la Geltrú is in charge of OBSEAobservatory development. SARTI collaborated withthe Monterey Bay Aquarium Research Institute(MBARI) to explore interoperability issues withinthe ESONET project. One of the strong demands ofESONET is that a real-time data web interface fromonline observatories is needed. In order to do so,online data are urgently needed, and some proposedstandards must be applied to ensure interoperabilitybetween instruments and data of multiple Europeanobservatories.I. INTRODUCTIONEach ESONET observatory has its own softwarearchitecture and data management processes.Standard interfaces, protocols, and formats can beapplied on top of each observatory’s datamanagement infrastructure to access observatorydata via the internet in a uniform way. Thesestandards include the Open GeospatialConsortium’s Sensor Web Enablement (SWE),IEEE 1451.1 and initiatives such as DataTurbinefor high speed real time data streaming.The use of standard web interfaces can provideinteroperable data access and visualization fromthe user point of view. Other issues not directlyrelated to data access or visualization must beaddressed to achieve interoperability betweenobservatories at or near the instrument level.Technologies such as MBARI PUCK protocol(for RS232 or IP instruments); the Smart SensorBoard (Ifremer, UPC) and more recently theSensor Interface Descriptor ( are alsobeing tested at OBSEA.Figure 1 OBSEA StructureWe are also investigating standard interfaces toaccess observatory data archives, taking intoaccount the experience of previous initiatives suchas SeaDataNet and standards proposed byINSPIRE for metadata specification (ISO 19115)and NetCDF for data transport.Various standards are available for observatorytime synchronization over IP networks. We havefocused on IEEE 1588, also known as PrecisionTime Protocol (PTP), which is especially suited toapplications that require sub-millisecondsynchronization accuracy. Some currentlyoperational observatories were deployed beforeIEEE 1588 v2 was released, and their junctionboxes are not equipped with IEEE 1588 v2Ethernet switches. We have run experiments to
  2. 2. test PTP using non-PTP switches in order toevaluate the time synchronization accuracy forthese older networks. An experimental setup toprovide GPS timing information to an instrumentusing an IEEE 1588 synchronization network isbeing tested.II. IEEE 1451 AND OGC SWEINTEGRATION INTO ACTUALOBSERVATORIESIn most cases, actual observatories use aproprietary data management and instrumentcontrol framework. We can divide theinteroperability problems into different parts frombottom (instrument or sensor side) to top (useraccess to real-time data and archive). In Figure 2 wecan see a simple approach to achieve interoperableaccess to real time data.Sensor Web Enablement and IEEE 1451 providestandard interfaces at the Internet level, while“hiding” the details of the underlying non-standard observatory infrastructure. Thus a singleweb client can access many diverse observatoriesthrough these standard interfaces.O b s e r v a t o r y F r a m e w o r kC T D _ 1 R B R P u c k E n a b l eP a y l o a d ( S I A M , S e n s o r M L , I E E ET E D S )C T D _ 2 S e a b i r d P u c k E n a b l eP 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 rS 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 tR D VH 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 rO 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 eInteroperabledataAccesInteroperableInstrumentControlFigure 2 Access to real-time data using standards such as SWE SOS or IEEE1451III. PUCK PROTOCOL AND SENSORMLWITH SENSOR INTERFACEDESCRIPTOR (SID)Standard protocols such as MBARI PUCK can beimplemented within the physical instrumentsthemselves. PUCK has been formally proposed asan OGC Sensor Web Enablement standard fromthe Smart Ocean Sensors Consortium (SOSC)where SARTI participates. PUCK does not itselffully implement interoperability, but ratherprovides the lower tier in a hierarchy of standardsthat achieve this goal. PUCK protocol is a simplecommand protocol that helps to automate theconfiguration process by physically storinginformation about the instrument with theinstrument itself. The protocol defines a small“PUCK datasheet” that can be retrieved fromevery compliant instrument; the datasheet includesa universally unique identifier for the instrumentas well as metadata that includes manufacturerand model. Additional information called “PUCKpayload” can be stored and retrieved from theinstrument. PUCK protocol was originally definedfor instruments with an RS232 interface. Aproposed revision (rev 1.4) extends the protocol toEthernet interfaces; the “IP PUCK” protocolincludes the use of Zeroconf to enable easyinstallation and discovery of sensors in an IPnetwork.One possible PUCK payload could be a documentknown as a Sensor Interface Descriptor (SID).SID is a proposed extension to OGC SensorML,and describes an instrument’s command protocolin a standard way. A generic observatory softwarecomponent known as a SID interpreter [9] canoperate any instrument that is described by a SID,
  3. 3. thus eliminating the need for instrument-specificdriver software. PUCK and SID serve to automatethe instrument installation and operation process.The OBSEA team has developed an automaticalgorithm to detect the installation of RS-232PUCK instruments. The host computerperiodically interrogates the serial ports for aPUCK enabled instrument. When the hostreceives a PUCK response from the serial port, thehost retrieves the UUID to determine if a newinstrument has been installed. If so, the hostretrieves the PUCK payload and uses thisinformation to collect data from the newinstrument and register it in order to make its dataavailable using standards like IEEE 1451.1 orOGC SWE.The detection algorithm for IP PUCK-enabledinstruments is based on the Zeroconf standard.When an IP PUCK instrument is plugged into alocal area network (LAN), it automatically gets anIP address and is registered as a PUCK service viaZeroconf. An application that runs in the sameLAN can discover the instrument and retrieve thePUCK payload through PUCK protocol andautomatically register the new instrument in astandard way in.IV. OBSEA DATA ACQUISITIONSYSTEMIn Figure 3 is presented the experimental OBSEAsetup using PUCK and SID [9] technologies inorder to provide an automatic SOS registration forSerial and Ethernet marine instruments.Figure 3 OBSEA experimental setup working with PUCK protocol and SIDFigure 3 shows the deployment of a Sensor Webinfrastructure. A sensor communicates with a dataacquisition system in its specific sensor protocolover a transmission technology such as RS232 orEthernet. To achieve the plug and play capabilitywith PUCK protocol it is used the SID payload
  4. 4. information attached to each instrument. The SIDpayloads describe entirely the functionality of theinstruments in a standard way and are machineand human readable.The SID interpreter runs on the data acquisitionsystem and uses SID instances for the differentsensors of the sensor network to translate betweenthe sensor specific protocol and the SWEprotocols. The interpreter is responsible to registera sensor at a SWE service and to upload sensordata to an SOS (Sensor Observation Service) forexample. Also, it is responsible for the oppositecommunication direction and forwards tasksreceived by an SPS (Sensor Planning Service) to asensor.V. INTERPRETER IMPLEMENTATIONThe implementation of the SID interpreter is donein Java code and is based on the OSGi frameworkwhich is extendible by pluggable and looselycoupled components. A central Managercomponent controls the workflow. First, the SIDParser is used to read in the SID document of thesensor. Depending on the specified addressingparameters, a particular Data Source Connectorimplementation (e.g. for RS232 connections) ischosen to connect to the sensor. Based on theprotocol definition of the SID, the ProtocolTransformer communicates with the sensor in abi-directional way.The SOS Connector triggers the SOS operation.RegisterSensor to add the new sensor to theSensor Web and executes the InsertObservationoperation to upload sensor data as observations toan SOS.CONCLUSIONS & FUTURE WORKIn this paper, we outline the need for mechanismsto close the interoperability gap between marinesensors and the Sensor Web. We bridge this gapby introducing a Data Management System usingPUCK protocol and SID model based onSensorML standard which enables the declarativedescription of sensor interfaces. Based on the SIDmodel, interpreters can be built, which areindependent of particular sensor technology, andare able to automatically generate communicationlogic to connect sensors to the Sensor Web. Thenext step on our implementation and developmentof interoperable technologies in OBSEAobservatory is to extend this data acquisitionsystem to IEEE 1451.1 HTTP standard.REFERENCES[1] Arne Broering, Stefan Below, “OpenGIS® SensorInterface Descriptors”, Open Geospatial ConsortiumInc. 2010-06-30, OGC 10-134.[2] George Percivall, Carl Reed "OGC® Sensor WebEnablement 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 MihaiToma et al. “Smart sensor interface for sea bottomobservatories”, Instrumentation Viewpoint, Num.8,pp96-98, autumn 2009.[4] Kent L. Headley, Thomas C. O’Reilly, et al, “ManagingSensor Network Configuration and Metadata in OceanObservatories Using Instrument Pucks” ThirdInternational Workshop on Scientific Use of SubmarineCables and Related Technologies, 25 27 June 2003.[5] Joaquin del Rio, Tom OReilly, Kent Headley, DanielMihai Toma, et al, “Evaluation of MBARI PUCKprotocol for interoperable ocean observatories”,Instrumentation Viewpoint, Num.8, pp87-91, autumn2009.[6] Lee, K., “IEEE 1451: A Standard in Support of SmartTransducer Networking”, Proceedings of the 17th IEEEInstrumentation and Measurement TechnologyConference, Baltimore, MD, May 1-4, 2000, Vol. 2,p.525-528.[7] Marc Nogueras, Carola Artero, Joquín del Rio, AntoniMànuel, David Sarrià, "Control and acquisition systemdesign for an Expandable Seafloor Observatory", IEEEOCEANS09, 11-14 May, Bremen, Germany.[8] OReilly, T. [et al.], “Instrument interface standards forinteroperable ocean sensor networks” MTS/IEEEOCEANS09 Balancing technology with future needs".Bremen: IEEE Press. Institute of Electrical andElectronics Engineers, 2009, p. 1-10.[9] Bröring, A., S. Below & T. Foerster (2010): DeclarativeSensor Interface Descriptors for the Sensor Web.WebMGS 2010: 1st International Workshop on PervasiveWeb Mapping, Geoprocessing and Services. ISPRS, 2010,38. 26.-27. August 2010. Como, Italy..