7/25/2019 06930544

1/8

A Framework for Environmental Monitoring

with Arduino-based Sensors using Restful Web Service

Sungchul Lee1, Juyeon Jo2, Yoohwan Kim3, Haroon Stephen4

1, 2, 3

Department of Computer Science,4

Civil and Environmental EngineeringUniversity of Nevada Las Vegas, Las Vegas, NV 89154

2, 3, 4 Email: { Juyeon.jo, yoohwan.kim, haroon.stephen }@unlv.edu1 Email: lees173@unlv.nevada.edu

Abstract The Nevada Solar Energy-Water-Environment

Nexus project generates a large amount of environmental

monitoring data from variety of sensors. This data is

valuable for all related research areas, such as soil,

atmosphere, biology, and ecology. An important aspect of

this project is promoting data sharing and analysis using a

common platform. To support this effort, we developed a

comprehensive architecture that can efficiently collect the

data from various sensors, store them in a database, and

offer an intuitive user interface for data retrieval. We

employed Arduino-based sensors due to their flexibility and

cost-effectiveness. Restful Web Service is used for

communication with the Arduino-based sensors, and Google

Charts service has been used for data visualization. This

framework for sensor data monitoring with Web Service is

expected to allow the Nevada Nexus project to seamlessly

integrate all types of sensor data and to provide a common

platform for researchers to easily share the data.

Keywords- Web Service, Arduino, Restful, Sensor network

I. INTRODUCTION

A.

Need for environment monitoringDeveloping renewable energy resources is a national

priority [1]. In order to develop and manage therenewable energy resources efficiently, University ofNevada, Las Vegas (UNLV) and other Nevadainstitutions are collaboratively working on the NevadaEnergy-Water-Environment Nexus project. This projectexplores advanced knowledge through the research onsolar energy generation, its environmental impact, andassociated water issues. To process and share thecollected data, it is building a new capability incyberinfrastructure (CI) [2]. To this date, Nexus projecthas generated a large amount of data from investigating

the environmental impacts and water issues of solarenergy production by engineers, hydrologists, biologists,ecologists, soil scientists, atmospheric scientists, andeconomists [2]. Standardized and integrated data on solar,water, and environment are needed to handle the needs oftheir research. The project also requires real-time datacollection and distribution to variety of entities to supporttheir research.

Over the years, environmental monitoring data hasbeen stored and analyzed at the field devices [3], and the

collected data has been moved to database manually [4].

In this paper, we employ Web Service with which thedata can be directly stored at database and analyzedconveniently. The security features, i.e., confidentiality,integrity and availability, are also better supported with

the new data sharing system based on the Web Service.B.Network Infrastructure status

In order to achieve the goals mentioned above, newfacility and network infrastructure is needed. There havebeen preceding projects in Nevada with similar goalsbefore the current Nexus project. The existing facilitiesfrom those projects are now being leveraged. The NEW-STAR facility, standing for Nevada Environment, Water,and Solar Testing and Research, was built in 2008 andbeing used in the current project. Figure 1 shows theproperty and the solar thermal power plant adjacent to it.The NEW-STAR facility is connected to other researchlocations throughout Nevada via a network infrastructure

that is illustrated in Figure 2. One of the neededimprovements for the cyberinfrastructure in the Nexusproject is to increase the connectivity and to expand theexisting network infrastructure. The infrastructureimprovement plans include expanding the scope of theexisting Sensor and Nevada Climate Change Portal(NCCP) system into the new Nevada Research DataCenter (NRDC) along with an extended sensor network,comprising additional communication links, servers, anddatabases [6].

Figure 1. NEW-STAR facility

2014 IEEE International Conference on Services Computing

978-1-4799-5066-9/14 $31.00 2014 IEEE

DOI 10.1109/SCC.2014.44

275

7/25/2019 06930544

2/8

There are a few issues to be addressed in building thenew system. Due to limited software support and datausability, the previous system has not reached its fullutilization. For example, it is challenging to share the datagenerated from the monitoring devices with otherresearchers. From the data management perspective, thereare two reasons for this underutilization. First concern isthe data integrity, i.e., the collected data must not bechanged by any unauthorized person. It hasnt been muchof a problem so far since most researchers conducted theirstudy independently with the original data. However, tomake it sharable, the data integrity issue must be resolvedbecause any unauthorized change may make the entire

database unusable. Second concern is the datastandardization. Researchers are producing their own typeof data in an ad-hoc fashion while processing and storingthe data. Very little attention is given to interoperability.As a result, these data are not easily searchable orunderstandable by other researchers or their tools. In orderto solve these issues, the concept of Sensor Data as aService (SDS) has been applied in the Nexus project. SDShas been proven to be suitable for Data-Centric Service ina previous research [7]. For its implementation, wedecided to make a REST-base Web Service [7].Regarding the data input, we employed Arduino boards [8]

to collect data from the sensors.

The proposed architecture is composed of three mainparts, that is, service, sensor network, and database. Theseparts are covered in the following sections. Section IIdescribes the motivation and the background on REST-based Web Service in the context of NV Nexus project.Section III illustrates the process of current sensor datacollection. The database normalization process isdescribed in Section IV. Section V describes how theenvironmental data is collected on Arduino and how it is

transmitted to the server via Restful communication.Section VI illustrates the interaction mechanisms amongour Web Service, Google Charts service, and Arduinoboards. Then section VII discusses a potential expansionscheme of the architecture. Finally section VIIIsummarizes our research and outlines the future works.

II.

BACKGROUND AND MOTIVATION

In the predecessor projects of the current Nexusproject, the researchers stored significant amount of dataon their database for almost ten years. The accumulateddata is classified into three groups; (1) solar energygeneration, (2) water resources, and (3) environment [9].It can be applicable to other researches in various fields,such as engineering, hydrology, biology, ecology, soil,atmospheric, economy, and so on. By sharing andcombining the data, a high level of synergy can beachieved among researchers in various fields. In spite ofthe benefits from the synergy, there are three major issuesin sharing the data. First, the data gathered from theNexus project exhibits different types and formats,making it impractical for researchers to process the datawhen necessary. Moreover, it has been shown thatregenerating the data not only takes long time but alsoproduces numerous errors. As a result, researchers tend tooverlook the data from other fields or other researchers.

Second, different types of data make the searchingoperation inefficient. Furthermore, different researchersemploy different ways of storing data. There arepractically no search engines currently for researchers toget specific data.

Although it offers some hints to examine the headersection of data, researchers still have a difficulty tounderstand the proper usage of data.

Figure 2. Network Infrastructures [5]

276

7/25/2019 06930544

3/8

Therefore, researchers end up spending a substantialamount of time for manually searching for specific datafrom the massive amount of data.

Last issue is security. Among the 3 aspects of datasecurity, i.e., confidentiality, integrity and availability,data integrity is the greatest concern in our case.Researchers are concerned about data being changedimproperly. They are reluctant to expose the data due to

the possibility of damage to the data,. Also, it is difficultto protect the data in a uniform way as researchers employdifferent data storage methods such as text file, excel file,Oracle database, MySQL database, etc. To resolve theseissues in relation to sharing data, Nexus CI team has beendeveloping a scheme for managing, processing, andprotecting data.

There are four areas where the CI team is concerned.First, the team needs to create new methods and tools forhandling, processing, and analyzing data, which will helpdata mining effort. Second, it needs to develop newsoftware tools that can streamline the communicationamong CI team members, and facilitate scientific andeducational effort. Third, it is necessary to create a securecyberinfrastructure with remote data collection capabilityon a high-speed network. Finally, efficient databasearchitecture and a data management scheme that aresustainable and extensible over long term have to bedeveloped. The answer to the above requirements was anarchitecture consisting of a sensor network infrastructure,web services, and database to integrate real-time data.Each component will be discussed in the followingsections.

III. CURRENT SENSOR SYSTEM

Nexus project and its predecessor projects have been

collecting various environmental data throughout theNevada state. Some of the sensors are located at UNLVcampus for measuring wind and solar data. The collecteddata has been stored at a CR1000 unit that is shown inFigure 4. CR1000 is one of the most widely used datalogger in the industry [10]. It offers a broad range ofmeasurements and control functions. Figure 3 and Table 1

illustrates a sample text output of the original datacollected at a CR1000 unit and the characteristics of dataeach element. It contains the measurements of averagesolar power, total solar power, average insidetemperature, average outside temperature, average windpower, and the wind direction in degree. Researchers haveto convert them to Excel or CVS format in order toprocess them in MATLAB. Also, when a specific dataentry should be analyzed at MATLAB, researchers haveto manually search through the entire dataset to locate thedesired data item. In order to change certain functions ofCR1000, such as collected data type, measurement unit,or time resolution, it is necessary for the researchers to

manually change the codes on the device. Obviously, thismanual process is inconvenient and time-consuming,which lowers the productivity of the researchers.

To mitigate the inconvenience, we created a web-based control interface. The sensor data collectionfunctions can be controlled via web services. Web Servicealso bridges the data with the database and allowsimproved search and analysis operations.

IV. DATABASE CONSTRUCTION

We explain the process of database construction aswell as the normalization process briefly in this section. Inorder to store the raw data into the database,

normalization is necessary, as the data from CR1000 isnot normalized. A normal form of data works as arestriction on the database and prevents certainundesirable properties from the database [11].

In order to normalize the data, the data types and theirrelationship need to be identified first. There are severalentities that will be used in database, such as collector,timestamp, sensor, value, and station. One sensor shouldbe in one collector. The value is defined by one sensor

Table 1. Data field Description

Record Description Unit

Slrkw_Avg Avg solar power km/m2

SlrMJ_Tot Total solar power MJ/m2

T109_K_Avg Avg Inside Temperature Kelvin

T110_K_Avg Avg Outside Temperature Kelvin

Avg_Wind_Speed Avg Wind Power m/s

Avg_Wind_Dir Avg Wind Degree Deg

Figure 4. CR1000 in UNLV

"TOA5","CR1000","CR1000","54582","CR1000.Std.25","CPU:UHI_Sensor_4-3-13.CR1","22967","UHI_Output""TIMESTAMP","RECORD","SlrkW_Avg","SlrMJ_Tot","T109_K_Avg","T110_K_Avg","Avg_Wind_Speed","Avg_Wind_Dir","NR_Wm2_Avg","CNR_Wm2_Avg""TS","RN","kW/m^2","MJ/m^2","Kelvin","","m/s","Deg","W/m^2","W/m^2""","","Avg","Tot","Avg","Avg","WVc","WVc","Avg","Avg""2013-04-05 14:09:00",1,0.863,0.05176543,311,314.6,2.119,286,"NAN","NAN""2013-04-05 14:10:00",2,0.864,0.05181818,311,314.5,2.545,262.6,"NAN","NAN"

"2013-04-05 14:11:00",3,0.866,0.05197314,311,314.3,3.264,333.3,"NAN","NAN"

"2013-04-05 14:12:00",4,0.865,0.05191634,311,314,1.986,333.4,"NAN","NAN""2013-04-05 14:13:00",5,0.861,0.05168364,311,314.1,2.984,307.6,"NAN","NAN""2013-04-05 14:14:00",6,0.859,0.05154042,311,313.9,2.132,352.2,"NAN","NAN"

Figure 3. Sample Data from CR1000

277

7/25/2019 06930544

4/8

with one timestamp. The Using the relationship amongthe entities in CR1000, we derive the mapping in figure 5.

In order to generate normalized data, we must gothrough a four-step process [12]. The four-step process is:

1. 1NF: atomic no list, no set2.

2NF: fully dependent no partially dependent3. 3NF: transitively dependent xy, y!x, ya

4.

BCNF: only key can decision. x

y, x must be key1NF represents a relation scheme, expressed only in

atomic form, where the elements of the domain areconsidered indivisible units. The values in the domainmay not represent a list, set, or any other compositevalues. 2NF is a relation scheme where every non-primeattribute fully depends on every key. 3NF is a relationscheme where no non-prime attribute is transitivity-dependent upon a key. Boyce-Codd Normal Form (BCNF)is a relation scheme where every determinant is acandidate key. Figure 6 displays the relations andstructures among the tables in the database. Sensor tableshows which sensors can be included in a particular

collector type (Collector_ID). Installed Collector tableshows the location of a collector represented byCollector_ID. Station table describes the location, such asaddress, zip code, and so on. Measure table shows thevalue of data at a Timestamp in a Sensor_ID of aCollector_ID. By transforming the data into a normalizedform, SQL join method can be performed without causingerrors. Furthermore, different fields of data can becombined safely. We construct database on MariaDB [13]based on the relations defined in Figure 6.

V. ARDUINO WITH RESTFUL WEB SERVICE

A.

Arduino-based sensor data collection

To overcome the limitations of CR1000, we exploredthe possibilities of data collection using Arduino [14].Arduino is an open-source electronics prototypingplatform that focuses on flexible, convenient hardware

and software. Arduino can create interactive objects andenvironments for beginners, such as,artists, designers,hobbyists, and so on [15].

Table 2 shows the characteristics of CR1000 andArduino. CR1000 has a higher performancemicrocontroller and larger memory than Arduino. Inmany cases, sensors are in outside without protectionfrom theft or damage. Arduino is much cheaper thanCR1000, thus the impact of a theft is much smaller.Arduino-based sensors can be reliably monitored andcontrolled remotely. Arduino can also work as a webserver making it easier to communicate using standardHTTP communication API. As stated in Table 2, Arduino

is capable of handling a comparable amount of data toCR1000 (20 vs. 24 inputs). Arduino boards can beequipped with a variety of sensors and function as adatalogger [16]. They can configure the sensors, such asmeasurement time resolution, and control switches oractuators. Arduino programming language (based onWiring) and the Arduino development environment isused for programming the on-board microcontroller.Arduino programs can run either in stand-alone mode orbe controlled by the software running on a host computer(e.g. Flash, Processing, MaxMSP). Figure 7 shows anArduino Uno 3.0 board with an Ethernet Shield V2.0 anda temperature sensor along with their connections.Arduino checks the voltage from the temperature sensorusing 5V input voltage. Arduino Ethernet Shield V2.0 isconnected to the Internet via RJ45 port [17]. Arduino usesa polling method to measure the voltage from the sensor.The polling interval can be determined by setting a timerin the program. To minimize the workload of the webserver, Arduino translates the voltage to the data onlywhen polled. We used Restful web communication tosend the data from Arduino to the server. An Arduinoprogram is called sketch, which has mainly two parts,

Figure 6. Normalized database relations

TABLE 2. CR1000 Vs. Arduino Specifications

CR1000Arduino uno

3.0

Microcontroller 16 bit H8S Renesas ATmega328

Input voltage -5 V ~ 5V 7~12 V

Analog pin 16 6

Digital I/O pin 8 14

Flash memory 2MB 32K

Data storage

Memory4MB External

Price $1280 $25

Sensor

Value Timestamp CR1000Arduino

TemperatureWind PowerWind Degree

Solar Power

InstalledCollector

Figure 5 functions of data in CR1000

278

7/25/2019 06930544

5/8

initialization and the main operation.

Figure 8 shows a sample Arduino program segment. Itfirst sets up the Ethernet connection and configures thetimer using setTime variable. The next part is the main

operation in a loop form. Within the loop, the timervariable t keeps reading the data using getData( ) everysecond. Figure 9 shows the code segment that transformsthe voltage to temperature, and then sends the temperaturedata to the server. The getVoltage( ) function reads ananalog signal from an analog input pin. The voltage isconverted to temperature in Fahrenheit or Celsius ingetData ( ). The data, which consists of the server IPaddress, sensor ID, and the measured value, is sent to theserver by restConnection ( ).

B. REST in sensor data collection

The restConnection ( )sends data to a destination URLover REST (Representational State Transfer) [18]. REST

is created for networking applications, which consists ofseveral constraints to address separation of concerns,visibility, reliability, scalability, flexibility, andperformance as an architectural style [19]. Until recently,web services based on Simple Object Access Protocol(SOAP) was commonly used as a middleware foraccessing equipment remotely. However, REST waschosen because the required technology to build a WebService is simpler than SOAP [20]. REST performs betterin a sensor network compared to SOAP, and equipmentvendors now recommends REST for applicationsconsuming embedded resources. Figure 10 shows thatWeb Services based on REST is faster than SOAP when

service or operation is requested, such as Register a client(REG), Send a message (SEND), Receive all messages(RCV), or Unregister a client (UREG) [21].

Typically more than one sensor data is collected bythe sensors in every polling interval depending on theresearchers needs. The sensor data is consequently passedto collectors, such as Arudino or CR1000. In order toproperly process the accumulated data, the memory sizeof data logger should be sufficiently large. The message

void setup() {

for(int i=0;i

7/25/2019 06930544

6/8

size also plays an important role. REST-based webservice is again ideally positioned for remotely accessingcollectors. In the next section, we show the architecture ofthe Web Service in the context of sensor network and dataanalysis in Nexus project.

VI.

WEB SERVICE FOR SENSOR NETWORK

Web Service is commonly used for a remote access toequipment. In this section, we show the Web Servicearchitecture to handle sensor data. Generally, WebService is composed of three tiers [22], that is, Client,Middle, and Server. Client tier is created for user interface.Users can request and receive data through the web page.Middle tier works as a mediator. It handles the requests ofthe users. For example, the requested data by the userscome from the Server tier, then gets processed by theMiddle tier, and is sent to the users [22]. In our project,we add Sensor tier and extend it to include remote sensors.

Figure 11 illustrates the architecture of our WebService. The measured data is temporarily stored inCollectorprior to being moved to Middle tier. While it ispossible to move the sensor data directly to the database

in Server tier, we avoid it for security reasons. Remotesensors are generally exposed to risks, such as beingstolen, damaged, or modified. To ensure databaseintegrity, the sensor data is verified and sanitized in theMiddle tier first, and sent to the database in Server tier.While it is possible to store the measured data withinCollector, we avoid that because Collector has limitedprocessing power. Collectors are best in gathering sensordata, and should not be overloaded with other non-essential functions. Although the Collectors (Arduino) canbe directly controlled with different configurationparameters, we delegate such functions to Middle tier .All data is first transported to Middle tier, and the usersrequests for data preparation are processed at the Middletier. The sensors and collectors can be upgradedindependently from the rest of the system.

This architecture improves overall data security overthe previous system, where the data is stored locally andretrieved manually. First of all, the physical access to thestorage hardware is prohibited since the data is exportedin real-time. The data link between the Sensor and the

Figure 10. Round trip times, RTTclient

Figure 12. Flow Web Service with Sensor Network

Figure 11. Web Service Architecture with Sensor

280

7/25/2019 06930544

7/8

middle tier uses SSL/TLS and the communication link isprotected from eavesdropping or packet injection attacks.

The data integrity is enhanced by pre-processing andaccess control at the middle tier. Inaccurate input datafrom the sensor is filtered out in the middle tier before itis entered in the database. Only legitimate users canaccess the system and they can access the database onlywith a read permission, thus any arbitrary datamodification is prohibited. The database is backed upperiodically, which increases the availability.

We built Web Service based on Model-View-Control(MVC) design pattern [22]. View presents the output tousers who requested the information from the Model. Thedata visualization was performed using a free 3rd partyservice, i.e., Google Charts [23]. Figure 12 shows the

interactions among the modules. They work in thefollowing sequence.

1. Web server receives requests from clients throughController that is programmed in Servlet.

2. Controller constantly sends commands to theModel for updating the current status of Model.

3.

Model, programmed in Java Bean, notifies itsupdated status to View and Controller wheneverthe change has been made in its status.

4. The notification allows the View to produce anupdated output as well as the controllers tochange the available set of commands.

5.

View sends the data from Model and associated

formatting parameters to a 3rd party service(Google Charts server).

6. Google Charts server gives an image in ScalableVector Graphics (SVG) format to View.

Figure 13 is an example of Google Charts service inSVG format created with the actual sensor data. SVG isan XML-based vector image format for two-dimensionalgraphics, interactivity, and animation [24]. Users can

choose the period or filter the data locally withoutcontacting any server. Different types of charts, such as

line, pie, tree map, or 3D chart can be created by GoogleCharts. Google data tables have data manipulationfunctions like sorting, modifying, and filtering. Thisflexibility helps the users to understand the nature of data.However, there is a higher delay in submitting andgenerating the SVG file for a bigger data set.

VII. EXTENDED WEB ARCHITECTURE

In this section, we extend the architecture forscalability and flexibility. So far we focused onconstructing the architecture suitable for one specific typeof collector. However, it is essential for the architecture toaccommodate other types of collector and users device.

Hence, the Middle tier needs to be extended to handle thediversity. The middle tier is now divided into two parts,Profile Manager (PM) and Asset Manager (AM). Figure14 shows the resulting extended Web Architecture withSensor network. The PM handles different types of userdevices such as tablet PC, cell phone, etc. The roles ofPM include processing, handling and describing usersrequest. The AM handles various types of collectors, suchas CR1000, Arduino, and so on. The collector iscontrolled by AM with command orders such as time, unit,update, and cancel [25]. AM transforms the raw sensordata into Sensor Model Language (SensorML) [26].SensorML provides the framework to XML forstandardizing data, capabilities, and systems of sensor

[27]. Platforms and sensor networks are primary examplesof the system.

This extended Web Service architecture is expected tocover wide range of user devices and sensor types thatwill be introduced in the future. It is expected to serve as afoundation for improving the current cyberinfrastructurein the Nevada Nexus project.

Figure 14. Extended Web Architecture with Sensor networkFigure 13. Google Chart with Nexus Sensor Data

281

7/25/2019 06930544

8/8

VIII. CONCLUSION AND FUTURE WORKS

This research has designed an architectural model withWeb Service to accommodate data collection and sharingneeds in Nevada Nexus project. The performance ofsensor devices have been reviewed and we learned theperformance of Arduino is comparable to a traditional

data logging device such as CR1000, thereby offering amore cost-effective solution. The Web architecture isdesigned based on MVC pattern. We used Restful WebService to handle the sensor data sent by Arduino-basedsensors and employed Google Charts service forvisualizing data. With the web service architecturedeveloped in this research, the data created from theenvironmental monitoring systems can be effectivelyshared among all researchers.

In the future, we plan to develop AM and PM in theMiddle tier to interface with a large range of clientdevices and sensor devices. Furthermore, we need toinvestigate the security and confidentiality issues as

REST-based Web Service may have some securityconcerns [28] inherent to basic URL-based service.

ACKNOWLEDGEMENT

This material is based upon work supported by theNational Science Foundation under grant number IIA-1301726.

DISCLAIMER

Any opinions, findings, and conclusions orrecommendations expressed in this material are those ofthe author(s) and do not necessarily reflect the views ofthe National Science Foundation.

REFERENCES

[1] U.S. Office of Management and Budget. 2012. Budget of the U.S.Government, FY 2013.

[2] Nevada Solar Nexus Proposal 2013 [Online]. Available:http://nvsolarnexus.org/

[3] Zheng Tao, Qin Yajuan , Zhang Hongke Environmentalmonitoring and air-conditioning automatic control with intelligent

building wireless sensor network, Control Automation Robotics& Vision (ICARCV), 2010 11th International Conference on, 7-10Dec. 2010, pp. 2431 - 2436

[4] Nikos Giannopoulos, Christos Goumopoulos, Achilles KameasDesign guidelines for building a wireless sensor network forenvironmental monitoring, 2009 13th Panhellenic Conference onInformatics, 10-12 Sept. 2009, pp. 148 152

[5] Frederick C Harries, Jr. Cyberinfrastrucure in Nevada: CurrentStatus and Future Developments, Feb 2, 2010

[6] The Solar Energy-Water- Environment Nexus in Nevada [Online].Available: http://nvsolarnexus.org/cyberinfrastructure/

[7] Jia Zhang, Bob Iannucci, Mark Hennessy, Kaushik Gopal, SeanXiao, Sumeet Kumar, et al., Sensor Data as a Service -AFederated Platform for Mobile Data-Centric Service Developmentand Sharing, 2013 IEEE 10thInternational Conference on ServicesComputing, June 28 2013, pp. 446-453

[8] Hiro Gabriel Cerqueira Ferreira, Edna Dias Canedo, RafaelTimteo de Sousa Junior IoT Architecture to EnableIntercommunication Through REST API and UPnP Using IP,

ZigBee and Arduino , 1st International Workshop on Internet ofThings Communications and Technologies (IoT'13), 7-9 Oct. 2013,

pp. 53 60[9] The Solar Energy-Water- Environment Nexus in Nevada [Online].

Available: http://nvsolarnexus.org/[10] Campbell Scientific [Online]. Available:

http://www.campbellsci.com/cr1000-overview[11] Abraham S, Henry F. Korth, S. Sudarshan, Database System

Concepts 6rd ed., McGrawHill, pp. 18-20,323-359[12] Amir Hassan Bahmani, Mahmoud Naghibzadeh, Behnam BahmaniAutomatic Database Normalization and Primary KeyGeneration, Electrical and Computer Engineering, 2008. CCECE2008. Canadian Conference on 4-7 May 2008, pp. 11-16

[13] Dead database walking: MySQL's creator on why the futurebelongs to MariaDB [Online]. Available:http://www.computerworld.com.au/article/457551/dead_database_walking_mysql_creator_why_future_belongs_mariadb/

[14] CR1000 Measurement and Control System Manual [Online].Available:http://s.campbellsci.com/documents/us/manuals/cr1000.pdf

[15] Arduino [Online]. Available: http://arduino.cc/[16] Vikatos, P., Theodoridis, E., Mylonas, G., Tsakalidis, A,

PatrasSense: Participatory Monitoring of EnvironmentalConditions in Urban Areas Using Sensor Networks andSmartphones, Informatics (PCI), 2011 15th Panhellenic

Conference on, Sept. 30 2011-Oct. 2 2011, pp. 392 39[17] Arduino Ethernet Shield [Online]. Available:

http://arduino.cc/en/Main/ArduinoEthernetShield[18] R. T. Fielding Architectural Styles and the Design of

Networkbased Software Architectures, California,Irvine:University of California, 2000

[19] Hongjun Li RESTful Web service frameworks in Java, SignalProcessing, Communications and Computing (ICSPCC), 2011IEEE International Conference on 14-16 Sept. 2011,pp.1-4

[20] Franco Davoli, Norbert Meyer, Roberto Pugliese, SandroZappatore Remote Instrumentation Services on the e-Infrastructure, Springer ISBN 978-1-4419-5573-9

[21] Aihkisalo, T. Latencies of Service Invocation and Processing ofthe REST and SOAP Web Service Interfaces, Services(SERVICES), 2012 IEEE Eighth World Congress on, 24-29 June2012, pp. 100-107

[22] Xuelei Wu, Coll,Jia Chen, Bilan Rong Web Service Architecture

and Application Research, E-Business and Information SystemSecurity, 2009. EBISS '09. International Conference on, 23-24May 2009, pp. 1-5

[23] Ying Zhu ,Introducing Google Chart Tools and Google Maps APIin Data Visualization Courses, Computer Graphics andApplications, IEEE,Nov. 2012, pp 6-9

[24] Quint, A. Scalable Vector Graphics, MultiMedia,IEEE (Volume:10 , Issue: 3 ), July-Sept. 2003, pp. 99-102

[25] Zeqiang Chen, Nengcheng Chen, Liping Di, Jianya Gong, AFlexible Data and Sensor Planning Service for Virtual SensorsBased on Web Service, Sensors Journal, IEEE , June 2011, pp.1429 - 1439

[26] M. Botts and A. Robin, "OpenGIS Sensor Model Language(SensorML) Implementation Specification," Open GeospatialConsortium Inc., OGC 07-000, 2007.

[27] Luis Bermudez, Tony Cook, David Forrest, Philip Bogden,Charlton Galvarino, et al., Web feature service (WFS) and sensorobservation service (SOS) comparison to publish time series data,Collaborative Technologies and Systems, 2009, CTS '09.International Symposium on, 18-22 May 2009, pp. 36- 43

[28] Gabriel Serme, Anderson Santana de Oliveira, Julien Massiera,and Yves Roudier Enabling Message Security for RESTfulServices , 2012 IEEE 19th International Conference on WebServices, 24-29 June 2012, pp. 114-121

282