(An Autonomous College Affiliated To University of Mumbai) : Page No

K. J.
Somaiya College of Engineering, Mumbai-77

(An Autonomous College Affiliated to University of Mumbai)
Batch:2016-17 Roll No.: 1601002
Experiment / assignment / tutorial No._03
Grade: AA / AB / BB / BC / CC / CD /DD
Signature of the Staff In-charge with date
Experiment No.:3
Title: IoT Applications in Agriculture
Objectives: The objective of this experiment is to utilize open source software and adapts
the standards of the Open Geo-spatial Consortium to introduce a method for the realization of
a sensor data infrastructure for precision Agriculture applications.
______________________________________________________________________
Expected Outcome of Experiment:
CO. 1) Understanding the Sensor Web Enablement (SWE) architecture and need for SWE in
agriculture,
2) How to connect sensor with interoperable SWE platform , and
3) Minimum System requirement for SOS installation.
_____________________________________________________________________
Books/ Papers/Websites referred:
1. Jakob Geipel ,Markus Jackenkroll,Martin Weis and Wilhelm Claupein;Eds. A Sensor Web-
Enabled Infrastructure for Precision Farming;ISPRS Int. J. Geo-Inf. 2015.
2. Oerke,E.C.;Gerhards,R.;Menz,G.;Sikora,R.A.;Eds. Precision Crop Protection—The Challenge

and Use of Heterogeneity, 1st ed.; Springer Verlag: Dordrecht, The Neatherlands, 2010.
3. Petr KUBÍČEK, Vojtěch LUKAS, Karel CHARVÁT ;Eds.Cartographic visualization of agricultural

sensor ; Czech Science Foundation.
_____________________________________________________________________
Pre Lab/ Prior Concepts:
1) knowledge of different types of sensors used in agriculture IoT applications.

Related Theory:
Department of Computer Engineering
Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

K. J. Somaiya College of Engineering, Mumbai-77
Rapid advances in Internet of Things 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 IoT 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.
The use of sensor technologies is standard practice in the domain of precision farming.
The variety of vendor-specific sensor systems, control units and processing software has led to
increasing efforts in establishing interoperable sensor networks and standardized sensor data
infrastructures. This study utilizes open source software And adapts the standards of the Open
Geospatial Consortium to introduce a method for the realization of a sensor data
infrastructure for precision farming applications. The infrastructure covers the control of
sensor systems, the access to sensor data, the transmission of sensor data to web services and
the standardized storage of sensor data in a sensor web-enabled server. It permits end users
and computer systems to access the sensor data in a well-defined way and to build
applications on top of the sensor web services.
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.
Related Theory (contd..):

1)Need for Sensor Web Enablement (SWE) in agriculture

A sensor network is a computer accessible network of many, spatially distributed devices using
sensors to monitor conditions at different locations, such as temperature, sound, vibration,
pressure, motion or pollutants. A Sensor Web refers to web accessible sensor networks and
archived sensor data that can be discovered and accessed using standard protocols and
application program interfaces (APIs).
In an Open Geospatial Consortium, Inc. (OGC) initiative called Sensor Web Enablement (SWE),
members of the OGC are building a framework of open standards for exploiting
Webconnected sensors and sensor systems of all types . SWE presents many opportunities for
adding a real-time sensor dimension to the Internet and the Web. The initial focus of OGC’s
SWE has been to investigate standardized interfaces for live sensors operating in near-real-
time, rather than the conventional static data stores. It addresses information gathering from
distributed, heterogeneous, dynamic information sensors and sources of different structure,
based on web services. It is the goal to develop common access, planning, and management
interfaces and a descriptive markup language (SensorML) for managing sensor information
and metadata in common consistent manners, independent of any application. The individual
parts were initially designed to fulfill the following needs
- Describe sensors in a standardized way
- Standardize the access to observed data
- Standardize the process of what is commonly known as sensor planning, but in fact is
consisting of the different stages planning, scheduling, tasking, collection, and processing
- Building a framework and encoding for measurements and observations
Falling producer prices and rising costs of production are increasingly forcing agricultural
businesses to optimize production costs. Therefore, the request for the selective use of inputs
such as water, fertilizers or chemicals, is now indispensable in modern agriculture. The growing
environmental awareness of consumers further accelerates this process. Improved agricultural
risk management using the actual knowledge of agricultural indicators becomes more and

more important. Every day or hour information made decision more exactly. Plant disease
initiation and development is a function of the interaction of several observable factors like
soil temperature, air temperature, relative humidity, and other soil and atmospheric variables.
The farmer can for instance define wet temperature low limits (calculated as a function of
temperature and relative humidity). Then, when the temperature drops below the predefined
thresholds, the software sends an alarm via email or SMS. The farmer can activate frost
protection equipment and reduce crop loss to a minimum. The same attitude is applicable in
monitoring of growth and development of plants, insects, and many other invertebrate
organisms’ endangerment.
Needs of SWE in agriculture:

 facilitate coherent and ubiquitous access to sensor data for improving utility through
interoperable systems (Botts and Robin, 2007)
 understand the lineage of the sensor data (Botts et al., 2006)
 easily avail the exact geo-location and recording phenomenon of respective sensor,
thereby reducing the ambiguity about sensor sampling point (Botts et al., 2006)
 increase the utility of sensory data through easy dissemination mechanism
 Monitor agro-meteorological parameters and estimate crop water requirement 
 Issue alerts based on crop pest/disease predictions 
 Disseminate sensory/advisory information to stakeholders information to stakeholders
Facilitate the human participatory sensing through closely coupled SWE services 
 Activate devices for crop water / nutrient application

2)SWE Architectures and alternatives

The models, encodings, and services of the SWE architecture enable implementation of
interoperable and scalable service-oriented networks of heterogeneous sensor systems and
client applications. In much the same way that Hyper Text Markup Language (HTML) and
Hypertext Transfer Protocol (HTTP) standards enabled the exchange of any type of
information on the Web, the OGC’s SWE initiative is focused on developing standards to
enable the discovery, exchange, and processing of sensor observations, as well as the tasking
of sensor systems. The functionality that OCG has targeted within a sensor web includes:
 Discovery of sensor systems, observations, and observation processes that meet an

application’s or user’s immediate needs;
 Determination of a sensor’s capabilities and quality of measurements;
 Access to sensor parameters that automatically allow software to process and geo-
locate observations;
 Retrieval of real-time or time-series observations and coverages in standard encodings
 Tasking of sensors to acquire observations of interest;
 Subscription to and publishing of alerts to be issued by sensors or sensor services
based upon certain criteria.
Within the SWE initiative, the enablement of such sensor webs and networks is being pursued
through the establishment of several encodings for describing sensors and sensor
observations, and through several standard interface definitions for web services. Sensor Web
Enablement standards that have been built and prototyped by members of the OGC include
the following OGC standards:
1. Observations & Measurements Schema (O&M) – An OGC adopted standard that defines
conceptual models for encoding observations and measurements from a sensor, both
archived and real-time.
2. Observations and Measurements XML (OMXML) – XML encoding of the O&M conceptual
model.
3. Sensor Model Language (SensorML) – An OGC adopted standard that defines standard
models and XML Schema for describing sensors systems and processes; provides information
needed for discovery of sensors, location of sensor observations, processing of low-level
sensor observations, and listing of taskable properties.
4. Sensor Observations Service (SOS)- An OGC adopted standard that specifies a standard
web service interface for requesting, filtering, and retrieving observations and sensor system
information. This is the intermediary between a client and an observation repository or near
real-time sensor channel.

5. Sensor Planning Service (SPS) – An OGC adopted standard that specifies standard web
service interface for requesting user-driven acquisitions and observations. This is the
intermediary between a client and a sensor collection management environment.
6. SWE Common Data Model -The Sensor Web Enablement (SWE) Common Data Model
Encoding Standard defines low level data models for exchanging sensor related data between
nodes of the OGC® Sensor Web Enablement (SWE) framework. These models allow
applications and/or servers to structure, encode and transmit sensor datasets in a self-
describing and semantically enabled way.
7. SWE Services Common – This standard currently defines eight packages with data types for
common use across OGC Sensor Web Enablement (SWE) services. Five of these packages
define operation request and response types. These packages use data types specified in
other standards.
8. PUCK Protocol Standard- This standard defines a protocol for RS232 and Ethernet
connected instruments. PUCK addresses installation and configuration challenges for sensors
by defining a standard instrument protocol to store and automatically retrieve metadata and
other information from the instrument device itself. PUCK is the newest addition to the SWE
standards suite.
9. Sensor Alert Service (SAS) – An OGC Discussion paper describing a web service interface for
publishing and subscribing to alerts from sensors. This is not an OGC standard.
10. Web Notification Services (WNS) – Standard web service interface for asynchronous
delivery of messages or alerts from SAS and SPS web services and other elements of service
workflows. This is not an OGC standard.

The goal of SWE is to enable all types of Web and/or Internet-accessible sensors, instruments,
and imaging devices to be accessible and, where applicable, controllable via the Web. The
vision is to provide a standards foundation for “plug-and-play” Web-based sensor networks.
Sensor location is usually a critical parameter for sensors on the Web, and OGC is the world’s
leading geospatial industry standards organization. Therefore, SWE standards have been
harmonized with other OGC standards for geospatial processing.


SensorML
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. (Botts and
Robin, 2007).
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

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 . Similar approach has been used to form physical layout of FS system.


3)Connecting sensor with interoperable SWE platform
The IoT application of agriculture 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.
This section gives background information about the principles and the implementation of an
actual agricultural sensor infrastructure

It is based on three main layers for:

(i) sensor control and communication (sensor layer);
(ii) Sensor Web Enablement (SWE) services as part of a sensor web (sensor web layer); and
(iii)end users and computers(application layer),
Which build applications on top of the SWE services.
A fourth layer is an intermediary integration layer, facilitating the connection of sensors and
services (sensor integration layer).
The extended sensor infrastructure stack is based on three main layers and one integration
layer, covering all levels from sensor measurements to end-user applications. The sensor layer
is the lowest level layer, managing the communication within sensor networks. It consists of
the different sensor devices and one or several data acquisition systems (DAS), to control and
access all sensor systems on-the-fly. The sensor integration layer is an intermediary layer
between sensors and SWE services.

Its idea is to establish an infrastructure that connects sensor web services, requesting specific
sensor data, with sensors, delivering exactly the requested data, on-the-fly. The sensor web
layer consists of one or a multitude of SWE services. Each service is defined for special
purposes, e.g., the sensor event service (SES), which offers a web interface to publish and
subscribe to notifications from sensors, or the sensor observation service (SOS), which offers
the discovery and retrieval of real-time or archived data, produced by any kind of sensor
system. The application layer is the highest level layer, where users or computer systems
interact with the SWE services.
1) Sensor Layer:
The sensor layer represents the lowest level layer of the proposed infrastructure. It was set-up
by four different sensor systems and a DAS, to control and access the sensor systems.
Communication was enabled by a 2.4-GHz wireless local area network (WLAN) and a 3G
mobile Internet connection.
1.1)Sensor system:
The sensor layer involved:
(i) a stationary HYT221 weather sensor (HYT221, IST AG, Wattwil, Switzerland) for measuring
temperature and relative humidity;
(ii) a stationary MMS1 NIR enhanced spectrometer (HandySpec Field, tec5 AG, Oberursel,
Germany) for the registration of incident solar radiation;
(iii) a tractor, equipped with a Multiplex fluorescence sensor (Multiplex, FORCE-A, Orsay,
France) for the detection of within-field plant health; and
(iv) Hexe, a prototype UAS, equipped with a PiCam RGB camera (Raspberry Pi Camera,
Raspberry Pi Foundation, Caldecote, Cambridgeshire, UK), a self-assembled multi-spectral
camera (D3, VRmagic Holding AG, Mannheim, Germany) and an MMS1 NIR enhanced
spectrometer, for the detection of plants spectral parameters. The HandySpec sensor system
was operated by a consumer notebook, which also served as the processing unit for the DAS.
All other sensor systems were operated by individual Raspberry Pi Model B computers

(Raspberry Pi Foundation, Caldecote, Cambridgeshire, UK), which were equipped with wireless
adapters to enable communication with the DAS
1.2)Data Acquisition System

Every connection of a sensor system with the DAS was realized by implementing an individual
input-plugin and a plugin description document. As all sensor control units and the DAS share
the same network, the input-plugins were configured:
(i) to establish a network connection to the appropriate sensor control unit;
(ii) to send configuration parameters; and
(iii) to request sensor observations
The plugin description document describes the plugin’s interpolation behavior, the sensor’s
observations and its metedata. The metadata were encoded in SensorML, a sensor description
language, which is specified by SWE and used to describe sensors and processes .
On the output plugins’ side, three output mechanisms were of interest: a visual control of the
Geo-referenced sensor observations, a mechanism to forward the sensor observations into the
sensor web and a simple data logger in case the DAS is disconnected from the sensor web. All
of these mechanisms have already been established in three different output plugins, which
can be downloaded from the 52◦N website.
Visualization was done by the “SensorVis—Real Time Sensor Visualization”
(https://wiki.52north.org/bin/view/SensorWeb/SensorVis) plugin, which allows live
visualization of sensor data based on a 3D virtual globe environment.

As the forwarding mechanism, the“Sensor Bus Output Plugin”, also distributed within the
standard SPF packages, was used. It implements a sensor adapter for a logical bus for the
standardized connection of sensor data and SWE services.
Overview of the input and output plugin architecture of the Sensor Platform Framework (SPF),
which serves as the data acquisition system (DAS). Four input plugins were implemented to
control and access all sensor systems individually. The Raspberry Pis and the notebook serve
as control units, implementing vendor-specific sensor protocols. DAS and control units
communicate with each other either through wireless (dashed lines) or wired connections
(solid lines). Three output plugins were implemented for:
(i) the live-visualization of sensor observations during measurement;
(ii) for the local logging of received sensor data; and

(iii) for the forwarding of the sensor data into the sensor bus. Visualization and logging were
performed on the notebook, running the DAS. Forwarding data into the sensor bus was
realized via a mobile Internet connection.
Sensor Integration Layer

Here we chose the sensor bus to serve as the sensor integration layer in between sensor
systems and remotely-connected sensor web services. Although it is designed to enable a
sensor plug and play infrastructure for a sensor web by incorporating semantic matchmaking
functionality, a publish/subscribe mechanism and a generic driver mechanism, the available
sensor bus output plugin is limited to messaging, based on the sensor bus protocol .
Therefore, matchmaking, publish/subscribe and driver issues were handled manually.
A driver mechanism to control and access the connected sensors was implemented for every
SPF input plugin, individually. The sensor bus plugin was configured to publish all sensor data,
gathered by the SPF, into an Extensible Messaging and Presence Protocol (XMPP) chat channel.
The chat message format follows the sensor bus protocol specifications and offers a simple
solution to distribute sensor data to a remote SWE service.
A sensor bus service adapter was implemented to forward the observations from the sensor
bus to an SOS. It was realized as a python program. It subscribed and listened to the XMPP
chat channel, which contained the published sensor data. The service adapter was designed to
parse the sensor data from the sensor bus protocol format to an SOS request Extensible
Markup Language(XML) format. Related sensor observations were assembled and grouped
following the predefined sensorML profiles. Subsequently, an Insert Observation request was
composed to add the observations to the SOS. The Insert Observation request is part of the
transactional operations SOS profile. This optional transactional profile allows clients to
register new sensors (InsertSensor) and add observations. Observations in the request are

encoded in accordance with the Observations and Measurement (O&M) schema, a standard
to describe all observations of a sensor system

Overview of the sensor bus architecture, which is designed to facilitate the communication of
sensor systems and SWE services. Any kind of sensor adapter can register to the bus and
publish its sensor data according to the sensor bus message protocol. For subscription and
receiving of sensor data, any kind of SWE services can register a service adapter, listening to
the sensor bus. The architecture is scalable to scenarios where a multitude of sensor systems
and SWE services participate.
3) Sensor Web Layer:

The sensor web layer consists of an SOS. It is the most common SWE service and it was used in
this study in its 52◦ N SOS 4.1 implementation, exclusively. It offers a web interface for
publishing operations, e.g., GetCapabilities, GetObservation and DescribeSensor, on the one
hand, and for transactional operations, e.g., InsertSensor and InsertObservation, on the other
hand. It builds on the technical frameworks of an Apache Tomcat 7 (http://tomcat.apache.org/
tomcat-7.0-doc)

servlet container, a PostgreSQL 9.3 (http://www.postgresql.org/docs/9.3) Database

Management System (DBMS) and a PostGIS 2.1 (http://postgis.net/2013/08/17/postgis-2-1-0)
support for geographic objects. Based on the SensorML descriptions of every input plugin,
each sensor system was registered once using the InsertSensor operation. After having
registered the individual sensors, the sensor bus service adapter was able to perform
InsertObservation operations on-the-fly, using the Service-Oriented Architecture Protocol
(SOAP).
4)Minimum System requirement for SOS installation

 Hardware 
-RAM min 512MB 
-HD installation space min 1GB 
-Processor: ARM, Intel 32 bit, AMD 64 bit, …
 Software
-Operating System: Windows xp/ 7 / 8 /10 , recent release of Linux (Ubuntu, Debianvariants,
etc.) 
- Admin permissions to Windows OS user
 Network 
-Wi-Fi / Ethernet connection to internet (required in case of additional software installations /
Linux based installation)
Conclusion:

This case study on IoT applications in Agriculture proved the applicability of the OGC SWE
initiative framework definitions for the set-up of a sensor data infrastructure for applications.
It is based on open source software, offering the possibility to deploy numerous sensor
systems and SWE services. The DAS provides a consistent method for the control, access and
forwarding of sensor observations. The sensor bus concept is scalable to more complex
scenarios involving a multitude of sensor systems, DAS and SWE services.
Here the web clients act as interfaces in between stored sensor data and a user,realizing the
application layer of the infrastructure stack. It can be applied to machinery and sensor systems
on the farm scale or be extended with data services offered by external parties.
Implementation of Sensor Web Enablement standards facilitates the interoperability and

sensor data discovery, and it is possible to improve the research in IoT application fields (e.g.
Agriculture, Environment, etc.) through this architecture.
Date _________ Signature of faculty in-charge

(An Autonomous College Affiliated To University of Mumbai) : Page No

Uploaded by

Copyright:

Available Formats

You might also like

(An Autonomous College Affiliated To University of Mumbai) : Page No

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

(An Autonomous College Affiliated To University of Mumbai) : Page No

Uploaded by

Copyright:

Available Formats

K. J.

Somaiya College of Engineering, Mumbai-77

Batch:2016-17 Roll No.: 1601002

Experiment / assignment / tutorial No._03

Signature of the Staff In-charge with date

Title: IoT Applications in Agriculture

2. Oerke,E.C.;Gerhards,R.;Menz,G.;Sikora,R.A.;Eds. Precision Crop Protection—The Challenge

3. Petr KUBÍČEK, Vojtěch LUKAS, Karel CHARVÁT ;Eds.Cartographic visualization of agricultural

1) knowledge of different types of sensors used in agriculture IoT applications.

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

Related Theory (contd..):

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

1)Need for Sensor Web Enablement (SWE) in agriculture

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

Needs of SWE in agriculture:

Related Theory (contd..):

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

2)SWE Architectures and alternatives

 Discovery of sensor systems, observations, and observation processes that meet an

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

Related Theory (contd..):

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

Related Theory (contd..):

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

Sensor System Description: it describes the sensor's purpose / field of application,

Sensor Process Model: Provides serializations of executable components in a sensor system

Related Theory (contd..):

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

Related Theory (contd..):

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

Related Theory (contd..):

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

3)Connecting sensor with interoperable SWE platform

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

It is based on three main layers for:

Related Theory (contd..):

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

Related Theory (contd..):

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

1.2)Data Acquisition System

Related Theory (contd..):

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016

Department of Computer Engineering

Page No M.Tech.Comp N.S. Lab Sem I /July.- Nov 2016