Research of Marine Sensor Web Based on SOA and EDA

JIANG Yongguo, DOU Jinfeng GUO Zhongwen and HU Keyong

1)Department of Computer Science and Technology,College of Information Science and Engineering,Ocean University of China,Qingdao266100,P.R.China

2)Shandong Provincial Key Laboratory of Marine Ecology and Environment and Disaster Prevention and Mitigation,Qingdao266033,P.R.China

Research of Marine Sensor Web Based on SOA and EDA

JIANG Yongguo1),2),*, DOU Jinfeng1), GUO Zhongwen1), and HU Keyong1)

1)Department of Computer Science and Technology,College of Information Science and Engineering,Ocean University of China,Qingdao266100,P.R.China

2)Shandong Provincial Key Laboratory of Marine Ecology and Environment and Disaster Prevention and Mitigation,Qingdao266033,P.R.China

A great deal of ocean sensor observation data exists, for a wide range of marine disciplines, derived fromin situand remote observing platforms, in real-time, near-real-time and delayed mode. Ocean monitoring is routinely completed using sensors and instruments. Standardization is the key requirement for exchanging information about ocean sensors and sensor data and for comparing and combining information from different sensor networks. One or more sensors are often physically integrated into a single ocean ‘instrument’ device, which often brings in many challenges related to diverse sensor data formats, parameters units, different spatiotemporal resolution, application domains, data quality and sensors protocols. To face these challenges requires the standardization efforts aiming at facilitating the so-called Sensor Web, which making it easy to provide public access to sensor data and metadata information. In this paper, a Marine Sensor Web, based on SOA and EDA and integrating the MBARI’s PUCK protocol, IEEE 1451 and OGC SWE 2.0, is illustrated with a five-layer architecture. The Web Service layer and Event Process layer are illustrated in detail with an actual example. The demo study has demonstrated that a standard-based system can be built to access sensors and marine instruments distributed globally using common Web browsers for monitoring the environment and oceanic conditions besides marine sensor data on the Web, this framework of Marine Sensor Web can also play an important role in many other domains’ information integration.

ocean sensor networks; ocean observing systems; marine sensor web; web service; SOA; sensor web enablement (SWE); EDA

1 Introduction

The monitoring of ocean waves, tides, temperature and salinity is routinely completed using sensors and ocean instruments. Today’s oceanographic instruments are characterized by diverse sensor data formats, parameters units, spatiotemporal resolution, application domains, data quality and sensors protocols, which bring challenges to integration of large-scale ocean sensor networks and other mesh networks (Wanget al., 2011). Ocean data interoperability of sensors or instruments has become globally important, as data users from many organizations and marine disciplines wish to query and access data from multiple data platforms of Ocean Observing Systems (O’Reillyet al., 2009; Songet al., 2009).

The Institute of Electrical and Electronics Engineers (IEEE) 1451 smart transducer interface standards for sensors and actuators define a set of network-independent communication interfaces to connect smart transducers to microprocessors, instrumentation systems and control networks (Lee, 2000).

Concept of standardized description files for sensor location, introduced by NASA, the University of Alabama Huntsville and CEOS (Committee on Earth Observation Satellites) was brought into OGC in 2001 for prototyping, testing and promotion as the OGC’s Sensor Web Enablement (SWE) activity (Mikeet al., 2007). The OGC, a geospatial standards organizations, is responsible for the task of standardizing sensor communication because every sensor, whether in situ (such as a rain gauge) or remote (such as an earth imaging device), has a location, and the location of a sensor is highly significant for many applications.

OGC SWE (Sensor Web Enablement, Bröringet al., 2011a) is intended to be a revolutionary approach for exploiting Web-connected sensors such as flood gauges, air pollution monitors, satellite-borne earth imaging devices,etc. The goal of SWE is to create Web-based sensor networks, that is, to make all sensors and repositories of sensor data discoverable, accessible and, where applicable, controllableviathe WWW. OGC defines a set of specifications and services for this goal.

Standardization is the key requirement for communicating information about sensors and sensor data and for comparing and combining information from differentsensors. The OGC’s SWE standards meet this requirement in the most complex as well as very simple applications. Sensor location is usually a key piece of sensor or sensor data information, and SWE standards make it easy to integrate this information into thousands of geospatial applications that implement the OGC’s other standards.

One or more sensors are often physically integrated into a single ‘instrument’ device. These components are connected through wired or wireless communication interfaces; RS232 or Ethernet ports are commonly used. The Monterey Bay Aquarium Research Institute (MBARI)’s Programmable Underwater Connector with Knowledge (PUCK) defines a protocol for RS232 and Ethernet connected instruments. PUCK addresses installation and configuration challenges for sensors by defining a standard instrument protocol to store and automatically retrieve metadata and other information from the instrument device itself (Tom, 2012). PUCK has been used in conjunction with existing OGC Sensor Web standards. Standards such as OGC SWE and IEEE 1451 strive to integrate diverse instruments into networks with minimal human effort and high reliability. Nevertheless, the using of these standards may require several software components to be manually installed on the instrument network, including instrument ‘drivers’, web servers, and metadata documents that describe instruments in a standard way.

PUCK augments but does not replace existing instrument protocols. Thus a manufacturer can modify its instrument firmware by adding PUCK commands to the already-existing instrument command set. This approach allows manufacturers to implement PUCK without abandoning their existing firmware and software applications.

The IEEE 1451 standard and PUCK protocol, which are implemented on sensor hardware and software, were demonstrated working with OGC Sensor Web Enablement (SWE) standards at the Web application level (Nischalet al., 2009). These standards are proven to work together to support interoperability among these systems as well as making it easy to provide public access to sensor information.

The above progress leads to standardization efforts aiming at facilitating the so-called Sensor Web. The term‘sensor web’ was first used by Kevin Delin of NASA in 1997 (Kevinet al., 2005), which is based on Service-Oriented Architecture (SOA) concept. The aim of sensor web is to discover, plan, control those web-resident sensors or instrumentsviathe WWW. By defining standardized service interfaces, a sensor web based on SWE services hides the heterogeneity of an underlying sensor network like its communication details and various hardware components, from the applications built on top of it. OGC’s SWE initiatively defines the term ‘sensor web’ as an infrastructure enabling access to sensor networks and archived sensor data that can be discovered and accessed using standard protocols and application programming interfaces. Through this abstraction from sensor details, their usage in applications is facilitated (Mike and Alex, 2007).

1.1 SOA and EDA

The capability of the marine sensor web is to collect information accurately and reliably, and enable the building of real-time marine elements detection and early observing warning systems. In addition, it allows rapid coordinate responses to threats such as red tides, enteromorpha, tsunamis, earthquakes, and other crisis situations.

A web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

Web Services (Chenet al., 2009a) use a loosely coupled integration model to allow flexible integration of heterogeneous systems in a variety of domains including business-to-consumer, business-to-business and enterprise application integration. The following basic specifications originally defined the Web Services space： SOAP, Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI). SOAP defines an XML messaging protocol for basic service interoperability. WSDL introduces a common grammar for describing services. UDDI provides the infrastructure required to publish and discover services in a systematic way. Together, these specifications allow applications to find each other and interact following a loosely coupled, platform-independent model.

The Service Oriented Architecture (SOA) provides an approach to describe, discover, and invoke services from heterogeneous platforms using XML and SOAP standards. Bringing the idea of SOA to marine sensor web is a very important step forward to presenting the marine sensors as reusable resources which can be discoverable, accessible and, where applicable, controllableviathe World Wide Web.

Sensor Web brings the heterogeneous sensors into an integrated and uniform platform supporting dynamic discovery and access (Chenet al., 2009b). A sample scenario would be the client (maybe the marine researchers or other software system), who wants to access the information collected by the deployed marine sensors which exists in the targeted area, such as weather forecast and red tides detection. The client may query the entire marine sensor web and get the response from either real-time sensors that have been registered in the web or existing data from a remote sensors database. The clients are not aware of where the real marine sensors are and what operations they may have, although they are required to set parameters for their purpose and invoke the service. The main goal of the marine sensor web is to offer data query services to the end-users. In other words, it provides the services and APIs for finding, querying, and accessing marine sensor services through the sensor web.

Service Oriented Architecture supports request-reply pattern, but does not suit the stop-start (asynchronous) communication. The critical problem is how to match the user request with the web service advertisement, efficiently and accurately as per the user requirements. Then the situation needs to integrate the SOA with the Event Driven Architecture (EDA) in web service discovery.

Event Driven Architecture (EDA) (Muehlet al., 2006) is an architectural style that prescribes the communication between components that has to be performed on the basis of event notifications, where events are basically understood as changes in the state of something relevant for the system. An event is defined as ‘any happening of interest in a computer system’,e.g., Value of Observing element reported by sensors, timers or generally any detectable state-change that can be described in a computer-processable manner.

1.2 BPEL

As an approach to specifying business process behavior, the second version of Business Process Execution Language (BPEL, also called BPEL4WS-Business Process Execution Language For Web Services) was announced in 2007 (Alveset al., 2007). Web services provide the basic technical platform required for application interoperability. They do not, however, provide higher level control, such as which web services need to be invoked, which operations should be called and in what sequence. Nor do they provide ways to describe the semantics of interfaces, the workflows, or e-business processes. BPEL is the missing link to assemble and integrate web services into a real business process. BPEL standardizes process automation between web services. BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces.

BPEL supports two kinds of business processes, executable and abstract. Executable business processes define concrete tasks and the needed service calls can be executed. Abstract processes describe information interchange between web services, but not behavior details.

Web Service Description Language (WSDL) is an XML-based standard. In BPEL process we use WSDL to call web services. BPEL process can also be represented as WSDL for calling. WSDL (Alexandreet al., 2007) document uses the following elements in the definition of network services：

Types： a container for data type definitions using some type system (such as XSD).

Message： an abstract, typed definition of the data being communicated.

Operation： an abstract description of an action supported by the service.

Port Type： an abstract set of operations supported by one or more endpoints.

Binding： a concrete protocol and data format specification for a particular port type.

Port： a single endpoint defined as a combination of a binding and a network address.

Service： a collection of related endpoints.

1.3 Sensor Web and OGC SWE

Sensor Web (Jirkaet al., 2009; Kevin, 2011) was firstly described by Delinet al. in 1999; a Sensor Web was considered as an autonomously organized wireless sensor network which can be deployed to monitor environments. The term ‘Web’ within Delin’s ‘Sensor Web’ relates to the intelligent coordination of the network rather than the World Wide Web (WWW) (Gibbonset al., 2003). The meaning of ‘Sensor Web’ has changed and it is more and more seen as an additional layer integrating sensor networks with the WWW and applications (Jeffet al., 2004). The Sensor Web (Silvia, 2009; Lianget al., 2005; Balazinskaet al., 2007) concept presents a vision of the Sensor Web is that access to sensors as uniform and easy as access to resources on the World Wide Web today, which makes intra-communicating spatially distributed sensor pods that can be deployed to monitor and explore different environments.

Referring to earth observation domain of GEOSS (The Global Earth Observation System of Systems), the derived view of the Sensor Web as a concept in the context is an ‘open coordinated observation infrastructure composed of a distributed collection of resources that can collectively behave as a single, autonomous, task-able, dynamically adaptive and reconfigurable observing system that provides raw and processed data, along with associated meta-data,viaa set of standards-based interfaces’ (van Zylet al., 2008; Teilletet al., 2010).

The OGC SWE working group was founded in 2003. The SWE working group develops standards to integrate sensors into the Geospatial Web for enabling a specialized subtype, the Sensor Web. Therefore, SWE has specified a number of standards defining formats for sensor data (O and M) and metadata (SensorML) as well as service interfaces which enable the interoperable access to real and virtual sensor resources. The SWE 1.0 specifications have been approved as standards between 2006 and 2007. As the middleware between sensors and applications, the new generation SWE (SWE 2.0) (Bröringet al., 2011b) is divided into two informal subgroups. Firstly, the information model includes the data models and encodings. Secondly, the interface model comprises the different web service interface specifications (the interface model was formerly called service model and to avoid naming confusion with the SWE Service Model standard, which is part of the new generation SWE).

1.4 Reality of Marine Observing Systems

A great deal of marine sensor observation data exists, for a wide range of marine disciplines, derived fromin-situand remote observing platforms, in real-time, near-real-time and delayed mode. These marine data are acquired as part of routine ocean monitoring activities and marine scientific surveys by related institutes andagencies. Sensors measure a host of interdisciplinary variables from moorings and other platforms. Some parameters of general interest include surface water temperature, atmospheric pressure, cloud cover, salinity, wind speed, wave height, plankton count, and ocean current speed and direction.

According to the marine observing systems, the variety of data observing platforms need to create seamless and coordinated access to marine observation raw data and products from distributed and heterogeneous observation system sources, which mainly depend on the on-the-fly marine sensors observation. But in fact, for different reasons, different marine research groups often represent, transport, store and distribute their data in different ways, making the simplified data exchange between the marine data centers become difficult. So the necessary methods or steps must be taken to improve the way that marine scientists observe the oceans and manage the observation data.

For the bad marine environments, the observing sensor and platform often do not work normally, so quality controlling of marine observing data is needed. At the same time we must have an eye on the poor buoy or other platform data bandwidth. Thinking of the above issues, we must have practical and efficient design and implementation of marine sensor web in sharing the observing data, which is based on SOA and EDA, including the New SWE 2.0 Sensor Web standards. In other words, we must think of the actual marine observing systems. In fact, we make use of the marine sensor web system which shares the observing data between the marine data producers and marine data consumers. Combining the New SWE Sensor Web 2.0 standards and the different marine observing data user requirements, a new marine sensor web system can be designed and developed, which can supply the marine data that marine scientists require.

The remainder of the paper is organized as follows：Section 2 gives the architecture of Marine Sensor Web based on SOA and EDA; the system software implementation of Marine Sensor Web is illustrated in Section 3; Section 4 gives the conclusion and future work.

2 Design of Marine Sensor Web

2.1 Architecture of Marine Sensor Web

There are many marine observing sensor platforms. Fig.1 shows three kinds of sensor networks,i.e., SeaSurface sensor network, SeaBed sensor network and underwater sensor network. The sensors in observing instruments can be classified as physical, chemical, biological, geophy- sical, and so on. Different marine observing systems with sensors can improve our understanding on the oceans and seabed using the data gathered locally by sensor networks.

Fig.2 is the five-layer architecture of Marine Sensor Web. According to the respective function of each layer, the first layer is Marine Sensor Source Layer, which contains various marine observing sensor sources, such as ocean station, buoys, research vessels, gliders and seabed network. The second layer is Information Model Layer, where the sensor data and metadata are acquired by the Data acquisition (DAQ) software. The third layer is Web Service Layer based on SOA, which consists of SOS, SPS, WNS, SAS, catalogue service,etc. The fourth layer and fifth layer are the EDA driven layers, which are Execution process-oriented and semantic process-oriented to meet the marine user process requirements.

Fig.1 Three typical marine sensor observing networks.

Fig.2 Five layers of Marine Sensor Web.

2.2 Marine Sensor Web Service Based on SOA

Web Service Layer in Fig.2 is the most important layer in the sensor web based on SOA, which plays a very important role to present the core services for upper lay- ers. SOA is a loose coupling distributed architecture and can make interoperability of the heterogeneous systems possible. SOA aims to allow users to string together fairly large chunks of functionality to form ad hoc applications that are built almost entirely from existing software services. SOA generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services.

According to the SWE Sensor Web 2.0, the system should comprise standards that specify the interfaces of the different sensor web services. Four service interfaces are introduced for the sensor web： The Sensor Observation Service (SOS) offers pull-based access to sensor measurements as well as metadata. The Sensor Alert Service (SAS) allows subscribing to alerts in case of a sensor measurement event that fulfills certain criteria. The Sensor Planning Service (SPS) can be used for tasking sensors and setting their parameters. The Web Notification Service (WNS) is, unlike the other three services, not directly sensor related. It is a supportive service which provides asynchronous notification mechanisms between SWE services and clients or other SWE services (e.g., delivery of notifications) including protocol transducing capabilities. While the SAS has evolved to the more powerful Sensor Event Service (SES), the WNS has not yet been further developed.

The most important web service is the Sensor Observation Service (SOS), which provides access to sensor observation data and sensor metadata. The service acts as a mediator between clients and a real-time marine observation platform. The heterogeneous communication protocols and data formats of the associated sensors are hidden by the standardized interface of the SOS. Sensor data requested by a client are returned as observations. The interface of the SOS supports the access of heterogeneous sensor types, stationary as well as mobile sensors which gather their datain situor remotely. The details of interactive actions of SOS, SPS, WNS, DAQ Service are illustrated in Fig.3.

In fact, according to the marine observation instruments status, the concrete web service interfaces added in marine sensor web are defined as follows：

Fig.3 Interactive Actions of Sensor Web Services Based on SOA.

RegisterPlatform： used to finish the enrollment of a platform;

InsertObservation： used to upload the observation data of a platform;

DescribePlatform： used to get metadata of all platforms;

DescribePlatformByID： used to return metadata of the platform by ID;

GetInstruments： used to get the instrument information by Platform ID;

GetParameters： used to get the observing parameter information by Platform ID;

GetProfiles： used to get profile measurement information by Platform ID and Instrument ID;

GetObservationInfo： used to get metadata information by Platform ID, starting time and end time;

GetInstrumentStatus： used to get current status information by Platform ID, current request time;

GetObservationData： used to get observation data by Platform ID, start time and end time;

GetLatestObservationInfo： used to get the latest metadata information by Platform ID.

2.3 Marine Sensor Web Based on EDA

Due to different semantic process layer and architecture style, the development method of workflow applications is complex based on event-driven architecture. To handle the complexity of EDA method, in fact, it needs to be built on the MDA (Model-Driven Architecture) software design approach, which can help save development software time. The method provides as much as possible automated transformation for the different steps in Fig.4; the main benefit results from the automatic transformation of the semantic business process specification layer to the very detailed BPEL workflow layer.

The following are transformation steps of the method in detail.

Step 1： Semantic Process Definition

Fig.4 EDA overview.

The first step is the creation of the process specification by marine domain experts. For this task any process modeling tool, such as the ARIS toolset, can be used.

Step 2： Event Extraction

The second step is the automatic extraction of all event names from the process specification.

Step 3： Process of Workflow Transformation

The third step is the transformation of process control flow to an abstract BPEL flow.

Step 4： Wiring to Complex Events

Wiring of source-events to complex events,i.e. the specification of the rules how complex events are created, is defined using a dedicated event wiring tool.

Step 5： Production of Executable Code

The last step is a purely technical step. This step mainly produces the executable BPEL code and WSDL definitions.

3 System of Marine Sensor Web

When successfully implemented, the system of Marine Sensor Web in our marine sensor observation platform can be applied to other industry information resources management. We propose to introduce it as early as possible to be the recommended standard of marine sensor networks integration, providing a better way of accessing sensor data for the marine researchers.

3.1 XML Format of Platform Capabilities and Sensor Data

Capabilities XML of marine observation platform provides the description of sensors and all available Web Service interfaces,i.e., the metadata of marine observation platform, which is illustrated in Fig.5. In fact the capabilities describe the types of sensors, the operations to gain remote access to sensor data, and the logical sensor grouping available to the consumer.

Fig.5 XML Format of capabilities’ elements.

Fig.6 Model View of Observation.

An observation illustrated in Fig.6 is an event that estimates an observed property of a feature of interest, using a procedure, and generating a result. Sometimes ‘observed property’ and ‘feature of interest’ are conflated in describing geophysical parameters,e.g. sea surface temperature.

According to the O and M encodings proposed in the OGC Observations and Measurements draft proposal, the two following formats were designed： The first is Full-Observation, which includes the sensor parameter metadata and sensor observation data, the second is SimpleObservation, that is, only the sensor observation data. Referring to the bandwidth restriction, Simple-Observation is the better format of sensor observation data.

3.2 Demo of Marine Sensor Web System

Demo of the marine sensor web is developed with google earth and map application programming interface (API), which let Web developers embed a 3D globe or 2D map into the Web pages, as displayed in Fig.7. It shows the 20 ocean sensors deployed in the sea area off the Laoshan coasts Qingdao, near China.

Fig.7 Demo homepage of marine sensor web system.

Fig.8 Details of sensor node20.

Fig.9 Sensor data curve of sensor node 20 (Time period：2008.4.5-2008.4.6)

If you click Sensor #20 node in the homepage, all the observation data of this sensor node can be seen from the next page illustrated in Fig.8.

Trough the ‘Display Curve’ selections you can get the sensor data of this sensor #20 node during a given time period. However the deployed sensor only detects the environment temperature and light values near the sea. But you can view the sea current data curve illustrated in Fig.9.

4 Conclusions

This paper presents the Marine Sensor Web based on SOA and EDA, which also included the MBARI’s PUCKprotocol, IEEE 1451 and OGC SWE 2.0. The case study has demonstrated that a standards-based system can be built to access sensors and marine instruments distributed globally using common web browsers for monitoring the environment and conditions of oceans. Besides the marine sensor data on the web, this framework of marine sensor web can also play an important role in many other fields, including weather forecasting, emergent applications, and EventWeb.

Future work is to provide more EDA new technologies, which are also expected to merge into the Marine Sensor Web concept. There are different areas of tools that would help a marine expert to use the proposed methods of model BPEL processes and transformation patterns. The expressivity and accessibility provided by such an integrated sensor web is important and significative to realize integrating sensors data of the Geo-Web.

Acknowledgements

This work was supported by the open fund project‘Research of Information Service of Marine Sensor Web’(Grant No. 2011002), the project ‘Research on Channel-Characteristics-Oriented Data Transmission Algorithm in USNs’ of NSF of China (Grant No. 61202403), the projects ‘Research of Making Regulation of Testing Technology of Device Interface’ and ‘Development and Application of Real-Time and Long-Term Observation Network Under Nearshore and Adjacent Marine Areas’ of Public science and Technology Research Funds Projects of Ocean(Grant No.201305033-6, No.201105030). The authors thank Drs. YU Yu, LU Yunhong and JIANG Ming- xing for their reviews and providing the wide knowledge of IEEE 1451, PUCK and OGC SWE standards, which improve this paper.

Alves, A., Arkin, A., Askary, S., Barreto, C., Bloch, B., Curbera, F., Ford, M., Goland, Y., Guzar, A., and Kartha, N., 2007. Web services business process execution language version 2.0 (OASIS standard).WS-BPEL TC OASIS, 21-25.

Balazinska, M., Deshpande, A., Franklin, M. J., Gibbons, P. B., Gray, J., Nath, S., Hansen, M., Liebhold, M., Szalay, A., A. and Tao, V., 2007. Data management in the worldwide sensor web.IEEE Pervasive Computing, 30-40, DOI： 10.1109/ MPRV.2007.27.

Bröring, A., Maué, P., Janowicz, K., Nüst, D., and Malewski C., 2011. Semantically-enabled sensor plug and play for the sensor web.Sensors, 7568-7605, DOI： 10.3390/s110807568.

Bröring, A., Echterhoff, J., Jirka, S., Simonis, I., Everding, T., Stasch, C., Liang, S., and Lemmens, R., 2011. New generation sensor web enablement.Sensors, 2652-2699, DOI： 10. 3390/s110302652.

Chen, N. C., Di, L. P., Yu, G. N., and Min, M., 2009. A flexible geospatial sensor observation service for diverse sensor data based on web service.ISPRS Journal of Photogrammetry andRemote Sensing, 234-242, DOI： 10.1016/j.isprsjprs.2008.12. 001.

Chen, N. C., Di, L. P., Yu, G. N., Gong, J. Y., and Wei, Y. X., 2009. Use of ebRIM-based CSW with sensor observation services for registry and discovery of remote-sensing observations.Computers and Geosciences, 360-372.

Gibbons, P. B., Karp, B., Ke, Y., Nath, S., and Seshan, S., 2003. Irisnet： An architecture for a worldwide sensor web.IEEE Pervasive Computing, 2 (4)： 22-33, DOI： 10.1109/MPRV. 2003.1251166.

Jeff, S., Peter, P., Jonathan, L., Mema, R., Margo, S., and Matt, W., 2004. Hourglass： An infrastructure for connecting sensor networks and applications.Technical Report,Harvard University, Columbia, 1-13.

Jirka, S., Bröring, A., and Stasch, C., 2009. Discovery mechanisms for the sensor web.Sensors, 2661-2681, DOI： 10. 3390/s90402661.

Kevin, A. D., Shannon, P. J., David, W. J., Scott, C. B., Richard R. W., and Baker, V. R., 2005. Environmental studies with the sensor web： Principles and practice.Sensors, 5 (1)： 103-117, DOI： 10.3390/s5010103.

Kevin, A. D., 2011. The sensor web： A macro-instrument for coordinated sensing.Sensors, 270-285, DOI： 10.3390/s2070 0270.

Lee, K., 2000. IEEE 1451： A standard in support of smart transducer networking,Proceedings of the 17th IEEE Instrumentation and Measurement Technology Conference, Baltimore, MD, 2： 525-528, DOI： 10.1109/IMTC.2000.848791.

Liang, S. H. L., Croitoru, A., and Tao, C. V., 2005. A distributed geospatial infrastructre for sensor web.Computers and Geosciences, 221-231, DOI： 10.1016/ j.cageo.2004. 06.014.

Mike, B., George, P., Carl, R., and John, D., 2007. OGC sensor web enablement： Overview and high level architecture (OGC 07-165).Open Geospatial Consortium White Paper, 175-190, DOI： 10.1007/978-3-540-79996- 2_10.

Mike, B., and Alex, R., 2007. Bringing the sensor web together,Geosciences, 6： 46-53.

Muehl, G., Fiege, L., and Pietzuch, P. R., 2006.Distributed Event-Based Systems. Springer, Heidelberg, 1-24.

Nischal, D., Durbha, S., King, R. L., and Younan, N. H., 2009. Sensor web for interoperability in power systems.Proceeding of North American Power Symposium(NAPS), DOI： 10.1109/ NAPS.2009.5484027.

Silvia, N., 2009. A survey of geosensor networks： Advances in dynamic environmental monitoring.Sensors, 5664-5678, DOI：10.3390/s90705664.

Song, E., Y., and Lee, K. B., 2009. A standard-based global ocean monitoring system.Proceedings of ICEMI’ 2009, 445-449, DOI： 10.1109/ICEMI.2009.5274835.

Teillet, P. M., 2010. Sensor webs： A geostrategic technology for integrated earth sensing.IEEE Journal of Selected Topics in Applied Earth Observations and Remote Sensing(IEEE J-STARS). 10-14, DOI： 10.1109/JSTARS.2010.2050578.

van Zyl, T. L., 2008. GEOSS from orbit, a sensor web approach.Proceeding of IEEE International Geoscience and Remote Sensing Symposium, DOI： 10.1109/IGARSS.2008.4778811.

Wang, Y., Liu, Y. J., and Guo, Z. W., 2011. Three-dimensional ocean sensor networks： A survey.Journal of Ocean University of China, 11 (4)： 436-450, DOI： 10.1007/ s11802-012-2111-7.

(Edited by Ji Dechun)

(Received September 30, 2013; revised May 7, 2014; accepted June 11, 2014)

© Ocean University of China, Science Press and Springer-Verlag Berlin Heidelberg 2015

* Corresponding author. E-mail： jiangyg@ouc.edu.cn