Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION 1

advertisement
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
Lab 1 – Defensive Driver Description
Andrew Will
Old Dominion University
Professional Workforce Development
Professor Janet Brunelle
1
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
2
Table of Contents
1 Introduction .................................................................................................................................. 3
2 Product Description ..................................................................................................................... 5
2.1 Key Product Features and Capabilities ................................................................................. 5
2.2 Major Components (Hardware/Software)............................................................................. 9
2.3 Target Market/Customer Base ............................................................................................ 12
3 Product Prototype Description ................................................................................................... 13
3.1 Prototype Functional Goals and Objectives ........................................................................ 14
3.2 Prototype Architecture (Hardware/Software) ..................................................................... 18
3.3 Prototype Features and Capabilities.................................................................................... 19
3.4 Prototype Development Challenges .................................................................................... 20
Glossary ........................................................................................................................................ 21
References ..................................................................................................................................... 23
List of Figures
Figure 1. Real World Product Device Logic……………………………………………………...6
Figure 2. Real World Product Input/Output Processing Diagram………………………………...8
Figure 3. Real World Product Major Functional Component Diagram…………………………10
Figure 4. Prototype Device Logic……………………………………………………………….15
Figure 5. Prototype Input/Output Processing Diagram………………………………………….17
Figure 6. Prototype Major Function Component Diagram……………………………………...19
List of Tables
Table 1. Real World Product and Prototype Comparison………………………………………..14
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
3
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 1 – DEFENSIVE DRIVER DESCRIPTION
4
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.
The Defensive Driver is the product that will change the way people learn to drive. It
will provide 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 in depth 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 onboard 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.
The initial target customers for the Defensive Driver will be driver education programs
and insurance companies. Both of these customers are at the front line of driver development.
The driver education programs are very important, as they are the only program that all new
drivers must complete in order to receive their license. Most importantly, it is where the only
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
5
current mandatory monitoring of a driver is done, and where bad driving habits can be easily
overlooked due to the non-comprehensive and short duration training sessions. Insurance
companies also influence how people drive. They are in control of insurance premiums, and
depending on how a driver performs, the premium can be adjusted to reward or punish the driver
for good or bad driving habits.
2 Product Description
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
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 unit will alert the
driver of unsafe driving habits by using specialized visual and audio alert generation in real time.
This will allow the driver to become aware of when bad habits are being engaged. When the
driver information is transferred from the on board unit to the client software, an in-depth
analysis of the driving session will be produced, showing the progression of the driver’s habits
over time.
The goal of this system will not only be to record and recognize safe and unsafe driving
habits, but to reinforce good driving habits by showing driver improvement through the client
software analysis. This will in turn produce safer drivers and reduce the annual billion dollar
economic toll and also reduce the loss of life that is a result of these poor driving habits.
2.1 Key Product Features and Capabilities
Real time monitoring and in-depth driver analysis client software are at the core of the
Defensive Driver product. Figure 1 shows how real time monitoring allows the Defensive
Driver to gather information on a driver’s performance, and immediately alert the driver of bad
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
6
habits. The real time monitoring coupled with the customized profile of the individual driver,
will minimize the amount of false positives recorded. The client software will take this data and
produce detailed profiles on drivers in order to allow a quick and easy reference point of how a
driver is performing in the areas being monitored.
Figure 1. Real World Product Device Logic
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
Real time monitoring will be enabled through an array of sensors coupled with
specialized monitoring algorithms. As shown in Figure 2, the monitoring algorithms will
interpret 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).
[This Space Intentionally Left Blank]
7
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
Figure 2. Real World Product Input/Output Processing Diagram
8
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
9
Alerting the driver of a bad driving habit will be the second part of the real time
monitoring system. The alert will be displayed visually on the Liquid Crystal Display (LCD)
and accompanied by an audible alert if desired. This alert 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.
2.2 Major Components (Hardware/Software)
Figure 3 shows the Major Function Component Diagram (MFCD) of the Defensive
Driver. As shown, the defensive driver has two main components consisting of multiple
hardware and software components, the On-Board Unit (OBU), and the client software. These
components work together to produce one of the most comprehensive real-time driving analysis
and monitoring tools available.
[This Space Intentionally Left Blank]
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
Figure 3. Real World Product Major Functional Component Diagram
The hardware inside the OBU consists of all the necessary sensors needed to produce a
comprehensive real time driving analysis. The accelerometer, distance sensor, Global
Positioning System (GPS) sensor, and the On-Board Diagnosics-II (OBD-II) interface will all
10
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
11
provide the data needed for alert generation and subsequent data recording. The fingerpring
reader will provide for driver authentication everytime the car is started and data begins
recording. This will prevent an unauthorized person’s data from being recorded as another. The
OBD-II interface will provide the OBU with all the data from the engine allowing speed, turn
signal data, seat belt usage, and brake utilization to be recorded in real time. The GPS sensor
will allow accurate accounting for where a driver is, and allow a cross reference with the stop
sign and speed limit database residing on the OBU’s internal memory. This will enable the OBU
to check if a driver is speeding and obeying stop signs properly. The distance sensor will be
used to detect if the driver is tailgating, or driving too closely, to any vehicle located in front.
Finally, the external Secure Digital (SD) memory will be used to transfer the data collected in the
OBU to the client software for analysis.
The software residing on the OBU will consist of the monitoring and alert generation
algorithms used for the real time collection of data. These algorithms will monitor all of the
sensors available and generate a comprehensive driving log and list of alerts generated
throughout the use of the OBU. These software components are necessary to building the data
points that will allow for a complete driver analysis on the client software.
The client software is the core of the driver profiling aspect of the Defensive Driver.
This software takes all the data collected from the OBU and will produce a detailed driver
analysis through a complex algorithm used to break down a driver’s performance. This will be
used to create a personal profile of each driver, allowing the system to constantly adapt to how a
driver is improving or regressing with regard to driving habits. The client software will use this
learning algorithm to minimize false positives and maximize effectiveness of the OBU.
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
12
2.3 Target Market/Customer Base
Defensive Driver will be initially marketed to customers that have a large investment in
driver development, driver education programs, driver improvement clinics, and insurance
companies. All three of these customers are on the front lines of driver development, and will
benefit largely from a product such as Defensive Driver.
The driver education program, both public and private, is the first actual schooling that a
driver receives in their quest to become licensed. These programs have the best chance of
influencing a driver’s habits and identifying bad habits that need to be fixed in the beginning of a
driver’s career. Therefore, a comprehensive monitoring and analysis tool such as the Defensive
Driver would be an indispensable asset to improve the areas in which these programs are lacking.
Driver improvement clinics suffer from being given drivers that have already had a
chance to develop and foster bad habits. Changing the habits that a driver has had for some time
is a hard process, and can hardly be accomplished with any lasting effects when done solely on
the Internet. The addition of the Defensive Driver into these programs would allow them to
become much more effective at identifying and monitoring the drivers sent to them. This would
also allow for them to be able to make informed decisions on whether a person has improved
based on the in-depth driver analysis that Defensive Driver produces.
Insurance companies are heavily invested in drivers, and are in control of all drivers’
insurance premiums. The data collected via the Defensive Driver will be indispensable to the
insurance companies when determining the appropriate insurance premium for a driver. The
data collected will also allow an insurance company to separate the good and bad drivers more
effectively.
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
13
3 Product Prototype 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
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.
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.
[This Space Intentionally Left Blank]
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
14
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
3.1 Prototype Functional Goals and Objectives
The main goal of the prototype is to prove that the key real world product capabilities
will work. Figure 4 shows the prototype logic, and how it will be used to prove the key realworld product capabilities. 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 realtime events. The prototype will also allow a demonstration of how the risks involved are being
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
mitigated, and will allow the customers questions regarding these risks to be answered
immediately. The preliminary user manual will also be developed in conjunction with the
prototype.
Figure 4. Prototype Device Logic
15
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
16
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. As seen in Figure 5, 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.
[This Space Intentionally Left Blank]
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
Figure 5. Prototype Input/Output Processing Diagram
17
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
18
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
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.
3.2 Prototype Architecture (Hardware/Software)
Figure 6 shows the MFCD of the Defensive Driver prototype. As shown, the prototype
will be loaded on a laptop, with a GPS sensor and a distance sensor connected by a Universal
Serial Bus (USB) connection. The internal memory of the laptop will provide space for the stop
sign and speed limit databases. It will also provide space for the monitoring and alert generation
algorithms, as well as the simulated sensor input and Engine Control Unit (ECU) databases. The
laptop will have a removable SD memory card so that the data generated during the simulation
can be brought to another computer with is hold the client software. This will allow for a
demonstration of driver analysis and profiling after using the OBU via the SD memory card.
The fingerprint reader is a component that is installed on the laptop, and will only serve to show
basic authentication of individual drivers.
[This Space Intentionally Left Blank]
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
19
Figure 6. Prototype Major Function Component Diagram
3.3 Prototype Features and Capabilities
The prototype will have many of the same features and capabilities as the real world
product as previously discussed. However there are a few key features that will need to be
demonstrated. Risk mitigation, or more specifically, elimination of false positives is a major
feature that will be shown in the prototype. The transparency of the Defensive Driver prototype,
along with the actual real-world algorithms, will be combined to show how the risk of recording
false positives has been mitigated. The use of the real-world algorithms will also allow us to
improve them if they are found to be ineffective when used in the prototype. The real time
monitoring aspect as well as the driver analysis, profiling algorithms, and report generation are
all integral features of the prototype that will be shown. This will allow the customer to see the
driver improve, or get worse, over time through the client software package. Ease of use will
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
20
also be addressed in the prototype, showing that anyone anywhere will be able to use the product
effectively.
3.4 Prototype Development Challenges
The Defensive Driver prototype has a unique set of development challenges that will
have to be mitigated, if not eliminated. Correct performance of the GPS sensor will be critical to
the success of the prototype. The SD memory card synchronization will also need to be
addressed. Most importantly however, is that the prototype shows that false positives have been
reduced to a minimum, if not eliminated completely. The hardware and software integration will
be a challenge, but can be easily overcome with sufficient planning. Also, OBD-II technology
could be updated or changed at any time. Therefore, our software will have to be flexible and
allow changes to be made easily to update and expand the Defensive Driver product.
[This Space Intentionally Left Blank]
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
21
Glossary
Accelerometer: A device that measures acceleration of an object.
Alerts and Logs Database: Database that holds a record of all the alerts and events recorded.
Algorithm: Method for solving a problem in a finite number of steps.
Central Processing Unit (CPU): Part of a computer that carries out instructions of a program.
Client Software: Software on a separate computer used for report generation of drivers.
Customized Profile: Profile consisting of a driver’s personal data related to driving performance
and ability.
Defensive Driver: Driver monitoring and analysis product.
Defensive Driver Prototype: Prototype of Defensive Driver
Department of Motor Vehicles (DMV): Agency that registers vehicles and licenses drivers
Driver: Person that operates a motor vehicle of any type.
Driver Education: Class that teaches new drivers how to properly drive.
Driver Improvement Clinics: Class that rehabilitates drivers with bad habits.
Driver Profile: All historical data on a driver.
Driving Attributes: Reflexes, and reaction times relevant to a driver.
Engine Control Unit (ECU): Embedded system that controls a car’s electrical systems.
Erratic Lane Change: Changing lanes erratically.
Events Database: Database that holds data on events collected by the OBU.
False Positives: Recording of an infraction that did not actually happen.
Fingerprint Reader: Scans and records fingerprints.
Flash Memory: Computer storage that can be electronically erased and reprogrammed.
Global Positioning System (GPS): Space based navigation system.
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
22
Graphical User Interface (GUI): Allows human interaction with computers.
Hard Drive: Non-volatile memory in a computer.
Infraction: The breaking of a traffic law.
Insurance Companies: Risk management company.
Internet: Global system of connected computer networks.
Liquid Crystal Display (LCD): Flat panel used to electronically display information
Major Functional Component Diagram (MFCD): Diagram that shows all major components.
National Highway Transportation Safety Administration (NHTSA): Government transportation
On-Board Diagnostics (OBD-II): Vehicle self diagnostics interface
On-Board Unit (OBU): Defensive Driver unit that resides in the vehicle.
Random Access Memory (RAM): Volatile computer memory.
Secure Digital Memory (SD Memory): Non-volatile memory card.
Sensor: Device that measures some physical quantity.
Sensor Network: Network of distributed sensors.
Speed Limit Database: Database that hold speed limit information for a given area.
Stop Sign Database: Database that hold stop sign information for a given area.
Tailgating: Driving too closely behind a vehicle.
Test Harness: Software that tests a software package in varying conditions.
Touch Screen: Display that can detect the presence of a body part.
Virginia Department of Transportation (VDOT): Government agency responsible for
maintaining roads and bridges in Virginia.
Running head: LAB 1 – DEFENSIVE DRIVER DESCRIPTION
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
23
Download