SERVICE ORIENTED ARCHITECTURE FOR WIRELESS SENSOR NETWORKS IN AGRICULTURE

Rapid advances in Wireless Sensor Network (WSN) for agricultural applications has provided a platform for better decision making for crop planning and management, particularly in precision agriculture aspects. Due to the ever-increasing spread of WSNs there is a need for standards, i.e. a set of specifications and encodings to bring multiple sensor networks on common platform. Distributed sensor systems when brought together can facilitate better decision making in agricultural domain. The Open Geospatial Consortium (OGC) through Sensor Web Enablement (SWE) provides guidelines for semantic and syntactic standardization of sensor networks. In this work two distributed sensing systems (Agrisens and FieldServer) were selected to implement OGC SWE standards through a Service Oriented Architecture (SOA) approach. Online interoperable data processing was developed through SWE components such as Sensor Model Language (SensorML) and Sensor Observation Service (SOS). An integrated web client was developed to visualize the sensor observations and measurements that enables the retrieval of crop water resources availability and requirements in a systematic manner for both the sensing devices. Further, the client has also the ability to operate in an interoperable manner with any other OGC standardized WSN systems. The study of WSN systems has shown that there is need to augment the operations / processing capabilities of SOS in order to understand about collected sensor data and implement the modelling services. Also, the very low cost availability of WSN systems in future, it is possible to implement the OGC standardized SWE framework for agricultural applications with open source software tools.


INTRODUCTION
The implementation of Wireless Sensor Network (WSN) coupled with communication networks has become easier to measure the agro-meteorological and crop parameters in precision agriculture (Díaz et al., 2011;Zhang et al., 2011).Various field level studies across the world has shown that with precise monitoring and analysis of crop / weather parameters, it is possible to judiciously allocate available resources in agriculture (Nash et al., 2009;Lee et al., 2010;Prabhakar et al., 2010;Li et al., 2011).Sensor Asia initiative has implemented WSN applications for crop, landslide and glacier in Asia (Honda et al., 2008).In India, many government, private and research institutes are implementing WSN for natural resources and agriculture monitoring applications, e.g.GramyaVikas: A distributed collaboration model for rural development planning (Adinarayana et al., 2009), COMMON-Sense Net: improved water management for resource-poor farmers via sensor network (Panchard et al., 2006;COMMON-Sense Net, 2011), etc. Sensor based services of Bhuvan for Land, Weather, Ocean and Disaster management (NRSC, 2011), environmental sensor based services of Ubiquitous Agriculture (uAgri C-DAC, 2011), mobile based agricultural advisory system mKRISHI (mKRISHI, 2011), etc. are few examples of the application of sensor technology for monitoring natural phenomenon.
All these services produce data in their specific format (Honda et al., 2009;Riquelme et al., 2009;Sudharsan et al., 2012;Tripathy et al., 2011).It is difficult for users from diverse fields of study to understand the exact lineage of collected data that gives rise to heterogeneous data formats and increases the difficulties in interoperability and data discovery.Hence, there is a need for standard set of specifications and encodings to bring multiple sensor networks on common platform to resolve the heterogeneity and data discovery issues (Durbha et al., 2010).
The Open Geospatial Consortium (OGC) has brought standards for sensor networks through Sensor Web Enablement specifications (SWE) (Botts et al., 2006;Walter and Nash, 2009).SWE aims at standardization through four standard interface definitions for web services such as Sensor Observation Service (SOS), Sensor Planning Service (SPS), Sensor Alert Service (SAS), Web Notification Service (WNS) and three encodings for describing sensors and sensor observations such as Sensor Model Language (SensorML), Transducer Model Language (TML) and Observation and Measurement (O&M) (OGC Standards, 2012).
The main objective of this study is to propose and implement some of the components of SWE such as Sensor SensorML, and SOS, etc. for standardization of agriculture based GeoSense system (Sudharsan et al., 2012;Tripathy et al., 2011), where two types of distributed sensing devices were International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XXXIX-B4, 2012 XXII ISPRS Congress, 25 August -01 September 2012, Melbourne, Australia used.The integrated client that has been developed can facilitate seamless integration and online visualization of sensor observations and measurements for agriculture applications.

GEOSENSE
GeoSense is an Indo-Japan initiative on integrating Geo-ICT and WSN for Precision Agriculture.Two sensor systems (AgriSens and FieldServer) were implemented.Dynamic real to near-real time data was collected, processed, analysed, and mined to provide location based services and agricultural advisory.

AgriSens (AS)
AS consists of Stargate (base station) communicating to various sensor hubs called Motes, which were placed in different positions and distributed across the field (SPANN Lab, 2011).Stargate plays an important role in receiving the data from the motes network and transmitting the data to remote server through mobile cellular GPRS / 3G network.Each mote has an array of sensors placed at various locations on the mote (Figure 1).

FieldServer (FS)
FS is evolved out of many dynamic experiments on agriculture/environmental aspects in 90's and currently, 3rd generation FieldServers are available.It is a WiFi (long range communication) based self-organizing distributed sensing device (Figure 3) with 24 bit and 24 channels.The embedded board in FS can accommodate the sensors to sense weather, agricultural and environmental parameters such as airtemperature, humidity, relative humidity, CO2, etc. FS transfers sensory data directly to the gateway, a central server in the field, it is then transmitted further over remote server on to the web (FieldServer, 2011).

SENSOR WEB ENABLEMENT IN GEOSENSE
Presently, although the GeoSense is based on Open Source Consortium (OSC) standards, each sensing system has its own data format thus contributing to the diversity of the data sources.This brings out semantic and syntactic heterogeneity in the sensory database.To facilitate interoperability and data discovery there is a need for implementing OGC SWE standards.

SensorML for GeoSense
SensorML is a eXtensible Markup Language (XML) representation used to represent the different aspects of sensor system.It describes details on different aspects like sensor system description, process model, process chain, connections, system physical layout, etc. (Figure 4) (Botts and Robin, 2007).

3.1.1
Sensor System Description: it describes the sensor's purpose / field of application, manufacturer and user details are provided in the basic system description.This information can help the sensor data user to understand the exact purpose of the application of the system.

Sensor Process Model:
Provides serializations of executable components in a sensor system which includes inputs, outputs, and parameters.The schematic view of sensor process model (Figure 2) provides information about how collected data is received and transmitted by different nodes in the system.

Sensor Process Chain:
Defines a serialized execution methodology of sensor (Botts and Robin, 2007).It also explains details of individual sensor and its input, output, accuracy, etc.

Sensor Connections:
These are part of the process chain and defines the connections between inputs, outputs, and parameters.The connection property uses a link object to reference the source and destination of a connector (Botts and Robin, 2007).

Sensor System Physical Layout:
It is the process chain that includes positional information (spatial and temporal) of all sensor components in the real world.For example, the Stargate (base station) in AS system is taken as a reference and relative position of each mote are located, similarly individual mote is considered as reference and position information of each sensor is calculated (Figure 4).Similar approach has been used to form physical layout of FS system.

SERVICE ORIENTED ARCHITECTURE
The Layered architecture of the service consists of Distributed Application Clients, Sensor Observation Service and WSN GeoSense, respectively (Figure 5).The database architecture for SOS is based on an open source implementation of SOS (Walkowski et al., 2011).

SOS Wrapper
The data from two different WSN systems has been collected together in SOS database by using SOS wrapper and subsequently it is accessed by the geographically distributed application clients through standard XML-HTTP requests.The SOS wrapper helps to convert raw data from different formats (text format in AS and XML format in FS) to real data in the SOS database.It processes the raw sensory data and converts it into real values at fixed intervals by using the calibration equations specified in the SensorML, which is stored in required relations of SOS database by executing Structured Query Language (SQL) insert statements.The SOS wrapper facilitates transactional data insertion, which helps in the real time observations of the data.
Figure 5. Service Oriented Architecture for GeoSense

Distributed Application Client
An AJAX (Garrett, 2005) based web application client has been designed with open source tools (GWT, 2011), which facilitate the visualization of sensor data on the web by executing standard XML-HTTP requests (e.g.GetCapabilities, GetFeatureofInterest, etc.) on SOS database (Figure 6).The geographically distributed client also has the ability to locate the sensor on the web mapping service (e.g.Google Web Map Service is used after signing the terms and conditions on the Google website), plot sensor data for given time interval in the table and/or chart formats.

Modelling Service
The SOS has the ability to access, storage and retrieval of real/ near-real time sensory data.It has been found that due to high temporal resolution of sensory data observation per minute), there are few difficulties in processing and retrieval data on client side.In addition to all basic operations only original GetObservation (Arthur and Priest 2007;OGC Standards, 2011) request was modified and statistical analysis was obtained as a response.
Through Remote Procedure Call (RPC) mechanism requests were processed and generated response was asynchronously transferred to the service client (GWT, 2011).The response for specified phenomenon would consist of observation values grouped by user specified time interval along with statistical analysis (minimum, maximum, mean, standard deviation, etc).Figure 7, shows request and response mechanism of the modified GetObservation operation.This would help to understand the exact degree of change occurred in agrometeorological parameters with detection of sensor defects and malfunction if any.The SensorML process chains has been implemented in order to obtain values for composite phenomenon (e.g.Reference Evapotranspiration (ET), Irrigation requirement, etc.).SensorML for computation of Reference ET by Hargreaves method (Allen et al., 1989) is shown in Figure 8.
Through integration of various data processing equations (e.g.Penman-Monteith, FAO-56, crop water balance, etc) SOS can be improved and made available as a location based service to formulate strategies for agricultural resource utilization and management.Implementation of Sensor Web Enablement standards facilitates the interoperability and sensor data discovery, and it is possible to improve the research in WSN application fields (e.g.Agriculture, Environment, etc.) through this architecture.
The GeoSense architecture has been improved through the application of SWE framework to work in ubiquitously in an interoperable manner and with web-based geo-visualization capability.

FUTURE SCOPE
It is possible to improve the capabilities of SOA through implementation of additional process chains and enable application based requests (e.g.crop disease risk prediction, etc.).There is need for implementation of efficient and robust algorithms to process the high resolution spatio-temporal distributed sensory data (15 minute interval for AS and 01 minute for FS) and use in various applications (e.g.quantifying deep percolation of irrigation water, correlating agrometeorological parameters with crop diseases, etc.).Through multi-modal communication (by implementing Sensor Event Service) enabling participatory decision making and advisory.

Figure 1 .
Figure 1.Mote of AgriSens (GeoSense, 2011) Different sensors used in AgriSens are Temperature, Humidity, and Leaf Wetness.The details of sensors are specified inTable 1 (Neelamegam et al., 2007).SN Name Make 1 Temperature Sensor LM61 BIZ 2 Humidity Sensor SY-HS-220 3 Leaf Wetness Sensor Vantage Pro2 6420 Table 1.Sensor Details A Mote wirelessly communicate in Zigbee mode (receiving and transmitting) among themselves and transfers the collected sensor data to the base station (Stargate).The basic interactions between various sensors of the mote are shown in Figure 2.

Figure 6 .
Figure 6.Sensor Observation Service Client

Figure 7 .
Figure 7. Request and response mechanism of modified GetObservation operation

Figure 8 .
Figure 8. SensorML Process and Method for Reference Evapotranspiration calculation 5. CONCLUSIONS Two different architectures of WSN having common application in agriculture are combined through the SWE framework.Through SensorML it provides performance characteristics (e.g.accuracy, threshold, lineage, etc.) and explicit description of the process by which an observation is obtained.This also ensures capacity to connect many sensor networks over internet and provide sensor observation information in support of data discovery.The implementation of the standards based SOA indicates that the sensor data can be efficiently accessed and utilized by researchers and various other user communities (students, government organizations, etc.) from web-based platform.Further, it is cost effective to transform the pre-existing WSN system into OGC Standards by using open source tools.
Geoinformation Services to Rural Extension Community for RuralInternational Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XXXIX-B4, 2012 XXII ISPRS Congress, 25 August -01 September 2012, Melbourne, Australia