From Dr.
Dagmawi’s Email:
This is a continuation of your previous assignment in which you submitted the Product Plan. For this
phase, you are required to submit a comprehensive project report.What to Do:
1) Use the attached template to document your project.
2) Complete all sections in the template, including:
● System block diagram
● Hardware and software details
● Implementation and testing evidence (e.g., photos, screenshots)
3) Submit your report in two ways:
● Printed copy to your assigned lab instructor (only one submission per group)
● Digital copy uploaded here on Google Classroom
Addis Ababa University
Department of Computer Science
A Course Project
Semester II, Year 2024/2025
Course Title: Real-Time and Embedded Systems
Couse Code: CoSc4412
Embedded Systems Final Project Report
Bus Tracking System
Submitted by:
Student Name 1 / <ID>
Newal Yimam / <ID>
Yigerem Bisrat / <ID>
Yodahe Gosa / UGR/9595/14
Yohannes Belay / UGR/4223/14
Submitted to:
<Name of Supervisor>
10 / May / 2025
Addis Ababa
Ethiopia
Revision History
Date Versio Description Author
n
March 2, 2025 1.0 Product Plan ???
Table of Contents
1. Introduction 1
2. System Block Diagram 1
3. Requirements 1
3.1. Functional Requirements..............................................................................................................1
3.1.1. Functionality 1 …....................................................................................................................1
3.1.2. Functionality 2 …....................................................................................................................1
3.2. Non-functional Requirements......................................................................................................1
4. Design 2
4.1. Hardware Design..........................................................................................................................2
4.2. Software Design...........................................................................................................................2
5. Implementation Results 2
6. Test Plan 2
7. References 2
Annex 4
Annex 1. Catalogue Card (Example).........................................................................................................4
Annex 2. Clearance Form (Example)........................................................................................................4
IMPORTANT NOTE:
- Please remove any text with red color.
- If a section or sub-section is in red color (e.g. Section “2. Existing System” or sub-
section “1.4. Definitions, acronyms, and abbreviations” below) then it means optional in
the sense of scrum documentation. So, you can remove such section IF YOU FIND IT
LESS IMPORTANT, otherwise, enrich the section but you need to change the color to
similar style with the rest of the document.
- Green colored texts are examples
1. Introduction
Provide background on the problem, motivation for the project, goals, and the intended
impact or usage. You may include the product plan documentation here.
<Your content goes here>
This project focuses on the design and simulation of a real-time bus tracking system using
embedded systems principles. In modern urban environments, efficient public transportation is
crucial, and providing passengers with accurate, real-time information about bus locations and
arrival times significantly enhances their travel experience. While a full-scale deployment
involves complex infrastructure, this project simulates the core embedded components
responsible for tracking and transmitting bus location data.
The motivation for this project stems from the need to understand and apply concepts of real-time
systems, sensor integration, and communication protocols within an embedded context. By
building a simulated bus tracking unit, we can explore the challenges and solutions involved in
acquiring data from sensors (like GPS), processing it on a microcontroller (Arduino), and
preparing it for transmission.
The primary goal of this project is to design and simulate an embedded system for bus tracking
that can:
● Acquire simulated GPS data representing the bus's location.
● Process this data using an embedded microcontroller.
● Prepare the location data for transmission (simulating a communication module).
● Demonstrate the real-time nature of data acquisition and processing within the embedded
system.
The intended impact of this simulation is to provide a practical understanding of how embedded
systems function in a real-world application like bus tracking. It serves as a foundational exercise
in developing real-time embedded solutions, highlighting the interplay between hardware and
software in a constrained environment. The simulation will be implemented using Proteus for
circuit simulation and Arduino IDE for programming the microcontroller.
2. System Block Diagram
Show the intended design using block diagram, and use narration to describe how it helps to
attain the goal.
The system block diagram illustrates the high-level architecture of the embedded bus tracking
system simulation. It depicts the main components and their interconnections, showing the flow
of data within the simulated environment.
Description of Blocks:
● Simulated GPS Module: This block represents the source of location data in the
simulation. In Proteus, this would be simulated using appropriate components or libraries
that can generate serial data mimicking a GPS receiver output (NMEA sentences). It
provides the raw geographical coordinates (latitude, longitude) and potentially other data
like speed and time.
● Arduino Microcontroller: This is the central processing unit of the embedded system.
The Arduino reads the serial data from the Simulated GPS Module. Its software is
responsible for parsing the received data, extracting the relevant location information,
and preparing it for output or transmission. It runs the core logic of the tracking unit.
● Simulated Communication Module: This block represents the part of the system that
would, in a real application, handle transmitting the processed location data (e.g., via
GSM, GPRS, or other radio protocols) to a server or monitoring station. In the
simulation, this might be simplified to outputting the processed data to a serial port or a
display within Proteus, demonstrating that the data is ready for transmission.
● Output/Monitoring: This represents the interface where the processed data can be
observed within the simulation environment, such as the Serial Monitor in Proteus, an
LCD display, or LEDs indicating status. It allows verification that the system is correctly
acquiring, processing, and preparing the location data.
Narration:
The System Block Diagram shows how the simulated bus tracking unit operates. The Simulated
GPS Module continuously provides location data to the Arduino Microcontroller. The
Arduino's software processes this raw data, extracting the necessary coordinates. The processed
location information is then passed to the Simulated Communication Module, which prepares it
for output. Finally, the data is sent to the Output/Monitoring interface within the Proteus
simulation, allowing us to visualize the tracked location data and verify the system's functionality.
This diagram highlights the sequential flow of data from acquisition to preparation for
transmission within the embedded simulation.
3. Requirements
You may provide general requirements here.
This section outlines the functional and non-functional requirements for the embedded bus
tracking system simulation. These requirements define what the system must do and the
quality attributes it must possess to be considered successful within the simulation
environment.
3.1. Functional Requirements
List and describe each functionality
Functional requirements describe the specific behaviors and functionalities that the
embedded system simulation must exhibit.
3.1.1. Acquire Simulated Location Data: The system must be able to receive and
interpret simulated GPS data (e.g., NMEA sentences) from the simulated GPS module
within Proteus.
Example: The system should correctly parse the GPGGA sentence to extract latitude,
longitude, and fix quality.
3.1.2. Process Location Data: The Arduino microcontroller must process the acquired
location data to extract relevant information (e.g., valid coordinates).
Example: The system should convert raw latitude and longitude strings into a usable
numerical format.
3.1.3. Prepare Data for Output: The processed location data must be formatted into a
suitable structure for output or simulated transmission.
Example: The system should format the data into a comma-separated string containing
latitude, longitude, and a timestamp.
3.1.4. Output Processed Data: The system must output the prepared location data to a
monitoring interface within the simulation (e.g., Proteus Serial Monitor).
Example: The system should print the formatted location string to the serial port at
regular intervals.
3.2. Non-functional Requirements
Based on your previous study on the market, stakeholder, etc. identify the quality attribute to
be considered in the design and document the list with description.
Non-functional requirements specify criteria that can be used to judge the operation of a system,
rather than specific behaviors. These relate to quality attributes like performance, reliability, and
constraints.
3.2.1. Real-time Performance: The system should process and output location data with
minimal delay to simulate real-time tracking. The delay between receiving simulated GPS data
and outputting processed data should be within acceptable limits for a tracking application
(specify a target delay if possible based on simulation constraints).
3.2.2. Reliability: The system simulation should run reliably within the Proteus environment
without crashing or freezing during operation. It should handle expected variations in simulated
input data.
3.2.3. Resource Utilization: The software running on the Arduino microcontroller should be
efficient in its use of processing power and memory, considering the limited resources of an
embedded system.
3.2.4. Simplicity/Maintainability: The code should be well-structured and commented to
facilitate understanding and potential modifications within the simulation context.
3.2.5. Testability: The system's design should allow for testing of individual components and the
overall data flow within the simulation environment.
4. Design
4.1. Hardware Design
List all electronic components, interfaces, and a brief description. Include pin mapping.
4.2. Software Design
Describe software structure, flowcharts, and key algorithm logic.
- Discuss the possible no
- tion of time and include it in the task specification
- Discuss the RTS if applicable
5. Implementation Results
Include screenshots, system photos, and performance data
Test Plan
Include:
● Test cases for each functional requirement. What will be used as input data and to
which functionality? Make sure to use various scenario.
● Include in the report what has been observed.
o Screenshots or photos of display/buzzer in action.
● Any issues encountered and how they were resolved or should it be a constraint in the
product specification?
6. References
List any external sources (datasheet, library framework, data used for testing, manual,
adapted diagram, etc.) used to develop your system
Annex
Note that the Annex shall not be labeled with chapter number
Each form and document you might have used shall be attached as annex and must be cited in
the document. You can consider the followings as example
Annex 1. Catalogue Card (Example)
Example: Attached sample of catalogue card or copy of it
Annex 2. Clearance Form (Example)
Example: Attached sample of clearance form or copy of it
