From Ocean Sensors to Traceable Knowledge by Harmonizing Ocean Observing Systems

EarthzineArticles, Earth Observation, Oceans, Original, Sections, Technology

Cropped image of a map of Slovenia

Table 1 Some of the sensors planned for deployment on the PLOCAN cabled observatory, with sensor measurement range, accuracy and sampling requirements to be determined. The fixed station will be complemented with mobile sampling platforms with fine spatial scale resolution (<1m). Mobile platforms generally will host conductivity, temperature, pressure sensors and a current profiler. Hydrophones are also planned on these platforms for acoustic characterization and monitoring of the area.

Table 1: Some of the sensors planned for deployment on the PLOCAN cabled observatory, with sensor measurement range, accuracy and sampling requirements to be determined. The fixed station will be complemented with mobile sampling platforms with fine spatial scale resolution (<1m). Mobile platforms generally will host conductivity, temperature, pressure sensors and a current profiler. Hydrophones are also planned on these platforms for acoustic characterization and monitoring of the area.

JoaquÌ_ni del Rio and Eric Deloryii

Society is requesting more than ever being better informed on the state and effects of Earth’s changing oceans. This has direct implications on ocean observing systems, including scientific planning and technology. For instance better knowledge implies that data on health, climate and overall dynamics of our oceans have a known level of quality, be up-to-date, be easily discoverable, be easily searchable both in time and space, and be human- and machine-readable in order to generate faster decisions when and where needed. Requirements with respect to spatial regions and scales (seas and ocean basins, from millimeters to hundreds of kilometers), time scope and scales (past, present, future, from microseconds to decades) indeed have direct implications on observing systems’ spatio-temporal sampling capabilities. Possibly high spatial and temporal resolution also means unprecedented amounts of data, communication bandwidth and processing power needs. Technological implications are thus quite substantial and, in this short article, we will try to provide a review of some initiatives of global and local focus that are aiming to respond to at least some of these needs, starting with the application of the Global Earth Observation System of Systems (GEOSS) guidelines to ocean observatories. Then we will address real scenarios in real ocean observing facilities, first with the European Seas Observatory Network and the European Multidisciplinary Seafloor Observation (ESONET-EMSO), then two recently associated Spanish initiatives, the Oceanic Platform of the Canary Islands (PLOCAN) infrastructure and deep sea observatory in the Canary Islands, and the Expandable Seafloor Observatory (OBSEA) shallow water Western-Mediterranean observatory of the Technical University of Catalonia, one of the first real-time ocean observatories implemented with state-of- the-art interoperable concepts, down to the sensor interface.

Instant Knowledge through GEOSS

From a user’s perspective, the apparent ease of downloading satellite images from the internet hides the daunting reality that it remains very difficult for society at large, i.e. from individuals to intergovernmental organizations, to obtain an answer to apparently simple questions such as: Is there a toxic algal bloom nearing our aquaculture farms? Has ocean temperature rise had a consequence on sea-level in my region in the last couple of years? In seismogenic areas these questions may take more critical tone: Are there sensors monitoring possible landslides on our shore and, if so, do they connect to an operational (read: useful) alert system? Will I be warned in due time in case of an abnormal tidal wave? Can we identify trends and predict climate critical inflection points, thresholds and discontinuities with sufficient reliability to make predictions worthy of trust? These issues are the whole point of the definition of the so-called GEOSS societal benefit areas (SBAs). As a matter of fact, ecosystems, biodiversity, disasters, health, water, energy and agriculture (also think aquaculture in our context), climate, and weather are the nine SBAs in GEOSS and all are reflected in ocean science and are being investigated via ocean observing systems in many places and continuously. The success of building and operating the GEOSS will consequently and largely also depend on efficient knowledge delivery of ocean observing systems.

Fig. 1 The coastal node extends from the shallow water areas' observing component down to 1000m (initial) and 3000m (extension). End of the cable initial stretch is approximately 10 nautical miles from the shore.

Fig. 1: The coastal node extends from the shallow water areas' observing component down to 1000m (initial) and 3000m (extension). End of the cable initial stretch is approximately 10 nautical miles from the shore.

Better Information: GEOSS and Data Quality

The GEOSS is tasked with providing guidelines on quality assurance/quality control. Thus, the GCI IOC (GEOSS Common Infrastructure Initial Operating Capability) task force has released a provisional set of requirements for GEOSS registered components and services (also currently categorized as best-practice) among which content quality management is required under the form of documentation, that will be provided by the service provider. Herein, ‰ÛÏidentification of the quality of registry content should be addressed and published by each GCI component operator‰Û and ‰ÛÏEach GCI registry offer shall document its operational plan to declare the level of expected information content quality and to monitor, manage, and assure the quality of such content on a specified basis. Plan shall identify the responsible parties required for content management.‰Û Also note worthy, the component will demonstrate the overall quality of service in GEOSS. Accuracy assessment and reporting of measurements uncertainty is essential to assure data products consistency and interoperability, implying that the instrument calibration and product validation need to be continuously monitored and traceable to standards [1]. In ocean observatories, bio-fouling and sediment are the prevailing factors that degrade and limit data quality. This is particularly true in conductivity/temperature/depth, chlorophyll, dissolved oxygen, and turbidity sensors. In [1] many, generic quality assurance requirements are highlighted, among which, the necessary provision of instrument characteristics and associated performance descriptions are provided in common formats for all sensors and across all observatories. In the following, we will show two standards able to encode such metadata and that are currently under test.

How Does This Translate into Facts?

A first step lies in adding the necessary connectivity and intelligence that will provide easy access to high quality data rapidly, that to some extent a computer can process without the intervention of a human operator. In this short article we will show how ESONET-EMSO and two associated initiatives in Spain are planning or already implementing the necessary technology, in situ.

ESONET-EMSO and the GEOSS

The European Seas Observatory Network (ESONET), a future component of and the European deep-sea contribution to the GEOSS, integrates all European deep-sea observatories under a common objective, i.e. the interconnection, standardization and interoperability of current and future infrastructures that produce ocean data collected from the seabed. ESONET-EMSO is one of the many large scale ocean observing initiatives taking place around the globe, such as Dense Oceanfloor Network system for Earthquakes and Tsunamies (Japan), NEPTUNE (Canada), and the Consortium for Ocean Leadership (USA).

Fig. 2 Standard implementation diagram for a generic smart and web-enabled multi-sensor system. Note that the IEEE1451 is optional in the scheme (CANBus and CANopen are other potential solutions), and if implemented can be plugged on conventional standards as a physical add-on. Sensor can be a current meter, a hydrophone, a multi-sensor system like a CTD or a multi-axis sensor such as an acoustic intensity sensor, etc. A sensor can also be more complex, integrating sound velocity measurement (e.g. either directly or based on salinity, pressure and temperature information) for further acoustic signal processing algorithms. Both sensor and signal processor characteristics can be encoded in a SensorML  file and hence be documented in standard format while remaining transparent to the user. With regard to real-world implementation: OBSEA currently serves IEEE1451 and Sensor Web Enablement. The ESONET Sensor registration interface has SensorML and IEEE1451 up and running and communicating for sensor metadata registration.

Fig. 2: Standard implementation diagram for a generic smart and web-enabled multi-sensor system. Note that the IEEE1451 is optional in the scheme (CANBus and CANopen are other potential solutions), and if implemented can be plugged on conventional standards as a physical add-on. Sensor can be a current meter, a hydrophone, a multi-sensor system like a CTD or a multi-axis sensor such as an acoustic intensity sensor, etc. A sensor can also be more complex, integrating sound velocity measurement (e.g. either directly or based on salinity, pressure and temperature information) for further acoustic signal processing algorithms. Both sensor and signal processor characteristics can be encoded in a

Proposed Recommendations for the Registration of ESONET-EMSO in GEOSS

Considering the different states of progress and the overall distributed and heterogeneous nature of ESONET-EMSO physical and virtual infrastructures, a coherent registration of ESONET-EMSO within GEOSS can be approached through surprisingly simple procedures considering the complexity of the system. Those can be summarized as follows:

‰Û¢ A first recommendation is that in ESONET-EMSO we identify which observatories are ready today to offer a data access service as well as the standards these services are based on. If services are not implementing a GEOSS standard, the method utilized in the encoding of data shall be registered as special arrangement

‰Û¢ In an initial period, to accelerate the registration of current operational resources, registered services can be owned and administrated by the regional observatory owner, which means that each service will come up with its own URL and service description with direct connection to the observatory cyber-infrastructure. This registration will have to be accepted by the ESONET-EMSO Steering Committee, which verifies compliance with the ESONET Label.

‰Û¢ When ESONET-EMSO is ready to act as a service provider for all registered services, URLs will be updated accordingly on the GEOSS component and services registry. This will imply that the ESONET-EMSO clearinghouse takes charge of the registration process for new services from then on. These URLs will transparently redirect to the regional observatory services URLs. This will insure that the user accessing these services can maintain their connection active independently of a change in the regional URLs as they will be updated by the regional observatory on the ESONET-EMSO clearinghouse service registry.

‰Û¢ ESONET-EMSO shall eventually be, as a component, the registrar of these services for which there shall be a single point of contact.

‰Û¢ ESONET-EMSO will create a registry along with a registration interface where all regional services will be registered so as to enable ESONET-EMSO to keep the GEOSS service registry updated.

‰Û¢ ESONET-EMSO, acting as a clearinghouse, implies that regional services be tested by expert users prior to registering these services on the GEOSS service registry.

‰Û¢ Service operation shall be insured by the regional observatory, which will inform the ESONET-EMSO clearinghouse on disconnection, failures, and maintenance activities for that service. ESONET-EMSO will update the GEOSS registry accordingly.

‰Û¢ ESONET-EMSO will be able to provide its own services as an integrated structure of regional observatories’ services. These, for example, could be services integrating data from different regional observatories. (These could be called ESONET-EMSO integrated services.)

‰Û¢ ESONET-EMSO will encourage the use of a reduced set of standards and will explicitly validate a specific standard proposed by a particular regional observatory.

For specific information on data interoperability, INSPIRE provides implementing rules and metadata requirements which closely reflect GEOSS guidelines, beside the resulting European directive which should guarantee its progressive implementation. We will now describe the implementation plans that will be pursued in PLOCAN and OBSEA, for which some of these principles are already in operation. These two observatories will provide data services compliant with the GEOSS guidelines, starting with interoperability concepts right from the sensor. Thus in the following, sensor interoperability and how it serves better data products is the main focus.

Fig. 3 Two scuba divers performing maintenance tasks on OBSEA, located next to an artificial reef.

Fig. 3: Two scuba divers performing maintenance tasks on OBSEA, located next to an artificial reef.

The PLOCAN Observatory Infrastructure Interoperability Plans

The PLOCAN observatory is composed of: 1.- a coastal node (Fig. 1), supported by two stations, located at 50 to 100m and 1500 to 2000m (cabled station) depth respectively and 2.- a regional node, which is an extension of the recently upgraded ESTOC station. These two nodes respond to a comprehensive series of scientific needs, in the region and for the Atlantic Ocean at large, providing unprecedented spatiotemporal sampling possibilities. Main scientific interests in this respect are the continuous and real-time monitoring of global change and ocean acidification, water-column and deep-sea ecosystems, ocean biogeochemistry and geophysics. PLOCAN’s cyber infrastructure will respond to the above guidelines for interoperability: this will be achieved at software level, implementing global data sharing principles in conformance with the INSPIRE directive (see above) and open standards. At hardware level most of the instrumentation is planned to follow the recommendations of ESONET-EMSO, thus ensuring technological integration at European level (i.e. standard scientific package, easy instrument development, exchange, testing, shared use of deployed resources and deployment procedures). Physical or virtual standard interfaces will be used for observatory sensors and systems interconnection, focusing on interoperability with regard to sensor metadata and physical connection. Time synchronization will be achieved across sensor platforms through the implementation of standard timing protocols (PTP being a candidate, see OBSEA section below), in agreement with time precision requirements in fields like seismic and acoustics. Generally, the PLOCAN observatory nodes and sensor packages will seek progressive compliance and harmonization with current practices in ocean and earth observation systems. This will be achieved by implementing similar concepts as those described in Fig. 2.

OBSEA Interoperability Plans And Implementation

OBSEA is a cabled seafloor observatory located 4 km off the Vilanova i la Geltru coast in a fishing protected area and connected to the coast by an energy and communication mixed cable. The exact location of the OBSEA is: Lat. 41å¡10’54.87″N; Long. 1å¡45’8.43″E.

Fig. 4 How standards make ocean sensors and data pop-up on a web-browser. The objective goes further than displaying numbers with SI Units: this is, in fact, the user-end--a machine-readable format is also provided through open standards for computers to collect, process and trigger useful events like alerts. Here the Openioos site is used from a web browser.

Fig. 4: How standards make ocean sensors and data pop-up on a web-browser. The objective goes further than displaying numbers with SI Units: this is, in fact, the user-end--a machine-readable format is also provided through open standards for computers to collect, process and trigger useful events like alerts. Here the Openioos site is used from a web browser.

The main advantage of having a cabled observatory is to be able to provide the power supply to the scientific instruments together with a high bandwidth communication link. Continuous real time data is available through an optical Ethernet network.

Tests of Sensor Web Enablement (SWE) from the Open Geospatial Consortium (OGC) and IEEE 1451.0 standards are being carried out to share data in a standard way through the internet [2]. Other initiatives have been tested such as PUCK protocol for plug & play instruments and DataTurbine for real-time data streaming over the internet. All these tests were implemented in parallel on the main software architecture allowing for the experimentation of new data management standards, as well as data communication and systems interoperability on a real ocean observatory [3, 4]. Transducer Electronic Data Sheets (‰ÛÏTEDS‰Û) are a key concept of IEEE 1451. A TEDS describes characteristics and capabilities of components such as transducers, interfaces and communications links in a standard way. Applications can retrieve TEDS through the IEEE 1451 protocols to dynamically discover instruments, sensors and actuators as well as other system metadata. Another format to store sensor metadata in a standard way is SensorML, proposed by the OGC. In our context, both SensorML and TEDS encodings could be stored in an instrument using PUCK protocol [4]. These encodings can also be stored on an on-line repository or any interface that provides retrievable data storage over the network. Other standards have been implemented on OBSEA such as the IEEE 1588 protocol [5] for high precision timing requirements, particularly required in seismic and acoustic array processing.

OGC Sensor ML and Sensor Web Enablement

Sensor Web refers to Web-accessible sensor networks and archived sensor data and metadata that can be discovered and accessed using standard protocols and Application Program Interfaces (APIs). The Open Geospatial Consortium is currently building a framework of open standards for exploiting Web-connected sensors and sensor systems, such as flood gauges, air pollution monitors, stress gauges on bridges, satellite-borne earth imaging devices, and other sensors and sensor systems [6]. The OGC-SWE initiative focuses on developing a set of standards to enable the discovery, exchange, and processing of sensor observations and tasking of sensor systems. SensorML is a key component of SWE and provides standard models for sensors and an XML encoding for describing any process associated with the sensors. All processes define their inputs, outputs, parameters, and methods, as well as provide relevant metadata. SensorML can be used to describe instrument and systems properties. As SensorML is very general it is important to define minimal description content for each instrument. Mapping between instrument properties described in SensorML and TEDS, and user-friendly interfaces to generate these encodings are being developed ‰ÛÒ see here some ESONET SensorML instance template examples for a CTD and an ADCP resulting from prior consensus between the ESONET-EMSO Sensor Registry and Oceansites.

Next Steps

While middleware has just started to spread over ocean sensors and technologies it is likely that current efforts to integrate observing systems under a set of common practices may eventually result in implementations which will probably look different. We have tried to show that technical priorities are now evolving towards harmonization of the overall system, more intuitive solutions by injecting commonly accepted protocols and encodings without having to modify existing technologies. While observatory owners are working on the implementation of such concepts, we must now think of inventing the tools on the user end, the ocean data ‰ÛÏclient‰Û. A GEOSS universal software application would be quite handy when ocean and earth observing systems meet the interoperability milestone. Standards will evolve and new standards will also be created, based on the lessons learned. Standard Development Organizations are already on this path, such as the OGC and the IEEE (see SCC40).

Acknowledgements

Part of the work addressed in this article was funded by the EU FP6 ESONET Contract 036851, the ISOTER Project (co-funded by the Agencia Canaria de InvestigaciÌ_n, InnovaciÌ_n y Sociedad de la InformaciÌ_n, Gobierno de Canarias, Spain). Thanks to Juan Carlos Elgue for the GIS rendering application for the PLOCAN coastal observatory area. We are also indebted to the ESONET-EMSO, OBSEA and PLOCAN teams.

References:

[1] S. Ungar, P. Campbell, M. Rast, and C. Cao, “Data Quality Guidelines for GEOSS Consideration-The CEOS Working Group on Calibration and Validation (WGCV).” in IEEE Geoscience and Remote Sensing Symposium, 2007. IGARSS 2007, 2007.

[2] E. Y. Song and L. Kang, “Understanding IEEE 1451-Networked smart transducer interface standard – What is a smart transducer?,” Instrumentation & Measurement Magazine, IEEE, vol. 11, pp. 11-17, 2008.

[3] J. del Rio, T. O’Reilly, K. Headley, D. M. Toma, N. Cater, C. Rueda, D. Edgington, C. Ng, I. Bghiel, L. Bermudez, J. Zedlitz, F. Johnson, G. Johnson, E. Davis, R. Phillips, S. Tilak, T. Fountain, E. Delory, A. Manuel, and C. Waldmann, “Evaluation of MBARI PUCK protocol for interoperable ocean observatories,” in MARTECH’09 INTERNATIONAL WORKSHOP ON MARINE TECHNOLOGY, Spain, 2009.

[4] T. O’Reilly, J. Del RÌ_o, D. Toma, E. Delory, and A. Manuel, “Instrument Interface Standards for interoperable Ocean Sensor Networks,” in IEEE Oceans 2009, Bremen, Germany, 2009.

[5] J. del Rio, D. Toma, A. MÌÊnuel, and H. Ramos, “Evaluation of IEEE1588 applied to synchronised acquisition in marine sensor networks ” in IMEKO XIX WORLD CONGRESS, Lisbon, Portugal, 2009.

[6] M. Botts, G. Percivall, C. Reed, and J. Davidson, “OGC Sensor Web Enablement: Overview and High Level Architecture.,” 2007.

iUnivesitat Polit̬cnica de Catalunya. SARTI. Rambla ExposiciÌ_n, 24. Vilanova i la Geltru, Barcelona, SPAINe-mail: joaquin.del.rio@upc.edu

iidBscale Sensing Technologies, C/ LeÌ_n y Castillo 25, Telde 35200, SPAIN

e-mail: edelory@ieee.org

iiiSensorML is a standard from the Open Geospatial Consortium that provides standard models and an XML encoding for describing sensors and measurements.