Middleware for Plug and Play Integration of Heterogeneous Sensor Resources into the Sensor Web - PubMed Skip to main page content
U.S. flag

An official website of the United States government

Dot gov

The .gov means it’s official.
Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.

Https

The site is secure.
The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

Access keys NCBI Homepage MyNCBI Homepage Main Content Main Navigation
. 2017 Dec 15;17(12):2923.
doi: 10.3390/s17122923.

Middleware for Plug and Play Integration of Heterogeneous Sensor Resources into the Sensor Web

Enoc Martínez  1 , Daniel M Toma  2 , Simon Jirka  3 , Joaquín Del Río  4
Affiliations

Middleware for Plug and Play Integration of Heterogeneous Sensor Resources into the Sensor Web

Enoc Martínez et al. Sensors (Basel). .

Abstract

The study of global phenomena requires the combination of a considerable amount of data coming from different sources, acquired by different observation platforms and managed by institutions working in different scientific fields. Merging this data to provide extensive and complete data sets to monitor the long-term, global changes of our oceans is a major challenge. The data acquisition and data archival procedures usually vary significantly depending on the acquisition platform. This lack of standardization ultimately leads to information silos, preventing the data to be effectively shared across different scientific communities. In the past years, important steps have been taken in order to improve both standardization and interoperability, such as the Open Geospatial Consortium's Sensor Web Enablement (SWE) framework. Within this framework, standardized models and interfaces to archive, access and visualize the data from heterogeneous sensor resources have been proposed. However, due to the wide variety of software and hardware architectures presented by marine sensors and marine observation platforms, there is still a lack of uniform procedures to integrate sensors into existing SWE-based data infrastructures. In this work, a framework aimed to enable sensor plug and play integration into existing SWE-based data infrastructures is presented. First, an analysis of the operations required to automatically identify, configure and operate a sensor are analysed. Then, the metadata required for these operations is structured in a standard way. Afterwards, a modular, plug and play, SWE-based acquisition chain is proposed. Finally different use cases for this framework are presented.

Keywords: OGC PUCK protocol; Open Geospatial Consortium; Sensor Web Enablement; SensorML; interoperability; plug and play; sensor integration.

PubMed Disclaimer

Conflict of interest statement

The authors declare no conflict of interest.

Figures

Figure 1
Figure 1
Sensor Web Enablement layer stack for ocean observing systems. The sensor layer comprises the physical sensors. The integration layer includes all the mechanisms that bridge the data from the sensor’s output to Sensor Web services. The Sensor Web Services layer is the core of a Sensor Web infrastructure, where the data is archived, processed and analysed. Finally the application layer provides interfaces between the Sensor Web services and the final users (e.g., data viewers).
Figure 2
Figure 2
Collaborative research scenario using specific drivers and data converters for each sensor-platform combination, in this case an underwater glider, a buoy and a cabled underwater observatory.
Figure 3
Figure 3
Proposed Sensor Web Enablement (SWE)-based architecture. Sensor resources are integrated by combining a standards-based description with a generic driver in order acquire data. As the generic driver provides a standardized output, the generated data can be directly sent to the SWE services using the observation platform’s communication link.
Figure 4
Figure 4
Requirements for a plug and play mechanism (rows) and protocols/standards that can fulfil these requirements (columns).
Figure 5
Figure 5
Proposed SWE-based acquisition chain.
Figure 6
Figure 6
Sensor and SWE Bridge with their models (left) and Sensor Deployment Files (SDF) model (right). The Sensor, with its associated SDF, is interfaced by the SWE Bridge middleware, which also has its own Sensor Model Language (SensorML)-based description, the SWE Bridge Model.
Figure 7
Figure 7
UML diagram of the Sensor Model. The gray elements represent all required information by the SWE Bridge (compulsory) while the blue elements represent optional metadata (used to register the sensor to a Sensor Observation Service (SOS) Instance).
Figure 8
Figure 8
Sensor Instance UML diagram. It inherits a sensor model and expands it with information related to a sensor instance alongside with information related to a specific deployment. The gray elements represent all the required information by the SWE Bridge (compulsory ) while the blue elements represent optional metadata (used to register the sensor to a SOS Instance).
Figure 9
Figure 9
Sensor Mission UML Diagram.
Figure 10
Figure 10
Metadata mapping from Sensor Deployment Files (SDF) to the Sensor Observation Service (SOS) transactional operations InsertSensor (left) and InsertResultTemplate (right). The blue elements correspond to Sensor Instance elements while the green elements correspond to Sensor Mission elements. Dashed lines indicate optional elements and thick lines indicate multiple elements.
Figure 11
Figure 11
SWE Bridge model. All modules inherit from the generic module, where the execution options for the processes are defined. Then each module expands its definition with its particular settings. The model also contains a set of identifiers and a generic communication’s interface.
Figure 12
Figure 12
SWE Bridge internal architecture. The different components use the resource abstraction wrappers to hide the underlying hardware and operating system, providing a unified way of accessing platform-dependent resources.
Figure 13
Figure 13
SWE Bridge operation. On the left the operation with a OGC PUCK-enabled sensor is shown. On the right the operation of a COTS sensor is presented, with the SDF stored locally on the platform.
Figure 14
Figure 14
NeXOS A1 Hydrophone integrated on the SeaExplorer glider as payload.
Figure 15
Figure 15
SeaExplorer mission acquisition chain
Figure 16
Figure 16
SWE Bridge mission scheduler configuration for the SeaExplorer NeXOS mission.
Figure 17
Figure 17
Sound Pressure Level (SPL) at 125 Hz octave band acquired by a SeaExplorer glider in a mission at the Norwegian coast. The incoming data from the hydrophone was subsampled and sent to shore in near real-time during deployment.
Figure 18
Figure 18
EMSO Generic Instrument Module (EGIM) with its instrument pack during its deployment (left) and EGIM deployed at the OBSEA observatory (right).
Figure 19
Figure 19
EGIM cyber-infrastructure in a cabled mode scenario.
Figure 20
Figure 20
Mission scheduler configuration used by the SWE Bridge instances deployed at the EMSODEV acquisition server. The data coming from each sensor (all of them configured in stream mode) is acquired using an Instrument Command process, which then passes the data to a Field Selector process. This process filters the useful data and discards the undesired variables, depending on the communications protocol of each sensor. Later on, two different branches are created, one that stores the data into Observations and Measurements (O&M) files using the Insert Result process, and another one that sends the data to the Zabbix Monitoring System.
Figure 21
Figure 21
INTMARSIS System overview. At the seafloor the OBS (Ocean Bottom Seismometer) acquires seismic data, storing it locally. A subsampled set of data is sent through the mooring line using an inductive modem. The surface buoy receives the real-time subsampled seismic data, which is transmitted to the Land Station server using a GSM link
Figure 22
Figure 22
INTMARSIS buoy (left) and INTMARSIS Ocean Bottom Seismometer (right).
Figure 23
Figure 23
INTMARSIS System acquisition chain. Virtual instruments are depicted as purple components.
Figure 24
Figure 24
SWE Bridge time-based memory profile when interfacing sensors from NeXOS, EMSODEV and INTMARSIS projects. The peak usage of heap memory is registered when decoding the SDF file. Afterwards, during the operation stage, the memory consumption is kept constant.
See this image and copyright information in PMC

Similar articles

See all similar articles

Cited by

References

    1. Reed C., Botts M., Davidson J., Percivall G. OGC Sensor Web Enablement: Overview and High Level Architecture. GeoSens. Netw. 2008;4540:175–190.
    1. Bröring A., Echterhoff J., Jirka S., Simonis I., Everding T., Stasch C., Liang S., Lemmens R. New generation Sensor Web Enablement. Sensors. 2011;11:2652–2699. doi: 10.3390/s110302652. - DOI - PMC - PubMed
    1. Bröring A., Maué P., Janowicz K., Nüst D., Malewski C. Semantically-enabled sensor Plug & Play for the Sensor Web. Sensors. 2011;11:7568–7605. - PMC - PubMed
    1. Broring A., Foerster T., Jirka S. Interaction patterns for bridging the gap between sensor networks and the Sensor Web; Proceedings of the Communications Workshops 2010 8th IEEE International Conference on Pervasive Computing and Communications; Mannheim, Germany. 29 March–2 April 2010; pp. 732–737.
    1. Del Rio J., Toma D.M., O’Reilly T.C., Broring A., Dana D.R., Bache F., Headley K.L., Manuel-Lazaro A., Edgington D.R. Standards-based plug & work for instruments in ocean observing systems. IEEE J. Ocean. Eng. 2014;39:430–443.