system engineered to support research and management of water resources at watershed scales. The system architecture is comprised of three primary tiers: (i) ...
The Intelligent River : Implementation of Sensor Web Enablement Technologies across Three Tiers of System Architecture: Fabric, Middleware, and Application David L. White, Samuel Esswein, Jason O. Hallstrom, Farha Ali, Shashank Parab, Gene Eidson, Jill Gemmill, Christopher Post Clemson University {whitedl, sesswei, jasonoh, farhaa, sparab geidson, gemmill, cpost} @clemson.edu ABSTRACT
Service (SAS) is used to provide near-real time notifications of sensor status and QA/QC failures. In this paper, we report on our experiences, both positive and negative, and outline potential solutions to some of the most important obstacles we have encountered.
Population growth, energy demand, and climate change are placing an unprecedented strain on water resources, requiring a fundamental shift in how these resources are managed. More precisely, resource management programs must embrace a new paradigm, one with realtime environmental monitoring at its core. The Intelligent River© is an environmental and hydrological observation system engineered to support research and management of water resources at watershed scales. The system architecture is comprised of three primary tiers: (i) a field-deployed sensor fabric and uplink infrastructure, (ii) real-time data streaming middleware, and (iii) repository, presentation, and web services. Sensor Web Enablement (SWE) adoption decisions revolve around balancing efficiency concerns and implementation time with capability and standards compliance. In this context, our team has examined, applied, and evaluated SWE technologies to enable data archival, access, and discovery.
KEYWORDS: SWE standards and implementations, Sensor Web data visualization, Sensor Web data management interoperable middleware.
1. INTRODUCTION Advanced monitoring networks are increasingly necessary to support the management of water resources from local to global scales. Urban and agricultural runoff and even pharmaceutical/personal care products are contributing to biological and chemical contamination of surface and groundwater [25]. Climate Change may ultimately affect global and regional water resources thus putting additional pressures on human populations and societies [26]. Ultimately, these issues will require an integrated management approach to provide resource estimation, provisioning, and pricing [3].
We have found varying levels of success with SWE adoption across the three tiers. At the fabric layer, platform configurability and ease-of-integration have been important engineering drivers. SensorML arose as a natural candidate solution; however, its resource requirements are largely incompatible with our target hardware platforms. At the middleware layer, recent efforts have focused on the use of SensorML and a metadata catalog to perform metadata annotation. This solution appends SensorML elements onto incoming observations, supporting data processing and semantic resolution. During early development of middleware technologies, we linked sensor platforms with web services using the transactional profile of the Sensor Observation Service (SOS) to perform data insertion and retrieval queries. At the application level, SOS is used to support data discovery and access, and Sensor Alert
978-1-4244-6622-1/10/$26.00 ©2010 IEEE
These monitoring networks will need to support variable spatial and temporal scales to provide data across a spectrum of observation types from biological to physical. The supporting sensor infrastructures will need to monitor contaminant loads, release and hold water resources for human consumption, monitor ecological function, and access industrial and agricultural needs. This necessitates advanced software architecture(s) to provide for access to quality assured data in real-time that are available to multiple data users, configurable with other data providers, documented with industry standard metadata, and usable across a suite of mobile, web, desktop and modeling tools.
340
The Intelligent River© is developing and operating an environmental and hydrological observation system to support research and provide real-time monitoring, analysis, and management of water resources in South Carolina. The Intelligent River© was conceived as a massive-scale macroscope capable of providing highprecision visibility into the physical world for purposes of enabling advanced environmental and hydrological modeling, high-fidelity visualization, and scientificallybased decision-making processes. This vision calls for unparalleled data density, both temporally and spatially. This is an end-to-end hardware/software infrastructure engineered to support real-time monitoring and management of water resources across the state. We are exploring, and in some cases have implemented, Open Geospatial Consortium (OGC) Sensor Web Enablement (SWE) technologies to support the three tiers of the Intelligent River© software architecture: (i) sensing fabric, (ii) middleware, and (iii) application shown in Figure 1. The sensing fabric must offer unparalleled configuration, management, and energy efficiency capabilities. To support these performance criteria we are exploring SWE technologies (i.e., SensorML) as a potential metadata standard. For the middleware tier, we are implementing SWE standards to support a brokered publish/subscribe streaming data system. The application tier of Intelligent River© is designed to support the use of Sensor Observation Services (SOS) [14] and Sensor Alert Services (SAS) [12]. SOS and SAS provide interfaces for applications and users to consume data and metadata from the Intelligent River©. These efforts are part of our design strategy as we implement a second-generation architecture based on experiences and field-testing of our first-generation architecture. Details of current and potential future uses of SWE technologies are discussed in the following sections.
Figure 1. Relevant SWE Standards and Alternatives sophisticated communications features and generalized tools for visualization, data inspection, and data archival. Hiding communication complexities and standardizing the deployment process shortens implementation time. Interoperability is achieved through adopting standards and conventions across organizations and industry. A key component of the Intelligent River© approach is the incorporation of streaming data middleware that relies on a brokered publish/subscribe messaging layer between the sensing fabric and the application. The sensing fabric (or sensor assets, as identified by the OGC) may include “observation archives, simulations, and observation processing algorithms in addition to physical sensors” [15]. This design decision provides a number of communication features not available in a traditional client/server model. First and foremost, it provides any number of clients the capability to immediately receive data as it becomes available. A real-time visualization client has the opportunity to receive data with the same service quality as a data archival tool writing to a relational database system. This streaming approach is no longer a novel approach but has yet to receive universal adoption, likely due to added complexity and resource requirements.
Paper Organization. Section 2 provides an overview of the Intelligent River© project. Section 3 discusses the use of SensorML at the first tier of the network, the sensing fabric. Section 4 describes the implementation of the SWE within the framework of our middleware tier. Section 5 discusses the use of SWE standards at the application tier. Finally, Section 6 concludes with a summary of our work and pointers to future efforts.
2. INTELLIGENT RIVER© DESIGN
Added functionality owing to the middleware comes from generalized applications to process, visualize, and archive observation data. These applications subscribe to data streams and automatically incorporate data that the messaging layer routes to them. The Intelligent River© currently includes three general-purpose archival mechanisms to handle scalar observation data, including a NetCDF archive, text, and a relational database [3].
Planning, implementing, and maintaining a data collection effort is an expensive and time-consuming undertaking. Technology offers the opportunity to maximize the return on a monitoring program by adding capability, decreasing implementation time, and improving interoperability. Improving capability can be achieved by providing
341
sensor deployed near the Monterey Bay Aquarium Research Institute – one of the standard examples advocated by the OGC [22]. The specification is basic, but illustrates the use of a number of elements relevant to the nodes within the fabric tier. In particular, the document specifies descriptive search tags, instrument identifiers, hardware characteristics, communication interfaces, deployment coordinates, sensor parameters, accuracy guarantees, range constraints, gain and offset values, and various other elements. This description could be further extended to capture the in situ process chain applied to derive each post-processed observation. These are precisely the elements that must be configured on each sensor platform for a device to fulfill its collection, processing, and transmission responsibilities; and the elements that must be made available to upper-tier application services to interpret the content, accuracy, and lineage of each observation.
Intelligent River© real-time visualization tools provide web-based methods of viewing observation trends, spatial locations, and payload contents. Examples of observation processing tools include automated quality assurance and quality control tools [3]. Integration of heterogeneous sensor systems across institutional boundaries requires recognizing and adhering to conventions for interoperability. This integration supports data sharing and broader application compatibility, adding value to data products. The SWE initiative provides a promising opportunity for achieving industry-wide interoperability through the development of standards for models, services, and encodings of sensor assets [15]. To promote interoperability, the Intelligent River© has adopted aspects of the SWE and other scientific data conventions.
3. SENSING FABRIC
Despite the conceptual suitability of SensorML for use in configuring and documenting the sensing fabric, our team has thus far been unsuccessful in achieving significant integration at this tier of the architecture. To understand the source of the difficulty, it is useful to consider the design of the underlying platform hardware. Specifically, the sensing fabric must consist of a large number of sensors capable of achieving extended network lifetimes, which are relatively inexpensive and offer unparalleled energy efficiency. To satisfy these requirements, we developed the MoteStack, a component-based sensornetworking platform that relies on a stackable hardware design to achieve device configurability [3]. While the details of the platform are beyond the scope of this paper, two salient characteristics must be emphasized: First, the platform is inexpensive. Depending on the configuration of the device, the cost ranges between approximately $60 and $200 – far below the cost of traditional field instruments. Second, the platform enables extended field deployments. Depending on the hardware configuration and the duty cycle imposed by the supporting firmware, a node can operate in the field for several months to a year on a single 9v lithium-ion battery, and analyses suggest that lifetimes can be extended with larger batteries.
The first tier of the Intelligent River© architecture serves as an intelligent sensing fabric that provides dense, multiparameter coverage over a large geographic area comprised of wireless sensor networking platforms and an associated uplink station. Each platform is responsible for collecting a specified set of environmental and/or hydrological data, processing that data, and communicating the results to the appropriate uplink. The processing performed at each node varies from one deployment to another, but may include localized quality assurance checks (e.g., range checking, temporal stability validation), distributed quality assurance checks (e.g., spatial stability validation), observation adjustments (e.g., offset and gain changes to negate drift), data storage (e.g., to an integrated MicroSD card), and other actions appropriate to a given deployment. The results are then transmitted over a short distance (i.e., 300ft to 6mi) to a high-powered uplink station that relays the results back to Clemson’s high performance computing backbone using a site-specific (IP-based) uplink technology (e.g., cellular, satellite). From this brief description, the motivation for adopting SensorML [13] as the principal metadata standard for configuring and documenting the nodes that compose this tier is clear: The standard affords descriptive capabilities that are well-matched to the concepts that must be captured to configure the tier and consume the data it provides. Introducing support for SensorML at each installation point provides the usual benefits attributed to the standard – simplified configuration processes, automated node discovery, simplified system integration, archival support, SWE support, etc. [29]. To highlight this point, consider the well-known SensorML specification of the buoy-mounted conductivity-temperature-pressure
To simultaneously ensure low cost and energy efficiency, the MoteStack platform relies on common-off-the-shelf embedded microcontrollers that offer deep-sleep functionality. The microcontroller operates at a maximum rate of 20MHz and offers 64K of ROM, 4K of RAM, and 2K of EEPROM storage [1] – orders of magnitude less resource than a standard desktop machine in every dimension. As a point of reference, the SensorML document for the buoy-mounted sensor discussed above requires approximately 24K – six times larger than the total amount of RAM available on the platform! And this observation brings us to the heart of the difficulty in
342
integrating SensorML within the fabric tier: SensorML was architected with desktop-class machines in mind. And suitable extensions to the standard are required to enable integration in resource-constrained devices.
standard benefits. It is important to note that our design is inspired by the work of Priyantha et al. [23], who have demonstrated a similar approach in the context of adapting web services to resource-constrained devices.
A seemingly natural solution immediately presents itself: Rather than integrating SensorML within the resourceconstrained confines of the MoteStack platform, the integration focus could be redirected to the uplink stations or the middleware. While this strategy is effective in enabling upper-tier lookup and discovery services, it suffers from three important limitations. First, it introduces an additional consistency management task, and consequently, another opportunity for error. Specifically, the approach requires network managers to maintain consistency between the metadata repository and the underlying network. This can be a challenging task, particularly in large, dynamic networks. Second, the approach precludes the possibility of node discovery and its associated benefits – most notably, the ability to automatically configure upper-tier services based on the addition of a new node in the field. Finally, the approach hinders the application of SensorML in configuring the behavior of the sensing fabric.
4. STREAMING DATA MIDDLEWARE The Intelligent River© middleware approach provides functionality for enabling communication, setting conventions for data/metadata encodings, and linking processes in order to provide useful data to applications and users. Our effort addresses challenges common to distributed observation efforts including those extensively explored in the OGC SWE initiative [15] to support industry-wide interoperability standards and technologies.
4.1. Communication Model The Intelligent River© approach to communication allows any number of data producers to exchange observation data with any number of data consumers. Observation data is exchanged via channels or data streams. This streaming approach is real-time in the sense that data is pushed to consumers as it becomes available, rather then a more technical definition involving adherence to formal quality of service criteria. Communication is asynchronous and anonymous in the sense that neither party is required to maintain any knowledge or dependency on the other.
To enable “deep” integration of SensorML in large-scale sensing systems, the resource requirements of the specification standard must be reconciled with the capabilities of “mote”-class sensing components such as the MoteStack. To this end, we are in the initial stages of designing a lightweight counterpart to the SensorML standard, which we refer to as MoteML. The approach is not to reinvent SensorML; indeed, we fully embrace the SensorML standard and the benefits it provides. Instead, we are developing a condensed representation format for storing, processing, and communicating SensorML documents from upper-tier components to mote-class devices, and vice-versa. Our intent is not to support the full standard, but to focus on the subset of the SensorML schema appropriate to the design of our sensing fabric. The approach relies on three compression techniques: (i) strip all comment data from the input document, (ii) map each SensorML element to a corresponding binary record structure, and (iii) compressing text blocks, some of which may encode binary data.
There are many middleware offerings implementing the brokered publish/subscribe or notification based communications model. Streaming data middleware technology is widespread, with applications ranging from audio/video conferencing [7] to particle physics data visualization [4]. These solutions may be general-purpose messaging systems such as RabbitMQ [20] or domainspecific. Within the environmental science community, the DataTurbine project [6] is a well-known middleware system providing streaming data functionality. Among the OGC SWE standards, the Web Notification Service (WNS) provides an analogous web services approach to notification functionality [19]. The open source NaradaBrokering software, developed by the Community Grids Laboratory at Indiana University [9], provides the basis for the Intelligent River© messaging substrate [5].
The final step in realizing SensorML integration at the fabric tier is developing a bidirectional transformation service capable of translating documents expressed using the standard SensorML encoding to semantically equivalent documents expressed using the MoteML encoding, and vice-versa. The service will be installed at each uplink station, serving as a document gateway. It will effectively hide the MoteML representation from upper-tier devices, providing the illusion of standard SensorML integration, and thereby enabling all of the
To participate in the Intelligent River© middleware, data producers and consumers must adopt this streaming data approach. Application layer software receives observation data and may choose to archive the data into a persistent format (e.g. a relational database) or perform a procedure on the data and republish it, such as quality assurance and quality control (QA/QC) procedures. Other middleware
343
technologies may adapt to Intelligent River© data streams or persistent storage systems. For the sake of clarity, these approaches are distinguished from the Intelligent River© middleware and are subsequently considered as part of our application tier.
4.2. Metadata & Data Encodings In addition to providing a simple, standardized interface for in situ network developers, the software translates observation data into common representation models before it is published onto the messaging substrate. The Unidata Common Data Model (CDM) [27] was chosen as a canonical format because of the availability of application programming interfaces and data processing tools. Following this approach, the Unidata NetCDF Markup Language (NcML) [28] was originally chosen to represent metadata elements (e.g., site information, publisher information, measurement units). The NcML metadata records were used to populate CDM header data during the translation of native sensor data into a standard observation format. Primarily a functional metadata, NcML is less suited for our organizational and descriptive metadata requirements. An alternate metadata convention has been implemented that supports SensorML-based descriptive metadata to describe data products and sensing equipment.
Figure 2. Process Chain of South Carolina, USA. A technological goal of this project was to evaluate the applicability of O&M and the transactional profile of the Sensor Observation Service (SOS) [14]. At the time, no implementations supporting the optional transactional profile were available. A custom application server was developed with Java and the open source SWE common data framework developed by the Visualization-Analysis Sensor Technology (VAST) team at University of Alabama Huntsville [29]. The data collection periods were short and allowed human-guided operation. The project utilized a customdeveloped data acquisition board that interfaced with a cellular telephone supporting J2ME. The higher-level functionality of this platform enabled the creation and packaging of simple XML and communication via the HTTP protocol. The nature of this implementation offered the opportunity to place a significant portion of the application logic close to the sensing instrument.
Proper operation of the Intelligent River© middleware relies on the accuracy and validity of its metadata documents. A challenge faced by our developers and users alike is generating and maintaining metadata records. In addition to centralizing and allowing discovery of sensor assets, we have explored alternatives for sensor data repositories and administration interfaces. Storage is currently accomplished with a flat file collection of metadata documents stored in a web accessible directory. We have developed a web-based metadata management tool using PHP as a development platform. A publicly available sensor discovery interface provides information about the platforms and sensors. This application includes a Google Maps visualization of the geographic location, a list of sensors with specification sheets, a link to the SensorML file(s), and a picture of the platform(s). An administrative interface provides secured access to create and edit metadata records. Authentication is enabled from the Intelligent River© web site that uses Shibboleth [24] and RaidP [21] for verifying credentials against the Clemson University Active Directory.
4.3. Process Chain Supporting a mechanism to link procedures to generate observation data is accomplished through a combination of metadata instructions and middleware routing methods, as shown in Figure 2. Within the Intelligent River© middleware, the first processing step is to convert native sensor data, from a wide range of formats, into a welldescribed encoding format, as described above. We rely
4.2.1. Observations & Measurements Pilot The application of the OGC Observations & Measurements (O&M) specification [11] as a data encoding standard was evaluated during a sediment dynamics monitoring project located in the upstate region
344
will investigate the applicability of extending our metadata documents to include additional aspects of the process chain.
5. APPLICATION INTEROPERABILITY The Application component of the Intelligent River© is designed and implemented en part, according to OGC SWE [15], including the use of the SOS [14] and SAS [12] standards. SOS and SAS web services provide interfaces for applications to interact with Intelligent River© data repository and metadata catalog as shown in Figure 3. Their main objective is to provide access to sensor data on demand, and to send notifications of events of interest occurring in the system to event subscribers. Implementation details of these services are discussed in the following sections.
5.1. Sensor Observation Service (SOS) The SOS is deployed to support third-party access to the Intelligent River© data repository. Its implementation hides the details of actual data collection, retrieval, and querying. Applications send their requests to the SOS server using HTTP post or get requests. Observation data includes metadata about the sensors and the environmental measurement(s). The sensor metadata are encoded in a SensorML document, whereas the observation values are encoded using the Observations & Measurements standard. All SOS servers are required to provide three services: GetCapabilities, DescribeSensor, and GetObservation collectively referred to as the core services.
Figure 3. SOS and SAS Application Interoperability on information in our metadata documents to instruct our software gateways how to perform this conversion. In the majority of cases we have encountered, the complexity of the translation step necessitates custom application logic. At runtime, our gateway loads a custom translation class for each instance of a sensor. When an incoming observation is uniquely identified and associated with a metadata record, it can be routed to a corresponding translation class. The gateway application then publishes the structured data, along with its metadata onto the publish/subscribe middleware. The sensors metadata document is again referenced to populate routing instructions in the observation header. This routing instruction is in the form of a hierarchical topic space that enables selective accessibility to the subscribers [3].
A GetCapabilities request returns an XMLencoded “capabilities” document structured according to the schema provided by the SOS specification that lists available SOS services with links to access them and information sensors. Sensor information includes unique ID of sensor at the SOS server, type of observation, and spatial features. An application can examine capabilities documents to search for a sensor to fulfill its requirements. Intelligent River© SOS prepares the capabilities document by retrieving metadata from the SensorML repository as each request arrives. DescribeSensor service returns information about one specific data-producing procedure that can be a single sensor or group of sensors. Currently, single sensors are the only data producing entities within the Intelligent River©. The DescribeSensor request requires sensorID as an input parameter, and returns a SensorML or TransducerML [16] encoded document containing a sensor position, inputs, outputs and calibrations. The Intelligent River© SOS redirects the DescribeSensor request to the corresponding SensorML file in the
Further processing may be accomplished within the Intelligent River© middleware. For example, we utilize a collection of QA/QC applications to monitor the status of our sensors. These applications act as both publishers and subscribers in our communication model. They receive observation data and depending on their purpose, alter or annotate observation data based on statistical operations before republishing the data onto the messaging substrate with updated routing instructions. Subscribing applications filter incoming observation data based on hierarchical topics. A subscriber can limit their interest to QA/QC’d data by limiting their subscriptions to particular topic spaces. Currently, the linking of observations using topic spaces is achieved in an ad hoc manner. Future work
345
GeoRSS feed based on the W3C Basic Geo Vocabulary, which is a RDF vocabulary for representing the latitude and longitude of spatially-located things. We have combined the Basic Geo Vocabulary with the Dublin Core metadata standard to support descriptions of the failure [2, 30]. This GeoRSS feed is available for any map service (e.g., Google Map API, Yahoo Map API, or other Geo-enabled RSS consumers).
metadata catalog. The GetObservation service provides access to sensor observation values and accepts arguments to filter the results. The SOS server uses the arguments of GetObservation request to send a query to the data repository and then formats the query results as an O&M observation before sending back the response.
5.2. Sensor Alert Service (SAS)
6. DISCUSSION
The SAS acts both as an alert registry/management system and an event notification system. The alert registry/management system is designed and implemented using OGC’s SAS standard. Applications can register with a web service to receive alert notifications. The alert registration/management system is implemented using the API specification provided by the OGC, which includes GetCapabilities, SubscribeAlert, SubscribeResponse, CancelSubscription and RenewSubscription, and DescribeSensor services.
The Intelligent River© project has elected to incorporate some aspects of the SWE standards while diverging from its architecture in others. This is primarily due to perceived performance and complexity trade-offs and ease-of- integration with current architecture tiers. Among the tiers of the Intelligent River©, the application layer offers the most promise for our adoption of the data exchange and discovery aspects of SWE. The benefits include wider visibility for our data collection efforts and access to SOS client tools as they become available. In addition, there is wide community support for other OGC standards such as the Web Feature Service (WFS) [17] and Web Map Service (WMS) [18], which are integrated into our application tier through the use of Geoserver [8], thus enabling a suite of data/metadata dissemination services.
GetCapabilities returns a listing of SAS server capabilities, including available SAS services and links to access them, available alert-delivery channels, and observation types available for alert subscription. This document is prepared by gathering observations listed in the data repository. SubcribeAlert allows consumers to subscribe to alert notifications either manually at the web service interface or by sending an HTTP post request to the SubscribeAlert service’s URL. A subscription is valid for 24 hours from the time of service subscription. After 24 hours, the subscription is deactivated and alerts are stopped. A subscriber can renew or cancel its subscription using CancelSubscription and RenewSubscription. Information about subscribed alerts including consumer information, delivery channel, and filter criteria are stored in a relational database.
Our efforts to develop unparalleled configuration, management, and energy efficiency capabilities at the sensing fabric have found that the current SWE standards (e.g., SensorML) do not meet the criteria that are needed. Although SensorML has the needed descriptive capabilities to support mote configuration and data consumption, it was not designed for resource limited devices such as mote-class sensing platforms. Our efforts are focused on design and implementation of a lightweight standard that builds upon SensorML as a principal metadata standard for configuration and documentation of nodes.
We have extended the functionality of the SAS beyond the current specification. In addition to standard OGC alert notifications to consumer applications (as discussed above), the service alerts system administrators about sensor status in the case of failure and QA/QC warnings. These alerts are generated when a sensor does not function as expected, such as a failure to report within a pre-determined time period, or reporting observation values that fail QA/QC checks. A service is implemented which runs periodically and checks the timestamps and values of observations reported in the data repository. If the timestamp is older than the accepted threshold value, an email is sent to the administrator noting the time since the last reported observation. Similarly, all reported values are checked against QA/QC data stored in the data repository, and if a QA/QC failure is detected, an email is sent to the administrator. This service also publishes a
At the streaming data middleware tier, we consider the communication model, data encodings, and process chain. Web services approaches to publish/subscribe communications are available [10, 19]. However, these specifications place additional programmatic burdens on developers and may incur a performance penalty resulting from additional message enveloping steps. The choice of a data and metadata encoding standard is a second significant challenge encountered by our middleware tier. As described above, this is particularly difficult when considered alongside our fabric tier. Communications and efficiency concerns are paramount to our design decisions at this tier. Based on our interpretation of the SWE standards, the Observations & Measurements and
346
TransducerML specifications offer alternatives for representing observation data, and SensorML and TransducerML offer metadata representation alternatives. The proper function of the Intelligent River© software architecture demands a convention for data and metadata representation. At the middleware tier, we have begun supporting SensorML to allow richer sensor description.
[5] S. Esswein, C. Post, J. Hallstrom, D. White, and S. Goasguen, “Application of Publish/Subscribe Messaging for Management of Streaming Water Resource Data,” Proceedings of the 2008 South Carolina Water Resources Conference. October 14-15, 2008. North Charleston, SC [6] T. Fountain, S. Tilak, P. Hubbard, P. Shin, and L. Freudinger, “The Open Source DataTurbine Initiative: Streaming data middleware for environmental observing systems,” 33rd International Symposium on Remote Sensing of Environment, 4-9 May 2009, Stresa, Italy.
One of the most promising aspects of SWE is the potential for a formalized description of the observation process chain. We currently employ a simple but effective means of describing a limited portion of the process chain based on our metadata records, which convert native sensor values into structured and well-described observation measurements. An area of active investigation is the process of linking published observations with processing tools to generate new or modified observation data (e.g. a resampling operation). Incorporating the message routing mechanisms of our communication model into a formal process chain described by SensorML will help address an area currently achieved by ad hoc methods in our subscribing applications.
[7] G. Fox, G. Aydin, H. Bulut, H. Gadgil, S. Pallickara, M. Pierce, and W. Wu, “Management of real-time streaming data Grid services: Research Articles,” Concurrency and Computation: Practice and Experience, 2007, 19(7) 983998. [8] Geoserver. www.geoserver.org, 2010 (last accessed). [9] Narada Brokering Project. www.naradabrokering.org, 2010 (last accessed). [10] Oasis Web Services Brokered Notification (WSBrokeredNotification). xml.coverpages.org/WSBrokeredNotification.pdf, 2010 (last accessed).
ACKNOWLEDGEMENTS
[11] Open Geospatial Consortium Inc. OpenGIS: Observations and Measurements – Part 1 - Observation schema, OGC 07-022r1, Open Geospatial Consortium Inc., 2008.
This work was supported through the Clemson PSA Remote Sensing Initiative, Clemson Computing and Information Technology, and the NSF (CNS-0745846). The authors gratefully acknowledge these agencies for their support.
[12] Open Geospatial Consortium Inc. OpenGIS: OGC Sensor Alert Service (SAS) Candidate Implementation Specification, OGC 06-028r3, Open Geospatial Consortium Inc., 2006.
REFERENCES
[13] Open Geospatial Consortium Inc. OpenGIS: Sensor Model Language (SensorML) Implementation Specification, OGC 06-028r5, Open Geospatial Consortium Inc., 2007.
[1] Atmel Corporation, ATmega644/V Preliminary, http://www.atmel.com/dyn/resources/prod_documents/do c2593.pdf, August 2007.
[14] Open Geospatial Consortium Inc. OpenGIS: Sensor Observation Service (SOS), OGC 06-009r6, Open Geospatial Consortium Inc., 2007.
[2] Dublin Core® Metadata Initiative. Dublincore.org, 2010 (last accessed).
[15] Open Geospatial Consortium Inc. OpenGIS: Sensor Web Enablement Architecture, OGC 06-021r4, Open Geospatial Consortium Inc., 2008.
[3] G.W. Eidson, S.T. Esswein, J.B. Gemmill, J.O. Hallstrom, T.R. Howard, C.J. Post, C.T. Sawyer, K.C. Wang, and D.L. White. “The South Carolina Digital Watershed: Endto-end support for realtime management of water resources,” The 4th International Symposium on Innovations and Real-time Applications of Distributed Sensor Networks, May 18-21, 2009, Hangzhou China.
[16] Open Geospatial Consortium Inc. OpenGIS: Transducer Markup Language, OGC 06-010r6, Open Geospatial Consortium Inc., 2007. [17] Open Geospatial Consortium Inc. OpenGIS© Web Feature Service Implementation Specification, OGC 04094. Open Geospatial Consortium Inc., 2005.
[4] J. Ekanayake, S. Pallickara, and G. Fox. “A collaborative framework for scientific data analysis and visualization,” International Symposium on Collaborative Technologies and Systems CTS 2008, pages 330-346, Irvine, California, May 2008.
[18] Open Geospatial Consortium Inc. OpenGIS© Web Web Map Server Interface, OGC 03-109r1. Open Geospatial Consortium Inc., 2004. [19] Open Geospatial Consortium Inc. OpenGIS© Web Notification Service (WNS) Best Practices Paper, OGC 06-095. Open Geospatial Consortium Inc., 2007.
347
[20] RabbitMQ. www.rabbitmq.org, 2010 (last accessed). [21] Research Affiliate Identity Provider www.raidp.org, 2010 (last accessed).
(RaidP).
[22] A. Robin, MBARI CTD Buoy System (SensorML Specification), http://vast.uah.edu/index.php?option=com_content&view =article&id=130:mbari-buoy-system&catid=61:marinesensors, October 2006. [23] N.B. Priyantha, A. Kansal, M. Goraczko, and F. Zhao, “Tiny Web Services: Design and Implementation of Interoperable and Evolvable Sensor Networks,” Proceedings of the 6th ACM Conference on Embedded Network Sensor Systems, pages 253-266, Raleigh, NC, USA, November 4-7, 2008. [24] Shibboleth®. www.shibboleth.internet2.edu, 2010 (last accessed). [25] S.A. Smyth, L. Lishman, S. Kleywegt, L.M. Svoboda, HB. Lee, and P. Seto, “Pharmaceuticals and Personal Care Products in Canadian Municipal Wastewater,” Proceedings of the Water Environment Federation, WEFTEC 2008: Session 41 through Session 50, pages 3505-3518(14). [26] L.G. Thompson, E. Mosley-Thompson, H. Brecher, M. Davis, B. León, D. Les, P. Lin, T. Mashiotta, and K. Mountain, “Abrupt tropical climate change: Past and present,” Proceedings of the National Academy of Sciences of the United States of America, 2006, 103(28), 10536-10543. [27] Unidata. Common Data Model. www.unidata.ucar.edu/software/netcdf-java/CDM/, 2008 (last accessed). [28] The NetCDF Markup Language (NcML). www.unidata.ucar.edu/software/netcdf/ncml/, 2010 (last accessed). [29] University of Alabama in Huntsville (UABH), Introduction to SensorML, http://vast.uah.edu/index.php?option=com_content&view =article&id=14&Itemid=52, January 2010 (last accessed). [30] W3C Basic Geo Vocabulary. www.georss.org/w3c, 2010 (last accessed).
348
