Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
Lab 2 – Defensive Driver Product Specification
Andrew Will
Old Dominion University
Professional Workforce Development
Professor Janet Brunelle
1
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
2
Table of Contents
1 Introduction .................................................................................................................................. 4
1.1 Purpose.................................................................................................................................. 5
1.2 Scope ..................................................................................................................................... 8
1.3 Definitions, Acronyms, and Abbreviations ........................................................................ 10
1.4 References ........................................................................................................................... 15
1.5 Overview ............................................................................................................................. 15
2 General Description ................................................................................................................... 15
2.1 Prototype Architecture Description .................................................................................... 16
2.2 Prototype Functional Description ....................................................................................... 19
2.3 External Interfaces .............................................................................................................. 25
2.3.1 Hardware Interfaces ..................................................................................................... 25
2.3.2 Software Interfaces ...................................................................................................... 26
2.3.3 User Interfaces ............................................................................................................. 26
2.3.4 Communications Protocols and Interfaces................................................................... 27
3 Specific Requirements ............................................................................................................... 27
3.1 Functional Requirements ................................................................................................ 27
3.1.1 Algorithms ................................................................................................................... 28
3.1.2 GUI Interfaces .............................................................................................................. 36
3.2 Performance Requirements ................................................................................................. 40
3.3 Assumptions and Constraints .............................................................................................. 41
3.4 Non-Functional Requirements ............................................................................................ 42
3.4.1 Ease of Use .................................................................................................................. 42
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
3
3.4.2 Security ........................................................................................................................ 42
3.4.3 Maintainability ............................................................................................................. 43
3.4.4 Reliability..................................................................................................................... 43
4. Appendix ................................................................................................................................... 43
List of Figures
Figure 1. Real World Product Major Functional Component Diagram…………………………...6
Figure 2. Prototype Major Function Component Diagram………………………………………17
Figure 3. Data Synchronization Module…………………………………………………………19
Figure 4. Prototype Process Flow………………………………………………………………..20
Figure 5. On-Board Unit GUI Map……………………………………………………………...21
Figure 6. Client Software GUI Map……………………………………………………………..22
Figure 7. Test Harness GUI Map………………………………………………………………...23
Figure 8. Database Schema………………………………………………………………………24
Figure 9. Speeding Algorithm Process Flow…………………………………………………….30
Figure 10. Following Too Close Process Flow…………………………………………………..31
Figure 11. Seat Belt Engagement Process Flow…………………………………………………32
Figure 12. “Are you in the Box?” Process Flow…………………………………………………33
Figure 13. Stop Sign Violation Process Flow……………………………………………………34
Figure 14. Analysis Algorithm…………………………………………………………………..35
List of Tables
Table 1. Real World Product and Prototype Comparison…………………………………………8
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
4
1 Introduction
Poor driving habits lay claim to tens of thousands of lives a year and cost the economy
billions of dollars annually. In 2008 the National Highway Traffic Safety Administration
(NHTSA) reported that over 37 thousand people died in a total of 5.8 million motor vehicle
accidents (NHTSA, 2008). These accidents had an economic toll of $230.6 billion and caused
one death every 14 minutes on average (NHTSA, 2008). In 2006, motor vehicle accidents were
the leading cause of death for people ages 3 to 34 (NHTSA, 2008). Poor driving habits are the
root cause of these staggering statistics. Ineffective identification, correction, and monitoring of
these habits is costing not only billions of dollars each year, but thousands of human lives.
Poor driving habits are the result of the current system used to teach people how to drive.
Mandatory monitoring of a driver is done only once, during the licensing phase of driver
training. This monitoring is not only very subjective, as not every new driver has the same
driving instructor; it is accomplished in short intervals. Therefore, the current system yields
drivers that may or may not have poor driving habits, due to the lack of time an instructor has to
effectively monitor and asses each new driver. This initial training lacks consistency in how a
driver’s habits are observed, and most importantly, how poor driving habits are identified and
corrected during, and after, a driver is licensed.
The correction of poor driving habits is unfortunately not a responsibility taken by many
individual drivers. This responsibility falls on the current ticketing and traffic court system.
When a poor driving habit is observed by a law enforcement officer, a citation is usually issued.
Depending on the severity of the infraction, the driver can be sentenced to, or voluntarily attend a
driver improvement clinic. The clinic is supposed to identify and correct the driving habit that
resulted in the infraction. However, these clinics have a short duration and usually lack actual
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
5
driving sessions. With the advent of the Internet, some driving clinics can be completed without
ever stepping into a car, much less a classroom. This system is ineffective and does not work
due to its lack of comprehensive monitoring and statistical analysis of the driver. What is needed
is a system that will monitor and analyze driver’s habits and generate reports that are unbiased
and complete.
1.1 Purpose
The Defensive Driver is designed with the purpose of providing real-time monitoring of a
driver through an in-depth sensor network. It will detect and record the safe and unsafe habits of
the driver, as well as inform the driver of these habits through specialized alert generation.
Defensive Driver will support driving event report generation, and allow individual driver
statistics to be compared to all others stored in the Defensive Driver client software. It will be
able to distinguish individual drivers through an on-board fingerprint scanner, and prevent
unauthorized access that could corrupt the integrity of a driver’s profile. This product will most
importantly have the capability to be custom tailored to individual drivers. The software will be
able to take into account driver information, such as age and any driving restrictions, and build a
custom profile for each driver. This will allow the software to, in a sense, learn the driver and
reduce false positives. For example, an 89 year old man will not have the same reaction time as
a 23 year old man while driving. This feature will allow for the maximum individual benefit of
the product, and the minimization of faulty data for each driver, as not all drivers have the same
driving attributes.
Figure 1 shows the Major Function Component Diagram (MFCD) of the Defensive
Driver. As shown, the defensive driver has two main parts consisting of multiple hardware and
software components, the On-Board Unit (OBU), and the client software. These components
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
will work together to produce one of the most comprehensive real-time driving analysis and
monitoring tools available.
Figure 1. Real World Product Major Functional Component Diagram
6
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
7
As seen in Figure 1, real-time monitoring will be enabled through an array of sensors
coupled with specialized monitoring algorithms. Monitoring algorithms, loaded onto the OBU’s
internal memory, will interpret and record a driver’s performance in seven key areas: tailgating,
seat belt engagement, erratic lane changes, headlight usage, speeding, stop sign procedure, and
proper turning procedure. These areas, according to the Department of Motor Vehicles (DMV),
are known to be the largest contributing factors to motor vehicle accident fatalities (DMV, 2008).
Alerting the driver of a bad driving habit is another function provided by the real-time
monitoring system. Alerts will be displayed visually on the Liquid Crystal Display (LCD) and
accompanied by a corresponding audible alert if desired. This system will allow the driver to be
aware of when and why bad habits are being recorded.
The client software is the portion of the Defensive Driver that will produce the in-depth
reports and profiles that will classify drivers. It will download the information collected by the
OBU through an SD Memory card, and analyze the individual driving reports. This is where a
driver will be categorized based on individual driving habits and compared to other drivers in the
client software. The reports will allow the user to identify and help fix areas that need
improvement with great efficiency.
[This Space Intentionally Left Blank]
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
8
Table 1. Real World Product and Prototype Comparison
Features
Real-time monitoring
Driver Analysis/Driver Profiling
Hardware
GPS
Fingerprint reader
Accelerometer
Distance Sensor
LCD Touchscreen
OBD-II
Flash and SD Memory
Audio Speakers
Software
Speed Limit Database
Stop Sign Database
GPS Coordinates
Erratic Lane Change Algorithm
Failure To Use Headlights
Algorithm
Improper Turns Algorithm
Following Too Close Algorithm
Seat Belt Usage Algorithm
Speeding Algorithm
Stop Sign Algorithm
Data Synchronization
Analysis Software
Final Product
Prototype
Real-time sensor data correlation when
Simulated sensor data correlation with prevehicle is in motion
loaded inputs
Fully functional
Final Product
Prototype
On-board Unit (OBU) embedded receiver
External receiver with USB interface
Embedded in OBU
Laptop component
OBU component
Not in prototype
OBU component
External sensor with USB interface
OBU Display component
Laptop display
OBU Interface
Simulated database input
OBU internal/external memory
Laptop memory
OBU component
Laptop speakers
Final Product
Prototype
Microsoft Access database to be provided
Database of sample speed limit data
by VDOT
Microsoft Access database to be provided
Database of sample stop sign data
by VDOT
Lat/Long obtained by embedded GPS
Lat/Long obtained by external GPS receiver
receiver
Data Processing Module component
Not in prototype
Data Processing Module component
Not in prototype
Data Processing Module component
Not in prototype
Fully functional
As seen in Table 1, the Defensive Driver will provide an in-depth driver recording and
analysis platform. However, this product can only be used as a tool to identify improper driving
habits, not correct them. The Defensive Driver will not be able to keep a driver from exhibiting
bad driving habits, or prevent accidents.
1.2 Scope
The inability of the current driver licensing system to properly identify and correct poor
driving habits will be fixed with the implementation of the Defensive Driver. With the
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
9
combination of the Defensive Driver’s on-board unit and client software, proper recording,
identification, and analysis of poor driving habits can be established.
The goal of the prototype is to prove that the key real world product capabilities will
work. Through using the real-world product algorithms in the prototype, and testing them in
many different scenarios, the Defensive Driver prototype will display its driver analysis
capabilities as well as prove the real-world algorithms through simulated real- time events. The
prototype will also allow a demonstration of how the risks involved are being mitigated, and will
allow the customers questions regarding these risks to be answered immediately.
There are many objectives that need to be met by the Defensive Driver prototype. The
stop sign and speed limit databases that will be stored within the OBU and client software will
need to be demonstrated as being effective. GPS data will be a significant part of this, as it is
how the OBU will cross-reference the simulated location of the driver with posted speed limits
and stop sign locations. The GPS data will come from an actual GPS receiver to produce the
most realistic data available. The OBD-II data will also need to be simulated as closely to the
real world data in order to prove functionality. This will provide for effective demonstration of
speed calculations, seat belt usage, and braking habits. Alerts generated will need to be
displayed accordingly as the simulated driver displays bad habits. Most importantly however, is
that all the data collected during the simulation will need to be properly profiled and the driver
reports will need to be generated as precisely as possible.
The test harness for the Defensive Driver will stress the real-world algorithms and show
how false positives and other risks have been mitigated. The harness will also display the
information in real-time in order to show the necessary inner workings of the Defensive Driver
prototype. It will consist of a display that will show the current speed of the vehicle, posted
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
10
speed limit, and distance from the vehicle in front of the simulated driver. The test harness will
display alerts when any one of these attributes are out of specs, and will allow for on-the-fly user
input to be inserted into the system. This will allow for the most comprehensive testing platform
for the prototype, and will allow the customer to see everything working together.
1.3 Definitions, Acronyms, and Abbreviations
Accelerometer: A reference to the piezoelectric accelerometer used in the H.E.A.R.T. device.
ALDB: Abbreviation for Alerts and Logs Database. A database used on both On-Board Unit and
Client Software which allows for historical data storage of users and their data.
(the) Box: A specific set of coordinates on a map that will identify a maximum posted speed
limit and stop sign location.
Algorithms: A set of algorithm provided to evaluate the safety of an individual’s driving habits.
Implemented within the Runtime Data Processing Module.
CF: An abbreviation for Compact Flash. A non-volatile type of memory that is commonly used
for Operating System and firmware storage of devices.
(the) Client Software: Software components of the Defensive Driver which will run on a
customer’s PC and provide profiling and reporting capabilities.
CPU: An abbreviation for Central Processing Unit. The microprocessor of both a customer’s PC
and the Defensive Driver On-Board Unit.
Defensive Driver: The Defensive Driver is a proposed solution to evaluate the current driving
habits of an individual and equip him with a long-lasting set of safe driving skill.
Defensive Driver Prototype: A modeled environment which will serve as a test-bed for
Defensive Driver product. The environment will processor simulated and real-time input apply
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
11
appropriate algorithms and generate output. Goal is proving functionality of the real-world
product.
(the) Device: See Defensive Driver.
Disk Drive: See Hard Drive.
DMS: Driver Monitoring Station. The PC of each client where the Client Software will be
installed.
DMV: An abbreviation for Department of Motor Vehicles.
Driver Education: Class that teaches new drivers how to properly drive.
Driver Improvement Clinics: An education institution that rehabilitates drivers with bad habits.
Driver Profile: All historical data on a driver.
Driving Attributes: Reflexes, and reaction times relevant to a driver.
DSM: An abbreviation for Database Synchronization Module. The component of the Client
Software that will ensure database consistency.
Erratic Lane Change: Changing lanes erratically.
ECU: An abbreviation for Engine Control Unit. The main microcontroller within a vehicle that
coordinates numerous driving parameters and exports them to external devices.
End-User: Driver behind the wheel.
False Positives: Recording of an infraction that did not actually happen.
Feedback: See Performance Report.
(the) Fingerprint Reader: A scanning sensor for reading biometrical user data and provide and
authentication layer for the Defensive Driver.
Flash Memory: See CF.
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
12
GUI: An abbreviation for Graphic User Interface. GUI refers to the displaying for the
informative reports.
Historical Data: Data recorded on the Logs and Alerts Database; kept for future reference and
profile updates.
GPS: An abbreviation for Global Position System. A GPS receiver will be embedded within the
On-Board Unit to allow location tracking of a vehicle in motion.
Hard Drive: The non-volatile memory storage of a computer system.
Infraction: The breaking of a traffic law.
Insurance Companies: Risk management company.
Internet: Global system of connected computer networks.
(the) Laptop: See LCU.
LCD: An abbreviation for Liquid Crystal Display. A display technology that will be used for the
On-Board Unit of the Defensive Driver.
LCU: An abbreviation for Laptop Computer Unit. The main hardware component of the
Defensive Driver Prototype. The laptop will be used to provide the hardware and software
integration for the prototype.
MFCD: An abbreviation for Major Functional Components Diagram. A diagram representing
the main integral elements of the design of a product.
NHTSA: An abbreviation for National Highway Transportation Safety Administration. A branch
of the Department of Transportation involved with establishing safety requirement in the US
automobile industry. Specifically, the agency directs the highway safety and consumer programs
established by the National Traffic and Motor Vehicle Safety Act of 1966, the Highway Safety
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
13
Act of 1966, the 1972 Motor Vehicle Information and Cost Savings Act, and succeeding
amendments to these laws.
OBD-II: On-Board System. The interface that provides data access to the Engine Control Unit
of a vehicle.
OBU: Abbreviation for On-Board Unit. The hardware component of the Defensive Driver that
will reside inside of a vehicle. This unit will provide real-time monitoring of a driver’s
performance.
OS: An abbreviation for Operating System. The first application that loads when a computer
starts and facilitates the communication between devices and user.
PC: An abbreviation for Personal Computer. Each customer will need to provide a PC station
for installation of the Client Software.
Performance Report: Report generation capabilities presenting the current performance
statistics regarding the safety habits of an end-user.
(the) Profile: A user-specific set of information referring to his long-turn performance.
(the) Prototype: See Defensive Driver Prototype.
RAM: Random Access Memory. A form of volatile computer storage memory.
RDPM: An abbreviation for Runtime Data Processing Module. The main component of the
OBU’s software application.
RWP: Real-World Product. The final result of the Defensive Driver initiative.
SD: An abbreviation for Secure Digital. A non-volatile type of memory that is available if large
sizes and used for portable devices storage.
SDHC: An abbreviation for Secure Digital High Capacity. A version of Secure Digital memory
that provides for large size inexpensive memory banks to be manufactured.
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
14
SDRAM: An abbreviation for Synchronous Dynamic Random Access Memory. A type dynamic
random access memory card that allows for easy transfer of data to computer devices.
Sensor: Device that measures some physical quantity.
Sensor Network: Network of distributed sensors.
Speed Limit Database: A database that will store location of posted speed limits. A copy will
be stored on the On-Board Unit for real-time speed comparison. It will be later updated to reflect
new speed signs for the value modifications of current signs in a certain region.
Stop Sign Database: A database that will store location of posted stop limits. A copy will be
stored on the On-Board Unit for real-time stop sign detection. It will be later updated to reflect
new speed addition or removal of stop signs in a certain region.
(the) System: See Defensive Driver.
Tailgating: Driving too closely behind a vehicle.
Test Harness: Software module of the Defensive Driver Prototype which will be used to
generate sample data sets and test overall algorithm and feature operations.
Touch Screen: A functionality of a display unit to provide user input through physical contact of
a finger or stylist. Will be used as a part of the user input for the On-Board Unit of the Defensive
Driver.
(the) Unit: See OBU
USB: Universal Serial Bus. A standard interface for host and devices interconnectivity.
VDOT: An abbreviation for Virginia Department of Transportation. Government agency
responsible for maintaining roads and bridges in Virginia.
[This Space Intentionally Left Blank]
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
15
1.4 References
Department Of Motor Vehicles, DMV. (2008).
Virginia driver action contributing to the crash 2001 - 2008. Retrieved from
http://www.dmv.state.va.us/webdoc/safety/crash_data/total/pdf/driver_action.pdf
National Highway Traffic Safety Administration, NHTSA. (2008).
Traffic saftey facts. Retrieved from http://www-nrd.nhtsa.dot.gov/Pubs/811162.PDF
Sentinel Incorporated. (2009).
Defensive driver description. Norfolk: Old Dominion University.
1.5 Overview
This product specification document provides a comprehensive explanation of the
Defensive Driver prototype’s hardware, software, internal and external interfaces, capabilities,
and features. The information provided in the following sections will explain in detail how the
internal and external architecture is designed, and how it works. This includes all hardware,
software, and interfaces associated with the prototype.
Due to limitations, the prototype will use a GUI, GPS receiver, distance sensor,
monitoring algorithms, and simulated OBD-II data. It will also use a MySQL database. It will
consist of a GUI for the OBU, Client Software, and the test harness. These interfaces will be
used in conjunction with each other to simulate a driving scenario meant to stress our monitoring
algorithms and prove the Defensive Driver’s capabilities.
2 General Description
The Defensive Driver prototype will effectively demonstrate the key features of the realworld product. It will perform real-time monitoring and reporting of simulated driving data from
all essential sensors present in the real world product. The prototype will provide an in-depth
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
16
driver analysis and profile for any number of driving scenarios. It will also be able to store the
data provided and produce a historical analysis of the simulated drivers to show how a driver’s
habits are progressing over time.
In order to limit the scope of the prototype, it will be necessary to eliminate non-essential
components of the real-world product. The algorithms to be eliminated in the prototype will be
the erratic lane change, headlight usage, and proper turn procedure algorithms. The
accelerometer is the only hardware component that will not actually be on or simulated in the
prototype. It will not be on the prototype because it is deemed a non-essential component in
proving the real-world product’s capabilities.
Many of the real world product hardware components will be simulated using databases
containing real world data. This will allow for ease of demonstration when using the prototype
and will allow customized scenarios to be created at the customer’s request. The simulated
hardware in the prototype can be seen in Table 1. No software will be simulated as the
monitoring, alert generating, and driver profiling algorithms are essential to the success of the
Defensive Driver. Therefore, these will be the fully functional algorithms that will appear in the
real-world product.
2.1 Prototype Architecture Description
Figure 2 shows the MFCD of the Defensive Driver prototype. As shown, each of the
prototype’s components, the OBU and the client software, will be loaded onto separate Laptop
Computer Units (LCU). Each of the two LCUs, will be running a separate part of the Defensive
Driver prototype.
[This Space Intentionally Left Blank]
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
17
Figure 2. Prototype Major Function Component Diagram
The OBU will be simulated in the following way using one of the two LCU’s. The LCD,
provided with the LCU, will be used to display the prototype GUI and all associated data.
Imbedded audio speakers will allow the corresponding audio to be played when an alert is
generated. The fingerprint reader, located on the LCU, will provide authentication for the
prototype. Processing of the OBU data will be completed by the Central Processing Unit (CPU).
It will be used to simulate the functionality of the ARM processor used in the real-world product.
The LCU’s external memory will be a removable SD memory card. This component will allow
the data generated during the simulation to be transferred to another computer containing the
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
18
client software. The internal memory will hold the OBU Alerts and Logs, Speed Limit, and Stop
Sign databases. It will also contain the Runtime Data Processing Module, which contains all the
algorithms used in the prototype. Finally, the GPS receiver and distance sensor will provide
real-world data for the prototype simulations.
The Client Software will be simulated on the second of the two LCU’s in the following
manner. The LCD, component of the LCU, will display all pertinent information related to the
Client Software. Processing for the client software will be provided via the internal CPU. The
internal memory will hold all other components of the client software. The Alerts and Logs
Database associated with the client software will be a repository for all information transferred
from the OBU. The User Profiling and Improvement Module will analyze the data received
from the OBU’s SD memory card, and populate the Alerts and Logs Database. Report
generation will be completed by the Report Generation Module. The User View GUI will
display the information needed when running the client software. As shown in Figure 3, the
Data Synchronization Module will synchronize the OBU and the Client Software using a SD
Memory card. Lastly, the Speed Limit and Stop Sign Databases located on the Client Software
will be used to update the OBU databases via the Data Synchronization Module.
[This Space Intentionally Left Blank]
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
19
Figure 3. Data Synchronization Module
2.2 Prototype Functional Description
There are many major functional components of the Defensive Driver prototype. They
are: driver monitoring process, GUI displays, database synchronization, algorithm testing,
secure access, and alert generation. These are all integral pieces of the prototype and will be
verified and tested extensively. Proving the validity of the driver monitoring process, seen below
in Figure 4, is integral to the success of the Defensive Driver prototype. All components of the
prototype will be working together to produce a complete and comprehensive driving simulation.
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
Figure 4. Prototype Process Flow
Laptop
Turned On
Simulation
Running
OBD-II
Database
Speed Limit &
Stop Sign
Manual/
Simulated
Input
Stop Sign
Database
RunTime Data
Processing
Module
GPS
Database
Speed
Limit
Database
Distance
Sensor
Manual/
Simulated
Input
Defensive
Driver
Dashboard
Seat Belft
Toggle Manual/
Simulated
Input
Simulation
Display
Y
Simulation
Still Running
N
Test Harness
Pass Data to
Report
Generation and
Analysis
Modules
Run User View/
GUI Module
20
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
21
The On-Board Unit GUI map, displayed in Figure 5 below, shows how the OBU GUI
will be organized in the prototype. This GUI will display all the information needed to show
correct functionality of the OBU. The OBU will have a welcome screen that will allow a user to
login or create a new user. After the user is logged in, the OBU information, owner info, driving
display, driver info, and completed session tabs will be available. From this level access to
information about the OBU and the owner, driver information, and completed session statistics
can be achieved. If the driving display tab is selected, more information becomes available.
From the level under driving display, information pertaining to the current speed limit, following
distance, seatbelt usage, and stop sign alerts can be accessed.
Figure 5. On-Board Unit GUI Map
The Client Software GUI map, displayed below in Figure 6, shows the Client Software GUI
structure. The Client Software administrator will be the only person allowed to log into this
GUI. After login, the administrator will have access to information about the Client Software
itself, all units that are used in conjunction with the Client Software, adding new drivers, and
stop sign and speed limit database synchronization. Also, a listing of drivers is available that
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
22
will lead to a driver profiling and reporting screen. This is where information pertaining to
individual driver’s alerts, analysis, statistics, and database syncing will be available.
Figure 6. Client Software GUI Map
The Test Harness GUI, displayed in Figure 7, shows how the prototype test harness GUI will be
set up. The GUI will first display a welcome screen that will allow access to information
pertaining to alerts. Also access to driving controls such as speed, seatbelt toggles, steering, and
braking are available at this level. Road controls are accessible and allow changes to speed
limits, following distance, and stop sign locations.
[This Space Intentionally Left Blank]
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
23
Figure 7. Test Harness GUI Map
Figure 8 shows all of the databases that will reside on the OBU and the Client Software.
The Data Synchronization Module will provide synchroniztion between the OBU and Client
Software databases via a SD Memory card. The master Stop Sign and Speed limit databases will
reside on the Client Software. As such, the OBU’s coresponding databases will be updated when
a synchronization occurs. The master Alerts and Logs databases will reside on the Client
Software as well. The difference here is that when a synchronization occures, the OBU’s
databases will update the master on the Client Software, and the OBU’s databases will be wiped
clean for future use. General Logs, Student, School, and Instructor information will be updated
so that a copy resides on both the OBU and Client Software. This will provide for accurate
reporting of the other information when synchronization occurs.
[This Space Intentionally Left Blank]
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
24
Figure 8. Database Schema
School
PK
School ID
Address
Name
Owner
Student
PK
Student ID
Name
Instructor ID
School ID
Hours Driven
Address
Fingerprint
Instructor
PK
Instructor ID
Name
School ID
Speed Limits
PK
Location ID
Point1 Latitude
Point1 Longitude
Point2 Latitude
Point2 Longitude
Length
Height
MaxSpeed
Stop Signs
Speed Logs
PK
Alert ID
Violation Type
Location ID
Current Speed
Timestamp
Student ID
General Logs
PK
Log ID
Type
Student ID
Location
Timestamp
PK
Location ID
Point1 Latitude
Point1 Longitude
Point2 Latitude
Point2 Longitude
Length
Height
Stop Sign Logs
PK
Log ID
Violation Type
Student ID
Location ID
Timestamp
Distance Log
PK
Log ID
Violation Type
Student ID
Location ID
Timestamp
Current Speed
Disrtance
The monitoring algorithms that need to be stress tested will be held inside of the Runtime
Data Processing Module. This module will be where all of databases and manual inputs will
come together via simulations test the individual algorithms. The Following Too Close, Seat
Belt Usage, Speeding, Stop Sign, Data Synchronization, Analysis Software algorithms will all be
tested in this manner.
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
25
2.3 External Interfaces
This section will identify the physical and logical interfaces used by the Defensive Driver
prototype. The interfaces to be discussed in this section will include the hardware, software, user
interfaces, and the communication protocols of the interfaces. The major hardware interfaces are
the GPS and the distance sensor. The software interfaces include a MySQL DB interface, GPS
software, and distance sensor software. The user interfaces include the LCU, fingerprint reader,
Client Software interface, OBU interface, and the test harness GUI. The communication
protocol used is USB.
2.3.1 Hardware Interfaces
The hardware interfaces used in the Defensive Driver prototype are a GPS and distance
sensor. The GPS interface is a BU-353 GPS receiver. This unit utilizes a SIRF Star III GPS
chipset which allows for coordinate accuracy to within fiver meters of actual location. The time
to get an actual location fix, Time to First Fix, is extremely fast with this model, even with a low
signal level. This device connects to the LCU via a USB connector. Although USB provides
480 MBs transfer rate, this GPS will only support a baud rate of 4800. The USB can connect to
up to 16 different satellites in order to receive its coordinates. This allows the prototype to utilize
the best real-world data available for use in the simulations.
The distance sensor interface being used in this prototype is the Vernier Go! Motion.
This sensor uses ultrasonic pulses to determine the distance of an object in front of it. The Go!
Motion connects to the LCU via a USB connecter, and can sample distance data in the
millisecond range. This allows a highly customizable interface for the prototype to pull
information from. This particular model has a maximum range of around four meters. The
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
26
signal is converted into usable by an open source library that used by the Runtime Data
Processing Module.
2.3.2 Software Interfaces
The software interfaces used in this prototype are a MySQL Database, GPS software, and
distance sensor software interface. The MySQL Database interface will be run via the Runtime
Data Processing Module. It will be able to push and pull data from the database in real-time
using the corresponding MySQL commands.
The GPS software interface is an open source project called GPS-NMEA Monitor v1.60.
This software allows the logging of GPS data at the rate of twice a second. It displays latitude
and longitudinal coordinates along with time stamps, direction, and speed. All information is
sent to a .txt file in which all the information is delimited by a comma. This allows the prototype
to easily parse through the flat file containing the real-world data.
The distance sensor interface is software created by Sentinel Inc. hardware personnel.
This software uses a library provided by the hardware manufacturer called GoIO_DLL.dll. It is
then used in a C program to interpret and display distance information in real time using POSIX
threads. This information is then sent to the Runtime Data Processing Module to be used in
determining alerts and logs entries.
2.3.3 User Interfaces
The Defensive Driver prototype has six user interfaces. They are the LCU, fingerprint
reader, Client Software interface, OBU interface, test harness interface, and GUI. The LCU
contains a keyboard and mouse for direct access to the prototype information and manipulation
software. It also has a LCD to display critical information about the prototype to the user. The
fingerprint reader is embedded in the LCU and allows the user to authenticate with the prototype
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
27
by swiping a finger across the reader. This is safer and more reliable than a password system.
The Client Software interface, seen in Figure 6, shows how the GUI is set up and allows access
to different portions of the prototype. The OBU interface, show above in Figure 5, show the
GUI map and how a user will be able to interface with the OBU. The test harness interface,
shown in Figure 7, explains how the test harness is designed and allows for a user to manipulate
different aspects of the prototype.
2.3.4 Communications Protocols and Interfaces
There are two communication protocols used in this prototype, USB 2.0, and NMEA
0183. The USB 2.0 protocol is responsible for high transfer rates between plug-and-play
devices. Both the GPS receiver and the distance sensor utilize this protocol. NMEA 0183 is a
serial communication protocol used by the GPS receiver to send and receive messages too and
from the GPS device. It uses ASCII to define how data is transmitted from one device to
another. Typical Bit rate for this protocol is 4800 bits per second.
3 Specific Requirements
The following sections describe the specifics of the functional, performance, and nonfunctional requirements. It also talks about assumptions and constraints in regard to the
Defensive Driver prototype. In order for the prototype to be successful, all functional
requirements will have to be met. The non-functional requirements will deal with security,
maintainability, and reliability.
3.1 Functional Requirements
The functional requirements of the Defensive Driver prototype will define the capability
and behaviors associated with the system. Each functional area will contain individual
requirements describing a part of the prototype. The functional requirements will include
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
28
monitoring algorithms, analysis algorithms, report generation algorithms, database
synchronization algorithms, and GUI interfaces.
3.1.1 Algorithms
The monitoring, analysis report generation, and synchronization algorithms are at the
heart of the Defensive Driver prototype. These algorithms will be able to monitor a driver’s
actions through a driving scenario and produce detailed analysis of the events. They will also be
able to synch the databases located on two different systems via a SD Memory card. The
algorithms that the Defensive Driver prototype will utilize are speeding, following too closely,
seat belt usage, stop sign, “In the box”, and analysis and reporting.
3.1.1.1 Formulas
The following formulas will be used to determine speed, speed limit box size, and
stop sign box size. These are going to be used in our speeding and stop sign
algorithms and will conform to the following functional requirements.
1. Speed
Driver speed will be determined by the following formula:
80mph *
0.44704meter / sec ond
meters
 35.76
1mph
sec onds
1. Speed Limit Box Size
Speed limit box size will be determined by the following formula:
40
meters 1sec onds
*
 40 meter box size
sec ond check
2. Stop Sign Box Size
Stop sign box will be determined by the following formula:
2 * 40 meters = 80 meter box size
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
29
3.1.1.2 Speeding Algorithm
The purpose of the speeding algorithm will be to determine if a driver is speeding
or not. The Speeding Algorithm will adhere to the following functional
requirements.
1. Driver Speed
The Driver’s Speed will be collected from GPS data in Mph
1. Mph
Mph will be represented by an integer
2. Maximum Speed Limit
1.
Maximum speed limit will be set in the database based on last
known speed limit change
2.
If speed limit has changed pull new speed limit from the database
via MySQL request
1. Pulled from database
Request current speed limit from the database via MySQL
request
3. Driver Locations
Check new GPS location from flat file
[This Space Intentionally Left Blank]
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
Figure 9. Speeding Algorithm Process Flow
Collect GPS
Location
Data
Collect Driver
Current Speed
Has Max Speed
Limit Changed?
Yes
No
Find New Max
Speed Limit
from Internal
DB
Update
Current Max
Speed
No
Has the Driver
been Speeding?
No
Yes
Record End
Time of
Speeding
Event
Is the Driver
Speeding?
Yes
Has the Driver
Been Speeding?
No
Record Start
Time;
Alert Event
3.1.1.3 Following Too Closely Algorithm
The following too closely algorithm will determine if a driver is following too
closely to a car in front of him. The algorithm will adhere to the following
functional requirements.
1. Driver Speed
Receive driver’s speed from GPS data flat file
2. Driver Distance
Receive driver’s distance from Go! Motion sensor
30
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
31
3. Safe Driving Distance
1. Determine safe driving distance via one standard car length for every 10
mph of speed
2. Give alert if needed in form of visual and/or audio
Figure 10. Following Too Close Process Flow
OBD-II
Database/
Manual
Input
Retrieve Driving Data
Collect
Current
Speed
Collect
Distance from
Vehicle Ahead
Is the Distance
Safe?
Yes
Lambda
Transition
Store event
log in driver
history
No
Alert driver to
maintain a
safe distance
3.1.1.4 Seat Belt Algorithm
The seat belt algorithm will determine if a driver is following too closely to a car in front
of him. The algorithm will adhere to the following functional requirements.
1. Seat Belt On?
1. Check seat belt toggle
2. Issue alert if toggle is not engaged
[This Space Intentionally Left Blank]
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
Figure 11. Seat Belt Engagement Process Flow
Unit Turns
on
Seat Belt
Engaged?
Record
Event
Alert Driver
No
Yes
Wait 30
Seconds
Yes
Seat Belt
Engaged?
No
Record
Event
3.1.1.5 Stop Sign Algorithm
The stop sign algorithm will determine if a driver is completely stopping at a stop sign.
The algorithm will adhere to the following functional requirements.
1. Driver Location
1. Receive driver location form GPS flat file
2 “Are you in the box?” Algorithm
1. Compare GPS location to stop sign database
1. ID trigger returned
2. No ID trigger returned
[This Space Intentionally Left Blank]
32
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
Figure 12. “Are you in the Box?” Process Flow
No
Collect GPS
Location
Compare GPS
Location to
Internal Database
Was a Trigger Box
ID Returned?
No
Yes
Record Trigger ID
Number
Was an Event Box
ID Returned?
Yes
Does the Event ID
match Trigger ID?
No
3. Determine Stop
1. Stop
Do Nothing
2. No Stop
Record Event and Issue Alert
[This Space Intentionally Left Blank]
Yes
Monitor for Event
33
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
34
Figure 13. Stop Sign Violation Process Flow
No
Compare Data
to Stop Sign
Internal
Database
Collect GPS
Location
Data
Driver in
A Stop Sign
Box?
Yes
Save
Trigger ID
Yes
Trigger
Box?
No
No
Event
Box ID match
Trigger ID?
Yes
Yes
Did Driver
stop?
No
Send Alert
Record
Event
3.1.1.6 Analysis Algorithm
The driver analysis algorithm will analyze a driver’s information and generate a driving
report. The algorithm will adhere to the following functional requirements.
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
Figure 14. Analysis Algorithm
1. Event Type
Receive event type from MySQL database
1. Following Too Closely
2. Speeding
3. Stop Sign
4. Seat Belt
2. Frequency of Event
35
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
36
Receive the frequency of event from MySQL database
3. Duration of Event
Receive the duration of event from MySQL database
4. Improvement
Record events were improved
5. Decline
Record events declined
1. Events that displayed a decline
What events displayed a decline
6. Most common Mistakes
Determine most common mistakes
7. Report Generation Algorithm
Generate report and display graphical data
3.1.2 GUI Interfaces
The GUI interfaces provides a user interaction interface with the Defensive Driver
prototype. There will be an OBU, Client Software, and a Test Harness GUI interface. These
interfaces will adhere to the following functional requirements.
1. OBU Welcome/Login Screen
1. Will provide instructional text for logging in
2. Will allow user to swipe finger for authentication
1. Allow user to insert information if a new and input fingerprint
1. About Screen
1. Will allow user to view information about OBU provided authenticated
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
2. Owner Information Screen
1. Will allow user to view information describing the owner of an OBU
provided authenticated
3. Driving Display Screen
1. Will display pertinent information about vehicle to authenticated user
1. Show distance from car in front in meters
2. Show current speed in mph and current speed limit in mph
3. Show direction in degrees and location in GPS coordinates
4. Show seatbelt engagement
5. Show upcoming stop signs
2. Speed Limit Alert
1. Display alert, in mph, if vehicle is driving too fast
1. Display current speed in mph
2. Display current speed limit in mph
3. Following To Closely Alert
1. Will display alert with distance from car in meters
4. Seatbelt Alert
1. Will display alert if seatbelt is not engaged
5. Stop Sign Alert
1. Will display stop sign alert stating that a full stop was not
completed
4. Driver Info Screen
1. Will display information about a driver to authenticated user
37
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
5. Database Synchronization Screen
1. Will automatically synchronize if SD Card is inserted
2. Will display progress bar
6. Completed Session Screen
1. Will show save progress bar
2. Will shut down program automatically
3. Will display shutdown message
2. Client Software Welcome/Login Screen
1. Will allow user to enter username and password
2. Will not allow unauthorized access
1. About Screen
1. Will display information about client software to authenticated user
2. List of Units Screen
1. Will display list of all units and associated drivers
3. List of Drivers Screen
1. Will display list of all drivers and associated units
1. Driver Profile & Report Processing Screen
1. Will display reports about each driver
1. Display Alerts Screen
1. Will display list of alerts issued for driver during a
session
2. Will organize list by date and time
2. Driver Analysis Screen
38
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
39
1. Will display analysis of driver habits in .doc format and
display on screen.
3. Driver Statistics Screen
1. Will display historical statistical analysis of driver
4. Alert Database Synchronization Screen
1. Will synchronize alerts database with SD Memory card
4. New Driver Screen
1. Will allow manual entry of a new driver’s information
1. Driver name
2. Unit number
3. Other pertinent info
5. Stop Sign/Speed Limit Database Synchronization Screen
1. Update user table
2. Update Speed Limit and Stop Sign Database
3. Display progress bar
4. Display success or failure alert
3. Test Harness Welcome Screen
1. Driving Control Screen
1. Allow access to car controls
1. Manually increase speed
2. Manually change seatbelt toggle
3. Manually change steering
4. Manually apply brakes
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
40
2. Display Alerts Screen
1. Will show alert window for alert issued
3. OBU Screen
1. Will show entire OBU prototype and information
4. Road Controls Screen
1. Manually adjust road conditions
1. Manually change speed limit
2. Manually change vehicle distance in front
3. Add stop sign location
3.2 Performance Requirements
The following performance requirements will be used to measure the algorithms,
capabilities, and speed of the Defensive Driver prototype. Each requirement will provide
numerical bounds, if applicable. Every performance requirement will be specifically bound to an
individual functional requirement of the prototype.
3.2.1 GPS Real-Time Data
1. Defensive Driver’s GPS data will meet the following accuracy requirements.
1. Provide accuracy to within five meters of location
3.2.2 Speed Limit Algorithm
1. Defensive Driver’s speed limit detection range will meet the following performance
requirement.
1. Detect the posted speed limit every second
3.2.3. Stop Sign Algorithm
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
41
1. Defensive Driver’s stop sign detection range will meet the following performance
requirement.
1. Be able to detect a stop sign every second
3.2.4 Following Too Closely Algorithm
1. Defensive Driver’s following too closely algorithm will meet the following
performance requirement.
1. Be able to check distance from car in front every two seconds
3.2.5 Seat Belt Algorithm
1. Defensive Driver’s seat belt algorithm will meet the following performance
requirement.
1. Be able to check set belt engagement within 30 seconds of powering on
3.3 Assumptions and Constraints
Due to limitations and constraints on our equipment and time, the Defensive Driver
prototype will be operating under the following assumptions and constraints. That speed limit
signs will not be located less than 40 meters apart. Our algorithm would not be able to detect
them within this constraint. Stop signs must be located outside of 80 meters from each other. A
driver will not exceed 80 mph during the testing of the prototype. This is where the minimum
distances come into play with the stop signs and speed limits. Input and output standards are
backwards compatible. We are assuming that the Virginia driving manual rules are adequate for
basing alert generation on them. OBD-II data is correct and timely. We are also assuming that
the speed limit and stop sign databases are correct from VDOT.
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
42
The constraints we are working under are that we are using a USB GPS, and not an actual
GPS unit with a display. This limits our accuracy and data gathering capabilities. We also have
to simulate our driving events, as our system is not yet portable enough to use in a car.
3.4 Non-Functional Requirements
The non-functional requirements are the supporting functionalities of the prototype that
help to support the functional requirements. Ease of use is important, as customers will need this
when dealing with our product. The easier it is to use, the better. Security is important to keep
the integrity of the system. Maintainability and reliability are important in any product. These
will keep a customer happy and allow expansion of the current product if needed.
3.4.1 Ease of Use
Ease of use is important to the Defensive Driver because it has such a complex
background. Without ease of use, a user could easily get frustrated and not use the system,
resulting in a drop in customer base. Also, the system needs to be easy to use for the person
being monitored, so that they can get the maximum benefit from it.
3.4.2 Security
Security is important to the prototype because it will prove system integrity. It will not
allow unauthorized access to sensitive information, and will cut down on the malicious
corruption of a driver’s profile by an unauthorized user. Also, having a person access their own
information without supervision could result in less than truthful changes being made. This will
be facilitated by the fingerprint authentication on the OBU, and username and password in the
Client Software.
Running head: LAB 2 – DEFENSIVE DRIVER PRODUCT SPECIFICATION
43
3.4.3 Maintainability
The maintainability of a product is directly related to its lifespan. If the Defensive Driver
is unable to expand with need, then customers could become disinterested. Maintaining parts
availability and low maintenance costs are important, and will help to expand customer base and
improve our product. Defensive Driver will have to be able to change with new protocols and
standards. Also be easily repairable if needed, as not all units will be in direct control of the
owner at all times.
3.4.4 Reliability
Reliability of the Defensive Driver will be measured by how well it does its job. It will
have to monitor all events correctly and display proper alerts when needed. Also, maintaining a
correct logs database is important, as this is important information. Generating proper charts and
graphs, and maintaining a reliable database will need to be commonplace as well.
4. Appendix
[This Space Intentionally Left Blank]