ollision C
Volume 13 Issue 2
The International Compendium for Crash Research
New biofidelic dummy crash behaviour in a crash comparison
vehicle fire = no electronic data?
tesla edr case studies and reconstruction techniques
infotainment systems use in accident reconstruction
collisionmagazine.com
Capture. Draw. Present. A common problem that many agencies face is how to make efficient use of all the data that can get captured at a scene. The last thing you need to worry about is how to use all this data to produce the reports and deliverables you need. We can help.
Read more, on page 63
Contents
Volume 13 Issue 2
inside 1
Digital Download - Bonus Material Access
4
Letter From the Editor
4
Collision Magazine Information
6
features 6
Vehicle Fire = No Electronic Data? by Michael Stogsdill
22
Vehicle Speed From Sound by Alan Moore
30
Crash Behaviour In A Crash Comparison: The New Biofidelic Dummy in Different Scenarios Of Accidents Involving Passenger Cars And Pedestrians by Annika Kortman
42
Crash-ol-o-gy: Introducing Toyota Vehicle Control History by Wesley Vandiver and Robert Anderson
48
Toyota Gen1 EDR Event Recording Logic by W. R. Rusty Haight and Robert Anderson
68
Motorcycle Accident Reconstruction: Incorporating EDR Data from the Struck Vehicle by Nathan Rose, Neal Carter, Martin Randolph and William Bortles
92
Tesla EDR Case Studies & Reconstruction Techniques by Weston Brown and Robert Anderson
106
Identifying Infotainment Systems for Use in Accident Reconstruction by Shawn Harrington
114
Guardrail Crash End Terminal Reconstruction and Analysis by Lawrence Wilson and Dr. Kevin Schrum
30
92
114 XX
case problem 56
CASE PROBLEM: Toyota Gen1 EDR Event Recording Logic by W. R. Rusty Haight and Robert Anderson
128
SOLUTION: Toyota Gen1 EDR Event Recording Logic by W. R. Rusty Haight and Robert Anderson
www.collisionpublishing.com
Collision Magazine - Volume 13 Issue 2 3
Vehicle Fire = No Electronic Data? Michael Stogsdill
Collision Reconstruction Services, LLC
6
Collision Magazine - Volume 13 Issue 2
www.collisionpublishing.com
A
bstract Many vehicles on the road today contain event data recorders which may record valuable data with respect to automobile collisions. In addition to the event data recorders, in-vehicle infotainment systems may store vehicle navigation information as well as cellular phone data from the vehicle's occupants. In addition to the electronic storage devices on the vehicle, occupants of the vehicle often bring their smart telephones, tablets, notebook computers, and other electronic devices in the vehicle. This paper will look at the electronic storage devices after they have been involved in a car fire as well as look at the temperatures of a car fire.
I
ntroduction According to the United States Fire Administration, one out of eight fires that fire fighters respond to are vehicle fires. Eighty-three percent of the vehicle fires involved passenger vehicles. Sixty percent of the fatal vehicle fires were the result of a collision (Topical Fire Report Series 2018).
Automobile manufacturers have implemented technology within vehicles to collect data in automobile collisions. The data is often written in event data recorders, which are subcomponents of vehicle modules such as an airbag control module, powertrain control module, roll-over sensor, pedestrian protection module, and/or an active safety control module. Other electronic data can also be stored in vehicle’s in-car entertainment or in-vehicle infotainment systems. Infotainment systems are comprised of hardware and software within the vehicle to allow the driver and passengers to have access to audio and video content, social networking, and games as well as navigation and vehicle diagnostics (Pati 2018). In addition to electronic storage mediums within the vehicle, passengers in the vehicle will bring other electronic devices with them. These devices can include cellular phones, smart phones, tablets, notebooks, GPS units as well as gaming devices and other electronic devices. During a vehicle fire, these items will often be left behind and burned in the fire. After the fire has been extinguished, and the smoke has cleared, can the data within the electronic devices be retrieved?
T
esting The car fires were conducted in Briggsdale Colorado with the assistance of the Briggsdale Fire Department. Four vehicles were burned. Each vehicle was instrumented with K-type thermometers and K-type thermocouples.
www.collisionpublishing.com
Collision Magazine - Volume 13 Issue 2 7
Vehicle speed from Sound Alan Moore, P.E., ACTAR
V
ideo recordings are frequently available as useful evidence in an accident reconstruction. Not as often, a video recording may contain the sound of a vehicle but not useful video images. This could occur in a motorcycle collision where the motorcycle strikes the side of the vehicle equipped with a dashcam, such that the motorcycle is not visible in the video prior to impact. It could also occur if a dashcam was able to view a passing motorcycle, but the video resolution and frame rate were insufficient to calculate the motorcycle’s speed. Also, a dashcam may record engine sound but the video quality is insufficient for using visual references to calculate speed. In such cases, the audio recording of the vehicle’s engine can be used to calculate its speed. Two methods were evaluated. The first is to use Doppler shift alone to evaluate speed. The second is to use spectral analysis of the engine sound, along with vehicle specifications, to determine vehicle speed from engine speed.
The Doppler effect is generally expressed as the following:
Where: is the velocity of waves in the medium is the velocity of the receiver relative to the medium (positive if the receiver is moving towards the source) is the velocity of the source relative to the medium (positive if the source is moving away from the receiver) The general form of the equation, when adapted for accident reconstruction use, is: ...
Doppler shift method Austrian physicist Christian Doppler first reported a phenomenon in 1842 wherein the frequency of a waveform measured by an observer is dependent on the relative speed between the transmitting source and the observer. In the most simple scenario wherein the transmitting source is moving directly toward the observer, the movement of the transmitter between each waveform produces the effect of compressing the waveforms in time in front of the transmitter and expanding them behind the transmitter – thereby producing a change in frequency. As a result, the approaching sound of a siren is of a higher pitch than as it moves away.
22
Collision Magazine - Volume 13 Issue 2
Where: ...
The frequency plot is generated from the audio track of the video using FFT (Fast Fourier Transform). Several free programs are available to generate FFTs; examples in this paper were mostly produced with Audizr for Windows. Using the Doppler shift method, any identifiable peak in the vehicle sound can be used, such as engine, gear or tire
www.collisionpublishing.com
noise, and any distinctive component of wind noise may also be used. An FFT can be demonstrated using a musical instrument. “Concert A” is a standard pitch used for tuning musical instruments, and is at 440 Hz. Played on a guitar, its FFT is as shown in Figure 1a.
As an example, a motorcycle was driven past a stationary camera at a GPS-measured speed varying between 39.1 and 39.5 mph. Figure 1b shows the frequency plot of the recording; the approach of the motorcycle is shown in red, its departure past the camera in yellow. Any prominent peak in the data can generally be used. In this case, the prominent engine sound was used. The peak was 120 Hz on the approach, and 108 Hz after it passed the camera. Using the above equation, the calculated speed is 40.4 mph, as shown below: ...
Where:
Figure 1a: “Concert A” at 440 Hz on a guitar
108 Hz 120 Hz
Figure 1b: Motorcycle approach frequency in red, and departure frequency in yellow.
www.collisionpublishing.com
Collision Magazine - Volume 13 Issue 2 23
crash·ol·o·gy THE SCIENCE OF CRASHES Wesley Vandiver
Robert Anderson
Collision Forensics, Inc.
Biomechanics Analysis
Introducing Toyota Vehicle Control History
E
vent Data Recorders (EDRs) have become a common source of important data for crash investigators. Since their introduction in the 1990s, EDRs have matured from devices that capture and record partial crash pulse data to sophisticated modules that can report a vast number of pre-crash and post-crash parameters. The important consideration here is the reference to a crash – “precrash” and “post-crash.” These devices are designed to capture data relative to a crash, allowing investigators to retrieve information that may assist them in reconstructing the incident. The adoption of 49 CFR Part 563 1 established a clear definition of an EDR: Event Data Recorder (EDR) means a device or function in a vehicle that records the vehicle's dynamic time-series data during the time period just prior to a crash event (e.g., vehicle speed vs. time) or during a crash event (e.g., delta-V vs. time), intended for retrieval after the crash event. For the purposes of this definition, the event data do not include audio and video data. What about data recorded by vehicles when they are not involved in a crash? Is that EDR data? Perhaps not, given the definition established in Part 563. However, as outlined in the first edition of Crashology2, there is significant data recorded by vehicles on an ongoing basis or in response to events that would not be categorized as a crash. These data may be just as valuable as the EDR data collected from a crash, or, potentially, the only data available following a crash, depending upon circumstances, including severity.
42
Collision Magazine - Volume 13 Issue 2
One source of such non-crash data is known as the Toyota Vehicle Control History (VCH). Toyota has been one of the most forthcoming manufacturers with its EDR data in terms of historical coverage and the volume of data retrievable by investigators. In addition to this, Toyota recognized the importance of recording vehicle behavior and driver operations during events that may not result in a crash, or at least a crash of sufficient severity to cause the recording of an EDR event. The VCH is a function that records control data (record data) when triggered by specific vehicle behavior. The VCH also stores image data when a specific trigger is set. The VCH is recorded in different storage areas designated by trigger group and it is possible to save up to 140 items in total. If storage space is filled, the data is overwritten on a First-In, First-Out (FIFO) basis. Each trigger receives time information from the main body Electronic Control Unit (ECU), which is the time elapsed since the engine switch was turned on for the given ignition cycle. Absolute time may be recorded for vehicles with factory-installed navigation systems. Data are recorded in the airbag ECU, and although it can be retrieved utilizing Toyota Techstream, it cannot be cleared using this application. Disconnecting power from the vehicle will also not result in VCH data loss. Any images stored as the result of specific triggers are stored in the camera sensor electrically erasable programmable read-only memory (EEPROM).
www.collisionpublishing.com
The VCH data is obtained utilizing the Toyota Techstream software 4 and a suitable connection to the vehicle’s OBD-II port. Tools that have been successfully used for connection include the MongoosePro Toyota 2 cable 5, Nexiq USB-Link 6, and the Bosch CDR 900 7.
not associated with PCS or Intelligent Clearance Sonar (ICS) can be seen in Figure 2. One of the more advanced and potentially valuable data elements available from VCH are images taken by the system as a result of specific triggers. These triggers include: •
PCS operation history - pre-collision brake assist operation (PCS brake assist operates)
•
PCS operation history - prior brake operation (PCS preliminary braking operates)
•
PCS operation history - pre-collision brake operation (PCS brake operates)
The recording details of data that is associated with PCS/ICS can be seen in Figure 3.
Figure 1: Splash screen for the Toyota Techstream The ability to recover VCH data began with the 2013 RAV4 and 2014 Highlander. This feature has subsequently been added to nearly all Toyota and Lexus models. The VCH data available from supported Toyota vehicles can vary by model. Table 1 shows a partial list of the triggers that generate VCH recordings in a 2018-2019 Toyota Camry. Reviewing this abbreviated list shows that many triggers are associated with accelerator pedal opening angle, gear shift selector changes, the Pre-Collision System (PCS), Vehicle Stability Control (VSC), Traction Control (TRC), Anti-lock Braking System (ABS), Lane Keeping Assist (LKA), and Lane Departure Alert (LDA) systems. As evident in Table 1, many of the trigger thresholds associated with VCH could be met during aggressive driving or in the course of an avoidance maneuver that did not ultimately result in a crash. Because of this, VCH data is potential evidence not only for collision investigation, but also the investigation of any incident that involves a supported Toyota vehicle, including racing incidents, police pursuits, fleeing suspects, etc. Table 1 lists the number of data samples and duration of the recording associated with the pre- and posttrigger VCH recordings. The recording details of data
In July 2019, the authors conducted controlled testing of a 2019 Toyota Camry. The vehicle was instrumented to assess the accuracy of many recorded values in its VCH. Detailed results of that testing are being compiled for a future technical article in Collision Magazine. Figure 4 shows a sample of the VCH data collected from a single trigger - in this case, the trigger was “Accelerator pedal opening angle signal is high immediately after brake pedal is released.” Figure 5 shows a sample of the VCH data collected from a separate trigger - in this case, the trigger was, “Sudden turning history.” Figure 6 shows a VCH record generated by the trigger, “Accelerator pedal opening angle is medium or higher immediately after shifting to R.” Figures 4, 5 and 6 represent a small portion of the data collected from the Camry testing, but are sufficient to show that the data are detailed and extensive. VCH data are a tremendous source of potential evidence in many types of vehicular investigations. The engineering of this technology into vehicles and the availability of publicly-available tools to acquire these data are exclusive to Toyota at this time. Investigators should certainly be aware of this data source and always consider gathering these data in any case involving a supported Toyota vehicle.
www.collisionpublishing.com
Collision Magazine - Volume 13 Issue 2 43
Toyota Gen1 EDR Event Recording Logic W. R. Rusty Haight, Collision Safety Institute Robert Anderson, Biomechanics Analysis
I
ntroduction This paper addresses the analysis of more than 100 CDR/CDRx files retrieved from crash test vehicles and a total of more than 600 Toyota system CDRx files. This was done to examine and better understand what is identified as the “Gen1" airbag control module’s process of overwriting previously recorded events and offers a more detailed examination of what is meant by the term “prior event” found as an event chronology identifier in some Gen1 system Event Data Recorder (EDR) components. The recording trigger threshold of hose systems and the recording order and other characteristics of the Gen2, 3 and 4 system is different than what is observed in Gen1 systems and is not addressed here.
is a Toyota followed by, for example, a Ford. Ultimately, both the stopped car, the Toyota and Ford are involved in a crash. The question comes down to: who hit whom first? Did the Toyota run into the stopped car and then hit by the Ford or, while slowing, did the Ford hit the Toyota and push it into the stopped car? During the investigation, data is retrieved from the Toyota and the events recovered are as seen in Figure 2.
But why?
There are almost any number of scenarios and data sets one might have already seen or might be able to envision where understanding the recording logic for Toyota ACMs would be useful in better understanding and evaluating a given collision sequence. Not to exclude the same sort of analysis for crash data which might be recorded in another manufacturer’s ACM/EDR component. Toyota EDR data - particularly as it relates to “Gen1" system - is fairly unique and it’s clear that a better understanding of that system’s recording logic deserves a closer look.
Consider an example of data retrieved from a Toyota Airbag Control Module (ACM) such that the “Front/Rear Event Record Summary at Retrieval” data table, as seen in Figure 1, reports that there were three events recovered and, chronologically, they are numbered Triggers (TRGs) 5, 13 and 14. On the surface, what can be said about the chronological order and what happened to, for example, TRGs 6 through 12 in Figure 1? It’s not hard to imagine a scenario involving, for example, multiple vehicles and impacts some of which rise to the level of recorded or recordable events creating a string of records which, progressively in chronological order, are recorded and then overwrite previously recorded events such that, when the sequence ends, leaves event records as seen in Figure 1. Imagine a crash scenario described such that a car is stopped at a traffic signal and, approaching that car from behind
48
Collision Magazine - Volume 13 Issue 2
In Figure 2, there are TRGs 4, 6, and 7. What kind of crash was TRG 5? Why does it appear that TRG 5 was overwritten by a later event and TRG 4 wasn’t? Would knowing more about what TRG 5 was (in terms of perhaps polarity or severity) be helpful in establishing the order of events?
Background As detailed in the Bosch Crash Data Retrieval (CDR) Tool help file and the Data Limitations 1 text associated with a CDR Tool data translation report for one of the Toyota line vehicles,2 there are, at this writing, four generations of Toyota Airbag Control Modules (ACMs) which include the Event Data Recorder (EDR) functionality which is accessible using the Bosch CDR Tool. Generation 1, or “Gen1,” refers to what are identified in the report as
www.collisionpublishing.com
Electronic Control Unit (ECU) “00EDR” and “02EDR” systems. Gen2 refers to “04EDR” and “06EDR” systems, Gen3 refers to, for North American sales, the “12EDR,” “13EDR,” and “15EDR” systems 3 and Gen4 which, thus far, includes “17EDR” and “19EDR” systems. The number in the generation designator (i.e.: the 02 in the 02EDR designation of a Gen1 system) is most closely associated with the first year the particular ACM/EDR variant was introduced in production.
data sets from various Toyota line vehicles from production year 2000 through 2019. Many of these tests were conducted to evaluate or verify polarity, range, resolution, rounding, timing and accuracy of the EDR reported data versus that of reference instrumentation and comparison with known circumstances of the crash (i.e.: seat position or driver’s seat belt status). ACM behavior such as trigger threshold,4 accelerometer bias, and recording threshold related to overwriting or the replacement of previously recorded events has also been investigated and will be addressed separately.
Toyota line systems with Gen1 ACM’s span the 2001 to 2011 production year range for North American distribution and may be found in vehicles made for sale outside North America through 2013. As such, Gen1 ACMs are still a fairly frequently encountered system and their event recording behavior warrants analysis and discussion. Gen1 ACMs (ECUs) typically store, at any one time, up ECUs in other generation groups have few recording char- to three longitudinal events, the deployment algorithm5 acteristics which overlap those found in Gen1 systems and trigger and recording thresholds are generally related their recording logic, in particular, does not mirror that meaning that once the module experiences sufficient lonfound in Gen1 systems as would be discussed here. For gitudinal acceleration (either positive or negative along the example, where Gen1 systems may record, at any one time, longitudinal axis) to engage the ACM’s decision making up to 3 longitudinal events, those in other systems only algorithm (a trigger threshold) that will result in a set of have space for two recorded longitudinal events at any one event data being recorded as an event record (assuming sufficient residual power to complete the recording and time. that the module’s EDR function hasn’t already been “froTo date, the authors have conducted over 100 instrument- zen.” A small number of these vehicles/modules may ined crash tests involving Toyota vehicles with Gen1, 2 and clude pre-crash data and most report longitudinal delta-V 3 ACMs and have undertaken a review of some 600 EDR for a period of 150 ms or more. www.collisionpublishing.com
Collision Magazine - Volume 13 Issue 2 49
Toyota Gen1 EDR Event Recording Logic
Case Problem W. R. Rusty Haight, Collision Safety Institute Robert Anderson, Biomechanics Analysis
T
his case problem was designed to tie into the article in this issue of Collision regarding the “Toyota Gen1 EDR Event Recording Logic” and reinforces the need for a careful reading of all the contents of CDR Tool data translation reports to fully grasp their meaning and value.
is, after all, from a series of crash tests designed to address the issues raised in the case problem.
In this case, you’re working on a crash involving a 2006 Toyota Corolla. You use your Bosch CDR Tool to access and retrieve crash data from the Toyota. Using the latest version of the CDR Tool software, you generate a translation report, select data tables of which are displayed here in this issue of Collision. In fairness to the reader, it should be made clear that this data comes from a series of crash tests conducted specifically to investigate Toyota ACM trigger/ event recording sequence, limitations and processes.
2. Although all three events are identified as “Most Recent Event,” determine, is you can, the actual chronological order of the recorded events?
As you can see from the report pages, there are three retrieved events, all are marked “Most Recent Event.” All are identified as TRG 254 (Trigger number 254). For the purposes of this case problem, assume the crash you are investigating is a rearender; you have every reason to believe that this Toyota was struck from behind at a relatively low speed by another vehicle. Although the normal process would be to first try to evaluate whether or not the retrieved data is related to the crash you are investigating, for this case problem you may rely on the information that one of the recorded events is actually from the described low speed rearender crash. Of course, in practical application, you’d want to be able to find a set of facts or conditions which could be used to affirmatively say that some or all of the data you have to work with IS related to the crash you’re investigating. Here, this is a case problem and you are given certain assumptions: (1) you may adopt the information as reliable and (2) one of the recorded events is actually from the described low speed rearender crash. The data presented here 56
Collision Magazine - Volume 13 Issue 2
That said, the questions for this case problem are: 1. Explain why the TRG (trigger) count numbers are all identified as TRG 254, Most Recent Event.
For the next part of the case problem, assume that, after the minor crash which lead to the recorded data as shown, the driver of this car was involved in another crash. In that subsequent crash, this driver was again rearended by another car. You may adopt as fact that the longitudinal delta-V in the subsequent crash was about +6.1mph. 3. Can you say whether or not there would there be any new data (a new recorded event) as a function of this subsequent rear end crash? 4. If there was new data recorded as a function of the subsequent crash, which previously recorded “Most Recent Event” would be overwritten by data from this subsequent event? 5. If there was new data recorded as a function of the subsequent crash, what would the TRG number of the new event record be? [Editor’s note: In the interest of page space, the data tables from the report have been formatted to fit the space available and the hexadecimal data has been omitted; it may be considered irrelevant to the focus of the case problem. One may wonder if any data or key element has been altered or otherwise excluded. The answer is no. You may rely on the data tables, as displayed, as having been translated from the original raw data using the latest version of the CDR Tool software and
www.collisionpublishing.com
nothing has been edited, none of the translated values or report form have been changed apart from the previously mentioned reformatting. The reformatting essentially reduces three pages of translated data for each of three recorded events to one page for each of the three recorded/retrieved events. The events, as
named, are presented in the same order they would be presented in a “normally” formatted report and the original page numbers indicating where the data for each of the translated events began are indicated.]
www.collisionpublishing.com
Collision Magazine - Volume 13 Issue 2 57
Motorcycle Accident Reconstruction: Incorporating EDR Data from the Struck Vehicle Nathan Rose
Neal Carter
Martin Randolph
ntroduction Electronic event data has become ubiquitous on modern passenger vehicles, and much of this data is accessible with either the Bosch Crash Data Retrieval (CDR) system or the Global Information Technology (GIT) system [Haight, 2013a]. This data will often contribute useful information to an accident reconstruction. However, reconstructionists will need to understand how the data is collected and its limitations. Issues of interpretation and accuracy arise that will often require the reconstructionist to employ classic reconstruction methods alongside the data from the event data recorder (EDR). Also, many accident reconstructions will seek answers to questions that go beyond what the EDR data can directly provide, and many accident reconstructions will need to draw on a broad swath of evidence – physical, video, audio, and testimonial, in addition to the electronic data. Many accident reconstructions will also draw on empirical data and principles of physics.
I
68
Collision Magazine - Volume 13 Issue 2
William Bortles
Some motorcycles now have EDRs and the possibility of there being electronic data from the motorcycle involved in a collision now exists [Fatzinger, 2017 and 2018]. This scenario remains rare, however, and the more common scenario is that the struck passenger vehicle will be equipped with an EDR. This EDR data will give useful information but will not directly report the collision speed of the motorcycle. The electronic data can, however, be combined with classic reconstruction techniques (conservation of momentum, analysis of the post-impact translation and rotation of the struck vehicle, and damage analysis methods) to infer the collision speed of the motorcycle, to reconstruct the speed and path of the passenger vehicle in the moments leading up to the collision, and to understand errors that the driver or rider made in the moments leading up to the collision. Newton’s 2nd and 3rd laws together (conservation of momentum) dictate that, during a collision between two vehicles, the ratio of the mass or weight of Vehicle #1 (m1
www.collisionpublishing.com
or W1) to the mass or weight of Vehicle #2 (m2 or W2) is equal to the ratio of the change in velocity experienced by Vehicle #2 (ΔV2) to the change in velocity experienced by Vehicle #1 (ΔV1), as follows: (1) If the EDR data from the struck vehicle reports that vehicle’s ΔV, then this ΔV can theoretically be used to calculate the change in velocity of the motorcycle. The ΔV of the motorcycle can then be used to infer the impact speed of the motorcycle. However, potential problems can arise with this approach due to the large weight discrepancy that may be present between the motorcycle and the struck vehicle [Niederer, 1990; McNally and Bartlett, 2002; Strohmeyer, 2018]. As an example, the ratio of the weight of the struck vehicle (including the driver) to the weight of the motorcycle (including the rider) in one of the case studies examined later in this article was approximately 7.15. The EDR-reported resultant ΔV in this instance was 12.1 mph. Applying Equation (1) yields a ΔV for the motorcycle of 85.8 mph, as follows (equation 2):
However, there is some level of error that could be present in the EDR-reported ΔV. Given the weight ratio, every 1 mph of potential error in the struck vehicle ΔV would produce 7.15 mph of uncertainty in the calculated ΔV for the motorcycle. If the potential error within the ΔV was ±3 mph, then the potential range on the ΔV for the motorcycle would be 65.1 to 108.0 mph, a 42.9 mph spread. On
the other hand, if the potential error within the ΔV were ±1 mph, then the potential range on the ΔV for the motorcycle would be 78.6 to 92.9 mph, a 14.3 mph spread. This illustrates the sensitivity in conservation of momentum analysis due to the typically large weight ratio present in motorcycle-to-passenger vehicle collisions and emphasizes the need to understand what the potential error in an EDR-reported ΔV is likely to be in any given case. The Accuracy and Usefulness of the Struck Vehicle EDR Data Pre-Crash Data A common motorcycle crash scenario occurs when an EDR-equipped passenger vehicle turns left across the path of a motorcycle and is struck by the motorcycle. In these instances, pre-crash EDR data can be helpful for establishing the specific characteristics of the attempted left turn that preceded the collision. This data may include speed, throttle percentage, brake applications, and steering angles for the struck vehicle. Bortles, Biever, Carter, and Smith presented a literature review related to the accuracy of the pre-crash speeds reported by original equipment event data recorders installed in passenger vehicles [2016]. These authors reported that “EDR reported vehicle [pre-crash] speed is typically measured by sensors monitoring the output of the transmission or an average of the speed of the drive wheels. These sensors can accurately report wheel speed but, due to certain factors, the wheel speed may not represent the true over-the-ground speed of the vehicle. These factors may include longitudinal wheel slip due to acceleration or braking, wheel slip due to rotation of the vehicle about the vertical axis, significant changes in the tire’s rolling radius as compared to the vehicle’s original
www.collisionpublishing.com
Collision Magazine - Volume 13 Issue 2 69
Tesla EDR Case Studies & Reconstruction Techniques Weston Brown & Robert D Anderson
A
bstract Tesla is currently the newest addition to the nearly comprehensive family of EDR/CDR supported vehicles. Aspects of the technology that are unique to this manufacturer will be covered through comprehensive review of case studies of crashes involving Tesla vehicles. Besides the mechanics of obtaining a download and telematics information, the discussion will include how data from the vehicle telematics obtained through Tesla compares and differs from the data retrieved from the airbag control module, as well as traditional reconstruction methods as well as video evidence evaluation. Introduction In today’s ever more technological world, we are increasingly offered different avenues to arrive at vehicle speeds. In 16 short years Tesla has made a significant impact on the automotive industry. According to Forbes, Tesla Model S and X made up 45% of the sales of electric vehicles in the United States and according to Statista by December of 2018 Tesla held 2.08% of the U.S. market share of cars and light trucks. They are a leader in new technology in vehicles and beginning with the Model S look at diagnostic data directly from the vehicle on a regular basis. This diagnostic data was generally only available to law enforcement on presentation of proper authority, i.e. a search warrant. In 2018 Tesla released its Event Data Retrieval Tool during the 2018 EDR Summit in Houston, Texas. This tool allowed for private consultants to retrieve information relevant to a crash and complied with 49CFR563. This initial rollout of the Tesla EDR tool included legacy coverage of: Model S, 2012 to present; Model X, 2016 to present; and Model 3, 2017 to present. The only model not included in coverage was the Roadster, produced from 2002 to 2012 prior to the effective date of 49CFR563. Tool Overview The Tesla EDR retrieval tool continues Tesla’s innovation by utilizing automated in-house data translation.
92
Collision Magazine - Volume 13 Issue 2
The software is free and available from Tesla’s EDR Reporting Service Portal. The retrieval equipment can be purchased through Crash Data Group and includes the following components: •
Hard-Shell protective carrying case with padded dividers, plus
•
TPCAN: PCAN-USB adapter
•
Power: AC power supply unit
•
TIV-144: Model S and Model X
•
TIV-145: Model S older than Sept. 2016
•
TIV-996: Model 3
•
TD2M-139: Model S
•
TD2M-601: Model X and 3
•
TD2M-602: Model S older than mid-2019
The Tesla EDR retrieval tool currently includes the PCAN interface, which is analogous to the Bosch CDR Tool’s CAN Plus or CDR 900 interfaces, and the Tesla In-Vehicle (TIV) cables and the Tesla Direct-to-Module (TD2M) cables, are analogous to the Bosch CDR Tool’s DLC, and direct-tomodule cables.
Figure 1: Tesla EDR Kit
The process for retrieving the raw data is similar to the Bosch CDR Tool (Figure 2). The software must be obtained and installed on a windows computer. Once the PCAN drivers are properly installed, the raw *.edr file is obtained via either an in-vehicle connection or direct to module connection, whichever is appropriate for the vehicle’s condition.
www.collisionpublishing.com
Download and install EDR retrieval software Purchase hardware from Crash Data Group
Upload the *.edr file to the edr.tesla.com web portal for translation into a report (for North American configured vehicles)
Connect to the Tesla vehicle or direct to the module and save a *.edr file to your computer
Maintain the *.edr file on your computer for later report translation in a later version of the EDR service software
Figure 2: Process for obtaining a Tesla EDR report
www.collisionpublishing.com
Collision Magazine - Volume 13 Issue 2 93
Identifying Infotainment Systems for Use in Accident Reconstruction Shawn Harrington Forensic Rock
I
ntroduction Like its big sibling Event Data Recorder nearly two decades ago, infotainment and telematics systems have burst onto the accident reconstruction scene in the past decade. Similar to early EDR coverage and the amount of data recovered, supported vehicles containing useful infotainment data for the accident reconstruction community is relatively small but growing. The application of data imaged from infotainment systems has been extremely helpful in criminal prosecutions involving stolen vehicles, human trafficking, homicides, drug trafficking and more. Berla, the manufacturer of hardware and software to image data contained within infotainment and telematics systems, has done an excellent job increasing vehicle coverage and support in the last five years. The intent of this article, however, is to focus solely on the practical applications of infotainment data relevant to the accident reconstruction community. In 2015, Lemere authored an overview of infotainment data relating to the field of accident reconstruction and presented a hit-and-run case study.1 In a 2017 SAE technical paper, Bortles et al. comprehensively introduced the accident reconstruction community to the Berla iVe infotainment ecosystem, conducting testing of various infotainment systems and presenting the results.2 In 2018, Vandiver and Anderson presented validation testing of Ford Sync Gen 2 and Sync Gen 3 infotainment systems, concluding that the speed data reported in these respective systems was acceptably accurate.3 A comprehensive search of the technical literature, however, failed to reveal any articles evaluating infotainment data and their involvement in actual collision events. This two-part article hopes to present a modest beginning to this area in accident reconstruction. In this first section, systems that contain relevant data to the acci-
106 Collision Magazine - Volume 13 Issue 2
dent reconstruction community will be discussed. In the second part, correlation of EDR and infotainment data will be presented. Hundreds of vehicles involved in collisions which contained infotainment systems and their imaged data have been reviewed and analyzed by the author. Figure 1 demonstrates all vehicle makes that contain supported infotainment systems covered by Berla’s iVe software. While the list of supported vehicles containing infotainment data is laudably immense when conducting a search on Berla’s website or iVe software, personal experience has concluded that only a subset of these infotainment-supported vehicles have potential data relevant to accident reconstruction analyses. It is important to note that infotainment data is trimlevel dependent. That is, only certain trim levels within a given model line are supported by a Berla infotainment imaging. For example, while every 2015 Dodge Charger will have a supported Bosch Crash Data Retrieval (CDR) system, only certain trim levels will have a Berla-supported infotainment system. Further complicating system identification is the fact that for some infotainment acquisitions, only certain manufacturers of the infotainment module itself are supported. That is, while a certain trim-level of a model of vehicle may be supported, only the specific Harman-manufactured infotainment system module is ultimately supported by a Berla iVe infotainment acquisition. This will be discussed further in the vehicle identification section. Based on the author’s experience, Berla’s vehicle lookup section is ultimately beneficial for determining whether a specific vehicle has the potential of being supported. Berla continues to improve their infotainment system identification by providing useful photographs and identification tips in their ‘Need Help Identifying’ sec-
www.collisionpublishing.com
Figure 1: All Berla-supported infotainment systems.
Figure 2: Berla systems that can provide useful data for accident reconstruction.
tion. However, due to the immense volume of different vehicle makes, models, and trim levels their software covers, it is not yet an exhaustive resource. Acquiring resolute photographs of the center stack area of the vehicle before committing to a vehicle inspection for an infotainment imaging is a recommended practice. Berla is an impressively willing and valuable resource for fieldand photo-identification of infotainment systems. Once you have identified the infotainment system in the vehicle of interest, Berla provides you with the data that is supported by an imaging of that infotainment system. This checklist should only serve to alert you to the potential of acquiring certain data, not specifically that this information will be provided in your imaging. For example, tracklogs from a Uconnect infotainment system have never been discovered in the field by the author or his colleagues, yet, tracklogs are always checked when
screening an infotainment system on Berla’s website for a Uconnect system. When attempting to parse out which information is valuable to the accident reconstruction community, priority to information concerning vehicle speed, braking, location, and other collision-related information were given. While cell phone data such as whose phone was paired to the vehicle is incredibly valuable for other types of investigations, specifically stolen-vehicle scenarios, this information is not as important to a classic accident reconstruction analysis. For these reasons, based on the author’s experience dealing with infotainment systems, the manufacturer’s in Figure 2 provide the reconstructionist a realistic chance at recovering useful collisionrelated information. The quality and quantity of this collision-related information to an accident reconstruction analysis, however, varies greatly. Three tiers of data are therefore presented.
www.collisionpublishing.com
Collision Magazine - Volume 13 Issue 2 107
Toyota Gen1 EDR Event Recording Logic
Case Problem Solution W. R. Rusty Haight, Collision Safety Institute Robert Anderson, Biomechanics Analysis
A
s noted, this car was used in a series of crash tests which were part of a larger research project conducted in conjunction with the Texas Department of Public Safety, Highway Patrol State Crash Reconstruction Team. When the project started, the 06 Corolla had one recorded trigger/event: “TRG 1.” The car was used as part of the larger project to examine recording order and prioritization as detailed in the paper “Toyota Gen1 EDR Event Recording Logic” found in this issue of Collision. In addition to the series of tests adding to the database of progressive recording examples developed for the recording logic article, one of the goals of the testing was to evaluate the statement found in the Data Limitations text (05002_ToyotaTRW_r027) for this module type which reads: “... “TRG Count” indicates the number of frontal/ rear recording triggers that have been established. The calculated value does not include the number of times side or rollover recording triggers have been established. The sequence in which each frontal/ rear event occurred can be verified from the “TRG Count”. The lesser the “TRG Count” value, the older the data. The upper limit for the recorded value is 254 times. When more than one event reaches the upper limit, the actual “TRG Count” may be greater than what is displayed for that event. ...” (emphasis added) While this statement is further addressed in the article (“Toyota Gen1 EDR Event Recording Logic”), a large part of this specific test series was designed to narrowly focus on the maximum TRG count and what would actually happen once that maximum number was reached. That there was a discussion of the maximum number included in the Data Limitations, it would seem it might be anticipated that that number might, at some point, be reached. In reports from the field, CDR Tool users have shared examples of Toyota vehicles from which crash data was retrieved in128 Collision Magazine - Volume 13 Issue 2
cluding “real world” trigger counts exceeding 90 for vehicles still in use. Moreover, in later Gen3 systems, the Data Limitations text indicates that the maximum number was increased from 254 to 65,533 as seen in this passage (again from 05017_ToyotaS00std_r027): “... “TRG Count” indicates a calculated value of the number of times recording triggers have been established for all crash types. The sequence in which each event occurred can be verified from the “TRG Count”. The smaller the “TRG Count” value, the older the data. The upper limit for the recorded value is 65,533 times. When more than one event reaches the upper limit, the actual “TRG Count” may be greater than what is displayed for that event. ...” Returning attention to the module type associated with this particular case problem, this part of the testing was referred to as the “How many licks does it take to get to the middle of the Tootsie Pop?” series or, what really happens when (if ) we set 254 triggers? An extension of that would be to evaluate whether or not the module behavior would follow the predicted path as seen in the recording logic article. The test series conducted followed the pattern set out in the recording logic article from TRG1 through TRG124. After that, the series was continued uninterrupted until reaching TRG254. From the recording logic article, we know that, when recording a new event, the Gen1 module protects the chronology of the “most recent event” and records the newly occurring event’s data over either a previously recorded and unprotected positive delta-V event or the smaller magnitude event of two events with the same polarity. Armed with that information, the 4th TRG set in the test series (identified as TRG4) was designed to have a negative longitudinal delta-V event and then all subsequent events created to increase the trigger count were conducted so as to result in positive longitudinal delta-Vs. That way, TRG4 would be preserved up through TRG254. Figure
www.collisionpublishing.com
1 shows where TRGs 4, 16 and 17 had been recorded and the data retrieved; TRG4 being that last negative longitudinal delta-V and, as subsequent events were created, here TRGs 16 and 17, they were all positive longitudinal deltaV events leaving TRG4 “undisturbed.” Figure 2 shows the Record Summary listed events as retrieved after Triggers 123 and 124. In this case, TRG4 remains “protected” again by virtue of the way the tests were planned and these two more recent events were conducted close in time to one another (3.953 sec. apart) such that the order could be confirmed by more than just the trigger count value. At Figure 3, the Record Summary data table shows the currently recorded events are Triggers 4, 254 and 254. Notably, both of the events listed as TRG254 in that table are marked “Most Recent Front/Rear Event.” The longstanding TRG4 is here marked “1st Prior Frontal/Rear Event.” Prior to this point in the series, TRG4 had been marked as “Prior Frontal/Rear Event” (see Figure 2).
Consistent with what we find in the Data Limitations text and the recording logic paper, as shown in Figure 3, the trigger count has reached its maximum count (“... The upper limit for the recorded value is 254 times. ...”). [Editor’s note: the fuller process is detailed in the paper “Toyota Gen1 EDR Event Recording Logic” found in this issue of Collision.] The test series continued and, using the knowledge of the process as detailed in the Recording Logic paper, TRG4 was ultimately intentionally overwritten. After that, the data found in the Case Problem statement was retrieved and the recorded events are described as seen in Figure 4 (as seen in the data tables from the Case Problem Statement found earlier in this issue of Collision). It is a given that you may adopt as fact, for the current investigation, that this Toyota was struck from behind at a relatively low speed by another vehicle and then data retrieved. The questions and then answers for this case problem are offered here:
Figure 1: Event Record Summary at Retrieval showing TRG Count 17, 16, and 4
Figure 2: Event Record Summary at Retrieval showing TRG Count 124, 123 and 4
Figure 3: Event Record Summary at Retrieval showing TRG Count 254, 254 and 4 www.collisionpublishing.com
Collision Magazine - Volume 13 Issue 2 129