Lab II – Defensive Driver Specification Outline CS 411W Lab II

Running Header: Lab II – Defensive Driver Specification Outline

Lab II – Defensive Driver Specification Outline

CS 411W Lab II

Prototype Product Specification

For

Defensive Driver

Prepared by: John Marr, Sentinel Inc.

Date: March 19

th

, 2010

1

Lab II – Defensive Driver Specification Outline

Table of Contents

2

1 Introduction ……………………………………………………………………………………………………Page 3

1.1 Purpose ………………………………………………………………………………………………………Page 4

1.2 Scope ………………………………………………………………………………………………………...Page 6

1.3 Definitions …………………………………………………………………………………………………...Page 8

1.4 References ………………………………………………………………………………………………….Page 10

1.5 Overview …………………………………………………………………………………………………...Page 11

2 General Description …………………………………………………………………………………………..Page 11

2.1 Prototype Architecture Description ………………………………………………………………………...Page 12

2.2 Prototype Functional Description …………………………………………………………………………..Page 14

2.3 External Interfaces ………………………………………………………………………………………….Page 19

3 Specific Requirements ……………………………………………………………………………….…….…Page 20

3.1 Functional Requirements …………………………………………………………………………………...Page 20

3.2 Performance Requirements ………………………………………………………………………….……..Page 33

3.3 Assumptions and Constraints ………………………………………………………………………………Page 36

Table of Figures

Figure 1Real World Product Major Functional Component Diagram…………………………………………..Page 5

Figure 2 Prototype MFCD………………………………………………………………………………………Page 12

Figure 3: Data Synchronization Module………………………………………………………………………Page 13

Figure 4 On-Board GUI Map…………………………………………………………………………………...Page 15

Figure 5 Client Software GUI Map……………………………………………………………………………Page 16

Figure 6 Test Harness GUI Map………………………………………………………………………………..Page 17

Figure 7 Database Schema……………………………………………………………………………………...Page 18

Figure 8 Speeding Algorithm Process Flow……………………………………………………………………Page 22

Figure 9 Following too close process Flow…………………………………………………………………….Page 23

Figure 10 Seat Belt Engagement Process Flow………………………………………………………………...Page 24

Figure 11 Are you in the Box? Process Flow…………………………………………………………………..Page 25

Figure 12 Stop Sign Violation Process…………………………………………………………………………Page 27

Figure 13 Analysis Algorithm……………………………………………………………………………….....Page 28

Table of Charts

Chart 1 Defensive Driver Real-World Product and Prototype Comparison………………………….………….Page 7


1 Introduction

In order to help train safer drivers, Sentinel inc. has designed the Defensive Driver. The reason behind this development is to help decrease the rate of traffic accidents caused by poor driving habits. The National Highway Traffic Safety Administration estimates that 25,576 people died in traffic crashes during the first three-quarters of 2009 (NHTSA 2010). The deaths that occurred during 2009 are a bi-product of unsafe driving habits that have gone without monitoring and correction.

Deaths that occur in traffic accidents commonly occur from neglecting to follow simple, safe driving practices. Examples of safe driving practices include: obeying stop signs and speed limits, wearing seat belts, and maintaining a safe driving distance. Simple use of a seat belt has saved an estimated 15,147 lives of those five years of age and older in the year 2007 alone

(NHTSA, 2009). When safe driving habits are neglected, they are only caught through accidents and citations.

The problem with the current method of detecting unsafe drivers involves modifying unsafe driving behaviors. When a driver is found to be unsafe, they are required to attend a

Driver Correction School. At Driver Correction Schools, a Driver is given written exams and watches instructional videos. For a school that is designed to instruct safer driving habits, a

Driver is never given behind the wheel corrective training. The lack of physical training and observation creates an issue of whether or not a driver corrected unsafe driving habits. Forming good driving habits and preventing the creation of bad driving habits must start from the beginning of Driver instruction.

3


Driver’s Education fails to provide monitoring of new Motorists and their habits. New

4

Drivers are unaccustomed to having to pay attention to their speed, stop signs, and other drivers.

When new Motorists are in behind-the-wheel Driver’s Education, they have an instructor to assist them in paying attention. Although an Instructor is with them, the Instructor’s attention will be divided among the other students, as well. After completing a Driver Education course, a

Motorist no longer has the influence of an instructor to follow proper habits. Through time, bad driving behaviors evolve from impatience and lack of accountability.

Property damages and loss of life are key issues that arise from unsafe driving habits.

Unsafe driving behaviors result in traffic accidents. Traffic accidents involve property damage, loss of life, and an increase in insurance rates. Through use of the Defensive Driver, Driver

Education Schools and insurance Companies could help to reduce the frequency of unsafe

Drivers. Driver Education programs shall be able to record how safe of a driver their students are, and demonstrate a good track record to future customers. Insurance Companies that use the

Defensive Driver will be able to instruct their clients in safer driving practices, which will help to keep insurance rates down.

1.1

Purpose

The Defensive Driver product is the first monitoring and analysis device built for identifying Good Drivers. Through use of Driver authentication, the Defensive Driver will record Driver histories and securely identify the Driver behind the wheel. This will be accomplished through achieving objectives with use of the Defensive Driver’s key components and features (Figure 1).

[This Space Intentionally Left Blank]


Figure 1: Real World Product Major Functional Components Diagram

5


1.2

Scope

6

In order to develop a viable Real World Product, the Defensive Driver will be prototyped.

Through prototyping, Sentinel, Inc. will test Algorithm functionality, develop a Good Driver

Algorithm, and create documentation of its development. The algorithms and components of the

Defensive Driver prototype and Real World Product will have similarities and differences.



Chart 1: Defensive Driver Real-World Product and Prototype Comparison

7

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

OBU Speed Limit Database

OBU Stop Sign Database

Erratic Lane Change Algorithm

Failure To Use Headlights Algorithm

Improper Turns Algorithm

GPS Coordinates

Following Too Close Algorithm

Seat Belt Usage Algorithm

Speeding Algorithm

Stop Sign Algorithm

Final Product Prototype

Real-time sensor data correlation when vehicle is in motion

Simulated sensor data correlation with pre-loaded inputs

Fully Functional

OBU

Final Product

On-board Unit (OBU) embedded receiver

Embedded in OBU

OBU component

OBU component

OBU Display component

OBU Interface

OBU internal/external memory

OBU component

Final Product

Microsoft Access database to be provided by

VDOT


VDOT

Data Processing Module component



Lat/Long obtained by embedded GPS receiver

Prototype

External receiver with USB interface

Laptop component

Not in prototype

External sensor with USB interface

Laptop display

Simulated database input

Laptop memory

Laptop speakers

Prototype

Database of sample speed limit data for a limited geographic location

Database of sample stop sign data for a limited geographic location

Not in prototype

Not in prototype

Not in prototype

Lat/Long obtained by external GPS receiver

Fully Functional

Software

Speed Limit Database

Stop Sign Database

Data Synchronization

Analysis Software

Client Software

Final Product


VDOT


VDOT

Prototype

Database of sample speed limit data for a limited geographic location

Database of sample stop sign data for a limited geographic location

Fully Functional


1.3

Definitions, Acronyms, and Abbreviations

8

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.

DSM: An abbreviation for Database Synchronization Module. The component of the Client

Software that will ensure database consistency.

ECU: An abbreviation for Engine Control Unit. The main microcontroller within a vehicle that coordinates numerous driving parameters and exports them to external devices.

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

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

9 will reside inside of a vehicle. This unit will provide real-time monitoring of a driver’s performance.

RDPM: An abbreviation for Runtime Data Processing Module.

The main component of the

OBU’s software application.

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.

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.

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.

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.

10

1.4

References

1.4.1 Professional Workforce Development

Documentation used by Sentinel, Inc. derives from works of its members in Red Group of CS 410 Fall 2009.

1.4.2 Defensive Driver Product Documentation

Documentation used by Sentinel, Inc. derives from works of its members in Professional Workforce Development II.

1.4.3 Virginia Driver’s Manual

Sentinel, Inc. utilizes the Virginia Driver’s Manual as found on their website, http://www.dmv.state.va.us/webdoc/citizen/drivers/manual.asp

, in order to determine driving laws and regulations.

1.4.4 National Highway Traffic Safety

Administration

The National Highway Traffic Safety Administration collects information regarding safe driving practices and causes of vehicular accidents. Sentinel, Inc. uses data collected by the NHTSA as found on their website, http://www.nhtsa.gov/ .


1.5

Overview

The Prototype Product Description for the Defensive Driver will provide information for Prototype architecture, functionality, and specific requirements.

Defensive Driver Prototype Hardware and Software components will be identified.

Additionally, requirements for functionality will be addressed for product performance.

2 General Description

11

The Prototype will not have certain capabilities and features that will be present in the

Real World Product (Refer to Chart 1). Algorithms and hardware components will be missing from the prototype that will be seen as future development occurs. The erratic lane change algorithm, along with its required accelerometer, will be absent from the Defensive

Driver Prototype. Further research will be required in order to solidify the algorithm for determining erratic lane changes before implementation. The determination of improper turning and lack of headlight usage will also be postponed for real world product development. Seatbelt usage is implemented in the prototype and requires OBD II data input. It is assumed that since the seatbelt Algorithm uses OBD II input, that other OBD II input Algorithms will be feasible.



Figure 2: Prototype Major Functional Component Diagram

12

2.1

Prototype Architecture Description

The test harness for the Prototype will differ from the Real World Product’s functionality. As Sentinel Inc. is unable to afford utilizing a vehicle for the Prototype testing, a laptop will simulate the vehicle (Figure 2). In addition, the display, fingerprint scanner, Client Software and OBU will be simulated through use of the laptop. As the laptop incorporates the same programming environment as the OBU and Client Software will be operating on, the algorithms developed in prototyping may be transferred to the

Real World Product. The OBD II data will also be simulated in the Prototype through

Lab II – Defensive Driver Specification Outline use of a flat file. Databases including Stop Sign and Speed Limit locations will be developed for further the Real World Product. The data needed for the Stop Sign and

13

Speed Limit Databases will be acquired through the Department of Transportation.

Databases will include area specific data provided by the Virginia Department of

Transportation (VDOT) to be used by the Prototype harness. These datasets will be compared to a Driver’s actual location through use of the Global Positioning System receiver for use in the OBU Algorithms.

Figure 3: Data Synchronization Module



The Client Software in the Defensive Driver Prototype will include a Data

14

Synchronization Module. This module will be used for updating the OBU internal Stop

Sign and Speed Limit Databases and the Client Software’s Reports and Logs Database.

With the module in place, databases on both OBU and Client Software will be updated to the most current version.

2.2

Prototype Functional Description

2.2.1 Prototype Process Flow

The Defensive Driver Prototype shall analyze driving behavior in Real-Time, provide historical data collection, and distinguish Safe Drivers. Through use of input sensors, internal databases, and event detection algorithms, the Prototype shall monitor driving behaviors. Collecting event information created from the detection algorithms, the Prototype shall record unsafe driving incidents. Client Software will analyze driver historical data in order to determine a safe driver.

The Prototype will provide a testing harness in order to demonstrate Real World functionality. The Testing Harness will allow users to simulate Alerts, Driving Events, and report generation. The simulation will include pre-loaded driving scenarios and allow for manual changes to demonstrate functionality.

Figure 4: Prototype Process Flow



2.2.2 Graphic User Interface

15

The Defensive Driver Prototype shall include GUI interfaces for the OBU, Client

Software, and Testing Harness. Figure 4 illustrates what screens the OBU will provide for Drivers and Administrators to the Defensive Driver. Important concepts to the OBU

GUI screens include Alerts, Login, and New User screens. These screens allow the

Drivers to register with, login to, and interact with the OBU.

Figure 4: On-Board GUI Map

Figure 5 illustrates the screens that the Defensive Driver Administrator will be capable of accessing. In the Client Software, an Administrator will be able to update internal databases including: Speed Limit, Stop Sign, and Driver Profile Databases.



Figure 5: Client Software GUI Map

16

Figure 6 identifies screens that will be visible during use of the Testing

Harness. These screens allow for simulation of a pre-loaded scenario or manual input of driving data in order to test events. An example would be to add a Stop Sign to a scenario while maintaining Driver Speed to demonstrate a Stop Sign Alert.



Figure 6: Test Harness GUI Map

17

2.2.3 Database Schema

Figure 7 illustrates the design of the Defensive Driver Databases. Database information shall include User Profile Information, event logs specific to event type and user, along with School and Administrator data.



Figure 7: Database Schema

School

PK School ID

Address

Name

Owner

Student

PK Student ID

Name

Instructor ID

School ID

Hours Driven

Address

Fingerprint

General Logs

PK Log ID

Type

Student ID

Location

Timestamp

Instructor

PK Instructor ID

Name

School ID

Speed Logs

PK Alert ID

Violation Type

Location ID

Current Speed

Timestamp

Student ID

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


Speed Limits

PK Location ID

Point1 Latitude

Point1 Longitude

Point2 Latitude

Point2 Longitude

Length

Height

MaxSpeed

Stop Signs

PK Location ID

Point1 Latitude

Point1 Longitude

Point2 Latitude

Point2 Longitude

Length

Height

18


2.3External Interfaces

2.3.1 Hardware Interfaces

Hardware Interfaces for the Defensive Driver shall include a GPS

Receiver and Distance sensor. These tools shall be connected to the Prototype via a USB connection.

19

2.3.2 Software Interfaces

The Defensive Driver Prototype shall include Software Interfaces for the

GPS receiver, Distance Sensor, and MySQL Database. The interfaces will provide the Defensive

Driver the ability to collect GPS Location and Following Distance while the vehicle is operated.

The MySQL database shall be accessed by the Defensive Driver for data storage and collection.

2.3.3 User Interfaces

The Laptop Unit shall include Fingerprint Identification, Client, OBU, and

Test Harness user interfaces. These interfaces shall allow the User to interact with the Defensive

Driver Unit in capacities such as a User or Administrator.

2.3.4 Communication Protocols

The USB components of the Defensive Driver require an interface to the

Defensive Driver Software. A benefit of using an USB connection include being able to power peripheral components through the Laptop Unit.


3 Specific Requirements

20

The Defensive Driver Prototype must adhere to functional and performance requirements.

Requirements will be met in order to make the Defensive Driver capable of performing

Real Time analysis of Driving Habits. Although accuracy and speed is top priority, nonfunctional requirements such as ease of use and security will be addressed in the Defensive

Driver Prototype.

3.1

Functional Requirements

3.1.1 Algorithms

3.1.1.1 Formulas

The Speed 80MPH (Reckless Driving Speed) is equivalent to 35.76 meters per second. 80MPH * .44704 mps/1 MPH=35.76mps. In order to check a Driver every second for an Event, a 40 meter box will be used for Stop Signs and Speed

Limits.

3.2.1.2 Speeding

The Defensive Driver includes an Algorithm to determine whether a Driver is obeying the posted speed limits in their location.

3.2.1.2.1 Driver Speed

The Driver’s Speed will be collected from OBU data which is simulated in the Test Harness.

3.2.1.1.2.1 MPH in integer


The Driver’s speed will be measured in whole number integers

21 where any speed above that of the posted speed limit will trigger an Alert.

3.1.1.2.2 Maximum Speed Limit

The Maximum Speed Limits will be held in a Speed Limit Database based on Location.

3.1.1.2.2.1 Pulled From Database

The Maximum Speed Limit will be listed by GPS Location in the

Speed Limit Database.

3.1.1.2.3 Driver Location

The Driver’s Location will be determined through a USB based GPS

Receiver.



Figure 8: Speeding Algorithm Process Flow

Collect GPS

Location

Data

Collect Driver

Current Speed

Has Max Speed

Limit Changed?

Yes

Find New Max

Speed Limit from Internal

DB

No

Update

Current Max

Speed

22

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

3.1.1.3 Following Too Close

The Defensive Driver Prototype will replicate Real World performance with use of a Sonic Distance Sensor.

3.1.1.3.1 Driver Speed

The Driver’s speed will be determined through use of the OBU which is

Simulated in the Test Harness.



3.1.1.3.2 Driver Distance from Vehicle Ahead

23

Distance will be determined with use of a Sonic Distance Measuring Tool.

3.1.1.3.3 Minimum Safe Driving Distance

Minimum safe distance will be determined through Driver’s current speed.

For every 10 miles per hour of driving speed, 1 car length of distance will be required of the driver. (e.g. 30mph = 3 car lengths of distance)

Figure 9: 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?

Lambda

Transition

Yes

No

Store event log in driver history

Alert driver to maintain a safe distance

3.1.1.4 Seat Belt

The Defensive Driver Prototype will monitor Seat Belt Engagement every

30 seconds after engine start until engine stop.


3.1.1.4.1 Seatbelt on?

Seatbelt Engagement data will be pulled from the OBU which is

Simulated in the Test Harness.

3.1.1.4.1.1 Test Harness

The Defensive Driver Prototype Test Harness will allow for toggling of Seatbelt Engagement.

Figure 10: Seat Belt Engagement Process Flow

24

Unit Turns on

Seat Belt

Engaged?

Yes

Wait 30

Seconds

No

Record

Event

Alert Driver

Yes

Seat Belt

Engaged?

No

Record

Event

3.1.1.5 Stop Sign

The Defensive Driver Prototype will determine whether a Driver has made a complete stop at each Stop Sign they approach.


3.1.1.5.1 Driver Location

The Driver’s Location will be determined through a USB based GPS

Receiver.

3.1.1.5.2 “Are you in the box?” Algorithm

25

In order to determine whether a Stop Sign applies to the Driver, a Trigger and Event system will be utilized.

Figure 11: Are you in the Box Process Flow

No

Collect GPS

Location

Compare GPS

Location to

Internal Database

Was a Trigger Box

ID Returned?

No

Was an Event Box

ID Returned?

Yes

Record Trigger ID

Number

Yes

Does the Event ID match Trigger ID?

Yes Monitor for Event

No

3.1.1.5.3 Determine Stop

The Defensive Driver Prototype will monitor engine data provided by the

OBU to log whether the Driver made a Complete Stop or No Stop at all.


3.1.1.5.3.1 Stop

A Stop in which the speed of the vehicle reaches 0 mph for 3 seconds.

3.1.1.5.3.2 No Stop

The Driver does not stop the vehicle, or fails to keep the vehicle stopped for 3 seconds.

26



Figure 12: Stop Sign Violation Process

No

Collect GPS

Location

Data

Compare Data to Stop Sign

Internal

Database

No

Yes

Save

Trigger ID

Yes

Driver in

A Stop Sign

Box?

Yes

Trigger

Box?

No

Event

Box ID match

Trigger ID?

Yes

Did Driver stop?

No

Send Alert

Record

Event


27


3.1.1.5 Driver Profiling Algorithm

28

The Driver Profiling Algorithm will take into account past Driver history, total driving time, and the weight of each Driving offense. Using duration, frequency, and the danger rating of each offense that the driver commits, the Driver Profiling Algorithm will analyze how safe a

Driver is. Through reducing duration and frequency of driving events, a Driver will be shown as improving their driving behavior.

Figure 13: Analysis Algorithm

Start

Event

Data

Collect

Event

Statistical

Data

Calculate

Weight

Collect

Duration/

Frequency

Calculate

Driver

Points

Record

Points

Collect Date Next Date?

No

Record

Event as

Declined

No

Have Points

Decreased Over

Time?

Generate

Driving

Report

Yes

Record

Event as

Improved

Yes


3.1.2 GUI Interfaces

29

The Defensive Driver Prototype will include Graphical User Interfaces to add ease of use and functionality to the product.

3.1.2.1 OBU Welcome/Login Screen

The Login Interface will allow for current users to start the prototype for recording of Driver History.

3.1.2.1.1 New User

Allows for a New Driver to be added to the OBU and requires Fingerprint scan for future identification.

3.1.2.1.2 About

The About screen describes Defensive Driver Unit and Software.

3.1.2.1.3 Owner Information

The Owner screen identifies the OBU Owner.

3.1.2.1.4 Driving Display

The Driving Display screen shows current driving data which includes current speed and location.



3.1.2.1.4.1 Speed Limit Alert

Displays an alert to inform Driver of Speeding infraction.

3.1.2.1.4.2 Following Too Close Alert

Displays an alert to inform Driver to maintain Safe Driving

Distance

30

3.1.2.1.4.3 Seat Belt Alert

Displays an alert to inform Driver to engage their seat belt.

3.1.2.1.4.4 Stop Sign Alert

Displays an alert to inform Driver to make a complete stop at each posted Stop Sign.

3.1.2.1.5 Driver Information

The Driver Information Screen provides information on the current Driver.

3.1.2.1.6 Database Synchronization

Screen presented when OBU is updating its internal databases, includes a progress bar.

3.1.2.1.7 Completed Session

Completed Session screen is presented at the end of a Driving Session. Driving Data is saved at this time.


3.1.2.2 Client Software Administrator Login

Welcome Screen presented to the Administrator in which a Login and Password are required to continue.

31

3.1.2.2.1 About

About Screen provides information on the Current Software Version.

3.1.2.2.2 List of Units

This screen provides a list of all OBU and their corresponding Driver.

3.1.2.2.3 List of Drivers

This screen provides a list of all Drivers and their corresponding OBU.

3.1.2.2.3.1 Driver Profile and Report Processing

This screen shows the user the Driver’s Profile and a list of sub-sections.

3.1.2.2.3.1 Display Alerts

Displays a list of Alerts generated by the specific Driver organized by date.

3.1.2.2.3.2 Driver Analysis

Generates and Displays Driver Analysis.


3.1.2.2.3.3 Driver Statistics

Displays Driver Statistical Data.

3.1.2.2.3.4 Alert Database Syncing

Saves Driver’s Alert Database from SD Card to Client Software.

3.1.2.2.4 New Driver

Input screen for New Driver information. Information includes Name and OBU ID.

3.1.2.3 Stop Sign and Speed Limit Database Syncing

This screen updates the SD Card with current versions of each database.

32

3.1.2.4 Test Harness Welcome

Provides a How-To for the User and a Short Description of the Defensive Driver.

3.1.2.4.1 Driving Controls

The Controls used to simulate a vehicle being driven.

3.1.2.4.1.1 Speed Control

Sets driving speed of the simulated vehicle.

3.1.2.4.1.2 Seatbelt Toggle

Toggles engagement of the simulated seatbelt.


3.1.2.4.1.3 Steering Control

Tool used to determine which path the vehicle is taking.

33

3.1.2.4.1.4 Braking Control

Controls whether a vehicle stops (e.g. A vehicle would need to stop at a stop sign)

3.1.2.4.2 Display Alerts

Generates a window that displays Alerts that have been generated.

3.1.2.4.3 OBU Prototype Display

Window that displays a depiction of what a Defensive Driver OBU looks like.

3.1.2.4.4 Road Controls

Window that provides tools for changing the simulated environment.

3.1.2.4.4.1 Change Speed Limit

Screen that allows for Speed Limits to be changed in the simulation.

3.1.2.4.4.2 Add Vehicle

Allows for a simulated vehicle to be added ahead of the Driver’s vehicle.

3.1.2.4.4.3 Add Stop Sign

Allows for a Stop Sign to be added in the Simulation at a specific location.


3.2 Performance Requirements

The Defensive Driver will rely on a set of tools to provide precise measurement of Driver location and Engine Control Unit information.

3.2.1 GPS Real Time Data

34

A G.P.S. receiver connected to the Prototype Laptop will register current location. The G.P.S. data will be required to be accurate in order to determine Driver’s location for comparisons to

Speed Limit and Stop Sign database.

3.2.1.1 Accuracy

The G.P.S. Receiver shall be accurate to within five feet of actual position of the vehicle.

3.2.2 Speed Limit

Maximum Speed Limit data will be collected from Virginia Department of

Transportation. Speed Limit and Location of Speed Limits will be extracted and used for the Defensive Driver Speed Limit Database.

3.2.2.1 1 Second Test Cycle

The Defensive Prototype will be required to check for the Maximum Speed Limit every second. By checking every second, the Defensive Driver will be able to determine if a

Driver is speeding up to speeds of 80 miles per hour. Speeds past 80 miles per hour will mark the Driver as speeding.


3.2.3 Stop Sign

The Defensive Driver Prototype will be able to determine if the Driver is approaching a Stop

Sign in which they need to stop.

3.2.3.1 Ability to detect Stop Signs

35

The Defensive Driver Prototype will compare Driver location to the Stop Sign Database every second.

3.2.4 Following Too Closely

The Defensive Driver will be required to determine if the Driver is properly maintaining a

Minimum Safe Driving Distance.

3.2.4.1 Ability to Check Distance

The Defensive Driver will be required to check distance every two seconds.

3.2.5 Seat Belts

The Defensive Driver shall determine Seat Belt Engagement and alert Drivers once they have a disengaged seat belt. Seat Belt monitoring will record how long the Driver’s seat belt is disengaged.

3.2.5.1 Seat Belt Alerts

Lab II – Defensive Driver Specification Outline 36

The Defensive Driver will provide a single Alert to inform Drivers that their Seat Belt is disengaged. After the first alert, the Defensive Driver will maintain a time of how long the Seatbelt has been disengaged. If the Driver engages the Seat Belt and then disengages, another alert will occur and be recorded.

3.2.6 Record Driver Events

All Driver Events are required to be saved by the end of the Driving Session.

3.3 Assumptions and Constraints

The Assumptions and Constraints provided are necessary in order for the Defensive Driver to function properly.

3.3.1 Assumptions

Assumptions are statements in which Sentinel, Inc. has designed Defensive Driver around.

3.3.1.1 Speed Limit Signs

Speed Limit Signs will not be located less than 40 meters from one another, as required for Trigger and Event Box logic.

3.3.1.2 Stop Signs

Stop Signs will not be located 80 meters within one another, as required for

Trigger and Event Box Logic.


3.3.1.3 80 MPH Max

The Driver will not exceed 80mph while driving. Any speed above 80mph will be considered Reckless Driving.

37

3.3.1.4 I/O Standards

Input/Output standards are assumed backwards compatible.

3.3.1.5 Virginia Driving Manual

Virginia Driving Manual is assumed adequate for alert generation.

3.3.1.6 OBD-II Validity

Data provided by OBD-II is assumed correct

3.3.2 Constraints

3.3.2.1 GPS Receiver

GPS Receiver for the OBU will be a USB based unit instead of a GPS Receiver Chip on a processor board.

3.3.2.2 Simulated Driving

Driving events will be simulated using a Laptop Computer instead of an actual vehicle.



3.3.3 Non Functional Requirements

3.3.3.1 Ease of Use

The Defensive Driver includes a module for updating Databases and an Algorithm for analyzing Drivers requiring only for the Administrator to connect the SD Card. The

Defensive Driver additionally collects data without distracting the Driver or requiring continuous input from an user.

3.3.3.2 Security

The Defensive Driver provides security through use of biometrics and passwords.

3.3.3.2.1 Finger Print Authentication

Fingerprints are associated with Drivers, requiring a Driver to scan their fingerprint in order to use the OBU.

3.3.3.3 Maintainability

3.3.3.3.1 Parts

38


The Defensive Driver is constructed of off the shelf materials which are available in most electronic stores.

3.3.3.3.2 Low Maintenance

The Defensive Driver will require little maintenance if handled properly.

3.3.3.4 Reliability

The Defensive Driver uses algorithms designed to prevent false positives and negatives from occurring. However, the Driver Analysis Algorithm takes into account human and computer error. If a mistake should arise in an event, the majority of the Driver’s actions will outweigh the singularity.



Glossary

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

41 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 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

42 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.

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

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

44 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.

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

45 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.


References:

Cars Direct (Page Accessed February 2010), “ Common Insurance Discounts ”

Retrieved from http://www.carsdirect.com/car-insurance/common-car-insurancediscounts

National Highway Traffic Safety Administration (January 2010), “ Traffic Safety Facts”

Retrieved from http://www-nrd.nhtsa.dot.gov/Pubs/811255.PDF

National Highway Traffic Safety Administration (December 2009), “ Lives Saved FAQ ”

Retrieved from http://www-nrd.nhtsa.dot.gov/Pubs/811105.PDF

Marr, John Casey-Sentinel, Inc.(Spring 2010), “Lab 1 Defensive Driver Product Documentation”

Lab II – Defensive Driver Specification Outline CS 411W Lab II

CS 411W Lab II

Prototype Product Specification

For

Defensive Driver

Prepared by: John Marr, Sentinel Inc.

Date: March 19

, 2010

Related documents

Products

Support

Lab II – Defensive Driver Specification Outline CS 411W Lab II

CS 411W Lab II

Prototype Product Specification

For

Defensive Driver

Prepared by: John Marr, Sentinel Inc.

Date: March 19

, 2010

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib