Wireless Roadside Inspection 

Proof-of-Concept Test 

September 2009
FOREWORD 

This study focuses on the ability of a Universal Wireless Inspection System to collect driver, 

vehicle, and carrier information; format a Safety Data Message Set from this information; and 

wirelessly transmit a Safety Data Message Set to a roadside receiver unit or mobile enforcement 

vehicle. 

The work performed under the project included: 

 Developing the Wireless Roadside Inspection Proof-of-Concept Fast Track Plan to 

conduct the Proof-of-Concept testing by using off-the-shelf technology to the fullest 

extent possible and by forming partnerships with the providers of such technology. 

 Drafting the project Statement of Work. 

 Drafting the Proof-of-Concept Test Plan. 

 Developing technology to identify a vehicle and that vehicle’s driver and carrier. 

 Developing technology to give the status of a vehicle and that vehicle’s driver and 

carrier. 

 Developing technology to format a Safety Data Message Set from driver, vehicle, and 

carrier information. 

 Developing technology to transfer the Safety Data Message Set to the roadside or Mobile 

Enforcement Vehicle. 

 Conducting the Proof-of-Concept Test. 

 Analyzing the data from the Proof-of-Concept Test. 

 Drafting a Final Report. 

NOTICE 

This document is disseminated under the sponsorship of the U.S. 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 or manufacturers named herein. 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-09-007 

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

5. Report Date 

 September 2009 

4. Title and Subtitle 

WIRELESS ROADSIDE INSPECTION PROOF-OF-CONCEPT TEST 

6. Performing Organization Code 

7. Author(s) 

Gary Capps, Oscar Franzese, Bill Knee, Randall Plate, 

Mary Beth Lascurain 

8. Performing Organization Report No. 

9. Performing Organization Name and Address 10. Work Unit No. (TRAIS) 

Oak Ridge National Laboratory 

Center for Transportation Analysis 

2360 Cherahala Boulevard 

Knoxville, TN 37932 

11. Contract or Grant No. 

DTMC75-03-X-00047/Mod 9 

13. Type of Report and Period Covered 

Final Report, 

June 2006–December 2007 

12. Sponsoring Agency Name and Address 

U.S. Department of Transportation 

Federal Motor Carrier Safety Administration 

Office of Analysis, Research and Technology 

1200 New Jersey Ave. SE 

Washington, DC 20590 

14. Sponsoring Agency Code 

FMCSA 

15. Supplementary Notes 

This program was administered through the Federal Motor Carrier Safety Administration (FMCSA). 

The FMCSA Program Manager is Jeff Loftus. 

16. Abstract 

This project was undertaken to determine the feasibility of gathering vehicle, driver, and carrier data to be used to 

format and wirelessly transmit from a commercial motor vehicle a Safety Data Message Set (SDMS). The Wireless 

Roadside Inspection (WRI) Program is defined in three phases: 

 Phase 1: Proof-of-Concept Test (POC)—Testing of commercial off-the-shelf technology to validate WRI concept. 

 Phase 2: Pilot Test—Safety technology maturation and back-office system integration. 

 Phase 3: Field Operational Test—Multi-vehicle testing over a multi-state region 

This report focuses on Phase 1 efforts. Technical efforts dealt with the ability of a wireless inspection system to collect 

driver, vehicle, and carrier information; format a SDMS from this information; and wirelessly transmit a SDMS to a 

roadside receiver unit or mobile enforcement vehicle. As a result of the WRI POC testing, it is concluded that WRI 

holds considerable promise in increasing highways safety by: 

 Improving the quality of the inspections performed. 

 Allowing more inspections to be conducted 

 Providing industry benefits for these technologies that encourage early adoption. 

Because of these positive results, it is recommended that Phase 2 (Pilot Testing) be engaged. 

17. Key Words 

Wireless Roadside Inspection, WRI, Wireless, Inspection, 

SDMS, Safety Inspection, CMV, commercial motor vehicle 

18. Distribution Statement 

No restrictions. 

19. Security Classif. (of this report) 

Unclassified 

20. Security Classif. (of this page) 

Unclassified 

21. No. of Pages 

95 

22. Price 

N/A 

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

Table of APPROXIMATE CONVERSIONS TO SI UNITS 

Symbol When You Know Multiply By To Find Symbol 

LENGTH 

in inches 25.4 millimeters mm 

ft feet 0.305 meters m 

yd yards 0.914 meters m 

mi miles 1.61 kilometers km 

AREA 

in2 square inches 645.2 square millimeters mm2 

ft square feet 0.093 square meters m2 

yd square yards 0.836 square meters m2 

ac acres 0.405 hectares ha 

mi square miles 2.59 square kilometers km2 

VOLUME Note: Volumes greater than 

1000 L shall be shown in m3 

fl oz fluid ounces 29.57 milliliters mL 

gal gallons 3.785 liters L 

ft3 cubic feet 0.028 cubic meters m3 

yd3 cubic yards 0.765 cubic meters m3 

MASS 

oz ounces 28.35 grams g 

lb pounds 0.454 kilograms kg 

T short tons (2000 lb) 0.907 megagrams (or “metric ton”) Mg (or “t”) 

TEMPERATURE Temperature is in exact degrees 

°F Fahrenheit 5 × (F-32) ÷ 9 

or (F-32) ÷ 1.8 

Celsius °C 

ILLUMINATION 

fc foot-candles 10.76 lux lx 

fl foot-Lamberts 3.426 candela/m2 cd/m2 

FORCE and PRESSURE or STRESS

lbf poundforce 4.45 newtons N 

lbf/in2 poundforce per square inch 6.89 kilopascals kPa 

Table of APPROXIMATE CONVERSIONS FROM SI UNITS 

Symbol When You Know Multiply By To Find Symbol 

LENGTH 

mm millimeters 0.039 inches in 

m meters 3.28 feet ft 

m meters 1.09 yards yd 

km kilometers 0.621 miles mi 

AREA 

mm2 square millimeters 0.0016 square inches in2 

m2 square meters 10.764 square feet ft 

m2 square meters 1.195 square yards yd 

ha hectares 2.47 acres ac 

km2 square kilometers 0.386 square miles mi 

VOLUME 

mL milliliters 0.034 fluid ounces fl oz 

L liters 0.264 gallons gal 

m3 cubic meters 35.314 cubic feet ft3 

m3 cubic meters 1.307 cubic yards yd3 

MASS 

g grams 0.035 ounces oz 

kg kilograms 2.202 pounds lb 

Mg (or “t”) megagrams (or “metric ton”) 1.103 short tons (2000 lb) T 

TEMPERATURE Temperature is in exact degrees 

°C Celsius 1.8C + 32 Fahrenheit °F 

ILLUMINATION 

lx lux 0.0929 foot-candles fc 

cd/m2 candela/m2 0.2919 foot-Lamberts fl 

FORCE and PRESSURE or STRESS 

N newtons 0.225 poundforce lbf 

kPa kilopascals 0.145 poundforce per square inch lbf/in2 

* SI is the symbol for the International System of Units. Appropriate rounding should be made to comply with Section 4 of ASTM E380. 

(Revised March 2003, Section 508-accessible version August 2009) 

ii 
TABLE OF CONTENTS 

LIST OF ACRONYMS .............................................................................................................VII

EXECUTIVE SUMMARY ........................................................................................................XI

1. PROJECT OVERVIEW ......................................................................................................1

1.1 INTRODUCTION .........................................................................................................1 

1.2 GOALS AND OBJECTIVES........................................................................................2 

1.2.1 ................................................................................................................. 2 Goals

1.2.2 Objectives ......................................................................................................... 2 

1.3 PARTNERS ...................................................................................................................3 

1.3.1 .......................................................................................................... 3 PeopleNet

1.3.2 Air-Weigh, Inc. ................................................................................................. 3 

1.3.3 TechnoCom Corporation .................................................................................. 3 

1.4 PROJECT TEAM ..........................................................................................................4 

1.5 APPROACH ..................................................................................................................5 

1.5.1 ........................................................................................................... 5 Phase 1A

1.5.2 ............................................................................................................ 6 Phase 1B

1.5.3 WRI POC Testing Platforms ............................................................................ 6 

1.6 SCHEDULE...................................................................................................................8 

2. PROOF-OF-CONCEPT TEST DESCRIPTION...............................................................9

2.1 WRI NETWORK AND UWIS OPERATION ..............................................................9 

2.2 EQUIPMENT AND TECHNOLOGY ........................................................................11 

2.2.1 PeopleNet System........................................................................................... 11 

2.2.2 Middle-Ware Computer.................................................................................. 12 

2.2.3 TechnoCom Transceiver................................................................................. 12 

2.2.4 Air-Weigh ....................................................................................................... 14 

2.2.5 ORNL Comparison System ............................................................................ 15 

2.3 SDMS DATA CATEGORY AND SOURCE .............................................................16 

2.4 TEST VEHICLES........................................................................................................17 

2.5 ROADSIDE CONFIGURATIONS .............................................................................19 

2.6 TESTING ELEMENTS...............................................................................................20 

2.6.1 Tested Features............................................................................................... 20 

2.6.2 Features Not Tested ........................................................................................ 20 

2.6.3 Testing Entry and Exit Criteria ....................................................................... 21 

2.6.4 Technology Pass/Fail and Evaluation Criteria................................................ 21 

iii 
3. ..........................................................................................PROOF-OF-CONCEPT TEST 23

3.1 PHASE 1A...................................................................................................................23 

3.1.1 Introduction..................................................................................................... 23 

3.1.2 Data Collected................................................................................................. 24 

3.1.3 Data Analysis.................................................................................................. 27 

3.1.4 Phase 1A Test Conclusions and Future Work ................................................ 37 

3.2 PHASE 1B ...................................................................................................................38 

3.2.1 Introduction..................................................................................................... 38 

3.2.2 Data Collection and Results............................................................................ 40 

3.2.3 Test Conclusions and Future Work................................................................. 46 

4. TECHNOLOGY SHOWCASE .........................................................................................49

5. WRI INTERFACE..............................................................................................................53

6. WRI POC PARTICIPANT QUESTIONAIRES..............................................................57

6.1 TDOS SURVEY..........................................................................................................57 

6.2 DRIVER SURVEYS ...................................................................................................59 

7. LESSONS LEARNED........................................................................................................61

8. SUMMARY OF RESULTS AND CONCLUSION..........................................................65

9. SUGGESTED FUTURE RESEARCH/RECOMMENDATIONS .................................67

REFERENCES.............................................................................................................................79

LIST OF APPENDICES 

APPENDIX A: WIRELESS ROADSIDE INSPECTION PROOF-OF-CONCEPT 

TESTING FAST TRACK PLAN DISCUSSION PAPER ..............................................69

APPENDIX B. ACKNOWLEDGEMENTS ..............................................................................77

iv 
LIST OF FIGURES 

Figure 1. Diagram. The WRI POC Testing Platforms (configurations and components)...............7 

Figure 2. Gantt Chart. WRI POC Schedule .....................................................................................8 

Figure 3. Drawing. WRI Network Configuration............................................................................9 

Figure 4. Block Diagram. WRI POC UWIS..................................................................................10 

Figure 5. Photo. UWIS as Installed on the Test Tractor................................................................10 

Figure 6. Photo. PeopleNet OBC and Display Used in the WRI POC..........................................11 

Figure 7. Photo. MCNU Interface Panel........................................................................................14 

Figure 8. Photo. MCNU RF Panel.................................................................................................14 

Figure 9. Photo. Air-Weigh In-Cab Display..................................................................................15 

Figure 10. Photo. ORNL Comparison System DAS......................................................................16 

Figure 11. Photo. ORNL Comparison System Mounted in Test Vehicle......................................16 

Figure 12. Photo. WRI POC Test Tractor......................................................................................18 

Figure 13. Photo. DOE Van Used to Simulate a MEV..................................................................18 

Figure 14. Photo. Tennessee Highway Patrol Car Similar to That Used as a MEV......................19 

Figure 15. Photo. Roadside Unit at the Knox County Inspection Station .....................................19 

Figure 16. Photo. Roadside Unit at the Greene County Inspection Station...................................20 

Figure 17. Map. Phase 1A Test Route and CMV Inspection Stations...........................................24 

Figure 18. Graph. Test Vehicle Speed Profile and Communication/GPS Blackout Periods.........27 

Figure 19. Map. Vehicle Position as Provided by the Kernel and Ground-Truth Original 

Messages ........................................................................................................................31 

Figure 20. Map. Vehicle Position as Provided by the Kernel and Ground-Truth Messages 

That Have Been Shifted 15 Seconds..............................................................................33 

Figure 21. Graph. HOS Diagram for Driver 1 Constructed Using Kernel (K) and 

Ground-Truth (GT) Messages........................................................................................37 

Figure 22. Graph. HOS Diagram for Driver 2 Constructed Using Kernel (K) and 

Ground-Truth (GT) Messages........................................................................................37 

Figure 23. Photo. Placement of the MCNU Dome Antenna on WRI Test Truck .........................39 

Figure 24. Location grid. Truck and MEV Positioning for Static Tests........................................41 

Figure 25. Location grid. File Transmission to the MEV at 5.9 GHz Using the Dome 

Antenna ..........................................................................................................................42 

Figure 26. Photo. Location of Signs at Knox County Inspection Station......................................43 

Figure 27. Diagram. Layout of Test Site at Eastbound Knox County CMV Inspection 

Station.............................................................................................................................43

Figure 28. Diagram. MEV-Truck Positions for Over-The-Road Tests Performed at 

Highway Speeds.............................................................................................................44 

Figure 29. Combined Diagrams. Dome Antenna Placement and Results for Over-the-Road 

(55 mi/h) Orientation Testing at 5.9 GHz ......................................................................45 

Figure 30. Aerial Photo. View of the Greene County CMV Inspection Station ...........................50 

Figure 31. Photo. WRI POC MEV Ready for Demonstration.......................................................50 

Figure 32. Photo. Wal-Mart Truck on the PBBT at the Aug 7, 2007 Showcase...........................51 

v 
Figure 33. Screen shot. WRI GUI Overview Screen.....................................................................53 

Figure 34. Screen shot. WRI GUI Driver Screen ..........................................................................54 

Figure 35. Screen shot. WRI GUI Carrier Screen .........................................................................54 

Figure 36. Screen shot. WRI GUI Vehicle Screen ........................................................................55 

Figure 37. Screen shot. WRI GUI HOS Screen.............................................................................55 

LIST OF TABLES 

Table 1. List of WRI POC Project Team Entities............................................................................4 

Table 2. SDMS Data and Input Method ........................................................................................17 

Table 3. Information Collected in Phase 1A Test..........................................................................25 

Table 4. Accuracy of Kernel Databus and Location Information Considering All Messages ......29 

Table 5. Accuracy of Kernel Databus and Location Information Without Repeated Messages...30 

Table 6. Accuracy of Kernel Databus and Location Information without Repeated Messages 

and with Time Shift........................................................................................................34 

Table 7. Kernel Message Delays in Providing Driver 1 Duty Status Change (DRDUTYTIME 

Field Used).....................................................................................................................35 

Table 8. Kernel Message Delays in Providing Driver 2 Duty Status Change (DRDUTYTIME 

Field Used).....................................................................................................................35 

Table 9. Results of Drive-by Dynamic Transmission Tests at Tested Speeds ..............................45 

vi 
LIST OF ACRONYMS 

Acronym Definition 

ABS antilock braking system 

ASCII American Standard Code for Information Interchange 

BOA back-office application 

CAN controller area network 

CDL commercial driver’s license 

CMV commercial motor vehicle 

COTS commercial off-the-shelf 

CVO commercial vehicle operations 

DAS data acquisition system 

DDTS day-to-day test schedule 

DSRC dedicated short-range communications 

ECM engine control module 

EDT Eastern Daylight Time 

EOBR electronic on-board recorder 

FMCSA Federal Motor Carrier Safety Administration 

FOT field operational test 

FTP file transfer protocol 

GHz gigahertz 

GIS geographic information system 

GB gigabyte 

GUI graphical user interface 

GPS global positioning system 

vii 
Acronym Definition 

HOS hours of service 

Hz Hertz 

IEEE Institute of Electrical and Electronics Engineers 

IFTA International Fuel Tax Agreement 

KB kilobyte 

KUT kernel under test 

LCD liquid crystal display 

Mbps millions of bits per second 

MCNU multi-band configurable networking unit 

ME mobile equipment 

MEV mobile enforcement vehicle 

MHz megahertz 

mi/h miles per hour 

MOU memorandum of understanding 

NTRC National Transportation Research Center 

ORNL Oak Ridge National Laboratory 

OBC on-board computer 

Partners industry suppliers of the UWIS in partnership with ORNL/FMCSA 

PBBT performance-based brake tester 

PDA personal digital assistant 

POC proof of concept 

psi pounds per square inch 

QoS quality of service 

viii 
Acronym Definition 

RF radio frequency 

RTL roadside testing laboratory 

RSE roadside equipment 

RSU roadside unit 

RTC Roadside Technology Corridor 

Schrader Schrader Trucking 

SDMS safety data message set 

SDO scheduled day off 

SOW statement of work 

TELS test event log sheet 

TDOS Tennessee Department of Safety 

TDOT Tennessee Department of Transportation 

USB Universal Serial Bus 

USDOE U.S. Department of Energy 

USDOT U.S. Department of Transportation 

UTC universal time coordinates 

UWIS universal wireless inspection system 

VII vehicle infrastructure integration 

WRI Wireless Roadside Inspection 

ix 

EXECUTIVE SUMMARY 

PURPOSE 

The U.S. Department of Transportation (USDOT) Federal Motor Carrier Safety Administration 

(FMCSA) commissioned the Wireless Roadside Inspection (WRI) Program to validate 

technologies and methodologies that can improve safety through inspections using wireless 

technologies that convey real-time identification of commercial motor vehicles (CMVs), drivers, 

and carriers, as well as information about the condition of the vehicles and their drivers. It is 

hypothesized that these inspections will: 

 Increase safety—Decrease the number of unsafe commercial vehicles on the road. 

 Increase efficiency—Speed up the inspection process, enabling more inspections to 

occur, at least on a par with the number of weight inspections. 

 Improve effectiveness—Reduce the probability of drivers bypassing CMV inspection 

stations and increase the likelihood that fleets will attempt to meet the safety regulations. 

 Benefit industry—Reduce fleet costs, provide good return on investment, minimize wait 

times, and enable uniform roadside safety compliance checking of all motor carrier 

operations regardless of type and size of operations. 

The WRI Program is defined in three phases, which are: 

 Phase 1: Proof-of-Concept Test (POC)—Testing of commercial off-the-shelf (COTS) or 

near-COTS technology to validate the wireless inspection concept. 

 Phase 2: Pilot Test—Safety technology maturation and back-office system integration. 

 Phase 3: Field Operational Test (FOT)—Multi-vehicle testing over a multi-state 

instrumented corridor. 

This report focuses on Phase 1 efforts that were initiated in March 2006. Technical efforts dealt 

with the ability of a universal wireless inspection system (UWIS) to collect driver, vehicle, and 

carrier information; format a safety data message set (SDMS) from this information; and 

wirelessly transmit a SDMS to a roadside receiver unit or mobile enforcement vehicle. 

PROCESS 

This POC Test involved the development and testing of a UWIS, the acquisition of lessons 

learned from the WRI POC testing, and the conduct of a public showcase of the tested 

technologies. Such testing and public demonstration would not have been possible without the 

efforts of a team of experts in the areas of vehicle enforcement, vehicle data generation, data 

collection, and data transmission. As a result, partnerships were formed between the Oak Ridge 

National Laboratory (ORNL), the Tennessee Department of Safety (TDOS), the Tennessee 

Department of Transportation (TDOT), and a number of private-industry participants, many of 

which participated in Phase 1 efforts without compensation. The purposes of the partnerships 

were to form teams that could: 

xi 
 Develop the necessary capabilities for data collection, data buffering, and formatting of 

the SDMS. 

 Secure the “best available” wireless technology and communications support. 

 Define the required inputs for the UWIS based on COTS sensor and systems technology. 

 Instrument a Class-8 tractor with the partner-developed and supplied kernels and 

transceivers. 

 Cooperatively test each partner-kernel at the I-40/I-75 Inspection station in Knox County, 

TN, with the test vehicle in a static mode; traveling in the bypass lane; traveling at 

highway speed; and in close proximity to a patrol car at highway speed. 

RESULTS 

The POC testing was conducted via a WRI POC Test Plan that was developed by ORNL and 

followed during the associated efforts. The WRI POC effort involved a number of activities, 

including: 

 Definition of a SDMS. 

 Development of partner-based UWIS kernels. 

 Testing of the UWIS on the FMCSA CMV Roadside Technology Corridor (RTC) to 

assess input to and output from the UWIS under varying conditions/situations. 

 Conduct of a POC Data Analyses. 

 Public Demonstration Testing on the CMV RTC on August 7, 2007. 

 Production of a Final Report. 

This report provides details of these efforts. Some of the major results from the WRI POC testing 

included the following: 

 The POC testing demonstrated that it was possible for the kernel to gather information 

from different sources, including an electronic on-board recorder (EOBR) and a vehicle 

databus, assemble the required SDMS, and make it available for transmission to a 

roadside unit (RSU) or mobile enforcement vehicle (MEV). 

 The transmission frequency at which these messages were generated was very high (i.e., 

an average of one SDMS every 10.2 seconds). 

 The largest observed delay in generating a new SDMS was just over 5 minutes, which 

was considered acceptable. 

 The accuracy of the information posted on the SDMS was measured within a certain 

tolerance that was arbitrarily set at three levels. 

 Information related to the spatial position of the vehicle (obtained from global positioning 

system [GPS] readings) was 100 percent accurate when considering a tolerance of 1,000 ft. 

 Vehicle speed (also determined via GPS readings) was provided at an accuracy level of 

more than 80 percent when considering a tolerance of 1 mile per hour (mi/h) or less, and 

close to 100 percent with a tolerance of 5 mi/h or less. 

 Odometer information (read from the vehicle’s databus) was 79 percent accurate when 

considering a tolerance of 0.25 mi/h. 

xii 
 Assessment of Hours of Service (HOS) information in the POC presented some 

problems. Inaccuracies, albeit minor, in the generation of a HOS diagram were 

experienced. More critical, however, was the delay in relaying of the messages, which 

ranged from 5 to 20 minutes. 

 Antenna when tripod-mounted received the SDMS more reliably than when the antenna 

was mounted on the MEV. 

 In the bypass-lane tests, the body of the truck itself and objects near the roadway limited 

the time during which transmission could occur; in addition, several pit-scale weight 

information signs were present along the right side of the bypass lane. 

 Results of the dynamic orientation tests indicated that a central placement of the dome 

antenna on the MEV roof was preferable to other potential placements. 

 Both the static and dynamic tests showed that there are unresolved issues regarding file 

transfers when the MEV is directly in front of the truck. 

 Use of the stick antenna is very inefficient at 2.4 gigahertz (GHz). 

 Use of the dome-type antenna at both 2.4 GHz and 5.9 GHz indicated much improved 

performance at 2.4 GHz. 

 The POC test demonstrated that the wireless inspection system tested was sufficiently 

robust to function as designed in real-world driving environments. 

 The reliability of file transfer varied with antenna type, placement, and frequency. 

 The POC test demonstrated that it is possible to reliably transfer an SDMS at highway 

speeds. 

CONCLUSION AND FUTURE DIRECTIONS 

The primary conclusion of the WRI POC testing was that the information contained in the 

SDMS was sufficiently accurate and acceptable to engage in future related research. Suggested 

research topics, with the reasons for their inclusion, are as follows: 

 Timeliness of the HOS information that is added to the SDMS: Most of the observed 

problems were attributed to communication and software issues; however, these 

problems are not insurmountable. 

 Reduction of the delays inherent to the system due to back-office communication of the 

kernel. 

 More extensive testing regarding ideal antenna parameters including type, height, 

position, and orientation: Antenna and communication requirements should be developed 

and refined to include required frequency (2.4 GHz vs. 5.9 GHz), antenna type, and 

optimal placement of the antenna on each instrumented vehicle. 

 Testing a larger number of vehicles to verify system feasibility on a wider scale: Largerscale testing should be designed to test performance when several instrumented vehicles 

pass an RSU all at the same time. 

 Development of the ability to visually identify which truck (in a group) is providing the 

information viewed by enforcement personnel for each wireless inspection. 

xiii 
In future tests, several administrative issues also need to be emphasized. These are as follows: 

 It is important that more detailed technical discussions be carried out between the tester 

and the developers of the system. Such communication would facilitate a better 

understanding of the idiosyncrasies of both the data acquisition system (DAS) and the 

kernel. 

 Emphasis should also be placed on gratis partnerships to minimize cost and maximize 

industry buy-in. 

As a result of the WRI POC testing, it is concluded that wireless roadside inspection holds 

considerable promise in increasing the safety of our highways by: 

 Improving the quality of the inspections performed. 

 Allowing more inspections to be conducted, due to the increased efficiency of the system. 

 Assuring that a larger percentage of the trucks on our highways are inspected. 

 Providing industry benefits for these technologies that encourage early adoption. 

Because of these positive results, it is recommended that Phase 2 (Pilot Testing)—safety 

technology maturation and back-office system integration—be engaged. If these efforts are also 

successful, it is recommended that Pilot Testing be followed by Phase 3 (Field Operational 

Test)—multi-vehicle testing over a multi-state instrumented corridor. 

xiv 
1. PROJECT OVERVIEW 

1.1 INTRODUCTION 

The mission of the U.S. Department of Transportation (DOT) Federal Motor Carrier Safety 

Administration (FMCSA) is to reduce crashes, injuries, and fatalities involving large trucks and 

buses. Its goal by 2008 is to reduce commercial motor vehicle (CMV)-related fatalities to 1.65 

fatalities per 100 million CMV-miles traveled. 

There currently exists a safety inspection violation rate of 73 percent, or approximately 2.2 

million annual inspections out of 3 million. This indicates that numerous CMVs are on the road 

with driver and/or vehicle infractions. Using wireless technology, FMCSA could potentially 

increase the number of inspections per year to approximately the number of weight inspections 

(82 million) and subsequently reduce the percentage of vehicles on the road with violations. It is 

expected that this will greatly reduce the violation rate by encouraging better vehicle 

maintenance and driver behavior. 

The FMCSA has commissioned the Wireless Roadside Inspection (WRI) Program to validate 

technologies and methodologies that can improve safety through inspections using wireless 

technologies that convey real-time identification of commercial vehicles, drivers, and carriers, as 

well as information about the condition of the vehicles and their drivers. It is hypothesized that 

these inspections will: 

 Increase safety—Decrease the number of unsafe commercial vehicles on the road 

 Increase efficiency—Speed up the inspection process, enabling more inspections to 

occur, at least on a par with the number of weight inspections 

 Improve effectiveness—Reduce the probability of drivers bypassing CMV inspection 

stations and increase the likelihood that fleets will attempt to meet the safety regulations 

 Benefit industry—Reduce fleet costs, provide good return on investment, minimize wait 

times, and enable uniform roadside safety compliance checking of all motor carrier 

operations regardless of type and size of operations. 

To this end, the WRI Program is defined in three parts: 

 Phase 1: Proof-of-Concept Test (POC)—Testing of commercial off-the-shelf (COTS) 

or near-COTS technology to validate the wireless inspection concept. 

 Phase 2: Pilot Test—Safety technology maturation and back-office system integration. 

 Phase 3: Field Operational Test—Multi-vehicle testing over a multi-state instrumented 

corridor. 

The Oak Ridge National Laboratory (ORNL) began discussions with FMCSA staff concerning 

the WRI Program in March 2006 and drafted a WRI discussion paper in May 2006. ORNL was 

asked to participate in an initial planning meeting for the WRI Program in June 2006. This 

meeting was held at FMCSA Headquarters in Washington, DC. From this meeting, ORNL was 

tasked to conduct the WRI POC testing within the CMV Roadside Testing Corridor (RTC) 

located in East Tennessee. ORNL drafted the WRI POC Fast Track Plan, which called for 

1 
partnering with private industry to quickly develop and field test technology to accomplish the 

goals of the WRI POC. See Appendix A for a copy of the Fast Track Plan Discussion Paper. 

ORNL was asked to lead the WRI POC and to conduct a Technology Showcase/Media Event on 

August 7, 2007, to showcase the WRI technology and other emerging and state-of-the-practice 

technologies being used at the Greene County, Tennessee CMV inspection station, located at 

mile marker 21 on southbound Interstate 81 (I-81). This inspection station is the northeast anchor 

point for the CMV RTC. 

ORNL drafted the project Statement of Work (SOW) in the fall of 2006, drafted the Test Plan 

and formed partnerships in the spring of 2007, and conducted the POC and the Technology 

Showcase in the summer of 2007. 

This final report addresses the Phase 1 POC that was conducted by ORNL to validate the 

technology needed to collect, assemble, and wirelessly transmit the vehicle, carrier, and driver 

safety data to fixed and mobile receivers. Phases 2 and 3 of the WRI Program were not 

conducted under this effort and will be addressed in this report only as efforts of these phases 

relate to the POC. 

1.2 GOALS AND OBJECTIVES 

1.2.1 Goals 

The five goals of the Phase 1 WRI POC Program were to: 

 Demonstrate the ability to gather appropriate vehicle, driver, and carrier data germane to 

the Phase 1 POC testing via a vehicle’s data bus, Global Positioning System (GPS) 

receiver, the vehicle operator’s input to the vehicle’s Universal Wireless Inspection 

System (UWIS), and the carrier’s input to the vehicle’s UWIS. 

 Demonstrate the industry partner-supplied kernel’s ability to collect, store, and transfer 

vehicle, driver, and carrier information to the transceiver in the format specified for the 

Safety Data Message Set (SDMS) (see section 2.0 for description of kernel and 

transceiver). 

 Demonstrate the transceiver’s ability to wirelessly transmit data from the UWIS to a 

second unit (roadside and mobile) at Interstate speed. 

 Obtain feedback from WRI stakeholders involved in the POC to verify the overall 

Concept of Operations and some of the high-level requirements. 

 Obtain feedback from the test vehicle operators concerning UWIS. 

1.2.2 Objectives 

The objectives of the Phase 1 WRI POC Program were to: 

 Formalize a partnership agreement with a kernel provider via a Memorandum of 

Understanding (MOU). 

 Develop the WRI POC Test Plan. 

 Conduct the WRI POC per the Test Plan. 

2 
 Analyze data from the WRI POC. 

 Obtain stakeholder and operator feedback to the extent possible within the limited scope 

of the test. 

1.3 PARTNERS 

Through an MOU, ORNL partnered with PeopleNet, a mobile computing and communications 

provider, to provide the kernel for the UWIS, and with Air-Weigh, Inc. to provide the on-board 

vehicle weighing system to provide the tractor’s real-time weight; these partnerships were gratis. 

ORNL also partnered with TechnoCom Corporation to provide the transceiver technology on a 

contractual basis. 

1.3.1 PeopleNet 

PeopleNet, based in Minneapolis, MN, is a provider of on-board computing and mobile 

communications solutions to the transportation industry, serving nearly 1,500 fleets across the 

for-hire and private fleet sectors. With more than 30 new product innovations delivered to the 

market in the last two years, PeopleNet’s core platform enables rapid application delivery to the 

market. This core platform includes the patented over-the-air programming capability that allows 

for wireless software updating of mobile/on-board units. The platform is based on an “open” 

architecture that enables data exchange with multiple third-party systems, such as the WRI POC 

platform. 

1.3.2 Air-Weigh, Inc. 

Air-Weigh, Inc. is a supplier of on-board weighing technologies that provides reliable and 

accurate products. The company is based in Eugene, OR, and since its inception, has provided 

technological solutions to longstanding transportation industry problems. 

Air-Weigh’s vision is to help the transportation industry “load smart.” The company’s mission is 

to increase efficiency and reduce waste within the transportation industry by implementing onboard weighing. Through the use of on-board scales, Air Weigh, Inc. contends that companies 

can improve profits while reducing wasted fuel, overall emissions, and vehicle wear associated 

with over-weight miles. Air-Weigh scales have the potential to improve operations in the 

transportation industry and benefit the greater community through improved safety, reduction in 

road and bridge damage, improved fuel usage, and enhanced company efficiency. 

1.3.3 TechnoCom Corporation 

TechnoCom Corporation is a provider of solutions to enable wireless location networks and to 

ensure their ongoing performance. Based in Encino, CA, it offers location quality of service 

(QoS) test and measurement solutions to wireless operators and service providers, and provides 

Vehicle Infrastructure Integration (VII) solutions to the transportation and automotive industries, 

systems integrators, and Federal, state, and local government agencies. 

3 
1.4 PROJECT TEAM 

The WRI POC project team consisted of the following entities, shown in Table 1. 

Table 1. List of WRI POC Project Team Entities 

FMCSA Role: WRI POC Sponsor 

Contact Name: Jeff Loftus 

Title: Transportation Specialist 

Phone Number: 202-385-2363 

ORNL Role: WRI POC Technical Lead 

Contact Name: Gary Capps 

Title: Technical Director CMV RTC 

Phone Number: 865-946-1285 

Tennessee Department 

of Safety (TDOS) Role: Provide Law Enforcement Support 

 Nashville Contact Name: Capt. Steve Binkley 

Title: Test Coordinator 

Phone Number: 615-687-2317 

Contact Name: Capt. J. R. Bridgeman 

Title: Officer in Charge 

 Knoxville 

 Inspection 

 Station Phone Number: 865-966-5071 

Contact Name: Lt. James McKenzie 

Title: Officer in Charge 

 Greene County 

 Inspection 

 Station Phone Number: 423-235 4104 

PeopleNet Role: Provide UWIS Kernel 

Contact Name: Brian McLaughlin 

Title: Director of Marketing 

Phone Number: 888-346-3486 ext. 211 

Air-Weigh Role: Provide On-Board Weighing Capability 

Contact Name: Jim Morton 

Title: Product Management 

Phone Number: 704-876-1909 

TechnoCom Role: Provide Transceiver Capability 

Contact Name: Justin McNew 

Title: Director, Mobility Solutions 

Phone Number: 818-501-1903 

Commercial Carrier 

Consultants 

Role: Provide Test Tractor 

Contact Name: Wilber Thomas 

Title: Owner 

Phone Number: 719-545-7843 

Greene Coach Role: Provide Motor Coach 

Contact Name: Russell Ooten 

Title: Owner 

Phone Number: 423-638-8271 

4 
1.5 APPROACH 

As defined for this project, a proof of concept “is a short and/or incomplete realization (or 

synopsis) of a certain method or idea(s) to demonstrate its feasibility, or a demonstration in 

principle, whose purpose is to verify that some concept or theory is probably capable of 

exploitation in a useful manner. The proof of concept is usually considered a milestone on the 

way to a fully functioning prototype.” 

To this end, the WRI POC tested the concept of inspecting a commercial vehicle wirelessly. This 

was accomplished by designing and specifying a UWIS. This “universal” system can be installed 

on any commercial vehicle in an aftermarket fashion, and it will gather and transmit data 

germane to motor vehicle enforcement. 

ORNL gathered a team of experts in the areas of vehicle enforcement, vehicle data generation, 

data collection, and data transmission to participate in the WRI POC and to develop the UWIS. 

The WRI POC team was formed either by MOUs on a gratis basis (partnerships), or by contract. 

The UWIS that was developed to inspect the test vehicles wirelessly during the WRI POC 

consisted of a user interface (for data input), a kernel (to collect and process the data), and a 

transceiver (to transfer the data wirelessly). The user interface allowed hand-entry of data by the 

vehicle operator (e.g., driver’s name) and by the carrier (e.g., carrier’s name, DOT number, 

vehicle license plate number, etc.). The kernel connected to the user interface, a GPS receiver, 

and the vehicle’s Controller Area Network (CAN) data bus to collect data relative to the driver, 

carrier, and vehicle. These data formed the SDMS (an American Standard Code for Information 

Interchange [ASCII] flat file). 

ORNL conducted the POC using a commercial vehicle (Class-8 tractor) fitted with a UWIS 

which transferred the SDMS to the roadside and to a mobile enforcement vehicle (MEV). The 

POC was divided into two sets of testing: Phase 1A, UWIS kernel testing; and Phase 1B, 

transceiver testing (to include the Phase 1A UWIS kernel). 

The WRI POC Test Plan was developed to guide the testing and data collection. The WRI POC 

Test Plan was submitted to FMCSA in its final form on December 4, 2007, as Rev 1.5. 

1.5.1 Phase 1A 

An MOU was put in place with PeopleNet, which supplied the UWIS kernel for testing. The 

MOU defined the roles of ORNL and PeopleNet for the POC, established the POC timeline, and 

acknowledged the gratis nature of the partnership. 

Once the UWIS kernel was developed, PeopleNet hand-delivered its system to the National 

Transportation Research Center (NTRC), located in Knoxville, TN. It provided instructions to 

the ORNL staff regarding how to integrate its systems onto the test vehicle and how to operate 

the technology. A pre-POC shakedown was conducted to verify that the equipment was 

operational. After this preliminary equipment check, the POC testing was conducted as specified 

in the WRI POC Test Plan. The test vehicle was operated in various modes of driver status (e.g., 

on-duty, on-duty driving, off-duty) within a 100-air-mile radius of the NTRC. The POC testing 

5 
for the partners’ UWIS kernel was completed in approximately 10 hours. The technology of the 

partners remained on the test vehicle for Phase 1B testing. 

1.5.2 Phase 1B 

This phase involved the testing of the transceiver by transmitting the SDMS to the roadside 

CMV inspection station or MEV. The transceiver was tested at 5.9 GHz and 2.4 GHz in the 

following scenarios: 

 Test Vehicle-to-Roadside (vehicle stopped at weigh station; “static test” for baseline). 

 Test Vehicle-to-Roadside (low-speed bypass lane: 25 mi/h). 

 Test Vehicle-to-Roadside (high-speed: 55 mi/h). 

 Test Vehicle-to-MEV (neither vehicle moving for baseline). 

 Test Vehicle-to-MEV (low-speed: 25 mi/h, both traveling in same direction). 

 Test Vehicle-to-MEV (high-speed: 55 mi/h, both traveling in same direction). 

 Test Vehicle-to-MEV (test vehicle stopped, enforcement vehicle moving). 

 Test Vehicle-to-MEV (test vehicle moving, enforcement vehicle stopped). 

The SDMS received at the roadside was checked against the output of the kernel. Results from 

this testing were reviewed throughout the testing process. Changes were made (as practical) to 

antenna placement, antenna cable length, antenna height, and frequency in an attempt to optimize 

the transmission in each scenario. All changes or adjustments during actual testing were done by 

ORNL personnel and recorded as to type, amount, and time of the change. 

1.5.3 WRI POC Testing Platforms 

Figure 1 shows the testing platforms involved in the WRI POC, their configuration, and the 

components involved. These platforms were present on the truck/motor coach (test vehicles), at 

the roadside (CMV inspection station), and the MEV. See section 2.0 for additional details. 

6 
Figure 1. Diagram. The WRI POC Testing Platforms (configurations and components) 

7 
8 X1.6 SCHEDULE Figure 2 shows the schedule for the WRI POC and Technology Showcase. Figure 2. Gantt Chart. WRI POC Schedule 
2. PROOF-OF-CONCEPT TEST DESCRIPTION 

The POC was conducted beginning in late May 2007 and was completed just before the August 

7, 2007 Technology Showcase. 

2.1 WRI NETWORK AND UWIS OPERATION 

The WRI application used a network configuration that consisted of the UWIS, Roadside 

Equipment (RSE) or Mobile Equipment (ME) and a back-office application (BOA) server (see 

Figure 3). The UWIS within the Commercial Motor Vehicle (CMV) consisted of three primary 

parts: the data collection kernel, a middle-ware computer, and the wireless transceiver. The 

kernel (provided by PeopleNet) interacted with the various data sources to collect and package 

information to form a single-line SDMS. PeopleNet also provided custom software to allow the 

transfer of these data from their on-board computer (OBC) to a middle-ware laptop where a 

single-line SDMS was generated every 10 seconds. These SDMSs were then collected on the 

middle-ware computer, further packaged and formatted by ORNL software, and sent to a 

wireless transceiver provided by TechnoCom. See Figure 4 for a block diagram of the UWIS and 

Figure 5 for an image of the UWIS as tested in the WRI POC. The transceiver on-board the 

CMV would immediately attempt to transfer these data to a transceiver at the roadside (or in a 

MEV). 

The RSE subsequently transferred the data to a BOA server for processing and display on a 

second laptop running ORNL-developed software. In addition, the network supported querying 

the CMV by an MEV that contained the ME. 

Figure 3. Drawing. WRI Network Configuration 

RSE

MEV

5.9 GHz

CMV (UWIS)

BOA Cellular

Communication

RSE

MEV

5.9 GHz

CMV (UWIS)

BOA Cellular

Communication

For the POC, transfer of the SDMS was attempted as soon as the middle-ware computer 

provided new data to the transceiver (approximately every 10 seconds). However, the transceiver 

also had the ability to trigger data transfer by defining geo-zones*

 based on GPS. While this POC 

 

*

 Geo-zones are virtual boundaries established with a set GPS coordinates that can be placed around moving assets and user defined points of 

interest. 

9 
did not explore this feature of the transceiver technology, the transceiver suppliers indicated that 

the geo-zone information could be transmitted by the RSE to the UWIS to indicate where data 

upload should be triggered. Once an instrumented CMV entered the geo-zone associated with the 

RSE, it would transfer the data from the UWIS to the RSE and subsequently the BOA. The MEV 

could also be set up to query a CMV within a dynamic area centered around the MEV and based 

on current GPS locations. 

The BOA consisted of a laptop running a second piece of ORNL software to display the 

information received from the roadside transceiver. This software was primarily a graphical user 

interface (GUI) which providing an intuitive, concise means to view the SDMS from the CMV. 

See section 5.0 of this report for further information and screenshots of the GUI. 

Figure 4. Block Diagram. WRI POC UWIS 

Driver ID

Vehicle ID

Carrier ID

Driver Status

Vehicle Status

Kernel

T

r

a

n

s

c

e

i

v

e

r

POC Monitor Points

Data In SDMS Roadside

Inputs

Driver ID

Vehicle ID

Carrier ID

Driver Status

Vehicle Status

Kernel

T

r

a

n

s

c

e

i

v

e

r

POC Monitor Points

Data In SDMS Roadside

Inputs

Figure 5. Photo. UWIS as Installed on the Test Tractor 

Monitor and 

Keyboard for MCNU

Interface

Multi-band Configurable 

Networking Unit (MCNU) 

Transceiver

PeopleNet OBC

Middle-Ware 

Computer

Monitor and 

Keyboard for MCNU

Interface

Multi-band Configurable 

Networking Unit (MCNU) 

Transceiver

PeopleNet OBC

Middle-Ware 

Computer

10 
2.2 EQUIPMENT AND TECHNOLOGY 

2.2.1 PeopleNet System 

PeopleNet provided a standard g3 model on-board computer, liquid crystal display (LCD), and 

keyboard for the WRI POC testing. The g3 provided wide-area communications and GPS 

positioning. This unit was connected to the vehicle’s J1708 interface to collect critical engine 

and speed data. In addition, the g3 was connected by means of a serial cable to a laptop 

computer. By virtue of this interface, the laptop had direct access to the GPS and J1708 data, 

which were collected by the g3 and also had the ability to exchange data over the PeopleNet 

network. The g3 OBC and LCD are shown in Figure 6. 

Figure 6. Photo. PeopleNet OBC and Display Used in the WRI POC 

For the purposes of the WRI POC test, PeopleNet established a back-end data collection 

repository using the PeopleNet LinkTM. This repository extracted all available vehicle, 

messaging, and electronic driver log data from PeopleNet’s network operations center and 

deposited those data in a local database. 

PeopleNet also developed custom programming for the laptop to interface with the PeopleNet 

system and assemble the required SDMS. In order to produce a POC in a timely and inexpensive 

fashion, PeopleNet collected electronic driver log data from the g3 on-board computer to the 

local data base. PeopleNet also provided an electronic input form through which the driver could 

provide key personnel data, including medical certification information. The driver’s 

Commercial Driver’s License (CDL) number could be scanned directly for input using a tethered 

barcode reader. This format made all driver log and personnel information available in a local 

data base at any time. For the POC, PeopleNet caused an SDMS consisting of the driver log and 

personnel data to be communicated to the laptop every 5 minutes. The PeopleNet-interface 

software on the laptop received the SDMS and added to it pertinent GPS and J1708 data 

retrieved from the g3 on-board computer. The GPS and J1708 data in the SDMS were refreshed 

with newly collected information every 10 seconds. 

11 
Each time the SDMS was updated (every 10 seconds), a modified version (produced by ORNLdeveloped software) was transferred via File Transfer Protocol (FTP) to a TechnoCom device 

that ultimately passed the data set wirelessly to a receiver at the WRI POC test station. 

2.2.2 Middle-Ware Computer 

The computer chosen to interface between the PeopleNet OBC and the transceiver was a Lenovo 

3000 N100 laptop Model 076807U. This computer contained both the PeopleNet-interface 

software mentioned above and software developed by ORNL to manipulate further the data 

provided by PeopleNet. ORNL’s task was to generate an on-board history of SDMS messages as 

provided by PeopleNet and to send this history to the transceiver for subsequent transmission to 

an RSU or MEV. To this end, the software developed by ORNL first created a simple appended 

SDMS by appending the new SDMS line, provided by PeopleNet every 10 seconds, to a text file. 

This format was used in Phase 1A to provide a large number of SDMS messages for accuracy 

checking. 

ORNL’s software also provided the capability of generating a status-change SDMS, in which 

only messages from PeopleNet which differed in driver duty status from the previously stored 

line were appended to a text file. This resulted in a much shorter cumulative SDMS in which 

each line represented a different driver status. The software was also configured to retain a 

maximum of eight days’ worth of such lines, deleting any entries that were more than eight days 

old each time a new line was added. This format closely approximates that which would be 

expected by FMCSA’s Proposed Rule Making on Electronic On-Board Recorders (EOBRs) for 

commercial vehicles’ eight-day history (395.16). 

The third function of ORNL’s software was to transfer data from the laptop to the transceiver, 

which then transmitted the data to the roadside or MEV. The software allows three options for 

which file to transfer: 

 Only the single-line output from PeopleNet. 

 The complete appended SDMS. 

 The eight-day-history SDMS. 

The selected option is sent to the transceiver every 10 seconds, when it is updated with the most 

recent PeopleNet information. The actual transfer was accomplished using the standard FTP. 

Because the laptop was running Windows XP and the transceiver ran on a Linux platform, this 

communication method provided a convenient method of transferring the data between the 

different operating systems. 

2.2.3 TechnoCom Transceiver 

The TechnoCom Multi-band Configurable Networking Unit (MCNU) served as the transceiver 

for the WRI POC and was tested at both 2.4 GHz and 5.9 GHz Dedicated Short-Range 

Communications (DSRC). The MCNU is a lightweight, weatherproof device used to build 

standards-compliant, high-speed, multi-band wireless communication networks. Optimized 

antennas for each frequency were supplied by TechnoCom and utilized by ORNL for the POC. 

12 
MCNU Specifications: 

Wireless Interfaces 

Two IEE 802.11a/b/g/j/p PHY-compliant 

interfaces 

Each wireless interface 

 Configurable locally or remotely 

– Institute of Electrical and 

Electronics Engineers (IEEE) 

802.11a/b/g/j/p PHY 

 Data rates 

– 1, 2, 5.5, 11 Mbps 

– 3, 4.5, 6, 9, 12,18, 24, 27 million 

bits per second (Mbps) 

– 6, 9, 12, 18, 24, 36, 48, 54 Mbps 

 Frequency band 

– 2.400–2.484 GHz (ISM) 

– 4.940–4.990 GHz (PS) 

– 5.150–5.250 GHz (UNII) 

– 5.250–5.350 GHz (UNII) 

– 5.470–5.725 GHz (UNII) 

– 5.725–5.825 GHz (UNII) 

– 5.825–5.850 GHz (ISM) 

– 5.850–5.925 GHz (ITS-DSRC) 

 Transmit power 

– 17–19 dBm maximum 

 Enhanced MAC features 

– Security enhancements—IEEE 

802.11.i 

– QoS enhancements—IEEE 

802.11.e 

 Antenna diversity: two antenna 

connections 

– N-Type RF Connectors 

 Antennas 

– Antenna selection and 

purchasing guide included 

 GPS 

– Ublox Antaris TIM-4H Super 

Sense Receiver 

– One external SMA antenna 

connector 

 Processor 

– Via Eden CPU, 400 megahertz 

(MHz) or 733 MHz 

 Memory 

– 256 MB SDRAM 

 Storage 

– 2 gigabyte (GB) Compact Flash 

 Standard Interfaces: 

– RS232 Serial (2) 

– 10/100 Mbps Ethernet (2) 

– Universal Serial Bus (USB) 2.0 

– SVGA port 

 Operating System 

– Linux version 2.6.14.6 

– Based on Fedora Core Linux 4 

Environmental 

 Temperature 

– -35 to +55° C @733 MHz 

– -35 to +75° C @400 MHz 

Physical 

 Packaging 

– NEMA4X-compliant enclosure 

 Size 

– 12" × 6" × 4.25" (33.3 cm × 16.7 

cm × 10.8 cm) 

Electrical 

 Power requirement 

– 2A @ 12 VDC (24 watts) 

– 1240 VDC 

13 
The MCNU unit is shown in Figure 7 and Figure 8. 

Figure 7. Photo. MCNU Interface Panel 

Figure 8. Photo. MCNU RF Panel 

2.2.4 Air-Weigh 

The Air-Weigh on-board scale is an “on-the-ground axle weight scale.” Axle weights can be 

determined in real time from the system installed on the vehicle. 

Air-Weigh Air-Suspension Scales measure changes in air-suspension pressure to 1/27th of one 

pound per square inch (psi), or in increments of about 20–40 pounds of the vehicle’s total on-theground weight. For the POC, the 5800 Series of truck scales were used on the tractor, interfaced 

to the vehicle’s J1708 data bus. The 5800 Series on-board scale converts tractor load to weight 

by comparing empty and loaded axle group weights with empty and loaded suspension pressures. 

14 
The scale can be calibrated to display weights at any suspension load. The Air-Weigh display 

used in the WRI POC is shown in Figure 9. 

Figure 9. Photo. Air-Weigh In-Cab Display 

2.2.5 ORNL Comparison System 

ORNL constructed a system similar to that provided by PeopleNet and TechnoCom to verify the 

contents of the test system’s SDMS. This independent monitoring system was comprised of an 

eDAQ brand data acquisition system, VBOX III (a GPS-based system that provides data based 

on vehicle location such as speed, latitude, and longitude), Air-Weigh, and custom software to 

simulate the BOA. The ORNL DAS is shown in Figure 10 and Figure 11. The eDAQ data 

acquisition system received vehicle-related signals from the VBOX III and the vehicle’s J1708 

data bus. This information was received by the eDAQ via a CAN vehicle bus module, which 

interpreted the J1939 signals from the VBOX III. The eDAQ DAS received other vehicle 

information directly from the test vehicle’s J1708 data bus through a J1708 vehicle bus module. 

This information included odometer readings, Antilock Braking System (ABS) status flags, and 

the vehicle axle weights (from the Air-Weigh system). 

In addition to information obtained by the DAS, the ORNL comparison system included custom 

software run on a separate laptop computer to simulate a back-office system for driver records. 

Driver, carrier, and vehicle information such as medical certification, carrier DOT number, and 

license plate number were hand-entered at the beginning of testing to simulate information that 

would be available in company and state records. The program was run throughout the testing to 

maintain current eight-day HOS records for each driver. Driver status was recorded on this 

computer based on the scanned driver’s license barcode and user-selected status. Post-processing 

of the data permitted the formatting of the data from the laptop and the DAS into an SDMS 

which could be compared to the SDMS of the WRI system. 

15 
Figure 10. Photo. ORNL Comparison System DAS 

Figure 11. Photo. ORNL Comparison System Mounted in Test Vehicle 

2.3 SDMS DATA CATEGORY AND SOURCE 

The SDMS consists of information from the vehicle’s data bus, inputs from the driver, and 

information calculated by the PeopleNet back-office system (e.g., HOS data). Table 2 lists the 

type of data in the SDMS and the source of the data (input method). 

16 
Table 2. SDMS Data and Input Method 

SDMS Data Input Method(s) 

Driver ID 

Driver Name Test Engineer/Driver 

Driver License Number Test Engineer/Driver 

Driver State Test Engineer/Driver 

Vehicle ID 

Vehicle Identification Number Test Engineer/Driver/J1708 

Vehicle License Tag Number Test Engineer/Driver 

Carrier ID 

Carrier Name Test Engineer/Driver 

USDOT Number Test Engineer/Driver 

Driver Status 

Hours of Service Duty Status Change Test Engineer/Driver 

Medical Card Expire Date Test Engineer/Driver 

Medical Card Physician Name Test Engineer/Driver 

Medical Card Physician ID Number Test Engineer/Driver 

Medical Card State of Issue Test Engineer/Driver 

Vehicle Status 

IFTA (International Fuel Tax Agreement)Year Test Engineer/Driver 

IFTA State of Issue Test Engineer/Driver 

IFTA Number Test Engineer/Driver 

Annual Inspection Date Test Engineer/Driver 

Annual Inspection Performed By Test Engineer/Driver 

Annual Inspection Number Test Engineer/Driver 

ABS Warning Lamp Status J1708 

ABS Brake Control Status J1708 

ABS Retarder Control Status J1708 

ABS Off-Road Function Switch Status J1708 

Axle Weights J1708 

2.4 TEST VEHICLES 

The test vehicles used in the WRI POC were secured by ORNL. The test tractor came from 

Salem Leasing (via a subcontractor). It was a 2005 Columbia Series Freightliner tractor with an 

Eaton 10-speed transmission and a J1708 data bus. The tractor is shown in Figure 12. 

17 
Figure 12. Photo. WRI POC Test Tractor 

During most of the testing, a U.S. Department of Energy (DOE) fleet vehicle was used to 

simulate the MEV. For a limited part of the testing, an actual Tennessee Highway Patrol car was 

used. The van is shown in Figure 1 and an example of a patrol car is shown in Figure 14. Each 

vehicle was fitted with the TechnoCom MCNU transceiver, antenna, and laptop computer. The 

antenna used (either stick or dome style) depended on the frequency of test, either 2.4 GHz or 5.9 

GHz. 

Figure 13. Photo. DOE Van Used to Simulate a MEV 

18 
Figure 14. Photo. Tennessee Highway Patrol Car Similar to That Used as a MEV 

2.5 ROADSIDE CONFIGURATIONS 

RSE was set up temporarily at the Knox and Greene County CMV inspection stations. The RSE 

consisted of the transceiver, antenna, antenna tripod, and laptop computer. Again, the antenna 

used depended on the frequency of test (2.4 GHz or 5.9 GHz). Images of an antenna and the 

computer system can be seen in Figure 15 and Figure 16. 

Figure 15. Photo. Roadside Unit at the Knox County Inspection Station 

ROADSIDE 

ANTENNA

19 
Figure 16. Photo. Roadside Unit at the Greene County Inspection Station 

WRI ROADSIDE 

COMPUTER 

SYSTEMS

2.6 TESTING ELEMENTS 

2.6.1 Tested Features 

For the POC, the following features and capabilities were tested: 

 The UWIS kernel’s ability to capture and store the list of SDMS data called out in section 

2.3 of this document. 

 The UWIS kernel’s ability to accurately process the required elements of the SDMS 

 The UWIS kernel’s ability to transfer the SDMS to the wireless transceiver using either 

an RS-232 or USB connection. 

 The wireless transceiver’s ability to receive the SDMS from the UWIS kernel. 

 The wireless transceiver’s ability to receive requests for the SDMS from the roadside 

under multiple conditions, as called out in the Test Plan, section 15.3. 

 The wireless transceiver’s ability to transmit the SDMS to the roadside under multiple 

conditions, as called out in the Test Plan, section 15.3. 

 The wireless transceiver’s ability to receive requests for the SDMS from the MEV under 

multiple conditions, as called out in the Test Plan, section 15.3. 

 The wireless transceiver’s ability to transmit the SDMS to an MEV under multiple 

conditions, as called out in The Test Plan, section 15.3. 

2.6.2 Features Not Tested 

For the POC, the following features were not tested: 

 The UWIS kernel’s ability to comply fully with FMCSA’s Proposed Rule Making on 

EOBRs for CMVs (§395.16) (it is desirable that the kernel devices meet, or closely 

approximate, the requirements of §395.16. However, relative to the HOS for the POC, the 

20 
testing was concerned only with finding status changes and total time in a status in order 

to construct the grid log). 

 Vehicle status information beyond what is already present on the test tractor. 

 Any features associated with the back-office analysis and storage systems (the BOAs 

were simulated for the WRI POC). 

 The ability of the UWIS to transmit and receive the SDMS in various terrains, in varying 

levels of traffic congestion, and in the presence of electronic interference. 

 Transmission of data above 55 mi/h (test vehicle or MEV speed). 

 Definitive range limitations of the wireless transceivers. 

2.6.3 Testing Entry and Exit Criteria 

Entry conditions included the following: 

 At least one UWIS kernel partner with operational equipment was desired; however, its 

absence would not have prevented Phase 1B testing of the transceiver using a simulated 

SDMS. 

 A contract for 5.9 GHz and 2.4 GHz transceiver technology was desired; however, its 

absence would not have prevented the Phase 1A testing of the kernel. 

 Availability of necessary test equipment. 

 Access to an acceptable test vehicle. 

 Finalized test plan and test procedures. 

 Suitable, safe test location(s). 

Exit conditions include the following: 

 POC Phase 1A and 1B testing successfully completed. 

 Expired POC test window (see section 1.6 for dates). 

2.6.4 Technology Pass/Fail and Evaluation Criteria 

In the event that the partner’s kernel had failed properly to collect, structure, and output the 

SDMS information (e.g., no viable data output for monitoring, no SDMS, or SDMS with no 

data), a second testing opportunity would have taken place within seven calendar days. If the 

partner’s technology had failed again to produce the SDMS, no further testing would have been 

conducted and ORNL would have deemed this partner unviable for the POC, per the MOU 

agreement. 

Note: The test team had a high expectation of reliability (i.e., a match of input data to the SDMS 

of greater than 99.5 percent; see section 3.1.3 for the data analysis). However, if the partner was 

able to construct the SDMS with a lower level of reliability, it would not have been rejected from 

the POC or from future efforts. 

21 

3. PROOF-OF-CONCEPT TEST 

3.1 PHASE 1A 

3.1.1 Introduction 

The objective of the Phase 1A test was to assess the UWIS kernel’s ability to format the SDMS. 

To accomplish this objective, ORNL configured a DAS to gather the comparison data (“ground–

truth”) using the system outlined in section 2.2.5. This comparison system consisted of a SoMat 

eDAQ DAS configured to collect data at 5 Hertz (Hz), and a laptop computer. ORNL had 

extensive experience with the DAS, which was used in other projects to collect more than 250 

GB of spatial and databus information similar to the data needed for this project. The kernel and 

the DAS were integrated onto a 2005 Freightliner Class-8 truck with a box trailer. 

The kernel included a system designed by mobile computing and communications provider 

PeopleNet. Because of time constraints, and in order to conserve funding, PeopleNet created a 

system to demonstrate the potential of WRI with the understanding that a different approach and 

additional design and coding would be required for its commercial release. The demonstration 

system took advantage of PeopleNet’s existing eDriverLogs product, in which available HOS are 

tracked on the OBC and can be communicated periodically to a back-office system. The driver 

completed an electronic form on the OBC to provide key personal information such as name, 

medical exam doctor, medical exam date, and date of annual vehicle inspection among other 

information. In addition, a tethered barcode scanner allowed the barcode representing the CDL 

license number to be scanned in directly from the license itself. Once these data were entered and 

transmitted, the back-office system recorded them, and the driver did not have to use the form 

again unless updates were required. 

In the truck itself, a laptop computer running software supplied by PeopleNet was connected via 

a serial port to the PeopleNet OBC. This software polled the OBC every 10 seconds 

(configurable interval) to obtain current GPS position and J1708 engine control module (ECM) 

data. Meanwhile, every 5 minutes (also configurable) the back-office system sent the most 

current driver identification data and HOS data on file to the laptop software via the OBC. When 

the OBC received these data from the back office, it simultaneously sent back the most recent 

driver HOS data, which was then communicated back to the laptop 5 minutes later. The software 

on the laptop provided a continuously updated SDMS file containing personal and HOS data that 

were 7–9 minutes old, as well as GPS and J1708 data that were approximately 10 seconds old. 

This file was sent to the transceiver via FTP as soon as it was updated every 10 seconds. 

For this POC, PeopleNet combined several existing processes originally created for other reasons 

in order to form a demonstration of WRI. Because the HOS data are already tracked on the OBC 

and the driver personal data could be stored on the OBC as well, a commercially releasable 

system would extract all data from the OBC at a higher frequency (i.e., every few seconds) than 

the one used in the POC. This methodology would result in greater overall accuracy and 

reliability. 

23 
The test team consisted of a test driver and a ride-along engineer. The ride-along engineer was 

responsible for inputting the data reflecting the driver’s duty-status changes into the kernel 

registering these changes, using the software deployed for the DAS’s on-board laptop computer; 

handwritten notes were also taken as a backup. Other information, specifically databus-related 

information, was read directly by the kernel and the DAS. The test lasted approximately 10 

hours, and consisted of a trip that visited three states. Departure was from Knoxville, TN; the 

first destination was London, KY, followed by Ringgold, GA, with the trip ending in Knoxville, 

TN. Figure 17 shows the route taken for this trip, as well as the CMV inspection stations along 

that route (marked with circles). Those inspection stations are located at Corbin, KY; Knox 

County, TN; and Ringgold, GA. 

Figure 17. Map. Phase 1A Test Route and CMV Inspection Stations 

Inspection 

Stations

Test Route

3.1.2 Data Collected 

The data fields collected during the test are presented in Table 3. The third column in that table 

shows an example of the contents of each field. Notice that although the DAS collected weight 

data, this information was not a requirement for the kernel and therefore an “NA” label is shown 

in column three for those weight-related fields. The DAS collected databus and vehicle location 

information (latitude, longitude, etc.) at 5 Hz (one reading every 0.2 seconds). An appended 

SDMS was generated throughout the duration of the Phase 1A test, which resulted in 3,597 lines 

of data, each containing the information listed in Table 3. 

24 
Table 3. Information Collected in Phase 1A Test 

Field Name Description Contents (Example) 

DRFIRSTNAME Driver’s first name John 

DRLASTNAME Driver’s last name Doe 

DRCDL Driver’s license number 987654321 

DRSTATE State issuing license TN 

CARRNAME Carrier’s name Commercial Carrier Consultants 

CARRID Carrier’s truck ID 10144 

CARRUSDOT Carrier’s USDOT number 1628871 

VIN Vehicle Identification number 1FUJA6AV95LU33071 

VID Kernel’s vehicle ID 1004429 

VLTN Vehicle License Plate TN20474HZ 

VEHNETWT Net Vehicle Weight NA 

VEHSTRWT Weight on Steer Axle NA 

VEHDRVWT Weight on Drive Axles NA 

VEHTRWT Weight on Trailer Axles NA 

ABSWRNLP ABS Warning Lamp Flag NA 

ABSBRKCTL ABS Brake Control Flag NA 

ABSRTDCTL ABS control flag NA 

ABSOFFRD ABS Off-Road Flag NA 

MCPN Medical Card Physician Name Smith 

MCPID Medical Card Physician ID 998877 

MCST Medical Card State TN 

MCED Medical Card Exam Date 39448 

AID Annual Inspection Date 39125 

AIPB Annual Inspection Performed by Jones 

AIN Annual Inspection Number 121212 

IFTAY IFTA Year 2007 

IFTASTATE IFTA State Issued TN 

IFTAN IFTA Number 18822045 

SEQID Unique Index Number for Each SDMS 392 

DRDUTYSTATUS Driver’s Duty Status ON 

DRDUTYTIME Time of Last Duty Status Change 18:50:46 

DRHOSDATE Date Logged Last Duty Status Change 6/26/2007 

DRHOSTIME Time Logged Last Duty Status Change 20:28:32 

DRHOS_USA607 PeopleNet HOS Info no 

DRHOSDSA_USA607 PeopleNet HOS Info 35778 

DRHOSOSA_USA607 PeopleNet HOS Info 35778 

PFXODO Odometer reading 161586.80 miles 

DRDUTYLOC Location of Last Duty Status Change 0@Knoxville, TN 

GPSLONG Longitude -84.15474 

GPSLAT Latitude 35.95472 

GPSHEAD Heading 0 deg 

GPSSPEED Speed 0 mi/h 

GPSUTC UTC Time (from GPS) Wed Jun 06 2007 13:58:23 

One of the key fields in Table 3 is the GPSUTC field. Information stored in this field provided a 

timestamp for any message generated by either the DAS or the kernel. Since this timestamp is 

taken from GPS satellites, it is universal and allows for synchronization of both messages. This, 

25 
in turn, permits the comparison of the information provided by the kernel to the “ground-truth” 

information that was collected by the DAS system at the same time. Since the sampling rate of 

the DAS was 5 Hz, there is an intrinsic error of less than 0.2 seconds in the synchronization of 

the messages. 

It should be noted that the GPSUTC value provided by the kernel is not a satellite timestamp, but 

rather the value of the OBC’s internal real-time clock. The difference between this clock and the 

UTC timestamp received from GPS satellite is checked once every second; if it becomes greater 

than 15 seconds (configurable interval), the clock is reset to the satellite time. This is done in 

order to supply time as accurately as possible to other applications, even when satellite signals 

are degraded by obstructions or atmospheric conditions. 

The test was run between 12:00:07 and 22:10:18.0 UTC (Universal Time Coordinates), 

corresponding to 08:00:07 to 18:10:18.0 Eastern Daylight Time (EDT). [Note: for the remainder 

of this chapter, all the times are shown in UTC.] During this interval, the kernel-generated 3,597 

messages composed of the information shown in Table 3. This represented an average rate of one 

message every 10.2 seconds, as expected, based on the configuration discussed above; in the 

same period of time, the DAS generated 188,330 messages. Of the 3,597 messages, four had an 

“N/A” label in most of the fields, indicating that the kernel was not able to generate the required 

information; the remaining 3,593 (or 99.9 percent of the messages) always contained information 

in all the fields showed in Table 3. 

There were 259 instances in which messages were repeated (i.e., instances when, because of 

communication or GPS problems, the kernel was not able to generate a new message and 

therefore repeated the last one that was correctly created). Those “blackout” periods, which 

covered 7.2 percent of the test time, resulted in 44 intervals with no updated messages. The 

longest blackout interval was 317 seconds, the shortest was 30 seconds, and the average was 75.6 

seconds. 

The blackout intervals occurred both with the truck moving and when it was stationary and were 

largely concentrated in two distinct periods of time. Figure 18 shows the speed profile of the test 

vehicle during the entire test, with the blackout periods superimposed. Some of the blackouts 

were explained by the area in which the truck was traveling. For example, between 14:37 and 

16:21, the vehicle was traveling in the Cumberland Gap/Jellico Mountain Region (mostly going 

southbound on I-75) on the border between Kentucky and Tennessee; this mountainous area is 

known to have problems with cell-phone coverage. However, there were almost no blackout 

periods on the northbound leg of the trip in the same area. The other time interval with a high 

number of blackouts was that between 20:44 and 21:50, when the vehicle was traveling on I-75 

North, between Cleveland, TN, and Knoxville, TN. This area has is not known to have particular 

problems with cell-phone coverage. 

26 
27 

Figure 18. Graph. Test Vehicle Speed Profile and Communication/GPS Blackout Periods 

0.0

20.0

40.0

60.0

80.0

100.0

12:00:00.0 14:00:00.0 16:00:00.0 18:00:00.0 20:00:00.0 22:00:00.0 0:00:00.0

Time of Day

Speed [mph]

0

1

GT Speed Profile Blackouts

Blackouts

0.0

20.0

40.0

60.0

80.0

100.0

12:00:00.0 14:00:00.0 16:00:00.0 18:00:00.0 20:00:00.0 22:00:00.0 0:00:00.0

Time of Day

Speed [mph]

0

1

GT Speed Profile Blackouts

Blackouts

3.1.3 Data Analysis 

3.1.3.1 Kernel-Generated Information 

In order to assess the accuracy of the information generated by the kernel, the messages that it 

generated were compared against “ground-truth” information collected by the DAS system. Out 

of the 188,330 messages collected by the comparison DAS, those with timestamps closest to the 

ones corresponding to the 3,593 kernel messages were selected; the four messages with “N/A” 

labels were eliminated from the dataset. The information contained in these messages was paired 

and compared for selected fields to assess the accuracy provided by the kernel. 

Although the DAS system is very reliable and accurate, the information it generates could have 

problems, such as bad readings from the databus sensors or loss of GPS signal. Therefore, when 

any DAS message that was paired to a kernel message contained inaccurate*

 information in any 

field, it was eliminated from the database together with the corresponding kernel message. This 

procedure was used in order not to penalize the kernel when the ground-truth information was 

not collected at its highest possible accuracy level. One hundred thirteen ground-truth messages 

presented some problem and were therefore eliminated from the assessments. 

The analysis was divided into two parts. The first part consisted of assessing information 

obtained from the databus sensors and location information provided by the GPS. The second 

part focused on the HOS and other driver-related information. 

 

*

 The DAS provides an error code for any field that presented any problem while a particular record was generated. These error codes were used 

to eliminate problematic records. 
3.1.3.2 Databus and Location Information 

Table 3 shows several fields related to information that can be obtained from the vehicle databus, 

including an ABS warning lamp flag, ABS brake control flag, ABS control flag, ABS off-road 

flag, and odometer reading. Because the kernel did not read any of the ABS-related information, 

the odometer reading was selected to represent the Databus Information category. Notice that 

whether only one field is used or many, the accuracy of the kernel in reading databus information 

is not affected, since the comparison is being made against the DAS reading the same 

information. Certainly, a problem would arise if the kernel were not querying the right sector of 

the databus, but that would result in an accuracy level of 0 percent and would rapidly be 

attributed to a gross reading error. 

Regarding the location of the vehicle, its position in terms of latitude and longitude coordinates 

were used to determine the accuracy of the kernel in providing spatial/temporal information. 

Also related to GPS-obtained information, vehicle speed was used to determine the accuracy of 

the kernel in providing this type of information. While the kernel gathered this information based 

on its GPS, the comparison (DAS-provided) information was obtained from the vehicle databus. 

In order to measure the accuracy of the kernel, the following procedure was used. First, using the 

timestamps added to both kernel and ground-truth messages by their respective data collection 

systems, the messages were paired such that their timestamps were ordered chronologically as 

closely as possible. A database was created with these paired messages. Second, the ground-truth 

messages that presented any problems (such as lack of GPS readings, out-of-bound readings, or 

other types of errors) were eliminated from the database, together with their paired kernel 

messages. Finally, the remaining records were used for the assessment of the kernel accuracy. 

Two different approaches were used for this assessment. For both database and speed 

information, the absolute difference between the kernel (denoted by the subscript K) readings 

and ground-truth (denoted by the subscript GT) readings of the same field (DKGT) was computed 

and compared against a tolerance level (TL) for that measure. If DKGT was within the tolerance 

level (i.e., DKGT ≤ TL), then the kernel message was considered accurate at that level. The 

percentage of accurate messages at level TL was calculated simply by dividing the number of 

accurate kernel messages by the total number of kernel messages in the database. 

In the case of the spatial location of the vehicle, rather than using the same procedure and 

comparing the latitude and longitude readings separately, the distance between the positions of 

the vehicle provided by the ground-truth system and the kernel (DKGT) was computed using the 

Haversine formula (Sinnott, 1984). The rest of the procedure was the same as that used in the 

previous case. That is, the distance DKGT was compared against a tolerance level TL, which 

allowed the determination of whether the information in the kernel message was accurate at that 

level. The accuracy of the kernel was then assessed as the percentage of spatially accurate 

messages out of the total number of kernel messages. 

It should be noted that, unlike the databus information, the GPS information depends on the 

device used. That is, although all the GPS devices use the same satellites, they may be optimized 

for different situations. If a high accuracy in the horizontal plane (latitude, longitude) is desired, 

then the GPS device gives more weight to the satellites that are closest to the zenith. On the other 

28 
29 

hand, a higher accuracy in altitude involves using the satellites that are closest to the horizon. 

Since the kernel and the DAS used different GPS devices, an error may have been introduced in 

the assessment of DKGT if these GPS devices had different optimization algorithms. The source 

of this error is unknown, although it is probably negligible compared to the tolerance levels used 

in the evaluations. 

The results of the evaluations considering all of the messages collected in the test are presented 

in Table 4. For each of the categories of information presented in that table, the headers of the 

three right-hand columns indicate the tolerance levels used to determine the accuracy of the 

kernel. For the computations of the accuracy levels presented in Table 4, the total number of 

messages was 3,480, which is less than the 3,593 kernel messages introduced previously. This 

was the case because 113 ground-truth messages presented problems and were therefore 

eliminated from the assessments. 

Table 4. Accuracy of Kernel Databus and Location Information 

Considering All Messages 

Information 

Type Tolerance Level 

Number of 

Accurate 

Messages 

Accuracy at 

Tolerance Level 

Odometer 0.01 miles 934 26.8% 

Odometer 0.10 miles 1,245 35.8% 

Odometer 0.25 miles 2,509 72.1% 

Speed 0.5 mi/h 1,361 39.1% 

Speed 1 mi/h 1,830 52.6% 

Speed 5 mi/h 3,154 90.6% 

Location 250 ft 957 27.5% 

Location 500 ft 1,070 30.7% 

Location 1000 ft 1,169 33.6% 

Although the tolerance levels are arbitrary, it appears from Table 4 that the accuracies of the 

different categories of information should be higher. In particular, Location Information seems to 

have a very low accuracy, even at a TL of 1,000 ft, and the other categories—Odometer 

Information and Speed Information—although not as bad as Location Information, also have 

very low accuracy levels. One issue that could have affected the accuracy was that of the 

repeated messages discussed previously. In a second round of calculations, all those repeated 

kernel messages (i.e., the messages provided during the blackout periods) were eliminated from 

the database. This reduced the total number of messages used in the accuracy assessments from 

3,480 to 3,221. 

The results of the new computations are presented in Table 5. Even when these repeated 

messages were eliminated, the accuracy levels increased only slightly in two cases, while 

decreasing in the other seven. This decrease in the accuracy level when apparently bad 

information (i.e., non-current information) is eliminated was due to the fact that a high 

proportion of the repeated messages occurred when the truck was stationary or traveling at a very 
30 

low speed (e.g., 62 percent of the blackout messages occurred when the truck was either 

stationary or traveling at less than 2 mi/h). Therefore, the odometer, speed, and location readings 

were the same as those provided by the ground-truth messages and were counted as accurate 

kernel messages in Table 4. Once those messages were eliminated, the percentage of accurate 

messages decreased in all but one case (Odometer Information, Accuracy at TL, at 0.25 miles) as 

can be seen in eight of the nine cells of Table 5. 

Table 5. Accuracy of Kernel Databus and Location Information 

Without Repeated Messages 

Information 

Type Tolerance Level 

Number of 

Accurate 

Messages 

Accuracy at 

Tolerance Level 

Odometer 0.01 miles 822 25.5% 

Odometer 0.10 miles 1,124 34.9% 

Odometer 0.25 miles 2,376 73.8% 

Speed 0.5 mi/h 1,243 38.6% 

Speed 1 mi/h 1,690 52.5% 

Speed 5 mi/h 2,922 90.7% 

Location 250 ft 863 26.8% 

Location 500 ft 945 29.3% 

Location 1000 ft 1,022 31.7% 

This warranted further investigation of the collected information. The messages were spatially 

and temporally tagged and loaded into a geographic information system (GIS) software utility 

(MapPoint) to visually inspect the data. Figure 19 shows this information as recorded while the 

test vehicle was driving in the Knoxville area during the first and second legs of the trip. The 

location provided by the kernel is displayed as a red dot, and the ground-truth information is 

displayed as a blue dot. The callout text in the four boxes show some of the information 

contained in each message, particularly the latitude and longitude coordinates, the record 

number, the odometer reading, and the timestamp. Consider, for example, Record 244. The 

kernel and ground-truth “bubbles” (messages) show the same timestamp, of course (since that 

was the common piece of information that tied those messages together). However, in all cases, 

the location reported by the kernel is ahead of the actual location (ground-truth location). 

Moreover, if the messages are matched by location and not by timestamp (recall that the groundtruth messages were collected at a rate 50 times that of the kernel), then there is always a 

difference of approximately 15 seconds (i.e., at the same location, the kernel indicates a 

timestamp that is 15 seconds earlier than the timestamp of the ground-truth message collected at 

that location). This time difference was consistent in terms of value and direction across all 

kernel-generated messages. 
31 

Figure 19. Map. Vehicle Position as Provided by the Kernel and Ground-Truth Original Messag

Copyright © 2003 Microsoft Corp. and/or its suppliers. 
32 

As explained earlier, the timestamp provided by the kernel was not a satellite timestamp but 

rather the value of the OBC’s internal real-time clock. Moreover, the difference between this 

clock and the UTC timestamp received from the GPS satellites was checked by the kernel at a 

rate of 1.0 Hz and was adjusted (i.e., reset to the satellite time) if it became greater than 15 

seconds. Therefore, the observed “shift” in time was explained by the difference between the 

GPS time (i.e., the timestamp provided by the DAS) and the kernel’s internal clock time. Since 

the difference never became larger than 15 seconds during the test, the kernel timestamp was 

never reset to the GPS time, thus generating a consistent, systematic difference between the 

timestamps of the kernel and the DAS. 

Since the objective of this data analysis was to determine the accuracy of the information 

gathered by the kernel, this time shift of approximately 15 seconds was corrected and the 

corrected data were analyzed. The analysis resulted in significant increases in the accuracies 

observed in the three categories of information that were assessed. Figure 20 presents the same 

type of information as that displayed in Figure 19, but with the corrected data. Figure 20

graphically illustrates this increase in accuracy, while Table 6 presents the results in numerical 

form. The figures shown in that table were computed over a pool of 3,220 messages (one of the 

new ground-truth messages had to be eliminated because of reported errors in some of its fields). 

It can be observed that, compared to the information presented in Table 3, all accuracy levels 

increased, some of them achieving values close to or at the 100 percent level. One exception was 

the odometer information, which did not reflect such a significant increase in accuracy. For this 

particular databus field, the J1587 standard indicates that the odometer data (total vehicle 

distance) can be read either in tenths of a mile (i.e., a resolution of 0.1 miles) or in kilometers at a 

resolution of 0.161 km (SAE International, 2002). While the kernel read the field in miles, the 

DAS did it in kilometers, introducing a small rounding error in the computations of the accuracy 

for this particular field. The difference, therefore, cannot be attributed to the kernel. Nonetheless, 

the analysis of this field was performed in order to determine whether the kernel was able to read 

databus information in real time, which it did successfully. 
33 

Figure 20. Map. Vehicle Position as Provided by the Kernel and Ground-Truth Messages That Have Been Sh

Copyright © 2003 Microsoft Corp. and/or its suppliers.
34 

Table 6. Accuracy of Kernel Databus and Location Information 

without Repeated Messages and with Time Shift 

Information 

Type Tolerance Level 

Number of 

Accurate 

Messages 

Accuracy at 

Tolerance Level 

Odometer 0.01 miles 1,296 40.2% 

Odometer 0.10 miles 2,053 63.8% 

Odometer 0.25 miles 2,538 78.8% 

Speed 0.5 mi/h 1,815 56.4% 

Speed 1 mi/h 2,615 81.2% 

Speed 5 mi/h 3,201 99.4% 

Location 250 ft 3,217 99.9% 

Location 500 ft 3,219 100.0% 

Location 1000 ft 3,220 100.0% 

In summary, once these corrections were made to the data provided by the kernel to account for 

factors that are exogenous to the investigation, for the three categories analyzed, the kernel 

provided information at a very good and sometimes excellent accuracy level. 

3.1.3.3 Driver’s Duty Status Information 

The evaluation of the accuracy provided for the driver status information required a different 

methodology than the one used for the databus and spatial information. The driver status 

information, which is composed of the few discrete points that mark any change in duty status, 

has to be precise; otherwise it is not possible to determine HOS information. 

During the test, and as discussed previously, any driver’s duty status change was registered by 

the ride-along engineer in both the DAS and the kernel equipment. The kernel then added that 

information to the DRDUTYSTATUS field (see Table 3) of the message it created and repeated 

the information in that field until it registered a new status change. Since all the messages were 

timestamped, it was relatively easy to build an HOS diagram that could be compared to the one 

obtained by using the DAS information. Using the SDMS information in this way showed some 

discrepancies between the kernel and the DAS in building the HOS diagrams. 

However, another field in the kernel message may be used to build an HOS diagram; this field 

was identified by PeopleNet as the correct field to use. The DRDUTYTIME field (see Table 3) 

contains time information of the last reported duty status change. This field was not used 

originally to construct the kernel’s HOS, since at first glance it appeared to have incorrect 

information. Further investigation revealed that the information was not incorrect, but that it was 

delayed, in some cases by several hours. This was most likely due to software issues that could 

be corrected easily in a commercial system. Table 7 and Table 8 show the information that was 

derived from fields DRDUTYSTATUS (second column in these tables) and DRDUTYTIME 

(third column), together with the timestamp of the message that contained the new information in 

DRDUTYTIME (column 4) and the delay that the new information had before it was added to 
35 

the kernel message (column 5). Consider, for example, row 5 in Table 7. At 15:01:15, there was 

a change in duty status from “Driving” to “Off Duty” for Driver 1. However, this information did 

not become available in the kernel messages until 19:55:23, or 4 hours and 54 minutes after the 

duty status change occurred. This was an extreme case; in fact, this was the maximum delay 

observed for Driver 1 duty status change during the test. The minimum delay was 4 minutes and 

37 seconds (row 1 in Table 7) with an average delay of 3,802 seconds (just over 1 hour). For 

Driver 2, the maximum delay was 33 minutes and 19 seconds, the minimum was 4 minutes and 

53 seconds (very close to that observed for Driver 1), and the average delay in reporting duty 

status change was 893 seconds (almost 15 minutes). 

Table 7. Kernel Message Delays in Providing Driver 1 Duty Status Change 

(DRDUTYTIME Field Used) 

Row 

No. 

Driver Duty 

Status 

Changed to 

Time of 

Driver Duty 

Status 

Change 

Message 

TS 

Delta 

Time Note 

1 On Duty 12:26:49 12:31:26 0:04:37 Min. delay 

2 Driving 12:31:18 12:40:46 0:09:28 

3 On Duty 13:47:32 14:00:03 0:12:31 

4 Driving 14:02:26 16:30:56 2:28:30 

5 Off Duty 15:01:15 19:55:23 4:54:08 Max. delay 

6 On Duty 19:51:32 20:01:05 0:09:33 

7 Driving 19:54:03 20:05:41 0:11:38 

8 Off Duty 21:52:36 22:09:06 0:16:30 

Table 8. Kernel Message Delays in Providing Driver 2 Duty Status Change 

(DRDUTYTIME Field Used) 

Row 

No. 

Driver Duty 

Status 

Changed to 

Time of 

Driver Duty 

Status 

Change 

Message 

TS 

Delta 

Time Note 

1 Off Duty 11:46:43 12:00:16 0:13:33 

2 On Duty 11:59:15 12:22:27 0:23:12 

3 Driving 15:57:46 16:31:05 0:33:19 Max. delay 

4 Off Duty 17:07:17 17:20:06 0:12:49 

5 Driving 17:24:23 17:35:12 0:10:49 

6 Off Duty 18:04:12 18:16:10 0:11:58 

7 Driving 18:38:03 18:45:12 0:07:09 

8 Off Duty 19:45:44 19:50:37 0:04:53 Min. delay 

Even though there were substantial delays in reporting driver duty status changes, the 

information extracted from the DRDUTYTIME field (combined with the DRDUTYSTATUS 

field) allowed the building of HOS diagrams that were much more accurate than those built 

using the duty status field combined with the message timestamp. These delay problems, which 

were software problems, were subsequently fixed by PeopleNet. However, since the Test Plan 
36 

had only one day of testing for Phase 1A, it was not possible to determine whether these issues 

were resolved completely. This will be done in the next phase of the project. Those HOS 

diagrams are shown in Figure 21 and Figure 22, with the disagreements between ground-truth 

and kernel data highlighted in light blue. Considering the total length of the test (i.e., 10 hours 

and 10 minutes), the agreements between the ground-truth and kernel diagrams amounted to 94.7 

percent and 93.5 percent of that time for Driver 1 and 2, respectively. Although those accuracy 

levels are high, they still fall short of 100 percent accuracy. 

Closer observation of the diagrams presented in Figure 21 and Figure 22 shows that most of the 

disagreements occur during a time period in which many “blackouts” were observed (see the 

“Kernel-Generated Information” subsection of section 3.1.3 and Figure 18). It is customary for 

devices that use wireless communication to store messages locally if the communication links 

are unavailable, and then to relay them later, once the communication links are reestablished. 

Because the observed disagreements occurred during these blackout periods, it appears that there 

was some software problem either in storing the information locally or in relaying that 

information later. 

However, another disagreement occurred outside the blackout periods. In Figure 21, during the 

period from 13:45:15 to 14:01:38, when the truck was stopped (see Figure 18), the ground-truth 

data indicated that Driver 1 was “On Duty,” while the kernel data showed the driver as 

“Driving.” This could be another software issue requiring further investigation since even during 

the blackout periods, the discrepancy observed in Figure 22 occurred at points preceded by or 

followed by a stopping period. That is, the largest discrepancy occurred between 15:05:30 and 

15:38:51, when the ground-truth system indicated that Driver 2 went from “On Duty” to 

“Driving” to “On Duty,” while the kernel showed that Driver 2 was “On Duty” for the entire 

period. Notice that immediately before the start of this period, between 14:47:28 and 15:05:30, 

the truck was stopped, and it was also stopped after the end of the discrepancy period, between 

15:38:51 and 16:00:14 (see Figure 18). 

The two types of problems seem to be related, and are probably due to software issues whose 

resolution would allow the system to generate HOS diagrams with 100 percent accuracy. 
37 

Figure 21. Graph. HOS Diagram for Driver 1 

Constructed Using Kernel (K) and Ground-Truth (GT) Messages 

(K DRDUTYTIME and DRDUTYSTATUS Fields Used) 

1.0000

2.0000

3.0000

4.0000

5.0000

12:00:00 13:00:00 14:00:00 15:00:00 16:00:00 17:00:00 18:00:00 19:00:00 20:00:00 21:00:00 22:00:00 23:00:00 0:00:00

Off Duty

Sleeping 

Berth

Driving

On Duty

GT

K

1.0000

2.0000

3.0000

4.0000

5.0000

12:00:00 13:00:00 14:00:00 15:00:00 16:00:00 17:00:00 18:00:00 19:00:00 20:00:00 21:00:00 22:00:00 23:00:00 0:00:00

Off Duty

Sleeping 

Berth

Driving

On Duty

GT

K

Figure 22. Graph. HOS Diagram for Driver 2 

Constructed Using Kernel (K) and Ground-Truth (GT) Messages 

(K DRDUTYTIME and DRDUTYSTATUS Fields Used) 

1.0000

2.0000

3.0000

4.0000

5.0000

12:00:00 13:00:00 14:00:00 15:00:00 16:00:00 17:00:00 18:00:00 19:00:00 20:00:00 21:00:00 22:00:00 23:00:00 0:00:00

Off Duty

Sleeping 

Berth

Driving

On Duty

GT

K

1.0000

2.0000

3.0000

4.0000

5.0000

12:00:00 13:00:00 14:00:00 15:00:00 16:00:00 17:00:00 18:00:00 19:00:00 20:00:00 21:00:00 22:00:00 23:00:00 0:00:00

Off Duty

Sleeping 

Berth

Driving

On Duty

GT

K

3.1.4 Phase 1A Test Conclusions and Future Work 

The results of the test performed in Phase 1A demonstrated that it was possible for the kernel to 

gather information from different sources (including EOBR and vehicle databus), assemble the 
38 

required SDMS, and make it available for transmission to an RSU or MEV. The frequency at 

which these messages were generated was very high (i.e., one SDMS every 10.2 seconds on 

average) for the type of application considered here. The largest observed delay in generating a 

new SDMS was just over 5 minutes, which was considered to be adequate. 

The accuracy of the information posted on the SDMS was measured within a certain tolerance, 

which was arbitrarily set at three levels. After some synchronization problems between the 

ground-truth and kernel messages were addressed, the information related to the spatial position 

of the vehicle (obtained from GPS readings) was 100 percent accurate when considering a 

tolerance of 1,000 ft. Speed, which was also determined via the kernel’s GPS, presented an 

accuracy level above 80 percent when a tolerance of 1 mi/h or less was considered, and close to 

100 percent with a tolerance of 5 mi/h or less. Odometer information, which was read from the 

vehicle’s databus, was 79 percent accurate when a tolerance of 0.25 miles was considered. 

The HOS information presented some problems. When a HOS diagram was built by combining 

driver status flags posted on the SDMS and the timestamp of that message, differences with the 

ground-truth’s HOS were found. Those differences were substantially reduced (although not 

completely eliminated) when a different SDMS field was used. However, the information posted 

in this field, although very accurate, was not relayed in a timely fashion. Most of the observed 

delays were in the 5–20-minute range (which was expected), although in two instances they were 

measured in hours. There were also a few occasions in which a status change was either not 

registered or not posted in the SDMS. 

Since the accuracy of the information contained in the SDMS seems to be acceptable, future 

work should focus mainly on the timeliness of the HOS information that is added to the message. 

Most of the observed problems were attributed to communication and software issues. In fact, 

during the pre-testing period, several related problems were identified by ORNL and addressed 

by the partner supplying the kernel information. It appears that some aspects of these problems 

were not fully resolved by the time of the test. Nevertheless, those problems do not seem to be 

insurmountable and should be resolved easily during the next phase. 

In future tests, it is important that more detailed technical discussions be carried out between the 

testers (ORNL) and the developers of the system, so that there is a better understanding of the 

idiosyncrasies of both the DAS and the kernel. This approach would avoid such issues as reading 

the same field in different units (e.g., odometer) or providing timestamps that are generated by 

different devices (thus introducing synchronization problems). 

3.2 PHASE 1B 

3.2.1 Introduction 

Phase 1A of the POC testing verified the kernel’s ability to generate an SDMS by combining 

information from different sources and making that message available to be transferred to a unit 

outside the vehicle in which the message was generated. The focus of Phase 1B was to determine 

the feasibility of transferring that information under both static conditions (vehicle stationary) 

and dynamic conditions (traveling at up to highway speeds). Because the purpose of this POC 

test was to provide initial information regarding wireless inspection technology, limited testing 
39 

involving several variables (such as antenna type and transmission frequency) was performed 

under both static and dynamic conditions. While the static tests were aimed at determining a 

general transmission range of the equipment used, the dynamic tests were performed to 

determine the feasibility of at-speed wireless safety inspections for heavy vehicles. 

The wireless inspection system tested involved both an OBC mounted in the test vehicle used for 

Phase 1A testing and an RSU or MEV to receive the SDMS. The information generated by the 

kernel was received by a support computer and sent to an MCNU, supplied by TechnoCom, 

which transmitted the file wirelessly to a receiver at either 5.9 or 2.4 GHz via a dome antenna 

mounted on the right side of the truck’s cab under the fairing. 

The receiving system consisted of an MEV or RSU which included an antenna, a receiving 

MCNU, and a support computer to display the received SDMS. The MEV and RSU systems 

were virtually identical: the software for each was the same with slightly different setup 

configurations. However, the MEV antenna was mounted to the vehicle, while the RSU antenna 

was set up on a tripod. In order to be mobile, all of the MEV power requirements were provided 

by the vehicle (using AC power inverters where required), while the RSU operated on standard 

AC power. 

A monitor and keyboard were also required to set up each MCNU upon startup; in addition, the 

monitor was used to display MCNU operation and to allow the test engineers to see when the 

MCNU had received or transmitted a file. Limited testing was performed at 2.4 GHz and 5.9 

GHz, using both stick and dome antennas. While antenna placement and type remain important 

to the efficiency of the WRI system, this was not an area in which ORNL was tasked to do 

research; therefore, standard antenna placement was used (Figure 23). 

Figure 23. Photo. Placement of the MCNU Dome Antenna on WRI Test Truck 

MCNU 

Antenna 
40 

 

3.2.2 Data Collection and Results 

3.2.2.1 Static Tests 

Static tests consisted of the assessment of the reliability of the wireless connection between the 

MEV and the test truck, as well as that of the file transfer function with both the test truck and 

the MEV in stationary positions. The objective of these tests was to determine a range at which 

the SDMS could be transmitted (although not necessarily the absolute maximum range), as well 

as to identify any file-transfer “dead zones” around the truck. The antenna was mounted on the 

tractor as illustrated in Figure 23, and the tests were conducted with a 53-ft trailer attached to the 

tractor. 

The protocol for these tests consisted of systematically parking the MEV at 100, 200, 300, and 

400 ft away from the tractor at positions that formed 0°, 45°, 90°, 135°, 180°, 225°, 270°, and 

315° angles with an imaginary line defined by the longitudinal axis of the tractor-trailer 

combination. Figure 24 provides a diagram showing the truck placement at the center of 

concentric circles having radii ranging from 100 to 400 ft with an increment of 100 ft. While the 

truck remained at that central location during the entire test,*

 the MEV was positioned at places 

marked by gray dots in Figure 24. The MEV was always pointed away from the tractor-trailer in 

each of these positions. 

Once the MEV was placed at the testing position, it made 20 attempts to “ping”†

 the OBE using 

the 5.9-GHz frequency. The number of successful MEV pings was noted. After that, the OBE 

made 20 attempts to “ping” the MEV. Again, the number of successful OBE pings was recorded. 

The OBE then attempted to transfer an SDMS wirelessly to the MEV. The same procedure was 

repeated for the remaining 31 MEV-truck relative positions. 

*

 Because of space constraints (these tests were performed at the Greene County, TN Inspection Station), the truck 

had to be rotated 180° to allow testing of all of the relative truck-MEV positions shown in Figure 10. 

†

 A “ping” is network procedure to test whether a particular host is reachable across that network. It is performed by 

sending “echo request” packets to the target host and listening for “echo response” replies. 
41 

Figure 24. Location grid. Truck and MEV Positioning for Static Tests 

The results of these stationary tests are graphically displayed in Figure 25. In that figure, the 

green circles indicate a successful file transfer at that location, while a gray circle shows an 

unsuccessful transfer. The numbers to the left and right of the circles show the number of 

successful MEV and OBE pings, respectively. 

The SDMS was successfully transferred to the MEV at any of the four distances considered 

when it was located on the northwest, northeast, and east positions relative to the truck. At these 

positions, both the MEV and OBE pings had a success rate of 100 percent (except when the 

MEV was at an east position 400 ft away from the truck, where the OBE ping success rate was 

95 percent). For the southeast, south, and southwest MEV positions, the success rate in pings and 

file transfer was 0 percent for all but the southeast and southwest positions at 100 ft from the 

truck. The probably reason for these results was obstruction by the trailer, which may have 

blocked the truck antenna. More difficult to explain are the unsuccessful file transfers and pings 

when the MEV was located on the west and north positions (probably the most common relative 

positions of truck and MEV in the field). For these instances, except for the case in which the 

MEV was at a distance of 100 ft from the truck, the success rates were 0 percent for all the 

measures considered. While it could be argued that the location of the antenna on the passenger 

side of the tractor may have affected the line of sight when the MEV was in the west position, it 

is difficult to explain why there were no file transfers or pings when the MEV was directly in 

front of the truck. One explanation may be that the dome antenna is directional (although no 

indication in this regard was given to ORNL by TechnoCom) and that it was inadvertently 
42 

placed in an unfavorable position. Regardless of which explanation is most accurate, in the next 

phase of this project new tests should be performed to investigate these dead zones further, both 

statically and dynamically (i.e., at highway speeds), as this problem of dead zones was present 

throughout the testing. 

Figure 25. Location grid. File Transmission to the MEV at 5.9 GHz Using the Dome Antenna 

Other static tests using the 5.9-GHz frequency were performed at the Knox County, TN, CMV 

Inspection Station for the purpose of verifying equipment functionality prior to dynamic testing. 

While the truck was in a stationary position, 10 file transfers to the RSU unit—equipped with a 

tripod stick antenna—were attempted with a success rate of 100 percent. Two other file transfer 

tests were conducted, this time between the stationary truck and the MEV. The MEV was 

equipped with a 5.9-GHz dome antenna centered on the roof (see Figure 29 inset). In the first 

case, with the MEV relatively close to the truck, all 10 SDMS file transfer attempts failed. This 

was attributed to interference from poles and signs (see Figure 26). When the truck was placed 

farther back, at about 63 ft from the MEV (in Figure 27, the truck placement would be in the 

bypass lane, west of the section which can be seen in the figure), the file transfer success rate 

was 90 percent for the 10 attempts. 
43 

Figure 26. Photo. Location of Signs at Knox County Inspection Station 

3.2.2.2 Dynamic Tests 

Drive-by Tests: Dynamic tests were performed at the eastbound Knox County CMV Inspection 

Station (Figure 27). In these tests the vehicle traveled past a roadside antenna and/or parked 

MEV (both a van [shown in blue in Figure 27] and a patrol car [shown as a dotted outline] were 

used to simulate MEVs) while traveling at 25 mi/h in the bypass lane. Tests were repeated at 

highway speeds of 55 mi/h on both sides of the highway. Most of the WRI testing employed a 

stick antenna on a tripod for the RSU, and a dome antenna on the MEV. TechnoCom supplied 

these antennas specifically for these units. However, some testing was also performed with the 

stick antenna on the MEV and a dome antenna on the tripod. In order to provide a comparison 

for realistic data, the dome antenna for the MEV unit was mounted on the trunk of a patrol car 

and that vehicle was placed in approximately the same position as the van (Figure 27) for very 

limited testing at 2.4 GHz. 

Figure 27. Diagram. Layout of Test Site at Eastbound Knox County CMV Inspection Station 

Eastbound – 55 mph 

Bypass – 25 mph 

Tripod (RSU) 

Patrol Car (MEV)

Van (MEV) 

Westbound – 55 mph

Eastbound – 55 mph 

Bypass – 25 mph 

Tripod (RSU) 

Patrol Car (MEV)

Van (MEV) 

Westbound – 55 mph
44 

Further dynamic tests of the WRI system included over-the-road tests performed on the highway 

with both the truck and MEV traveling at or near 55 mi/h. For these tests, the MEV traveled near 

the instrumented truck at various relative positions such as 12:00, 1:30, 3:00, etc (Figure 28). 

This test was performed at 5.9 GHz with two different dome antenna placements on the MEV: 

the first location was centered on the roof, and the other was laterally centered but toward the 

front of the vehicle (see Figure 29 inset). Two tests were performed for each position and 

antenna location. While both placements allowed transmission toward the front of the 

instrumented vehicle, the centered placement permitted transmission when the MEV was farther 

behind the test truck. 

Figure 28. Diagram. MEV-Truck Positions for Over-The-Road Tests 

Performed at Highway Speeds 

The WRI system was also tested during an interstate trip from Knoxville, TN to a CMV 

inspection station near Corbin, KY and back. For this test, a van (the MEV) was instrumented 

with two receiving systems, one using a dome antenna and the other connected to a stick 

antenna. During the trip to Kentucky, the wireless systems were set up for constant 5.9-GHz 

communication; 2.4-GHz communication was used for all transmissions during the return trip. 

General observations regarding transmission over the road were recorded during this trip. 

The drive-by testing which made use of a tripod stick antenna for 5.9-GHz reception yielded 

overall positive results. As shown in Table 9, a wireless inspection could be performed each time 

the instrumented truck traveling east in the 25-mi/h bypass lane passed an RSU using a stick 

antenna or a MEV (van) instrumented with a dome antenna. The system had less success across 

the highway. It was observed that during the westbound testing, other vehicles occasionally came 

between the truck and the RSU. The stick antenna was able to complete a file transfer from the 

westbound side more than 80 percent of the time, while the dome antenna was unable to achieve 

transfer at all at 5.9 GHz. 

The drive-by file transfer testing performed at 2.4 GHz yielded fairly good results (see Table 9). 

With the dome antenna mounted on a tripod, file transfer from the opposite side of the highway 

was nearly as successful as transfer from the bypass lane at 25 mi/h. For the dome-instrumented 

van (MEV), however, reception from the bypass lane was poor, although more inspections could 

be performed from across the highway. It is recommended that this surprising result be analyzed 

further in future tests. With the dome antenna mounted on the patrol car (MEV), files could be 
45 

received in each of the three different passing scenarios (25 mi/h bypass, 55 mi/h eastbound, and 

55 mi/h westbound). 

Table 9. Results of Drive-by Dynamic Transmission Tests at Tested Speeds 

Frequency 5.9 GHz 5.9 GHz 2.4 GHz 2.4 GHz 2.4 GHz 

Antenna Type Dome Stick Dome Dome Dome 

Antenna Placement MEV—Van Tripod MEV—Van MEV—Patrol Tripod 

Bypass—25 mi/h 100% 100% 25% 100%* 83% 

Eastbound—55 mi/h 67%* N/A N/A 100%* N/A 

Westbound—55 mi/h 0% 82% 71% 100%* 80% 

*Indicates only 2 or 3 runs tested for this situation. 

Relative Position Tests: The results of the 5.9-GHz at-speed tests (with the van, which served as 

the MEV, instrumented with a dome antenna) are shown in Figure 29. For both antenna positions 

tested, file transfer was successful when the MEV was positioned directly to the side of the 

instrumented truck and slightly ahead, as well as in the lane to either side of the truck. File 

transfer to the MEV positioned slightly behind the truck in the adjacent lane was accomplished 

only with the centered antenna placement as shown in the Figure 29 inset. A wireless inspection 

could not be performed either directly behind or directly in front of the instrumented truck, 

regardless of the MEV antenna placement. Those results were similar to those produced by the 

static tests discussed in the previous subsection. 

Figure 29. Combined Diagrams. Dome Antenna Placement and Results for 

Over-the-Road (55 mi/h) Orientation Testing at 5.9 GHz 

Centered 

Placement 

Top View of MEV

Direction 

of Travel 

Forward 

Placement 

Centered 

Placement 

Key

Mixed transfer success (1 of 2) 

No file transferred (0 of 2) 

File transferred (2 of 2) 

Forward 

Placement 

Other Road Tests: During the trip to Kentucky (in which 5.9-GHz transmission was used), the 

number of files obtained by the stick antenna on the MEV was nearly four times the number 

obtained by the dome antenna. At 5.9 GHz, both antenna types were able to receive files when 
46 

the MEV was positioned directly to either side of the truck. For the system using the stick 

antenna, however, file transfer was possible at many more positions. At the inspection station, 

the stick antenna was able to receive files from either side of the highway, but the dome antenna 

was unable to receive any files. At 2.4 GHz (during the return trip), the dome antenna obtained 

more than 4.5 times the number of files that the stick antenna did. In the instance in which there 

was little traffic and the MEV was ahead of the truck but slightly off-center, the system using the 

stick antenna could inspect the truck at a distance of more than a quarter-mile. 

3.2.3 Test Conclusions and Future Work 

For two antennas of the same type, the antenna mounted on the tripod received the SDMS more 

reliably than on the van (MEV). This result is probably because transmissions at 2.4 and 5.9 GHz 

are greatly improved by line-of-sight; a higher antenna placement results in fewer objects 

interfering with the transmission. In the bypass-lane tests, it is likely that the body of the truck 

itself and objects near the roadway limited the time during which transmission could occur; 

several pit-scale weight information signs were located along the right side of the bypass lane. 

The results of the dynamic orientation tests (Figure 29) indicate that a central placement of the 

dome antenna on the MEV roof is preferred. Both the static and dynamic tests demonstrated that 

there are unresolved issues regarding file transfers when the MEV is directly in front of the 

truck. 

The results of the Tennessee-Kentucky trip confirmed that the stick antenna is very inefficient at 

2.4 GHz; this was expected because the stick antenna used was designed to operate at 5.9 GHz. 

While the dome-type antenna was specified to operate at both 2.4 and 5.9 GHz, its performance 

at 2.4 GHz was much better than its performance at 5.9 GHz. The overall performance of the 

dome antenna when operated at 2.4 GHz was comparable to that of the stick antenna used at 5.9 

GHz; however, the dome antenna seems to be the preferable choice, because of the flexibility 

afforded by its ability to operate at two frequencies. However, because only one frequency will 

ultimately be used for a WRI system, the choice of antennas should be tailored to the frequency 

chosen. Other factors not taken into account in this POC test that should be considered in future 

research include the durability of different antenna types, optimum mounting solutions, and the 

effect of weather and terrain. 

This POC test demonstrated that the wireless inspection system tested was sufficiently robust to 

function as designed in real-world driving environments. Inasmuch as this testing was performed 

to provide a starting point for further research into wireless safety inspection methods, future 

work is necessary to refine the system. Regarding file transfer, reliability of this process varied 

with antenna type, placement, and frequency. The results of this POC test, however, demonstrate 

that it is possible to reliably transfer an SDMS at highway speeds. 

Future work should include more extensive testing with regard to ideal antenna parameters, 

including type, height, and orientation. Antenna and communication requirements should be 

developed and refined to include required frequency (2.4 GHz vs. 5.9 GHz), antenna type, and 

optimal placement of antenna on each instrumented vehicle. 

Ultimately, it will be necessary to test a large number of vehicles to verify system feasibility on a 

wider scale. Larger-scale testing should be designed to test performance when several 
47 

instrumented vehicles pass an RSU. This testing will most likely involve a system that uses an 

inspection method that is focused (such as a directional antenna placed over a specific lane) 

rather than widespread (such as an omni-directional antenna with a large coverage area), and 

therefore more appropriate for a large number of trucks. The TechnoCom transceiver that was 

used has the capability of selectively communicating with one of multiple vehicles via geozoning, direction of travel preference, and other such methods. However, the scope of this POC 

did not include testing these features. Another problem which must be resolved before 

widespread implementation of such a wireless inspection method is the problem of how to 

identify visually which truck (in a group) is providing the information viewed by enforcement 

personnel for each wireless inspection. 

49 

4. TECHNOLOGY SHOWCASE 

The FMCSA, in close partnership with TDOS, the Tennessee Department of Transportation 

(TDOT), and ORNL, sponsored a CMV Roadside Technology Showcase to demonstrate current 

and prototype large truck and bus safety inspection technologies. This event was facilitated by 

ORNL and was held on Tuesday, August 7, 2006, from 10:00 a.m. to 2:00 p.m., at the Greene 

County CMV Inspection Station, located on southbound I-81 near mile marker 21 in eastern 

Tennessee. 

The Showcase highlighted the establishment of a permanent truck and bus roadside technology 

testing corridor for FMCSA, TDOS, and TDOT. 

Current inspection technologies and systems showcased were: 

 Inspection Selection System. 

 Query Central Data Portal. 

 Aspen Inspection Software. 

 Driver Information Resource. 

 Performance-Based Brake Testing (PBBT). 

 ComVISTM Portable Inspection Data Collection. 

 PrePassTM Electronic Screening System. 

Future technology inspection prototypes exhibited were: 

 Smart Infrared Inspection System—captures thermal signatures of wheel components and 

automatically alerts inspectors to anomalies needing further attention 

 WRI System—allows for the retrieval of real-time safety data pertaining to the driver, 

vehicle, and carrier from both a Class-8 tractor-trailer and a commercial motor coach as 

they pass by the inspection station 

Figure 30 shows an aerial view of the Greene County CMV Inspection Station and the location 

of the various exhibits for the Showcase. Figure 31 and Figure 32 show example demonstrations 

in progress during the Showcase. 
50 

Figure 30. Aerial Photo. View of the Greene County CMV Inspection Station 

Figure 31. Photo. WRI POC MEV Ready for Demonstration 
51 

Figure 32. Photo. Wal-Mart Truck on the PBBT at the Aug 7, 2007 Showcase 

53 

5. WRI INTERFACE 

A primary requirement for the Technology Showcase was the ability to format and display the 

data that had been wirelessly transferred from the moving vehicle to the roadside or MEV in a 

format that could be easily seen and understood by the viewing audience and the end-user. The 

WRI GUI software was designed specifically for this purpose, at the same time incorporating 

functionality that would be useful for an inspection official when performing wireless 

inspections. 

The interface organizes the data to be displayed according to what is most important about the 

vehicle, or needs to be quickly identified, as well as according to whether the most important 

thing pertains to the driver, the carrier, or the vehicle itself. Therefore, five primary screens 

(Figure 33 through Figure 37) were designed: overview, driver status, carrier status, vehicle 

status, and driver HOS. The program is designed such that the user starts with the overview 

screen, which summarizes the identifying information of the driver, carrier, and vehicle, and 

provides a quick alert for any infringements identified. The remaining four screens provide more 

detailed information in each specific category. 

The data displayed in the interface are a combination of data that have been wirelessly 

transferred from the vehicle and information that is acquired from a back-office database. For 

demonstration purposes, the kernel message was augmented with weight data obtained from the 

vehicle data bus through the comparison system (see section 2.2.5) before being wirelessly 

transferred. While some electronic databases already exist and can be manually queried by an 

inspection officer for a given truck, driver, or carrier, other information is not yet available in 

this way. Therefore, for the purposes of this POC test, a “pseudo-database” was created that 

contained information necessary to demonstrate how the wireless inspection system would 

function if the actual databases were fully networked and accessible to the WRI system. 

Figure 33. Screen shot. WRI GUI Overview Screen 
54 

Figure 34. Screen shot. WRI GUI Driver Screen 

Figure 35. Screen shot. WRI GUI Carrier Screen 
55 

Figure 36. Screen shot. WRI GUI Vehicle Screen 

Figure 37. Screen shot. WRI GUI HOS Screen 

57 

6. WRI POC PARTICIPANT QUESTIONAIRES 

Although there was almost no interaction with carriers or drivers during the POC (with the 

exception of the Technology Showcase; see section 4.0), TDOS personnel were involved in the 

POC testing, were familiar with the capabilities of the system, and used the graphical user 

interface (section 5.0). Feedback questionnaires were developed as a part of the Test Plan for the 

WRI POC. The responses of the TDOS personnel and the truck and motor coach drivers for the 

Technology Showcase are presented in sections 6.1 and 6.2. 

6.1 TDOS SURVEY 

Six troopers from TDOS responded to the questionnaire regarding the WRI technology. The 

questions and responses are below. 

Enforcement Personnel Questionnaire with Responses 

Section 1: Use of the technology at the inspection station (RSU)

1. Would you find this type of device useful? 

 Responses: Yes: 6 No: 0 Response Not Provided: 0

Additional Comments: 

 None 

2. Was the format of the test performed a good simulation of how the device would actually be used on the 

job? If not, what would have made the test more realistic? 

Responses: Yes: 5 No: 0 Response Not Provided: 1 

Additional Comments: 

 I mostly used the front page (1) 

 Great (1) 

3. Would additional information from the screens be useful to you? If so, what data? 

Responses: Yes: 1 No: 4 Response Not Provided: 1 

 Additional Comments:

 Too much info (2) 

 I am fairly satisfied (1) 

 If co-driver is used, need to have that information so duty status would match up with time (1) 

4. Was any of the information presented on the screens superfluous or otherwise not needed? If so, what 

data? 

 Responses: Yes: 1 No: 5 Response Not Provided: 0

 Additional Comments:

 Only need expiration date on medical card (1) 

 System status not needed (1) 

 Only date needed on last Annual Inspection (1) 

5. Do you see any pitfalls or problems with such a device? 

 Responses: Yes: 3 No: 2 Response Not Provided: 1

 Additional Comments:

 The information can be changed by the company or driver (3) 

 The vehicle information can be wrong (1) 

 In order to be beneficial, the device would need to be mandatory to all motor vehicles (1) 
58 

Section 2: Use of the technology in a Mobile Enforcement Vehicle (MEV Unit)

1. Would you find this type of device useful? 

 Responses: Yes: 5 No: 0 Response Not Provided: 1

 Additional Comments:

 None 

2. Was the format of the test performed a good simulation of how the device would actually be used on the 

job? If not, what would have made the test more realistic? 

 Responses: Yes: 5 No: 0 Response Not Provided: 1

 Additional Comments:

 I mostly used the front page (1) 

3. Would additional information from the screens be useful to you? If so, what data? 

 Responses: Yes: 0 No: 5 Response Not Provided: 1

 Additional Comments:

 Too much info (2) 

4. Was any of the information presented on the screens superfluous or otherwise not needed? If so, what 

data? 

 Responses: Yes: 4 No: 2 Response Not Provided: 0

 Additional Comments:

 Only need expiration date on medical card (1) 

 System status not needed (1) 

 Only date needed on last Annual Inspection (1) 

5. Do you see any pitfalls or problems with such a device? 

 Responses: Yes: 4 No: 0 Response Not Provided: 2

 Additional Comments:

 The information can be changed by the company or driver (3) 

 The vehicle information can be wrong (1) 

 In order to be beneficial, the device would need to be mandatory to all motor vehicles (1) 

6. Was the device a distraction for the Trooper? 

 Responses: Yes: 0 No: 5 Response Not Provided: 1

 Additional Comments:

 None 
59 

6.2 DRIVER SURVEYS 

One tractor-trailer driver and one motor coach driver from industry responded to the 

questionnaire regarding the WRI technology. The questions and responses are below. 

Tractor-Trailer Driver Questionnaire with Responses 

1. Did the device impede your productivity? 

 Response: No. 

2. Was the device easy to use? 

 Response: Yes. I have used a similar device in the past. 

3. Would you object to the mandate of using such a device? Why or why not? 

 Response: I would be concerned about cost and the use of the information. 

4. Was the device a distraction while driving? If so, how could this be combated? 

 Response: No. 

5. Which do you feel would be the easiest interface for future designs? 

a. Keypad (cell phone) b. Touch screen c. Full keyboard d. Other _____ 

 Response: Voice activation for duty status changes. Keyboard for information entry. 

6. Was the format of the test performed a good simulation of how the device would actually be used on the 

job? If not, what would have made the test more realistic? 

 Response: Too limited to tell. 

7. What would your biggest concerns about the implementation of such a device be? 

 Response: Out-of-pocket cost and invasion of privacy. 

Motor Coach Driver Questionnaire with Responses 

1. Would you object to the mandate of having all of your buses equipped with such a device? Why or why 

not? 

Response: As a commercial vehicle owner and operator, I would object to a proposed mandate if I am 

expected to bear the expense of the mandate. Small operators are at the point that they can not bear any 

additional cost to their operations. 

2. Was the format of the test performed a good simulation of how the device will actually be used on the job? 

Response: Yes, although I am sure its capabilities had to be limited for the demonstration. 

3. Would the data obtained from the device be useful to you? 

Response: There [are] no data (viewed in the demonstration) that we are currently not keeping (i.e., DQFs, 

MVRs, maintenance files, HOS status). I am sure that there are many more options that would be available 

to us that would be beneficial. 

4. Do you see a need for such technology in order to keep a closer eye on driver activity and vehicle status? 

Response: I cannot speak for other operators. As far as our operation is concerned, the safety of our 

passengers is the primary goal of our company. When we are mixed with other commercial vehicles on the 

highways, then their safe operation becomes a major factor for us. It is getting much harder to find 

professional driver candidates as the transportation industry grows; therefore I feel a watchful eye would be 

in the best interest of all parties involved. 

5. Do you think your drivers would object to the use of such a device? Why or why not? 

Response: Yes, drivers would object at first. But, after the initial intimidation of a change, I think they would 

quickly begin to realize the benefits. One area that I think would appeal to drivers is the fact that the gray 

areas of doubt in infractions should disappear and the enforcement officer is no longer the judge, jury, and 

executioner. From what I’ve seen, it just seems to level the playing field. 

6. Do you see a value to your company from such a device? 

Response: Yes, definitely. Unlike the freight haulers, our cargo is human. Anything that promotes safety and 

makes us look good, has to be good for us and our industry. We currently encourage our customers to go to 

safersys.org and review our company snapshot and safety record. Any system that would make us more 

visible would keep us on our toes and become one more tool for us to promote our company. 

61 

7. LESSONS LEARNED 

The following is a general discussion of the lessons learned from the WRI POC. Input for this 

section was provided by the ORNL technical team, PeopleNet, and TechnoCom. 

Several positive lessons learned during the WRI POC proved to be of benefit to the project, and 

many will be of benefit to future related projects. 

 Private industry is willing to participate gratis in research that they find to be of value to 

their field of interest. This was certainly true of Air-Weigh and PeopleNet. They provided 

technology, software, and engineering support throughout the WRI POC. While it is 

difficult to put a value on this support, ORNL estimates that for the WRI POC, the value 

of this support was greater than $300,000. 

 The State of Tennessee’s Departments of Safety and Transportation and FMCSA’s 

Tennessee-based field staff are willing to help in any way possible. Neither the POC nor 

the Media Event would have been possible without their support and hard work. The 

WRI POC can serve as a model for bringing Federal and state government and private 

industry together to accomplish difficult tasks in a short time within a fixed budget. 

 The Greene County Tennessee CMV Inspection Station was found to be an excellent 

location for CMV research and technology testing. The 80-acre concrete pad, power 

availability, Internet access, and Interstate access made the site indispensable for this 

project. 

 The feasibility of composing a message in real time and transmitting that message 

wirelessly to a fixed or a mobile station was demonstrated. 

 The SDMS does not have to be a very large file in order to contain the needed vehicle, 

carrier, and driver information. ORNL found that a single record (a complete SDMS with 

one duty status change) was approximately 600 bytes. A complete, eight-day SDMS 

consisted of multiple records appended together equivalent to the number of duty status 

changes made during that eight-day period. For this case, an estimate of the SDMS total 

file size could be found simply by multiplying 600 bytes by the number of duty status 

changes made. 

 The PeopleNet OBC uses an internal real-time clock that is reset to GPS once the 

difference between it and the GPS UTC time reaches a pre-determined value. As a result, 

this system is more reliable than one which relies on GPS time signals alone, because the 

OBC is able to continue to provide time information in the absence of the GPS signal. 

However, the default configuration for the time difference before time reset for the kernel 

was set to 15 seconds. In retrospect, the difference could have been reduced considerably, 

thereby preventing the 15-second position discrepancy. 
62 

Among the lessons learned there were several that could have affected the WRI POC in a 

detrimental way. They are: 

 Greater depth of partnerships—Only one kernel provider partnership was provided. This 

left the WRI POC in a very vulnerable position. If the PeopleNet device had failed to 

gather and format the SDMS, the POC would not have been able to finish with a 

commercially viable system and the project would have had to rely on the ORNLdeveloped DAS. This was similarly true of the transceiver provider. Although 

TechnoCom did not participate gratis, the project budget would not have allowed for a 

second paid transceiver partner in the event that the TechnoCom equipment/software 

failed to transmit the SDMS. Such an event would have been catastrophic to Phase 1B of 

the POC. 

 Remoteness of the Greene County, Tennessee CMV Inspection Station proved to be 

costly in time, manpower, and dollars. Travel time from ORNL to the site was 

approximately 90 minutes. Furthermore, the site is located about 30 minutes from the 

nearest hardware and retail stores and restaurants (food was not available on-site). 

 It is very difficult to find large, flat, paved areas for CMV static and dynamic testing. The 

Greene County site proved to be acceptable, but required some novel testing schemes to 

accomplish all of the static testing called for in the test plan. A test track would have been 

a better option, but would have required funding for the track time, travel time, and travel 

expenses for the technical team. 

 It is difficult and potentially unsafe to conduct some types of CMV testing at highway 

speeds on public roadways. It is difficult to determine vehicle separation distance and to 

maintain separation angle and distance. A test track is recommended for all future testing 

of this nature. 

 The WRI POC team attempted to accomplish too much during the POC (develop the 

system, test the system, include a MEV, include a motor coach, include an unproven 

transceiver, and conduct the Technology Showcase; and demo the tractor, MEV, and 

motor-coach-based systems at the Technology Showcase). Given the time and budget, the 

number of deliverables for the POC made it uncertain that success would be achieved in 

all areas of the POC. 

 Conducting the Technology Showcase endangered the success of the POC. A large 

portion of the technical team’s effort went into preparing for the Technology Showcase 

and the vehicle perturbations (MEV and motor coach) for the Showcase. Much of the 

preparation for the Showcase had to be done during the POC in order to meet the 

Showcase date of August 7. 

 The transceiver equipment requires additional analytical testing for this type of 

application (antenna attenuation, cable attenuation, obstruction interference, bandwidth, 

range, deployment methods, antenna transmission/reception angles, antenna types). A 

large portion of the ORNL technical team’s time was spent trying to get transmission via 

the transceiver. 
63 

 Partners should be encouraged to install the equipment that they are providing, or at least 

spend a day or two on-site to assist with troubleshooting. The ORNL technical team spent 

a significant amount of time working through problems with the transceiver (exploring 

the problem, communicating with the provider, testing the problem further, trying a 

possible solution, etc). While in a project such as this it is not possible completely to 

avoid set-up and configuration problems, an on-site visit from a representative from the 

transceiver provider would very likely have resulted in a more efficient resolution of 

these problems. 

 The analysis outlined in section 3.0 reveals that there was some misunderstanding as to 

which fields in the SDMS contained the PeopleNet-provided driver HOS data. There was 

also confusion as to how the J1708 odometer data are supplied and how they are 

formatted per the J1587 specification. Clarity in such matters before testing begins would 

yield results that are more accurate and hence more suitable for comparative analysis of 

competing vendors for future phases of this project. 

65 

8. SUMMARY OF RESULTS AND CONCLUSION 

The test performed in Phase 1A showed that it was possible for the kernel to gather information 

from different sources (including an EOBR and a vehicle databus), assemble the required SDMS, 

and make it available for transmission to an RSU or MEV. The frequency at which these 

messages were generated was very high (i.e., an average of one SDMS every 10.2 seconds) for 

the type of application considered here. The largest observed delay in generating a new SDMS 

was just over five minutes, which was considered acceptable. 

The accuracy of the information posted on the SDMS was measured within a certain tolerance, 

which was arbitrarily set at three levels. After some synchronization problems between the 

ground-truth and kernel messages were addressed, the information related to the spatial position 

of the vehicle (obtained from GPS readings) was 100 percent accurate when considering a 

tolerance of 1,000 ft. Speed, which was also determined via the GPS by the kernel, presented an 

accuracy level above 80 percent when considering a tolerance of 1 mi/h or less, and close to 100 

percent with a tolerance of 5 mi/h or less. Odometer information, which was read from the 

vehicle’s databus, was 79 percent accurate when considering a tolerance of 0.25 miles. 

The HOS information presented some problems. When a HOS diagram was built by combining 

driver status flags posted on the SDMS and the timestamp of that message, differences with the 

ground-truth HOS were found. Those differences were substantially reduced (although not 

completely eliminated) when a different SDMS field was used. However, the information posted 

in this field, although very accurate, was not relayed in a timely fashion. Most of the observed 

delays were in the 5–20-minute range (which was expected), although in two instances they were 

measured in hours. There were also a few occasions on which a status change was either not 

registered or not posted in the SDMS. 

For two antennas of the same type, the antenna mounted on the tripod received the SDMS more 

reliably than on the van (MEV). This was probably due to the fact that transmission at 2.4 and 

5.9 GHz is greatly improved by line-of-sight; a higher antenna placement results in fewer objects 

interfering with the transmission. In the bypass-lane tests, it was likely that the body of the truck 

itself and objects near the roadway limited the time during which transmission could occur; 

several pit-scale weight information signs were located along the right side of the bypass lane. 

The results of the dynamic orientation tests indicated that a central placement of the dome 

antenna on the MEV roof was preferable. Both static and dynamic tests showed that there were 

unresolved issues regarding file transfers when the MEV was directly in front of the truck. 

The results of the Tennessee–Kentucky trip confirmed that the stick antenna is very inefficient at 

2.4 GHz; this was expected because the stick antenna used was designed to operate at 5.9 GHz. 

While the dome-type antenna was specified to operate at both 2.4 and 5.9 GHz, its performance 

at 2.4 GHz was much better than at 5.9 GHz. The overall performance of the dome antenna when 

operated at 2.4 GHz was comparable to that of the stick antenna used at 5.9 GHz; however, the 

dome antenna seems to be the preferable choice, because of the flexibility afforded by its ability 

to operate at two frequencies. However, because only one frequency will ultimately be used for a 

given WRI system, the choice of antennas should be tailored to the frequency chosen. Other 

factors that were not taken into account in this POC test, but that should be considered in future 
66 

research, include the durability of different antenna types, optimum mounting solutions, and the 

effect of weather and terrain. 

This POC test demonstrated that the wireless inspection system tested was sufficiently robust to 

function as designed in real-world driving environments. As this testing was performed to 

provide a starting point for further research into wireless safety inspection methods, future work 

is necessary to refine the system. While the reliability of file transfer varied with antenna type, 

placement, and frequency, the results of this POC test demonstrated that it is possible to transfer 

an SDMS reliably at highway speeds. 
67 

9. SUGGESTED FUTURE RESEARCH/RECOMMENDATIONS 

Since the accuracy of the information contained in the SDMS seems to be acceptable, the main 

area on which future research should focus is the timeliness of the HOS information that is added 

to that message. Most of the observed problems were attributed to communication and software 

issues. In fact, during the pre-testing period, several related problems were identified by ORNL 

and addressed by the partner supplying the kernel information. It appears that some aspects of 

these problems were not fully resolved by the time the test took place. Nevertheless, those 

problems are not insurmountable, and should be easily resolved during the next phase. Also, as 

previously mentioned, certain delays were inherent to the system due to the back-office 

communication of the kernel. These delays would not be present in a commercially produced 

product. 

Also, in future tests, it is important that more detailed technical discussions be carried out 

between the testers (ORNL) and the developers of the system. Such communication would 

facilitate a better understanding of the idiosyncrasies of both the DAS and the kernel, which 

would help to avoid issues such as reading the same field in different units (e.g., odometer) or 

providing timestamps that are generated by different devices (thus introducing synchronization 

problems). 

Future work should include more extensive testing regarding ideal antenna parameters, including 

type, height, and orientation. Antenna and communication requirements should be developed and 

refined to include required frequency (2.4 GHz vs. 5.9 GHz), antenna type, and optimal 

placement of the antenna on each instrumented vehicle. 

There is a need ultimately to test a large number of vehicles to verify system feasibility on a 

wider scale. Larger-scale testing should be designed to test performance when several 

instrumented vehicles pass an RSU. This testing will likely involve a system which uses an 

inspection method that is more focused (such as a directional antenna placed over a specific lane) 

rather than widespread (such as an omni-directional antenna with a large coverage area), 

resulting in a system which is appropriate for a large number of trucks. The TechnoCom 

transceiver that was used has the capability to communicate selectively with one of multiple 

vehicles via geo-zoning, direction of travel preference, and other such methods. However, the 

scope of this POC did not include testing of these features. Another problem that must be 

resolved before widespread implementation of a wireless inspection method is that of the ability 

to identify visually which truck (in a group) is providing the information viewed by enforcement 

personnel for each wireless inspection. 

For the next phase of the program, in order to ensure greater success, it is recommended that 

more time be given to the formation of partnerships to provide good depth of technology. 

Emphasis should be placed on gratis partnerships to minimize cost and maximize industry buyin. Each critical area of the Pilot Test (as described in section 1.1) should be identified, and when 

technology is present, redundancy should be emphasized as well. In the case of the WRI POC, 

only one kernel provider and only one transceiver provider participated. This provided no depth 

of options as to the method, and if either provider’s technology had failed, that would have 

caused the effort to fail. 
68 

It is envisioned that the future Pilot Test will involve a much greater level of complexity and 

many more entities. It is suggested that the Pilot Test be conducted using a “subsystems” 

approach with multiple teams working in parallel. Work-arounds should be planned if any teams 

fail their primary task. This would allow other teams to proceed, ensuring that the overall project 

comes to a successful conclusion. For example: If DSRC is chosen to be the communications 

method for the SDMS transmission, a team should be appointed to develop, test, and integrate 

this technology into the greater project. This team should be responsible only for the DSRC 

portion of the project. Further, DSRC should not be the only communications method selected. A 

back-up method should be explored in the event that DSRC fails to function as expected. 
69 

APPENDIX A: 

WIRELESS ROADSIDE INSPECTION PROOF-OF-CONCEPT 

TESTING FAST TRACK PLAN DISCUSSION PAPER 

71 
72 
73 
74 
75 
76 
77 

APPENDIX B. ACKNOWLEDGEMENTS 

The Oak Ridge National Laboratory would like to thank Mark Jones and Jim Bunch (Noblis), 

Valerie Barns (Johns Hopkins Applied Physics Laboratory), Joe Lovecchio (Volpe National 

Transportation System Center), Steve Keppler (Commercial Vehicle Safety Alliance), Randall 

Plate (Cedarville University), and Mary Beth Lascurain (Pensacola Christian College) for their 

technical support and guidance during the Wireless Roadside Inspection Proof-of-Concept Test 

(WRI POC). We would like to thank PeopleNet and Air-Weigh, Inc. for their gratis partnership; 

the contributions made by these firms are greatly appreciated. 

We would also like to thank the troopers from the Tennessee Department of Safety (Knox 

County and Greene County Inspection Stations, and Headquarters Nashville) and personnel from 

the Tennessee Department of Transportation for all of their hard work and support during the 

WRI POC. 

Lastly, we would like to thank Gerald Keifer, Lisa Rouse, and Stephanie Mann, FMCSA Field 

Staff (Tennessee), for their support of the Technology Showcase and all of the hard work leading 

up to the success of the Technology Showcase on August 7, 2007. 

79 

REFERENCES 

SAE International. 2002. Electronic Data Interchange between Microcomputer Systems in 

Heavy-Duty Vehicle Applications. Document number J1587, February 2002, p. 138. 

Sinnott RW. 1984. Virtues of the Haversine. Sky and Telescope, 68(2), p. 159.