Real Time Fuel Monitoring System: Supervised by

Real Time Fuel Monitoring System
Supervised by
Mr. MukhtiarZamin
Developed by
Umer Ali
FA12-BSE-208
Saif-ur-Rehman
FA12-BSE-065
Javeria Mughal
FA12-BSE-109
DEPARTMENT_OF_COMPUTER SCIENCES
COMSATSINSTITUTE_OF INFORMATION
TECHNOLOGYABBOTTABAD
MAY, 2016
STARTING WITH NAME OF ALLAH,THE
COMPASSIONATE, ETERNALLY MERCIFUL
Thesis report submitted to COMSATS (CIIT) Abbottabad,
As completionof_requirements
For the_award of the degree_of Bachelors_of Science_in
Software Engineering
FINAL APPROVAL
It is to certify, that we have analyze and read the thesis report submitted by
______________________. It is our analysis and judgment that this thesis report is of enough
standard to warrant it acceptances by the CIIT, Abbottabad for the ____________
1. External Examiner __________________________________

Mr.
2. Internal Examiner ___________________________________

Dr. Eraj Khan
Assistant Professor,
Department of Computer Science,
COMSATS Institute of Information Technology,
Abbottabad.
3. Supervisor ___________________________________
Mr. MukhtiarZamin
Lecturer,
COMSATS Institute of Information Technology, Abbottabad.
4. Head of Department
Dr. Muhammad Waqas
COMSATS Institute of Information Technology,
Abbottabad
I
DEDICATION
This thesis is devoted to my mother and father who encourage me and give_me economic and
moral_aid for fulfilling all my_needs for the duration of the time I evolved my system. This
thesis is also dedicated to my_respected and honorable instructors who supported me all the
way. This thesis is also dedicated to my_juniors and all those people who believe within the
richness of mastering.
I devoted this degree to my respectable Parents, My whole Family, and close Friends
regarded Teachers who spurred, upheld and empowered me in each part of my project.
Umer Ali
II
DECLARATION
I therefore proclaim that this anticipate neither as entire nor as a section has been duplicated
out from any source. It is further announced that I have built up this equipment and went with
report completely on the premise of my own exertion, under the earnest direction of my
instructor (supervisor) and seniors. On the off chance that any piece of this framework is
turned out to be replicated out from any source or observed to be generation of another
person, I might remain by the results.
Signature: ___________
Umer Ali
III
ACKNOWLEDGEMENT
It is my pleasure and I am happy and feeling greatly euphoric to pay heartiest obligations.
Above all else, omnipotent ALLAH that he empowered and favored me to remove the leaf
from his large number bounties.
To my Dear guardians, their supplications turned into the venturing stones towards the
fruition of my undertaking.
I am enormously obligated to my regarded good and kind-hearted supervisor
Mr.MukhtiarZamin that he proposed me an exceptionally amazing and productive thought
and directed and co-worked our venture entire heartedly.
I might likewise want to thank the individuals from the Committee to the Commission and
give esteem counsel and help with this anticipate.
IV
PROJECT IN BRIEF
Project Title Real time fuel monitoring system
Organization Comsats Institute of Information Technology Abbottabad
Under taken by Umer Ali, Saif-ul-rehman, Javeria Mughal
Starting Month September 2015
Ending Month May 2016
Software Visual Studio 2013 and Arduino 1.0.6
Operating System Windows 8
End Product Real time fuel monitoring system
V
PREFACE
The report speaks to portrayal of investigation, outline, improvement, usage and testing of
"Real Time Fuel Monitoring System (V2)" at CIIT Abbottabad. The whole progress is
outlined and divided in chapters, Appendix and some sections.
CHAPTER ONE: This section examines the introduction of our work, the foundation,
scope and destinations of the framework. It is fundamentally the presentation of the proposed
framework and the disadvantages of the past framework.
CHAPTER TWO: This chapter includes non-functional and functional requirements of

system. All the work of the system is explained in this chapter. This chapter contains the
main features, facts and functionalities of the system so it is very important chapter.
CHAPTER THREE: This chapter contains information about components of our projects.
It contain information about both hardware and software components. This chapter is helpful
for the people who are not aware of hardware or software components used in system.
CHAPTER FOUR: This chapter includes the complete design of the system that is main
model of the system, the ways in which system is working and tasks are being executed.
Complete details are provided about the design of system and diagrams are used to give
graphical displays for understanding. The graphical UI is also displayed through images in
this chapter.
CHAPTER FIVE: This chapter includes the information about trial and error in the system
and describes the use of the ways and strategies. The test cases and test plans are used to
make sure the credibility of the system are also described in this chapter. Test cases defined
in this chapter are helpful to understand the functionalities of system and also prove the
correctness of system. Test cases are described in this chapter are detailed to deliver the
correctness of system.
CHAPTER SIX: This chapter deals with the conclusion, features, limitations and future
works of system. This chapter includes the information about the work and advancements
that can be done in future to maximize the utilities and functionalities of system. This
chapter can be helpful for the people working on the system in future.
CHAPTER SEVEN: This chapter deals with the user manual that how to install the system,
how to operate the system and how to take advantage of all functionalities of system. User
manual is for the ease of the user to use the system without any problem and to install al
components when needed.
VI
ABSTRACT
As we know Fuel theft is very common issues now a days and an important economic
problem. It is very common on Base stations and other industrial area where fuel is
continuously used in generators and machines. In our project “Real Time Fuel Monitoring
System” our objective is to remotely monitor the fuel consumption 24/7 and view the refined
information with Graphical displays, Alerts/notifications generation, Reports generation of
consumption, Admin Console, Operator Console, Contractor Console. Monitoring of fuel will
be done using Arduino, specific sensors, GSM and data SIM. Alerts and notifications along
with time and device id are being generated on web server against any change in specified
device of any stakeholder.
In this project main functionalities are extract fuel status from generator, maintain logs on
web server along with date, time and status, Notifications and alerts generations in case of
any change. There will be 3 users of our system Admin, contractor and operator. Admin has
overall authority of system. Contractor will be registered by admin, operator will be
registered by contractor. System is developed by using the separate roles of all stakeholders.
Permissions and roles are assigned to stakeholders according to their level. System
automatically manages the roles of stakeholders when they signed in to the system.
Tools and technologies used in project are C#, Bootstrap, MVC, SQL databases, Html, CSS,
Signal R ,Visual studio and Arduino coding, Arduino (used as medium to read data from
sensors and transfer it to GSM), GSM (used as medium between Arduino and Server for
sending data), Arduino Software (interface between developer and Arduino device), and
Sensors to measure level. Due to Bootstrap technology, system is independent of size of
device in which user will access the website. Bootstrap will automatically resize the size of
website according to screen. So we don’t need android or IOS application in future to access
the system using mobile devices.
Our product will be very effective and beneficial in industries and base stations and it will
decrease the fuel theft rate. We are focusing to make a system as a product to fulfill the
industry requirements and to minimize the fuel theft.
System is useful in all those industries using fuel as their primary source of running daily
operations. System is also helpful to be used in houses, small industries to measure and
monitor any type of liquid on a large scale. As there is no restriction to use the system on fuel
monitoring only, that’s why it can be advantageous on many places.
VII
Table of Contents
Chapter 1:Introduction………….…………………………………………………………………….1
1.1Introduction ........................................................................................................................................ 1
1.2 Scope ................................................................................................................................................. 1
1.3 Objectives ......................................................................................................................................... 1
1.4 Statement of the problem .................................................................................................................. 2
1.5 System importance ............................................................................................................................ 2
1.6 Process prototypical .......................................................................................................................... 2
1.6.1 Prototypes model ....................................................................................................................... 2
1.6.2 Communication: ......................................................................................................................... 2
1.6.3 Planning ..................................................................................................................................... 2
1.6.4 Quickly design ........................................................................................................................... 2
1.6.5 Prototypeconstruction ................................................................................................................ 2
1.6.6 Development, delivery and feedback ......................................................................................... 3
1.7 Feasibility report ............................................................................................................................... 3
1.7.1 Technical feasibility ................................................................................................................... 3
1.7.1.1 Arduino Mega and Arduino IDE......................................................................................... 3
1.7.1.3 Simulators ........................................................................................................................... 3
1.7.1.4 C# language using MVC architecture ................................................................................. 3
1.7.1.5 Web server .......................................................................................................................... 3
1.7.1.6Bootstrap and CSS ............................................................................................................... 3
1.7.1.7 RTC time module ................................................................................................................ 3
1.7.1.8 GSM module ....................................................................................................................... 4
1.7.1.9 SIM ..................................................................................................................................... 4
1.7.2 Financial feasibility .................................................................................................................... 4
1.7.3 Resource feasibility .................................................................................................................... 4
1.7.3.1 Hardware ............................................................................................................................. 4
1.7.3.2 Visual studio ....................................................................................................................... 4
1.7.3.3 XAMPP server and domain ................................................................................................ 5
1.7.4 Operational feasibility ................................................................................................................ 5
Chapter 2:Requirement Analysis…………………………………………………………………….6
2.1 Introduction ....................................................................................................................................... 6
2.1.1 Objective of project.................................................................................................................... 6
2.1.2 Current system ........................................................................................................................... 6
2.1.3 Proposed system......................................................................................................................... 6
2.2 Requirements analysis ...................................................................................................................... 7
VIII
2.2.1 Documentation for user.............................................................................................................. 7
2.2.2 External interface ....................................................................................................................... 7
2.2.3 Functional requirements............................................................................................................. 7
2.3 Performance requirements ................................................................................................................ 7
2.4 Security requirements ....................................................................................................................... 8
2.5 Quality requirements ......................................................................................................................... 8
2.6 Non-Functional requirements ........................................................................................................... 8
2.6.1 Visibility .................................................................................................................................... 8
2.6.2 Scalability .................................................................................................................................. 8
2.6.3 Compatibility ............................................................................................................................. 8
2.6.4 Usability ..................................................................................................................................... 8
2.6.5 Availability ................................................................................................................................ 8
2.6.6 User profiling and role assignment ............................................................................................ 8
Chapter 3:Project Components...…………………………………………………………………….9
3.1 Hardware parts description ............................................................................................................... 9
3.1.1 Arduino Mega 2560 ................................................................................................................... 9
3.1.2 Ultrasonic Module Transducer Sensor ..................................................................................... 10
3.1.3 GSM Module SIM900D .......................................................................................................... 11
3.1.4 RTC module ............................................................................................................................. 12
3.2 Software parts components ............................................................................................................. 13
3.2.1 Windows Operating System..................................................................................................... 13
3.2.2 Visual studio 2013 ................................................................................................................... 13
3.2.3 Arduino 1.0.6 ........................................................................................................................... 13
Chapter 4:System Design………….……………………………………………………………...….13
4.1 Design description .......................................................................................................................... 14
4.2 The design specification of the system ........................................................................................... 14
4.2.1 Analysis model partition .......................................................................................................... 14
4.2.2 Allocation and concurrency subsystem.................................................................................... 14
4.3 Use Case diagram ........................................................................................................................... 14
4.4 Class diagram .................................................................................................................................. 15
4.5 Sequence diagram ........................................................................................................................... 17
4.5.1 Create log readings .................................................................................................................. 17
4.5.2 Login request ........................................................................................................................... 18
4.5.3 Register device ......................................................................................................................... 19
4.5.4 Register user............................................................................................................................. 20
4.6 Component diagram ........................................................................................................................ 21
4.7 Deployment diagram ....................................................................................................................... 22
IX
4.8 Package Diagram ............................................................................................................................ 23
4.9 Entity Relationship Diagram ........................................................................................................... 24
4.10 Block diagram ............................................................................................................................... 25
4.11 Communication diagrams ............................................................................................................. 26
4.11.1 Login request ......................................................................................................................... 26
4.11.2 Add log readings .................................................................................................................... 27
4.11.3 Register device ....................................................................................................................... 28
4.11.4 Register user........................................................................................................................... 29
4.11.5 Request logs ........................................................................................................................... 30
4.12Circuit diagrams ............................................................................................................................. 31
4.12.1GSM Connections ................................................................................................................... 31
4.12.2GSM Module internal circuit diagram .................................................................................... 32
Chapter 5:Quality Assurance………….……………..…………………………………………..….32
5.1 Quality............................................................................................................................................. 33
5.2 Tests ................................................................................................................................................ 33
5.2.1 Test scenario 1 ......................................................................................................................... 33
5.2.2 Test scenario 2 ......................................................................................................................... 33
5.2.3 Test scenario 3 ......................................................................................................................... 34
5.3 Test cases ........................................................................................................................................ 35
5.3.1 Verify Sign In .......................................................................................................................... 35
5.3.2 Verify Register ......................................................................................................................... 38
5.3.3 Change Password ..................................................................................................................... 43
5.3.4 Edit Profile ............................................................................................................................... 46
5.3.5 View Alerts .............................................................................................................................. 49
5.3.6 View Logs ................................................................................................................................ 50
5.3.7 Update Device .......................................................................................................................... 51
5.3.8 Verify Device Reports ............................................................................................................. 54
5.3.9 Verify Devices View................................................................................................................ 56
5.3.10 Verify Accounts View ........................................................................................................... 57
5.4 Discussion on results....................................................................................................................... 59
Chapter 6:Conclusion and Future work.…………………………………………………………...59
6.1 Assessment...................................................................................................................................... 60
6.2 Limitations and features .................................................................................................................. 60
6.2.1 Limitations ............................................................................................................................... 60
6.2.2Features ..................................................................................................................................... 60
6.3 Conclusion ...................................................................................................................................... 60
6.4 Future enhancements ...................................................................................................................... 61
X
Chapter 7:User Manual……..….…………………………………………………...……………….61
7.1 Device installation .......................................................................................................................... 62
7.2 Light status ...................................................................................................................................... 62
7.3 SIM installation............................................................................................................................... 62
7.4 Turn on GSM .................................................................................................................................. 63
7.4.1 GSM light status ...................................................................................................................... 63
7.5 Open the website ............................................................................................................................. 63
7.6 Registration ..................................................................................................................................... 64
7.7 Sign In ............................................................................................................................................. 64
7.8 View dashboard .............................................................................................................................. 65
7.9 Main features .................................................................................................................................. 67
8.1 References ...................................................................................................................................... 71
9.1 Appendix ........................................................................................................................................ 72
XI
List of Tables
Table 1-1: Financial Feasibility .............................................................................................................. 4

Table 5-1: Test Case Verify Sign In ..................................................................................................... 38
Table 5-2: Test Case Verify Register .................................................................................................... 43
Table 5-3: Test Case Change Password ................................................................................................ 46
Table 5-4: Test Case Edit Profile .......................................................................................................... 49
Table 5-5: Test Case View Alerts ......................................................................................................... 50
Table 5-6: Test Case View Logs ........................................................................................................... 51
Table 5-7: Test Case Update Device..................................................................................................... 53
Table 5-8: Test Case Verify Device Reports ........................................................................................ 56
Table 5-9: Test Case Verify Devices View .......................................................................................... 57
Table 5-10: Test Case Verify Accounts ................................................................................................ 59
XII
List of Figures
Figure 3-1: Arduino Mega ...................................................................................................................... 9

Figure 3-2: Ultrasonic Sensor ............................................................................................................... 10
Figure 3-3: SIM900D ............................................................................................................................ 11
Figure 3-4: RTC Module ...................................................................................................................... 12
Figure 4-1: Usecase diagram................................................................................................................. 15
Figure 4-2: Class diagram ..................................................................................................................... 16
Figure 4-3: CreateLogReadings seq ...................................................................................................... 17
Figure 4-4: LoginRequest seq ............................................................................................................... 18
Figure 4-5: RegisterDevice seq ............................................................................................................. 18
Figure 4-6: RegisterUser seq ................................................................................................................ 19
Figure 4-7: Component diagram ........................................................................................................... 20
Figure 4-8: Deployment diagram .......................................................................................................... 22
Figure 4-9: Package diagram ................................................................................................................ 23
Figure 4-10: ER diagram ...................................................................................................................... 24
Figure 4-11: Block diagram .................................................................................................................. 25
Figure 4-12: LoginRequest comm ........................................................................................................ 26
Figure 4-13: AddLogReadings comm................................................................................................... 27
Figure 4-14: RegisterDevice comm ...................................................................................................... 28
Figure 4-15: RegisterUser comm .......................................................................................................... 29
Figure 4-16: RequestLogs comm .......................................................................................................... 28
Figure 4-17: Ultrasonic sensor circuit ................................................................................................... 29
Figure 4-18: SIM900 circuit ................................................................................................................. 29
Figure 4-19: Internal circuit .................................................................................................................. 32
Figure 5-1: Test Scenario 1 ................................................................................................................... 33
Figure 7-1: Arduino light ...................................................................................................................... 62
Figure 7-2: SIM jack ............................................................................................................................. 62
Figure 7-3: GSM light status................................................................................................................. 63
Figure 7-4: Home page ......................................................................................................................... 64
Figure 7-5: Registration ........................................................................................................................ 64
Figure 7-6: SignIn ................................................................................................................................. 65
Figure 7-7: Dashboard .......................................................................................................................... 67
Figure 7-8: Device registration ............................................................................................................. 68
Figure 7-9: Fuel graph .......................................................................................................................... 68
Figure 7-10: Logs graph........................................................................................................................ 69
XIII
Figure 7-11: Device report .................................................................................................................... 69
Figure 7-12: Logs .................................................................................................................................. 70
XIV
XV
RealaTimeaFuelaMonitoringaSystem
1.1 Introduction
It is the second or modified part of already done fuel monitoring system but we are focusing
to increase the functionalities and utilities of system. Main objective is to create a system
which will monitor the fuel consumption 24/7 and send the required data to web server.
Furthermore we will provide the remote access to the system. It will also include order
processing, refill analysis and fuel consumption analysis. When fuel consumption exceed
threshold value system will send alert to the server to avoid fuel theft. They are normally
utilized as a part of the remote zones where telecom segments have towers and their full
equipment keeps running on Generators, including, Mobilink, Zong, Ufone and Warid and
additionally any association that obliges fuel to work.
Fuel monitoring system is a proper mechanism to analyze and view the live values of fuel
consumption and refill. System will monitor the level or amount of fuel in defined unit and
send the values (data) on server with defined interval of time. Monitoring of fuel level will be
done using Arduino and specific sensors which will be connected to the web server. System
will also perform order processing which includes sending order in case of decreasing fuel to
specified stage. In case of any unwanted change in fuel level system will send alert to the
server. It will also measure and store the amount of change.
Its scope also includes customized website which will presents proper and detailed
information which is required for complete monitoring, alerts and order processing.
1.2 Scope
The framework is designed for the daily monitoring of fuel where user wants. This system is
very cheap, simple, useful, easy to understand and helpful in organizations where fuel is a
basic need and used on daily basis. This framework must be utilized by the administrator,
contractual worker and admin. All of three clients have their specific rights. In simple words
the system will monitor fuel with the help of specialized hardware, arrange the data in
specific order and send the data to web server for refined and customized display.
1.3 Objectives
Main objective is to remotely monitor the fuel consumption 24/7 and view the refined
information with:
 Graphical displays
 Alerts and notifications generation
 Reports generation of consumption
 User’s Console
 It will empower clients of FMS to save quality energy and time by specifically
giving them the required information of interest on the web, without accessing the
actual device deployed at any place to save client's valuable time
 It will decrease the fuel theft rate
 Enable users (admin, contractor, and operator) to check the status of the generators
Department of computer Science, CIIT Abbottabad 1

1.4 Statement of the problem

As I realize that the announcement of the issue relies on upon what problem is, who are users,
why to tackle problem and how to tackle it. Manual will be provided at the end to provide
understanding for users. The individuals will be able to use the system easily. The Laptop or
PC is essential. Data will be sent to the server using Data SIM in GSM module. SIM internet
is dependency for transmission of data (3G can also be used as good solution). Battery is
needed for working of hardware side. Without battery data cannot be captured. Hardware
must be compatible with software, for this we need device programming like Arudino code.
To use the system efficiently, specific hardware I have mentioned will be required and login
credentials will be necessary to enter in the system.
1.5 System importance

The system which is designed is for base stations and for those associations, industries or
production lines wherever generators square measure getting used. The system is run only for
the registered purchasers. The system identifies the backlog and thru this it ascertains the
standing of the fuel within the tank. At the purpose once the system acknowledges any
sudden amendment within the backlog, it will create an alarm and warnings and show them
on the web server. Also it maintain logs after every 17 seconds it will send reading to the
server showing current status of fuel.
1.6 Process prototypical

Procedural prototype describes the set of actions, action performance, management, how to
perform actions with ease and other procedures.
1.6.1 Prototypes model
System model is used because of the majority of the necessities know, yet the subtle element
of items is all around characterized.
1.6.2 Communication:
The communication prototypes are designed to make sure excellent communication. The
product architect and client depict the over articles for the product. It will make sure
arrangement and layout and communication between system components.
1.6.3 Planning
Planning prototypes are used to take advantage of quick planning and how planning is
utilized.
1.6.4 Quickly design
The focus of project is on noticeable parts of the product in aspect of client and all other
stakeholders.
1.6.5 Prototypeconstruction
Purpose of construction prototype is to make construction of system understandable and also
construction prototype will be used for further development.

1.6.6 Development, delivery and feedback

The project is based on useful prototypes and not based on throwaway. Prototypes will be
used in development, deliver to clients and used further.
1.7 Feasibility report

Feasibility analysis enables to understand the possibility of successful completion of project.
We have done technical, financial, resource and operational feasibility analysis in order to
estimate cost, finalize hardware components and to decide that from where we get them. Due
to feasibility analysis we are completely sure about all the dimensions of system and have
surety about its development.
1.7.1 Technical feasibility

In technical feasibility we will discuss material and components which are required for our
working model
1.7.1.1 Arduino Mega and Arduino IDE

Arduino is a programmable chip used for certain purposes. It contains voltage, input and
output ports. It also contains ports for interface to computer, battery and internet. Arduino
contains a small processor to process code instructions. Its code is compiled in Arduino IDE.
1.7.1.2 Ultrasonic sensor
This sensor is based on the concept of sonar waves production to determine distance. It is a
good and cheap way of measuring distance from sensor to the surface where it is placed. Its
readings can be modified to centimeters, inches or feet etc. depending upon requirements
1.7.1.3 Simulators
Simulator are use to send bulk of data to server
1.7.1.4 C# language using MVC architecture

We have use MVC architecture with C#.Controller bind model and view together. View
component implement the interface which will b seen. Model handle the data and database
issues.
1.7.1.5 Web server

Main objective is to create a system which will monitor the fuel consumption 24/7 and send
the required data to web server with proper graphical displays
1.7.1.6 Bootstrap and CSS

We have use Bootstrap template with CSS for proper styling.
1.7.1.7 RTC time module

Real Time Clock (RTC) Module is the cheapest and excellent way to get the time with every
reading sent from device to server. The module is used for time calculations and real time
updation. This module contains its own battery so that time remains updated even if the
system is power of. Different libraries can be used with it.
1.7.1.8 GSM module

This GSM module supports SIM card, and SIM internet can be activated and used by using this
module with Arduino. This module uses the internet connection of SIM to transfer data to server
1.7.1.9 SIM
GSM module supports SIM card, so it enables us to activate internet package on SIM and use that
internet package to send data to server
1.7.2 Financial feasibility

Financial feasibility deals with the finance and cost required to complete the project.
Resource name Price Source
Arduino Mega with GSM Rs. 8000 College road, Rawalpindi

module
Ultrasonic module Rs. 1000 College road, Rawalpindi
Long life rechargeable Rs. 1000 College road, Rawalpindi

battery
M to M and M to F jumpers Rs. 300 College road, Rawalpindi
Visual Studio Free Dreamspark by Comsats
Table 1-1: Financial Feasibility
1.7.3 Resource feasibility

Resource feasibility deals with the resources require to complete the project. It includes
hardware resources and software resources.
1.7.3.1 Hardware
Hardware is easily available in market and can also ordered online.
1.7.3.2 Visual studio

Available on Dream Spark and can easily download and installed.

1.7.3.3 XAMPP server and domain

Available online. We can use XAMPP server for testing on Local Host and domain will
provided by Supervisor.
1.7.4 Operational feasibility

Project is based on:
 Real time data capturing from fuel levels through Arduino by using Ultrasonic sensor
(SR04)
 Process data on server side and display results
 Operational environment for hardware side will include Arduino, Ultrasonic sensors
and fuel tank
 For server side web technologies will be used and server will be deployed in any
computer system
Simulators will be used:
 To send bulk of data to database so that database can handle maximum load in future
 To establish scalability standards
 Simulators will be installed in same or different computer systems
Windows Operating system for server side and simulators:
 Simulators and server will run in windows operating system

 Visual studio (new version) will be used for development and operations of simulators
and actual system
No sponsor and funding is approved for the project. All the cost and expenditure will be paid
by three group members. Supervisor will provide the domain for actual deployment.

2.1 Introduction
A prerequisite detail for software framework portrays far reaching report of execution of the
system which we will be built up. It contains assets of employments possessions that depict
the all communications the clients will have with the product. SRS likewise contains practical
and non-useful prerequisites. Requirement Analysis is the beginning stage of the product
creating movement. As system developed more intricate it got to be clear that the goal of
whole system can't grasp. Requirement Analysis procedure is request and more uncertain, it
manage the comprehension of the issue, aim and constraints.
The motivation behind our venture is to delineate a model FMS in generators/fuel tanks. The
main purpose as mentioned above is that, system will monitor the fuel in fuel generator tanks.
After analyzing the level in tanks, it will deliver logs, cautioning and alerts .it can be
recognized sufficiently early to maintain a strategic distance from any loses in fuel and
distinguish burglary. The extent of this anticipate performs essentially two errands at first
recognizing fuel volume and afterward performing activity concurring (cautioning the
Operator, contractual worker or Admin – Theft identification).
2.1.1 Objective of project

A prerequisite detail for software system portrays far reaching report of execution of the
system which we will be built up. It contains assets of employments possessions that depict
the all the terms and communication that occurs between clients. SRS that is designed is
helping for functional and non-functional requirements. SRS is the initial and starting phase
of creation of project for further development. When system created further it will be clear
that the goal of whole system can't grasp. Requirement Analysis procedure is request and
more uncertain, it manage the comprehension of the issue, aim and constraints.
As mentioned, he motivation behind our venture is to delineate a model FMS in

generators/fuel tanks. The focal point of a framework is that, it will analyze and check the
level of fuel in generator tanks and store the readings in form of levels. When fuel level is
analyzed, it will deliver logs, cautioning and alerts .it can be recognized sufficiently early to
maintain a strategic distance from any loses in fuel and distinguish burglary.
2.1.2 Current system

Recent and present system are very good but theft of fuel is our targeted and great issue
(notifications, alerts, log).simple logs are being generated but we need customized website
having separate console for each user (admin, operator and contractor).there is no reports
generation but we need it.
2.1.3 Proposed system

The proposed framework is to create programming framework which for this situation is the
tweak site, which can be utilized by the FMS administrators, Admins and temporary workers.
All of three clients have different consoles and powers for utilizing the framework. The
central point of the system is that, it will continuously monitor and analyze the levels of fuel
in tanks either single or multiple. After gathering the levels and readings, it will produce logs,
warning and cautions.It will create reports for vital basic leadership. The extent of this
anticipate performs fundamentally three errands at first identify the fuel volume and after that
performing activity concurring (cautioning the Operator, temporary worker or Admin – Theft
discovery) and generate reports.
2.2 Requirements analysis

It incorporates exhaustive portrayal of framework conduct which we are creating. It
comprises of the utilization cases that portray all of dynamic capacity cooperation’s amongst
clients and the product .SRS likewise incorporates practical and non-utilitarian necessities.
Outline investigation contains all the configuration ideas of framework. The framework
should utilizes the Arduino software for programming of hardware main module i.e. Arduino.
For software side we have used C# for programming and .NET framework and tool used is
Visual Studio.
2.2.1 Documentation for user
As I have mentioned all the basics and functionalities of the system above. To focus on the
understanding of the user, I will again elaborate the overview of the system for the users. The
system will be used to monitor fuel or can be used for any other liquid, in organizations
where there is danger of theft, or fuel maintenance. Our system will properly analyze the fuel
levels and send the readings to the server. Server will perform operations on readings and
display the alerts, warnings and critical situations all time.
2.2.2 External interface

User registration in system is the mandatory condition for using the system. Otherwise user
will be unable to get the full functionalities of system.
2.2.3 Functional requirements
Main and basicfunctionalities that system should perform are as follow:
 Sensor will perform first part i.e. they will get fuel levels
 Sensors data will be then sent to server using GSM module
 Third function is related to GSM, i.e. GSM is the medium of sending data to
server
 After transfer of data to server, server will perform its operations on data
 Information dissemination
 Alerts generation
 Monitoring Fuel
 Server Side Computations
 Customized Website
 Console Functionalities
2.3 Performance requirements

FMS will work effectively and its performance will be good. We will provide 24/7 services.

2.4 Security requirements

It will give all the efforts to establish safety and security establishments and the measures of
the simplicity of the client. Nobody aside from the client will have the access of the
application.
2.5 Quality requirements

Software is an application outlined particularly to suit the requirements of the client. It is
powerful and effective regarding execution. It is consummately consents to all the utilitarian
prerequisites that is all predefined qualities are utilized as a part of practice.
2.6 Non-Functional requirements

Other requirements include non-functional requirements and some special requirements in
order to meet quality standards and improve effectiveness and efficiency.
2.6.1 Visibility
It has friendly user interface and responsive (The forms and screens of the system will be
adjusted to the size of window of device)
2.6.2 Scalability
The system will be scalable to handle more users after deployment. To test the scalability we
will use simulators to increase users.
2.6.3 Compatibility
This application is compatible with all versions of laptop PC’s.
2.6.4 Usability
System should have usable and simple interfaces for the ease of users.
2.6.5 Availability
As the main purpose of the system is to monitor fuel 24 hours, so availability matters a lot.
System should be available 24/7 to fulfill required functionalities.
2.6.6 User profiling and role assignment

One of the major requirement of our system is separate user’s profiling and assignment of
user’s roles for performance, quality and modulation.

3.1 Hardware parts description

This section includes the hardware parts of system with pictures, description and sub
components details.
3.1.1 Arduino Mega 2560

Arduino is a programmable chip used for certain purposes. It contains voltage, input and
output ports
Figure 3-1: Arduino Mega
.It also contains ports for interface to computer, battery and internet. Arduino contains a small
processor to process code instructions. Its code is compiled in Arduino IDE.
 Arduino board can be used on choice of coder, you can use Arduino to perform any
task by attaching specific hardware with it and write the required code.Arduini board
have versatile functionalities and it can be usedwith multiple sensors and components.
 It has 54 automated data/yield pins for data and yield, 15 of them are dedicatedto be
used as PWM yields.
 In our undertaking observing of fuel level will be done utilizing Arduino and
particular sensors which will be associated with the web server.
 Our task depends on Real time information catching from fuel levels through Arduino
by utilizing Ultrasonic sensor (SR04).

3.1.2 Ultrasonic Module Transducer Sensor

This sensor is based on the concept of sonar waves production to determine distance.
Figure 3-2: Ultrasonic Sensor
 It is a good and cheap way of measuring distance from sensor to the surface where it
is placed. Its readings can be modified to centimeters, inches or feet etc. depending
upon requirements
 When voltage is provided i.e. 5 volts, it sends sonar waves to the fuel, to check the
level of fuel
 When sonar waves hit the level of fuel, ultrasonic sensor measures the distance
between its face and the level of fuel
 Distance can be converted to cm, inches, feet etc. on the demand of user
 Ultrasonic sensor is the best way to measure distance as it is cheap
 It also have some limitations that cannot be ignored like positioning problems
 For more accurate measurement and very less percentage of data loss, highly accurate
sensors can be used

3.1.3 GSM Module SIM900D

SIM 900D is a GSM module used for many purposes like data sharing in our case.
Figure 3-3:
3 -3:SIM900D
GSM Module Figure 3-3: SIM900D
 This GSM module supports SIM card, and SIM internet can be activated and used by
using this module with Arduino. This module uses the internet connection of SIM to
transfer data to server.
 GSM module is a best way to remove the dependency of internet in far or backward
areas
 We are using GSM module in order to remove dependency of internet connection like
DSL in mobile communication towers on hilly areas
 GSM module supports SIM card, so it enables us to activate internet package on SIM
and use that internet package to send data to server
 This module works likes a medium to end the dependency of internet like DSL,
Ethernet, WIFI and used the remote network to transfer data
 It is used in all mobiles by telecommunication companies. It can be also used with
embedded systems to perform many tasks.

3.1.4 RTC module

Real Time Clock (RTC) Module, is the cheapest and excellent way to get the time with every
reading sent from device to server.
Figure 3-4: RTC Module
 The module is used for time calculations and real time updation. This module contains
its own battery so that time remains updated even if the system is power of. Different
libraries can be used with it.
 Calculations of Leap and normal years
 Calender with full accuracy
 Backup battery for time updation
 Pin for output
 Memory of 56 bytes for user, it is non-volatile
 This module works on DST library, which can be easily download and installed in
Arduino IDE
 It also have built-in method of checking circuit, if circuit is not properly made,
Arduino IDE will display message to check circuit
For interfacing and connection of these hardware modules, connectors or jumpers are used.
These are small wires to provide voltage to hardware components from battery. All hardware
used in this project is easily available in market and can be programmed to do required
functionality.
In case of failure of any of hardware component, it can be easily replaced and new component
can easily installed.

3.2 Software parts components

This section includes components used for software side, i.e. tools, IDE and programming
environment.
3.2.1 Windows Operating System
Windows operating system is used as a main environment for the development of complete
system.
3.2.2 Visual studio 2013

Visual Studio is a versatile tool of developing and testing applications. It is most commonly
used tool for .NET and C# language. We have used Visual Studio 2013, for development of
our application.
 Visual studio is a versatile and very good tool for development of applications
designed and created by Microsoft
 It is used for many purposes including web applications development, android apps
development and much more
 It contains rich variety of forms, facility of designing, debugging and testing, code
management, frameworks, application architectures, and support of multiple
applications development
 It’s one other functionality is that managed and native code both can be produced
 Visual studio allows multiple instances to run at same time because every instance has
its own VS package
3.2.3 Arduino 1.0.6

For coding of Arduino, we have used IDE named Arduino 1.0.6. It is a dedicated IDE for
coding of Arduino. It has built-in compiler to check code errors in Arduino.
 It provides compilation of code which will be executed in Arduino, errors including

syntax and logical errors are caught due to this IDE
 When code is compiled, it is then burned to the actual Arduino device to show the
actual results and behavior of device. Serial monitor of IDE is used to show the text
and response sent back by the device
 IDE of Arduino provides some libraries and sample codes also to help coder in order
to understand the working of Arduino and check the board that if it is in working
condition or not.
 The program which is written for Arduino is called sketch
 Arduino programs are written in C++/C and come with software wiring library which
makes its operation easier.

4.1 Design description

It deals with the design, diagrams, visual representation, tables and charts to describe the
system to the users and to show that it satisfies the requirements.
4.2 The design specification of the system

Design of any system shows the visual representation of the system and through visual
representation designer tries to fulfill the requirements of system. Design specifications are
used to give the users and clients a full representation of system working, components
interaction, data used and many other aspects. Design specification basically tells that how
system will perform the functionalities described in functional requirements. Design
specifications contains all the aspects like how data is transferred in different parts of system,
how data is used in different components, how database is accessed and how data is saved
and retrieved, what is relationship between system units, classes and modules. Design of the
system also describes the deployment methods, components used, and database design.
Design specifications also deals with the interface design and interface integration with the
back end functionality. How design is important and further details about design
specifications are mentioned below.
Specific inputs (data types etc.) which we are entering into the system.
 Calculation/codes which are used to achieve define requirements

 Outputs which are being generated from the system
 It explains technical measure for ensuring security of system
 Choose a basic plan for implementing of data management
 Assign subsystems to processors and tasks
4.2.1 Analysis model partition
Partitioning of the system is one of the best way for understanding, maintenance and
understandability of system. System is divided into subsystems.
4.2.2 Allocation and concurrency subsystem
Dynamic behavior of objects can be determined through dynamics aspects. Concurrent
processing is only needed at that time when objects are active at same time.
4.3 Use Case diagram

Use case diagrams are used to describe user’s goals i.e. it is used to describe the interaction of
user with system. It is functionalities of system written in an organized manner. Actors can be
defined as something that interacts with the system.

Figure 4-1:Usecase diagram
Admin usecase diagram is describing complete interaction of Admin with system. This
diagram is showing all the functionalities and the roles fulfilled by the Admin. Contractor
usecase diagram is describing complete interaction of Contractor with system. This diagram
is showing all the functionalities and the roles fulfilled by the Contractor. Operatorusecase
diagram is describing complete interaction of Operator with system. This diagram is showing
all the functionalities and the roles fulfilled by the Operator.Device usecase diagram are
describing complete interaction of Genset device with system. This diagram is showing all
the functionalities and the roles fulfilled by the Genset device.
4.4 Class diagram

Class diagram is used to represent the classes of the system, state variables of classes and
methods used in classes in OOP. It is use for modeling of systems which are object oriented.
It shows collection of classes, associations, composition, aggregation, collaboration
etc.Classdiagram shows the state variables and functions or methods of each class. Following
class diagram is representing our system. Following class diagram is showing the all classes
of Real time fuel monitoring system, state variables and methods of each class.

Figure 4-2: Class diagram

4.5 Sequence diagram

It show connection between objects in a successive request in which communication happen.
It indicates stream of rationale in our framework in a visual way. The Sequence Diagram
models the coordinated effort of items taking into account a period succession. It
demonstrates how the objects collaborate with others in a specific situation of a utilization
case.
4.5.1 Create log readings

This diagram is showing sequence of steps to create log readings.
DeserializeObject<ResultsCont...
Figure 4-3: CreateLogReadingsseq

4.5.2 Login request

This diagram is showing sequence of steps to make login request
Figure 4-4: LoginRequestseq
Steps includes how to make request, what data is required, how data will be passed, how
objects will be made etc.

4.5.3 Register device

This diagram is showing sequence of steps to register device with system to get full authority
in device and monitor fuel using it.
Figure 4-5: RegisterDeviceseq

4.5.4 Register user

This diagram is showing sequence of steps to resister user by giving valid data and get the
response.
Figure 4-6: RegisterUserseq
Diagram is showing the complete mechanism which will be performed at the back end.
4.6 Component diagram

Component diagrams are used to show the components of system. Which are the main
components and how components are connected. It is general overview of the system without
details. In our system three major components are FMS Service and FMS web application
and Arduino.
Figure 4-7: Component diagram
Above mentioned diagram is showing our system’s components and their connection. It is
clearly mentioned that there are three main components in our system. Arduino is used at
hardware side for fuel monitoring and sending it to server through GSM. FMS service is
playing the role of data acceptor and performing analysis on data, It is accepting data from
device sent through GSM, analyze it and send it to FMS web application.
FMS web application receives data and display it on dashboard for the stakeholders, It
displays the data in different styles for the understanding of stakeholders.

4.7 Deployment diagram

Deployment diagrams are utilized to show the actual deployment of system when it will
complete. Deployment diagrams show the main components and sub components of system,
their relationship at the time of deployment and environment where system will be deployed.
Deployment diagrams gives advantage at the time of deployment of system as everything
related to deployment was already modeled. It shows the segments, dependencies and also
small components of system.
Figure 4-8: Deployment diagram
Deployment diagram mentioned above is showing the deployment of our system when we
will deploy it in actual environment. Diagram is showing the main components and the way
in which they are deployed. Diagram is also sowing the relationship between components
when they are deployed.

4.8 Package Diagram

Package diagram mentioned below is showing the packages of our system, sub components in
each package, relationship between sub components in each package and relationship
between main packages
Figure 4-9: Package diagram
The package diagram is use for demonstrating the course of action and association of model
components in center to expansive scale undertakings. This outline demonstrates both
structure and conditions amongst frameworks and subsystems or modules of the fancied
framework. Packages are arranged in form of layers or we can say separate boxes, each
packages contains related components which works together or whose work is related to each
other. For example package for UI, package for business logic, package for storage or
database etc. In our project our three main packages are FMS, FMSCommon and FMSDAL
application.

4.9 Entity Relationship Diagram

E/R Modelling is utilized for conceptual design
Figure 4-10: ER diagram
 Entities – objects of interest

 Attributes – proprieties, facts about an entity
 Relationships – links or joins between entities
This ER diagram is showing the database structure of our system, main classes of database,
their dependency, relationships and variables declared. ER diagram shows the complete
database design, working and purpose of database. It also shows the data needed to be saved
and how to deal with data. It also shows the data types of data which is being stored.

4.10 Block diagram

Block diagram’s structure gives an abnormal or high level state diagram of significant
framework segments, key procedure members, and essential working connections.
Figure 4-11: Block diagram
This block diagram is showing the main blocks of our system and how these main blocks are
communicating with each other. How communication is depending on blocks and what is the
dependency, we can take the general idea about blocks of system and their working but we
can’t take details from block diagram, In short we can say that this diagram is generally
showing the overview of the blocks of the system without going into inner details of system.
It does not describe the inner functionalities but the components of the system in which one
component provide the services and other component require the services
In our case we have 4 major blocks of our system Sensor, Arduino, GSM,
WebService.Arduino takes reading from the sensor and send reading to web server through
GSM modem. Sensor will sense the top distance of fuel from sensor in centimeters .Arduino
will take reading from sensor and transfer it to webserver through GSM.

4.11 Communication diagrams

Communications diagrams have function of showing the concept of transfer of messages
between components while processing any request.
4.11.1 Login request

This Diagram is showing the communication which will be done between system components
while processing Login request.
Figure 4-12: LoginRequestcomm

It can be easily observed that how functions are being called, which functions are called and
how communication is being done in the mentioned diagram. It is presenting the clear image
of processing request of login with all the methods and data used to process login request.

4.11.2 Add log readings

while processing Add logs.
Figure 4-13: AddLogReadingscomm

how communication is being done in the mentioned diagram.

4.11.3 Register device

while processing Register device.
Figure 4-14: RegisterDevicecomm

how communication is being done in the mentioned diagram. Diagram is clearly describing
the data and methods used in processing request of register device.

4.11.4 Register user

while processing Register user request.
Figure 4-15: RegisterUsercomm

4.11.5 Request logs

while processing Request logs.
Figure 4-16: RequestLogscomm

4.12 Circuit diagrams

It gives us over all description of Ultrasonic sensor circuit.
Figure 4-17: Ultrasonic sensor circuit
4.12.1 GSM Connections

GSM/GPRS module is used_to establish communicationbetween a computer and_a GSM-
GPRS_system.
Figure 4-18: SIM900 circuit

4.12.2 GSM Module internal circuit diagram

These circuit diagrams are fully describe the circuit of hardware used in the project. These
diagrams are describing the connections, interfacing and communication between hardware
components.
Figure 4-19: Internal circuit
How GSM module is integrated with Arduino, and how to join sensors with Arduino. It is
clearly described from these diagrams. Also one diagram is showing the internal mechanism
and structure of GSM module for more understanding.
These diagrams are helpful for future works and also helpful in case there is need to replace
any module and connect it again. Circuit diagrams are important because it is very difficult to
make hardware runnable without circuit diagram. Circuit diagrams enables developers to
integrate and run hardware components in short time.
These diagrams are also describing the position and direction of connectors to connect them
on a specific point of Arduino. These connector are difficult to manage and very hard to
remember without these circuit diagram. Circuit diagrams are clearly elaborating everything.

5.1 Quality
As mentioned above, we will discuss accuracy and performance of our system from both
developers and users point of view. The aspect of the future upgrade and adjustments to be
made are also mentioned. Quality is assured with the help of test cases and test scenarios.
5.2 Tests
We have perform different tests to measure the accuracy and performance of our system by
taking 100 different reading actual reading, layered reading, reading by using 2 sensors and
compare the results and see which gives better result.
5.2.1 Test scenario 1

In test scenario 1 we will discuss accuracy of stable readings by using 1 sensor. We will
discuss it by confidence interval and F measure by taking 100 different readings. Stable
readings are being compared with actual reading and we get 92 % accuracy.
Figure 5-1: Test Scenario 1

In test scenario 2 we will discuss accuracy of layered readings. We will discuss it by
confidence interval and F measure by taking 100 different readings. Layered readings are
being compared with actual reading and we get 16% accuracy which is too minimum.


In test scenario 3 we will discuss accuracy of layered readings by using 2 sensors. We will
discuss it by confidence interval and F measure by taking 100 different readings. Layered
readings are being compared with actual reading and we get up to 59% accuracy.

5.3 Test cases

Test cases are actually set of conditions through which we can determine the quality of our
software.
5.3.1 Verify Sign In

Verify Sign In page and functionality with valid username and Password.
Project Name: Real Time Fuel Monitoring System

Test Case ID: TC_S_IN_01 Design: Javeria Mughal
Priority (Low/Medium/High): High Design date: 6/18/2016
Module: Accounts Management Executed: Umer Ali
Test Title: Verify Sign In Execution date: 6/18/2016
Description: Verify Sign In page and Approved by: Supervisor andUmer Ali
functionality with valid username and Password
Pre-conditions:
1. Sign In screen should be open
2. There should be working internet connection
Basic flow:
Basic flow shows the basic steps needed to perform the testcase.
Step No. Steps Data Expected Actual Status

Result Result
1 Navigate NILL User should be User is Pass

to Sign able to see navigated to
In page Sign In page Sign In page
User should Successfully

Sign In when signed in to
2 Provide Email Sign In pressed required Pass
valid Id=saif.ciit@gmail.co account
usernam m when SignIn
e

User should Successfully

Sign In when signed in to
3 Provide Password=abcd Sign In pressed required Pass
valid account
Passwor
d
4 Click on Valid Email Id and User should Successfully Pass

Sign In Password Sign In signed in
button
Alternate flow 1 (Invalid Password)

In alternative flow we will give invalid password and see the result
Step No. Steps Data Expected Result Actual Status

Result
1 Navigate NILL User should be able User is Pass

to Sign to see Sign In page navigated to
In page Sign In page
Sign In failed with Sign In failed

message Invalid with message
2 Provide Email email/Password Invalid
valid Id=saif.ciit@gma when Sign In email/Passwor Pass
usernam il.com pressed d when Sign In
e pressed

3 Provide email/Password Invalid
invalid when Sign In email/Passwor Pass
Passwor Password=aaa
pressed d when Sign In
d pressed
Alternate flow 2 (Invalid Email)

In alternative flow 2 we will give invalid email and see the result. Alternate flow will show
the possibilities and chance of errors and system’s functionality to what to do in case anyone
enters wrong format of Email.

Step No. Steps Data Expected Result Actual Result Status
1 Navigate NILL User should be able User is Pass

to Sign to see Sign In page navigated to

2 Provide Email email/Password Invalid Pass
invalid Id=saif.ciit@gma when Sign In email/Passwor
usernam il.com pressed d when Sign In
e pressed

3 Provide email/Password Invalid Pass
valid when Sign In email/Passwor
Passwor Password=abcd
pressed d when Sign In
d pressed
4 Click on Invalid Email Id User should not Sign Sign In failed Pass
Sign In and valid In and message is with message
button Password displayed
Alternate flow 3 (One or both empty fields)

In alternative flow 3 one or more fields are being empty
Step No. Steps Data Expected Result Actual Status

Result
Navigate NILL User should be able User is Pass

1 to Sign to see Sign In page navigated to

message Please fill with message
2 Provide NILL out this field when Please fill out Pass
valid Sign In pressed this field when
usernam Sign In
e pressed


message Please fill with message
3 Provide Password=abcd out this field when Please fill out Pass
invalid Sign In pressed this field when
Passwor Sign In
d pressed
User should not Sign Sign In failed

In and message is with message
4 Click on One or both displayed Pass
Sign In empty fields
Post-conditions:
1. User is validated with database
2. Successfully signed in to required account (Admin account or Contractor account or
Operator account according to Email Id and Password)
3. The account session details are maintained
Table 5-1: Test Case Verify Sign In
5.3.2 Verify Register

Verify Registration page and functionality with all valid fields.

Test Case ID: TC_REG_U_02 Design: Saif-ur-Rehman
Priority (Low/Medium/High): High Design date: 6/18/2016
Module: Register Executed by: Umer Ali
Test Title: Verify Register Execution date: 6/18/2016
Description: Verify Registration page and functionality Test Approved by: Supervisor
with all valid fields andJaveria Mughal
Pre-conditions:
1. Register screen should be open
3. System is up to use
Basic flow:
Basic flow shows the basic steps needed to perform the testcase. Basic flow is showing the
steps needed to perform the step and data required to fulfill the requirements of steps needed
to process the request.

Step No. Steps Data Expecte Actual Status

d Result Result
User User is Pass

should be navigated
Navigate to NILL able to to
Register see Register
1 page Register page
page
User Successfu
should lly
2 Enter FirstName=Umer Register Registere Pass
FirstName when d to
Register required
pressed account
when
Register
pressed
User Successfu
should lly
3 Enter LastName= Register Registere Pass
LastName when d to
Ali
Register required
pressed account
when
Register
pressed
User Successfu
should lly
4 Enter EmailId= Register Registere Pass
EmailId when d to
umer_shiningstar@yahoo.co
m Register required
pressed account
when
Register
pressed
User Successfu
should lly
5 Enter Password= Register Register Pass

Password Fuel1234 when required

Register account
pressed when
Register
User Successfu
should lly
6 Enter CellNumber= Register Registere Pass
CellNumbe when d to
r 034595627333
Register required
pressed account
when
Register
pressed
User Successfu
should lly
Enter Supervisor Id= Register Registere Pass
Supervisor when d to
7 Id “saif.ciit@gmail.com”
Register required
pressed account
when
Register
pressed
User Successfu Pass

should lly
8 Select type o Contractor register Registere
o Operator with d to
his/her required
selected account
type when
Register
pressed
Alternate flow 1 (Invalid Password)

In alternative flow 1 invalid password is being given.
Navigate NILL User User is

to Register should be navigated
1 page able to see to Register Pass
Register page
page

Provide FisrtName: Register Register

with all failed with user failed
2 other Umer message with Pass
fields LastName: Invalid message
mentioned Password Invalid
above Ali when Password
Register when
Email:
new user Register
umer_shiningstar@yahoo.co pressed new user
m button
pressed
CellNumber:
034595627333
Etc
Display “Enter 8-
“Enter 8- 20
Provide
20 characters
invalid
3 Password=aaaa characters Password” Pass
Password
Password”
message Message is
with displayed
Password with
field. Password
field.
Click on Valid other fields and invalid Cant Register Pass

Register Password registered user with
4 new user withmessge message
Alternate flow 2 (Invalid Email)

In alternative flow 2 invalid email is being given and see the results to verify that system is
working as per requirements

Result Result
Navigate User User is

1 page NILL able to see to Register Pass
Register page
page

Provide Display “Enter

invalid “Enter valid email
2 email Email Id=umer
valid email with @
with @ keyword Pass
keyword” “message is
message displayed
with
FisrtName:
Umer
LastName: Register Register

new user user failed
Provide Ali failed with with
with valid message message
3 all other Password: Pass
“Enter “Enter
fields fuel1234 valid email valid email
with @ with @
CellNumber:
keyword” keyword
034595627333
Etc
Register Register Pass

new user user failed
Click on failed with with
Register message message
4 new Invalid Email Id
“Enter “Enter
button
valid email valid email
with @ with @
Alternate flow 3 (One or both empty fields)

In alternative flow 3 One or both empty fields are given.

Result Result
Navigate User User is

1 page NILL able to see to Register Pass
Register page
page

2 Provide All or some empty fields Display “Required Pass

1/more “Required ” message
empty ” with all is displayed
fields fields. with all
User Sign In
should not failed with
3 Click on One or both empty fields Sign In and message Pass
Sign In message is “Required
button displayed ” with all
fields
Post-conditions:
1. User(Contractor, Operator) data is being save in database
2. Successfully registered to required account ( Contractor account or Operator account
according to their selection of type)
Table 5-2: Test Case Verify Register
5.3.3 Change Password

In this test case we verify change password.

Test Case ID: TC_CHN_PS_03 Design: Javeria Mughal
Priority (Low/Medium/High): Medium Design date: 6/18/2016
Module: Account Management Executed by: Umer Ali
Test Title: Change Password Execution date: 6/18/2016
Description: Verify Change Password Test Approved by: Supervisor and Saif-
ur-Rehman
Pre-conditions:
1. Change Password panel should be open
Basic flow:
Basic flow shows the basic steps needed to perform the testcase for verifying the required
functionality of testcase. Basic flow is showing the steps and data needed to process this
request and sequence in which steps should be performed in order to process the task
successfully.


Result Result
1 Navigate to NILL User should User is

Change be able to navigated to
Password see change change Pass
Page Password Password
Successfully
Changed
User Password
Password from
2 Enter Old OldPassword= should be specified Pass
Password change
Fuel1234 account
when when
change change
Password Password
pressed pressed
Successfully
Changed
User Password
Password from
3 Enter New NewPassword= should be specified Pass
Password change
mughal1234 account
when when
change change
Password Password
pressed pressed
4 Confirm Confirm User Successfully

New NewPassword= Password Changed
Password should be Password Pass
mughal1234 change from
when specified
change account
Password when
pressed change
Password
pressed
5 Click on Valid fields Updated Password Pass

Button Password changed

Alternate flow 1 (Empty Fields)

In alternative flow 1 one or more empty fields are being given and see the result

Result Result
Navigate to NILL User should User is

change be able to see navigated to
1 Password change change Pass
Password Password
page page
Provide All or some empty Display “Required

1/more fields “Required” “message is
2 empty with all displayed Pass
fields.
Profile Update failed

should not be with message
3 Click on One or both empty updated and Pass
please fill in
change fields message is all fields
Password displayed “with all
button fields
“please fill
in all fields”
Alternate flow 2 (Passwords doesn’t match)

In this flow we will discuss password un match scenario

Result Result
1 Navigate to NILL User should User is Pass

change be able to see navigated to
Password change change
Password Password
page page
Password New
with message Password and
“New and confirm

2 Enter Old OldPassword= confirm Password Pass

Password password doesn’t
Fuel1234
not match” match
Password New
doesn’t Password and
change with confirm
Enter New NewPassword= following Password
Password message doesn’t
3 mughal1234 “New match Pass
Password
and confirm
Password
doesn’t
match”
Password New
doesn’t Password and
change with confirm
Confirm Confirm following Password
New NewPassword= message doesn’t
4 Password “New match Pass
Mughal0345 Password
and confirm
Password
doesn’t
match”
Click on User Password not

Change Password change
5 Password Invalid fields should not be Pass
button updated
Post-conditions:
1. New Password is being updated in database
2. Successfully change Password from specified account ( Contractor ,Operator, Admin)
Table 5-3: Test Case Change Password
5.3.4 Edit Profile

This testcase is about verify edit profile page .


Test Case ID: TC_EditProfile_04 Design: Umer Ali
Module: Account Management Executed by: Javeria Mughal
Test Title: Edit profile Execution date: 6/18/2016
Description: Verify Edit Profile page Test Approved by: Supervisor andSaif-
ur-Rehman
Pre-conditions:
1. Update profile screen should be open
Basic flow:

Result Result
1 Navigate to NILL User should User is

Edit Profile be able to navigated to
Page see Edit Edit profile Pass
profile page page
User profile Successfully

changed, if Updated
2 Update FirstName= update from Pass
FirstName profile specified
Ahmed
pressed account

should be Updated
Update LastName= change when from Pass
LastName update specified
3 Khan
profile account
pressed when update
pressed


should be Updated
4 Update Cell Cell Number= change when from Pass
Number update specified
03469563733
profile account

should be Updated
5 Update Address= change when from Pass
Address update specified
College
road,mandian profile account
pressed when update
profile
pressed
Click on User profile Profile

Update should be Updated
6 Profile Valid fields updated Successfully Pass
Alternate flow 1 (Empty Fields)

In alternative flow 1 one or fields are being empty.

Result Result

update be able to see navigated to
profile update edit profile
profile page page
Provide All or some empty Display “Required

1/more fields “Required” “message is
2 empty with all displayed Pass
fields.
Click on One or both empty Profile Update failed

update fields should not be with message
3 profile updated and Pass
please fill in
button message is all fields
displayed “with all
“please fill” fields

Post-conditions:
1. User(Contractor, Operator, Admin) data is being updated in database
Table 5-4: Test Case Edit Profile
5.3.5 View Alerts

This test case is about verify view alerts.

Test Case ID: TC_ViewAlerts_05 Design: Umer Ali
Module: Data Management Executed by: Saif-ur-Rehman
Test Title: View Alerts Execution date: 6/18/2016
Description: Verify View Alerts Approved by: Supervisor andjaveria
Pre-conditions:
1. Alerts page should be displayed on screen
Basic flow:

Result Result
User is
navigated on
the alerts
1 Navigate to Alerts are being User should page and Pass
view alerts save in database be able to alerts are
see all alerts being
displayed.
Alternate flow 1 (No logs)

In this test case scenario is being discuss when there is no logs save in database. This
alternate flow is showing the possibility of wrong understanding of system and entering any
wrong data.


Result Result
1 Navigate to Alerts not save in User should Alerts are not Pass
view logs database not see alerts displayed
Post-conditions:
1. Alerts are being displayed on screen with Threshold, id and device etc.
Table 5-5: Test Case View Alerts
5.3.6 View Logs

In this test case verify logs are maintained.

Test Case ID: TC_ViewLogReading_06 Design: Saif-ur-Rehman
Module:Data Management Executed by: Javeria Mughal
Test Title: View Logs Execution date: 6/18/2016
Description: Verify Logs are maintained Approved by: Supervisor and Umer Ali
Pre-conditions:
1. Logs reading page should be open
3. Database in working condition
4. Server should be up and working
Basic flow:

Result Result
1 Navigate to Logs save in User should User is Pass

view log database be able to navigated on
reading see all logs the logs page
page and reading
displayed

Alternate flow (logs not save in database)

Scenario is being discuss when logs are not save in database.
Step No. Steps Data Expected Actual Result Status
Logs are not

being
1 Navigate to Logs not save in User should displayed and Pass
view logs database not be able to display the
see logs message “No
record found”
Post-conditions:
1. Logs are being displayed on screen with id, phone number, distance in cm etc.
Table 5-6: Test Case View Logs
5.3.7 Update Device

In this test case we will verify update device.

Test Case ID: TC_UpdateDevice_07 Design: Saif-ur-Rehman
Module: Device Management Executed by: Javeria Mughal
Test Title: Update Device Execution date: 6/18/2016
Description: Verify Update Device Approved by: Supervisor andUmer Ali
Pre-conditions:
1. User must be logged in
2. Dashboard should be in working
Basic flow:

Result Result
1 Navigate NILL User see User is Pass

to update updated navigated on
genset results in the page

page for result of which is
updation update requested
New device Message is

should be displayed
2 Enter Phone# Pass
updated ”Device
phone when click
03005631995 updated
number update successfully”
device

should be displayed
3 Enter Maximum measuring updated Pass
”Device
maximum unit: 27 when click updated
measuring update successfully”
unit device
Enter New device Message is

litres at should be displayed
4 maximum Litres at maximum Pass
updated ”Device
measuring measuring unit: 11 when click updated
unit update successfully”
device
Enter New device Message is

difference should be displayed
5 Difference b/w max Pass
between updated ”Device
max fuel fuel level and sensor: when click updated
level and 5 update successfully”
sensor device

should be displayed
6 Enter Latitude: Pass
updated ”Device
latitude when click
9.644000000 updated
update successfully”
device

should be displayed
7 Enter Longitude: Pass
updated ”Device
longitude when click
8.223000000 updated

8 Address Address: mandian New device Message is

should be displayed
Pass
updated ”Device
when click updated

should be displayed
Threshold Threshold value: 5 Pass
updated ”Device
value when click
9 updated
device
Alternate flow 1 (Empty fields)

When one or more fields are empty

Result Result
1 Navigate NILL User should User is Pass

to update be able to navigated to
device see update edit device
device page page
Provide Display “Required

1/more “Required” “message is
2 empty All or some empty with all displayed Pass
fields fields fields. with all
fields.
Profile Update failed

should not be with message
Click on updated and please fill in
update
4 device One or both empty message is all fields Pass
fields displayed “with all
button fields
“please fill
in all fields”
Post-conditions:
1. Updated device data stored in database should be maintained with updated data
Table 5-7: Test Case Update Device

5.3.8 Verify Device Reports

In this test case we will verify each device report. .

Test Case ID: TC_DEVREP_08 Design: Umer Ali
Priority (Low/Medium/High): Med Design date: 6/18/2016
Module: Report Management Executed by: SaifurRehman
Test Title: Verify device reports Execution date: 6/18/2016
Description: Verify each device report Approved by: Supervisor andgroup

members
Pre-conditions:
1. User (Admin, Contractor, Operator) must be logged in
2. Dashboard should be in working
Basic flow:

Result Result

to be able to navigated to
dashboard see dashboard
dashboard
Click on User should User is Pass

device be able to navigated to
2 report NILL see device device report
from Main report page page
navigation

Select
required
device Selected device from Device Device Pass
from dropdown should be selected
3 selected successfully
dropdown
4 Click on Selected device from Report of Report of Pass

View dropdown selected selected
Report device device is
button should be displayed
shown successfully
Alternate flow 1 (Registered device with no logs)

When device has registered but no logs are maintained.

Result Result

to be able to see navigated to
dashboard dashboard dashboard
Click on NILL User should User is

device be able to see navigated to
2 report device report device report Pass
from page page
Main
navigation
Select Selected device from Device Device Pass

device dropdown should be selected
3 with no selected successfully
logs sent

Click on Report Report is not

Sign In should not be shown with
4 button Selected device from shown with message No Pass
dropdown message Data Found
Post-conditions:
1. Data is fetched from database for displaying report
2. Report displayed with specific information
Table 5-8: Test Case Verify Device Reports
5.3.9 Verify Devices View

In this test case we will verify each device views.

Test Case ID: TC_V_DEV_09 Design: Saif-ur-Rehman
Module: Device Management Executed by: Saif-ur-Rehman
Test Title: Verify devices view Execution date: 6/18/2016
Description: Verify that all registered devices Approved by: Supervisor andgroup
are available to display members
Pre-conditions:
1. User (Admin or Contractor or Operator should be signed in)
2. Dashboard should be in working condition
3. Working internet connection
Basic flow:

Result Result
1 Navigate to NILL User see User is Pass

dashboard dashboard navigated to
dashboard
Click on User should View

view be able to devices page
2 devices NILL see view with all
from Main devices page registered

navigation with register devices in a Pass

devices table is
Alternate flow 1 (No operator)

In this scenario we will discuss the case when device has no operator registered.

Result Result

dashboard be able to see navigated to
dashboard dashboard
View devices
page with all
Click on NILL User should registered
view be able to see devices in a Pass
2 devices empty space table is
from Main at “operated displayed
navigation by” if device with empty
has no space if
operator device has no
operator
Post-conditions:
1. Specific data is fetched from database for displaying devices (Contractors and
Operators can view their devices only not all
2. Devices displayed in table with specific information
Table 5-9: Test Case Verify Devices View
5.3.10 Verify Accounts View

In this test case we will verify each account view.

Test Case ID: TC_V_ACC_10 Design: Saif-ur-Rehman
Module: Accounts Management Executed by: Saif-ur-Rehman

Test Title: Verify accounts view Execution date: 6/18/2016
Description: Verify that all registered Approved by: Supervisor andgroup

contractors and operators are available members
Pre-conditions:
1. Admin should be signed in
2. Dashboard should be in working condition
3. Working internet connection
Basic flow:

Result Result

dashboard be able to navigated to
see dashboard
dashboard
Click on NILL User should View users

view be able to page with all
accounts see view registered
2 from Main users page users in Pass
navigation with all form of a
registered table is
users in displayed
form of table
Alternate flow 1 (No operator or contractor)

In this test case scenario is being discuss when no operator or contractor is found.

Result Result

dashboard be able to see navigated to
dashboard dashboard

Click on User should View empty

view be able to see page with
2 accounts NILL empty page message “No Pass
from Main with message Data
navigation “No Data Found”
Found”
Post-conditions:
1. Specific data is fetched from database for displaying accounts (Only admin can view)
2. Accounts displayed in table with specific information
Table 5-10: Test Case Verify Accounts
5.4 Discussion on results

By performing all these tests we came to know that accuracy also depends on number of
sensors so if we increase number of sensors accuracy also increases, so instead of using one
sensor we will use two or three sensors than it perform good in both cases, stable and layered.
With the help of test cases we can assure quality that what is the stability of the system and
what is the accuracy and performance of system. System can be improved more by some
efforts of adding more accurate sensors and more reliable hardware.

6.1 Assessment
Assessment of the framework is really assessment of execution, from engineers and clients
perspective, complex programming frameworks. The part without bounds conformity to be
made is additionally said.
6.2 Limitations and features

Here we will discuss about the limitations and features of system. We will also discuss about
future works.
6.2.1 Limitations
The limitations or drawbacks of the system are:
 Sensors can cause problem in highly layered level of fuel for measuring accurate
distance so replication of sensors is necessary
 This application may not be able to keep a track or record of any of the user who is
using that for how much time or period was the user online and using the system,
when he last time logged to the system
 Sensors may cause problem if fuel level hits the sensors because they are not much
reliable to resists fuel so technical problems in sensors can occur
 GSM may cause problem as soon as voltage level decreased from 4.7 volts. So
constant voltage is required
6.2.2 Features
The features of the system are:
 This application has an attractive and user friendly user interface.
 Its interface is responsive i.e. adjusted and set according to the resolution and size of
the screen
 Many number of users can use this application at a time
 Separate operator, admin and contractor console
 Report generation
 Average consumption and other calculations
 Alerts and notifications
6.3 Conclusion
As I have discussed all aspects of the system in the document above. All functionalities,
features, and limitations are discussed in detail. I conclude that this system is good for the
fuel monitoring at different places like telecommunication companies. These companies use
large generators under the towers, and it cause difficulties and extra efforts to maintain the
required level of fuel. There is also a big problem of fuel theft which is the main target of our
system.
If it is marketed in the proper way and we take care of its maintenance and future works and
we update it with time, this system has full capability to survive in market and save the time,
efforts and cost of people. Also it can play a good role in avoiding fuel theft. Some
limitations are still there in system at hardware side but these can be controlled and removed
with time and we can make the system more reliable.
6.4 Future enhancements

The future enhancement of the system is:
1. In the future we will modify this application to allow the application to run on other
operating systems
2. We will extend the role of the application and add some extra features to the website.
3. Sensors that will not be failed even fuel touches them
4. Highly accurate sensors
5. More refine reports and more refine hardware
6. System will be able to handle more large reservoirs
7. System will produce crystal reports (more refined mechanism of reporting)
8. Extension of system to be used in automobiles and tankers also
9. Future works also contains handling of much irregular fuel and tank shape
10. More realistic and simple user interface

7.1 Device installation

1. Sensor/Sensors should be place on tank
2. Power up the battery
3. Turn on the device
4. Device lights will show the status of device
5. Arduino light will show that it is now turned on
7.2 Light status

Arduino light status shows the battery power by bright and dull glow.
 If light is glowing bright, it means battery is charged
 If light is glowing dull, it means battery is near to end
Figure 7-1: Arduino light
7.3 SIM installation

Install the SIM incase it is not already installed in SIM jack placed on GSM.
Figure 7-2: SIM jack

7.4 Turn on GSM

1. After SIM installation turn on GSM
2. If LCD light is on its mean GSM is on
Figure 7-3: GSM light status
7.4.1 GSM light status

After SIM installation turn on GSM, lights placed on GSM will behave in different ways.
 Red light is used to check that whether GSM is turned on

 If GSM is turned on Red light will blink continuously
 Yellow light will show the status of network
 If network is available, yellow light will blink wih difference of 3 to 4 seconds
 If network is not available, yellow light will blink in every second
7.5 Open the website

Open the website through the link below:
http://fms.multi-engr-gp.com

Figure 7-4: Home page
7.6 Registration
User should first of all register himself or herself and select their type.
Figure 7-5: Registration
7.7 Sign In
After this user can sign in by the credentials he used to sign up.

Figure 7-6: SignIn
7.8 View dashboard

After this user can view all logs readings, alerts, notification of their registered device etc.
If user will be admin he can:
 Log in to enter is system
 View alerts of critical and informative situations
 View log readings of fuel level
 Generate device reports
 Edit profile
 Update any device
 View any device
 Register another admin
 View accounts of any stakeholder
 Verify requested contractors
 Generate fuel added report
 Generate fuel consumption report
 Register new device
 View Genset device on map(reporting devices, on reporting devices, reporting in last
15 minutes)
 Log off to quit safely
If user will be contractor he can:

 Log in to enter in the system
 Update assigned Device
 View Log readings of only assigned devices
 Device Reports of only assigned devices
 Change password
 View assigned devices
 Edit profile
 View alerts of assigned devices only
 Generate fuel added reports
 View concerned operator
 Verify requested operator
 Register new device
 Assign device to operator
 Generate fuel consumption graph
 View Genset device on map(reporting devices, non-reporting devices, reporting in
last 15 minutes)
If user will be operator he can

 Log in to enter in the system
 Edit profile
 Update device
 Change password
 View log readings of assigned devices
 View assigned devices
 View genset device on map(reporting devices, non-reporting devices, reporting in last
15 minutes)
Following screenshots are provided for the better understanding of main features of the
system.

7.9 Main features
Figure 7-7: Dashboard
It is contractor console with all features provided to contractor at left side in side bar. Main
map is showing device locations and status of devices. Three boxes above the map are
showing the information about the logs, devices and members. Icons at top left corner are
shoeing alerts and notifications.
Same dashboard is designed for the admin and operator with different features and
permissions.

Figure 7-8:Device registration
It is device registration panel for registration of new device when it is deployed in real
environment. After registration system will perform all functionalities on new device
implemented for device management.
Figure 7-9: Fuel graph

Figure 7-10: Logs graph
These are the graphs for visualizing logs readings and fuel consumption for better
understanding and analysis performed by the user. These graphs are generated on real data
and gives the picture of real analysis of fuel monitoring.
Figure 7-11: Device report

These are the device reports showing the customized and summarized information about
device. User will just select the device and click on generate report to show the report of that
specific device.
Figure 7-12: Logs
These are the actual readings showing the actual level of fuel in the Genset where device is
deployed. System perform every functionality on the basis of data i.e. reports, graphs, etc. are
generated on the basis of this data.

8.1 References
http://www.guardmagic.com/01-engl/11e-solution/21e-fuelstorage-tank/22-04-tank-
monitoring.htm
http://imgusr.tradekey.com/p-8567263-20140126074347/fuel-monitoring-system.jpg
http://www.fueltek.co.uk/news/
http://www.guardmagic.com/01-engl/01e-shortly/1-fuel-monitoring/0e-fuel.htm
http://www.guardmagic.com/01-engl/11e-solution/aboutproducts.htm
http://www.alltrac.com.pk/generator-monitoring/
http://aakashtechsupportdocs.readthedocs.org/en/latest/nonfunc.html
https://www.sparkfun.com/products/9533
https://www.elprocus.com/gsm-architecture-features-working/
http://ecomputernotes.com/software-engineering/principles-of-software-design-and-concepts
http://creately.com/blog/diagrams/uml-diagram-types-examples/

9.1 Appendix
Terms Definition
Server Server means web server application that will run on PC side.
FMS Fuel monitoring System.
GSM Global system for mobile communication is a standard developed by

European Telecommunications standards Institute to describe the
protocols of 2nd generation.
RTC Real Time Clock (RTC) Module is the cheapest and excellent way to get
the time with every reading sent from device to server.
HC SR04 Ultrasonic module transducer sensor. This sensor is based on the

concept of sonar waves production to determine distance.
MVC Model, View and Control.


Real Time Fuel Monitoring System: Supervised by

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Real Time Fuel Monitoring System: Supervised by

Hochgeladen von

Copyright:

Verfügbare Formate

Real Time Fuel Monitoring System

1. External Examiner __________________________________

2. Internal Examiner ___________________________________

Department of Computer Science,

COMSATS Institute of Information Technology, Abbottabad.

Project Title Real time fuel monitoring system

Organization Comsats Institute of Information Technology Abbottabad

Under taken by Umer Ali, Saif-ul-rehman, Javeria Mughal

Starting Month September 2015

Ending Month May 2016

Software Visual Studio 2013 and Arduino 1.0.6

Operating System Windows 8

End Product Real time fuel monitoring system

CHAPTER TWO: This chapter includes non-functional and functional requirements of

Table 1-1: Financial Feasibility .............................................................................................................. 4

Figure 3-1: Arduino Mega ...................................................................................................................... 9

Department of computer Science, CIIT Abbottabad 1

1.4 Statement of the problem

1.5 System importance

1.6 Process prototypical

Department of computer Science, CIIT Abbottabad 2

1.6.6 Development, delivery and feedback

1.7 Feasibility report

1.7.1 Technical feasibility

1.7.1.1 Arduino Mega and Arduino IDE

1.7.1.2 Ultrasonic sensor

1.7.1.4 C# language using MVC architecture

1.7.1.5 Web server

1.7.1.6 Bootstrap and CSS

1.7.1.7 RTC time module

1.7.1.8 GSM module

1.7.2 Financial feasibility

Resource name Price Source

Arduino Mega with GSM Rs. 8000 College road, Rawalpindi

Ultrasonic module Rs. 1000 College road, Rawalpindi

Long life rechargeable Rs. 1000 College road, Rawalpindi

M to M and M to F jumpers Rs. 300 College road, Rawalpindi

Visual Studio Free Dreamspark by Comsats

Table 1-1: Financial Feasibility

1.7.3 Resource feasibility

1.7.3.2 Visual studio

Department of computer Science, CIIT Abbottabad 4

1.7.3.3 XAMPP server and domain

1.7.4 Operational feasibility

 Simulators and server will run in windows operating system

Department of computer Science, CIIT Abbottabad 5

2.1.1 Objective of project

As mentioned, he motivation behind our venture is to delineate a model FMS in

2.1.2 Current system

2.1.3 Proposed system

2.2 Requirements analysis

2.2.2 External interface

2.3 Performance requirements

Department of computer Science, CIIT Abbottabad 7

2.4 Security requirements

2.5 Quality requirements

2.6 Non-Functional requirements

2.6.6 User profiling and role assignment

Department of computer Science, CIIT Abbottabad 8

3.1 Hardware parts description

3.1.1 Arduino Mega 2560

Figure 3-1: Arduino Mega