The ABCs of HVEDRs for Truck Crash Analysis Introduction Modern heavy-duty trucks 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 Airbag 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 Detroit Diesel 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 hours of service 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.