A sensor web architecture for integrating smart oceanographic sensors into the semantic sensor web

(c) 2017 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. IEEE JOURNAL OF OCEANIC ENGINEERING 1 Peer-Reviewed Technical Communication A Sensor Web Architecture for Integrating Smart Oceanographic Sensors into the Semantic Sensor Web Joaqu´ ın del R´ ıo, Member, IEEE, Daniel Mihai Toma, Enoc Mart´ ınez, Thomas C. O’Reilly, Eric Delory, Jay S. Pearlman, Life Fellow, IEEE, Christoph Waldmann, and Simon Jirka Abstract—Effective ocean and coastal data management are needed to manage marine ecosystem health. Past ocean and coastal data management systems were often very specific to a particular application and region, but this focused approach often lacks real-time data and sharing/interoperating capability. The challenge for the ocean observing community is to devise standards and practices that enable integration of data from sensors across devices, manufacturers, users, and domains to enable new types of applications and services that facilitate much more comprehensive understanding and analyses of marine ecosystem. A given kind of sensor may be deployed on various platforms such as floats, gliders or moorings, and thus must be integrated with different operation, and data management systems. Simplifying the integration process in existing or newly established observing systems would benefit system operators and is important for the broader application of diverse sensors. This paper describes a geospatial “sensor web” architecture developed by the “NeXOS” project for ocean and coastal data management, based on the concepts of spatial data infrastructure and the Sensor Web Enablement framework of the Open Geospatial Consortium. This approach reduces the effort to propagate data from deployed sensors to users. To support the realization of the proposed Next generation Ocean Sensors (NeXOS) architecture, hardware and software specifications for a Smart Electronic Interface for Sensors and Instruments (SEISI) are described. SEISI specifies small lower-power electronics, minimal operating system, and standards-basedresearch software to enable web-based Manuscript received July 23, 2017; accepted October 24, 2017. This work was supported in part by the NeXOS Project. NeXOS is a collaborative project funded by the European Commission Seventh Framework Programme, under the call OCEAN-2013.2—The Ocean of Tomorrow 2013—Innovative multifunctional sensors for in situ monitoring of marine environment and related maritime activities, under Grant 614102, and it is composed of 21 partners including SMEs, companies, and scientific organizations from six European countries; visit: www.nexosproject.eu. This work was also supported in part by the Fixed Point Open Ocean Observatory (FixO3) Network Project from the European Union’s Seventh Programme for research, technological development, and demonstration under Grant 312463. FixO3 seeks to integrate European open ocean fixed point observatories and to improve access to these key installations for the broader community. The proposal has 29 partners drawn from academia, research institutions, and SMEs; visit: http://www.fixo3.eu/. (Corresponding author: Joaqu´ ın del R´ ıo.) Guest Editor: O. Zielinski. J. del R´ ıo, D. M. Toma, and E. Mart´ ınez are with the Department Electronics, SARTI Research Group, Universitat Polit` ecnica de Catalunya, Vilanova i la Geltru 08800, Spain (e-mail: [email protected]; daniel.mihai.toma@ upc.edu). T. C. O’Reilly is with the Monterey Bay Aquarium Research Institute, Road Moss Landing, CA 95039-9644 USA (e-mail: [email protected]). E. Delory is with the M Oceanic Platform of the Canary Islands, Telde 35200, Spain (e-mail: [email protected]). J. S. Pearlman is with the IEEE France Section, Paris 75116, France (e-mail: jay[email protected]). C. Waldmann is with the MARUM—Center for Marine Environmental Sciences, University of Bremen, Bremen 28359, Germany (e-mail: waldmann@ marum.de). S. Jirka is with the 52°North Initiative for Geospatial Open Source Software GmbH, Muenster 48155, Germany (e-mail: [email protected]g). Digital Object Identifier 10.1109/JOE.2017.2768178 sharing, discovery, exchange, and processing of sensor observations as well as operation of sensor devices. An experimental scenario is presented in which sensor data from a low-power glider with low-bandwidth intermittent satellite communications is integrated into the geospatial sensor web using the NeXOS architecture. Index Terms—Interoperability, metadata, Sensor Model Language (sensorML), standards. NOMENCLATURE XML XML is a markup language that defines a set of rules for encoding documents in a format that is both human readable and machine readable. EXI Binary XML format for exchange of data on a computer network. FP7 Seventh Framework Programme, European union research and development funding program. GEOSS GEOSS is being built by the Group on Earth Observations on the basis of a 10-Year Implementation Plan running from 2005 to 2015. Interoperability A characteristic of a system, whose interfaces are completely understood, to work with other systems, present or future, in either implementation or access, without any restrictions. JSON A light-weight data interchange format. Metadata Data that provides information about other data. NeXOS FP7 project lead by plocan.eu. OGC A standards organization for geospatial information systems. PUCK This standard defines a protocol for RS232 and Ethernet connected sensors. PUCK addresses installation and configuration challenges for sensors by defining a standard sensor protocol to store and automatically retrieve metadata and other information from the sensor device itself. SEISI SEISI is a set of software and hardware components defining an interoperable architecture to propagate data from sensors, through platforms to the web. SensorML SensorML provides standard models and an XML encoding for describing sensors and measurement processes. It can be used to describe a wide range of sensors, including both dynamic and stationary platforms and both in situ and remote sensors. Sensor Alert The SES is an enhancement of the SAS. Both Service are used to provide and publish/subscribe (SAS)/SES based access to sensor data and measurements. 0364-9059 © 2017 IEEE. Translations and content mining are permitted for academic research only. Personal use is also permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications standards/publications/rights/index.html for more information. This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. 2IEEE JOURNAL OF OCEANIC ENGINEERING SOS This standard defines a web service interface, which allows querying observations, sensor metadata, as well as representations of observed features. SPS The OpenGIS SPS Interface Standard defines interfaces for queries that provide information about the capabilities of a sensor and how to task the sensor SQL It is a special-purpose programming language designed for managing data held in a relational database management system. SWE The OGC’s SWE standards enable developers to make all types of sensors, transducers, and sensor data repositories discoverable, accessible, and useable via the web. I. INTRODUCTION SENSORS collect data for oceanographic research and societal benefit. They should be able to seamlessly contribute data to large Earth observing initiatives (regional and global) that make data discoverable and accessible to large and diverse user communities. Such initiatives include The Copernicus Marine Environment Monitoring Service (CMEMS), the Global Earth Observation System of Systems (GEOSS), and the Web of Things, to name a few. However, there are many systems and sensor types deployed in practice that rely on diverse communication protocols, where each protocol defines many communication layers from the physical/hardware interface up to command and data formats. Connecting disparate devices into a network typically requires specialized “driver” software that can translate these protocols between the individual sensors and the platforms on which they are installed [1]. The platforms typically require extensive manual configuration to match the driver software and other operational details of each network port to a specific sensor. Some data protocols, such NMEA, can facilitate such configuration, but in most cases a specific configuration still has to be done manually. Oceanographic sensors are usually developed by small companies, and lack standard protocol for configuration, operation, data acquisition, and data formats. RS 232 and RS 485 serial communications are the dominant physical layer protocols (although increasingly displaced by Ethernet), but in general each manufacturer defines distinct syntax and command sets as well as data formats for the sensors it produces [1], [4]. These sensors are often integrated into an observing system or sensor network, which provides a software infrastructure for functions such as data acquisition, data logging, and data transfer via hard-wired or wireless telemetry links. Driver software must be written, and must be properly configured when the sensor has been physically installed into a communication port on the observing system. Thus sensor integration can be a time consuming, expensive, and challenging task. Moreover an efficient data access approach for users is needed. As a comprehensive solution, the development of an architectural concept and implementation to integrate sensors and their data into the Internet is a core objective of the Next generation Ocean Sensors (NeXOS) project funded by the European Seventh Framework Programme. This paper introduces the NeXOS sensor web architecture (see Fig. 1) as an example of how interoperability standards help to facilitate infrastructure for sharing oceanographic observation data, and the integration of sensor data into applications [4]. Sensor Web Enablement (SWE) standards specify how users interact with sensors and their data through interfaces and formats defined and maintained by the Open Geospatial Consortium (OGC). The user needs just a web browser to access data from a sensor web. There is no need for custom operating system-dependent applications to access raw sensor data. The way to access and manage sensor data is succinctly described in a set of standards that have been developed by the community under the OGC umbrella. In the following sections, more details about the standards used in our proposal will be described. Standardizing the installation process of a new sensor helps to reduce operating costs of the observatory. In some cases, a sensor must be integrated with marine observation platforms such as oceanographic gliders or buoys at sea under extreme environmental conditions. Standardizing and streamlining installation and operating processes can dramatically reduce costs, as well as the risk of failures due to manual errors [5]. Standard protocols and formats also facilitate interoperability, maintenance, and replacement of observatory sensors and maintain traceability of the data they generate [2]. A key idea of our proposal is that the information about the sensor resides physically “inside” the sensor, i.e., sensor metadata is stored within the device itself, and marine platforms can interrogate the sensor to download this information to identify, configure, and operate the device. Our proposed system uses OGC PUCK protocol as a standard way to access this metadata, and more details about it are found below. PUCK and other OGC SWE standards [6] form the basis of the NeXOS sensor web architecture are introduced in this paper. The remainder of this paper is structured as follows. In Section II, the motivation and requirements underlying the sensor web architecture are described. In Section III, the main principles and components of the proposed architecture are presented. In Sections IV, V, and VI, description of how this architecture has been implemented, deployed, and validated. Finally, in Section VII, a conclusion and an outlook are provided. II. MOTIVATION AND REQUIREMENT ANALYSIS At present, much oceanographic and coastal data are of limited value as they are locked in proprietary systems and in “vertical” deviceand usage-specific applications. A great opportunity lies in being able to create “horizontal” independent applications and services that use sensor data aggregations across devices and domains. Such applications and services can focus on the needs and interests of users, such as data from devices belonging to a particular user or of particular geographic/temporal interest to the user. Although some observing systems fulfill some of these goals, they could be made more efficient and lower cost through use of standard protocols. A basic requirement of such systems is the capability to discover sensors of interest in a user’s proximity, e.g., identifying nearby clusters of hydrophones in a coastal area and visualizing marine mammal detections to the user. To fulfill this requirement, web-enabled ocean sensor systems must be designed to support data interoperability and at least some level of commonality in data taxonomies, ontologies, naming, and metadata assignment and processing. For efficiency, a system should work with a minimal set of interoperable data and metadata formats that work across devices and domains, allowing applications to discover and access sensors of interest, interpret their observations, and trigger sensors or actuators where appropriate. The metadata should provide basics and context such as calibration history, sensor ID/name, command set for configuration and control, engineering units, time synchronization, location, calibration methods, maintenance periods, and other parameters, all of which should be automatically accessible independent of any human interaction. Regardless of implementation, clients need to be able to query sensors to obtain real-time observations and to query historical sensor values, e.g., by name and time. The sensors should be easily integrated into observing systems, which call for standards for connectors, power supplies, data formats, protocols, and handling procedures. For remote observing systems, sensors should be able to check themselves autonomously for This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. R´ IO et al.: SENSOR WEB ARCHITECTURE FOR INTEGRATING SMART OCEANOGRAPHIC SENSORS INTO THE SEMANTIC SENSOR WEB 3 Fig. 1. Sensor web architecture for the NeXOS project. Data coming from sensors are available on the web. Data are propagated from sensors to the web using standard protocols such as OGC SOS. Users also interact with sensors and receive event notifications through standardized mechanisms. possible malfunctions to report back to the operations center. These are exactly the objectives of the NeXOS sensor web architecture presented in this paper. For the design of the sensor web architecture several functional requirements were identified. 1) “Pull” access to observation data by a client, i.e., following a request–response pattern. 2) Push delivery of observation data to clients: data are injected without a request. 3) Visualization of the collected observation data for all sensors, accounting for sensor specificities. 4) Automatic conversion of sensor readings into appropriate format to enable data access via the web. In addition to these sensor and data access needs, the following requirements help to improve cost effectiveness. 1) Reusability: The components and implementations of the sensor web architecture shall be as generic as possible and shall follow international standards. Thus, data providers shall be able to reuse the resulting architecture and software in multiple application contexts beyond this project. 2) Interoperability: Through the use of international standards, the integration of interoperable sensor data into applications shall require less effort. As soon as new sensor data sets are available in the sensor web infrastructure, all clients compatible with these standards will be able to access the data immediately. When needed, standard security protocols can be also applied to sensor actuation and data access. 3) Open Source: For each component of the sensor web infrastructure at least one open source implementation shall be provided. This will allow data providers to rely on free implementations. Furthermore, the open source license of the developed components will ensure that users of the software are not bound to a single vendor. Many of the components needed to build such an architecture are available; the question is how to define a convincing demonstration case, where all aspects that might come up in other application cases are covered. At first, this is a very complex problem and it is tempting to stray into cumbersome premature generalizations that may hinder adoption and implementation. Probably the best and the fastest way forward is to first define a minimal usable subset of guidelines and specifications for the ocean and coastal observing community, with room for refinement as experience in building and operating those systems is gained. Therefore for NeXOS we propose a framework that builds on the concepts and prototypes developed for the OGC Architecture Implementation Pilot [7] and the OGC Ocean Science Interoperability Experiment (http://www.opengeospatial.org/projects/initiatives/oceansie). III. NEXOS SENSOR WEB ARCHITECTURE The vision of providing oceanographic and coastal data for geospatial sensor web services is not new and there are many initiatives working in that direction. Examples of sensor web initiatives with the goal to make oceanographic and coastal information available for smart appli- This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. 4IEEE JOURNAL OF OCEANIC ENGINEERING Fig. 2. Overview of the components for the Ocean and Coastal Sensor Web Architecture. cations and services have and are being developed in different international projects such as: CMEMS, the GEOSS, and the Web of Things, to name a few. Examples of projects that include the oceanographic and coastal monitoring domain include SCHeMA (http://www.schemaocean.eu), SenseOCEAN (http://www.senseocean.eu), EmodNET, SeaDataNet, IMOS, IOOS, and the OGC working group to extend the current SWE standards toward the Internet of Things (www.opengeospatial.org/projects/groups/sweiotswg). In the NeXOS architecture presented here there are three new main components: 1) the Smart Electronic Interface for Sensors and Instruments (SEISI hardware and firmware), which facilitates the integration of oceanographic sensors on various platforms such as floats, gliders cabled observatories, vessels of opportunity or moorings; 2) OGC SWE Bridge, which executes on a deployed platform to provide data to a shore-based OGC Sensor Observation Service (SOS); and 3) several web service implementations, based primarily on OGC-SWE specifications. As shown in Fig. 2, these interfaces use the OGC SOS for accessing the measured data, the OGC Sensor Planning Service (SPS) for controlling sensor parameters, and an approach for subscribing to push-based sensor data streams. A detailed description of the architecture shown in Fig. 2 follows. The starting point is always a system composed of a sensor or a set of sensors connected to a platform. As shown in the figure, the sensor can be either a “SEISI system” or “non-SEISI system.” In either case, the sensor is accompanied by a Sensor Model Language (SensorML) file that describes the sensor. A “SEISI system” indicates a PUCK enabled sensor that can transfer its data through Transactional SOS (T-SOS) Operations (such as InsertSensor or InsertObservation) directly to an SOS server if a connection to the Internet is available. The T-SOS operations can be executed by the sensor itself (if it is designed with this capability), or through a specific electronic board called SEISI Hardware. These transactional operations are described in more detail in Fig. 7, and the objectives are to declare a new sensor and populate sensor data into the SOS server. On the other hand, a “non-SEISI system,” refers to a PUCK enabled or non-PUCK enabled sensor unable to communicate directly with an SOS server. Instead the non-SEISI’s data is first transferred to a software component called the OGC SWE Bridge, which then eventually relays the data to a T-SOS. The user can discover, visualize, and retrieve data from the SOS with “SOS web client” software. Secondary components such as the “SPS” module will allow the user to communicate with an Internet-connected SEISI directly, or through the “OGC SWE Bridge” with a non-SEISI system or with SEISIs not directly connected to the Internet. Also, thanks to a “feeder” software component a Sensor Event Service (SES) that will inform the user about events related to the data, such as when new data are available. The “SEISI and non-SEISI systems” in Fig. 2 are software with associated physical sensors plus cables plus the host controller of the platform; the rest are software components that are executed on a server computer. The fundamental functionality of the architecture is the interoperable access to sensor data. Thus, an essential component is a web service interface for pull-based access to observation data (i.e., following a request–response pattern). Within the NeXOS architecture, this interface is realized through the OGC SOS 2.0 standard [8]. This interface defines standard operations for requesting sensor measurements and metadata as well as for publishing newly acquired data. It relies on two further specifications: ISO/OGC Observations and Measurements (O&M) 2.0 [9] is used for modeling and encoding the measured observation data, and OGC SensorML 2.0 [10] standard is applied to the metadata associated with the observations and corresponding sensors. With regard to the SOS, special emphasis is put on the need for easy integration into existing IT infrastructures (e.g., configuration mechanisms that can be flexibly coupled with existing observation databases). This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. R´ IO et al.: SENSOR WEB ARCHITECTURE FOR INTEGRATING SMART OCEANOGRAPHIC SENSORS INTO THE SEMANTIC SENSOR WEB 5 The SOS interface offers a typical request-response pattern for accessing observation data. This means that users/clients submit a request for a specific set of observation data (e.g., for specific parameters, locations, time periods, etc.) and the service returns this requested data set as a response. However, in addition, many users need to receive new observations as soon as they are measured. Such a delivery pattern cannot be efficiently implemented by the request-response pattern which would require continual polling by the user. Thus a web service for push delivery of observation data is required. For this purpose the OGC SES discussion paper [11] and the current activities of the OGC Publish/Subscribe Standards Working Group provide a valuable foundation. These specifications have been evaluated within this work to define a push-based data subscription/delivery service interface. A further important functionality is the configuration and control of sensor systems. This includes simple settings such as the sampling rate of a temperature sensor but also complex tasks such as the track planning for an autonomous underwater glider sensor platform. While these configure and control operations involve diverse protocols, there is a need for a common to define and submit such commands. To address this need, the proposed NeXOS sensor web architecture includes a tasking component based on the OGC SPS 2.0 [12]. This interface allows users to determine which tasks can be executed by a sensor and which parameters can be changed, to manage and submit tasks as well as to request information on how the resulting data can be accessed from other services. To allow users to explore and visually analyze available observation data, this architecture also includes a data viewer for visualizing the collected observation data for all oceanographic sensors. This is achieved by an SOS 2.0 client capable of providing the user with an overview of the data available from SOS servers and visualizing these data sets as maps and graphs. To allow the adjustment to specific use cases and individual requirements, this client shall be designed to allow flexible customization. Finally, the transfer of observation data from the sensor into the sensor web infrastructure and the submission of commands from components such as the SPS to the devices is addressed. These operations rely on ISO/OGC O&M 2.0 [9] and the OGC SensorML 2.0 [10] standard. After this overview of the core components of the NeXOS sensor web architecture, the following section provides some insight how this architecture concept is implemented. IV. IMPLEMENTATION During the first two years of the NeXOS project, the overall architecture as well as outlines of the component specifications were developed. Based on that design work a first iteration of prototypes has been conducted, resulting in several new or enhanced implementations. Of these implementations, four will be presented in this section in more detail: the SOS, a JavaScript sensor web client, the SEISI, and the OGC SWE Bridge. These components are available as open source software. A. SOS Server The NeXOS SOS implementation is based on the 52°North SOS 4.0 development [13]. To ensure easy integration of the SOS server into existing data management systems, the SOS has been implemented completely independent of a specific database management system or data model. To achieve this independency the 52°N Hibernate abstraction framework that links existing databases with an SOS server is used [http://hibernate.org/]. This layer hides specific aspects (e.g., Structured Query Language (SQL) “dialects”) of different database management systems from SOS clients. This is achieved through mappings that describe which element of the core SOS data model corresponds to which Fig. 3. Typical Deployment Scenario for SOS Servers. table/column of a specific database. As a result, the abstraction layer acts as a translator between different database models. An overview of this approach to allow the flexible integration of database management systems as well as data models into the SOS implementation can be seen below in Fig. 3, where users access data through the SOS client, while sensor systems populate sensor data into the SOS server or into the database. As noted above, Hibernate software links data stored in existing databases with an SOS server, allowing an SOS client to discover and access such data. These three components (SOS client, SOS server with Hibernate, and the database) can operate on separate distributed machines. Normally, the SOS server and database will be executed on a server computer with an accessible URL over the Internet. The SOS client can be opened in any browser on any Internet connected computer to access data. B. SOS Client With Visualizer To explore the data available through the SOS, it is necessary to provide the users with tools to discover and visualize the available observation data sets. For this purpose NeXOS uses the 52°North JavaScript client. Together with other projects (especially the FP7 project GEOWOW) and stakeholders from other domains (especially hydrology and air quality) a first version of this client was developed. Fig. 4 displays the client’s abilities to visualize time series data. C. Smart Electronic Interface for Sensors and Instruments To ensure the easy integration of the NeXOS sensors into previously introduced SOS implementation, the SEISI has been implemented [14]. SEISI refers to specifications for a set of hardware and software components. As an example, an instrument (e.g., CTD) connected to a platform controller such as a buoy, vehicle, etc., is SEISI-compliant if it implements certain components that appear in Fig. 5. SEISI devices provide standard services for data access, data push, and sensor configuration based on the existing standard OGC SWE specifications for OGC SOS [8] and SPS [12]. SEISI devices may be deployed on platforms with a direct TCP/IP connection to the Internet, such as cabled observatories, ships or buoys with an Internet connection. A compliant SEISI device includes an RS232 serial interface as well as Ethernet, so a SEISI may also be deployed on platforms with limited-bandwidth intermittent non-TCP/IP links such as Iridium satellite. In the latter case, the NeXOS SWE Bridge component is also present on the platform, providing the connection between the at-sea sensors and Internet web services across the low-bandwidth link. The links between at-sea sensors and Internet-based NeXOS sensor web components are shown in Fig. 5. These components are based on OGC SWE protocols to provide sensor detection, identification, configuration, and data acquisition. This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. 6IEEE JOURNAL OF OCEANIC ENGINEERING Fig. 4. Screenshot of sensor web client developed in the JavaScript language. In the SEISI architecture shown in Fig. 5, we see four distinct OGC standard protocols namely: 1) SOS; 2) T-SOS; 3) SPS; and 4) PUCK protocol (which can be implemented across RS232 or Ethernet). In addition to these standards, a proprietary protocol service is implemented to cover any other sensor functionalities, which may not be fulfilled by the available standards. In the rest of this section, we specify in greater detail the functional services that enable interoperability among the different parts of the system. 1) SEISI Data Format: OGC SWE architecture sets specific data accessibility requirements. In architectures based on web services, data exchange is typically accompanied by a description of the transferred content by means of semantic representation languages, of which the eXtensible Markup Language (XML) is probably the most common. Nevertheless, the size of XML messages is often too large for the limited bandwidth of oceanographic platforms such as gliders or profilers. Furthermore, the text nature of XML representation complicates the parsing of messages by CPU-limited devices, compared to binary formats. For these reasons, the working group of the World Wide Web Consortium (W3C) [15] has proposed the Efficient XML Interchange (EXI) format, sometimes referred to as “binary XML” [16], which makes it possible even for very constrained devices to natively process and generate messages using an open data format compatible with XML. Therefore, we adopt EXI’s schema-less encoding and processing for all OGC SOS operations of the SEISI system (i.e., GetCapabilities, DescribeSensor, GetObservation, InsertSensor,andInsertResult). Moreover, EXI is employed for SEISI metadata provided by the PUCK protocol [17] and encoded in SensorML 2.0. Further details about EXI and schema-less processing can be found in [18]. 2) SEISI SOS Web Service: The SOS web service implemented for SEISI provides standard access to sensor data by clients when the device is connected to a TCP/IP network as illustrated in Fig. 6, and is sufficiently lightweight for deployment on CPU-limited devices. The lightweight SOS only implements the core operations of OGC SOS Specification v2.0 (i.e., GetCapabilities, DescribeSensor,andGetObservation). The GetCapabilities operation provides access to metadata and detailed information about the available capabilities of the SOS. By using HTTP, GET, or POST request, the service capabilities can be retrieved from the SEISI encoded as an XML or EXI response. The capabilities response contains metadata about the service, such as information about the interface, the unique sensor identifiers, the observation offering of the SEISI and a list of one or more quantities observed by this offering. The DescribeSensor operation provides the sensor metadata in SensorML format. The sensor description contains information about the sensor capabilities and characteristics, details such as calibration data and available communication protocols, interfaces, and data formats of the SEISI. The SensorML also contains a standardized description of the sensor’s command protocol, i.e., it specifies commands that should be issued to configure and operate the device. In our NeXOS SEISI implementation, the SensorML is physically stored within SEISI sensors and retrieved through OGC PUCK protocol (see below). The GetObservation operation provides access to the observations made by the sensors. On request the SOS returns the SEISI system observations expressed in OGC O&M standard format, using EXI binary encoding. 3) SEISI T-SOS Web Client: The T-SOS operations implemented for SEISI provides standard data push service as shown in Fig. 7, i.e., the SEISI can push its data and metadata to an external SOS. Like other NeXOS implementations, the T-SOS client is sufficiently lightweight to be deployed on CPU-limited devices. The T-SOS implements the InsertSensor, InsertResultTemplate,andInsertResult operations of OGC SOS Specification v2.0. This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. R´ IO et al.: SENSOR WEB ARCHITECTURE FOR INTEGRATING SMART OCEANOGRAPHIC SENSORS INTO THE SEMANTIC SENSOR WEB 7 Fig. 5. SEISI system architecture and links with other components. The InsertSensor operation publishes the SEISI description to an SOS server. The publish request can be sent by the SEISI encoded as either an XML or EXI request. The InsertSensor request contains metadata about the SEISI, such as information about the interface, the unique sensor identifiers, observation offerings of the SEISI, and a list of one or more quantities observed by this offering. The InsertResultTemplate operation is used by the SEISI system to insert a “result template” (encoded as XML or EXI) to an SOS server; the template describes the structure of subsequent observations uploaded by SEISI to the SOS through InsertResult operations (below). The SEISI uploads raw data to the SOS through the SOS InsertResult operation, passing the data in the structure specified by the previous InsertResultTemplate operation. The actual data values are expressed in OGC Observations and Measurement format and may be binary EXI encoded. 4) SEISI PUCK Protocol: OGC adopted the PUCK protocol in 2012 as a new member of the SWE framework of specifications [17]. Briefly, PUCK defines a set of standard commands that enable platform software to identify and retrieve metadata information about the sensor from the device itself. This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. 8IEEE JOURNAL OF OCEANIC ENGINEERING Fig. 6. SOS data access service procedure. Fig. 7. T-SOS data push service procedure. OGC PUCK does not itself fully implement interoperability, but rather provides the lower tier in the hierarchy of SWE standards that achieve this goal. OGC PUCK establishes a protocol to retrieve metadata directly from a sensor. Several manufacturers of the Smart Ocean Sensor Consortium in the USA have already implemented the PUCK protocol on their sensors. European NeXOS partners developing new sensors are implementing this protocol in their devices as part of the SEISI specification, including TRIOS (optical sensors), SMID (hydrophones), and NIVA (carbon cycle), while NeXOS platform manufacturers including Alseamar (SeaExplorer glider), Fig. 8. PUCK sensor detection, identification, and configuration services procedure. TeledyneWebResearch (Slocum glider), CMR (Sail Buoy), and NKE (Provor float) use PUCK protocol on the platform side to retrieve metadata from attached PUCK-compliant sensors. PUCK provides a formatted electronic datasheet, which contains the information needed to identify the sensor model and manufacturer, as well as a universally unique identifier for each device. A PUCK-enabled sensor may also carry an additional payload that can include a SensorML document. PUCK protocol was originally defined for sensors with an RS232 interface, and the latest revision extends the protocol to Ethernet; this “IP PUCK” protocol uses the Zeroconf standard (http://www.zeroconf.org/) to enable easy installation and discovery of sensors in an IP network. SEISI systems use PUCK and its payload to enable sensor detection, identification, and configuration as illustrated in Fig. 8. The SensorML includes a description of the sensor’s manufacturer-specific command protocol and data format [19], i.e., it describes nonstandard protocols and formats in a standard way. The platform host can automatically retrieve and use this sensor protocol descriptor from the device when it is installed, and thus can operate the sensor without aprioriknowledge or sensor-specific “driver” software on the host. The generic SWE Bridge plays this role in the NeXOS architecture. This “plug-and-play” implementation significantly reduces the effort needed to integrate new sensors. Building on previous work [2], NeXOS specifies the standardized description of sensor protocols and has developed tools to support the creation of those descriptors [20]. Having this standardized language for the description of sensor protocols will facilitate the process of integrating sensors into marine observing systems, moving toward plug and play oceanic sensor systems [21]. Although sensors implementing PUCK protocol can store their metadata within the sensor, the NeXOS architecture is also compatible with sensors that do not implement PUCK. In such cases, the SensorML document with all the sensor metadata can be stored in a specific location on the platform file system and the SWE Bridge can be configured to read the sensor metadata from either a PUCK-enabled sensor or from the repository (for non-PUCK enabled sensors).