Running head: LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
Lab 2 – Defensive Driver Prototype Product Specification
Barbara A. Dixon
CS410
Professor Janet Brunelle
Old Dominion University
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
2
Table of Contents
1
Introduction ....................................................................................................................5
1.1 Purpose...........................................................................................................................7
1.2 Scope ..............................................................................................................................11
1.3 Definitions, Acronyms and Abbreviations ....................................................................11
1.4 References ......................................................................................................................16
1.5 Overview ........................................................................................................................16
2.0 General Description .......................................................................................................17
2.1 Prototype Architecture Description ...............................................................................17
2.1.1 On-Board Unit .............................................................................................................17
2.1.2 Client Software ...........................................................................................................19
2.2 Prototype Functional Description ..................................................................................20
2.2.1 Prototype Process Flow...............................................................................................20
2.2.2 Graphical User Interface (GUI) Maps ........................................................................22
2.2.3 Database Schema ........................................................................................................24
2.3 External Interfaces .........................................................................................................26
2.3.1 Hardware Interfaces ....................................................................................................26
2.3.2 Software Interfaces .....................................................................................................26
2.3.3 User Interfaces ............................................................................................................26
2.3.4 Communication Protocols and Interfaces ...................................................................27
3 Specific Requirements ......................................................................................................27
3.1 Functional Requirements ...............................................................................................27
3.1.1 Algorithms ....................................................................................................................27
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
3
3.1.1.1 Speeding Algorithm .................................................................................................28
3.1.1.2 Following Too Closely Algorithm ...........................................................................29
3.1.1.3 Seat Belt Engagement Algorithm ............................................................................30
3.1.1.4 “Are you in the Box?” Algorithm ............................................................................30
3.1.1.5 Stop Sign Algorithm ................................................................................................31
3.1.1.6 Analysis Algorithm and Report Generation ............................................................32
3.1.2 GUI Interfaces .............................................................................................................34
3.1.2.1 OBU/End User Welcome/Login ...............................................................................34
3.1.2.2 Administrator Welcome/Login ................................................................................35
3.1.2.3 Stop Sign/Speed Limit Database Syncing ...............................................................36
3.1.2.4 Test Harness Welcome ............................................................................................36
3.2 Performance Requirements ............................................................................................37
3.2.1 GPS Real-Time Data....................................................................................................37
3.2.2 Speed Limit Algorithm ...............................................................................................37
3.2.3 Stop Sign Algorithm ...................................................................................................37
3.2.4 Following Too Closely Algorithm ..............................................................................38
3.2.5 Seat Belt Algorithm ....................................................................................................38
3.3 Assumptions and Constraints .........................................................................................38
3.4 Non-Functional Requirements .......................................................................................39
Figures
Figure 1: Real World Product Major Functional Components Diagram ..............................8
Figure 2: Prototype Major Functional Components Diagram ..............................................18
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
4
Figure 3: Data Synchronization Module ...............................................................................19
Figure 4: Prototype Process Flow .........................................................................................21
Figure 5: On-Board Unit GUI Map ......................................................................................22
Figure 6: Client Software GUI Map .....................................................................................23
Figure 7: Test Harness GUI Map ..........................................................................................24
Figure 8: Database Schema ...................................................................................................25
Figure 9: Speeding Algorithm Process Flow .........................................................................28
Figure 10: Following Too Close Process Flow .....................................................................29
Figure 11: Seat Belt Engagement Algorithm Process Flow .................................................30
Figure 12: “Are you in the Box?” Process Flow...................................................................31
Figure 13: Stop Sign Violation Process Flow .......................................................................32
Figure 14: Analysis Process Flow.........................................................................................33
Tables
Table 1: The Defensive Driver Real-World Product and Prototype Comparison .................10
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
1
5
Introduction
According to the National Highway Traffic Safety Administration (NHTSA) (2008):
“Motor vehicle travel is the primary means of transportation in the United States,
providing an unprecedented degree of mobility. Yet for all its advantages, deaths
and injuries resulting from motor vehicle crashes are the leading cause of fatalities
accounting for nearly 95 percent of transportation-related fatalities.” (p. 1)
In 2008, the Virginia Department of Motor Vehicles (DMV) reported 36,000 car
accidents, which were caused by common bad driving habits (DMV 2008). According to
the NHTSA, there were 37,261 fatal accidents in 2008, with the majority of those drivers
being 15 to 20 years of age (NHTSA 2008). In addition to fatalities and injuries, the cost
of accidents is astronomical. According to CNN, the cost of accidents per year is $164.2
billion (Clifford 2008), with $40.4 billion of that being speed-related (NHTSA 2008).
Currently, standardized Driver monitoring methods are either limited or not available at
all. Analysis software to record and report a Driver’s habits is also non-existent. The
lack of monitoring methods and analysis software may hinder a motorist’s ambition to
drive safer.
According to Merriam-Webster’s dictionary, a habit is defined as “a behavior
pattern acquired by frequent repetition or physiologic exposure that shows itself in
regularity or increased facility of performance” (Merriam-Webster). It can also be
described as “an acquired mode of behavior that has become nearly or completely
involuntary” (Merriam-Webster). Currently, to acquire a driver’s license in Virginia, the
applicant must first obtain a learner’s permit. This requires that the applicant be at least
15 years and six months of age and pass a written driver’s test. The applicant then
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
6
completes book and driving courses, whether these are offered through the public school
system or a private driving class. After completion of the driving course, the applicant
must complete a Department of Motor Vehicles (DMV) road test, and upon successful
completion, a judge will grant the applicant a driver’s license. After obtaining the
driver’s license, the Driver must also obtain automobile insurance. Throughout this
process, there is no tangible way to ensure safe consistent driving habits. In driving
courses, the motorist learns the proper techniques of driving from a ride-along instructor,
but does not have sufficient time to acquire safe driving habits. A Driver’s habits are
only realized to be unsafe when a ticket or citation is issued. In many cases, a traffic
citation will result in a Judge ordering the Driver to attend a driving clinic. A driving
clinic is a means of rehabilitation to refresh the Driver with proper driving techniques.
Sentinel Inc. has designed The Defensive Driver, which provides the Driver with
a means to monitor, record and analyze their driving habits. Initially, the Driver must
create a profile that will be used for authentication. While driving, the Defensive Driver
will monitor particular driving factors by using analysis of real-time sensor data. This
data will often be compared to reputable databases to determine if the Driver is
displaying improper or unsafe driving techniques. When the Driver is displaying these
techniques, the Defensive Driver will issue alerts, audio and/or visual, that will inform
the Driver about their unsafe driving. The patterns and alerts of the Driver will be
recorded and used for analysis of their driving habits. After the Defensive Driver learns
the motorist, it will be able to determine improvement in the Driver’s habits based on a
documented analysis.
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
7
The Defensive Driver will primarily be used by driver education schools, both
driving courses and driving clinics, and insurance companies. Driver education courses
will utilize the Defensive Driver as a safe habit enforcer, to instill safe driving techniques
within new Drivers. Driver rehabilitation clinics will employ the Defensive Driver as a
tool to aid in the redevelopment of safe driving habits. Automobile insurance rates
usually increase when a traffic citation is issued. The Defensive Driver allows insurance
companies to determine whether a Driver is displaying safe driving habits and is possibly
eligible for lower insurance rates.
1.1
Purpose
Sentinel, Inc. will develop a Defensive Driver Prototype that will provide real-
time monitoring and reporting, historical analysis, driver profiling and driver
improvement monitoring. The major components for the Defensive Driver are identified
in Figure 1. This diagram shows the hardware, software and interfaces that define the
system.
{This space is intentionally left blank.}
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
Figure 1: Real World Product Major Functional Components Diagram
Table 1 describes the differences in features, hardware and software. The realtime monitoring feature for the Real-World Product will provide real-time sensor data
correlation when the vehicle is in motion, whereas the Prototype will provide simulated
sensor data correlation. The Erratic Lane Change, Failure to Use Headlights and
Improper Turn algorithms will all be eliminated from the Prototype. The use of the
8
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
9
accelerometer will also be removed from the Prototype. To demonstrate the functionality
of the Prototype, Sentinel Inc. will conduct a simulated driving session in a controlled
environment where the Driver is displaying unsafe driving techniques. The Prototype
will consist of a laptop and the Defensive Driver software. The laptop will essentially
represent the capabilities of the LCD Touchscreen, fingerprint reader, audio speakers and
integrated RAM and hard drive. The input from the OBD-II will be simulated and the
Speed Limit and Stop Sign Databases will be scaled-down to focus on the specific
location of the controlled environment.
{This space is intentionally left blank.}
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
10
Table 1: The Defensive Driver Real-World Product and Prototype Comparison
Features
Final Product
Prototype
Real-time monitoring
Real-time sensor data correlation when
vehicle is in motion
Simulated sensor data correlation with
pre-loaded inputs
Driver Analysis/Driver Profiling
Fully Functional
OBU
Hardware
Final Product
Prototype
GPS
On-board Unit (OBU) embedded receiver
External receiver with USB interface
Fingerprint reader
Embedded in OBU
Laptop component
Accelerometer
OBU component
Not in prototype
Distance Sensor
OBU component
External sensor with USB interface
LCD Touchscreen
OBU Display component
Laptop display
OBD-II
OBU Interface
Simulated database input
Flash and SD Memory
OBU internal/external memory
Laptop memory
Audio Speakers
OBU component
Laptop speakers
Software
Final Product
Prototype
OBU Speed Limit Database
Microsoft Access database to be provided
by VDOT
Database of sample speed limit data for
a limited geographic location
OBU Stop Sign Database
Microsoft Access database to be provided
by VDOT
Database of sample stop sign data for a
limited geographic location
Erratic Lane Change Algorithm
Data Processing Module component
Not in prototype
Failure To Use Headlights Algorithm
Data Processing Module component
Not in prototype
Improper Turns Algorithm
Data Processing Module component
Not in prototype
GPS Coordinates
Lat/Long obtained by embedded GPS
receiver
Lat/Long obtained by external GPS
receiver
Following Too Close Algorithm
Seat Belt Usage Algorithm
Speeding Algorithm
Stop Sign Algorithm
Fully Functional
Client Software
Software
Final Product
Prototype
Speed Limit Database
Microsoft Access database to be provided
by VDOT
Database of sample speed limit data for
a limited geographic location
Stop Sign Database
Microsoft Access database to be provided
by VDOT
Database of sample stop sign data for a
limited geographic location
Data Synchronization
Analysis Software
Fully Functional
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
1.2
11
Scope
Sentinel Inc. is developing a prototype that demonstrates the essentials of the
Defensive Driver. The Prototype will prove that it is possible to record and analyze from
a GPS Receiver and Distance Sensor to simulate driving scenarios. The prototype will
also show that it can provide a historical analysis of the Driver’s habits (both good and
bad).
1.3
Definitions, Acronyms and Abbreviations
Accelerometer: An instrument for measuring acceleration or for detecting and
measuring vibrations.
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 algorithms 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 skills.
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
12
Defensive Driver Prototype: A modeled environment which will serve as a test-bed for
Defensive Driver product. The environment will process simulated and real-time input,
apply 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.
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
13
(the) Fingerprint Reader: A scanning sensor for reading biometrical user data and
provide and authentication layer for the Defensive Driver.
Flash Memory: See CF.
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.
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
14
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 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.
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
15
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.
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.
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
16
(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.
1.4
References
Clifford, Catherine. (2008). U.S. Car Accident Cost: $164.2 billion. Retrieved from
http://money.cnn.com/2008/03/05/news/economy/AAA_study/
CS410 Defensive Driver Documentation
CS411 Lab 1 – Defensive Driver Product Description
Go! Motion Distance Sensor. Retrieved from http://www.vernier.com/go/gomotion.html
Habit. (n.d.). In Merriam-Webster online. Retrieved from http://www.merriamwebster.com/
National Highway Traffic Safety Administration (NHTSA) (2008). Traffic Safety Facts.
Retrieved from http://www-nrd.nhtsa.dot.gov/Pubs/811162.PDF
Virginia Department of Motor Vehicles (DMV) (2008). Driver action contributing to the
crash. Retrieved from
http://www.dmv.state.va.us/webdoc/safety/crash_data/total/pdf/driver_action.pdf
Virginia Department of Motor Vehicles (DMV). Virginia Driver Manual. 1 Jan 2010.
1.5
Overview
The Sentinel Inc. specification document provides information on the capabilities,
features, and configuration of the hardware components and software of the Defensive
Driver Prototype. The goals of the Prototype are real-time monitoring and reporting,
historical analysis, driver profiling and driver improvement monitoring. Due to time and
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
17
financial limitations some of the algorithms and hardware components identified in the
Real-World Product have been eliminated to allow for rapid Prototype development.
And, all driving will be simulated or conducted in a controlled environment.
2.0
General Description
The Prototype of the Defensive Driver will simulate the features and capabilities
of the Real-World Product. The purpose of the Prototype is to show that the Defensive
Driver can be developed and that it is easy to use. The Prototype will use a Laptop
Control Unit (LCU), GPS Receiver and Distance Sensor to simulate driving scenarios
and provide feedback to the end user. While in motion, the Driver is notified of an alert
if they have demonstrated a violation. When this alert is generated, it is recorded as an
event in the Alerts and Logs Database, and will be analyzed for report generation.
2.1
Prototype Architecture Description
The hardware for the Prototype is a LCU that interfaces with a GPS receiver and
Distance Sensor. The software algorithms, analysis software and databases provide a
solid foundation to accurately perform the features of the Defensive Driver. The
information from the Speed Limit and Stop Sign Databases, the simulated GPS and ECU
data, will be directly related to the actions of the algorithms.
2.1.1 On-Board Unit (OBU)
The hardware for the Prototype is a LCU containing a LCD display, audio
speaker, fingerprint reader, CPU, external and internal memory. The LCD display will
provide a visual representation and interaction with the user. It will also relay the visual
alerts generated. The audio speaker will provide the user with audio alerts. The
technology of the laptop’s integrated fingerprint reader is well founded and reliable and
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
18
will be utilized for the LCU. The CPU is the processing component of the OBU and is
integrated in the LCU. The external memory will be the intermediate data storage
between the OBU and Client Software. This will store the short term (driving session)
Alerts and Logs Database and the Speed Limit and Stop Sign Databases, which contains
the GPS coordinates of the Speed Limit Signs and Stop Signs. The internal memory of
the LCU will serve as the data storage for the Runtime Data Processing Module, which
will process the algorithms. The LCU interfaces with a GPS Receiver and a Distance
Sensor. The GPS Receiver will provide GPS coordinates of a simulated vehicle in
motion. The Distance Sensor will provide distance information for objects in front of the
simulated vehicle. The Prototype architecture is described in Figure 2.
Figure 2: Prototype Major Functional Components Diagram
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
19
2.1.2 Client Software
The Client Software will contain the modules for User Profiling and
Improvement, Report Generation, User GUIs and Data Synchronization. The OBU and
Client Software will also store versions of the Speed Limit and Stop Sign databases. It
will also store the comprehensive driving history for the Alerts and Logs Database.
Figure 3 describes the flow of the Data Synchronization Module for the OBU and the
Client Software.
Figure 3: Data Synchronization Module
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
2.2
20
Prototype Functional Description
The Prototype will encompass the LCU, Client Software, Test Harness, GPS
Receiver and Distance Sensor. These items will allow Sentinel Inc. to demonstrate the
functionality of the Defensive Driver system. Through demonstration, the Prototype will
display a driving scenario and will display applicable alerts and then report analysis and
generation.
2.2.1 Prototype Process Flow
The Prototype Process Flow (Figure 4) describes the process when the simulation
is running on the LCU. This simulation encompasses the Run Time Data Processing
Module, which contains simulated (or manual) inputs for Speed Limits, Stop Signs,
Distance Sensor and Seat Belt. It also incorporates the databases for the GPS, OBD-II,
Speed Limit and Stop Sign. The test harness will issue alerts, audio and/or visual, that
warns the Driver when they have performed an unsafe driving technique and allows
Report Generation and Analysis of the data processed.
{This space is intentionally left blank.}
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
21
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
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
22
2.2.2 Graphical User Interface (GUI) Maps
The Graphical User Interface (GUI) Maps for the Defensive Driver Prototype
show the expected layout for the On-Board Unit, Client Software and Test Harness. The
Defensive Driver Prototype will include graphical user interfaces that allow the Driver
login to the On-Board Unit, the Administrator login to the Client Software and Test
Harness (which will be used during the Prototype Demonstration).
The GUI interface for the On-Board Unit (Figure 5) will allow the Driver to login
and setup new users. It will also display information about the Defensive Driver
Prototype and applicable Owner Information, such as first and last name. It will also
display the current Driver’s information (if there are multiple Drivers using the device).
For the Driving Display, it will notify the Driver of any alerts they may have triggered
while driving. The Driver will also notice a completed session window once they have
finished driving.
Figure 5: On-Board Unit GUI Map
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
23
The GUI Interface for the Client Software (Figure 6) will allow only the
Administrator to login. The Client Software will allow the Adminstrator to view a list of
Defensive Driver units that they have access to and the Drivers listed for that device.
This feature will be used by Driving School instructors that have Defensive Driver
devices in multiple vehicles with many different users. The Client Software also allows
the Administrator to add a new Driver. For the Driver Profile and Report Processing, the
Client Software will display alerts and provide a driver analysis and driver statistics
calculated from the alerts generated. Stop Sign and Speed Limit Database Syncing will
allow the Administrator to synchronize the alerts generated by the Drivers with the Stop
Sign and Speed Limit Databases.
Figure 6: Client Software GUI Map
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
24
The GUI Interface for the Test Harness (Figure 7) will display a welcome screen.
The test harness will use Driving Controls to allow manipulation of Speed, Seatbelt
Toggle, Steering Control and Braking Control and will display alerts when violations
have occurred. The test harness will also allow manipulation of the road using Road
Controls such as Changes in Speed Limits, Adding a Vehicle to the road and Adding a
Stop Sign to a road.
Figure 7: Test Harness GUI Map
2.2.3 Database Schema
The Database Schema (Figure 8) shows the relationships for the tables that
support the Defensive Driver Prototype. The Alerts and Logs, Speed Limits, and Stop
Signs databases will capture most of the information needed. The Alerts and Logs
Database will store the alerts generated by violations and allow for historical analysis.
The Speed Limits database will contain the information needed to store the location of a
speed limit sign. The Stop Signs database will contain the information needed to store
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
25
the location of a stop sign. For the Speed Limit and Stop Signs, latitude and longitude of
two points will be required in order to create a “box” that allows the system to determine
which direction the Driver is coming from. This is used to evaluate which stop sign or
speed limit would apply.
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
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
PK
Location ID
Point1 Latitude
Point1 Longitude
Point2 Latitude
Point2 Longitude
Length
Height
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
2.3
26
External Interfaces
The Prototype will utilize hardware, software, user, and communication protocols
and interfaces to demonstrate the Prototype.
2.3.1 Hardware Interfaces
The Prototype uses a USB connector GPS Receiver and Distance Sensor, both of
which will be provided by the Old Dominion University Computer Science Department.
The GPS Receiver will provide simulated GPS coordinates of a vehicle in motion. The
Distance Sensor will provide distance information from objects in front of the simulated
vehicle.
2.3.2 Software Interfaces
The Prototype will interface with a MySQL Database and the software for the
GPS Receiver and Distance Sensor. The GPS Receiver will utilize GPS-NMEA Monitor
Version 1.60, which is available on the Internet at no cost. The Distance Sensor will
utilize software from GoMotion by Vernier, which is no cost “lite” software that comes
with the device.
2.3.3 User Interfaces
The Prototype user interfaces will be the Laptop Control Unit (LCU) and the GUI
Interfaces (referenced in Section 2.2.1). The LCU will contain the interfaces for
fingerprint reader, Client Software, OBU and Test Harness. The fingerprint reader will
provide the user with authentication capability.
{This space is intentionally left blank.}
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
2.3.4 Communication Protocols and Interfaces
The Prototype will require USB protocols for the power and data provider and
specifications for USB 2.0: 480 Mbps maximum bandwidth and USB 3.0: 4.8 Gbps
maximum bandwidth.
3
Specific Requirements
The functional requirements, performance requirements, assumptions and
constraints and non-functional requirements for the Prototype will be described in this
section.
3.1
Functional Requirements
3.1.1 Algorithms
The algorithms applicable to the Prototype are the Speeding Algorithm,
Following Too Closely Algorithm, Seat Belt Engagement Algorithm, “Are you in the
Box?” Algorithm, Stop Sign Violation Algorithm and the Analysis Algorithm. For the
Speeding Algorithm and the Stop Sign Violation Algorithm, formulas needed to be
generated to determine if the Speed Limit or Stop Sign was applicable to the Driver.
Those formulas are stated below.
Speed Limit:
80mph *
40
0.44704meter / sec ond
meters
 35.76
1mph
sec onds
meters 1sec onds
*
 40 meter box size.
sec ond check
Stop Signs:
2 * 40 meters = 80 meter box size.
27
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
28
3.1.1.1 Speeding Algorithm
This algorithm shall provide the Driver a method of determining if current speed
is above the legal posted speed limit. The process flow is identified in Figure 9. The
following functional requirements shall be provided:
1. Must obtain the maximum speed limit from the Speed Limit Database in an
integer.
2. Must output the Driver’s current speed in miles per hour (mph) in an integer
format.
3. Must provide the Driver’s location in GPS Coordinates. (address LAT LONG
– refer to “the box”)
4. **Collect GPS Location Data from…..
5. ** Collect Driver Current Speed from….
Figure 9: Speeding Algorithm Process Flow
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
Collect GPS
Location
Data
Collect Driver
Current Speed
Has Max Speed
Limit Changed?
No
29
Yes
Find New Max
Speed Limit
from Internal
DB
Update
Current Max
Speed
No
Has the Driver
been Speeding?
Yes
Record End
Time of
Speeding
Event
No
Is the Driver
Speeding?
Yes
Has the Driver
Been Speeding?
No
Record Start
Time;
Alert Event
5.1.1.2 Following Too Closely Algorithm
This algorithm shall provide the Driver a method of determining if they are not
maintaining a safe following distance with the vehicle in front of them. The process flow
is identified in Figure 10. The following functional requirements shall be provided:
1. Must provide the Driver’s current speed in miles per hour (mph) in an integer
format.
2. Must obtain the Driver’s distance from the vehicle ahead using the Distance
Sensor.
3. Must determine and notify Driver of a safe following distance based on
current speed.
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
30
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
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
31
5.1.1.3 Seat Belt Engagement Algorithm
This algorithm shall provide the Driver a method of determining if they are have
their seat belt properly secured. The process flow is identified in Figure 11. The
following functional requirements shall be provided:
1. Must determine if the Driver’s seat belt is on.
2. Must allow for a Boolean toggle.
Figure 11: Seat Belt Engagement Algorithm Process Flow
Unit Turns
on
Seat Belt
Engaged?
Record
Event
Alert Driver
No
Yes
Wait 30
Seconds
Yes
Seat Belt
Engaged?
No
Record
Event
5.1.1.4 “Are you in the Box?” Algorithm
This algorithm shall provide the Driver a method of determining if the Driver is
within specified location to determine applicable Speed Limit and Stop Signs. The
process flow is identified in Figure 12. The following functional requirements shall be
provided:
1. Must obtain the Driver’s location in GPS Coordinates.
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
32
2. Must compare the Driver’s location to the Speed Limit and Stop Sign
Databases.
Figure 12: “Are you in the Box?” Process Flow
5.1.1.5 Stop Sign Algorithm
This algorithm shall provide the Driver a method of determining if the Driver
makes a complete stop at a Stop Sign. This Algorithm also utilizes the “Are you in the
Box?” Algorithm. The process flow is identified in Figure 13. The following functional
requirements shall be provided:
1. Must provide the Driver’s current speed in miles per hour (mph) in an integer
format to determine if a complete stop was made.
{This space is intentionally left blank.}
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
33
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
5.1.1.6 Analysis Algorithm and Report Generation
This algorithm shall provide the Driver with a method of analyzing the data
collected. An event is a violation detected by the Defensive Driver. The event types
consist of Speeding, Following Too Close, Stop Sign Violation and Seat Belt Non-
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
34
Engagement. This will collect the event type, frequency of event and duration of event.
A weight will be assigned to an event based on its statistical data. Statistical data is based
on the NHSTA’s top causes of accidents. The analysis will provide an evaluation that
will show improvement or decline in the Driver’s profile. It will also determine which
events were most common. The process flow is identified in Figure 14. The following
functional requirements shall be provided:
1. Must determine type of event.
2. Based on type of event, must collect event specific statistical data.
3. Based on event collected, the weight will be calculated
Figure 14: Analysis Process Flow
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
Start
Event
Data
Collect
Event
Statistical
Data
Calculate
Weight
Collect
Duration/
Frequency
Calculate
Driver
Points
Collect Date
Next Date?
No
Record
Event as
Declined
No
Have Points
Decreased Over
Time?
Yes
Generate
Driving
Report
Record
Event as
Improved
{This space is intentionally left blank.}
35
Record
Points
Yes
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
36
3.1.2 GUI Interfaces
This section describes the GUI interfaces for the Prototype Demonstration. The
OBU/End User Welcome/Login, Administrator Welcome/Login, Stop Sign/Speed Limit
Database Syncing and Test Harness Welcome will allow the user to generate a
simulation.
3.1.2.1 OBU/End User Welcome/Login
This is a welcome screen for the end user. This screen enables fingerprint
authentication. Refer to Section 2.2.2 for the GUI Map. The following information
describes the intent of each window.
New User: Automatic and/or manual via button on welcome screen. If manual,
then type user’s name. Gather fingerprint for authentication.
About: Describes the unit and software.
Owner Information: Identifies the owner of the unit.
Driving Display: Shows the distance from the vehicle ahead of them; speed and
posted speed limit; direction and location; seatbelt engagement; and upcoming
stop signs. It generates alerts for:
-
Speed Limit - warning the Driver that they are driving too fast,
showing the posted speed limit and current speed.
-
Following Too Close – warning the Driver they are too close to the
vehicle ahead of them, showing the distance and current speed.
-
Seat belt – warning the Driver to properly secure seat belt.
-
Stop Sign – warning the Driver to completely stop at an approaching
stop sign.
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
37
Driver Info: Identifies the current Driver of the vehicle.
Database Synchronization: Automatic on login, shows a progress bar and warns
the Driver not to remove the memory card until synchronization is complete.
Completed Session: Automatic on shutdown, shows a saving progress bar and
warns the Driver not to remove the memory card until synchronization is
complete.
3.1.2.2 Administrator Welcome/Login
This is a welcome screen for the administrator. This screen utilizes fingerprint
authentication. Refer to Section 2.2.2 for the GUI Map. The following information
describes the intent of each window.
About: Describes the unit and software.
List of Units: A list of all Units cross-referenced with the list of Drivers.
List of Drivers: A list of all Drivers cross-referenced with the list of Units. This
also includes a Driver Profile and Report Processing window that is unique to
each driver and shows the following buttons to access sub-categories.
-
Display Alerts – shows a list of each alert issued during a session.
This is organized by date and time.
-
Driver Analysis – generates and displays an analysis of the Driver’s
habits. This is presented in Microsoft Word format and shown in a
reading pane.
-
Driver Statistics – displays a statistical analysis of the Driver.
-
Alert Database Syncing – manual and/or automatic, takes alerts off of
SD memory card and saves them to the database linked to the Driver.
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
38
New Driver: Manual and/or automatic (if from SD automatic; otherwise manual).
Enter Driver name, unit number and other information.
3.1.2.3 Stop Sign/Speed Limit Database Syncing
Automatic and/or manual. All updates to the User Table and Speed Limit and
Stop Sign tables are pused to a NewUser table, NewSpeedLimits Table and
NewStopSigns table. When SD is plugged in, a progress bar appears and the databases
are synced. A success/failed message appears when algorithm is finished.
3.1.2.4 Test Harness Welcome
The Test Harness Welcome screen provides a short description of the Defensive
Driver Prototype and explains how to use the test harness. The following information
describes the intent of each window.
Driving Controls: This window allows the user to access the controls to simulate
driving a vehicle.
-
Speed Control – simulates increases or decreases in speed.
-
Seat Belt Toggle – allows seat belt to be secured or unsecured.
-
Steering Control – simulates turning the steering wheel of a vehicle.
-
Braking Control – simulates pressing the brake.
Display Alerts: Pop-up window that shows alerts issued.
Instance of OBU Prototype: A pane showing the entire OBU prototype being
tested.
Road Controls: This window allows the user to access the controls to adjust road
conditions.
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
-
39
Change Speed Limit – changes the posted speed limit of the road the
vehicle is on.
-
Add Vehicle – adds a vehicle ahead of the simulated vehicle.
-
Add Stop Sign – adds a stop sign on the road ahead of the simulated
vehicle.
5.2
Performance Requirements
Performance requirements are used to evaluate the behaviors and capabilities of
the Defensive Driver Prototype. Performance requirements will provide specific test
conditions to demonstrate the functional requirements.
3.2.1 GPS Real-Time Data
The GPS Receiver for the Prototype shall meet the following performance requirements:
1.
Must provide accuracy within 5 meters of actual location.
3.2.2 Speed Limit
The Speed Limit Algorithm for the Prototype shall meet the following performance
requirements:
1.
Ability to detect posted speed limit change every 1 second using a 40
meter box.
3.2.3 Stop Sign
The Stop Sign Algorithm for the Prototype shall meet the following performance
requirements:
1.
Ability to detect stop signs every 1 second using an 80 meter box (split in
40 meter sections).
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
40
3.2.4 Following Too Closely
The Following Too Closely Algorithm for the Prototype shall meet the following
performance requirements:
1.
Ability to check distance every 2 seconds.
3.2.5 Seat Belt
The Seat Belt Engagement Algorithm for the Prototype shall meet the following
performance requirements:
1.
Check for seat belt engagement within 30 seconds after device is powered
on.
2.
3.3
Must not issue continuous alerts.
Assumptions and Constraints
For the Defensive Driver Prototype, it will be assumed that:
-
Speed Limit Signs will not be located less than 40 meters from each other.
This is to prevent overlapping boxes.
-
Stop Signs will not be located within 80 meters of each other. This is to
prevent overlapping boxes.
-
Driver does not driver more than 80 mph. Anything 80 mph and over is
considered Reckless Driving.
-
Virginia Driving Manual Rules are adequate for alert generation.
For the Defensive Driver Prototype, the following constraints are identified:
-
Sentinel Inc. is not using a real GPS unit. A USB connected unit will be
used instead.
-
The driving scenario for the Prototype Demonstration will be simulated.
LAB 2 – DEFENSIVE DRIVER PROTOTYPE SPECIFICATION
3.4
41
Non-Functional Requirements
Non-functional requirements identify the supporting functionality required by the
Defensive Driver Prototype. Ease of use, security, maintainability and reliability are
critical in development efforts. Ease of use is attractive to users when they are using an
unfamiliar product. Security, such as fingerprint authentication, is a feature that is builtin to the LCU. For Prototype development, maintainability is easy to achieve. The LCU
encompasses most components, making regular maintenance simple. Reliability provides
the user with a product that is dependable. The components of the OBU are reputable
and affordable.
{This space is intentionally left blank.}