Publication date: 2024.10.25
Table of contents
- Technical report documentation page
- 1.0 Introduction
- 2.0 Background
- 3.0 HVEDR functionality
- 4.0 HVEDR data
- 5.0 HVEDR event triggers
- 6.0 HVEDR events
- 7.0 HVEDR current OEM ECU coverage
- 7.1 OEM trip computers
- 7.2 Other OEM data recorders
- 8.0 HVEDR access
- 9.0 HVEDR survivability
- 10.0 HVEDR data as evidence
- 11.0 HVEDR training
- 12.0 Best practices
- 13.0 Guidelines
- 14.0 Summary and path forward
- 15.0 Acknowledgements
- 16.0 References
- 17.0 Disclaimer
Technical report documentation page
- Report no.
T8080-210526 MSSC - Report date
March 31, 2023 - Published date
July 23, 2024 - Title and subtitle
Heavy Vehicle Event Data Recorders: Best Practices - Deliverables
Development of Heavy Vehicle Event Data Recorders: Best Practices - Performing Organization Code
- Author(s): Wesley Grimes, John Grindey, Bradley Higgins, John Isbister, John Kolter, Kristina Lombardi, Henry Ramirez, Henry Schmoker, and John Steiner of Mecanica Scientific Services Corporation
- Performing organization report no.
T8080-210526 MSSC - Performing organization name and address
Mecanica Scientific Services Corp
3051 Sturgis Rd
Oxnard, California 93030 - Work unit no.
- Contract no.
T8080-210526 - Sponsoring agency name and address
Transport Canada
Road Safety and Vehicle Regulations
330 Sparks Street
Ottawa, ON, Canada, K1A 0N5 - Type of report
- Sponsoring agency routing symbol
ASFCA - Collision Investigations and Research - Supplementary Notes
- Abstract
In May 2018, Mecanica Scientific Services Corp (Mecanica) submitted the initial Transport Canada T8080-160062 Feasibility Study of Event Data Recorders for Commercial Buses. Building upon this submission, the current T8080-210526 Heavy Vehicle Event Data Recorders: Best Practices (HVEDR Best Practices) aims to provide background information, research references and a summary of best practices and guidelines for event data recorders installed in medium- and heavy-duty trucks, motorcoaches, and buses. Transport Canada encourages vehicle manufacturers, Tier 1 suppliers of engines, transmissions, and vehicle safety systems, as well as service tool manufacturers to review and take advantage of this document when designing HVEDRs or developing service tools for HVEDRs.
The HVEDR Best Practices also serve as a comprehensive reference document for collision investigators, law enforcement agencies, government agencies, researchers, and fleet managers.
- Acknowledgements
The Mecanica Scientific research team would like to acknowledge and thank Lt. Timothy Austin, Mr. Timothy Cheek, Mr. Matt DiSogra, Mr. David Plant, and Mr. Greg Wilcoxson for their contributions, expertise, and guidance in this project. The team would like to acknowledge and thank the Mecanica Scientific Services team for their contribution in releasing this document. - Key Words
EDR, HVEDR, Event Data Recorder, Heavy Vehicle Event Data Recorders, bus, school bus, motorcoach, medium-duty vehicle, heavy-duty vehicle, straight truck, truck-tractor, SAE J2728, Recommended Practices, Guidelines - Distribution statement
- Security classification. (of this report) Unclassified
- Security classification. (of this page) Unclassified
- No. of Pages
- Price
1.0 Introduction
In heavy vehicles, the term “Heavy Vehicle Event Data Recorder (HVEDR)” is used to describe an electronic system that captures and records information related to an event during vehicle operation. The event may be a collision event, a sudden change in vehicle speed, a controlled or uncontrolled stop, or a fault detected in a monitored sensor. This real-time data collection encompasses details such as vehicle speed, throttle position, engine RPM, clutch status, brake status, the use of cruise control, the engagement of drivetrain retarders and various other operational parameters. The available data and its sources will depend on the truck’s model year and engine manufacturer.
The quantitative and objective information recorded by on-board systems is an invaluable resource for Original Equipment Manufacturers (OEMs) and Tier 1 Suppliers, collision investigators and law enforcement agencies, government agencies and researchers, as well as fleet managers.
OEMs and Tier 1 Suppliers can use HVEDR data to evaluate the performance characteristics of their products in real-world crashes. This data allows them to identify areas for improvement, enhance safety features, and refine vehicle designs to meet higher standards of safety and performance.
Collision investigators and law enforcement agencies can use HVEDR data as supporting evidence in a crash reconstruction analysis. This data has become increasingly important due to the integration of crash mitigation systems, such as Anti-Lock Brakes (ABS), Traction Control (TC), Electronic Stability Control (ESC), Automatic Emergency Braking (AEB), and Dynamic Steering with Lane Keeping Assist.
Government agencies and researchers can utilize amalgamated data originating from numerous HVEDRs as a valuable resource for comprehensive safety research and analysis. By discerning patterns and trends within accident data, strategies can be formulated aimed at diminishing accidents, enhancing road infrastructure, and refining vehicle safety systems.
Fleet managers can leverage HVEDR data to gain insights into driver behavior, vehicle maintenance needs, and compliance with regulations. This information can be used to provide real-time feedback and training to drivers, leading to safer driving practices and better overall fleet safety.
The data captured by these devices offer invaluable insights for diverse stakeholders. Ensuring the standardization of HVEDRs is important as it promotes consistency in the data collected from these devices. The Heavy Vehicle Event Data Recorders: Best Practices (HVEDR Best Practices) report provides detailed and comprehensive recommendations and guidance for the standardization and implementation of HVEDRs.
1.1 Purpose
In May 2018, Mecanica Scientific Services Corp. (Mecanica) published the initial Transport Canada T8080-160062 Feasibility Study of Event Data Recorders for Commercial Buses. This study examined the feasibility of introducing an HVEDR regulation for motorcoaches, buses, and school buses. It determined that there were no technical barriers to the implementation and standardization of HVEDRs.
The industry has moved in the direction of HVEDR standardization following the recommended practices outlined in SAE J2728, without the need for formal regulations. Since the model year 2000, the majority of commercial vehicle trucks and buses have been equipped with Original Equipment Manufacturer (OEM) HVEDRs that have the capability of recording extensive data. These OEM-supplied HVEDRs utilize factory-equipped ECUs, communication networks, and sensors.
While standardization has progressed, certain shortcomings persist. These include, but are not limited to, challenges in accessing HVEDR data, the dispersion of functionality across multiple ECUs, potential data loss due to fire or power loss, and the absence of a synchronized common time clock across all recorded data sources.
Transport Canada encourages Original Equipment Manufacturers (OEMs) to adopt the best practices and guidelines outlined in this report to address the existing inconsistencies of HVEDRs found in a vast majority of North American medium- and heavy-duty trucks and buses. This will ensure accurate, reliable, and consistent data and data collection practices across various vehicles and jurisdictions. Ultimately, this effort will lead to improved safety and advancements in the trucking and bus transportation industries. It is imperative for Original Equipment Manufacturers to effectively oversee the standardization of HVEDRs to ensure their successful implementation.
1.2 Scope
These best practices and guidelines primarily target Original Equipment Manufacturer (OEM) HVEDRs that are commonly found in vehicles categorized as Class 3 through 8, which weigh over 4,536 kg (10,000 lb.) and are equipped with either the SAE J1708/J1587 serial communications bus or the J1939 CAN communications bus. The specific OEM HVEDR functionalities covered by these best practices and guidelines are typically found within heavy truck or bus OEM Electronic Control Units (ECU) including:
- Engine ECU
- Chassis/cab ECU
- Safety system ECU
These best practices and guidelines will not address aftermarket fleet management technologies that consistently record data such as journey recorders, Electronic Logging Devices (ELD) for driver hours of service, GPS telematics devices, or Video Data Recorders (dashcams).
These aftermarket devices are installed by commercial fleets or owner-operators after they have taken delivery of their heavy truck or bus. These devices can range from simple off-the-shelf devices that internally store recorded data in their own memory to enterprise-level fleet devices that incorporate 4G, 5G, or LTE cellular connectivity, transmitting data to be stored in the cloud.
Development of these best practices and guidelines
The development of the HVEDR Best Practices involved a comprehensive process that incorporated extensive research and analysis of existing literature and technical reports. The guidelines were created through the following steps:
- Research and data collection: A thorough review of research papers, technical reports, and publications related to HVEDR technology was conducted. This research focused on various aspects such as data accuracy, reliability, limitations, and the impact of Event Data Recorders (EDR) and HVEDR on road safety and commercial fleet operations.
- Examination of regulatory activities: The guidelines took into account the current regulatory landscape specific to HVEDR and bus/motorcoach/school bus vehicles. The review included regulatory activities in the United States, as well as the European Union, concerning the installation of light-duty vehicle EDRs, as well as medium- and heavy-vehicle EDRs.
- Review of existing EDR and HVEDR recommended practices: This step involved evaluating established best practices such as SAE J1698 Event Data Recorders specific to light-duty motor vehicle Original Equipment applications and SAE J2728 Heavy Vehicle Event Data Recorders (JUNE 2020) specific to heavy-duty ground wheeled vehicles.
- Collaboration with industry experts: Experts in the field of HVEDR technology, commercial vehicle safety, and related areas were consulted during the development process. Their insights and expertise helped shape the guidelines and ensure their relevance and effectiveness.
Building upon the completion of this effort, Transport Canada, in collaboration with Mecanica, has included linked references in Appendix A of the HVEDR Best Practices. Furthermore, references from the initial publication of the Transport Canada Feasibility Study of Event Data Recorders for Commercial Buses published in May 2018 have been updated to include more recent studies, reports, and technological advancements. These updates can be accessed at Feasibility Study of Heavy Vehicle Event Data Recorders (HVEDR) website
Original Equipment Manufacturers (OEM) should review the HVEDR Best Practices report, along with the comprehensive collection of peer-reviewed technical studies provided in the 2018 Transport Canada Feasibility Study of Event Data Recorders for Commercial Buses. This wealth of information can serve as a valuable resource for OEMs to establish industry standards for HVEDR technology.
1.4 Intended use
The HVEDR Best Practices have been created with the purpose of offering a structured document that encompasses historical context, background information and an extensive compilation of research on HVEDRs. The HVEDR Best Practices provides recommendations and guidance pertaining to HVEDR for the following key stakeholders:
- Designers and manufacturers of medium- and heavy-duty trucks and buses
- Tier 1 suppliers of engines, transmissions, and heavy-duty vehicle safety systems
- Service tool manufacturers who could develop a common HVEDR data imaging (extraction) tool.
The HVEDR Best Practices also serve as a comprehensive reference document for the trucking and bus transportation industries operating medium-and heavy-duty trucks, motorcoaches, and buses equipped with an HVEDR. Furthermore, it provides valuable information to potential end-users who may need to access HVEDR data in the event of a highway crash or any other unusual vehicle incident requiring investigation. These end-users include government agencies, researchers, fleet managers, law enforcement agencies, and crash reconstructionist.
2.0 Background
2.1 Overall level of road safety in Canada
In 2020, Canada's population exceeded 38 million, and the country had nearly 26 million registered vehicles. Collisions involving these vehicles resulted in an estimated 104,286 injured victims and 1,746 fatalities. According to the National Collision DatabaseFootnote 1 (NCDB) maintained by Transport Canada, an average of 285 people were injured and 5 people died on Canadian roads every day.
In the National Safety CodeFootnote 2 for Motor Carriers, a heavy commercial vehicle is defined as: “…a truck, tractor, tractor-trailer, or combination thereof which exceeds a registered gross weight of 4,500 kilograms or a bus designed, constructed, and used for the transportation of passengers with a designated seating capacity of more than ten, including the driver, but excluding operation for personal use.”
Out of the 1,746 traffic fatalities that occurred in 2020, 317 (18.2%) involved a heavy commercial vehicle. The breakdown of these 317 fatalities is as follows; 212 (67%) were occupants of the other vehicle, 47 (15%) were occupants of the heavy commercial vehicle, and 58 (18%) were non-occupants. From 2011 to 2020, commercial vehicles represented approximately 9% of all vehicles involved in collisions, but they were involved in roughly 18% of all road user fatalities.
The percentages of fatally injured victims of collisions involving commercial vehicles by road user type from 2011 to 2020 are displayed below in Table 1. (Source: Road Safety in Canada 2020Footnote 3)
Year | Commercial vehicle occupants | Occupants of other vehicles | Pedestrians | Bicyclists |
---|---|---|---|---|
2011 | 15.7 | 69.6 | 12.6 | 2.1 |
2012 | 17.5 | 67.2 | 11.6 | 3.7 |
2013 | 16.3 | 66.7 | 12.6 | 4.4 |
2014 | 13.8 | 72.4 | 11.4 | 2.4 |
2015 | 11.5 | 76.5 | 10.2 | 1.8 |
2016 | 15.3 | 67.8 | 13.4 | 3.5 |
2017 | 16.9 | 68.5 | 11.9 | 2.7 |
2018 | 19.8 | 63.3 | 14.2 | 2.7 |
2019 | 12.9 | 70.6 | 13.7 | 2.8 |
2020 | 14.8 | 66.9 | 14.8 | 3.5 |
While there is no metric more important or valuable than the tragedy of the loss of life, it is not the sole measure by which the significance of commercial vehicle crashes can be quantified. The economic impact must also be considered. High-value loads, such as pharmaceuticals, medical supplies, electronics, automotive parts, chemicals, high-end fashion, and luxury goods, can be damaged or destroyed in commercial vehicle crashes, resulting in significant economic losses for the companies involved. Moreover, such crashes can disrupt supply chains and cause delays or cancellations of deliveries, which can have ripple effects throughout the economy.
Furthermore, certain types of commercial vehicle crashes, such as those involving hazardous materials or fuel, can cause extensive damage to infrastructure or the environment, resulting in expensive cleanup costs. Even in cases where there are no injuries or fatalities, the economic impact of such crashes can be significant.
In 2020, the social cost of Canadian motor vehicle collisions was estimated at approximately $36 billion, equivalent to around $99 million per day (in 2010 dollars). The social cost includes two major elements, human costs, and other costs. The human costs include the expenses associated with fatalities, disabilities, and non-disabling injuries, while the other costs include vehicle damage, health care, emergency vehicles, out-of-pocket expenses, and traffic delay.
Therefore, while the loss of life is certainly the most tragic consequence of commercial vehicle crashes, it is important to also consider the economic impact in order to fully understand their significance.
2.2 Technical drivers for HVEDR
To meet more stringent emissions requirements, truck tractors manufactured around the year 2000 may have been equipped with two to three Electronic Control Units (ECUs), 50 to 75 sensors, and a serial communications bus. In contrast, modern truck tractors manufactured today may have over twenty closed-loop Electronic Control Units (ECUs) and over a thousand sensors, relays, and gateways. These components operate on various public and proprietary high-speed CAN communications buses. The growth in the number of sensors and vehicle network complexity is shown in Figure 1 below.
Figure 1: Vehicle Data Items per Model YearFootnote 4.
HVEDR data triggered by an event or crash can be recorded, accessed, preserved, and analyzed to provide crash investigators with valuable insights into the moments leading up to, during, and following a crash. This data includes but is not limited to, driver input data such as accelerator pedal position, brake status, clutch application, and steering input data, as well as data on the operator’s use of systems such as cruise control and other speed control devices like engine brakes or retarders.
Heavy-duty trucks and buses are equipped with additional systems that drivers can leverage to enhance control and safety when operating these vehicles on mountainous roads. For example, engine brakes or drivetrain retarders can generate substantial retarding forces at the drive wheels, allowing commercial drivers to manage the speed of the vehicle while descending a mountain grade without relying solely on the foundational brakes. It is important to note, however, that using these retarders in adverse and slippery road conditions such as wet, snowy, or icy roads can potentially lead to the loss of vehicle control. Without HVEDRs, aside from relying on driver statements, there is currently no way to determine if the use of a retarder contributed to a crash.
One notable real-world example of a major crash involving a motorcoach is the December 21, 1999 motorcoach crash near Canon City, Colorado. This crash was investigated by the National Transportation Safety Board (NTSB). The crash occurred when a 1999 Setra motorcoach experienced a runaway situation while descending a mountain pass. As a result, the motorcoach veered off the road, rolled over, and led to 53 passengers being ejected from the vehicle. Tragically, two passengers lost their lives, and 51 others sustained injuries in the crash. The NTSB reported that their investigation team was able to access and image data from the 1999 Setra’s Detroit Diesel Series 60 DDEC IV Engine ECU and recover event data recorded as a result of this crash. The DDEC IV data indicated that an oversteer condition of the motorcoach was induced by the motorcoach operator’s improper use of drivetrain retarders (Jake Brakes) in slippery roadway conditions. Without the presence of an HVEDR on the 1999 Setra, there would not be a concrete and independent source of evidence to determine that the use of a system such as a drivetrain retarder was one of the primary causes of this crash. More details can be reviewed in the NTSB report, Motorcoach Run-Off-the-Road Near Canon City, Colorado, December 21, 1999, Highway Accident Brief NTSB/HAB-02/19 (Washington, DC: National Transportation Safety Board, 2002).
As vehicles become safer and are equipped with more advanced safety technologies such as Adaptive Cruise Control (ACC), Automatic Emergency Braking (AEB), Lane Departure Warning (LDW), Lane Keeping Assistance Systems (LKAS), “autopilot” cruise control with dynamic steering, data recorders are required to understand and segregate the functions and interventions of the vehicle from the actions (or inactions) of the operator. Additionally, as safety systems such as Anti-Lock Brakes (ABS) become more prolific, there may be limited or no physical evidence at a crash scene to document and analyze.
It is important to note that today, most EDRs or HVEDRs are unable to record whether the driver was actively controlling the vehicle or the automated driving system had intervened and was providing inputs to control the vehicle. To that end, the Data Storage System for Automated Driving (DSSAD) will record data to classify whether or not the driver was controlling the vehicle.
Those involved with the investigation and analysis of commercial vehicle crashes need to understand the available types of event data for commercial vehicles, how the data is generated, how to access the vehicle data, and how to apply it in a collision reconstruction event. Motor carrier managers, insurance adjusters, claim managers, and attorneys handling vehicle collision cases would also benefit from this knowledge. HVEDRs typically record vehicle speed, brake usage, and diagnostic trouble codes. Moreover, there is the potential for EDR and HVEDR to be leveraged and used to monitor and coach commercial vehicle drivers to improve fleet safety.
2.3 A historical perspective
Advancements in passenger vehicle passive occupant restraint systems and their electronic controls in the 1990s set the foundation for further development and acceptance of EDR in North America for passenger vehicles in Canada, the United States, and Mexico. Initially focused on light-duty vehicles, the functionality of EDRs has now extended to medium-and heavy-duty vehicles. This expansion was prompted by the shift of manufacturers of medium-and heavy-duty truck engines from traditional mechanical or electro-mechanical controls to solid-state electronic controls in response to the United States Environmental Protection Agency (EPA) 2002 requirements for lower diesel nitrous oxide (NOX) emissions. This transition allowed for improved engine performance and compliance with EPA emissions requirements. The adoption of electronic engine controls also led to the establishment of standardized on-vehicle serial communications protocols, followed by high-speed Controller Area Network (CAN) standardized communications protocols. These protocols defined the physical network (wiring), communications protocols, and messages within vehicles, laying the foundation for HVEDRs. In June 2010, SAE International published a Recommended Practice, J2728 “Heavy Vehicle Event Data Recorder, Tier 1,” which defined the HVEDR function in vehicles with a Gross Vehicle Weight Rating (GVWR) of 10,000 lb (4,536 kg) or more and equipped with a J1587 or J1939 communications data bus.
The interest in HVEDRs has grown due to their ability to record crucial data regarding vehicle dynamics and driver inputs for a short period of time just before and after a triggered event, typically due to a crash or a non-crash event. These recorded event data records provide valuable insights combined with physical evidence, enabling experts to conduct comprehensive vehicle crash reconstruction analysis. The integration of HVEDR data with reconstruction evidence also provides valuable information to enhance our understanding of safety system performance, potentially contributing to safer vehicle designs and more effective safety regulations.
The National Highway Traffic Safety Administration (NHTSA) established requirements for the voluntary installation of EDRs in light passenger vehicles through United States Regulation 49 CFR Part 563 in August 2006. Instead of mandating the installation of EDRs, NHTSA opted for a voluntary approach to encourage the development of this technology while minimizing costs for both manufacturers and consumers.
In January 2012, NHTSA published the final rule amending 49 CFR Part 563 for light passenger vehicles up to 3,856 kg (8,500 lb) gross vehicle weight rating (GVWR). The requirements apply only to light passenger vehicles manufactured on or after September 1, 2012.
In December 2012, NHTSA published a Notice of Proposed Rulemaking (NPRM) proposing to convert Part 563’s ‘‘if-installed’’ requirements for EDRs into a new Federal Motor Vehicle Safety Standard (FMVSS) mandating the installation of EDRs in most light passenger vehicles. At the time that NHTSA issued the NPRM, the agency estimated that about 92 percent of model year (MY) 2010 light vehicles had some EDR capability.
In February 2019, NHTSA withdrew the December 2012 NPRM because the agency determined that a mandate for the installation of EDRs on new light passenger vehicles was not necessary at that time. NHTSA’s internal analysis showed that, for Model Year (MY) 2017, 99.6 percent of new light vehicles sold already came equipped with EDRs that met the requirements of Part 563. This high installation rate demonstrated that the nearly universal installation of EDRs on new light passenger vehicles has been achieved without the need for a regulatory mandate.
In July 2022, NHTSA published a technical document titled, “Considerations for Regulating Installation and Performance of Heavy Vehicle Event Data Recorders (HVEDRs)" (Document ID NHTSA-2007-28793-0031). The main technical issues under consideration in the document include data element types to be captured, trigger mechanisms to capture data elements during a particular event, storage issues, survivability characteristics, and data extraction methods.
The NHTSA concluded that it was not yet ready to develop regulations for the HVEDRs, citing significant informational gaps in the areas of operator privacy, system costs, and data elements required for NHTSA crash analysis. Additionally, the agency noted that estimating the benefits of HVEDRs may be challenging, making it hard to justify the costs associated with mandating HVEDRs. NHTSA believes that as heavy vehicles adopt new crash avoidance technologies and Advanced Driver Assistance Systems (ADAS), the data availability and system cost considerations may change. Furthermore, NHTSA continues to research and to engage in international activities surrounding expanded data logging approaches and data recording triggers that may appropriately support analyses of incidents that could occur while emerging driving automation systems, including future Automated Driving Systems (ADS), are engaged. The NHTSA will continue to monitor the issues surrounding HVEDRs, related data standards, and emerging technologies and will revisit the possibility of developing a regulatory proposal at a future date.
In parallel to the work conducted to publish the voluntary U.S. federal rule on EDRs, the U.S. National Transportation Safety Board (NTSB) has played an active role in advocating for the implementation of EDRs. Since 1997, the NTSB has made numerous recommendations regarding the use of EDRs in vehicles. Additionally, the NTSB has hosted or participated in six public forums and issued eight formal reports that focused on the need for recorder technologies.
In 1999, the NTSB issued safety recommendations H-99-53Footnote 5 and H-99-54Footnote 6 to the National Highway Traffic Safety Administration to require EDR-type devices in motorcoaches and school buses. H-93-53 and H-93-54 have since been closed and in 2010 NTSB issued two new safety recommendations H-10-14 and H-10-15Footnote 7 which remain open to this date.
H-10-14: To the NHTSA - Develop and implement minimum performance standards for event data recorders for trucks with gross vehicle weight ratings over 10,000 pounds that address, at a minimum, the following elements: data parameters to be recorded; data sampling rates; duration of recorded event; standardized or universal data imaging interface; data storage format; and device and data survivability for crush, impact, fluid exposure and immersion, and thermal exposure. The standards should also require that the event data recorder be capable of capturing and preserving data in the case of a power interruption or loss, and of accommodating future requirements and technological advances, such as flashable and/or reprogrammable operating system software and/or firmware updates.
H-10-15: To the NHTSA - After establishing performance standards for event data recorders for trucks with gross vehicle weight ratings over 10,000 pounds, require that all such vehicles be equipped with event data recorders meeting the standards.
The European Union is following the lead of regulators in the United States. In 2022, a new UN Regulation (UN Regulation No. 160) was introduced to enhance information gathering about road crashes by requiring the installation of EDRs in passenger cars and vans. As of July 2022, the fitment of an EDR became mandatory for new types of passenger cars and vans, and by July 2024, it will be mandatory for all new cars and vans. EDRs for heavy trucks and buses will be introduced in 2029.
The automotive sector in other key countries has also taken the leap. In addition to the European Union, the United Kingdom, Japan, South Korea, and China, for example, are all actively working on EDR and HVEDR requirements.
3.0 HVEDR functionality
Light-duty vehicle Event Data Recorders (EDR) and Heavy Vehicle Event Data Recorders (HVEDR) are often compared to Flight Data Recorders (FDR) used in passenger aircraft, which are mandated by the United States Federal Aviation Administration (FAA) Part 121. However, there is not much in common between FDRs and EDRs/HVEDRs besides the general idea and concept of recording data.
The FDR and the Cockpit Voice Recorder (CVR) are purpose-designed and built with electronic data and audio recorders that independently monitor and record hundreds of channels of data. The data capture engine performance, flight control position, aircraft dynamics, pilot controls inputs, and cockpit audio recordings. These systems have their own dedicated wiring harnesses and power supply to monitor all aspects of the aircraft.
Unlike FDRs, HVEDRs rely on pre-existing sensors and data networks that are foundational to the vehicle’s operation. The data that can be captured, such as engine speed, vehicle speed, and accelerator pedal position data, is generated by sensors that transmit the data for the Engine/Powertrain Control Module to operate the engine and transmission. Similarly, the steering wheel input rate and position are monitored by a sensor that transmits the data to the vehicle’s Electronic Stability Control (ESC) system to monitor dynamic situations and assists the driver in maintaining control of the vehicle. The HVEDR algorithm itself monitors the vehicle’s sensors and determines when an event of interest has occurred and if that event should be recorded for subsequent imaging. The EDR function, responsible for capturing and recording data, is a function running within an Electronic Control Unit (ECU). This ECU, which contains the HVEDR functionality, also serves other primary functions related to the vehicle’s operation, such as engine protection, engine diagnostics, reduced maintenance, engine and road speed governing, fuel economy, emissions control, and other operational tasks. The EDR function is secondary in nature, designed to supplement the primary functions of the ECU.
In the case of a light-duty vehicle, the EDR function is typically integrated into the vehicle's Airbag Control Module (ACM). The primary role of the ACM is to detect crash events and determine whether to deploy various occupant protection systems such as seatbelt pre-tensioners, airbags, and active head restraints. As a result of deploying these occupant protection systems, the ACM can also capture and record data to memory within the ACM for access and imaging (download) after a collision event.
4.0 HVEDR data
It is important to understand the difference between the recording metrics and triggering protocols of light-duty vehicle EDRs and the triggering mechanics of HVEDRs in heavy-duty vehicles.
In the case of HVEDRs, they are typically triggered by a change in vehicle speed over a period of approximately one second as measured at either the wheel speed sensor(s) or the drivetrain mounted Vehicle Speed Sensor (VSS).
Historically, early HVEDR functionalities found in the late 1990s and early 2000s leveraged an older, now retired serial data bus network as defined by SAE J1708 (Serial Data Communications Between Microcomputer Systems in Heavy-Duty Vehicle Applications) and J1587 (Electronic Data Interchange Between Microcomputer Systems in Heavy-Duty Vehicle Applications).
Today, HVEDR functionalities are built on high-speed Controller Area Network (CAN) as defined by SAE J1939/13 (Serial Control and Communications Heavy Duty Vehicle Network) and ISO 15765:2011 (Road vehicles – Diagnostic communication over Controller Area Network (DoCAN)). Other standardized CAN networks as well as proprietary CAN networks can be used as well.
Some of the key sensors used as primary sources of recorded HVEDR data can include the following:
- Vehicle speed sensor (VSS) - the source of vehicle road speed
- Can be dedicated VSS mounted on the tail shaft of transmission and measures output shaft rotations
- Anti-lock brake system (ABS) wheel speed sensors can be leveraged. Either a singular sensor or, in most cases, two sensors on the same axle can be used and averaged
- Engine camshaft & crankshaft position sensors - the source of engine speed (RPM)
- Throttle position sensor (TPS) - Position of the accelerator pedal (in percent) as applied by the driver
- Brake switch - used to energize (or command) the activation of the brake lights on the exterior of the vehicle. Also used as a source of analog data for simple service brake applications (ON/OFF)
- Clutch switch - primarily used to disengage the cruise control system (if engaged) when the driver applies the clutch. Can provide analog clutch position (APPLIED/NOT APPLIED)
- Steering wheel position sensor - primary input to vehicle Electronic Stability Programming (ESP) functionality and provides steering wheel position in degrees positive and negative depending on the definition of values per the OEM or Tier 1 supplier.
Please note that this list is not exhaustive, as there are additional data elements captured by HVEDRs in trucks and buses today. For a complete list of data elements, it is recommended to refer to SAE J2728 (Heavy Vehicle Event Data Recorder Recommended Practice).
The primary concept here is that HVEDR functionality does not necessarily require the addition of new closed-loop Electronic Control Units (ECUs), networks, or sensors. Pre-existing systems on the vehicle can be utilized for HVEDR functionality, thereby minimizing the financial impact of incorporating such systems.
5.0 HVEDR event triggers
HVEDRs rely on changes in velocity (Delta-V) measured at either the drivetrain-mounted Vehicle Speed Sensor (VSS) or the wheel speeds sensor(s) as event triggers.
The different event triggers in HVEDRs can be categorized into two main types: acceleration triggers (hard brake / sudden deceleration / quick stop) and last stop triggers. Each heavy-duty vehicle manufacturer implements these event triggers to varying degrees. To promote consistency and standardization, there is a Recommended Practice document, SAE J2728 (Heavy Vehicle Event Data Recorder) that describes a common set of performance requirements for recording and storing data related to specific events that can occur during the operation of a heavy vehicle. According to SAE J2728, an HVEDR must save an event record if any of the following sets of conditions occur:
- Acceleration trigger - The HVEDR is triggered when the vehicle speed changes at a rate higher than the programmable threshold set between 8.0 km/h/s (5.0 mph/s, 7.3 fps/s) and 22.5 km/h/s (14.0 mph/s, 20.5 fps/s). This speed change can be positive or negative and must persist beyond the threshold for at least 0.5 seconds. The acceleration event starts at the time that the threshold is crossed. The recommended default threshold setting is 11.3 km/h/s (7.0 mph/s).
- Last stop trigger - The HVEDR is triggered when the vehicle speed falls below 3.0 km/h (1.9 mph) for 15 seconds or more. The last stop event starts at the time when the threshold is crossed. To prevent last-stop events from being overwritten due to the movement of the vehicle after an incident of interest, the last top trigger cannot reoccur until the vehicle speed reaches a speed of 24.0 km/h (14.9 mph) or more for a minimum of 6 seconds. Turning the ignition off will not directly trigger a last-stop event.
It is important to note that the defined acceleration trigger for HVEDRs of 8.0 km/h/s (5.0 mph/s, 7.3 fps/s) and 22.5 km/h/s (14.0 mph/s, 20.5 fps/s) is equivalent to a 0.23 g’s to 0.63 g’s braking. These values of braking to trigger an Acceleration Triggered HVEDR event have been found to work well for medium- and heavy-duty vehicles equipped with air brakes for their foundational braking system.
The acceleration trigger for HVEDRs of 0.23 g’s to 0.63 g’s braking applied to medium-duty vehicles equipped with hydraulic foundational brakes will be too sensitive and result in excessive false-positives being recorded. This could lead to excessive read-write cycles of the HVEDR’s host Electronic Control Unit (ECU) resulting in premature memory failures.
It is recommended that this topic be revisited by the SAE J2728 committee and that another solution for event triggers be considered for medium-duty vehicles equipped with hydraulic foundational brakes. This would be in addition to the current J2728 recommended practice that the acceleration trigger and last stop trigger apply to vehicles equipped with the SAE J1587/J1708 serial or J1939 CAN bus communications.
These events are triggered and captured differently among the various manufacturers. OEM HVEDR triggers, recording duration, and recording frequency are displayed below in Table 2.
Daimler Trucks North America Detroit Diesel/Mercedes-Benz |
Volvo Group North America (Mack, Volvo, Volvo Bus/Prevost) |
Caterpillar | |
---|---|---|---|
Engine/ modules | DDEC 16 (CPC04T) & Mercedes OM471 | Mack V-MAC IV+ Volvo Version 3 Controls | CAT C15 EPA 07; ADEM IV Module |
Year | 2016 to current | 2013 to current | 2010 |
Recording durations |
Hard Brake: 1 min (pre), 15 sec (post) Last Stop: 1 min 44 sec (pre),15 sec (post) |
Acceleration Triggered: 1 min (pre), 30 sec (post) Last Stop: 90 sec |
44 sec (pre), 15 sec (post) |
Recording frequency | 1 Hz | 4 Hz | 1 Hz |
Hard brake trigger | Factory set to 7 mph/s; Configurable by owner | +/- 10 mph/sec | Factory set to 7 mph/s; Configurable by owner |
Last stop trigger |
Vehicle speed changes from greater than 1.5 mph to less than 1.5 mph and is stopped for 15 sec. |
0 mph/s | N/A |
Trigger conditions |
Vehicle speed must be above 10 mph; will not trigger if preceded or followed by acceleration of more than 4 mph/s. | No trigger conditions for acceleration triggered events. Last Stop requires vehicle to exceed 5 km/hr (3.1 mph) for Last Stop to be written. | No special conditions. |
Navistar International | Cummins | PACCAR | Bendix | |
---|---|---|---|---|
Engine/ modules | Navistar A26 | X15 Engine; CM2350 | MX-11 Engine (EPA 2013) | EC-80 Module |
Year recording durations |
2018 to current 105 sec (pre), 15 sec (post) |
2017 to current 59 sec (pre), 15 sec (post) |
2010 to 2017 | 2011 and later |
5 sec (pre), 5 sec (post) |
10 sec (pre), 10 sec (post) |
|||
Recording frequency | 1 Hz | 1 Hz | 4 Hz | 2 Hz |
Hard brake trigger | 7.4 mph/s | 9 mph/sec | 8.95 mph/sec |
0.55 g triggers Bendix Data Recorder Log; 0.75 g triggers and locks. |
Last stop trigger | Vehicle comes to a stop and engine is shut down, or vehicle comes to a stop and engine remains idle for more than 2 min. | N/A | N/A | N/A |
Trigger conditions | Minimum vehicle speeds may be required; currently being determined. | 9 mph/sec default; most are not programmable. | N/A | When the magnitude of lateral and/or longitudinal acceleration exceeds 0.5g in any direction. (acceleration > 0.5 g); when vehicle speed is reduced by 6.9 mph or greater in 1 sec (Hard Brake); when there is a Wingman Advanced system brake intervention; when Active Cruise with Braking (ACB) is set, and the takeover alert (or impact alert) and driver are overriding the system. |
In addition to acceleration triggers and last-stop triggers, an externally triggered event provides the operator with the ability to initiate the recording process manually. This allows the operator of a heavy-duty vehicle to manually trigger an HVEDR event by pressing a switch or a set of switches on the instrument panel. The idea of an External Trigger HVEDR Event is not new and has been implemented by several chassis OEMs and engine suppliers. One notable example is Caterpillar, which introduced the ability for the operator to trigger an “External Snapshot” of data in their powered commercial vehicles as early as the late 1990s. In Caterpillar vehicles, the operator could trigger an External Snapshot by toggling the cruise control “SET/RESUME” three-position toggle switch from the “Center/Off" position to the “SET” position and then to the “RESUME” position within a one-second time period. This action would store a snapshot of data stored in Caterpillar’s Engine ECU’s memory that contained 13 seconds of engine data (9 seconds pre-trigger and 4 seconds post-trigger). The Caterpillar ECU was capable of storing the last four External Triggered Snapshots. Detailed information on Caterpillar’s External Trigger is depicted in Figure 2 below.
Figure 2: Caterpillar External Trigger Snapshots
Caterpillar incorporated is a leading manufacturer of diesel engines. The image on the left is the cover page of a Caterpillar instruction manual entitled, Programming Cat Electronic Truck Engines dated May 2005. The image on the right is page 170 of the Caterpillar manual indicating that in Caterpillar vehicles, the operator could trigger an external snapshot by toggling the cruise control “Set / Resume” three-position toggle switch from the “Center / Off" position to the “Set” position and then to the “Resume” position within a one-second time period. This action would store a snapshot of data stored in the Caterpillar’s Engine Electronic Control Unit’s memory that contained 13-seconds of engine data (9-seconds pre-trigger and 4-seconds post-trigger). The Caterpillar Electronic Control Unit was capable of storing the last four external triggered snapshots.
In addition to Caterpillar, other engine or chassis manufacturers, such as PACCAR and Cummins, have also implemented external trigger functionality in the past.
PACCAR introduced the Snapshot Recorder feature, which allowed the driver to manually trigger a recording event. Details on triggering the snapshot are available in the PACCAR diagnostics software (DAVIE4) and technical library (Engine Rapido). Three snapshot recorder events will be stored, containing 10 pre- and 5 seconds post-trigger.
Cummins Celect RoadRelay 4 and 5 dash-mounted trip computers allowed the operator to manually initiate the recording process by pushing a series of buttons to record the event.
6.0 HVEDR events
In today’s North American medium-duty and heavy-duty truck and bus market, significant quantities of event-specific and non-event-specific data can be found on the ECUs with the vehicle's respective diagnostics software for powertrain (engine and transmission), emissions, chassis, and safety systems controllers (anti-lock brakes, traction control, electronic stability control, ADAS). So what do we mean by event-specific and non-event-specific data? Data reports can be classified based on whether they are triggered to be recorded in response to a specific incident, condition, or event or whether they are continuously captured. These two categories of data are defined and explained further below.
An example of an event-specific record is a “Hard Brake Event'' triggered by a detected change in vehicle speed as measured at the drive wheels, as previously discussed. This event can result in a “Hard Brake Record'' being recorded by an ECU, as discussed in the HVEDR Event Triggers section. Another example of an event-specific record is a Diagnostic Trouble Code (DTC) that is recorded by the relevant ECU when a fault is detected with the CAN bus, a sensor or when a sensor detects that the monitored component or system is not within the manufacturer's pre-determined parameters. For instance, an out-of-range operating parameter could be the engine’s coolant temperature exceeding the maximum safe operating temperature because of an engine overheating condition. In addition to storing DTC data in the ECU’s memory for later imaging, the ECU also provides warnings to the operator by activating Malfunction Indicator Lamps (MILs), displaying electronic messages on the instrument panels’ digital displays, or emitting audible warnings.
Non-event-specific data encompasses various types of information, including programming parameters and trip data. A summary of event-specific and non-event-specific records is summarized in Table 3 below.
Non-event specific data | ||
---|---|---|
Data type (ECU) | description | notes |
Programming parameters (powertrain, emissions, cab/controls, safety systems) | Vehicle configuration settings, including road speed limiters, cruise control parameters, engine power settings, iesel injector calibrations, Vehicle Speed Sensor calibrations, lighting, cab control configurations, and many more | Some programming parameters such as Vehicle Speed Sensor calibration, tire size programming, rear axle ratio are foundational to validating HVEDR data. |
Diagnostics trends (powertrain, emissions, cab/controls, safety systems) | Normal operating parameters for various temperatures, pressures, and mechanical speeds of powertrain components. | Random snapshot data of normal operating parameters (when no active faults) to set a baseline of a healthy vehicle and used for predictive maintenance and repairs |
Trip data (powertrain) | Average vehicle speeds, engine speeds, engine load, gear usage, cruise control usage, and fuel economy data | May include maximum ever vehicle speed and engine speed data |
Histograms (powertrain) | Fuel burn histograms, Vehicle Speed vs. Engine Speed histograms | Average vehicle usage for improving fuel economy, reduce equipment abuse |
Event specific data | ||
Data type (ECU) | Description | Notes |
DTCs (powertrain, emissions, cab/controls, safety systems) | Specific event data surrounding system faults. | May also include DTC extended snapshot data |
DTC extended snapshot (powertrain, emissions, cab/controls, safety systems) | A snapshot of some or all operating parameters at the moment in time a DTC goes active. | May be a single snapshot recorded when DTC goes active, or it could be a snapshot with 2 to 60 seconds of data at a variety of reporting resolutions, depending on the OEM |
Last stop trigger (dependant on OEM) | Generally speaking, an event record triggered by the heavy vehicle coming to a stop. May or may not require the application of a parking brake or switching off of the ignition. | SAE J2728 recommended trigger |
Acceleration trigger (dependant on OEM) | Generally speaking, an event record triggered by a change in vehicle speed, typically 7 to 10 mph/sec, as measured at the tail shaft of the transmission or by one or more wheel speed sensors mounted on an axle end in the hub assembly. | SAE J2728 recommended trigger |
External trigger (dependant on OEM) | Generally speaking, an event record that is manually triggered by the vehicle operator via a dash-mounted switch. |
The data events summarized in Table 3 above are a general description of the non-event-specific and event-specific data records. The naming conventions of these general types of records vary from manufacturer to manufacturer.
7.0 HVEDR current OEM ECU coverage
Heavy Vehicle Event Data Recorders (HVEDR), as defined by SAE J2728, is a specific function for the purposes of crash investigations, crash reconstruction, and road safety research. It is important to note that an HVEDR could be found on a North American commercial truck or bus in the vehicle’s Original Equipment Manufacturer (OEM) Electronic Control Units (ECUs). The HVEDR function may also be found in an aftermarket device installed on a commercial truck or bus. These aftermarket devices could include GPS-based telematics devices or legacy Automatic On-Board Recording Devices (AOBRD,) which have now been replaced by Electronic Logging Devices (ELD). AOBRD and ELDs’ primary function is the electronic logging of commercial driver Hours Of Service (HOS). There are other digital data sources, such as commercial dashcam systems like Lytx, Nauto, Netradyne, SmartDrive, SmartWitness, and others.
Commercial trucks and busesFootnote 9 typically use diesel engines manufactured by Caterpillar, Cummins, Detroit Diesel, Mack, Mercedes Benz, Navistar, and Volvo. These engines have been designed and manufactured using OEM ECUs to control the engine's operation. The focus of these guidelines is placed on the HVEDR functions found within the commercial truck or bus OEM ECUs and require a laptop with the appropriate service software and an RP1210-compliant vehicle communications interface to be able to connect, communicate, and image (download) data from the OEM ECUs (Figure 3).
Figure 3: Cummins PowerSpec software connected laptop via J1939/13.
Commercial vehicles manufactured after 1998 may be equipped with HVEDR functionality in the vehicle’s Engine ECU. Figure 3 above shows a PC-based laptop running Cummins PowerSpec software connected to a truck tractor via the vehicle’s Deutsch 9-pin J1939/13 diagnostics link connector (DLC). Between1998 and 2007, there were typically three to four ECUs on a commercial truck or a bus. Typically, they were the Engine ECU, the Vehicle or Cab ECU, and the Anti-Lock Brakes/Traction Control ECU. For commercial trucks and buses equipped with Caterpillar, Cummins, Detroit Diesel, and Mercedes-Benz diesel engines, the HVEDR function was found in the Engine ECU. However, the Mack DataMax(R) HVEDR function would be present in the Vehicle ECU for Mack trucks during this same time period equipped with a Mack turbo-diesel engine.
Determining the availability of OEM HVEDR functionality in a commercial truck or bus goes beyond solely considering the vehicle’s model year, make, and model. For commercial vehicles, it is required that the model year, make, model, and installed engine make and model be known to determine what HVEDR functionality exists on the subject vehicle. Table 4 below summarizes the available HVEDR functions based on the engine installed in the commercial truck or bus.
Engine manufacturer | Data-recording capabilities |
---|---|
Detroit iesel |
Two Hard Brake Events (1998 – present) One Last Stop Event (1998 – present) Three Diagnostic Records (1998 – 2007 & 2010 – present) |
Mercedes-Benz |
Two Hard Brake Events (2000 – 2009) One Last Stop Event (2000 – 2009) Three Diagnostic Records (2000 – 2009) |
Cummins |
Three Sudden Deceleration Events (2005 – present) Fault Code Snapshots (1998 – present) |
Caterpillar |
Quick Stop Events (2007 – 2010)* Diagnostic Snapshots (1995 – 2010) External Triggers (1995 – 2010) * Quick Stops not enabled by default |
Mack |
One Acceleration Triggered Event (1998 – present) One Last Stop Event (2007 – present)** Fault Reporter (1998 – present) ** Prior to 2007, it was possible for Mack trucks to record two acceleration triggered events instead of one of each. |
Volvo |
One Acceleration Triggered Event (2011 – present) One Last Stop Event (2011 – present) Freeze Frames (2002 – present) |
International/Navistar Maxxforce |
Two Hard Brake Events (2010 – present) Two Last Stop Events (2010 – present) Freeze Frames (2010 – present) |
PACCAR |
Three Fast Stop Events (2008 – 2016) Freeze Frames (2008 – present) Fast Stop Recorder (2022 - ?) |
7.1 OEM trip computers
Commercial vehicles manufactured in the late 1990s and equipped with Detroit Diesel or Cummins engines did not come with built-in HVEDR capabilities in their Engine ECUs. However, these engine manufacturers offered an optional instrument-panel mounted trip computer that provided drivers with trip-related information such as travel time, distance traveled, fuel consumption, and fuel economy data. These instrument-panel mounted trip computers also included HVEDR functionality.
When investigating a crash involving an older truck equipped with a Detroit Diesel or Cummins engine, the crash investigator should inspect the instrument panel and the header above the windshield for the presence of trip computer devices.
Figures 4 through 6 below showcase examples of a Cummins RoadRelay trip computer in a 2012 Peterbilt truck.
Figure 4: Cummins RoadRelay5 trip computer
Figure 5: Cummins RoadRelay3 trip computer
Figure 6: Cummins RoadRelay3 trip computer Panic Stops Counter
The image depicts the Cummins RoadRelay trip computer installed in a 2012 Peterbilt truck instrument panel. The display of the RoadRelay device is indicating one recorded panic stop event.
Depending on the generation of Cummins RoadRelay, the trip computer can store between one to three Panic Stop events along with other information as is shown in Figure 7 below.
Figure 7: Cummins RoadRelay Device SummaryFootnote 10
The image depicts versions three, four and five of the Cummins RoadRelay trip computer. The RoadRelay3 can store one panic stop event and the RoadRelay4 and five can store three panic stop events. For event correlation, the RoadRelay3 uses trip mileage and trip hours and the RoadRelay4 and five use an internal real time clock. All the RoadRelay trip computers record trip reports and fault codes. The RoadRelay3 requires InRoads software, the RoadRelay4 requires Inform/Inspec or PowerSpec software and the RoadRelay5 requires PowerSpec software. The RoadRelay3 requires a hardware cable RS-232, the RoadRelay4 requires a through in cab diagnostic hardware connector or a direct to module through RoadRelay extraction harness part number 4003775 and the RoadRelay5 requires a through in cab diagnostic hardware connector. The RoadRelay3 uses solid state memory for data storage and the RoadRelay4 and five use random access memory for data storage.
RoadRelay3 devices can store one Panic Stop event, including 45 seconds Pre-Trigger data and 15 seconds Post-Trigger data reported at 1 Hz (1 data sample per second). The trigger threshold is programmable but is set to 9 mph/sec (14.5 km/h/s) by default.
RoadRelay4 and 5 devices can store the last three Panic Stop events, including 59 seconds Pre-Trigger data and 15 seconds Post-Trigger data reported at 1 Hz (1 data sample per second). The trigger threshold is programmable but is set to 9 mph/sec (14.5 km/h/s) by default.
Cummins HVEDR functionality is found in most Cummins Engine ECUs, starting with the model year 2007 engines. However, there are rare occurrences where newer trucks are still equipped with a Cummins RoadRelay4 or RoadRelay5 trip computer. In such cases, the Cummins Engine ECU and the RoadRelay trip computer will have HVEDR functionality.
For older vehicles equipped with a Detroit Diesel engine, the instrument panel and the header above the windshield should be inspected for a ProDriver(R) trip computer, as is shown in Figure 8 and Figure 9 below.
Figure 8: Detroit Diesel (Freightliner) ProDriver Trip Computer
The image depicts the Detroit Diesel Freightliner ProDriver trip computer. The ProDriver trip computer added HVEDR capabilities to the vehicle. The screen in the image indicates a system test release version three.
Figure 9: Detroit Diesel (Freightliner) ProDriver Trip Computer
The Detroit Diesel DDEC III generation of Detroit Diesel Engine Controls (DDEC) did not have HVEDR capabilities. However, adding the optional Detroit Diesel ProDriver trip computer added HVEDR capabilities to the vehicle it was installed in. The DDEC III series of controls were used on production engines from model years 1994 to 1997.
The DDEC IV generation of electronic controls was used in production engines from 1998 to 2003 and did include an HVDR function. This HVEDR functionality has been retained in all subsequent generations of DDEC controls up to the present day. After 1998, it was no longer necessary to have the Detroit Diesel ProDriver trip computer in order to have HVEDR capabilities in a vehicle. However, it is worth noting that there is a possibility that later Detroit Diesel-powered trucks equipped with DDEC IV or newer controls may still have a ProDriver trip computer installed. In such rare cases, HVEDR-type data would be available in both the Detroit Diesel DDEC Engine ECU and the ProDriver trip computer.
There are other older trip computers that one may encounter, such as a Western Star DataStar(R) Trip Computer (Figure 10) or a Caterpillar Messenger System Trip Computer (Figure 11).
Figure 10: Western Star DataStar System
The image depicts the Western Star DataStar trip computer. The DataStar device solely serves as a trip computer device, tracking trip distance, time, fuel consumption, and fuel economy. It does not possess heavy vehicle event data recorder functionality.
Figure 11: Caterpillar Messenger System
The image depicts the Caterpillar Messenger System trip computer. The Caterpillar Messenger device solely serves as a trip computer device, tracking trip distance, time, fuel consumption, and fuel economy. It does not possess heavy vehicle event data recorder functionality.
The Caterpillar CAT Messenger and WesternStar DataStar devices solely serve as trip computer devices, tracking trip distance, time, fuel consumption, and fuel economy. They do not possess HVEDR functionality.
Starting with (approximately) model year 2006, more advanced engine and emissions control systems were introduced to meet more stringent diesel emissions requirements as defined by the United States Environmental Protection Agency (EPA) 2007 [EPA2007] requirements. As the engine and emissions controls became more sophisticated, so did the OEM instrument panels, resulting in the discontinuation of the need for optional trip computers such as the Cummins RoadRelay or the Detroit Diesel ProDriver devices. These new emissions requirements were generally met by the introduction of emissions devices such as Diesel Particulate Filtration (DPF), which required many more sensors and processing power. To accommodate the demand for increased computer processing power, engine, and emission controls expanded from a single ECU to configurations with multiple ECUs. These newer vehicles still possess HVEDR capabilities. However, when a heavily damaged truck needs to be imaged (downloaded), the data imaging (download) protocol becomes more complicated.
7.2 Other OEM data recorders
Starting with the (approximate) 2016 model year, commercial trucks and buses that are equipped with Bendix Anti-Lock Brakes/Traction Control/Electronic Stability Control may also have a separate and independent HVEDR known as the Bendix Data Recorder (BDR). The BDR serves as an additional HVEDR alongside the HVEDR function found in the Engine ECU or the Vehicle ECU for vehicles previously discussed.
Also, starting with the (approximate) 2016 model year, commercial trucks and buses may be equipped with radar and camera-based Collision Mitigation Systems that include Adaptive Cruise Control (ACC), Front Automatic Emergency Braking (AEB), and Lane Departure Warning (LDW). These systems may also possess data recording capabilities.
Furthermore, many trucks have automated manual transmissions (AMT), which use electronic controls to operate the clutch and gears. These transmissions are equipped with electronic controllers that may also have data recording capabilities as part of their functionality.
8.0 HVEDR access
Multiple expensive OEM diagnostic software tools and hardware are required to image data from the various makes of heavy trucks or buses. Unlike the passenger car EDR, there is no universal tool that can access a vast majority of medium- or heavy-duty vehicles in North America.
When accessing data, both the SAE J1698 light-duty EDR standards committee and the SAE J2728 Heavy Vehicle Event Data Recorder Committee recommend using the term “imaging” instead of “downloading” to describe the process of copying data from an ECU’s physical memory chips. This terminology emphasizes a forensically neutral protocol that ensures data is copied without physically altering, deleting, or clearing those memory chips.
There are some processes of “downloading” data that are more invasive and may not preserve the original data as it resides on the physical memory chips. Some situations may require these more invasive techniques due to extensive damage to the heavy truck or bus or its ECUs.
In many cases, modern vehicles may have multiple HVEDR functions that can capture data, each requiring specific diagnostics software for access. For example, a 2021 Peterbilt 589 may have a PACCAR MX13 turbo-diesel engine, an Eaton RoadRanger Automated Manual Transmission (AMT), and Bendix ABS, with optional Bendix Wingman Fusion. All of these systems have the capability to record HVEDR events or extensive Diagnostics Trouble Code (DTC) related snapshot records and would require PACCAR Davie4 software, the Eaton ServiceRanger software, and Bendix Acom Pro software to be able to access, image, and preserve all available data. Failing to use all of these software tools could result in an investigator missing a key piece(s) of electronic evidence.
The most common diagnostic port on late-model medium- and heavy-duty vehicles is the SAE J1939-13 9-PIN (Deutsch) diagnostic port. There is an older Type I J1939 connector that is black, as is shown below in Figure 12.
Figure 12: SAE J1939-13 Type I9-pin Deutsch connector (black)
The newer, high-speed Type II J1939 Connector is green, as shown below in Figure 13.
Figure 13: SAE J1939-13 Type II9-pin Deutsch connector (green)
Mack and Volvo heavy-duty vehicles manufactured from 2014 onwards can be equipped with the light-duty vehicle OBD-II style diagnostic port.
A vehicle communications interface is required to physically connect a laptop to the heavy truck or bus to image data from that vehicle with the appropriate software. These interfaces are required not only for accessing HVEDR data but also for proper servicing, repairing, and configuration of these heavy-duty vehicles. They are designed to meet the TMC RP1210 Recommended PracticeFootnote 11.
The top three RP1210 medium- and heavy-duty vehicle communications interfaces are the NEXIQ USB-Link2 Device, the Noregon DLA 2.0 Device, and the Dearborn Group DPA5 Pro Device.
Some medium-duty trucks and related systems require the use of a specific OEM vehicle communications interface to be able to connect and communicate with certain medium-duty vehicles.
When an agency or organization lacks the necessary software, an RP1210-compliant device, or the training and experience to conduct data imaging on a commercial vehicle, they may seek assistance from a heavy-duty diesel repair shop or an authorized truck or bus dealership. These independent repair shops and dealerships typically have access to OEM service and diagnostics software, as well as the required hardware. They possess extensive knowledge and experience in working with a truck's electronic configuration and diagnostics data, including Diagnostic Trouble Codes (DTC), for the purposes of calibrating, configuring, repairing, and maintaining these vehicles. However, they will not have the expertise to understand and handle HVEDR data as physical evidence in a forensically neutral fashion.
HVEDRs possess unique characteristics that must be considered before accessing the stored data. For example, many Freightliner dealerships utilize the Detroit Diesel Diagnostics software to image and save HVEDR data from Detroit Diesel Engine Controls (DDEC). That software is configured by default to erase and reset event and trip data which can cause significant spoliation of evidence and raise concerns regarding the chain of custody.
Given these factors, HVEDR data must be handled only by experienced and qualified personnel. Using a repair shop or an authorized truck or bus dealership should only be considered a “last resort”, and careful consideration should be conducted to ensure that the personnel and procedures in place are capable of preserving the integrity of the data, maintaining the chain of custody, and adhering to legal requirements.
8.1 Specialized HVEDR imaging services
Currently, a limited number of HVEDR functions require the assistance of the specific manufacturer of the HVEDR to access, interpret and report the data. These manufacturers include Daimler Trucks, Mack Trucks, Volvo Bus, Prevost, Volvo Trucks, and Bendix Commercial Vehicle Safety Systems.
Trucks equipped with the Detroit Assurance Collision Mitigation System may have limited event data recorded by the system. This data can be accessed by trained personnel equipped with the Detroit Diesel Diagnostic Link software who has followed the outlined protocols recommended by Daimler Trucks North America and who has received clear and written permission from the owner of that particular truck. Alternatively, the hardware containing the data can be removed from the truck and sent to two authorized service providers specializing in imaging data from such systems. For more information, visit the HVEDR DTNA website.
To access HVEDR data on a Mack, Volvo truck, Volvo bus, or Prevost bus equipped with a Mack or a Volvo engine, a Mack/Volvo authorized service provider should be contacted, and more information is available at the MACK TRUCKS + VOLVO website:
To access data from certain Bendix EC-60 or EC-80 ABS ECUs or other Bendix systems, data or hardware must be sent to Bendix for data imaging, translation, and reporting. The raw HEX data can be imaged from the Bendix EC-60 or EC-80 using the Bendix Acom Pro Diagnostics Software. The resulting diagnostics file must be saved as a “.htm” web file or a “.logx” (Bendix proprietary service log file) and sent to Bendix either via email or on a USB thumb drive for data translation and reporting services. The latest release of the Request and Release of Bendix AutoVue Data Download form should be consulted for directions and guidance.
There are also provisions in Canada that require manufacturers to assist the government in retrieving and analyzing information created or recorded by a vehicle. In particular, all new motor vehicles manufactured or imported for sale in Canada must comply with regulations passed pursuant to the Motor Vehicle Safety Act. Section 8 of this Act references “Analytical aids,” which states:
“A company that applies a national safety mark to any vehicle or equipment, sells any vehicle or equipment to which a national safety mark has been applied or imports any vehicle or equipment of a class for which standards are prescribed shall, on the Minister’s request, provide the Minister with the means to retrieve or analyze information created or recorded by the vehicle or equipment.”
This provision is of significant importance as it empowers the government to effectively monitor and enforce safety standards for vehicles and equipment. By enabling the government to retrieve and analyze information recorded by the vehicle, they gain the necessary tools to identify and address potential safety issues, trends, or patterns.
8.2 Common tool needed
Standardizing HVEDR across OEMs necessitates a common tool so that government agencies, researchers, fleet managers, law enforcement agencies, and independent consultants do not have to purchase and train on multiple tools for imaging data from commercial trucks and buses.
An agency or organization may incur approximately $9,000 USD as an initial investment and recurring annual licensing fees for all the different truck diagnostic software available. In addition, they may need to spend an additional $1,000 on one of the limited TMC RP1210-compliant vehicle interfaces that can physically connect to the trucks. By establishing a common tool that can connect to all types of commercial trucks and buses, the cost of investing in hardware and software for imaging HVEDR data can be significantly reduced.
Furthermore, standardizing a common data imaging tool for HVEDR would greatly simplify training efforts. Currently, extensive time is required to train on the separate diagnostics software applications for different manufacturers, including Allison, Bendix, Caterpillar, Cummins, Detroit Diesel/Mercedes-Benz, Eaton, International/Navistar, PACCAR, Volvo/Mack, and WABCO.
The common EDR imaging tool widely used for light-duty passenger vehicles equipped with Part 563-compliant EDR functionality is the Crash Data Retrieval (CDR) Tool designed, built, and sold by Bosch Automotive Service Solutions, Inc., based in Santa Barbara, California, USA. The Bosch CDR Tool can access data from approximately 90% of vehicles equipped with EDR in the North American light-duty vehicle market. To ensure its effectiveness and compatibility, the CDR Tool receives regular manufacturer updates and incorporates input from CDR trainers at the annual BOSCH OEM Summit.
Currently, no single universal tool is compatible with most North American -market commercial truck and bus manufacturers. However, Synercon Technologies offers a solution called the Forensic Link Adapter (FLA). The FLA is a rugged computer designed to download HVEDR data from various manufacturers, including older Detroit Diesel, Mercedes, PACCAR MX, Navistar MaxxForce, and Caterpillar ECUs. Additionally, the FLA servesas an RP1210-compliant interface for communicating with OEM software. Communicating over the J1939 and J1708 networks, the Synercon Technologies detection algorithm scans the vehicle’s networks for engine-specific data, such as CAT Snapshots or DDEC hard brake event records. The FLA then securely images the data by encrypting it to ensure authenticity and integrity. With 16 GB of memory, the FLA can store data indefinitely until it is uploaded to, decoded, and displayed on the Synercon Technologies server. For more detailed information about the FLA and its capabilities, please visit the Synercon Technologies website.
The device may claim universality regarding its compatibility with multiple OEM ECUs. Still, it is important to note that its design did not involve direct input or proprietary contributions from the OEM manufacturers. While the device may work with various ECUs, the absence of manufacturer input may result in limitations or variations in compatibility and performance across different OEMs. It is recommended to consult with the device manufacturer or verify its compatibility with specific OEMs before relying on it for imaging data from commercial trucks and buses.
8.3 HVEDR data analysis & limitations
When reviewing the “digital” data from an HVEDR, it is crucial to validate its accuracy and relevance to the specific vehicle and incident being investigated. While this document does not cover every possible scenario or research paper on data validity, it emphasizes the importance of thorough vehicle component inspections, staying current with HVEDR training, and conducting relevant and necessary practical testing.
Some of the validation points that need to be analyzed are listed below. Failing to document and inspect these areas could result in an inaccurate application of the data.
- Chassis identification (VIN number, build date)
- Engine identification (engine serial number, engine model number, engine build date)
- Transmission and drive axle identification (serial numbers, ratios)
- Drive tires (model, size, load range, condition)
- ECU identification (ECU serial number, ECU model number, software version)
- Sensors (vehicle speed sensor, wheel speed sensors)
There are typically three foundational questions to answer when analyzing HVEDR data, and they are as follows:
- Establishing that the HVEDR data is from the subject vehicle;
- Establishing that the HVEDR data is from the subject crash or incident, and;
- Establishing the accuracy of the data.
In analyzing the HVEDR reported vehicle speed time history data, the most significant source of error in the reported vehicle speed is from wheel slip as a result of ABS intervention during braking that results in partial wheel lockup leading to a potential underreporting of the vehicle speeds in the range of 7 to 31.5%Footnote 12. The second most common source of error in the reported vehicle speed time history data is the calibration of the vehicle speed sensor. Typically, this may result in an error in the reported speed of less than +/- 2%Footnote 13. However, greater errors have been observed, especially with trucks that were purchased second or third-hand, and the truck configuration was changed from that which was originally built as a Class 8 truck-tractor for over-the-road long-distance operations and converted to a three-axle dump truck. A different model manual transmission, with a different gear ratio set, may be swapped out along with the rear axle ratio being swapped out for a much shorter rear axle ratio. If the Engine ECU is not reprogrammed to reflect these changes, the vehicle’s speedometer and any vehicle speed-time history data can have significant errors. Build records from the chassis manufacturer can be obtained to show what engine serial number and what other major components and their serial numbers were originally installed in that chassis when the vehicle was manufactured.
It is important to exercise caution when dealing with older vehicles, as there may be instances where the original engine or ECUs may have been replaced. This can lead to discrepancies between the engine data plates and the engine configuration.
In the case of older Detroit Diesel Series 60 engines, the engine valve cover is equipped with important identification plates containing EPA certification information, EPA engine family identification, build date, engine model, engine output, and engine serial number. It is important to note that these valve covers, being made of fiber-reinforced composite, can crack and break over time. If a used valve cover is purchased to replace the broken one, it is possible that the valve cover still retains the engine data plates from its original engine, which may not have been updated to reflect the current engine configuration.
Engine ECUs that become no longer serviceable due to internal faults with the circuit board can be replaced with used ECUs. However, it is important to note that replacing faulty ECUs with used ones may require some reprogramming to ensure proper functionality. This reprogramming typically involves matching horsepower output and entering calibration values for the diesel fuel injectors, among other adjustments. Other information, including chassis identification (VIN, Chassis No., Unit No.), might not be updated during this process. If the Vehicle Speed Sensor (VSS) calibration is not updated, the vehicle’s speedometer will be incorrect, and any data recorded by the HVEDR may also be incorrect.
Documentation of the truck or bus’s powertrain components, such as engine identification, transmission identification, drive axle identification, and drive tire identification, including make, model, load range, size, and condition is indeed crucial for validating and quantifying the accuracy of the recorded vehicle speed-time history.
It is important to conduct data imaging (download) of all available data, including odometers and hour meters, to stamp the HVEDR data.
For trucks with real-time clocks, it is important to synchronize the clock on the laptop being used to image data from the vehicle with an accurate time and date. To ensure accurate imaging of HVEDR data, it is recommended to set the laptop’s clock to Universal Coordinate Time (UTC) or ZULU Time to prevent introducing any further complications or confusion to the time correction by having to account for different time zones and Daylight Savings Time. Some vehicles can have limited clock functionality, or the internal real-time clock is so far off it may not be usable.
There may be specific data reporting issues for certain truck OEMs and model years that need to be considered when analyzing HVEDR data. For example, the “ON” status of Cruise Control in HVEDR reports may not always indicate that the Cruise Control system actively controls the vehicle speed. Instead, it may mean that the Cruise Control master switch is “ON'' and that the system is ready and armed. A constant vehicle speed with 0% accelerator pedal position and a variation in calculated engine load greater than zero would indicate that the cruise control is “ON” and actively maintaining the set vehicle speed.
Passenger vehicle EDR data is a valuable source of information that can provide accurate and reliable details about the timing, sequence of events, and actions taken leading up to a crash, as well as the performance of occupant protection systems during the crash. Analyzing passenger vehicle EDR data allows for easy correlation with the crash scene, including the actual point of impact (POI). Passenger vehicle EDR data is triggered by deploying occupant protection devices such as seatbelt pre-tensioners and airbags. Since these occupant protection devices are deployed during the early phases of a developing crash pulse, the trigger is typically the crash event.
However, this may not be the case for HVEDR data from a crash between a heavy-duty commercial truck or bus and a passenger vehicle due to the weight disparity between the two vehicles, as is shown in Figure 14 below. As discussed earlier in this document, event triggers on an HVEDR are based on a change in velocity as measured by the Vehicle Speed Sensor rather than a crash pulse detected by an accelerometer.
Figure 14: Light-duty vehicle vs. heavy-duty combination vehicle weight disparities
The image depicts the weight disparity between two vehicles traveling on a two lane, asphalt paved, rural highway. On the left side of the image is a passenger vehicle with a weight of 996 kg. On the right side of the image is a combination tractor trailer with a weight of 58,500 kg.
The trigger in a Hard Brake record recorded during a crash between a large tractor-trailer combination heavy-duty vehicle and a passenger vehicle may not necessarily correspond to the actual crash event or the crash pulse itself. The Hard Brake record could be triggered before the impact, during the crash event, or even after the crash event. For example, the Hard Brake record could be triggered before the impact if the truck driver or an ADAS initiates pre-crash braking in an attempt to avoid the collision. Alternatively, the event could be triggered at the onset of the crash event itself. There is also the possibility that the event is triggered after the crash event, either due to the truck driver braking after the impact or as a result of mechanical damage that causes the drive wheels to lock up and trigger the event without any braking input from the truck driver.
For this example, as well as many other scenarios, it is critical for a crash investigator who will be imaging (downloading) data from a commercial vehicle HVEDR to also conduct a traditional crash reconstruction investigation and analysis.
Completing a traditional investigative reconstruction allows the investigator to understand the sequence of events, compare the traditional crash reconstruction methodologies to the recorded HVEDR data, and validate the recorded HVEDR data. This approach is often called a situationally appropriate reconstruction.
There is a significant risk of data misinterpretation if the HVEDR data from a heavy-duty truck or bus is solely relied upon to analyze a crash event. As discussed in this document, there are data limitations and uncertainties associated with HVEDR (or EDR) data that make it insufficient to stand independently without considering physical evidence and traditional crash reconstruction methodologies that have been utilized and refined over the last 75 years.
To properly address and understand data limitations and the proper analysis of EDR and HVEDR data, continuing technical education on this technology is essential.
9.0 HVEDR survivability
The research team working on this document brings over 125 years of combined experience in accessing, preserving, and analyzing HVEDR data. Their extensive expertise has identified two primary situations where data cannot be imaged from an HVEDR in a heavy truck or bus involved in a highway crash. These situations are:
- Post-collision fires: In a post-collision fire, the intense heat and resulting damage can render the HVEDR and its data inaccessible for imaging.
- Electrical power loss: Electrical power loss can occur due to extensive damage to the heavy truck or bus, leading to the destruction of the vehicle’s main batteries or severe electrical system disruption. In some cases, the main battery cables may be pinched, grounded, or cut, resulting in a complete loss of electrical power.
For truck tractors, HVEDR functionality and data are typically located in Engine ECUs that are commonly mounted directly on the engine block or within the instrument panel in the truck’s cab. Similarly, for buses, the HVEDR and its data are typically found in the Engine ECU mounted directly to the engine block. In some cases, they may also be located in electrical panels situated in various areas of the bus, such as in the luggage compartments just forward of the drive axle, just aft of the steer axle, at the left front of the bus just outboard of the driver’s compartment, or somewhere inside the bus around the driver’s compartment.
Certain HVEDRs are designed to be more robust and less susceptible to data loss caused by electrical power loss. These HVEDRs have the capability to store 20, 30, or 90 seconds of pre-trigger data and will write the trigger data and post-trigger data to memory before they stop functioning in the event of a power loss.
However, it’s important to note that not all HVEDRs will store any data in the event of an electrical power loss. Some HVEDRs require specific conditions, such as a park brake application or an ignition key-off signal, to initiate data storage in memory.
In situations involving post-collision fires, heavy trucks and buses with ECUs containing the HVEDR function and the physical HVEDR data module installed on the engine side or within the instrument panel in the cab of the vehicle, are equally affected, as shown in Figures 15, 16, and 17.
Figure 15: Tractor-trailer consumed by post-collision fire
Figure 16: Tractor-trailer Engine ECU consumed by post-collision fire
Figure 17: Melted ECU on steering linkage
Addressing and designing solutions to avoid data loss due to post-collision fires or electrical power loss is indeed a topic that should be discussed among truck OEM and Tier 1 suppliers, potentially in forums such as the SAE J2728 Committee.
One simple solution to mitigate data loss in post-collision fires could be to identify an optimal physical location for the ECU on the truck or bus that minimizes the risk of damage in such incidents. Additionally, a more complex solution would involve considering the placement of the ECU on the chassis or cab along with the implementation of a more robust and heat-resistant exterior shell to protect against thermal damage.
For addressing the issue of electrical power loss, a simple solution could involve removing the requirement for specific conditions, such as applying the parking brake or an ignition key off signal, to write data to memory. By eliminating these requirements, at least a partial HVEDR record (either a Last Stop Record or an Acceleration Triggered Record) could be preserved up to the point of power loss.
A more complex solution to mitigate data loss due to electrical power loss would involve incorporating an electrical power backup system. This backup system could provide power to the HVEDR, allowing it to continue writing data even in the event of a complete loss of electrical power. However, it is recommended that even with electrical power backup, the requirement of a park brake application or an ignition key-off signal to write data to the HVEDR’s memory be removed to account for situations where the operator of the heavy truck or bus is incapacitated or unable to apply the parking brake or to switch the ignition key off.
It is worth noting that light-duty vehicle EDRs, which are embedded in the Airbag Control Module, benefit from backup electrical power systems designed into the occupant protection system controls. These systems typically use capacitors to provide backup DC voltage for a short period, typically ranging from 150 ms to 300ms, ensuring that the occupant protection systems, such as seatbelt pre-tensioners and airbags, can still function and deploy even if the vehicle’s electrical system is compromised. Overall, exploring and implementing solutions to prevent data loss in extreme events such as post-collision fires and electrical power loss can significantly enhance the reliability and completeness of HVEDR data, contributing to more accurate crash investigations and analysis.
10.0 HVEDR data as evidence
In Canada and the U.S., the ownership of the EDR/HVEDR and the generated data is generally vested in the vehicle owner. This means that the owner has the right to access and control the data recorded by the EDR/HVEDR. However, there are circumstances under which others, such as law enforcement, insurers, and opposing parties in civil litigation, may be granted access to this data.
In the case of law enforcement, they may obtain access to EDR/HVEDR data through a search warrant and use the information obtained as evidence in court. A Coroner’s warrant may be used to obtain access to EDR/HVEDR data in cases where no charges are being brought forward. The evidence obtained from the Coroner’s warrant cannot be used in judicial proceedings instituted by the police.
In insurance claims, policy owners have an obligation to give their insurer access to their collision-involved vehicle, including access to EDR/HVEDR data. This data may be used by insurers to determine fault and facilitate claims settlement.
In civil litigation, the opposing party may seek and be granted the right of access to EDR/HVEDR data as part of the discovery process. Although the EDR/HVEDR and the generated data may be "owned" by the vehicle owner, that data may be used as evidence against the owner or the vehicle's driver in either a civil or a criminal case.
It's worth noting that there may be some variation in laws and regulations between different jurisdictions, and some exceptions to the general rule of ownership of the EDR/HVEDR data may apply. It's important to consult local laws and regulations to understand the specifics of EDR/HVEDR data ownership and access in a particular jurisdiction.
Imaging HVEDRs requires specialized skills and training, and it is important to work with qualified professionals familiar with the equipment and procedures. When imaging HVEDR data, it is important to follow proper photo and video documentation protocols. This includes taking photos or videos of the HVEDR's location on the vehicle and capturing images of the HVEDR itself along with any labels, serial numbers, or other identifying information. Additionally, recording the laptop screen using a Windows-compatible screen capture application can be a helpful way to document the process of imaging HVEDR data.
It is recommended to save the HVEDR data in both its native format and a more accessible format, such as a PDF file. The native HVEDR files typically require specialized diagnostic software, which can be expensive to open. For example, the Cummins Insite diagnostic software is required to view a Cummins Engine Work Order, and the DDEC Reports software is needed to view the Detroit Diesel Electronic Controls (DDEC) file containing the Hard Brake Records and Last Stop Records. By saving a copy of the data in a PDF format, the data can be easily opened and viewed using the free Adobe Acrobat Reader software, which is widely available.
When dealing with heavily damaged vehicles that require the removal of the HVEDR, special precautions should be taken to handle the electronic components to prevent damage or data loss. Before removing electronic components, it is important to disconnect and isolate the vehicle’s main batteries. Once the electronic components are removed, it is recommended to store the ECUs in protective electronic anti-static bags. These bags are designed to prevent static electricity from damaging any sensitive components during handling and storage. However, this is applicable only if the electronic devices are not wet, exposed to moisture, or have been submerged. If the electronic devices have been submerged or drenched from firefighting activity, the devices should be wrapped in paper and stored in breathable cardboard boxes. These boxes should be properly labeled and sealed after removing the components to prevent any damage, contamination, or data loss.
The removal process should be thoroughly documented in a step-by-step, time-sequential manner, with photographs, and if necessary, video.The removed components should be photographed from all sides, with special attention paid to identifying labels and the electrical connector pins. The locations from where the components were removed should also be documented with photographs to illustrate that the components were indeed taken out of the vehicle. Additionally, it is recommended to photograph or record video of the removed component alongside the vehicle certification label, VIN, or any other identifying feature that confirms its origin from the specific vehicle. Using a permanent marker, the VIN of the vehicle, date, and the name or initials of the personnel removing the component should be written on the component itself. Ensure photographs and/or video of this portion of the documentation is also recorded.
Boxes containing the components should be sealed and if they are to be shipped, an appropriate carrier should be used, and all tracking information should be documented and placed in case files.
Entities involved in removing components should have established evidence-tracking procedures, forms, software, and protocols to ensure that evidence is properly documented, tracked, and stored. This should include the assignment of case and evidence numbers that can be documented. Every person having access to the component, whether for examination, shipping, or safekeeping, should be required to attach their name, date, time, and reason for handling the components. All removed components should be stored in a secure facility, with restricted access granted only to designated personnel. When opening containers containing modules removed from a vehicle, the opening process should be documented, as well as the personnel opening the containers.
With the HVEDR removed from the vehicle, it may be necessary to use a truck simulator or other special hardware to image the HVEDR. Extracting the data using such tools can be a complex process, and it is important to adhere to proper procedures to ensure accurate and reliable extractions. Off-vehicle data imaging should be documented as if the components were still located in the vehicle. It is recommended to create a step-by-step, time-sequential recording of the data imaging process, documenting each stage of the procedure.
In the context of EDR/HVEDR data, the chain of custody documentation should include details such as the date and time of the data extraction, the identity of the person or persons who extracted the data, and the specific equipment and software used to extract the data. This documentation should be carefully maintained and preserved to ensure the data can be used as evidence in court if necessary.
Maintaining a complete and verifiable chain of custody is crucial for ensuring the integrity and reliability of evidence in legal proceedings. By documenting the possession and handling of the evidence, the chain of custody provides a clear record of who had control over the evidence and when, establishing its authenticity and preventing tampering or alteration.
Failure to maintain a complete and reliable chain of custody can have serious consequences. It may lead to challenges regarding the integrity of the evidence, resulting in case dismissal or adverse court sanctions. Without a properly documented chain of custody, the credibility and reliability of the evidence can be called into question, potentially jeopardizing the outcome of the case.
11.0 HVEDR training
Over the years, there has been a significant increase in the adoption of HVEDRs in the heavy-duty truck and bus market in North America. Remarkably, this growth has occurred despite the absence of regulations mandating their installation on vehicles in Canada, the United States, or Mexico. The driving force behind this surge in demand is the need for data by commercial truck and bus fleets. The technology applied to heavy trucks and buses follow a similar pattern to that of passenger vehicle EDRs, wherein pre-existing sensors, vehicle data networks, and ECUs are utilized to incorporate an HVEDR functionality. This approach eliminates the need for additional sensors, wiring, or ECUs, resulting in a more cost-effective solution for fleet operators. By leveraging existing systems, the HVEDR can capture and record crucial data without requiring extensive modifications to the vehicle’s infrastructure.
As outlined in this document, the HVEDR function is integrated into ECUs and sensors that serve primary functions related to the safe, clean, and efficient operation of the turbo-diesel engine and drivetrain. Additionally, they contribute to the operation of various vehicle systems such as the Anti-Lock Braking, Traction Control, Electronic Stability Control, and ADAS.
Since the HVEDR is a function that is added to an ECU with other primary functions, it could be likened to adding an app to your mobile smartphone. The HVEDR leverages existing sensors and data, capturing information from those sensors when triggered.
Because the HVEDR, like the EDR, relies on other vehicle systems, it is essential to have proper training and understanding of those foundational systems, controls, sensors, and vehicle data networks. This knowledge is crucial in understanding HVEDR data and determining the capabilities and limitations of using HVEDR data for analysis and interpretation.
There are currently several established training programs on HVEDRs in the United States. Several authors of this document have extensive experience as instructors for two specific courses, which are listed below. It is important to note that the training references provided in this document reflect the data published on the linked web pages at the time of writing. However, please be aware that this information may no longer be accurate or available.
11.1 Forensic training group, LLP
Forensic Training Group, LLP, in Tennessee has training courses tailored for law enforcement officers and crash reconstructionists. Their courses include topics such as Heavy Truck Reconstruction Techniques, Heavy Vehicle Event Data Recorder (HVEDR) Use in Traffic Crash Investigation Analyst Training, and the use of the Synercon Technologies Forensic Link Adapter (FLA) and TruckCRYPT Software. The instructors are Mr. Tony Becker, Mr. Scott Skinner, Mr. James Loftis, Mr. Steve Anderson, and Mr. Jason Riddle. More information is available on the Forensic Training Group, LLP webpage.
11.2 Institute of Police Technology & Management
The Institute of Police Technology & Management (IPTM) offers a course on HVEDR that is the Heavy Vehicle Electronic Control Module Data Use in Crash Reconstruction course. This course offered by IPTM is a 40-hour, 5-day course with a current registration fee of $1,195.00 USD. More information is available on the IPTM website.
11.3 Northwestern University, Center for Public Safety
Northwestern University’s Center for Public Safety covers some of the basic information on HVEDRs in their Heavy Vehicle Crash Reconstruction Course. This course has a current tuition fee of $600.00 USD and requires the successful completion of Northwestern’s Traffic Crash Reconstruction Courses 1 and 2. More information is available at Northwestern University’s Center for Public Safety website
11.4 SAE International
Since 2010, SAE has offered a continuing education technical training program on HVEDRs. It is the SAE course Accessing and Interpreting Heavy Vehicle Event Data Recorders (Course ID C1022). This course was originally developed and taught by Mr. Timothy Cheek of DELTA |v| Forensic Engineering, Inc. (Charlotte, NC) and Mr. John Steiner of Mecanica Scientific Services Corporation (Oxnard, CA). Since 2010, the course has grown and has been refined to keep up with the fast-paced changing technologies in heavy trucks and buses that are the foundation of HVEDR. The SAE C1022 course covers the foundational systems of HVEDR and the characteristics and traits of each HVEDR function found in the various engine ECUs and safety systems ECUs. The class also reviews numerous case studies and the fundamentals to analyze HVEDR data in crash reconstruction. Today, this class is taught by Mr. Timothy Austin, Mr. Timothy Cheek, Mr. Matt DiSogra, Mr. Wesley Grimes, Mr. Bradley Higgins, Mr. David Plant, Mr. John Steiner, and Mr. Greg Wilcoxson. The C1022 class is a four-and-a-half-day course and registration fees currently are $2,499.00 USD.
In 2019, Mr. Wesley Grimes and Mr. Gregory Wilcoxson organized and started teaching a continuing education technical class that is a follow-on class to the C1022 class. This is the SAE Course, Advanced Applications of Heavy Vehicle EDR Data (Course ID C1901). The C1901 course is a two-day course that is a deeper dive into numerical methods and advanced analysis methodologies for HVEDR data and is taken upon the successful completion of the C1022 course. This course has a current tuition fee of $1,349.00 USD. More information on the SAE Course No. C1022, Accessing and Interpreting Heavy Vehicle Event Data Recorders is available on the SAE website. More information on the SAE Course No. C1901, Advanced Applications of Heavy Vehicle EDR Data is available on the SAE website.
12.0 Best practices
The SAE J2728 Recommended Practice (RP) document applies to Heavy Vehicle Event Data Recorders (HVEDR) for heavy duty (HD) ground wheeled vehicles over 4,545 kg (10,000 US pounds) commonly referred to as Class 3-8 vehicles. SAE J2728 was developed through the SAE Truck and Bus Event Data Recorder Committee and first published in 2010. In 2020 a revised version of SAE J2728 was published.
As stated in the Recommended Practice (RP) SAE J2728-1:
Scope: This document provides a list of data elements and event triggers for the recording of event data relevant to crash investigations for heavy vehicles. The list of data elements includes recommended source(s) and formatting.
Purpose: This document provides design and performance recommendations needed to develop an HVEDR with minimum capabilities. It is not intended to prevent, constrain, or limit additional capabilities which could be combined or contained in any current or future HVEDR as long as the minimum design and performance capabilities described herein are maintained.
12.1 SAE J2728-1 HVEDR event triggers
As stated in SAE J2728-1:
The event trigger is a set of criteria which, if met, cause an HVEDR event record to be saved to non-volatile memory. The HVEDR should save an event record if any of the following sets of conditions occur:
- Acceleration trigger: Vehicle speed changes at a rate higher than the programmable threshold set between 8.0 km/h/s (5.0 mph/s) and 22.5 km/h/s (14.0 mph/s). The vehicle speed change can be either positive or negative and persists beyond that threshold for at least 0.5 seconds. The acceleration event start will be the time that the threshold is crossed. A common threshold setting is 11.3 km/h/s (7.0 mph/s).
- Last stop trigger: This trigger intends to capture an event when the vehicle has come to a complete stop for a period of time. The last stop event start will be the time the threshold is crossed. A suggested threshold is when the vehicle speed falls below 3.0 km/h (1.9 mph) for 15 seconds or more. To prevent last-stop events from being overwritten due to the movement of the vehicle after an incident of interest, the last-stop trigger cannot reoccur until the vehicle speed reaches a speed of 24.0 km/h (14.9 mph) or more for a minimum of 6 seconds. Turning the ignition off will not directly trigger a last-stop event.
- Safety system trigger: Systems that are installed for control or driver alerts from safety systems should trigger an event record. (Recommended trigger signals from known systems are listed in Table 1 of the RP and include Safety Restraint System, ABS System, Adaptive Cruise Control/Automated Braking, and Electronic Stability Control).
The recommended default 11.3 km/h/s (7.0 mph/s) acceleration trigger is specified for typical on-highway heavy truck applications. Recognizing that other vehicle configurations, applications, or vocations may require adjustment to the event trigger vehicle speed rate of change, the rate may be programmable within the range per the above specifications.
Original Equipment Manufacturers (OEMs) should implement the event triggers outlined in SAE J2728-1 as a baseline. Additionally, OEMs are encouraged to consider incorporating additional event triggers relevant to their specific vehicle systems, safety features, and control mechanisms to enhance the capabilities of the HVEDR.
12.2 SAE J2728-1 HVEDR data elements
SAE J2728-1 presents a comprehensive list of standardized data elements categorized into two groups: Header Data and Data Element Buffers. The Header Data comprises elements that assist in identifying the event’s time and location, along with mostly static vehicle states at the time of the event (such as engine hours, odometer, rear axle ratio, VIN, etc.). On the other hand, Data Element Buffers include pre-trigger data and post-trigger data, allowing for an examination of the vehicle’s operation leading up to the event trigger and for a period after the trigger (including vehicle speed, brake status, engine speed, clutch switch, accelerator pedal position, etc.).
As stated in J2728-1:
The data elements listed in this recommended practice are only relevant if the vehicle is equipped with the associated sensor and/or vehicle system and their status is available to the HVEDR. While the HVEDR manufacturer can determine which data elements are applicable to their system, manufacturers are referred to Table 2 of the J2728-1 document for a list of recommended data elements as a minimum. Users of this recommended practice may include data elements beyond those listed in Table 2. It is recommended to use SAE J1939-71 as a reference for formatting the data elements where applicable.
Original Equipment Manufacturers (OEMs) should incorporate the data elements from Table 2 of the J2728-1 document as a minimum requirement, where they apply, and as much as possible, while also considering including additional data elements beyond the recommended list.
12.3 SAE J2728-1 HVEDR data sampling rate and recording duration
As stated in J2728-1:
The HVEDR must record data collected before and after the event trigger threshold is reached. For this reason, a pre-trigger data buffer must continuously be writing to volatile memory all required data elements that are available before an event record is triggered (i.e., event trigger criteria being met) in a continuously updating, first-in-first-out circular buffer. Similarly, the instant an event trigger is reached, the HVEDR should immediately store the remainder of the record of required HVEDR data elements for the remainder of the event as defined. By default, the HVEDR must provide a minimum pre-event capacity of 15 seconds, with data written at a 10 Hz rate and a minimum post-event trigger capacity of 15 seconds, for a minimum of 30 seconds of event-related data. The minimum pre- and post-event capacity is not intended to preclude devices with greater capacity.
Original Equipment Manufacturers (OEMs) should ensure that their HVEDRs adhere to the minimum requirements outlined for data sampling rate and recording duration. It is important to note that while meeting the minimum requirements is essential, manufacturers are encouraged to develop HVEDRs with greater capacities to provide enhanced data capture capabilities.
Best practices
SAE J2728-1 HVEDR event triggers
OEMs should implement the event triggers outlined in SAE J2728-1 as a baseline. Additionally, OEMs are encouraged to consider incorporating additional event triggers relevant to their specific vehicle systems, safety features, and control mechanisms to enhance the capabilities of the HVEDR.
SAE J2728-1 HVEDR data elements
OEMs should incorporate the data elements from Table 2 of the J2728-1 document as a minimum requirement, where they apply, and as much as possible, while also considering including additional data elements beyond the recommended list.
SAE J2728-1 HVEDR data sampling rate and recording duration
OEMs should ensure that their HVEDRs adhere to the minimum requirements outlined for data sampling rate and recording duration. It is important to note that while meeting the minimum requirements is essential, manufacturers are encouraged to develop HVEDRs with greater capacities to provide enhanced data capture capabilities.
13.0 Guidelines
13.1 HVEDR access
The functionality of HVEDRs is optimized for the specific vehicle they are installed in, and retrieving data depends on the engine manufacturer. Unlike passenger car EDRs, there is no universally compatible tool for data retrieval from HVEDRs across most manufacturers. The process requires multiple expensive OEM diagnostic software tools and hardware.
To address this issue and to simplify data access, there is a need to standardize HVEDRs across Original Equipment Manufacturers (OEMs). This would ensure that a common tool can be used to access data from commercial trucks and buses.
By standardizing HVEDRs, a common tool can be developed that would enable government agencies, researchers, fleet managers, law enforcement agencies, and independent consultants to access data from commercial trucks and buses without the need for multiple tools and training.
Given the expertise of commercial vehicle chassis manufacturers in-vehicle electronic architecture and integration, and the knowledge possessed by commercial vehicle engine and safety system manufacturers regarding functional requirements and implementation issues of HVEDRs, collaboration between OEMs and OEM-approved third-party diagnostic tool providers is encouraged.
This collaboration can lead to the development of a standardized imaging tool specifically designed for HVEDRs, making data access more efficient and accessible across different commercial vehicle manufacturers.
13.2 HVEDR functionality across multiple OEM ECUs
In the past, HVEDR functionality was primarily found in the Engine Electronic Control Unit (ECU) of commercial trucks or buses. This ECU is responsible for various core operational functions such as engine protection, engine diagnostics, fuel economy, emissions control, and speed governing. However, with technological advancements, HVEDR-type data can now also be found in other ECUs, associated with systems like Antilock Braking and Stability Control, Collision Warning and Active Braking, Lane Departure, and Automated Transmission.
Standardizing HVEDR through an OEM-based solution must consider the variations in HVEDR functionality across different ECUs. The goal of standardization should not dictate where manufacturers choose to store the data but should aim to prevent the dispersal of HVEDR data across multiple ECUs. Ideally, recording all data to a single ECU is preferable. This single ECU could be accessed either through the preferred connection method, that is, the diagnostic link connector (DLC) defined by J1939/13 on a heavy truck, or directly to that ECU in the event the vehicle sustains significant damage preventing connection via the DLC.
It's important to note that, like passenger-vehicle EDRs, HVEDR is a programming algorithm executed on an existing ECU with a processor (or processors) and internal memory. The HVEDR is not an additional or stand-alone data recorder with its own network of sensors.
To facilitate standardization, OEMs are encouraged to develop a programming algorithm that consolidates HVEDR-type data to a single ECU. This approach can streamline data collection and retrieval processes, making it easier to access comprehensive HVEDR data from commercial trucks and buses.
13.3 HVEDR survivability - electrical power loss
When a vehicle experiences extensive damage that crushes or destroys its main batteries, or when the main battery cables are pinched, grounded, or cut, electrical power loss can occur, leading to the inability to record data. This complete electrical power loss typically happens in severe situations.
The survivability of HVEDR data during electrical power loss varies depending on the specific device. Some HVEDRs are designed to be more robust and less susceptible to data loss in such scenarios. Some HVEDRs have the capability to store 20, 30, or 90 seconds of pre-trigger data. In the event of power loss, these HVEDRs will write the trigger data and post-trigger data to memory before ceasing operation. In contrast, certain HVEDRs will not write any data if an electrical power loss occurs because the HVEDRs require a park brake application or an ignition key-off signal to store data in memory.
To ensure the capture of vital crash data, having a backup power reserve is crucial. Relying on an external power source can present challenges if the structural integrity around the HVEDR is compromised. However, HVEDRs with internal backup power sources, such as batteries or internal capacitors, can provide power even if the primary power is interrupted.
To improve HVEDR survivability during electrical power loss, Original Equipment Manufacturers (OEMs) are encouraged to develop triggering algorithms that do not rely on a park brake application or a key-off signal to store data in non-volatile memory. Additionally, OEMs should develop HVEDRs with integrated internal backup power source solutions and devise appropriate strategies to preserve data in the event of an electrical power loss. These measures would help ensure the availability of critical crash data even in challenging circumstances.
13.4 HVEDR survivability - fire
Developing effective solutions to mitigate data loss in post-collision fires is crucial for ensuring the reliability of HVEDRs. Both commercial trucks and buses face the challenges of fire, as the ECUs containing the HVEDR function can be susceptible to fires, whether installed on the side of the engine or within the cab.
To establish a standardized industry framework and ensure data survivability in fire incidents, it is important to define clear requirements for fire survivability. Neglecting to implement fire-related requirements can result in the loss of valuable data. Therefore, conducting dedicated research on fire survivability is necessary to determine the minimum requirements.
These requirements outline the necessary measures to prevent data loss in post-collision fires. Conducting dedicated research on fire survivability is essential to determine the minimum requirements OEMs should adhere to.
Addressing the issue of data loss in post-collision fires is a topic that warrants discussion among Original Equipment Manufacturers (OEMs), particularly within relevant platforms like the SAE J2728 Truck and Bus Event Data Recorder Committee. By engaging in collaborative efforts, OEMs can contribute to developing effective solutions and design strategies that mitigate the risk of data loss due to post-collision fires.
13.5 HVEDR synchronized timestamp
A timestamp in HVEDRs plays a vital role by offering precise and synchronized timing information for recorded events. By using a standardized time reference across various data sources, it becomes easier for end users such as government agencies, researchers, law enforcement, and independent consultants to analyze and correlate the recorded data to events accurately and reconstruct the sequence of events leading up to an incident or crash.
In addition to incident-specific event records, HVEDRs often capture Diagnostics Trouble Code (DTC) related freeze frames or snapshot data triggered during an event. However, the timestamps reported for these events may be "rough" or relative, making it challenging to correlate them accurately to the incident or crash.
A common approach for achieving synchronized timestamps is to rely on an internal clock (to the vehicle) broadcasting date and time per SAE J1939, synchronized with a global positioning system (GPS) receiver, cellular, or another external time source. These methods help establish a consistent and accurate time reference for all recorded data.
Original Equipment Manufacturers (OEMs) should adopt a synchronized common time clock across all recorded data in HVEDRs. By implementing this approach, OEMs can ensure that incident-specific event data and DTC snapshots or freeze frame records are accurately timestamped, facilitating a more comprehensive analysis and understanding of the recorded events.
Guidelines
HVEDR access
Collaboration between OEMs and OEM-approved third-party diagnostic tool providers is encouraged. This collaboration can lead to the development of a standardized imaging tool specifically designed for HVEDRs, making data access more efficient and accessible across different commercial vehicle manufacturers.
HVEDR functionality across multiple OEM ECUs
To facilitate standardization, OEMs are encouraged to develop a programming algorithm that consolidates HVEDR-type data to a single ECU. This approach can streamline data collection and retrieval processes, making it easier to access comprehensive HVEDR data from commercial trucks and buses.
HVEDR survivability - electrical power loss
To improve HVEDR survivability during electrical power loss, OEMs are encouraged to develop triggering algorithms that do not rely on a park brake application or a key-off signal to store data in non-volatile memory. Additionally, OEMs should develop HVEDRs with integrated internal backup power source solutions and devise appropriate strategies to preserve data in the event of an electrical power loss. These measures would help ensure the availability of critical crash data even in challenging circumstances.
HVEDR survivability - fire
Addressing the issue of data loss in post-collision fires is a topic that warrants discussion among OEMs particularly within relevant platforms like the SAE J2728 Truck and Bus Event Data Recorder Committee. By engaging in collaborative efforts, OEMs can contribute to developing effective solutions and design strategies that mitigate the risk of data loss due to post-collision fires.
HVEDR synchronized timestamp
OEMs should adopt a synchronized common time clock across all recorded data in HVEDRs. By implementing this approach, OEMs can ensure that incident-specific event data and DTC snapshots or freeze frame records are accurately timestamped, facilitating a more comprehensive analysis and understanding of the recorded events.
14.0 Summary and path forward
This document provides a detailed overview of the issues surrounding the use of HVEDRs and includes a series of best practices and guidelines that OEMs should consider regarding the development of these devices. Adherence to the SAE Recommended Practices for HVEDR event triggers, HVEDR data elements, and HVEDR data sampling rates and recording duration is strongly recommended. OEMs should also follow the suggested guidelines on HVEDR access, HVEDR functionality across multiple ECUs, HVEDR survivability, and HVEDR timestamp synchronization.
The primary focus was on Original Equipment Manufacturer (OEM) HVEDRs, which are commonly installed in vehicles categorized as Class 3 through 8. These vehicles weigh over 4,536 kg (10,000 lb) and are equipped with either the SAE J1708/J1587 serial communications bus or the J1939 CAN communications.
The document did not address aftermarket fleet management technologies that consistently record data, such as journey recorders or incident-specific devices like Electronic Logging Devices (ELDs) for driver hours of service, GPS telematics devices, or Video Data Recorders (dashcams).
In the context of this document, Original Equipment Manufacturers (OEMs) refer to the manufacturers of commercial vehicle chassis, engines, and safety systems. They also include designers and manufacturers of medium- and heavy-duty trucks and buses, Tier 1 suppliers of engines, transmissions, and heavy-duty vehicle safety systems, and service tool manufacturers who could develop a common HVEDR data imaging (extraction) tool.
HVEDRs have the potential to offer valuable insights into crash causation, driver avoidance maneuvers, and crash dynamics, which are crucial elements in crash investigations. Original Equipment Manufacturers (OEM) play a critical role in effectively using HVEDRs by ensuring their integration and adherence to the minimum requirements. Taking a proactive approach, OEMs can facilitate the collection of invaluable data that can significantly enhance road safety and improve crash investigations.
15.0 Acknowledgements
Mecanica Scientific research team would like to acknowledge and thank Lt. Timothy Austin, Mr. Timothy Cheek, Mr. Matt DiSogra, Mr. David Plant, and Mr. Greg Wilcoxson for their contributions, expertise, and guidance in this project. The team would like to acknowledge and thank the Mecanica Scientific Services team for their contribution in releasing this document.
16.0 References
Transport Canada Commercial Bus HVEDR Feasibility Study (File No. T8080-160062) Deliverable No. 1, Highway Safety Research Reference List; Oxnard, CA, USA; May 11, 2018
Transport Canada Commercial Bus HVEDR Feasibility Study (File No. T8080-160062) Deliverable No. 2, Database of Highway Safety Research; Oxnard, CA, USA; May 11, 2018
Transport Canada Commercial Bus HVEDR Feasibility Study (File No. T8080-160062) Deliverable No. 3, Summary Report of Facts; Oxnard, CA, USA; May 11, 2018
Transport Canada Commercial Bus HVEDR Feasibility Study (File No. T8080-160062) Deliverable No. 4, All Devices Summary Report; Oxnard, CA, USA; May 11, 2018
Transport Canada Commercial Bus HVEDR Feasibility Study (File No. T8080-160062) Deliverable No. 5, Summary Report of International Commercial Vehicle EDR Industry Standards and Recommended Practices; Oxnard, CA, USA; May 11, 2018
Transport Canada Commercial Bus HVEDR Feasibility Study (File No. T8080-160062) Deliverable No. 6, Commercial Bus HVEDR Feasibility Report; Oxnard, CA, USA; May 11, 2018
Transport Canada Commercial Bus HVEDR Feasibility Study (File No. T8080-160062) Deliverable No. 7, Final Report; Oxnard, CA, USA; May 11, 2018
Austin, T., Cheek, T., Plant, D., Steiner, J., and Lackey, L., “SAE C1022: Accessing and Interpreting Heavy Vehicle Event Data Recorders,” Modules 1-10, Course Presentation by SAE International, Oct. 2016.
Austin, T., Plant, D., and LeFevre, J., “Using NFPA Compliant Fire Apparatus Vehicle Data Recorders for Collision Investigation - Weldon Type 6444,” SAE Technical Paper 2015-01-1446, 2015, doi:10.4271/2015-01-1446.
Bayan, F. P., Cornetto, A. D., Dunn, A., Tanner, C. B., et al., “Comparison of Heavy Truck Engine Control Unit Hard Stop Data with Higher-Resolution On-Vehicle Data,” SAE Int. J. Commer. Veh. 2(1):29-38, Apr. 2008. doi: 10.4271/2009-01-0879
Bortolin, R., van Nooten, S., Scodeller, M., Alvar, D. et al., “Validating Speed Data from Cummins Engine Sudden Deceleration Data Reports,” SAE Int. J. Passeng. Cars – Mech. Syst. 2(1):970-982, 2009, doi:10.4271/2009-01-0876.
Bureau of Transportation Statistics, “Project 5: Developing Common Data on Accident Circumstances,” Project Presentation at U.S. Department of Transportation 2002 Safety in Numbers Conference, Jan. 2002.
Chidester, A., Hinch, J., Mercer, T. C., and Schultz, K.S, “Recording Automotive Crash Event Data,” presented at International Symposium on Transportation Recorders, Arlington, Virginia, May 3-5, 1999.
Chidester, A., Hinch, J., and Roston T. A., “Real World Experience with Event Data Recorders,” Paper No. 247, Proceedings of Seventeenth International Technical Conference on Enhanced Safety of Vehicles, Amsterdam, June 4-7, 2001.
Commission of the European Communities, Technical Specifications for the Digital Tachograph, Commission Regulation (EC) No. 1360/2002, June 13, 2002.
Dannenberg, R., "Multiplexing Consumer Electronic Products in Truck Applications," SAE Technical Paper 982757, 1998, doi:10.4271/982757.
daSilva, M. P., Analysis of Event Data Recorder Data for Vehicle Safety Improvement, NHTSA Report No. DOT-VNTSC-NHTSA-08-01, Springfield, Virginia: National Technical Information Service, Oct. 2008.
Federal Motor Carrier Safety Administration, and National Highway Transportation Safety Administration, “Large Truck Crash Causation Study,” accessed Jan. 2018.
Gabler, H. C., Gabauer, D. J., Newell, H. L., and O'Neill, M. E., Use of Event Data Recorder (EDR) Technology for Highway Crash Data Analysis, Final Report, NCHRP Project 17-24, prepared for the Transportation Research Board of the National Academies of Science, Dec. 2004.
Gabler, H. C., Hinch, J., and Steiner, J.C., “Event Data Recorders: A Decade of Innovation,” (Warrendale, SAE International, 2007), ISBN:9780768020663
Graz, T., ECBOS - Enhanced Coach and Bus Occupant Safety, Summary Report, Technical University GRSG-86-4, Project No. 1999-RD.11130, Jan. 2000.
Grose, G., Tunick, L., Cavicchioli, E., Cawdron, I., and Wood, S., “NHTSA EDR NPRM: Small Volume Manufacturer Lead-time,” Presentation to NHTSA, Washington, D.C., Jan. 2013.
Hendershot, K., Tiessen, P., (Canada) Heavy Vehicle Event Data Recorders GRSG-121-28; United Nations Economic Commission for Europe, World Forum for Harmonization of Vehicle Regulations (WP.29), 121st Working Party on General Safety Provisions (GRSG) Meeting, Geneva, Switzerland, April 2021.
Hynd, D., and McCarthy, M., Study on the Benefits Resulting from the Installation of Event Data Recorders, Final Report, prepared for European Commission, DG MOVE, Transport Research Laboratory Published Project Report No. PPR707, 2014.
Kane, S., Liberman, E., DiViesti, T., Click, F., and MacDonald, M., An Examination of the National Highway Traffic Safety Administration and the National Aeronautics and Space Administration Engineering Safety Center Assessment and Technical Evaluation of Toyota Electronic Throttle Control (ETC) Systems and Unintended Acceleration, Rehoboth, MA: Safety Research & Strategies, Inc., May 2011.
Knight, S. K., “Federal Motor Vehicle Safety Standards; Event Data Recorders: Part 571 Federal Motor Vehicle Safety Standards, §571.405,” Federal Register, 77(240):74159, 2012.
Lambourn, R. F., “Accident Investigation: Tachographs” in Encyclopedia of Forensic Sciences, (Academic Press, 2000), 48-58, doi:10.1006/nwfs.2000.0482
---. “The Analysis of Tachograph Charts for Road Accident Investigation,” Forensic Science International, 28(3-4):181-199, 1985, doi:10.1016/0379-0738(85)90130-6.
Lee, W. and Han, I., “Development of an Event Data Recorder and Reconstruction Analysis,” SAE Technical Paper 2004-01-1180, 2004, doi:10.4271/2004-01-1180
Legal Information Institute, “49 CFR Part 563 - EVENT DATA RECORDERS,” accessed Jan. 2018.
Martinez, R., National Transportation Safety Board Safety Recommendation H-97-10-18, Washington, D.C., July 1997.
Messerschmidt, W. and Muttart, J., “A Statistical Analysis of Data from Heavy Vehicle Event Data Recorders,” SAE Int. J. Commer. Veh. 2(1):39-48, 2009, doi:10.4271/2009-01-0880.
Millman, R. G., “Safety Recommendation; H-99-45 through -54,” National Transportation Safety Board, Nov. 2,1999.
Molino, L., “Meeting with Bosch on EDR Rulemaking,” National Highway Traffic Safety Administration, Memorandum to Docket No. NHTSA 2012-0177, Jul. 30, 2014.
Motorcoach Run-Off-the-Road Near Canon City, Colorado, December 21, 1999, Highway Accident Brief NTSB/HAB-02/19 (Washington, DC: National Transportation Safety Board, 2002).
National Collision Database (NCDB)
National Highway Traffic Safety Administration, “Considerations for Regulating Installation and Performance of Heavy Vehicle Event Data Recorders (HVEDRs)”, Docket No. NHTSA-2007-28793, July 2022.
National Highway Traffic Safety Administration, “Event Data Recorders,” 49 CFR Part 563, Docket No. NHTSA-2004-18029, RIN 2127-AI72, Federal Register 69(113):32932-32954, June 14, 2004.
---. “Event Data Recorders,” 49 CFR Part 563, Docket No. NHTSA-2006-25666, RIN 2127-AI72, Federal Register 71(166):50998-51048, Aug. 28, 2006.
---. “Event Data Recorders,” 49 CFR Part 563, Docket No. NHTSA-2012-0099, RIN 2127-AL14, Federal Register 77(154):47552-47557, Aug. 9, 2012.
---. “Federal Motor Vehicle Safety Standards; Event Data Recorders,” 49 CFR Part 571, Docket No. NHTSA-2012-0177, RIN 2127-AK86, Federal Register 77(240):74144-74159, Dec. 13, 2012.
---. “Federal Motor Vehicle Safety Standards; V2V Communications,” 49 CFR Part 571, RIN 2127-AL55, Federal Register 82(8):3854-4019, Jan. 12, 2017.
---. “Guidelines for the Safe Deployment and Operation of Automated Vehicle Safety Technologies,” DOT Docket No. NHTSA-2016-0036, Federal Register 81(96):31296-31297, May 18, 2016.
---. Motorcoach Safety Action Plan, Report No. DOT HS 811 177, Docket No. NHTSA-2007-28793, U.S. Department of Transportation, Nov. 2009.
---. “NHTSA Vehicle Safety and Fuel Economy Rulemaking and Research Priority Plan 2011-2013,” Docket No. NHTSA-2009-0108, Mar. 2011.
---. “NHTSA Vehicle Safety Rulemaking and Research Priority Plan 2009-2011,” Docket No. NHTSA-2009-0108, Oct. 2009.
---. “Request for Comment on Automotive Electronic Control Systems Safety and Security,” Docket No. NHTSA-2014-0108, Federal Register 79(194):60574-60583, Oct. 7, 2014.
National Transportation Safety Board, “Highway Accident Brief,” Accident No. HWY-00-FH011, Report No. NTSB/HAB-02/19, 2002.
National Transportation Safety Board, “Truck‐Tractor Semitrailer Rear‐End Collision Into Passenger Vehicles on Interstate 44 Near Miami, Oklahoma June 26, 2009” (HAR-10-02)
National Transportation Safety Board, Safety Recommendation H-99-53
National Transportation Safety Board, Safety Recommendation H-99-54
National Transportation Safety Board, Safety Recommendation H-10-14
National Transportation Safety Board, Safety Recommendation H-10-15
NHTSA Event Data Recorders Working Group, Event Data Recorders: Summary of Findings, Final Report No. NHTSA-1999-5218-9, U.S Department of Transportation, National Highway Traffic Safety Administration, Aug. 2001.
---. Event Data Recorders: Summary of Findings, Final Report, Volume II: Supplemental Findings for Trucks, Motorcoaches, and School Buses, Report No. DOT HS 809 432, U.S. Department of Transportation, National Highway Traffic Safety Administration, May 2002.
Office of Regulatory Analysis and Evaluation, FMVSS No. 405 Event Data Recorders (EDRs), Preliminary Regulatory Evaluation, prepared for National Highway Traffic Safety Administration, Nov. 2012.
Owings, R. P., “Record of the National Highway Traffic Safety Administration (NHTSA) Event Data Recorder Working Group First Meeting,” prepared for the Motor Vehicle Safety Research Advisory Committee, Crashworthiness Subcommittee, Washington DC, Oct. 2, 1998.
Reust, T., "“The Accuracy of Speed Captured by Commercial Vehicle Event Data Recorders”," SAE Technical Paper 2004-01-1199, 2004.
SAE Course, Accessing and Interpreting Heavy Vehicle Event Data Recorders, Course ID No. C1022; Timothy Austin, Timothy Cheek, Matt DiSogra, Wesley Grimes, Bradley Higgins, David Plant, John Steiner, Gregory Wilcoxson
TMC RP1210A, VMRS 053, Windows Communications API, Revised 7/99, © 2003 TMC/ATA
Transportation Safety Board of Canada, Crossing Collision, Via Rail Canada Inc. Passenger Train No. 51, OC Transpo Double-Decker Bus No. 8017, Mile 3.30, Smiths Falls Subdivision, Ottawa, Ontario, 18 September 2013, Railway Investigation Report No. R13T0192, 2015.
United States Congress, H.R. 22 cited as the “Fixing America’s Surface Transportation Act” (129 STAT. 1312 PUBLIC LAW 114–94), 114th Congress, Washington DC, Dec. 2015.
17.0 Disclaimer
This report has been produced by Mecanica Scientific Services Corporation (Mecanica) under contract with Transport Canada. We have made every effort to ensure that the contents presented in this report are relevant, accurate, and up-to-date. Mecanica will not accept any liability for any errors or omissions, or reliance on part or all of the content in another context.
The information and views set out in this report are those of the author(s) and do not necessarily reflect the official opinion of Mecanica. Mecanica does not guarantee the accuracy of the data included in this study. Neither Mecanica nor any person acting on Mecanica’s behalf may be held responsible for the use that may be made of the information contained therein.