online cars system

MANSOURA UNIVERSITY FACULTY OF ENGINEERING Electronics and communications

DESIGN AND IMPLMENTATION OF

Online Cars System Supervised by Dr. El-saeid Marzouk

2013

Online Cars System Teamwork: Ahmed Adel El-Emam Azam Amr Salah Rashed El-behedy Amr Mohamed Mohamed El-shamy Mohamed Elsaeid Elsaeid Eissa

Mohamed Saad Taher Nada

Mohamed Mohamed Aiad

Omar Mohamed Belal Shaban

TO OUR NATION

Table of Contents Preface: About GPS Technology Receiver Clock Error __________________________________________________ 1 Geometry to the rescue! _______________________________________________ 2 System Accuracy ____________________________________________________ 2 Differential GPS ______________________________________________________3 Single-Frequency Operation ____________________________________________ 3 Everyone on the dock will have one soon _________________________________4

Chapter 1:Team Building, Mission Zero and Project Selection _____________ 6 1.1. Team Buildin___________________________________________________ 6 1.2.Project Selection ________________________________________________ 6 Chapter 2:Abstract __________________________________________________ 9 2.1. Problem Definition _______________________________________________ 9 2.2. Problem Solution (project added-value) ______________________________9 2.3.Customers needs as interpreted from the market research _____________ 10 2.4.Business Objectives of the Project _________________________________ 11 2.5. Market and Competitons__________________________________________ 11

2.6. Breakdown Structure ____________________________________________ 12

Chapter 3:Market Research ___________________________________________15 3.1.Product Planning ________________________________________________ 15 3.2. Identifying Opportunities _________________________________________ 15

3.3. Market Plan ____________________________________________________ 16 3.3.1. Compeve Strategy __________________________________________________ 16 3.3.2. Market Segmentaon _________________________________________________ 16 3.3.3. Product Plaorm Planning ______________________________________________ 17 3.4.Allocate Pre-Project Resources and Time Planning____________________ 17 3.4.1.Resource Allocaon ___________________________________________________ 17 3.4.2.Time Planning ________________________________________________________ 18 3.5.Complete Pre-Project Planning_____________________________________ 18 3.5.1.Mission Statement ____________________________________________________ 18 3.6.Identifying Customer needs _______________________________________ 19 3.6.1.Organize the needs into a hierarchy _______________________________________ 19 3.7. Software and Hardware Tools ____________________________________ 20 3.7.1. Hardware Components ________________________________________________ 20 3.7.2.Soware components: _________________________________________________ 20

Chapter 4: Vision Scope and Project Plan ______________________________ 22 4.1 Solution Concept _______________________________________________ 22 4.1.1.Usage Analysis _______________________________________________________ 22 4.1.2. Usage Scenarios ______________________________________________________22 4.2.Scope _________________________________________________________ 24 4.2.1.Feature / Funcon List _________________________________________________ 24

4.2.2.Out of Scope _________________________________________________________ 24 4.2.3.Acceptance Criteria ____________________________________________________ 25

4.2.4.Operaonal Criteria ___________________________________________________ 25 4.3.Schedule Planning ____________________________________________ 26 4.3.1.Schedule Summary ____________________________________________________ 26 4.3.2.Team Working Time table ______________________________________________ 26 4.4.Risk Identification/Statements____________________________________ 27 4.4.1.Risk Analysis _________________________________________________________ 28 4.4.2.Risk Plan ____________________________________________________________ 38

Chapter 5: Detailed Design of the Project _____________________________ 31 5.1.Software Requirements Specification (SRS) ________________________ 31 5.1.1.Overall Descripon ____________________________________________________ 31 5.1.2.Product Perspecve ___________________________________________________ 31 5.1.3.System Interfaces _____________________________________________________ 31 5.1.4.User Interfaces _______________________________________________________ 31 5.1.5.Hardware Interfaces ___________________________________________________ 32 5.1.6.Soware Interfaces ___________________________________________________ 32 5.1.7.Communicaon Protocols ______________________________________________ 32 5.1.8.Assumpons and Dependencies __________________________________________ 32 5.1.9.Apporoning of Requirements ___________________________________________ 33 5.1.10.Specic Requirements ________________________________________________ 33 5.1.11.Funconal Requirements ______________________________________________ 33 5.1.12.Logical database Requirements _________________________________________ 34 5.1.13. Design Constraints ___________________________________________________ 35

5.1.14.Other Requirements __________________________________________________ 35 5.1.15.Priorizaon of Requirements and Dependencies between them ______________ 35 5.2.System Requirements Specifications (SyRS) __________________________ 36 5.2.1.General System Descripon _____________________________________________ 36 5.2.2.System context _______________________________________________________ 36

5.2.3.System modes and states _______________________________________________ 37 5.2.4.Major System capabilies _______________________________________________ 38 5.2.5.Major System Constraints ______________________________________________ 40 5.2.6.System Interfaces _____________________________________________________ 40 5.3.Software High Level Design Description ______________________________ 41 5.3.2.Typical Use Scenarios __________________________________________________ 41 5.3.3. Use Cases ___________________________________________________________ 43 5.4.Conceptual Design _______________________________________________ 46 5.4.1 Major System Components _____________________________________________ 46

Chapter 6: OCS navigation algorithm ___________________________________ 49 6.1 what is meaning of algorithm _______________________________________49

6.2 Dijkstra algorithm _________________________________________________49

6.2.1 Dijkstra Engine ________________________________________________________ 50

6.2.2 what it does __________________________________________________________ 50

6.2.3 how it work ___________________________________________________________ 50

6.2.4 Detailed example ______________________________________________________ 50

6.3: OCS navigation algorithm _________________________________________ 57 Chapter 7: Hardware Platform _________________________________________ 60

7.1.Introduction _____________________________________________________ 60 7.2.Requirements ____________________________________________________ 60 7.3.Solution _________________________________________________________60 7.4.Architecture _____________________________________________________ 61 7.4.1.CPU ________________________________________________________________ 62 7.4.2.GPS Receiver _________________________________________________________ 66 7.4.2.1.SiRF chipset ________________________________________________ 66 7.4.2.2.NMEA standard _____________________________________________ 67 7.4.3.Interfaces ___________________________________________________________ 69 7.4.4.Power Supply ________________________________________________________ 69 7.5. Prototype ______________________________________________________ 74 7.5.1. Selecon criteria: ___________________________________________________ 74 7.5.2. Selected Evaluaon Kit for Prototyping __________________________________ 76 7.5.3. Selected GPS Receiver for Prototyping __________________________________ 79

Chapter 8: Operating System Porting __________________________________ 83 8.1. Introduction ___________________________________________________ 83 8.2.Android _______________________________________________________ 85 8.3. Android features _______________________________________________ 86 8.4. Android Architecture ___________________________________________ 89 8.5. initializing a build Environment ___________________________________ 96 8.6. Getting Linux Kernel Source Code ________________________________ 97 8.7. Configuring and Building Linux Kernel ____________________________ 98

8.8. Getting Android Source Code ____________________________________ 100 8.9. Android Build System __________________________________________ 101 8.10. Building the Android File System ________________________________ 106 8.11. U-Boot image generation _______________________________________ 108 8.12.X-loader image generation_______________________________________ 108

8.14 android system demonstration ___________________________________109

Chapter 9 : Online Cars System________________________________________114

PART A :Android programming________________________________________114 9.A.1.Android Develop tools___________________________________________114 9.A.2 Essential Command line tools ____________________________________115 9.A.3 other third-party development tools_______________________________117 9.A.4 Managing projects______________________________________________121 9.A.5 Library projects________________________________________________124 9.A.6 Development tools considerations ________________________________126 9.A.7 test projects___________________________________________________128 9.A.8 testing a library project__________________________________________129 9.A.9 building and running ___________________________________________130 9.A.10 detailed look at build project____________________________________131 9.A.11 Debugging___________________________________________________133 9.A.12 Google Maps_________________________________________________135 9.A.13 parsing the xml response ______________________________________145 PART B :Server Programming ________________________________________148 9.B.1-collecting feedback from the cars for each road _____________________148

9.B.2-Analyzing feedbacks and Sending the status for any road when requested from a car _______________________________________________________149 9.B.3-Selecting the best route between a source & destination and sending it when requested from a car _________________________________________149 Chapter 10: Documentation _________________________________________ 154 10.1. Reporting system _____________________________________________ 154 10.1.1. Project proposal __________________________________________________ 154 10.1.2 MOMs ___________________________________________________________ 155

Appendix A: Sample Documents ______________________________________ 157 A.1. Online forms used in information gathering _________________________ 157 A.2. Survey used in organizing needs into a hierarchy ____________________ 158 A.3. An Example of a proposal ________________________________________ 162

Appendix B: Source Code____________________________________________ 157 About Team members _______________________________________________ 204

References _____________________________________________________ 207

Online Cars System 2013

About GPS Technology Amazingly precise satellite navigation receivers are now widely available and reasonably priced, thanks to the Global Positioning System (GPS). How do these little wonders figure out exactly where you are? OCS (Online Cars System ) is a system that provides modular GPS services. The modularity will be from both hardware and software aspects. Other applications will be able to make use of OCSs APIs such as location, routing etc. Other devices will also be able to connect to our system and make use of the functions provided by it via USB or serial ports. OCS is based on Google Android OS & open source software making it highly reliable, efficient and cost effective. The basic principle behind GPS is simple, and it's one that you may have used if you have done any coastal navigation: if you know where a landmark is located, and you know how far you are from it, you can plot a line of position. (In reality, it's a circle or sphere of position, but it can be treated as a line if the circle is very large.) If you plot two or more lines of position, you know that your location is the point where those lines cross. With GPS, the landmarks are a couple of dozen satellites flying about 11,000 miles above the earth. Although they are moving very rapidly, their positions and orbits are known with great precision at all times. Part of every GPS receiver is a radio listening for the signals being broadcast by these satellites. Each spacecraft continuously sends a data stream that contains its orbit information, equipment status, and the exact time. All of the information is useful, but the exact time is crucial. GPS receivers have computers that can calculate the difference between the time a satellite sends a signal and the time it is received. The computer multiplies this time of signal travel by the speed of travel to get the distance between the GPS receiver and the satellite (TIME x SPEED = DISTANCE), location in space. Receiver Clock Error Even with two lines of position, though, the resulting fix may not be very good due to receiver clock error. The orbiting satellites have extremely accurate (and expensive!) clocks


that use the vibrations of an atom as the fundamental unit of time, but if GPS receivers had similar atomic clocks they would be much too expensive for recreational users. Since precise measurement of time is so critical to the system - a clock error of only one thousandth of a second causes a position error of almost 200 miles - the system designers were faced with dilemma. Geometry to the rescue!

It turns out that GPS receivers can use inexpensive quartz clocks (like the ones used in wristwatches) and still come up with extremely accurate position fixes as long as one extra line of position is calculated. How does this work? First, imagine two earthbound landmarks with well-known positions. For example, we'll use two BIG landmarks: the cities of Honolulu and Los Angeles. If we measure the travel time of radio waves from each of these cities to San Francisco, we can use the known speed of the radio waves to compute two lines of position that cross. If our clock is a little fast, those position lines will show us to be closer to both cities than we really are; the lines will cross, but the crossing point might be somewhere out in the ocean southwest of San Francisco. On the other hand, if our clock is too slow, the radio waves will seem to take longer to get to us, and the position lines will show us to be farther away from the landmarks than we really are. The lines might cross near Sacramento, to the northeast. System Accuracy For accurate two-dimensional (latitude and longitude) position fixes, then, we always need to get signals from at least three satellites to get around receiver clock error. Fortunately, there are now enough GPS satellites orbiting the earth to allow even three-dimensional position determination (latitude, longitude, and altitude, which requires signals from at least FOUR satellites) anytime, from anywhere in the world. The more satellites your receiver can "see" at one time, the more accurate your position fix will be, up to the system's standard accuracy limit of a few hundred feet. The U.S. Department of Defense (DOD) is responsible for the GPS system, and it reserves increased accuracy for military users. For this reason, the satellites


broadcast a coded signal - the encrypted P-code - that only special military receivers can use, providing positions that are about ten times more accurate than those available with standard receivers. In addition, random errors are put into the satellite clock signals that the civilian GPS receivers use. Not everybody is happy with this intentional degradation of accuracy, though, including the U.S. Coast Guard. Differential GPS

To get around the DOD-imposed accuracy limitation, the Coast Guard is setting up "differential beacons" around the U.S. A differential beacon is a special device positioned at a precisely surveyed location; it picks up GPS satellite signals and determines the difference between its real position and the computed position based on GPS. The beacon then broadcasts this error information over a radio channel for all nearby differential equipped receivers to use. With this method, inexpensive GPS receivers can produce position information accurate to within a few inches using the standard, un-coded civilian signal. GPS receivers that can take advantage of this differential broadcast are becoming quite common, although a separate differential beacon receiver usually must be purchased. Single-Frequency Operation The way GPS receivers pick up the satellite signals is pretty interesting: all of the satellites broadcast their messages on the same frequency, but they each include a unique identification code. The receiver determines which message is from which satellite by matching the identification code with the codes stored in its memory. This is similar to standing in a room with many people speaking at the same time - you can listen to what only one person is saying among all of the conversations taking place simultaneously, and you can identify a person's voice by its unique sound. In the same way, a GPS receiver picks up signals from all of the satellites in view and matches them with patterns in memory until it figures out which ones are "talking" and what they are saying.


This technique allows GPS receivers without Backyard-sized dish antennas to reliably use the tiny signals that the satellites transmit toward earth. Everyone on the dock will have one soon Ten years ago, it would have been hard to believe that you could buy a device capable of using the most advanced satellite technology to provide your precise location anywhere on the globe, and even harder to believe that it would be smaller than a frozen waffle and cost less than a TV set. In just a few years, though, I suspect that these technological marvels will be just about everywhere, and even cheaper. There are terrific handheld units with basic course ploers selling for under $500, and the prices keep going down.


the page left intentionally..........


Chapter 1:Team Building, Mission Zero and Project Selection 1.1. Team Building the core members of the team ( Mohamed Nada , Mohamed Eissa , Ahmed El-emam) decided to start of building a strong team to work in the graduation project . they work together many times before graduation project , and the first two members were participants at EED (Egyptian Engineering Day ) at the summer of 2012 . at the summer of 2012 they started to search and think about graduaon project ideas . after they find the project idea , they search about other members to help in the implementation of the project . the team members selection based on the next criteria : - Technical abilities. - Time management and awareness of deadlines. - Motivation. - Work. - Efficiency. - Team worker. finally they decide to add four new members to their team , working to achieve success with this project .

1.2. Project Selection Applicable and can be marketed the above words were our slogan during searching about ideas . we gathered more than 10 ideas to be evaluated. The ideas to be selected had to be mainly feasible and to have high market value. to select only one idea we must to answer about the next questions for every idea : - Does it t in 8 months? - Is it valuable in the Egyptian market? - Is it valuable in the world market?


- Will it be sponsored easily? - What is the estimated cost? - What it are the required background areas of experience and knowledge? - Are all the required resources available? - Is it a unique idea? - Will we face limitations or restrictions? and we select the more suitable idea .

As an example of our ideas we think about : 1- a glass for blind people to see 2-power over IP


Chapter 2:Abstract 2.1. Problem Definition That one of the most serious problems that we face every day is the problem of traffic congestion , Daily individuals need to move from region to region and from city to city, everyone wants to go to work and children to school, and this is often at the same time each day, leading to traffic congestion. Traffic congestion has many risks, which have a negative impact on the individual and on society. Traffic congestion affects the health of the individual because of car exhaust, and it does not affect the drivers only, but affects the residential areas around the busy roads .And thus affect the overall health of the community and the average age of the society individuals . Another serious problem, a waste of time as a result of standing for hours in crowded roads, and thus be late every day about the performance of the work required and be late for access to work schedules .Which also adversely affects the society in general. Also wasting huge amounts of fuel while standing in the crowded roads, costing the country a lot of money wasted without benefit .after solve this problem we can save these funds and use them in the form of services help the individual and society and affect it positively

2.2. Problem Solution (project added-value) we intended to develop a system which help to solve the traffic problems . we use two main factors in our project . 1- GPS technology 2- users Feedback about the roads GPS:


- Global Navigation Satellite Systems (GNSS) is the standard generic term for satellite navigation systems (sat nav) that provide autonomous geo-spatial positioning with global coverage. - GNSS allows small electronic receivers to determine their location (longitude, latitude, and altitude) to within a few meters using time signals transmitted along a line-of-sight by radio from satellites. Receivers calculate the precise time as well as position, which can be used as a reference for scientific experiments. - The Global Positioning System (GPS) is a space-based global navigation satellite system that provides reliable location and time information in all weather and at all times and anywhere on or near the Earth when and where there is an unobstructed line of sight to four or more GPS satellites: o It is maintained by the United States government and is freely accessible by anyone with a GPS receiver. o The Egyptian market has increasing needs for GPS solutions since Egypt has lifted the ban on importing GPS receivers; the countrys National Telecommunication Regulatory Authority is now allowing the importation of devices with civilian applications provided that NTRA authorizes the type of machines based on its criteria and procedures .

Users Feedback about roads : while the user is driving to reach his destination in a road , we ask him to leave his feedback about road traffic situation , is this road stable ? is it crowded with cars ? , is there any accident ? and then we can use users feedbacks to inform the other users about the roads they intend to use to reach their destination . and then using the data collected we can select the suitable road to every user to use to reach his destination in a short time .

2.3.Customers needs as interpreted from the market research - knowing data about the locations and services . - Downloadable on-demand data about the traffic. - Downloadable on-demand data about the weather. - Pre-defined locations on the map saved along with touristic information


- Accurate maps. - Notifications in case of arrival to some pre-defined places. - Downloadable on-demand data about the traffic. - Downloadable on-demand data about the weather. - Pre-defined locations on the map saved along with touristic information - Accurate maps. - Notifications in case of arrival to some pre-defined places. - Implementing an efficient algorithm to find best routes. - Authentication programs in the device. - In Case of Emergency Service. - Connectivity and control with car security system. - TV receiver / Radio receiver. - Extra accessories

2.4.Business Objectives of the Project - Satisfying a customer need which is Location detection using Global Positioning System (GPS) - The GPS devices were illegal in Egypt 4 year ago. - The Egyptian market has increasing needs for GPS solutions since Egypt has lifted the ban on importing GPS receivers; the countrys National Telecommunication Regulatory Authority (NTRA) is now allowing the importation of devices with civilian applications. -we aim to spread our system in every car . it will lead to accurate data . - also we use a SIM card in every device . this will increase mobile companies markets . - we noted that the previous systems only use the feature of feedback or the GPS navigation . then we tried to combine the two feature in a such project . 2.5. Market and Competition - Market segments will be car drivers . - Targeted customers will buy it because: o Drivers will find it useful to find their current location besides the ability to find their best routes. - Our major competitors are the foreigner GPS companies like Navking, Mio Moov and Supernav besides the GPS-enabled mobile manufacturers such as Nokia and


Sony. - Our competitive edge is to introduce the first made-in-Egypt device which can be as reliable and efficient as imported products with lower prices. - We are using a reliable operating system (Google Android) Our tools and applications will be open-source which will allow the open development in the final product, making it an excellent choice for manufacturers to consider it as a platform to develop new products. - Our competitors have the strengths of their old repetition in the market and their technical support.

2.6. Breakdown Structure - Description. - Team gathering and hierarchical construction. - Documentation. - Project identification and selection. - High-level design. - Requirements gathering. - Components selection. - Components purchasing and shipping. - Researching/Studying Android development. - Testing Android and compiling images. - Maps navigation application. - Researching extension manager. - Native extensions. - Routing. - Implementing extension manager. - Integrate components. - Testing. and before starting our work in the project , we have to draw a mind map . to know what exactly tasks we should do and when .


Our Mind Map


Chapter 3:Market Research

3.1.Product Planning The planning process considers the project development opportunities, identified by many sources including: research, customers, learning from competitors and more. 3.2. Identifying Opportunities - Implications of trends in lifestyles, demographics and technology for existing product categories and for opportunities: o Thousands of people travel through far distances each day; they need an easy way to provide them the route for a specific destination in both fast and easy way. o National Telecommunication Regulatory Authority (NTRA) has left the ban on importing GPS devices. o Compared to traditional GPSs, our product has the advantage of including the real-time crowdedness status of roads in the parameters of choosing the best road. o At the same time , it is easier to use in cars than the mobile applications that offers a similar service. o IN addition, the connectivity to the internet and the future usages after applicaon of 4G technology are not oered in the market. Opportunity statements The Opportunity Statement describes the customers current situation that creates the need for the project. It may contain a statement of the customers opportunity and the impact of capitalizing on that opportunity (product innovation, revenue enhancement, cost avoidance, operational streamlining, and leveraging knowledge). It may contain a statement of the customers problem and the impact of solving the problem (revenue protection, cost reduction, regulatory compliance, alignment of strategy and technology).


It should include a statement that connects the customers opportunity/problem to the relevant business strategy and drivers. The Opportunity Statement is written concisely using a business executives voice. All opportunity statements we have reached - A GPS device that performs basic GPS functions. - An application (not specified) that makes use of GPS and performs some action (mostly in control field). - Real time application that provide instantaneous and dynamic updates .

3.3. Market Plan 3.3.1. Competitive Strategy - Cost Leadership: by using Open source Operating system, Software development kits and applications instead of the proprietary ones the productions cost will be decreased significantly. - Customer focus : a solution for traffic problems more improved way than the application provide the same service in the market .

3.3.2.Target Market -we designed our platform to be fit to car drivers needs (regular car owners or professional drivers). -Government (ambulances, police patrols, etc).


3.4.3. Product Platform Planning

3.4.Allocate Pre-Project Resources and Time Planning 3.4.1.Resource Allocation Hardware resources : for networking we used 3G components , and we use GPS . Software resources are available and mostly open source. Personnel may not be familiar with Android as they are with other operating systems such as windows


or Linux so modifications and hacking of the operating system functions may not be as efficient as possible. Our team members are familiar with java programming language, which is the main programming language for android, so our focus will be on the applications more than on the operating system.

3.4.2.Time Planning - Timing of product introductions: The prototype of the project is expected to be completed upon the graduation project presentaon in July 2013 . - Technology readiness: o The technology of GPS has been introduced to the world markets in the 1980s and proved to be reliable. o Android as the operating system is a reliable efficient open source operating system and has been deployed to a number of embedded systems such as smart phones.

3.5.Complete Pre-Project Planning The Vision Statement section clearly and concisely describes the future desired state of the customers environment once the project is complete. This statement provides a context for decision-making. It should be motivational to the project team and the customer. Our vision statement:

it`s always a win win deal 3.5.2.Mission Statement Product Description Make Egyptian device can solve traffic

problems and low cost . Key Business Goals - Introduce the made in Egypt GPS device

which everyone need to use it Primary market - Egyptian market.

- Drivers . - First introduction - July 2013.


Secondary market - Global market - Government

Assumptions and Constrains

- New Egyptian product - Location detection technology - Open source software are used

Stakeholders

- Purchasers & users - Project sponsor - Manufacturing operations - Distributors & resellers

3.6.Identifying Customer needs 3.6.1.Organize customer needs into a hierarchy OCS has the ability to get updates from the Internet: - Downloadable on-demand data about the locations and services. () - Downloadable on-demand data about the traffic. () - Downloadable on-demand data about the weather. () OCS stores accurate location-related information - Pre-defined locations on the map saved along with touristic information. () - Accurate maps. () - Notifications in case of arrival to some pre-defined places. () OCS connects to the Internet - Always on Internet connection for sending the locations information. () - Packet switching capability like 3G. () OCS interacts with user in the most convenient ways - Ability for voice recognition. () - Touch screen. () - Ability for voice generation. () OCS saves time by finding best routes


- Implementing an efficient algorithm to find best routes. () OCS provides entertainment - MP3 player / video player. ()

3.7. Software and Hardware Tools 3.7.1. Hardware Components For the prototype the following items will be needed: Components description

Components name

Number of required items

Company

Price

Development kit

Devkit8500D 1 Embest US$329

GPS module GPS8000-S 1 Embest US$59 3G module CDMA800-U 1 Embest US$79 Touch screen N/A 1 Embest Included SD card N/A 1 Embest Included

3.7.2.Software components: Components description

Components name

Number of required items

Company

Price

Operating System

Android 1 Google Free

SDK Android SDK 1 Google Free IDE Eclipse IDE 1 VisualAge Free


Chapter 4: Vision Scope and Project Plan 4.1 Solution Concept 4.1.1.Usage Analysis Driver: A driver needs to know his location, reach certain places using the best possible routes. Allowing to save his routes , knowing about weather condition . He or she can be driving a private car, trunk, cab, ambulance or police patrol car.

4.1.2. Usage Scenarios Usage Scenarios define the sequences of activities the users perform within the proposed solutions environment. This information is comprised of a set of key events that will occur within the users environment. These events should be described by their objectives, key activities and their sequences, and the expected results.

4.1.2.1. Present Scenarios Scenario 1 Normal Car driving

1. Ahmed is driving the car. 2. Ahmed turns on the OCS. 3. Ahmed checks his current location on the map. 4. Ahmed define his destination on the map. 5. Ahmed finds the best route to his destination. 6. Ahmed Start to send his feedback about the road . 7. Ahmed want to know all the event on his road , he select to see the

feedback of other users . 8. There was a accident after few Kms from his location 9. The algorithm change Ahmeds road dynamically to avoid the accident


10. Ahmed reach his destination .

Scenario 2 Using OCS Accessories : 1. Ahmed want to play a song or a video. 2. Ahmed select mp3 player and select his song or video .

Scenario 3 -Weather checking: 1. Ahmed clicks a buon on the Main Screen to get Current City. 2. Device connects via Internet to a dedicated server. 3. Device gets the weather, and shows on GUI. 4.1.2.2. Future Scenarios

Scenario 1 -Activating sound recognition:

1. Ahmed want to send his feedback 2. Ahmed presses a button on GUI or makes a gesture. 3. Ahmed tells OCS his feedback 4. Ahmed orders OCS to give him feedback about a road 5. OCS replay phonetically to Ahmed

Scenario 2 using CAN bus :

CAN bus (for controller area network) is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other within a vehicle without a host computer. CAN bus is a message-based protocol, designed specifically for automotive applications but now also used in other areas such as aerospace, industrial automation and medical equipment.

1. Ahmed want to send his feedback 2. Automatically OCS used CAN bus to send feedback to the server based on

cars speed.

Scenario 2 Each Road is a community :


Users in the sane road can share road information with each other phonetically . Each road is a chat roam . Ahmed and other users in the same road can make a conversation during their travel .

4.2.Scope The Scope places a boundary around the solution by detailing the range of features and functions, by defining what is out of scope, and by discussing the criteria by which the solution will be accepted by users and operations. The Scope clearly delineates what stakeholders expect the solution to do, thus making it a basis for defining project scope and for performing many types of project and operations planning. 4.2.1.Feature / Function List The Feature/Function List section contains an expression of the solution stated in terms of Features and Functions. It identifies and defines the components required to satisfy the customers requirements. The Feature/Function List enables the customer and project team to understand what the project will develop and deliver into the customers environment. It is also the input to the Architectural and Technical Design Strategies. Feature Function GPS Determine the current position Internet connectivity Download on-demand data like

weather, services, etc Touch screen Easy Interface with user Storage Store maps, visited locations Implementation of routing algorithms

Find best paths from a source point to a destination point

4.2.2.Out of Scope

- The Out of Scope section lists and defines a limited set of features and functions


excluded from a product or solution -that is, the features and functions that fall outside its boundaries. It does not list everything that is Out of Scope; it only lists and defines the features and the functions that some users and other stakeholders might typically associate with a type of solution or product. - Out of Scope documentation helps to clarify the solution scope and explicitly states what will not be delivered in the solution. - Making our own hardware is out of scope the final product will follow open standards like PC104 for producon, USB & serial ports as interfaces.

4.2.3.Acceptance Criteria

Acceptance Criteria define the metrics that must be met in order for the customer to understand that the solution meets the requirements. Acceptance Criteria communicates the terms and conditions under which the customer will accept the solution to the project team. - Availability on time of competition for the prototype. - Accurate working of all functions. - Elegancy, smartness and handheld shape. - Ease of operating. - Re-chargeability by more than one method (electrical ports, car batteries). - Reliability. - Reduced development cost. - Ease of use. 4.2.4.Operational Criteria Operational Criteria define the conditions and circumstances by which the customers operations team judges the solution readiness to deploy into the production environment. Once deployed, the customer takes ownership of the solution. Operational Criteria communicate to the project team the terms and conditions under which the customer will allow deployment and ultimately sign off on the project. This information provides a framework for planning the solutions deployment. - Available budget. - Required function of the device (many combinations can be made due to the modularity).


4.3.Schedule Planning The Project Scope section defines the tasks, deliverables, resources, and schedule necessary to deliver the customers solution. The tasks are expressed in the Master Project Approach, the Milestone Approach, the Project Estimates, and the Project Schedule. These multiple views allow the customer and project team to look at the project from different perspectives and to analyze how the work is organized. The tasks, deliverables, resources, and schedule exist at a high level of detail. These Project Scope statements provide the context for more detailed planning during follow-on project phases. 4.3.1.Schedule Summary The Schedule Summary section identifies and compiles the collective work tasks and their calendar dates into a complete project schedule that identifies its beginning and end dates. Each major Project Milestone is identified and assigned a targeted completion date. The schedule is a consolidated schedule it includes the work and dates of all project teams. The scheduling process is iterative. During the envisioning phase, the projects Major Milestones anchor the schedule. During the planning phase, the schedule will become more granular as the work tasks are broken down. The Schedule provides the basis for the customer and/or the sponsor to verify timelines and for the project team to produce a constrained master plan from which it can validate proposed budgets, resources, and timescales. 4.3.2.Team Working Time table This section illustrates the number of hours that our team practically worked on the project from the beginning till the finals. 3 hours/day


Start date 25/9/2012 End date 1/7/2013 About 10 months About 30 days / months Available hours will equal 10*30*3 = 900 hours / individual Cumulave working hours for team = 900 * 7 = 6300 hours

4.4.Risk Identification/Statements

The Risk and Issue Assessment section identifies and quantifies all the risks and issues that have become apparent through the envisioning phase. This section should be developed early in the phase and be updated as more information is gathered. At the close of the envisioning phase, this section should contain all risks and issues that exist at that point in time. The section includes the following: Risk Identification/Statements: a list of project risks and the conditions and consequences of each of the risks. Risk Analysis: the objective assessment of any risks significance; the calculation of risk exposure by assessing probability and impact for each item on the list of risks. Risk Plan: the actions that will prevent and minimize risks and provide a course of action if risks occur. Risk Priorities: the top x risks the project should focus on Risk identification Consequence(s) Legality issues with GPS and tracking applications

The project can be banned from the market. Required components cant be Imported

There might be some difficulties in sponsorship deals.

- No financial support for the team. - No technical support for the team.

some technical difficulties related to working with embedded systems

More time required for studying in the field of embedded systems. - Selection of the required components will take long time


Allowed time may not be sufficient for all phases

Some of the iterations may not be delivered.

4.4.1.Risk Analysis Each risk statement/identification will take a number from one to 5 where one is the least risky and 5 is the most. Risk identification Risk analysis and

prioritization Legality issues with GPS and tracking

applications.

4


1

Some technical difficulties related to working with Embedded Systems.

3

Allowed time may not be sufficient 2

4.4.2.Risk Plan

Risk identification Risk analysis and prioritization

Legality issues with GPS and tracking

applications.

- Guarantees of academic usage to the authorities.


1. Sucient informaon about the project must be provided in the proposals sent to the potential sponsors. 2. Contacng organizaons and companies who provide sponsorships to universities such as ITIDA. 3. Project supervisor and professors can


help us in finding sponsors. Some technical difficulties related to working with Embedded Systems.

1. Gathering informaon about famous architectures, technologies and

famous development kits. Allowed time may not be sufficient Prioritize the deliverables to guarantee

that the most important iterations are

delivered at time.


Chapter 5: Detailed Design of the Project 5.1.Software Requirements Specification (SRS)

It describes the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are dened in detail in Secon 2 of the SRS, and makes them easier to understand

5.1.2.Product Perspective This subsection of the SRS puts the product into perspective with other related products and describes the context and origin of the system. - The modularity in our system will be an improvement to the existing GPS devices, which are usually un-customizable and targeted to specific applications. - Using open-source OS and applications to encourage the development and increase the space of customizability 5.1.3.System Interfaces This lists each system interface and identifies the functionality of the software to accomplish the system requirement and the interface description to match the system. Our system will be variant depending on application needs, it may be - Touch screen friendly GUI. - Device push buttons. - Voice Recognition. - Narrator. 5.1.4.User Interfaces There will be various interfaces depending on the application needs like: - Touch-screen-friendly GUI. - Device push buttons. - Voice recognition. - Narrator/Speakers.


5.1.5.Hardware Interfaces The GPS platform will have variant interfaces for communications - USB. - 3G. The device won't be limited to those, as the platform is designed to be modular we may extend the platform in the future to have any of the following interfaces: - 4G. - Bluetooth. - ZigBee. - CAN bus. 5.1.6.Software Interfaces - Google Android API v.7 - revision 1 - android.location - android.database.sqlite - android.voice - Open Street Map. - Google Weather APIs. 5.1.7.Communication Protocols The platform will have the following communication protocols to fetch information, maps, and add-ons: - CDMA2000 via 3G module to get connected to the Internet. - NMEA 0182 via GPS module to get connected to GPS satellite. 5.1.8.Assumptions and Dependencies This subsection of the SRS should list each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but are, rather, any changes to them that can affect the requirements in the SRS. For example, an assumption may be that a specific operating system will be available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change accordingly


- If no Internet connecon available via 3G then user won't be able to send or receive feedback , or weather status , etc. - Android OS: if we had problems that prevent us from using Android, we will have to rewrite some parts of the application that depend on Android APIs. - User won't be able to find out his place if no GPS signal coverage in that location. 5.1.9.Apportioning of Requirements This subsection of the SRS identifies requirements that may be delayed until future versions of the system. These future requirements can be: - Communication with car computer CAN bus - Voice recognition 5.1.10.Specific Requirements This section of the SRS contains all of the software requirements to a level of detail sufficient to enable designers to design a system that can satisfy those requirements, and testers to test that the system satisfies those requirements. Throughout this section, every stated requirement should be externally perceivable by users, operators, or other external systems. These requirements should include at minimum a description of every input (stimulus) into the system, every output (response) from the system, and all functions performed by the system in response to an input or in support of an output. 5.1.11.Functional Requirements This section of the SRS contains all of the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. A functional requirement does not define the inner workings of the proposed system; it does not include the specification how the system function will be implemented. Instead, it focuses on what various outside agents (people using the program, computer peripherals, or other computers, for example) might "observe" when interacting with the system. - Downloadable on-demand data about the locations and services. - Downloadable on-demand data about the traffic.


- Downloadable on-demand data about the weather. - Pre-defined locations on the map saved along with touristic information. - Accurate maps. - Notifications in case of arrival to some pre-defined places. - Always-on Internet connection for sending the locations information. - Packet switching capability like 3G or 4G . - Ability for voice recognition. - Touch screen. - Ability for voice generation. - Implementing an efficient algorithm to find best routes. - Authentication programs in the device. - Connectivity and control with car security system. - TV receiver / Radio receiver. - Extra 5.1.12.Logical database Requirements Our system will not be remarkably dependant on database, we will only use MYSQL database to store minor information and the design is rather trivial:

So, mainly a complicated database design is not required.


5.1.13. Design Constraints This specifies design constraints that can be imposed by other standards, hardware limitations. - Low Processing Power for mobile devices limits the number of add ons/extensions can be installed and supported. - Android constraints on application: android kills any application that lags/stops for more than 5 seconds, so we have to make the main process light-weighted one to avoid this unavoidable kill. - Small and light-weight - Provide long periods of operation and standby from a single battery charge - Low power consumption. 5.1.14.Other Requirements - Low price - Efficiency - Usability (driving friendly interface) - Interoperability - Extensibility - Performances 5.1.15.Prioritization of Requirements and Dependencies between them Put the requirements prioritized based on their importance to the customer HERE and requirements that are interdependent. Req. Ref.

No. Name Priority

1 Downloadable on-demand data about the locations and services

4.3

2 Downloadable on-demand data about the traffic 4.5 3 Downloadable on-demand data about the weather 4.5 4 Pre-defined locations on the map saved along with

touristic information 3.7

5 Accurate maps 3


6 Notifications in case of arrival to some predefined places 4 7 GPS always connected to the internet for sending

the locations information 3.2

8 3G connecon 4 9 Voice recognition 2.5

10 Touch screen 3.5 11 Implementing an efficient algorithm to find best routes 4.5 12 Narrator 3.5 13 Radio receiver 3

5.2.System Requirements Specifications (SyRS) 5.2.1.General System Description It describes the general factors that affect the product and its requirements. 5.2.2.System context Appropriate diagrams and narrative are included in this sub clause, to provide an overview of the context of the system, defining all significant interfaces crossing the systems boundaries plus the actors (users and/or external services) that interact with the proposed system (System interaction with the environment is also shown). The Device will interact with user with a Touch screen to ease the accessibility especially with the Maps navigation program. User may also interact through microphone so he/she can use while being busy for example while driving.


The main system software will allow extensibility with allowing other programs to be installed and run on the device, and then interact with the system to add more functionality to the system according to user needs. New hardware can be connected using USB to allow extensions to add even more functions to the device when used by extensions based upon this new Hardware. The full-fledged installment will contain networking capabilities: - GPS module to get connected to GPS satellite. - 3G : allows connecvity to the internet to send or receive feedback and consume very important services on the web; like finding important places around you like restaurants, parking areas, cinemas ...etc. 5.2.3.System mode and state Software Mode: - Fully Operational: All systems functions and extensions are running.


Device hardware mode: fully featured device will contain: o Touch screen LCD o Microphone and speakers o 3G for Internet access o GPS 5.2.4.Major System capabilities Components: - Core (CPU + Memory + GPS +Power Supply + Interfaces ) - 3G / GSM - SD card - Touch screen - Audio Jack - serial interface


Functions: - Feedback updates - Position logging - Memory extensibility. - Basic location detection - Map navigation - Best device usage experience. - Services updates. - Weather and Traffic data. - Real time location tracking. - Storing offline maps.


- Storing Multi-media. - Update/Replace OS. - Development purposes. 5.2.6.Major System Constraints - Areas with no GPS coverage - coverage obstacles, there some situation when your GPS receiver can't connect with the satellites due to being in a closed area. - Being not able to use other GPS frequencies (e.g. L2) for it being restricted to military uses; which have could provided more accurate data about position, but we hope that this would be solved if we used the new Galileo (a new satellite navigation system) in the future as it may have more accuracy. - Long battery lifetime - Small Size, lightweight and handheld device for the ease of mobility for users. - Egypt regulations has lots of constraints/reservation on tracking devices, so there may be some extensions that could be developed facing problems with these regulations. - Cost effectiveness: we have a major constraint that will limit the amount of hardware we want to add on the device. 5.2.7.System Interfaces - USB connections: user can connect new hardware through using USB. - Internet or GSM: the device can access the internet with the provided 3G module. - User can add new data and port them on SD cards and plugging them into the device. - Mainly GPS module will be used to get location but if the user chosen a better accurate location can be calculated through GSM connection. - Most of our used protocols will be handled by Android, so it's out of our scope of interest. -serial port for purposes of debugging


5.3.Software High Level Design Description 5.3.1.Typical Use Scenarios


1. Need feedback of road X ?

2. Go to a restaurant?

3. His only need is to see his current location to check the map around him.


5.3.2.Use Cases

Name Running map navigation application Description Opening the navigation program Actors User Pre-conditions

The device is powered on.

Actions - User selects the source and the destination . - User navigates through the installed maps

Name Selecting a new destination. Description user selects a place to navigate to Actors User Pre-conditions

Navigation application is running

Actions - User search/navigate map, till he finds his destination. - Mark the location, and selects navigate to.

Name Get short path driving instructions Description User gets the shortest path to his destination Actors User Pre-conditions

User selects destination

Actions Device executes an algorithm and calculates the shortest path Post-conditions

User get instruction on screen or from narrator

Name Activate accurate positioning


Description User use GPS to get his accurate position Actors User Pre-conditions

Device is running

Actions GPS start connection to get the position on the map Post-conditions

GPS gives accurate Positioning

Name Adding a place bookmark Description Select destination in the Navigation program to save for further

access Actors User Pre-conditions

Navigation extension is running

Actions - User Navigates to specific location - User Selects the Saving option

- User types a name for this location Post-conditions

The Location is saved into device memory

Name Activating sound recognition Description Makes device listen for a voice command Actors User Pre-conditions

Device is powered on

Actions User press a button on GUI or makes a gesture Post-conditions

Desired command is run

Name Playing media Description Play media, using existing car sound system


Actors User Pre-conditions

A connection to an existing sound system.

Actions - User selects media file - Select play on Car

Post-conditions

Media plays

Name Check traffic Description Checks traffic of a selected street Actors User Pre-conditions

Navigation Application is running

Actions - User selects a location (saved or navigated to) - User select to Check traffic

- Device connects via Internet to a dedicated server - OCS gets the traffic (feedback of users ), and shows on GUI

Post-conditions

Name Check weather Description Checks weather of a selected city Actors User Pre-conditions

- Navigation Application is running - Or Just Device is powered on

Actions - User Selects a City or use GPS to get your current city - click to get the weather

- Device connects via Internet to a dedicated server - OCS gets the weather, and shows on GUI

Post-conditions


5.4.Conceptual Design 5.4.1 Major System Components Location API This class can be used by other extensions or native components to get information about location: GetLocation() Used to when the current location of the device is needed. TranslateLocation(location : GPSLocation) An extension can use this function to translate the GPS data to a real world address. GetAccurateLocation() If the user enabled using the GSM module to pinpoint the device location, this function will return the current location according to the GSM measurement. GetSpeed() Calculates the speed at which the device is moving with. SupscripeToLocation(location : GPSLocation, callBackFunction : method) An extension would want in some situations to be informed if the device has reached a certain location, so the Observer pattern is used here. Map Navigator component The application that will view visual maps and routes on the LCD screen; it can be regarded as a native extension (for sake of modularity we will do it so), but as its very important one it will have much more permissions and priority. EditCurrentLocation(location : GPSLocation) To inform the app that the current location of the device has changed. AddNewDestination(location : GPSLocation) Add a location to the map and mark it as a destination where the app will


draw a path to it. DeleteDestination(location : GPSLocation) Delete an added destination. UpdateDestination(location : GPSLocation) Relocate a destination to a new location. AddBookmark(location : Bookmark) Add a bookmarked place the user want to know about later and save , can be his home, a bank, a gas station or a public service MoveTo(location : GPSLocation) An extension may want to move the app screen focus to another part of the map (the device is still in its place here). Bookmarks A data structure used to add/save the user bookmarked sites.


OCS navigation algorithmChapter 6 :

6.1what is the meaning of algorithm ?

an algorithm is a step-by-step procedure for calculations. Algorithms are used for calculation, data processing, and automated reasoning .

An algorithm is an effective method expressed as a finite list of well-defined instructions for calculating a function. Starting from an initial state and initial input (perhaps empty), the instructions describe a computation that, when executed, proceeds through a finite number of well-defined successive states, eventually producing "output" and terminating at a final ending state .

by a simple expression " it`s the way to make your idea tidy and clear "

this idea can be a solution for a problem as we have here for our algorithm as we want to find a decent solution for route planning .

Route planning problems in car navigation systems are search problems for finding an optimal route from a starting point to a destination on a road map

in OCS navigation algorithm we use Dijekstra algorithm .

Dijekstra considered as one of the best shortest path algorithms , so famous in networking field as it used with OSPF and IS-IS routing protocols and in artificial intelligence fields .

6.2 Dijkstra's algorithm:

Invented by Edsger Wybe Dijkstra

*May 11, 1930 August 6, 2002

*Dutch computer scientist from Netherlands

*Received the 1972 A. M. Turing Award, widely considered the most prestigious award in computer science

*Known for his many essays on programming


6.2.1.DijkstraEngine:

Dijkstra's algorithm is probably the best-known and thus most implemented shortest path algorithm. It is simple, easy to understand and implement, yet impressively efficient. By getting familiar with such a sharp tool, a developer can solve efficiently and elegantly problems that would be considered impossibly hard otherwise.

6.2.2.What It Does :

Dijkstra's algorithm, when applied to a graph, quickly finds the shortest path from a chosen source to a given destination. In fact, the algorithm is so powerful that it finds all shortest paths from the source to all destinations! This is known as the single-source shortest paths problem.

6.2.3.How It Works :

First let's start by defining the entities we use. The graph is made of vertices (or nodes, I'll use both words interchangeably), and edges which link vertices together. Edges are directed and have an associated distance, sometimes called the weight or the cost. The distance between the vertex u and the vertex v is noted [u, v] and is always positive.


Dijkstra's algorithm partitions vertices in two distinct sets, the set of unsettled vertices and the set of settled vertices. Initially all vertices are unsettled, and the algorithm ends once all vertices are in the settled set. A vertex is considered settled, and moved from the unsettled set to the settled set, once its shortest distance from the source has been found.

6.2.4.Detailed example :

The goal is to find a path of minimum total weight (cost) from s to t .

Initially we put all the vertices in the uncolored (black) set T and set up a possible cost function on the vertices. We set (s) = 0 which indicates that we have found a path from s to s of total weight 0 (the path with no edges). For any other vertex v we set (v) = since we havent even veriied that an s v path exists. Lets add the -values to the picture.


The smallest -value is (s) = 0, we remove s from T, indicating that (s) = 0 represents the smallest possible total weight of a path from s to s :

We examine the edges that leave s. The edge sa gives us a path of cost 18 from s to a so we change on a to (a) = 18. Likewise, we change (c) from to the smaller value 15 :

The smallest -value on a black vertex is 15, which happens at c, so we color c:


The edge ca has weight 6, tells us we can get from s to a for a cost of

(a) + (ca) = 15 + 6 = 21,

which is more than 18. We leave (a) at 18. The edge cb has weight 14, tells us we can getfrom s to b for a cost of

(c) + (cb) = 15 + 14 = 29,

which is less than , so we change on b so that (b) = 29. The edge cd has weight 14, tellsus we can get from s to d for a cost of

(d) + (cd) = 15 + 7 = 22,

which is less than , so we

change on d so that (d) = 22.

The smallest -value on a black vertex is (a) = 18, so we color a


Now we reexamine the -values at the uncolored neighbor of a

Now the smallest -value on T occurs at d

Recalculate (b) and (t)

The min occurs at b


Recalculate (t)

The min occurs at t

Now starting at t, find edges vw where (v) + (vw) = (w) and mark them with an arrow from v to w : since 27 + 28 = 55

Since 18 + 9 = 27,

Since 0 + 18 = 18,


In this case, the cheapest path from s to t is unique, and has total cost 55

this simple example for Dijeksra algorithm demonstration explain in detail how DA works and all the concepts related to it .


6.3.OCS navigation Algorithm

this is the flow chart of our Algorithm :


step 1: client send his source and destination to the server step 2: the server identify nodes , which is the the main points between source and destination - these points stored in the database step 3 : the server calculate the cost to be used in Dijkstra algorithm by this equation

step 4 : run Dijektra algorithm as stated previously step 5 : send the best rout to the user to be used


Chapter 7: Hardware Platform 7.1.Introduction In this chapter; all the mandatory hardware specifications will be taken into account; for each one of them a proper hardware solution for OCS will be discussed. Hardware is an important issue in our system because the modularity issue must be provided. This positioning application meets strict needs such as car navigation, mapping and so on . 7.2.Requirements - Fast CPU - Suitable Memory RAM, NAND Flash - High performance - Small and light-weight - Provide long periods of operation and standby from a single battery charge - Cost-efficient - Scalability. - Ability of integration with other H.W - Provide various types of connectivity i.e. wire/wireless, Ethernet/Can bus, USB. GPS receiver. - Extension Ports or General Purpose I/O

7.3.Solution The underlying silicon solution is essential to meet our system design requirements. The solution must provide specialized processing and dedicated engines to achieve the communications and multimedia tasks. To keep board size and manufacturing expense under control, the processor must offer (SoC) integration that includes multiple processing cores, ample memory and all necessary system peripherals. The manufacturing process and circuit design must enable the greatest performance-per-unit of power consumed during active operation and negligible leakage during standby periods.


7.4.Architecture Our architectural design vision is to build modular system, which provides the modularity from applications side of view. The next block diagram will illustrate OCS H.W. components:

Figure (7-1): OCS Hardware Block Diagram.

Our design is to separate the hardware into two categories: - OCS H.W. Core. - Extensions. Mainly for our project, we will focus on the main parts of OCS or what we called OCS H.W. core.


This core contents are: Processor, GPS receiver, interfaces, memory, and power supply unit. In other chapters we will review two applications on OCS which use OCS interfaces and implement some functions based on a modular platform concept. This provides the modularity concept to apply many applications such as car navigation, mapping, surveying and so on. Now we will review core elements one by one: 7.4.1.CPU As a high-performance processor for enhanced digital media, DM37x/AM37xemploys TI 45nm advanced industrial technology; this architecture has the advantage of low power consumption at the same time of being designed for ARM and graphical demonstration. The Texas Instruments DM3730 DaVinci digital media processor is powered by up to 1-GHz (also supports 300, 600, and 800-MHz operation) ARM Cortex-A8 and 800-MHz (also supports 250, 520 and 660-MHz operation) C64x+ DSP core, and has integrated 3D graphics processor, imaging and video accelerator (IVA), USB 2.0, MMC/SD memory card, UART and many more. DaVinci DM3730 video processor is pin-to-pin compatible with Sitara AM37x devices and software compatible with the OMAP35x processors. The C64x+ DSP and hardware video accelerator enable audio and HD 720p video decoding and encoding independent of the ARM processor. The programmable DSP engine allows multiple signal processing tasks such as image processing and analysis, digital filtering, and math functions. DaVinci DM3730 video processor is suitable for 720p HD (High Deinition) video applications which require large amount of data processing. 7.4.1.2 CPU Features Clock The CPU clock includessys_32k, sys_altclk, sys_clkout1, sys_clkout2, sys_xtalout, sys_xtalin, sys_clkreq. The sys_32k 32-kHz clock is used for low frequency operation. It supplies the wake-up domain signals for operating in lowest power mode (off mode). This clock is provided through the sys_32k pin. The 32-kHz is generated by power management.


The sys_xtalin / sys_xtalout system input clock (26 MHz) is used to generate the main Reset The functionof reset is decided by the SYS_NRESPWRON signal on the CPU, Reset is enabled when LOW levelsignal (high to low) is given. General-Purpose Interface The general-purpose interface combines six general-purpose input/output (GPIO) banks. Each GPIO bank provides 32 dedicated general-purpose pins with input and output capabilities; thus, it supports up to 192 (6 x 32) general-purpose interface pins. These pins can be configured for the following applications:

Data input (capture)/output (drive)

Keyboard interface with a debounce cell

Interrupt generation in active mode when external events are detected. Display Subsystem The display subsystem provides the logic to display a video frame from the memory frame buffer (either SDRAM or SRAM) on a liquid-crystal display (LCD) panel or a TV set. The display subsystem integrates the following elements:

Display controller (DISPC) module

Remote frame buffer interface (RFBI) module

Display serial interface (DSI) complex I/O module and a DSI protocol engine

DSI PLL controller that drives a DSI PLL and high-speed (HS) divider.

NTSC/PAL video encoder


The display controller and the DSI protocol engine are connected to the L3 and L4 interconnect; the RFBI and the TV out encoder modules are connected to the L4 interconnect. 2D/3D Graphics Accelerator

The 2D/3D graphics accelerator (SGX) subsystem accelerates 2-dimensional (2D) and 3-dimensional (3D) graphics applications. The SGX subsystem is

based on the POWERVR SGX core from Imagination Technologies. SGX is a new generation of programmable POWERVR graphic cores. The POWERVR SGX530 v1.2.5 architecture is scalable and can target all market segments from mainstream mobile devices to high-end desktop graphics. Targeted

applications include feature phone, PDA, and hand-held games. (see Figure 7-2)


Figure 7-2

The SGX graphics accelerator can simultaneously process various multimedia data types:

Pixel data

Vertex data

Video data

General-purpose processing This is achieved through a multithreaded architecture using two levels of scheduling and data partitioning enabling zero-overhead task switching.


7.4.2.GPS Receiver In a GPS receiver the signal is processed to obtain the required information, which in turn is used to calculate the users position. Therefore, at least two areas of discipline, receiver technology and navigation scheme, are employed in a GPS receiver. This book covers both areas. In the case of GPS signals, there are two sets of information: the civilian code, referred to as the coarse/ acquisition (C/A) code, and the classified military code, referred to as the P(Y) code. This book concentrates only on the civilian C/A code. This is the information used by commercial GPS receivers to obtain the user position. GPS receivers must solve two fundamental problems, first is the receiver itself, which gets the raw data, the other is the manipulation and computations done on that data to calculate the user position. The idea of GPS is not only about the physical position of the user and satellites. Although, GPS is really time-dependent. In other words GPS is predominately a very complex system of clocks. 7.4.2.1.SiRF chipset SiRFstarII makes it easy and economical to add high-performance SiRFstarII technology to systems that are based on many popular processors and operating systems. The SiRF starII solution allows GPS function to be added at minimal cost in components and circuit board area, by sharing the host system's processor and memory resources. The chipset acquires and tracks satellites, then sends raw measurements to the host processor running the SiRFNav software in parallel with the host applications.


Figure (7-3): SiRF Chipset Block Diagram The chipset consists of the GSP2t highly integrated digital chip, GRF2i integrated RF receiver. The SiRFstarII is designed to be embedded into large volume applications that use multi-thread processors and real time operating systems. The SiRFstarII hardware can be added to the host Motherboard is within an area as small as two square centimeters, and with minimal increment in bill of material. The accurate positioning and built in dead reckoning support provide optimum performance for automotive navigation and entertainment systems. Small size and low cost also make the SiRFstarII the solution for portable devices such as hand-held navigators and Personal Digital Assistants where space and cost are critical. One part that all GPS receivers have in common is the antenna, whose jobs to receive the signal from the satellites and pass that signal on for processing. The signal the antenna picks up is a UHF signal with a frequency of 1575.2MHz (this is the civilian, unencrypted frequency; the military sign uses 1227.6 MHz).This frequency offers all-weather navigation capability but is blocked by walls, ceilings and even trees. 7.4.2.2.NMEA standard The National Marine Electronics Association (NMEA) developed a standard over 20 years ago that defnes the interface between various pieces of marine electronic equipment and navigational computers, allowing them to talk together and share vital information.


The NMEA 0183 standard slowly became the common method by which marine electronics devices could talk to one another. The standard specifes both the electrical connections that make up an NMEA system, the communications method of transmitting the data, and the format of the data sentences that carry the NMEA information .The NMEA 0183 standard is a purely digital data transmission scheme, using 1s and 0s in a binary format, to communicate a digital representation of the required information (depth, speed etc.) to a connected device .The need for NMEA 0183 evolved from the earlier NMEA 0180 and NMEA 0182 standards. Because they differ in baud rate and transmission parameters from NMEA 0183, they are completely incompatible with NMEA 0183. communication specification: The data communication specification for NMEA version 1, 2 and 3 is essentially the same as RS232 with the settings: 800 baud, 1 start bit, 1 stop bit and No Parity. Output message: NMEA output messages provided by SiRF chipset. Message Description GGA Time, position and fix type data GLL Latitude, longitude, UTC time of position fix and status GSA GPS receiver operating mode, satellites used in the position

solution, and DOP values GSV Number of GPS satellites in view satellite ID numbers, elevation,

azimuth, & SNR values MSS Signal-to-noise ratio, signal strength, frequency, and bit rate from

a radio-beacon receiver RMC Time, date, position, course and speed data VTG Course and speed information relative to the ground ZDA PPS timing message (synchronized to PPS) 150 OK to send message 151 GPS Data and Extended Ephemeris Mask 152 Extended Ephemeris Integrity


154 Extended Ephemeris ACK Table (7-1) 7.4.3.Interfaces This point is the most vital point in the OCS which can provide the sense of modularity and the ability of connecting multiple hardware extensions. The serial interfaces is the most appropriate solution for this issue also considered the mandatory interfaces for OCS - HDQ - I2C - SmartReflex - McBSP LP - McSPI S - McSPI - UARTs - USB OCS also provide some peripherals as: Video Interfaces TV - Video Interfaces DSS Signals - Video Interfaces RFBI Audio Interfaces Test interfaces - JTAG - SDTI "Serial data out (System Trace)" - HWDBG "Hardware Debug Signal" Removable Media Interfaces - MMC/SDIO MULTIMEDIA MEMORY CARD/SECURE DIGITAL IO 7.4.4.Power Supply


The power supply circuit is one of the most important part in the full product design and it strongly affects the product overall performances. Power Supply Requirements After calculations and researches about the appropriate hardware the OCS power requirements are: Nominal Supply Voltage 3.8 V Max Supply Voltage 4.2 V Supply voltage range 3.4 V - 4.2 V Max Peak current consumption (impulsive)

1.9 A

Max Average current consumption during GPRS transmission

400 mA

Max Average current consumption during VOICE/CSD transmission

270 mA

Average current during Power Saving (CFUN=5)

4 mA

Average current during idle (Power Saving disabled)

17 mA

GPS Max Peak current consumption 80 mA GPS Max Average current consumption during Tracking

60 mA

GPS Average current during Power Saving

1 mA

GPS antenna consumption (external active antenna)

20 m

Electrical Design The electrical design of the power supply depends on the power source where this power is drained. We will distinguish them into four categories: - +5V input (typical PC internal regulator output) - +12V input (typical automotive)


- Battery - 110~220 V Ac (typical adaptor) + 5V input Source Power Supply Design The desired output for the power supply is 3.8V, hence there's no big difference between the input source and the desired output and a linear regulator can be used. A switching power supply will not be suitable because of the low drop out requirements. When using a linear regulator, a proper heat sink shall be provided in order to dissipate the power generated. Also protection diode should be inserted close to the power input, in order to save the OCS from power polarity inversion. + 12V Input Source Power Supply Design The desired output for the power supply is 3.8 V; hence due to the big difference between the input source and the desired output, a linear regulator is not suitable and shall not be used. A switching power supply will be preferable because of its better efficiency especially with the 2A peak current load needed by the OCS. When using a switching regulator, a 500 kHz or more switching frequency regulator is preferable because of its smaller inductor size and its faster transient response. This allows the regulator to respond quickly to the current peaks absorption. For car battery the input voltage can rise up to 15,8V and this should be kept in mind when choosing components: all components in the power supply must withstand this voltage. A Bypass low ESR capacitor of adequate capacity must be provided in order to cut the current absorption peaks, a 100F tantalum capacitor is usually suitable. For Car applications a spike protection diode should be inserted close to the power input, in order to clean the supply from spikes. Also protection diode should be inserted close to the power input, in order to save the OCS from power polarity inversion. This can be the same diode as for spike protection. Battery Source Power Supply Design


The desired nominal output for the power supply is 3.8V and the maximum voltage allowed is 4.2V, hence a single 3.7V Li-Ion cell battery type is suitable for supplying the power to OCS. The three cells Ni/Cd or Ni/MH 3,6 V Nominal. Battery types or 4V PB types must not be used directly since their maximum voltage can rise over the absolute maximum voltage for the OCS and damage it. A Bypass low ESR capacitor of adequate capacity must be provided in order to cut the current absorption peaks, a 100F tantalum capacitor is usually suited. Also protection diode should be inserted close to the power input, in order to save the OCS from power polarity inversion. Otherwise the battery connector should be done in a way to avoid polarity inversions when connecting the battery. The battery capacity must be at least 500mAh in order to withstand the current peaks of 2A; the suggested capacity is from 500mAh to 1000mAh. Battery Charge control Circuitry Design The charging process for Li-Ion Batteries can be divided into 4 phases: - Qualification and trickle charging - Fast charge - constant current - Final charge - constant voltage or pulsed charging - Maintenance charge The qualification process consists in a battery voltage measure, indicating roughly its chargestatus. If the battery is deeply discharged, that means its voltage is lower than the trickle charging threshold, then the charge must start slowly possibly with a current limited precharging process where the current is kept very low with respect to the fast charge value: the trickle charging. During the trickle charging the voltage across the battery terminals rises; when it reaches the fast charge threshold level the charging process goes into fast charge phase. During the fast charge phase the process proceeds with a current limited charging; this current limit depends on the required time for the complete charge and from the battery pack capacity. During this phase the voltage across the battery terminals still raises but at a


lower rate. Once the battery voltage reaches its maximum voltage then the process goes into its third state: Final charging. The voltage measure to change the process status into final charge is very important. It must be ensured that the maximum battery voltage is never exceeded, otherwise the battery may be damaged and even explode. Moreover for the constant voltage final chargers, the constant voltage phase (final charge) must not start before the battery voltage has reached its maximum values. Otherwise the battery capacity will be highly reduced. The final charge can be of two different types: constant voltage or pulsed. The constant voltage charge proceeds with a fixed voltage regulator (very accurately set to the maximum battery voltage) and hence the current will decrease while the battery is becoming charged. When the charging current falls below a certain fraction of the fast charge current value, then the battery is considered fully charged, the final charge stops and eventually starts the maintenance. The pulsed charge process has no voltage regulation, instead the charge continues with pulses. Usually the pulse charge works in the following manner: the charge is stopped for some time, just few hundreds of mS, then the battery voltage will be measured and when it drops below its maximum value a fixed time length charging pulse is issued. As the battery approaches its full charge the off time will become longer, hence the duty-cycle of the pulses will decrease. The battery is considered fully charged when the pulse duty-cycle is less than a threshold value, typically 10%, the pulse charge stops and eventually the maintenance starts. The last phase is not properly acharging phase, since the battery at this point is fully charged and the process may stop after the final charge. The maintenance charge provides an additional charging process to compensate for the charge leak typical of a Li-Ion battery. It is done by issuing pulses with a fixed time length, again few hundreds of mS, and a duty-cycle around 5% or less. The charging process is not a trivial task to be done. All of these operations


should start if and only if battery temperature is inside a charging range, usually 5C - 45C. The OCS must measures the temperature of its internal component, in order to satisfy this last requirement. It is not exactly the same as the battery temperature but in common application the two temperatures should not differ too much and the charging temperature range should be guaranteed.

7.5. Prototype It is mandatory to have a development hardware kit to make a reality development on your platform neither then emulation and simulation. In other words it will add the practical sense. For our system we put this criteis when we think about the development kit. It is the answer for the question which is meet our needs. 7.5.1. Selection criteria: - Software related: o Operating Systems Hardware drivers - General features - Processor o Speed o Cash o Fan-less - Interface o Audio interface o Repeat button o External keyboard connector o GPIOs - Portability


o Battery life o Unit weight o Waterproof o Overall size - Display o Display size o Brightness o 3D map display o Color o Display resolution o Night view mode o Touch capability - System Memory o Built-in system memory o Internal hard drive - Connectivity o Wi-Fi/Wi-Max o USB o Bluetooth o Multimedia headphone ja

online cars system

Documents

behedy amr mohamed mohamed

project selection

complete preproject

problem solution project

time planning

product planning

market plan

market research