Abstract

The abstract is a very brief summary of the report’s contents. It should be about half a page
long. Somebody unfamiliar with your project should have a good idea of what it’s about having
read the abstract alone and will know whether it will be of interest to them.

1
 Acknowledgments

You may put your acknowledgments here.

2
Contents

1 Introduction 7
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Organization of the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Literature Review 10
2.1 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Inserting figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Requirements Specifications 12
3.1 Non-functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Product requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2 Organisational requirements . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.3 External requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1 Category 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.2 Category 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Project Design 16
4.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Design Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1 Module 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.2 Module 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.3 Module 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3
5 Implementation 19
5.1 Development Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.1 <STAGE 1> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.2 <STAGE 2> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.3 <STAGE 3> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.4 System Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Key Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1 <Component 1> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.2 <Component 2> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.1 <UI Component 1> . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.2 <UI Component 2> . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6 Evaluation 22
6.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2 Function Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2.1 Testing Requirements <A, B, C> . . . . . . . . . . . . . . . . . . . . 22
6.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.3.1 <Comparison of . . . > . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.3.2 < ...> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7 Conclusion and Future Work 24

4
List of Figures

2.1 An Example of inserting Figure into your project . . . . . . . . . . . . . . . . 11

3.1 Functional Requirements Numbering . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 Prototype application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Overview of the architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.1 Example of a user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.1 I love Latex, reprinted from [1]. . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.2 Incorporating bibtex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5
List of Tables

3.1 Product Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Organizational Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 External Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Functional Requirements Category 1 . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Functional Requirements Category 2 . . . . . . . . . . . . . . . . . . . . . . . 15

6.1 Testing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6
Chapter 1

Introduction

This is one of the most important components of the report. It should begin with a clear
statement of what the project is about so that the nature and scope of the project can be un-
derstood by a lay reader. It should summarize everything you set out to achieve, provide a
clear summary of the project’s background, relevance and main contributions. The introduction
should set the scene for the project and should provide the reader with a summary of the key
things to look out for in the remainder of the report.

• The introduction itself should be largely non-technical.

• It is sometimes useful to state the main objectives of the project as part of the introduction.

• Concentrate on the big issues, e.g. the main questions (scientific or otherwise) that the
project sets out to answer.

1.1 Motivation
What motivated you to carry out this research work or build this project?

1.2 Objective
Many industrial processes are now dependent on automatic machinery. The transition from
manual systems to automatic systems was necessary to optimize the rate and capacity of pro-
duction. To control an industrial process, a special microprocessor based controller called the
programmable logic controller (PLC) is used. There are many advantages of using PLCs in
process control. These controllers are built to withstand the harsh environment of industry floor

7
(i.e. protected against dust, moisture, hot and cold temperatures etc.), so these do not need spe-
cial housing or protection. The PLCs are also built in a way so that the electronic circuitry of
the controllers is not affected by moderate amount of noise.
A more attractive feature which made PLCs so popular is that, the same PLC can be re-
programmed (using only software) to perform another task or control another process. Before
the introduction of PLCs, electrical relays were used to automate processes, and the relays
needed to be physically re-wired if these were intended to control another process. PLCs can
be programmed many times to do different tasks. Besides in industries, PLCs are also used
in building management systems (BMS), amusement parks, mills, water and waste treatment
plants etc. The PLCs read the input states of switches, sensors etc. and can drive motors, relays,
solenoids etc.
One of the many uses of PLCs in industries is in assembly lines involving packaging. Espe-
cially in pharmaceuticals, beverage industries, mineral water packaging plants etc., it is required
to fill-up a bottle with a certain amount of liquid. In these systems, empty bottles are put on a
conveyor belt which brings these to the filling station. At the station, the bottles are automati-
cally filled-up and then moved along the conveyor for further stages to perform other tasks such
as cap fitting or packaging etc.

1.3 Methodology
s part of our undergraduate project, we have developed a hardware model of a liquid filling
system, and the process is controlled using a PLC. It is an automatic process where empty
bottles are first placed on the conveyor belt. As an empty bottle is brought to the filling station,
the belt stops to let the bottle fill-up with a fixed amount of liquid. The liquid is kept at an
overhead tank near the filling station. After the bottle is filled-up, the belt starts again to move
away the filled-up bottle and to bring another empty bottle to the filling station.
The whole process consists of three tasks:
bottles one after another with the desired level of liquid. refilling the overhead tank to
continue smooth operation. of the liquid flow from the reservoir to overhead tank.

1.4 Organization of the Report

Chapter 2 covers the background material and literature reviewed to understand the intrica-
cies of . . .
Chapter 3 then specifies the lists of extracted requirements for the project development.

8
These requirements are categorized into several groups on the basis of their functionality. Re-
quirements are also prioritized to explain their importance and enable the user to sift them
according to his needs.
Chapter 4 describes the design formulated for the successful execution of the suggested
techniques. The design explains the architecture of . . . In the end, this chapter gives detailed
information for each module, explaining their critical methods and properties required for suc-
cessful execution.
Chapter 5 explains the approach taken and issues confronted while implementing the in-
tended goals. It explains the temporal stages experienced while implementing the design, and
also the key functions that needs special consideration from the viewpoint of implementation.
In the end, the author has explained the user-interface of the implemented program, and the
details of each command how it is handled and used.
The testing and evaluation of the developed hardware and software is discussed in Chapter
6. It explains the testing procedure followed and then the various types of tests executed on the
application to confirm its proper functioning and meeting the acceptance criteria. The results of
these tests are summarized in the end, with possible results concluded from these tests [2].
In the end, we briefly present the conclusions from this project and also the possible future
improvements and additions for better design/implementation and investigation of ¡PROJECT
NAME¿.

9
Chapter 2

Literature Review

2.1 Literature Review

The background section of the report should set the project into context by relating it to
existing published work which you read at the start of the project when your approach and
methods were being considered. There are usually many ways of solving a given problem, and
you shouldn’t just pick one at random. Describe and evaluate as many alternative approaches
as possible.
The background section can be included as part of the introduction but is usually better as
a separate chapter, especially if the project involved significant amount of prior research. The
published work may be in the form of research papers, articles, text books, technical manuals,
or even existing software or hardware of which you have had hands-on experience.

2.1.1 Inserting figures

Unlike MS Word, you cannot just import a figure into your document. Instead, there is a
way to incorporate the figures. An example is given below, figure 2.1.
WARNING: Avoid plagiarism If you take another person’s work as your own and do not
cite your sources of information you are being dishonest; in other words you are cheating. When
referring to other pieces of work, cite the sources where they are referred to or used, rather than
just listing them at the end.

10
LibraryManagement
Observer
Subject * * Observer
add(Observer) observers start(Subject)
remove(Observer) stop(Subject)
notify() update(Subject)
getState()

Library
Customer
0..1 *
BookCopy * 1 Location
name id roomNumber
address available shelfNumber
getName() getId() addBook(BookCopy)
setName() setId() removeBook(BookCopy)
getAddress() getAvailability()
borrow(Customer) BookManager
setAddress()
return(Customer) addBook(Book)
getState() removeBook(Book)
* searchBook(Book)
1 buyBook(BookCopy)
Book discardBook(BookCopy)
title 1..* * update(Subject)
ISBN
getTitle() Author
getISBN() name
addCopy(BookCopy) 1..* 1..* getName()
removeCopy(BookCopy) setName()

Figure 2.1: An Example of inserting Figure into your project

11
Chapter 3

Requirements Specifications

The Non-functional and Functional Requirements are categorized into various groups based
on relations and objective of requirements. Each requirement is assigned an ID which is num-
bered as shown in figure 3.1.
The Requirement code consists of three parts separated by minus sign i.e. -, the three
parts are explained below: Requirement Type: This is a two letter code explaining the type
of requirement. It contains one of the following two values: FR - Functional Requirement NR -
Non-Functional Requirement Group Index: This is a serial number assigned to the group with
unique value. This is placed in the middle of Requirement ID. Requirement Index: This is a
serial number assigned to the requirement, and has unique value inside its own group. It is
placed at the end of Requirement ID.
Moreover, all the requirements are given priority scale from 1 to 3. Requirements with pri-
ority value 1 must be implemented with full functionality. Priority value 2 is intended to be
implemented with a secondary importance. However, priority value 3 is applied to the require-
ments that maybe skipped in favour of completing the project in time.

Figure 3.1: Functional Requirements Numbering

12
 Table 3.1: Product Requirements

ID Priority Details
NR-01-001 1 Platform:
NR-01-002 1 Language:
NR-01-003 1 Compiler:
NR-01-004 1 Usability:
NR-01-005 2 Portability:
NR-01-006 2 Space:
NR-01-007 1 Machine:

Table 3.2: Organizational Requirements

ID Priority Details
NR-02-001 1 Delivery: The system development process and deliverable
documents shall conform to the process and deliverables
defined in the document CIIT-CE-02H Degree Project Stu-
dents Handbook.
NR-02-002 1 Standard: The standard of the final product shall be of un-
dergraduate level or above.

3.1 Non-functional Requirements

3.1.1 Product requirements

Table 3.1 presents the product requirements with their priority . . .

3.1.2 Organisational requirements

The organizational requirements are as tabulated in Table 3.2 . . .

3.1.3 External requirements

The external requirements are as tabulated in Table 3.3 . . .

13
 Table 3.3: External Requirements

ID Priority Details
NR-02-001 3 Security: This is a degree project having no strict security
requirements.
NR-02-002 1 Ethical: The application will not use any type of un-ethical
electronic material while project development and execu-
tion.
NR-02-003 1 Legislative: The application shall not use any private or
confidential data, or network information that may infringe
copyrights and/or confidentiality of any personnel not di-
rectly involved in this product.
NR-02-004 3 Safety: The application shall not use any private or confi-
dential data, or network information that may infringe copy-
rights and/or confidentiality of any personnel not directly
involved in this product.

3.2 Functional Requirements

3.2.1 Category 1
The application is intended to . . . as given in Table 3.4 . . .

3.2.2 Category 2
The application is intended to generate . . . Following requirements should be met under
given priorities in Table 3.5 . . .

14
 Table 3.4: Functional Requirements Category 1

ID Priority Details
NR-01-001
NR-01-002
NR-01-003
NR-01-004
NR-01-005
NR-01-006

Table 3.5: Functional Requirements Category 2

ID Priority Details
NR-01-001
NR-01-002
NR-01-003
NR-01-004
NR-01-005
NR-01-006

15
Chapter 4

Project Design

4.1 Methodology
A very basic prototype was developed . . .
The prototype was helpful in . . . shown in figure 4.1.

4.2 Architecture Overview

The design of the intended product is explained graphically with the help of a diagram
shown in figure 4.2. The diagram explains the overall interactions of the modules and their
placements.

4.3 Design Description

Following are the modules constituting the product to be developed. Please note that we are
documenting only the salient properties and methods of each module to keep the description
simple and more readable.

4.3.1 Module 1
Description: This module is the . . .
Details: Add details here . . .

16
 Figure 4.1: Prototype application

Figure 4.2: Overview of the architecture

17
4.3.2 Module 2
Description: This module is the . . .
Details: Add details here . . .

4.3.3 Module 3
Description: This module is the . . .
Details: Add details here . . .

18
Chapter 5

Implementation

We have implemented the suggested design using . . .

5.1 Development Stages

Following were the discrete phases we have experienced incrementally to realize our product
in the given time:

5.1.1 <STAGE 1>

We started the project by creating a . . .

5.1.2 <STAGE 2>

The next step followed was to . . .

5.1.3 <STAGE 3>

As we already described, some of the modules were critically depending on other modules
and could not be unit-tested without communicating to them properly. Hence, we needed to
write down . . .

5.1.4 System Integration

The next step followed was to . . .

19
5.2 Key Components
Following are the key components that need special attention from developers viewpoint.
We are not intending to present the code in this discussion, rather the hardware and software
components are explained using state-charts and pseudo-code, and are critically discussed. The
importance of key components with their implementation is elaborated. Moreover, we explain
the approaches taken, along with their advantages and/or limitations.

5.2.1 <Component 1>

We have implemented . . .

5.2.2 <Component 2>

...

5.3 User Interface

User Interface is an extremely important consideration for any project that requires human-
machine interaction. However, this project doesnt require human machine interaction and there-
fore the product runs solely in the background without any user input. Besides this fact, we have
introduced an option to display the current status, orientation, and power production from the
requested solar panels. The user interface is

5.3.1 <UI Component 1>

...
Figure 5.1 presents an example of a user interface.

5.3.2 <UI Component 2>

...

20
Figure 5.1: Example of a user interface

21
Chapter 6

Evaluation

We have focussed on thorough testing through-out the design and implementation phase.
While testing the . . .

6.1 Unit Testing

Each module in the application was tested while being developed to confirm its adherence
to the related requirements. This testing was . . .

6.2 Function Testing

After integrating the system, testing was done on a . . .

6.2.1 Testing Requirements <A, B, C>

Table 6.1 . . .

6.3 Results
After thorough testing of the system, we proceeded for investigation of our implemented
techniques for . . .

6.3.1 <Comparison of . . . >

We have compared the . . .

22
 Table 6.1: Testing Requirements

Requirement CYCLE 1 CYCLE 2 Final Details (if any)

tested status
FR-01-001 OK OK OK
FR-01-002 OK OK OK
FR-01-003 Failed OK OK
FR-01-004 OK OK OK Test for . . .
Failed OK OK Test for . . .
FR-01-005 OK OK OK
FR-01-006 OK OK OK
FR-01-007 OK OK OK
Failed Failed Failed Test for . . .
This part of requirement is
found invalid
Failed OK OK Test for . . .

6.3.2 < ...>

23
Chapter 7

Conclusion and Future Work

In this project, we have investigated and developed . . .

There could be several improvements possible . . . Some of the ideas for future development
are mentioned below: Idea 1
...
Idea 2
...
Idea 3
...

24
Bibliography

[1] W. T. Yeung, “My first latex document,” 2012.

[2] R. Sherlock, P. Mooney, A. C. Winstanley, and J. Husdal, “Shortest path computation: a

comparative analysis,” 2002.

25
Appendix A: HDL or C Source Code

It is not mandatory to include your source code in the report, however, if it is essential, or
desired by your supervisor(s), then use this section for your code.

26
Appendix B: Hardware Schematics

It is also not bad to include your hardware schematics within your chapters, but the schemat-
ics you have adopted from the internet or other sources, especially those owned by someone
else, may be put here.

27
Appendix C: List of Components

This is optional − in case you have a long list of components, you may use this space instead
of describing them in your text.

28
Appendix D: Project Timeline

To be provided by the supervisor on MS-Word template.

29
Appendix E: List of Abbreviations

It is a good practice to provide a list of abbreviations used within the report here for easy
referencing.

30
Appendix F: Tips for the Latex beginners.

Do not include this section in your FYP report! This is just for your help. Also note
that the FYP committee will continue to update this chapter as the problems/issues con-
tinue to come up. The supervisors are requested not to encourage their FYP students to
communicate their concerns regarding the latex template to the FYP committee on their
own. Instead, the supervisors should get in touch with the FYP committee themselves.

1. In order to get going with Latex and build your PDF, we recommend you to install WinEdt
(v 8.0 should be good enough) along with Miktex (v 2.9 works fine).

2. For this template, your source folder must contain two subfolders: 1) chapters and 2)
figures. We recommend you do not alter this setting, otherwise you will have to alter
the hyperlinks in each file individually, where a chapter or a figure is being referenced.
However, it is also a good practice to arrange your figures chapter wise. For example,
you may create a folder figures/ch1 for keeping all the figures referenced in chapter 1, a
chapter figures/ch2 for keeping the figures used in chapter 2, and so on.

3. The compiler, once you compile the project, automatically creates a few associated auxil-
iary files, which only increase size of the source folder. While emailing the source folders
to the FYP committee, or even in your personal use, it is recommended you delete those
redundant files. In this template, files with the following extensions are unnecessary:
.aux, .bbl, .lof, .lot, .out, .synctex, .bak, .toc, Text Document, and Performance Monitor
File. The only important files are FYP-template.tex, references.bib, FYP-template.pdf,
and the two folders chapters and figures.

4. The first compile on your system will take a long time before the pdf is generated. Be
patient!

5. It will take some effort to learn latex. For example incorporating figures, equation editing,
creating tables may get annoying at times. The FYP committee has tried its best to include
an example of each of these important elements in this template for guidance; yet there

31
 Figure 7.1: I love Latex, reprinted from [1].

may be issues that are not answered here. Please know that help is available in abundance
on internet. We encourage you to figure out a solution to your problem yourself, or
approach your project supervisor for guidance. The FYP committee should be your last
resort.

6. Here is an example of a simple equation 7.1

(p1 + p3 ) − (p2 + p4 )
P = (7.1)
p1 + p 2 + p3 + p4

7. Make sure you refer to each table, figure, and equation that you may have used, some-
where in the text. For example, figure 2.1 in chapter 2 presented . . . table 3.3 presented
the external requirements . . . , and equation 7.1 suggests . . . . You are advised not to use
abbreviations while referring to something like this, for example, fig., tab., ch., and eqn.
for figure, table, chapter, and equation respectively, are not allowed.

8. Should you find it essential to reprint a figure or a table from another source (not belong-
ing to you), you must provide a citation to the original source in the caption of the figure.
For example see figure 7.1.

9. Carefully observe the references.bib file. It is your bibliography. Should you want to cite
an article in your text, you need to do the following. Assume the article you want to cite
is My First Latex Document by WT Yeung published in the year 2012, you should search
this title on scholar.google.com, as shown in figure 7.2. Click the cite button followed by
BibTex. Copy the contents of the file that pops up, and paste them in the references.bib
file. You are advised to paste them in the alphabetical order of the authors’ names, so that
overlapping may be avoided.

32
Figure 7.2: Incorporating bibtex

33