WRITE YOUR PROJECT TITLE HERE

STUDENT NAME 1STUDENT NAME 2STUDENT NAME 3

July 2006

Department of Electrical EngineeringCOMSATS INSTITUTE OF INFORMATION

TECHNOLOGYLAHORE – PAKISTAN

Font: Impact

Size: 24

Font: Times

Size: 16

Font: Arial

Size: 14

Submission Form for Final-Year

PROJECT REPORT

PROJECT ID NUMBER OF MEMBERS

TITLE

SUPERVISOR NAME TERNAL / EXTERNAL

MEMBER NAME REG. NO. EMAIL ADDRESS

CHECKLIST:Number of pages in this report

I/We have enclosed the soft-copy of this document along-with the codes and scripts created by myself/ourselves YES / NO

My/Our supervisor has attested the attached document YES / NO

I/We confirm to state that this project is free from any type of plagiarism and misuse of copyrighted material YES / NO

MEMBERS’ SIGNATURES

Supervisor’s Signature

Note 1: This paper must be signed by your supervisor

COMSATS Institute of Information Technology, Lahore Campus Department of Electrical Engineering

Note 2: The soft-copies of your project report, source codes, schematics, and executables should be delivered in a CD

ii

This work, entitled “Insert Project Title Here” has been approved for the

award of

Bachelors in Electrical Engineering

Date

External Examiner:

Head of Department:

Department of Electrical EngineeringCOMSATS INSTITUTE OF INFORMATION

TECHNOLOGYLAHORE – PAKISTAN

Declaration

“No portion of the work referred to in the dissertation has been submitted in support of an

application for another degree or qualification of this or any other university/institute or

other institution of learning”.

MEMBERS’ SIGNATURES

ii

Acknowledgements

Thanks to Almighty Allah for granting us strength, wisdom, perseverance and confidence to

carry out our studies during this project.

We are thankful to our parents who supported us both financially and morally during our

studies. Their affection and love granted us confidence to accomplish our task. We would also

like to thanks our friends who supported us through their valuable suggestion to improve our

work.

We would also like to thank our project supervisor Dr. Ali Nawaz Khan Assistant professor in

Electrical Engineering department CIIT Lahore for his guidance and encouragement to work

hard and smart. This dissertation would have not been possible with the guidance of our project

advisor who helped us to accomplish our task. During our project we found him very helpful

while discussing and sharing his valuable ideas. His technical and research related advice was

essential to the completion of this dissertation and has taught us innumerable lessons and

insights on the workings of academic research in general.

iii

Abstract

Wireless sensor network is an important technology that is being employed

for the observation of a variety of phenomena in the physical world. Video-

based sensor networks can provide multimedia application evolved towards

live video streaming and static images for surveillance and monitoring

purposes. In this project, our aim is to design multimedia network capable

of sending real time video and static images through LAN and WAN. One

of the methods is by using ArduCAM shield which has limited capacity of

real time video streaming. So, we made a design enhancement to Raspberry

Pi Module along with Raspberry Pi Camera. This framework is capable of

sending real-time video with less delay to a remote area on a Smartphone

android application. This architecture proposal addresses some challenges

over the network that is frame loss, information loss and interferences. As a

future work, we will make a design enhancement towards the

commercializing of the project.

iv

Table of contents1 INTRODUCTION...............................................................................................................................1

2 LITERATURE REVIEW..................................................................................................................3

3 REQUIREMENTS SPECIFICATION.............................................................................................4

3.1 NON-FUNCTIONAL REQUIREMENTS..............................................................................................4

3.1.1 Product requirements..............................................................................................................4

3.1.2 Organisational requirements...................................................................................................5

3.1.3 External requirements..............................................................................................................5

3.2 FUNCTIONAL REQUIREMENTS.......................................................................................................5

3.2.1 Category 1................................................................................................................................5

3.2.2 Category 2................................................................................................................................6

3.2.3 Category 3................................................................................................................................6

3.2.4 Category 4................................................................................................................................6

4 PROJECT DESIGN............................................................................................................................7

4.1 METHODOLOGY............................................................................................................................7

4.2 ARCHITECTURE OVERVIEW..........................................................................................................8

4.3 DESIGN DESCRIPTION...................................................................................................................8

4.3.1 Module 1..................................................................................................................................9

4.3.2 Module 2..................................................................................................................................9

4.3.3 Module 3..................................................................................................................................9

5 IMPLEMENTATION......................................................................................................................10

5.1 DEVELOPMENT STAGES..............................................................................................................10

5.1.1 <STAGE 1>...........................................................................................................................10

5.1.2 <STAGE 2>...........................................................................................................................10

5.1.3 <STAGE 3>...........................................................................................................................10

5.1.4 System Integration.................................................................................................................10

5.2 KEY COMPONENTS.....................................................................................................................10

5.2.1 <Component 1>.....................................................................................................................11

5.2.2 <Component 2>.....................................................................................................................11

5.3 USER INTERFACE........................................................................................................................11

5.3.1 <UI Component 1>...............................................................................................................11

5.3.2 <UI Component 2>...............................................................................................................11

v

6 EVALUATION.................................................................................................................................12

6.1 UNIT TESTING.............................................................................................................................12

6.2 FUNCTION TESTING....................................................................................................................12

6.2.1 Testing Requirements < A, B, C>..........................................................................................12

6.2.2 Testing Requirements < A, B, C>..........................................................................................12

6.3 RESULTS.....................................................................................................................................13

6.3.1 <Comparison of …>..............................................................................................................13

6.3.2 <…>......................................................................................................................................13

7 CONCLUSIONS & FUTURE WORK...........................................................................................14

REFERENCES..........................................................................................................................................15

APPENDIX A: HDL OR C SOURCE CODE.........................................................................................17

APPENDIX B: HARDWARE SCHEMATICS.......................................................................................18

APPENDIX C: LIST OF COMPONENTS.............................................................................................19

Appendix D: Project Timeline.....................................................................................................................20

vi

Table of FiguresFIGURE 2-1 AN EXAMPLE OF INSERTING FIGURE INTO YOUR PROJECT.........................................................3

FIGURE 3-1 FUNCTIONAL REQUIREMENTS NUMBERING................................................................................4

FIGURE 4-1 EXAMPLE FIGURE FOR PROTOTYPE APPLICATION......................................................................7

FIGURE 4-2 ARCHITECTURE OVERVIEW DIAGRAM........................................................................................8

Figure 5-1 Example Figure for User Interface.............................................................................................11

vii

1. IntroductionWireless sensor nodes are tiny and cheap devices that can communicate wirelessly either by

using network topology either by point to point or mesh topology. The geographical area in

which these sensor nodes are deployed is known as Wireless Sensor Network (WSN). These

sensor nodes have been used for wide range of applications e.g. video surveillance, monitoring,

person tacking and detection etc.

Video based wireless sensor networks have the ability to capture video at distributed nodes and

transmit it via wireless link to a centralized location, providing significant benefits in the form

of useful information to many sensor networking applications such as security or surveillance,

environmental monitoring, health-care monitoring etc. when compared with wired camera

networks, wireless video sensor network has many advantages e.g. cost reduction for network

installation, remote monitoring, reliable video transmission source, easy adaptation etc. Since

these deployed camera system are expected to deliver live video streaming continuously as a

result they can cause system overload. One can limit the load to get required information which

can be delivered to a remote observer.

This hardware based project focuses on high frame rate video transmission on LAN, WLAN

and WAN. There are a lot of commercial techniques available in the market to complete this

task e.g. IP camera etc. Compared to the other commercially available camera system, our

product can provide a high resolution and high frame rate information at a lower cost. Wireless

video-based sensors have to face some resource constraints like low bandwidth, frame loss and

information loss etc. Irrespective of these limitations our product is capable of sending real-time

video with less delay over a wireless medium.

1.1 Wireless Sensor Node Architecture:

A complete system design must be developed that combine to predict applications out of

underlying hardware capabilities by monitoring a complete wireless sensor network. A wireless

sensor network node consists of several components: a radio transceiver (transmitter and

receiver), a processing unit an internal or external antenna for wireless communication and an

energy source for power (battery).

1

1.2 Objectives

The main objective of our project is to design a low cost wireless video sensor network that can

be deployed for security and surveillance and physical monitoring. Video Sensors are capable of

sensing physical parameters accurately and transmit the information efficiently to a remote

application.

Some of key objectives are listed below:

Design and development of image and video sensor

Develop a low cost surveillance application

Remote viewing of physical parameter

Image tracking and detection

1.3 Why WSN Technology Preferred?

Wireless sensor network technology is preferred due to its innumerable characteristics. Some of

its characteristics are

Freely movement of sensor nodes within a specified geographic area

Low cost and easy deployment

Possess Energy Efficient methodology

Ability to handle high traffic

Better quality of service

Secure operation

Remotely access

1.4 Summary

We are going to develop a hardware product that can be utilized in further research

purposes as well as in medical and environments to collect useful information. The idea

is to implement multimedia applications such as for security purposes, in healthcare for

observing patient’s certain physical parameters and for group monitoring. As a future

perspective, we can make a design enhancement towards the commercializing of our

product.

2

2. Literature Review

2.1 Introduction to Wireless Video Sensor NetworkIn this era of 21st century, wireless sensor network has been considered as the emerging

technology for multimedia applications such as real-time audio and video streaming. Due to the

existence of different multimedia compression schemes such as H.264 and MPEG-4 it have

been made possible to stream multimedia service by eliminating redundant video frames by

means of wireless link.

Video based wireless sensor networks possess the ability to capture video at distributed nodes

and transmit it via wireless link to a centralized location, providing significant benefits in the

form of useful information to many sensor networking applications such as security or

surveillance, environmental monitoring, health-care monitoring etc. when compared with wired

camera networks, wireless video sensor network has many advantages e.g. cost reduction for

network installation, remote monitoring, reliable video transmission source, easy adaptation etc.

Since these deployed camera system are expected to deliver live video streaming continuously

as a result they can cause system overload. One can limit the load to get required information

which can be delivered to a remote observer.

In this project, our aim is to transmit the videos and pictures over the internet so that it can be

viewed remotely. This task has been performed in a number of ways to get better results. One of

the methods is by using Arduino Board. Unfortunately, this method has not worked because the

video frames were about 1 frame per second. So, we switched to second method which is about

to use a Raspberry Pi Module along with Raspberry Pi Camera Module. This module is very

user friendly and we get succeed by sending real time video and pictures over internet with very

small delay. Now, we are aiming to view our video remotely on Smartphone by building an

Android application.

2.2 IEEE 802 standardThe IEEE had developed different standards that had been deployed in

telecommunication, power, transportation energy, biochemical and many other industries. IEEE

802 belongs to the family of IEEE standards that deals with local area networks (LAN) and

metropolitan area networks (MAN).The IEEE 802 standards are network restricted that carry

packets of variable-size. Among the seven OSI layer model, IEEE 802 standard specifies

services and protocols that map the two lower layers i.e. Data Link and Physical layer. Where,

OSI Data Link Layer is further divided into Logical Link Control (LLC) and Media Access

Control (MAC).

3

2.2.1 IEEE 802.11IEEE 802.11 has been created by IEEE standard committee for the implementation of

wireless local area network (WLAN) communication operating in 2.4, 3.6, 5 and 60 GHz

frequency bands using Wi-Fi. This standard has been further classified depending upon the

range and data

2.2.1.1 IEEE 802.11b802.11b standard supports a date rate of maximum 11Mbps by operating in 2.4GHz

band that includes many devices as Bluetooth, cordless telephones, microwave oven. 802.11b

technology possesses substantial price reductions with increase in throughput due to CSMA/CD

that makes it as acceptable for the wireless LAN technology. 802.11b communicate using Omni

directional antenna within the specified which depends on the receiver sensitivity and radio

frequency enjoinment. A directional antenna focuses output power into a smaller field which

increases point-to-point range.

2.2.1.2 IEEE 802.11g802.11g standard supports maximum bit rate of 54 Mbps exclusive of forward error

correction codes having hardware compatible with 802.11b hardware which operates in 2.4

GHz band. Due to its higher date rate it was rapidly adopted. 802.11g devices operating in the

2.4 GHz band had to suffer from interference as 802.11b e.g. wireless keyboards.

2.2.1.3 IEEE 802.11n 802.11n supports maximum bit rate ranges from 54 Mbps to 600 Mbit/s by operating in

2.4 GHz band and lesser used 5 GHz band. It was an extension to previous 802.11 standards.

This standard possesses an extra feature of having multiple-input multiple-output antennas

(MIMO) to increase data rates by providing wireless connectivity.

2.3 Television Standards Different television standards have been studied and analyzed during our literature

review. These are listed as NTSC, PAL and SECAM. These standards define number of TV

lines, image frame rate, horizontal and vertical scanning frequency and video signal bandwidth.

4

2.3.1 PAL (Phase Alternating Line) PAL is a colour encoding system for analogue television used in broadcast television

systems in most countries broadcasting at 576i. In analogue format 576 refers to 625 lines that

are interlaced. Depending upon the rate at which a broadcast is displayed on a TV screen PAL

displays at a rate of 25 frames per second provides (fps). PAL television broadcasts contain 625

lines of resolution per 50Hz from top to bottom and signal is sent out at 50 "fields" per second.

More lines referred to more visual information, which results in better picture quality and

resolution.

2.3.2 NTSC (National Television System Committee) NTSC is an analogue television system that is used in most of the countries. The rate at

which a broadcast is displayed on a TV screen NTSC displays at 30 frames per second (fps).

NTSC signal is also sent out at 60 "fields" per second. NTSC television broadcasts contain 525

lines of resolution.

2.3.3 SECAM (Sequential Colour with Memory)  SECAM is an earlier attempt at compatible colour television. It uses 50Hz

having field lines of 625 lines of resolution. SECAM transmissions are more robust over longer

distances than NTSC or PAL. SECAM like PAL and NTSC doesn’t use QAM, rather it use

Frequency Modulation (FM).

2.4 Applications of WSNWith the start of 21st century, WSNs has been considered as an emerging technology

that provides visual information in many applications and have the ability to monitor or sense

ambient condition in the nearby places. They provide useful information for continuous event

monitoring, detection of events e.g. environmental monitoring, health monitoring, security and

surveillance etc. Some of its covered applications are listed below.

2.4.1 Military ApplicationsWireless sensor network applications are deployed for military application by sensing

and sensing useful information from the battle field to the head office for security, surveillance,

enemy tracking, targeting, monitoring equipment and target classification. As the sensors

network are of low cost and efficient monitoring so they can be deployed in military activities.

This makes wireless sensors network a suitable and secure approach in battle field.

5

2.4.2 Environmental MonitoringEnvironment monitoring is an important application of Wireless sensor network that

also includes area monitoring. In order to monitor some area WSN is deployed in the nearby

place. A civilian example includes geo-fencing of gas or oil pipelines. It can be an indoor or

outdoor environment monitoring. This application can effectively used to alarm in natural

disasters condition and prevent from damage e.g. Wireless nodes deployed in rivers can alarmed

us during the increase of water level and flood.

2.4.3 Health monitoringWireless sensor nodes can be used as heath and patient monitoring application for both

wearable and implanted devices. A sensor node mounted on a patient’s cap can be used to send

useful information regarding the body position, location of the person, overall monitoring of ill

patients in hospitals and at homes to the doctor in a local as well as remote area.

2.5 Component Selection

2.5.1 Arduino Mega 2560:-The Arduino Mega 2560 is a microcontroller based module consisting of 54 digital

input/output pins with 16 analog inputs, 4 UARTs, a 16 MHz crystal oscillator. It consists of

USB connection to interface it with computer, a power jack, an ICSP and a reset button.

Interfacing is simple by connecting it to computer with a USB connection or power cable. Due

to its excessive application this Arduino Mega module is compatible with most shields designed

for the Arduino. The number 2560 demonstrates an update to the Arduino Mega.

2.5.2 ArduCAM shieldArduCAM shield consists of Arduino Mega module attached with Ethernet shield

which is further attached to camera module. This ArduCAM Ethernet shield can be used to

transfer the video over internet but it has certain limitation of video processing and produces

one frame per second. So to avoid such circumstances, we made a design enhancement towards

Raspberry Pi module.

6

2.5.3 Raspberry Pi ModuleIn order to encourage the generation of 21st century towards programming skills, a small

card sized computer board has been discover. The Raspberry Pi Board contains a graphics chip

with processor, RAM and various interfaces with keyboard and mouse connectors. Instead of

hard disk, it contains SD card slot for mass-storage which contains its operating system.

2.5.4 Raspberry Pi CameraThe Raspberry Pi Camera Module is a small 5 MP high resolution omnivision5647

camera with small IR sensor. This camera module can be connected to Raspberry Pi module

through Camera to Serial Interface and is capable of transferring high data rates. This camera

has a fixed focus lens onboard and produces still images of 2592 x 1944 pixel static images, and

also supports 1080p with 30fps, 720p with 60fps and 640x480p with 60/90fps video.

2.5.5 Wi-Fi DongleWireless USB is a radio communication device that connects our module to a wireless

hotspot for internet connectivity. It is capable of sending a maximum of 480 Mbps at distances

up to 3 meters in a Wi-Fi range. The designed feature allows it to operate in the 3.1 to 10.6 GHz

frequency band. However, it is mostly used at 2.4 GHz.

7

1 ABCThe 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 numbered as shown in Figure 3-1.

Figure 3-1 Functional Requirements Numbering

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 priority 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 requirements that maybe skipped in favour of completing the project in

time.

1.1 ABC

1.1.1 ABC

1.2 Functional Requirements

1.2.1 Category 1

The application is intended to ... … …

1.2.2 Category 2

The application is intended to generate… … Following requirements should be met under given

priorities:

FR 00 000

Requirement IndexRequirement Type

Group Index

8

2 Project Design

2.1 Methodology

A very basic prototype was developed … …

Figure 4-2 Example Figure for Prototype Application

The prototype was helpful in … … … shown in Figure 4-2.

9

2.2 Architecture Overview

The design of the intended product is explained graphically with the help of a diagram shown in

Figure 4-3. The diagram explains the overall interactions of the modules and their placements.

Figure 4-3 Architecture Overview Diagram

2.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.

Network

Path FinderInterface Network Decomposer

Path Finder Implementers

NetworkSerialization

NetworkEditing

NetworkGeneration

EventHandlersGraphical User

Interface(GUI)

NodesObjects

NodesLinks

NodesNodes

Zones(Partition)Zones

(Partition)Zones(Partitions)

10

2.3.1 Module 1

Description: This module is the … …

Details:

Add details here… …

2.3.2 Module 2

Description: This module is the … …

Details:

Add details here… …

2.3.3 Module 3

Description: This module is the … …

Details:

Add details here… …

11

3 ImplementationWe have implemented the suggested design using … …

3.1 Development Stages

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

the given time:

3.1.1 <STAGE 1>

We started the project by creating a … …

3.1.2 <STAGE 2>

The next step followed was to … … …

3.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 … … …

3.1.4 System Integration

The next step followed was to … … …

3.2 Key Components

Following are the key components that need special attention from developer’s 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.

3.2.1 <Component 1>

We have implemented …

12

3.2.2 <Component 2>

…

3.3 User Interface

User Interface is an extremely important consideration for any project that requires human-

machine interaction. However, this project doesn’t require human machine interaction and

therefore 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… …

3.3.1 <UI Component 1>

… … … …

Figure 5-4 Example Figure for User Interface

3.3.2 <UI Component 2>

… … …

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

testing the … … …

13

4.1 Unit Testing

Each module in the application was tested while being developed to confirm its adherence to the

related requirements. This testing was … … …

4.2 Function Testing

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

4.2.1 Testing Requirements < A, B, C>

4.3 Results

After thorough testing of system, we proceeded for investigation of our implemented techniques

for … … …

4.3.1 <Comparison of …>

We have compared the … …

4.3.2 <…>

14

5 Conclusions & Future WorkIn this project, we have investigated and developed … … …

There could be several improvements possible … Some of the ideas for future development is

mentioned below:

Idea 1

…

Idea 2

…

Idea 3

…

15

References[1] Ross Sherlock, Peter Mooney, Adam Winstanley & Jan Husdal, "Shortest Path Computation: A

Comparative Analysis", GISRUK pp 91-94, Sheffield, UK, April 2002.

[2] S. Shekhar, M. Coyle, A. Kohli, Path Computation Algorithms for Advanced Traveller Information Systems, IEEE Computer Society, 1993.

[3] R. Jacob, M. Marathe and K. Nagel, A Computational Study of Routing Algorithms for Realistic Transportation Networks, invited paper appears in ACM J. Experimental Algorithmics, 4, Article 6, 1999. http://www.jea.acm.org/1999/JacobRouting/

[4] D. Wagner, T. Willhalm and C. D. Zaroliagis; Geometric Shortest Path Containers; Universit¨ at Karlsruhe, Fakult¨ at f¨ ur Informatik 2004-5, 2004.

[5] John Taplin, Simulation Models of Traffic Flow, Proceeding of the 34th Annual Conference of the Operational Research Society of New Zealand (ORSNZ'99), Keynote Paper, University of Waikato, Hamilton NZ, December 1999, pp 175-184.

[6] S. Pallottino e M. G. Scutell`a, Shortest path algorithms in transportation models: classical and innovative aspects, In (P. Marcotte and S. Nguyen, eds.) Equilibrium and Advanced Transportation Modelling, Kluwer (1998) 245-281.

[7] Andrea Díaz, Verónica Vázquez, G. Wainer. "Vehicle routing in Cell-DEVS models of urban traffic". In Proceedings of European Simulation Simulation. Marseille, France. 2001.

[8] Rong Zhou and Eric A. Hansen, Breadth-First Heuristic Search , 14th International Conference on Automated Planning and Scheduling (ICAPS-04) Whistler, British Columbia, Canada, 2004.

[9] Jayadev Misra, A walk over the shortest path: Dijkstra's Algorithm viewed as fixed-point computation. Information Processing Letters. Volume 77, Number 2-4, pp 197-200. February 2001.

[10] Matthias Schmidt, "Decomposition of a Traffic Flow Model for a Parallel Simulation", Proc. AI, Simulation and Planning in High Autonomy Systems (AIS2000), March 6-8, 2000, Tucson, USA, pp 199-202

[11] KLD Associates Inc. (last accessed on April, 2004). http://www.kldassociates.com/

[12] Peytchev E., Bargiela A., Parallel simulation of city traffic using PADSIM, Proceedings of Modelling and Simulation Conference ESM'95, Prague, Eds. M Snorek, M Sujansky, A Verbraeck, June 1995, ISBN 1-56555-080-3, pp. 330-334.

[13] Oscar Franzese and Shirish Joshi, Traffic Simulation Application to Plan Real-Time Distribution Routes, Proceedings of the 2002 Winter Simulation Conference (WSC), E. Yücesan, C.-H. Chen, J. L. Snowdon, and J. M. Charnes, eds.

[14] Polly Huang and John Heidemann, Minimizing Routing State for Light-Weight Network Simulation, In Proceedings of the International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems, p. to appear. Cincinnati, Ohio, USA, IEEE. August, 2001. http://www.isi.edu/~johnh/PAPERS/Huang01b.html

[15] Yu Jiangsheng, Lecture on Single-Source Shortest Paths, Institute of Computational Linguistics, Peking University, 2003

[16] Baruch Awerbuch , Bonnie Berger , Lenore Cowen , David Peleg, Near-Linear Time Construction of Sparse Neighborhood Covers, SIAM Journal on Computing, v.28 n.1, p.263-277, Feb. 1999

16

[17] Vittorio Astarita, Vincenzo Punzo, Vincenzo Torrieri, Calibration and Comparison Of Simulation Models For Road Network Planning: The Congested Network Of Pozzuoli, 9th Meeting of the Euro Working Group on Transportation, Bari, Italy, June 2002.

[18] M.Herty And A.Klar, “Modeling, Simulation,And Optimization Of Traffic Flow Networks”, SIAM Journal On Scientific Computing Volume 25, Number 3 Pp. 1066-1087

[19] Andrew V. Goldberg and Craig Silverstein, Implementation of Dijkstra’s Algorithm Based on Multi-Level Buckets, Technical Report 95-187, NEC Research Institute, Princeton, NJ, 1995

[20] Ariel Orda and Raphael Rom, "Shortest path and minimum-delay protocols in networks with time-dependent edge-length", Journals of the ACM, Volume 37 ,  Issue 3, pp 607-625, 1990, ISSN:0004-5411

[21] A. Orda and R. Rom. Shortest-path and minimum-delay algorithms in networks with time-dependent edge-length. Journal of the ACM, 37(3):607--625, 1990.

[22] Hermann Kaindl and Gerhard Kainz. Bidirectional heuristic search reconsidered. Journal of Artificial Intelligence Research, 7:283--317, 1997.

[23] D. Wagner, T. Willhalm, C. Zaroliagis. Dynamic shortest path containers. Alberto Marchetti-Spaccamela, Proc. Algorithmic Methods and Models for Optimization of Railways (ATMOS 2003), Volume 92 of Electronic Notes in Theoretical Computer Science, pages 65-84, 2004.

[24] P. W. Eklund, S. Kirkby, and S. Pollitt, A Dynamic Multi-source Dijkstra’s Algorithm for Vehicle Routing, IEEE Transactions, Proceeding 1996 Australian New Zealand Conference on Intelligent Information Systems, 18-20 November 1996, Adelaide, Australia.

[25] Öjvind Johansson. Graph decomposition using node labels. PhD thesis, Royal Institute of Technology, Stockholm, 2001.

17

Appendix A: HDL or C Source Code

18

Appendix B: Hardware Schematics

19

Appendix C: List of Components

20

Appendix D: Project Timeline

DATE

PROJECT IDTOTAL NUMBER

OF WEEKS IN PLAN

TITLE

No. STARTING WEEK DESCRIPTION OF MILESTONE DURATION

1

2

3

4

5

6

7

8

9

10

* You can provide Gantt chart instead of filling this form, if you like

21