Report_Monitoring & Control of Water Tank Filling System

I
Abstract
Technical Project Report
Prepared By:
HASSAN AKHTER
MUZAMMIL EJAZ NOOR
SARA FATIMA
TARIQ JAMIL
WASEEM AKHTER
HMI BASED MONITORING AND CONTROL
OF WATER TANK FILLING SYTEM
The purpose of the project is to design and develop an HMI based monitoring and
control of water tank filling system. The system consists of water pumps responsible to feed
water to the tank. Status of level alarm switches and field switches, decides the state of the
system. The field switch decides whether respective pump is available for operation or it is under
maintenance. The system has two modes of operation i.e. manual and auto where each mode
has its own constraints. A windows based HMI application is developed for display of system
status. The final stage (PLC implementation) is achieved through step by step development of
multiphase implementation.

II
Contents
ACKNOWLEDGEMENT .................................................................................................................................III
PROJECT OVERVIEW ....................................................................................................................................2
Description....................................................................................................................................................2
Conditions and Limitations ......................................................................................................................2
PROJECT DEVELOPMENT & IMPLEMENTATION ..................................................................................3
1. Control System Software Implementation (Software Simulation only)................................................6
1.a) Implementation using Logic Gates Only.........................................................................................6
1.b) Implementation using Microcontroller Interfacing with Logic Gates............................................7
2. Design and Development of Windows based HMI Application...........................................................11
3. Control System Hardware Implementation .........................................................................................16
3.a Implementation using Arduino.....................................................................................................16
3.b Implementation using Programmable Logic Controller (PLC)......................................................21
PROJECT SCOPE..........................................................................................................................................26

III
ACKNOWLEDGEMENT
We are extremely thankful to Mr. Khalid Chaudhry (Managing Director) for giving us the opportunity
to handle this project. We extend many thanks to the extremely cooperative staff who guided us throughout
the project development. They helped us a lot in performing all the activities and in gaining the practical
knowledge. They monitored all of our activities and gave us the best suggestions to accomplish the assigned
tasks in an effective manner.
Special thanks to the following technical personalities at UEC:
 Mr. Khalid Chaudhry Managing Director
 Mr. Irfan General Manager
 Mr. Jawad Deputy Manager
 Mr. Bilal Ahmad Senior Instrument Engineer
 Mr. Irfan Instrument and Control Engineer

1
EXCLUSIVE SUMMARY
Before the detailed description of the report, we would like to start with the summary of the work we
have done. The basic purpose of this summary is to give an idea about the contents and efforts made behind
the completion of the report.
This document mainly focuses on practical work performed during project development; however,
theory to some extent is also explained wherever it is considered to be necessary. Please refer to respective
manual or tutorial of the product for detailed description of any component used (e.g. software or hardware)
in the project.
We tried our best to explain functions of all the products used, however, these are not described in
detail considering conciseness of the report. Only functions required to perform implementation are briefly
described with sufficient information. This document gives description, hierarchically, how the project is
developed to achieve the final goal.

2
PROJECT OVERVIEW
Description
A complete system consists of pumps, level alarm switches, field switches and HMI for display of
system status and control. Human Machine Interface (HMI) is a hardware with facility to display the status of
all devices and operator interaction to manually send commands to the controller. The commands are based
on graphical interaction and operator is unaware what is going behind this. The system has two modes of
operation i.e. Manual and Auto. In Auto Mode, pumps run depending upon the priority scheme while rest of
them are on standby whereas, for Manual Mode, pumps can be operated through HMI. The state of level
alarm switches decides the state of the system to be held. Each pump has a dedicated field switch which
decides whether respective pump is available for operation or it is under maintenance.
Conditions and Limitations
The perfect operation of the system has certain conditions and limitations as below:
System Modes:
The system can be operated in Manual Mode or Auto Mode. In Manual Mode, the operator can
directly turn ON or turn OFF the respective pump from HMI while, in Auto Mode, the operator is unable to
change state of any pump, however, the operator can toggle the system mode. In Auto Mode, pumps are
subjected to the priority scheme i.e. maximum of two pumps will run at a time. Moreover, considering the
whole system is working properly and all devices retain their state, toggling from Auto to Manual mode should
not change the state of the pumps.
Pumps:
Pumps are responsible to feed water to the water tank. There are four pumps and running status of a
pump depends upon the system mode, status of level alarm switches and respective field switch.
Level Alarms Switches:
Level alarm switches contribute only in Auto Mode whereas system operation is independent of their
state in case of Manual Mode. There are two level alarm switches (High and Low). Pumps will start when low
level alarm switch is active i.e. water level reaches its lower limit in tank and pumps should feed water to the
tank. The pumps continue running until high level alarm switch becomes active, after that all pumps must stop
regardless of the state of other devices.
Field Switches:
Field switches contribute in both modes of the system. Each pump has a dedicated field switch. The
worker at site can turn ON or OFF the field switch to indicate that the pump is healthy and ready for operation
or not. If field switch is ON then respective pump will be available for operation. If field switch is OFF then
pump is considered to be under maintenance and it will be unable to run unless its field switch is turned ON.
HMI:
Manual control interaction facility (i.e. buttons etc.) is disabled when system is in Auto Mode,
however, operator can toggle system state. In Manual Mode, operator can start/stop pumps directly from the
control buttons on HMI.

3
PROJECT DEVELOPMENT & IMPLEMENTATION
Considering all constraints and functions discussed before, it is the point to describe the project in detail
with dedicated tags of all devices and logic schemes as below:
 There are four Pumps P1, P2, P3 and P4.
 There are four Field Switches FS1, FS2, FS3 and FS4 located at field site.
 There are two Level Alarm Switches labeled as Level Alarm Low (LAL) and Level Alarm High (LAH)
installed at water tank.
 The system has two modes of operation i.e. Auto and Manual abbreviated as A-M.
 There are four local switches LC1, LC2, LC3 and LC4. These are windows GUI based control switches
directly operated from HMI.
In case of Manual Mode, local control switches are enabled (operable) in HMI and pumps priority scheme
will be bypassed whereas LAL and LAH have no effect on the system. In this case, pumps are directly under
control of the operator while in case of Auto Mode, local switches are disabled for miss-operation from the
operator side and pumps are subjected to priority scheme. System Mode, LAL and LAH directly contribute to
affect the state of the system. Following figure shows overview of the scenario.
Fig - 01 Project Scheme Overview

4
Following is pumps priority scheme subjected to status of field switches. For field switches the logic
“1” represents the field switch is ON and the logic “0” represents the field switch is OFF. For pumps, the logic
“1” represents the pump will run and the logic “0” represents pump will not run.
Field Switches Pumps Control_RUN Status Validity
FS1 FS2 FS3 FS4 Pump1 Pump2 Pump3 Pump4
0 0 0 0 0 0 0 0
0 0 0 1 0 0 0 1
0 0 1 0 0 0 1 0
0 0 1 1 0 0 1 1
0 1 0 0 0 1 0 0
0 1 0 1 0 1 0 1
0 1 1 0 0 1 1 0
0 1 1 1 0 1 1 0
1 0 0 0 1 0 0 0
1 0 0 1 1 0 0 1
1 0 1 0 1 0 1 0
1 0 1 1 1 0 1 0
1 1 0 0 1 1 0 0
1 1 0 1 1 1 0 0
1 1 1 0 1 1 0 0
1 1 1 1 1 1 0 0
In case of Pump1 & Pump2, the logic output is directly dependent only upon status of respective Field
Switch. In case of Pump3 & Pump4 Boolean expression can be developed using k-map method. Moreover,
level alarm switches and system mode has direct relationship with the output of the respective pump because
they are independent of combination of the logics.
As Pump1 and Pump2 has direct relationship with their respective Field Switch while logics for Pump3
and Pum4 require k-map method for finding Boolean expression. Thus respective k-maps for Pump3 and
Pump4, along with Boolean expressions are as below:
P3
FS1, FS2
Boolean Expressions00 01 11 10
FS3,FS4
00
01
P1 = FS1
11 1 1 1
10 1 1 1
P2 = FS2
P4 00 01 11 10
FS3,FS4
00
P3 = FS3 (FS1’ + FS2’)
01 1 1 1
11 1
P4 = FS1’ FS4 (FS2’ + FS3’) + FS2’ FS3’ FS4
10

5
In the previous section of the document, the complete scenario of the project has been described in detail
and next part of the document will cover methods of its implementation. Project is not implemented at
advance professional level in a single step rather it is achieved through multiple phases i.e. from software level
implementation (simulation) to small hardware level implementation (microcontroller) and then professional
hardware level implementation (PLC).
The purpose of multiphase implementation is not only to explore different programming languages and
methods (e.g. using logic gates only, using C language and Function Block Diagram) but also help the beginners
to familiarize them with different methods for sole project implementation. Following methods are used:
1. Control System Software Implementation (Software Simulation only)
a. Implementation using Logic Gates Only
b. Implementation using Microcontroller Interfacing with Logic Gates
2. Design and Development of Windows based HMI application
3. Control System Hardware Implementation
a. Implementation using Arduino
b. Implementation using Programmable Logic Controller (PLC)
Following table enlist all methods chronologically along with reason of their importance:
Sr.
No.
Development
Stage
Method of
Implementation
Method’s Importance
1a
Software
Simulation
Using Logic Gates only Perfect development of logic is verified
1b
Using Microcontroller
Interfacing with Logic Gates
 Conversion of logic into C Program
 Duplex communication with HMI to
verify controller send/receive commands
2 HMI Design
Widows based Application
Development
Ensures perfect display update against
received commands using duplex
communication between HMI and controller
3a
Hardware
Implementation
Using Arduino Controller
Display on LCD:
Hardware Interfacing to verify proper
working of controller commands and duplex
communication with HMI. Commands for
display are written by the controller.
Control & Display on HMI:
Hardware Interfacing to verify proper
working of controller and HMI. Duplex
commands and responses are verified. The
controller just send the status string to HMI
and the HMI is responsible for display of
updated system status.
3b Using PLC
Professional level implementation with
standard Function Block Diagram (PLC
programming language).

6
1. Control System Software Implementation (Software Simulation only)
Commencement of the project starts from development of Boolean logic and expression described earlier.
At this stage, Boolean expressions are implemented on simulation level only. Following are two different
methods used for this purpose:
1.a)Implementation using Logic Gates Only
This step of implementation is necessary because it ensures 100 % perfection of the logic developed for
the system. At this phase, basic logic gates are used only and in case of inaccurate results, only developed
Boolean logic needs to be reviewed. In short, this step is basic building block of the project.
Components & Accessories:
Software: Proteus with built-in simulator.
Description:
Referred by water tank level (Fig-01) where LAL=0 & LAH=0, this condition is ignored based on the
following arguments:
 LAL=0 & LAH =0 or LAL=1 & LAH=1 conditions are invalid and they can’t be true in case level switches
are healthy and working properly, however, such cases may arrive due to fault in either of them.
 This is ignored because only basic logic gates are used and this condition can’t be solved without using
latching components like flip-flop. This situation will be considered in advance level implementation.
Boolean logic is implemented using basic logic gates only i.e. AND, OR and NOT gate. Logic States are used
to toggle the binary state of devices and Logic Probe are used for display of binary state of the final output i.e.
water pumps. A combination of gates is used for implementation of single Boolean expression. Following
figure is Proteus diagram of the whole scheme.
Fig-02 Circuit Diagram of Proteus Implementation using Logic Gates only
In the above figure, all logic states on the top are outputs of devices i.e. inputs to the system. The logic
state with the label “PC” is the system mode which is Auto for logic “1” and Manual for logic “0”. The logic

7
circuit is subdivided into two sections each dedicated to Manual and Auto mode of the system for each pump.
System Mode logic state has direct effect on these sections and decides which section should be activated.
Once a section is enabled, the other will be masked out independent of the logic state of all devices. Hence,
only one of the inputs to final OR gate is activated at a time keeping other ineffective and masked to zero logic
state. In short, the subjected output of final OR gate is the output of only one mode at a time.
Result:
During simulation, logic state of each input of the system was changed to observe its effect on the system.
The system output was successfully achieved according to pre-described requirements.
1.b) Implementation using Microcontroller Interfacing with Logic Gates
This step of implementation is required to ensure perfect duplex data transmission between HMI and
Controller using RS232 protocol, keeping logic scheme unchanged as described in previous method. The health
of communication ports and cable connection are also verified. Logic status of certain part of logic scheme,
required by HMI, is converted into C program. HMI will be able to change state of the system through
communication with the controller.
Software: Proteus with built-in simulator; mikroC a micro controller programming software;
communication cable with DB9 cable connection.
Description:
At this stage, windows based application HMI is not developed, however, UART terminal of
microcontroller programming software “mikroC” is used to send and receive commands through RS232
protocol. Fig-03 shows GUI interface of UART terminal of mikroC. All we need is to establish a COM Port
connection, setting of parameters and send/receive data. Fig-04 show circuit diagram for simulation in Proteus
software.
Authority to change state of five inputs to the controller (4 for local controls and 1 for system mode) is
transferred to C Program while operation of rest of them is same as discussed in previous method. Specific
characters are sent through RS232 communication and the microcontroller takes predefined action after they
are received. These characters are sent through UART terminal in mikroC which is capable of sending and
receiving character/string using RS232. Whenever state of any device or system is changed microcontroller
update the status and send it to RS232 in form of string. The string consists of character ‘0’ & ‘1’ with limit of
15 characters and each character is dedicated to a specific status tag of the system. Position of each character
in the string is predefined.
For successful transmission of data between UART Terminal and Proteus, parameters of RS232 must match
on both sides. Following setting for RS232 parameters is used:
Baud Rate: 9600 bps Stop Bits: One Parity Bit: None Data Bits: 08
State of Level alarms and Field Switches can be changed using logic states while for state change of system
mode and local control, character a, b, c, d and e are sent to controller to toggle state of A-M, LC1, LC2, LC3
and LC4 respectively. Whenever microcontroller receives the character “s”, it sends updated status string to
RS232. Microcontroller scan state of all devices at inputs, in real-time and whenever state of either of them is
changed the controller updates the status array and send it to RS232.

8
Fig-03 GUI Interface of mikroC UART Terminal
The microcontroller C-program is subdivided into four sections as below:
Section - I:
Initialization of parameters, status array, controller inputs, outputs and UART RS232 port.
Section - II:
This section of program is dedicated to HMI. The controller scans UART periodically and upon receiving
character, it toggles the state of respective parameter, updates status array and sends the updated
status array on UART terminal to HMI.
Section - III:
This is for controller section scanning of inputs and outputs. All inputs & outputs are scanned and
status array is updated according to the state of respective input/output.
Section - IV:
The controller checks whether certain input or output has changed its state or not. In case of change
in state, respective parameters is updated accordingly and updated status array is sent to HMI through
UART terminal RS232.

9
Following are status array indices and each represents specific state of system as described below:
Array
Index
Status Tag Logic 0 Logic 1
0 System Mode (AM) Manual Mode enabled Auto Mode enabled
1 Level alarm Low (LAL)
Inactive (Water level is above lower
limit)
Active (Water level is equal to or
lower than lower limit)
2 Level alarm High (LAH)
Inactive (Water level is below upper
limit)
Active (Water level is equal to or
above than upper limit)
3 Field Switch (FS1)
Pump1 - OFF (Unavailable and under
maintenance)
Pump1 - ON (Available for
operations)
maintenance)
operations)
maintenance)
operations)
Pump4 -OFF (Unavailable and under
maintenance)
operations)
7 Local Control (LC1)
Turns OFF Pump1 (Manual Mode
only)
Turns ON Pump1 (Manual Mode
only)
only)
only)
only)
only)
only)
only)
11 Pump1 Feedback (FP1) Pump1 is not running Pump1 is running
During simulation, character ‘a’ is sent to microcontroller using mikroC UART terminal. This toggles
system mode. Whenever system mode is changed to auto mode, pumps run according to priority scheme
considering effect of Field Switches. In case of manual mode, pumps are manually turned ON and OFF by
sending respective character. The contribution of all other devices is same as described in previous method.
Result:
During simulation, logic state of each input of the system was changed to observe its effect on the
system. The system output was successfully achieved according to pre-described requirements. Data
transmission was successful and system behaved to the commands as it was supposed to behave.

10
Fig - 04 Proteus Circuit Diagram using Microcontroller

11
2. Design and Development of Windows based HMI Application
After successful development of logic and C-program, designing of logic circuit, interfacing and
communication with microcontroller, it is feasible to build a windows based HMI application as per
requirements. This application is similar to other GUI applications which runs under environment of Windows
operating system developed by Microsoft Corporation. It is a Graphical User Interface (GUI) application
containing controls in form of push buttons and status in form of LED indicators and many more features. The
application is capable of receiving and sending commands through RS232 interface. Its high flexibility provides
protection against miss-operation by the operator by enabling and disabling certain properties of the GUI. The
operator is restricted to specific commands enabled by the application under specific conditions.
Software: Microsoft Visual Studio 2010
Description:
MS Visual Studio is an Integrated Development Environment (IDE) which is used to develop different types
of windows based applications from simple windows forms to web applications including databases. However,
scope of MS Visual Studio in HMI development is limited only to simple windows based application with little
assistance of databases. Following is overview of interface of MS Visual Studio when windows based
application project is created:
The overview is distributed into different labeled sections and each of them has its own particular
functions:
1. This is toolbox window containing various built in GUI controls. It facilitates drag and drop of controls
into the design window.
2. The Solution Explorer window contains all files related to the project created.
3. The Properties window contains the properties and events associated with the selected control in the
design window.

12
4. There are two windows represented by tag 4 and 5. Current view of the window displayed is Design
Mode. This mode of window provides GUI interaction. The developer can put GUI controls and
indicators etc. in this mode of window so that operator can interact with these controls. There is
program code behind this control hidden from the operator and visible only in developer mode.
5. This window contains the whole program code associated with the controls. The code can be
organized into a standard programming structure i.e. classes, functions and loops etc.
6. This is tray containing all the controls associated with the system. The operator don’t need to interact
with them. The developer only need them to keep the application stable and healthy. These controls
are serial port, background worker and timer etc.
7. Toolbar contains all same icons associated with a general windows based GUI application, e.g. copy,
paste, cut and save etc. MS Visual studio contains a few special toolbar icons linked to debugging
purposes.
A complete HMI GUI system is developed having the following functions and facilities for the operator:
1. After launching the HMI application, availability of serial COM Port is checked. The user is notified whether
a COM port is available for connection or not. If no port is found, the user is prompted to rescan for COM
Ports.
3. The user login form is displayed before final display of the HMI. This is necessary because in case of more
than one operators, all events and alarms acknowledgement are recorded against the logged in user. Each
user may have different access levels.
4. After login, the operator requires to connect HMI with the serial port so that data transmission can be
established. Available COM Ports are enlisted in the list box. HMI controls are enabled after COM Port
connection is set up.

13
The HMI will send character “s” just after COM Port connection is established. The controller sends
updated status string against that character. HMI decodes the status array and updates the display of all
indicators accordingly with color representation of Green as device is ON and Red as device is OFF. The default
color is black until no status update is received from the controller.
5. System Mode section contains a control button, indicator and a timer. System Mode button is enabled
and Timer start stop buttons are visible only when COM Port connection is established.
System mode can be toggled using button or the timer. After specific time period, the system mode
will be toggled automatically. This option is introduced to facilitate the operator to toggle system mode while
system mode needs to be toggled periodically or the operator is busy in other tasks.
Timer time is set before starting it. After setting time, the start timer button is enabled. As soon as
timer is started, the indicator starts blinking, the start button is disabled and stop button is enabled so that
the operator can stop the timer if it is required to do so. Stopping the timer doesn’t affect the system mode.
However, time set value needs to be reassigned every time before starting the timer.
6. The operator can control the pumps manually only when system is in Manual Mode. In Auto Mode, the
local control buttons are disabled to give security against operator interference with Auto Mode scheme.

14
7. This is indication section of the whole system. Status of all devices is represented by respective LEDs.
8. Main display contains mini active alarm window. Three most recent active alarms are displayed here. For
all active alarms, an active alarm window is dedicated for operator to acknowledge alarms.
9. Alarm history window contains all the alarms including active and acknowledged. Alarms history can be
deleted but this is only possible if logged in user is administrator. The delete Alarms button prompts for
selection of two dates. After confirmation, all the alarms between these two dates will be deleted and
they can never be recovered.

15
10. User account management option is visible only when administrator is logged in. The administrator has
privilege to manage accounts. He can add or delete accounts as many as required. Each added user ID is
considered by the alarm management system. All alarms acknowledged by certain user are indicated by
the category of “Acknowledged by”. The logged in user is responsible for consequences of all alarms and
their acknowledgement.

16
3. Control System Hardware Implementation
Software simulation ensured perfect development and working of logic, program, HMI and
communication. It means all the upcoming troubleshooting to achieve accurate and efficient working of
hardware, will be considered in hardware. Hardware implementation is achieved in two steps. The first
implementation is performed on Arduino microcontroller and then, in the second step implementation, a PLC
is used.
3.a Implementation using Arduino
Arduino implementation is further subdivided into two steps. In the first step, the controller’s inputs,
outputs and commands are verified using display on LCD. In the second step, it is interfaced with GUI HMI and
duplex transmission with HMI is verified as well.
Software: Arduino Compiler, HMI
Hardware: Arduino development board (Mega 2560), Graphical LCD LM12864DDY, RS232 cable with D9
connectors, breadboard, connection wires and USB (Type-A) to USB (Type-B) cable for Arduino interfacing with
programming device (say computer).
Description:
Arduino development board is good for embedded system developers because it is a complete system
of microcontroller interfaced with digital & analogue inputs and outputs, RS232 as well as LCD interfacing.
Program is burned through RS232 (USB Type-2) interfaced with programing device using USB (Type-A) to USB
(Type-B) cable. This type of interfacing provides plug and play facility to the programming device and program
can be transmitted/retrieved from the controller within few seconds. A dedicated Arduino compiler is used to
compile the program code. Following figure shows overview of the compiler.

17
Arduino compiler provides flexibility of adding header file of the graphical LCD, in its library. The
header file provides facility to read/write data from/to LCD with the help of predefined functions. These
functions are ease to the programmer. All it needs is just calling the function without handling the controller’s
pins selection and activation/deactivation. ClearScreen(), ReadData() and WriteData() are some of its main
functions. It would be very tedious to communicate with LCD, without using these functions.
The Arduino implementation is performed in two steps:
3.a.1 LCD Display:
In this step, the controller is in duplex transmission mode. The controller monitors all input and output
devices and update status array along with activation of outputs and then send the updated status for display
on the graphical LCD. The controller receives commands from mikro-C UART Terminal instead of HMI.
For LCD display, Arduino has somewhat different program code as compared to code in previous
methods whereas the logic and program distribution is same. The difference lies only in syntax of the code
because Arduino compiler do not follow compiling mechanism used by the compilers for PIC microcontrollers.
The distribution of the program code is similar to the previous methods with the addition of code for writing
data to the LCD.
The graphical LCD (LM12864DDY) has display size of 128x64 pixels and it provides a great flexibility of
different types of font and character sizes as well. The display is subdivided into two parts by half of the total
display area. The both or either of the sections can be activated for display at a time. The data is displayed on
graphical LCD referred by cursor coordinates. The cursor coordinates are used to put a character at a specific
location.

18
Following table shows connection pins of the LCD requires to be connected with the Arduino, along
with function of each pin:
Arduino
Pin #
LCD Pin #
LCD
Pin Label
LCD pin Function
5V 1 +5V +5 VDC supply voltage
GND 2 GND Electrical Ground
N/A 3 Contrast in Wiper of contrast pot for LCD contrast
22 4 D0
Data Pins with maximum of 8-bit data carrying capacity
23 5 D1
24 6 D2
25 7 D3
26 8 D4
27 9 D5
28 10 D6
29 11 D7
33 12 CSEL1 half of the LCD Displayst
Chip1 Select: Enables 1
34 13 CSEL2 Chip2 Select: Enables 2nd
half of the LCD Display
N/A 14 Reset Resets LCD display by supplying +5 VDC
35 15 R_W Toggles Read/Write mode of LCD
36 16 D_I Toggles Display RAM/Instruction (RS) mode of LCD data
37 17 EN Enable/Disable data read/write mode of LCD data
N/A 18 Contrast out Input pin to adjust contrast of LCD display
N/A 19 Backlight +5 Supply voltage to enable LCD backlight
GND 20 Backlight GND Ground terminal of LCD backlight
The main issue with display on LCD is bigger size of program code for writing data on LCD. This is
because each character is placed in LCD using coordinates. Moreover, before putting a character at specified
location, it is required to clear that area otherwise character may not look like as it should. The following figure
shows the system status is displayed on LCD.
Result:
transmission was successful and system behaved to the commands according to predefined requirements. A
valid display of system status was achieved in an artistic way.

19
3.a.2 HMI Display:
In this step, the controller is in duplex transmission mode. The controller monitors all input and output
devices and update status array along with activation of outputs and then it sends the updated status for
display on the graphical LCD. The controller receives commands from windows based application HMI and, in
return, the controller sends the updated status to the HMI through RS232. The HMI decodes the received
instructions and update the display of the system status.
The program code is same as in the previous method except that the code to write data on LCD is
excluded and data is sent on RS232 to the HMI instead. Following figure is the overall view of HMI
Result:
transmission was successful and system behaved to the commands according to predefined requirements. A
valid display of system status was achieved in an artistic way. All functions of HMI were tested, debugged,
verified and finalized.

20
Following is flow chart of program code for Arduino and Microcontroller excluding logic gates interfacing:

21
3.b Implementation using Programmable Logic Controller (PLC)
This is industrial and professional level of implementation of the project. A Programmable Logic Controller
is used as a central processing unit for processing instructions. A PLC is more rugged and robust to withstand
industrial environments with its own Operating System (OS) whereas a microcontroller lacks such features.
The working principle of PLC is similar to microcontroller. The main difference is that it has advance
architecture with built-in diagnostics and troubleshooting abilities. A PLC has a dedicated configuration
software according to the manufacturer’s choice. However, all PLCs have same basic working principle. The
main standard languages used in PLC programming are LAD (Ladder Logic), FBD (Function Block Diagram), STL
(Instruction List) and SCL (Structured Control Language).
Software: TIA Portal v11
PLC Hardware: Siemens PLC CPU 313-C2 DP with 16 Digital Inputs and 16 Digital Outputs.
Description:
TIA Portal v11 is one of the Siemens newly released PLC configuration software with capabilities of
diagnostics and troubleshooting. The software has integrated environment for PLC configuration as well as
HMI designing, online monitoring and runtime simulation. Online monitoring enables the engineer to monitor
status of all parameters and program block while PLC is in running condition. Simulation provides facilities to
debug the program pretending as PLC is running and processing the program. The engineer can change
parameters and variables to check their effect on the system output. Following is brief introduction to TIA
Portal v11 and Siemens PLC:
TIA Portal is a PLC configuration software developed to support PLC and HMI by Siemens. The software
has advance features within single environment. Following are its main feature:
 Uploading/Downloading programs through multiple communication protocols.
 Integrated user friendly environment for tags management and HMI designing with runtime facility.
 Easy to manage tags and their automatic update.
 Instance conversion from one to another programming language.
 Simulation for debugging purposes.
 Online monitoring for real time analysis of the process parameters.
 Advance features with trace functionality for easy diagnostics and troubleshooting.
 It provides facility of migration of projects created in other versions of the software e.g. SIMATIC
Manager STEP 7, TIA Portal v12 and v13.
The software has user friendly environment with task oriented steps to accomplish the project design. It
contains multiple views to illustrate how hardware components are linked to each other. It provides drag and
drop facility for tags management and many more features. An engineer can configure hardware, write a
program and design a HMI within single environment. Moreover, tags of HMI and PLC are linked in order to
reduce the numbers of data tags for a program, thus, improving program processing and performance.

22
Following is overview of Siemens TIA Portal v11
The above figure shows steps to accomplish the project in a user friendly environment. There are three
major steps to do so i.e. (1) Configure a Device (2) Write PLC Program (3) Configure HMI.
The third step is optional because the design engineer can use third party HMI software and hardware.
However, the scope of the project is limited to online simulation only and TIA Portal v11 provides this facility
through one of its main features i.e. Simulation for online monitoring. Following is description of each step:
1. Device Configuration
In this step, the required CPU and IO hardware is selected. Addresses for communication with PLC and the
addresses of tags associated with IO channels are configured and assigned to the respective IOs.

23
Under flexible environment of the software, we can arrange hardware graphically in the same manner
as we want arrangement of the original hardware thus this reduces time for commissioning. This is the critical
part of the configuration because if addresses are not feasible then there will be mismatch in tagging and
communication with the PLC and other hardware leading to no operation or malfunctioning of the system.
2. Writing a PLC Program
The main focus of the project is to write a PLC program. The program is written in Function Block Diagram
(FBD). Each software of a certain brand has its own rule for memory management. Moreover, a Siemens PLC
program manages all this in form of Memory Blocks and Operational Blocks. Each block has its own features
regarding memory management and ability to link data with other blocks. Following is brief description of
them:
There are three types of operational blocks and each block can have inputs and outputs for interfacing
with other blocks or parameters. Inside the block these Inputs and Outputs are linked with the tags and
memory locations, logically. The program code of the block behaves like a function in the C-Program with
hybrid access level from local to global:
 Organization Block: This block is a system block that contains functions regarding PLC Operating
System (OS), diagnostics and Troubleshooting. It is responsible for execution of the program. It allows
the program execution to respond to cyclic, time-based and interrupt-driven events.
 Function Block: It is a code block that stores its values permanently in a dedicated instance data block,
so that they remain available after the block has been executed. This is suitable for program code that
read and write values to permanent memory e.g. saving parameters like set-points, counting run hours
and many other features.
 Function: It is a code block without dedicated memory. No data is available after its execution. This
subroutine is suitable for program code that required temporary or no memory for manipulation e.g.
scanning of IOs, mathematical calculation and interlocking schemes etc.
There are two type of memory blocks. These blocks are similar to permanent memory locations for storing
and retrieving user data:
 Global Data Block: This data block contains memory areas accessible globally in the whole program
of the PLC. Functions can access these memory location for storing and retrieving values of parameters
used at multiple locations in the PLC program.
 Instance Data Block: An instance data block is assigned to every function block call that transfers
parameters. The actual parameters and the static data of the FB are saved in the instance DB. The
variables declared in the FB determine the structure of the instance data block. Instance means a
function block call. If, for example, a function block is called five times in the S7 user program, there
are five instances of this block.
In the scope of this project, no storage of permanent values is required so no function block (FB) is required
which means no instance data block (Instance DB) is required as well. Only tags, global data block (global DB)
and Function (FC) are required for the logic implementations.

24
Dedicated tags are created for PLC IOs. A FBD language based Function (FC1) is created. The logical
program in FC1 is similar to the logic of the program described in previous methods. FC1 is called in OB1 where
OB1 executes itself periodically. Following are some snapshots during certain steps of programming the PLC.
Fig- Overview of Tags management section

25
Fig- Overview of FBD program in FC1
Fig- Overview of PLC Simulation
Result:
During simulation, logic state of each input of the system was changed to observe its effect on the system.
The system output was successfully achieved according to pre-described requirements. Data transmission was
successful and system behaved to the commands according to predefined requirements. Display of system
status was updated perfectly. HMI Implementation is left as future scope of the project.

26
PROJECT SCOPE
The basic principle of the project is to control the outputs considering situation of its inputs. Moreover, it
is related to fluid management system which keeps the fluid level within normal limits by starting and stopping
the feeding pumps. Thus, this project can be implemented in chemical and food processing industries where
we encounter mostly with fluid filling system.
Despite industries, this project can also be implemented in building management system to fulfill the
requirements of water consumption. More advance features can be added with a little modification or
addition in the program e.g. calculation of run time and maintenance hours for each pump, consumption and
expenses of electrical energy consumed by the system and accumulated volume of the water consumed. This
all leads to the best management of energy and resources with high flexibility and reliability for the operators.

Report_Monitoring & Control of Water Tank Filling System

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Report_Monitoring & Control of Water Tank Filling System

Ähnlich wie Report_Monitoring & Control of Water Tank Filling System (20)

Report_Monitoring & Control of Water Tank Filling System