1.

INTRODUCTION

1.1. PROJECT OVERVIEW

Farming in India is done using the mundane ways. The fact that most of our farmers lack
proper knowledge makes it even more erratic. A large portion of farming and agricultural
activities are based on the predictions, which at times fail. Farmers have to bear huge losses
and at times they end up committing suicide. Since we know the benefits of proper soil
moisture and its quality, air quality and irrigation, in the growth of crops, such parameters
cannot be ignored.

We therefore, have come up with a new idea of crop monitoring and smart farming using
IoT. We believe that our concept will be useful to farmers due to its reliability and remote
monitoring. Our idea tries to digitalize farming and agricultural activities so that the farmers
can check on the requirements of the crops and accurately predict their growth. The
implementation of our project largely depends upon the awareness among farmers, which, we
believe will be easily created due to its numerous advantages.

Features of “Krishi-Mitra”:

 Detection of soil moisture and automatically controlling irritation system

according to need.
 Automatically controlling environmental parameters as Temperature and
Humidity.
 Collection of Valuable information as Air Quality ( Methane , Butane and
Smoke )
 SMS notification for critical events.

1.2. PROJECT DELIVERABLES

DELIVERABLES STATUS
Background Research Done

1
Project Proposal Done
Product Definition Done
Alternative Analysis Done
Prototype Design Done
List of HW/SW components Done
Cost/Implementation Analysis Done
Benefits Analysis Done
Report Done
Presentation Done
Application Done
Table 1.2 (a): - Project Deliverables

2. PROJECT ORGANIZATION
2.1. SOFTWARE PROCESS MODEL
The software model used in our project is Incremental model.The incremental model applies
the waterfall model incrementally. The series of releases is referred to as “increments”, with
each increment providing more functionality to the customers. After the first increment, a
core product is delivered, which can already be used by the customer. Based on customer
feedback, a plan is developed for the next increments, and modifications are made
accordingly. This process continues, with increments being delivered until the complete
product is delivered. The incremental philosophy is also used in the agile process model.

Figure 2.1 (a): - Incremental Model

2
 2.2. ROLES AND RESPONSIBILITIES.

2.2.1. USER ROLES

a) Shows the status of every sensor on cloud/webpage.
b) Remotely know the status of pump or exhaust system.

2.3. TOOLS AND TECHNIQUES

The software tools used in our project are as follows:
a) Raspberry pi 3
b) VNC Viewer
c) Relay switches
d) Temperature and humidity sensor(DHT22)
e) Soil and moisture sensor(FC28)
f) Ultrasonic sensor
g) MQ2

3. PROJECT MANAGEMENT PLAN

3.1. TASKS

a) Study and working of various sensor and Raspberry Pi3.

b) Documentation and modelling
c) Proper connections
d) Approval to documentation.
e) Creating a user interface
f) Coding for sensors on Raspberry
g) Testing the project
h) Storing data on cloud

3.2. INFORMATION GATHERING

The major information that was gathered for "Krishi-Mitra" :

3
a) Datasheet of sensors
b) Working of electric appliances such as pump and exhaust system at farm
c) Analysis on different issues and problems at farming
d) Analysis of benefits of maintaining appropriate temperature and moisture at farm
e) Working and use of cloud for data analysis and storage

3.3. RESOURCES NEEDED

HARDWARE
a) Raspberry Pi3
b) Relay switches
c) Temperature and humidity sensor(DHT22)
d) Soil and moisture sensor(FC28)
e) Ultrasonic sensor
f) MQ2
g) Wires
h) Power source

SOFTWARE
a) VNC Viewer
b) Advance IP Scanner
c) ThingSpeak Cloud
d) Web Browser
e) Python IDE 2.7

3.4. DEPENDENCIES AND CONSTRAINTS

DEPENDENCIES:
a) The application must need internet while displaying readings of sensor. It must be done in
online mode.
b) All users must have a Web Browser to see sensor data on cloud.
CONSTRAINTS:
This device is for everyone. It is considered that the users have the basic knowledge of
Internet and Web Browser.

3.5. RISKS AND CONTINGENCIES

4
a) Slow Internet
b) Exposure to water
c) Devices are delicate.

4. INTRODUCTION

4.1PRODUCT OVERVIEW

The project congregated of many smart farming devices and is a stand-alone device
which comprehends smart farming, crop monitoring, etc. Our project envisions an
automated system for farming that will create new dimensions in smart farming. It
understands the necessities of a farmer. Our project “Krishi-Mitra” is a wireless
automation system that is meant to be implemented in the existing farming environment
without any changes in present infrastructure. It is a system that is integrated with
automatic irrigation system, controlling of cooling and exhaust system, check on the
moisture, temperature and humidity of the poly-house. It consists of components like
Raspberry PI3 along with relay, DHT22, FC28, etc.

5. SPECIFIC REQUIREMENTS

5.1 EXTERNAL INTERFACE REQUIREMENTS

5.1.1 USER INTERFACES
The user interface is provided to user by the website where user can easily check the current
status of the temperature and humidity of the poly-house and analyse the data visually. The
user gets notification if the pump or exhaust system if turned on or off.
5.1.2 SOFTWARE INTERFACES
a) VNC Viewer:

VNC is a graphical desktop sharing system that allows you to remotely control the desktop
interface of one computer (running VNC Server) from another computer or mobile device
(running VNC Viewer). VNC Viewer transmits the keyboard and either mouse or touch
events to VNC Server, and receives updates to the screen in return.

5
5.1.3 COMMUNICATION PROTOCOLS
The Communication between different parts of the system is important since they depend on
eachother. However, the way in which communication achieved may not be important for the
functioning of system and is therefore handled by the underlined architecture for server and
mobile application.

5.2 SOFTWARE NON-FUNCTIONAL REQUIREMENTS

Constraints on the service or functions offered by the system such as timing constraints,
constraints on development process, standards etc.

5.2.1 RELIABILITY
High Reliability is the measure of how a product behaves in varying circumstances and our
project is reliable because there are few chances of errors and exceptions and works well in
varying circumstances. The probability that device will perform required function without
failure would depend on traffic on server as well as the good internet speed.

5.2.2 AVAILABILITY
The application is available to everyone. The users are able to use the appliance with their
smartphones and PC from anywhere in the world at anytime. The services are available to the
user as long as there is a good internet access in smartphone and PC.

5.2.3 SECURITY
Security is the ability of the software to remain protected from unauthorized access. This
includes both change access and view access. This application is well secured using multiple
levels of security constraints. It would be taken care that only an authenticated person can
access this location, by checking validated fields in the database.

5.2.4 MAINTAINABILITY
Maintainability of system is done by admin. Admin can add or delete the access of the other
member to control the devices.

6
5.2.5 PORTABILITY
This project works on a cloud, mobile phones are highly portable and can be easily accessed
from anywhere by users. Popularity of internet is another important aspect as most of users
are aware of using internet which makes it easy to use and increases scope of this system.

5.2.6 PERFORMANCE
Performance requirement is concerned with the speed of operations of functions and their
accuracy. For optimum performance of application some non-functional requirements are
recommended:
a) Good Internet Connectivity
b) Electric Supply
c) All the switches should be turn on always.

6. INTRODUCTION
A software design description (a.k.a. software design document or SDD) is a written
description of a software product, that a software designer writes in order to give a software
development team overall guidance to the architecture of the software project. An SDD
usually accompanies an architecture diagram with pointers to detailed feature specifications
of smaller pieces of the design. Practically, the description is required to coordinate a large
team under a single vision, needs to be a stable reference, and outline all parts of the software
and how will they work.

6.1 DESIGN OVERVIEW

6.1.1 DATA FLOW DIAGRAM

7
Fig 6.1.1 Data Flow Diagram

8
6.1.2 USE CASE DIAGRAM

Figure 6.1.2 : - Use Case Diagram

9
6.1.3 CLASS DIAGRAM

Figure 6.1.3 : - Class Diagram

10
6.1.4 ACTIVITY DIAGRAM
6.1.4.(a) Temperature and Humidity Sensor

Figure 6.1.4.(a) :- Activity Diagram (Temperature and Humidity)

11
6.1.4.(b) Activity Diagram (Smart Irrigation)

Figure 6.1.4 (b):- Activity Diagram (Smart Irrigation System)

12
6.1.4(c) Activity Diagram (Smart Intrusion Detection)

Figure 6.1.4(d) Activity Diagram (Smart Intrusion Detection)

13
6.1.5 SEQUENCE DIAGRAM

6.1.5(a) Sequence Diagram (Smart Cooling and Exhaust System)

Figure 7.1.1 : - Sequence Diagram (Smart Cooling and Exhaust System)

14
6.1.5(b) - Sequence Diagram (Smart Irrigation System)

Figure 6.1.5(b) : - Sequence Diagram (Smart Irrigation System)

15
6.2 DETAILED DESCRIPTION OF COMPONENTS

This system consists of 4 different module or components, each for: -

a) Smart Irrigation System : - This module is useful as it sense the moisture content of the
soil and according to it automatically controls the irrigation system according to need, it
has to major merits it saves water and timely waters the crop which is beneficial to
farmers.
b) Smart Intrusion Detection: - This module will detect any human or animal who came
near to the farm or poly-house and will alert the farmer, through which we will know that
there is someone at the farm.
c) Temperature and Humidity: - This module will allow the user to control the cooling
and exhaust fans of the poly-house using the sensor and microcontrollers and also the data
will be uploaded to cloud.
d) MQ2 Gas Module: - This module gives the benefit to the user that user can analyse
various gas contents of the poly-house as it will upload the data to cloud.

7. USER INTERFACE DESIGN

7.1 DESCRIPTION OF USER INTERFACE
1) Temperature and Humidity value display Activity:
Through the web browser user can access his ThingSpeak account where he can view the
Temperature and Humidity value inside the poly-house.

2) Gas value display Activity

Through the web browser user can access his ThingSpeak account where he can view the
percentage of various gases present inside the poly-house.

16
7.2 SCREEN IMAGES

17
18
8. INTRODUCTION

Testing documentation involves the documentation of artefacts that should be developed

before or during the testing of Software. Documentation for software testing helps in
estimating the testing effort required, test coverage, requirement tracking/tracing, etc. This
section describes some of the commonly used documented artefacts related to software
testing. Testing allows you to ensure your application works the way you think it does,
especially as your codebase changes over time. If you have good tests, you can refactor and
rewrite code with confidence. Tests are also the most concrete form of documentation of
expected behaviour, since other developers can figure out how to use your code by reading
the tests.

8.1 SYSTEM OVERVIEW

Android is the latest and a rapid growing technology available for all the users or customers
in today’s market. An enormous increase in the end user acceptance has been experienced in
the past few years. This paper proposes an Android mobile phone application that gives
information about the various sensors data stored on cloud. Reason for Android platform -
Android requires an open source development which is probably the most feasible and a
present user friendly approach. The main goal of the proposed work is to improve the
Farming and Agriculture System of India by adding the necessary additional features into the
application.

8.2 TEST APPROACH

Various software-testing strategies have been proposed so far. All provide a template for
testing. Things that are common and important in these strategies are: Testing begins at the
module level and works “outward”: tests which are carried out are done at the module level
where major functionality is tested and then it works towards the integration of entire system.
Different testing techniques are appropriate at different point of time: Under different
circumstances, different testing methodologies are to be used which will be the decisive
factor for software robustness and scalability. The developer of the software conducts testing

19
and if the project is big then there is a testing team: All programmers should test and verify
that their results are according to the specification given to them while coding. In cases where
programs are big enough or collective effort is involved for coding, responsibilities for testing
lies with the team as a whole.
A test approach is the test strategy implementation of a project, defines how testing would be
carried out. Test approach has two techniques:
Proactive - An approach in which the test design process is initiated as early as possible in
order to find and fix the defects before the build is created.
Reactive - An approach in which the testing is not started until after design and coding are
completed.
There are many strategies that a project can adopt depending on the context and some of them
are:
a) Dynamic and heuristic approaches
b) Consultative approaches
c) Model-based approach that uses statistical information about failure rates.
d) Approaches based on risk-based testing where the entire development takes place based on
the risk
e) Methodical approach, which is based on failures.
f) Standard-compliant approach specified by industry-specific standards.

8.3 TESTING OBJECTIVES

Testing should systematically uncover different classes of errors in a minimum amount of

time and with a minimum amount of effort. A secondary benefit of testing is that it
demonstrates that the software appears to be working as stated in the specifications. The data
collected through testing can also provide an indication of the software's reliability and
quality. But, testing cannot show the absence of defect -- it can only show that software
defects are present.

Objectives of testing are: -

a) Finding defects which may get created by the programmer while developing the software.
b) Gaining confidence in and providing information about the level of quality.
c) To prevent defects.

20
d) To make sure that the end result meets the business and user requirements.
e) To ensure that it satisfies the BRS that is Business Requirement Specification and SRS
that is System Requirement Specifications.
f) To gain the confidence of the customers by providing them a quality product.

9 .TEST PLAN
A Software Test Plan is a document describing the testing scope and activities. It is the basis
for formally testing any software/product in a project. It identifies amongst others test items,
the features to be tested, the testing tasks, who will do each task, degree of tester
independence, the test environment, the test design techniques and entry and exit criteria to
be used, and the rationale for their choice and any risks requiring contingency planning.

9.1 FEATURES TO BE TESTED

Features are changes that add new functionality or significantly modify existing functionality.
They are designed to be useful, effective, and attracting. Though, users are inventive and use
the functionality unexpected ways. Also the application is complex and all pieces have to
cooperate with each other. Any change might have surprising side effects in the related parts.
Finally, developers are just humans and they might simply forget to implement a piece.

Feature testing should catch the above mentioned problems and make sure that users will be
happy with the new stuff.

21
 10. TEST CASES
Test Case
Test Case Description Test Result
Number
Temperature and Detects
T-001 Humidity sensor temperature and Successful
(Dht11) humidity
Gas Sensor For detecting
T-002 Successful
(MQ2) various gases
Soil and
For checking
T-003 Moisture sensor Successful
moisture in soil.
(FC28)
For measuring
T-004 Ultrasonic sensor Successful
distance

T-005 Raspberry PI3 Microcontroller Successful

Table 10 (a) Test Cases

10.1 UNIT TESTING

Unit testing is the testing of an individual unit or group of related units. It falls under
the class of white box testing. It is often done by the programmer to test that the unit he/she
has implemented is producing expected output against given input.

a) Connections: - To check if all connections are correct and not loose.

b) Network Failures: - To check network failures if any while data transmission between
sensor and micro-controller.
c) Sensor Values: - To check if sensor sends correct and accurate value.
d) Output Values: - To Check if actuators work according to sensor data.

22
10.2 FUNCTIONAL TESTING
Functional testing is the testing to ensure that the specified functionality required in the
system requirements works. It falls under the class of black box testing. Functional Testing is
a testing technique that is used to test the features of the system or Software, should cover all
the scenarios including failure paths and boundary cases. React forces us to build everything
as “components.”

10.3 SYSTEM TESTING

System testing is the testing to ensure that by putting the software in different environments
(e.g., Operating Systems) it still works. System testing is done with full system
implementation and environment. It falls under the class of black box testing.

System Testing (ST) is a black box testing technique performed to evaluate the complete
system the system's compliance against specified requirements. In System testing, the
functionalities of the system are tested from an end-to-end perspective.

System Testing is usually carried out by a team that is independent of the development team
in order to measure the quality of the system unbiased. It includes both functional and Non-
Functional testing.

23
 Figure 13.3 (a):- System Testing Types
10.4 INTEGRATION TESTING
Integration testing is testing in which a group of components are combined to produce output.
Also, the interaction between software and hardware is tested in integration testing if
software and hardware components have any relation. It may fall under both white box
testing and black box testing.

Figure 13.4 (a): - Integration Testing

10.5 BOTTOM UP INTEGRATION

Each component at lower hierarchy is tested individually and then the components that rely
upon these components are tested.

Bottom up Integration - Flow Diagram

Figure 13.7 (a): - Bottom Up Testing

Though Top level components are the most important, yet tested last using this strategy. In
Bottom-up approach, the Components 2 and 3 are replaced by drivers while testing
components 4,5,6,7. They are generally more complex than stubs.

24
 11. CONCLUSION AND FUTURE SCOPE
Conclusion
The conclusion of this study suggests that knowledge of specific domain improves the results.
This Project has been implemented on IOT platform. Also, different attributes are added to
project which are advantageous to the system. The requirements and specifications have been
listed above. This project uses python as backend. Using internet connectivity the system can
be accessed from anywhere in the world at anytime via a valid user. No more worry of the
electricity bill you can optimize it using our system.

Future Scope
a) This system can become more advance which will help to convert agriculture into
profiting business.
b) It can be further developed to remotely control motor pump and other resources.

12. REFERENCES
a) www.instructables.com/technology/raspberry-pi
b) https://www.geeksforgeeks.org/crop-monitoring-smart-farming-using-iot/
c) https://www.link-labs.com/blog/iot-agriculture
d) Wikipedia.org
e) Google.com

13. BIBLIOGRAPHY
(a) Python Programming: Python Programming in 24 Hours
(b) IOT Disruptions: The Internet of Things – Innovation & Jobs

25
LIST OF FIGURES

LIST OF FIGURES

Figure Number Figure Name Page Number

Figure 2.1 (a) Incremental Model 3
Figure 6.1.1 Data Flow Diagram 8
Figure 6.1.2 Use Case Diagram 9
Figure 6.1.3 Class Diagram 10
Activity Diagram
Figure 6.1.4 (a) (Temperature & Humidity 11
Module)
Activity Diagram (Smart
Figure 6.1.4 (b) 12
Irrigation)
Activity Diagram (Intrusion
Figure 6.1.4 (c) 13
Detection)
Sequence Diagram (Cooling
Figure 6.1.5(a) 14
And Exhaust Module)

Figure 6.1.5 (b) Sequence Diagram (Smart 15

Irrigation System)

LIST OF TABLES

LIST OF TABLES
Table Number Table Name Page Number
Table 1.2 (a) Project Deliverables 8
Table 10 (a) Test Cases 21

LIST OF ABBREVATIONS

LIST OF ABBREVATIONS
Abbreviation Meaning

26
IOT Internet Of Things

27
28