Onboard Monitoring and Reporting for 

Commercial Motor Vehicle Safety 

Final Report 

 December 2007
FOREWORD 

This Final Report documents the results of the investigation and development of a prototype 

hardware and software suite that allowed for online measurement of a set of driving 

characteristics that are indicators of unsafe driving behavior. Via the prototypical suite, feedback 

could be provided to drivers, either directly in real-time or through carrier management. This 

would allow truck drivers to significantly improve their attentiveness and enhance their safety 

performance. 

In the prototype development work, the monitored parameters and the type of feedback to be 

given were systematically selected by first examining commercial vehicle crash causes in the 

literature and then deriving five categories or “core behavioral categories,” which, as a whole, 

comprise the feature set recommendations for an ideal onboard driver monitoring system. The 

five monitoring categories or behaviors are listed as follows: 

1. Speed Selection 

2. Following Behavior 

3. Attention (or Inattention) 

4. Fatigue 

5. General Safety 

After identifying the five categories, a prototypical suite was developed, installed, and tested on 

a Class 8 tractor, and a concept for Field Operational Testing (FOT) was developed. 

This Report will be of interest to anyone interested in the use of onboard monitoring technology 

that provides a combination of real-time and non-real-time driver monitoring feedback to 

enhance safe behaviors for heavy truck and bus drivers. 

NOTICE 

This document is disseminated under the sponsorship of the Department of Transportation in the 

interest of information exchange. The United States Government assumes no liability for its 

contents or the use thereof. 

The contents of this Report reflect the views of the contractor who is responsible for the accuracy 

of the data presented herein. The contents do not necessarily reflect the official policy of the 

Department of Transportation. 

This Report does not constitute a standard, specification, or regulation. 

The United States Government does not endorse products of manufacturers. Trade or 

manufacturers’ names appear herein only because they are considered essential to the objective 

of this document. 
Technical Report Documentation Page 

1. Report No. 

FMCSA-RRT-07-030 

2. Government Accession No. 3. Recipient’s Catalog No. 

4. Title and Subtitle 

Onboard Monitoring and Reporting for Commercial Motor Vehicle Safety 

Final Report 

5. Report Date: 

December 2007 

6. Performing Organization Code 

7. Author(s) 

James A Misener, Christopher Nowakowski, Xiao-Yun Lu, Thomas Koo JD 

Margulici, John Spring, Scott Johnston, ZuWhan Kim, Sue Dickey, Kenny 

Kuhn, Paul Kretz, Jerry Robin, and Martin Walker 

8. Performing Organization Report No. 

9. Performing Organization Name and Address 10. Work Unit No. 

University of California Partners for Advanced Transit and Highway 

(PATH) 

1357 S. 46th Street, Bldg 452 

Richmond, CA 94804-4648 

11. Contract or Grant No. 

13. Type of Report and Period Covered 

Final Report 

12. Sponsoring Agency Name and Address 

Department of Transportation 

Federal Motor Carrier Safety Administration 

Office of Research and Analysis 

1200 New Jersey Ave. SE, Room 600 West 

Washington, DC 20590 

14. Sponsoring Agency Code 

FMCSA 

15. Supplementary Notes 

16. Abstract 

This Final Report describes the process and product from the project, Onboard Monitoring and Reporting for Commercial 

Motor Vehicle Safety (OBMS), in which a prototypical suite of hardware and software on a class 8 truck was developed and 

tested. 

The OBMS suite allows for online measurement of a set of driving characteristics which are indicators of unsafe driving 

behavior. These characteristics included speed, following distance, lane-keeping performance, safety belt use, and the use of 

turn signals. Feedback could be provided to the drivers, either directly via real-time feedback or through carrier 

management, to allow drivers to significantly improve their safety performance. For example, if a driver received a report 

that he/she is not using his/her turn signals during lane changes, that driver can then be monitored during a follow-up period 

to determine if the feedback had corrected the deficiency. Commercial fleets would pioneer this concept because they have 

the resources and organizational structure to provide feedback and training to professional drivers. This concept differs from 

commercial onboard devices in that it is an ensemble set of instruments (not one or a few warning devices) with a safety 

focus and different feedback modalities. It is comprehensive in that it addresses crash causes and provides “corrective” 

feedback in real-time and/or post trip feedback, depending on the particular subsystem(s) which are activated. In essence, the 

objective is to improve driver safety behavior. Thus, it does not explicitly address fleet management or other non-safety 

operations (for example, vehicle location). 

A systems engineering process was applied to this research, resulting in a prototypical OBMS hardware suite and a plan 

to follow-up this effort with an FOT. This project is the result of a Federal Motor Carrier Safety Administration’s 

Cooperative Agreement with the California Department of Transportation (Caltrans). It was undertaken by the California 

Partners for Advanced Transit and Highways (PATH) program, with assistance from the California Center for Innovative 

Transportation (CCIT) and a subcontractor, Advanced Systems Engineering Consulting.

17. Key Words: 

Commercial Motor Vehicle, Driver Safety, Electronic Onboard Recorder, 

FOT, Hours of Service, Lane Departure Warning Systems, Onboard 

Monitoring 

18. Distribution Statement 

19. Security Classification (of this report) 20. Security Classif. (of this page) 21. No. of Pages 

226 

22. Price 

Form DOT F 1700.7 (8-72) Reproduction of completed page authorized.
SI* (MODERN METRIC) CONVERSION FACTORS 

APPROXIMATE CONVERSIONS TO SI UNITS APPROXIMATE CONVERSIONS FROM 

Symbol When You Know Multiply By To Find Symbol Symbol When You Know Multiply By 

LENGTH LENGTH 

in inches 25.4 millimeters mm mm millimeters 0.039 inft feet 0.305 meters m m meters 3.28 feyd yards 0.914 meters m m meters 1.09 Ymi miles 1.61 kilometers km km kilometers 0.621 m

AREA AREA 

in2 square inches 645.2 square millimeters mm2 mm2 square millimeters 0.0016 sqft2 square feet 0.093 square meters m2 m2 square meters 10.764 sqyd2 square yards 0.836 square meters m2 m2 square meters 1.195 sqac acres 0.405 hectares ha ha hectares 2.47 acmi2 square miles 2.59 square kilometers km2 km2 square kilometers 0.386 sq

VOLUME VOLUME 

fl oz fluid ounces 29.57 milliliters ml ml milliliters 0.034 flgal gallons 3.785 liters l l liters 0.264 gft3 cubic feet 0.028 cubic meters m3 m3 cubic meters 35.71 cuyd3 cubic yards 0.765 cubic meters m3 m3 cubic meters 1.307 cu

MASS MASS 

oz ounces 28.35 grams g g grams 0.035 oulb pounds 0.454 kilograms kg kg kilograms 2.202 poT short tons (2000 lbs) 0.907 megagrams Mg Mg megagrams 1.103 sh

TEMPERATURE (exact) TEMPERATURE (exact) 

°F Fahrenheit 5(F-32)/9 Celsius °C °C Celsius 1.8 C + 32 F

temperature or (F-32)/1.8 temperature temperature te

ILLUMINATION ILLUMINATION 

fc foot-candles 10.76 lux lx lx lux 0.0929 fofl foot-Lamberts 3.426 candela/m2 cd/m2 cd/m2 candela/m2 0.2919 fo

FORCE and PRESSURE or STRESS FORCE and PRESSURE or ST

lbf pound-force 4.45 newtons N N newtons 0.225 ppsi pound-force per square inch 6.89 kilopascals kPa kPa kilopascals 0.145 p

pe

* SI is the symbol for the International System of Units. Appropriate rounding should be made to comply with Section 4 of A
TABLE OF CONTENTS 

List of Acronyms.......................................................................................................................... vi

Executive Summary................................................................................................................... viii

1. Introduction................................................................................................................................1

2. Onboard Monitoring Concept Development...........................................................................5

2.1. Delineating Causal Factors in Crashes ............................................................................5 

2.2. Driver Behavior Task Analysis......................................................................................18 

2.3. Principles to Guide Driver Monitoring Feedback..........................................................22 

2.4. Onboard Monitoring Review .........................................................................................25 

2.5. Proposed Driver Monitoring Tasks and Methods..........................................................36 

3. Stakeholder Feedback .............................................................................................................57

3.1. Group Discussions .........................................................................................................57 

3.2. Carrier Q&A Discussion Outline...................................................................................58 

3.3. Summary Results and Relevancy...................................................................................62 

4. Prototype System .....................................................................................................................71

4.1. Overview of OBMS Prototype Implementation ............................................................71 

4.2. Hardware Layout and Operating Principles...................................................................75 

4.3. Software Building Blocks and Interfaces ......................................................................82 

5. OBMS Functions......................................................................................................................91

5.1. Truck Following/Stopping ALGORITHM DEVELOPMENT .....................................91 

5.2. Fatigue and Inattention Detection................................................................................109 

6. Onboard Monitoring Performance ......................................................................................119

6.1. Driver Feedback...........................................................................................................119 

7. FOT Planning.........................................................................................................................132

8. Summary and Conclusions....................................................................................................135

i 
Appendix A: Systems Engineering Process and Chronology ................................................139

A.1. Integration ...................................................................................................................139 

A.2. Configuration Management ........................................................................................141 

A.3. Verification .................................................................................................................142 

A.4 Risk Management ........................................................................................................144 

Appendix B: Systems Engineering Management Plan...........................................................145

B.1. Introduction .................................................................................................................145 

B.2. SystemS engineering process......................................................................................146 

B.3. Engineering disciplines and integration ......................................................................150 

B.4. Product deployment.....................................................................................................153

B.5. Technical plans............................................................................................................155 

B.6. Team, resources, and organization..............................................................................163 

Appendix C: System Requirements Document.......................................................................187

C.1. Background and scope ................................................................................................187 

C.2. System requirements ...................................................................................................191 

C.3. Enabling requirements.................................................................................................196 

C.4. Onboard processor (OBP) requirements .....................................................................198 

C.5. Input sensor requirements ...........................................................................................204 

C.6. Driver interfaces..........................................................................................................207 

C.7. Data storage.................................................................................................................208 

C.8. Analysis module..........................................................................................................208 

ii 
LIST OF TABLES 

Table 1 Summary of OBMS Suite: Functions, Monitored Elements, and Feedbacks.................... x 

Table 2. Critical Safety Behaviors or Issues................................................................................... 8 

Table 3. Most Common Self-Reported Aberrant Driving Behaviors in New Zealand .................. 9 

Table 4. Fatal Crash Type Distribution When the Truck Driver Was Primarily Responsible ..... 10 

Table 5. Fatal Crash Casual Factors When the Truck Driver Was Primarily Responsible .......... 10 

Table 6. Trucks Involved in Fatal Crashes by Crash Type........................................................... 11 

Table 7. Fault Distribution of Crash Types .................................................................................. 12 

Table 8. LTCCS Critical Events by Vehicle Exhibiting the Critical Event.................................. 13 

Table 9. Critical Reasons for Two-Vehicle Crashes Involving Trucks........................................ 13 

Table 10. Comparing Critical Reasons Between Studies ............................................................. 15 

Table 11. Related Factors Described in the 2006 LTCCS Interim Results .................................. 15 

Table 12. Possible Behavioral Failures for Crashes Resulting From Lane Departure ................. 19 

Table 13. Possible Behavioral Failures for Intersection Crashes ................................................. 20 

Table 14. Possible Behavioral Failures in Rear-End Crashes....................................................... 21 

Table 15. Factors Influencing Onboard Monitoring Acceptance ................................................. 28 

Table 16. Basic Feature Comparison Among OBMS Products—by Company ........................... 31 

Table 17. Comparison of Approaches Taken To Provide Feedback to Drivers—by Company... 32 

Table 18. Safe Following Distance by Speed for Cars and Trucks .............................................. 40 

Table 19. Federal Regulations for Interstate Travel Versus California State Code...................... 51 

Table 20. Features of Three Current COTS Devices Currently on the Market ............................ 51 

Table 21. COTS Systems and the Auxiliary Vehicle Parameters Monitored............................... 55 

Table 22. Institutional Issues: Known Positives and Negatives ................................................... 60 

Table 23. Component Cards of OBMS Prototype PC104 Onboard Processor............................. 73 

Table 24. Sensor Systems and Data Sources of OBMS Prototype............................................... 73 

Table 25. Sensor Requirements and Corresponding OBMS Prototype Components................... 74 

Table 26. Driving Parameter Requirements and OBMS Prototype Data Source ......................... 75 

Table 27. Average Total Stopping Distance Versus Weight ........................................................ 94 

Table 28. Tire Slip Coefficients in Weather Conditions (Flat Asphalt/Concrete Road) .............. 96 

Table 29 Vehicle Speed and Stopping Distances ......................................................................... 97 

Table 30. Analytical Relationship Between Stopping Distance and Vehicle Speed .................... 98 

Table 31. Definition Criteria for Following Too Closely, Straddling Lanes, and Driving 

 Too Fast ...................................................................................................................... 112 

Table 32. ISA Driver Feedback Design in Recent International FOT Efforts............................ 120 

Table 33. Following Distance (Time-Gap) Driver Feedback Design in FOT Efforts................ 123 

Table 34. Lane Departure Driver Feedback Designs.................................................................. 125 

Table 35. Attributes To Be Monitored and Associated Feedback Methods............................... 133 

Table 36. Summary of OBMS Suite: Functions, Monitored Elements, Feedback..................... 138 

Table 37. Engineering Specialties Integration in the Systems Engineering Process.................. 152 

iii 
Table 38. Project Deliverables.................................................................................................... 154 

Table 39. Integration Plan........................................................................................................... 155 

Table 40. Configuration Management Plan................................................................................ 156 

Table 41. Verification Plan......................................................................................................... 157 

Table 42. Risk Management Plan ............................................................................................... 158 

Table 43. ConOps Plan ............................................................................................................... 159 

Table 44. Hardware Development Plan...................................................................................... 160 

Table 45. Software Development Plan ....................................................................................... 161 

Table 46. Data Intelligence Development Plan .......................................................................... 162 

Table 47. Driving Parameters ..................................................................................................... 191 

Table 48. System Events............................................................................................................. 192 

Table 49. Sensors and Information Sources Included in System................................................ 196 

LIST OF FIGURES 

Figure 1. Vehicle Used for OBMS Prototype Integration ............................................................. ix 

Figure 2. Depiction of OBMS Driver Feedback............................................................................ xi 

Figure 3. Six Subsystems of Onboard Monitoring System........................................................... xii 

Figure 4. Vee Diagram of Project................................................................................................... 2 

Figure 5. Onboard Monitoring Feedback in the Scheme of Driver Assistance Systems............. 23 

Figure 6. Typical OBM System.................................................................................................... 29 

Figure 7. OBMS Prototype PC104 and Sensor Interfaces............................................................ 72 

Figure 8. Freightliner Tractor Platform Used for OBMS Prototype System............................... 76 

Figure 9. Computer and Associated Electronics........................................................................... 77 

Figure 10. Radar and Lidar Sensors.............................................................................................. 78 

Figure 11. Road Surface Detection System Sensor ...................................................................... 79 

Figure 12. Steering Wheel Angle Sensor (String Potentiometer)................................................. 80 

Figure 13. Rate Gyro and Accelerometer Enclosure (Opened) .................................................... 80 

Figure 14. Brake Pressure Transducer.......................................................................................... 81 

Figure 15. Camera Enclosure........................................................................................................ 82 

Figure 16. Publish and Subscribe Data Clients in OBMS Prototype............................................ 84 

Figure 17. Forward Road Scene: Single Car ................................................................................ 88 

Figure 18 Forward Road Scene: Multiple Cars ............................................................................ 89 

Figure 19. Truck Speed Versus Recommended Distance........................................................... 102 

Figure 20. Vehicle Sprung Mass Model ..................................................................................... 104 

Figure 21. Different Realizations of Crossover Model............................................................... 110 

Figure 22. Human Information Processing Model ..................................................................... 111 

Figure 23. Driver Model Using ARMAX Structure ................................................................... 111 

iv 
Figure 24. General Driver-Vehicle Interactions ......................................................................... 114 

Figure 25. Probability Distribution of SDLP of the Driver With Different Levels of 

Alertness ............................................................................................................................... 115 

Figure 26. Fatigue Flags Based on Standard Deviation of Lane Positions................................ 116 

Figure 27. Frequency Response of the Original PE Filter With Sampling Frequency of 4 Hz. 117 

Figure 28. Implemented Inattention Detection Algorithm ......................................................... 118 

Figure 29. OBMS Prototype ISA Visual Feedback Design........................................................ 121 

Figure 30. OBMS Prototype Following Time-Gap Visual Feedback Design ........................... 124 

Figure 31. COTS SafeTRAC Lane Departure Warning System DVI ........................................ 126 

Figure 32. OBMS Prototype Lane Departure Warning Visual Feedback Design ..................... 126 

Figure 33. OBMS Prototype Visual Feedback Design for Seat Belt and Side Obstacles ......... 128 

Figure 34. Systems Engineering Vee Diagram Illustrating Sequence of 10 Tasks to 

Complete FOT ...................................................................................................................... 133 

Figure 35. Vee Diagram of Project............................................................................................. 136 

Figure 36. Block Diagram of OBMS Prototype PC104 and Sensor Interfaces......................... 137 

Figure 37. Top-Level Overview of Integrated Components....................................................... 140 

Figure 38. Overview of Hardware Integration Components/Topics .......................................... 141 

Figure 39. Functional Relationships Between Sensor Data and Monitoring System................. 143 

Figure 40. Vee Diagram.............................................................................................................. 148 

Figure 41. Vee Diagram Acceleration ........................................................................................ 150 

Figure 42. Project Organizational Chart ..................................................................................... 163

Figure 43. Overall System Architecture ..................................................................................... 189 

v 
LIST OF ACRONYMS 

ACAS Automotive Collision Avoidance System 

ADASRP Advanced Driver Assistance Systems Research Platform 

APP Accelerator Pedal Pushback 

ARMAX Auto-regression moving average with exogenous inputs 

Caltrans California Department of Transportation 

CAN Controller Area Network 

CCIT California Center for Innovative Transportation, UC Berkeley 

CG Center of gravity 

CMV Commercial Motor Vehicle 

COM Designates a requirement that applies only to ultimate commercialization 

ConOps Concept of Operations 

COTS Commercial off-the-Shelf (commercially available product) 

CSW Curve Speed Warning 

DDU Driver Display Unit 

DRI Caltrans’ Division of Research and Innovation 

DSP Digital Sound Processor 

DVI Driver-Vehicle Interface 

EOBR Electronic Onboard Recorder 

FARS Fatality Analysis Reporting System 

FCWS Forward-Collision Warning System 

FHWA Federal Highway Administration 

FMCSA Federal Motor Carrier Safety Administration 

FMEA Failure Modes and Effects Analysis 

FOT Field Operational Testing 

FT Designates a requirement that applies to the FOT but not to the prototype 

GIS Geographical Information System 

GPS Geographical Positioning System 

GUI Graphical User Interface 

HHDD High Head-Down Display 

HOS Hours of Service 

ISA Intelligent Speed Adaptation 

ITS Institute of Transportation Studies 

LCD Liquid Crystal Display 

LDWS Lane Departure Warning System 

LTCCS Large Truck Crash Causation Study 

vi 
MTBF Mean Time Between Failures 

MVMT Million Vehicle Miles Traveled 

NEMA National Electrical Manufacturers Association 

NHTSA National Highway Traffic Safety Administration 

NTSC National Television Standards Committee 

OBM Onboard monitoring 

OBMS Onboard Monitoring System 

OBP Onboard Processor 

OEM Original Engineering Manufacturer 

PATH Partners for Advanced Transit and Highways, UC Berkeley 

PE Prediction error 

PERCLOS Percentage of eye closure 

RCA Root Cause Analysis 

RDWS Road Departure Warning System 

RODS Records of duty status 

RPM Revolutions per minute 

SAE Society of Automotive Engineers 

SDLP Standard deviation of lane positions 

SEMP Systems Engineering Management Plan 

TLC Time-to-line crossing 

TPM Technical Performance Measure 

TRB Transportation Research Board 

TTR Time-to-Rollover 

UMTRI University of Michigan Transportation Research Institute 

VHT Vehicle-Hours Traveled 

VMT Vehicle-Miles Traveled 

vii 
EXECUTIVE SUMMARY 

The mission of the Federal Motor Carrier Safety Administration (FMCSA) is to promote the safe 

operation of commercial vehicles on our Nation’s highways. Of all the people killed in motor 

vehicle crashes in 2005, 12% (5,240) died in crashes that involved a large truck. Another 

114,000 people were injured in crashes involving large trucks. Only about 15% of those killed 

and 24% of those injured in large truck crashes were occupants of large trucks. 

As the Onboard Monitoring project is discussed in this report, please also consider the following 

2005 Large Truck Crash statistics: 

• From 1995 to 2005, the number of large trucks involved in fatal crashes increased from 

4,472 to 4,932 – up 10 percent. The number of large trucks in fatal crashes per 100 

million vehicle miles traveled declined in these years from 2.5 to 2.2 – down 12 percent. 

The same rate for passenger vehicles fell from 2.2 to 1.7 – down 23 percent. 

• From 1995 to 2005, the number of large trucks involved in injury crashes per 100 million 

vehicle miles traveled declined by 21 percent, while the rate for passenger vehicles 

dropped by 36 percent. 

• In 2005, 4,932 large trucks were involved in fatal crashes, 82,000 were involved in injury 

crashes and 354,000 trucks in property damage only crashes. 

• In 2005, large trucks accounted for 7 percent of all vehicle miles traveled and 3 percent 

of all registered vehicles in the United States. In motor vehicle crashes, large truck 

represented: 

– 8 percent of all vehicles in fatal crashes, 

– 3 percent of all vehicles in injury crashes, and 

– 5 percent of all vehicles in property damage only crashes. 

• Speeding (exceeding the sped limit or driving too fast for conditions) was a factor in 22% 

of the fatal crashes involving a large truck, compared with 32% of all fatal crashes. In 

addition to speeding, some of the most common factor cited for drivers of large trucks 

(and drivers of passenger vehicles) were: 

– Failure to keep in proper lane 

– Inattention, and 

– Failure to yield the right of way. 

• Of the drivers of large truck involved in fatal crashes, 15 percent were not wearing a 

safety belt at the time of the crash, of those, 21 percent were completely or partially 

ejected from the vehicle. 

While significant improvements are in highway safety are being realized, more must be done to 

further reduce the number of truck-involved crashes and resulting fatalities and injuries. 

The OBMS project has produced a prototypical suite of hardware on a Freightliner Century Class 

truck at the Richmond Field Station, shown in Figure 1 below. 

viii 
Figure 1. Vehicle Used for OBMS Prototype Integration 

The hardware suite allows for online measurement of a set of driving characteristics which are 

indicators of unsafe driving behavior. These characteristics include speed, following distance, 

lane-keeping performance, safety belt use, and the use of turn signals. Feedback can be provided 

to drivers, either directly in real-time or through carrier management, which would allow drivers 

to significantly improve their safety performance. For example, if a driver receives a report that 

he/she is not using his/her turn signals during lane changes, that driver can then be monitored 

during a follow-up period to determine if the feedback had corrected the deficiency. This concept 

would be pioneered in commercial fleets because they have the resources and organizational 

structure to provide feedback and training to professional drivers. 

In the OBMS prototype development work, the monitored parameters and the type of feedback 

to be given were systematically examined by first examining commercial vehicle crash causes, 

and then deriving five categories or “core behavioral categories,” which, as a whole, comprise 

the feature set recommendations for an ideal onboard driver monitoring system. The five 

monitoring categories or behaviors are listed as follows: 

1. Speed Selection 

2. Following Behavior 

3. Attention (or Inattention) 

4. Fatigue 

5. General Safety 

From examination of these categories and by synthesizing the literature examined (and reported) 

during the course of this project, specific monitoring methods, parameters, and feedback were 

determined, and a prototype suite was developed. Table 1 summarizes the suite by mapping 

classes of monitored behavior to specific application descriptors and the type of real-time 

ix 
feedback provided. All behaviors exceeding threshold values are fed back to the driver and 

reported to the carrier. 

Table 1 Summary of OBMS Suite: Functions, Monitored Elements, and Feedbacks 

Core 

Behavioral 

Categories 

Potential 

Behaviors/ Parameters 

To Be Monitored 

Required 

Sensors or 

Subsystems 

Potential Driver 

Feedback 

Real-Time 

Potential Driver 

Feedback 

Offline 

1. 

Speed 

Selection 

Speed versus: 

- Speed Limit 

- Traffic Flow 

- Curve Speed 

- Road Surface 

- Grade 

Vehicle J-bus Access 

GPS 

Database of Speed Limits 

Road Surface/Weather 

Radar or Lidar 

Accelerometer 

Visual feedback 

of recommended 

and maximum 

speed limits 

Summary metrics 

such as the time 

spent over the 

recommended and 

maximum speed 

limits 

2. 

Following 

Behavior 

Following Distance 

Forward-Collision Warnings 

Driver Response to Cut-ins 

Forward-Collision Warning 

System (FCWS) 

Radar or Lidar 

Video Recording 

Visual feedback 

of following timegap shown 

Auditory alerts 

for following too 

closely and 

approaching too 

fast 

Summary of time 

spent following too 

closely, number of 

warning incidents, 

video review of 

warning incidents 

3. 

Attention 

(or 

Inattention) 

Road/Lane Departures 

Hard Braking Events 

Hard Steering Events 

Eye-Off-the-Road 

Road Departure Warning 

System (RDWS or LDWS) 

Accelerometer 

Steering Angle 

Steering Gyro 

Video Recording 

Eye/Face Tracking 

Visual and 

auditory alerts of 

lane departures 

or eyes-off-theroad for too long 

Summary metrics 

such as the 

frequency of lane 

departures, hard 

braking, and hard 

steering incidents 

4. 

Fatigue 

Road/Lane Departures 

Lane Position Keeping 

Hard Braking Events 

Hard Steering Events 

Eye Closure (PERCLOS) 

Hours of Service (HOS) 

Compliance 

RDWS/LDWS 

Eye Tracking 

Accelerometer 

Steering Angle 

Steering Gyro 

Video Recording 

EOBR (Electronic Onboard 

Recorder for HOS) 

Visual and 

auditory alerts of 

lane departures, 

lane weaving, 

eye closure, and 

HOS compliance 

Summary metrics 

such as the 

frequency of lane 

departures, hard 

braking, hard 

steering incidents, 

and HOS 

compliance 

5. 

General 

Safety 

Safety Belt Use 

Lane Change Turn Signal 

Use 

Lane Change Blind Spot 

Check 

Proper Mirror Adjustment 

Fuel Economy 

Engine Overspeed (RPMs) 

Acceleration 

Deceleration (Downshifting) 

Gear selection on grades 

Safety Belt Monitor 

Video Recording 

RDWS/LDWS 

Eye/Face Tracking 

Accelerometer 

Vehicle J-bus Access 

MiscWire Taps 

Visual and 

auditory alerts if 

safety belt is not 

use 

Visual feedback 

on other 

parameters 

Summary metrics 

such as time spent 

using the safety 

belt and the other 

listed parameters 

x 
For the OBMS prototype, if feedback was supplied by a Commercial Off-the-Shelf (COTS) 

system, that feedback was kept. Additional feedback was provided via audio channel and via 

surrogate instrument cluster displayed in a 7-inch LCD screen, as illustrated in Figure 2. In that 

figure, the suggested speed limit for the given road surface and curvature is the portion of the 

circular speedometer gauge not outlined in red. The suggested safe following-distance feedback, 

again providing for the prevailing road surface condition (and for this function, by the sensed 

“field” of other forward vehicles), is the color and size of the vehicle shown at the bottom of the 

surrogate cluster. In this instance, the vehicle is colored green; when following too closely for 

prevailing conditions, the vehicle changes to yellow, then red, and grows or looms. Also, beneath 

the green vehicle icon is the car following gap, given in seconds. Finally, the “driver ID”, “HOS 

[hours of service] remaining” and “Alertness Index” are also provided as direct feedback of a 

prototypical digital tachometer. A drowsiness/alertness warning which supplements that 

subsystem’s COTS-based feedback is also provided. 

Figure 2. Depiction of OBMS Driver Feedback 

Figure 3 diagrams the prototype OBMS, which consists of six subsystems: 

• Core system 

• Sensing equipment 

• Data storage devices 

• Real-time feedback devices 

• Driver input devices 

• Offline analysis tools 

xi 
In Figure 3, (1) sensors input to the (2) onboard processor, which outputs to (3) data storage and 

(4) analysis modules. Driver interfaces (5) also interact with the onboard processor. Additionally, 

(6) hardware mounts and cables interact with all except the analysis module. The analysis 

module is offboard and all other subsystems are onboard. 

Hardware Mounts and Cables 

(6)

Driver Interfaces

(5) Onboard Offboard 

OBP/Core Unit 

(2) 

Sensors 

(1) 

Data Storage 

(3) 

Analysis Modules

(4) 

Figure 3. Six Subsystems of Onboard Monitoring System 

This prototype was developed using systems engineering principles and, specifically, via the vee 

diagram methodology. This entailed development and use of a concept of operations 

(ConOps)—a derived set of requirements which defines the OBMS. 

The background, data sources, tradeoff considerations, description of the hardware, software, and 

applications of the OBMS—plus a description of a notional FOT—are discussed in detail within 

this report and its appendices. 

This prototype was tested on a Los Angeles-based fleet of 100 drivers to determine the suitability 

of this hardware suite to the firm’s management and truckers. In FY08, it is anticipated that a 

different, larger fleet will be used to conduct an FOT to replicate this suite on a host of other 

vehicles to determine the technical and operational effectiveness of the OBMS suite of 

monitoring systems. 

xii 
1. INTRODUCTION 

Each year over 450,000 large trucks are involved in crashes resulting in about 5,000 fatalities 

and 114,000 injuries according to the most recent compilation of traffic safety facts released by 

the National Highway Traffic Safety Administration (NHTSA). Overall, crashes involving large 

trucks comprise 4.1 percent of all crashes, but they also contribute to 12 percent of all fatalities 

(or one out of every nine). Due to the size and mass differential, more than 85 percent of the 

time, the fatality was not an occupant of the truck (NHTSA, 2005). 

The general case for truck driver monitoring in the trucking industry has already been made 

through research sponsored by the Federal Motor Carrier Safety Administration (FMCSA) and is 

best summarized in a technical brief (Behavioral Science and Technology, 2000). In its most 

simplistic form, the behavior-based safety approach is a method for improving safety—one in 

which the behaviors critical to safety are identified and monitored. Safe behavior is rewarded and 

unsafe behavior is discouraged and improved upon, thereby proactively improving overall safety. 

In section 2 of this report, three types of studies will be presented on the topic of delineating the 

causal factors in large truck crashes: expert interviews, reviews of crash statistics, and the Large 

Truck Crash Causation Study (LTCCS). Although all of these sources had both advantages and 

disadvantages, the LTCCS (Craft and Blower, 2004) suggested three general categories of 

critical events leading to crashes that could be considered high priorities: (1) driving over the 

lane markings or off the road, (2) turning at or crossing an intersection, and (3) rear-end 

collisions. The most common reasons for the critical event were driver errors in recognitions 

(due to inattention or distraction) and errors in decisions (misjudgments). In support of this 

assertion, the industry experts, truck drivers, fleet managers, and safety experts, all agreed that 

the inattention and distraction are major problems which need to be addressed. Furthermore, 

according to surveys, fleet managers often estimate that their worst 10 percent of drivers account 

for up to 50 percent of their fleet risk, and this estimate was supported in a critical incident 

analysis of the instrumented vehicles (Knipling, 2005). In this study, the worst 6 drivers, 

accounting for only 12 percent of the driving time, were responsible for 38 percent of the critical 

incidents. In contrast, the best 25 drivers, accounting for 63 percent of the driving time, were 

only responsible for 16 percent of the critical incidents. Onboard driver monitoring and feedback 

may be one way to objectively identify high-risk drivers and help them to curb risky driving 

behavior. 

Also, as discussed in an earlier project report, the concept onboard driver monitoring comes from 

the behavior-based safety approach. Using this method, safe behavior is rewarded and unsafe 

behavior is discouraged and improved upon, thereby proactively improving overall safety. 

Implementing an onboard driver-monitoring, behavior-based safety approach generally requires 

four steps (Sherry, 2001): 

1. Identify behaviors which may be precursors to increased crash rates. 

2. Determine cost-effective ways to monitor safe and unsafe behaviors. 

1 
3. Determine the best way to provide the driver with feedback which rewards safe behavior 

and discourages unsafe behavior. 

4. Establish management and driver acceptance to the program. 

These four steps constitute the fundamental basis or philosophy of OBMS. The pragmatic or 

implementation dimension was built upon this and consumed approximately 80 percent of the 

time and resources of the project. Driven by necessity since the project scope was ambitious—to 

research the aforementioned elements of an OBMS system, then, on a fast track, develop a 

prototype and set the stage for a FOT, the project was tailored to and performed with the 

principles of systems engineering. The nomograph shown in Figure 4 illustrates the project tasks, 

conducted along the left side, then travels down to the vertex of the vee diagram, then up to the 

low-speed testing, through the horizontal dashed line to the environs of the PATH facility of the 

Richmond Field Station, which includes public roads outside the premises. 

On-Board Monitoring to Improve 

Commercial Motor Vehicle Safety 

(OBMS) 

CG10 

CG9 

Field Operational Evaluation 

Plan

OBMS System Verification Plan 

(System Acceptance) 

CG1 

Control Gates 

Phase 3 

Deployment 

Phase 2 

Field Operational 

Test 

CG8 

High Speed 

Evaluation

Low Speed 

Evaluation

Crows Landing ?? 

Richmond Field 

Station 

OBMS SS 

Evaluation

CG7 

CG2 

CG3 

CG4 

CG5 CG6 

SW/HW 

Evaluation Level

Software Coding 

Hardware Fabrication 

Bench/On-Board Installation 

Planning Integration 

Deployment 

Development 

Installation 

Verification 

Procurement 

Causal Study 

Human Factors 

OBMS - ConOps 

OBMS SS 

Requirements 

OBMS SS 

ConOps 

OBMV SS 

Requirements/Final 

Architecture 

OBMS 

SW/HW 

Detailed Design 

Safety Sub-Systems 

Verification Plan 

SW / HW 

Verification 

CG1 – Planning Framework, Stakeholders Identified, Long Haul Carrier

CG2 – Approve ConOps 

CG3 – Approve System Requirements 

CG4 – Approve Subsystem Req 

CG5 – SW/HW Detailed Design Review 

CG6 – On-board sub-system integration 

CG7 – On-board Unit Verification 

CG8 – On-board SS Verification 

CG9 – TSS Verification – Approve FOT 

CG10 – Approve Deployment 

SW/HW = Software & Hardware 

COTS 

Sensors 

Alarm 

Evaluation 

Concept Exploration 

Alternative Architectures 

Measures of Effectiveness 

Measures of Merit 

Risk Identification 

External Interfaces Identified 

Deployment Plan 

Procurement Plan 

= Detailed

Integration Plan 

Installation Plan 

Development Plan 

External Interfaces 

Internal Interfaces 

Defined and Documented 

Project Management 

Risk Monitoring 

Configuration Management 

(Through-out the Development) 

Figure 4. Vee Diagram of Project 

2 
The OBMS-customized vee diagram illustrated in Figure 4 consists of Planning, Causal Study, 

Requirements, ConOps, Requirements and System Architecture, and Detailed Design on the 

downward-pointing segment of the diagram. The vertex consists of software coding and 

hardware fabrication. The upward-pointing segment of the diagram is the Software-Hardware 

Evaluation (stemming from the Detailed Design and bridged by a Verification Plan), System 

Evaluation (stemming from the ConOps and Requirements and bridged by the System 

Acceptance Plan), and finally the Phase 2 or next project FOT (stemming from Planning and 

bridged by the Field Operation Evaluation). At each of these major elements is a decision gate. 

This project is structured to reflect the logical sequence of the work performed. The project 

results are described chronologically, beginning with Section 2.0: Onboard Monitoring Concept 

Development. This section describes driver behavior, functional needs and product background 

that formed the project ConOps. This section is particularly important as the content therein 

forms the basis for the requirements and actual implementation of the OBMS system. Section 

3.0: Stakeholder Feedback details the group discussions, the questionnaire outline that was 

administered to the truck drivers, and the associated summary results and relevancies. 

The resulting hardware and software that constitute the prototype OBMS is described in Section 

4.0: Prototype System. This is followed by Section 5.0: OBMS Functions, which describe some 

of the PATH-developed algorithms and applications that leverage the existent hardware. How 

the interface to the driver and system inputs work is described in Section 6.0: Onboard 

Monitoring Performance. 

An activity begun about midway through the project was to co-develop a FOT plan with a 

commercial carrier. Section 7.0: FOT Planning briefly describes the process and next steps, then 

details a notional FOT Statement of Work that was developed in the time frame of this project. 

Finally, Section 8.0: Summary and Conclusions provides a summary of the project vis-à-vis 

initial objectives and outlines a set of recommended further activities. 

REFERENCES (SECTION 1): 

Craft, Rand Blower, D (2004) An Overview of the Large Truck Crash Causation Study A 

Presentation Given at The 3rd Annual Stakeholder’s Forum on November 30th in Phoenix, 

Arizona Washington, D.C.: The Federal Motor Carrier Safety Administration’s Office of 

Research and Technology. 

Knipling, R(2005) Evidence and Dimensions of Commercial Driver Differential Crash Risk 

Proceedings of the Third International Driving Symposium on Human Factors in Driving 

Assessment, Training, and Vehicle Designpp2-8. 

National Highway Traffic Safety Administration (2003) Traffic Safety Facts 2003: A 

Compilation of Motor Vehicle Crash Data from the Fatality Analysis Reporting System and 

the General Estimates System (DOT HS 809 775 and DOT HS 809 763) Washington, DC: 

National Center for Statistics and Analysis [http://www.nhtsa.dot.gov/people/ncsa] 

3 
Sherry, P(2001) In-Vehicle Monitoring Technologies: Review of Current Use and Potential 

Enhancement Through Behaviorally Based Safety Processes (Report Submitted to the 

American Trucking Association Foundation) Denver, CO: The University of Denver. 

4 
2. ONBOARD MONITORING CONCEPT DEVELOPMENT 

This section provides background on the topic of onboard driver monitoring systems for use in 

commercial heavy vehicles and serves as a basis for the suite used on the prototype system 

developed for this project. To reiterate, the purpose of this project was to develop a ConOps and 

a required sensor suite for an ideal driver monitoring system which would help to improve fleet 

safety. These were developed based on information gathered from the industry and on previous 

research summarized in this report. Furthermore, an expert group of professional drivers and an 

advisory panel of industry experts and practitioners reviewed and supplemented the findings of 

these reports. This section is divided into six subsections: 

1. Delineating Causal Factors in Crashes 

2. Driver Behavior Task Analysis 

3. Principles To Guide Driver Monitoring Feedback 

4. Onboard Monitoring Review 

5. Proposed Driver Monitoring Tasks and Methods 

6. Stakeholder Feedback 

These subsections build upon one another, with the first subsection providing a literature-based 

foundation on what causes truck driver crashes (including reports and papers from recent 

FMCSA-sponsored research) and the second subsection further breaking driver crash causes into 

specific tasks. On top of these sections is the third subsection (Principles To Guide Driver 

Monitoring Feedback), which overlays onto the previous two sections a fundamental philosophy 

and approach. A fourth subsection (Onboard Monitoring Review) and fifth subsection (Proposed 

Driver Monitoring Tasks and Methods) follow, where specific and objective OBMS measures 

are suggested, and short descriptions of COTS devices, as they existed at the time of the project’s 

review, are provided. Lastly, stakeholder feedback—in the form of expert interviews with a midsized, Los Angeles-based carrier—is covered It is the combination of these factors and COTS 

devices, via the systems approach, that led to decision and installation of the suite of OBMS 

hardware described in section 4.0. 

2.1. DELINEATING CAUSAL FACTORS IN CRASHES 

2.1.1. Introduction 

Historically, three methods have commonly been employed to approach the problem of heavyvehicle crash causation. First, panels of drivers or experts have been consulted to generate lists of 

safety issues in the trucking industry and “unsafe” driving behaviors. While these methods are 

completely subjective, they are based on drivers’ experiences and often provide a useful 

perspective. 

Second, many studies have mined the crash statistics associated with large trucks with some 

success. Unfortunately, crash reports, as currently recorded in the United States, are often vague 

and lacking in important details, and, thus, do not necessarily reflect or contain the true causes of 

a crash. Additionally, many of past studies which are reviewed in this section have tried to 

5 
categorize or examine crashes in terms of “fault,” which is a fairly subjective designation and 

should be read as such. 

In response to these sorts of issues, a third approach, the LTCCS, addressed the problem with a 

more robust perspective and method. Instead of trying to determine “cause” or “fault” directly, 

the LTCCS addressed “cause” in terms of critical events, critical errors that lead to those events, 

and contributing factors. 

2.1.2. Safety Issues From the Trucking Industry 

Studies in the United States 

In 2003, the first in a series of Transportation Research Board (TRB) reports on commercial 

truck and bus safety was published. In this report (Knipling, Hickman, and Bergoffen, 2003), 

surveyed CMV fleet managers and experts in motor vehicle safety on the importance of 20 

perceived safety problem areas in the trucking industry. The top nine issues that were found are 

listed below: 

1. At-risk driving behaviors (e.g., speeding, tailgating) 

2. Individual high-risk drivers (all causes combined) 

3. Lifestyle or general health issues (e.g., poor diet, smoking) 

4. Lack of defensive driving skills (poor space management) 

5. Delays associated with loading and unloading cargo 

6. Driver fatigue/drowsiness 

7. Aggressive driving 

8. Heart disease 

9. Poor attitude, morale, or emotional state 

Of these nine issues, at-risk driving behaviors, defensive driving skills, fatigue, and aggressive 

driving are all potential candidates for using an onboard monitoring system. Although aggressive 

driving could not be specifically defined, the report went on to define the following as at-risk 

driving behaviors (many based upon prior studies and crash data): 

• Speeding 

• Excessive speed on curves or in relation to weather conditions 

• Improper following distance 

• Lateral encroachment (e.g., during lane changes, due to improper mirror adjustment) 

• Failure to yield at intersection 

• General disobedience of the rules-of-the-road 

The specifics of space management and defensive driving skills were left somewhat undefined. 

The general concept of space management refers to the fact that large trucks have large blind 

spots and limited maneuverability when reacting to actions taken by automobile drivers. In 

effect, space management refers to the need for truck drivers to preventively compensate for any 

poor decisions being made in their presence because many crashes between trucks and 

automobiles tend to be primarily attributed to the actions of the automobile driver. 

6 
Finally, the Knipling, Hickman, and Bergoffen (2003) report provided a good discussion on the 

issue of fatigue. It had been widely reported that fatigue was a large problem and a factor in 31 

percent of single-vehicle, ran-off-the-road crashes in which the truck driver was killed; this 

particular crash type only accounts for 1 in 7 fatal truck crashes and 1 in 700 overall truck 

crashes. Thus, when considering truck crashes overall, the issue of fatigue is ranked as a 

somewhat lower priority and possibly one that is limited mostly to specific segments of the 

trucking industry. 

While the study described above interviewed fleet managers and safety experts, two recent 

studies surveyed truck drivers about their safety concerns. Hanowski, et al. (1998) conducted 11 

focus groups across five states with a total of 82 local- and short-haul (L/SH) truck drivers. 

Across all sessions, the top five critical issues or crash causal factors as seen by drivers were as 

follows (ranked in order of importance to the drivers): 

1. Problems caused by drivers of light vehicles 

2. Stress due to time pressure 

3. Inattention 

4. Problems caused by roadway or dock design 

5. Fatigue 

The problems caused by the drivers of light vehicles, although ranked as the most important 

safety issue, was generally described in vague terms, such as light vehicle drivers do not show 

trucks enough respect. Specifically, cut-ins and backing were listed as problems with light 

vehicles. Interestingly, inattention was listed as one of the top five safety issues by drivers in this 

study, but there was no mention of it by management in the previous study; however, inattention, 

in the context of L/SH drivers, seemed to refer to the issues of multitasking while driving, such 

as planning your next stop or delivery or having to navigate with ineffective road signage. 

Similarly, fatigue, in the eyes of L/SH drivers, was used more in the context of mental fatigue as 

opposed to actually falling asleep at the wheel. Since L/SH drivers tend to work during daylight 

hours and have frequent breaks (deliveries) to interrupt their driving, fatigue is simply the result 

of a normal day’s work, which can be exacerbated by excessive heat (a lack of A/C in their 

vehicles) or irregular meal times. 

Finally, Roetting, et al. (2005) surveyed 239 long-and short-haul drivers specifically asking them 

to rank the importance of several critical safety behaviors. The drivers were presented with ten 

behaviors and asked to select their “top three.” The results are shown below in Table 2, which 

maps critical safety behaviors or issues by percentage of drivers ranking them in their top three 

7 
Table 2. Critical Safety Behaviors or Issues 

Rank 

Critical Safety 

Behaviors or Issues 

% of Drivers Who Ranked 

Behavior in Their Top 3 

1 Looking far enough ahead and 

anticipating changes 

74.4 

2 Being ready to avoid the mistakes of 

other drivers 

55.4 

3 Turn signal use in advance of lane 

changes 

48.7 

4 Properly adjusting mirrors to prevent 

blind spots 

29.2 

5 Drowsy driving 28.2 

6 Speeding 17.4 

7 Seat belt usage 16.4 

8 Following too closely 13.3 

9 Distracting driving 8.7 

10 Being courteous to other drivers 8.7 

International Studies 

In New Zealand, Sullman, Meadows, and Pajo (2002) surveyed 382 truck drivers on the topic of 

aberrant driving behaviors falling into three categories: 

1. Errors 

2. Lapses 

3. Violations 

Errors included such things as failures of observation and misjudgments (e.g., braking too hard 

on a slippery road). Lapses were considered as failures of attention, and violations were 

deliberate actions, such as speeding or tailgating. The questionnaire asked drivers to self-report, 

on a scale of 0 (never) to 5 (all the time), how often they engaged in or experienced a particular 

behavior. Of the three categories, only responses to the questions on violations were predictive of 

increased crash risk. The most commonly reported behaviors in each category (those with a 

mean score above 0.5) are listed in Table 3 comprised of columns categorizing errors as lapses, 

violations, or aggressive driving. 

8 
Table 3. Most Common Self-Reported Aberrant Driving Behaviors in New Zealand 

Errors Lapses Violations 

Aggressive 

Driving 

Underestimating the 

speed of an oncoming 

vehicle while overtaking 

Getting into the wrong lane at a 

junction 

Speeding Honking at others 

Having no recollection of the road you 

just traveled 

Tailgating Showing hostility 

Hitting the wrong control in the vehicle Running a 

red light 

Racing away from 

a traffic light 

Starting in the wrong gear Running a 

red light 

Racing away from 

a traffic light 

Backing into an object Running a 

red light 

Racing away from 

a traffic light 

In Finland, Häkkänen and Summala (2001) surveyed 251 long-haul drivers, asking them to rank 

eight safety issues from the most common to the least common cause of crashes. The results are 

listed below in rank order from most to least common: 

1. Other road users 

2. Errors in truck driver perception or judgment 

4. Speeding 

5. Weather 

6. Fatigue 

7. Errors in operating the vehicle 

8. Traffic environment 

9. Technology faults 

Unfortunately, greater detail on what was meant specifically by errors in perception or judgment 

or errors in operating the vehicle was not available; however, the country of Finland is somewhat 

unique in that every fatal crash involving large trucks has been investigated by a panel of experts 

to determine what factors were relevant in the cause of the crash. From 1991 to 1997, it was 

found that in 83 percent of the crashes involving large trucks, the truck driver was not primarily 

at fault. Similar to the conclusions found in the United States, this evidence supports the truck 

drivers’ view that other road users are the most common cause of crashes. In the 17 percent of 

crashes in which the truck driver was primarily at fault, the breakdown by crash type is listed in 

Table 4, which ranks fatal crash types by percentage. 

9 
Table 4. Fatal Crash Type Distribution When the Truck Driver Was Primarily Responsible 

Rank Crash Type % 

1 Opposite direction or head-on collision 50.9 

2 Same direction (overtaking, change of lane, or rear-end collision) 17.5 

3 Same direction with one vehicle turning 10.5 

4 Intersection straight crossing-path 8.8 

5 Intersection with one vehicle turning into or across path 5.3 

- Opposite direction with one vehicle turning 0.0 

- Other 7.0 

Total 100.0 

The high prevalence of opposite direction head-on collisions is probably due to the fact that most 

of the roads traversed by trucks in Finland are two-lane highways. A different crash type 

distribution would probably be expected in the United States, where multilane freeways are more 

common. In addition to determining which driver was primarily at fault, the panel of experts also 

made determinations about casual factors. Table 5 shows the percentage of crashes attributed to 

each causal factor. Over 50 percent of the fatal truck crashes in which the truck driver was 

primarily at fault were attributed to errors in attention, anticipation, or estimation, and 26 percent 

were attributed to errors in operating the vehicle. Unfortunately, specific details were not given 

on these two classifications. 

Table 5. Fatal Crash Casual Factors When the Truck Driver Was Primarily Responsible 

Rank Causal Factor % 

1 Error in attention, anticipation, or estimation 50.8 

2 Error in operating the vehicle 26.3 

3 Technological faults 7.0 

4 Driver having fallen asleep while driving 5.3 

5 Attack of illness 1.8 

6 Traffic environment 1.8 

- Other reasons 7.0 

Total 100.0 

United States Crash Statistics 

There have been numerous studies employing various methods to analyze the crash statistics 

when large trucks are involved. In the United States, the Center for National Truck and Bus 

Statistics at the University of Michigan Transportation Research Institute (UMTRI) publishes a 

yearly Trucks Involved in Fatal Accidents Factbook, which combines data from the Fatality 

Analysis Reporting System (FARS) with follow-up surveys. From the latest factbook (Matteson, 

10 
Blower, and Woodrooffe, 2004), Table 6 summarizes the types of fatal crashes in which trucks 

are typically involved in, showing by crash type whether the truck was striking or whether 

another vehicle was striking. It is interesting to note that when it comes to fatal crashes, the 

percentage of crashes is fairly evenly distributed among crash types. The largest single category 

of crash type involvement was single vehicle, either ran-off-the-road or hit-an-object-in-the-road. 

The second largest category was rear-end collisions, in which the truck was the striking vehicle 

38 percent of the time. Interestingly, in sideswipe and head-on collisions, the crashes typically 

occurred with the other vehicle striking the truck or moving into the truck’s lane; however, for 

straight crossing-path collisions (at intersections), the truck typically did the striking—probably a 

reflection of the well-known rural crash paradigm in which a light vehicle driver pulls out in 

front of an oncoming truck due to misjudgment of the truck’s distance and speed. 

Table 6. Trucks Involved in Fatal Crashes by Crash Type 

Crash Type 

Truck Striking 

(In Other 

Vehicle’s Lane) 

Other Vehicle 

Striking 

(In Truck’s Lane) 

Total 

(%) 

Single Vehicle — — 14.4 

Rear-end 5.1 8.2 13.3 

Sideswipe 2.2 10.2 12.4 

Intersection (Straight Crossing) 8.0 3.2 11.2 

Head-on 1.1 9.2 10.3 

Intersection (Across Path Turn) — — 9.2 

Backing 0.5 0.1 0.6 

Other 15.5 

Unknown 13.2 

Total 100.0 

Another important study, Council, et al. (2003), examined the North Carolina crash database 

from 1994 to 1997, which included 16,264 car-truck crashes. Although this database is not 

national, it includes all crashes, not just fatal crashes. What is most interesting to note is that 

while national studies of fatal truck crashes have shown that car drivers were considered at fault 

for the crashes almost 70 percent of the time, truck drivers may share more of the blame when it 

comes to overall or nonfatal crashes. As shown in Table 7, the distribution of truck at fault 

versus car at fault by crash type, Council, et al. (2003) found that, overall, fault was more evenly 

split, with 48 percent of crashes being attributed to the truck driver and 40.2 percent being 

attributed to the car driver (with the remaining being attributed to both or neither). 

11 
Table 7. Fault Distribution of Crash Types 

Crash Type 

% of Trucks 

At Fault 

% of Cars 

At Fault 

Total 

% 

Rear-end (slow) 50.7 41.0 25.8 

Rear-end (turning) 51.5 36.0 2.4 

Left turn (same roadway) 45.4 38.6 8.7 

Left turn (crossing traffic) 42.9 48.4 5.9 

Right turn (same roadway) 43.1 35.5 4.7 

Right turn (crossing traffic) 36.2 54.4 2.3 

Head-on 22.5 71.2 1.4 

Sideswipe 51.1 35.1 21.8 

Angle 39.3 48.5 21.4 

Backing 81.5 9.7 5.5 

Total 48.0 40.2 100.0 

Interestingly, most of the crash types show a fairly even split between car and truck drivers; 

however, there were several crash types with large disparities. Crashes that involved backing or 

rear-end crashes while turning were much more often the fault of the truck driver, although these 

two categories accounted for only 7.9 percent of the overall crashes. The largest overall category 

in which truck drivers were most at fault was in sideswipe crashes, which account for 21.8 

percent. Although a detailed description was not given for this crash type, process of elimination 

would suggest that the authors are referring to intersection straight crossing-path collisions. 

2.1.3. Large Truck Crash Causation Study Emerging Results 

In recognizing that surveys of truck drivers and industry experts and crash statistics as currently 

gathered have flaws, perhaps the most definitive work on the topic of truck crashes is the 

LTCCS. The joint study between FMCSA and NHTSA was in progress during the time it was 

examined for inclusion in this OBMS study. An interim report on the project status (Blower and 

Campbell, 2002) laid out the methodology for the study. The study was seeking to build a 

national sample of over 1,000 fatal and serious injury crashes, with supplemental information 

gathered to allow the coding of a critical event, a critical reason for the critical event, and other 

crash-related factors. The critical event is defined as the action or event that put the vehicles on a 

collision course. The critical reason is defined as the immediate reason for the critical event. 

The distribution of critical events for two-vehicle crashes (between trucks or other vehicles and 

indexed by the critical event in two-vehicle crashes) is detailed in table 7, based on presentation 

of the LTCCS interim results (Craft and Blower, 2004). At the time this was examined in the 

OBMS development, the LTCCS had only examined 589 raw crash samples, and only 287 of 

those crashes were two-vehicle crashes between a car and a truck. The largest three categories of 

critical events (almost 80 percent of the crashes) included driving out of the lane, turning at or 

crossing intersections, and rear-end crashes. 

12 
Table 8. LTCCS Critical Events by Vehicle Exhibiting the Critical Event 

Critical Event 

(for Two-Vehicle Crashes) 

Truck 

(%) 

Other Vehicle 

(%) 

Total Crashes 

(%) 

Vehicle 1 1 1 

Roadway or environment 0 3 2 

Loss of control (driving too fast) 3 10 8 

Driving over the lane or off the road 

(including head-on and lane change) 

35 29 30 

Turning at or crossing an intersection 27 28 28 

Same lane (rear-end) 28 27 26 

Other 8 3 5 

Total 100 100 100 

Although the results in Table 8 somewhat resemble past studies detailing crash type by fault, the 

power of the LTCCS is in the fact that it goes beyond just crash type. As shown in Table 9, the 

critical reasons and distribution between trucks and other vehicles for the critical events are 

shown for the same two-vehicle crashes described in Table 8. The largest critical reason found 

for two-vehicle crashes was inattention, followed closely by poor decisions or misjudgment. 

These two factors alone account for over 80 percent of two-vehicle crashes attributed to truck 

drivers. 

Table 9. Critical Reasons for Two-Vehicle Crashes Involving Trucks 

Critical Reason 

Truck 

(%) 

Other Vehicle 

(%) 

Total 

(%) 

Vehicle (typically brake failure) 6 4 5 

Environment 0 6 4 

Driver nonperformance (sleep or sickness) 3 11 9 

Driver recognition (inattention or external 

distractions) 

46 34 38 

Driver decisions (misjudgments) 36 20 25 

Driver performance (poor control) 5 9 8 

Driver unknown errors 3 13 10 

Other/unknown 1 3 2 

Total 100 100 100 

Inattention or distraction was also found frequently as a related factor in the crash. Internal 

distractions were found to be related to almost 17 percent of the two-vehicle crashes, and 

external distractions were found to be related to almost 8 percent of the two-vehicle crashes. 

Poor surveillance, driving too fast, and making false assumptions were each found to be related 

to about 10 percent of the crashes, but following too closely was only a factor in 4 percent of the 

crashes. By far, the largest related factor was prescription or over-the-counter medications, 

which were a factor in almost 34 percent of the two-vehicle crashes. 

13 
The results described in the previous tables for the critical reasons of two-vehicle truck crashes 

hold fairly true when looking at all truck crashes. For all truck crashes, in 53 percent of the time, 

the critical reason was not associated with the truck or truck driver. Nearly 31 percent of the 

crashes could be attributed to truck driver inattention, distraction, misjudgments, or poor 

decisions. Only 4 percent of crashes could be attributed to sleep or sickness, and only 4 percent 

of crashes could be attributed to poor vehicle control. Finally, a full 5 percent of crashes could be 

attributed to vehicle failures (typically brakes), meaning that the top 5 critical reasons accounted 

for almost 97 percent of crashes. 

2.1.4. Large Truck Crash Causation Study 2006 Results 

Coinciding with the completion of this section, newer interim results for the LTCCS were 

released by the FMCSA (2006). The new results were based on 967 crashes, including 1,127 

large trucks and 959 other vehicles. A total of 251 fatalities and 1,408 injuries resulted from 

these crashes. Additionally, while the 2004 interim results focused on two-vehicle crashes, the 

2006 interim results expanded the study to include both single-vehicle and multiple-vehicle 

crashes (each comprising about 26.9 percent of the crashes). 

While the new results changed some of the categories and percentages, the conclusions did not 

change much between analyses. One notable difference is that the 2006 interim results report that 

for 54.6 percent of all crashes, the truck was coded with the critical reason for the crash. This is 

slightly higher than the 2004 results which found that the truck was coded with the critical reason 

for the crash only 47 percent of the time. The discrepancy is most likely due to the fact that the 

2006 results included single-vehicle crashes. 

The top four critical events found in the 2006 analysis are listed below and, combined, account 

for 92.7 percent of the crashes. Compared to the 2004 interim results, the only category of 

critical events that was added in the 2006 results was loss of control. Again, this category most 

likely arose from the fact that the 2006 analysis included single-vehicle crashes. 

5. Over the lane line or ran-off-the-road 

6. Loss of control (such as traveling too fast for conditions) 

7. Other vehicle in the travel lane (likely rear-end collisions) 

8. Turning at or crossing an intersection 

While the distribution of critical events remained relatively unchanged between analysis results, 

there were notable differences in the distribution of critical reasons (see Table 10, which gives 

percentage distribution by each of the two years in question). Truck driver recognition and 

decision errors still account for 66.4 percent of the crashes, but truck driver nonperformance 

(sleep, sickness, or medical reasons such as a heart attack or seizure), truck driver performance 

(poor control), and vehicle failures all were found to account for a larger share of the crashes 

than originally found in the 2004 interim results. 

14 
Table 10. Comparing Critical Reasons Between Studies 

Critical Reason (When Coded to the Truck) 2004 (%) 2006 (%) 

Driver nonperformance (sleep or sickness) 3 11.6 

Driver recognition (inattention or external distractions) 46 28.4 

Driver decisions (misjudgments) 36 38.0 

Driver performance (poor control) 5 9.2 

Vehicle (brake failure, tire, or cargo failure) 6 10.1 

Environment 0 2.3 

Total 96 100 

Finally, the 2006 LTCCS interim results provided a much more detailed analysis of related 

factors—those that were not the critical reason but were still associated with the crash (see 

highlights in Table 11, which provides the percentages of associated factors). 

Table 11. Related Factors Described in the 2006 LTCCS Interim Results 

Associated Factors (%) 

Driver Impairment 

Prescription drug use 26.3 

Over-the-counter drug use 17.3 

Fatigue 36.0 

Work-related pressure 9.2 

Illness 2.8 

Illegal drug use 2.3 

Alcohol use 0.8 

Driver Behaviors 

Traveling too fast for conditions 22.9 

Unfamiliar with roadway 21.6 

Inadequate surveillance 13.2 

Illegal maneuver 9.1 

Inattention 8.5 

External distraction 8.0 

Aggressive driving 6.6 

Following too closely 4.9 

Making false assumptions about other drivers 4.7 

15 
Associated Factors (%) 

Vehicle 

Brake failure or improper adjustment 29.4 

Cargo shift 4.0 

Cargo securement 3.0 

Similar to the conclusions of the 2004 analysis, fatigue, prescription drug use, and over-thecounter drug use (such as cold medications) were still the most prominent related factors. 

Interestingly, two new driver-related factors, traveling too fast for conditions and unfamiliarity 

with the roadway, were also found to be fairly prominent, while inattention and external 

distractions lost ground compared to the 2004 results. 

2.1.5. Summary and Relevancy 

This section contains a review of the recent literature on the topic of delineating causal factors 

for large truck crashes. The concept of an onboard driver monitoring system has been born from 

the behavior-based safety approach, which aims to identify “unsafe” behaviors, monitor those 

behaviors, and provide feedback to encourage good behavior and discourage the “unsafe” 

behavior. 

Based on the findings of the LTCCS, three general categories of critical events leading to crashes 

could be considered high priorities: (1) driving over the lane or off the road, (2) turning at or 

crossing an intersection, and (3) rear-end collisions. The most common reasons for the critical 

event were driver errors in recognitions (due to inattention or distraction) and errors in decisions 

(misjudgments). In support of this assertion, the industry experts, truck drivers, fleet managers, 

and safety experts, all agreed that inattention and distraction are major problems which need to 

be addressed. 

Industry experts, truck drivers, fleet managers, and safety experts also agreed that aggressive or 

risky truck driver behaviors, such as speeding or tailgating, were of great concern; however, 

contrary to popular belief, most studies agreed that fatigue, in the sense of falling asleep at the 

wheel, is a much lower priority and only a primary factor in approximately 3 percent of truck 

caused crashes. Vehicle failures, typically brake failures, were only responsible for 5 to 6 percent 

of crashes according to the LTCCS. 

Four studies were reviewed on the general topic of driver monitoring systems in the trucking 

industry. Each of the studies surveyed drivers, managers, or industry experts to gather their input 

on the concept of driver monitoring. All of the studies came to the same basic conclusion: 

although privacy and misuse of the data were of primary concern, there was general acceptance 

within the industry for the concept of driver monitoring. 

Not surprisingly, acceptance was also a function of perceived benefit. The more benefit the 

drivers saw in the individual system, the more positive they were toward accepting the overall 

concept of onboard monitoring. 

16 
In regard to the delineation of causal factors in large truck crashes, three types of studies were 

presented, those that interviewed industry experts, those reviewed crash statistics, and the 

LTCCS. Although, all of these sources had both advantages and disadvantages, the results of the 

LTCCS can probably be thought of as carrying the most weight, while the other studies can be 

thought of as providing confirming evidence. 

These results provide a sound basis and background for the first step of the behavior-based safety 

approach, identifying the “unsafe” behaviors, on which principles in driver monitoring feedback 

are built. 

REFERENCES (SECTION 2.0) 

Blower, Dand Campbell, K.L(2002) The Large Truck Crash Causation Study (UMTRI-2002-31) 

Ann Arbor, MI: The University of Michigan Transportation Research Institute. 

Council, F.M., Harkey, D.L., Nabors, D.T., Khattak, A.J., and Mohamedshah, Y.M(2003) 

Examination Of Fault, Unsafe Driving Acts, And Total Harm In Car-Truck Collisions 

Transportation Research Record 1830, 63-71 (See also Council, Harkey, Nabors, Khattak, 

and Mohamedshah, 2004). 

Council, F.M., Harkey, D.L., Nabors, D.T., Khattak, A.J., and Mohamedshah, Y.M(2004) An 

Examination of Fault, Unsafe Driving Acts, and Total Harm in Car-Truck Collisions 

(Publication NoFHWA-HRT-04-085) McLean, VA: Turner-Fairbank Highway Research 

Center. 

Craft, Rand Blower, D (2004) An Overview of the Large Truck Crash Causation Study A 

Presentation Given at The 3rd Annual Stakeholder’s Forum on November 30th in Phoenix, 

Arizona Washington, D.C.: The Federal Motor Carrier Safety Administration’s Office of 

Research and Technology. 

Federal Motor Carrier Safety Administration (2006) Report to Congress on the Large Truck 

Crash Causation Study Washington, D.C.: The Federal Motor Carrier Safety 

Administration’s Office of Research and Technology [Available Online at 

http://www.fmcsa.dot.gov/facts-research/research-technology/report/ltccs-2006.htm] 

Häkkänen, Hand Summala, H(2001) Fatal traffic accidents among trailer truck drivers and 

accident causes as viewed by other truck drivers Accident Analysis and Prevention 33, 187-

196. 

Hanowski, R.J., Wierwille, W.W., Gellatly, A.W., Knipling, R.R., and Carroll, R(1998) Safety 

Issues In Local/Short Haul Trucking: The Drivers’ Perspective Proceedings Of The Human 

Factors And Ergonomics Society 42nd Annual Meeting 1185-1189. 

Knipling, R., Hickman, J., and Bergoffen, G(2003) Commercial Truck and Bus Safety Synthesis 

Program: Synthesis 1 - Effective Commercial Truck and Bus Safety Management 

Techniques Washington D.C.: Transportation Research Board. 

Matteson, A., Blower, D., and Woodrooffe, J(2004) Trucks Involved in Fatal Accidents 

Factbook 2002 Ann Arbor, MI: The University of Michigan Transportation Research 

Institute (See also Shrank, Matteson, Pettis, and Blower 2004.) 

Roetting, M., Huang, Y., McDevitt, J.R., and Melton, D(2003)When Technology tells you how 

you drive—truck drivers’ attitudes towards feedback from technology Transportation 

Research Part F 6pp275-287. 

17 
Shrank, M., Matteson, A., Pettis, L., and Blower, D(2004) Trucks Involved in Fatal Accidents 

Codebook 2002 Ann Arbor, MI: The University of Michigan Transportation Research 

Institute. 

Sullman, M.J.M., Meadows, M.L., and Pajo, K.B(2002) Aberrant Driving Behaviours Amongst 

New Zealand Truck Drivers Transportation Research Part F 5, 217-232. 

2.2. DRIVER BEHAVIOR TASK ANALYSIS 

In section 2.1, preliminary results of the LTCCS were reviewed. Based on these findings (Craft 

and Blower, 2004), three general categories of critical events (summarized earlier in table 7.) 

could be considered high priorities: (1) driving over the lane or off the road, (2) turning at or 

crossing an intersection, and (3) rear-end collisions in which the truck crashes into the vehicle in 

front. The most common reasons for the critical event (summarized earlier in Table 8) were 

driver errors in recognitions (due to inattention or distraction) and errors in decisions 

(misjudgments). 

Building upon these results, the driving behavior task analysis presented in this report section 

focuses on transforming the critical incidents and critical reasons found in the LTCCS into 

failures in driving behavior or driver tasks. Using a reverse Failure Modes and Effects Analysis 

(FMEA), possible driving behaviors or tasks (the potential failures) which could lead to the 

crashes described in the crash causation literature (the effects) were brainstormed and discussed 

as the foundation for the set of driver behavior monitoring tasks. 

2.2.1. Method 

In systems engineering terms, the crash causation literature detailed above is akin to a Root 

Cause Analysis (RCA). It provides background on how frequently truck crashes happen and 

why. The challenge at hand is to organize, prioritize, and translate the crash causation research 

into a ConOps for an onboard driver monitoring system. Although there are an infinite number of 

ways this problem could be viewed, the primary goal of onboard driver monitoring is risk 

management, and one tool used widely in the systems engineering approach for risk management 

is FMEA. This tool is simply a formal process to proactively identify and correct potential 

product failures by examining each component, how that component might fail, and what effect 

that failure might have on the overall system. 

In this analysis each specific driver behavior or task was considered as a system component with 

the potential for failure. In this case, the driving behavior or task is the unknown. The most likely 

failure modes of crashes are rooted in two of the critical reasons detailed in the LTCCS, 

specifically failures in recognition (including distractions) and poor decisions. The effects and 

frequency of failures comes from the crash types or critical events also detailed in the LTCCS. 

Working backward through the FMEA method, driving behaviors and tasks which could 

potentially lead to crashes can be identified. These behaviors and tasks can then be suggested as 

prime candidates for onboard monitoring. 

18 
2.2.2. Failures Resulting in Driving Over the Lane or Off the Road 

The LTCCS suggested that nearly 35 percent of truck crashes resulted from driving out of the 

lane or off the road. Additionally, 3 percent of truck crashes resulted from losing control of the 

vehicle. Although it was the largest single category of critical events found in the LTCCS, the 

category itself combines several crash types. Crashes which result from a lane departure could 

include single vehicle run-off-the-road, head-on, or lane change and merging crashes. Table 12

breaks down each crash type of lane departure (crash scenario) and the two primary modes of 

failure (critical reason) into possible behavioral failures on the part of the truck driver. 

Table 12. Possible Behavioral Failures for Crashes Resulting From Lane Departure 

# 

Effect 

(Crash Scenario) 

Mode 

(Critical Reason) 

Failure 

(Possible Behavior Failures) 

1 Single vehicle runs 

off the road or twovehicle head-on 

collision 

Recognition Driver takes eyes off the road (distraction) 

Fatigue/falling asleep 

1 Single vehicle runs 

off the road or twovehicle head-on 

collision 

Decision Driving too fast for weather 

Overdriving headlights at night 

Curve overspeed 

2 Overtaking Recognition — 

2 Overtaking Decision Misjudging the speed of an oncoming vehicle 

Misjudging the amount of safe passing roadway 

available and the time it will take to complete the 

maneuver 

3 Lane change/merge Recognition Failure to check mirrors 

Failure to properly adjust mirrors 

3 Lane change/merge Decision Failure to use turn signals 

Of the potential behavioral failures, speed is fairly easy to measure. However, absolute speed 

alone is not the issue. The issue is speed relative to roadway conditions, which could be roadway 

design, such as in the case of curve overspeed or a combination of roadway design and weather 

conditions. Other driver decisions, such as misjudgments of oncoming vehicle speed and 

distance, are far more difficult to monitor as they would involve the need to know or measure the 

speeds and distances of the surrounding vehicles. 

Distraction and fatigue (or falling asleep) are also somewhat difficult to measure, but there are 

options and COTS devices available. The most direct measure for both distraction and sleep is 

monitoring eye scan behavior; however, there may also be the possibility of using surrogate 

measures such as lane-keeping performance. 

2.2.3. Failures Resulting From Turning at or Crossing an Intersection 

Another large category of critical events suggested by the LTCCS was crashes resulting from 

turning at or crossing an intersection; approximately 27 percent of the crashes were caused by 

19 
the truck or truck driver. Again, although this category comprises a large amount of crashes, 

there are numerous permutations of intersection crashes, including making a left turn across the 

path of an oncoming vehicle, straight crossing-path, left turn across the path of lateral traffic, and 

right turn into the path of lateral traffic. Furthermore, intersection crashes can be complicated by 

control method, uncontrolled, stop sign, or traffic signal. Table 13 details the possible driving 

behavior failures which may result in an intersection crash by, similar to Table 12, breaking 

down each crash type (scenario) and primary mode of failure (critical reason) into possible 

behavioral failures on the part of the truck driver by showing the effect or crash scenario by 

mode or critical reason and by failure and possible behaviors. 

Table 13. Possible Behavioral Failures for Intersection Crashes 

Effect 

(Crash Scenario) 

Mode 

(Critical Reason) 

Failure 

(Possible Behavior Failures) 

Intersection crashes Recognition  Driver takes eyes off the road 

 Driver does not see intersection control (stop 

sign or stoplight) 

 Driver does not check lateral traffic in both 

directions before crossing 

 Driver does not check or see oncoming traffic 

before turning

Intersection crashes Decisions  Driver misjudges oncoming vehicle speed or 

distance 

 Driver misjudges lateral vehicle speed or 

distance 

 Driver does not stop for intersection control (stop 

sign or stop light) 

 Driver does not properly yield to a vehicle with 

the right-of-way 

Intersection crashes often result from an extremely complicated set of causal factors. The main 

difficulty in monitoring intersection behavior is that many of the crashes result from 

misjudgments or poor decisions. In order to detect and monitor these decisions, one would need 

to know the speeds and positions of all the vehicles approaching the intersection. Although this 

may be possible one day with the advent of intelligent intersections, vehicle-to-infrastructure, 

and vehicle-to-vehicle communications, these technologies are still in the distant future; 

however, what may be possible in the present or near future is monitoring whether the driver 

intentionally or unintentionally disobeys traffic controls, such as stop signs or stop lights. 

2.2.4. Failures Resulting in Rear-End Collisions 

The third major category of critical events suggested by the LTCCS was same-lane crashes or 

rear-end collisions, which accounted for approximately 28 percent of the crashes caused by the 

truck or truck driver. Table 14 details the possible driving behavior failures that may result in a 

rear-end collision, where the truck strikes the vehicle in front. Unlike intersection crashes, many 

of these behaviors are prime candidates for monitoring both directly and indirectly with current 

sensor technology. 

20 
Table 14. Possible Behavioral Failures in Rear-End Crashes 

Effect 

(Crash Scenario) 

Mode 

(Critical Reason) 

Failure 

(Possible Behavior Failures) 

Rear-end collisions Recognition  Driver takes eyes off the road (distraction) 

 Fatigue/falling asleep 

 Failure to anticipate changes ahead in traffic 

(stopped traffic or turning vehicles) 

 Failure to predict and react to vehicle cut-ins 

Rear-end collisions Decision  Following too closely 

 Following too closely for weather 

 Speeding compared to traffic flow (aggressive 

driving) 

2.2.5. Other Behavior or Task Failures and Contributing Factors 

The issues of fatigue and drowsy driving (falling asleep while driving) are interesting. While 

they appear often as potential behavioral failures in the reverse FMEA analysis, the LTCCS 

found that only about 3 percent of crashes were primarily caused by drivers actually falling 

asleep at the wheel. Additionally, fatigue was only listed as a related factor 5 percent of the time. 

It should be noted that there is a distinction to be made when talking about fatigue and talking 

about drowsy driving or falling sleep at the wheel. Fatigue is a condition that occurs long before 

drowsy driving or actually fatigue can mimic distraction, which was also mentioned as a possible 

cause of many crash types, and the symptoms common to both include reduced scanning patterns 

and scanning frequency, slowed reactions, and making poor decisions. 

While monitoring whether or not the driver is actually falling asleep at the wheel is probably not 

the highest priority based on the crash causation studies, it has been reported as a major safety 

issue in the trucking industry, especially for long-haul drivers. An ideal onboard driver 

monitoring system may provide drowsy driver monitoring as an option to be used with long-haul 

drivers. Additionally, one driver monitoring countermeasure already mandated by State and 

Federal regulatory agencies is the logging of driver HOS. Since this logging is already required 

of drivers, any onboard monitoring system should automatically handle this task since any 

perceived system benefits, such as cutting down on paperwork, will help with overall system 

acceptance. 

Vehicle failures, typically brake failures, were responsible for 5 to 6 percent of crashes according 

to the LTCCS. Consideration might be given to monitoring driver behaviors that can lead to or 

cause vehicle failures, such as riding the brakes when descending prolonged steep hills. Finally, 

although not specifically the cause of crashes, safety belt usage is essential to death and injury 

reduction in a crash, and drivers not using seat belts have been reported as a concern of the 

trucking industry. For light-duty passenger vehicles (but not commercial vehicles), real-time 

feedback of safety belt usage to the driver already exists; however, a well-designed safety belt 

sensor (e.g., one that cannot be spoofed if the driver latches the belt and sits on it) coupled with 

real-time and delayed feedback would be a useful onboard monitoring system to enhance 

commercial vehicle safety. 

21 
References (Section 2.2) 

Craft, Rand Blower, D (2004) An Overview of the Large Truck Crash Causation Study A 

Presentation Given at The 3rd Annual Stakeholder’s Forum on November 30th in Phoenix, 

Arizona Washington, D.C.: The Federal Motor Carrier Safety Administration’s Office of 

Research and Technology. 

2.3. PRINCIPLES TO GUIDE DRIVER MONITORING FEEDBACK 

2.3.1. Overview 

The end goal of onboard driver monitoring is to be able to provide the driver with feedback that 

will have a positive influence by promoting safe behaviors and discouraging unsafe behaviors. 

As part of the Roetting, et al., 2003) study, truck drivers were surveyed on questions of how they 

would like to receive feedback from an onboard driver monitoring system Unsurprisingly, they 

found little consensus over how feedback on driving performance should be given. Their results 

showed that when asked the generic question of how to provide feedback, 47 percent opted for 

via a dashboard device, 37 percent opted for postdriving feedback, and 30 percent opted for 

some sort of voice-auditory system. When postdriving feedback was suggested as an option, 

drivers generally selected a time summary interval between once a week and once a month, as 

opposed to longer or shorter time intervals. One thing with which the drivers did agree was that 

any technology providing feedback should not interfere with the driving task and should not be a 

distraction. Clearly, there is a delicate balance between life-saving, real-time feedback and 

distracting feedback. 

2.3.2. Constituent Tasks of Driving 

Over the years starting as early as Gibson and Crooks (1938), there have been a number of 

approaches used to try to break down the skill of driving into its various component tasks. While 

this task breakdown may vary from study to study in both nature and complexity, the one thing 

most all agreed upon is the fact that driving is mostly a visual task guided by perception. Drivers 

must perceive the road, the vehicles around them, any threats to their intended path, and so forth. 

Drivers must also make decisions like “Should I pass?” or “Is there enough gap to turn in front of 

this vehicle?” Finally, drivers must use the vehicle controls, throttle, steering, brakes, and gears 

to control the vehicle maintaining its desired path. Errors can occur in all stages of processing 

which could lead to “unsafe” conditions or even crashes. 

For the drivers of large trucks, all of these tasks still apply. The major differences between truck 

drivers and car drivers lie in the maneuvering characteristics of the vehicle. Since trucks are far 

less maneuverable, they are less forgiving and tolerant of errors in perception, decision making, 

or vehicle control, requiring drivers to be even more attentive and vigilant. Other differences 

include generally longer driving hours, and additional reporting requirements (such as 

documenting and reporting HOS). 

Unfortunately, the component tasks of driving are too often situation dependent to provide any 

overall guidance on the issue of driver feedback. 

22 
2.3.3. What is the Role of Driver Monitoring Feedback? 

Given that driving is composed of many widely varying tasks, the answer to the question of how 

to provide driver feedback likely varies depending on what specific feedback being provided. In 

order to start deciding which feedback should be given in which way, the role of how the 

onboard driver monitoring feedback fits into the overall scheme of driver assistance must be 

established .Figure 5 was first published in a report by NHTSA (1992) as a means of describing 

the relationship between urgency (x-axis) and the intensity of intervention required (y-axis). 

Since the first appearance of this graph, two categories have been added by researchers at 

California PATH: situational awareness and onboard monitoring feedback. 

Figure 5 shows the continuum of warning as functions of time running out versus intensity of 

action—normal driving, onboard monitoring feedback, situational awareness, driver warning 

systems, partial automatic control, full automatic control, and unavoidable crash. A warning 

system, in the classical sense, provides the driver with information that a specific, urgent threat 

exists and immediate action must be taken to avoid that threat Onboard monitoring is such a 

system—and it additionally provides real-time feedback. The most prominent examples in the 

automotive realm are forward- and side-collision warning systems. Designing a warning system 

that will be accepted by drivers typically considers issues such as reaction time and false alarms. 

Figure 5. Onboard Monitoring Feedback in the 

Scheme of Driver Assistance Systems. 

Source: Figure adapted from National Highway Traffic Safety Administration, 1992. 

Situational awareness systems are generally one step removed in urgency with the intention of 

providing the driver with supplemental information, upon which better informed decisions can 

be made. The best example of a situational awareness system is a side-object detection system. 

23 
When an object in the driver’s blind spot is detected, the information is transferred or fed back to 

the driver. The difference between situational awareness and warning is that an immediate threat 

does not need to be present. In designing a situational awareness system, timing issues are 

generally considered, but timing and false alarms are much less critical. 

The elements of OBMS would fit at various points in this continuum, providing onboard 

monitoring feedback and situational awareness, depending on the time urgency of the threat 

posed to the driver. Behavior monitoring feedback attempts to convey in real-time when the 

driver is engaging in what might be considered an unsafe behavior. A prime example is the 

feedback provided by most vehicles on driver seat belt usage. This feedback is not a collisionimminent warning, as there is no immediate threat, but it does indicate that the behavior of not 

wearing a seat belt is dangerous. In the design of behavioral feedback, the issue of timing in 

relationship to a crash is not critical. False alarms are also less critical, unless the feedback is 

overly distracting. 

2.3.5. When Should Feedback Be Given: Immediate or Delayed? 

Perhaps the first and largest question regarding onboard driver monitoring feedback is the 

question of whether the feedback should be immediate (real-time and somehow provided in the 

vehicle) or can be delayed (allowing postprocessing). The general guiding principle on this issue 

comes down to whether or not the unsafe behavior is persistent and correctable. Nonuse of the 

seat belt is persistent and correctable by the driver, and thus, immediate feedback is a good 

option. Following too closely is also a good candidate for immediate feedback, as it is a 

persistent state correctable by the driver. 

Other monitoring parameters do not lend themselves well to immediate feedback. For example, 

if a driver had just performed a hard braking because he was distracted and did not see the car in 

front of him start braking, the condition was not persistent or correctable. The event would be 

over, and providing the driver with immediate feedback that he just performed a hard braking 

event would be pointless. In this particular example, feedback would better serve the driver by 

summarizing how many hard-braking events he found himself in during the past week or month. 

In a case where a single event does not necessarily indicate a problem, but frequent events may 

be indicative of a larger correctable problem, then delayed feedback would be more appropriate 

(as would be providing real-time feedback if, for example, the frequency of these events within a 

short time period, is excessive). 

2.3.6. Should Feedback Be Framed as Positive or Negative? 

Another issue which needs to be considered is whether the feedback provided should be positive 

or negative. In the case of immediate or in-vehicle feedback, positive feedback would generally 

be avoided. As a general vehicle design principle, in-vehicle displays are not added unless 

necessary because of fear of introducing a distraction. Thus, for the case of following too closely, 

the preferred feedback method would only provide a warning when the driver was following too 

closely for an extended period of time; however, when giving delayed feedback, several of the 

studies mentioned earlier reported that drivers wanted to hear the positive about their driving, not 

just the negative. 

24 
2.3.7. Feedback Modality 

The final topic of onboard driver monitoring feedback is how to provide immediate in-vehicle 

feedback, specifically, through which modality: auditory, visual or both. As discussed earlier, 

driving is an extremely visual task. The driver is constantly scanning the road, the instruments, 

and the traffic around the vehicle. Thus, the use of visual displays, such as for driver monitoring 

feedback does not guarantee that the driver will see or notice the information immediately, and 

any time spent looking at the information will take from time that might be better spent scanning 

the roadway for hazards. Still, most in-vehicle warning or situational awareness systems use 

some visual component. If the information is noncritical, then using a visual display alone can be 

completely acceptable, as drivers can easily ignore the warning when their attention is occupied 

elsewhere and attend to the warning once their workload has subsided. It is also well-known in 

the automotive industry that drivers tend to prefer static warning, as dynamic or flashing 

warnings tend to be less easily ignored and more often are considered annoying. 

Typically, auditory feedback is used in situations where an immediate response is needed, and 

the driver’s attention may or may not be focused on the feedback device (or the road for that 

matter). The problem with auditory feedback is that it quickly becomes annoying and even 

distracting when overused or used in the wrong situation because drivers have no means to avoid 

it. Thus, it would not be recommended to follow the advice of the 30 percent of drivers who 

responded that they would prefer feedback through some auditory-voice type system as reported 

by Roetting, et al. (2003). 

Finally, there are cases and times where auditory warnings and flashing visual warnings have 

been used for noncritical situations (e.g., the seat belt monitoring system). In the case of the seat 

belt monitoring system, the annoyance and distraction factor of the auditory warning and the 

flashing visual warning was intentional, with the hope that it would persuade drivers to comply 

at the start of their trip. Of course, the disadvantage of this strategy is that too much distraction 

and annoyance can cause the driver to attempt to disable the system entirely. 

References (Section 2.3) 

Gibson, Jand Crooks, L(1938) A Theoretical Field-Analysis of Automobile Driving The 

American Journal of Psychology, 51(3), 453-471. 

National Highway Traffic Safety Administration(1992) NHTSA IVHS Plan (Report NoDOTHS-807-850) Washington DC: NHTSA Office of Crash Avoidance Research. 

Roetting, M., Huang, Y., McDevitt, J.R., and Melton, D(2003)When Technology tells you how 

you drive—truck drivers’ attitudes towards feedback from technology Transportation 

Research Part F, 6, 275-287. 

2.4. ONBOARD MONITORING REVIEW 

2.4.1. Driver Monitoring in the Context of the Behavior-based Safety Approach 

The concept of operator (driver) monitoring is neither new nor limited specifically to the 

trucking industry. Sherry (2001) identified and compared operator monitoring systems used in 

25 
the maritime, air freight, motor carrier, and rail industries. A more recent paper (Lotan and 

Toledo, 2005) discussed a pilot program in Israel which would provide driver monitoring and 

feedback for teen drivers. 

The general case for truck driver monitoring in the trucking industry has already been made 

through research sponsored by the FMCSA and is best summarized in a technical brief 

(Behavioral Science and Technology, 2000). In its most simplistic form, the behavior-based 

safety approach is a method for improving safety, by which behaviors critical to safety are 

identified and monitored vis-à-vis mutual goals, rewards, expectations and punishments. Safe 

behavior is rewarded and unsafe behavior is discouraged and improved upon, thereby proactively 

improving overall safety. 

2.4.2. Driver Monitoring Research Review 

There is much literature devoted to the many issues surrounding truck and truck driving safety, 

all of which can be both relevant and tangential to the concept of onboard driver monitoring, and 

much of that literature is discussed throughout the various sections of this report; however, there 

have only been about four major published studies which have specifically focused on the 

acceptance of onboard driver monitoring systems in the trucking industry. In the first study, 

Sherry (2001) interviewed both management and operators in the maritime, air freight, motor 

carrier, and rail industries. At the time, many of the onboard monitoring COTS devices reviewed 

later in this report were in existence and in use by the companies he interviewed; however, 

management acceptance of onboard monitoring was mostly concentrated around the issues of 

reducing engine idle time and fuel consumption or accident/event recording Most management 

incentives based on the monitoring and feedback devices were given for reducing engine idle 

time. 

From the driver interviews conducted in this first study, it was reported that 42 percent of the 

drivers would have no problems with a driver monitoring system, but almost 58 percent felt that 

the in-vehicle monitoring systems had been used to unfairly discipline drivers. Drivers were 

more accepting of systems that included some sort of collision avoidance system or provided 

additional tangible benefits, such as reducing paperwork and logging requirements. It was also 

reported that drivers perceived as “good” drivers were more positive and accepting towards the 

monitoring systems than were drivers that were considered more problematic. Summarizing from 

interviews across industries, Sherry (2001) concluded that several factors (outlined in 

26 
Table 15 in two columns, positive influences on acceptance and negative influences on 

acceptance) were frequently cited in support of or against operator monitoring systems. 

27 
Table 15. Factors Influencing Onboard Monitoring Acceptance 

Positive Influences 

on Acceptance 

Negative Influences 

on Acceptance 

Improved safety (if the technology lives up to its 

promise) 

Fear of embarrassment or self-consciousness at 

being monitored all the time 

Liability protection (such as when the driver is not 

at fault for a crash) 

Fear of liability or unfair accountability on the part 

of drivers, such as being determined as 

responsible for a crash 

Efficiency (such as reducing paperwork) Concern that the monitoring parameters are not 

indicators of safety 

Monetary incentives Misuse of the collected data 

In the second reviewed study, Knipling, Hickman, and Bergoffen (2003) found support for driver 

monitoring among nearly 33 percent of trucking industry safety managers. In their survey, 36 

percent of the respondents reported using some form of driver monitoring system with 

management review and feedback, and 33 percent of the respondents ranked driver monitoring 

and feedback as one of their “top five” choices for solutions to help improve safety. 

Interestingly, when given the option of driver monitoring without management review (thus 

ensuring driver privacy), only 9 percent of the safety managers ranked this option in their top 

five and the option fell overall to last place (out of 28 solutions). Most industry experts and 

carrier safety managers seemed to agree that driver monitoring without management review 

would be ineffective. 

The final two studies, Roetting, et al. (2003 and 2005), extensively examined the topic of truck 

driver monitoring and feedback from the driver’s perspective. In the 2003 study, a total of 66 

long- and short-haul drivers, supervisors/managers, and insurance industry safety professionals 

participated in nine focus groups. These focus groups reported similar opinions as those 

described above. Drivers generally felt that monitoring could have potential safety benefits and 

possibly vindicate the driver in the even of an incident or crash; however, privacy concerns and 

mistrust over the use of data were also voiced. Drivers were also concerned that feedback would 

be primarily negative and lead to programs focused on punishments, as opposed to incentives 

which reward good driving behavior. 

The 2005 study surveyed 239 long- and short- haul drivers throughout 40 States and Canada. 

Drivers were generally positive towards the concept of feedback, with less than half of the 

drivers surveyed (42 percent) responding that they were currently getting adequate feedback on 

their driving. Similar to the earlier focus groups, more than half the of the drivers (59 percent) 

felt that positive feedback would be more useful than negative feedback, and 56 percent felt that 

the greatest potential benefit of in-vehicle monitoring was defending the driver in the event of a 

crash. Unsurprisingly, the greatest concern found in the survey was over the issue of privacy. 

Over two-thirds or 65 percent of the survey respondents were concerned with the possibility that 

the data collected by the onboard monitoring system might be misused. 

All of the studies outlined above basically came to the same conclusions. Truck drivers were not 

universally opposed to the concept of onboard monitoring and feedback, and the issues 

surrounding privacy and misuse of the data being collected were of primary concern. The studies 

28 
all also tended to reveal that acceptance was a function of perceived benefit. The more benefit 

the drivers saw in the individual system, the more positive they were towards accepting the 

overall concept of onboard monitoring. 

2.4.3. Onboard Monitoring COTS Review 

Overview 

A search for COTS onboard truck driver monitoring systems turned up six major manufacturers: 

XATA, Delphi, Accident Prevention Plus, Cadec, QualCOMM, and DriveCam. These 

companies have been releasing onboard monitoring (OBM) products since as early as 2000. Two 

relative newcomers to the field of driver monitoring are AllTrackUSA and Drive Diagnostics. 

AllTrackUSA makes a variety of products marketed towards teen drivers and fleet management, 

and DriveDiagnostics is an Israeli start-up with plans to make both a teen driver monitor and a 

fleet version. 

Figure 6. Typical OBM System1

The features promoted in most OBM products include real-time location tracking, delivery 

status, fuel performance, and driver logs. In general; these systems emphasize savings on fleet 

 

1 This figure and the information on the Accident Prevention Plus AP+ series products were 

from the NHTSA website at the following URL: http://www-nrd.nhtsa.dot.gov/edrsite/uploads/accident_prevention_plus.pdf 

29 
operations and maintenance costs. An overview of a typical onboard driver monitoring system is 

shown in Figure 6. The OBM system generally consists of three major components: sensors, a 

processing unit, and feedback devices. The most commonly used sensors include the 

speedometer, tachometer, odometer, throttle angle encoder, GPS receiver, accelerometer, and 

steering encoder. 

By employing these sensors, the COTS systems measure the driver performance by monitoring 

signal use, position, speed, acceleration, and vehicle mechanical states (e.g., engine rpm, throttle 

angle, brake pressure, and so on). All these systems can be installed in a vehicle easily. Most of 

them also provide advanced driver identification system to avoid unauthorized use of the vehicle, 

but there are some basic feature differences between systems as illustrated in table 15 (systems 

are: XATA, Delphi, APPlus, Cadec, QualCOMM, DriveCam, AlltrackUSA, and 

DriveDiagnostics). Features are: preventative maintenance monitoring, event recording using 

camcorder, remote deceleration and shutdown, real-time asset tracking, GPS-based 

“geofencing,” driver identification, trailer door security, and wireless communication. 

Feedback can be provided to the driver either in real-time or after the data has been downloaded 

and analyzed. Real-time feedback is typically provided to the drivers through displays or 

speakers. 

30 
Table 17 compares the feedback methods employed across systems (systems are the same as 

with Table 16, but the methods are: text messaging, audible or visible warnings and offline 

feedback). 

Table 16. Basic Feature Comparison Among OBMS Products—by Company 

Company Preventative 

Maintenance 

Monitoring 

Event 

Recording 

Using 

Camcorder 

Remote 

Deceleration 

& Shutdown 

Real-Time 

Asset 

Tracking 

GPSbased 

“Geofencing” 

Driver ID 

Trailer 

Door 

Security 

Wireless 

XATA × × × 

Delphi × × × × × × 

APPlus × 

Cadec × × × 

QualCOMM × × 

DriveCam × × 

AllTrackUSA2 × × × 

DriveDiagnostics × × × × 

 

2 AllTrack USA makes a variety of products. Not all products include all of the features noted 

here. 

31 
Table 17. Comparison of Approaches Taken To Provide Feedback to Drivers—by Company 

Company Text Messaging 

System 

Audible and/or 

Visual Warnings 

Offline 

Processing 

XATA × × 

Delphi × × 

APPlus × 

Cadec × × 

QualCOMM × × 

DriveCam × 

AllTrackUSA2 × × 

DriveDiagnostics × 

XATA 

XATA (http://www.xata.com/) is a company that has been around since 1985 and got their start 

in the electronic driver log business. Their current OBM product is called XATANET, and it is 

advertised primarily as a fleet management and fleet intelligence system, with benefits such as 

real-time tracking, optimizing fleet utilization, and addressing safety and security concerns. The 

functions provided by this system as described on the XATA website include the following: 

• Increased driver productivity 

– Delivery status, routes, and schedules 

– Analysis of speed, idling, braking, RPM, MPG, and more 

– Two-way driver messaging 

• Increased fuel economy (through analysis of idle time and driving habits) 

• Compliance with electronic DOT logs and reporting requirements 

• Improved safety and security 

– Real-time asset tracking 

– Monitoring speed and rapid stops 

– Accident reconstruction 

• Improved fleet maintenance (monitoring engine diagnostics) 

The XATA systems incorporates GPS, speedometer, tachometer, odometer, fuel rate sensor, 

throttle position, braking (on/off only), clutch (on/off only). The two-way messaging system 

allows the vehicle to send remote telemetry back to the fleet managers and the fleet managers to 

communicate with the drivers. 

Delphi’s TruckSecure 

Delphi’s TruckSecure system is a service offered in partnership with MobileAria 

(http://www.mobilearia.com/prodserv/trucksecure.shtml). The system is a fleet management tool 

that is advertised as a means to reduce the possibility of cargo trucks being used to threaten 

homeland security. The functions provided by this system include: 

32 
• Driver authentication (ID and PIN) to prevent unauthorized use 

• Increased security with wireless key fob and panic button 

• GPS-based, real-time asset tracking and “geo-fencing” 

• System tied to a call center that monitors vehicle telemetry and notifies fleet managers of 

alerts 

• Remote vehicle disablement capable of gradually decelerating the vehicle to a stop and 

disabling the engine 

The installed sensors include GPS, speedometer and odometer monitors, and cellular and satellite 

communications. This system includes a small display in which the driver can receive text 

messages. 

Accident Prevention Plus 

The main goal of the APP system was to provide security for unauthorized use of vehicles and to 

monitor vehicle operational data for accident prevention. Unfortunately, at the time of this report, 

no current information could be found on this company or its product, and it is likely that the 

company and and its product has been discontinued. According to archived documents, the 

system was advertised as an aid in driver training, driver evaluation, and maintenance purposes. 

More specifically, the system was supposed to: 

• Prevent unauthorized use of a vehicle 

• Monitor vehicle operational data 

• Record 50 seconds of data before and 10 seconds of data after an accident 

The operational data that was supposed to be collected included driving chronologies, idling 

chronologies, 20 most recent speed violations, maximum speed, maximum 

acceleration/deceleration, speed histograms, engine speed histograms, brake intensity 

histograms, brake occurrence, speed ranges, and gear position histograms. The system also was 

supposed to record distance driven, maximum speed, and the number of driving periods above a 

selected duration. The employed sensor suite includes speedometer, accelerometer, tachometer, 

fuel rate sensor, gear position sensor, braking (on/off), and lights (on/off). The system was not 

supposed to include any interface to interact with the driver. It was supposed to function mostly 

as a “black box,” recording data for offline analysis 

Cadec 

Cadec Corporation (http://www.cadec.com/) has been around since 1976 and got their start in 

electronic DOT logging capabilities. The company currently offers the Cadec Mobius TTS 

“mobile information system.” The system integrates onboard computers, handheld devices, and 

wireless communications to provide a paperless tracking and delivery system; however, the 

system also has additional features concerning safety, security, and DOT logging compliance. 

This system includes the following features: 

• Delivery status, route information, and schedules 

– Real-time asset and route tracking 

• Instant event notification 

33 
– Trailer door security 

– Trailer temperature tracking 

– Border crossing notification 

• Detailed driver and vehicle information 

• Electronic logging compliance 

The installed sensors include the speedometer, odometer, GPS, and tachometer. A touch screen 

display is used to communicate with the driver; however, text messages can only be displayed if 

the vehicle is not in motion. Although the advertisements suggest that detailed driver and vehicle 

information is collected by the system, a detailed description of how that information is collected 

was not found. 

QualCOMM 

QualCOMM (http://www.qualcomm.com/qwbs/solutions/prodserv/sentracs.shtml) makes a 

series of products, including the SensorTRACS and TrailerTRACS, for the purpose of real-time 

asset tracking and fleet maintenance monitoring. 

The SensorTRACS system monitors speed, RPM, and engine idle summaries and sends that data 

through wireless communications in near real-time back to the fleet management. This can: (1) 

increase fuel savings by reducing over-idle, over-revving, and excessive speed and (2) reduce 

engine wear and hard braking. 

The TrailerTRACS system provides real-time asset location tracking system, and other add-on 

modules include electronic documentation of HOS, proactive vehicle maintenance, and panic 

buttons for security. The employed sensors include speedometer, odometer, throttle-position 

sensor, and tachometer. In-vehicle text messaging and communications systems are also 

available as add-ons. 

DriveCam 

The main purpose of the DriveCam system (http://www.drivecam.com/) is safety and driver 

training. The system integrates video technology and management software to identify high-risk 

driving habits. It records large g-force events such as hard braking, fast lane changes, and 

collisions. Their system can record 10 seconds of audio and video both before and after a large gforce event or accident. The g-force threshold is adjustable and can be adapted to different 

vehicles. The employed sensors include accelerometers and cameras, which are used to record 

events and accidents. The DriveCam system focuses entirely on recording video of what’s going 

on inside and outside the vehicle, as opposed to recording any engine-based performance 

measures. The only feedback provided by the system is real-time feedback in the form of a light 

which lets the driver know that an incident has occurred and triggered the cameras to save their 

recorded data. 

AllTrackUSA 

AllTrackUSA (.com) makes a variety of products for both passive driver monitoring and for realtime fleet asset tracking through the use of GPS and cellular phone technology. The black box 

34 
device monitors aggressive driving using an accelerometer and a connection to the vehicle’s 

CAN bus to read parameters, such as engine speed and accelerator position. Some of the systems 

are outfitted with cellular communications for real-time asset tracking and real-time event 

notification (excess speed or electronic geo-fencing). For security, the some of the systems also 

offer remote door unlock and remote starter enable/disable features. 

Most of the systems operate in a black box capacity where data can be downloaded to generate 

offline driver reports. One of the devices, the Audio Monitor, provides driver feedback in realtime in the form of a loud beep whenever aggressive driving (high-g maneuvers) are made. 

DriveDiagnostics 

DriveDiagnostics, Ltd., is an Israeli start-up that intends to make products for monitoring both 

teen drivers and fleet vehicles. Very little information is freely available on any of their 

upcoming products. Based on the web descriptions of their future products, they will likely 

contain, at a minimum, GPS and accelerometers. Feedback will likely be given in the form of 

reports generated offline after downloading the data. 

2.4.4. COTS Summary and Conclusions 

The COTS systems built specifically for the trucking industry generally focus on fleet 

maintenance, asset tracking, and on saving operations costs, but many have features related to 

driver monitoring and safety. Generally, as a result, these systems monitor driver behaviors from 

the perspective of the vehicle’s mechanical conditions and motions. 

The systems specifically focused on safety rely almost entirely on high-g incidents as the 

primary measure of driver safety. While high-g incidents might be one measure of “unsafe” 

driving, they most certainly aren’t the only measure. It is clear that none of these individual 

products are comprehensive from the standpoint of monitoring safety-related driver behavior. 

References (Section 2.4) 

Behavioral Science and Technology, Inc.(2000) The Potential Application of Behavior-Based 

Safety in the Trucking Industry (Publication NoFMCSA-MCRT-00-009) Washington DC: 

Federal Motor Carrier Safety Administration. 

Knipling, R(2005) Evidence and Dimensions of Commercial Driver Differential Crash Risk 

Proceedings of the Third International Driving Symposium on Human Factors in Driving 

Assessment, Training, and Vehicle Designpp2-8. 

Lotan, Tand Toledo, T(2005) Evaluating the Safety Implications and Benefits of an In-Vehicle 

Data Recorder to Young Drivers Proceedings of the Third International Driving Symposium 

on Human Factors in Driving Assessment, Training, and Vehicle Designpp448-455. 

Roetting, M., Huang, Y., McDevitt, J.R., and Melton, D(2003)When Technology tells you how 

you drive—truck drivers’ attitudes towards feedback from technology Transportation 

Research Part F 6pp275-287. 

Roetting, M., Huang, Y., McDevitt, J.R., Melton, D., Smith, G.S(2005)Feedback by technology: 

Attitudes and opinions of truck drivers Transportation Research Part F 8pp277-297. 

35 
Sherry, P(2001) In-Vehicle Monitoring Technologies: Review of Current Use and Potential 

Enhancement Through Behaviorally Based Safety Processes (Report Submitted to the 

American Trucking Association Foundation) Denver, CO: The University of Denver. 

2.5. PROPOSED DRIVER MONITORING TASKS AND METHODS 

In this section, the monitored parameters and the type of feedback monitoring categories or 

behaviors listed below are examined: 

• Speed Selection: Is speed too fast for the roadway, traffic or weather conditions? Is speed 

in excess of posted speed limit? 

• Following Behavior: Are car- or truck-following time gaps too close for roadway or 

weather conditions? 

• Attention (or Inattention): Are the driver’s eyes on the road? (This is difficult to measure, 

so surrogate measures such as lane-keeping performance may be the default method of 

detection.) 

• Fatigue Is the driver tired? (Again, surrogate measures as lane-keeping performance may 

be the default method of detection.) Are HOS rules being maintained? 

• General Safety Are seat belts being used? What is the engine RPM? Is there undo 

acceleration? What is the fuel consumption rate? 

These were synthesized and categorized from the results of the review and analysis of the 

literature described earlier. This list is shorter than other taxonomies because within each topic, 

there can be multiple and sometimes redundant parameters, which would be identified as 

candidates for monitoring. 

This list can be expanded into 11 topics: 

1. Monitoring Vehicle Speed 

2. Monitoring Following Distance 

3. Monitoring Attention 

4. Monitoring Hard-Braking Incidents 

5. Monitoring Lane Position 

6. Monitoring Lane Changes 

7. Monitoring and Recording Incidents 

8. Monitoring Fatigue 

9. Monitoring HOS 

10. Monitoring Behaviors at Intersections 

11. Monitoring Other Vehicle Parameters 

36 
Some of these candidates, such monitoring behaviors at intersections, are likely beyond the 

capabilities of current technology. Others, such as monitoring curve overspeed or fatigue, may 

ultimately prove too costly. 

Each topic is presented as a self-contained summary featuring of the following format: 

• Introduction 

• Candidate Driver Behaviors for Onboard Monitoring 

• Driver Feedback Recommendations 

• Additional Discussion 

• Cross-References 

Note that each topic starts with an introduction which references why the topic is important. 

After the introduction, the next subsection lists which driver behaviors or tasks are related to that 

topic and might be candidates for onboard monitoring. A subsection on driver feedback 

recommendations discusses the various options on how driver feedback might be provided, lists 

the pros and cons when multiple design options are available, and, where appropriate, discusses 

the interfaces of specific COTS subsystems that have been referenced on the topic. 

The additional discussion subsection describes and references some of the key literature on the 

topic. Although, performance measure options and COTS devices have been listed when 

available, the discussion and recommendations have been kept at a high level, as the purpose of 

this section is to provide an unconstrained exhibit of potential system features. 

The subsection entitled Cross-References merely points the reader to other topics which might be 

related or utilize similar performance measures. As an example, lane position might relate to 

both distraction and fatigue. 

2.5.1. Monitoring Vehicle Speed 

Introduction 

From section 2.2, there are several ways that speed could be driver behavior failure with a lane 

departure and rear-end crashes. Speeding, under the banner of aggressive driving, was also listed 

as one of the top concerns among industry experts (Knipling, Hickman, and Bergoffen, 2003) 

and by long-and short- haul truck drivers by (Roetting, et al., 2005). 

Candidate Driver Behaviors for Onboard Monitoring 

Candidate driver behaviors for onboard monitoring are listed below: 

• Vehicle speed relative to roadway speed limit 

• Vehicle speed relative to safe curve speed 

• Vehicle speed relative to roadway (weather) conditions 

• Vehicle speed relative to night visibility (headlight sight distance) 

• Vehicle speed relative to traffic flow 

37 
Driver Feedback Recommendations 

The recommended driver feedback designs are listed as follows: 

• Delayed or offline feedback with summary statistics 

• Real-time feedback in the form of a series of speed warning or status lights 

• Engine speed limiters 

Three driver feedback options have been presented both in orders of complexity and in order of 

the aggressiveness of the intervention. A vehicle speed monitoring system could be effectively 

built around any or all of these driver feedback schemes. Realistically, the driver already receives 

feedback about vehicle speed from the speedometer and feedback about the speed limit and 

recommended curve speeds from signs on the roadside. For these reasons, offline or delayed 

feedback could be justified. 

As long as the information is available, an argument could also be made to provide the driver 

with some indication or comparison of current and recommended speed, so long as it is presented 

in a way that does not distract the driver. While perhaps the best system utilizing this method of 

feedback might include concepts such as a reconfigurable speedometer, simpler implementations 

could include a series of speed warning or status lights which illuminate when the recommended 

speed has been exceeded. At least in the case of curve overspeed, system design consideration 

must be given to the overall goal of safety. If the information is available to monitor curve speed 

compliance, should it also be coupled with a curve overspeed warning system to aid the driver? 

Conceivably, the strictest and most aggressive form of driver speed monitoring and feedback 

would be to electronically disallow the vehicle from traveling above the recommended speed. 

While systems exist currently to simply limit the overall top speed of a vehicle, there are many 

more human factors issues with the implementation of a dynamic speed limiting system. 

Although this feedback method may eventually be an option, it would likely be coupled with 

visual indicators, and the number of implementation questions, for which there is currently little 

or no research available, would make this option challenging. 

One alternative that has not been recommended based on the current research is the use of force 

feedback on the accelerator pedal to influence driver speed selection. While Várhelyi, et al. 

(2004) have reported some success in Sweden using accelerator pedal feedback for speed limit 

compliance, other studies currently being conducted on the topic of curve overspeed have 

preliminarily reported limited effectiveness and sometimes even adverse effects when using 

accelerator pedal feedback. More conclusive research on this topic will likely be released in the 

next few years and should be carefully reviewed before recommending accelerator pedal 

feedback as an option. 

Additional Discussion 

In 1998 the TRB published Special Report 254 (1998), a review of current knowledge and 

literature on the topic of speed and safety. This report, along with a more recent paper from the 

Netherlands (Aarts and van Shagen, 2006), summarized that there is evidence, though not 

conclusive, that both increasing speed and increasing speed disparity can be associated with 

crash involvement and crash severity for certain crash types. As an example, increased speed can 

38 
be associated with increases in single vehicle or ran-off-the-road types of crashes. At higher 

speeds, deviations from the average traffic speed have been shown to increase crash probability. 

In all cases, crash and injury severity rises sharply with increased speed, which simply reflects 

the laws of physics which state the energy of an impact will be proportional to the square of the 

speed. 

Cross References 

See Section 2.5.2: Following Distance. Monitoring vehicle speed relative to traffic flow is related 

to rear-end collisions and may also be related to following distance. 

2.5.2. Monitoring Following Distance 

Introduction 

The LTCCS found that rear-end collisions accounted for approximately 28 percent of the crashes 

caused by truck drivers. Table 13 lists following too closely as a potential driving behavior 

failure which could contribute to a rear-end crash. Following too closely was also listed under 

the banner of aggressive driving that was one of the top concerns among industry experts 

(Knipling, Hickman, and Bergoffen, 2003) and by long-and short-haul truck drivers by 

(Roetting, et al., 2005). 

Candidate Driver Behaviors for Onboard Monitoring 

Candidate driver behaviors for onboard monitoring are listed as follows: 

• Following too closely for travel speed and trailer loading 

• Following too closely for weather conditions 

Driver Feedback Recommendations 

Recommended driver feedback designs are listed as follows: 

• Delayed or offline feedback with summary statistics 

• Real-time feedback in the form of a warning/status light 

• FCWS 

Effective feedback for following distance could be provided in the form of delayed summary 

feedback, a real-time following too closely warning/status light, or a fully functional FCWS. 

Real-time feedback on this parameter is highly recommended as Shinar and Schechtman (2001) 

have effectively shown that providing real-time following-distance feedback to drivers has a 

lasting improvement on intervehicular distance. 

System design consideration must also be given to the overall goal of safety. If the information is 

available to monitor following distance, it should also be coupled with a fully functional FCWS 

to aid the driver, especially since it was found in earlier research that the more tangible benefits 

the system could provide, the more likely drivers would accept the system. 

39 
Additionally, there will likely be an issue with handling vehicle cut-ins, which are a common 

problem around heavy trucks. Specifically, drivers will likely be unhappy if their feedback 

penalizes them for following too closely when an event was not considered their fault. 

Additional Discussion 

In Table 18, stopping distances required by both cars and trucks for various initial speeds are 

given. These stopping distances are based on typical deceleration rates as reported by Radlinski 

(1987) for a variety of light and heavy vehicles; however, these numbers are on the extreme side, 

as maximum vehicle braking capabilities often exceed the limit drivers are willing to push them. 

From the required stopping distances, a safe following distance can be computed by subtracting a 

typical car’s stopping distance from the truck’s stopping distance and adding buffers for air brake 

lag and driver reaction time. Air brakes typically take a half-second to build up pressure before 

braking can start; however, some models of truck may take up to a full second. The typical value 

reported for driver perception-response time is 1.5 seconds, which was the 95 percentile response 

time found in the CAMP project (Kiefer, et al., 1999) for a reasonably attentive driver. 

Table 18. Safe Following Distance by Speed for Cars and Trucks 

Speed 

(mph) 

Speed 

(m/s) 

Car Stopping 

Distance (m) 

Minimum 

Truck 

Stopping 

Distance 

Maximum 

Truck 

Stopping 

Distance 

Safe 

Following 

Distance (m) 

Safe 

Following 

Distance (s) 

1.5 2.2 2.7 

20 8.9 6.1 8.7 10.8 22.6 2.5 

30 13.5 13.6 19.5 24.3 37.5 2.8 

40 17.9 24.2 34.8 43.2 54.7 3.1 

50 22.4 37.8 54.3 67.5 74.4 3.3 

60 26.8 54.5 78.2 97.2 96.4 3.6 

70 31.3 74.2 106.4 132.3 120.7 3.9 

Factors such as trailer loading and weather conditions may also be important when determining 

the safe following distance; however, these factors were not included in this table 14. 

Additionally, some fine-tuning will likely be necessary to adjust safe following distances, based 

on typical driver preferences and to make sure that an opportunity for even more hazardous 

situations aren’t created (such as an opportunity for vehicle cut-ins). 

Eaton (http://www.vorad.com/) is one of the leading COTS manufacturers of commercial 

collision warning systems, and they currently manufacture the VORAD radar-based FCWS 

specifically designed for trucks. Delphi also has a COTS FCWS called Forewarn 

(http://delphi.com/manufacturers/cv/safesecure/). 

Cross-References 

See Section 2.5.1: Vehicle Speed. Following distance is related to rear-end collisions and another 

metric which may also be related is vehicle speed relative to traffic flow. 

40 
See Section 2.5.3: Attention. Safe following distances are based on the attentive driver. Although 

rear-end collisions were one of the three major crash scenarios found in the LTCCS, 

intentionally following too closely was only a factor in approximately 4 percent of crashes, 

and inattention was to blame far more often. 

See Section 2.5.4: Hard-Braking Incidents. Same as above. 

2.5.3. Monitoring Attention 

Introduction 

The LTCCS found that nearly 46 percent of the two-vehicle crashes caused by trucks were 

primarily attributed to inattention or distractions (See table 2.). Overall, inattention or distraction 

was an associated or related factor in over 25 percent of crashes. In table 4, factors related to 

distraction were given as potential behavioral failure mechanisms for all of the major types of 

truck crashes, including single vehicle ran-off-the-road crashes, head-on collisions, intersection 

crashes, and rear-end collisions. 

Candidate Driver Behaviors for Onboard Monitoring 

The candidate driver behaviors for onboard monitoring are as follows: 

• Driver eyes-off-the-road time 

• Driver eye scanning patterns 

• Surrogate measures (see hard-braking incidents, lane position, and lane keeping) 

Driver Feedback Recommendations 

Recommended driver feedback designs are as follows: 

• Delayed or offline feedback with summary statistics 

• Real-time feedback of eyes-off-the-road time and traveled distance 

• Supplement to a collision warning system 

Feedback for driver attention monitoring could be provided in the form of delayed summary 

feedback or possibly through a real-time display. Inspiration for a real-time, eyes-off-the-road 

feedback device might come from the interface developed by Attention Technologies for its 

drowsy driver detection system (Ayoob, Grace, and Steinfeld, 2003). In this system, eyes-closed 

time along with distance traveled in that time is fed back to the driver. 

Recent news releases from Japan have described a driver attention monitoring system currently 

being researched by Toyota. The system recognizes facial orientation to establish probable eyesoff-the-road events to supplement collision and precrash warning systems. If the driver is found 

to be looking away from the road, the forward-collision warning could be given sooner and 

stronger in an attempt to get the driver back to being focused on the road ahead. Thus, in the 

pursuit of overall system safety, if the information is available from monitoring eyes-off-the-road 

time and following distance, should the monitoring feedback be coupled with collision warning 

systems to aid the driver? 

41 
Additional Discussion 

Two direct measures of driver attention (or inattention) have been proposed and discussed in the 

literature: (1) eyes-off-the-road time and (2) changes in the driver’s scanning patterns. Eyes-offthe-road time has generally been referenced in the context of the design of in-vehicle devices, 

specifically, navigation systems. Green (1998) summarizes links that have been found in the 

literature between eyes-off-the-road time (glance duration and frequency) and lane departures. 

More recently, Victor, Harbluk, and Engström (2005) have shown that changes in eye scanning 

patterns may also indicate distraction or inattention. Specifically, when attention becomes 

divided between two tasks, such as driving and an in-vehicle task, the driver’s scanning pattern 

of the road ahead becomes more tunneled. 

While direct measures of attention tend to focus on the driver’s visual attention, indirect or 

surrogate measures of attention might include looking at the outcome or result. Potential 

indications that a driver is or has been distracted might include hard-braking incidents or 

excessive weaving (poor lane position control). 

Cross-References 

See Section 2.5.2: Following Distance. Rear-end collisions are a typical byproduct of an 

attention failure, and the typical countermeasure is a FCWS as discussed in section 2.5.2. 

See Section 2.5.4: Hard-Braking Incidents. Hard-braking incidents may provide a surrogate 

measure for monitoring attention. 

See Section 2.5.5: Lane Position. Ran-off-the-road crashes are a typical byproduct of an attention 

failure, and the typical countermeasure is a lane-departure warning system as discussed in 

section 2.5.5. Lane position may provide a possible surrogate measure for monitoring 

attention. 

2.5.4. Monitoring Hard-Braking Incidents 

Introduction 

Rear-end crashes (table 5) can potentially result from many behavioral failures, such as 

distraction, falling asleep, failures to anticipate changes in traffic, and failures to react to vehicle 

cut-ins. Since many of these behaviors are difficult to monitor directly, one potential solution is 

to monitor, record, and investigate near misses which can be defined as hard-braking events. 

Candidate Driver Behaviors for Onboard Monitoring 

The candidate driver behaviors for onboard monitoring are as follows: 

• The frequency of hard-braking events 

• The engineering details and forward looking video surrounding the event 

Driver Feedback Recommendation 

The recommended driver feedback design is as follows: 

42 
• Delayed or offline feedback with summary statistics 

Feedback for near misses or hard-braking events is best provided offline with summary statistics. 

A real-time feedback system for these events would not be recommended since the driver would 

already be aware of the event, and the event would be completed by the time the system could 

react. Even if the system could detect and react during a hard-braking event, it would not be 

recommended because the driver’s attention should be focused on controlling the vehicle at that 

point, not on receiving feedback. Useful feedback on hard-braking events comes from reviewing 

event frequency over time. While the driver may be aware of an individual braking event, the 

driver may not realize just how many situations he or she gets into that require hard braking 

during a specific time period or how that compares to other drivers. 

Additional Discussion 

The XATA, the Accident Prevention Plus, and the DriveCam onboard monitoring COTS systems 

record hard-braking events. The DriveCam system also records audio and video both before and 

after the incident. 

Cross-References 

See Section 2.5.2: Following Distance. Hard-braking incidents may be related to rear-end 

collisions, which are also related to following distance. 

See Section 2.5.3: Attention. Hard-braking incidents may provide a surrogate measure for 

attention. 

See Section 2.5.7: Incidents. Hard-braking incidents are just one of many incidents that might be 

monitored and recorded. 

2.5.5. Monitoring Lane Position (Including Lane Departure) 

Introduction 

As described in section 2.2, lane departures was one of the three major critical reasons for truck 

crashes as identified in the LTCCS which can result in ran-off-the road crashes, head-on 

collisions, and lane change or merge crashes. Although poor vehicle control only accounted for 

about 5 percent of truck caused crashes (table 2), lane position might also provide a surrogate 

measure of driver inattention, which can also lead to crashes. 

Candidate Driver Behaviors for Onboard Monitoring 

The candidate driver behaviors for onboard monitoring are as follows: 

• Lane position 

• Steering inputs 

Driver Feedback Recommendations 

The recommended driver feedback designs are as follows: 

43 
• Delayed or offline feedback with summary statistics 

• A lane departure warning system (LDWS) 

Feedback on lane position would best be provided offline with summary statistics and real-time 

through a LDWS. Most measures of lane-keeping performance are either normalized over time 

or for the express purpose of predicting a lane departure. Providing lane-keeping performance 

feedback after a lane departure would be similar to providing feedback after a hard-braking 

event. The driver already knows that an event has occurred and the feedback could potentially be 

distracting. What the driver may not realize is how many lane departure events he becomes 

involved in and how this compares to other drivers. 

Real-time feedback would best be provided through a predictive lane-departure warning system. 

Iteris (http://www.iteris.com/) is one of the leading COTS manufacturers of commercial truck 

lane-departure warning systems. Delphi also has the Forewarn Lane Departure Warning System 

(http://delphi.com/manufacturers/cv/safesecure/). 

Additional Discussion 

Three direct measures of lane-keeping performance have generally been proposed and discussed 

in the literature: (1) the number of lane departures per vehicle-miles traveled (VMT), (2) the 

standard deviation of lane position (over a time window), and (3) time-to-line crossing (TLC). 

The standard deviation or variance of lane position has generally been reported in the literature 

as a measure of lane-keeping performance; however, it is generally used to compare one 

condition to another, and absolute safety criteria has never been defined. Green, et al. (2003) 

provides a good summary of how the standard deviation of lane position has been used in the 

past. 

TLC was first suggested by Godthelp, Milgram, and Blaauw (1984) and more recently in a paper 

comparing the merits of various calculation methods by van Winsum, Brookhuis, and de Waard 

(2000). 

Two indirect measures of lane-keeping performance have been proposed and discussed in the 

literature: (1) steering wheel reversals and (2) steering entropy (Hp). Steering wheel reversals had 

been proposed as a measure of workload, but it was not found to be a very sensitive measure 

Steering entropy is a promising measure that has been recently proposed to quantify drivers’ 

efforts to maintain lateral safety margins (Boer, 2001; Boer, et al., 2005). Steering entropy was 

originally developed as a measure that might be used to quantify reduced or diverted attention or 

changes in the driver’s workload and has recently also been proposed as a measure of fatigue 

(Paul, et al., 2005). 

Cross-References 

See Section 2.5.3: Attention. Lane position may provide a possible surrogate measure for 

monitoring attention. 

See Section 2.5.6: Lane Changes. While section 2.2.2 covers unintentional lane departures, 

section 2.5.6 covers intentional lane departures. 

44 
Key References: 

Boer, E(2001) Behavioral Entropy as a Measure of Driving Performance Proceedings of the First 

International Driving Symposium on Human Factors in Driver Assessment, Training and 

Vehicle Design Iowa City, IA: The University of Iowa[Available Online at 

http://ppc.uiowa.edu/driving-assessment/] 

Boer, E., Rakauskas, M., Ward, N., and Goodrich, M(2005) Steering Entropy Revisited 

Proceedings of the Third International Driving Symposium on Human Factors in Driver 

Assessment, Training and Vehicle Design Iowa City, IA: The University of Iowa[Available 

Online at http://ppc.uiowa.edu/driving-assessment/] 

Godthelp, J., Milgram, J., Blaauw, G(1984) The development of a time-related measure to 

describe driving strategy Human Factors 26, 257–268. 

Green, P., Cullinane, B., Zylstra, B., and Smith, D(2003) Typical Values for Driving 

Performance with Emphasis on the Standard Deviation of Lane Position: A Summary of 

Literature (Technical Report UMTRI-2003-42) Ann Arbor, MI: The University of Michigan 

Transportation Research Institute. 

Paul, A., Boyle, L., Boer, E., Tippin, J., and Rizzo, M(2005) Steering Entropy Changes as a 

Function of MicrosleepsProceedings of the Third International Driving Symposium on 

Human Factors in Driver Assessment, Training and Vehicle Design Iowa City, IA: The 

University of Iowa[Available Online at http://ppc.uiowa.edu/driving-assessment/] 

van Winsum, W., Brookhuis, K., and de Waard, D(2000)A comparison of different ways to 

approximate time-to-line crossing (TLC) during car driving Accident Analysis and 

Prevention 32, 47-56. 

2.5.6. Monitoring Lane Changes 

Introduction 

As previously described in table 3, lane change and merge related crashes were grouped under 

lane departures as a causal factor. In most of the other analyses that were reviewed, lane change 

crashes were typically combined with several other types of crashes; however, lateral 

encroachment during lane changes often due to improper mirror adjustment was listed as an atrisk driving behavior that is one of the top concerns among industry experts (Knipling, Hickman, 

and Bergoffen, 2003). 

Candidate Driver Behaviors for Onboard Monitoring 

The candidate driver behaviors for onboard monitoring are as follows: 

• Use of turn signal before merging 

• Eye glances to the mirror before merging 

• Did the driver adjust the mirrors before departing the yard 

• Side or blind spot vehicle presence or position during lane changes 

45 
Driver Feedback Recommendations 

The recommended driver feedback designs are as follows: 

• Delayed or offline feedback with summary statistics 

• A side object awareness and collision avoidance system 

Feedback on items such as turn signal use, mirror adjustments, and eye glances would best be 

provided offline with summary statistics. If real-time monitoring of side or blind spot vehicles is 

possible, feedback would best be provided through a side-object awareness and collision 

avoidance system. 

Additional Discussion 

There has been much research on side-object detection and side-collision avoidance systems 

resulting from three NHTSA initiatives on the topic. Descriptions of these programs can be 

found on the NHTSA web site’s link as follows: http://www-nrd.nhtsa.dot.gov/departments/nrd12/11rev.html. More recently, a Society of Automotive Engineers (SAE) paper which may be of 

relevance (Smith, et al., 2003) discussed the feasibility of modeling lane-change performance 

using four states. 

Eaton (http://www.vorad.com/) is one of the leading COTS manufacturers of commercial 

collision warning systems. The VORAD BlindSpotter is a currently available radar-based, sideobject detection system for truck applications. Delphi also has the Forewarn Radar Side Alert 

system (http://delphi.com/manufacturers/cv/safesecure/). 

Cross-References 

See Section 2.5.5: Lane Position. While section 2.2.2 covers intentional lane changes, section 

2.5.5 covers unintentional lane changes (lane departures). 

2.5.7. Monitoring and Recording Incidents 

Introduction 

Industry experts (Knipling, Hickman, and Bergoffen, 2003) and truck drivers (Roetting, et al., 

2005) both ranked several fuzzy behavioral concepts, such as defensive driving skills, space 

management, anticipating traffic changes, and being ready to avoid the mistakes of other drivers, 

as critical safety behaviors. Unfortunately, most of these concepts are difficult to measure 

directly, so one potential solution is to monitor, record, investigate, and teach drivers these skills 

through incident investigation. 

Candidate Driver Behaviors for Onboard Monitoring 

The candidate driver behaviors for onboard monitoring are as follows: 

• Hard braking incidents 

• Hard steering incidents 

• Close following distances (vehicle cut-ins) 

46 
• Collision warning system activations 

• Crashes 

• Forward and/or driver video during the incident 

Driver Feedback Recommendation 

The recommended driver feedback design is as follows: 

• Delayed or offline feedback 

Feedback on the monitoring and recording of incidents would likely need to be part of a carefully 

constructed program that would be presented to drivers in a nonthreatening way. The goal of the 

program would be to have drivers examine and review near-misses and other violent maneuvers 

in such a way that they might learn the skills necessary to avoid such incidents in the future. 

The resulting analysis will be most effective as more and more data can be included about the 

incident, especially forward-looking video and video of the driver at the time. Drivers will relate 

to and recall the details of the incident much better if video is provided. The inclusion of 

forward-looking video might allow the system to be thought of as protection against liability in 

the case of a crash, since most crashes involving large trucks are not the fault of the truck driver. 

However, video of the driver may prove a difficult “sell,” given privacy concerns. 

Additional Discussion 

Several of the reviewed COTS devices record or flag various events. XATA records rapid stops 

and contains tools to reconstruct accidents with black box data. The Accident Prevention Plus 

system records vehicle data for 50 seconds before and 20 seconds after a crash, and the 

DriveCam system records both vehicle data an external video both before and after large g-force 

events or crashes. Finally, Eaton (http://www.vorad.com/) makes the VORAD Accident 

Reconstruction Technology, a product which combines vehicle data with the data received from 

a VORAD FCWS to graphically reconstruct crashes. 

Cross-References 

See Section 2.5.4: Hard Braking Incidents. Hard-braking incidents are discussed in detail in 

section 2.5.4. 

2.5.8. Monitoring Fatigue 

Introduction 

Industry experts ranked fatigue or drowsy driving as number six out of their top nine safety 

concerns (Knipling, Hickman, and Bergoffen, 2003), and drivers ranked it as number five out of 

their top ten (Roetting, et al., 2005). However, European crash data has shown that fatigue was a 

causal factor in only 5.3 percent of truck crashes (Häkkänen and Summala, 2001), and the 

LTCCS found similar results, suggesting that only 4 percent of crashes could be attributed to 

sleep or sleep-related to illness. 

47 
Candidate Driver Behaviors for Onboard Monitoring 

The candidate driver behaviors for onboard monitoring are as follows: 

• Driver eye movements 

• Lane position 

Driver Feedback Recommendation 

The recommended driver feedback design is as follows: 

• Real-time drowsy driver detection and warning system 

Fatigue or drowsy driving can result in an immediate threat if left unchecked; short breaks, naps, 

and even a simple cup of coffee at the right moment can be a highly effective countermeasure to 

fatigue, as the human body tends to work in cycles or rhythms. The goal of any fatigue feedback 

system should be first and foremost to assist the driver in determining when best to stop and take 

a break. A second goal might be to educate or convince a driver that a break is necessary, and 

finally, the feedback should be able to warn or wake a driver engaged in microsleeps. One novel 

feedback interface exists on the Copilot driver fatigue monitoring system by Attention 

Technologies (http://www.attentiontechnology.com/); its user-centered design is detailed in 

Ayoob, Grace, and Steinfeld (2003). 

Additional Discussion 

A distinction should be made between the terms and concepts of fatigue and drowsy-driving 

fatigue, which is often lumped together with drowsy driving on surveys, since the terms might 

carry certain connotations which could affect how highly it has been rated as a problem by 

drivers compared to the actual crash statistics. Fatigue represents an entire continuum which ends 

in drowsy driving. Noticeable changes occur and increase with the onset of fatigue, such as 

feelings of tiredness, a lack of the ability to focus attention, decreased working memory, slowed 

reactions times, and tunnel vision in eye scan patterns. Some of the indicators were specifically 

reported with solo long-haul truck drivers in Hartley, et al. (1994). A recent paper by 

Williamson, et al. (2001) further detailed and characterized some of the cognitive and motor skill 

performance decrements that can be associated with fatigue. Moderate stages of fatigue may 

mimic distracted driving, resulting in a general, overall increased crash risk. This is generally 

believed to be one of the reasons why crashes occur more frequently during evening commutes 

rather than during morning commutes. 

As fatigue slowly builds, sometimes over a series of hours, it becomes drowsy driving, which 

can be characterized by extreme tunnel vision and microsleeps. One fatigue or drowsy-driving 

detection method or measure that has been researched, validated, and extensively tested is 

PERCLOS. Simply put, PERCLOS is the percentage of eye closure, and some of the early work 

on the measure can be found in Weireille, et al. (1994) and Dinges, et al. (1998). At least one 

COTS fatigue monitoring device utilizing PERCLOS is available, the Copilot, which is made by 

Attention Technologies (http://www.attentiontechnology.com/). 

48 
Steering entropy, a measure of lane-keeping performance, has also been recently proposed as a 

surrogate measure for fatigue (Paul, et al., 2005). 

Cross-References 

See Section 2.5.2: Following Distance. One possible result of driver’s falling asleep at the wheel 

is a rear-end collision, and an FCWS may also prove a useful countermeasure. 

See Section 2.5.3: Attention. The stages of fatigue can result in similar performance decrements 

as seen with inattention, so similar monitoring techniques may prove useful to both. 

See Section 2.5.5: Lane Position. One likely result of driver’s falling asleep at the wheel is a lane 

departure, so lane position may be a surrogate for drowsy driver detection, and a lanedeparture warning system may also prove a useful countermeasure. 

See Section 2.4.9: Hours of Service. One surrogate to measuring fatigue directly is monitoring 

HOS. 

2.5.9. Monitoring Hours of Service 

Introduction 

The maximum HOS a driver can perform is specified in both Federal and State regulations. 

These limits have been placed, in part, to guard against driver fatigue. Drivers are required to 

keep logs to determine compliance the mandatory HOS requirements, and the requirements for 

an automatic monitoring system have already been laid out in both the Federal and the State odes 

which are listed below. It is noted that there are many nuances in HOS rules, to include, for 

example, the restart provision. The final OBMS system should be carefully designed to 

accommodate this and other nuances to the rule and will include additional considerations, such 

as the amount of time left before a HOS violation. 

Candidate Driver Behaviors for Onboard Monitoring 

The requirements for HOS for automatic onboard monitoring per Federal Regulation CFR III395.15 of Title 49 are as follows: 

1. Duty status: off duty, sleeper berth, driving, or on duty not driving 

2. Date 

3. Total miles driven today 

4. Truck or tractor and trailer number 

5. Name of carrier 

6. Main office address 

7. 24-hour period starting time 

8. Name of co-driver 

9. Total hours 

10. Shipping document number or name of shipper and commodity 

49 
11. For each change of duty status, the name of the city, town, or village, with state must be 

recorded. 

12. Amount of time remaining before exceeding HOS. 

The requirements for HOS for automatic onboard monitoring per California Code Section 1213.2 

are as follows: 

1. Engine use 

2. Road speed 

3. Miles driven 

4. Date 

4. Time of day 

6. Duty status 

7. Multiple drivers 

Driver Feedback Recommendations 

The feedback requirements for automatic onboard monitoring of HOS per California Code 

Section 1213.2 are as follows: 

1. Automatic onboard recording devices should produce an electronic display or printout 

(on demand) of a driver’s HOS, showing the time, sequence, and location of duty status 

changes including the driver’s starting time at the beginning of each day. 

2. Automatic onboard recording devices with electronic displays must have the capability of 

displaying the following: 

– Driver’s total hours of driving 

– Total hours on duty today 

– Total miles driven today 

– The sequential changes in duty status, and the times and locations where changes 

occurred for each driver. 

Additional Discussion 

The maximum hours of operation as defined by Federal and State codes and regulations are 

compared in Table 19. Federal regulations apply for interstate travel, but the California State 

Code, which is somewhat less stringent, applies for intrastate travel. In addition to the Federal 

and State regulations, the TRB has published a guide on HOS and fatigue management 

techniques (Brock, et al., 2005) 

50 
Table 19. Federal Regulations for Interstate Travel Versus California State Code 

CFR Title 49, Subtitle 3, Chapter III, 

Section 395.3 

California Vehicle Code 

Section 34501.2 

(1) May drive a maximum of 11 hours after 10 

consecutive hours off duty. 

(1) The maximum driving time within a work 

period must be 12 hours for a driver of a 

truck or a truck tractor, except for a driver 

of a tank vehicle with a capacity of more 

than 500 gallons transporting flammable 

liquid, who must not drive for more than 10 

hours within a work period. 

(2) May not drive beyond the 14th hour after 

coming on duty, following 10 consecutive 

hours off duty. 

(2) No motor carrier must permit or require a 

driver to drive, nor must any driver drive, 

for any period after having been on duty for 

80 hours in any consecutive eight days. 

(3) May not drive after 60/70 hours on duty in 

7/8 consecutive days. 

(3) Exceptions include drivers hired by: 

a. Water, electrical, and gas corporations 

b. Governmental fire and law enforce 

departments 

c. Agricultural carriers (different 

restrictions apply) 

(4) CMV drivers using a sleeper berth 

provision must take at least 8 consecutive 

hours in the sleeper berth, plus 2 

consecutive hours either in the sleeper 

berth, off duty, or any combination of the 

two. 

EOBRs have been available for completing records of duty status (RODS), fulfilling operator 

HOS regulations since 1988. Three current COTS devices which are currently on the market are 

described in Table 20. 

Table 20. Features of Three Current COTS Devices Currently on the Market 

Company 

CFR 49 

Part 395.15 

Compliance 

GPS-based 

Location 

Recording 

Wireless 

Communication 

Vehicle 

Speed 

Two-way 

Text 

Message 

Fuel 

Consumption 

Evaluation 

Karta × × × × × 

Nextel × × × × × × 

Tripmaster × × × × 

Karta’s TransTRAK (also known as planetTRAKS) system (http://www.planettraks.com/) is a 

vehicle tracking system that is designed to deliver real-time vehicle location, speed, distance 

monitoring, and data on numerous other vehicle events. The bonus features of this system consist 

of: (1) GPS-based positioning, routing, and “geofences,” (2) asset tracking, and (3) two-way text 

messaging system. This system can automate the collection and reporting of driver duty status 

information. 

51 
Nextel’s XORA system (http://www.nextel.com/en/solutions/gps/xora.shtml) system is a JAVAand GPS-enabled phone that is designed to deliver real-time user location, speed, distance 

monitoring. The bonus features of this system consist of: (1) GPS-based positioning, routing, and 

“geofences” and (2) phone alerts for HOS violations. The advantage of this system is that the 

EOBR functions have been built into a cell phone. 

The purpose of Tripmaster’s suite of products (http://www.tripmaster.com/) is to assist in basic 

federal compliance reporting requirements, such as computing fuel and mileage tax and driver 

logs. The additional features of this system include: (1) GPS-based positioning and (2) overspeed 

continuous warning beeper. 

Cross-References 

See Section 2.5.8: Fatigue. Monitoring HOS may be considered surrogate to measuring 

fatigue directly. 

Key References: 

Brock, J., Golembiewski, G., Krueger, G., Daecher, C., Bishop, R., Bergoffen, G(2005) 

Commercial Truck and Bus Safety Synthesis Program: Synthesis 7- Motorcoach Industry 

Hours of Service and Fatigue Management Techniques Washington D.C.: Transportation 

Research Board. 

California Code of Regulations, Title 13 Motor Vehicles, Division 2 Deptof CHP, Chapter 6.5 

Motor Carrier Safety, Article 3 General Driving Requirements, Section 1213.2 Automatic 

Onboard Recording Devices. 

California Vehicle Code, Division 14.8 Safety Regulations, Section 34501.2 Limitations: 

Driving Hours. 

Code of Federal Regulations, Title 49, Subtitle 3, Chapter III, Sections 395.3 and 395.15. 

Nextel’s XORA website: 

planetTRAKS website: http://www.planettraks.com/ 

Tripmaster’s website: http://www.tripmaster.com/ 

2.5.10. Monitoring Behaviors at Intersections 

Introduction 

The LTCCS found that intersection-related crashes accounted for approximately 27 percent of 

the crashes caused by truck drivers, which was the third largest category of critical events. As 

described in section 3.2, intersection crashes can result from poor scanning, failures in 

perception, and poor decisions. The LTCCS, in table 2, found that, overall, 46 percent of the 

crashes were primarily the result of inattention or distraction, and 36 percent were primarily 

caused by driver decisions (misjudgments). Unfortunately, without knowing exact vehicle 

locations, it’s very difficult to monitor or critique driver decisions While this may become 

possible in the future with the advent of vehicle-to-vehicle (V2V) and vehicle-to-infrastructure 

(V2I) communications, there are several near-term possibilities for intersection behavior 

monitoring. 

52 
Candidate Driver Behaviors for Onboard Monitoring 

The candidate driver behaviors for onboard monitoring are as follows: 

• Stopping for stop signs 

• Stopping for red lights 

• Eye-glance patterns (i.e., checking for cross-traffic when leaving a 2-way stop sign) 

Driver Feedback Recommendations 

The recommended driver feedback designs are as follows: 

• Delayed or offline feedback 

• Real-time stop sign or red light violation warning system 

Feedback for intersection behavior monitoring would best be provided through offline with 

summary statistics. A real-time feedback system for these events would not be recommended 

since the driver would already be aware of the event, and the event would be completed by the 

time the system could react. Useful feedback on these events may come from reviewing event 

frequency over time. While the driver may be aware of an individual event, the driver may not 

realize how often those events happen. 

Alternatively, there has been recent and ongoing research (FHWA, 2004) on the topic of stop 

sign and red light violation warnings. This research should eventually result in specifications on 

how to predict violations and provide the driver with real-time feedback in the form of a warning 

system. 

In the OBMS prototype implementation, intersection warning was not provided due to difficulty 

in acquiring the correct map database with stop signs and traffic signals; however, this will be an 

open topic in the ensuing FOT. 

Additional Discussion 

While enhanced maps might provide the locations of stop signs and traffic signals, detecting the 

current phase of the traffic signal can probably only be achieved through video detection and 

processing. In there near future, there may be the possibility of getting traffic signal state 

automatically through V2I communications. 

Checking eye-glance scanning patterns, although possible, would probably provide little useful 

information. Intersection scanning is complex and not well–understood. Additionally, scanning 

does not necessarily result in seeing or perceiving, as is evident by the crash causation category 

of “looked, but did not see.” 

Cross-References 

See Section 2.5.3: Attention. Intersection crashes may also result from inattention or distraction. 

53 
2.5.11. Monitoring Other Vehicle Parameters 

Introduction 

In this section, other vehicle parameters include engine RPM, acceleration, gear position, throttle 

position, clutch position, fuel consumption rate, and safety belt usage. The reasons of monitoring 

these parameters can be divided into three categories: 

1. Incident reconstruction. In general, vehicle locations, speeds, and accelerations can be 

used to reconstruct vehicle trajectories during an accident. Since some of these sensors 

may not work accurately when incidents occur, the redundancy of the sensor information 

can be very helpful. 

2. Prevention of vehicle abuse. Two examples are used to illustrate the incentive to monitor 

vehicle abuse. First, running engines at high RPM frequently can result in abnormal 

engine wear. The second example is that for vehicles with manual transmission, 

depressing clutch pedals halfway can cause additional clutch wear or gear damage. As a 

result, monitoring engine RPM, clutch positions, throttle position, etc., can help prevent 

abuse by drivers. 

3. Fuel economy. One of the concerns from fleet managing teams is the fuel economy. From 

the aspect of public health, good fuel economy implies less air pollution. Combining 

throttle positions, gear positions, fuel rate, and engine RPM, one can determine if drivers 

have good driving habits to “save some gas.” In addition, increased fuel economy has 

been linked with safer driving, so the contribution to greater fuel economy links to the 

objectives of OBMS. 

4. Safety belt. Truck driver safety belt usage can be electronically monitored to give an 

indication whether the truck is moving and the seat belt is not buckled. This is a relatively 

straightforward monitored parameter that could yield a simple and important change in 

some drivers’ behavior. 

Candidate Driver Behaviors for Onboard Monitoring 

The candidate driver behaviors for onboard monitoring are as follows: 

1. Engine RPM (engine overspeed) 

2. Appropriate gear selection 

3. Use of low gears to save brake when driving on slopes 

4. Fully depressing/releasing clutch (for vehicles with manual transmission) 

5. Driving time 

6. Nondriving time 

7. Engine idle time 

8. Acceleration 

9. Deceleration 

10. Fuel rate/fuel economy 

11. Safety belt use 

54 
Driver Feedback Recommendations 

The recommended driver feedback designs are as follows: 

• Delayed or offline feedback 

• Safety belt use to be fed back both real-time and offline 

Much of the information described in this section is not essential to be displayed in real-time, 

and those items that are essential already have driver displays. 

Additional Discussion 

A listing of COTS systems and the auxiliary vehicle parameters monitored by each company is 

provided in Table 21. The companies are: 

• XATA (http://www.xata.com/) 

• Delphi (http://www.mobilearia.com/prodserv/trucksecure.shtml) 

• APPlus (no information available) 

• Cadec (http://www.cadec.com/) 

• QualCOMM (http://www.qualcomm.com/qwbs/solutions/prodserv/sentracs.shtml) 

• DriveCam (http://www.drivecam.com/) 

While these parameters may not always be safety related, fuel economy and vehicle maintenance 

translate to direct cost savings for management, making them desirable additions to any onboard 

monitoring system. 

Table 21. COTS Systems and the Auxiliary Vehicle Parameters Monitored 

Mileage 

Engine 

RPM Acceleration 

Gear 

Position 

Throttle 

Position 

Fuel 

Rate 

Clutch 

Position 

XATA × × × × × 

Delphi × 

APPlus × × × × 

Cadec × × 

QualCOMM × × × 

DriveCam × 

Another example is Eaton’s VORAD Information Management System (EVIMS) 

(http://www.roadranger.com/). It analyzes safety trends for drivers and vehicles, benchmarks 

safety goals for the fleet, and identifies drivers who do meet those goals. The EVIMS does this 

by comparing individual driver and vehicle performance to fleet averages. Additional features 

include braking and fuel economy, time on brake, and slow traffic reports. 

Cross-References 

See Section 2.5.4: Hard-Braking Events. 

55 
See Section 2.5.7: Recording Incidents. 

Key References: 

APPlus: At the time of this report, information on this company could not be found. 

Cadec’s Mobile Information System website: http://www.cadec.com/ 

Delphi’s TruckSecure is offered by MobileAria at the following website: 

http://www.mobilearia.com/prodserv/trucksecure.shtml 

DriveCam’s website: http://www.drivecam.com/ 

Eaton’s EVIMS is marketed and sold through its RoadRanger subsidiary at the following 

website: http://www.roadranger.com/ 

QualCOMM’s SensorTRACS website: 

http://www.qualcomm.com/qwbs/solutions/prodserv/sentracs.shtml 

Transportation Development Centre (June 1998) Incentive Programs for Enhancing Truck Safety 

and Productivity: A Canadian Perspective TP 13256E 

XATA’s website: http://www.xata.com/ 

A successful driver monitoring system should ideally monitor “unsafe” driving behaviors, which 

might be defined as any behavior that can be shown to be a precursor to increased crash risk. 

Thus, to understand what behaviors are unsafe, we must first understand what factors “cause” or 

lead to crashes involving large trucks. As discussed throughout this literature review, this is no 

easy task, and ultimately, the research to definitively answer this question is still ongoing; 

however, the delineation of truck crash causal factors is still a key element required to create a 

ConOps for an onboard driver monitoring system, even if the research reporting the casual 

factors is still preliminary. 

56 
3. STAKEHOLDER FEEDBACK 

Proceeding with the systems engineering methodology described in Appendix A, a stakeholder—

a mid-sized (100-truck) carrier operating in Los Angeles, California—was contacted. The drivers 

for this carrier generally operated from a central dispatch and, although operations were often at 

night time, they were at maximum several hundred miles. Drivers rarely slept in their cabs. 

Moreover, turnover was not high. 

A difficulty in interacting with this carrier was that other operational priorities dominated, so it 

was difficult to schedule time with management and drivers. Hence, the systems engineering 

approach could not be strictly followed. Specifically, by the time stakeholder feedback could be 

obtained, hardware procurement and hardware and software integration were well underway. 

The project team endeavored to ameliorate this poor timing by considering the literature 

described in previous subsections, specifically section 2.4, and inferred probable stakeholder 

reaction. 

The net result may be positive. At the time of this final report, it appeared that this particular 

carrier will not likely be part of the envisioned FOT for the very reasons of other operational 

priorities, and the likely FOT partner will be a different, larger carrier with a different corporate 

and safety culture. Nonetheless, the feedback from “typical” drivers in the six-driver groups sointerviewed in this project is an important resource and is reported in two subsections: 

• Group Discussions 

• Results and Relevancy 

The actual Carrier Q&A Outline that was used is also provided in a following subsection. 

3.1. GROUP DISCUSSIONS 

The purpose of this question-and-answer group discussion was to get driver feedback on an 

onboard driver monitoring system ConOps. Six drivers from a small- to medium-sized carrier 

based out of the Los Angeles area participated in a two-hour group discussion. The drivers were 

all full-time employees of the carrier and not owner-operators. The carrier employs around 100 

drivers at any given time and leases and maintains a relatively new fleet of trucks. The carrier 

was likely representative of the more safety conscious drivers in the industry, and it was unique 

in the fact that their trucks were already outfitted with the XATA monitoring system and in the 

fact that their trucks are speed governed at either 58 or 62 mph (depending on whether the trucks 

traveled intrastate or interstate). Likewise, the drivers that participated in the discussion were 

also representative of the most experienced and safety conscious drivers in the industry. 

The drivers were recruited by their management to participate in the discussion group. Most of 

the drivers participated at the beginning or end of their shift, although one driver volunteered to 

come in on his day off. Typically, the focus group method requires 8 to 12 participants to 

achieve the proper group dynamic and any representative or any measure of statistical precision 

or reliability that could be generalized. For these reasons, this discussion group is not referred to 

57 
as a focus group; however, since the drivers knew each other, the interactions between members 

was similar to the group dynamic that is achieved in a focus group, but statistical generalizations, 

such as 3 out of 6 drivers equating to 50 percent of the truck driving population, should be 

avoided with this sample. 

3.2. CARRIER Q&A DISCUSSION OUTLINE 

The following questionnaire was used as a guideline for the two-person interview team. 

Disclaimer: Everything discussed here will remain confidential. Your name and personal 

information will not be given to anyone except the research team. So please feel free to tell us 

what you really think. Your participation is strictly voluntary very important for this study. You 

may decide to leave the room at any time. 

• The session will take approximately two hours 

• We would like everyone to be involved in the discussion 

• Everyone’s opinions are important! 

• We expect different views and opinions. We are not looking for agreement. We are 

interested in all opinions. 

• If you have a cellular telephone, please turn it off now. 

3.2.1. UCB Introductions 

• Denise Allen: Public Policy Analyst 

– Background in legislative policy - specializing in public outreach prior to new policy 

implementation 

– Investigates the needs of stakeholders and represents the public interests to policy 

makers 

– Studies human behavior and interactions with the environment 

• Christopher Nowakowski: Human Factors Researcher Engineer 

– Studies driver behavior to find ways to improve safety and prevent crashes 

– Translates the needs of drivers to the designers of advanced safety systems 

– Designs interactions between drivers and systems 

• Christopher (taking notes) 

I would like to go around the table and have you introduce yourself. How about saying your first 

name, and tell me how long you have been with the company? 

3.2.2. California PATH (Partners for Advanced Transit and Highways) 

Research group that is part of the Intelligent Transportation Studies department at UCB. We act 

as a research arm between the UC system and its public and private partnerships. 

3.2.3. Past Projects 

• Virtual Weigh Station 

• Automated Speed Enforcement 

58 
• Truck Parking 

3.2.4. OBMS Project Description 

Research for FMCSA (Federal Motor Carrier Safety Administration) and CALTRANS 

FMCSA has sponsored numerous studies on truck safety. In general, research shows that truck 

drivers are extremely safe. However, crashes still happen and crashes involving trucks are 

devastating—450,000 trucks involved in crashes each year lead to 5,000 fatalities. (According to 

who? We need a citation here). 

The focus of this current project is to improve safety through Onboard Driver Monitoring, which 

provides feedback and continuous improvement based on the behavior-based safety method. 

We want to: 

• Identify behaviors which may be precursors to increased crash rates. 

• Determine cost-effective ways to monitor safe and unsafe behaviors. 

• Determine the best way to provide the driver with feedback which rewards safe behavior 

and discourages unsafe behavior. 

3.2.5. Current Project Status 

We are currently at the conceptual system design stage. This is only the very first stage of many: 

conceptualize, prototype, beta test, etc. 

We want your input, both as experts and as the eventual users, to help us design a system that 

will eventually be accepted, useful, and successful. Both FMCSA and CALTRANS value the 

input being gathered here today. 

3.2.6. Driver’s Opinions of the Current XATA Monitoring System. 

Now, we’d like to discuss a topic that might be a little more familiar to you. We understand the 

trucks being used by the carrier are equipped with a monitoring system—the XATA system 

(used in conjunction with a fuel economy monitoring program). 

• Can you tell me what the system monitors and how it works (from the driver’s point of 

view)? 

• How is driver identification done? (Is there a code or electronic key?) 

• Preventive maintenance? (What about it? Do you want to know what they think about it 

or how it works?) 

• Can you tell me about the text messaging system? (The system has one; is it used? If so, 

for what?) 

• How does the fuel economy monitoring and incentive program work? 

• What benefits does the system provide to you? 

• Did the system change your driving behavior? (show of hands) 

• If so, how? If not, why? 

59 
• Do you think a program focused on safety could benefit you? (show of hands) Please 

explain what benefits such a program would offer you. If you do not see the benefit, why 

not? 

3.2.7. Institutional Issues: Known Positives and Negatives 

This list (shown in Table 22) was compiled from other focus groups conducted with truck drivers 

like yourself. 

Table 22. Institutional Issues: Known Positives and Negatives 

Positive Negative 

Improved safety 

Regular objective assessment of both the good and 

bad provides opportunity for continuous 

improvement of driving skills 

Concern that the monitoring parameters are not 

indicators of safety 

Fear of being unfairly penalized for the actions of 

other drivers? 

What kind of review process might help with this 

fear? 

Would detailed training on how the system works 

alleviate fears? 

Collisions warnings 

Forward, Side, and Road Departure warnings 

added as a bonus to monitoring 

In the past, drivers thought that this side benefit 

would help system acceptance. 

Fear of too many bells, whistles, warnings, and 

distractions 

Does it help to limit audio warnings to only 

emergency situations? 

Does it help if most feedback is delayed, given 

daily, weekly, monthly? 

Increased efficiency 

What types of paperwork issues might a system 

like this be able to automate? (HOS, Others?) 

Fear of embarrassment or self-consciousness at 

being monitored 

Does it help if video is only saved during specific 

incidents instead of all the time? 

What other specific fears? 

Liability protection 

When it can be proven you’re not at fault? 

Fear of liability 

When you might be considered as partially at 

fault? 

Incentive programs Misuse of the collected data 

How? What is the fear here? 

BREAK: 10 Minutes 

3.2.8. Unsafe Behaviors (Open-ended) 

• What are the biggest safety challenges/obstacles to you as a truck driver? 

• What are the common safety problems/pitfalls experienced by novice drivers? 

• What driving behaviors should a system monitor to help improve safety? (Please list the 

top three; Top 1 to 3?) 

60 
3.2.9. Unsafe Behaviors (OBMS ConOps Feedback) 

Expand upon biggest safety concerns for the following topics: 

1. Speed 

• Drivers will probably point out that trucks are speed limited (55/62 mph) 

• Where is speeding a problem? Freeways? Two-lane Highways? Suburbs? City? 

• Curves? (What do you want to ask them—do they speed around curves?) 

• At night? (Does your speed change during certain times of the day? If so, why?) 

• How do weather conditions affect safe driving conditions? 

• How would you feel about a simple indicator light to alert you that the system thinks 

you’re going too fast? 

2. Following Distance 

• Please explain truck drivers’ rules-of-thumb for following distance? 

• Does your following distance change if your trailer is loaded or unloaded? 

• Do weather conditions affect your following distances? 

• Night? (be specific) 

• Are you concerned with cut-ins? 

• Are there special cases where short following distance is required? 

• How would you feel about a simple indicator light to alert you that the system thinks 

you’re following too closely? 

3. Lane Changes 

• Open-ended question here...What are the biggest safety issues with lane changes? 

• Do other drivers around you use their turn signal? Do you use your turn signal? Under 

what conditions? 

• Adjusting mirrors properly? What about it? 

• Blind spot check? We need to be very specific 

4. Attention/Distraction 

• Open ended question here...How big of a problem is becoming distracted? 

• Common scenarios/situations to look for? 

• Lack of attention can lead to hard braking...how often does this happen? 

• Lack of attention can also lead to leaving the lane...how often does this happen? 

5. Fatigue/Drowsy Driving 

• Open ended question here...How big of a problem in the industry? 

• Is fatigue ever a problem for you? If so, when? 

• How do overnight routes work? 

• How do 24-hour operations work (shifts)? 

• What are the HOS regulations that apply? (sort of asking for driver interpretation of 

federal regulations) 

• What paperwork do you have to do for HOS? 

• Could an automated system help here? Is so, how? If not, why? (Do they have one 

already?) 

6. Intersections 

61 
• Open ended question here...What are the biggest safety issues with intersections? 

7. Seat Belt Use 

• Is seat belt use a problem? Are you asking if wearing it is a problem or if drivers do not 

wear it? 

• Do trucks have the same seat belt warning systems as cars? Can you please explain: Is the 

issue of people just buckling the belt behind them prevalent? What does this mean? Are 

you asking if people wear the belt properly? 

• How would you feel about a random interval snapshot to make sure belt is on? What is a 

random interval snapshot? 

8. Incident Review 

• Video saved for review during (hard braking, steering, warning scenarios) 

• How might this help you? 

• How should such a review process be organized? 

That concludes all of the questions we have for you today. Do you have any questions for us? 

Thank you so much for taking time out of your busy day to answer our questions. We look 

forward to our partnership and working with you again soon. 

3.3. SUMMARY RESULTS AND RELEVANCY 

3.3.1. Driver Experience 

At the beginning of the discussion group, the participants were asked to read and sign a consent 

form and to fill out a short three-page questionnaire on their driving background and opinions on 

problem areas in the trucking industry. The participants reported between 3 and 25 years of 

experience with the company (with a mean of 14 years), but all of the drivers had over 19 years 

of truck driving experience (with a mean of 25 years). 

Four out of the six drivers were self-classified as exclusively short-haul, meaning that they leave 

from and return to the same base of operations each day in under 12 hours. The remaining two 

drivers were self-classified as primarily medium/long-haul, reporting that about 70 percent of 

their routes are longer than 12 hours, thus requiring an overnight stay; however, it should be 

noted that for this carrier, long-haul routes consisted of a single overnight stay with the driver 

returning to his home base on the following day. 

Road type usage varied wildly between drivers, likely depending on the specific routes driven by 

the drivers. Several drivers spent most of their time on rural or urban freeways, while others 

spent a fair amount of time on two-lane highways; however, most drivers agreed that only a very 

small portion of their routes were composed of suburban arterials or city streets. 

3.3.2. Perception of Safety Problems in the Trucking Industry 

The questionnaire asked the drivers to rank their level of concern over various safety topics. For 

most questions, two different answers could be given: one indicating their perception of the 

62 
problem in regard to truck drivers and the other indicating their perception of the problem in 

regard to car drivers. For each question, the following four responses were possible: 

1. Not concerned/not a problem 

2. Somewhat concerned/It can be a slight problem. 

3. Concerned/It is a problem. 

4. Very concerned/It is a serious problem. 

On the questions related to speeding, tailgating, aggressive driving, and fatigue (or drowsy 

driving), the drivers all agreed that they were concerned or very concerned about these issues, 

fairly equally for both truck and car drivers; however, when asked about HOS compliance, half 

of the drivers felt that the issue was not a problem or only a slight problem. 

The question on distracted driving elicited interesting responses. Drivers were split between 

somewhat concerned and very concerned over the issue in regard to truck drivers; however, all of 

the truck drivers were very concerned over distraction in regard to car drivers. The questions 

about lack of turn signal use and lack of blind spot checks elicited similar responses patterns, 

with truck drivers being more concerned with the lack of signal use displayed by car drivers. 

Concern over seat belt use was scattered over the responses, and the truck drivers were mostly 

very concerned with seat belt use among car drivers and not among truck drivers. Interestingly, 

this was reversed for the question on alcohol and drug use. The participants were mostly very 

concerned about alcohol and drug use among truck drivers but only concerned when it came to 

alcohol and drug use among car drivers. 

Mechanical failures and adverse weather conditions were generally reported as somewhat 

concerned or concerned; however, roadway infrastructure issues, such as poor road repair, 

signage, etc., were mostly reported as either concerned or very concerned. 

One driver commented that speeding on highways and especially in construction zones was one 

of the largest safety problems on the road. 

3.3.3. Discussion Summary 

XATA Onboard Monitoring System 

The first discussion topic centered on the participants perceptions of the XATA onboard 

monitoring system that was already in use by their carrier. The initial questions centered on what 

the system monitors and how the driver interact with it. 

The participants reported that the XATA system served as an electronic log book by monitoring 

the following parameters: 

• Miles traveled 

• Speed 

• Idle time 

• Fuel economy 

63 
• Locations 

• Breaks 

• Traffic, weather, or other incidents causing delay 

• Speed governing (58/62 mph depending on whether the truck travels intrastate/interstate) 

The system has a key that drivers use to log into and out of the truck, and then return the key to 

their management to upload the logged data to a central server. Once logged in to a vehicle, the 

system automatically records everything except traffic, weather, or other incidents causing delay. 

These events are keyed in by the driver using a text interface. Some frequently used messages, 

such as traffic delays, can be quickly entered via soft menu keys while driving. The drivers 

pointed out that the system functions only as a log. It cannot be used to communicate with other 

drivers or with dispatch. Drivers were also unaware of any preventative maintenance functions 

provided by the system. 

The speed governing system beeps at the driver as he approaches the vehicle’s maximum 

allowed speed. Once that speed is reached the engine will not go any faster. 

When asked whether or not the drivers liked the system, five of the drivers enthusiastically liked 

it, while one of the drivers commented that it was only OK. All of the drivers agreed that the 

XATA system was better than no system at all. The main advantages of the system were 

described as follows: 

• When using the system, the drivers do not have to keep a paper log. 

• The system backs the drivers up when they are late due to traffic or other incidents. 

• Drivers do not have to hurry to make up time if they are legitimately delayed. 

• The system can back up the driver’s claim that he wasn’t speeding in a crash. 

• The speed governing cuts down on the number of speeding tickets. 

Disadvantages of the system included the following: 

• A feeling that big brother was watching 

• The speed governing system robs engine power. 

• The system doesn’t provide navigation. 

• The system had no communication (to warn other drivers of traffic jams). 

The most controversial part of the system was the speed governing feature. At least three of the 

six drivers really liked this feature and perceived it as helping to keep them from getting 

speeding tickets and helping to keep the company’s insurance down; however, one of the drivers 

commented that speeding, overall, was not as much of a problem for their carrier because the 

drivers are paid by the hour resulting in less time pressure and less motivation to speed. Another 

driver commented that California has lower speed limits for trucks (a maximum of 55 mph) than 

other states, and often there is some latitude given by the California Highway Patrol (CHP), 

relating a story about being asked by CHP over the radio to speed up even though the driver was 

at the maximum allowed speed; however, other drivers reacted to that statement by pointing out 

that the unwritten latitude overspeed often can be used against you just as easily, resulting in a 

ticket. 

64 
Although none of the drivers were adamantly against the speed governing feature, one 

commented that the device robbed power from the engine, and another commented that there are 

times where you need a burst of speed, such as before hills and when passing. 

General Opinions on Onboard Driver Monitoring Systems 

Next, drivers were asked about potential benefits and pitfalls surrounding the concept of driver 

monitoring It was presented as a series of perceived advantages and disadvantages to which the 

drivers could comment or discuss (all of topics had been previously reported on in the OBMS 

literature). 

Overall, all six drivers agreed that onboard driver monitoring and feedback had the potential to 

increase safety; however, they also agreed that being monitored adds stress and there was worry 

about how management would use the data. Two of the participants felt that they were good 

enough drivers that they did not mind a system being on and monitoring them all day long. The 

other four drivers felt some trepidation towards having a system that monitors them, and might 

be more comfortable if the system was only recording data during an incident or if the system 

had an off switch. 

Researchers explored driver support and opposition to the use of a hypothetical monitoring 

system. All of the drivers reported no problems with cameras facing outside the vehicle used to 

capture the forward traffic scene, but at least four of the participants were clearly against the idea 

of having a camera pointed inside the vehicle at them. One of the participants was adamantly 

against placing a camera on the driver, commenting that there was no reason for it and that there 

was a potential for misuse of any data that it collected. 

When asked about adding collision warning devices and real-time feedback to the truck versus 

the fear of adding too many bells and whistles, the drivers were all in agreement with a 

preference for real-time warnings and feedback as opposed to offline or delayed feedback. In 

talking mostly about feedback for “following too closely,” three of the drivers felt strongly that 

the feedback should be visual, while the other three were more undecided. It was mentioned that 

sometimes visual only feedback is not enough and could be missed, but at the same time, the 

truck is a loud environment and with the radio turned up, auditory alerts are not always heard 

either. 

When asked about the benefit of liability protection versus fear of liability, the drivers all agreed 

with both point. The participants pointed out that their current XATA system was already being 

used to exonerate one of their coworkers (and subsequently save his job), who was involved in a 

crash and had been accused of speeding. 

Misuse of Monitoring Data 

One central theme that appeared several times throughout the discussion was the possibility of 

misuse of the monitoring data (specifically video of the driver) both by management and by 

lawyers. The concerns centered around the somewhat flexible interpretation of the data. One 

person may look at the data and interpret it one way, while another may look at the same data 

and interpret it another way. The drivers felt that this second guessing or backseat driving would 

only serve to hurt them. 

65 
The primary concern over management’s misuse of the data centered on job security. The drivers 

expressed concern about what the consequences would be if one of them became fatigued and 

started to nod-off at the wheel or was “distracted” and had an incident. As one driver 

commented, nobody’s perfect 100 percent of the time. It should be noted that most of these 

concerns were raised specifically when talking about the use of cameras aimed inside the vehicle 

at the driver. 

Safety Monitoring Incentive Programs 

Only one out of the six participants thought that a safety incentive program would be effective or 

good for drivers. The sentiments expressed by the other drivers included the following: 

• Driving safety was part of their job and not something you give incentives for. 

• Improved safety was incentive enough. 

• Driving safety keeps them on the job and with a license and that’s incentive enough. 

• A tool to help make sure that they do not hurt anyone else on the road was incentive 

enough. 

Overall, the drivers agreed that a tool that provided instant, real-time feedback in the cab was 

preferable to any incentive-based program that involved management in the feedback process. 

Parallels were also made in the discussion between the carrier’s current fuel economy incentive 

program and the concept of a safety incentive program. The majority of drivers felt that there 

would always be problems with incentive programs, such as the problem of grading everyone on 

a curve (comparing data across drivers in a fleet) and not being able to account for differences in 

the routes (such as traffic). One driver did suggest that any incentive program should look at 

individual improvements over time, rather than averages across the fleet. 

Monitoring Speed 

Based on their experience with the XATA speed monitoring (and governing) system, the 

participants were generally supportive of a system that monitored speed since they perceived that 

their current system kept speeding tickets down. When asked where they thought speeding was 

the most problem, drivers generally answered with on the freeways. Speeding in curves was not 

thought of as a problem for typical or experienced drivers, but might be one way to single out 

unsafe drivers. One of the participants did comment that a curve overspeed warning system that 

provided advanced warning of curves might be helpful at night. 

The participants generally felt that night driving did not affect their speed selection much 

because the decrease in traffic congestion allowed the drivers to travel at the speed limit without 

a problem. Weather was considered a much more important factor. The worst conditions 

reported by drivers were the combination of fog and rain because of the lack of visibility. 

Although the drivers felt that they typically slowed down in the rain, especially when their trailer 

was empty, which was considered more dangerous, they were also quick to point out that no one 

else did. 

High winds and wind gusts were considered the most unpredictable weather hazard, especially 

when the trailer was empty. One driver commented that he might like a system that could 

provide him with wind direction and wind speed. Another driver commented that moving the 

66 
tandems forward was helpful; however, there was little agreement on whether drivers should 

slow down during high winds. 

Following Distance 

Overall, the drivers were receptive to the concept of monitoring following distance, but there was 

little agreement on just how much following distance was appropriate. Answers varied from one 

to three truck lengths depending on speed and traffic conditions. One driver commented that the 

more space you leave, the more opportunity there is for cars to cut you off; however, several 

drivers rebutted this attitude by saying that cars were going to cut them off if they left 10 feet or 

100 feet, so they may as well leave enough room to be safe. Other issues brought up by drivers 

include the following: 

• More cut-ins happened at night 

• A cut-in followed by braking was considered the most obnoxious and dangerous 

maneuver. 

• Vehicles that cut-in do not realize that a stopped truck takes a long time to speed up 

again. 

• Vehicles merging (on ramps) do not realize that trucks usually slow a little, and that the 

merging vehicle should speed up and merge in ahead of them. 

• Trucks have one speed (i.e., they do not accelerate or decelerate quickly) 

All of the drivers seemed to like the concept of a following too closely warning light, and that 

such a system would be the most useful in light or medium traffic at faster speeds 

Lane Changes 

The drivers generally agreed that lane changes were often difficult maneuvers since car drivers 

never want to be behind a truck so they generally will not slow down to let the truck change 

lanes (even when the truck signals). All six of the participants reported that they always used 

their turn signals because truck lane changes needed to be planned well in advance (unlike car 

lane changes which were perceived as more spontaneous). The drivers also agreed that mirror 

adjustment was critical, always taking place before they left the yard, and the only real blind spot 

or problem they had was from cars that would come from two lanes over. Several of the drivers 

had already driven trucks with blind spot warning system, and all of the drivers were generally 

receptive to the concept. 

Driver Distraction 

Only one of the six participants felt that distracted driving was a major problem among truck 

drivers. Most participants felt that distracted driving was more of a problem with the drivers of 

other cars, especially those on cell phones. 

Fatigue and Drowsy Driving 

Fatigue and drowsy driving was considered an important topic by the participants and the main 

points of the discussion are listed below: 

67 
• Fatigue is a problem for all drivers, it can just come up on you without much warning. 

• Getting the proper rest at home is an important way to combat fatigue. 

• Fatigue is common because biorhythms are not always in synch with the work schedule. 

• HOS doesn’t always correlate to fatigue. 

The XATA system already electronically recorded HOS and provided a button for recording 

driver fatigue in the log; however, the participants reacted favorably to the concept of a fatigue 

monitoring and feedback system, especially one that provided feedback in the cab. 

Intersections 

The only problem reported by drivers at intersections was with the unpredictable actions of cars. 

The participants described how car drivers were often impatient at stop signs, and cars would 

often run the stop sign or refuse to yield the right of way to the truck when it was the truck’s turn 

to go. 

Seat Belt Use 

Five out of six drivers reported that they always used their seat belts, while the sixth driver 

reported that he only wore it because enforcement by the CHP was so strict and recanted a story 

about a driver who was involved in a crash and would have died if he had been wearing his seat 

belt. The trucks already came equipped with a standard seat belt warning light, but newer trucks 

have been equipped with orange seat belts to aid CHP with enforcement. 

Overall, the drivers were receptive to the concept of seat belt monitoring. Furthermore, three of 

the participants had a positive reaction to taking random photos to verify seat belt use, while the 

other three had a more neutral response. Interestingly, one driver reported that he was currently 

fighting a ticket given for not wearing his seat belt when he was actually wearing his seat belt, 

and he commented that a seat belt monitoring system would have helped his case. 

Offline Incident Review 

The participants were not very receptive to the concept of postdriving incident review, especially 

if management was involved. The participants were far more interested in real-time feedback and 

tools provided in the cab that could help them detect and correct problems with their driving. The 

general sentiment regarding delayed feedback and incident review centered on the question of 

what was the consequence of negative feedback or how could the information be used against 

them. As an example, if the system detected that the driver was fatigued during part of his run, 

how would it benefit him to know that later and what would be the consequence. Similarly, for 

the case of a hard-braking incident, drivers were concerned over the consequences of the video 

showing that they glanced away from the road for a second right before the incident. 

Relevancy 

This study resulted in the discussion of about 12 major topics regarding onboard driver safety by 

six experienced drivers working for a small- to medium-sized Los Angeles-based carrier. 

Overall, the participants responded positively to the concept of onboard driver monitoring and 

feedback for the purpose of improving safety. Most of the other proposed monitoring parameters, 

68 
speed, following distance, fatigue, lane changes, and seat belt use were well-received by drivers. 

The drivers thought that in-cab systems that could provide real-time feedback for speed, 

following distance, and fatigue would be useful, and there was no opposition to seat-belt and 

HOS monitoring systems. 

The drivers were most positive towards in-cab technologies and displays that could be used as a 

tool to help keep them driving safely. When presented with various scenarios and feedback 

options, the drivers always preferred options that could provide them with in-cab, real-time 

feedback, as opposed to offline or delayed feedback. The drivers made a good point in that 

delayed or offline feedback may come too late for them to really understand the problem and 

modify their driving behavior. 

Although all of the drivers preferred in-cab feedback, there was little agreement on how to best 

provide that feedback. It was not surprising that that the drivers had differing opinions over the 

question of visual versus auditory feedback since the generally accepted answer to that question 

is most often “it depends.” Interestingly, the discussion did suggest that truck drivers might be 

more tolerant of auditory alerts than car drivers tend to be, as the participants made no mention 

of complaints over the auditory speed alert provided by their current XATA system. It is noted 

that to be effective, an auditory alert should be loud enough to be heard over the ambient noise. 

Based on the discussions, the parts of the onboard driver monitoring ConOps that are most likely 

to encounter resistance from the drivers include the use of cameras aimed at the driver and the 

use of offline or delayed feedback. The primary concern over both of these issues was the 

potential for misuse of the collected data, a widely cited institutional concern in regard to 

onboard driver monitoring systems. The participants described two ways in which the data could 

be misused. First, the drivers made an excellent point about the potential for alternate 

interpretations of the collected data and video (i.e., backseat driving or armchair quarterbacking). 

Although the engineers who designed the system might have one intention for the system and 

interpretation of the data, both management and lawyers (in the event of a crash) might each 

make their own interpretation. 

The point made by drivers on the issue of alternative interpretations is not entirely without merit. 

Most of the monitoring parameters that have been proposed in the onboard driver monitoring 

ConOps are, at most, related to increased crash risk; however, crashes are very rare and complex 

events, and their causes are often the subject of much debate. As an example, distraction has 

been cited as cause of as few as 30 percent and as high as 80 percent of crashes. Much of that 

variation comes from the fact that the definition of just what constitutes distraction or inattention 

has not been standardized. Take for instance, the following example in which a truck is 

following a car, and the car signals and merges into a turn lane. Having no vehicle in front of 

him, the truck driver glances away from the road briefly, but returns to find that the car was 

merging back into the trucks path (without checking his blind spot). Depending on how you 

interpret the described incident, distraction may or may not be cited as the cause. 

Even going a step further, most would agree that eyes-off-the-road time is a good indicator of 

distraction, but there is little agreement on a specific maximum eyes-off-the-road time. Some 

might argue 1.5 seconds while others argue 2 seconds, and the results are always subject to 

interpretation. Furthermore, glancing away from the road for more than 1.5 seconds likely occurs 

69 
very frequently without any ill effects, and tasks, such as reading a map to get directions, involve 

distraction from the road, but still amount to a significant part of normal driving. 

The second point the participants made regarding the potential for misuse of monitoring data was 

centered on the potential consequences to the drivers when offline or delayed feedback is 

provided. The drivers generally asked questions such as, “What would be the consequences of 

the feedback report showing that a driver was fatigued during part or all of their trip?” These 

concerns came from both the justified notion that nobody can be perfect 100 percent of the time, 

and a fear that poor reports or several incidents could or would be used against them as cause for 

termination. Although the intention of the driver monitoring and feedback program is to provide 

opportunity for continuous feedback and improvement of driving skills, the concerns over this 

sort of alternate and misuse of the program are valid. 

Along these same lines, the most resistance encountered with any of the proposed monitoring 

parameters came from the proposed use of a driver video camera. The drivers had no issue with 

video taken of the road scene or a camera that simply took still snapshots of the driver to 

determine whether or not he was wearing seat belt; however, cameras that took video during 

incidents were viewed providing too much potential for misuse. 

Although both of the points made by the participants (the potential for alternative interpretation 

and the potential for misuse of the data) held merit, recent research does corroborate the validity 

and usefulness offline or delayed feedback and incident review. While a single incident or nearcrash might not indicate an increase crash risk, the recent 100-car study found that patterns of 

frequent incidents and near-misses were indeed indicative of increased crash risk (Klauer, et al., 

2006). 

References (Section 2.6) 

Klauer, S., Dingus, T., Neale, V., Sudweeks, J., and Ramsey, D(2006) The Impact of Driver 

Inattention on Near-Crash/Crash Risk: An Analysis Using the 100-Car Naturalistic Driving 

Study Data (DOT HS 810 594) Washington, D.C.: National Highway Traffic Safety 

Administration (NHTSA). 

70 
4. PROTOTYPE SYSTEM 

The OBMS prototype system was designed in accordance to the systems engineering process 

described in Appendix A and, in particular, with the vee diagram methodology. This entailed 

development and use of a ConOps-derived set of requirements (given also in Appendix A), 

which addressed the 11 feature set recommendations discussed in section 2.0 and listed in 

section 2.5. Because of their central role in specific OBMS prototype discussed in this section, 

these 11 monitoring task recommendations bear repeating: 

1. Monitoring Vehicle Speed 

2. Monitoring Following Distance 

3. Monitoring Attention 

4. Monitoring Hard-Braking Incidents 

5. Monitoring Lane Position 

6. Monitoring Lane Changes 

7. Monitoring and Recording Incidents 

8. Monitoring Fatigue 

9. Monitoring HOS 

10. Monitoring Behaviors at Intersections (which, again, is beyond current technology; 

however this task monitoring category warrants discussion for the long term when it may 

become practicable) 

11. Monitoring Other Vehicle Parameters (e.g., safety belt use, lane change turn signal use, 

lane change blind spot check, proper mirror adjustment, fuel economy, engine overspeed, 

acceleration, deceleration, gear selection on grades) 

This section concentrates on the implementation of the sensor and data recording requirements. 

Software and algorithms for event detection implemented in the prototype are described in 

section 5, and prototype driver feedback mechanisms are described in section 6. Specifics of this 

system are provided in the ensuing subsections as follows: 

• Overview of prototype implementation 

• Hardware layout and operating principles 

• Software building blocks and interfaces 

4.1. OVERVIEW OF OBMS PROTOTYPE IMPLEMENTATION 

A detailed block diagram of the OBMS prototype is shown in Figure 7.The onboard 

processor/core unit is implemented in the OBMS prototype as a PC104 Plus stack, containing the 

cards shown in Table 23. Component Cards of OBMS Prototype PC104 Onboard Processor. This 

computer records the output from a variety of sensors onto its hard drive and drives a display for 

driver feedback, as well as implementing onboard real-time monitoring algorithms. 

71 
Front radar 

Lidar 

Road surface

SAE J1939 

(RS232 to CAN) 

SAE J1587 

(RS232 to RS485) 

Rate gyroscope 

Lane tracker 

Serial Interface 

Sensors 

Processor 

Board 

Serial 

Expansion 

Card 

A/D 

Converter 

Card 

Digital I/O 

Card 

MPEG 

Encoder 

Card 

Hard drive

PC104

2

8

RS232 

connections 

Video out

Driver 

Feedback 

Display

Ethernet

Turn Signals 

Side Radar 

Mirror Adjust 

Seat Belt Sensor 

Digital Input 

Signals 

NAVTEQ 

laptop 

Steering Angle 

Potentiometer 

Brake Pressure

Accelerometer 

Analog Input 

Signals 

Cameras Video In

Figure 7. OBMS Prototype PC104 and Sensor Interfaces 

The environmental sensors and inputs to the computer include a frontal radar, frontal lidar, side 

radar, lane tracker, road surface state detection system, frontal camera, and GPS vehicle sensors, 

including steering wheel angle, gyroscope, brake pressure, and an accelerometer. Vehicle 

parameters, such as vehicle speed and cruise control, are acquired from the J1939 and J1587 

vehicle data buses, and direct connections to truck electrical signals, such as turn signal 

activation, are also connected as digital inputs. In addition, the two video cameras capture the 

forward road scene and passenger compartment of the truck. Hardware identification and brief 

descriptions of these sensors are given in Table 24. Sensor Systems and Data Sources of OBMS 

Prototype. 

72 
Table 23. Component Cards of OBMS Prototype PC104 Onboard Processor 

Component Qty Make/Model No. Function 

Processor Board 1 Advanced Digital Logic 

Pentium M 1.4 GHz 

Includes two serial ports and 

Ethernet connection as well as 

graphics display card 

Hard drive 1 Desktop Hard Disk Drive Software installation and data 

recording 

Serial Port Expansion Card 1 Connect Tech Xtreme/104 Adds serial ports to the PC 

Analog Digital Converter Card 1 Diamond Systems Corp 

DMM-32X-AT 

Inputs analog signals to the PC 

Digital Input-Output Card 1 Diamond Systems Corp 

DMM-32X-AT 

Inputs digital signals to the PC 

MPEG Encoder 1 Advanced Micro Peripherals 

MPEG44000-4 

Converts video to MPEG-4 

format files 

Table 24. Sensor Systems and Data Sources of OBMS Prototype 

Component Qty Make/Model No. Function 

Card or 

Bus 

Forward radar 

sensor 

1 Eaton-Vorad EVT-300 Range, rate and angle to nearby 

obstacles 

RS232 

Side radar sensor 1 Eaton-Vorad EVT-300 Presence of obstacles at side RS232 

Lidar 1 Nippon-Denso Prototype 

Lidar 

Range, rate and angle to nearby 

obstacles 

RS232 

Lane Tracker 1 Assistware SafeTRAC Measure vehicle position in the 

lane 

RS232 

Road Surface 

Sensor 

1 Innovative Dynamics Inc, 

RoadSight Mobile 

Detect presence of road 

contamination 

RS232 

SAE J1939 CAN 

bus 

1 B&B Electronics 1939STB Converts SAE J1939 data bus to 

RS-232 

RS232 

SAE J1587 CAN 

bus 

1 B&B Electronics 232SAER Converts SAE J1587 data bus to 

RS-232 

RS232 

Rate gyroscope 1 Crossbow VG400 Measures vehicle rate of pitch, 

yaw, and roll and pitch angle 

RS232 

Steering Angle 

Potentiometer 

1 Ametek PSS-40A Measure steering wheel angle A/D card 

Accelerometer 1 Summit 23203a Bi-axial 

Accelerometer 

Record vehicle acceleration A/D card 

Brake Pressure 1 AST4000 Measure applied brake pressure A/D card 

Video cameras 2 Visiontech 1/3” color CCD 

Minivision camera 

Video cameras Video 

card 

NAVTEQ System 1 NAVTEQ ADASRP GPS location, road curvature, 

speed limits 

Ethernet 

73 
While Figure 7, Table 23, and Table 24 highlight the OBMS prototype hardware installation, 

Table 24, and Table 25 show the relationship of these hardware components to the requirements 

in Appendix A. Table 25 shows the correspondence between the COTS sensor requirements of 

Appendix A and the OBMS prototype components. Table 26 shows the sensors used as a data 

source for the driving parameters that is to be monitored on a continuous basis. 

Table 25. Sensor Requirements and Corresponding OBMS Prototype Components 

Sensor ID OBMS Prototype Component Message 

Length 

(Bytes) 

Update 

Period 

(ms) 

S1 Accelerometer Summit 23203a Bi-axial 

Accelerometer 

N/A 37.5 

S2 Driver ID reader Eaton Vorad EVT 300 driver ID 

message 

3-13 10,000 

S3 Electronic Onboard 

Recorder (EOBR)/HOS 

Calculated from driver ID and 

engine speed in prototype 

(Expected to be via COTS system 

in subsequent versions.) 

N/A 10,000 

S4 Front radar/warning 

system 

Eaton Vorad EVT 300 4-60 65.536

S5 GIS roadway map NAVTEQ ADASRP variable 1,000 

S6 GPS receiver NAVTEQ ADASRP 24 1000 

S7 Lane position monitor Assistware SafeTRAC 39 500 

S8 Outward video camera Visiontech 1/3” color CCD 

Minivision 

N/A N/A 

S9 Road surface conditions 

sensor 

Innovative Dynamics Inc 

RoadSight Mobile 

variable 1000 

S10 Rollover sensor Calculated from Gyro and 

NAVTEQ data 

N/A 50 

S11 Side radar Eaton Vorad EVT300 N/A 37.5 

S12 Steering angle sensor AmetekPSS-40A N/A 37.5 

S13 Thermometer None 

S14 Throttle angle sensor Equivalent information from J1939 

EEC2 

28 50 

S15 Wheel speedometer From J1939 CCVS 40 100 

S16 Wiper usage monitor None N/A 

S17 Brake pressure monitor AST4000 N/A 37.5 

S18 Mirror adjustment 

monitor 

Custom add-on signal N/A 37.5 

S19 Turn signal monitor Custom add-on signal N/A 37.5 

S20 Seat belt usage monitor Custom add-on signal N/A 37.5 

S21 Driver camera Visiontech 1/3” color CCD 

Minivision 

N/A N/A 

74 
Table 26. Driving Parameter Requirements and OBMS Prototype Data Source 

Parameter ID OBMS prototype data source 

P1 Driver 

identification 

Eaton Vorad EVT300 driver ID message 

P2 Following 

distance 

Eaton Vorad EVT300, Nippon Denso prototype lidar 

P3 HOS Not directly available from vehicle bus, but is derived in prototype 

(expect to use one of several available COTS systems in subsequent 

versions) 

P4 Lane position Assistware SafeTRAC 

P5 Road surface 

conditions 

Innovative Dynamics Inc, RoadSight Mobile 

P6 Roadway 

curvature 

NAVTEQ ADASRP 

P7 Roadway 

scenery 

Video 

P8 Seat belt usage Custom digital input 

P9 Vehicle location NAVTEQ ADASRP 

P11 Speed J1939 CCVS message 

P12 Brake pressure AST4000 

P13 Steering angle AmetekPSS-40A 

P14 Occupancy of 

side lane 

Eaton Vorad EVT300 

P15 Turn signal use Custom digital input signal 

4.2. HARDWARE LAYOUT AND OPERATING PRINCIPLES 

In developing the OBMS prototype, a driving factor in the hardware selection was to consider 

elements that could, with perhaps minimal adaptation of substitution, be used in a subsequent 

larger-scale FOT. The Freightliner tractor used for the OBMS prototype is pictured in Figure 8. 

The data recording computer and all associated hardware are mounted in the sleeper portion of 

the cab. 

75 
Figure 8. Freightliner Tractor Platform Used for 

OBMS Prototype System 

The sensor data is recorded using an industrial PC104 Plus computer with ISA/PCI architecture 

and a 1.4 gigahertz Pentium M PC running the Linux 2.6 operating system installed from the 

Kubuntu 5.10 distribution. It uses a serial port expansion card, an analog-to-digital and digital-toanalog converter card, and a MPEG encoder card all mounted internally to read the sensors and 

various inputs. All the analog voltage signals are anti-alias filtered before being input to the 

analog to digital converter card. All the sensors attached to the serial expansion board 

communicate with the RS232 protocol. This computer records the output from the sensors onto 

an internal 100 gigabyte hard disk drive. A picture of the installed computer system is shown in 

Figure 9. 

76 
Figure 9. Computer and Associated Electronics 

The sensors selected to capture the environment around the truck include the commercially 

available Eaton-VORAD EVT-300 mono-pulse millimeter wave radar. This radar unit, on the 

front of the vehicle, measures the distance and azimuth angle for multiple targets up to a distance 

of 100 meters in front of the vehicle. This unit is mounted in the center of the front grill and was 

installed by Freightliner as an option when the truck was built. Included in the EVT-300 system 

is a simpler radar unit mounted on the right side of the vehicle that only registers the presence or 

absence of an obstacle in the adjacent lanes, and does not provide distance or azimuth 

information about the obstacle. This sensor is mounted on a side fairing of the truck behind the 

passenger door. Also included in the system are the driver display units mounted in the view of 

the driver for the front and side radars as well as a system CPU. 

Also mounted on the vehicle is a prototype Nippon-Denso mechanically scanning infrared lidar. 

This unit also measures the distance and azimuth angle for multiple targets up to a distance of 

100 meters in front of the vehicle. This unit is also mounted in the center of the front grill. The 

radar and lidar are shown in Figure 10. 

77 
Figure 10. Radar and Lidar Sensors 

Another sensor fitted to the truck, the Assistware SafeTrac, is a video-based lane detection 

system (lane tracker). This system finds the lane boundaries of the lane the truck is traveling in 

and measures the position of the truck within the lane. The camera for the lane tracker is 

mounted near the windshield and the control unit is mounted on top of the instrument panel in 

the view of the driver. 

An Innovative Dynamics Inc., RoadSight Mobile off-the-shelf road surface state detection 

system was also installed on the truck. This system detects whether the road is dry, wet, snowy, 

or icy. The system bounces two infrared lasers off the road surface and detects the spectral 

differences of the road surface and possible road surface contaminants. The sensor head for this 

unit is mounted on the passenger side of the cab above the passenger door. The control 

electronics are mounted in the cab above the passenger seat. This sensor is pictured in Figure 11. 

78 
Figure 11. Road Surface Detection System Sensor 

The vehicle is also equipped with a NAVTEQ Advanced Driver Assistance Systems Research 

Platform (ADASRP) GPS. This system is composed of GPS processor, gyro, and vehicle speed 

and backing status inputs mounted in an enclosure called a NAVTEQ box. The NAVTEQ box 

sends data to a laptop running the ADASRP software. This software performs map-matching 

using the GPS and the gyro and vehicle transmission inputs to calculate dead-reckoning during 

GPS outages. The ADASRP sends vehicle location information as well as information about the 

road ahead and the local speed limit to the PC104 computer. These units are mounted in the rear 

of the cab and the GPS antenna is mounted on top of the cab. 

Other sensors record the driver inputs to the truck. The hand wheel angle is measured with a 

string potentiometer. This string potentiometer is mounted in the engine compartment as shown 

in Figure 12. The string is attached to the steering column. As the steering column rotates, the 

string wraps or unwraps around the column, depending on which direction the steering wheel is 

turned. 

79 
Figure 12. Steering Wheel Angle Sensor (String Potentiometer) 

A gyroscope and analog accelerometer are mounted in a weather-proof enclosure on a frame rail 

near the 5th wheel hitch plate, depicted in Figure 13. The gyro is a Crossbow VG400 tri-axial 

fiber optic rate gyro with tri-axial accelerometers. The analog accelerometer is a Summit 

Instruments 23203B bi-axial MEMS accelerometer with a 1g range. 

Figure 13. Rate Gyro and Accelerometer Enclosure (Opened) 

The brake pressure applied by the driver is measured with a pressure transducer. The American 

Sensor Technology AST4000 pressure transducer is plumbed into the brake system on the left 

front brake actuator as shown in Figure 14. 

80 
The engine SAE J1939 and SAE J1587 data buses are also monitored on the truck. Data such as 

throttle position, wheel speed, and cruise control status are recorded on these data buses. 

Turn signal and mirror adjustment usage are determined by connecting four computer digital 

inputs to the respective power relays on the truck. 

Figure 14. Brake Pressure Transducer 

Also mounted on the truck are two CCD “board” cameras. These cameras are mounted behind 

the windshield in a small enclosure. One camera looks at the forward road scene and the other 

camera looks at the driver. The video streams from these cameras are connected to an MPEG 

encoder card in the computer. The computer then writes the MPEG files to the hard disk drive. 

Also mounted in the camera enclosure is the camera for the lane tracker. The enclosure is shown 

in Figure 15. 

The system is powered from the vehicle battery and charging system. All cabling and most 

sensors are installed behind trim panels and fascias. Thus, the truck looks like a normal truck, not 

a research vehicle. The only obviously visible component is the camera housing for the cameras. 

81 
Figure 15. Camera Enclosure 

4.3. SOFTWARE BUILDING BLOCKS AND INTERFACES 

In keeping with the system requirement for modular software design, the OBMS prototype 

software makes heavy use of reusable software components developed at PATH during previous 

Caltrans projects, as well as using drivers supplied by the manufacturers for COTS systems. 

Without the availability of this preexisting software it would have been impossible to implement 

a functioning OBMS prototype with the limited time and resources available. Preexisting PATH 

software components included processes to interpret the Eaton Vorad EVT 300, Nippon Denso 

Prototype Lidar, SafeTRAC Lane Tracker, and NAVTEQ ADASRP message formats, as well as 

a the SAE J1939 and SAEJ1587 in-vehicle data bus formats. Integration of these processes with 

the new drivers was facilitated by the use of a publish/subscribe in-memory database for 

interprocess communication. This publish subscribe applications programming interface (API) 

has been used at PATH for a number of years on the QNX4 and QNX6 operating systems and 

was ported to Linux last year for the use of this and other projects. 

Software has been written to read and record all the data from the sensors described in section 

3.2 and to make it available to applications that identify significant driver behavior and events 

and issue feedback, as described in sections 5 and 6. In the following subsections we will give 

more detail about: 

Software architecture, including the publish subscribe database 

Software for serial interface devices (EVT300, Nippon Denso Lidar, J1939, J1587, Crossbow 

Gyro, Roadsight, SafeTRAC) 

Software for communicating with NAVTEQ ADASRP over Ethernet 

82 
DMM32 device driver and analog and digital input issues 

Video recording software 

4.3.1. Software Architecture 

The OBMS real-time software may be roughly divided into three types of processes that 

communicate using the publish/subscribe API through a memory-resident data server: 

• Device resource managers that interface directly with the hardware and supply sensor 

inputs to the data server 

• Analysis programs that extract filtered event and driver behavior information from the 

raw sensor inputs and write this processed information to the data server 

• Notification and recording programs that may use any information available from the 

data server to provide feedback through the graphical user interface and that save selected 

data for later analysis and feedback 

The interaction of these three types of clients with the publish/subscribe data server is 

graphically illustrated in Figure 16. 

83 
Figure 16. Publish and Subscribe Data Clients in OBMS Prototype 

Device clients are on the left of the dataflow diagram; the arrows showing the direction of the 

data are labeled with the data structure type carrying that data. The data processing module on 

the right processes the raw data and writes the processed data to the data server. The DVI reads 

and displays both raw and processed data. 

All three types of processes operate as clients of the publish/subscribe data server, which allows 

client processes to create, read, and write variables of structured types, as well as to subscribe to 

a notification service indicating when a particular variable was updated. These notifications are 

called triggers and can be seen as messages that are sent to the client process from the database. 

The publish/subscribe data server framework is modular, generic, and inherently asynchronous 

(producers and consumers need not know about each other and can run at different rates). It has 

84 
been used successfully in many different PATH applications, including car-platooning, as part of 

the Automated Highway Systems project, and car longitudinal and lateral control, truck, bus, 

snowplow, and automated ship applications. The data server provides asynchronous interprocess 

communication in the sense that a process can write a database variable without worrying who 

the potential consumers might be or at what rate they read the data. 

In summary, the publish/subscribe API contains primitives to: 

• Register/log out of the database 

• Create/destroy a database variable of a specified number of bytes 

• Read a variable 

• Write a variable 

• Set/unset triggers for variables 

These requests are atomic, which means that the database will completely serve a request before 

it proceeds with the next request (that is, the database serializes the requests). Atomicity ensures 

database integrity, which means that the value read by a client is not modified during the reading 

process and that the most recent value of a variable is always made available. 

The publish/subscribe API can be easily ported as an easy-to-use layer for user-level processes 

on top of lower level interprocess communication primitives. On QNX the publish/subscribe API 

was based on kernel-level message passing. On Linux it uses Posix message queues to provide 

data sharing while maintaining data integrity and avoiding race conditions. 

4.3.2. Software for Serial Interface Devices 

Database clients for the various serial devices were constructed similarly: each logs into the 

database, creates its own database variables, and opens a connection to a serial port. The client 

then enters an infinite loop: it reads serial data as it comes into the port, parses the message into 

usable data, and writes the data to the database. Clients differ in the message format, message 

content, and may poll the device (infrequently) in addition to receiving a data stream. 

85 
The following is a synopsis of the serial port clients: 

1. Eaton-Vorad Radar: The client parses three different messages from EVT–300. They 

are: 

– Driver Display Unit (DDU) Display Update Message: proximity warnings, message 

length 4 bytes, update period 250 ms or 65.536 ms for one second on change 

– Front-end Target Report Message: range and relative velocity, message length 4–60 

bytes, depending on number of targets acquired, update period 65.536 ms 

– DDU Driver ID Data Message: driver ID, message length 3–13 bytes, depending on 

length of user-selected ID, polled data, update period 10 seconds 

This client was ported from QNX 6 to Kubuntu 5.10. 

2. Nippon Denso Lidar: The lidar message is 146 bytes long, containing a 3-byte header 

(0xFF 0xFF 0xFD) and a checksum in the last byte. The payload is data for up to eight 

targets. Each target has the following fields (all are relative to the subject vehicle): lateral 

position, vertical position, distance, lane rate, vehicle rate, target status, lateral velocity, 

width, height, depth, and relative acceleration. This client was ported from QNX 6 to 

Kubuntu 5.10. 

3. J1939/J1587: The CANbus messages important to this project are: 

a. J1939 

– CCVS (Cruise Control Vehicle Speed), containing the wheel-based vehicle speed, 

message length 40 bytes, update period 100 ms 

– EEC2 (Electronic Engine Controller #2), containing accelerator pedal position, 

message length 28 bytes, update period 50 ms 

b. J1587 

– 183 (Fuel rate), update period 200 ms 

– 190 (Engine speed), update period 100 ms 

4. Crossbow Gyro: The message from this device is 22 bytes long, containing ten 2-byte 

measurements of angle, angular rate, acceleration, temperature, and time. It contains a 

header byte (0xFF), and a checksum byte at the end. The update rate is 75 Hz. 

5. Roadsight: This device uses two infrared lasers of different wavelengths to detect road 

condition (dry, wet, snowy, icy), the message is variable-length ASCII, and the update 

rate ~1 Hz. This device outputs an ASCII string, terminated by a newline, containing 

eight values: short wavelength voltage, long wavelength voltage, temperature (the 

temperature option is not installed, so this value is undefined), ratio of the voltages, 

displayed condition code number (0–15), measured condition code number (0–15), 

displayed condition mnemonic (3 characters), and measured condition mnemonic (3 

characters). 

6. SafeTRAC Lane Tracker: The message from this device is 39 bytes long and update 

rate ~2 Hz. The message header is two bytes long (0x5A 0xA5), and a checksum is at the 

86 
end. The message contains the fields: lateral offset, lateral velocity, road curvature, lane 

width, left and right boundary types, offset confidence, curvature confidence, driver 

alertness index, and alert system status. 

4.3.3. Software for Communicating with NAVTEQ ADASRP over Ethernet 

The NAVTEQ COTS software resides on a laptop and communicates to the PC104 via Ethernet. 

It transmits three message types of interest to this project: 

0x403: latitude, longitude and distance traveled since the last transmission 

0x501: current speed limit 

0x502: projected road curvature information ahead of the vehicle 

The client is started up with two arguments: the IP address of the NAVTEQ laptop, and the port 

that the laptop will be using to communicate. Once the connection is established, the client waits 

for a data stream over the socket pair. When data starts coming in, the client searches for the 

header [0x64, 0x19, 0x11, 0x29] and then begins reading data. This client was ported from QNX 

6 to Kubuntu 5.10. Changes to the original code were: 

Task QNX Linux___________ 

login to the data server: getnid() (QNX) → gethostbyname() (Linux) 

transport: COMM_QNX_XPORT → COMM_PSX_XPORT 

call to localtime(): _localtime → localtime_r 

In order for the NAVTEQ COTS has to work, the vehicle must begin moving for it to begin 

outputting data over the Ethernet port. Moreover, it only works for Windows OS, which may 

cause it to occasionally crash. 

4.3.4. DMM32 Device Driver and Analog and Digital Input Issues 

The Diamond Systems DMM32 provides 32 single-ended, 16-bit resolution analog-to-digital 

inputs, 24 digital I/O lines, and four 12-bit resolution digital-to-analog outputs. The update 

period is 37.5 ms. 

The analog inputs are as follows: 

• Brake pressure transducer: AST4000, used in determining hard-braking events 

• Steering angle potentiometer: AmeTek PSS-40A, used in determining hard-steering 

events 

• Accelerometer: The Summit 23203a puts out two analog signals, namely x and y 

accelerations. Its calibration sheet gives the sensitivity of each voltage along its own axis 

and along the other axis. That is, there is “cross-talk” between the two sensors. Thus the 

“true” acceleration for each axis is calculated from a linear equation using the 

87 
coefficients given in the calibration sheet. Voltage offsets are zeroed by measuring the 

voltages when the vehicle is stopped, and subtracting them from subsequent 

measurements. 

The digital inputs are listed below. These devices are actually read as analog signals and their 

values compared to their respective thresholds A “1” means “TRUE” and a “0” means FALSE. 

• Turn signals 

• Mirror adjustments 

• Radar side sensor 

• Seat belt use 

4.3.5. Video Recording Software 

The OBMS video recording software stores video clips (from two separate sources, one for the 

driver and the other for the front-view) before and after a given event signal. The event signal is 

sent through the database. The video clip contains the video of at least two minutes prior to the 

event. Example snapshots from the video event recorder are shown in Figure 17 and Figure 18. 

Figure 17. Forward Road Scene: Single Car 

88 
Figure 18 Forward Road Scene: Multiple Cars 

The system requires four video inputs (A,B,C,D) where A and B are from one video source 

(which requires a video splitter) and C and D from the other. 

The video recording software receives two signals, sync (or timer) and event, through the system 

database. The sync signal comes with sync information, which is used to define the filename. 

The filename convention follows the usual PATH sensor recording filename convention, 

vmmddsss-n.mpg, where: 

mm = month (2 digits) 

dd = day of the month (2 digits) 

sss = sequence number (3 digits) 

n = video input (1 or 2) 

Examples would be v1203004-1.mpg or v0123051-2.mpg. 

Given a sync signal, the software starts recording two video clips (one for A or B and the other 

for C or D). The recording is alternative. For one sync signal, the video from A and C are 

recorded and for the next signal, the video from B and D are recorded. The recording ends with 

the 2nd sync signal from when it started. Therefore, the two consecutive video clips will overlap 

with each other. For example, the timeline for the video clips taken on 12/3 is as follows: 

89 
A : | v1203000-1.mpg | v1203002-1.mpg ... 

B : | v1203001-1.mpg | v1203003-1.mpg ... 

C : | v1203000-2.mpg | v1203002-2.mpg ... 

D : | v1203001-2.mpg | v1203003-2.mpg ... 

Sync: ^ ^ ^ ^ ... 

Evnt: ^ 

Normally, the sync signal will be sent in every two minutes, with the same sync applied to other 

engineering data such as lidar. Therefore the length of the usual video clips is be four minutes. In 

order to save disk space, not all the video clips will be stored to save the disk space; rather, only 

the video clips around the event signal will be stored to hard drive. 

At all times, two overlapping copies of video clips are recorded. For example, when an event is 

triggered, both v1203002-1.mpg and v1203003-1.mpg are being recorded (for camera #1). The 

previous one (v1203002-1.mpg) is always 2 minutes longer than the new one (v1203003-1.mpg). 

When an event signal is triggered, the longer video clips (v1203002-1.mpg) are stored in the 

hard drive. As a result, whenever an event occurs, the stored video clip contains at least two 

minutes of video prior to the event. The recording finishes at the next timer signal. The 

engineering software therefore sends the next timer signal two minutes after the event signal. 

90 
5. OBMS FUNCTIONS 

5.1. TRUCK FOLLOWING/STOPPING ALGORITHM DEVELOPMENT 

5.1.1. Introduction and Motivation 

Per section 2, monitoring vehicle stopping distance as the criterion for truck following distance 

may be one way to mitigate truck-involved vehicle crashes. The vehicle stopping distance is 

determined by several factors: current speed, braking system retardation force, tire slip, and road 

grade. For truck onboard monitoring and real-time feedback to the driver, it is necessary to know 

at anytime the appropriate stopping distance. Data available in literature only shows the stopping 

distance information on flat, dry and concrete road surface conditions. In practice, trucks are 

driven under variable environments. In the OBMS project, practical implementation issues in 

addressing real-world, heterogeneous environments and a multiple-aspect algorithm were 

implemented. 

Truck OBM longitudinal (following and stopping) algorithm development includes the following 

aspects, which are detailed in the following subsections: (i) truck stopping distance under 

variable weather and road geometric conditions; (ii) front multiple target tracking and relative 

distance and speed estimation; (iii) recommended following distance under variable conditions 

such as weather and road situation; (iv) recommended speed under similar variable conditions; 

and (v) the human factor. The combination of all five aspects is a unique feature of this 

algorithm, resolved in the OBMS project with an underlying multiple-aspect algorithm described 

in this section. 

Points (i), (iii), and (iv) are closely related to truck dynamics, road geometry, and weather. Truck 

dynamics itself is very complicated if coupled with weather and road geometry. This OBMS 

study considers the problem with a pragmatic, limited basis, aimed at prototype development. 

Front, multiple-target tracking using vehicle onboard remote sensors are the key for threat 

assessment of potential collisions between vehicles. For OBMS, a tracking algorithm was 

developed for three potential front targets: target on the left, middle, and right lanes. Other 

targets beyond the three lane-widths are ignored. 

In the OBMS work, the road curvature effect on target tracking is not considered due to the 

aforementioned pragmatic, limited prototype development scope of the project. This means that 

it is implicitly assumed that the freeway is straight ahead. There were many ways for assessing 

the threat of potential collision between vehicles. Basically, it is determined by relative distance, 

speed, and acceleration. Relative distance and speed could be determined by remote sensors of 

target tracking if well-built; however, relative acceleration would be very difficult to estimate in 

real-time. Thus, target tracking is usually accompanied by relative distance and speed estimation 

for the targets tracked. 

Using vehicle stopping distance as the criterion for truck following distance may be one way to 

mitigate truck-involved vehicle crashes. Vehicle stopping distance is determined by several 

factors: current speed, braking system retardation force, tire slip, and road grade. For truck on91 
board monitoring and real-time feedback to the driver, it is necessary to know at anytime the 

appropriate stopping distance. All the previous data available in literature only proved partially 

the stopping distance information on flat, dry and concrete road surface conditions 

The recommended following distance is less conservative than the truck stopping distance if the 

front target is moving. Such a distance is determined by threat assessment for vehicle frontcollision and avoidance, which is determined mathematically by relative speed, relative 

acceleration, and reaction time from a kinematics viewpoint. However, the relative acceleration 

is difficult to measure with current technology. Thus, the worst case scenario of relative 

accelerations (i.e., the potential deceleration capability and front target and maximum 

deceleration capability of the truck) are selected as constants. Although the implementation of 

the recommended following distance does not incorporate variable environmental conditions, 

such as road grade and tire slip, it is important to take them into consideration in any on-road, 

operational implementation. The analysis method for any future implementation will be similar 

to that for considering vehicle stopping distance under variable conditions. 

Speed is another important factor for truck safety. High speed (as discussed in section 2.0) not 

only causes threats to other vehicles, but also causes instability of truck itself, such as rollover. It 

is thus necessary to provide a recommended speed. Several factors would affect the 

recommended speed: (1) speed limit of the road, (2) speed determined by rollover stability 

threshold, (3) traffic speed in adjacent lanes, (4) road geometry, such as curvature and grade, (5) 

weather conditions (tire slip), and (6) a combination of all. Due to limited time, resources, and 

pragmatism, this effort considers the first four factors. 

Rollover for a large commercial truck with a tractor and trailer combination is a very 

complicated problem which involves vehicle dynamics, road geometry, and weather (tire slip). 

This project, based on previous study and experience in vehicle dynamics, has preliminarily 

implemented a Three-Step Progressive Rollover Warning (feedback): (1) on approaching curve: 

prediction using vehicle lateral acceleration based on road curvature data and GPS position from 

the NAVTEQ system and vehicle speed and (2) on the curve: prediction using vehicle lateral 

acceleration and truck speed based on real-time. 

5.1.2. Vehicle Stopping Distances Under Different Conditions 

This section is to discuss the effect of other physical factors on vehicle stopping distance. For 

this project, physical factors were defined as all factors not related to driver behaviors. The most 

obvious physical factors include: vehicle load, road surface conditions, road grade, vehicle 

speed, and the combination of them all. 

The following notations are used for discussion in this section: 

M − vehicle mass 

D0 – required stopping distance on flat road 

Dθ – required stopping distance on graded road with grade θ

0 v − vehicle initial speed (longitudinal) just before braking 

92 
θ − road grade, θ > 0 means ascending; θ < 0 means descending 

g – acceleration of gravity 

μ – friction coefficient 

Ftrac – total traction force of all the wheels 

N f – normal force of all the wheels 

Tb – total braking torque on wheels from braking system 

( ) a Tb – braking torque on wheels contributed by air brake 

( ) e Tb – braking torque on wheels contributed by engine brake 

( )t Tb – braking torque on wheels contributed by transmission retarder 

w d – wheel effective radius 

The unit system used is k-s-m. 

Vehicle Load 

It seems obvious that vehicle load would affect the vehicle stopping distance a lot; however, the 

following analysis indicates that this is not the case. 

Vehicle kinetic energy stored at the time instant of braking is 

2

0 2

1 Mv

To bring the vehicle to completely stopped, the work done by the traction force of the braking 

system (pneumatic brake, engine brake, and transmission retarder) should be equal to this 

number. This is the first of the following equations. 

( )

2

0

( ) ( ) ()

2 stop trac

trac f

aet

bb b b

trac w b

D F Mv

F N

TT T T

Fd T

μ

=

=

= ++

≤

1

The second equation just says that the traction force is proportional to the normal force from the 

vehicle to the ground. The third equation says that the braking torque is from three components: 

pneumatic brake, engine brake, and transmission retarder. The last inequality is an assumption 

that the effective braking torque the traction force could provide cannot exceeds the braking 

torque provided by the braking system. In other words, the braking system has adequate 

retardation force compared the traction between the wheels and road surface. This assumption is 

reasonable for healthy braking system satisfying the FMVSS (Dunn and Hoover, 2004). 

93 
Now since Ftrac f = = μN Mg μ , the second equation above becomes 

2

0

2 stop

Mv D Mg μ =

Or simply, 

2

0

2 stop

v D g μ = , 

which suggests that as long as the braking system has adequate retardation force on wheels, 

vehicle stopping distance is independent of vehicle load. If this assumption is not true, then for 

the same vehicle, more of a load would require longer stopping distance. 

What is the number in practice? Table 27 includes the stopping distances, compiled by the 

Frederick County Highway Safety Task Force (http://www.xecu.net/hwysafety/ 

nozone.html#table), which roughly gives a relationship with vehicle mass on flat road. 

Table 27. Average Total Stopping Distance Versus Weight 

Passenger 

Car 

TractorTrailer, 

Cab Only 

TractorTrailer 

Empty 

Tractor-Trailer 

Loaded With 

Cool Brakes 

Tractor-Trailer 

Loaded With Hot 

Brakes 

Stopping 

distance, in [m] 58.8 74.1 75.9 78.03 131.06 

The main point here is that the stopping distances for cab only, empty tractor-trailer combination, 

and fully loaded truck do not have much difference; however, the heavier loading would require 

slightly longer stopping distance. 

It is noted that the last column is the case when the air brake is hot, for example, after long 

period of braking. In this case, the retardation force of the brake could significantly reduce and 

the required stopping distance would be longer; however, properly combining engine brake and 

transmission retarder to reduce the use of air brake for continuously braking for a long period of 

time could reduce brake temperature and compensate for this. Thus, the hot brake case will not 

be discussed separately. 

Weather (Road Surface) Conditions 

The weather condition affects the vehicle stopping distance through the road surface condition or 

the weather affect the tire slip μ . Tire slip is very complicated, which depends on several 

factors: material, stiffness and trade types and depth. This means that different tires with the 

same normal force would generate different traction force. To practically simplify the discussion, 

it is assumed that the trade and material meet the standard, and their differences between tires are 

ignored. 

94 
Most previous work considers truck and other vehicle stopping distance on a dry flat road. When 

weather factors are taken into consideration, the suggested truck stopping distance may not be 

applied to the corresponding driving situation. This is due to the fact that rubber tire vehicles 

have different friction coefficients when the road surface condition changes. 

The tire slip coefficient μ depends on the tire characteristics (material, trade, stiffness), road 

surface conditions (Nishira, Kawabe, and Shin, 1999): 

• Assumption 1: The vehicle will remain on road and continue in a longitudinal motion 

without lateral slippery. 

• Assumption 2: The road surface is either concrete or asphalt. On the other hand, vehicle 

stopping distance represented in maximum deceleration (in an ideal situation, for 

example, dry asphalt or concrete on a flat road) and initial speed is: 

2

0

max 2 stop

v D

d =

• Assumption 3: The vehicle braking system has adequate braking torque. This assumption 

removed the possibility that stopping distance is affected by braking torque. This 

assumption is reasonable since modern trucks use a combined braking system composed 

of engine brake (“Jake brake“), transmission retarder, and pneumatic wheel brake. 

The maximum deceleration max d can be considered proportional to the longitudinal traction 

max r d F = β where β is a constant for given vehicle, but may vary from vehicle to vehicle. Now 

we have: 

22 2

N

00 0

max 222 stop

r f

vv v D

d Fβ βμ ===

For a given vehicle with the same load, β and N f will be the same. The weather dependent 

road surface only affect the slip coefficient μ . For the same initial speed 0 v , the stopping 

distances ( )i ,( 1,2) D i stop = of the same vehicle in weather conditions 1 and 2 have the following 

relationship: 

2

0

(1)

1 2

(2) 2

0 1

2

2

2

stop f

stop

f

v

D N

D v

N

βμ μ

μ

βμ

= =

where 

2

1

μ

μ may be called relative (to idea road situation) tire slip coefficient. 

95 
Table 28 provides values of μ in different road surface conditions. 

Table 28. Tire Slip Coefficients in Weather Conditions (Flat Asphalt/Concrete Road) 

Weather Condition Dry Wet Heavy Rain Icy 

Tire slip coefficient 0.8 0.53 0.45 0.2 

The research by Dunn and Hoover (2004) studies brake performance in detail for several makes 

on a straight road in different scenarios, including some with brake failures, and the results are 

close to those shown previously in table 26. 

Road Grade Conditions 

Road grade is another factor affecting vehicle stopping distance. This is particularly true for 

heavy vehicles. In general, suppose we are considering the problem in the same road surface 

condition. Intuitively, when a vehicle is going up a hill, required stopping distance is shorter than 

on a flat road. While when a vehicle is going down a hill, the required stopping distance will be 

longer than that on a flat road. Quantitatively, this is considered as follows: the calculation is 

irrespective vehicle mass and the types of vehicles. Thus, the results can be used for any vehicle. 

Suppose the road surface condition is the same for flat and graded roads. Then friction 

coefficients are the same for a flat road and for a graded road. For a flat road, stopping distance 

can be calculated as follows: 

2

0 0 . 2

1

μ ⋅ ⋅= M g D Mv (5.1) 

It is implicitly assumed that the braking system of the vehicle can provide enough braking torque 

(retardation force), which means that the total stopping distance only depends on the friction 

force between the tires and the road. This also implicitly assumes that the traction of the tire only 

depend on the road surface, or equivalently, the tire dynamics would not change during braking 

process. 

For vehicles of the same mass and the same initial speed but on a graded road with grade θ , the 

equation would be: 

2

0 . cos sin

2 M g D Mv M g D θ θ

1

μ ⋅ ⋅ ⋅ = + ⋅⋅ ⋅ θ θ (5.2) 

The left-hand side is the work done by braking force; the first term on the right-hand side is the 

kinetic energy the vehicle has at the time instant of staring braking. The second term on the righthand side is the potential energy of the vehicle caused by the road grade. 

96 
Solving the equation (5.1) for Dθ and dividing both sides of equations (5.1) and (5.2) leads to: 

0

cos sin

Dθ

D

θ θ = −

This formula can be used to calculate the stopping distance for a vehicle on a graded road. If D0

happens to be the stopping distance of the vehicle on a flat road but in different weather, Dθ will 

the stopping distance on a graded road in corresponding weather conditions. 

Vehicle Speed 

Researchers from the James Madison University 

(http://www.jmu.edu/safetyplan/vehicle/generaldriver/) have given a relationship between speed 

and stopping distances in Table 29. This table can be interpolated with polynomials: 2nd-4th 

order polynomials with least square fitting. The 2nd order achieves reasonable accuracy. 

Table 29 Vehicle Speed and Stopping Distances 

Miles 

per 

Hour 

Meters 

per 

Second 

Automobile 

Brakes 

(in Meters) 

Truck Brakes

(Brakes on All 

Wheels 

(in Meters) 

Average Driver 

Reaction Time

(3/4 seconds) 

Automobiles 

Total Stopping 

Distance 

(in Meters) 

Truck 

Total 

Stopping 

Distance (in 

Meters) 

10.0 4.4714 1.5240 2.1336 3.3528 4.8768 5.4864 

15.0 6.7056 3.6576 5.1816 4.8768 8.5344 10.0584 

20.0 8.9428 6.4008 9.1440 6.7056 13.1064 15.8496 

25.0 11.1618 9.7536 14.3256 8.2296 17.9832 22.5552 

30.0 13.4112 14.3256 20.4216 10.0584 24.3840 30.4800 

35.0 15.6362 19.2024 28.0416 11.5824 30.7848 39.6240 

40.0 17.8918 24.9936 36.5760 13.4112 38.4048 49.9872 

45.0 20.1168 31.6992 46.3296 15.2400 46.9392 61.5696 

50.0 22.3418 39.0144 56.9976 16.7640 55.7784 73.7616 

55.0 24.5974 47.2440 69.1896 18.5928 65.8368 87.7824 

60.0 26.8224 56.3880 82.2960 20.1168 76.5048 102.4128 

65.0 29.0474 66.1416 96.3168 21.6408 87.7824 117.9576 

70.0 31.2725 76.8096 111.8616 23.4696 100.2792 135.3312 

75.0 33.4975 88.0872 128.6256 24.9936 113.0808 153.6192 

80.0 35.7226 99.9744 146.3040 26.8224 126.7968 173.1264 

90.0 40.2336 129.5400 185.0136 30.1752 159.7152 215.1888 

100.0 44.6837 156.6672 228.6000 33.2232 189.8904 261.8232 

Combined Factors 

If the above factors are combined together, which can significantly affect the vehicle stopping 

distance, the following relationship is reached: 

97 
1

2 0 2

1

1

cos sin

0.8( )

D D

asphalt

μ

θ

μ μ

θ θ μ

μ

= −

=

Where the stopping distance in nominal road conditions 1

0

μ D D 0 = is given in Table 30. Table 29 

contains the result of experiments made with motor vehicles, unloaded except for the driver, 

equipped with all-wheel brakes, in good condition, on dry, hard, approximately level stretches of 

highway free from loose material. It has also accounted for the average driver response time 

delay. 

Table 30. Analytical Relationship Between Stopping Distance and Vehicle Speed 

Vehicle 

Type 

Average Stopping distance [m] 

versus speed [m/s] 

Average Total Stopping distance [m] 

versus speed [m/s] 

Automobile 2

0 0 0 D v = ⋅+ ⋅ -0.002593 0.030575 v

2

00 0 Dv v = 0.101900 0.030526 ⋅+ ⋅

Truck 2

0 0 0 D v = ⋅+ ⋅ -0.000437 0.044166 v

2

0 00 Dvv = 0.104055 0.044117 ⋅+ ⋅

5.1.3. Front Target Tracking 

Between target tracking and relative distance/speed estimation, target tracking is the main 

challenge in the implementation. Preliminary work in this respect (if the remote sensor is fixed 

on the ground) has been investigated extensively by Lu and others (Lu, et al., 2005; Lu and 

Shladover, 2005); however, the OBMS prototype uses Doppler radar (EVT-300) and DENSO 

Lidar (laser radar) as onboard remote sensors for front multiple-target tracking and relative 

distance and speed estimation. Radar is mainly used for relative distance and speed estimation 

Front multiple-target tracking is the key for threat assessment for collision between vehicles. 

Multiple-target tracking using vehicle onboard remote sensors, such as radar, is more challenging 

due to the following factors: 

1. The detection or recognition capability of each sensor is very limited physically. Doppler 

radar is good for relative distance measurement but accurate for distance and lateral 

position (or azimuth) measurement. Laser radar (lidar) is good for distance measurement 

but speed estimation is not as good as the Doppler radar. In addition, the sensitive signal 

reflecting materials of the two radar types (microwave and laser) are different. For 

example, lidar likes the rear light of the front vehicle, while Doppler radar may see the 

rear end of the truck easier. Due to those factors, about 25 to 30 percent of the target-time 

has been missed by either of them. An algorithm has been developed to fuse the two 

signals to combine their advantages to achieve more reliable multiple-target tracking. 

2. False target: Due to the subject vehicle moving, front targets’ situations relative to the 

vehicle are complicated—any objects in the sight of view of the sensor would be taken as 

98 
a potential target by Doppler radar and lidar. It is unreasonable to simply drop static 

objects since there may be a vehicle stopped ahead, in front of the truck lane. 

3. Subject vehicle vibration: The subject vehicle vibration causes the radar/lidar beams to 

move around and thus causes large disturbances to the sensors in the measurement of 

distance, angle, and speed of the targets. Significant vibration may cause a front target to 

be missed. 

4. From target vehicle lane changing behavior: Front target vehicle lane-changing will cause 

confusion of the internal tracking of radar and lidar by changing the tracking ID. 

Additionally, lateral position or azimuth estimation is more difficult. 

5. The curve of the road ahead: Unless the road curvature is well-predicted, road curve 

ahead causes front target lateral shift. For example, road curve ahead to the left may 

cause target in the right lane to be missed and the target in the middle lane to be mistaken 

as the target in the left lane. 

To fully solve those problems with all the factors addressed would require extensive research 

with multiple-sensor fusion techniques development in the future. 

This project has developed tracking algorithm for three potential front targets: target on the left, 

middle, and right lanes. Other targets beyond the three lane-widths are ignored. In this phase of 

the project, road curve affect on target tracking is not considered yet. This means that it is 

implicitly assumed that the freeway is straight ahead. 

Front Multiple-Target Tracking Using Radar and Lidar 

A standard Eaton Vorad set (EVT-300) provides information for up to seven targets, with an 

update interval of 75 ms. Information includes target ID, speed, distance, and azimuth. This 

means that the radar set has an internal tracking algorithm in addition to filtering capability. 

To achieve this, it is necessary to use prediction in the tracking algorithm in addition to target 

association due to target missing. Other tracking and association methods are referred to by BarShlom and Frotmann (1988) and Mobus, Joos, and Kolbe, 2003). These methods use a Kalman 

filter approach for multitarget tracking in developing adaptive cruise control. Distance-based 

tracking algorithms are used for lidar for developing a frontal collision warning system (Wang, 

et al., 2001). These methods were chosen for their simplicity, reliability, and effectiveness. In 

particular, the characteristics of the Doppler radar are fully utilized. 

The main problem for vehicle-following using radar is to detect targets in the front although 

there may be multiple vehicles in each lane. The characteristic of Eaton Vorad is that it is speedbased measurement, which will be used in radar target tracking and association. This means that 

the criteria for building tracks corresponding to vehicles threshold should be set with respect to 

target speed. This can be called a speed-based measurement, which is different from those of 

distance-based measurement, such as laser radar or video camera. The following terminologies 

and notations are used: 

• Track: A track corresponds to an expected target which may be composed of several time 

series of data assigned. Each time series of data corresponds to one parameter or state 

(speed, longitudinal distance, and lateral distance) of the target. A tracking algorithm is a 

99 
rule to redistribute the data from the seven channels of the data set. Suppose the number 

of lanes is N, the maximum number of target to be tracked is also N. 

• Filtering: For the built tracks, it is necessary to smooth the data series. For radar distance 

measurement, low-pass digital filters are used for smoothing the measurement. 

Specifically, the following filter is used: 

10

)1()1()()(

<<

−⋅−+⋅=

λ

λ txtx λ tx

where tx )( is the estimate of current time step, tx )( is the measurement of current time 

step, and tx − )1( is the estimate of previous time step. 

• Prediction: A simple prediction method is used to predict the vehicle speed and distance 

based on acceleration for the case when radar misses the target. A simple kinematics 

model is used for the prediction: 

)1()1()( Δ⋅−+−= ttvtxtx

)1()1()( Δ⋅−+−= ttatvtv

At each time step, acceleration ta )( is calculated and saved in the buffer if there is no 

target loss a −−= /)]1()([)( Δttvtvt . If there is a temporary target loss, are used as 

estimates. 

ttvtxtx

ttatvtv

Δ⋅−+−=

Δ⋅−+−=

−−−=− /)]2()1([)1( Δttvtvta

)1()1()(

)1()1()(

• Fusion of radar and lidar signals: Because the characteristics of lidar and radar and their 

detection capabilities are different, it is necessary to fuse the tracks built from those two 

sensors to produce a reliable front-target tracking, and some parts are complementary. 

The advantage for data fusion is to use their combined strengths and avoid their 

weaknesses. To achieve this, the following fusion logic is used: If radar has no detection 

while lidar has detection, use lidar data; if radar has reasonable detection while lidar does 

not, then use radar data; otherwise, use a Kalman filtering approach to assign appropriate 

weight to those two streams of data. 

A static Kalman filter is used to fuse those two for relative distance measures in normal 

cases (Chui and Chen, 1999). The purpose for data fusion is to achieve a more reliable 

and accurate measure by means of sensor redundancy: (a) using two distance estimates to 

compensate for each other’s measurement to reduce target loss, (b) using Kalman 

filtering properties to achieve an optimal estimation by assuming that the two measures 

from radar and lidar sets are simultaneous and independent (Chiu and Chen, 1999; 

100 
Maybeck, 1979), and (c) all signals—relative distance, speed, and lateral position—are 

fused. 

Let nyny )(),( L R denote lidar and radar measurement in the longitudinal direction at time 

step n Let ny )( LR denote the fused longitudinal distance of the target at time step n . Let 

y n( ) denote the prediction variable. Then the Kalman filter for data fusion can be written 

as the following “predictor-corrector” form: 

( )

2

2 2

2

2 2

( ) ( )

() () () () ()

( )

L

L R

R

L R

y

R

y y

LR L

y

y y

y n y n

y n yn Kn y n yn

K n

σ

σ σ

σ

σ σ

= +

=+ −

= +

where nK )( is generally recognized as the gain of the corrector, and L σ y

2

 and R σ y

2

 are 

the variances of the lidar estimate and radar longitudinal distance measurements, which 

are obtained by comparison of the estimated value from measurement and those 

broadcasted by the test vehicle. The fusion of relative speed and lateral position 

measurement are the same and are not repeated here. 

5.1.4. Recommended Following Distance 

The recommended following distance is preliminarily determined based on time headway under 

normal environmental conditions. The recommended following distance is described by: 

2 2

v B

2 2

L F

recomm R F

L F

L F

v v S T

a a

v rv

⎛ ⎞⎛ ⎞

= − +⋅+ ⎜ ⎟⎜ ⎟ ⎝ ⎠⎝ ⎠

= +&

where 

L v − leading (target) vehicle speed, obtained form radar/lidar tracking 

L a − leading (target) vehicle acceleration, F v − following (object) truck speed 

F a − following (object) acceleration 

r r, & − relative range and range rate of the truck with respect to the front target 

vehicle, obtained from radar/lidar tracking 

TR − reaction time 

B − minimum safe following distance 

101 
Since the target vehicle acceleration is difficult to measure/estimate based on remote sensor, 

2 4.0[ / ] s L a m = − as the maximum deceleration of the front vehicle, and 2 2.0[ / ] s F a m = − as the 

maximum braking capability of the fully loaded truck, which corresponds to the worst-case 

scenario; B m =10 is considered as the minimum distance relative to the front vehicle. This 

consideration is based on the research on threat assessment for the collision warning system at 

Mazda, illustrated in Figure 19. 

Figure 19. Truck Speed Versus Recommended Distance 

5.1.5. Recommended Speed 

The recommended speed is mainly determined by three factors: (a) speed limit of the road based 

on geographical situation of the road, such as curvature, grade and elevation, (b) simplified 

rollover threat assessment, and (c) traffic speed: the average speed of vehicles in adjacent lanes. 

The recommended speed is the minima of the three. The speed limit of the road is obtained from 

the NAVTEQ system in real-time, which is eventually determined by highway design standards. 

Under normal weather conditions, the limit is usually the safe speed; however, the limit speed 

needs to be reduced adaptively under the following conditions: 

• Reduced tire slip due to weather such as rain, snow, and ice 

• Curvature and super-elevation of the road 

As detailed later, lateral acceleration could be used as a threat assessment index for rollover 

warning. Based on this consideration, it is possible to generate speed threshold for curved roads; 

the curvature can be predicted from other sensors such as NAVTEQ system. Using the critical 

lateral acceleration for Freightliner fully loaded trucks: 

102 
a critical g N ( ) 0.225 =

One can estimate recommended speed as: 

2

t

() () ()

() ()

N

roll N

ta t vt

v ta

ρ

ρ

=

=

In the implementation, the recommended speed would be v v vv recom = min , , { limit roll traffic}, where 

limit v is from the speed limit of the road; roll v is the critical speed for rollover threshold as above; 

and traffic v is the traffic speed based on tracking of front target of left and/or right lanes. 

5.1.6. Preliminary Consideration of Rollover Warning 

This subsection preliminarily considers rollover warning based on vehicle dynamics from an 

implementation viewpoint instead of extensive theoretical analysis. 

A truck (tractor and trailer combination) may have high center of gravity (CG) or may loose 

traction on curved roads when the vehicle speed is above some threshold. Those factors may lead 

to rollover of commercial trucks. Truck rollover not only causes damage to the truck itself and 

hurts the driver, but also causes more devastating consequences to other vehicles on the highway 

if the traffic density is high. The situation is even worse if hazardous materials are loaded on the 

truck. As discussed by Baker, Bushman, and Berthelot (2000), truck rollover is likely to cause 

the following consequences: 

(a) Property damage 

(b) Human life 

(c) User costs/delays 

(d) Environmental liability 

(e) Loss of traffic mobility/efficiency 

(f) Capital infrastructure costs 

It is important to have an effective device to warn the driver for any potential rollover. 

From a vehicle dynamics viewpoint, truck rollover is the result of loosing stability. Truck 

dynamics can be divided into tractor and trailer coupled at the king ping. The trailer dynamics 

can be considered as coupled sprung mass and unsprung mass as shown in Figure 20. 

Previous Rollover Studies 

Brievik (2000) considered factors which cause truck rollover. By means of a powerful simulation 

package provided by DaimlerChrysler, a numerical sensitivity analysis with respect to vehicle 

parameters was performed. It was found that the stability of the system is highly dependent of 

the loading condition. Based on simulation results and literature studies, it was determined that 

the event of wheel liftoff is very significant with respect to rollover. Wheel liftoff causes a 

significant difference in wheel angular speed of the two wheels on the same axle due to the 

103 
differential mechanism. This work thus suggests using the wheel angular speed difference Δω as 

another measure of rollover. 

min( , )

l r

l r

ω

ω ω

ω ω

− Δ =

Once the Δω is above certain threshold, a warning should be issued to the driver. The study 

claimed that it can provide 0.5s warning ahead. 

Figure 20. Vehicle Sprung Mass Model 

Kamnik (2000) considered the maneuver-induced vehicle rollover, which is primarily attributed 

to the dynamic roll behavior of the trucks, while the contributions from the tripping mechanism 

are absent. This work claimed that type of rollover might occur during low-speed cornering and 

braking or high-speed evasive directional maneuvers. This work used analytical truck dynamics 

in the roll plane and was evaluated by the numerical simulator of the Freightliner tractor/trailer 

combination. It appeared that the vehicle-roll response, encompassing the lateral acceleration and 

104 
the sprung and unsprung mass roll angles, was directly related to the rollover coefficient and was 

nearly in phase with it. 

The works of Chen and Peng (2001; 2005) tried to predict the rollover based on Time-ToRollover (TTR) metric for an articulated heavy vehicle. The TTR metric conducted a “countdown” toward rollover independent of vehicle speed and steering patterns. Basically, TTR is a 

prediction process to indicate how far the truck is from the rollover threshold as progressing. In 

this approach, an accurate model significantly faster than real-time was needed. Meanwhile, the 

TTR predicted by this model needed to be accurate enough under all driving scenarios. An 

innovative approach was proposed in these studies (2001; 2005) to solve this dilemma and the 

design process is illustrated in an example. First, a simple yet reasonably accurate yaw/roll 

model was identified. A Neural Network (NN) was then developed to mitigate the accuracy of 

the model. The NN took the TTR generated by the simple model, vehicle roll angle, and change 

of roll angle to generate an enhanced NN-TTR index. The NN was trained and verified under a 

variety of driving patterns. It was found that an accurate TTR is achieved across all the driving 

scenarios were tested. 

Chen considered roll stability based on role angle and its derivatives: 

2

00 0 2 p p t t

1 φ =+ + φφ φ p & &&

where ( 000 φ , , φ φ ) & && are measured or estimated roll angle, roll rate, and roll acceleration 

respectivelyφ p is the predicted roll angle of the semi-trailer and p t is the prediction time. When 

φ p becomes larger than the selected threshold roll angle, the signal-based TTR is set to be p t . 

This is Taylor expansion approximation. To implement, the roll rate is measurable, but 

acceleration is difficult to measure, which needs to be estimated independently from the roll rate 

for the above estimation to make sense. To look at the roll angle would have much less 

prediction capability, because roll movement is the result of other movement, such as 

longitudinal speed and yaw and yaw-rate; however, it is useful for progressive warning if it is 

used as the last dam if all the other predictions failed. 

Stevens (2000) developed a rollover warning system with onboard instrumentation that measures 

the roll stability of the trailer continuously and determines the location and probable near-term 

path of the vehicle. In addition, roadside beacons at selected curves on I-75 broadcast the 

curvature of the road section. The receiver on the truck receives the information and an onboard 

computer estimates rollover risk based on roll stability, vehicle speed, and acceleration, and the 

lateral acceleration demand of the upcoming curve. If estimated rollover risk exceeds a trucking 

company’s specified threshold, visible and audible warnings were sent to the driver in time for 

corrective action to avoid rollover. 

Rogers and Zhang (2003) provided an interesting implementation-oriented set of results, 

introducing the Freight Line Rollover Advisor, and then extended the system. This study 

contained a simple model for lateral acceleration calculation based on speed, curvature, and 

elevation. The threat assessment is based on the score of RSA: 

105 
a actual ( ) _ ( )

N

N

RSA Score

a critical =

where 

2

t () () ( ) N

v tKt a E

g = −

and v t( ) − longitudinal speed in [m/s] 

K( )t − curvature in −1 [ ] m

2

g ms = 9.8[ / ]

E( )t − super elevation as slope in radiant 

In the implementation, the super-elevation (bank) and curvature is from a survey data map. 

Measured parameters include: 

• Longitudinal peed 

• Lateral acceleration 

• Operational parameters (brake and throttle pedal deflections, wiper info) 

• Lane marker detection 

Rogers and Zhang (2003) generated the road map based on DaimlerChrysler’s own GPS system, 

which was claimed to have improved accuracy for the road map compared to that from the 

NAVTEQ system. 

For Freightliner fully loaded trucks, the following threshold applies: 

a critical g N ( ) 0.225 =

as the critical lateral acceleration. 

Implementation Considerations 

For online monitoring of the relative rollover stability and predicting vehicle rollover risk, the 

feedback signals and some knowledge about the vehicle parameters are needed. Parameters that 

primarily characterizes truck roll behavior include: 

• load mass and distribution—height of CG 

106 
• vehicle geometry configuration and characteristics, such as wheel base and the 

suspension vehicle speed 

• lateral acceleration 

• front-wheel turning angle or the angle difference between tractor and trailer 

• yaw/roll angle/rate 

• road characteristics: curvature and super-elevation 

• angular speed difference of left/right wheels on the same axle of the trailer wheel 

Based on vehicle dynamics, the following rollover-cause logic sequences was proposed: 

• longitudinal speed + road curve (or steering angle) 

• lateral acceleration 

• load transfer 

• trailer outer wheel liftoff 

• tractor outer wheel liftoff 

• rollover 

In practical implementation, the Three-Step Progressive Rollover Warning approach was 

proposed based on above analysis: 

Step 1: Rollover Longer Time Prediction. Based on the predicted road curvature 

information from NAVTEQ system, a potential lateral acceleration was calculated using 

the simplified model: 

2 () () / () N a t vt t = ρ

where vehicle speed v t( ) is estimated from wheel speed, and instant radium ρ( )t of the 

road curve is predicted from the NAVTEQ system. Using the lateral acceleration 

threshold for Freightliner fully loaded trucks, if a t a critical N N () ( ) > is satisfied for 

certain time steps, a warning is issued. 

Step 2: Rollover Shorter Time Prediction. This prediction is based on a simplified model 

based on vehicle longitudinal speed and yaw angle to calculate lateral acceleration as in 

Step 1. The difference is that the lateral acceleration is measured from the Inertia 

Measurement Unit (IMU) instead of from a prediction using NAVTEQ system. If 

a t a critical N N () ( ) > is satisfied, a warning is issued immediately. 

Step 3: On-the-Curve Instant Prediction. As the last dam, it is based on roll angle of the 

truck. The roll angle measure is from the IMU, which is mounted near the yaw center of 

the tractor. Instead of using yaw acceleration, roll angel and roll rate were used only to 

predict the potential rollover: 

p 0 0 p φ = + φ φ t &

107 
If φ p >3.5 [deg], a rollover warning is issued. However, this is only a preliminary 

implementation. The threshold needs to be calibrated in the next phase. In the future, this 

could be further improved by mounting the roll angle sensor at the roll center at end of 

the trailer, which will be more direct and faster. 

By incorporating more vehicle information into the rollover decision threshold, the accuracy and 

effectiveness of the rollover warning system can be significantly increased. 

5.1.7. Algorithm Implementation 

Critical Parameters 

The critical parameters for implementation of the algorithms are: 

v − vehicle speed 

μ − practical tire slip 

θ −road grade 

φ,φ& − yaw/yaw rate 

φ,φ −& roll/roll rate 

Target relative distance 

Target relative speed 

Additionally, it is necessary to know in real-time if there are other moving or static objects, such 

as a vehicle in the front and the intervehicle distance. This requires real-time tracking using 

remote sensors. 

Sensors 

Sensors used for the truck OBM system include: 

• Radar: EVT-300 

• DENSO Lidar 

• Gyroscope 

• Inertia Measurement Unit 

• Road surface detection for tire slip 

• Video camera 

• NAVTEQ system (including GPS) 

• J1939/J1857 list: providing most vehicle-related measurements, including wheel speed, 

engine, brake, vehicle kinematics, and driver operation information 

108 
The set of parameters to be inferred from the sensors include the parameters related to truck 

kinematics: speed, acceleration, steering angle, fuel rate, and braking system (pneumatic brake, 

engine brake, and transmission retarder) use; the lane-keeping information is from the NAVTEQ 

system. 

Parameter Estimation From Target Tracking 

Front multiple-target tracking has been an active topic for many years regarding Frontal 

Collision Warning Systems development. 

Sensors are mainly used for the following purposes: 

(1) Detection of road surface condition for tire slip: A commercially available camera and 

other sensor-based road surface detection system will be used to detect road surface 

condition in real-time. This information will be fused with ambient temperature detection 

and luminance detection for more reliable estimation of tire slip. 

(2) Road grade information: This is obtained in real-time by using the NAVTEQ system, 

which has GPS location of the vehicle. This location data is compared with the internal 

road map which provides road information including the umber of lanes, lane number 

curvature, and grade. 

5.2. FATIGUE AND INATTENTION DETECTION 

5.2.1. Introduction 

Any error, failure, or lapse of attention may lead to a crash. These errors may be related to the 

driver’s energetic or alertness state and are described more fully in section 2.0 of this report. As a 

consequence, it is important to investigate the detection approaches on driver fatigue and 

inattention. 

A brief review of the past studies on fatigue and inattention monitoring is provided in section 

5.2.2. In the OBMS prototype implementation described in section 4.0, the SafeTrac system and 

its lane-keeping monitor was used as a surrogate, since despite the body of research described in 

the next section, reliable methods and products beyond the relatively straightforward, simple 

(and, at best, modestly effective) systems like SafeTRAC were not available, at least at the time 

of selection. However, as a research element to the OBMS project, a set of relatively 

straightforward fatigue and inattention schemes—while not implemented due to its complexity—

was researched; this uses the concepts and ideas for systems as SafeTRAC as a “point of 

departure.” The remainder of this section describes the development of these detection schemes. 

These schemes are entirely based on the existing approaches in literature and are slightly 

modified in order to be adapted to the environments of the truck and the OBM system. 

5.2.2. Literature Review 

Without directly monitoring the driver’s psychological and physiological states, such as using an 

electroencephalogram (EEG), eyes-off-the-road time, and blink rates, the past studies in the 

109 
literature focused on driver models, driving performance statistics, and driving behavior analysis. 

These approaches are reviewed as follows: 

Driver Models 

A well-known result from human factors research is the “crossover model.” The crossover model 

states that the open loop frequency response of the driver-vehicle combination approximates that 

of transfer function /s ωc around the crossover frequency, where ωc is the crossover frequency. 

More precisely, the open loop driver-vehicle combination approximate ( / )exp( ) E s s ωc −τ around 

ωc , where an effective time delay of the driver, E τ , is included. Some other models have similar 

characteristics around the crossover frequency and differ more at higher and lower frequency 

ranges. shows such a driver model proposed by Hess and Modjtahedzadeh (1990). In Figure 21 , 

y ( ) R t denotes the lateral position of current road centerline in the global reference frame and Vy

is the vehicle lateral position relative to the global reference frame. The driving task is to keep 

the difference, A R V e y = − y near zero. The output of the driver model is the steering wheel angle, 

denoted as SW δ . 

Figure 21. Different Realizations of Crossover Model

Kiencke, Majjad, and Kramer (1999) developed a hybrid driver model for modeling and 

analyzing the driver’s handling of both the lateral and longitudinal motion of the vehicle. It 

consists of four parts: queuing system, selection, reference variables, and controller. The hybrid 

model combined discrete event system and the classical control. It tries to handle all the 

cognitive processes of the human operator in order to mimic real driver behavior, which can be 

used in vehicle/driver simulations. The block diagrams in Figure 22 show the idea of hybrid 

driver model 

110 
Figure 22. Human Information Processing Model 

Chen and Ulsoy (2001) have proposed to use an ARMAX (auto-regression moving average with 

exogenous inputs) model as the driver model structure. Based on statistic analysis of 

experimental data, it was found that the input (lateral position) and output (steering angle) has a 

good coherence up to 1 Hz, which indicates that a linear model can characterize human driving 

adequately from the control point of view. The basic structure of ARMAX models is depicted in 

Figure 23(a). One advantage of this model structure is a rich body of knowledge available in the 

field of modeling and identification of dynamic systems. Another advantage of the model is that 

some of its coefficients have clear physical interpretation; for example, the delay time may be 

estimated based on the number of vanishing coefficients of the moving average portion of the 

model, and the delay time may be interpreted as the driver’s response time, the time that the 

driver needs before initiating a corrective action after visual observation. Chen and Ulsoy (2001) 

also introduced nonlinearity (dead zone) in the model to further reduce errors between modeling 

and experiments, as shown in Figure 23(b). They used the lateral position of the center of gravity 

of the vehicle as the input to the human driver model. This selection is not realistic, and their 

results include aspects that are not consistent with basic limitations of the human driver. 

(a) (b)

Figure 23. Driver Model Using ARMAX Structure 

However, the fatigue/inattention detections based on driver models are not yet mature and have 

many limitations. The difficulties of the driver model-based approach will be delineated in the 

subsequent subsection describing the problem. 

111 
Driving performance: A suggested list of impairment of criteria was proposed by Brookhuis, 

De Waard, and Fairclough (2003). They characterized criteria in terms of absolute levels (i.e., 

the cut-off point which defines impaired driving) and relative change (i.e., the relative change 

which indicates a significant change in individual driver performance) based on driving 

performance. The proposed criteria, shown in Table 31, were divided into three areas: following 

too closely, straddling lanes, and driving too fast. These events are defined as follows: 

• Following too closely: characterized as tailgating where the temporal separation between 

the vehicle and the lead vehicle is evaluated. 

• Straddling lanes: characterized by an increase of the lateral deviation of the vehicle. 

• Driving too fast: characterized by exceeding the legal speed limit. 

Table 31. Definition Criteria for Following Too Closely, Straddling Lanes, and Driving Too Fast 

Absolute Change Relative Change 

Following too closely: 

Time headway to lead vehicle (TTC) <0.7 s -0.3 s 

Straddle lanes: 

Steering SD >1.5° +0.5° 

Lateral deviation (SD) of the vehicle >0.25 m +0.04 m 

Minimum time-to-line crossing (TLC)—right lane <1.3 s -0.3 s 

Minimum TLC—left lane <1.7 s -0.2 s 

Median TLC—right lane <3.1 s -0.7 s 

Median TLC—left lane <4.0 s -1.4 s 

Driving too fast: 

Vehicle speed Limit+10% Limit±20% 

112 
Driving behaviors: This approach is derived from the observation on driving characteristics. 

Steering entropy is one such attempt (Nakayama, Futami, and Nakamura, 1999). It was observed 

that as the driver performed other tasks while driving, steering variance increased and bandwidth 

of steering input decreased when compared with the so-called “baseline” driving behavior. 

During the experiments, drivers had various strategies to adapt differently to the tasks rather than 

driving. As a result, magnitude-only or frequency-only metrics to detect driver inattention could 

be applied to some samples but failed for other samples. The steering entropy method may not 

have such problems. Another attempt by Desai and Haque (2006) to utilize the time derivative of 

force exerted by the driver at the vehicle-human interfaces can be used to construct a signature of 

individual driving styles and to discern different levels of alertness. In this study, a parameter, 

spikiness index, was introduced for the time series data of the force derivative to quantify driver 

alertness. 

5.2.3. Problem Description 

From a dynamical system perspective, if a driver is regarded as a nonlinear time-varying 

multiple-input-multiple-output (MIMO) system, Figure 24 shows the general interactions in a 

typical driver-vehicle system. A driver gives commands to the vehicle based on the vehicle states 

and the external factors, such as the desired trajectory, road conditions, side vehicles, obstacles, 

and so on. In addition to the vehicle states and the external disturbances, the psychological and 

physiological factors of the driver can also impact the driver’s commands. The difficulties of the 

driver fatigue and inattention monitoring lie on the following issues: 

(1) The structure of the comprehensive driver model is not sophisticated, yet, there is 

no guarantee that using typical system identification approaches to identify driver 

fatigue/inattention with an incorrect model structure would lead to correct results. 

(2) The parameters of the driver model can be time-varying. This increases the 

difficulty of system identification heavily. 

(3) Note that fatigue/inattention is only part of these psychological and physiological 

factors. Without investigation on the influence of other physiological and 

psychological factors, it is highly possible that one of these factors can have very 

similar driving characteristics to those under fatigue/inattention. 

(4) Some inputs, such as pedestrian, obstacle, and pot holes, are generally not acquired 

in such fatigue/inattention monitoring systems. These factors can also affect the 

driving characteristics significantly. 

(5) Since the driver perceives many inputs and processes them during driving within 

each short period of time, the parameter identification task may fail due to the 

insufficient richness of the input signals. Furthermore, in order to identify 

parameters for a nonlinear system, the system may need to experience various 

operational conditions. 

113 
Driver

Commands Vehicle

Lane position

Yaw rate, pitch rate, and roll rate

G-forces in 3 axes

Speed

Obstacle

Wind gust

Gravity

Road (e.g. pot hole)

External factors Pedestrian

Side vehicles

Psychological 

and 

physiological 

factors

Mood

Inattention

Fatigue

...

...

...

...

...

...

...

Muscular aches

Following distance

Driver

Commands Vehicle

Lane position

Yaw rate, pitch rate, and roll rate

G-forces in 3 axes

Speed

Obstacle

Wind gust

Gravity

Road (e.g. pot hole)

External factors Pedestrian

Side vehicles

Psychological 

and 

physiological 

factors

Mood

Inattention

Fatigue

...

...

...

...

...

...

...

Muscular aches

Following distance

Figure 24. General Driver-Vehicle Interactions 

This section is not aimed at developing a new fatigue/inattention detection technique. Instead, it 

utilizes the combination of above-mentioned approaches to generate the associated metrics in 

order to identify possible fatigue/inattention. The basic requirements of such monitoring schemes 

include: 

(1) Using onboard vehicle sensors only 

(2) Less computation time 

(3) Sufficient adaptation capability or robustness to different drivers 

The correlation between these metrics and the driver fatigue/inattention will be further evaluated 

in the FOT. 

5.2.4. Driver Fatigue Detection 

The driver fatigue monitoring in this study is divided into two parts: using the dedicated COTS 

system and employing the driving performance measures. The COTS system installed on the 

prototype truck is SafeTRAC, made by AssistWare. It is essentially a camera-based, lanedeparture warning system. This system can provide warnings upon the following events: 

roadway departure, unsignaled lane change, and unsatisfactory driver alertness. It provides an 

alertness index that scores a driver’s lane-keeping performance based on TLC, lane departures, 

and lane position deviations. If the driving turns out to be unpredictable or inconsistent, the 

alertness index drops. This can alert the driver to pay more attention. When the index is under a 

predetermined value, the system will give the driver a warning. This warning signal and the 

score are recorded in the OBM system as the fatigue measures. 

114 
The driving performance measures of interest are the lane-keeping capability and the throttle 

angle usage. Based on criteria presented earlier, one of the important metrics is the standard 

deviation of the lane position; however, it is generally very difficult to set a single threshold to 

identify the driver alertness status as “fatigue” or “normal.” Such a threshold would lead to false 

alarms or missed detections easily. For example, suppose that the driver alertness levels can be 

quantified from 0 to 100 percent and Figure 25 shows the respective probability density 

functions of the standard deviations of lane positions (SDLP) for the alertness levels of 25 

percent, 70 percent, and 100 percent3

. By comparing the driving performance between the 

alertness levels of 25 to 100 percent, it is easy to identify the driver fatigue by setting a single 

threshold; however, this single threshold strategy will not work when the alertness level falls in 

between (e.g., 70 percent). This example indicates that such a strategy based on a single 

threshold would not be able to monitor driver fatigue. 

SD of lane position

Probability

Alertness 

level: 25%

Alertness 

level: 100%

Alertness 

level: 70%

Single threshold

Fatigued? SD of lane position

Probability

Alertness 

level: 25%

Alertness 

level: 100%

Alertness 

level: 70%

Single threshold

Fatigued?

Figure 25. Probability Distribution of SDLP of the Driver With Different Levels of Alertness 

A better approach is to define the fatigue flags for different levels of the SDLP. Introducing two 

more intermediate states and a few basic rules can help identify the driver fatigue. Figure 26

illustrates an example of different driver alertness states based on the SDLP. The fatigue flags 

are defined by: 

 

3 3 These alertness indices are only used to present the driver status for exemplary 

purposes. 

115 
fatigue flag _ = 0 (Normal) if 3 m SDLP > ≥ 0

fatigue flag _ = 1 (Not yet determined) if m SDLP m 2 3 > ≥

fatigue flag _ = 2 (Possible fatigue) if m SDLP m 1 2 > ≥

_fg

 (Fatigue) if 1 SDLP m>

where 123 mmm >>> 0 , 123 mmm ,, R ∈ . 

m3 m2 m1

012 3

m3 m2 m1

012 3

Figure 26. Fatigue Flags Based on Standard Deviation of Lane Positions 

The decision-making scheme is mainly based on the criterion in Figure 25. In order to decrease 

the probabilities of false alarms, some more heuristic rules are integrated into the decisionmaking scheme. The rules are summarized below: 

(1) If the fatigue state stays in “possible fatigue” exceeding a predetermined period, the 

state will be set to “fatigue.” 

(2) If the state is “not yet determined” for some time and if the driver keeps on driving, 

the fatigue flag becomes “possible fatigue.” 

(3) If the state falls into “fatigue” immediately followed by “normal,” the fatigue flag 

will show “possible fatigue.” 

5.2.5. Driver Inattention Monitoring 

The driver inattention in this study is evaluated by using steering entropy. The steering entropy 

algorithm mainly includes two components: prediction error filter and a nonlinear weighting of 

the prediction errors (Boer, et al., 2005). The key concept is to compare driving characteristics 

between the current condition and the so-called baseline condition. The baseline driving with 

respect to the current condition refers to the condition under which the driver focuses on driving: 

(1) without performing other tasks, (2) in the same driving course, and (3) with the same speed 

profile; however, it is not possible to have the driver driving in the same course at the same time 

twice. In addition, since the driving conditions and the environments vary from time to time, it 

116 
may be “unfair” to evaluate the characteristics at different times. As a result, using the low-pass 

steering input as the baseline driving characteristic is proposed. 

There are two versions of prediction error (PE) filters: the original PE filter (Nakayama, Futami, 

and Nakamura, 1999) and the modified PE filter (Boer, et al., 2005). The modified PE filter is a 

third-order autoregressive (AR) filter and the original PE filter can be viewed as the movingaverage (MA) version of the modified PE filter. The difference between these two filters lies on 

the low-frequency amplification (less than 0.3 Hz). Figure 27 shows the frequency response of 

the original filter used in this study. This filter is a high-pass filter and it amplifies the highfrequency contents of steering input higher than 0.7 Hz. The reason why the modified PE filter is 

not employed is because of the way the baseline steering signal is generated. Since a low-pass 

filter is applied to the current steering data in order to provide the baseline steering signal, there 

is no difference at low frequencies between these two signals. The discrepancy between them 

lies on the high-frequency contents. 

Figure 27. Frequency Response of the Original PE Filter With Sampling Frequency of 4 Hz 

The nonlinear weighting function places an extra focus on extreme prediction errors with respect 

to the baseline driving characteristic. Any strong and fast steering input would cause higher 

steering entropy. This nonlinear weighting function is summarized as follows: The prediction 

errors under the baseline driving and the current driving conditions are sorted into 14 sets. A 

prediction error e n[ ] at epoch n belongs to the k -th set for k =1, 2,3,...,14 , if 

117 
[] 6 1

6 [ ] 14

, arg{( 7) [ ] ( 6) } 1

i

en e k

e en k

otherwise k i e e n i e

α

α

α α

⎧ <− ⇒ = ⎪

⎪

⎨ < ⇒=

⎪ = − ≤ <− ⎪⎩ +

, 

where arg{ ( ) } arg{ ( ) 1 }

2

e e

CDF e CDF e

e

α

= + =− α α

= with α = 0.2 . CDF stands for the 

cumulative probability density function. The steering entropy is given by: 

14

)] 2

1

[ log ( current baseline

k k

k

steering

P P

S

N

=

−

=

∑ , 

where 

current

current k

k

N P

N = , 

baseline

baseline k

k

N P

N = , and N is the number of the total samples 

during this period current Nk is the number of the elements in the k -th set for the current 

driving condition. Similarly, baseline Nk is for the baseline driving condition. 

Figure 28 shows the block diagram of the driver inattention monitoring algorithm. The steering 

signals are fed independently into two filters: one with the PE filter and the other with the PE 

filter and an additional low-pass filter. The nonlinear weighting block employs the current and 

the baseline prediction errors to compute the steering entropy. This steering entropy will be 

recorded as an index of the driver inattention. 

Steering Signals

Low-Pass Filter

PE filter

Nonlinear 

Weighting 

Function

PE filter

Current 

Prediction 

Error

Baseline 

Prediction 

Error

Steering 

Entropy (S)

Steering Signals

Low-Pass Filter

PE filter

Nonlinear 

Weighting 

Function

PE filter

Current 

Prediction 

Error

Baseline 

Prediction 

Error

Steering 

Entropy (S)

Figure 28. Implemented Inattention Detection Algorithm 

118 
6. ONBOARD MONITORING PERFORMANCE 

6.1. DRIVER FEEDBACK 

6.1.1. Overview 

The overall purpose of this section is to document the Driver-Vehicle Interface (DVI) designs 

that were developed for and used in the prototype OBMS. The OBMS is not a single integrated 

system, but as described in section 4.0, an integration of COTS systems and sensors that provide 

the driver with feedback, situational awareness, and warnings. 

The results of the question-and-answer group discussion (detailed in section 3) highlighted the 

need to provide drivers with real-time monitoring feedback. The drivers interviewed in this 

project showed a strong and clear preference for systems in-the-cab that could aid them with 

real-time feedback so that unsafe behaviors could be immediately corrected. In creating the 

prototype system, real-time feedback was given the priority; however, this section also includes 

some discussion on which parameters might be better suited for offline feedback. 

One of the goals of this project was to use as many COTS monitoring devices as possible, and to 

avoid redesigning COTS warning systems and algorithms. In selecting the suite of COTS 

systems and sensors to be used in the OBMS prototype, the COTS system DVI was only one 

consideration, and, thus, DVI was less than ideal given the current state of research. This section 

serves three goals: 

1. To compare DVI design and functionality across COTS systems and recent FOT systems 

2. To document the DVI design and functionality of both the COTS devices and monitoring 

feedback as built in the OBMS prototype 

3. To suggest DVI enhancements and additional necessary features that should be 

considered for an OBMS FOT 

Some of the COTS devices used in the prototype design serve multiple functions (e.g., the Eaton 

Vorad system provides both following-distance feedback and forward-collision warnings). Some 

of the parameters being monitored may have multiple interpretations (e.g., frequent forwardcollision warning activations might indicate either frequent following too closely or frequent 

inattention). Nevertheless, an attempt has been made to group the OBMS system functionality 

(from the driver’s point of view) and DVI design discussion into six categories, realizing that the 

categories are not mutually exclusive and that any specific parameters being monitored may be 

used in more than one monitoring application. 

1. Speed 

2. Following 

3. Attention and Fatigue 

4. Good Driving Safety Practice 

5. Offline Feedback and Reporting 

6. Incident Recording and Review 

119 
6.1.2. Monitoring Speed: Intelligent Speed Adaptation 

ISA Research Summary and Design Comparison 

The concept of speed monitoring or Intelligent Speed Adaptation (ISA) is not new, but the 

research that has been conducted on the topic primarily comes from outside the United States. At 

least two ISA field experiments using prototype systems have been conducted in Europe 

(Brookhuis and de Waard, 1999; Várhelyi and Mäkinen, 2001), and the second study eventually 

moved to an FOT (Várhelyi, et al., 2004). Additionally, one recent FOT has been conducted in 

Australia, the TAC SafeCar Project (Young, et al., in press 2006). The details of these studies are 

show in Table 32. 

Table 32. ISA Driver Feedback Design in Recent International FOT Efforts 

Study Type/Size/Technology ISA Driver Feedback 

Visual Audio Haptic 

Brookhuis and de 

Waard (1999) 

- Experiment with 24 drivers 

- 35 min route 

- Vehicle-Infrastructure 

Communication 

Digital Speed 

Green/Amber/Red 

Color Coding 

Initial 

Voice 

Várhelyi and 

Mäkinen (2001) 

- Experiment with 60+ drivers 

- 30 km route 

- Vehicle-Infrastructure 

Communication 

X 

Várhelyi, 

et al. (2004) 

- FOT with 284 cars 

~1 year 

- GPS/Map Database 

X 

Young, et al. 

(2006) 

- FOT with 23 cars 

- 16,500 km each 

- GPS/Map Database 

Speed Limit Sign 

(Flashing) 

Initial 

Tone 

X 

Both studies utilizing auditory feedback provided some leeway (10 percent for Brookhuis and de 

Waard [1999] and 2 km/h for Young, et al. [2006]) before the voice or tone was initiated. 

Continuous auditory feedback was not used in any of the studies. Haptic feedback was given in 

the form of Accelerator Pedal Pushback (APP); however, in the Várhelyi and Mäkinen (2001) 

experiment, the APP was supplemented with the use of a speed governor, whereas the 

subsequent FOT used haptic APP alone with some overall success. Other recent studies such as 

Neurauter (2004) have found little positive effect when using APP alone. In fact, for curve speed 

warning applications, APP alone might even have a negative impact on speed reduction as the 

driver’s tendency when encountering accelerator pedal resistance might be simply to push 

harder. 

Most of the COTS truck or truck driver monitoring devices reviewed in this project (XATA, 

Delphi, APPlus, Cadec, QualCOMM, DriveCAM, AllTrackUSA, and DriveDiagnostics) 

recorded speed; however, none of them were coupled with a system that could understand what 

the current speed limit was. Real-time feedback on speed to the driver was limited to auditory 

120 
beeps at predefined speed ceilings. Alternatively, some of these systems could work in 

conjunction with a speed governor limiting the top speed of the truck to a predefined value. One 

fleet interviewed in this project used the XATA system in conjunction with a speed governor set 

to 58 mph for California intrastate operations (where the maximum speed for trucks is limited to 

55 mph) and 62 mph for interstate operations (where the maximum speed for tricks might be as 

high as 65 mph). 

As a final design consideration, seat-based vibrations (haptic warnings) have been tried with 

limited comprehension success for curve speed warnings (Kochhar and Tijerina, 2006). The 

study concluded that drivers did not naturally relate seat vibrations with excessive speed or 

approaching curves. 

OBMS Prototype ISA Feedback Design 

The ISA driver feedback design conceived and implemented for the OBMS prototype assumed 

the utilization of a High Head-Down Display (HHDD) and is shown in Figure 29. The design 

utilized a multistage warning. In the first stage, continuous visual feedback on speed was 

provided by replicating the vehicle’s speedometer and adding a two-stage alarm bar (similar to 

the display concept of a red-line in a typical tachometer). The amber boundary would indicate 

recommended speed (45 mph in the figure) and the orange boundary would indicate speed limit 

(55 mph in the figure), with the assumption that the recommended speed might be lower than the 

current speed limit based on factors such as an approaching curve, weather (rain, snow, or ice), 

road grade, or current traffic conditions. These speed reducing factors would be displayed at the 

bottom of the screen to give drivers a sense of why the recommended speed was less than the 

current speed limit. 

Figure 29. OBMS Prototype ISA Visual Feedback Design 

A second-stage warning could be given in the form of a flashing text message at the top of the 

screen (possibly in conjunction with an auditory alert) if the vehicles speed exceeds the 

recommended speed or the speed limit by more than a specified threshold for a specified period 

121 
of time. For the prototype demonstration, the thresholds were nominally set at 5 mph and 0 

seconds. 

OBMS ISA FOT Recommendations 

One issue that will need to be addressed before deploying this type of ISA system in a FOT will 

be the desired trade-off between alarm annoyance, alarm compliance, and driver acceptance of 

the system. In general, the more annoying the alarm, the higher the compliance, but the less 

accepting drivers will be of the system. The prototype utilized a configurable speed and time 

“grace” threshold before escalating the warning and recording an incident, and this threshold will 

need to be fine-tuned with feedback from any potential FOT partner’s management and drivers, 

as well as direction from both FMSCA and Caltrans. 

Another issue that will need to be addressed during an FOT is the potential for the system to 

incorrectly determine the speed limit or incorrect speed. This could occur due to map database 

errors, poor GPS, or incorrect map matching. If such an error occurs, the driver will need a 

button to press to cancel the alarm and report the error for further review. 

6.1.3. Monitoring Following Behavior 

Research Summary and Design Comparison 

There have been a number of FOTs (and a number of COTS devices) that utilize followingdistance feedback (often combined with forward-collision warnings). Table 33 compares the 

interfaces developed in five products for FOT efforts relating to following distance (time-gap) 

and forward-collision warnings. The first product compared was the Eaton Vorad EVT-300, 

which is perhaps the most widely used COTS system available on many new trucks to provide 

both following time-gap and forward-collision warnings. The ACAS FOT (Automotive Collision 

Avoidance System) was sponsored by NHTSA, designed by General Motors (GM), and tested by 

the University of Michigan Transportation Research Institute (UMTRI) (Ervin, et al., 2005a, 

2005b, 2005c; 1998). Shinar and Schechtman (2001) conducted a long-term experiment with 

teen drivers providing following-distance feedback. Finally, there have been two very recent 

following-distance feedback FOTs, one in Australia (the TAC SafeCar Project by Young, et al., 

in press 2006) and one in Europe (the Netherlands) using the COTS Mobile Eye system (Alkim, 

2006). 

122 
Table 33. Following Distance (Time-Gap) Driver Feedback Design in FOT Efforts 

COTS Device/FOT Visual Display Visual Warnings Auditory Warnings 

Eaton Vorad EVT-300 3 LEDs Horizontally 

Yellow/Amber/Red 

Yellow: Time-Gap 

> 2 s 

Orange: TG < 2 s 

Red: TG < 1 s 

Red: Collision 

Warning 

- Proximity: Double 

Beep 

- TG < 2 s: 

 Single Beep 

- TG < 1 s: Single 

Beep 

- TG < 0.5 s: 

Continuous 

- CollWarning: Single 

Beep 

ACAS FOT 

(GM; Ervin, 2005a, 2005b, 

2005c) 

- Looming Car Icon 

- 6 Stages: 1 Turquoise; 4 

Amber; 1 Red 

- Turquoise: 

Target Detected 

- Amber: 

Increasing Threat 

- Red Flashing: 

Imminent Coll. 

Constant Beeps at 

Imminent Threat Level 

Shinar and Schechtman 

(2001) 

Digital Time-Gap 

displayed in (s) 

Warning Icon at 

TG < 1.2 s 

Beep at TG < 0.8 s 

Australian TAC SafeCar 

(Young, et al., 2006) 

- Inverted Trapazoid 

- 3 Yellow Levels 

- 3 Red Levels 

- Yellow: TG > 1.3 

s 

- Red Flashing: 

TG < 1.3 s 

TG < 1.1 s 

Mobile Eye, Dutch Ministry of 

Transportation FOT (in 

Progress) 

- Digital Time-Gap 

displayed in (s) 

- Color Car Icon: 

Green/Amber/Red 

- Green: TG > 1.0 

s 

- Amber: 0.6 < TG 

< 1.0 s 

- Red: TG < 0.6 s 

- Flashing Red: 

Collision Warning 

- TG < 0.6 s: 

Single Beep 

- Collision Warning 

 Continuous Beep 

Although none of the FOTs used the haptic modality for warnings, there has been much research 

on haptic warnings, and there has been some success with the comprehension of haptic warnings 

for forward-collision warning applications (Kochhar and Tijerina, 2006). This study concluded 

that shaking the seat pan (and optionally the seat back) in unified pulses was mostly associated 

with a general urgency and directed the driver’s attention to the forward scene. 

OBMS Prototype Feedback Design 

The OBMS prototype used the COTS Eaton Vorad EVT-300 for forward-collision warning and 

auditory following distance alerts; however, since the EVT-300 had the most simplistic and 

nondescript visual interface (a series of three LEDs), the feedback was supplemented using the 

best aspects of the designs reviewed. As shown in Figure 30, a digital display of the following 

time-gap that was color-coded to a looming car icon was added. Similar to the recommended 

speed display, factors influencing the recommended following distance, such as road conditions 

or grade, were also displayed. 

123 
Figure 30. OBMS Prototype Following Time-Gap Visual Feedback Design 

The color-coding of the digital time-gap display (and corresponding vehicle icon) was based on 

two parameters. First, a minimum recommended following distance was computed based on a 

stopping distance that assumed that the truck and followed vehicle would start braking at the 

same time. If the following time-gap was less than the minimum plus 0.5 s for the truck driver 

reaction time, then flashing red (at 2 Hz) was used for the text color and icon. Solid red was used 

for less than 1.0 s of reaction time, amber for less than 2 seconds, and green for greater than 2 

seconds. When the collision warning system sounded, the red icon with the yellow crash was 

used, flashing at approximately 4 Hz. 

OBMS FOT Recommendations 

The following time-gap feedback display and algorithm may require some fine-tuning with 

actual truck drivers, especially in field conditions with heavy traffic to ensure that the display 

and algorithms meet their needs under nonfree flow conditions. The Eaton Vorad EVT-300 uses 

the most simplistic forward-collision warning algorithm and produces a greater number for false 

alarms than might be desired; however, it is the most common system found in trucks, so drivers 

may be more likely to be familiar with and tolerant of the system. Furthermore, since the 

following-distance feedback algorithm being used in the prototype’s visual display is more 

advanced than the one being used by the Eaton Vorad, there is the potential for a mismatch 

between the auditory and visual warnings. This potential mismatch may need to be addressed if 

drivers notice it or become confused by it. 

6.1.4. Monitoring Attention and Fatigue 

Research Summary and Design Comparison 

Inattention and fatigue generally result in two types of crashes, rear-end crashes and crashes 

resulting from a lane-departure. Since an FCWS (discussed earlier) is the typical countermeasure 

124 
associated with a rear-end crash, this section will only focus on lane-departure warning systems 

and direct or indirect detection of inattention and fatigue. 

Direct detection of inattention and fatigue requires driver eye, head, and/or face tracking. Until 

recently, the only COTS off-head fatigue detection monitor was produced by Attention 

Technologies (http://www.attentiontechnology.com/), consisting of a single infrared camera used 

for pupil monitoring and a driver display unit. While the system has a novel interface, providing 

both visual feedback of how far the vehicle traveled when the driver last closed his or her eyes 

and an audible alarm, the system only performs adequately at night. A new system, the Seeing 

Machines DSS-R or driver state sensor (http://www.seeingmachines.com/), is soon to be released 

in 2007. While also a single-camera system, the product provides for both daytime and nighttime 

operation and for limited attention (eyes-off-the-road) monitoring. 

For LDWSs, there are two COTS systems currently being manufactured, the SafeTRAC by 

Assistware (http://www.assistware.com/) and the Mobile Eye (http://mobileye-vision.com/). It 

should be noted that Iteris Inc. (http://www.iteris.com/) also supplies its AutoVue custom LDWS 

to vehicle manufacturers; however, they do not have a COTS aftermarket system. While the 

amount of research on LDWSs has been considerable, the most recent and comprehensive study 

is the currently ongoing Road Departure Warning System (RDWS) and Curve Speed Warning 

(CSW) FOT being conducted at UMTRI, which used the Assistware lane tracking sensor but 

their own custom DVI. Table 34 describes the lane departure DVI designs used by the various 

COTS systems and FOTs. 

Table 34. Lane Departure Driver Feedback Designs 

COTS and FOT 

LDWS 

Visual 

Warnings Auditory Warnings 

Haptic 

Warnings 

Fatigue 

Detection 

Assistware SafeTRAC Three-line graphic 

showing position 

within the lane 

Nondirectional 

- Single beep for 

lane change without 

turn signal use 

- Double beep 

for imminent LDWS 

None Fatigue 

Number 

(0-100) 

Mobile Eye Green flashing leftor right-lane lines 

drawn in 

perspective 

Directional 

- Rumble strip 

None None 

Iteris AutoVue Custom built Directional 

- Rumble strip 

Custom built None 

UMTRI 

RDWS FOT (using 

SafeTRAC with a 

custom interface) 

Two-Stage Icon 

- Yellow: Caution 

- Red: Imminent 

Directional 

- Buzz/Tone for 

second-stage imminent 

LDWS 

Directional 

- Seat 

vibration on 

first-stage 

cautionary 

alert 

None 

125 
OBMS Prototype Feedback Design 

The OBMS prototype used the Assistware SafeTRAC system for lane departure warning and 

fatigue detection. As shown in Figure 31, the visual provided by the device itself was very 

simplistic, consisting of a single line text display showing the fatigue number and a graphical 

display of the current position within the lane. The display could also show simple messages, 

such as “Get Rest,” if the fatigue number dropped below a specified threshold. For lane 

departure warnings, the system relied on a nondirectional beeps. 

Figure 31. COTS SafeTRAC Lane Departure Warning System DVI 

Compared to the other COTS LDWS devices on the market, and the state-of-the-art being testing 

in the current LDWS FOT, the SafeTRAC has, perhaps, an interface that that could be 

considered as less than minimally desired. To supplement the SafeTRAC’s COTS feedback, a 

visual indication of any detected lane departures was added to HHDD OBMS prototype display 

(figure 28). If a lane departure was detected by the system, either the right-or left-lane line 

flashed red (at ~4 Hz) for the duration of the event. 

Figure 32. OBMS Prototype Lane Departure 

Warning Visual Feedback Design 

126 
One final element relating to fatigue monitoring that could be added to the prototype OBMS 

display is an HOS remaining countdown. To keep the display from becoming too distracting, it 

should probably only include the driving start time, and a countdown of hours remaining, at least 

until the last 30 to 90 minutes, when minutes remaining would be more appropriate. 

Alternatively, the HOS remaining might be hidden on the main display and only appear in the 

last 30 to 90 minutes. 

OBMS FOT Recommendations 

In talks with potential trucking industry partners, it was mentioned that the COTS SafeTRAC 

device has been evaluated and dismissed by several trucking companies since the drivers found 

the system to be less than useful due to the fact that they could never understand what it was 

doing or telling them. These kinds of comments suggest that some effort should be spent to 

supplement the SafeTRAC’s feedback and warning interface, and bring it up to par with the 

current thinking on LDWSs. At minimum, this would mean modifying the system to add 

directional audio tones (or rumble strips). Haptic feedback could also be considered depending 

on the recommendations of the UMTRI FOT as it nears completion. 

It is also recommended that at least one sensor be added to the prototype to monitor fatigue and 

attention directly, such as the Seeing Machines DSS-R. The device was not available during the 

construction of the initial OBMS prototype, but will be explored during the FOT. A model for 

driver feedback with the device would follow the same lines at the feedback provided by the 

Attention Technologies fatigue monitor. Feedback and warnings for high PERCLOS (lengthy 

eye closures) and excessive eyes-off-the-road glances should be developed. 

Finally, some of the finer details, such as how to display the HOS remaining, could be 

effectively displayed in multiple ways. The initial stages of the FOT should get some early 

feedback from the drivers as to what their preferences might be. 

6.1.5. Monitoring Good Driving Safety Practice 

Research Summary and Design Comparison 

Two topics that fall into this category have had some documented research. First, on the issue of 

seat belt use, the TRB (2003) issued a comprehensive special report on safety belt technologies 

for passenger automobiles. In passenger cars, NHTSA regulates seat belt reminder design and is 

currently prohibited by law from requiring more than a visual display and auditory tone lasting 

four to eight seconds upon vehicle start-up; however, NHTSA is not expressly prohibited from 

allowing enhanced seat belt warnings. From a survey of several late model vehicles from Ford 

and Honda, the typical enhanced seat belt warning provides a six-second audible warning (and 

flashing seat belt icon) every 30 to 35 seconds once the vehicle’s speed exceeds 10 to 15 mph. 

Such regulations do not exist with commercial trucks; however, this reported practice may lead 

to driver safety and could be considered. 

A second issue covered in this section is turn signal use during lane changes. Although merely a 

footnote, most studies involving lane departure warning and side-obstacle detection systems 

report that turn signal use during lane changes increased as a side effect of having these systems. 

127 
OBMS Prototype Feedback Design 

Four monitored parameters were classified into the category of general good driving safety 

practice: seat belt use, lane change signal use, mirror adjustment, and side-collision avoidance or 

blind spot warning. The side collision avoidance system used was the Eaton Vorad Blindspotter 

warning system that came factory-installed in the truck. The display consisted of a set of two 

LEDs mounted inside the vehicle on the A-pillars near the side mirrors. The bottom LED was 

continuously yellow, indicating that no object was detected. When an object was detected, the 

top LED illuminated red. To supplement the factory display, side-object awareness icons were 

added to the prototype HHDD display (Figure 33) since there has been some research to suggest 

that this location would be ideal as a supplementary display for the side-obstacle detection icons 

(Olsen, 2004). These icons would illuminate if the driver put on the turn signal when an object 

was detected in a blind spot (accompanied by an audible beep provided by the factory system 

installation). 

Figure 33. OBMS Prototype Visual Feedback Design for Seat Belt and Side Obstacles 

The seat belt monitoring system used the standard seat belt warning icon displayed on the OBMS 

prototype HHDD (as access to the factory seat belt warning system was unavailable). The system 

functioned in the same manner as other automotive enhanced seat belt warning systems, flashing 

the icon in accompaniment with an auditory tone for six seconds every 30 seconds when the 

vehicle exceeds 15 mph. 

Turn signal use during lane changes was not displayed visually in real-time, but lane changes 

made without turn signal use would cause the SafeTRAC to emit a single beep. Feedback for 

monitoring mirror adjustment is proposed as a simple “check mirror adjustment icon” that comes 

on next to the seat belt icon whenever a new driver enters the vehicle and inserts his driver ID 

card. The icon would be turned off as soon as the driver adjusted the right power mirror. 

128 
OBMS FOT Recommendations 

Other convenience and reporting features may need to be added based on driver feedback; for 

example, some companies may be interested in fuel economy, maximum engine RPMs, or other 

engine parameters which could easily be incorporated into the DVI. 

6.1.6. Offline Feedback and Reporting 

The bulk of the interface design has focused on the real-time, in-cab feedback for the driver; 

offline feedback and summary reporting will still need to play an integral role in any successful 

driver monitoring and feedback program. The purpose of the offline feedback and summary 

reporting is two-fold. First, the offline feedback supplements the real-time feedback, as there are 

some measures of driving performance that may only be useful when summarized over time or 

compared across drivers. Second, the summary reporting needs to convey the results of the driver 

monitoring to management, allowing for the identification of which drivers need improvement in 

which areas. 

Two monitoring parameters that will primarily use offline feedback include hard-braking and 

hard-steering incidents. For either parameter, a single incident alone may not be significant, but a 

pattern of repeated incidents might indicate an underlying problem, such as aggressive driving or 

excessive inattention. 

The frequency of offline feedback summary and reporting could vary from weekly to monthly, 

although some measures, such as hard-braking incidents, may require averages over a longer 

time period to produce a useful and reliable metric. Some of the parameters may require 

additional filtering or comparing across drivers to produce a useful and reliable metric. As an 

example, the Eaton Vorad EVT-300 produces numerous false alarms in real-world driving 

conditions, so simply looking at the number of forward-collision warning alerts would probably 

not provide any useful information about how safe a particular driver was without comparing 

that driver to others. 

As discussed earlier and as detailed in Sherry (2001), the behavior-based safety approach to 

onboard driver-monitoring requires four steps, with this report focusing primarily on steps one 

and two: 

1. Identify behaviors which may be precursors to increased crash rates. 

2. Determine cost-effective ways to monitor safe and unsafe behaviors. 

3. Determine the best way to provide the driver with feedback which rewards safe behavior 

and discourages unsafe behavior. 

4. Establish management and driver acceptance to the program. 

The offline feedback and summary reporting design feeds into steps three and four and should be 

designed with the input of an actual truck carrier (FOT partner) as part of a comprehensive safety 

monitoring and feedback program. There are numerous issues in the design of such a program 

that would need to be addressed, including the format of the report, who will receive and have 

access to the reports, and how the reports will be used. 

129 
6.1.7. Incident Recording and Review 

Related to the offline feedback and summary reporting is the issue of how to deal with recorded 

incidents. While the system will record, save, and sort incidents (such as speeding, hard braking, 

hard steering, and seat belt nonuse), a program with the carrier will need to be established to 

review these incidents Such a program might involve driver self-review of incidents, 

management or safety officer review of incidents, or a combination of both. The details of the 

program will depend heavily on the corporate culture of the carrier. Such an incident review 

program will require software to download the saved incidents from the trucks and transfer them 

to a centralized server, categorize the incidents, and provide a tool to select and playback the 

video and associated vehicle data. 

REFERENCES (SECTION 6) 

Alkim, T(2006) The Assisted Driver Interim Results Presentation at the International Task Force 

on Vehicle-Highway Automation Meeting (London) Den Haag, Netherlands: Dutch Ministry 

of Transport, Public Works, and Water Management. 

Brookhuis, K., and de Waard, D(1999) Limiting speed, towards an intelligent speed adapter 

(ISA) Transportation Research F, 2, 81-90. 

Ervin, R., Sayer, J., LeBlanc, D., Bogard, S., Mefford, M., Hagan, M., Bareket, Z., and Winkler, 

C(2005) Automotive Collision Avoidance System FOT Methodology and Results Volume 1 

(Technical Report UMTRI-2005-7-1) Ann Arbor, MI: The University of Michigan 

Transportation Research Institute. 

Ervin, R., Sayer, J., LeBlanc, D., Bogard, S., Mefford, M., Hagan, M., Bareket, Z., and Winkler, 

C(2005) Automotive Collision Avoidance System FOT Methodology and Results Volume 2: 

Appendices (Technical Report UMTRI-2005-7-1) Ann Arbor, MI: The University of 

Michigan Transportation Research Institute. 

Ervin, R., Sayer, J., LeBlanc, D., Bogard, S., Mefford, M., Hagan, M., Bareket, Z., and Winkler, 

C(2005) Automotive Collision Avoidance System FOT Methodology and Results (Technical 

Report UMTRI-2005-7-2) Ann Arbor, MI: The University of Michigan Transportation 

Research Institute. 

Kochhar, Dand Tijerina, L(2006) Comprehension of Haptic Seat Displays for Integrated Driver 

Warning Systems Proceedings of the Human Factors and Ergonomics Society 50th Annual 

Meeting Santa Monica, CA: 2395-2399. 

Neurauter, L(2004) Multidimensional warnings: Determining and Appropriate Stimulus for a 

Curve-Warning Device (Maser’s Thesis) Blacksburg, VA: Virginia Polytechnic Institute and 

State University. 

Olsen, E(2004) Lane Change Warning Design Guidelines Proceedings of the Human Factors and 

Ergonomics Society 48th Annual Meeting Santa Monica, CA. 

Sherry, P(2001) In-Vehicle Monitoring Technologies: Review of Current Use and Potential 

Enhancement Through Behaviorally Based Safety Processes (Report Submitted to the 

American Trucking Association Foundation) Denver, CO: The University of Denver. 

Shinar, Dand Schechtman, E(2001) Headway feedback improves inter-vehicular distance: a field 

study Human Factors, 44(3), 474-481. 

130 
Transportation Research Board (2003) Buckling Up: Technologies to Increase Seat Belt Use 

(Special Report 278) Washington, D.C.: National Academes of Science. 

Várhelyi, Aand Mäkinen, T(2001)The effects of in-car speed limiters: field studies 

Transportation Research C, 9, 191-211. 

Várhelyi, A., Hjälmdahl, M., Hydén, C., and Draskóczy, M(2004) Effects of an active 

accelerator pedal on the driver behaviour and traffic safety after long-term use in urban areas 

Accident Analysis and Prevention, 36, 729-737. 

Young, K., Regan, M., Triggs, T., Tomasevic, N., Stephan, K., and Mitsopoulos, E(2006 

Manuscript) Impact on Car Driving Performance of a Following Distance Warning System: 

Findings from the Australian TAC SafeCar Project (Manuscript submitted for publication in 

the Journal of Intelligent Transportation Systems). 

131 
7. FOT PLANNING 

An activity planned and conducted during this study was to leverage the expert interviews, 

research conducted, and—it was hoped—a carrier stakeholder into a FOT plan, for further 

development and turn a research-focused initial implementation of an OBMS system into a field 

trial. The purpose of this activity was to set the foundation for a follow-on effort to essentially 

propagate and test OBMS ideas in a larger, real-world setting. 

As it turned out, the initial carrier contact, who had enthusiastically participated with the OBMS 

research and prototype development team, was less forthcoming in co-developing an FOT plan. 

Hence, this FOT plan was largely developed by the research team, bereft of the all-important 

operational and pragmatic knowledge base of a carrier. This was redressed quite well at the end 

of the project, as a different carrier was quite engaged and committed at that stage; however, the 

FOT developed and planned will have to undergo revision to adjust to this particular carrier’s 

needs, knowledge, and operational philosophy. 

The FOT development and testing is envisioned to be conducted using a systems engineering 

approach and process following the guidelines of the Systems Engineering Guidebook online at 

http://www.fhwa.dot.gov/cadiv/segb, and will use the vee technical model diagramed in . It is 

envisioned that the project will include a large number trucks, possibly as many as two hundred, 

and will take place over a period of 48 months commencing in FY08. Within this time period, 

the formal FOT is expected to be conducted over 18-month period consisting of two parts: a pilot 

test and the final FOT observations. It is expected that in the end, the resulting outcome of how 

an OBMS would be integrated into carrier operations and be accepted by stakeholders (e.g., 

carrier, driver, safety community that would include State and Federal governments) would be 

understood, as well as be valued. This will allow carriers and other potential users and 

stakeholders to determine the effectiveness vis-à-vis costs. 

132 
Figure 34. Systems Engineering Vee Diagram Illustrating Sequence of 10 Tasks to Complete FOT 

The FOT plan developed prior to this end-of-project interaction is an interesting layout of initial 

ideas for such a test. It is worth noting that one very important and well-developed aspect of the 

FOT plan is driver feedback, which is discussed to considerable extent in section 3.0. Part of the 

development of section 3.0 stemmed from considerations and feedback, particularly from 

FMCSA, on what attributes should be monitored in real-time and postfacto by the carriers. This 

discussion and consideration of the monitored parameters is encapsulated in Table 35. 

Table 35. Attributes To Be Monitored and Associated Feedback Methods 

Core 

Behavioral 

Categories 

Potential Behaviors/ 

Parameters 

To Be Monitored 

Required 

Sensors or 

Subsystems 

Potential Driver 

Feedback 

Real-Time 

Potential Driver 

Feedback 

Offline 

1. 

Speed 

Selection 

Speed versus: 

- Speed Limit 

- Traffic Flow 

- Curve Speed 

- Road Surface 

- Grade 

Vehicle J-bus Access 

GPS 

Database of Speed 

Limits 

Road 

Surface/Weather 

Radar or Lidar 

Accelerometer 

Visual feedback of 

recommended and 

maximum speed limits 

Summary metrics such 

as the time spent over 

the recommended and 

maximum speed limits 

2. 

Following 

Behavior 

Following Distance 

Forward-Collision 

Warnings 

Driver Response to 

Cut-ins 

Forward-Collision 

Warning System 

(FCWS) 

Radar or Lidar 

Video Recording 

Visual feedback of 

following time-gap 

shown 

Auditory alerts for 

following too closely 

and approaching too 

fast 

Summary of time spent 

following too closely, 

number of warning 

incidents, video review 

of warning incidents 

133 
Core Potential Behaviors/ Required Potential Driver Potential Driver 

Behavioral 

Categories 

Parameters 

To Be Monitored 

Sensors or 

Subsystems 

Feedback Feedback 

Real-Time Offline 

3. 

Attention 

(or 

Inattention) 

Road/Lane 

Departures 

Hard Braking Events 

Hard Steering Events 

Eye-Off-the-Road 

Road Departure 

Warning System 

(RDWS or LDWS) 

Accelerometer 

Steering Angle 

Steering Gyro 

Video Recording 

Eye/Face Tracking 

Visual and auditory 

alerts of lane 

departures or eyes-offthe-road for too long 

Summary metrics such 

as the frequency of lane 

departures, hard 

braking, and hard 

steering incidents 

4. 

Fatigue 

Road/Lane 

Departures 

Lane Position 

Keeping 

Hard Braking Events 

Hard Steering Events 

Eye Closure 

(PERCLOS) 

Hours of Service 

(HOS) Compliance 

RDWS/LDWS 

Eye Tracking 

Accelerometer 

Steering Angle 

Steering Gyro 

Video Recording 

EOBR (Electronic 

Onboard Recorder for 

HOS) 

Visual and auditory 

alerts of lane 

departures, lane 

weaving, eye closure, 

and HOS compliance 

Summary metrics such 

as the frequency of lane 

departures, hard 

braking, hard steering 

incidents, and HOS 

compliance 

5. 

General 

Safety 

Safety Belt Use 

Lane Change Turn 

Signal Use 

Lane Change Blind 

Spot Check 

Proper Mirror 

Adjustment 

Fuel Economy 

Engine Overspeed 

(RPMs) 

Acceleration 

Deceleration 

(Downshifting) 

Gear selection on 

grades 

Safety Belt Monitor 

Video Recording 

RDWS/LDWS 

Eye/Face Tracking 

Accelerometer 

Vehicle J-bus Access 

MiscWire Taps 

Visual and auditory 

alerts if safety belt is 

not use 

Visual feedback on 

other parameters 

Summary metrics such 

as time spent using the 

safety belt and the other 

listed parameters 

134 
8. SUMMARY AND CONCLUSIONS 

The OBMS prototype development was based upon prior research which points to progression of 

four steps toward implementing an onboard driver-monitoring, behavior-based safety approach. 

1. Identify behaviors which may be precursors to increased crash rates. 

2. Determine cost-effective ways to monitor safe and unsafe behaviors. 

3. Determine the best way to provide the driver with feedback which rewards safe behavior 

and discourages unsafe behavior. 

4. Establish management and driver acceptance to the program. 

This project did not complete, nor was it designed to complete, the four steps, each in their 

entirety; rather, the project did a thorough review—and where possible, expert interviews with a 

carrier—to implement a prototype that addressed steps 1–3. Step 4 would require strong carrier 

participation and, ideally, an FOT, which was also covered in this project and described in 

section 7.0. 

The project was tailored to and performed with the principles of systems engineering. The 

nomograph shown in illustrates the project tasks, conducted down along the left side, then across 

the vertex of the vee diagram, then up to the low-speed testing, through the horizontal dashed 

line, to the environs of the PATH facility of the Richmond Field Station, which includes public 

roads outside the premises. 

135 
136 

On-Board Monitoring to Improve 

Commercial Motor Vehicle Safety 

(OBMS) 

CG10 

CG9 

Field Operational Evaluation 

Plan

OBMS System Verification Plan 

(System Acceptance) 

CG1 

Control Gates 

Phase 3 

Deployment 

Phase 2 

Field Operational 

Test 

CG8 

High Speed 

Evaluation

Low Speed 

Evaluation

Crows Landing ?? 

Richmond Field 

Station 

OBMS SS 

Evaluation

CG7 

CG2 

CG3 

CG4 

CG5 CG6 

SW/HW 

Evaluation Level

Software Coding 

Hardware Fabrication 

Bench/On-Board Installation 

Planning 

Integration 

Deployment 

Development 

Installation 

Verification 

Procurement 

Causal Study 

Human Factors 

OBMS - ConOps 

OBMS SS 

Requirements 

OBMS SS 

ConOps 

OBMV SS 

Requirements/Final 

Architecture 

OBMS 

SW/HW 

Detailed Design 

Safety Sub-Systems 

Verification Plan 

SW / HW 

Verification 

CG1 – Planning Framework, Stakeholders Identified, Long Haul Carrier 

CG2 – Approve ConOps 

CG3 – Approve System Requirements 

CG4 – Approve Subsystem Req 

CG5 – SW/HW Detailed Design Review 

CG6 – On-board sub-system integration 

CG7 – On-board Unit Verification 

CG8 – On-board SS Verification 

CG9 – TSS Verification – Approve FOT 

CG10 – Approve Deployment 

SW/HW = Software & Hardware 

COTS 

Sensors 

Alarm 

Evaluation 

Concept Exploration 

Alternative Architectures 

Measures of Effectiveness 

Measures of Merit 

Risk Identification 

External Interfaces Identified 

Deployment Plan 

Procurement Plan 

= Detailed 

Integration Plan 

Installation Plan 

Development Plan 

External Interfaces 

Internal Interfaces 

Defined and Documented 

Project Management 

Risk Monitoring 

Configuration Management 

(Through-out the Development) 

Figure 35. Vee Diagram of Project 
The resulting hardware and software that constitute the prototype OBMS is described in block 

diagram form in Figure 36 (and more fully, in sections 4.0 and 5.0). Suffice it to say that 

monitored driver behaviors are clustered into five monitoring categories or behaviors: 

1. Speed Selection 

2. Following Behavior 

3. Attention (or Inattention) 

4. Fatigue 

5. General Safety 

Figure 36. Block Diagram of OBMS Prototype PC104 and Sensor Interfaces 

The resultant suite, with functions, monitored elements and feedback attributes is given in Table 

36. To underscore, this prototype suite is unique in that it is aimed squarely at safety and not 

necessarily toward other fleet operational goals; however, the overall philosophy is that it is an 

operational imperative to reduce crashes and, therefore, fatalities, injuries, and property damage 

due to CMV drivers. The main means to lower the amount of CMV driver errors is to improve driver 

performance through OBMSs, coupled with appropriate feedback to the driver. This project 

therefore served as a foundation to illustrate how to design and build an onboard monitoring that 

may provide the best, lasting mechanism to encourage good driving behavior by recognizing and 

correcting self-induced hazardous driving situations 

137 
Table 36. Summary of OBMS Suite: Functions, Monitored Elements, Feedback 

Core 

Behavioral 

Categories 

Potential 

Behaviors/ Parameters 

To Be Monitored 

Required 

Sensors or 

Subsystems 

Potential Driver 

Feedback 

Real-Time 

Potential Driver 

Feedback 

Offline 

1. 

Speed 

Selection 

Speed versus: 

- Speed Limit 

- Traffic Flow 

- Curve Speed 

- Road Surface 

- Grade 

Vehicle J-bus Access 

GPS 

Database of Speed Limits 

Road Surface/Weather 

Radar or Lidar 

Accelerometer 

Visual feedback of 

recommended and 

maximum speed 

limits 

Summary metrics 

such as the time 

spent over the 

recommended and 

maximum speed 

limits 

2. 

Following 

Behavior 

Following Distance 

Forward-Collision Warnings 

Driver Response to Cut-ins 

Forward-Collision Warning 

System (FCWS) 

Radar or Lidar 

Video Recording 

Visual feedback of 

following time-gap 

shown 

Auditory alerts for 

following too closely 

and approaching too 

fast 

Summary of time 

spent following too 

closely, number of 

warning incidents, 

video review of 

warning incidents 

3. 

Attention 

(or 

Inattention) 

Road/Lane Departures 

Hard Braking Events 

Hard Steering Events 

Eye-Off-the-Road 

Road Departure Warning 

System (RDWS or LDWS) 

Accelerometer 

Steering Angle 

Steering Gyro 

Video Recording 

Eye/Face Tracking 

Visual and auditory 

alerts of lane 

departures or eyesoff-the-road for too 

long 

Summary metrics 

such as the 

frequency of lane 

departures, hard 

braking, and hard 

steering incidents 

4. 

Fatigue 

Road/Lane Departures 

Lane Position Keeping 

Hard Braking Events 

Hard Steering Events 

Eye Closure (PERCLOS) 

Hours of Service (HOS) 

Compliance 

RDWS/LDWS 

Eye Tracking 

Accelerometer 

Steering Angle 

Steering Gyro 

Video Recording 

EOBR (Electronic Onboard 

Recorder for HOS) 

Visual and auditory 

alerts of lane 

departures, lane 

weaving, eye 

closure, and HOS 

compliance 

Summary metrics 

such as the 

frequency of lane 

departures, hard 

braking, hard 

steering incidents, 

and HOS 

compliance 

5. 

General 

Safety 

Safety Belt Use 

Lane Change Turn Signal Use 

Lane Change Blind Spot 

Check 

Proper Mirror Adjustment 

Fuel Economy 

Engine Overspeed (RPMs) 

Acceleration 

Deceleration (Downshifting) 

Gear selection on grades 

Safety Belt Monitor 

Video Recording 

RDWS/LDWS 

Eye/Face Tracking 

Accelerometer 

Vehicle J-bus Access 

MiscWire Taps 

Visual and auditory 

alerts if safety belt is 

not use 

Visual feedback on 

other parameters 

Summary metrics 

such as time spent 

using the safety 

belt and the other 

listed parameters 

138 
APPENDIX A: 

SYSTEMS ENGINEERING PROCESS AND CHRONOLOGY 

This section describes the systems engineering efforts undertaken as a part of the OBMS project. 

Emphasis is placed on some of the most important project processes identified in systems 

engineering, including integration, configuration management, verification, and risk 

management. These terms are defined in relevant subsections. 

It is noted that the application of the systems engineering vee diagram previously shown in 

Figure 30 dictates a research-development-prototype cycle with concomitant systems 

documentation. Because the resources to do this were lean, some of the documentation was 

sparse; in other cases, particularly in the tradeoff basis for our down selection of OBMS 

components, the documentation is necessarily extensive. In this section, examples are shown of 

diagrams and tables that project team members developed to track progress related to integration, 

configuration management, verification, and risk management processes in order to illustrate the 

tools and sequences used in this project and to provide, in abstract form, a foundation to 

understand the OBMS prototype. The Systems Engineering Management Plan (SEMP) and 

system requirements documents are also provided to further demonstrate the project team’s work 

in the area of systems engineering. As such, the bulk of our OBMS documentation can be found 

in previous sections, and in particular Section 2: Onboard Monitoring Concept Development and 

Section 4: Prototype System. 

A.1. INTEGRATION 

In the language of systems engineering, integration is a term used to describe the combining of 

components or subsystems to form a complete functional end-product system. Hardware and 

software components must be identified or constructed, and connected to one another. Planning 

is essential, both before and during the development of the component subsystems. Unforeseen 

difficulties connecting component pieces of a project can yield old plans obsolete, and a dynamic 

approach is needed for integration. 

Integration was especially important for this project, as the project consisted of combining data 

from the truck serial buses, various COTS products, and custom-built devices that were mounted 

on a truck, processing the data both on the truck itself and offline, and providing feedback to 

truck drivers. Links had to be forged between the various sensors and an onboard computer, 

between the computer and driver interface devices, and between the computer and an offline 

analysis module. 

Figure 37 provides a broad overview of the subsystems that had to be integrated for this project. 

Arguably, the most daunting challenge of this project was linking a comprehensive suite of 

COTS and custom-built sensors to a computer installed on the tractor. Different component 

sensors required different hardware connections. For instance, COTS lane tracking systems 

could be connected directly to the serial ports of a computer, whereas cameras that the project 

team purchased needed to be linked to MPEG encoder cards. Even ensuring that the onboard 

computer recognized the various computer cards attached to it was complex. Coordination 

139 
discussions had to be held to determine which cards worked with which computer operating 

systems, and which operating systems could be installed on the onboard computer. 

Communications were crucial here, and weekly meetings were set up to check the progress of 

integration efforts and to plan future integration related tasks. 

Sensors 

Removable 

Hard Drive 

Onboard 

Computer 

Analysis 

Module 

Onboard truck Offline 

Driver 

Interfaces 

Driver 

Reports 

Figure 37. Top-Level Overview of Integrated Components 

Figure 34 depicts how a handful of sensors were connected to the onboard computer and 

removable hard drive used in this project. At the start of this project, a similar set of tentative 

hardware connections were drawn up. As the project proceeded, it became apparent that certain 

sensors would not be used on the experiment test truck, possibly because the hardware 

connections could not be made or possibly because the functionality these sensors offered was 

deemed unnecessary. Plans had to be altered on-the-fly. 

The integration process progressed along the vee diagram; however, the iterative, experimentally 

oriented tradeoffs to complete the design and installation progressed to a series of weekly 

progress meetings, which were informed by very rough block diagrams, like the one presented in 

Figure 38, and spreadsheets containing information about the status of efforts to link various 

system components. Discussions were also held at these weekly meetings related to 

configuration management, verification, and risk management efforts. 

140 
Front radar Serial Port 

Expansion Removable 

Figure 38. Overview of Hardware Integration Components/Topics 

A.2. CONFIGURATION MANAGEMENT 

Configuration management ensures that project documentation is consistent with the 

characteristics of the system under development. Like integration, configuration management is 

a process that must be ongoing throughout the life span of a project. As changes are made to the 

system, documents must change as well. 

For this project, as decisions were made about which sensors could and would be used on the test 

truck, the data that would be available also changed. Software had to adapt to reflect changing 

information. Figure 39 shows the final state of connections made by the software, using sensor 

data to track items of interest for potentially generating warnings that would require 

communicating with a driver interface device or generating a driver report. So, the suite of 

sensors generating data was changing, as were the software monitoring this data and the 

feedback mechanisms through which the system communicated with the driver. This constant 

change required a concentrated effort in the area of configuration management. 

Hard Drive 

PC104 

Computer 

Card 

Digital 

Input/Output 

Card 

Lane tracker 

Analog/ 

Digital 

Converter 

Card 

Ignition on signal 

Mirror adjustment 

Turn signal 

Brake pressure 

Accelerometer 

Steering angle 

Front camera 

MPEG 

Encoder 

Card 

Radar (side units) 

Driver camera 

141 
Evidence of the project team’s efforts in the area of configuration management can be seen in the 

changing Systems Engineering Management Plan (SEMP) associated with this project. There 

was not always time to document decisions made and changing plans; however, the project team 

made sure to update the SEMP so that it reflected the evolving project. The final version of the 

SEMP is included in Appendix B. 

A.3. VERIFICATION 

Verification is the process by which the project team ensures that the system, as it is being built, 

meets the requirements. Appendix C contains the System Requirements Document developed by 

the project team, stemming from the ConOps. This document was referred to time and again 

during the verification process. As was the case for the other processes identified above, much of 

the project team’s efforts in verification centered on weekly meetings. Below is a list extracted 

from documents related to verification efforts, with each of the “test item” columns consisting of 

a verification task. 

• Radar calibration: long/lat distance; long/lat speed 

• Lidar calibration: long/lat distance; long/lat speed 

• IMU calibration: roll and yaw rate; lat accelerometer examination 

• Tilt sensor for road grade 

• Road surface detection sensor 

• NAVTEQ System: road curvature forecasting; GPS 

• Integrate with feedback to the driver: following too closely in normal weather and tilt 

sensor for road grade; overspeed in normal weather based on NAVTEG information 

about speed limit 

• roll stability warning in normal weather 

• roll stability warning in normal weather: on the curve 

• roll stability warning in normal weather: begin to roll 

• multiple target tracking 

• following too closely with weather factor and road grade incorporated 

142 
Figure 39. Functional Relationships Between Sensor Data and Monitoring System 

143 
A.4 RISK MANAGEMENT 

Risk management as a term is fairly self-explanatory. The goal of the risk management process 

in systems engineering is to recognize, plan for, and mitigate the impacts of risk during project 

development. Risk management is closely related to verification and integration. Major risks 

often have to do with the prospect of subsystems failing to be integrated into a larger system, or 

failing tests run as a part of verification efforts. The risk management plan is provided with in the 

SEMP given in Appendix B. 

144 
APPENDIX B: 

SYSTEMS ENGINEERING MANAGEMENT PLAN 

FOREWORD 

This document outlines the Systems Engineering Management Plan (SEMP) for the OBMS 

PATH project. The onboard monitoring and reporting for commercial motor vehicle safety 

(OBMS) project started as a research effort that defines the concept of an integrated safety 

monitoring system and turns it into a prototype. This will be followed closely by an FOT, for 

which a plan will be specified during the research phase. The SEMP spells out the systems 

engineering process that will be applied as well as the project plan. 

B.1. INTRODUCTION 

B.1.1. Project Summary 

The University of California Partners for Advanced Transit and Highways (PATH) and the 

California Center for Innovative Transportation (CCIT), both part of the Institute of 

Transportation Studies (ITS), collaborated on this project to improve truck safety via onboard 

monitoring and reporting of variables that may precede crashes. This project was funded by the 

Federal Motor Carrier Safety Administration (FMCSA) through the California Department of 

Transportation (Caltrans). Both are considered project stakeholders. 

If the prototype can demonstrate a significant potential to reduce truck accidents, the following 

steps will be an attempt to turn the prototype into a commercially available product. One of the 

reasons for CCIT’s involvement was to prepare this deployment stage. 

B.1.2. Document Scope 

The SEMP describes the systems engineering approach applicable to the project and presents the 

work plan. The SEMP is intended as a project roadmap that the project team and the project 

sponsor can refer to. It spells out what the project team will do and how they will accomplish it. 

The document is divided into subsections; the first one (B.2) describes the systems engineering 

process itself in the context of this project. In particular, it shows how the environment and the 

constraints surrounding this project have shaped the planning of the workflow. The next 

subsection (B.3) presents each engineering discipline applicable to the project, and how the 

activities of these disciplines fit into the development process as a whole. The engineering 

specialties are the human factors, the hardware engineering, the software engineering, the data 

intelligence, and the experiment design, plus the added disciplines of systems engineering and 

product deployment. 

The rest of the subsections document the overall project plan and includee the scope of work, the 

schedule, the deliverables, the project resources, and the project management structure. 

145 
B.1.3. Applicable Documents 

• California PATH, Statement of Work, OBMS – June 2005. 

• California PATH, Kick-off meeting slide show, OBMS – June 2005 

B.2. SYSTEMS ENGINEERING PROCESS 

B.2.1. Process Intent and Overview 

This project involves a multidisciplinary team and a commercial partner yet to be determined. Its 

main deliverable will be a functioning prototype of an onboard monitoring system that processes 

inputs from various truck sensors and outputs safety metrics and warnings that are fed back to 

the drivers. 

Because the prototype will be a complete system with hardware and software components built 

for an operational environment with which it will interact tightly, it is appropriate to use a 

systems engineering framework. The systems engineering process intends to ensure that the 

research product will be the result of a concerted effort to derive design and development from 

well-defined requirements, and to harmoniously integrate the different engineering disciplines. 

The ultimate goal of this project is to turn over the prototype to the industry so that truck carriers 

can benefit from enhanced safety features that could reduce the number of crashes and fatalities. 

Systems engineering will enable the transition from research to industry by forcing a rigorous 

and well-documented development process from the early stages. If a deployed commercial 

system is considered the ultimate outcome of the OBMS research, then this project is the first 

iteration in a more global product development process. 

While the expectation that the project delivers a functioning system underlines the needs for a 

systems engineering process, some adjustments had to be made. First of all, the project is 

considered research and its outcome is a prototype. This means that the risks and uncertainties 

are usually higher than at the product development stages. Second, the project timing happens to 

be tight, given the complexity of the task at hand. These two observations influenced the systems 

engineering process presented in the next subsections. 

B.2.2. Product Development Steps 

This project uses the traditional vee diagram to define cascading stages in the development 

process. While this diagram and its specific representation in Caltrans’ guidelines for ITS 

systems engineering were used as a baseline, simplifications were made based on the nature of 

the project. 

As already mentioned, this phase intends to develop a prototype and not the finished product. 

Moreover, the research aspect entails an exploratory component that is not always compatible 

with the stiffness of the systems engineering development process. 

This led the project team to consider what in the cascading process was really of importance to 

the ultimate success of the research. The research will be successful if: (1) the prototype 

146 
demonstrates some potential safety benefits and if, as previously stated, (2) it can be handed off 

after the Phase II FOT to the industry for widespread deployment. The systems engineering 

process has only limited ability to realize the first part of this proposition. On the other hand, the 

subsequent deployment to the industry will be greatly facilitated if documentation is readily 

available to allow building on top of the prototype. On a side note, if the first iteration of this 

research meets tough challenges, it will also be much easier to track down what went wrong, 

whether it is the implementation or the realization that the research is not looking in the right 

direction. 

As a result, what was deemed essential to this development process was: 

• A detailed ConOps 

• The system requirements 

• The system design 

• The verification of the system’s features and attributes 

On the other hand, the distinction between high-level design and detailed design, or a thorough 

and staged validation of each subsystem, will not be documented. The outcome of this decision 

is that the amount of documentation will be slightly less than a formal systems engineering 

approach would normally recommend. 

With the aforementioned provisions, the systems engineering process for this project will apply 

the framework of the vee diagram. This means that, starting with the ConOps, the project team 

will gradually define and implement the system. Subsequently, the system will be tested and 

verified. Figure 40 represents the overall vee diagram for this project. Note that the FOT is 

shown in white. This reflects the fact that the FOT is not a part of this project, but rather a 

complement to it. Although its definition belongs to the current project, the project team will 

stop at the verification stage. 

147 
Figure 40. Vee Diagram 

148 
Referring to Figure 40, the systems engineering steps for this project are as follows: 

• ConOps: outlines how the system operates in its intended environment and justifies why 

it can address the problem statement 

• Requirements Definition: the requirements clarifies, in more detail, what the system has 

to accomplish and spells out the performance targets 

• System Design: the system design documents how the system is going to be built, based 

on requirements. It includes the system architecture and the detailed design of individual 

subsystems. 

• Implementation: the fabrication of the system and its subsystems 

• Components Testing: tests individual subsystems to ensure that they function properly 

and that they conform to the design 

• System Verification: overall acceptance test for the assembled system, in order to verify 

how well it meets the requirements 

Each of these steps defines a corresponding control gate. Control gates refer to stages in the 

project where stakeholders get a chance to formally review project deliverables and agree on 

whether or nor the project team should proceed to the next systems engineering step. For this 

project, the control gates will take the form of review meetings with the Caltrans project manager 

and the FMCSA stakeholders. Meetings may take place in person or over the phone, depending 

on the circumstances. The project team will deliver applicable documents and other deliverables 

for review meetings one week before the meeting. Control gates and their corresponding 

meetings are tentatively scheduled in the overall work plan. 

B.2.3. Sequence of Implementation 

A second consideration in adjusting the systems engineering nominal development process was 

the tight timeframe allocated to the project. This essentially means that the development process 

cannot be linear. It should rather try to maximize the available time by conducting some of the 

tasks in parallel. In this area, the project team attempted to think creatively about the systems 

engineering process. Although both a ConOps and some clear requirements need to be 

formulated for this project, they will only impact part of the product design. This stems from two 

reasons: (1) the basic requirements are already known: there needs to be an onboard computer 

that can read sensor inputs which are relevant to safe driving behavior and (2) PATH has already 

successfully implemented very similar systems in the past. Based on these observations, one can 

say that one-third of the system is already known from the project team, this said without in any 

way limiting the range of potentialities for the prototype. 

As a result, the systems engineering process for this project considered a “core” of components 

that are known to be part of the system to be developed, regardless of the decisions made in the 

ConOps. For these core subsystems only, the design can start almost immediately and funnel into 

implementation as needed, on a faster track than for the rest of the subsystems. This allows a 

spreading of some of the engineering resources over a longer period of time and provides 

flexibility in the schedule. 

Another acceleration step that was taken by the project team is an early start for the investigation 

of existing COTS sensors. Because most of the onboard sensors will be COTS or slight 

149 
modifications thereof, and because there is not such a vast market, it is appropriate to start 

reviewing sensors regardless of what the requirements will say. This will essentially provide 

more schedule flexibility for the hardware group, freeing resources for the later stages. 

The acceleration steps, namely the parallel track for the core subsystems and the early COTS 

investigation, is depicted in Figure 41. 

Figure 41. Vee Diagram Acceleration 

Finally, it should be noted that even though the FOT is not part of the present project, a task will 

be devoted to generating an overview of an FOT plan. Because the specifics of the FOT will be 

affected by multiple factors that will unfold throughout the project, the execution of the 

corresponding task will be kept relatively independent from the rest of the project. A major 

requirement of the FOT and of some of the tasks in the current project is the determination of the 

partner carrier. This should be tackled early in the project. 

B.3. ENGINEERING DISCIPLINES AND INTEGRATION 

This project will require the integration of multiple engineering disciplines. This section outlines 

these disciplines and shows what their respective contributions to the project will be. In order to 

control the integration of these disciplines as plans are developed and changes are made, a 

configuration management process will be applied. This process is described in subsection B.5, 

Technical Plans. 

The OBMS project includes the integration of five engineering specialties. The following bullet 

points provide a short description of each of them: 

• Human factors: Human factors are the core-science of this project. Most accidents 

involve some kind of driver error. The system intends to warn drivers of behaviors that 

lead to dangerous situations, as they occur and/or through targeted feedback, which can 

ultimately reduce the number of crashes. Human factors will direct the ConOps and the 

150 
151 

system requirements. As such, this discipline will be instrumental all throughout the 

project to ensure that the requirements are well-captured by other disciplines. Human 

factors will also specify system user interfaces if applicable. 

• Hardware engineering: The project product will be comprised of several hardware 

subsystems, including various sensors, a computer board, and potentially some user 

interfaces. These subsystems will be linked together and mounted onboard a truck. The 

hardware engineering group will select COTS hardware subsystems, design and build 

additional custom subsystems as needed, design and implement an architecture to 

interface the subsystems, and finally install the subsystems onboard the project truck. 

• Software engineering: Software engineering will be required to program the onboard 

computer that sits at the center of the project system. Depending on the ConOps, software 

engineering may also be required to program user interfaces, whether onboard the truck 

or on a remote server. The software engineering group will design and implement the 

software subsystems. 

• Data intelligence: Data intelligence refers to the set of algorithms that may be needed to 

process the flow of data from the selected truck sensors and assemble meaningful metrics 

as defined by the ConOps. Determining these algorithms requires a good understanding 

of the available data and how data from different sensors can be combined together. The 

data intelligence group will participate in the selection of the onboard sensors, conduct 

extensive data analysis, and design the data processing algorithms. 

• Experiment design: The follow-up to this project will be an FOT intending to validate the 

system. The design of the FOT will be part of the research phase and is therefore 

included in this SEMP. The FOT design will define the experimental protocol that will be 

used to validate that the system has the potential to reduce accidents in a cost-effective 

manner. The experiment design group will lay out performance metrics that will be 

measured as part of the FOT, design test procedures, and develop a data analysis plan. 

In addition to these five engineering specialties, two more disciplines are involved in the project: 

• Systems engineering: Systems engineering is responsible for the overall prototype 

development process, including planning and tracking, engineering specialties 

integration, risk management, documentation and configuration management. 

• Product deployment: The product deployment group will lay the ground for the ultimate 

commercialization of a product based on the outcome of this project. Their role is 

described in more detail in subsection B.4, Product Deployment. 

Table 37 provides a matrix indicating the specific application of the five engineering specialties 

through the systems engineering process defined for this project. It shows how the disciplines 

will interact and complement each other throughout the six stages of the prototype development 

process. Note that these six stages correspond to Tasks 2 to 7 in the project plan. 
152 

Table 37. Engineering Specialties Integration in the Systems Engineering Process 

Stages / 

Disciplines Human Factors Hardware Engineering 

Software 

Engineering Data Intelligence 

1. Concept of operations 

Identifies accident factors Defines safety attitudes Outlines feedback to the driver and/or the carrier management 

Provides inputs on feasibility within time and budget 

Provides inputs on feasibility within time and budget 

Insures that safety indicators can be derived from elementary sensor inputs 

2. Requirements Lists parameters to measure & 

parameters boundaries Develop application cases & specifies feedback Develop performance specifications 

Provides inputs on feasibility within time and budget Investigates existing COTS sensors and defines the feasible envelope 

Provides inputs on feasibility within time and budget 

Links parameters to measure with safety indicators Participates in sensors review to verify that parameters are available 

3. System Design Check overall conformity of 

design to requirements Participate in user interface design if any 

Selects COTS sensors Designs custom sensors Designs hardware architecture Designs component mounts for truck 

Designs all software products including input reading and processing software, analysis software, and reporting and warning software 

Analyzes data stream from sensors Designs algorithms to fuse sensor inputs if needed Designs algorithms to diagnose overall data 

4. Implementation Builds custom sensors if 

any Assembles onboard computer Builds mounts for onboard sensors 

Develop software subsystems 

5. Components Testing 

Participates in testing of critical human factors components Tests ergonomics of hardware and usability of software 

Tests hardware subsystems (performance, reliability, ruggedness...) 

-Tests software subsystems (QA) 

Tests algorithms implementation 

6. System Verification Verifies conformity to 

requirements 

Assists in overall system verification 

Assists in overall system verification 

-Collects data from system Verifies conformity of algorithms to requirements 

LEGEND: Not Involved Light Involvement Significant Involvement Technical Lead 
B.4. PRODUCT DEPLOYMENT 

The ultimate goal of this project is the deployment of a commercially available system that can 

reduce truck accidents. Reducing truck accidents will reduce fatality rates on the road and can 

also translate into operational savings for trucking companies. 

Because this project only intends to develop a prototype, deployment is one step remote; yet, it 

will be examined and taken into consideration as part of the engineering decisions made during 

the project. This was one of the reasons why CCIT is involved in this project, and the 

deployment activities and how they should relate to engineering will be the responsibility of their 

group. 

Dimensions to be examined as part of the overall deployment objective are captured by the 

following items: 

• Quality and thoroughness of the product documentation 

• Applicability of the design to a wider framework than the one of the project (alternative 

sensors procurement, different truck models, different drivers and company culture, 

different state regulations) 

• Intellectual property issues for transfer to an industry partner 

• Benchmarking of the current market for truck safety products 

• Tracking the assembly costs of the prototype to ensure it stays within reasonable limits of 

what the industry typically accepts (per benchmark) 

The deployment group will work with systems engineering and the project manager to assess and 

monitor these dimensions. 

B.4.1. Project Plans 

This section presents the work plan, deliverables, milestones, the technical plans, and the project 

management and reporting structure. 

B.4.2. Scope of Work 

The overall scope of this project is to conceptualize, design, implement, and test a prototype 

system to monitor truck driving safety in real-time and provide diagnostics. Additionally, a 

framework will be developed to evaluate the prototype in an operational environment. This 

requires finding a partner carrier. 

The scope of work is made up of nine tasks, including a general management and reporting task 

(task 0). The nine project tasks are as follows: 

Task 0. Management and Reporting 

Task 1. Planning 

Task 2. Develop ConOps 

Task 3. Develop Requirements 

153 
Task 4. Develop System Architecture and Design 

Task 5. Implementation 

Task 6. Components Testing 

Task 7. System Verification 

Task 8. Develop FOT 

The deliverables for the project are shown in Table 38, along with the corresponding tasks. 

Table 38. Project Deliverables 

Task / Index Deliverable 

0ABCD Quarterly Progress Reports 

0E Project Final Report 

1A Systems engineering Management Plan 

2A ConOps Document 

3A System Requirements Document 

3B System Verification Plan 

4A System Design Document, including COTS specifications and Testing Procedures 

5A Developed Systems (Hardware and Software) 

6A Components Testing Report 

7A Prototype System Acceptance Test Report 

8A FOT Plan 

154 
B.5. TECHNICAL PLANS 

B.5.1. Integration Plan 

The integration plan (Table 39) indicates when and how system components will be assembled 

together as part of the system as a whole. It spells out the sequence of integration, the procedures 

and criteria involved in the integration of specific components to the system and whether the 

integration takes place on a test bench first or directly onboard the project truck. The integration 

plan will be completed as part of the system design. 

Table 39. Integration Plan 

INPUT 

Sources of 

Information 

Hardware Development Plan 

PROCESS 

Key Activities 

Review RFP/Work Plan and defined Task 4 Objectives 

Review the Hardware Development Plan 

Contact with vehicle manufacturer and maintenance personnel for vehicle 

functioning and build information 

Envision methods that would integrate the hardware in the vehicle 

OUTPUT 

Results from Process 

This Integration Plan 

Detailed Integration Plan 

TOOLS Vehicle maintenance and technical manuals 

Microsoft Word for writing the plan 

REVIEW Draft plan will be submitted to customer and broader team for review written 

comments will be addressed and incorporated and customer approval will be 

received before moving to the next step in the process. 

155 
B.5.2. Configuration Management Plan 

Configuration management, as detailed in Table 40, is a tool designed to document and track 

changes made to the system and its components, whether they are features, hardware design, 

software versions, etc. Once the system design is known, the systems engineering team will set 

up and apply a configuration management process. The configuration management process will 

use an electronic document as a repository that will be accessible by each team member. This 

electronic document will likely be an MS Excel spreadsheet that will be organized in sections 

corresponding to the design areas. The configuration management spreadsheet will be a live 

document meant to be modified on the fly. Every month, the live version will be saved into an 

archive for future reference. This will establish a track of past configurations to document the 

prototype development. 

Table 40. Configuration Management Plan 

INPUT 

Sources of 

Information 

Systems engineering Management Plan 

System Requirements Document 

System Design Documents 

Bi-Monthly meetings 

PROCESS 

Key Activities 

Establish key characteristics of the system being developed (safety attributes 

to monitor, data metrics, hardware and software requirements, physical 

characteristics of the system). 

Map characteristics into a numbered list of qualitative and quantitative items. 

Create a flexible spreadsheet structure to host these items. 

Instruct the team on how to read and edit the spreadsheet. 

Make the spreadsheet available on the project’s FTP site. 

Status accounting: every month, integrate inputs from the team and freeze the 

latest version for archiving. Inputs will be collected informally on a continuous 

basis and reviewed with the whole team before being frozen. 

Audit changes: major configuration changes are fed back to the project’s 

Change Control Board (CCB), comprising the project systems engineering 

team, management team and sponsors for approval. 

OUTPUT 

Results from Process 

Configuration management spreadsheet—initial baseline and monthly frozen 

versions. 

The Change Control Board 

A trail of past configurations and configuration changes, archived on a monthly 

basis. 

Audit results 

TOOLS Microsoft Excel 

REVIEW Initial spreadsheet will be reviewed by project management and sponsors for 

process approval. 

Subsequent versions will be available for review on a continuous basis. 

156 
B.5.3. Verification Plan 

The verification plan (as shown in Table 41) spells out the procedures and measurements that 

will be employed to verify how well the built prototype meets the system requirements. The 

verification plan is a deliverable of Task 3, System Requirements. 

Table 41. Verification Plan 

INPUT 

Sources of Information 

Requirements Document 

PROCESS 

Key Activities 

Review RFP/Work Plan and define Task 3 Objectives 

Review the Requirements Document 

Envision tests that would verify system meets the requirements. 

OUTPUT 

Results from Process 

This verification plan 

A detailed verification plan 

TOOLS The developed prototype system will be used to verify system performance 

Other instrumented vehicles may be used in the verification testing 

Matlab and/or other engineering software will be used to review and 

analyze raw and reduced data 

Microsoft Word and Excel will be used for data management and report 

writing 

REVIEW Draft plan will be submitted to customer and broader team for review. 

Written comments will be addressed and incorporated and customer 

approval will be received before moving to the next step in the process. 

157 
B.5.4. Risk Management Plan 

The risk management plan, shown in Table 42, identifies individual project risks and indicates 

mitigation strategies. The risk management plan will be started at the beginning of the project 

and be augmented as necessary until the system design is completed. It will be modeled after the

FAA Programmatic Risk Analysis Approach. 

Table 42. Risk Management Plan

INPUT 

Sources of 

Information 

Systems engineering Management Plan 

System Requirements Document 

System Design Documents 

Bi-Monthly meetings 

PROCESS 

Key Activities 

Identify risks 

Begin with risks identified at onset of project and documented in kickoff 

1 Obtaining carrier partner 

2 OBM implementation (hardware and software) 

3 High quantity of reporting 

Analyze risks and rank consequences 

Likelihood 

A: Not likely 

B: Low likelihood 

C: Likely 

D: Highly Likely 

E: Near Certainy 

Consequence 

Level 1: Minimal impact 

Level 2: Minor performance shortfall, same approach retained 

Level 3: Moderate performance shortfall, alternatives available 

Level 4: Unacceptable performance, but alternatives available 

Level 5: Unacceptable performance, and no alternatives exist 

Focus will be where likelihood x consequence is high. 

Create a flexible spreadsheet structure to monitor and track risks, particularly 

where aforementioned product is high. 

At each bi-weekly, address all risks with focus on higher level risks; select risk 

mitigation option

During project execution, implement risk mitigation decisions and plan 

Awareness and buy-in on risks 

Tracking of risks 

Risk mitigation plan 

TOOLS Microsoft Excel 

REVIEW Bi-weekly with project team, to include Caltrans management 

158 
B.5.5. Plan for ConOps 

This Task 2 effort is the marriage of a literature review, stakeholder feedback, and technical 

inputs, resulting in the ConOps document deliverable. As shown in Table 43, there are four main 

tasks which will provide input to ConOps document. First, there is a COTS survey. Second, there 

is an identification of causal factors in truck crashes. Third, there is a literature review on various 

specific and relevant Human Factors related issues, and finally, there is stakeholder input 

gathered during interviews and ride-alongs. 

Table 43. ConOps Plan 

INPUT 

Sources of 

Information 

Product literature for COTS onboard monitoring systems 

Reports published by the Center for National Truck and Bus Statistics 

Peer-reviewed academic literature 

Stakeholder input 

PROCESS 

Key Activities 

Survey the market for COTS monitoring systems documenting what parameters 

the system monitors and how feedback is given to the drivers. 

Review the literature published by the Center for National Truck and Bus Statistics 

to identify causal factors in the truck crashes. 

Review the literature that has been published on the topic of onboard monitoring 

and driver feedback. 

Review the literature on various driving performance measures such as speed, 

lane position, headway, and fatigue with intent to determine how to convert the 

monitored data into a measure of driving performance. 

Perform a task analysis during a ride-along with a stakeholder partner. 

Perform a management interview with a stakeholder partner. 

Develop application cases for the ConOps document. 

Develop driver feedback concepts for the ConOps document. 

OUTPUT 

Results from 

Process 

Onboard Monitoring ConOps Document 

Provides a review of relevant literature 

Provides a survey of COTS monitoring systems 

Provides a draft concept of what parameters should be monitored 

Provides a rationale for how to use the monitored parameters to make a statement 

about driving performance 

Provides a draft concept of how feedback should be provided to the driver for each 

monitored parameter 

TOOLS Access to Science Direct, Ingenta Connect, and the UCB Library 

Adobe Acrobat Reader (to read and print online literature) 

Microsoft Word (for document development) 

Video Camera (for recording interviews and ride-alongs) 

REVIEW Periodic presentations at the bi-weekly meetings will be provided to review the 

findings of the COTS survey, literature review, and stakeholder inputs. 

159 
B.5.6. Hardware Development Plan 

The hardware development plan, shown in Table 44, will outline the implementation of required 

hardware components for the system, such as the tools to be employed and the distribution of 

tasks among the team. It will include test plans for the hardware components. The hardware 

development plan will be finalized when the hardware design is complete. 

Table 44. Hardware Development Plan 

INPUT 

Sources of 

Information 

Requirements Document 

PROCESS 

Key Activities 

Review RFP/Work Plan and defined Task 4 Objectives 

Review the Requirements Document 

Review Availability of COTS sensors and equipment 

OUTPUT 

Results from 

Process 

This Hardware Development plan 

A detailed hardware development plan 

TOOLS Microsoft Word (for document development) 

REVIEW Draft plan will be submitted to customer and broader team for review. Written 

comments will be addressed and incorporated and customer approval will be 

received before moving to the next step in the process. 

160 
B.5.7. Software Development Plan 

Software development, as detailed in Table 45, will be required to interface COTS hardware and 

software to the onboard data gathering computer that sits at the center of the project system and 

to do any data filtering or archiving services required by the data intelligence operations. 

Depending on the ConOps, software engineering may also be required to program user interfaces 

for safety systems, based on data intelligence analysis, whether onboard the truck or on a remote 

server. 

Table 45. Software Development Plan 

INPUT 

Sources of 

Information 

ConOps plan and requirements document 

Hardware development plan and COTS system documentation 

Data intelligence plan and list of required data elements 

If user interfaces are part of the requirements, human factors input specification for 

the characteristics of the interfaces 

PROCESS 

Key Activities 

Identify major software subsystems and capabilities required of each. 

Define and document data and control interfaces between hardware and software 

components. 

Develop prototype software to test capabilities of COTS hardware and software. 

Revise software subsystem capabilities and interface requirements based on 

results of COTS system testing. 

Evolve prototype COTS testing software into a hardware and components test 

suite that can be used to check integrity of system. 

Write prototype data gathering software and collect initial data sets. 

Add capabilities or improve performance as required for correct operation of safety 

system, based on data intelligence analysis carried out on initial data sets. 

Develop regression tests to ensure integrity of software development as 

capabilities are added. 

With human factors group, develop and carry out tests of any user interfaces 

Iterate software process as required to address deficiencies identified by testing. 

Document software and testing procedures. 

OUTPUT 

Results from 

Process 

Software for data gathering and safety systems 

Test software for system components and software integrity 

Documentation for software and testing procedures 

TOOLS Real-time operating system for data gathering—QNX6 or (possibly) a real-time 

version of Linux 

C programming language and Unix scripting and filtering tools 

Open-source package doxygen for automatic generation of software 

documentation in pdf or html format 

User interface development package may be needed. 

REVIEW Quarterly reports will be submitted to customer and broader team for review. A 

web page will be maintained containing current software documentation. 

161 
B.5.8. Data Intelligence Plan 

The data intelligence plan, as shown in Table 46. Data Intelligence Development Plan, will 

outline the scope and extent of data intelligence tasks for this project. Data intelligence will be 

concerned with the safety measurements defined by the system requirements and how to 

assemble these measurements from available sensor inputs. The plan will indicate how data will 

be collected and analyzed so that algorithms can be properly calibrated, what tools will be used, 

and how the adherence of the system data processing algorithms to the requirements will be 

measured. The data intelligence plan will be produced once the requirements are completed. 

The objective of the project is for onboard monitoring with some feedback reminding (warning) 

to the driver, which is to be determined with the iterative development of the project. Sensor 

specification, detection, tracking, information from J1939-Bus and data fusion will depend on 

the system performance requirement. Some of the measures will be processed in real-time to 

provide feedback to the driver. Other data will be collected for after processing to analyze 

driver’s behavior related to safety 

Table 46. Data Intelligence Development Plan 

INPUT 

Sources of 

Information 

List of parameters to be monitored 

List of sensors 

Description of data from sensors 

Requirement of feedback to the driver 

Requirement of data logging for after processing 

Dangerous situation in operation 

Previous work in Warning System Study including threat assessment 

PROCESS 

Key Activities 

According to the requirement to develop tracking and sensor fusion algorithm 

According to the specification, development, and implementation of threat assessment 

algorithm for heavy-duty truck for longitudinal motion 

With human factors group, develop warning scenarios and feedback if necessary 

System integration of onboard signal processing, monitoring of driver’s operation 

regulation violation, and threat assessment 

Field testing and data analysis 

Data offline processing 

System refining 

OUTPUT 

Results from 

Process 

Multiple frontal target detection and tracking using radar and lidar 

An integrated system for real-time signal processing, monitoring of driver’s operation 

regulation violation, threat assessment and warning 

Documentation for algorithm, software, and testing procedures 

TOOLS Real-time operating system for data processing such as QNX6.0 

C programming language 

Matlab packages 

162 
REVIEW Quarterly reports will be submitted to customer and broader team for review 

Customer’s feedback will be incorporated in system tuning and refining 

A web page will be maintained containing current algorithm, software, and system 

documentation. 

B.6. TEAM, RESOURCES, AND ORGANIZATION 

B.6.1. Staff and Resources 

PATH is the primary contractor for this project. The project team comprises PATH staff 

members as well as staff from other Transportation Research Centers at the University of 

California, Berkeley. In addition, a professional system engineer was hired on a subcontract. 

B.6.2. Organization 

The project team is organized under the responsibility of the project manager. For each 

engineering discipline, a group leader is designated and bears responsibility for carrying out 

specific tasks, providing deliverables, and acting as a coordinator for their discipline. This means 

reporting to the project team as a whole and being a liaison with other disciplines. Throughout 

the project, meetings will be held to allow updates within the project team. The nominal 

frequency of team-wide meetings is one meeting every other week. 

Figure 42 represents the overall organization chart for this project. It includes the yet-to-bedetermined partner carrier. Tan boxes indicate the groups that specifically belong to the project. 

Project 

Manager

Stakeholders

System 

Engineering

Human 

Factors

Hardware 

Engineering

Software 

Engineering

Data 

Intelligence

Experiment 

Design

Partner 

Carrier

Deployment 

Group

Stakeholders

Project 

Manager

Deployment 

Group

System 

Engineering

Human 

Factors

Hardware 

Engineering

Software 

Engineering

Data 

Intelligence

Experiment 

Design

Figure 42. Project Organizational Chart 

163 
APPENDIX C: 

SYSTEM REQUIREMENTS DOCUMENT 

The entire contents of this appendix is the paper Onboard Monitoring and Reporting for 

Commercial Motor Vehicle Safety: System Requirements, copyright© YYYY, California PATH 

and California Center for Innovative Transportation (CCIT). Reprinted with permission. 

C.1. BACKGROUND AND SCOPE 

C.1.1. Background 

The project’s scope of work was to develop a prototype system that measures a set of driving 

characteristics which are indicators of unsafe driving behavior and provides appropriate feedback 

to drivers and fleet managers. Once a first prototype is developed, the project team intends to test 

it on a class 8 tractor owned by Caltrans. 

A subsequent research award would allow a nFOT, consisting of a limited deployment of the 

product of the present research project on a fleet of commercial vehicles in order to test and 

validate the concept. The ultimate goal is to demonstrate a set of innovative safety features that 

can be replicated and commercialized by trucking equipment manufacturers and to formulate 

safety policy recommendations, depending on the outcome of the research. 

Appendix C supports this project by providing a nominal “first pass” during the prototype stage 

set of requirements for an final OBMS The process of determining final requirements is, of 

course, iterative and the results of the subsequent FOT will figure prominently. 

C.1.2. Applicable Documents 

Onboard Monitoring and Reporting for Commercial Vehicle Safety, Systems Engineering 

Management Plan, PATH/CCIT, January 2006 

Onboard Monitoring and Reporting for Commercial Vehicle Safety, ConOps—Draft, 

PATH/CCIT, May 2006 

C.1.3. Definitions 

The following definitions are used as part of the system requirements. 

Crash: accident involving a collision. 

Driver attention: is an assessment of the driver’s concentration on their task. 

Driver fatigue: refers to a state of tiredness on the part of driver, which impairs good 

judgment and reflexes. 

Event: any occurrence of certain circumstances and / or parameter values crossing defined 

thresholds that reveals a specific action taken by the driver or is a safety hazard. 

187 
Following distance: distance between the CMV and the vehicle immediately leading it on the 

same lane. 

Notice: a signal meant to inform the driver, for instance about the risk associated with a 

certain situation or action. A notice is intended as less intrusive than a warning. 

Parameter: any variable, measurable property whose value characterizes the state of the 

vehicle or the behavior of the driver. 

Roadway curvature: is defined as the inverse of the roadway curve radius. 

Vehicle parameters: generally refers to engine and other vehicle parameters that are readily 

available on CMV CAN buses. Includes in particular engine RPM, clutch pressure and 

release, fuel consumption rate, etc. 

Warning: a visual or audible signal meant to alert the driver of a potential threat or dangerous 

action. 

C.1.4. System Overview 

The system described in this document (thereafter referred to as “the system”) intends to improve 

the safety of CMV fleet operations by (1) recording and monitoring HOS, driver input 

commands, vehicle states, and environmental conditions on each equipped vehicle and (2) 

providing recommended driving behavior by using real-time feedback devices or offline 

feedback procedures. 

The system architecture comprises five logical subsystems as follows: 

• Onboard processor (OBP): This is the system core that acquires and processes all the data 

being collected by the system. 

• Sensors: A set of sensors provides behavioral and environmental parameters to the OBP. 

• Driver interfaces: This subsystem encompasses all the means of interactions between the 

system and the driver, including real-time feedback. 

• Data storage device: An onboard memory storage device that records monitored 

parameters and events. 

• Analysis module: A PC program that processes data recorded on the data storage device 

and provides analysis of driving behavior. 

Note that, with the exception of the analysis module, which will typically be deployed in the fleet 

dispatch, all subsystems are replicated on each equipped vehicle. In addition to the five 

subsystems, hardware mounts and cables ensure the integration of the onboard components to a 

truck. Figure 43 depicts the overall system architecture. 

188 
Hardware Mounts and Cables

(Section C.2.3)

Sensors 

(Section C.5)

Driver Interfaces

(Section C.6)

Figure 43. Overall System Architecture 

The proposed system uses various sensors, including COTS systems. In some cases, these COTS 

systems are self-contained units that can operate independently. As such COTS are integrated 

into the system; their nominal modes of operations will still be used. The purpose of this research 

is to seek benefits from their integration to a larger onboard monitoring suite, while maintaining 

regular use. For example, a LDWS will provide lane positioning to the system while still issuing 

a warning to the truck driver in case of an uncontrolled lane change. 

The OBP stores a set of recommended driving behaviors as the reference. It continuously 

compares driving behavior with referenced behavior. Technically, the system distinguishes 

between monitored parameters, for which there are continuous values over time (e.g., speed or 

lane positioning), and events, which are occurrences of a specific set of circumstances or 

parameter values (e.g., speeding or nonsignaled lane change). Certain events or behaviors can 

trigger real-time feedback in the form of visual or audible notices to the driver. In addition, data 

and events are recorded into the data storage device for later retrieval. The data recorded in the 

storage device is then processed by the offline analysis module in the back-office. The analysis 

module produces safety metrics that can be tracked over time to determine general driving 

behavior and monitor progress. 

In summary, the system provides three types of feedback: 

Real-time warnings indicating immediate threats. These warnings all stem from COTS 

components and will be integrated “as is” into the system. 

Real-time feedback in the form of visual or audible notices. Such notices signal 

potentially unsafe behaviors but intend to be less intrusive than a warning. Moreover, 

notices are only delivered in situations that allow corrective action by the driver. 

OBP / Core Unit

(Section C.4)

Data Storage

(Section C.7)

Analysis Module

(Section C.8)

Onboard

Driver Interfaces

(Section C.6) Offboard

OBP / Core Unit

(Section C.4)

Hardware Mounts and Cables

(Section C.2.3)

Sensors 

(Section C.5)

Data Storage

(Section C.7)

Analysis Module

(Section C.8)

189 
Offline feedback in the form of summary statistics. Summary statistics synthesize the 

parameter values and event data being logged by the onboard subsystems and intend to 

provide a comprehensive picture of driving behavior 

(It is noted that real-time and offline feedback are not necessarily mutually exclusive.) 

At a glance, the system can monitor the following driving attributes and events: HOS, seat belt 

usage, speeding, following distance, lane positioning, turn signal usage, blind spot checks, driver 

attention and fatigue, collision and lane departure warning activations, stop sign violations, hardsteering events, hard-breaking events, and crash events. 

C.1.5. Document Scope 

This document establishes the design requirements of the proposed system and the associated 

subsystems. The requirements covered in this document include functional requirements, 

interface requirements, performance and environmental requirements, as well as various enabling 

requirements to allow proper design and fielding of the system. 

The intended audience of this document comprises the project team, the project sponsors, and 

system stakeholders, including equipment manufacturers, fleet managers, and policy makers. The 

level and detail of the requirements vary for different subsystems and features, based on what is 

deemed necessary to provide the intended audience with a clear understanding of the intended 

functions of the system, of its constraints, and of significant enabling factors and conditions. 

One particular challenge to this document was that the system was be developed iteratively over 

several stages. As part of the current stage, a single prototype will be developed. For the 

subsequent FOT, it is expected that additional constraints will be factored in to allow the fielding 

of the system in an operational environment. Ultimately, the system, or part of it, may be 

commercialized, which will impose yet another set of requirements. Moreover, as feedback on 

the system effectiveness and relevance is collected at each stage, the requirements will evolve. It 

is clear that stakeholders need to capture the ultimate system vision to be able to validate the 

requirements. In order to deal with this issue, the requirements in this document are usually 

inclusive of what is needed to deploy the system on a commercial fleet (although requirements 

specifically aimed at making the system into a commercial, rugged product are not included); 

however, to distinguish between requirements that are immediately applicable and requirements 

that can be put off to a later stage, two labels are used: FT designates requirements that will be 

needed for FOT fielding, but won’t be considered for the prototype; COM designates requirements 

that will not even be applied for the FOT, but would ultimately be needed for commercial 

deployment; therefore, only nonlabeled requirements apply to the prototype development in this 

project. 

Section C.2, spells out the general requirements at the system level and section C.3 details the 

system enabling requirements. The following subsections, starting with section C.4, provide 

requirements for each of the individual five subsystems of the overall system architecture (as 

shown previously in figure 39). Figure 39 also indicates the corresponding document section for 

each subsystem. Note that the Hardware Mounts and Cables requirements are part of the general 

system interface requirements (section C.2.3). 

190 
C.2. SYSTEM REQUIREMENTS 

C.2.1. General System Requirements 

This section describes requirements for the system as a whole, including general-purpose 

requirements that flow down to subsystems. 

C.2.2. Functional Requirements 

System mission: The system must improve the safety of CMV fleet operations by (1) recording 

and monitoring HOS, driver input commands, vehicle states, and environmental conditions on 

each equipped vehicle and (2) providing recommended driving behavior by using real-time 

feedback devices or offline feedback procedures. 

Applicability: The system must be designed for a fleet of CMV. Onboard subsystems must be 

installed and able to perform nominally on any CMV that has the required interfaces.FT

Monitoring functions 

Monitoring functions can be separated between parameters and events. Parameters are monitored 

on a continuous or near-continuous basis. Events are occurrences of specific circumstances or 

sets of parameter values. 

a. Driving parameters: The system must monitor, record, process, and summarize the following 

parameters as shown in Table 47. 

Table 47. Driving Parameters 

Parameter ID Description 

P1 Driver identification Unique driver ID 

P2 Following distance 

P3 HOS Hours logged by driver 

P4 Lane position Computed tracking value as compared to lane delineators 

P5 Road surface conditions Dry, Wet, Icy, Fog, Snow 

P6 Roadway curvature 

P7 Roadway scenery Video 

P8 Seat belt usage 

P9 Vehicle location Latitude and Longitude 

P11 Speed 

P12 Brake pressure 

P13 Steering angle 

P14 Occupancy of side lanes Binary measure 

P15 Turn signal use 

191 
b. Events: The system must identify and record the following events as shown in Table 48. 

Table 48. System Events 

Event ID Description 

E1 Crash events 

E2 Driving more hours than legal maximum Based on Federal Regulation CFR III-395.15 of 

Title 39 and California Code Section 1213.2 

E3 Driving without seat belt 

E4 Following too closely 

E5 Hard-breaking events 

E6 Hard-steering events 

E7 Nonsignaled turns 

E8 Speeding with respect to legal speed 

limit 

E9 Speeding with respect to weather and 

road surface conditions 

E10 Speeding with respect to road curvature 

conditions 

E11 Speeding with respect to traffic flow 

conditions 

E12 Stop signs violations 

E13 Initial failure to adjust mirrors 

E14 Excessive lateral acceleration 

E15 Fatigue 

E16 Lane Departures 

E17 Eyes-off-the-road 

E18 Failures to check mirrors 

E19 Forward collision threats 

Feedback functions 

The system must deliver three types of feedback: 

• Real-time warnings 

• Real-time advisory notices 

• Offline feedback 

It can also deliver both real-time and offline feedback. 

192 
a. Real-time warnings: The system must deliver real-time warnings in response to the following 

events: 

• Forward collision threat 

• Roll-over danger 

• Side collision threat 

• Unintended or nonsignaled lane departure 

These warnings must be delivered by COTS components. 

b. Real-time advisory notices: The system must deliver real-time audible or visible notices in 

response to the following events: 

• Speeding 

• Following too closely 

• Driving over the legal maximum number of hours 

• Driving without seat belt (to include percentage of time) 

• Alerts given by COTS systems used in OBMS 

c. Offline feedback: The system must deliver offline feedback based on summary statistics of 

recorded parameters and events. Specific statistics will be based on results of the FOT. 

Data management 

Individuality: The system must treat each driver and each CMV in a fleet as individual, 

identified entities. Data recorded for a given driver on a given truck must be stamped as such.FT 

Confidentiality: The system must treat personal information about driving behavior with 

confidentiality throughout all subsystems and interfaces. Access to the data must be restricted 

accordingly.FT 

Security: Because data may be sensitive and even have legal implications, its integrity and 

confidentiality must be guaranteed by security measures: physical access, passwords, and 

cryptography.COM 

Extensiveness: The amount of data collected and kept is determined by individual safety 

features; however, all data monitored by the system must be recorded and accessible for later 

retrieval and consultation, at least in summary format. 

C.2.3. Interface Requirements 

Onboard interfaces 

J-Bus: The CMV that hosts the system must feature a Control and Communications Network 

that complies with standard sensing equipment and provides baseline vehicle parameters. 

193 
Physical space: The CMV cabin must offer the required amount of physical space and electrical 

power to host the system, including the onboard processing units, the sensors and the cables and 

mounts. 

Existing onboard sensors: Any sensor pre-existing on a CMV may be interfaced to the system 

if it meets the functional, performance, and interface requirements described in the relevant 

section of this document. 

Offboard interfaces 

PC computer: The system requires a PC computer to run the analysis module. 

C.2.4. Performance and Environmental Requirements 

Mission 

Crash reduction: The system must reduce the statistical occurrence of crashes on the fleets on 

which it is equipped, as measured by number of crashes per million vehicle-miles traveled 

(MVMT). 

Casualty reduction: The system must reduce casualties involving equipped CMV per MVMT. 

Safety-related behavior improvements: The system must lead to safer behaviors by drivers 

operating within an equipped fleet. Specific Technical Performance Measures (TPMs) to track 

overall safety-related behavior will be based on the results of the FOT. 

C.2.5 Reliability. 

Up-time 

Overall system up-time is defined as the availability of all subsystems and functions to perform 

nominally. System failure is the opposite of up-time. Up-time requirements are expressed in 

terms of Mean Time Between Failures (MTBF). 

Data reliability and accuracy 

Data reliability is defined as a percentage of operating time when measurements are within a 

tolerable margin of error from the actual parameter being measured. 

Data accuracy for a given parameter being monitored is defined as the average error over time 

between measurements and actual values of the parameter. 

Data reliability is defined as the percentage of occurring events being recorded by the system. 

False positives 

False positives are instances where the system records one of an event even though it did not 

occur. The system must minimize the number of false positives, measured as the ratio of false 

positive instances to MVMT. 

194 
Resilience 

The system as a whole must be able to handle down-times of its components. In particular: 

• The OBP unit must still function, although in degraded mode, when other parts of the 

onboard elements are downFT

• The analysis module must be able to acquire and process the down-times of onboard 

elements, and produce analysis accordinglyCOM

C.2.6. Environmental Constraints 

Ambient conditions 

Onboard elements must withstand the following conditions: 

• Temperature: the ambient air temperature range is -55F to 125F for operating conditions 

and -55F to 200F for nonoperating conditionsCOM

• Relative humidity: the ambient relative humidity range is 0-100 percent FT

• Atmospheric pressure: the absolute pressure range (not corrected to sea level) is between 

16.8 and 31.4 inches of mercury (427 and 797 millimeters of mercury, respectively)FT

Cabin safety 

Onboard hardware elements, cables, and mounts must observe the following constraints 

pertaining to cabin safety: 

• Driver sight: the system must not block driver sight. 

• Driver motion and access: the system must not impair driver’s movements or interfere 

with original equipment and commands in the vehicle. 

• Electrical safety: the system must not represent an electrical hazard. Fuses or safety 

breakers must limit current flow to a maximum value. 

• Feedback and warnings: feedback and warnings must be delivered in a way that does not 

overload the driver or adds undue stress. 

Cabin security 

To ensure the security of the system the system elements in the cabin must conform to the 

following: 

• Physical security: the hardware elements, cables and mounts must be hidden from the 

driver to the extent possible, with the exception of the user interfacesFT

• Tamper-proof design: data communications between the sensors and the core processing 

unit, as well as data storage, must be secure and tamper-proofcom

Human factors 

Onboard elements must guarantee cabin comfort in the following ways: 

195 
• Physical comfort: the system must not affect driver comfort by limiting available space or 

creating physical annoyance. 

• Sonic and visual comfort: the system must not provoke sonic or visual discomfort unless 

the safety benefits of such discomfort are clear. 

• Driver interfaces: driver interfaces (i.e., vehicle identification reader, video devices, 

memory storage) must be simple, effective and nonintrusive. 

• Interfaces layout: physical access to the driver interfaces must be easy and convenient. 

C.3. ENABLING REQUIREMENTS 

C.3.1. COTS Components 

The system must be designed with available COTS to the extent that they can meet functional 

requirements in a cost-effective manner. All-purpose requirements apply to COTS and originaldesign components alike. Specific requirements for COTS components are usually not included 

in this document, based on the following statement: 

COTS components must be selected on the basis of performance/cost ratio and be positioned as 

industry standards in their product class, unless otherwise specified. 

The following sensors and information sources shown in Table 49 must be included in the 

system. These come in addition to baseline sensing equipment that must be present in trucks on 

which the system is installed. 

Table 49. Sensors and Information Sources Included in System 

Sensor ID 

S1 Accelerometer 

S2 Driver ID reader 

S3 EOBR/HOS 

S4 Front radar/warning system 

S5 GIS roadway map 

S6 GPS receiver 

S7 Lane position monitor 

S8 Outward video camera 

S9 Road surface conditions sensor 

S10 Rollover sensor 

S11 Side radar (2) 

S12 Steering angle sensor 

S13 Thermometer 

S14 Throttle angle sensor 

S15 Wheel speedometer 

196 
Sensor ID 

S16 Wiper usage monitor 

S17 Brake pressure monitor 

S18 Mirror adjustment monitor 

S19 Turn signal monitor 

S20 Seat belt usage monitor 

S21 Driver camera 

C.3.2. Design and Upgrades 

Modular design 

The system must be designed in a modular fashion that allows interchangeability of sensors and 

acquisition functions. 

Software design 

The software design must be in accordance with industry best practices such as CMMI or ISO 

12207 software development standards.COM 

Upgradeable design 

The design must allow software upgrades to be carried out simply and speedily. Similarly, 

sensors and other hardware upgrades must be easy, based on a modular design. 

C.3.3. Installation and Setup 

A CMV fleet being outfit with the system must bear minimum cost and disruption to its regular 

operations. Deployment at one given site or dispatch station consists of the following steps: 

• Installation and configuration of onboard components on individual trucks 

• Installation and setup of the analysis software on selected dispatch computers 

• User training, both for drivers and users of the analysis module 

The following TPM must be employed. 

On-vehicle installation 

Installation and testing of the onboard components must not immobilize individual vehicles for 

more than one day. The process must not require more than two-people days.FT 

Analysis module installation 

Installation and configuration of the analysis software must be conducted in a maximum of x

days + y days/n vehicles in the fleet.COM 

197 
Driver training 

Training of the drivers for the onboard functions must require less than one day.FT 

Analysis training 

User training for the analysis module must require less than one day.FT 

C.3.4 User Acceptance 

One key hurdle faced by the system is driver acceptance. The system must be designed and 

evaluated so as to maximize acceptance likelihood by drivers and managers in CMV fleets. 

Acceptance must be considered in the comprehensive context of fleet operations and not be 

limited to onboard elements feedback. 

C.3.5. Maintainability 

The system must be easy to maintain and not generate excessive added burden on CMV fleet 

operations and costs. Because of the system complexity and the multiplicity of its components 

(i.e., sensors), a maintenance plan must be developed for equipped fleets.FT 

C.4. ONBOARD PROCESSOR (OBP) REQUIREMENTS 

C.4.1. Functional Requirements 

Operating modes 

The OBP must feature the following operating modes: 

• Off mode: No power. Occurs when the ignition is off or if the system is manually shutdown. 

• Diagnostics mode: In this mode, the OBP diagnoses the onboard system elements. The 

OBP automatically switches to this mode when the truck ignition is turned on. 

Subsequently, the diagnostics mode is intertwined with the monitoring and recording 

mode to allow continuous diagnostics.FT

• Monitoring and recording: Nominal mode, during which the OBP monitors, records, and 

processes parameters and events. 

• Memory access mode: This mode allows transfer of stored data off the vehicle. 

• Degraded mode: A generic mode to describe monitoring and recording when parts of the 

onboard elements are failing.COM

C.4.2. Data Recording 

The OBP must record values of monitored parameters and event occurrences in the onboard data 

storage. 

198 
Each record must include the following information: 

• Driver identificationFT

• Time stamp 

C.4.3. Monitored Parameters 

The OBP must monitor the following parameters. 

Driver identification 

The OBP must acquire driver identification and stamp each recorded data with this information. 

Following distance 

The OBP must monitor and record actual following distance. 

The OBP must compute and record a safe following distance based on the following inputs: 

• Vehicle speed 

• Trailer load 

• Roadway surface conditions 

The OBP must continuously compare the actual following distance and the calculated safe 

following distance. The OBP must determine occurrences of unsafe driving behavior based on a 

set of criteria involving those two parameters. 

Hours of service 

The OBP must monitor and record operating hours by driver. The OBP must compare these 

hours with the Federal (Federal Regulation CFR III-395.15 of Title 39) and local regulations (in 

California, California Code Section 1213.2) and determine occurrences of violations. 

Lane position 

The OBP must monitor and record the vehicle’s position relative to lane delineators. 

Road surface conditions 

The OBP must monitor and record the road surface conditions. Road surface conditions must be 

characterized, at a minimum, with the following criteria: 

• Dry road 

• Wet road 

• Icy road 

• Fog over the road 

• Snow on the road 

199 
Roadway curvature 

The OBP must monitor roadway curvature ahead of the trajectory of the truck, based on a 

GPS/GIS system. 

Roadway scenery (video) 

The OBP must monitor and record roadway scenery ahead of the truck. Recording must be 

implemented as a five-min buffer which is overwritten on a cyclical basis. At any given moment, 

the last five minutes of video footage must be stored by the OBP in the data storage device. 

Seat belt usage 

The OBP must monitor and record seat belt usage when the engine is on. 

Speed 

The OBP must monitor and record vehicle speed. 

The OBP must monitor and record a recommended safe speed based on the following inputs: 

• Legal speed limit, as provided by a GPS/GIS system 

• Roadway curvature ahead, also provided by a GPS/GIS system 

• Road surface conditions 

• Weather 

The OBP must continuously compare vehicle speed and recommended safe speed. The OBP 

must determine occurrences of unsafe driving behavior based on a set of criteria involving those 

two parameters. 

Vehicle location 

The OBP must monitor and record vehicle location based on GPS. 

Brake pressure 

The OBP must monitor and record the pressure applied to the brake pedal. 

Steering angle 

The OBP must monitor and record the angle of the steering wheel. 

Occupancy of side lanes 

The OBP must monitor and record whether or not there are objects in the spaces on either side of 

the vehicle. 

200 
Turn Signal Use 

The OBP must monitor and record whether or not the turn signals are in use. 

C.4.4. Monitored Events 

While parameters are state variables that can be described as steady data streams, events are 

isolated occurrences in time resulting from a set of specific circumstances and parameter values. 

Events occurring while driving will usually call for a response by the system, or at least be 

logged in an event list that contributes to the analysis of driving patterns and behavior. The OBP 

must catch and record the following events. 

Crash events 

The OBP must detect and record crashes. Crash events must cause video data, both inside and 

outside the vehicle, to be permanently recorded for later retrieval. 

Driving over the legal maximum number of hours 

The OBP must detect and record occurrences of a driver exceeding the legal maximum of service 

hours. 

Driving without a seat belt 

The OBP monitors seat belts usage. Occurrences of the driver not using the seat belt must be 

treated and recorded as events, along with percentage of time without a belt. An audible 

reminder icon will be included. 

Following too closely 

The OBP must detect and record occurrences of tailgating, which must be defined as a set of 

criteria involving following distance, calculated safe following distance, and their relationship 

over a time segment. Tailgating events result from monitoring requirements. 

Hard-braking events 

The OBP must detect and record occurrences of hard-breaking events. Hard-breaking events 

occur when break pressure exceeds a threshold to be determined. 

Hard-steering events 

The OBP must detect and record occurrences of hard-steering events. Hard-steering events occur 

when steering angle variations exceed a threshold to be determined. 

Nonsignaled turns 

The OBP must detect and record nonsignaled turns. 

201 
Speeding (speed limit violation) 

The OBP must detect occurrences of speed limit violation. 

Speeding with respect to road curvature and road surface conditions 

The OBP must detect occurrences speed unsafe given road curvature and surface conditions. 

Stop sign violations 

The OBP must detect and record stop sign violations based on the following inputs: 

• Truck location and roadway map, provided by a GPS/GIS system 

• Truck speed 

A set of criteria involving these parameters must define a threshold that indicates an event 

occurrence. While this was not implemented in the prototype, this is targeted for the FOT 

vehicles. 

Initial failure to adjust mirrors 

The OBP must detect occurrences of a failure to adjust mirrors when starting the vehicle. 

Excessive lateral acceleration 

The OBP must detect occurrences of unsafe excessive lateral acceleration. 

Fatigue 

The OBP must detect occurrences of evidence of driver fatigue. 

Lane departures 

The OBP must detect occurrences of lane departures. 

Eyes-off-the-road 

The OBP must detect occurrences of evidence of drivers taking their eyes off the road in front of 

them. 

Failures to check blind spots 

The OBP must detect occurrences of drivers failing to check blind spots before changing lanes or 

making turns. 

Forward collision threats 

The OBP must detect threats of collisions involving the truck and the vehicle in front of the 

truck. 

202 
C.4.5. Feedback Notices 

The OBP must deliver feedback notices in response to the following events: 

• Speeding 

• Following too closely 

• Driving over the legal maximum number of hours 

• Driving without seat belt 

• Other feedback as present on the COTS devices used 

The OBP must be programmed with specific feedback procedures that feed into a display, 

Digital Sound Processor (DSP), or other feedback indicator for each of these events. 

C.4.6. Interface Control 

The OBP must control an onboard Liquid Crystals Display (LCD) and a DSP to provide 

information to the driver, such as: 

• System state and diagnosticsFT

• Feedback notices 

C.4.7. Performance and Environmental Requirements 

The OBP must perform reliably and swiftly, allowing timely feedback notices. In particular, the 

OBP processing power must be sufficient to handle the multiple inputs and processes required by 

its functionalities. Specific TPMs will be developed as part of the FOT. 

C.4.8. Interfaces and Material Requirements 

Data interfaces 

The OBP must feature data interface ports to connect to the truck’s J-Bus as well as to individual 

COTS if required. 

Physical interface 

The OBP must be contained in a reasonably size form factor that is easily mounted onboard the 

truck with the appropriate mounts and cables. 

Material requirements 

The OBP must be hosted by a PC computing platform that includes the following components: 

• Baseboard 

• CPU and fan 

• Memory 

• Power supply 

• Connectors and cable kit 

• Case (NEMA enclosure) 

203 
• Case Fans 

• Case shock mounts 

The PC platform must be completed with the following extensions: 

• MPEG encoder (2) 

• Serial expansion board 

• Analog I/O board 

• CAN card 

• System hard drive (see section C.7) 

• PCMCIA slot board 

• WiFi card and antenna 

C.5. INPUT SENSOR REQUIREMENTS 

This section lists all sensors known to be required by the system. There is one subsection for 

each sensor, which combines functional, performance, and interface requirements unless 

otherwise specified. In general: COTS components must be selected on the basis of 

performance/cost ratio and be positioned as industry standards in their product class, unless 

otherwise specified. 

Input sensors acquire information about the environment and feed data into the OBP. As such, all 

input sensors need to interface to the OBP. This is done in two ways: 

The sensor outputs data to the J-Bus, which enables acquisition by the OBP 

A direct data link is established between the sensor and the OBP 

In the latter case, the nature of the hardware data link between the sensor and the OBP must be 

specified. Another consideration is whether the data transfer protocol is “push” (sensor sending 

data) or “pull” (OBP querying data). 

Data requirements for each sensor are guided by two dimensions: (1) the output unit and (2) the 

sampling rate. 

C.5.1. Accelerometer 

The accelerometer must sense the longitudinal acceleration rate of the truck. 

• OBP interface: J-Bus 

• Output: m.s-2 

• Sampling rate: 1 Hz 

204 
C.5.2. EOBR (HOS) 

The EOBR must acquire driver identification and track HOS. Driver identification may be a 

functionality of the EOBR system or may be provided by a separate COTS identification reader 

that feeds into the EOBR. 

• OBP interface: TBD 

• Output: min, DriverID 

• Sampling rate: 1/60 Hz 

C.5.3 Front-Collision Warning System 

The front-collision warning system must be a radar-based system that detects forward collision 

threats. The system must deliver a warning to the driver when such a threat is imminent. 

The system also provides the distance between the truck and the leading vehicle on a continuous 

basis. 

• Output: meters, activation events 

• Sampling rate: 10 Hz 

C.5.4. GIS Roadway Map 

The GIS roadway map is a geographical database of roadway geometry and traffic rules and 

signs. 

• Output: Curvature: m-1 

• Speed limit: mph 

• Distance to stop sign: m 

• Sampling rate: 1 Hz 

C.5.5. GPS Receiver 

The GPS receiver must acquire the truck’s absolute position on a second by second basis. A GPS 

antenna must be integrated with the receiver. 

• Output: Lat, Long, HH:mm:ss 

• Sampling rate: 1 Hz 

C.5.6. Lane Departure Warning System 

The LDWS must be a video-based system that detects unintended or nonsignaled lane changes 

by correlating the truck’s position relative to lane delineators, the truck speed, and signal turn 

use. The LDWS must deliver a warning when such lane changes occur. 

205 
C.5.7. Outward Video Camera 

The outward video camera must capture video footage on the roadway immediately ahead of the 

truck on a continuous basis. Images must have a resolution of at least 320 x 240 at 30 frames per 

second in color. 

• Output: NTSC video 

• Sampling rate: 30 Hz 

C.5.8. Road Surface Conditions Sensor 

The road surface conditions sensor must be an infrared system that uses spectrographic 

techniques to detect road surface conditions such as: dry road, wet road, icy road, fog over the 

road, and snow on the road. 

• Output: Index variable 

• Sampling rate: 1/10 Hz 

C.5.9. Rollover Stability Advisor 

The rollover stability advisor must sense lateral acceleration and detect excessive curve velocity 

that puts the truck at risk of rolling over. The rollover stability advisor must deliver warnings 

accordingly. 

• Output: Danger event 

• Sampling rate: N/A 

C.5.10. Side-collision Warning System 

The side-collision warning system is a radar-based system that must monitor the presence of 

other vehicles to the immediate sides of the truck. The side collision warning system must 

deliver warnings to alert the driver of the presence of vehicles in the truck blind spot when the 

turn signal is activated. 

• Output: Danger event 

• Sampling rate: N/A 

C.5.11. Steering Angle Sensor 

The steering angle sensor must sense the angle that is applied to the steering wheel. 

• Output: degrees 

• Sampling rate: 10 Hz 

C.5.12. Thermometer 

The thermometer must sense external temperature. 

• Output: F 

206 
• Sampling rate: 1/60 Hz 

C.5.13. Throttle angle sensor 

The throttle angle sensor must sense the angle that is applied to the throttle pedal. 

• Output: degrees 

• Sampling rate: 10 Hz 

C.5.14. Wheel speedometer 

The wheel speedometer must acquire truck speed by counting wheel turns. 

• Output: Mph 

• Sampling rate: 1 Hz 

C.5.15. Wiper usage sensor 

The wiper usage sensor must sense the activation of windshield wipers. 

• Output: Dummy variable (on/off) 

• Sampling rate: 1/10 Hz 

C.6. DRIVER INTERFACES 

Driver interfaces must comprise the following components: 

• A driver identification system 

• A video device providing visual feedback and notices 

• An audio device providing audible notices 

• Warning signals provided by some of the COTS 

C.6.1. Driver Identification System 

The driver identification system must perform reliable, secure, and continuous identification of 

the current driver based on a personal smart card or access code. 

C.6.2. Video Feedback Device 

The video feedback device must be an LCD screen that is placed on the dashboard. The video 

feedback device must provide the driver with essential system information generated by the 

OBP, such as: 

• System states and diagnostics 

• Visual safety notices 

• Meaningful event notices and parameter values 

207 
C.6.3. Audio Feedback Device 

The audio feedback device must be a combination of DSP and speaker. The audio feedback 

device must deliver audible safety notices to the driver. 

C.7. DATA STORAGE 

C.7.1. Functional Requirements 

Onboard data storage must be a hard drive or flash memory that is accessed by the OBP to write 

and read recorded parameters and events. 

In order to allow transfers to the back-office systems, onboard system memory must be portable. 

This could be achieved by using a movable, portable memory device, or by enabling download 

from the OBP via a physical port or a wireless link. 

C.7.2. Performance Requirements 

Capacity 

The data storage device must store up to 30 days worth of driving parameters and events. 

Reliability 

The data storage device must observe the following requirements in order to withstand the 

operational environment: 

• The data storage devices must have less than 1 percent memory damage during the 

system life cycle.FT

• The data storage devices must tolerate shocks up to 30 gCOM

C.8. ANALYSIS MODULE 

The analysis module is a PC program that is used in the fleet dispatch to read and interpret the 

data logged by the onboard subsystems. 

C.8.1. Functional Requirements 

The analysis module must comprise the following components: 

• A secure database to host records from multiple drivers on a fleetFT

• An upload processor that reads and processes raw data from the onboard data storage 

• A report generator that queries and formats data into comprehensive, printable reportsFT

• A Graphical User Interface (GUI)COM

208 
Database FT 

The database must be designed to host data generated by the OBP. The database may not need to 

store raw data for all records. 

Upload 

The upload process must read data from the onboard data storage, process it, and insert it into the 

database. 

The upload process must be fast and efficient. 

Report generator FT 

The report generator must retrieve data from the database according to preset functional 

requirements. Data must be retrieved into reports that can be viewed on a computer screen or 

printed as fully formatted documents. 

The query engine must be expansible to allow users to develop new types of reports. 

Graphical User Interface COM 

The analysis module GUI must be simple and user-friendly. It must provide direct access to the 

main functionalities of the analysis module: 

• New data upload 

• Running preset report 

• Querying data 

• Administrative functions 

C.8.2. Material Requirements 

The material requirements for the analysis module are a modern PC with enough processing 

power, memory, and hard drive storage. 

Optionally, the analysis module may be installed on a network server. In this configuration, 

multiple clients may run the GUI and report engine, simultaneously accessing the database. 

C.8.3. Performance Requirements 

The following TPMs may be used to measure the performance of the analysis module. 

Data storage 

Data storage must be measured in GB but, more importantly, typical amounts of data collected 

during drives should be used to express requirements in terms of vehicle-hours traveled (VHT). 

209 
Processing speed 

Processing speed must be measured for both data upload and data queries. Speed must be 

measured in seconds, as a function of the volume of data being uploaded or queried. 

Human factors 

The GUI must be easy to use, which must be measured by the average time dispatchers require to 

master the most essential functionalities.COM

210