The ABCs of HVEDRs for Crash Analysis

Introduction

Modern heavy-duty can be described as rolling computer networks with seemingly endless possibilities for data collection and transmission. Many different devices found on trucks have the capability of collecting and storing this data when an incident occurs. These devices are collectively referred to as Heavy Vehicle Event Data Recorders (HVEDRs). In most cases, however, an HVEDR is not a device but a software application added to an existing device that has an original purpose other than collecting and storing incident data.

Data collected and stored by HVEDRs can be useful when analyzing a truck crash. The most useful data comes from trip/event data recorders on engine Electronic Control Modules (ECMs) and wireless fleet management systems (a.k.a. tracking/ communication systems, mobile resource management systems, and telematic systems). These systems can record vehicle speed, brake usage, vehicle-use histograms, vehicle position history, active and historic diagnostic trouble codes, and more. An endless number of devices used on trucks that have a HVEDR function and no two devices record the same data. Therefore, an HVEDR is like a Christmas present where you really don’t know what you're going to get until you open it. You may think you know what is in the box and sometimes you are right but often it is a surprise.

Rolling Computer Networks

To understand HVEDRs, an explanation of the basics of a truck onboard networks is helpful. A modern vehicle has numerous sensors that report volumes of data to small computers, called Electronic Control Modules (ECMs) or “modules”. These modules process the sensor information to make decisions about how to control actuators that effect engine fuel management, antilock brake system activation, cruise-control management, transmission shifting, climate-control management, etc. These modules also run diagnostics on their sensors and actuators, set Diagnostic Trouble Codes (DTC) if a fault is detected, and turn on dashboard warning lamps, called Malfunction Indicator Lamps (MIL), when a fault occurs. These modules are also where HVEDR data can be found.

Modules have been used in vehicles for more than 30 years, but only became widely used on heavy-duty trucks in the 1990's when most of these trucks were outfitted with electronic fuel injection and antilock brake systems (ABS). These modules go by different names depending on either the vehicle manufacturer, or the system they control, or more likely by who is describing them. Some examples are an Engine Control Module (ECM), a Powertrain Control Module (PCM), a Body Control Module (BCM), and an Control Module (ACM). Each of these modules will be directly connected to all the sensors and actuators that are part of its system. The module’s sensors tell it what is going on by varying voltage levels or by toggling a voltage on and off repeatedly to create a frequency in the sensor circuit.

In addition to the modules being connected to their sensors and actuators, they will also be connected to each other by data lines that allow them to share their sensor data and actuator control. Early vehicle networks had separate data lines between modules that shared information. However, in the 1990’s, most vehicles started using some type of multiplexed onboard network. Multiplexing is a method of transmitting multiple signals on a single network data line allowing many modules to share that line. The first of these multiplexed vehicle networks either had a star or a ring style network topography. In a star network, each of the modules is connected to a central device or hub. In a ring network each of the modules is connected to two others in order to complete a ring. The current vehicle network standard, “CAN” (Controller Area Network), uses a linear bus-style topography with a single network data line or “backbone” with all the modules connected in parallel. The CAN standard allows all the modules to connect anywhere on the backbone and communicate with any other module connected to the CAN network.

Over the last fifteen years, the transition to multiplexed networking has resulted in virtually everything electrical on a vehicle to become actuated by a module. The advantage of multiplexed technology has been the large reduction in the amount of wire in modern vehicles while allowing an exponential increase in previously unimagined vehicle features like speed-controlled stereo volume. This function is accomplished by connecting the stereo module to the onboard network where it can “see” the vehicle speed sensor data and then use that data to adjust its volume accordingly.

Since nearly everything on a modern vehicle has become controlled by a module, almost all of the driver’s switches and buttons are no longer “direct wired” to the component they control. Instead, when driver’s switches and buttons are pushed or turned on they first send commands to a module, and then the module actuates the associated device. In the past, when a driver rolled down a power window, he pushed on the switch completing the 12-volt electrical connection to the window motor. In a modern vehicle, when a driver pushes on the power window switch, it “tells” a module to roll down the window and the module actuates the power window motor by completing the 12-volt electrical connection. The network module in the driver’s door replaced the massive cluster of wire that, in the past, connected everything electrical in the door to the vehicle’s wiring harness, and commonly broke over time from the door being opened and closed.

Society of Automotive Engineers (SAE) standards specify communication protocols and physical architecture for these onboard networks. SAE standardization allows modules from different equipment manufacturers (i.e., a engine control module and a Bendix antilock brake control module) to be networked and communicate with each other. For heavy-duty vehicles, the initial standards were J1587, which established the language used by these systems, and J1706, which established the physical architecture of the wiring. The current heavy-duty vehicle network standard, J1939 is a CAN network.

These onboard networks can be accessed through a standard Diagnostic Link Connection (DLC) mounted in the truck’s cab. The heavy-duty vehicle DLC connection is also commonly referred to as a Deutsch connection and can be either a 6-pin, J1706 connector, or a 9-pin, J1939 connector. A diagnostic scan tool connected to the DLC, allows access to data such as live sensor data streams, a.k.a., Parameter IDs (PIDs), DTCs, sensor data snapshots, and sensor data logs, etc. With a scan tool, PIDs can be viewed to determine if sensors are functioning properly and reporting normal information. Output tests can also be performed to test device actuation. Bidirectional testing can be done by looking at the live network PIDs with a scan tool. For example, you could push the horn with your hand and, if working properly, you would see its PID display on the scan tool change from "off" to "on". Conversely, you could perform an output test on the horn by using the scan tool to sound the horn.

What’s important for the purpose of this HVEDR discussion is that many vehicles currently have a large volume of PIDs, including many of the driver’s controls such as the horn, windshield wipers, windshield washer, climate controls, etc. These and many more PIDs are available on the onboard networks of many modern vehicles and they can potentially be captured by an HVEDR. While most HVEDRs are only capturing PIDs such as vehicle speed, engine RPM, throttle position, brake-switch status, and a few others, with current network technology, many more PIDs are available to be captured by an HVEDR. The potential for an HVEDR report to show, at the time of a crash, that a driver was using the windshield washer, adjusting the mirrors, honking the horn, etc. is realistic.

Also important, for the purpose of this HVEDR discussion, is that onboard network standardization allows other devices, such as a wireless fleet management system (covered in detail later) to be connected to the truck’s onboard network. These wireless fleet management systems are essentially another module on the network that can record any of the PIDs on the truck’s onboard network and wirelessly transmit them to a remote computer system where they can be stored. A large number of these wireless fleet management systems are currently available, but no two truck fleets seem to be using the same system. So, determining what data one of these wireless fleet management systems may have recorded can be a challenge.

HVEDR Background

Mostly, current HVEDRs are trip/event recorders that were originally intended as a fleet management tool to allow trucking companies to directly monitor their driver's and driving behavior. Even before truck manufacturers began using electronics to control vehicle systems, both mechanical and electronic aftermarket add-on trip recorders were available for fleets to install on their trucks. A mechanical trip recorder (tachograph) is a device that writes speed and hours-of-service data to a paper disc mounted on the truck's dashboard. Add-on electronic trip recorders, like the Rockwell Trip-Master, have been around since the 1970's and also record speed and hours-of-service data.

With the transition to engines with electronically-controlled fuel injection in the 1990s, engine manufacturers began adding a trip/event recorder function to the engine ECM. This addition was very easy since fuel injection systems were already streaming data from sensors like the vehicle speed sensor. The first of these ECM-based trip/event recorders probably appeared on Detroit Diesel's third generation electronic control system, the DDEC III system. This system was in use between 1993 and 1997 and some had a trip/event recorder function called Pro-Driver.

More recently, add-on electronic trip recorders have become common again. The modern term-of-art for these add-on electronic trip recorders is Electronic Onboard Recorders (EOBRs). These modern EOBRs, which are typically part of a wireless fleet management system connected to the truck's onboard network, collect volumes of sensor data.

Sources of HVEDR Data

HVEDRs record data that streams from a number of different PIDs on a truck. Some common sources of these PIDs are as follows:

Vehicle Speed Sensor (VSS) - The VSS is a pulse generator and tone ring (toothed ring) that is mounted on the tail-shaft of the transmission. The tone ring spins with the transmission tail-shaft and, as its teeth pass the VSS, it creates a high and low voltage pulse. The ECM measures the VSS pulse frequency, and then calculates vehicle speed.

Throttle Position Sensor (TPS) - The TPS is a potentiometer (variable resistor) mounted to the throttle. It tells the ECM how far the throttle is pushed in by varying resistance in its 5-volt circuit. Varying resistance causes the voltage on the output side of the circuit to vary proportional to throttle movement. The ECM measures the TPS output voltage and “sees” the throttle position as follows: (1) idle at 0.5 volts; (2) half throttle at 2.25 volts; and (3) wide-open throttle at 5.0 volts.

Crank Position Sensor (CKPS) - The CKPS is a pulse generator similar to the VSS that reports the position and rotational speed (RPM) of the engine’s crank shaft to the ECM.

Brake Position Sensor (BLS) - The BLS is an electrical switch on an air-braked truck that measures brake control-line air pressure to report whether the brakes are on or off.

Clutch Pedal Position Sensor (CPPS) - The CPPS is an electrical on/off switch that reports the position (engaged or disengaged) of the clutch pedal to the ECM.

Calculated Engine Load - The ECM uses data from sensors that report engine RPM, throttle position, and engine intake air flow to calculate engine load. This calculation is used by the ECM to determine how much fuel to inject into the engine.

HVEDR Data and Events

The common types of data and events found in HVEDRs that can be useful for a crash analysis are:

1. Configuration Data.

2. Last Stop Record.

3. Incident Record.

4. Engine Use Histograms.

5. Trip Reports.

6. Diagnostic Trouble Code Snapshots.

7. Stability Control Event Record.

8. Crash Acceleration Record.

These types of data and events are described as follows:

Configuration Data - Electronically-controlled heavy diesel engines have certain programmable parameters that owners can adjust to meet their operational and performance needs. These changes are normally performed by a truck technician and must be made with a diagnostic scan tool. The ECM will often have a trail showing when changes were made to the configuration file and show a scan tool I.D. number to identify who made the change. A common example of an adjustable parameter found in the Configuration File is the truck's maximum speed or “Governed Speed”.

Last Stop Record - A Last Stop Record is an event triggered by the vehicle speed sensor reading 0 mph. The Last Stop Record will contain information including vehicle speed history from immediately before the last stop. This report could contain 1.5 minutes or more of data such as vehicle speed, engine RPM, engine load, throttle percentage, brake application, etc. If the truck is driven after a crash or towed while its key is in the on position, this Last Stop Record could be overwritten by a new Last Stop Record.

Incident Event Report - A Incident Event Report (A.K.A.) Sudden Deceleration/ Acceleration, Quick Stop, Hard Brake Event, etc.) is most commonly triggered by a rapid change in the VSS speed that meets a preset threshold but can also be triggered by other events like a rapid change in engine RPM . Incident Event Reports, which are triggered by a rapid change in VSS speed, are normally looking for a decrease in VSS speed but, in some systems, a rapid increase in VSS speed will also trigger an Incident Event Report. A common threshold setting for an Incident Event Report trigger is a VSS speed change of 7 mph or more in one second. However, the predetermined threshold can be from as low as 1 mph to as high as 15 mph. A Incident Event Report could include as much as 20 minutes of vehicle speed, throttle position, clutch position status, cruise control status, engine load, engine RPM, brake status, and MIL status. The Incident Event Report can be overwritten if the truck is driven and subsequent incident events occur. Any subsequent Incident Event Reports will overwrite the oldest stored Incident Event Report first. Most systems can store 2 to 3 Incident Event Reports, therefore, after a crash there would have to be two or three subsequent incident events to overwrite all the Incident Event Reports in storage at the time of the crash.

Engine Usage Histogram - Engine Usage Histograms record how long and when the truck is idling, the number of miles driven, and when the truck is moving. An Engine Usage Histogram record could contain as much as 30 days of data. These reports are very useful when performing log-book audits.

Trip Report - Trip Reports contain cumulative totals and averages of data like fuel economy, idle time, over speed, etc. The Trip Report normally starts from the date that these data were last accessed and downloaded. Since these data are rarely downloaded, they are often never reset and the start date for the “trip” is commonly the date the ECM was put in service.

Diagnostic Trouble Code Snapshot - Diagnostic Trouble Code (DTC) snapshots capture data when the ECM “sees” a sensor reporting data outside the sensors normal values and sets a DTC. Snapshots can record data from numerous sensors when a DTC occurs. This recording is intended to allow a technician to see everything that was occurring when the DTC was triggered. The purpose of DTC Snapshots is to aid a technician in diagnosing intermittent problems.

DTCs and DTC snapshots are often triggered during a crash from damage that causes rapid engine coolant leaks, rapid engine oil leaks, wiring damage, etc. A DTC snapshot that occurs at the time of a crash could have useful data such as vehicle speed. However, the data reported in a snapshot is normally a very small window of time and it is often hard to determine when and where this data occurred in relation to the crash. Therefore, in most cases, DTC snapshots are not very useful for crash analysis.

DTC snapshots are very volatile and can be overwritten easily when subsequent occurrences of the same DTC or new DTCs occur when the ECM is powered up to get the data. No fail-safe way exists to retrieve snapshots and DTCs without the risk of overwriting them. Attempting to retrieve snapshot data and DTCs can be very costly and they rarely produce much useable data. In cases where the ECM has other valuable data sources like incident events and you have no reason to believe the truck experienced any causative engine problems, you would be foolish to postpone the access of this other valuable data and instead incur extreme difficulty and expense in an attempt to preserve the often useless DTC data.

Stability Control Event - Antilock Brake Systems have been standard on heavy trucks for more than ten years. More recently, traction control systems have been integrated into the standard ABS. Now stability control systems have also become a common part of an ABS. An ABS, with traction control and stability control, can apply or release the brakes on a truck and/or trailer, and can prevent wheel lockup, understeer, oversteer (jackknifing), and truck rollovers. Some of these systems may record data such as vehicle speed when a stability control event occurs.

Crash Deceleration Record - Trucks equipped with air bags may record crash deceleration and other data in their ACM. This data will typically display the change in speed over time that normally is associated with a deceleration rate that could only be caused by a crash.

Engine Control Module HVEDRs

HVEDR data often comes from the Engine Control Module (ECM). Not all ECMs, however, are capable of storing event data and not all ECMs store the same data. The following list is an overview of what we have learned from more than 15 years of experience accessing and analyzing HVEDR data from ECMs. Understand, however, that this list is a general guideline and some of these systems may have variations. The following list was current as of 2012:

Detroit Diesel

Detroit Diesel started using electronic fuel management on their engines in 1985. They called their electronic fuel management system the Detroit Diesel Electronic Control (DDEC).

1. The DDEC I, starting production in 1985, likely has: a. Configuration Data. b. No trip/event data recording.

2. The DDEC II, starting production in 1987, likely has: a. Configuration Data. b. No trip/event data recording.

3. The DDEC III, starting production in 1994, likely has: a. Configuration Data. b. No trip/event data recording.

4. The DDEC III, starting production in 1997, likely has: a. Configuration Data. b. No trip/event data recording unless the data pages are turned on. c. With data pages turned on it may record: 1) Periodic maintenance. 2) Engine usage histograms. 3) Trip activity.

5. The DDEC IV, starting production 1998, likely has: a. Configuration Data. b. Trip/event data recording. c. One last stop record. d. Two incident event reports. e. Engine usage histograms. f. Three diagnostic Trouble Code Snapshots.

6. The DDEC V, starting production in 2003, likely has: a. Configuration Data. b. Trip/event data recording. c. One last stop record. d. Two incident event reports. e. Engine usage histograms. f. Three Diagnostic Trouble Code Snapshots.

7. The DDEC VI, starting production in 2007, likely has: a. Configuration Data. b. Trip/event data recording. c. One last stop record. d. Two incident event reports. e. Engine usage histograms.

8. The DDEC 10, starting production in 2010, likely has: a. Configuration Data. b. Trip/event data recording. c. One last stop record. d. Two incident event reports. e. Engine usage histograms. f. Three diagnostic Trouble Code Snapshots.

Mercedes-Benz

Since 2000, Mercedes-Benz and Detroit Diesel have both been owned by the same company, which is currently Daimler Trucks. In about 2002, Mercedes-Benz started using an electronic fuel management system on their heavy-duty engines that is basically the same as the Detroit Diesel DDEC and will have basically the same data as the DDEC.

Cummins

Cummins started using electronic fuel management on their engines in 1990. The first Cummins Electronic fuel management system was called the CELECT system and later was called the Cummins Integrated Systems (IS).

1. The CELECT, starting production in 1990, likely has: a. Configuration Data. b. No trip/event data recording.

2. The Road Relay and Sensor Plus, was optional on Cummins engines, starting production in 1990. It likely has: a. Trip/event data recording. b. Incident event report.

3. The IS series, starting production in 1998, likely has: a. Configuration Data. b. No trip/event data recording.

4. The IS series, starting production in 2002, likely has: a. Configuration Data. b. Trip/event data recording if it has a 2005 or later software update. c. Three incident event reports. d. Diagnostic Trouble Code Snapshot.

5. The IS series, starting production in 2005, likely has: a. Trip/event data recording. b. Three incident event reports. c. Diagnostic Trouble Code Snapshots.

Caterpillar

Caterpillar started using electronic fuel management on their engines in 1987. They called their electronic fuel management system the Programmable Electronic Engine Controller (PEEC) and later called it the Advanced Digital Engine Management (ADEM).

1. The PEEC, starting production in 1987, likely has: a. Configuration Data. b. No trip/event data recording.

2. The ADEM II, starting production in 1994, likely has: a. Configuration Data. b. Trip/event data recording. a. Incident event report **. b. Diagnostic Trouble Code Snapshot.

3. The ADEM III, starting production in 1998, likely has: a. Configuration Data. b. Trip/event data recording. c. Incident event report **. c. Diagnostic Trouble Code Snapshot.

4. The ADEM IV, starting production in 2005, likely has: a. Configuration Data. b. Trip/event data recording. a. Incident event report **. b. Diagnostic Trouble Code Snapshot.

5. The ADEM IV, starting production in 2007, likely has: a. Configuration Data. b. Trip/event data recording. c. Incident event report. d. Diagnostic Trouble Code Snapshot.

**From the factory, the ADEM has the default incident event speed threshold setting at 0 MPH which causes no data to be recorded. If the default incident event speed threshold setting has been reprogrammed with a setting other than 0 MPH, the ADEM will record an incident event.

Mack

Mack started using electronic fuel management on their engines in 1990. They called their electronic fuel management system the Vehicle Management and Control (VMAC).

1. The VMAC I, starting production in 1990, likely has: a. Configuration Data. b. No trip/event data recording.

2. The VMAC II, starting production in 1995, likely has: a. Configuration Data. b. No trip/event data recording.

3. The VMAC III, starting production in 1998, likely has: a. Configuration Data. b. Trip/event data recording. c. Two incident event reports.

4. The VMAC IV, starting production in 2007, likely has: a. Configuration Data. b. Trip/event data recording. c. Two incident event reports. d. Engine usage histograms.

Volvo

Since 2000, Volvo and have both been owned by the Volvo Group. Sometime around 2010, Volvo started using an electronic fuel management system on their heavy-duty engines that is basically the same as Mack’s VMAC system and will have basically the same data as the VMAC. Additionally, many Volvo trucks have an air bag system, which may record crash data.

International

Historically, International has been a large manufacturer of medium-duty diesel engines. Sometime in 2005, they acquired a South American engine manufacture MWM motors and began producing 11-liter and 13-liter heavy-duty truck engines in 2006. They call their new engine line the MaxxForce Advanced Diesel.

1. The MaxxForce 11-liter and 13-liter engines, starting production in 2006, likely have: a. Configuration Data. b. No trip/event data recording.

2. The MaxxForce 11-liter, 13-liter, and 15-liter engines, starting production in 2010, likely have: a. Configuration Data. b. Trip/event data recording. c. Two last stop records. d. Two incident event reports. e. Diagnostic Trouble Code Snapshot.

Other HVEDRs

VORAD / Wingman

The VORAD (Vehicle Onboard Radar) is a passive safety alert system that uses radar to detect and alert truck drivers about objects in their path before they become a conflict. The VORAD system consists of a Central Processing Unit (CPU), a dash- mounted forward sensor display, a bumper-mounted forward radar sensor (a.k.a., the forward antenna), a gyroscope sensor, an optional passenger A-pillar-mounted side sensor display and side radar sensor, and an optional driver’s A-pillar-mounted side sensor display and side radar sensor. The VORAD system is often found on heavy-duty trucks in large fleets. The VORAD was developed by the Eaton Corporation, but was later sold to Bendix Commercial Vehicle Systems.

The VORAD’s CPU is a module responsible for controlling the collision warning system commonly mounted on the truck’s passenger B-pillar. The CPU receives information from the truck’s onboard network (note: on older trucks these inputs are hard wired) like vehicle speed, engine speed, throttle percentage, turn signals, etc. along with information from the VORAD radar sensors and information from the VORAD gyroscope sensor to make decisions on when and how to activate the collision warning system.

The VORAD forward sensor display has a row of lights and an audible warning that light up and sound progressively when the driver is getting too close to or is quickly closing on a vehicle or object. The forward sensor display has one control knob that the driver can use to adjust the range of the radar sensor and another knob to adjust the volume of the audible warning.

The VORAD gyroscope senses when the truck is on a curve. It reports this information to the CPU to adjust the forward radar so it is not picking up vehicles in lanes next to the truck. Because the gyroscope sensor is contained inside the CPU, the CPU must be mounted in the truck correctly for it to work.

The VORAD can have either a side sensor only on the right side of the truck, or on both the right and left side of the truck, or on neither side. If equipped with a side sensor(s), the side sensor display(s) will be mounted on the A-pillar(s). Like the forward sensor, the side sensor display has a row of lights and an audible warning. The side sensor warns the driver of something in the side blind spot by lighting the lights on the display and giving the audible warning when the driver has his turn signal on.

After acquiring the VORAD, Bendix incorporated it into their Wingman system. The Bendix Wingman is a VORAD system with added active control functions called Active Cruise Control and Braking (ACB) and Advanced Collision Mitigation. The Wingman uses the VORAD technology to identify conflicts with other vehicles but still has passive driver warnings just like the VORAD. If the driver fails to respond to the passive warnings, the Wingman will actively respond to prevent conflicts or collisions with other vehicles by reducing engine power, by applying the engine retarder, and by applying the brakes. A Wingman with Active Cruise Control and Braking (ACB) only has active control over the truck when the cruise control is on. A Wingman that also has Advanced Collision Mitigation can apply up to two thirds of the truck's braking power when the system determines a collision with a forward vehicle is imminent even when the truck is not on cruise control.

After a VORAD-equipped truck has been involved in a crash, holding the range control knob in for 5 seconds causes the CPU to save 10 minutes of VORAD data that preceded the crash. The data that is stored by the VORAD includes vehicle speed, turn signal status, brake status, turn rate, and alert status.

Bendix

The Bendix air ABS system with the Electronic Stability Program (ESP) reportedly can store data from a stability control event.

Telematics

Truck telematics is the sending, receiving, and storing of data with mobile telecommunication devices. Truck telematics systems are widely used on commercial trucks and trailers for wireless fleet management. In the 1990's, large trucking companies started using truck telematics because they eliminated many dispatch problems for over- the-road trucks. Historically, truck drivers would have to either find a pay phone or wait in line at a truck stop’s pay phone bank to receive dispatch orders. Dispatchers would usually only receive information about the position of their trucks and freight when drivers would check in daily by phone.

Truck telematics systems were quickly embraced by larger trucking companies and, as their cost came down, smaller companies started using them as well. Today, wireless fleet management systems are used by just about everyone operating trucks. We have seen very small trucking companies with as few as five trucks using wireless fleet management systems. Qualcomm was one of the first and probably the largest service provider of truck telematics systems. As a result, truck telematics systems are often generically called a Qualcomm system. However, hundreds of different truck telematics systems are in use. Some of the more common truck telematics systems are:

1. PeopleNet

2. DriverTech

3. Teletrac

4. Dynafleet

5. Xdata

6. XataNet

7. MobileNet

8. FleetMatics

The capabilities of these truck telematics systems vary tremendously, but most are capable of reporting a real-time vehicle location, reporting a vehicle location history, performing driver-to-dispatch two-way text messaging, and performing turn-by-turn navigation. The more advanced systems display real-time truck onboard network sensor data, log historic truck onboard network sensor data, and snapshot truck onboard network sensor data.

As with cell phones, every truck telematic device will have a service provider. The truck telematic systems use cellular data networks, low-orbit satellites, and Wi-Fi to relay data to the service provider’s computer system where it can be viewed and accessed by the owner through a web portal. The truck telematic device is registered to the owner/service provider using the device’s Electronic Serial Number (ESN). ESN’s are required by the Federal Communications Commission on all mobile telecommunications devices. The device’s ESN is found on its manufacturer’s label and can be used to determine where its data is going.

Truck telematic systems have three main components: the human interface, the computer/transceiver, and the antennas.

The human interface is usually located near the driver’s seat and is commonly some type of electronic tablet or keyboard that is wired into the truck telematics system for communication. However, some of the newer systems use Bluetooth technology to connect to laptops, portable tablets, and even smart phones. Other systems connect to a Mobile Resource Management (MRM) enabled portable GPS such as a Garmin NIVI and use its screen as the human interface. New trucks may have the human interface permanently mounted in the factory dash assembly. Basic systems, however, may not have a human interface at all and simply collect and transmit data.

The computer/transceiver is a metal box that can be mounted in a variety of locations. Some of these are a complete PC computer with a large hard drive; others are just basic transceivers. Common locations for these devices are under the bed in a sleeper truck, on the back wall of a day-cab truck, under the dashboard, or under the B-pillar trim.

Truck telematics systems can have as many as four antennas. The system can have as many as three transmitter antennas including: one VHF satellite antenna, one cellular data antenna, and one Wi-Fi antenna. The system can also have a GPS receiver antenna. The VHF satellite antenna is a thin, metal radio-type antenna usually mounted on the back of the truck cab or on the roof. The cellular data antenna is usually a small black puck mounted on the inside of the windshield or on the roof of the truck. The Wi- Fi antenna is usually a small rubber or metal antenna mounted on the roof of the truck. GPS antennae historically have been a large white dome mounted on the roof or the back of the cab, but in modern systems are usually a small puck mounted in the same location.

A truck with a telematics system sometimes is easily identified by the exposed antennas and a human interface device. However, sometimes a truck’s telematic system is well hidden and can be very difficult to locate. The best method of locating one of these devices is to first locate one of its previously discussed components and then to follow the wires from that component until the computer/transceiver is located. Alternatively, since these systems require a 12-volt power source, their power wires can be located in one of the vehicle’s fuse boxes and traced back to the computer/transmitter. These systems can also be connected to the onboard network through the vehicle's factory wiring harness that can also be located and traced back to the computer/transceiver. Once the computer/transceiver is located, the manufacturer’s label identifying the systems ESN number can be found. The ESN number can be used to determine who is monitoring the system.

The amount of information wirelessly transmitted by truck telematic systems varies tremendously depending on the type of system. The transmitted data can be viewed by fleet managers in real time or historically in data logs or data snapshots. Data logs are continuous recordings of vehicle data at a preset time interval. Data snapshots log time windows of data after a vehicle behavior triggers an event recording. Common triggers for data snapshots in truck telematic systems can be hard brake events, hours of service violations, stability control events, speeding events, pressed emergency button events, excessive idle time events, and engine overspeed events. Both data logs and data snapshots will be stored on the service providers computer servers where the data can be accessed by fleet managers. Additionally, data snapshots are often sent by email to a fleet manager and can be viewed immediately following an event on his computer or smartphone.

Truck telematic systems could monitor and report all the following and more:

1. Vehicle GPS location 2. Vehicle speed 3. Hours of service 4. Active and historic DTCs 5. Cruise control active/inactive 6. Engine hours 7. Odometer miles 8. Fuel level 9. Oil level 10. Engine temperature 11. Time at full throttle 12. Engine idle time 13. Fuel economy 14. Engine overspeed 15. Time on brakes 16. Time in top gear 17. Following too closely 18. Approaching vehicle to fast

Truck telematic systems have a messaging function that allows drivers to communicate with fleet managers. Every time a load is assigned, a load is delivered, a truck is fueled, etc., a message is sent through the truck telematic system logging the truck’s location. These messages can be freeform or macros. Freeform messages allow driver and fleet managers to type anything into the message window. Macros are fill-in- the-blank message templates used for common activities and allow drivers and fleet managers to communicate with minimal typing. Some common activities that will use macro messages are.

1. Check call 2. Load assignment 3. Arrived at stop 4. Leave stop 5. Projected time available 6. Request for time off 7. Appointment time 8. Request for directions 9. Fuel stop 10. Arrive at consignee 11. Cargo delivered, empty

Electronic Log Systems

Truck telematic systems can be used to keep electronic logbooks in place of a hand-written log book. With these electronic log systems, the driver changes duty status by simply pushing a button on the truck telematic system screen for on-duty driving, on- duty not driving, sleeper-berth, or off duty. Some systems will have the driver select an activity from a pick list and change the driver’s duty status to the appropriate line for that activity. Electronic log systems can also automatically change the driver's duty status such as: when the parking brakes are released, the system may change the driver’s duty status to on-duty driving; or when the parking brakes are set, the electronic log system may change the driver’s duty status to on-duty not driving. Electronic log systems determine the miles driven each day and the average speed for the truck. They will calculate the driving and on-duty times that the driver has left and will automatically create a graph grid log that can be either viewed on the truck telematic systems screen or faxed to a law enforcement officer inspecting the truck.

Video Event Data Recorders

Digital Video Recorders (DVR) are becoming common in trucks. These systems can have one to 12 cameras mounted inside and/or outside the vehicle. Most systems will have one camera pointed toward the front and may have others pointed at the cabin, at the sides of the truck, or at the cargo area.

Some DVR systems record video continuously and others are event triggered. Systems that continuously record will often record video at a higher quality and lock the video from being overwritten when an event trigger occurs. Most DVR systems with event recording use an accelerometer sensor that senses impacts, hard stops, aggressive turns, and aggressive accelerations. These systems record GPS speed, GPS location, time and date, and can be connected to the truck's onboard network to collect network data. The video data can be accessed directly from an SD card or wirelessly transmitted through Wi-Fi or truck telematic systems.

Retrieving ECM HVEDR Data

ECM-based HVEDR data is part of an automotive diagnostic system and should only be accessed by an experienced and qualified automotive technician. However, for truck crash analysis, mechanical engineers and law enforcement officers with little or no automotive diagnostics training or automotive experience often attempt to access this data. Most heavy-duty truck diagnostics are preformed with PC software-based tools and use an interface/translator box to connect the PC to the truck's 6- or 9-pin Deutsch DLC. While some aftermarket diagnostic tools are available, the OEM tools, such as the Detroit Diesel Diagnostic Link (DDDL), the Caterpillar Electronic Tech (ET), the Cummins Power Spec/Insite, and the Bendix ACOM must be used to access the trip/event data.

After a crash, if the truck's battery and wiring harness have not been damaged, an experienced and qualified automotive technician can access the truck's diagnostic system (including incident data) through the truck's DLC usually located either under the driver's side dashboard or behind the driver's seat. If the truck is damaged and can't be powered up, ECM data can still be accessed by disconnecting the ECM from the truck's wiring harness and replacing it with a simulated wiring harness or a device called a re- programmer placed between the interface/translator box and the ECM.

HVEDR Data for Truck Crash Analysis

Crash reconstruction is the science of analyzing vehicle collisions using applied physics. A reconstruction analysis commonly relies on the study and interpretation of roadway and vehicle evidence and, when available, can also rely on the data collected from Heavy Vehicle Event Data Recorders (HVEDRs). Data from HVEDRs can be very valuable evidence. However, this data is not a substitute for a truck crash reconstruction, but can be used as supporting evidence in a crash reconstruction analysis. A truck crash reconstruction may include analysis of any or all of the following: (1) vehicle movements, (2) vehicle speeds, (3) vehicle impact angles, and (4) time-distance relationships of vehicles, etc.

HVEDR data cannot stand alone, and should only be used as a tool to analyze a truck crash, just as any other evidence, such as skid marks or vehicle damage would be used. Cavalier investigators often present this data at face value with no understanding of where the data is coming from or how the crash dynamics can affect it. However, the data must be analyzed in conjunction with other evidence to ensure its reliability. A truck crash reconstructionist must properly analyze and have an understanding of what the vehicle dynamics were prior to the collision, then he must determine whether the vehicle's pre-crash dynamics affected the recorded vehicle speed. He must also know that the vehicle speed data comes from a vehicle speed sensor (VSS) that effectively measures the rotation of the wheels and that wheel speed and vehicle speed are not always the same. For example, a truck that is rolling over with its tires off the ground, or sliding sideways, or braking hard, will have a wheel speed that is different than its forward speed. These factors have to be taken into consideration to correctly analyze the data.

Summary

1. HVEDR data can be useful for analyzing truck crashes.

2. HVEDR data comes from a myriad of electronic sensors and modules connected to a truck's on-board network.

3. HVEDRs are, for the most part, a software application that is contained in these modules.

4. Currently, HVEDR data mostly come from Engine Control Modules (ECM) and wireless fleet management systems.

5. A large variety of devices other than ECMs, which have an HVEDR function, are currently available, but identifying these HVEDR devices can sometimes be difficult.

6. With current on-board network technology, we predict an exponential increase in the types of data recorded by HVEDRs in the next few years.

7. Truck collision reconstructionists should have adequate automotive diagnostic training before trying to access or interpret HVEDR data.

8. Although HVEDR data can be valuable evidence from a truck crash, this data is not a substitute for truck crash reconstruction, but can be valuable analysis tool.

The author, John C. Glennon, Jr., is a forensic automotive technologist who performs crash reconstruction, vehicle failure analysis and detailed vehicle testing for trucking companies, insurance companies and lawyers involved in investigating and litigating motor vehicle collisions. He has a B.S.A.T. degree in Automotive Technology, he is a triple-certified Master Automotive Technician, and he holds a Class A CDL in the state of Kansas. For more information about the author go to www.crashforensics.com. The author, Dan C. Bahr, is a forensic automotive technologist who performs vehicle failure analysis and detailed vehicle testing for insurance companies and lawyers involved in investigating and litigating motor vehicle collisions. He has a B.S.A.T. degree in Automotive Technology, he is a certified Master Automotive Technician. For more information about the author go to www.crashforensics.com.