Worldwide Sensor Web Framework Overview - CiteSeerX

Worldwide Sensor Web Framework Overview I. Rhead, M.Merabti, H. Mokhtar, P.Fergus School of Computing and Mathematical Sciences Liverpool John Moores University Byrom Street, Liverpool, L3 3AF, UK. email {cmpirhea, m.merabti, h.m.mokhtar, cmppferg}@livjm.ac.uk Abstract— Environmental sensing is seen as key to understanding the physical processes that affect our lives. The collection of such data is used to enhance the decision making processes of governments, organizations and society as a whole in their future interactions with the planet. In order to be able to generate a global picture of the effects a physical phenomenon may have it is necessary to generate a framework which is capable of networking sensing devices on a global scale. This paper presents an initial overview of a framework to facilitate the worldwide networking of a wide variety of sensing device types into a Worldwide Sensor Web. Index Terms— Sensors, Distributed Systems

Sensor

Web,

Framework,

I. INTRODUCTION Current worries regarding climate change, coupled with the seemingly increasing frequency of freak weather events, has increased the desire to more fully understand the effect our actions are having on the Earths physical processes. Environmental data is now routinely collected from many different sources, for many different purposes. Sensing devices deployed range in scale from satellite monitoring platforms to highly constrained devices collaborating to capture physical data in a sensor network. This near global coverage of sensing devices has been likened to an electronic skin for the Earth capturing the physical data, the results of which when analysed, can underpin decision making processes of governments, organisations and help shape the way society thinks about the Earths processes and our interaction with them. Much of this data collection effort is undertaken by individual organisations for a particular purpose, usually with a limited scope. The data collected could be immensely valuable in obtaining a wider view of the Earths natural processes and give a valuable understanding of our effect upon them. If the physical data that is currently being collected for specific scientific or commercial purposes

ISBN: 978-1-902560-19-9 © 2008 PGNet

were made available to others it could be cross-referenced, collated and analysed in order to gain a fuller appreciation of the wider implications of real world phenomenon other than those it was specifically intended to capture. In addition to the issue of data independence, potential duplication of effort, both in the setup of sensing devices and the data gathering effort is likely to be experienced. The Worldwide Sensor Web concept aims to facilitate the gathering, sharing and analysis of physical data through the networking of sensor devices. The abstraction of the detailed working, protocols and communications of the sensing device from the methods of gathering, sharing and analysing the physical data allows the collection effort currently underway to be incorporated into such a system. The utilisation of a service oriented architecture, through the use of web services allows the integration of components to facilitate the discovery, accessibility, querying and, where applicable, control of sensor devices made available by the sensor owners through the Worldwide Sensor Web.

Worldwide Sensor Web

Fig. 1. Conceptual view of the Worldwide Sensor Web

Although the capture of environmental data is, perhaps, the most obvious application of a Worldwide Sensor Web, there are many other application areas that would take benefit from its implementation. Many of these application areas, such as military, healthcare, civil infrastructure and home monitoring are discussed with reference to sensor networks [1]. These application areas and others would benefit from the introduction of a Worldwide Sensor Web in

a number of ways. Chiefly the data derived from different sensing devices and sensor networks could be fused and manipulated making it available in a number of formats, for a number of different purposes. A Worldwide Sensor Web is not limited in scope to scientific endeavours, or those with the technical expertise required to setup and operate the sensing devices or sensor networks. This allows the data to be opened up for commercial usage such as including real world effects in games, allowing vehicle satellite navigation systems to alter a route to avoid congestion and a myriad of other uses. The implementation of a Worldwide Sensor Web has many research areas to be overcome before it can become viable as an application in the real world. Previous proposed frameworks have not discussed the issue of data storage, and the querying of historical data, in any great depth. The querying of the Worldwide Sensor Web is one of the key motivations behind its delivery and this area needs to be considered in much more detail than in previously proposed frameworks. There are a number of components that are required in order to deliver a distributed Worldwide Sensor Web system and in section 3 an overview of the Worldwide Sensor Web framework is given. A brief outline of the operation of the Worldwide Sensor Web in the satisfaction of a query is given in section 4. Section 5 concludes the paper.

II. BACKGROUND Several groups are currently working towards developing a Worldwide Sensor Web framework. The Open Geospatial Consortium has developed a series of standards for the delivery of a set of services and encodings, as part of their wider OpenGIS standards and specifications, entitled Sensor Web Enablement (SWE) [2]. Four web services are proposed: Sensor Observation Service, Sensor Planning Service, Sensor Alert Service and Web Notification Service. Three methods of data encodings and models are specified: Observations and Measurements, SensorML and TransducerML. The SWE proposals do not include a complete implementation but are rather specifications for Worldwide Sensor Web developers to use when creating applications, platforms and products relating to the capture of physical data through networked sensor devices. NICTA at the University of Melbourne have produced the Open Sensor Web Architecture (OSWA). OSWA [3] is a fully SWE compliant Worldwide Sensor Web implementation. It has been extended since the first implementation and discussion. It takes the services defined in the SWE standards and adds numerous proposals to provide additional functionality, such as stateful services,

data storage and caching due to disparate networking speeds of the wired Internet and potentially much lower speeds of wireless sensor networks. The Sensor Internet Share and Search project [4] is inspired by the way in which users interact, and share information, with the Worldwide Web. Three sources of data are mentioned: sensor publishers, data stores and republishers. The sensor data streams would be accessible from the web through the use of sensor search engines. Functionality is added to the data through the use of the republisher who would take data from sensor publishers or data stores and perform some functionality to it, such as cleaning up data streams, aggregating data from different data publishers etc. Microsoft is developing SensorMap [5] as part of its SenseWeb project to provide an online GUI application enabling the querying and visualising of captured physical data. The SenseWeb project allows sensor owners to register their sensing devices and publish their captured physical data which will then be made available to users through SensorMap. SensorMap provides a simple way of selecting sensors and a geographical region of interest. GeoSWIFT [6] is again an SWE compliant implementation of a Worldwide Sensor Web. A sensor web client capable of visualising physical data has been developed along with a series of stateless Web Services. The GeoSWIFT implementation is capable of communicating with webcams as its sensing medium and does include data storage capabilities in the form of a registry service. It can be seen from this brief overview of current projects, along with others such as [7, 8], the delivery of a global physical sensed data delivery framework is a current, active research field. The main goals of such a framework is to provide an almost infinite scalability allowing sensing devices, the data they produce and any required functionality to be added, managed and used in an intuitive manner. Each of the proposed frameworks above satisfies these high level requirements to some extent. The framework we discuss in the following section has been conceived to fully handle these requirements.

III. WORLDWIDE SENSOR WEB FRAMEWORK The Worldwide Sensor Web would be composed of a number of components each of which would offer defined roles within the system. The system could be distributed over the Internet with components being held on accessible servers as required. Messaging between components would be undertaken in a Worldwide Sensor Web Structured Language. The Worldwide Sensor Web Structured

Language would be delivered between components in a structured XML document wrapped in a HTTP message. The relationship between the components of the Worldwide Sensor Web is shown in Fig. 2. The responsibilities of the components of the Worldwide Sensor Web are listed below.

involve a period of time between the initial query, and the response to the client. The Query Handler must handle potentially many thousands of concurrent connections, mapping unique queries to their respective originator. Therefore the Query Handler must be able to keep track of all ongoing queries it is currently handling. A register within the Query Handler would need to be able to relate a particular query back to its originating client in order for the results to be delivered. B. Sensor Register

Fig. 2. Relationship between components

A. Query Handler The Query Handler will be capable of accepting messages from users through one of three possible methods. A web browser provides the simplest method of obtaining a single, individual, query from a user. A web application would facilitate the querying of the worldwide sensor web and the visualisation of data. Specific client applications could be developed to access the data directly from the Worldwide Sensor Web on an ongoing basis. The web portal would necessarily suffer in terms of its flexibility and visualisation options whilst the client application development would be entirely the responsibility of the user. A third method of accessing the worldwide sensor web could be provided by a downloadable worldwide sensor web browser. This would provide much of the flexibility inherent in the client application whilst removing the technical requirements of developing such an application. Regardless of the method of connection the Query Handler would provide the point of contact to the Worldwide Sensor Web. Messages could be queries, sensor control requests or user management requests. As the Query Handler is the initial point of contact between users and the Worldwide Sensor Web it must also forward messages to other components as required. For example a pre-registered user wishing to login would send the request to the Query Handler which would then forward it to the User Register. The Query Handler is responsible for checking the validity of any messages received and actioning them as required. User management requests would be forwarded to the User Register for action. Sensor control messages would be forwarded to the relevant Sensor Interface. A query made of the Worldwide Sensor Web would

The sensor register holds list of all sensor assets that are made available via the Worldwide Sensor Web. Previous proposed registries for sensor networks have relied on a centralised database system such as in [9], or a web services based system [10] A distributed database system such as that used by the DNS system [11] used in the World Wide Web offers a model which is extensible to cater for the, potentially, millions of sensing devices which could be made available over the Worldwide Sensor Web. However, whereas addresses within the DNS system are arranged according to a hierarchy of domain name spaces, the sensor register could be arranged more effectively according to the geographical region the sensing device resides in. This hierarchical method of arranging the sensor register is demonstrated in Fig. 3. WorldWide

Africa

Antarctica

South Africa

Maghreb

Asia

Australasia

North Africa

Nile Valley

Europe

N. America

Western

Sahara

UK

S. America

Eastern

Continental

Fig. 3. Sensor Registry structure example

A pre-configured sensor asset which is made available to the Worldwide Sensor Web from the Internet for the first time will automatically attempt to register itself with the sensor register. The sensor register will need to check each submission for validity, possibly necessitating an exchange of messages between the sensor register and the sensing devices interface. Upon acceptance of the submission as valid the sensor register will be updated in its geographical region as required. A query made of the Worldwide Sensor Web would require a geographical range and type of sensor be specified within it. This geographical range and sensor type could be used by the Query Handler to query the sensor register in order to obtain addressing information for the interfaces of

the sensing devices within the specific geographical area of the specified type. C. Sensor Interface The interface acts as bridge between the Worldwide Sensor Web and the sensor assets themselves. It could be implemented at the sensor or resident on a server which is directly linked to the sensing device. The sensor interface allows the workings of the sensing device to be made invisible to the Worldwide Sensor Web. Its main function is to accept messages from the Worldwide Sensor Web, convert these into sensor specific messages, task the sensor as required and convert the resulting messages back to a format relevant to the Worldwide Sensor Web Structure Language. Where historical data is required from the Worldwide Sensor Web to satisfy a query the interface would message the data store related to the sensing device. The returned result would then be bundled and returned to the Query Handler. A conceptual overview of the sensor interfaces role in the query process is shown in Fig. 4.

Fig. 4. Sensor Interface role

The Sensor Interface would also assume responsibility for access control to a sensing device. It is possible that a sensor owner would wish to restrict access to the results returned by the sensing device and probable that any control messages to the device would be restricted to the sensor owner. The current user session would form the basis of any access control decisions. The Interface would provide a wrapper to the control software for the sensing device. It would require configuration which would necessarily need to be completed prior to the sensing devices introduction to the Worldwide Sensor Web. The sensor owner would need to work through a configuration program in order to complete this configuration process. Upon activation of the sensing device the pre-configured Sensor Interface would then

automatically register the sensing device with the Sensor Register. In the case where a sensing device provides push based, event driven data the sensing device will send this data to the sensor interface, which will forward it to the sensing devices data store. D. Sensor Data Store Each sensing device will have a data store which it records its results to. It is most likely that these will be database management systems developed for the World Wide Web which are accessible via standard SQL queries. The sensing devices interface will provide access to the data stores. It is possible that there will be a great range in scale of these storage systems from small data stores maintained by individuals or research groups with larger data stores maintained by universities and organisations. In [4] the possibility of central storage hosts selling storage space is explored. This has benefits in that administration and backup duties are removed from the sensor owner and such ventures are able to take advantage of quantity of scale. It is entirely possible that current Web hosting companies could utilise the servers they have to provide this kind of service. As with the other components of the Worldwide Sensor Web the sensor data stores need to be addressable and discoverable A balance for the storage of metadata associated with sensed data needs to be discovered between the sensor interface and the sensor data stores. The point is made in [12] that environmentally sensed data has two types of metadata, common and dynamic metadata. Common metadata does not change between events and would include such information as sensor type, location, unit of measure, etc. This type of data could be included in the interface for the sensing device or in the sensor register for retrieval. Dynamic metadata such as time of measurement needs to be stored with the sensed data in the sensors data store. E. Functionality Register The data returned from the sensing devices would potentially require transformation functionality be applied. Data from different sources will need to be fused in order to gain the wider appreciation of the natural phenomenon being monitored by the sensing devices. This fusion will almost certainly require some level of transformation of one if not all of the different data results. The transformation functionality will be presented through a register of functionality presented as Web Services. Some of the functions will be standard, such as conversion of sensed

data between different measurement units. For example a temperature value conversion between Celsius and Fahrenheit. It is possible that users will write functions specific to data types, such as object recognition in camera images. These functions could also be made available over the Worldwide Sensor Web through the functionality register. Allowing users to share their data transformation functionality to be applied to raw data streams ensures that the Worldwide Sensor Web evolves to suit the requirements of the users of the system. Some of the required transformation functionality will be evident from the results returned by the sensing devices. For example different units of measure from two data sources will necessitate transformation of one of the results in order to fuse the result. Functionality such as averaging results of a period of time could be achieved by mapping keywords in the generated query with data transformation functions. This would allow these functions to be applied to the raw data returned from the sensing devices by the Query Handler.

Functional Register

Publish Find

Function Provider

Interact

Worldwide Sensor Web Query Handler

Fig. 5. Conceptual Functional Register operation

F. User Register Users of the Worldwide Sensor Web should be capable of interacting with it beyond the simple raising of queries. A user may wish to register with the Worldwide Sensor Web for a number of reasons. These might include the subscription to event driven data streams, the inclusion to a group for sensor access control purposes, the registration of persistent queries and to specify delivery methods for results to queries. The User Register will perform a number of key functions within the Worldwide Sensor Web framework. The Query Handler would send the result of any queries to the User Register in order that it may be delivered to the user in the required manner. Where the user has not specified a delivery method it will simply be the task of the User Register to deliver the results back to the address the query was raised from. If an alternative delivery method is specified the results will be delivered as directed.

A user may login as a member of the Worldwide Sensor Web using a pre-registered account which would create a user session. The user session would be maintained by the User Register. One area that benefits from the creation of a user session lies in the area of sensing device access control. Where access control rules are in place the Sensor Interface would contact the User Register to establish the credentials of a user attempting to gain access to that sensing device. Sensing devices producing event driven data would inform the User Register of when data was produced in order that the data can be delivered to interested parties. In addition to storing the data at its nominated data store, an event driven sensing device would also deliver a copy of the data, and its associated metadata to the User Register in order that it may be formatted to interested users. The User Register would then deliver the resultant data in accordance with that users specified delivery method.

IV. WORLDWIDE SENSOR WEB QUERY OPERATION A user or application raising a query of the Worldwide Sensor Web would require a connection to the Query Handler component. After establishing the validity of a query the Query Handler would then contact the Sensor Register to establish a list of relevant sensor devices based on type and geographical location. The Query Handler would then contact each of the sensing devices via their interfaces in order to obtain the physical data as a result of the query. Any required transformations of the data, specified in the query, will then be obtained from the functionality register. The Query Handler will then apply the functionality published by the function provider to the raw data returned from the sensing devices. If a user session is established the result will then be forwarded to the User Register in order that the result can be delivered to the user in the required manner. An overview of the query process is shown in Fig. 6.

Fig. 6. Overview of query process

V. CONCLUSION

REFERENCES

This document describes a new Worldwide Sensor Web framework which is implementable using existing technologies. The concept is for a framework which allows the addition of a wide variety of heterogeneous sensing devices which allow users to be able to easily query them, and extract meaningful results in an intuitive manner. Whilst frameworks for a Worldwide Sensor Web have been previously discussed, the framework introduced in this paper tackles the issue of integrating sensor networks and mobile sensors in addition to static, relatively powerful sensing devices such as PCs with sensing devices attached. The framework aims to facilitate access to both real time and historical sensed data, through a variety of access methods. As the devices are likely to produce immense amounts of data during their operation, the framework needs to address the issue of scalability. The Worldwide Sensor Web aims to address scaling concerns via a distributed sensor register and the capacity for each sensing device to choose and access their own data storage mechanism. The ability of users to develop and share transformation functionality and data visualizations gives a greater range of extensibility to the framework than that offered by previous proposed frameworks. In summary, this paper shows there are many research issues to be addressed in order to provide an implementable Worldwide Sensor Web.

[1] Akyildiz I.F., et al., (2002), "A Survey on Sensor Networks", Communications Magazine, IEEE, vol.40, issue.8, August 2002, pp.102114. [2] Botts M., et al., (2006), "OGC Sensor Web Enablement: Overview and High Level Architecture", Open Geospatial Consortium, OGC White Paper, OGC 06-050r2 v2, 19th July 2006 [3] Chu X., Buyya R., (2007), "Service Oriented Sensor Web," in Sensor Networks and Configuration: Fundamentals, Standards, Platforms and Applications, N. P. Mahalik, (ed). Springer-Verlag, 2007, pp. 51-74, 978-3540-37364-3 [4] Reddy S., et al., (2007), "Sensor-Internet Share and Search - Enabling Collaboration of Citizen Scientists", ACM Workshop on Data Sharing and Interoperability on the World-wide Sensor Web, Cambridge, Mass. USA, April 2007. [5] Nath S., Liu J., Zhao F., (2007), "SensorMap for Wide-Area Sensor Webs", IEEE Computer Magazine, 40, issue.7, July 2007, pp.106-109. [6] Liang S.H.L., Tao V., Croitoru A, (2004), "Sensor Web and GeoSwift An Open Geospatial Sensing Service", ISPRS XXth Congress, Istanbul, Turkey, 12-23rd July 2004, pp.1-6. [7] Gibbons P.B., et al., (2003), "IrisNet: An Architecture for a Worldwide Sensor Web", Pervasive Computing, IEEE, vol.2, issue.4, Oct-Dec 2003, pp.22-33. [8] Moodley D., Simonis I., (2006), "New Architecture for the Sensor Web: the SWAP Framework", ISWC 2006: 5th International semantic web conference, Athens, GA, USA, 5-9 November 2006, pp.1-17. [9] Park J., et al., (2007), "The Registry for Sensor Network Discovery", Proceedings of the 12th IEEE International Conference on Engineering Complex Computer Systems (ICECCS2007), Auckland, New Zealand, July 11-14, pp.129-137. [10] Delicato F.C., et al., (2003), "A Flexible Web Service based Architecture for Wireless Sensor Networks", Proceedings of the 23rd International Conference on Distributed Computer Systems (ICDCSW'03), Providence, Rhode Island, USA, May 19-22nd 2003, pp.958-961. [11] Lui C., Albitz P., (2001), "DNS and BIND 4th Edition", O'Reilly, 0596-00158-4 [12] Balazinska M., et al., (2007), "Data Management in the Worldwide Sensor Web", Pervasive Computing, IEEE, vol.6, issue.2, Apr-Jun 2007, pp.10-20.