DI proposed a sensor Web and virtual sensor definitions

Transcription

1 IEEE SENSORS JOURNAL, VOL. 11, NO. 6, JUNE A Flexible Data and Sensor Planning Service for Virtual Sensors Based on Web Service Zeqiang Chen, Nengcheng Chen, Liping Di, Senior Member, IEEE, and Jianya Gong Abstract How to achieve a flexible data and sensor planning service to schedule, plan, and empower diverse sensors and heterogeneous data ordering systems is a big challenge. In this paper, a service-oriented framework of data and sensor planning service for virtual sensors is proposed. The framework includes an Open Geospatial Consortium (OGC)-compliant Sensor Planning Service (SPS), a Web Notification Service (WNS), a Sensor Observation Service (SOS), and virtual sensors. There are two important key technologies in this framework, namely a flexible SPS middleware and an asynchronous message notification mechanism. The flexible SPS middleware, based on a configuration file and standard interfaces, is adopted to integrate virtual sensors into a sensor Web. A WNS-based asynchronous notification middleware is used to inform the user of the status of a task that may need midterm or long-term actions. The framework has been successfully demonstrated in application scenarios for Simplified General Perturbations Satellite Orbit Model 4 (SGP4) and Earth Observation System ClearingHOuse (ECHO). The results show that the proposed method has the following improvements over the existing SPS implementation: a uniform planning service for more satellites, a seamless connection with data order systems, and a flexible service-oriented framework for virtual sensors. Index Terms ECHO, sensor observation service, sensor planning service, sensor Web, SGP4, virtual sensor. I. INTRODUCTION DI proposed a sensor Web and virtual sensor definitions from the computational viewpoint and under the serviceoriented architecture (SOA) and Web service environment [1]: a sensor web is a group of interoperable web services which all comply with a specific set of sensor behaviours and interface specifications. In this definition, a web Manuscript received August 17, 2010; revised October 10, 2010; accepted November 12, Date of publication November 29, 2010; date of current version April 20, This work was supported in part by the National Basic Research Program of China under Grant 2011CB707101, Chinese 863 program under Grant 2007AA12Z230, the National Natural Science Foundation of China under Grant and , and the NASA ESTO/AIST Sensor Web Program under Grant NNX06AG04G. The associate editor coordinating the review of this paper and approving it for publication was Prof. Georgios Papadimitriou. Z. Chen is with the State Key Laboratory for Information Engineering in Surveying, Mapping and Remote Sensing (LIESMARS), Wuhan University, Wuhan, Hubei , China, and also with the Center for Spatial Information Science and Systems (CSISS), George Mason University, Fairfax, VA USA ( czq0119@gmail.com). N. Chen and J. Gong are with the State Key Laboratory for Information Engineering in Surveying, Mapping and Remote Sensing (LIESMARS), Wuhan University, Wuhan, Hubei , China ( cnc_dhy@hotmail.com; geogjy@163.net). L. Di is with the Center for Spatial Information Science and Systems (CSISS), George Mason University, Fairfax, VA USA ( ldi@gmu.edu). Digital Object Identifier /JSEN service which contains an algorithm or simulation model could be a senor in a sensor web as long as its interfaces and behaviours comply with the specifications. We call such a sensor the virtual sensor. From this definition, a sensor Web that complies with Open Geospatial Consortium (OGC) Sensor Web Enablement (SWE) specifications [2] can be called an OGC sensor Web, while a sensor Web that complies with the IEEE 1451 standard [3] can be called an IEEE sensor Web. Moreover, a Web service that contains an algorithm or simulation model to comply with a sensor Web standard can become a virtual sensor. For example, the National Aeronautics and Space Administration (NASA) provides an Earth Observing System Data and Information System (EOSDIS) [4] for users to freely access earth science data and services; if we use the OGC SWE specification to access this system, we can see this system as a virtual sensor. The OGC s SWE standards enable developers to make all types of sensors, transducers and sensor data repositories discoverable, accessible and usable via the Web. There are three information models: Sensor Model Language (SensorML) [5], Observation and Measurements (O&M) [6], [7], and Transducer Markup Language (TML) [8], and five service implementation specifications: Sensor Planning Service (SPS) [9], Sensor Observation Service (SOS) [10], Sensor Alert Service (SAS) [11], Sensor Event Service (SES) [12], and Web Notification Service (WNS) [13] in the SWE framework. An SPS is designed to enable an interoperable service by which a client can determine collection feasibility for a desired set of collection requests for one or more sensors/platforms, or a client may submit collection requests directly to these sensors/platforms. There are four mandatory operations: GetCapabilities, DescribeTasking, Submit, and DescribeResultAccess, and four optional operations: GetFeasibility, GetStatus, Update, and Cancel. Chen et al. proposed a flexible SOS for diverse sensors based on Web service [14]. An SOS is designed for managing deployed sensors and retrieving sensor data. Whether from in situ sensors (e.g., water monitoring) or dynamic remote sensors (e.g., satellite imaging), measurements made from sensor systems contribute most of the geospatial data by volume used in geospatial systems today. There are three mandatory core operations: GetCapabilities, DescribeSensor and GetObservation, and six optional operations: RegisterSensor, InsertObservation, GetObservationById, GetResult, GetFeatureOfInterest, and DescribeFeatureType. A WNS is a service by which a client may conduct asynchronous dialogues (message interchanges) with one or more other services. This service is useful when many collaborating X/$ IEEE

2 1430 IEEE SENSORS JOURNAL, VOL. 11, NO. 6, JUNE 2011 services are required to satisfy a client request, and/or when significant delays are involved is satisfying the request. There are four mandatory operations: GetCapabilities, Register, Unregister, and DoNotification. SWE builds a unique and revolutionary framework of open standards for exploiting Web-connected sensors and sensor systems for many types, especially providing the opportunity to add a real-time or near real-time sensor dimension to the Internet and the Web [15]. It is very important for science research, environment monitoring, disaster management, and many other domains of activity. For example, a flood happens in East Lake (a lake in Wuhan, China), and there is a sensor Web system. The government wants to know how much of the area has been flooded today and tomorrow. We may obtain live data from the sensor Web system, historic data from a data ordering systems, and further observations from some satellite scheduling systems; however, many SPS prototype systems described in Section II are only standard-based implementations and are not flexible enough to conduct data and sensor planning under the virtual sensor Web system. Taking this flooding example into consideration, we can see that there are at least the following problems to be faced in the phase of data ordering and sensor planning. 1) The current implementation of SPS is mainly suitable for real sensors, but is rarely applied, or difficult to apply to a data ordering system, which in this paper is especially defined as a Web based system that gives user convenient means to order data the system can provide. 52 North developed four plug-ins for its SPS, which are real sensors like the AXIS(TM) camera and a track vehicle [16]. Earth Observing (EO)-1 SPS provides EO-1 satellite planning data [17]. Meanwhile, many data ordering systems are not wrapped by SPS listed as follows: National Oceanic and Atmospheric Administration (NOAA) National Environmental Satellite, Data and Information Service provides geostationary satellite images and polar satellite images [18]. They are distributing environmental satellite data. Earth Observation System ClearingHOuse (ECHO) is a metadata clearinghouse and order broker being built by NASA s Earth Science Data and Information System (ESDIS) [19]. The data are now published by the ECHO Web service. AutoChem is NASA release software that constitutes an automatic computer code generator and documenter for chemically reactive systems written by David Lary between 1993 and the present [20]. It was designed primarily for modeling atmospheric chemistry, and in particular, for chemical data assimilation. These data ordering systems are related to the data about environment, ocean, atmosphere and land, so they are very important in our lives and scientific research. If we wrapped them with SPS, it would be meaningful. 2) The current implementation of SPS is mainly suitable for a single sensor and has some difficulties to plan several sensors at the same time. Section II details some implementations, frameworks, and application related with SPS. These implementations are pointed at one sensor at a time, for example, EO-1 SPS is only for EO-1 satellite data. If a user wants higher resolution images at a special place at a cer- Fig. 1. The comparison of SPS implementation. tain time, it is powerless. A good solution is to find out what satellites will be in the required place at the appropriate time, and then invoke these satellites to obtain the required data, but at present rare SPS can do this. To solve the above problems, we use the virtual sensor concept and propose a flexible Data and Sensor Planning Service (DSPS). We take all the required Web services or resources as virtual sensors and integrate these virtual sensors into a standard-compatible sensor Web. Related work is described in Section II. Section III presents the system architecture of DSPS and interactions between SOS, SPS, and WNS. Section IV outlines the key technologies, including the flexible DSPS middleware and WNS-based asynchronous notification mechanism. Section V uses two virtual sensors cases, namely the NASA MODIS data ordering system and satellite orbit planning system to illustrate the feasibility of the proposed method. Section VI discusses the better properties of the framework, and Section VII summarizes the conclusions and outlines further work. II. RELATED WORK There are some implementations, frameworks and applications related with SPS. The 52North Sensor Web community focuses on the development of a range of services and implementations related to SWE [21]. It implements SOS, SPS, SAS, SES, WNS, and SWE Client using the Java language. 52North SPS provides standard interfaces to collection assets and is a Java servlet. Its framework contains three components: the controller, the asset manager (AM), and the profile manager (PM). The controller serves as a front-end to validate incoming requests and to forward them to the other two components depending on the kind of request. The PM is responsible for answering GetCapabilites, DescribeTasking, and DescribeResultAccess requests. The AM is the main part of the application. GetFeasibility, Submit, GetStatus, Update, and Cancel requests are delivered to this service. The

3 CHEN et al.: A FLEXIBLE DATA AND SPS FOR VIRTUAL SENSORS BASED ON WEB SERVICE 1431 Fig. 2. Service-oriented architecture of flexible DSPS. AM is a framework that is capable of supporting every type of sensor as long as a plug-in has been provided and registered for this sensor type. GeoBliki EO-1 SWE data node [17] provides a SPS implemented by the Hypertext Preprocessor (PHP) language, a general-purpose scripting language that was originally designed for producing dynamic Web pages. The SPS is deployed as a Common Gateway Interface (CGI) and allows an authorized user to task the EO-1 satellite for specific data products in a geographic location. This capability is offered by using HTTP GET, POST and Simple Object Access Protocol (SOAP) interfaces. It implements GetCapabilities, DescribeGetFeasiblity, DescribeSubmit Tasking, DescribeResultAccess, Submit- Tasking, and GetStatus. In the National Information and Communications Technology Centre of Australia (NICTA), Open Sensor Web Architecture (NOSA) [22] implements a set of uniform operations and a standard representation for sensor data, which will meet the software needs of a sensor network regardless of the deployment scenario. The SPS is responsible for a user s observation request and retrieving O&M encoded data from the Sensor Collection Service (SCS). Once the O&M data are ready, it will notify the user by WNS. The design of the SPS considers both the short-term and long-term requirements of the user s plan, for it utilizes a rule engine to clarify the feasibility of the plan made by the user, and uses a Scheduler, which is implemented as a separate thread. Northrop Grumman Corporation (NGC) has been using the SWE standards in a major internal research and development project called Persistent Universal Layered Sensor Exploitation Network (PULSENet). PULSENet [23] is a sensor Web framework that has been used to integrate a variety of real sensors over the Internet to demonstrate the feasibility of a standards-based, interoperable sensor Web. PULSENet has utilized 52 North s open source, Java-based SPS instance for interacting with Axis network video cameras, and has developed a custom,.net-based SPS instance for interacting with a long-range earth observation (EO) or infrared (IR) camera. Several legacy and non-ogc SWE standards compliant sensors are brought into the sensor Web framework through the Sensor Listener Service (SLS) developed by NGC, a plug-in based component that translates vendor-specific sensor descriptions and data into SensorML and O&M and registers new sensors with the PULSENet SOS. Fig. 1 shows that almost all SPS have implemented all the mandatory and optional operations. The implementations are suitable for physical sensors, but not consider or flexible enough for data ordering systems. The Distributed Computing Platform request is HTTP Get/Post and very little is SOAP/XML (Extensible Markup Language) protocol. In short, the existing SPS are mainly designed to some applied aspects they concerned, and have a challenge or not flexible enough for virtual sensors. III. DESIGN A. Architecture The aim of this system is to develop a flexible DSPS to compile all kinds of sensors and virtual sensors. There are some considerations: 1) this system must implement all the standard interfaces of SPS and the related interoperation with SOS; 2) it should be flexible to all kinds of sensors and virtual sensors include physical sensors, sensor systems, data ordering system and satellites planning systems; 3) the architecture of this system must be loosely coupled and components must be machine and platform independent to allow for worldwide use on the Internet; and 4) this system must be a Service Oriented Architecture (SOA) to make it discover access and can be invoked by different clients with a Web service method. To meet the above goals, service-oriented middleware architecture is proposed as in Fig. 2. There are three main layers in this architecture: Application Layer, Business Layer, and Sensor and Virtual Sensor Layer. The Application Layer is the presentation layer of user clients. Its main function is to get user s requests such as a SOS request, or a SPS request. When the responses of those requests come back, the results can be presented in the form of a XML document, statistical tables and graphs, image, URL, or some data visualization. Service requestors can find service through this layer. The Business Layer consists of a uniform Web Services Description Language (WSDL) service description, service controller, SPS implementation, SOS implementation and WNS im-

4 1432 IEEE SENSORS JOURNAL, VOL. 11, NO. 6, JUNE 2011 IV. IMPLEMENTATION A. Flexible SPS Middleware Fig. 3. Interaction of DSPS with other components. plementation. A uniform WSDL service description is used to expose the service, bindings, port types and operations about SPS and SOS. The service controller controls the service request and dispatches the service to SPS and SOS. SPS implementation is the implementation of SPS, and it has two main parts; one is the standard interfaces (SIs) defined in the SPS implementation specification, and the other is a flexible middleware. The SPS flexible middleware is used to connect the sensor or virtual sensor and how it is developed is explained in Section IV. SOS implementation implements SOS standard interfaces and WNS implementation implements WNS standard interfaces. The implementation of a flexible SOS is presented by Chen et al. [14]. The Sensor and Virtual Sensor Layer includes the physical sensors, sensor systems, data centers or Web services that can be integrated into virtual sensors. Sensor systems are the standard-compiled sensor systems and provide SPS, SOS, or SPS and SOS. Data centers are data order systems and can be regarded as virtual sensors. All those sensors and virtual sensors are regarded as service providers. B. Interactions Fig. 3 shows how DSPS communicates with the requester and the provider. 1) Interactions Between a Sensor Data Requester and DSPS: A sensor Web data requester obtains SOS data using the GetObservation operation, but before this operation the requester needs to invoke the GetCapabilities operation to discover the SOS capability information and invoke the DescribeSensor operation to inspect detailed sensor metadata for this sensor advertised in the observation offerings of the identified SOS instances. Meanwhile, the requester can interact with SPS directly using GetCapabilities, DescribeTasking, and Submit operations. The GetCapabilities operation is used to retrieve the SPS capability information. The DescribeTasking operation is used to get the task and the parameters the task needs. Requester invokes the Submit operation to submit a task. When SPS finishes the task or SOS can provide the data requester needs, WNS will notify the requester with the DoNotification operation. 2) Interactions Between a Sensor Web Data Provider and DSPS: Fig. 3 shows how a provider of sensor Web data interacts with an SOS that supports the transactional profile. Using SOS InsertObservation operation inserts the data coming from sensors, sensor systems or data centers into SOS. When the requester needs SOS data but there are no data in SOS, SOS will trigger SPS to submit a task to sensors or virtual sensors. There are two parts in the SPS flexible middleware; one is the configuration file and the other is SIs implementation. The configuration file is restricted by the XML schema, and it is used to flexibly add virtual sensor information including sensor XML, sensor task parameters and the name of the sensor implementation interfaces class. SIs implementation implements the standard interfaces of SPS. These two parts combine and integrate virtual sensors into a sensor Web. Their main attribute is that they make it easy for users to develop new sensor tasks. The detailed explanation is as follows. The configuration file XML schema (visualized by XMLSpy) is as in Fig. 4. SPSConfig is the root element of this configuration file and it has zero to an unbounded number of sensor elements, which describe the information of a sensor. There are two attributes and three elements in the sensor element. The attributes are name and id used to distinguish other sensors. The sensor description element sensorxml is used to describe a sensor with SensorML [5]. The sensor task description element task is used to describe what task the sensor can do and the parameters the task needs. The sensor implementation middleware element middleware is used to show the class one sensor used to collect the implemented SIs. collect means that this class can invoke all the SIs of this middleware. The SIs implementation means that a sensor implements SIs. SIs implements GetCapabilities, DescribeTasking, Submit, DescribeResultAccess, GetFeasibility, Get- Status, Update, and Cancel operations. DescribeTasking operation shows the content of the TaskConfig document. Submit is the interaction between SPS and the sensor or virtual sensor. DescribeResultAccess exposes the result URL. GetFeasibility checks whether the task and task parameters fit to the TaskConfig document. GetStatus shows the status of a sensor. Update can update the task of a sensor, while Cancel cancels the task. All the standard interfaces of SPS need to be implemented. The SIs implementation is designed and implemented using the Abstract Factory design pattern. The Abstract Factory pattern is intended to provide an interface for creating families of related or dependent objects without specifying their concrete classes [24]. Fig. 5 shows that abstract factory class SPSSensorFactory provides interfaces for creating real sensors (like RealSensor1Factory to RealSensorNFactory) and virtual sensors (like VirtualSensor1Factory to VirtualSensorNFactory) instances. SPSSensorOperation defines the operation interfaces of each concrete sensor and virtual sensor. Each concrete sensor or virtual sensor factory (as VirtualSensor1Factory) creates a concrete sensor or a virtual sensor operation. The interfaces in this system are designed and implemented according to SPS. Parsing the request XML document and wrapping the response XML document of interfaces use java APIs generated by XMLBeans and SPS schema. The submit operation is a very important operation for it is the only operation that SPS communicates with sensors or virtual

5 CHEN et al.: A FLEXIBLE DATA AND SPS FOR VIRTUAL SENSORS BASED ON WEB SERVICE 1433 Fig. 4. Configuration file schema of SPS flexible middleware. sensors. For different sensors or virtual sensors, the Submit operation is very different. But there are some similar implementation processes for all the sensors or virtual sensors as shown in Fig. 6. The first step is validating the whole tasking request XML document, and finding out whether it fits to an XML document standard. And then all the required parameters and their values are validated to make sure that they are all fit to task the XML document. Then, it is necessary to validate the optional parameters and check whether their values are correct. This first step is a GetFeasibility operation to check whether the tasking is right and feasible. The second step is wrapping the SPS task into a sensor or virtual sensor request. Wrapping requests vary according to diverse sensors or virtual sensors. Shown in Fig. 6, a real sensor directly wraps into a real sensor implementation; data centres need to wrap the SPS interface into the protocol and data model of this data centre; a Web service needs to wrap the request into a Web service request. The third step is submitting the request and obtaining the result. The whole SPS is implemented by Java. If users want to add their own sensors, they only need to fill the SPSConfig document and write a SIs implementation middleware, so it is very easy for users. B. WNS-Based Asynchronous Notification Middleware Because the sensors and virtual sensors are diverse and complex, SPS submits a task and the sensor or the virtual sensor may need midterm or long-term actions, which cause a basic requestresponse mechanism communication between a user and SPS to be unsuitable. In order to solve this problem, a WNS-based asynchronous notification middleware has been implemented. Reference [25] proposes a WNS-based asynchronous notification middleware by augmenting the OGC Web Processing Service with message-based asynchronous notification to resolve WPS asynchronous communication and notification problems, and we use it for reference. An asynchronous service wrapper is implemented. It acts as a server to receive the client s request and sends back the response later with a callback URL by implementing WNS s two-way communication for its end-users, and it acts as a client to interact with the SPS server by polling to check whether the response status has changed. There are four functional components in this wrapper: Register, Invoker, Parser and Informer. Register registers the client s request and the correlation ID of this request. This correlation ID has a unique value to be used to recognize the requestor when a response is returned. Invoker sends services requests to the SPS server. Its initial request includes the requested SPS server s URL and the requested services sent by the client that come from the Register. It also can be used by the Parser in later action. Parser is used to read and interpret the XML-based response from the SPS server and sends the result to the Invoker to poll the server again or to the callback component to process. Informer will get the callback URL from the request and send the parsed response to the specified callback URL of the client with the unique task correlation ID. There is one SOS transaction operation InsertObservation. We use SPS to plan sensors or virtual sensors for obtaining the required data, but after the sensors or virtual sensors can provide the data, the data will be inserted into SOS dynamically. The insert processes are as follows: first, there is a wrapper, which is implemented by flexible middleware, and wraps the data into the SOS InsertObservation XML document and sends this document to SOS Web service. Then, this SOS inserts operation triggers the refresh of the SOS initialization. V. CASE STUDIES In order to verify the feasibility of the proposed architecture and method above, we develop two case studies. The first one is wrapping a data order system such as the NASA MODIS order system as a virtual sensor. The other one is wrapping a satellite orbit planning system as a virtual sensor. In order to explain those two case studies better, the Section of each case study has the same organization structure which consist of four main parts: 1) Overview; 2) Experiment design; 3) Flexible DSPS middleware implementation; and 4) Experiment result. A. NASA MODIS Data Order System 1) Overview: ECHO is a metadata clearinghouse and order broker being built by NASA s ESDIS. ECHO is an operational open system based on XML and Web service technologies. ECHO is a middleware solution, which provides a SOA environment for the EO community. Now the services that ECHO

6 1434 IEEE SENSORS JOURNAL, VOL. 11, NO. 6, JUNE 2011 Fig. 5. Flexible SPS implementation of abstract factory pattern. provided are a data partners service, client partners service and service partners service. Users can obtain NASA s Earth Science Data such as MODIS through the client partners service. 2) Experiment Design: According to the service-oriented, flexible and easily extensible principle, the SOA experiment is designed as follows. Service provider (data server) is the ECHO metadata server provided by NASA. All ECHO metadata is stored in an Oracle database with spatial extensions, but it is invisible to client users, and client users can only ECHO APIs to obtain the metadata. The data entity of metadata is published by the NASA FTP server. Service broker (DSPS server) can be deployed on any computer that can link to the Internet. In this experiment, the Service broker is deployed in our server ( Service requesters are the users on the Internet, and they can use Web service technology to invoke these Web services in the DSPS server. 3) Flexible DSPS Middleware Implementation: The procedures of wrapping ECHO as a virtual sensor are given below. Config configuration file. As shown in Fig. 7, Name is nasa_modis_sensor, and id is urn:ogc:object:feature:sensor:liesmars:modis. sensorxml document is

7 CHEN et al.: A FLEXIBLE DATA AND SPS FOR VIRTUAL SENSORS BASED ON WEB SERVICE 1435 Fig. 8. A sensorml document. Fig. 6. Submit operation implementation process. Fig. 7. Configuration file. nasa_modis_sensorxml.xml, and the content is as in Fig. 8. The task document is nasa_modis_task.xml, and the content is as in Fig. 9. Middleware is the main class that implements the SIs, and its name is cn.edu.whu.liesmars.swe.sps.sensor.nasamodis. Implement the SIs, and it has two implementations listed as follows. 1) Standard interfaces implementation. Using the Factory Pattern program model mentioned in Fig. 5, VirtualSensorNASAMODISFactory.java inherits SPSSensor- Factory.java, and VirtualSensorNASAMODISOperation.java inherits SPSSensorOperation.java. Both those classes can be invoked by class NASAMODIS.java in the package cn.edu.whu.liesmars.swe.sps.sensor. Fig. 9. Task description document. 2) Key operation implementation. Submit is the core operation in different virtual sensors. As Section IV discussed, there are three steps in implementing the Submit operation. The first step is validating the whole tasking request XML document, and finding out whether it fits a XML document standard. And then all the required parameters and their values are

8 1436 IEEE SENSORS JOURNAL, VOL. 11, NO. 6, JUNE 2011 Fig. 10. SubmitRequestResponse XML document. validated to ensure that they are all right and have not been missed. Then the optional parameters are validated. The second step is wrapping the SPS task into an ECHO Web service request. The ECHO client API is generated according to the WSDL and v10/catalogservice.wsdl provided by ECHO using AXIS2. Then the API is used to acquire NASA MODIS metadata with the following substeps. Substep1: Login to the ECHO service. Use the AuthenticationService class, the username and password to login to the ECHO service, and then a token is returned. Substep2: Build the query request. According to the data centre, sensor, time range, and spatial range and so on, build a request query adapting to the gov/echo/dtd/iimsaqlquerylanguage.dtd. Substep3: Query and obtain query results. Call the CatalogService class to query and get the results according to the token and query request from step 1 and step 2. The results are XML documents and they conform to the ECHO metadata model. Sub step4: Logout ECHO service. Log out ECHO service using the Logout class and the token. The third step obtains the results and wraps them to the SOS Insert document and Inserts this document to SOS, so the user can obtain their result from SOS. 4) Experiment Result: Having developed the DSPS middleware in Section V, we sent a task to find data about time and space range (30.0 N, E, 40.0 N, E). Fig. 10 shows the SubmitResponse to the Submit request. ftp://n4ftl01u.ecs.nasa.gov/san/most/mod29.005/ /MOD29.A hdf is the obtained data. Fig. 11 is the SOS GetObservation Response and swe:values shows the result. B. Orbit Planning System as a Virtual Sensor 1) Overview: Simplified General Perturbations Satellite Orbit Model 4 (SGP4) and Simplified Deep Space Perturbations Model 4 (SDP4) are North American Aerospace Defense Command (NORAD) algorithms to calculate satellite location and velocity in earth orbit. SGP4 is for near-earth satellites whose orbital time is less than 225 min, and SDP4 is for deep space satellites whose orbital time is more than 225 minutes [26]. These two models are widely used and can produce very accurate results when used with the current NORAD two-line element (TLE) datum. We use these algorithms to simulate planning satellites data. In this paper, we mainly consider what satellites there are at a certain time and in a certain place. If we can find the satellites, we think we will have successfully simulated planning. 2) Experiment Design: As in Section V, the SOA experiment is designed as follows. Service provider (Web Service) is the SGP4 server, which is deployed in our server ( whu.edu.cn/). It is an implementation of NORAD algorithms for determining satellite location and velocity in earth orbit. The algorithms come from the December, 1980 NORAD document Space Track Report No. 3. We developed it using a C# program. Service broker (DSPS server) is also deployed in our server ( Service requesters are the users on Internet, and they can use Web service technology to invoke these Web services in DSPS server. 3) Flexible DSPS Middleware Implementation: Write configuration file. As in Fig. 7, the name is SGP4_sensor, id is urn:ogc:object:feature:sensor: liesmars:sgp4, sensorxml is sgp4_sensorxml.xml, task is sgp4_task. xml and middleware is cn.edu.whu.liesmars.swe.sps. sensor.sgp4. Implement the SIs, which have two implementations as follows: 1) Standard interfaces implementation. Using the Factory Pattern program model mentioned in Fig. 5, VirtualSensorSGP4Factory.java inherits SPSSensorFactory.java, and VirtualSensorSGP4Operation.java inherits SPSSensorOperation.java. Those two classes can be invoked by class SGP4.java in the package cn.edu.whu.liesmars.swe.sps.sensor. 2) Key operation implementation. The implementation of Submit is also similar to ECHO, but the core is wrapping the request to invoke SGP4 and SDP4 Web service. How many satellites we can plan is determined by the TLE data we use. NASA provides much TLE data and updates it every few days. We should use as recent TLE data as possible. The first step is validating the whole tasking request XML document, and finding out whether it fits to an XML document standard. And then all the required parameters and their values are validated to make sure that they are correct and none have been missed. Then, the optional parameters and their values are validated. The second step is wrapping the SPS task into a SGP4 Web service request. SGP4 client API is generated according to the SGP4 WSDL. The third step is getting the results and wrapping them to SOS Insert document and Inserting this document into SOS, so the user can obtain their results from SOS. 4) Experiment Result: After developing the SGP4 virtual sensor middleware, we carried out an experiment. There are dozens of satellite TLE information. We use the time range ( :00:00, :00:00) and space range

9 CHEN et al.: A FLEXIBLE DATA AND SPS FOR VIRTUAL SENSORS BASED ON WEB SERVICE 1437 Fig. 11. GetObservation XML document. Parser obtains the response and Informer notifies the user by . To simulate midterm time, we set the notification time of WNS at one day and used a Timer to control it. Fig. 13 shows the result sent by WNS-based asynchronous notification middleware. Fig. 12. A query result. (73, 30, 114, 70) to query the satellites that meet the requirements. The results are given in Fig. 12 and there are two satellites. The value of TLEName element is the name of the satellites; GPS NIIA-12 (PRN 25) is one satellite and KIKU-7 (ETS-VII) is the name of the other. When we performed this experiment, the date was , which means that this SPS can plan future satellites. Satellite planning always takes a long time and it cannot respond to the request immediately. It uses WNS-based asynchronous notification middleware to deal with long-term responses. There are four functional components in this middleware: Register, Invoker, Parser, and Informer, as mentioned in Section IV. The user first registers information in Register and is given a unique user ID, which binds into the user . And then the request to the SPS server is sent by Invoker. VI. DISCUSSION This paper proposes a service-oriented data and Sensor Planning Service framework to integrate all the heterogeneous sensors and virtual sensors, and from the discussion in Section II and the two studies in Section V, we can see that as compared with some existing SPS it has some better properties or overcomes some deficiencies, which are listed as follows. 1) It is more flexible. It is a flexible architecture. First, the system adopts a service-oriented architecture, which makes the service independent of the development language, machine and platform. Second, functional modules can be independently deployed with service middleware. Third, the system and functional modules are communicated by standard interfaces. It is flexibly implemented. The SPS can be developed by users with their requirements, and these requirements can all be different. They can configure the configuration file and develop a middleware to develop their own SPS system, and the two case studies in Section V are the best explanation for

10 1438 IEEE SENSORS JOURNAL, VOL. 11, NO. 6, JUNE 2011 Fig notification. ECHO data ordering system and SGP4 are heterogeneous systems. In developed systems, 52North SPS is developed by Java servlet and is not conveniently invoked by other Web service like using SOAP, and so it is with PULSENet for PULSENet utilizes 52North open source; EO-1 SPS is only supporting EO-1 service with SOAP. 2) It enlarges the scope of sensor and its application. It makes data order systems as virtual sensors, extending the sensor scope and more effectively integrating existing resources. Sometimes, we cannot plan sensors at all; for example, if one wants to obtain some image data about an area several days ago, the sensors cannot do it for time can never be turned back. The data order system is very good for obtaining history data; also some data order systems can order future data. So if we see these data order systems as virtual sensors, they can be used in SPS. In ECHO data ordering system example, historical MODIS data can be obtained by SPS using spatiotemporal query. All the SPS showed in Section II seems insensitive to virtual sensors. A virtual sensor is an extensible definition and it extends the sensor scope. Meanwhile, it can service most satellites, not only for one or one series of satellites. This is because users can develop their own SPS middleware. As indicated in Section V SGP4, user can plan satellites in a certain time and a certain place. All satellites meeting the required request can be found. It is beneficial to obtain the same area data with different kinds of satellites. EO-1 SPS discussed in Section II is only for EO-1 satellites. If users want to obtain higher resolution images or other satellite image data, it is powerless. VII. CONCLUSION AND FEATURE WORK To design and implement a flexible Data and Sensor Planning Service for integrating existing sensor Web systems, data order systems, and planning sensors is a great challenge. This paper proposes a service-oriented framework to integrate all the heterogeneous sensors and virtual sensors. The proposed method was successfully tested using many remote sensing satellites and the NASA ECHO data ordering system. The approach overcomes many problems, discussed in Section II, that plague existing Data and Sensor Planning Service implementations. The next step is to study how to use Geo-Processing Workflow (GPW) technology to integrate all the operations of DSPS and how to implement multi-satellite sensors collaborative planning at the service level.

11 CHEN et al.: A FLEXIBLE DATA AND SPS FOR VIRTUAL SENSORS BASED ON WEB SERVICE 1439 ACKNOWLEDGMENT The authors would like to thank Dr. D. A. Tait for proofreading the manuscript. REFERENCES [1] L. Di, Geospatial sensor Web and Self-adaptive Earth Predictive Systems (SEPS), in Proc. ESTO/AIST Sensor Web PI Meeting 2007, 2007, pp. 1 4 [Online]. Available: [2] OGC SWE Project Website [Online]. Available: [3] IEEE 1451 Standard Website [Online]. Available: gov/ [4] NASA EOSDIS Website [Online]. Available: gov/eosdis/overview.html [5] M. Botts and A. Robin, OpenGIS Sensor Model Language (SensorML) implementation specification, in Open Geospatial Consortium (OGC), Wayland, MA, 2007, pp , OGC Document, OGC [6] S. Cox, Observations and measurements Part 1 Observation schema, in Open Geospatial Consortium (OGC), Wayland, MA, 2007, pp. 1 85, OGC Document, OGC r1. [7] S. Cox, Observations and measurements Part 2 Sampling features, in Open Geospatial Consortium (OGC), Wayland, MA, 2007, pp. 1 46, OGC Document, OGC r3. [8] S. Havens, OpenGIS transducer markup language implementation specification, in Open Geospatial Consortium (OGC), Wayland, MA, 2006, pp , OGC Document, OGC r2. [9] I. Simonis and P. Dibner, OpenGIS sensor planning service implementation specification, in Open Geospatial Consortium (OGC), Wayland, MA, 2007, pp , OGC Document, OGC r3. [10] A. Na and M. Priest, OpenGIS sensor observation service implementation specification, in Open Geospatial Consortium (OGC), Wayland, MA, 2006, pp , OGC Document, OGC r6. [11] I. Simonis and J. Echterhoff, OpenGIS sensor alert service implementation specification, in Open Geospatial Consortium (OGC), Wayland, MA, 2006, pp , OGC Document, OGC r5. [12] J. Echterhoff and T. Everding, OpenGIS sensor event service implementation specification, in Open Geospatial Consortium (OGC), Wayland, MA, 2008, pp. 1 88, OGC Document, OGC [13] I. Simonis and A. Wytzisk, Web notification service, in Open Geospatial Consortium (OGC), Wayland, MA, 2003, pp. 1 46, OGC Document, OGC r2. [14] N. Chen, L. Di, G. Yu, and M. Min, A flexible geospatial sensor observation service for diverse sensor data based on Web service, ISPRS J. Photogrammetry Remote Sens., vol. 64, no. 4, pp , [15] M. Botts, G. Percivall, C. Reed, and J. Davidson, OGC (R) sensor Web enablement: Overview and high level architecture, in Proc. 2nd Int. GeoSensor Networks Conf. (GSN ), pp , Springer LNCS. [16] 52 North SPS Website [Online]. Available: bin/view/sensornet/spsplugins [17] EO-1 SPS Website [Online]. Available: [18] NOAA NESDIS Website [Online]. Available: gov/ [19] NASA ECHO Website [Online]. Available: index.html [20] WIKI AutoChem Website [Online]. Available: wiki/autochem [21] N52 North Website [Online]. Available: project-sites/swe/ [22] X. Chu, T. Kobialk, B. Durnota, and R. Buyya, Open sensor Web architecture: Core services, in Proc. 4th Int. Conf. Intelligent Sens. Inf. Process., 2006, pp [23] S. M. Fairgrieve, J. A. Makuch, and S. R. Falke, PULSENet (TM): An implementation of sensor Web standards, in Proc. Int. Symp. Collaborative Technologies Syst., 2009, pp [24] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns. Reading, MA: Addison-Wesley, 1995, pp [25] M. Min, N. Chen, L. Di, G. Yu, and J. Gong, Augmenting the OGC Web processing service with message-based asynchronous notification, in Proc. Geosci. Remote Sens. Symp., 2008, pp. II-1337 II [26] F. R. Hoots and R. L. Roehrich, Models for propagation of NORAD element set, Aerospace Defense Command, U. S. Air Force, Project Spacecraft Rep. No. 3, 1980, pp Zeqiang Chen received the B.Sc. degree in geography from Huazhong Normal University in 2006 and the M.S. degree in geographical information system from Wuhan University in He is currently working towards the Ph.D. degree at the State Key Laboratory for Information Engineering in Surveying, Mapping and Remote Sensing (LIES- MARS), Wuhan University, Hubei, China. He is also a Research Assistant at the Center for Spatial Information Science and Systems (CSISS), George Mason University. His current research interests include semantic Web and sensor Web. Nengcheng Chen received the B.Sc. degree in geodesy from the Wuhan Technical University of Surveying and Mapping in 1997, the M.S. degree in geographical information systems from the Wuhan University in 2000, and the Ph.D. degree in photogrammetry and remote sensing from the Wuhan University in He was a Post-Doctoral Research Associate at the Center for Spatial Information Science and Systems (CSISS), George Mason University, Greenbelt, MD, from 2006 to He is currently a Professor of geographic information science of the State Key Laboratory for Information Engineering in Surveying, Mapping and Remote Sensing (LIESMARS), Wuhan University, Hubei, China. His research interests include Smart Planet, Sensor Web, Semantic Web, Digital Antarctica, Smart City, and Web GIS. Prof. Chen is a member of the International Association of Chinese Professionals in Geographic Information Sciences (CPGIS). He was the Chair of the 2010 CPGIS Young Scholar Summer Workshop. Liping Di (M 01 SM 06) received the B.Sc. degree in remote sensing from Zhejiang University in 1982, the M.S. degree in remote sensing/ computer applications from the Chinese Academy of Science in 1985, and the Ph.D. degree in geography from the University of Nebraska-Lincoln in He was a Research Scientist at the Chinese Academy of Science from 1985 to 1986 and the NOAA National Geophysical Data Center from 1991 to He served as a Principal Scientist from 1994 to 1997, and a Chief Scientist from 1997 to 2000 at Raytheon ITSS. Currently, he is a Professor of geographic information science and the Director of the Center for Spatial Information Science and Systems, George Mason University, Greenbelt, MD. His research interests include remote sensing, geographic information science and standards, spatial data infrastructure, global climate and environment changes, and advanced Earth observation technology. Jianya Gong received the Ph.D. degree in photogrammetry and remote sensing from the Wuhan Technical University of Surveying and Mapping in He is currently Professor and Director in the State Key Lab of Information Engineering in Surveying, Mapping and Remote Sensing (LIESMARS) at Wuhan University. He was the Chair Professor of the Cheung Kong Scholars Program, Visiting Professor in the Department of Surveying and Land Information at the Hong Kong Polytechnic University between March 1998 and September 1998, and Visiting Professor in the Department of Geography at the University of Massachusetts between October 1995 and His research interests include GIS and remote sensing.