Sensor Node Data Distribution on Cloud by Service Oriented Architecture

Sensor Node Data Distribution on Cloud by Service Oriented Architecture

Dr. P.Senthilkumar #1, Bharathiraja N #2 , Muneeswari A #3

SKR Engineering College, Anna University Chennai India Saveetha Engineering College, Anna University Chennai India Saveetha University Chennai

Abstract

Wireless sensor networks (WSNs) are gaining more interest as a new technology to realize the ubiquitous computing and monitoring. Data collected by sensor networks are required to be transmitted promptly by users for analysis and gathering. WSNs are expected to be integrated into the Internet, where sensor nodes join the Internet dynamically and accomplish the assigned tasks. This paper proposes an integration module, a middleware component, integrating the WSNs with the internet using Service Oriented Architecture (SOA), and with the application of cloud computing technology. The cloud will provide a functionality to deploy the service as well as store the data. The cloud computing objective is to make data always available to users and it offers feature extendibility of new application server as well as new data base. The sensor services are exposed to the external world through Service Oriented Architecture (SOA) and the collected data by the sensor are represented in XML form for easy and simple distribution among the clients using cloud computing technology. The Data Centre (DC) is acting as a interface between sensor and the internet.

1. INTRODUCTION

   Wireless Sensor Networks (WSNs) enables novel and attractive solutions for information gathering across the spectrum of endeavour including transportation, business, health-care, industrial automation, and environmental monitoring. [1]WSNs are originally standalone networks, where sensor readings are usually disseminated towards the sinks located in the boundary of the networks [2],[3]. However, numerous WSNs applications lead to the need of interconnecting WSNs to the external networks, e.g., the Internet, to broaden WSNs applications into another domain. The interconnection of Sensor Networks to the

   Internet also relays the control and management tasks of building management system under dynamic changes of the environment.[4] But one main issue in WSN is the delivery of collected information efficiently with minimum delays to processing and/or acting elements [5],[6].

   The proposed system provides the solution of integrating the Wireless Sensor Networks with Internet using Service Oriented Architecture (SOA) paradigm and with Cloud Computing technology. It enables the authorized user can have a single point of interaction to control all the facilities in an integrated manner at any place and everywhere using Internet and Cloud Computing technology.

   The Data Centre (DC) is the distributor and acting as an inter face between sensor and Internet. It is responsible for collecting and storing of sensed data from the sensor networks, provides recovery system and also uploading sensed data to Internet through Cloud Computing technology, So the authorized user can access the sensed data from anywhere in the world through the Internet with cloud Service Provider which provides data reliability, scalability, security and interoperability and it provides option to store sensed data on multiple Cloud servers to maintain data availability.

2. RELATED WORK

   In existing work, two approaches for the integration solution. 1. Gateway-Based Integration 2.Overlay-Based Integration. In Gateway-based Approach, different protocols can be used for WSNs and Internet and therefore a gateway is an essential element to connect a WSN with Internet, Which performs

   several tasks such as protocol conversion and message relay [7].

   Next, in Application Layer Gateway (ALG) approach receives message from the internet and translate to the Sensor Network. This approach was designed only for specific application. In this approach all process takes place by Gateway so it is Single Bottleneck at Application Layer Gateway. No direct accessibility [7].In Delay Tolerant Network Gateway approach adopts store and-forward mechanism and bundle layer on top of region specific network protocols to support interoperability of heterogeneous regions. The disadvantages of this approach is Need to change protocol stack and no direct accessibility.[7].

   Overlay-based Approach: The first overlay- based approach is to implement an IP overlay network over WSN. IP over WSN namely, Sensor nodes are equipped with IP protocol stack for addressing and data routing. Cluster Head only having the IP address [7].IP overlay network over WSNs: Sensor nodes are equipped with IP protocol stacks for addressing and data routing and constitute an overlay network among them. Tunnels between cluster head.[7]WSN over the Internet: This approach extends the data centric routing protocol in WSNs into the internet via overlay networking in the application layer When the packets originated from WSNs arrive at the gateway, they are encapsulated within typical TCP/IP packets and then deliver to a specific destination IP host.[7]

   DATA CENTRE (DC) MODULE

   The Data Centre (DC) is integrating the Internet and WSNs through three phases registration, control, and monitor. The registration phase is carried out with the help of the wireless sensor networks registration protocol (WSNRP), due to space limitation. After the registration phase, the Data Centre enters the control phase. It reconfigures the quality of service parameters on the network edge router to adapt to the new registered information. Next, it monitors the

   traffic on the integration link to determine if there are any abrupt changes to the traffic pattern. If there are link failures or congestions, the system will enter the control phase to adapt to these changes. [5]

3. PROPOSED SYSTEM

   The sensed data is very important to take an action and need to recover from problem and also avoid the problem before will occur. But the data can be sensed and sent it to end user for on time action so that sensed data do not saved in anywhere in our existing system.

   The stored data is used to gain the knowledge from sensed data for doing a correct way of operation. Even if failure may occur we need to recover that problem, so alternatively take an action and provide data availability to the users without any interruptions, so those issues are not done in existing system.

   But in proposed system those issues are taken and implement a recovery system and data storing facility over Data centre. In proposed system the wireless sensor network is integrate with internet through cloud computing technology. Already we discussed about how cloud computing is better than other internet integrate technology.

   A. System Architecture

   The proposed system architecture Figure.1 shows the integration of Wireless Sensor Network and Data Centre using Service Oriented Architecture (SOA) paradigm and the integration of Internet and Data Centre using Cloud Computing technology.

   1. Integration of Sensor Network and Data Centre using SOA Paradigm

      The Sensor Node and Integration of Data Centre will form SOA architecture. Here the actual Service Provider is Sink node and Service Consumer is Data Centre. The Sensor Node data will store it on Application web server. Now the Sink node will provide the service to read the Sensed Data. The Data Centre will bind the

      service information from registry and invoke the actual Web Service by URL.

      The Gateway node is a sensor node it is called as a sink node when a node connected with more than one Sensor Nodes. Du to constraints on Sensor node it will not communicate to the Centre Unit directly, So it send the data via only the Sink node and the sink node will keep all those sensed data on Web Server. The Service Consumer searches a service on sink registry to invoke a service. The sink registry maintaining information about services and it tells how to invoke those services such as parameter details and return type.

   2. Integration of Internet and Data Centre with Cloud

      The Data Centre is responsible for Collecting Sensed data from Sink node and stores it on Data Centre as XML form. The XML form of data will provide high security and natural form of data and support multiple platforms.

      The Data Centre is responsible for deploy the sensed data to the user end server. The Service Consumer is responsible for collecting the data from server and stored those data on multiple server depends on STAX specification. The storing speed of data on server is depends on internet bandwidth. Once if you stored on server you can get instantly on different clients.

   3. Cloud Computing Service Provider

   The STAX is a provider for cloud computing service. It is free to create account on STAX. The STAX will allocate some initial amount of space to your ID. Store an application and data on STAX server by using Data Centre.

4. ANALYSIS

   In this proposal Gas Pipeline System (GPS) utilizes Wireless Sensor Networks. However, especially in distributed Gas Pipeline System processes we expect a growing need for information from multiple sources of specialized Wireless Sensor Networks (WSNs). In the following we explore how sensor networks can contribute to a Gas Pipeline System and what technical problems still have to be solved to enable an effective use of WSN technology in this application area.

   1. Application Analysis

      Transmission Pipelines for gas and oil are an important part of national energy- transportation infrastructure vital to the national economy. Because these Pipeline Systems are operated at high pressure, pipeline failure can cause severe damage to human health and property and interruption of gas or oil supplies.

      Pipeline inspection technologies using sensor networks have drawn significant attention, for example, in the applications of natural gas pipeline inspection and monitoring by acoustic sensors [8], [9]. In this paper, we discuss how sensor networks can detect, localize, and quantify bursts, leaks and other anomalies in general pipeline systems. In general, pipeline defects can occur in the

      manufacture, construction, and operation processes. In this paper, we focus on the operational defects that encompass internal corrosion, external corrosion, erosion, fatigue, third party damage, denting and buckling. The leading cause of pipeline incidents is damage by digging near existing pipelines. Corrosion sometimes results from excavation damage, which, while not severe enough to trigger a puncture or failure of the pipeline, could create weaknesses in the pipeline. Such a weakness later renders the pipeline more susceptible to corrosion. To ensure the continued safe operation of the transmission pipelines, continuous monitoring or periodic assessment of the integrity of the pipelines is necessary. In pipeline monitoring and inspection, the ultimate objective is to identify the locations that have defects, and obtain an accurate measurement and assessment of the defects so that human operators can take appropriate actions to prevent further damage. The key objective is to develop a Service Oriented Architecture (SOA) to investigate the feasibility of developing a continuous, remote, and real-time monitoring and inspection system using sensors on web that can provide early detection and early warning of defects, such as corrosion and leaks, for pipeline systems.[10]

      A pipeline monitoring and inspection system has a long list of tasks to accomplish. For example, [8], for natural gas pipelines, these tasks include: Measuring wall thickness, detecting gas contamination in pipeline, measuring velocity and flow of gas, detecting presence of gas leaks, determining the variation in pipe cross-section and determining structural defects in pipes, etc.

      To achieve these goals, we rely on various sensors and each type of sensors has its unique feature and operational condition. Sharing sensor networks yields several advantages for Gas Pipeline System. Sensor networks allow a continuous and direct monitoring of enterprise network process. Sensor networks may automate processes by seamlessly share detailed process information at the point where it is really needed. Next, monitoring and automatic

      processing of current data from sensor data across large sites allows manual inspections to be reduced to a minimum in Gas Pipeline System. Manual action is then only required in cases of unrecoverable exceptions. Each part of the process resides in a different location and utilizes different types of sensor nodes. A deployed sensor network of sensors around the items monitors, that certain ranges are met.

      The Data Centre (DC) is responsible for collecting and storing of sensed data from the sensor networks, provides recovery system and also uploading sensed data to Internet through Cloud Computing technology, So that the authorized user can access the sensed data from anywhere in the world through the Internet. Now we can implement the cloud computing technology by subscribing a required amount of data space from the Cloud Service Providers. For example, STAX is a Cloud Service Provider which provides data reliability, scalability, security and interoperability and it provides option to store sensed data on multiple servers to maintain data availability.

   2. Technical Analysis

   SOA The Service Oriented Architecture (SOA) provide s an approach to describe, discover, and invoke services from heterogeneous platforms using XML and SOAP standards. The term service not only represents a software system but also refers to hardware and any devices that can be used by human beings.

   The SOA will communicate WSN for reading sensed data and communicate for transferring sensor responses. The SOA will handle the request as well as response in the form of XML.

   Manageability

   It supports a single point of control, from which system definitions can be maintained, adapted and then distributed across the WSNs from anywhere through the Internet and Cloud

   Scalability and Performance

   The STAX provide separate servers space for our application so any number of users can

   communicate the servers to get the sensed data. [11]

   In future the sensor will add on our system and also new user can get those details. The new sensor data will easily capture by the application server. The application server is responsible for giving those data to user end. In our system we are maintaining the proxy system for critical situation to handle server failure. So we can improve data availability.

   Authentication

   When designing systems that communicate data across multiple users, and thus security domains, controlling the information flow is an obvious problem. Therefore, we finally see the need for data centric access control, that ensures that only data critical to the distributed process is forwarded. The registered user can give the request and can receive the response. Therefore we propose a authentication control mechanism that can directly work on the data. Requests for data forwarding are checked against a local policy

   Context Aware

   The end user can get the details of sensed data anywhere and at anytime. The user may not present at the same place in the plant. The users may roam on inside the plant or on around the world. The authorised users can get the information through Mobile, PDA, laptops and other internet enabled devices. This can be achieved by the system is deployed on an external web server.

   Heterogeneity

   Accomplishing onnectivity to a wide range of WSNs reveals their true heterogeneity. The client now has to interface a number of different platforms hosting different sensor types and using different data encodings. A client would have to support all different encodings in such a heterogeneous environment. However, even if we can understand the message encoding, we will still fail to extract sensible information from the data. If transport container and environment have both humidity sensor embedded, it is not possible to make a statement

   about neither absolute nor relative humidity, because both sensors will most likely have different sensitivity, different resolutions or only a different mounting. Because it not feasible to transfer information about how to interface the data with the sensor network message, only domain knowledge helps us to process it. This is why we propose to externalize the message decoders and to make interface descriptions explicit by introducing a service view on sensor network functionality. Services are self-descriptive, i.e. they provide information by publishing a service description. The concrete technology used to implement functionality is hidden behind that interface. Service interfaces provide the client with typed and attributed data. Because service oriented architectures have a standardized, uniform interface to all services, only one message decoder is needed to process the message. Using standardized service interfaces also allows seamless integration with other application frameworks.

   Data Availability

   Data can be redundantly store in multiple physical locations. Physical location should be distributed across world. So It can be available everywhere.[11]

   Security

   Data should be stored and processed only in specific jurisdictions as define by user. Service Provider should also make a contractual commitment to obey local privacy requirements on behalf of their customers, Data-centred policies that are generated when a user provides personal or sensitive information that travels with that information throughout its lifetime to ensure that the information is used only in accordance with the policy [11]. Data store in database of provider should be redundantly store in multiple physical locations. Data that is generated during running of program on instances is all customer data and therefore provider should not perform backups and Control of Administrator on Databases.[11]

5. IMPLEMENTATION

   This section outlines the architecture that enables us to couple the services provided by remote sensor networks over the Internet.The sensor network is built as model, using random numbers generated as sensed parameters. In a sensor network, this provides a number of advantages, including shielding the user from faulty sensors and reducing the number of expensive sensor readings and radio transmissions that the network must perform. This general architecture acts as the proper platform for answering queries and interpreting data from real world environments like industrial sensor nets, as conventional database technology is poorly equipped to deal with lossiness, noise and non-uniformity inherent in such environments.

   A. SOA between Sensor and Data Centre

   1. Designing Sensor Module

      Actual Sensor Data is simulated by TinyOS. TinyOS is an operating system specifically designed for sensor networks. It has a component-based programming model, provided by the NesC language, a language of

      module SenseM { provides {

      interface StdControl; } uses {

      interface Timer; interface ADC;

      interface StdControl as ADCControl; interface Leds; }}

      implementation {

      C. TinyOS application [8] is not an OS in the traditional sense. It is a programming framework for embedded systems and set of components that enable building an application specific OS into each application TinyOS Simulator is run on TinyOS1.7. The NesC is a language is used to simulate the Sensor Nodes. The TinyOS itself having the packages to simulate the real time sensors on simulators. The following Figure 2 shows code will explain the designing Sensor Module.

      int i=1; randomize();

      result_t display(uint16_t value)

      {

      if (value &1) call Leds.yellowOn(); else call Leds.yellowOff();

      if (value &2) call Leds.greenOn(); else call Leds.greenOff();

      if (value &4) call Leds.redOn(); else call Leds.redOff();

      return SUCCESS; }

      async event result_t ADC.dataReady(uint16_t data)

      { i=random();

      i=i/1000; if(i>2 && i<=3) { printf("<SensorData>12.22</SensorData>");}

      else if(i>3 && i<=4) {

      printf("<SensorData>13.23</SensorData>\n")

      ; }

      else if(i>4 && i<=5) {

      printf("<SensorData>14.24</SensorData>\n")

      ;

      }

      else if(i>6) {

      printf("<SensorData>16</SensorData>\n");

      }

      display(7-((data>>7) &0x7)); return SUCCESS; }}

      Figure 2 Designing Sensor Modules

   2. SOA Between Sink Node And Data Centre

   Here, we described how the sensed parameters are converted into web service and how they have been deployed. Web services are application components that are designed to support interoperable machine-to-machine interaction over a network. The lists of services are discovered and invoked by the sensor applications (client), using SOAP messages. The client communications are passed through the Data Centre. The Data Centre (DC) also takes care of the authentication of the users and delivering the required parameters using push interaction pattern. This pattern can be triggered by multitude of events, here an auditable event,

   trigger (when the process parameters exceeds some threshold) the message sent to the client Figure 3. J2EE 1.4 SunApp server is used as service provider. The J2EE 1.4 platform provides comprehensive support for web services through the JAX-RPC 1.1 API, which can be used to develop service endpoints based on SOAP.

   1. Deploy Sensed Data into the Client end By STAX

      STAX is Elastic Java application platform for EC2.The fastest way for Java EE developers to build, manage and scale applications in the Cloud. STAX provides easy deployment of test and production environments, a local development model, and strong integration with existing development tools, frameworks, and processes.

      The Data Centre is responsible for read the sensed data from Sink and deploy into the client end by using STAX. The following Figure.4 code will show that deploy the new appended sensed data to client end.

      buildXML(strFileName,strCurrentReading,out); out.println(strCurrentReading);/* Batch File Running*/ String command = "cmd /C start D:/tomcat50-

      jwsdp/webapps/servlets-examples/WEB-INF/classes/cloud.bat "; Runtime rt = Runtime.getRuntime();

      rt.exec(command);} else{ out.println("Error over File making");}

      Figure 3 Deploy the Sensed Data to Client End

   2. Handling Xml form of Data from Sink to the user end

   <?xml version="1.0"?>

   <Units><GasVelocity><SensorID>Time:VS78</SensorID><VelocityTi me>ID:02:41:11</VelocityTime><SensorData> null

   </SensorData></GasVelocity><GasPressure><SensorID> Time:VS79</SensorID><SensorTime> ID:09:28:02</SensorTime><SensorData>1</SensorData>

   </GasPressure><GasPressure><SensorID>PS1P1</SensorID><Senso rTime>ID:09:28:02</SensorTime><SensorData>1</SensorData></P ressure></Units>

   Figure 4 XML forms of Sensed Data

   The Simulator is provide the Sensed data the Bridge program is responsible for read the Sensed data from simulator and converts into XML form of data and stores it on Web Server. The following Fig 6 code shows that sample XML code Sensed data.

6. CONCLUSION AND FUTURE WORK

   The Sensor data is distributed over Internet using Service Oriented Architecture (SOA), and with Cloud Computing technology. The basic properties of cloud like interoperability, reliability, availability and security are also extended to the proposed system. The Wireless Sensor Network data is monitored on client machine. This proposed model provides fast delivery of data to client machine compare to existing gateway approaches. Failure time recovery can takes place instantly.

   Potential future works is deploying this proposed work in Industry in real time and test it.

7. REFERENCE

1. Field Monitoring Using Sensor-Nodes with a Web Server Tokihiro Fukatsu, and Masayuki Hirafuji National Agricultural Research Centre 3-1-1 Kannondai, Tsukuba, Ibaraki 305-8666, Japan

2. S.Hadim and N. Mohamed, Middleware: Middleware Challenges and Approaches for Wireless Sensor Networks,in IEEE Distributed Systems Online, vol.7, no. 3, 2006.

3. Weilian Su and Bassam Almaharmeh, QoS Integration of the Internet and Wireless Sensor Networks WSEAS TRANSACTIONS on COMPUTERS, Issue 4, Volume 7, April 2008.

4. Internetworking Wireless Sensor Networks with the Internet Quan Le-Trung, Frank Eliassen IFI/UiO, Paal E. Engelstad, Telenor R&I, Tor Skeie, Simula E- mail: {quanle, frank}@ifi.uio.no,Paal. ngelstad@telenor.com, tskeie@simula.no

5. C. Decker, M. Beigl, A. Krohn, U. Kubach, P. Robinson,eSeal – A System for Enhanced Electronic Assertion of Authenticity and Integrity of Sealed Items, Proceedings of the Pervasive Computing, Wien, Austria, 2004.

6. Nils Hoeller, Christoph Reinke, Jana Neumann, Sven Groppe, Daniel Boeckmann,Volker Linnemann, Efficient XML Usage within Wireless Sensor Networks,WICON 08, November 17-19, 2008, Maui, Hawaii, USA

7. An Extensible Internetworking Architecture (EIA) for Wireless Sensor Network and Interne APNOMS 2006,Min Zhang,Sangheon Pack,Kideok Cho,Dhkhyum Chang

8. H. W. Park, H. Sohn, K. H. Law and C. R. Farrar, Time reversal active sensing for health monitoring of a composite plate, Journal of Sound and Vibration, vol.302, no. 1-2, 17 April 2007, pp.50-66.

9. A. Agrawal, A theoretical, numerical and experimental investigation of guided wave propagation in hollow cylinders. Master thesis, Carnegie Mellon University, September 2008.

10. Jinglun Shi, Weiping Liu A Service-oriented Model for Wireless Sensor Networks with Internet Proceedings of the 2005 The Fifth International Conference on Computer and Information Technology (CIT05).

11. K. Hwang, S Kulkarni and Y. Hu, Cloud security with virtualized defence and Reputation-based Trust management, Proceedings of 2009 Eighth IEEE International Conference on Dependable,Autonomicand Secure Computing (security in cloud computing),pp.621-628, Chengdu, China,December,2009.ISBN:978-0- 7695-3929-4

International Journal of Engineering Research & Technology (IJERT)

ISSN: 2278-0181

Vol. 1 Issue 10, December- 2012