Volume 17, Issue 1

ollision C

Volume 17 Issue 1

The International Compendium for Crash Research

Using Centrodes

CATAIR 2022

to Describe Vehicle

Crash Conference

Motion

Crashology Crash Analysis with Berla and EDR Data,

Trigger counts marked “Invalid” in Toyota EDR data

Two Case Studies

Moving Masses and Barrier Impact Dynamics

collisionmagazine.com

Expert AutoStats®

4N6XPRT BioMeknx™

Expert AutoStats® is a computer program containing over 50,000 vehicles cars, vans, utility vehicles, and light pickups. 1945-2020 model years are represented.

(Laptop & Desktop Windows 32 & 64-bit OS Compatible)

Enter:

Manufacturer and Year

Select:

Model from pop-up window

Output:

Wheelbase Overall Length Height Wt. Distrib

4N6XPRT BioMeknx is designed as a collection of the Biomechanical data of importance to the Accident Investigator into one easily accessible reference location. It is designed as a program to be useful to ALL accident investigators, not just the Biomechanical expert.

Curb Weight Width Drive Wheels Front/Rear Track

Mid-60's to present output also includes (when available): Front Overhang Rear Overhang Bumper Heights Hood Height Turning circle Wheel radius Bumper-to-Hood Bumper-to-Window

Expert AutoStats® is currently owned by over 700 private individuals and 300 Law Enforcement agencies in the U.S.A., Canada, and South America. Additional information, brochure, and order from can be downloaded from:

www.4n6xprt.com/4n6as.htm

The program includes: 1. Over 65 printable illustrations and charts 2. 10 Separate categories or sections of information related to forensic biomechanics 3. Information on walking speeds of people from 17 months to > 65 years 4. Calculation modules for: - segment length from total body height, - segment weights and Centers of Mass (CoM) based on total body weight, - Predicted Maximum Walking Speed based on total height 5. Information was obtained by review of over 65 scientific texts, several of which are now "out of print"

www.4n6xprt.com/4n6bm.htm PROGRAM ORDER FORM (Please Print)

4N6XPRT StifCalcs® 4N6XPRT StifCalcs puts the NHTSA Crash Test database on YOUR 32 or 64 bit MS-Windows computer PLUS calculates A-B-G values and Test Specific Crush Factors based on the NHTSA test data, with no need for you to get on the internet, all for the price of only $700.00*!

Can you do this yourself “for free”?? Only if you value YOUR time at $0.00!!

Contact Name: ________________________________________________ Company: ____________________________________________________ Street: ______________________________________________________ City:____________________ State:____ Zip:__ __ Country: __________ Phone: (_____) _______________ Fax: (_____) ___________________ E-Mail: ______________________________________________________ Expert AutoStats® 4N6XPRT BioMeknx™ Expert Qwic Calcs® 4N6XPRT Ped & Bike Calcs® 4N6XPRT StifCalcs® Expert VIN DeCoder® (pkg) Expert TireStuf® Order Processing

- $ 675.00 ea.

- $ 550.00 ea.

- $ 275.00 ea.

- $ 375.00 ea.

- $ 700.00 ea.

- $ 575.00 ea.

- $ 85.00 ea.

= ________ = ________ = ________ = ________ = ________ = ________ = ________

- Check = $5.00 / Credit Card = $10.00 / Govt. P.O. = $15.00 = _______ Notarized Affidavit Requirement $25.00 per required Notarized Signature = _______

Q Deliver via electronic download (Email address Required) Q Ship on USB - $50.00 per disk per program California Sales Tax

- 8.50%

TOTAL (U.S. Dollars)

= 0.00 = ______

= ________

= ________

Search for vehicles by entering Year, Make, and Model, or by any combination of: Length, Wheelbase, Weight, Body Style, Make, Model, and Impact location

Enclosed is:

Print out data and stiffness for single tests, or a Test Summary Stiffness Report when more than one test meets your search criteria

Card Number: _______________________________________________ Name on Card: _______________________________________________ Signature: ________________________________________________

For more information, program order form, and sample printouts please visit our web site at http://www.4n6xprt.com. You may also call us at (619) 464-3478 M-F, 9a-5p (PST), if you have specific questions.

www.4n6xprt.com/4n6sc.htm 2

Collision Magazine - Volume 17 Issue 1

Visa ___ MasterCard ___ Am. Ex. ___ Exp ____/____ - Check ___ - Gvt PO ___

Please Make Checks*/Purchase Orders Payable to:

4N6XPRT Systems®

8387 University Ave - La Mesa, CA 91942-9342 - U.S.A. FAX: (619) 464-2206 Phone: (619) 464-3478 Web: http://www.4n6xprt.com Checks *MUST* be drawn on a U.S. bank. Orders are shipped within 10 working days of receipt.

Prices subject to change without notice.

Multiple orders and Package discounts available. Please call for details.

www.collisionpublishing.com

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 1

Publisher's Message It’s finally here, Volume 17, Issue 1 of Collision!

Over the last few months, there were times I wondered if we’d get here, but we got it together AND we have Vol 17, Issue 2 almost ready to go in a just a couple short months. When I took the reigns at Collision Publishing in March this year, I looked at all the Scott Baker had accomplished with Collision and the EDR Summit and wondered if I could pull off anything close to what he had done so successfully for so long.

"

Well, the jury’s still out on that and it’s taken a lot of work and the time and patience of a lot of people and a learning curve was far steeper than I expected to get to this point but we did it. Now the goal is to get Issue 2 out in time for the EDR Summit and then Volume 18 on track to fill out 2024 mid-year.

other conference later in 2024 outside of Houston. We’ll have to see…

In the meantime, the EDR Summit returns for 2024 in Houston at the Sheraton – not the Hilton – and the speakers and topics are set. Exciting new research on a correlation between cell phone date and time and vehicle data – EDR and GM’s FCM, for example – date and time should be one of the highlights.

Either write something worth reading. or do something worth writing.

Don Floyd from GM, Bill Rose from Bosch as well as other new presenters and relevant topics will make the 2024 Summit a “don’t miss” opportunity not the “same ol’, same ol’.”

- Benjamin Franklin.

Benjamin Franklin once said “Either write something worth reading, or do something worth writing [about].” I’d like to think that’s the idea behind Collision Magazine. We have a group of great frequently contributing authors and want to continue to live up to the idea that Collision will be the home of new and fresh, articles, papers, and relevant information.

For the Summit return there’s an optional session after the Summit from a long-time Toyota in-house trainer on how to read and use Toyota Techstream data more effectively.

This hands-on session is a first for the EDR Summit and is sure to be a hit – not to be missed.

I look forward to reaching out to you through the coming Volume of Collision Magazine and meeting you all at the 2024 Summit.

In the coming few months we have the EDR Summit (February 2024) and the second issue in Volume 17 of Collision and some other exciting ideas in development. There’s talk of perhaps an-

Rakel Arnardttir - Publisher & Graphic Designer 2

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

In this issue 2

Volume 17, Issue 1

Publisher's Message 16

4

Collision Magazine Info and Advertiser Index

6

Crash·ol·o·gy -Crash Analysis with Berla and EDR Data, Two Case Studies

by Wesley Vandiver, Robert Anderson, Michelle Hoffman, David Hallman, Billy Cox

16

Using Centrodes to Describe Vehicle Motion

24

by Micky Marine, SSi Phoenix, Inc.

24

Performance of BMW Event Data Recorder (EDR) in Instrumented Barrier and Vehicle-to-Vehicle Crashes

by Robert D. Anderson, Biomechanics Analysis and Michael Rosenfield, RSR Engineering

44

Personally Identifying Information

50

by Katarina Juric

50

Trigger counts marked “Invalid” in Toyota EDR data - Part 1

by W. R. "Rusty" Haight, Collision Safety Institute

78

What Is Tesla Sentry Mode And How Does It Work?

by Rehan Arif

102 84

Moving Masses and Barrier Impact Dynamics

by Micky Marine, SSi Phoenix, Inc.

102 CATAIR 2022 Crash Conference

by Michael Rosenfield RSR Engineering, and Robert D. Anderson Biomechanics Analysis

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 3

Collision Publishing 2529 South Golf Freeway B#333 League City, TX 77573 1 832 864 0427 E-mail: admin@colllisionpublishing.com https://www.collisionmagazine.com/ ISSN: 1934-8681

COLLISION STAFF Rakel Arnardottir Sean Haight W. R. Rusty Haight

Publisher Senior Editor Editorial Cordinator

SUBMIT AN ARTICLE Article submissions may be emailed to:

https://collisionpublishing.com/pages/ submit-an-article-proposal BACK ISSUES ADVERTISER INDEX

If you would like purchase back issues of Collision Magazine, please visit:

https://issuu.com/collisionpublishing All rights reserved, ©2023 Collision Publishing, LLC. The opinions and conclusions expressed in this publication and in any associated data and content of the articles attributed to specific authors are the opinions and conclusions of the authors noted and not necessarily the editorial staff or anyone else for that matter. While some articles have been reviewed for content, the accuracy of reprinted models or equations cannot be fully guaranteed. It is the responsibility of the reader to apply critical thinking to an individual review of the content and make their own personal judgements as to its value to them, individually.

At the end of the day, facts belong to everybody, any other opinions to us. The distinction is yours to draw... otherwise, the opinions expressed herein are not necessarily those of any employer, not necessarily ours, and probably not necessary.

4

Collision Magazine - Volume 17 Issue 1

PAGE

4N6XPRT

Inside Front Cover

Aperture

1, 115

Alterra

5

Crash Data Group 15, Inside Back Cover EDR Summit

42, 48-49

Crash Hub

43

Car Clouds

96

CSI

101

Skillwise

116

Eng. Dynamics

Back Cover

www.collisionpublishing.com

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 5

crash·ol·o·gy THE SCIENCE OF CRASHES Wesley Vandiver

Robert Anderson

Collision Forensics

Michelle Hoffman Forensic Injury Analysis

Biomechanics Analysis

David Hallman Hallman Engineering

Billy Cox

Billy Cox Group

Crash Analysis with Berla and EDR Data, Two Case Studies

Most vehicles on the road today are equipped with airbag control modules (ACMs), which store crash (EDR) data that can be retrieved and utilized to assist in reconstructing a crash. For the collision reconstructionist, the ability to retrieve digital evidence of vehicle speed and driver’s actions around the time of a particular incident can yield key evidence in an investigation. The acquisition of vehicle speed data from Event Data Recorders (EDRs) has become commonplace and is a routine item on the checklist for those investigating vehicular incidents. Much has been written about the accuracy of EDR data from a multitude of vehicle tests involving actual crashes, simulated crashes, hard acceleration, hard braking, etc. In summary, nearly all experts agree that EDR data is tremendously valuable but should always be considered alongside the other physical evidence and a proper analysis of that evidence as part of a situationally complete reconstruction.

More and more vehicles are also equipped with multiple other modules which store data that can be retrieved and used for crash and / or other analysis of driver actions prior to and even after a crash. More recently available to the reconstructionist than EDR data is Vehicle System data acquired using Berla iVe. As will be demonstrated through two case studies, the additional data acquired using Berla iVe can be used to analyze driver behavior before, during, and after an incident; identify time, date, and place of an incident; as well as identify cellular phones connected to the vehicle.

This article will present two case studies of vehicles which had both EDR data from a crash as well as data that was 6

Collision Magazine - Volume 17 Issue 1

retrieved from the infotainment system using the Berla iVe hardware and software. Having both Berla and EDR data sets allowed comparison between the two, to evaluate and confirm that the data from the two separate systems agreed.

Case 1 – 2020 Ford F150 The first case involves a 2020 Ford F150 (Figures 1 and 2) which was reportedly stolen, involved in a hit and run crash, and then abandoned. The owner reported that the vehicle had been stolen from their driveway earlier in the evening and that they were unaware it was missing until the police called them to report it had been recovered. The F150 contained a Ford Sync system, Generation 3, Version 2 which was removed and imaged with the Berla iVe hardware and software. The EDR data was imaged with the Bosch Crash Data Retrieval (CDR) Tool equipment and software.

The data from the infotainment system was analyzed and a map (Figure 3) and a timeline of events beginning at 7:04 pm on 7/22/2021 and ending on 7/23/2021 at approximately 1:40 am was prepared and is shown: 7/22/2021 – 7:04 pm (Track 24) The subject vehicle starts at 5108 Brookdale Drive N.

•

A Galaxy S20 Ultra 5G phone connects, carrier is TMobile, number: 1-763-614-XXXX

www.collisionpublishing.com

•

A Galaxy S20 Ultra 5G phone connects, T-Mobile, number: 1-763-614-XXXX

•

7/22/2021 – 10:58 pm (Track 29)

•

The subject vehicle arrives near 1650 White Bear Avenue in St. Paul MN

•

7/22/2021 – 11:45 pm (Track 31)

•

The subject vehicle starts near 1650 White Bear Avenue

•

A Galaxy S20 Ultra 5G phone connects, T-Mobile, number: 1-763-614-XXXX (11:47 pm)

•

7/22/2021 – 11:49 pm (Track 31)

•

The subject vehicle stops near 1800 White Bear Avenue but is not shut off.

•

7/22/2021 – 11:50 pm (Track 31)

•

The subject vehicle leaves the area of 1800 White Bear Avenue.

•

7/22/2021 – 11:53 pm (Track 31)

•

Crash detected at the intersection of White Bear Avenue and Highway 36, specifically in the intersection that leads to the entrance to westbound Highway 36.

•

The subject vehicle does not stop at the time of the crash.

•

7/22/2021 – 11:56 pm (Track 31)

•

Vehicle stops on the shoulder of Highway 36 just west of White Bear Avenue entrance.

•

Driver’s door is closed.

•

A Galaxy S20 Ultra 5G phone becomes unavailable, T-Mobile, number: 1-763-614-XXXX

Figure 1: 2020 Ford F150

Figure 2: 2020 Ford F150 •

7/22/2021 – 7:40 pm (Track 24)

•

The subject vehicle arrives near 1930 Buerkle Road in White Bear Lake MN

•

7/22/2021 – 9:04 pm (Track 26)

•

The subject vehicle starts near Buerkle Road

•

7/22/2021 – 9:14 pm (Track 26)

•

7/23/2021 – 12:07 am (Track 31)

•

A Galaxy S20 Ultra 5G phone connects, T-Mobile, number: 1-763-614-XXXX

•

Track 31 ends.

•

7/22/2021 – 9:16 pm (Track 26)

•

7/23/2021 – 12:29 am

•

The subject vehicle arrives near 1800 White Bear Avenue in Maplewood MN

•

Door opens, vehicle wakes up – Highway 36 shoulder.

•

7/22/2021 – 10:53 pm (Track 29)

•

7/23/2021 – 1:39 am

•

The subject vehicle starts near 1800 White Bear Avenue

•

Door opens and closes – Twin City Towing impound lot.

www.collisionpublishing.com www.collisionpublishing.com

Collision Magazine Volume17 17 Issue 1 7 Collision Magazine - -Volume

Figure3: The data from the infotain system was analized and put on a map that shows a timeline of events The infotainment data indicates that the Galaxy S20 Ultra 5G phone, T-Mobile, number: 1-763-614-XXX was in Bluetooth and connected to the subject vehicle throughout the timeline from 7/22/2021 at 7:04 pm when the vehicle left 5108 Brookdale Drive North, made various stops and was eventually left on the shoulder of Highway 36 westbound near White Bear Avenue at 11:56 pm, including, but not limited to, at the time of the infotainment system indicated crash.

The EDR data was also analyzed. A locked side event which deployed the airbags was recorded. According to

the pre-crash data (Figure 4), the vehicle was decelerating with the brake applied until approximately 2 seconds prior to Algorithm Enable (AE). At that time, the driver applied the accelerator and speed increased from 16 to 22 mph. The driver did not apply the brakes prior to AE. The steering data (Figure 5) shows that the driver started turning left approximately 3 seconds prior to AE and continued to make a sharp turn to the left up to AE. A review of the infotainment system crash notification and the map where it occurred shows that the corner where the truck was turning is more than 90 degrees to the left which matches the steering angle in the crash data (Figure 6).

Figure 4: A locked side event associated with airbag deployment was recorded 8

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Figure 5: The steering data shows that the driver started turning left approximately 3 seconds prior to AE

Figure 6: the map where it occurred shows that the corner where the truck was turning is more than 90 degrees to the left which matches the steering angle in the crash data www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 9

The data in this case showed that the vehicle owner, or at least the vehicle owner’s phone, (which was never reported missing, misplaced, or stolen by the vehicle owner) was in and connected to the subject F150 from the time it was reportedly “stolen” until it was abandoned immediately after the crash.

The location of the crash was identified by the infotainment system and the steering in the crash data confirmed that the data was from the crash under investigation. Furthermore, the crash data provided some insight into the driver’s behavior at the time of the crash by showing that the brakes were not applied, and the driver was accelerat-

ing up to the point where the F150 was struck by another vehicle in the intersection.

Case 2 – 2017 Ford Fusion The second case involves a 2017 Ford Fusion (Figures 7 and 8) which was the second vehicle in a four vehicle, in-line chain reaction crash (Figure 9). The police reported that that the Fusion struck the first car and was then struck from behind by vehicle 3. The driver of the Fusion reported that they were struck from behind by vehicle 3 and pushed into the back of vehicle 1. The Fusion contained a Ford Sync system, Generation 3, Version 1

Figure 7: The second case involves a 2017 Ford Fusion

Figure 8: The Ford Fusion was the second vehicle in a four vehicle, in-line chain reaction crash 10

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Figure 9: The police reported that the Fusion struck the first car and was then struck from behind by vehicle 3

which was removed and imaged with the Berla iVe hardware and software. The EDR data was imaged with the Bosch equipment and software.

The data from the infotainment system was analyzed, paying particular attention to the track point data at the time of the crash. That data is collected at 10Hz. A review of the relevant speed data (Figure 10) from the GPS track-

log shows that on 6/5/2022 at 12:39:57 pm, the vehicle was decelerating and slowed from 6.8 mph to 3.3 mph.

Before and during these recorded speeds, the vehicle also identified “Hard Braking” (Figure 11). The vehicle then accelerated to 7.6 mph (in 0.1 seconds from 3.3 mph), 7.7 mph and then 7.8 mph (in 0.3 seconds). During the acceleration, the vehicle identifies one “Wheel Traction” event (Figure 12). It is marked as “Possible Wheel Spin”,

Figure 10: A review of the relevant speed data from the GPS tracklog www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 11

Figure 11: The module also identified “Hard Braking” with a 1.1 G acceleration. Speed then goes from 7.8 mph to 3.8 mph in 0.1 seconds and to 1.2 mph in 0.2 seconds.

Two other “Wheel Traction” events occur (Figure 12) during the deceleration and are marked as “Possible Wheel Slip”, both with -1.2 G accelerations.

The EDR data was also analyzed. A locked event which deployed the airbags was recorded. According to the precrash data (Figure 13), the vehicle was decelerating with the brake applied for the entire recorded five seconds prior to AE. The driver does not apply the accelerator during the pre-crash data. Paying particular attention to the last second of pre-crash data (Figure 14), the vehicle was decelerating until 0.4 seconds prior to AE and slows to 3.3 mph. Between 0.4 and 0.2, the vehicle then accelerated to 7.9 mph with the brake applied and no application of the accelerator pedal. The event setting crash then occurred at approximately 7.8 mph.

12

Collision Magazine - Volume 17 Issue 1

Both the EDR image and the infotainment system captured nearly identical data regarding the crash. As a bonus, the infotainment system also captured the exact location, date and time where the crash occurred.

The infotainment system also captured information about the directionality of the accelerations. Showing the positive and the negative and the order in which they occurred.

These two data sets together confirmed the driver’s story that they were slowing, were struck from behind and then struck the vehicle in front of them. It is important to remember that, if only one data set were available, the order of the crash could still be determined, but having both sets together confirm all aspects including, time, date, location, and most importantly in this case, the order of impacts.

www.collisionpublishing.com

Figure 12: During the acceleration, the module identifies one “Wheel Traction” event

Figure 13: Airbag deployment resulted in a locked event. www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 13

Figure 14: Paying particular attention to the last second of pre-crash data (Figure 14), the vehicle was decelerating until 0.4 seconds prior to AE and slows to about 3.3 mph

These are two examples of how Berla iVe acquired data and EDR data are complimentary and once aligned, pro-

vide a more comprehensive understanding of a crash than would have been available with either data-set alone.

Wilton “Wilt” Nelson 9 Dec 2927 - 13 Sept 2023 It's always hard to have to announce the passing of a colleague, especially someone as well known and admired as Wilt Nelson. Wilt passed on September 13, 2023 and was laid to rest at the Bushnell National Cemetery in Bushnell, FL. He is survived by Marion, his wife of 44 years, as well as two daughters Holly and Elizabeth, 4 grandchildren, and 11 great grandchildren.

Wilt’s life seemed to be ordained into traffic safety after being run over as a child and sustaining two fractured femurs. Most of us remember him from his time at General Motors where he worked for 31 years as well as his time on various committees with the Society of Automotive Engineers.

While at GM he worked at the Proving Grounds and was involved in numerous projects including experimental engineering and served as the Chief Investigator for the GM “Air Cushion Program” (predecessor to the “airbasystem”), “Automatic Belt Program,” and field crash studies and product evaluation. After retirement from GM, Wilt was a widely respected consultant operating as Crash Analysis & Reconstruction.

Wilt was a founding member of the Midwest Association of Traffic Accident Investigators (MATAI) and worked tirelessly to improve crash investigation training and assist law enforcement with crash analysis in Michigan and throughout the Midwest.

An avid Scuba diver, Wilt traveled the world after retirement on dive charters and found his way to dive spots and dive trips literally spanning the 7 seas not to mention the innumerable lakes and rivers worldwide. Wilt’s last email to his many correspondents began: “Dear friends, fellow countrymen and relatives…” and it those of us who will keep him in our hearts and minds.

14

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 15

Using Centrodes to Describe Vehicle Motion Micky Marine SSi Phoenix, Inc.

I

n the study of rigid body kinematics, angular velocity is considered a property of the body and is not dependent on the choice of reference point selection. Meaning, for instance, angular rate sensors can be placed anywhere on a rigid body that undergoes rotational motion and the sensors will measure the angular velocity of that body. The angular velocity vector is therefore known as a free vector – its magnitude and direction can be specified, but its point of origin cannot. This fact then leads us to the notion of an instantaneous center of rotation (IC) where the velocity of any point on a rigid body can be defined solely by the angular velocity and the position vector between the IC and the point on the body. For general rigid body motion, the IC will change position over time leading to the concept that the motion of a rigid body can be described by a locus of ICs that form what are known as body and space centrodes. The objective of this article is to examine automobile motion in a variety of situations through the perspective of the centrodes concept.

Examples for vehicle motion in the yaw, pitch and roll planes are presented, providing analysts with an uncommon but, hopefully, interesting perspective of rigid-body motion.

16

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Instantaneous Centers of Rotation & Centrodes In the context of automobile accident analysis, vehicle motion is very often considered planar. More than a few accidents occur with the vehicle(s) moving along on their tires and wheels, remaining in that condition throughout the accident. This is often referred to yaw-plane motion.

Rollover accidents, on the other hand, can comprise complex three-dimensional motion, though frequently the predominant rotational motion is about the vehicle longitudinal axis.

The vehicle is thus visualized in cross-section (a lamina of the vehicle) and the angular motion is considered to be about an axis that is perpendicular to the lamina. The IC is a point in the plane of interest that can be geometrically located at the intersection of lines that are drawn from any two points on a given body and are perpendicular to the absolute velocity vector at those respective points (see Figure 1 below). At a particular instant in time, the motion of the body can be thought of as being in pure rotation about the IC. The velocity of any point on the body, in either a space-fixed or a body-fixed reference frame, can be determined through the cross-product of the angular velocity vector and the position vector from the IC to the point of interest.

relative to that body while the space centrode is a virtual space-fixed terrain upon which the body centrode “rolls” without slipping. While we’ll confine ourselves to planar motion in this article, the centrodes concept can be expanded to the description of three-dimensional rigid body precession motion relative to an instantaneous axis of rotation where a virtual body cone rolls without slipping on a virtual space cone. References 1 and 2 both provide useful IC discussions.

A simple example of a planar body and space centrode system is that of a wheel rolling over a flat surface in the absence of wheel slip (no sliding of the wheel along the surface plane). In this situation, as is commonly understood, the absolute velocity of the wheel at the point where it is in contact with the flat surface is zero. Thus, the IC is located at the wheel/surface contact point. At each successive instant, as the wheel rolls along the surface a new point on the wheel perimeter, now arriving at the surface, becomes the current IC. In this system, the body centrode is a circle that coincides with the wheel perimeter, while the space centrode is a line that coincides with the surface that the wheel is rolling on (Figure 2). Hence, the body centrode (wheel perimeter) is literally rolling on the space centrode (surface plane).

Figure 2: Body and Space Centrodes for a Wheel Rolling with No Slip

Figure 1: Construction of an Instantaneous Center of Rotation If the velocity time-history at some point on the vehicle and the angular velocity time-history of the vehicle are known, at each instant that the body is in motion the position-history of the IC can be determined relative to both a space-fixed reference system and a body-fixed reference system. The plotting-out of these successive ICs relative to the reference coordinate systems form what are known as the space (or fixed) centrode and body (or moving) centrode, respectively. Conceptually, the body centrode is virtually attached to the physical body and remains fixed

A more complex example is that of a wheel initially rolling on a flat surface without wheel slip that then undergoes braking with increasing wheel slip. As the wheel undergoes braking, a slip velocity (sliding) is developed at the wheel/surface contact point. For this slip-velocity condition, the IC is located at some distance below the surface plane. This is shown conceptually in Figure 3. Note that for this situation the velocity vectors at the center of the wheel and at the wheel/surface contact are both parallel to one another; the IC is then found to be the intersection of the line connecting the two origin points and the line connecting the tips of the velocity vectors.

The body and space centrodes for increasing braking then take a form similar to that depicted in Figure 4. The body centrode shape is a spiraling curve originating at the wheel perimeter, and the space centrode a curve that moves progressively further below the surface plane. In this example,

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 17

Figure 3: Rolling Whel with Slip Velocity at the Surface Plane the wheel is initially rolling with no slip at the wheel/ surface contact point and the IC is located at the wheel/ sur-face contact point as in the previous example. With the development of wheel slip (i.e., relative velocity at the wheel/surface contact point), however, the IC moves to a location below the surface plane. As the slip increases, the IC location moves further below the surface plane.

If the braking torque becomes sufficient to affect lockedwheel skidding (100% slip, no rotation), the IC will then move to an infinite distance below the surface plane and all points on the wheel travel at the same velocity.

Figure 4: Body and Space Centrodes for a Wheel Undergoing Braking with Increasing Slip

For the case of a vehicle experiencing yaw-plane motion, the location of the IC at a particular instant in time, with

respect to both space and body-fixed coordinate systems, can be found from the equations immediately below.

The time-history of these locations defines the locus of points that comprise the space and body centrodes. As an example of yaw-plane centrodes, consider the impact configuration of a full-scale crash test depicted in Figure 5. The above equations, along with accelerometer and angular rate sensor data from the crash test and the yawcorrection methods of reference 3, were used to define the space and body centrodes for the vehicle traveling at 20.5 mph and struck near the left rear door by a vehicle of the same year, make, and model traveling at 60.3 mph. Figure 6 (located at the end of the article) depicts the motion of a vehicle during the collision phase of this crash test.

Space Centrode (Fixed):

Body Centrode (Moving):

Cetrodes of a Vehicle in Yaw-Plane (X-Y) Motion

Equations 1 18

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Figure 7 (also at the end of this article) depicts a portion of the motion of the vehicle after it has separated from its collision partner. As we see in Figure 6, the IC at the instant of initial contact is located an infinite distance from the struck vehicle. After this initial contact the IC rapidly approaches the vehicle and, as the yaw rate increases, the body centrode takes on the shape of a fairly tight curve around the vehicle. Approximately 150 milliseconds after initial contact the test vehicles have separated and the struck vehicle motion is dominated by the curved body centrode shape around the vehicle as it rotates and translates on its post-impact trajectory as shown in Figure 7. In this example, the body centrode is observed to pass very near the right front, right rear, and left rear tire locations of the vehicle. This means that tire path cusps will occur near the location where those respective body centrode points make “contact” with the space centrode. The paths for these tire locations are depicted in the last panel of

of Figure 7 (readers of a certain age might here be reminded of the once-popular Spirograph® art toy). Note that these are the paths of the respective tire locations; whether tire marks are visible after the fact obviously depends on factors like vertical tire load, tire slip angle, tire conditions, amount of tire/wheel entrapment, roadway surface conditions, etc. For the crash test used in this example, the left rear tire cusp was plainly visible after the test and is shown (green highlight) in Figure 8. Tire marks from the front tires (blue highlight) and right rear tire (yellow highlight – making a less visible cusp) are also visible in this figure.

Figure 8: Tire Cusp Mark from Left Rear Tire of the Struck Vehicle (green highlight) Centrodes of a Vehicle in Pitch-Plane (X-Z) Motion

Figure 5: Crash Test Impact Configuration Space Centrode (Fixed):

For the case of pitch-plane motion, the space and body centrodes can be found using the following equations: Body Centrode (Moving):

Equations 2 www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 19

Figure 9 (located at the end of the article) depicts the motion of a vehicle executing a maneuver made iconic in the movie "Thelma & Louise" – i.e., driving off a cliff. The depicted motion begins as the front tires have just left the edge of the terrain. For this vehicle motion, just as the front tires leave the edge of the terrain, the IC is located an infinite distance below the vehicle and, as the vehicle travels with the rear tires still in contact with the terrain, the IC quickly approaches the vehicle. At the point where the rear tires leave the terrain and the vehicle begins a freeflight ballistic path, the centrodes begin a sharp turn, receding from the vehicle as the free-flight fall progresses.

In Figure 9 we see that there is greater curvature of the centrodes early in the free-flight motion due to the ratio of the translational velocities to the pitch rate. This curvature subsequently diminishes as the translational velocity of the vehicle increases as it falls under the influence of gravity while the pitch rate remains constant. The early part of this vehicle trajectory would, of course, be representative of a vehicle driving off an embankment into a canal or a ditch; an occurrence somewhat less rare than driving off the cliff of a deep canyon.

Centrodes of a Vehicle in Roll-Plane (Y-Z) Motion For motion in the roll-plane, the space and body centrodes are defined as:

Space Centrode (Fixed):

For the case of an overturning vehicle there are two phases to be considered: the airborne phase and the ground contact phase. As one would expect, the airborne phase of an automobile rollover accident is simply defined as those periods of time in which the vehicle is not in contact with the ground. During these intervals the vehicle travels with a constant horizontal velocity relative to a level ground plane (aerodynamic effects are assumed negligible) and will rotate at a constant angular velocity. The vertical motion (relative to the ground) is governed by gravity and the vertical velocity at separation from the ground, with the resulting vehicle center of gravity (CG) path being a parabolic arc.

The locus of ICs for the airborne phase of a rollover will be similar in form to that shown in Figure 10 (located at the end of the article). Though the vehicle rotates at a constant roll rate, the body centrode is not circular. In fact, it is oval in shape. When the vehicle reaches its apex on the parabolic CG path, the total vehicle velocity is less than it is at either end of the depicted path segment (vertical velocity component has diminished to zero), therefore, the body centrode radius of curvature, relative to the vehicle CG, is smallest at the apex and larger at either end of the depicted path segment. At larger roll rates, the body centrode will become more circular (the oval being less eccentric) and of smaller radius of curvature as the velocity component at the vehicle periphery becomes larger relative to the CG velocity. The change in elevation of the Body Centrode (Moving):

Equations 3 20

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

vehicle CG is reflected in the shape of the space centrode which mimics the shape of the ballistic CG path. At larger vehicle roll rates, the space centrode will move closer to the vehicle and become flatter (i.e., a larger radius of curvature).

represent vehicle motion somewhat interesting, and that an analyst might perhaps find this uncommon perspective of rigid-body motion useful in some way.

During automobile rollover accidents there are any number of occasions where the vehicle comes into contact with the ground. These contacts can involve wheels and tires, body components, and underbody components. The nature of any particular contact during the rollover phase depends on a variety of parameters including the vehicle translational velocity, rotational velocity, vehicle orientation, and surface condition.

1. Meriam, J.L. and Kraige, L.G., Engineering Mechanics, Volume 2: Dynamics, John Wiley and Sons, 1986.

A simple example of centrodes while in contact with the ground is shown in Figure 11 (located at the end of this article) where the roll rate of the vehicle increases during the ground interaction. The resulting centrodes are analogous to the reverse of the rolling-wheel-with-braking example presented above with the centrodes approaching the vehicle and ground surface as the roll-rate-to-translational-velocity ratio grows larger. The shape of the centrode pair will of course depend on the translational and angular velocities with the instantaneous center located at some position below the ground surface. It can be readily observed in the developing shape of the centrodes depicted in Figure 11 how they can transition to a form of the airborne phase centrodes depicted in Figure 10.

While centrode concepts have found use in areas such as machine linkage analyses, biomechanical joint analyses, and noncircular gear analyses, there has been little discussion of them in the open automobile accident investigation literature. Campbell et al. 4 briefly discussed the concept of centrodes in an accident reconstruction training reference manual for the National Accident Sampling System (NASS), presenting the simple example of a circular body centrode at the perimeter of a disk rolling on a straightline space centrode in the yaw plane, and noting in passing that the paths of various fixed points on the disk have a relationship to the tire marks of a skidding vehicle. While not discussing the centrode concept explicitly, Rapp van Roden and Zolock 5 nonetheless sailed in the offing of the topic by plotting IC positions in the body-fixed reference frames of their vehicles-of-study (body centrodes) in an effort to provide a qualitative understanding of free-particle trajectory shapes within vehicles involved in eccentric impacts (see references 6 and 7 for more on free-particle trajectory calculations). In this article several vehicle motion scenarios relevant to automobile accident reconstruction were presented vis-à-vis the centrode concept. It is hoped that the reader has found the use of centrodes to

References

2. Greenwood, D. T., Principles of Dynamics, 2nd Edition, Prentice Hall, 1988.

3. Marine, M., and Werner, S., “Delta-V Analysis from Crash Test Data for Vehicles with Post-Impact Yaw Motion,” Society of Automotive Engineers, Paper No. 980219, 1998.

4. Campbell, K., Cooley, P., Hess, R., Scott, R., Winkler, C., and McDole, R., “Training Materials for Accident Reconstruction Volume 1 – Reference Manual,” Highway Safety Research Institute, University of Michigan, Report No. UM-HSRI-79-27-1, 1979.

5. Rapp van Roden, E., and Zolock, J., “Using the Instantaneous Center of Rotation to Examine the Influence of Yaw Rate on Occupant Kinematics in Eccentric Planar Collisions,” Society of Automotive Engineers, Paper No. 2022-01-0826, 2022.

6. Wirth, J., Marine, M., and Thomas, T., “An Analysis of a Staged Two-Vehicle Impact,” Society of Automotive Engineers, Paper No. 2000-01-0464, 2000.

7. Smith, G., “Reconstructing Vehicle and Occupant Motion from EDR data in High Yaw Velocity Crashes,” Society of Automotive Engineers, Paper No. 2021-01-0892, 2021.

Figure 10: Body and Space Centrodes Rollover Example – Airborne

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 21

Figure 6: Body and Space Centrodes Example for a Yaw Plane Collision Phase

Figure 7: Body and Space Centrodes Example for a Yaw Plane Post-Collision (Separation) Phase 22

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Figure 9: Body and Space Centrodes Example for a Vehicle Driving Off a Cliff

Figure 11: Body and Pace Centrodes Rollover Example - Ground www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 23

Performance of BMW Event Data Recorder (EDR) in Instrumented Barrier and Vehicle-to-Vehicle Crashes Robert D. Anderson Biomechanics Analysis Michael Rosenfield RSR Engineering

24 Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

A

bstract

BMW automobiles have Event Data Recorder (EDR) functionality to record crash-related data that is retrievable using the Bosch Crash Data Retrieve (CDR) Tool going back to the 2013 model year. However, unlike most automobile brands, there have been few, if any, prior crash test demonstrations of the performance and behavior of BMW automobile EDRs. This research was conducted as part of the Canadian Association of Technical Accident Investigators and Reconstructionists (CATAIR) 2022 Crash Conference. A description of CATAIR’s 2022 crash test demonstration program is outlined in “CATAIR 2022 Crash Conference,” which is also in this issue of Collision. A 2016 BMW X5 sport utility vehicle was subjected to a series of seven low speed front- and rear-to-barrier tests, followed by a high-speed vehicle-to-vehicle crash demonstration. EDR-reported pre-crash speed, longitudinal and lateral vehicle acceleration, and longitudinal and lateral delta-V was compared to reference instrumentation. The EDR reported driver and front passenger seat belt buckle status was compared to the test configuration, the ignition cycles increment was tracked, and the rear-to-barrier impact resulted in the deployment of the BMW’s active head restraints (AHR).

Introduction Event Data Recorder (EDR) information from vehicles has become a common element in crash investigation and reconstruction analyses. As such, examples regarding the accuracy of EDR data are important to understanding how EDR data can fit into a situationally complete crash reconstruction analysis.

Passenger vehicles manufactured for sale in the United States after September 1, 2012, are subject to the provisions of Code of Federal Regulations (CFR) Title 49, Section 5631 (49CFR563 which may also be referred to as “Part 563”) requiring manufacturers of passenger cars, light trucks and SUVs who elect to install a device or function in a vehicle which meets the regulation’s definition of an “Event Data Recorder” (EDR) to record a specified set of data parameters and make the data access and retrieval publicly available. As a consequence of the Part 563 requirement that after September 1, 2012, a publicly available tool be in place within 90 days after the first sale of a vehicle equipped with an EDR, a number of automobile manufacturers’ vehicles, including BMW, became Bosch CDR supported beginning in the 2013 model year.

Literature Review Lawrence et al.2 compared three different 2002 GM vehicles' pre-crash speeds to 5th wheel data at various speeds. They concluded that the preevent speeds reported by Sensing Diagnostic Modules (SDMs) of some GM vehicles overestimated vehicle speed by up to 1.5 kph at low speeds and underestimated vehicle speed by up to 3.7 kph at high speeds. In a comparison of the SDM recorded pre-crash speed data during an acceleration maneuver case for a 2006 GMC Envoy Denali by Bare et al.3, the average error for each run was always less than 1.0 mph and the maximum error was 1.3 mph.

During acceleration and braking runs, the maximum difference in the SDM recorded vehicle speed data was 1.5 mph and the average error was within 0.8 www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 25

mph. Some of the differences in pre-crash vehicle speed data between the GM SDMs and reference instrumentation have been attributed to asynchronous data reporting, reporting resolution, rounding or truncating of reported data or wheel slippage during acceleration or braking4.

A 2008 Ford Focus and 2008 Ford Edge restraint control module (RCM) showed a maximum error between a VBOX reported speed and an RCM EDR recorded speed of −1.1 kph (−1.3%) and −0.9 kph (−1.1%), respectively.

The EDR reported pre-crash in 0.5 second increments, the accelerator pedal generally matched that reported on the CAN bus, and the average delay or latency for a change in brake switch status was 0.41 or 0.42 seconds5.

Ruth and Daily6 also studied a 2010 Ford Flex during steady-state and braking conditions. They found that under steady-state conditions the RCM EDR average underreporting error in speed was 1.4% and that the 99% confidence interval was within 2.5% at 113 kph. As previously reported, the average reporting error increased during deceleration due to the expected wheel slip during the hard braking maneuver. The EDR reported accelerator pedal tracked the CAN bus value, but due to being reported with less precision was accurate within 0.5%. The EDR reported pre-crash in 0.5 second increments, and the time between pedal contact to when the EDR reported brake on was relatively uniformly distributed between 0.05 and 0.5 seconds.

Ruth and Reust7 reported on the accuracy of two Chrysler ACM EDRs. The 2008 Jeep Commander ACM EDR speed data was within 1.5% of the VBOX data using a 3 sigma statistical criteria. The 2008 Dodge Dakota ACM event data was reported to be within −3.1 kph or −2.7% of the reference VBOX speed at highway speeds. At lower speeds, the absolute error was less but the percentage was higher. The error averaged approximately −2% of the speed being traveled. The EDR reported accelerator pedal position matched the pedal sensor output within 3.2% and the brake switch on was reported on the CAN bus within hundredths of a second. The largest delay or latency between when the brake switch is tripped and when brake on is reported in EDR data is due to time interval to the next EDR sample.

Bortolin et al.8 reported an average error of 1.11 mph and maximum error of 1.74 mph during steady state speed for a 2008 Dodge Grand Caravan.

The controller area network (CAN) data for a Mini Cooper was shown to overreport vehicle speed by as much as 3.7 kph at low speeds and under report by as much as 4.34 kph at higher speeds9. Mueller at al. concluded that 26

Collision Magazine - Volume 17 Issue 1

the Mini Cooper reported wheel speed was approximately 5% higher than the VBOX without heavy braking.

Testing of a 2010 Toyota Camry by Brown and White10 indicated that the High-speed CAN (HS-CAN) speed data was less than the actual speed by 2.7% during constant speed operation. Brown et al.11 provided data plots for pre-crash vehicle and engine speeds for a 2011 Toyota Camry, a 2010 Toyota 4Runner and a 2011 Toyota Prius.

They concluded that the Toyota EDR pre-crash data and other parameters were accurate when compared with the HS-CAN data; however nominal error rates were not reported. Ruth et al.12 reported errors for a 2010 Toyota Camry EDR pre-crash speed under steady-state conditions within +0.4 to −2.3 kph of the referenced GPS instrumentation. At 113 kph, the differences equated to +0.4%/−2.0%. They also reported error for a 2011 Toyota Camry EDR pre-crash speed under steady-state conditions to be +0.0 to −3.0 kph of the referenced instrumentation. At 113 kph, the differences equated to +0/−2.7%.

A comparison of J-NCAP EDR pre-crash velocity and the reported test velocity for 14 Toyota models was performed

by Takubo et al.13. In all cases the difference was less than 7% with an average of approximately 2% and root mean square of approximately 3%.

In 2013, Diacon, Ruth and Mueller14 tested and reported on the accuracy of vehicle speed reported by EDRs in a 2012 Honda CR-V and 2012 Honda Civic. The vehicle speed data from the CR-V EDR, when compared to a VBOX, under conditions of moderate acceleration and braking was +/- 1.15 kph with a mean of +0.033 kph and a standard deviation of 0.39 kph. Under steady state conditions the 2012 Civic vehicle speed CAN bus message (speed, vehicle indicated) accurately represented the vehicle ground speed. The EDR truncated the CAN speed to the next lower whole kph, resulting in the average GPSEDR difference being higher by approximately 0.5 kph, to a mean of +0.22 kph with a standard deviation of 0.33 kph. The range was from −1.38 kph to +1.95 kph. This corresponds to accuracy within about 2% at speeds near 100kph as tested with new, minimally worn tires.

In 2013, Vandiver, Ikram and Randles15 tested the accuracy of pre-crash speed recordings in a 2009 Mitsubishi Lancer GTS. They used a 4-wheel dynamometer to allow for the testing of accuracy under hard acceleration at speeds over 85 mph. When compared to the dynamometer, the Mitsubishi EDR tended to slightly overreport the vehicle speed by an average of 4.34%, but closely matched the speed being reported by the vehicle speedometer.

In 2014, Ruth and Tsoi16 tested the accuracy of EDR translations from 2010-2012 Kia and Hyundai vehicles

www.collisionpublishing.com

using the 2013 Hyundai and Kia EDR Tools manufactured by GIT. The data in these vehicles were accessed using various cables and by varying the year and model selections within the GIT software. A total of 56 ACMs were obtained from vehicles used in National Highway Traffic Safety Administration (NHTSA) New Car Assessment Program (NCAP) tests. Of those, 54 were able to be read and compared to data collected and documented in the testing reports published via NHTSA. The emphasis of this research was the accuracy of speed and Delta-V data due to the lack of data generated during the NHTSA testing related to other elements, including braking, engine rpm, throttle position, Anti-lock Braking System (ABS) activation, stability control and steering input. In 20 of 22 frontal tests examined, the reported speed was within ±4%. In Test 7612, involving a 2012 Kia Soul, the speed was underreported by -3.42 kph, a difference of -6.1%. The readings for longitudinal DeltaV in 20 of the 22 frontal tests were accurate to within -8% to +14% of reference and 19 of those 20 were within the ±10% normally ascribed to benchmark GM EDR DeltaV data (excluding clipping). Lateral Delta-V reported in the EDRs from side Moving Deformable Barrier (MDB) and side pole tests was generally proportional to reference, but several EDR data points reported outside the normal ±10% range.

In 2015, Vandiver, Anderson, Ikram, Randles, and Furbish tested and examined the accuracy of the crash data recorded in a 2012 Kia Soul, which was one year too old to be officially supported by the GIT Kia EDR tool. Vandiver, et al.17 found that the reported pre-impact speed, steering angle, engine speed, and brake switch status compared favorably with the data from the test instrumentation.

In 2021 Vandiver & Anderson reported that the accuracy of EDR reported speed and service brake status from the 2012 Hyundai Genesis, which was one year too old to be officially supported by the GIT Hyundai EDR tool was found to be properly recorded and retrievable using the GIT EDR tool.18 In 2022 Anderson & Vandiver19 reported that both GIT supported and pre-GIT supported Hyundai vehicles had the accuracy and behavior consistent with that which has become expected from post-part 563 supported vehicles.

The steering wheel angle, SRS warning light, longitudinal and lateral vehicle accelerations were not correctly translated in the pre-GIT supported Hyundai.

Hallman, Cox & Anderson20 reported in 2022 that the Nissan EDR’s appeared to record a non-deployment event based not based upon reaching a 5 mph delta-V, but rather when the initial accelerations are consistent with

Figure 1: The 2016 BMW X5 test vehicle www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 27

an impact that would reach 5 mph delta-V. In low speed impacts, the Nissan passenger car and SUV required an acceleration of 1 g in less than 30 msec to set a nondeployment event, and that the recorded accelerations missed some of the initial crash pulse and therefore the CDR reported Delta V could be under-reported.

In crash tests conducted at the 2022 and 2023 crash conferences by the Southwestern Association of Technical Accident Investigators (SATAI), Honda and Subaru vehicles were subjected to barrier and vehicle-to-vehicle testing.

Test Vehicles A 2016 BMW X5, VIN 5UXKS4C50G0N12870, pictured in Figure 1, was the test vehicle used in lowspeed front and rear to barrier crashes and in a high speed broadside to a 2006 Ford Freestar, VIN 1FMZK02146GA45543.

Equipment & Instrumentation

The BMW X5 was instrumented vehicle acceleration using an IST which is capable of collecting 3-axis accelerations with 100g range and at a sample rate of 3.2 kHz. A SlamStick S and a SlamStick X, which measure 3-axis acceleration and rotational rates were also used. The SlamSticks had a 500g range for their DC accelerometer, the sample rate for the SlamStick S was 10 kHz and the sample rate for the SlamStick X was 3.2 kHz. Video was obtained with a Racelogic Video VBOX HD. This system collects GPS data for location and speed and allows for 1080p video from one or two cameras to be synced with the collected data.

The Video VBOX HD collects, calculates and records speed at 10 Hz based upon the doppler shift of GPS satellite radio signals. When average over four samples, the reported accuracy is ± 0.06 mph for speeds up to 1000 mph.

Video of the crashes was also obtained from ground-based cameras, and from aerial drones.

Figure 2: Rear-to-barrier configuration for the BMW X5 28

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Before the test series, a baseline EDR download was obtained, and an EDR download was obtained after each test using version 21.5.1, which was the current version of the Bosch Crash Data Retrieval (CDR) Tool.

For the final test, a Phantom Driver remote-driving system was installed in the BMW X5 so that it could be driven up to a speed of 76 mph, as shown in the Video VBOX output shown in Figure 3, before broad-siding the Ford’s right rear side.

There were not any changes or updates in the translation through Version 23.1.1, which was the current version of the Bosch CDR software at the time of the writing of this paper.

Crash Test Results The baseline CDR report contained “Record 1, Most Recent”, which was an impact that occurred while the vehicle was traveling at 22 mph, slowing it by 4.3 mph, and pushing it laterally at 2.5 mph. This non-deployment event is generally consistent with the right front damage to the test vehicle, which would have slowed as evidenced by the front to rear deformation of its fender seen in Figure 4, as well as pushed the vehicle to its right, as evidenced by the left-to-right shift of the hood also shown in Figure 4.

Crash Tests The BMW X5 was driven using a seat-belted human driver forward and rearward into a line of concrete barriers, which were connected end-to-end, as shown in Figure 2. The uninstrumented driver and front passenger were wearing the lap and shoulder belts for all barrier tests.

For the front-to-barrier impacts, there was also an unrestrained occupant seated in the right rear.

Non-deployment record threshold: as shown in Table 1, the highest delta-V from a frontal barrier impact that did not set a non-deployment event was -4.6 mph and the lowest delta-V that set a non-deployment event was -6.3 mph. The final rear-to-barrier impact produced a +6.7 mph, which not only set a non-deployment event, but it also deployed the active head restraints.

For the rear-to-barrier impact, the rear seat occupant replaced the right front seat occupant from the frontal impact tests. The barrier impact direction, impact speed, delta-V and EDR event for the low-speed barrier impacts is shown in Table 1.

Barrier

VVBox Speed (mph)

Delta-V (mph)

EDR Event

Test 1

Front

3.6

-2.7

-

Test 2

Front

3.6

-3.6

-

Test 3

Front

3.8

-4.3

-

Test 4

Front

4.6

-3.8

-

Test 5

Front

6.4

-4.6

-

Test 6

Front

10.5

-6.3

ND

Test 7

Rear

8.9

6.7

Deploy

Table 1: Low speed barrier testing www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 29

Figure 3: Video VBOX speed, orientation and location of the BMW's impact with the Ford

Figure 4: The BMW X5’s pre-existing damage 30

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Figure 4: The BMW X5’s pre-existing damage

Figure 5: The BMW’s pre-crash speed versus VBOX speed in Test 6 www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 31

Pre-crash speeds: the BMW’s CDR report gives pre-crash data in half-second increments. The CDR-reported crash

speeds are plotted against the reference VBOX speeds for Test 6, Test 7, and the Broadside Test in Figures 5, 6 and 7.

Figure 6: The BMW’s pre-crash speed versus VBOX speed in Test 7

Figure 7: The BMW’s pre-crash speed versus VBOX speed in Broadside Test 32

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Vehicle Acceleration: the BMW’s CDR report includes both longitudinal (x) and lateral (y) acceleration.

The comparison between x and y acceleration reported by the CDR and measured by reference instrumentation for Test 6, Test 7 and the Broadside Test are shown in Figures

Figure 8: X and Y acceleration versus the reference SlamStick accelerations in Test 6 www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 33

Figure 9: X and Y acceleration versus the reference SlamStick accelerations in Test 7 34

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Figure 10: X and Y acceleration versus the reference SlamStick accelerations in Broadside Test www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 35

8, 9 and 10. The data in the graphs follow SAE J211 polarity and the reference accelerations were filtered at CFC 60.

Delta-V: the BMW’s CDR report includes both longitudinal (x) and lateral (y) delta-V. The comparison between x and y delta-V reported by the CDR and measured

Figure 11: X and Y delta-V versus the reference SlamStick delta-V in Test 6 36

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Figure 12: X and Y delta-V versus the reference SlamStick delta-V in Test 7 www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 37

Figure 13: wX and Y delta-V versus the reference SlamStick delta-V in Broadside Test 38

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

by reference instrumentation for Test 6, Test 7 and the Broadside Test are shown in Figures 11, 12 and 13.

Events stored: after Test 6, the non-deployment event from Test 6 became the new Record 1, Most Recent, and the pre-existing recording became Record 2. Following Test 7, the event from Test 7 became the Record 1, Most Recent, Test 6 became Record 2, and the pre-existing event was Record 3. After the BMW broadsided the Ford, that event became Record 1, Most Recent, Test 7 became Record 2, Test 6 became Record 3, and the pre-existing recording became Record 4.

Deployment events: the CDR report after Test 7 does not indicate that the front seat active head restraints were deployed. The broadside to the Ford produced driver’s frontal, knee bolster and side curtain deployments and the CDR report indicated deployment times. There is not any other indicator that the broadside crash was a deployment event.

Ignition cycles: the pre-existing event occurred on ignition cycle (IC) 7,603 and the baseline download was on IC 7,698. Following each test, the BMW’s engine was shut off at least once, after most tests the doors were opened and closed and in one instance the FOB (with dead battery) was carried about 30 yards away. In spite of this, throughout testing, very few IC increments occurred.

The CDR reports obtained after Tests 1 through 4 showed the IC at download as 7,699. After Tests 5 through 7, the IC at download was 7700, so that according to the CDR report, the download occurred on the same IC as Records 1 and 2 from Tests 6 and 7. After the BMW broadsided the Ford, the IC at download was 7,707 and the IC of that crash was reported as 7,706.

Seat belt buckle status: the non-deployment events from Tests 6 and 7 correctly reported that the driver and front passenger were belted. In the broadside collision, the driver was correctly listed as belted, and the right front was listed as unbelted. In this test, the right front seat was unoccupied and the CDR report for Occupant Size Classification, Front Passenger (child) was reported as “Unknown.”

where the impact was similar to a low-speed broadside impact, where the bullet vehicle’s delta-V was not only dependent on the impact speed, but it was also depended upon the mass and lateral friction of the barriers on the roadway.

The BMW’s pre-crash speeds correlated well with the speeds from the reference instrumentation, which was the Racelogic Video VBOX HD. In the Broadside Test, the CDR reported speeds are seen to generally over-report the vehicle’s actual speed. At T0/impact, the speed was overreported by 3 mph. This could be a result of the vehicle accelerating maximally during the pre-crash record, and/ or the speedometer’s setting to slightly over-report vehicle speed.

The reference VBOX and CDR reported speeds only report positive speed values. Therefore, like CDR reports from other automobile manufacturers that do not report gear selection, it cannot be discerned from the BMW’s CDR report if the direction of travel in the pre-crash data was forward or backward.

As evident in Figures 8 through 10, the CDR reported longitudinal and lateral vehicle acceleration appeared to generally track the readings from reference instrumentation. However, with a resolution that is in 3 g increments, this representation is somewhat poor. However, as might be expected, a better representation was obtained with the higher readings of the Broadside Test. Perhaps it is important to recognize that the CDR reported delta-V’s cannot be obtained by integrating the CDR reported accelerations due to their coarse resolution. This indicates that delta-V reported in the CDR report is obtained by integrating higher resolution acceleration data that may have a higher sample rate as well.

Discussion

The BMW’s lack of a CDR recording in a 4.6 mph magnitude delta-V impact and CDR recording in a 6.3 mph magnitude delta-V impact is consistent with 5 mph deltaV being the record threshold, as it has been demonstrated in crash testing of virtually all other post-563 vehicles tested. Indeed, the data limitations specify that “a NonDeployment Event is recorded if the change in longitudinal or lateral velocity equals or exceeds 8 km/h over a 150 ms timeframe.”

Although the concrete barriers were connected end-toend, the barriers were observed to scoot on the asphalt with each impact. This had the effect of reducing the restitution, or bounciness, of the impact and allowed the magnitude of the delta-V to be less than the impact speed, rather that higher, as is typical of impacts with immovable infinitely massive barriers. This produced a situation

Unlike the CDR reports from other automobile manufacturers, the BMW does not label events as deployment or non-deployment events. Airbag and seat belt pre-tensioner deployments are indicated by their time deployment commanded. However, the active head restraint (AHR) deployment was physically evident, but the CDR report does not indicate activation of the front seat AHRs.

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 39

Consistent with observations of testing with other AHR equipped vehicles, such as the Jeep Grand Cherokee at the 2012 ARC-CSI crash conference, the deployment of the BMW’s AHRs in a 6.7 mph delta-V impact is consistent with an AHR deployment threshold of 5 mph delta-V. Attempts to reset AHRs were unsuccessful as they appeared to be a single activation system.

Conclusions

In keeping with the concept that live humans can safely be subjected to frontal impacts with delta-V’s up to 20 mph21,22,23,24 and rear-end impacts up to about 10 mph 21,25,26,27,28,29,30,31,32 , the barrier tests with live human occupants were planned and executed to produce vehicle velocity changes with magnitudes of less than 10 mph.

The test results are also consistent with the activation threshold of the active head restraints (AHRs) was also about 5 mph delta-V, as has been observed in other rearend impact testing.

The CDR reported delta-Vs reasonably represented the reference delta-Vs for the resolution of the data, which was in 1 kph or 0.6 mph increments, as evident in Figures 11 through 13. The best representation was the longitudinal delta-V from the Broadside crash and the worst representation was the lateral delta-V from the Broadside crash. The reason for the poor representation of the lateral delta-V may be due to the impact induced vehicle rotation combined with the difference in location between the ACM and the reference instrumentation. Overall, the accuracy of the CDR reported delta-Vs was comparable to other manufactures’ and within the typical tolerance in accident reconstruction and biomechanical analyses.

Although it is unknown how the BMW was handled after it sustained the right frontal damage associated with the pre-existing CDR recording, the number of ignition cycles (IC) from that event to the baseline CDR report was not unusual of that observed in case work in these authors’ experience. During the test series the ICs did not increment as expected, even when the FOB was taken away from the BMW’s immediate area. However, between the barrier testing and the Broadside Test, the IC’s incremented in an expected way. As such, it appears that the abnormal IC incrementing during the barrier testing was some artifact of the testing and/or the key FOB’s low or dead battery.

Although not measured independently, CDR reported the accelerator pedal and steering wheel angle appeared to have the appropriate magnitude and polarity. Similarly, the timing of brake pedal on/off appeared to be correctly correspond with the testing scenarios.

The comparison between the CDR pre-crash and crash data from the BMW and the reference instrumentation and observations is generally within that observed from other manufacturers’ supported vehicles. Perhaps it is fair to expect this for post-part 563 automobiles.

40

Collision Magazine - Volume 17 Issue 1

The test results are consistent with the non-deployment record threshold being a delta-V with a magnitude of 5 mph, as specified in the BMW’s data limitations and as observed in virtually all, if not all, testing of post-part 563 automobiles.

The CDR reported vehicle speeds and delta-Vs reasonably represented the vehicle delta-Vs and speeds obtained from the referent instrumentation.

The CDR reported vehicle accelerations generally tracked the accelerations from the reference instrumentation, but the CDR reported accelerations had coarse resolution and were not of sufficient quality to be usable to calculate the vehicle delta-Vs. Therefore, the CDR reported delta-Vs are evidently calculated from acceleration data that has higher resolution and possibly higher sampling rate.

Except during the barrier testing, the BMW’s ignition cycle count appeared to increment correctly.

Although not measured independently, the CDR reported accelerator pedal, steering wheel angle and brake pedal on/off appeared to correctly coincide with the circumstances of the testing.

The accuracy and behavior of the BMW EDR was consistent with that which has become expected from the post-part 563 supported vehicles from other automobile manufacturers.

References 1.

“49CFR563”; 49CFR563 – EVENT DATA RECORDERS. NHTSA, 1 Oct. 2011. Web. 13 Dec. 2014; http://www.gpo.gov/fdsys/granule/CFR-2011-title49vol6/CFR-2011-title49-vol6-part563/content-detail. html 2.

Lawrence, J., Wilkinson, C., Heinrichs, B. and Siegmund, G. “The accuracy of pre-crash speed captured by event data recorders,” SAE technical paper 2003-010889, 2003.

3.

Bare, C., Everest, B., Floyd, D. and Nunan, D. “Analysis of pre-crash data transferred over the serial data

www.collisionpublishing.com

bus and utilized by the SDM-DS module,” SAE technical paper 2011-11-0809, 2011, doi:10.4271/2011-01-0809.

work (CAN) Traffic,” SAE Int. J. Trans. Safety 1(2):399419, 2013, doi:10.4271/2013-01-1264.

4.

Wilkinson, C., Lawrence, J., Heinrichs, B. and King, D. “The timing of pre-crash data recorded in General Motors sensing and diagnostic modules,” SAE technical paper 2006-01-1397, 2006.

15.

Vandiver, W., Ikram, I., and Randles, B., “Accuracy of Pre-Crash Speed Recorded in 2009 Mitsubishi Lancer Event Data Recorders,” SAE Technical Paper 2013-01-1263, 2013, doi:10.4271/2013-01-1263.

5.

Ruth, R., West, O. and Nasrallah, H. “Accuracy of selected 2008 Ford restraint control module event data recorders,” SAE technical paper 2009-01-0884, 2009.

16.

Ruth, R. and Tsoi A. “Accuracy of Translations Obtained by 2013 GIT Tool on 2010-2012 Kia and Hyundai EDR Speed and Delta V Data in NCAP Tests,” SAE technical paper 2014-01-0502, 2014, doi: 10.4271/2014-01-0502.

6.

Ruth, R. and Daily, J. “Accuracy of event data recorder from 2010 Ford flex during steady state in braking conditions,” SAE technical paper 2011-01-0812, 2011, doi: 10.4271/2011-01-0812.

7.

Ruth, R. and Reust, T. “Accuracy of selected 2008 Chrysler airbag control module event data recorders,” SAE technical paper 2009-01-0877, SAE Int. J. Passeng. Cars – Mech Syst., Volume 2, Issue 1, 2009.

8.

Bortolin, R., Gilbert, D., Gervais, J. and Hrycay, J. “Chrysler airbag control module (ECM) data reliability,” SAE technical paper 2010-01-1002, 2010.

9.

Mueller, C., Daily, J. and Papa, M. “Accessing the accuracy of vehicle event data based on CAN messages,” SAE technical paper 2012-01-1000, 2012, doi:10.4271/2012-01-1000.

10.

Brown, R. and White, S. “Evaluation of Camry HS-CAN pre-crash data,” SAE technical paper 2012-010996, 2012, doi:10.4271/2012-01-0996.

11.

Brown, R., Lewis, L., Hare, B., Jakstis, M., Landis, R., Clyde, H. and Buetzer, R. “Confirmation of Toyota EDR pre-crash data,” SAE technical paper 2012-010998, 2012, doi:10.4271/2012-01-0998.

12.

Ruth, R., Bartlett, W. and Daily, J. “Accuracy of event data in the 2010 and 2011 Toyota Camry during steady-state and braking conditions,” SAE technical paper 2012-01-0999, SAE Int. J. Passeng. Cars – Electron. Syst., Volume 5, Issue 1 (May 2012), 2012, doi:10.4271/201201-0999.

13.

Takubo, N., Hiromitsu, T., Kato, K., Hagita., Oga, R., Kihira, M. and Yamasaki, T. “Study on characteristics of event data recorders in Japan; analysis of J-NCAP and 13 crash tests,” SAE technical paper 2011-01-0810, 2011, doi:10.4271/2011-01-081.

14.

Diacon, A., Daily, J., Ruth, R., and Mueller, C., “Accuracy and Characteristics of 2012 Honda Event Data Recorders from Real-Time Replay of Controller Area Net-

17.

Vandiver, W., Anderson, R., Ikram, I., Randles, B. et al., “Analysis of Crash Data from a 2012 Kia Soul Event Data Recorder,” SAE Technical Paper 2015-011445, 2015, https://doi.org/10.4271/2015-01-1445.

18.

Vandiver, W., and Anderson, R., “Analysis of Crash Data from a 2012 Hyundai Genesis Coupe Event Data Recorder,” SAE Technical Paper 2021-01-0905, 2021, https://doi.org/10.4271/2021-01-0905.

19.

Anderson RD & Vandiver W, “Analysis of the Event Data Recorder Information Obtained in Crash Testing of Supported and Pre-Supported Hyundai Vehicles: a 2015 Elantra Sedan and a 2012 Genesis Coupe,” Collision, The International Compendium for Crash Research, Volume 16, Issue 1, 2022.

20.

Hallman DM, Cox BS & Anderson RD, “Nissan Automobile EDR Recording Characteristics,” Collision, The International Compendium for Crash Research, Volume 16, Issue 2, 2022.

21.

Collision Reconstruction for the Medical Practitioner, Texas A&M University, Texas Engineering Extension Service (TEEX), 1998.

22.

Wagner R, “A 30 mph Front/Rear Crash with Human Test Persons,” SAE paper 791028, Proceedings of 23rd Stapp Car Crash Conference, Society of Automotive Engineers, 1979.

23.

Vandiver W & Anderson RD, “Analysis of Crash Data from a 2012 Hyundai Genesis Coupe Event Data Recorder,” Society of Automotive Engineers, Paper 202101-0905.

24.

Anderson RD & Vandiver W, “Analysis of the Event Data Recorder Information Obtained in Crash Testing of Supported and Pre-Supported Hyundai Vehicles: a 2015 Elantra Sedan and a 2012 Genesis Coupe,” Collision-The International Compendium for Crash Research, Vol 16, Issue 1, 2022.

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 41

25.

Szabo TJ and Welcher JB, “Human Subject Kinematics and Electromyographic Activity During LowSpeed Rear Impacts,” SAE paper 962432, Proceedings of the 40th Stapp Car Crash Conference, Albuquerque, NM, November 1996.

26.

McConnell WE, Howard RP, Poppel JV, Krause R, Guzman HM, Bomar JB, Raddin JH, Benedict JV, and Hatsel CP, “Human Head and Neck Kinematics After Low Velocity Rear-End Impacts - Understanding ‘Whiplash’,” SAE Paper 952724, Proceedings of the 39th Stapp Car Crash Conference, San Diego, CA, November 1995.

27.

West DH, Gough JP and Harper GTK, “Low Speed Rear-end Collision Testing Using Human Subjects,” Accident Reconstruction Journal, May/June 1993.

28.

Szabo TJ and Welcher JB, “Human Subject Responses to Various Acceleration Fields,” Presented at the Low-Speed Collision TOPTEC”, Society of Automotive Engineers, Vancouver, BC, August 1996.

vention, Diagnosis and Treatment of Cervical Whiplash Syndrome, Robert Gunzberg and Marek Szpalski, ed., Lippencott-Raven, Philadelphia, 1998.

30.

Mills D & Carty G, “Comparative Analysis of Low-Speed Live Occupant Crash Test Results in Current Literature,” Proceedings of the Canadian Multidisciplinary Road Safety Conference XIV; June 27-30, 2004; Ottawa, Ontario.

31.

Lam, T. and Ivarsson, B., "Vehicle Rear Impacts and Spinal Disc Herniations in Occupants: Is there a Basis for Causation?" SAE Paper 2017-01-1458, 2017, doi:10.4271/2017-01-1458.

32.

Cormier J, Gwin L, Rienhart L, Wood R & Bain C, “A Comprehensive Review of Low-Speed Rear Impact Volunteer Studies and a Comparison to Real-World Outcomes,” Spine, DOI: 10.1097, PMID 29489567, ISSN 0362-2436, Feb 2018.

29.

Meyer S, Weber M, Castro W, Schilgen M and Peuker C, “The Minimal Collision Velocity for Whiplash,” in Whiplash Injuries: Current Concepts in Pre-

To register and find more imformation about the summit, please go to: collisionpublishing.com and click on EDR Users summit. Those qualified to attend the CollisionSafety Institute’s Technician Train-The-Trainer Course will have that opportunity February 4,2024.

42

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 43

Personally Identifying Information -Katarina Juric

44

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

A

ll data that might be used to identify a specific person is considered personally identifying information (PII). In order to successfully identify a person, PII may be used alone or in conjunction with other pertinent data. It may include direct identifiers, like passport information, which can uniquely identify a person, as well as quasi-identifiers, like race, which can be combined with other quasi-identifiers, like date of birth, to successfully identify an individual.

As the legal system in the USA is built of diverse regulations and different federal and state laws, the definition of PII is not as consistent or a structured as the personal data established in the GDPR1 for the countries in the European Union. To begin with, it is challenging to distinguish between PII and personal data because PII is defined by numerous laws, rules, and policies, including: Act concerning Health Insurance Portability; American Labor Department Federal Trade Commission; Act Protecting Children’s Internet Information; American National Standards Institute.

Different sources define PII or particular components of it. When it comes to really establishing a list of minimum things that should be anonymized and what constitutes private, personal data, this leads to a lot of minute variances. Due to the fact that the European rule includes the connection between the personal data and an identifiable individual, which is frequently not as obvious, the GDPR’s definition of personal can occasionally appear wider than the definition of Personally Identifiable Information in the US. Any data that may be used to directly or indirectly identify a person is considered personally identifiable information.

The most practical way to determine what information is and isn’t Personal Identifying Information in practice is through individual assessment and paying attention to the procedure, law, regulation, or standard governing your particular State, industry, or field of application. Some examples of PII include the subject’s full name, phone number, passport number, residential address, social security number, driver’s license number, email address, and other digital information like IP address and geolocation. Some things, such as biometric data or medical information, are regarded as sensitive data. Yet, when contrasted to the GDPR’s definition of personal data, this can be somewhat ambiguous. Certain PII definitions in the US exclude IP addresses and cookie IDs, which directly contradicts the GDPR definition.

The GDPR offers standards for businesses and organizations regarding how they should manage data pertaining to the people they engage with. It has made it simpler

for EU citizens to comprehend their rights with regard to how their personal information should be utilized. According to the GDPR, information is considered “personal data” if it can be used to directly or indirectly identify a specific person, including through the use of online identifiers like their name, an identity number, IP addresses, or geographical information.

If online identifiers reveal details on a person’s physical, physiological, genetic, mental, economic, cultural, or social identity. In some cases, even details about a person’s occupation, hair color, or political views may qualify as personal data. The environment in which the data was gathered and whether a data subject might be directly or indirectly identified usually determine this. Most people think of phone numbers and addresses when they think of personal data, however there are many different identifiers that might be considered personal data.

GDPR-related personal data does not include: information pertaining to a deceased person, proper anonymization of the data, information on businesses and government entities.

Anonymization and Pseudonymization When data is made anonymous, it loses its personal nature because it is no longer possible to identify a specific person. But in order for data to actually be anonymous, anonymization must be permanent. Personal data still includes information that can be used to re-identify an individual even after it has been encrypted, de-identified, or pseudonymized. In order to provide the European Union with a unified set of privacy laws, the GDPR was introduced in 2016.

Only retain this data for as long as it serves its intended purpose. This information should also be encrypted and/ or pseudonymized, especially if it is considered sensitive data. Pseudonymization is the process of masking data by swapping out any identifying or traceable information with made-up identifiers. Pseudonymization has several limitations, despite the fact that it can be a fantastic approach to safeguard the confidentiality and privacy of personal data. Although a person cannot be directly identified from pseudonymous data, they can directly identified from pseudonymous data, they can still be indirectly identified rather readily.

Any information related to a person’s friends list or login details on social media. Radio frequency identification (RFID) codes—RFID chips typically include an easily recognizable, singular number that distinguishes any item to which it is attached and can be used to identifytify a

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 45

person. By substituting different pieces of data for unique identifiers, By uniqueidentifiers, it masks personal information. However, encryption only permits authorized users to view the entire data set, in contrast to pseudonymization, which enables anybody with legal access to the data to view a portion of the data set. Many firms decide to employ both anonymization andpseudonymization to safeguard their data subjects2.

Car Crash Investigation

In order to reconstruct the accident, camera footage from both inside and outside of the Uber, along with information on the driving behavior of the car, were crucial.

Even while the volume of data on this incident may have seemed extraordinary, it may soon become the standard.

This is due to the requirement under Article 6 of General Safety Regulation (EU)4, also known as GSR, that all cars have an Event Data Recorder or EDR5 by the year 2022. Such an EDR gathers information on things like the car’s speed and braking right before, during, and after a collision. The public prosecutor, litigants, and national authorities may find these data relevant.

We will first provide a broad review of the GSR and the expected functions of EDRs in order to identify these data protection issues. The relationship between the GSR’s data protection articles and the General Data Protection Regulation is then covered. The so-called Vision Zero initiative of the European Commission from 2018 calls for a reduction of traffic fatalities to zero by the year 2050.

Collision Magazine - Volume 17 Issue 1

The investigation into the fatal Uber accident serves as an example of the value of EDRs: the data from the vehicle’s EDR proved to be a crucial source of information on how the vehicle operated and the circumstances in which the accident occurred, enabling the detection of software flaws and the subsequent implementation of changes to increase the safety of the vehicle.

Crash Data Protection Issues

A required event data recorder is one of the new automotive safety features included by the new EU General Safety Regulation (EDR). Data protection issues are raised by the introduction of the EDR. This essay contends that while it is commendable that the General Safety Regulation includes data privacy regulations, doing so unnecessarily complicates issues. In 2018, a pedestrian was struck by a self-driving Uber test vehicle and suffered fatal injuries3.

46

The European Union has established new car safety standards in the GSR. New vehicles will be required to have systems like an alcohol interlock installation facilitation, driver sleepiness and attention warning, enhanced driver distraction warning, an emergency stop signal, and an event data recorder starting on July 6th, 2022. The EU hopes to avert 24,794 fatalities and 140,740 serious injuries in road traffic during a sixteen-year period with the help of these new regulations. The Event Data Recorder is made a requirement in all new vehicles by the GSR. The EDR may aid in achieving Vision Zero’s objectives since it collects crash data that can be used to identify flaws in vehicle and ecosystem design as well as assist accident investigators in determining the cause of an accident.

Examining the GDPR, the EU’s lex generalis for data protection, is crucial to fully understand these efforts because it governs all processing of information relating to an identified or identifiable person. The GDPR is applicable because the GSR-required technologies track motorists until fully autonomous vehicles become a reality. In addition to establishing rights and obligations, it also sets a number of principles, the two most important of which, purpose limitation and data minimization.

But first, it’s important to take into account the notion of lawful processing. Hence, processing can only be allowed if it has a GDPR Article 6. This indicates that there is a legal basis for any processing necessary to comply with the GSR. Yet, the aforementioned methods also determine if drivers are “in a fit physical and mental condition to drive” and “have the physical and mental ability” to do so.

Processing of the data is banned because it relates to personal health information. Where there is a foundation under Union or member state law, this prohibition is exempted under Article 9 of the GDPR7. To qualify for this exception, the law in question must ‘provide for sufficient and particular safeguards to safeguard the basic rights and interests of the data subject’. Thus, a comprehensive analysis of the GSR is necessary.

The GDPR has already been incorporated into the GSR by the European Parliament8. Any processing of personal

www.collisionpublishing.com

data, including information about the driver processed in event data recorders or information regarding the driver’s drowsiness, is prohibited, according to Recital 14 of the GSR. The GSR’s Article 6 restricts the use of personal data for processing to accident research and analysis, including for the purposes of type approval of systems and components. After the goal has beachieved recorded personal data shall also be promptly erased.

About the author: Katarina Jurić from Belgrade is a senior law student at the University of Belgrade. Her areas or interest include international law, arbitration, and human rights. She has participated in model United Nations forums as a Delegate and once as Chairperson.

In the US, realtive to the EU, the idea of

References 1. Regulation, General Data Protection. https://gdprinfo.eu/ 2. Pseudonymization and Anonymization of Personal Data. https://complior.se/pseudonymization-and-anonymization-of-personal-data-what-is-the-difference/ 3. 2018 Uber Crash. https://www.wired.com/story/uberself-driving-car-fatal-crash/ 4. Annex II to Regulation (EU) 2018/858 is amended in accordance with Annex III. https://members.wto.org/ crnattachments/2021/TBT/EEC/21_0621_00_e.pdf 5. Recorder, Even Data. https://www.nhtsa.gov/researchdata/event-data-recorder 6. Lawfulness of Processing. https://gdpr-info.eu/art-6gdpr/ 7. Processing of Special Categories of Personal Data. https://gdpr-info.eu/art-9-gdpr/. [Online] 8. What is the difference between personally identifiable information (PII) and personal data? https://techgdpr. com/blog/difference-between-pii-and-personal-data/

www.collisionpublishing.com

protecting Personally Identifying Information (PII) on the scale it is seen in the EU is relatively new. Apart from California’s “ California Consumer Privacy Act (CCPA).“ There are no specific state regulations associated with PII as seen in the EU and California. Personally, identifiable information is defined by the US Office of Privacy and Open Government as: “Information which can be used to distinguish or trace an individual’s identity, such as their name, social security number, biometric records, etc. alone, or when combined with other personal or identifying information which is linked or linkable to a specific individual, such as date and place of birth, mother’s maiden name, etc.”

This article is an overview of PII, chiefly in Europe, such that North American readers might identify trends which could, in the near term, effect the data we alredy develop during crash investigations.

Collision Magazine - Volume 17 Issue 1 47

THE EDR USER’S SUMMIT™ RETURNS “FEBRUARY 2024!”

February 5-7, 2024. Moving to a different hotel but still near Houston’s Bush Intercontinental airport, the EDR User’s Summit will pick up where we left off before the lockdowns bringing back the only true wide ranging EDR data-centric Summit to be found anywhere. Do not miss EDR User’s Summit 2024!

Check out the Data Analysis Optional Add-On Session for Toyota Vehicle Control History (VCH – “Techstream”) At the Summit, Russ Casella, a Toyota in-service trainer, will cover Toyota VCH data in Techstream for all users in a general session. For a deeper dive, join the optional post-Summit workshop after the Summit on 2/7, 1:30–4 PM, where Russ explores detailed VCH data with hands-on applications. Bring your laptop for a unique Techstream training experience!

48

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

To register and find more imformation about the summit, please go to: collisionpublishing.com and click on EDR Users summit. Those qualified to attend the Collision Safety Institute’s Technician Train-The-Trainer Course will have that opportunity February 4,2024.

Shanon Burgess

Bill Rose

This timely and thorough presentation is an examination of the various types of data that can be extracted from smartphones, including location (GPS and speed) information, call logs, text messages, app usage, device activity, and sensor data followed by a look at recent testing to examine the connection between mobile device use and the EDR data date/time stamp such as that found in the GM FCM or ASCM systems.

Bill Rose from Bosch will present in this longstanding feature of the EDR User’s Summit™, this is an in-depth overview of what’s new and what may be coming soon to the Bosch Crash Data Retrieval tool. Will there be new system coverage? What is going on with the possible GUI revision? How will changes in the CDR Tool process impact how I use the tool in the field? Attendees can expect this and more!

Don Floyd

What’s New with GM EDRs 2024. Covering new GM system supported by the Bosch CDR tool, what Bosch interface to use with the new supported modules (CANPlus vs CDR 900), this presentation will cover: Pedestrian Protection System, SDM-50 Airbag Control Module, Active Safety Control Modules, and Forward Camera Module. Learn more about what parameters can be recorded, what are the event recording triggers, what are the event overwrite conditions, and the Active Safety Control Module and Front Camera Module data collection and image handling operations.

Charles Getz

Heavy Vehicle EDRs are continuously evolving. This presentation will cover the latest developments in the HVEDR world. Topics will include the newly released systems in Detroit Diesel, Paccar, Mack, and Volvo.

Electric truck data will also be discussed.

Using GM Active Safety Module EDR Data with Case Examples. Learn more about the operation of GM Active Safety Systems supported by the Bosch CDR tool. Hear from a subject matter expert how to effectively manipulate vast quantity of Active Safety Control Module and Forward Camera Module EDR data and how to apply it in real-world case examples.

As a long-time Toyota inhouse trainer heavily involved in Techstream and Vehicle Control History, Russ will be sharing his wealth of information on the best ways to access and use VCH data.

Don Phillips

Working with Nissan crash data and something doesn’t “look right...” the delta-V polarity seems backwards, data elements are marked “clipped” but the sensors must be able to measure more than the data shows. This presentation will look at documented methods of identifying where Nissan data polarity is reported backwards and what “CLP” really means - and doesn’t mean.

Tommy Beetham

Russell Casella

Shawn Gyorke

Shawn is arguably the most well known go-to source for everything related to Hyundai and Kia EDR data and will share a bit about changes to the system and interesting data sets as seen in real-world applications.

Chris Medwell

A case study where Pre-Crash “Speed, Vehicle Indicated” was misreported by 50% and how the author was able to identify and create a test method for that anomaly and then where that error was corrected in the CDR Tool Software.

Ramon Homan

Presenting a unique look at Automated Traffic Signal Performance Measures and data sets captured by state traffic control authorities which might augment EDR data.

Wes Vandiver

Vehicle data useful to crash investigators can go beyond the traditional evidence found in airbag control modules. This presentation on Vehicle System Forensics will discuss the acquisition of data elements such as vehicle speeds, historical locations, connected devices, events, and system configurations that can be acquired from modern vehicles.

W. R. Rusty Haight

What do terms in Tesla CAN Bus data sets really mean? What is the range for the parameters? Will the CAN bus data elements be the same across all Tesla models? How does one get CAN bus data in the first place? These aspects and more of the increasingly common Tesla CAN data isn’t well understood or documented. This presentation looks to change that.

Tim Reust

Jason Chilson

Tim’s presentation will focus on Toyota Safety Sense (TSS) Testing and the results of over 65 instrumented tests conducted to trigger the Pre-Collision System resulting in PCS, Sudden Braking History and ABS Operation records.

Tests were conducted at speeds between 25 to 70 mph.

Jason will explore case studies looking at GM’s Frontview Camera Module (FCM) data and photos in practical application real-world scenarios and then associate that analysis with testing examples. His practical approach will go hand-in-hand with the other active safety systems presentations and offer a different perspective on the data and its application.

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 49

50

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Trigger counts marked “Invalid” in Toyota EDR data - Part 1 - W. R. “Rusty” Haight

- Collision Safety Institute

T

oyota Event Data Recorder (EDR) data first became accessible using the Bosch Crash Data Retrieval (CDR) Tool with the release of CDR software version 4.0 in March 20111. Toyota data translation reports generated from the retrieved data have generally included a unique data element; one not found in the same way in data translation reports from other manufacturers’ systems: a “trigger count.”2 The “Trigger Count”2 as seen in Toyota data translation reports is normally identified by the acronym “TRG” as found in the element identifier “TRG Count” or in the normal numbering convention TRGn (i.e.: TRG2, TRG11, or TRG65). In some Toyota data translation reports, end users have found that the numbering convention appears to have failed and the TRG number is instead marked “Invalid” or, in some cases, “N/A.” Figures 1 and 2 are offered as examples of how that “TRG Count” may be observed to be marked “Invalid” or “N/A” under the column heading “TRG Count.” This apparent anomaly can be found in Toyota systems identified as part of the ECU/EDR Generations3 04EDR, 06EDR, 12EDR, 13EDR, 15EDR, and 17EDR. For this paper, the word “anomaly,” in various forms, is used to mean a translated data element or data description

that deviates from what might be considered otherwise expected in a data set were compared to the majority of like data sets. It doesn’t necessarily mean the anomalous data is “wrong”4…it is just different. We know that “digital Data, by virtue of its binary nature, is either right or wrong.”4 Here, the explanation of the source of the anomalous data and the identification of the conditions bringing it about in the various Toyota airbag control module (ACM) types suggests that that the data isn’t “wrong” as it relates to the identified conditions and meaning of the translated or reported values, it just isn’t reported as one might normally expect to find it and that may complicate an analysis when the analyst tried to apply that data.

Based on a review and analysis of almost 27,000 Bosch CDR Tool data files (*.CDR and *.CDRx files) which were distilled to some 5,000 Toyota systems files5, this paper will explore under what circumstances a Trigger Count may be marked “invalid” in a CDR Tool data translation report, and present a more detailed explanation of the meaning of the “invalid” indicator than that found in current Toyota Data Limitations narratives or Bosch CDR Tool Help file. In Part 2 – in the next issue of Collision Magazine – options for confirming or verifying the represented order of events in a Toyota data transla-

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 51

Figure 1: Event Record Summary example from a Recording Type 2 system with the “Events Recorded” chronology displaying “TRG Invalid #1” and the TRG Count displaying “Invalid”

Figure 2: Event Record Summary example from a Recording Type 3 system with the TRG Count displaying “Invalid” for all recorded events tion report where the Trigger Count is marked “invalid” will be discussed in greater detail.

In all of the data files examined for this analysis, about 2% of the approximately 5000 Toyota files were found to report “Invalid” or “N/A” for the TRG Count. About 55% of those displayed the “N/A” translation and the remaining 45% the “invalid” indicator. In the overwhelming majority of the occurrences (more than 80% of the data files examined where the anomaly was observed), the “Invalid” or “N/A” translation for a TRG Count is associated with data from 13EDR and 17EDR systems although it was also observed infrequently in data translation reports from 04EDR, 06EDR, 12EDR, and 15EDR systems.

Toyota Data Recording Theory The Data Limitations section of a data translation report generated by the Bosch CDR Tool software is designed to give the end user of the translated data at least a little insight into some of the data element conventions, element polarity, and may offer a description of the meaning of some of the words, terms, and acronyms found in the body of that report for that module type. Anyone familiar 52

Collision Magazine - Volume 17 Issue 1

with the variety of data translation reports available from the various manufacturers (OEMs) knows that some Data Limitations are more detailed, and others are, unfortunately, less so. As it relates to the Toyota term “Trigger Count” across the various generations of Toyota systems (also seen as “TRG Count”), there may be more than one description or definition. Examples6 include: “… “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. …” – 05002_ToyotaTMC7

www.collisionpublishing.com

“… “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. …” – 05022_Toyota_Std-S02 The phrase “across the various generations,” as used here, perhaps requires some explanation for those not familiar with the Toyota ECU (Electronic Control Unit) Generation indicators found in a Toyota data translation report (later identified as an “EDR Generation”3). Generally, the

specific ECU/EDR Generation corresponds to digits 3-5 in the Data Limitations text code (i.e.: “022” in the Data Limitations text code8 05022_Toyota_Std-S02 indicates the system is a 22EDR).

That ECU/EDR Generation data element is also found in every set of Toyota Data Limitations where we find, for example, this passage: “…The data recording specifications of Toyota’s airbag ECUs are divided into the following categories. The specifications for 12EDR or later are designed to be compatible with NHTSA’s 49CFR Part 5639 rule.

- 00EDR / 02EDR / 04EDR / 06EDR / 10EDR / 12EDR / 13EDR / 15EDR / 17EDR / 19EDR / 21EDR / 22EDR …” (reference added)

Figure 3: An example section of the Bosch CDR Tool Help File “Vehicle and Cable Lookup” section for a Toyota Corolla. The “Data” and associated ECU/EDR Generation is highlighted in the red box www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 53

12EDR group of modules, we might find the text codes 05012_ToyotaS02ind3, 05012_ToyotaS02std, and 05012_ToyotaS04std.

The ECU/EDR Generation data element is found in a Toyota data translation report in the “System Status at (Time of ) Retrieval” data table as seen in Figure 4. Relatively older systems refer to this element as the “ECU Generation” while those offered as compliant with 49CFR563 appear to use the element name “EDR Generation;” both are seen in the various examples found in Figure 4. For the end user of this data, this is little more than form over function: there is no meaningful or functional difference between the two phrases “ECU Generation” and “EDR Generation” as previously noted.

Figure 4: - Examples of ECU and EDR Generation indicators (highlighted) from various recording Type 2 and 3 data sets The first two digits in the ECU/EDR Generation represent the year that ACM type was first introduced by Toyota for production vehicles and may or may not correspond to a given Toyota vehicle’s model year or actual production date. The data described by the Data Limitations text code as “05022_Toyota_Std-S02” is for the airbag control module type introduced in 2022, the Toyota EDR Generation designated as a “22EDR” and not necessarily only found in a model year 2022 vehicle. For example, an 04EDR may be found installed in a 2008 Camry. These ECU Generation values (i.e.: 04EDR, 15EDR, etc.) correspond to those referenced in the Data Limitations passage above and are also referenced in the Bosch CDR Tool Help File as seen in Figure 3. In Figure 3, the highlighted “Data” link references the anticipated set of data elements one might find in the various listed ECU/EDR Generations. The ECU/EDR Generations shown are hyperlinks to those lists by generation in the Bosch CDR Tool Help File.

Specific to Toyota systems, digits 3-5 are used to identify the EDR/ECU Generation as in the examples “05004_ ToyotaFTEN” and “05004_ToyotaDENSO” where both are 04EDR systems. However, the Data Limitations text for those are separately associated with information specific to the module made by the first-tier supplier of that ACM at the time; in this case, FujitsuTen or Denso, respectively10 as called out by the “plain language” identifiers. Some EDR/ECU Generations have more than one Data Limitations text code associated with the larger EDR/ECU Generation identifier. For example, in the 54

Collision Magazine - Volume 17 Issue 1

There are multiple references within the larger body of literature which call out Toyota module “generations.” As pointed out, end users will see either “EDR Generation” or “ECU Generation” in a data translation report, and in the Bosch CDR Tool Help File Glossary, we find this reference seemingly to both when compared to the relevant named element(s) (as seen in Figure 4): “… EDR Generation (Toyota) Indicates the generation of EDR functionality included in a Toyota airbag ECU. The data recording specifications of Toyota’s airbag ECUs are divided into the following three generations.

Generation 1 (Gen 1): 00EDR & 02EDR Generation 2 (Gen 2): 04EDR & 06EDR Generation 3 (Gen 3):10EDR, 12EDR, 13EDR & 15EDR Generation 4 (Gen 4): 17EDR & 19EDR The specifications for 12EDR and later are designed to be compatible with the requirements of NHTSA’s 49CFR Part 563 rule. …” (sic) (emphasis added) – CDR Tool Help file from v23.2.1 Clearly this definition lists 4 “generations,” not 3, nonetheless, what specific criteria has been used to establish or group these 3 (or 4) “generations” is not otherwise clearly explained in the Help file (or in any Data Limitations text). The Help File passage generally references “recording specifications” but, as set out later in this paper, there are some overlapping similarities beyond the Help File designated “generations” (depending on how generally or narrowly the phrase “recording specifications” might be interpreted). Moreover, in a data translation report, where

www.collisionpublishing.com

we would find the data element “EDR Generation” (or “ECU Generation”) as given in the Help File passage, we do not find the translated value reported as “Generation n.” However, we do see the translated value reported as, for example, 06EDR or 22EDR (as seen in Figure 4).

ECU has two recording pages for each accident type: two pages for frontal and rear crash, two pages for a side crash, and two pages for rollover event. …” – 05012_ToyotaS03std, 05013_ToyotaS00std and 05015_ToyotaS01std

The most obvious distinction between what might be called Gen 211 and Gen 3 in the Help File passage would be whether or not the data elements in that ACM type’s data set are or are not otherwise designed to be compliant with 49CFR56312. Inasmuch as Toyota clearly indicates that the 12EDR and later systems are designed to be compliant with 49CFR563 and the Help File Gen 2 systems do not meet that test, logically, the Gen 2 systems might be in a group/generation based on that criterion alone.

Beyond the passage found in the Data Limitations with respect to stated compliance with 49CFR563, there are other differences as well as similarities13 between the various designated Toyota ECU Generations.

Clearly, they are the same admonition with respect to the recording process of the systems indicated. The point is that the data is “stored” (recorded) in the same way for these five ECU/EDR Generations’ systems as it relates to the recording memory mapping even though other characteristics would suggest the 04EDR and 06EDR are a different “ECU Generation” as referenced in the Help file based on criteria most likely associated with the requirements of 49CFR563. In contrast, in the Data Limitations for the 17EDR, 19EDR, 21EDR, and 22EDER systems, we find this passage:

With respect to similarities, for this paper, one investigative step used to discover the source of the “invalid” Trigger Count indication focused on the recording order of the various module types. Based on that criterion, and to separate the recording function from the “generations” as that term is used in the CDR Tool Help file, we might revise the designation of module groups to what will be identified as numbered “Recording Types” in this paper.

Recording Type 1 (Type 1) includes the 00EDR and 02EDR ECU Generations. The recording process for the 00EDR and 02EDR (Gen 1) has been addressed in detail

by Haight and Anderson14 and the “invalid” TRG indicator discussed herein has not been found in data translation reports from those systems.

The ECU Generations 04EDR and 06EDR, while not identified as 49CFR563 compliant, both record data as described in this passage from the Data Limitations: “… The airbag ECU has two recording pages (memory maps) to store pre-crash data. Additionally, to store post-crash data, the airbag ECU has two recording pages for each accident type: two pages for frontal and rear crash, two pages for a side crash, and two pages for rollover event. …” – 05004_ToyotaDENSO and 05006_ToyotaFTEN Then, in the Data Limitations for the 12EDR, 13EDR and 15EDR systems, we find this passage: “…The airbag ECU has two recording pages (memory maps) to store pre-crash data. Additionally, to store post-crash data, the airbag

“… The airbag ECU has the following recording pages (memory maps) for each accident type to store event data: four pages for frontal/rear/side crash, four pages for a side crash, and two pages for rollover event.

“- When a crash impact for a lateral direction is occurred, data may be recorded in a page for frontal/rear/side crash. And additional data may be recorded in a page for side crash. …” (sic) – 05017_ToyotaS00std, 05019_ToyotaS00std, 05021_Toyota_Std-S01ind1, and 05022_Toyota_Std-S02 For this analysis, based only on the recording logic similarities, we will refer to the 00EDR and 02EDR systems as Recording Type 1 (Type 1), the 06EDR, 12EDR, 13EDR, and 15EDR systems as Recording Type 2 (Type 2), and the 17EDR, 19EDR, 21EDR and 22EDR systems as Recording Type 3 (Type 3). Setting aside other differences in what data is recorded, the way that data is represented after translation, and the potential for compliance with 49CFR563, as it relates to the recording memory mapping process, this will work to clarify if not simplify the larger analysis.

Type 1 systems record data one memory page at a time for each Front/Rear event (trigger) to be recorded and Toyota’s demonstrated recording logic has been to prioritize the preservation of the “Most Recent” and “First Prior” events which, for this Type, are limited to impacts to-thefront or to-the-rear of the vehicle with a priority given to those which act as front-to-rear events15. For this Recording Type, the recording page number is identified in the “Front/Rear Event Record Summary at Retrieval” data table. Graphically, the recording memory map for Type 1

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 55

compared to an example “Front/Rear Event Record Summary at Retrieval” data table is shown in Figure 5 and as further detailed in Haight and Anderson16.

Prior to this Toyota system Type’s introduction, no other OEM had included what is or was effectively a module lifetime cumulative event counter as part of the recorded and translated data. Where Toyota module accessibility reaches back as far as model year 2000, at that time and over several model years after that, the only other comparable data element even remotely associated with lifetime event chronology in some way might be the GM “Ignition Cycles at Event” versus “Ignition Cycles at Investigation” pair of data elements. While not representing an actual event counter, the elements are one way to establish chronology across two recorded event records, for example, where they may have occurred on different ignition cycles17.

What is referred to here as Toyota Recording Type 2 systems retained the numbered memory page convention writing the first of an event type and the first set of PreCrash data to recording memory page 0 for each set of data then expanded the type of events to be recorded beyond just Front/Rear events while reducing the total number of records (pages) for each type to 2 (recording memory pages 0 and 1 for each category of event to be recorded).

Recording two of each event type generally maintains the previously demonstrated prioritization of the “most recent” and “first prior” event of each category of event. Fig-

ure 6 is a graphical representation of the previously noted passages from the Data Limitations for 04EDR through 15EDR and an example “Event Record Summary at Retrieval” data table. In Figure 6, we see where the recording memory page number is referenced for each recorded event. In this example, we find this passage in the Data Limitations from which the “Event Record Summary” was captured: “… This airbag ECU records post-crash data, and depending on the airbag ECU, may record pre- crash data.

- If a single event occurs independently, the data for that event is recorded on a one-to-one basis.

- If multiple events occur successively (within a period of approximately 500ms), the establishment of the recording trigger for the first event is defined as the “pre-crash recording trigger”.

Pre-crash data for the first event and post-crash data for each successive event is then recorded. …” –05006_ToyotaFTEN The reason that the 4 recorded events in this example at Figure 6 all share the pre-crash data first associated with “Front/Rear” TRG2 is a function of separate “Pre-Crash” and “Event and Crash Pulse Data” recording pages common to what are here referred to as the recording Type 2 systems18.

Figure 5: A graphical representation of the Recording Type 1 memory and recording logic with a Front/Rear Event Record Summary example for reference 56

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Figure 6: A graphical representation of the Recording Type 2 memory and recording logic with an Event Record Summary example for reference The third group, for this paper referred to as Recording Type 3 systems, adopts a recording methodology which allows for the majority of the recorded events to include associated Pre-Crash data, generally maintains the prioritization of the most recent and first prior events of a given event category, captures potentially more events than called for in 49CFR563, and includes detailed data associated with side impacts not included in any earlier set of Toyota data.

Figure 7 is a graphical representation of the Type 3 recording scheme based on the Data Limitations passage above for the 05017_ToyotaS00std, 05019_ToyotaS00std, 05021_Toyota_Std-S01ind1, and 05022_Toyota_StdS02 systems. Lost with this recording type is the recording memory page number (i.e.: “Front Rear Page 0”).

In Figure 7, we see that what was set aside in Recording Type 2 for Front/Rear events has now been combined with Side events for a total of 4 records for that newly defined category (“Front/Rear/Side Crash”) and 4 separate recording memory areas (again, represented as unnumbered recording memory pages) have been set aside for, as described in the Data Limitations for where “…additional data may be recorded in a page for side crash.” The 4 “Side

(only) Crash” records don’t have separate pre-crash data and several of the other data elements found in the Front/ Rear/Side category are also not captured or reported in the “Side (only) Crash” records. On the other hand, these “Side (only) crash” events give more detailed data related to, for example, lateral acceleration exposure in side impacts from multiple satellite sensors19.

The discussion of the Recording Types as described here lends itself to a better understanding of at least part of the analysis used to find the underlying reason for the “invalid” Trigger Count indicator and helps to demonstrate, objectively, the extent of the anomaly and offers methods which might be used to confirm or reconfirm event order beyond relying on a numbered Trigger Count.

“Invalid” and “N/A” Perhaps the best way to approach the idea of an “invalid” or “N/A” indicator found in a Data Translation report as it may be associated with a TRG Count is to look for a definition of the word or acronym as used in either the Data Limitations text for a Toyota module type or in the CDR Tool Help File Glossary20. Starting with the CDR Tool Help File glossary, we find this passage:

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 57

“… Invalid - Data is known invalid due to operational measurement range issues, a failed validity test or, the data reported was in a ring buffer that was partially filled. …”

Then there is this definition which the Help File Glossary lists as Toyota-specific: “…Invalid (Toyota) - Data Element is not supported or data is known invalid due to operational measurement range issues, a failed validity test or, the data reported was in a ring buffer that was partially filled. …” (-emphasis added) Of course, the difference between those two passages adds, for Toyota, the unique and specific phrase “element is not supported.”

In the 04EDR and 06EDR Data limitations, the only Data Limitations passage incorporating the word “invalid” is: “… The “Drive” setting for the “Shift Position” value indicates the shift position state is other than “R,”(Reverse), “N” (Neutral), or “P” (Park). If sequential shift had been used, “Invalid” may be displayed. ...”

In the 12EDR, 13EDR, 15EDR, 17EDR and 19EDR Data Limitations, we find these passages which include the word “invalid:” “… “Brake Oil Pressure” has an upper limit of 12.14 Mpa. In the case of the vehicle that has not VSC system, “0 Mpa” or “Invalid” may be displayed. …” “… Some vehicles will not be equipped with all “Drive Mode” types indicated in the “Drive Mode” table. If some or all drive modes are not applicable to vehicle, “OFF” or “Invalid” may be displayed. The item in the “Drive Mode” table may not match the name of switch or indicator that equipped the vehicle. …” (sic) While the word “invalid” isn’t specifically associated with the next passage but in the context of this research, in the 17EDR Data Limitations, we find this sentence: “… The TRG count may indicate “not available”, when a trigger count could not be provided. Other information in the recorded events can help identify event timing. …”

Figure 7: A graphical representation of the Recording Type 3 memory and recording logic with an Event Record Summary example for reference 58

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Nothing close to the verbiage found in the passage immediately above is found in the Data Limitations for the 04EDR, 06EDR, 12EDR, 13EDR, or 15EDR systems. Nothing similar is found in the 19EDR, 21EDR, or 22EDR Data Limitations, either. The sentence above including the phrase “not available” is unique to the 17EDR21 Data Limitations.

In this study, the “TRG Invalid #1” and “N/A” indicators – as seen in Figure 8 – was found in data translation reports from 04EDR, 06EDR, 12EDR, 13EDR, and 15EDR systems, however, none of the Data Limitations from those systems include a reference to a use case where a TRG Count might be translated to display “TRG Invalid #1” or “N/A.”

The “problem” with the passage from the 17EDR is that it specifies that when a Trigger Count can’t be “provided,” the counter element may indicate “not available” not “invalid” and there were no examples of the phrase “not available” as a TRG count element indicator found in any of the more than 500 17EDR data translation reports analyzed for this paper.

Naturally, one may consider other ways to try to confirm or better understand the use of “N/A” and, in that regard, we might first look to the Bosch CDR Tool Help File Glossary to find this definition:

The closest one may come to finding a Trigger Count marked “Not Available” is as seen not in the 17EDR system data translation reports but in the 04EDR, 06EDR, 12EDR, 13EDR, and 15EDR systems where the indication of the TRG Count (number) may be found as “N/A” – where “N/A” might be seen to indicate that the translated data element is/was “not available.” In Figure 8, we can see that the general event chronology is translated to show the series of events working backwards from the Most Recent Event to the 4th Prior Event. Then the next line below that shows a translated indicator of “TRG Invalid #1” and the TRG Count as “N/A” (as highlighted for Figure 8).

“N/A” would seem to logically fit the definition found in the Data Limitations passage “…The TRG count may indicate “not available”, when a trigger count could not be provided. …”, however, that passage is found in the Data Limitations for a 17EDR system, and the Event Record Summary example seen at Figure 8 comes from a 13EDR system not a 17EDR system. Again, the Data Limitations for the 13EDR system does not include a passage comparable to that seen in the 17EDR.

“… N/A – Not Applicable. N/A may be used when data elements included in CDR reports may not be applicable to the event observed or vehicle it was retrieved from or where the display of some data element is not applicable to conditions or limitations present. See also “SNA.” …”

In the most narrow, literal reading, the definition clearly indicates “Not Applicable” rather than “Not Available.”

The description, however, including the phrase “…the display of some data element is not applicable to conditions or limitations present …” aligns contextually with the 17EDR definition such that one may see where “…The TRG count may indicate “not available”, when a trigger count could not be provided. …” Here, there is little meaningful difference between “Not Applicable” and “Not Available” in context. Moreover, in the Bosch CDR Tool Help File Glossary, we are directed to also consider the definition of the acronym “SNA” where we find this: “… SNA – Signal Not Available typically indicates that a defective sensor or system fault condition exists that is not allowing the sensor data for a given signal to be sent across the vehicle communication bus. …” (-emphasis added)

Figure 8: A graphical representation of the Recording Type 3 memory and recording logic with an Event Record Summary example for reference www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 59

Figure 9: Event Record Summary example from a Recording Type 3 system – specifically a 17EDR system – with the TRG Count displaying “Invalid” for all recorded events. Compare to Figure 2 As found in the Cambridge Dictionary, the abbreviation N/A is used to mean both “Not Applicable” and not “Not Available22.” Additionally, multiple references and definitions include23: “… N/A or sometimes n/a is a common abbreviation in tables and lists for the phrase not applicable, not available, not assessed, or no answer. …” (-emphasis added) Noting that the only reference where the TRG Count is specifically associated with the phrase “not available” is in the 17EDR systems we might next look to data from that system type in an effort to find the phrase “not available” or the acronym “N/A” associated with the TRG Count.

Neither that phrase nor acronym are associated with the 17EDR system TRG Count data element in any 17EDR data translation report of the more than 500 17EDR data translation reports reviewed. In fact, of the approximately 30 data translation reports where there was an unusual TRG Count indicator, that element reflects the word “invalid” and not the phrase “not available” or the acronym “N/A” as in the example provided as Figure 9 (highlighted).

The “TRG Invalid #1 - N/A” Indicator For 04EDR, 06EDR, 12EDR, 13EDR and 15EDR systems, there exists the possibility that the event order indicator column will display the translated value “TRG 60

Collision Magazine - Volume 17 Issue 1

Invalid #1” rather than, for example “Most Recent Event” or “nth Prior Event.” When that occurs, the TRG Count will be displayed as “invalid” in an 04EDR or 06EDR system and “N/A” in a 12EDR, 13EDR, and 15EDR system data translation report. Examples of these “invalid” or “N/A” translated or indicated values are seen in Figures 1 and 8, respectively, and together in Figure 10. The “TRG Invalid #1” was not seen in 17EDR or later systems and is not included in this part of the analysis.

Evaluating “invalid” and/or “N/A” anomalies for this group of systems, we might examine some of the common data elements across the 04EDR through 15EDR systems (the Recording Type 2” systems). In Table 1, the common and, for the purposes of this paper, related, elements are listed from the “System Status at Time of Retrieval” and “Event Record Summary at Retrieval” data tables as found in 04EDR, 06EDR, 12EDR, 13EDR and 15ED systems.

There are more elements in those data tables, however, the elements shown in Table 1 relate, at least in part, to an evaluation of the “invalid” or “N/A” condition found on the 04EDR to 15EDR systems24.

At the bottom of the event chronology list in an Event Record Summary, the indicator “TRG Invalid #1” only occurs when that condition is identified for that data set as seen in Figures 1, 8, and 10. It is not present in a data translation report where there is no “TRG Invalid

www.collisionpublishing.com

Figure 10: A comparison of two Recording Type 2 Event Record Summaries illustrating the difference between the “Invalid” and N/A” TRG Count indicators

Figure 11: Examples of Event Record Summaries from 06EDR Systems where the “TRG Invalid #1” and the TRG Count displaying “Invalid” anomalies are not present #1” displayed and, of course, no corresponding “invalid” or “N/A” as is depicted in the two randomly selected 06EDR examples used to create Figure 11.

As a function of identifying the conditions under which the “TRG Invalid #1” chronology element and the corresponding “invalid” or “N/A” indicators are reported, the elements considered (as seen in Table 1) included (1) the module (ACM) part number, (2) the type of event

marked as “invalid” or “N/A,” (3) the order of events, and (4) recording (complete) status.

Part Number There are some 2636 Toyota ACM part numbers listed in the Bosch CDR Tool Help file. Of those, 2562 may be found in vehicles sold outside China25. Some (i.e.: 10EDR) are not found in the North American sales vehicles (10EDR is also not included in the 2562 total).

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 61

The Toyota Part Number list in the Bosch CDR Tool, however, does not list all the available part numbers inasmuch as some of the part numbers found in various data translation reports examined in this review are not found in the Bosch CDR Tool Help file part number list 26, 27,28.

That said, some 2080 part numbers which are listed in the Bosch CDR Tool Help File are associated with the 04EDR through 17EDR module type range. From the list in the Help File alone, it is almost impossible to associate a specific part number with a year model vehicle or whether or not that vehicle may or may not have been sold in North America.

For this study, data from the 2500 Toyota CDRx data files – all from North American sources29 – represented a group of more than 75 unique part numbers. Of those, data from 25 unique part numbers associated with the 13EDR type module reported the “TRG Invalid #1” and the TRG Count as “N/A.” It would seem to be a large number of the total of 75, however, of those part numbers, all were also identified in data sets/data translation reports for modules which did not exhibit the “TRG Invalid #1” and the TRG Count as “N/A” anomaly. A similar analysis – with smaller total counts – was done for the 04EDR, 06EDR, 12EDR, and 15EDR data translation reports with essentially the same result. Of the 13EDR systems which were closely compared for similarities and differences, of those there were 24 which were found to yield either the “TRG Invalid #1” chronology indicator or a “normal” chronology indicator (i.e.: nth Prior Event).

Since the part number appeared in data translation reports where the indicator for the event chronology was

reported as “TRG Invalid #1” and the TRG Count for that event was reported as either “invalid” or “N/A” and where that anomaly was not observed across this range of specific module part numbers, the part (identified by part number) was discounted as the source of the apparent anomaly.

The “TRG Invalid #1” Crash Type and Order In the Event Record Summary at Retrieval data table for the 04EDR, 06EDR, 12EDR, 13EDR and 15EDR, the third column is labeled “Crash Type,” and the translated responses or indications are “Front/Rear Crash,” “Side Crash,” or “Rollover.”

Initially, as the review of the data translation reports from this group of EDR/ECU Generation systems progressed, there were a significant number of events (“Crash Types”) which were marked as “TRG Invalid #1” and that event was identified as a “Rollover.” Of this group of module types, 30 of the 34 included in this portion of the review were “Rollover(s).” The remaining three were “Front/ Rear Crash” (2) or “Side Crash (2).” But there was a second related element found in the data sets which further complicated this part of the analysis.

While the “Crash Type” was identified in the Event Record Summary data table, in the “System Status at Event” data tables, a second, related element was identified which helps call out the order of the “TRG Invalid #1” event.

This element – “Previous Crash Type” – is also one of the elements described as “…information that clarifies the collision event sequence …”30 in the relevant, respective Data Limitations.

Figure 12: For Recording Type2 Systems, where the “TRG Invalid #1” and the TRG Count displaying “Invalid” anomalies are present, the examples shown highlight the elements “Recording Status [type]” and “Previous Crash Type” 62

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Figure : 13 Comparisons of 13EDR and 06EDr system indications of the recording complete data elements and the various verbiage changes or revisions Whether or not the event that was reported as the “TRG Invalid #1” event from this EDR/ECU Generation was a Rollover, Side Crash or Front/Rear Crash, the “Previous Crash Type” was always reported as a Front/Rear Crash with one exception. In that lone exception, the “TRG Invalid #1” was reported as a “Front/Rear Crash” but there was no “Previous Crash Type” reported. Examples of how the data is reported where the event is identified as a “TRG Invalid #1” and the “Previous Crash Type” – therefore the relative order – is reported are seen in Figure 12 as highlighted in yellow. Also highlighted in Figure 12 was the final element to be considered and common thread in this group of EDR/ECU Generation modules as it relates to the “TRG Invalid #1” anomaly: whether or not all of the event recording was complete (highlighted in red) at Figure 12).

Recording (Complete) Status The relevant data element found in the “System Status at Time of Retrieval” data table for the 04EDR and 06EDR

is identified as “Recording Status, All Pages.” For the 12EDR, 13EDR, and 15EDR, in the “System Status at Time of Retrieval” data table, the element is identified as “Complete File Recorded” which is, as noted before, consistent with the data element name “specified” in 49CFR563 for this recording condition31.

At Figure 13, the upper example is from a 13EDR data translation report and the lower example is from an 06EDR data translation report (see also the Generations indicated as seen in Figure 4). In the “System Status at Time of Retrieval” data table for both of these examples, we see the variations of the element name which, when taken with the associated “System Status at Event” data tables for each example, makes the “different” element name verbiage really nothing more than a distinction without a difference.

More importantly, in all of the 04EDR through 15EDR files in which the chronological event name is given as “TRG Invalid #1” and where the associated TRG Count

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 63

Figure14: “Longitudinal/Lateral Crash Pulse [identifier information]” data tables from sample data translation reports where there are indications of a power interruption during the crash pulse is translated as either “invalid” or “N/A” (depending on the ECU/EDR Generation range) there are other indications that the event data was not completely recorded; that there was a power interruption during the event and then a power depletion during the recording process.

For this Recording Type, as identified for this paper where there are “… two recording pages (memory maps) to store pre-crash data. … (and) two recording pages for each accident type: two pages for frontal and rear crash, two pages for a side crash, and two pages for rollover event …” (see also Figure 6), the potential exists where there may not be Pre-Crash data or Crash Pulse data associated with some of the events recorded including the event labeled “TRG Invalid #1.” Where there was Crash Pulse data recorded for associated events, another indication of a power interruption during the crash event which would then be con64

Collision Magazine - Volume 17 Issue 1

sistent with the power interruption during the event and then suggest the likelihood of a power depletion during the data recording period is seen in the crash pulse data tables in Figure 14.

The data tables in Figure 14 are specific to the 12EDR, 13EDR, and 15EDR systems inasmuch as the 04EDR and 06EDR systems do not report the crash pulse in the same way as the 12EDR32 and newer systems33 do. Unfortunately, there simply isn’t the same level of detail in the 04EDR and 06EDR systems as we find in the 12EDR and later systems for the longitudinal and lateral crash pulse.

Following the requirement for reporting the “Delta-V, longitudinal” data element found in 49CFR56334, the data tables seen in Figure 14 identified as the “Longitudinal/Lateral Crash Pulse ([Chronological Event Identifier]

www.collisionpublishing.com

event being reported and are simply “default” values for the data table as part of the data translation report form.

The more directly relevant observation is that the Power Supply Status is reported in the right-most columns of each of the examples in Figure 14. In the upper left example, during the reporting period of 0-140ms, the Power Supply Status changes from “ON” to “OFF” at about the 20-30ms39 sample. This indicates that power from the vehicle charging system to the ACM was interrupted at some point around the 20-30ms point from Time Zero into the crash pulse. Since at least some data was recorded after that 20-30ms point (or we wouldn’t have any data for the “TRG Invalid #1” event much less that seen after the Power Supply Status changes reported in the tables in Figure 14) this indication is not the same as an indication of when a power depletion during the recording process which resulted in an incomplete recording took place.

Returning then to consider the gray “shaded” section of the data table, where the Power Supply Status seems to be “ON” (and the reported delta-V is “0.0” in whatever units), that “data” (the indications) is simply placeholder information in the data translation report form inasmuch as the reporting and the reporting period has ended because the reporting requirement has been met. In each of the examples in Figure 14, we can see where the vehicle charging system power was randomly interrupted during the crash pulse at some point after Time Zero and the reported Power Supply Status indicator changes from “ON” to “OFF.”

Figure 14 (continued) TRG n - table n of n)” are designed in the data translation report form to display up to 250ms of crash pulse data in 10ms intervals (as called out in 49CFR563.7 et seq35).

Where the crash pulse data ends in less than 250ms, following the provisions of 45CFR563 for “End of Event Time,”36 the data table rows (relative to the 10ms time intervals) are shaded or “grayed out37”.

For example, in Figure 14 the upper left data table does not display crash pulse data after the 140ms sample. This would suggest that the “end of event time” for the element “Maximum delta-V, longitudinal” was reached at around 110ms and then the module reported about 30 ms of crash pulse data after that38. After the 140ms sample, the “grayed out” or “shaded” portion is simply beyond the reporting requirement. For that reason, data in the gray “shaded” rows in the data table are not relevant to the

In the lower left example in Figure 14, there is a Power Supply Status change in the 140-170ms range suggesting the power was “OFF” leading into that time range, appears to have come back “ON” during that time, then went back to “OFF” for the remainder of the reporting period. Inasmuch as there is an indication that recording is NOT complete, that apparent anomaly may be (1) an artifact of the incomplete recording or it may be (2) a function of the charging system supplying power to the ACM ever so briefly as though it “flickered” from OFF, to ON, then back to OFF again. There were several examples of this apparent contradiction observed in the data translation reports analyzed and, again, all were from those where the overall data recording status was reported as incomplete.

Another way to consider the crash pulse and power interruption during an event versus power depletion during recording indications in Figure 14 would be to more closely examine what is given in a data translation report for the associated data elements “Max. Longitudinal Delta-V (MPH [km/h]),” “Time, Maximum Delta-V, Longitudi-

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 65

Figure15: A comparison of two “Longitudinal/Lateral Crash Pulse [identifier information]” data tables indicating power interruptions during the recording process, where those interruptions were reported and then the maximum delta-V values in the smaller tables 66

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

nal (msec)”40 and “Power Supply Status at Max. DeltaV” from the associated “Longitudinal/Lateral Crash Pulse ([event order] table 2 of 2)” data table.

In Figure 15, there are two 13EDR examples of Power Supply Status from the “Longitudinal/Lateral Crash Pulse ([event order] table 2 of 2)” data tables. In the upper example in Figure 15, the indication is that the Power Supply Status was interrupted at about 70-80ms after Time Zero and continued to report “OFF” through the remainder of the 250ms of reported crash pulse data (no gray shaded section). "In the lower example in Figure 15, the Power Supply Status changed to “OFF” at a very early 10-20ms and remained “OFF” to the end of the reported crash pulse at about 160ms. Note that the “Power Supply Status at Max. Delta-V” element for each indicates “Off” as well41.

In Figure 15, the “Longitudinal/Lateral Crash Pulse ([event order] table 1 of 2)” data tables shown at the bottom of each example include the elements the “Max. Longitudinal Delta-V (MPH [km/h])” and “Time, Maximum Delta-V, Longitudinal (msec)” where the time may be reported, per 49CFR563, beyond the 250ms data table out to 300ms. In the upper example in Figure 15 indicates the “Max. Longitudinal Delta-V (MPH [km/h])” was captured at 267ms. That is, of course, beyond the 250ms shown as required in the data table (Figure 15, upper) which is why there are no “gray shaded” rows in that data table.

In the lower example in Figure 15, the “Time, Maximum Delta-V, Longitudinal (msec)” to the reported “Max. Longitudinal Delta-V (MPH [km/h])” is 144ms. In the upper data table, the reported crash pulse period ends at 160ms.

On its face, that 144ms plus 30ms42 would mean the data table would seem to have to be reported to 174ms (about 170ms at the 10ms reporting resolution). There is, however, another element or condition to consider in this example. The first being that the element “Time from Time Zero to TRG (msec)” where “Time Zero"43 and the use of the acronym “TRG”44 by Toyota are not necessarily synonymous. Given there is a difference between the two terms as used and the reporting resolution for time for “Time, Maximum Delta-V, Longitudinal (msec)” is greater than the time resolution the “Longitudinal Delta-V” element in the “Longitudinal/Lateral Crash Pulse ([event order] table 1 of 2)” data tables, it would follow that there might be some apparent mathematical “difference” between the two – however slight. Essentially, however, there is no meaningful difference between reporting to 160ms in the upper table and the idea that 144+30ms is 174ms. If we are to “shift” the “Time, Maximum Delta-V, Longitudi-

nal (msec)” by the reported 6.5ms for the element “Time from Time Zero to TRG (msec)” that would suggest the 144ms might be reduced to (144-6.5ms=) 137.5ms and 137.5ms+30ms is 167.5ms. The 167ms point is obviously within the 160ms range at 10ms resolution.

Nonetheless, what we can deduce from this analysis as depicted in Figured 15 and 16 confirms that the Power Supply Status shown in the gray shaded rows in those figures is essentially irrelevant and, back to the original discussion, there was a clear indication of a power interruption during the crash pulse in these examples and the further associated indication was that the event recording was not complete where there was a power depletion during the recording process.

That incomplete recording is the common thread in the 04EDR, 06EDR, 12EDR, 13EDR and 15EDR systems where we find the event chronology indicator is given as “TRG Invalid #1” and where the associated TRG Count is translated as either “invalid” or “N/A” (depending on the ECU/EDR Generation range).

The event labeled as the “TRG Invalid #1” may or may not easily fit into the remaining displayed event chronology (i.e.: the first column showing the “Most Recent Event” and “nth Prior Event(s)” a seen in Figures 10 and 11 among others). In some instances, it is clear that the “TRG Invalid #1” event fits with or within the remaining recorded events although it does not have a specified TRG Count value as a function of a power depletion during recording. Using other data elements may a basis for the end user to establish how or whether or not the “TRG Invalid #1” event fits into the chronology of the remaining events which do have TRG Count values and then to apply or discount that data as appropriate. The further analysis of associating the “TRG Invalid #1” in the larger chronology – where that can be done – is the subject of Part 2 in this series and will be outlined in the next issue of Collision.

The “Invalid” TRG Count Indicator Unlike the “TRG Invalid #1 - N/A or Invalid” indicator common to Recording Type 2 systems45, for the Recording Type 3 systems, the “Invalid” indicator is found in the “Event Record Summary at Retrieval” data table as seen in Figures 2 and 10 for the TRG Count element alone, there is no “TRG Invalid #1” indicator found in the 17EDR and later systems under the heading “Events Recorded.”

There are two obvious differences between the two recording types where an “Invalid” indicator is reported. First, for the Recording Type 3 systems, all of the events have a “Most Recent Event” and then “nth Prior Event(s)” as

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 67

indicated in the “Events Recorded” column of that data table whereas in the Recording Type 2 systems, there is one of the “Events Recorded” reported with the indicator “TRG Invalid #1” when the anomaly is present (i.e.: Figures 10 and 11). The second difference is that in the Recording Type 2 systems, all the events – except the one marked “TRG Invalid #1” – still include TRG Counts but in the Recording Type 3 systems, all of the TRG Counts are marked “Invalid” (see Figures 2 and 9).

Beyond that, a unique condition exists in the Recoding Type 3 systems where the “Invalid” TRG Count indication is present in an “Event Record Summary at Retrieval” for only one of the related ECU/EDR Generations: the 17EDR. This anomaly has not been found in 19EDR, 20EDR, or 22EDR data sets46. However, as it relates to the 17EDR module type, 45% of the Recording Type 2 and 3 systems where there was an “Invalid” event indicator as described earlier in this paper were from the 17EDR module type.

As was the case with the “TRG Invalid #1” indicator, this research focused on identifying the conditions under which the “Invalid” TRG Count element was reported and the elements considered included (1) the recording (complete) status, (2) the type of event marked as “Invalid,” (3) the order of events, and the (4) part number.

Recording (Complete) Status For the data translation reports associated with 17EDR systems, the main data elements considered in this analysis are found in Table 2 (like that found in Table 1 for the Recording Type 2 systems). Where the anomaly associated with the Recording Type 2 systems as always associated with an incomplete recording, except for one of the 29 17EDR files examined for this group – specifically the 17EDR systems – the recording was indicated as “complete.”

No other characteristic found in the single “incomplete” recording data translation report from the group of 17EDR systems examined was also found in the remaining 17EDR system data translation reports where recording was indicated as “complete.” Unlike the Recording Type 2 systems, where an incomplete recording was the common thread associating the “TRG Invalid #1” files within that group, whether or not the recording was complete does not appear to be the common thread in the 17EDR group and the “invalid” TRG Count anomaly.

Type of Event Marked “Invalid” During the initial review of the data translation reports, the “Crash Type” (as it is seen in the Event Record Sum68

Collision Magazine - Volume 17 Issue 1

mary) was suspected as potentially the common thread connecting the “Invalid” TRG Count in the 17EDR group data sets. For most of the first few files examined, “Side Crash” was given as the chronologically oldest recorded event and the initial thinking was that since a “Side Crash” in the 17EDR (and later systems) was described “additional information” related to a side crash and because a TRG Count was a calculated value, perhaps there was no “0” TRG to start calculating from where the initial recorded data was for a “Side Crash” (as opposed to a more complete set of data associated with a “Front/ Rear/Side Crash”). Starting with a review of the data focusing on the oldest chronologically recorded event, other “Crash Type(s)” aside from “Side Crash” began to emerge as the oldest chronological event undermining this initial working theory.

Since the TRG Count is a calculated value47 it would follow that the calculation would have to be from some event, logically, from an established “TRG1”. The 17EDR and newer systems in the Recording Type 3 group include a “Side Crash” data set where “…additional data may be recorded in a page for side crash. …” (- emphasis added, example from 05017_ToyotaS00std, 05019 Data Limitations) and a review of that data demonstrates that the recorded event data set includes far fewer elements than others the initial working theory was that this less sparsely populated event record might not include a TRG Count from which to establish a calculation IF it were to be the first recorded event. For that reason, the potential for the event type to be the reason for the “Invalid” TRG Count was, at least initially, promising.

Of 29 17EDR files where the TRG Count was marked “Invalid.” Of that 29, 13 reported the oldest chronological event as a “Side Crash,” 13 reported the oldest chronological event as a Rollover, and 3 reported the oldest chronological event as “Front/Rear/Side Crash(es).” Sorting through commonalities across the remaining, chronologically newer events focused on the order of events element, it became clear that the type of event (“Crash Type”) failed to develop as a repeatable pattern across the group of files examined.

The same analysis was done with the “second to oldest” recorded event with equally inconsistent results across the group of systems although that touches on the next filter – the order of events. Still in all, since all recorded events in those files identified the TRG Count for ALL recorded events in that data translation report as “Invalid,” and there was no apparent correlation between the initial or chronologically oldest event and the anomaly, the next possibility seemed to be the order of events.

www.collisionpublishing.com

The Order of Events Where the majority of the oldest chronological events were initially identified as Side Crash events and then an equal number of Rollover crash type files emerged, consideration was next given to the order of events. The working theory was that the timing between the oldest chronological event and the next more recent might be masking a lack of more complete information where “Side Crash” events didn’t capture all the same information as a sidebased event which was otherwise recorded as a “Front/ Rear/Side Crash.” Essentially, there appeared to be data sets where a “Front/Rear/Side Crash” and the “…additional…”48 data in the “Side Crash” recorded event were essentially the same “contact” but were reported as two events or “TRG Counts” (whether marked “Invalid” or for those which had TRG Count numbers).

After a review of the 29 files where the “Invalid” anomaly was manifest, some record sets were observed where there was no connection between the oldest chronological event and the next newest (based on the data elements used to establish the recording order49). Even where there was a connection between the events, there was no similarity between one data translation report’s order of event types and that found in another such that a meaningful and repeatable connection could be established.

To investigate the potential for the event order implication, that order was also compared to a body of 50 17EDR files where the TRG Count was (a) not marked “Invalid” and (b) the order was the same as that found in the data translation reports where the TRG Count was marked “Invalid.” Looking for a connected order of, for example, a “Side Crash” as the first chronological event and then the next newer recorded as a “Front/Rear/Side Crash” where in one set of 17EDR systems the TRG Count was reported where in another all were marked “Invalid.” No repeatable trend based on order or event type emerged in the analysis.

Where the reason for what would logically have been TRG1 from which later TRG Counts could be calculated where the event TRG Count was marked “Invalid” and that event was a “Side Cash,” the next newer chronological event could have been any type. Similarly, that order was observed in data translation reports where there were TRG Counts reported. The finding was that there was no correlation between the type and order of events. Moreover, once other initial event types (particularly “Rollover” events) were observed as the initial chronological event, it became more evident that order or initial event type was not an influencing factor in the “Invalid” TRG Count indicator.

Table 1 The Part Number Data translation reports generated by the Bosch CDR Tool software are essentially forms into which the CDR Tool Software translates the retrieved data to populate the form fields corresponding to the data elements pre-established into the report form. If one were to stop the report generation or preview process in the CDR Tool software at a point before the report fields were populated, one of the tables in a data translation report might look like that seen in Figure 16 such that the form layout would include the table title (without the specific identifier which would be added to the area in parentheses) and the data element descriptions (on the left side of the table in Figure 16). After translating the retrieved data, the CDR Tool software would populate the right side of the table – the empty fields in Figure 16 – following instructions from the OEM for each individual element.

There is a long history of the data translation report forms for a given OEM being different across module types identified by that OEM’s Data Limitations text identifier code. For example, within the larger GM “SDMG” family, the GM types identified by Data Limitations codes 01023_SDMG-99JXZ01-07, 01024_SDMG99JXZ07-08, and 01025_SDMG-99JXZ09-10 have very similar report forms but there are still differences across that group. With these GM systems, there are no part numbers displayed and the only outward module type difference is seen or identified in the form of the Data Limitations text identifier code (i.e.: 01024_SDMG99JXZ07-08 as seen above).

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 69

For Toyota systems, however, data translation reports are connected by the module type identified in the Data Limitations text identifier code and a part number found in the report, for example, as seen in Figure 14 as the element “ECU Part Number. “ Should one closely review a number of Toyota data translation reports, it would become apparent that the part number plays a significant role in the underlying data translation report layout as well as the elements in the report form (i.e.: those found on the “left side” in the example at Figure 13).

During the examination of the similarities and differences between those 17EDR files where the TRG Count was marked “Invalid” and those where the TRG Count was displayed, a common and repeatable thread developed with respect to part numbers.

In the CDR Tool Help file, there are 427 part numbers associated with 17EDR files and 70 part numbers are associated with 19EDR and 20EDR systems. During this research, several part numbers were identified in data translation reports which were NOT listed in the CDR Tool Help file Part Number list. Of 50 unique 17EDR part numbers examined as part of this analysis, the only time the TRG Count was displayed as “Invalid” (for any or all recorded events) was when the part number identified in the data translation report was from a group of 8 specific Part Numbers.

Notably, those 8 part numbers are not shared with any other ECU/EDR Generation group. Those 8 part number identified modules always display the “Invalid” TRG Count anomaly and never displayed a numerical TRGn value for the TRG Count. The data from the 17EDR systems associated with the remaining 42 part numbers never displayed “Invalid” for a TRG Count value.

The part numbers identified which always reported the TRG Count as “Invalid” and never reported a value in the TRGn format are: 89170-02N50

89170-02U20

89170-07391

89170-0C573

89170-0C583

89170-0C630

89170-0C640

89170-02X80

Once it became clear that the part number of the 17EDR was associated with the anomaly, another trend emerged.

The “System Status at Event” and “Event Record Summary at Retrieval” data tables were the same, however, the “System Status At Event” data tables for “Front/Rear/Side Crash” events were not the same. The difference highlights the relevance of the Part Number and its influence on the data translation report form.

In Table 3, select elements from the “System Status at Retrieval,” “Event Record Summary at Retrieval,” System Status at Event [TRG identifier if indicated],” and “Pre-Crash Data, 1 Sample [identifier if indicated] from a data set where the TRG Count was set out numerically (TRG6 in the example) and one where the TRG Count was marked “Invalid” are compared side-by-side. There are other data elements which are common to both sets of data and are otherwise irrelevant to this analysis which have been omitted.

Table 2 70

Collision Magazine - Volume 17 Issue 1

The data in Table 3 for the Study Module ID 20951 identifies the Most Recent Event as TRG6 and in the “System Status at Event” and “Pre-Crash Data, 1 Sample” data tawww.collisionpublishing.com

bles the title of those tables includes the identifier “TRG 6.” The data for Study Module ID 23035 does not include TRG count in either the “Most Recent Event” TRG Count identifier or in the data table titles common to the first example.

ments “Previous Crash Type” and “Time from Previous TRG (msec).”

Another notable difference observed across these two part number identified systems are the elements “Previous Crash Type” and “Time from Previous TRG (msec)” found in the “System Status at Event [TRG identifier]” data table. For the event record where there is a calculated TRG Count, those elements are associated with the previous event whereas for the 17EDR module type associated with the TRG Count anomaly, those elements are missing entirely.

“…The data recorded by the airbag ECU includes correlating information between each previously occurring event (i.e., information that clarifies the collision event sequence. This correlation information consists of the following items.

Keeping in mind that the data translation report is a form, the missing element names would be consistent with the conclusion that those elements aren’t left off by chance, they’re simply not part of the elements to be reported for this module type, based on data translation report form for that part number. None of the 17EDR systems in the group of part number identified modules where the “Invalid” TRG Count anomaly occurred included the ele-

In the Data Limitations for the 17EDR, one may find this passage:

- Time from Previous TRG - TRG Count - Previous Crash Type …”

(05017_ToyotaS00std) Obviously, all three of these elements are either wholly omitted from the data translation report or the one (TRG Count) is marked “Invalid” which leads to the question, can the represented order of events as seen in Figures 2 or 9 be considered chronologically accurate? That topic, as with the similar topic for the Recording Type 1 systems,

Figure 16: An example of how a data translation report data table might look before the Bosch CDR Tool translates data from the original .CDRx file and then populates the data element fields www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 71

is the subject of Part 2 in this series to be included in the next issue of Collision Magazine.

Summary and Conclusions The Recording Type 1 systems may potentially exhibit “TRG Invalid #1” and “N/A” in the “Event Record Summary” for one event’s chronological order and its corresponding TRG Count. The order and TRG Count anomaly were found to be associated with instances where there was an incomplete recording of the crash data. The potential for this order and TRG Count indicators is not addressed in the Data Limitations for the relevant module types or in the Bosch CDR Tool Help File.

Recording Type 2, and more specifically the 17EDR systems, have the potential for indicating the chronological order of all recorded events but, for specifically identified module Part Numbers, the TRG Count is always indicated as “Invalid.” The Data Limitations admonition with respect to establishing the chronological order is problematic inasmuch as the anomaly itself is left unaddressed and the data elements suggested to correlate the order of events are either omitted or indicated as “Invalid.” The potential for the TRG Count indicators to show “Invalid” is not readily addressed in the Data Limitations for the relevant module types or in the Bosch CDR Tool Help File.

Confirming or establishing the chronological order of events is the subject of Part 2 in this series “Trigger counts marked “Invalid” in Toyota EDR data” to be found in the next issue of Collision Magazine.

“

Digital data by virtue of its binary nature is either right or wrong.

– W. Rosenbluth

End notes 1. The introduction of Toyota data access being introduced in “March” is surely not lost on long-time CDR Tool users.

2. Some manufacturers may include a generally similar element in some of their systems’ data translation reports.

For example, in some Chrysler “System Status at Event” data tables, we may find the element “Event Number” as a chronological event (number) counter. In another example, for some General Motors system data translation reports, in varying named data tables, we may find the element “Dynamic Event Counter” or, within an individual record, the element “ Event Counter.” Other OEMs may use a similar approach although that numbering isn’t always as clear as is the case with a Ford 02007_RCM-RC6 data translation report where we may find the element “Multi-event, number of events (1,2)” used to identify a lifetime counter (number). A lifetime chronological event numbering scheme or convention is not nearly as common or universal across all OEMs as it is found in Toyota system data translation reports.

Table 3 72

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

3. As seen in the various Toyota data translation reports, the relevant data element may be found, interchangeably, as “ECU Generation” or “EDR Generation” and should be considered to refer to the same data element at least in this paper.

4. “Digital data by virtue of its binary nature is either right or wrong.” – W. Rosenbluth 5. The numbers given are approximate because, with such a large volume of data to work through, there remains the potential for a small number of duplicates to be included in the larger count. At this writing, there were, for example, 11,933 data files from the NHTSA Crash Investigation Sampling System (CISS) database for collection years 2014-2021 which were sorted and examined. Beyond that, the author accessed and culled through about 14,000 additional data files, however, it is not only possible but perhaps likely, that there were some duplicates counted in the larger total particularly with respect to those which weren’t affected by the anomalies being investigated. From the larger total, at least 3000 were identified as 04EDR or “newer” ECU Generation systems which were included in this analysis.

6. Throughout this paper we should keep in mind the admonition found at the top of every data translation report which reads: “… IMPORTANT NOTICE: Robert Bosch LLC and the manufacturers whose vehicles are accessible using the CDR System urge end users to use the latest production release of the Crash Data Retrieval system software when viewing, printing or exporting any retrieved data from within the CDR program. Using the latest version of the CDR software is the best way to ensure that retrieved data has been translated using the most current information provided by the manufacturers of the vehicles supported by this product. …”

To this end, figures taken from various data translation reports were created using the latest version of the Boch CDR Tool software which is, at this writing, Crash Data Retrieval Tool (version) 23.3 7. Data Limitations text identifier codes appear at the end of a block of Data Limitations in a data translation report generated by the Bosch CDR Tool software. They are unique to a specific set of OEM authored Data Limitations text blocks and can be used, to some extent, to identify a module type (i.e.: GM example: “01065_SDM50veoneer” or Ford example: “02018_RCM-RC8”) others

are more general for a given OEM (i.e.: Chrysler example: “03002_Chrysler”). The first two digits identify the OEM responsible for that block of Data Limitations text i.e.: GM is OEM 01, Toyota is OEM 05, and Subaru is OEM 22. The next three digits numerically identify a unique or, in some cases, a larger set of Data Limitations text. The next (“plain language” name) portion (i.e.: “SDM50-veoneer”) is often used as a more narrowly specific identifier of the Data Limitations appropriate for a module type.

For Toyota systems, digits 3-5 are used to identify the ECU Generation. For example, “05004_ToyotaFTEN” and “05004_ToyotaDENSO” are both 04EDR systems.

However, the Data Limitations text for those is for a module type specific to the first-tier supplier of the ACM at the time: Fujitsu Ten or Denso, respectively. (Although Denso and Fujitsu Ten became Denso Ten in 2017, these ACMs pre-date that merger.)

All text identifier codes include a revision number as the last 4 digits. For example, the complete code for the GM example cited as an example above is “01065_SDM50veoneer_r016” indicating that specific block of Data Limitations text is “R”evision number 16 (i.e.: R016) using the current version of the CDR Tool software. By way of comparison, the complete Ford example above is: “02018_RCM-RC8_r001” indicating, of course, the first version of that set of Data Limitations for that module.

For this paper, the revision number isn’t particularly significant inasmuch as the reader should already know (note above) what version of the software was used to generate the examples which are drawn from data translation reports for this paper and, for that reason, the revision number has been left off.

8. Ibid 9.The frequently referenced “Part 563 rule” is, more fully detailed as the US Department Of Transport regulation found at Title 49, Subtitle B, Chapter V of the Code of Federal Regulations (CFR), Part 563 “Event Data Recorders” or 49CFR563.

10. Although Denso and FujitsuTen became Denso Ten in 2017, these ACMs pre-date that merger.

11. The designation as used in the CDR Tool Help File definition.

12. For this paper, the 10EDR has been generally omitted inasmuch as it’s normally only seen outside the North American market and the data used in this analysis is limited to that collected within North America. Similarly, it is not mentioned in the Data Limitations or Help file in-

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 73

asmuch as 49CFR563 has no real application outside the United States.

13. Apart from the observation with respect to compliance with 49CFR563, another obvious difference is that through the 06EDR systems pre-crash data is captured at 1 sample per second and the 12EDR and later systems capture pre-crash data at 0.5sec intervals (setting aside the “0 TRG” sample resolution for each). The pre-crash data, however, doesn’t play a role in the recording process as it later relates to how the “invalid” indication appears in some data translation reports and not others with respect to the TRG Count.

14. Haight, W. R., Anderson B. A.. Toyota Gen1 EDR Event Recording Logic (Volume 13, Issue 2). Collision Magazine.

15. Ibid.

16. Ibid 17. Other elements including the time between events would be useful in establishing chronology, however, that element’s use is limited to events close in time to one another on the same ignition cycle.

18. The larger explanation of the “Unlinked” pre-crash data is further off-topic and best left for a separate discussion of the recording process as it relates to which event captures a set of Pre-Crash data and when that is or isn’t overwritten.

19. Although there was a time when “satellite sensors” were inexplicably represented by some to refer to GPSbased sensing of some sort and while one would hope that level of ignorance perpetuated by a tiny minority is long gone, for clarity, “satellite sensors” means “not in the airbag control module (ACM).” Rather, it means that that the sensor is remote from the central ACM. It might be compared to a “satellite office” being remote or away from the “main, home office.” Other similar references from other OEMs include “Electronic Satellite Sensors (ESS),” and “Electronic Frontal Sensors (EFS),” among other OEM specific designations.

20. Often, another source of definitions or references to terms is found in 49CFR563.5 “Definitions” or in context taken together with another definition or term in the regulation. The word “invalid” does not appear in 49CFR563 at all. Of course, neither does “Trigger Count.”

21. At the time of this writing, as found in data translation reports created using CDR Tool version 23.2.1.

74

Collision Magazine - Volume 17 Issue 1

22. According to the Cambridge Dictionary, “N/A” is a “… written abbreviation for not applicable: used on a form when you cannot give a relevant answer to a question …” or “… written abbreviation for not available: used in a list to show that something cannot be provided …”

(Cambridge Dictionary, https://dictionary.cambridge. org/us/dictionary/english/n-a) 23. Multiple simple references include: • Oxford Dictionary of Abbreviations. Oxford University Press. 1998. Retrieved 2010-11-14.

• Barbara H. Foley, English In Action (2003), p. 192.

• Alan C. Kay, J., Metzler Contracting Co. LLC v. Stephens, 774 F.Supp.2d 1073, n. 12 (D. Haw., 2011) ”…interpretation is consistent with Metzler's contention that "N/A" means "not applicable", whereas the latter is consistent with the Stephenses' contention that it means "not available", in that the contract required Metzler to prepare the preliminary budget after the contract was signed". …”

• Franklin D. Elia, J., Santa Clara Cnty. Dep't of Family & Children's Servs. v. C.K. (Cal. App., 2010): "… The abbreviation "N/A" or "N.A." or "NA" can mean "not available" as well as "not applicable". (See Webster's Ninth New Collegiate Dictionary (1990) p. 1380; Prince's Bieber Dictionary of Legal Abbreviations (6th ed. 2009) p. 420; "N/A," http://www. all-acronyms.com/N/A (September 28, 2010)".

24. For the 04EDR and 06EDR systems, the data element for complete recording is listed as “Recording Status, All Pages” whereas that element for the 12EDR, 13EDR, and 15EDR system is shown as “Complete File Recorded” the latter being consistent with the data element name as used in 49CFR563.

25. As a function of the Chinese“equivalent”of 49CFR563, cars sold in China have different requirements for Event Data Recorder-like data and would, reasonably it would seem, have a different ACM with different EDR capabilities. See also the document GRSG-117-05, 117th GRSG, 8-11 October 2019, Agenda item 19 re: Chinese Mandatory National Standard GB “Automobile Event Data Recorder system”.

26. This caveat is found with the list of supported Toyota vehicles in the Bosch CDR Tool Help file:

www.collisionpublishing.com

“… It is important to note that even if the vehicle is listed in this section, CDR must also support the part number on the ACM. [Click here] for a list of supported ACM part numbers. …” [link in the Help File] That doesn’t mean that all available part numbers are listed. It means that, when one is trying to access and retrieve data from the Toyota ACM, the Bosch CDR Tool Software will identify the part number or the specific identification of that particular module and, if that module part number is not supported, data won’t be retrieved. That fits with the Bosch CDR Tool Help file Toyota/Lexus/Scion Vehicle Coverage Note regarding part numbers which reads: “… In some cases, the part number printed on the ACM label may not be the same as the part number reported to the CDR Tool …”

And that passage is consistent with the passage from the Data Limitations which reads: “… In some cases, the airbag ECU part number printed on the ECU label may not match the airbag ECU part number that the CDR tool reports. The part number retrieved by the CDR tool should be considered as the official ECU part number. …” –(example from 05013_ToyotaS00std Data Limitations, also found in others)

27. As of this writing - Bosch CDR Tool v23.2.1 – there are no part numbers listed as associated with the 22EDR systems.

28. Given the volume and production demands on Toyota, not to mention Bosch as it relates to the CDR Tool software prioritization of coverage over convenience or reference lists, that a part number isn’t listed in the Bosch CDR Tool Help file shouldn’t really be a surprise nor should it indicate a part is not supported. The important thing is that the actual part found in the car is (or isn’t) supported for data access and retrieval once the Bosch CDR Tool software attempts to communicate with that ACM. Effectively, that’s what is being laid out in the Bosch CDR Tool Help File and Data Limitations (note above).

29. Not included in this study group were two Toyota data sets retrieved from vehicles sold in Brazil. A Hilux with a module identified as an 04EDR and an Etios with a module identified as an 06EDR. Both vehicles, the Hilux and Etios, are listed as supported in “Market Code 7” in the Bosch CDR Tool Help file under “Vehicle and cable lookup.” The data from the Etios was unremarkable and there were no anomalies observed.

The data from the Hilux is the lone example observed where the event chronology was represented as “Most Recent Event” and ”First Prior Event” and there was no indication of “TRG Invalid #1,” however, the TRG Count for both recorded events (one from a crash test) reflected “SNA” as shown below. There was no reference to “SNA” in the data limitations and the part number

As referenced above (Note 29), this is an example of the “System Status at Retrieval” and the “Front/ Rear Event Record Summary at Retrieval” data tables from a non-North American sales Toyota www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 75

(89170-0K020) is not found in the Bosch CDR Tool Help File Toyota Part Number list (the data access and retrieval was completed in-car using the actual VIN for that specific Hilux). None of the 04EDR, 06EDR, 12EDR, 13EDR, 15EDR, or 17EDR systems data translation reports reviewed indicated that the relevant part number was 89170-0K020. That part number was only found on the Hilux imaged in Brazil.

30. The complete passage from the Data Limitations is: “… The data recorded by the airbag ECU includes correlating information between each previously occurring event (i.e., information that clarifies the collision event sequence. Thicorrelation information consists of the following items.

- Time from Previous Pre-Crash TRG - Linked Pre-Crash Page - Time from Pre-Crash TRG - TRG Count - Previous Crash Type …” (- emphasis added, from example 05013_ToyotaS00std) 31. In 49CFR563, the element “Complete File Recorded” is not defined as such. It is found in tables I and III as a required data element (Table I) and in Table III the indicate is that it is a binary “yes/no” element. In table I at 49CFR563.7 Data Elements it is listed and the specified Recording Interval/Time is “Following other data.”

32. The way in which the crash pulse reporting differs is one of the reasons they are considered to be a different ECU Generation as detailed in the Help file, however that aspect is outside the parameters of the “Recording Type” as used in this paper.

33. Note that, in Figure 14, the “Longitudinal/Lateral Crash Pulse (table 2 of 2)” reported the ” Longitudinal Delta-V (MPH [km/h])” as a cumulative calculated value in km/h and converted to mph. This is consistent with the reporting requirements found in 49CFR563.8, “Data Format” Table III. For the Lateral component of the crash pulse in that table, the data is reported as “Lateral Acceleration for Frontal/Rear Crash, Floor Sensor (m/ sec^2).” That reporting is also consistent with the provisions of 49CFR563.7 such that a Lateral delta-V is an “if recorded” value in 49CFR563.7 Table II and the reporting requirement for the Lateral Acceleration as seen in 49CFR563.8 Table III is “At option of manufacturer.”

34. As found in 49CFR563.5: “… Delta-V, longitudinal means the cumulative change in velocity, as recorded by the EDR of 76

Collision Magazine - Volume 17 Issue 1

the vehicle, along the longitudinal axis, starting from crash time zero and ending at 0.25 seconds, recorded every 0.01 seconds. …”

35. Ibid 36. As found in 49CFR563: “… End of event time means the moment at which the resultant cumulative delta-V within a 20 ms time period becomes 0.8 km/h (0.5 mph) or less, or the moment at which the crash detection algorithm of the air bag control unit resets. …”

37. From exemplar set of Data Limitations for a 05013_ ToyotaS00std system: “…In frontal and rear collision events, the record time varies depending on the period during which a longitudinal cumulative delta-V of over 0.8 km/h (0.5 mph) is reached, and time series data is recorded for up to 250 ms. The record time described above is indicated as "Length of Delta-V". "Delta-V, Longitudinal" outside the record time is indicated by area shaded in the table, and not indicated in the graph. …” (-emphasis added) 38. At 49CFR563.7, Data Elements, Table I, the requirement is to report the element ‘Maximum delta-V, longitudinal” to “…0-300 ms or 0 to End of Event Time plus 30 ms, whichever is shorter…”

39. As a matter of convention, the time where the Power Supply Status change is reported here as, for example, 2030ms rather than a more precise time value (i.e.: 26ms) because (a) the data translation report doesn’t provide a more specific time value for the interruption and (b) the time increments reported in the data table follow the provisions of 49CFR563 where the reporting resolution is 10ms. The best we can do to be faithful to the data is to report the Power Supply Status change within a range following the reporting resolution.

The easiest mistake to make with this data would be to attempt to be overly precise with respect to time using the “Longitudinal/Lateral Crash Pulse ([event order]TRGn table n of n)” data table.

40. As found in 49CFR563: “…Maximum delta-V, longitudinal means the maximum value of the cumulative change in velocity, as recorded by the EDR, of the vehicle

www.collisionpublishing.com

along the longitudinal axis, starting from crash time zero and ending at 0.3 seconds. …”

41. One may have noticed in Figure 15 that the element “Recording Status, Time Series Data” (under the data table heading “Longitudinal/Lateral Crash Pulse ([event order] table 1 of 2)”) is marked “Complete.” That doesn’t change the observation for each of these examples that the more global indicator in the data translation report under the data table “System Status at Time of Retrieval” for the element “Complete File Recorded” was reported as “No.” What we see in the “Longitudinal/Lateral Crash Pulse ([event order] table 1 of 2)” data table is specific to that portion of the data. The more global “Complete File Recorded” element is for all the data which would otherwise be recorded. Another way to think of this would be to say that the element “Complete File Recorded” is for all n data tables in a data translation report and if one is incomplete, the entire set of data is marked incomplete even if all the others were properly recorded.

42. The “30ms” is in reference to the note above where at 49CFR563.7, Data Elements, Table I, the requirement is to report the element ‘Maximum delta-V, longitudinal” to “…0-300 ms or 0 to End of Event Time plus 30 ms, whichever is shorter…”

include the change in speed during the period from the start of the actual collision to establishment of the time zero. …”

45. As previously indicated, the “Recording Type 2” systems are the 04EDR, 06EDR, 12EDR, 13EDR and 15EDR systems.

46. Perhaps this sentence could be modified with the word “yet” inasmuch as there are so few examples of these module generations to work with so far.

47. From the Toyota Data Limitations for 17EDR and newer systems: “… "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. …” – (emphasis added) 05022_Toyota_Std-S02 48. As used in the Data limitations:

43. As found in 49CFR563: “Time zero means whichever of the following occurs first: (1) For systems with “wake-up” air bag control systems, the time at which the occupant restraint control algorithm is activated; or (2) For continuously running algorithms, (i) The first point in the interval where a longitudinal cumulative delta-V of over 0.8 km/h (0.5mph) is reached within a 20 ms time period; or (ii) For vehicles that record “delta-V, lateral,” the first point in the interval where a lateral cumulative delta-V of over 0.8 km/h (0.5 mph) is reached within a 5 ms time period; or (3) Deployment of a non-reversible deployable restraint. …”

44. From the Data Limitations for a 05013_ToyotaS00std system: “…"Delta-V, Longitudinal" indicates the change in forward speed after time zero. This does not refer to vehicle speed, and it does not

“… The airbag ECU has the following recording pages (memory maps) for each accident type to store event data: four pages for frontal/rear/side crash, four pages for a side crash, and two pages for rollover event.

“- When a crash impact for a lateral direction is occurred, data may be recorded in a page for frontal/rear/side crash. And additional data may be recorded in a page for side crash. …” (sic) – (Emphasis added) 05017_ToyotaS00std, 05019_ToyotaS00std, 05021_Toyota_StdS01ind1, and 05022_Toyota_Std-S02 49. For example, this from the Data Limitations: “…The data recorded by the airbag ECU includes correlating information between each previously occurring event (i.e., information that clarifies the collision event sequence. This correlation information consists of the following items.

- Time from Previous TRG - TRG Count - Previous Crash Type …”

– 05017_ToyotaS00std

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 77

What Is Tesla I Sentry Mode And How Does It Work? ntroduction

All data that might be used to identify a specific person is considered personally identifying information (PII). In order to successfully identify a person, PII may be used alone or in conjunction with other pertinent data. It may include direct identifiers, like passport information, which can uniquely identify a person, as well as quasi-identifiers, like race, which can be combined with other quasi-identifiers, like date of birth, to successfully identify an individual.

As the legal system in the USA is built of diverse regulations and different federal and state laws, the definition of PII is not as consistent or a structured as the personal data established in the GDPR (1) for the countries in the European Union. To begin with, it is challenging to distinguish between PII and personal data because PII is defined by numerous laws, rules, and policies, including: Act concerning Health Insurance Portability; American Labor Department Federal Trade Commission; Act Protecting Children's Internet Information; American National Standards Institute.

- Rehan Arif

D

Different sources define PII or particular components of it. When it comes to really establishing a list of minimum things that should be anonymized and what constitutes private, personal data, this leads to a lot of minute variances. Due to the fact that the European rule includes the connection between the personal data and an identifiable individual, which is frequently not as obvious, the GDPR's definition of personal can occasionally appear wider than the definition of Personally Identifiable Information in the US. Any data that may be used to directly or indirectly identify a person is considered personally identifiable information.

The most practical way to determine what information is and isn't Personal Identifying Information in practice is through individual assessment and paying attention to the procedure, law, regulation, or standard governing your particular State, industry, or field of application. Some examples of PII include the subject's full name, phone number, passport number, residential address, social security number, driver's license number, email address, and other digital information like IP address and geolocation. Some things, such as biometric data or medical information, are regarded as sensitive data. Yet, when contrasted to the GDPR's definition of personal data, this can be somewhat

riving safely and protecting yourself, your family, and your vehicle is more important than ever these days. If you're a Tesla owner looking for an extra layer of security, then you have to be familiar with Tesla Sentry Mode. It is configured with Autopilot Hardware HW 2.0 or newer. Video recording facility is available on HW 2.5 models built after August of 2017. Tesla has two separate programs, Tesla Dashcam, and Tesla Sentry Mode. We will explore Tesla Sentry Mode here. Tesla Sentry Mode is designed to act as an additional deterrent against theft or vandalism by monitoring your vehicle's interior and exterior from multiple cameras installed in its frame, Including front, rear, and side cameras. It uses the camera images from the front main cam, side repeater cams, backup cam, and an inertial measurement unit (IMU). Using the cameras and the IMU sensor, this mode can alert owners via mobile app push notifications so they can take immediate action if necessary. Read on to find out all there is to know about Tesla's Sentry Mode!

How Exactly Does Tesla Sentry Mode Work?

Here's how Sentry Mode works in more detail:

Tesla's Sentry Mode uses the car's cameras and sensors to detect any unusual activity around the vehicle when parked and unoccupied. When Sentry Mode is active, the system will record video footage if it detects any movement.

There are three states:

78

Collision Magazine - Volume 17 Issue 1

The car's cameras and sensors monitor the surroundings: When the car is parked and Sentry Mode is enabled, the car's cameras and sensors continuously monitor the area around the vehicle.

Detection of movement : If the cameras and sensors detect any movement, such as someone approaching the vehicle, trying to open a door, or tapping on the car, Sentry Mode will be triggered. Once activated, the owner is alerted when they return to their car - allowing them to stay aware of any potential security threats. However, when triggered in an alarm state, the car's alarms will sound which may notify nearby persons and will send a push notification to the owner via their Tesla mobile app.

Activation of recording: When Sentry Mode is activated, the car's cameras will begin recording video footage of the surroundings. The footage is saved to a USB drive connected to the car.

(1) No Response state: The vehicle appears to be off so that no alarms will sound and no recordings will be made.

(2) Awareness State: The vehicle enters this state from a trigger, such as a pedestrian walking or the car sensing

www.collisionpublishing.com

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 79

movement. In this state, the car will beep, and its lights will flash, warning anyone nearby of its active recording mode

at the front of the car to capture footage of any movement outside the vehicle.

(3) In 3rd State: When Sentry Mode is initiated, the Center screen will appear with a message indicating that recording has commenced.

Alert to the owner: The car's owner will receive an alert on their Tesla mobile app that Sentry Mode has been activated. In times of emergency, your car will alert you with a push notification.

Warning to the intruder: In addition to recording footage, Sentry Mode will also display a message on the car's touchscreen warning any potential intruders that they are being recorded.

Deactivation: Sentry Mode will deactivate when the car is unlocked or in drive mode.

Forward-facing camera

Hit-and-run Detection is another feature that Tesla Sentry Mode offers, which can help you capture the identity of any individual or vehicle that hits your car and drives away. It takes videos of the event and records the licence plate numbers of vehicles that hit your car and leave without stopping.

Overall, Tesla's Sentry Mode is a sophisticated security feature that provides additional protection for Tesla vehicles. Using the car's cameras and sensors to detect and record any unusual activity can deter potential thieves or vandals and provide valuable evidence in the event of a break-in or theft.

Four camera angles almost cover 360 degrees for a full view of the detected activities. Its integration into the Tesla system is where Tesla's sentry mode shines above all other car security systems and aftermarket and OEM components.

Where are the cameras located in Tesla used for sentry mode?

Tesla vehicles equipped with Sentry Mode have various cameras and sensors throughout the vehicle to monitor the surrounding area for any suspicious activity. These include: Forward-facing camera: Located at the top of the windshield, this camera is used for features such as Autopilot, Dashcam and is part of the Sentry Mode system. Forward facing or the main camera is used out of the triple camera assembly or the double camera assembly, depending the autopilot hardware version, newer Hardware 4 vehicles deleted the narrow camera and now only has two cameras.

80

Collision Magazine - Volume 17 Issue 1

Rear camera Rear-facing camera: Located above the licence plate at the vehicle's rear, this camera is the backup camera and serves as part of the Sentry Mode system.

Side cameras: Located on the sides of the vehicle, these cameras are used for features such as blind-spot Detection and serve as part of the Sentry Mode system. This particular type of camera is also known as a "repeater" due to its placement on the front fenders.

B-pillar cameras: Located on the B-pillars on both sides of the vehicle, these cameras are used to monitor the car's exterior. Owners receive four cameras when using sentry mode or dashcam: a front main camera two side repeater cameras and a rear camera. When sentry mode is activated, only four connected cameras will be enabled to cap-

www.collisionpublishing.com

When Sentry Mode is activated, all these cameras and sensors work together to monitor the surroundings and detect any movement, which could be suspicious activity. Suppose any unusual activity is detected while the vehicle is aware or panicked. In that case, the car's alarm will sound, and the cameras will begin recording footage (9 minutes prior and 1 minute after the event, a total of 10 minutes). The recorded footage is then saved to a USB drive connected to the car.

Inertial Measurement Unit (IMU): Equipped with a front, rear, and side camera setup, this Unit captures images from the main cam at its vanguard, followed by additional repeater cameras on either flank. Furthermore, its features provide added support for data acquisition as part of the Sentry Mode system.

How long can a Tesla stay in Sentry mode?

A Tesla can stay in Sentry mode depending on several factors, including the battery level. Sentry mode will not be applicable if the battery is lower than 20% and if there is no available storage on the USB drive. In 2020, Tesla started providing a 64GB drive as standard equipment, with the option to upgrade to 128GB for $35.

Driver side rearward facing camera

The time the car can stay in Sentry mode will depend on how long the battery can last and how much storage capacity the USB drive has.

For example, a Tesla Model 3 or Model Y may stay in Sentry mode for approximately 24 hours before the battery level gets too low. However, this can vary depending on factors such as ambient temperature, the age of the battery, and the number of Sentry mode events that occur during that time. If the battery level gets too low, the car will automatically turn off Sentry mode to prevent the battery from completely draining.

Regarding the storage capacity of the USB drive, the amount of footage that can be stored will depend on the drive's size and the selected video quality setting. A standard 64GB USB drive can typically store around 10 hours of footage at the default video quality setting, which can be adjusted in the car's settings.

Driver side forward-facing camera ture what's happening - all other sensors are still online and running but not recording any footage.

Front-facing radar: Located in the front bumper, this radar system is used for features such as Autopilot. This sensor is not enabled during sentry mode and has be shut down, so it cannot be used with the Sentry Mode system.

It's worth noting that Sentry mode is primarily designed to be used when the car is parked and unoccupied. It is intended to be used sparingly for extended periods. Using Sentry mode for prolonged periods can drain the car's battery and wear down the USB drive. New alarms and alert events will overwrite old recordings unless event clips are tagged to be saved by the owner when the internal memory peaks to maintain optimal storage.

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 81

How To Use or activate sentry mode?

To activate Sentry Mode on a Tesla vehicle, follow these steps: 1. Make sure your Tesla is parked.

2. Insert a compatible USB drive into one of the USB ports in the car's front console. Tesla recommends using a USB drive with a minimum capacity of 64 GB and a writing speed of 4 Mb/s or higher. Opt for a USB drive with ample storage space to ensure that your video footage is properly stored.

3. Your write speed should remain at least 4 MB/s and sustain throughout the transfer; this differs from peak write speeds. It's important to note that the USB 3.0 format must also be compatible with 2.0 drives to avoid compatibility issues down the line! For techsavvy people, connecting a 5 TB SSD to the USB port effectively increases storage capacity.

“

4. Tap on the Touch Controls> Safety> Sentry Mode> ON.

6. Tap on the "Security" option.

7. Scroll down to find "Sentry Mode" and turn it on.

8. Customize Sentry Mode settings if desired, such as enabling or disabling the audible alarm or selecting the video recording quality. Set camera-based Detection to get the most out of Sentry Mode. Only clips that show physical threats will be stored on the USB drive by disabling this option.

9. To adjust, touch controls > Safety > Sentry Mode > Camera-based Detection. Once you have set up Sentry Mode, exit the car and lock the doors.

10. To turn off Sentry Mode, return to the "Security" menu and turn it off.

It's worth noting that Sentry Mode is only available on certain Tesla models, such as the Model 3, Model Y, Model S, and Model X, and may require a software update to be installed on the vehicle.

Collision Magazine - Volume 17 Issue 1

For example: If you set a location as "home," then Sentry Mode will not automatically activate when you are there.

What will be the battery drain rate when Tesla is in sentry mode?

The battery drain rate of a Tesla vehicle while in Sentry Mode can vary based on several factors, including the age of the battery, temperature, and how many Sentry Mode events occur during that time.Tesla has stated that Sentry Mode uses approximately 1-2% of the car's battery daily. This means that if the car has a full charge, it should be able to remain in Sentry Mode for 2-3 days before the battery level gets too low. However, this estimate is based on ideal conditions, and the actual battery drain rate can vary depending on the abovementioned factors.

Tesla Sentry Mode is a feature that allows owners to monitor the surroundings of their car while it is parked.

5. Once enabled, when activated, the Sentry Mode icon in the controls tab will glow a fiery red.

82

If certain places need to be omitted, you can choose locations that will not receive Sentry updates. Set up exclusions for specific areas to ensure consistent accuracy and reliability., In controls> Safety>Sentry mode, You can determine whether you want Sentry Mode enabled or disabled in specific locations, such as at home, work, and your favorite destinations.

It's worth noting that if the battery level gets too low, the car will automatically turn off Sentry Mode to prevent it from completely draining. The car's owner will receive an alert on their Tesla mobile app notifying them of the action.

To minimize battery drain while using Sentry Mode, Tesla recommends the following: • Use a USB drive with a higher writing speed to minimize the time the car's cameras actively record and write to the drive.

• Park the car in a shaded area or a garage to reduce the power draw from the computer and thermal system.

Depending on the system, some vehicles have aircooled computers. In contrast, others feature watercooled systems with an electric pump and fan that circulate a glycol/water mixture around the battery and computer.

• As we discussed earlier Sentry Mode is a software application and that the vehicle computer must remain

www.collisionpublishing.com

powered to be operational. The car's low voltage system powers the cameras and computer. The low voltage battery is considered to be a low capacity and is not meant to sustain the vehicle’s low-voltage computer components for an extended period of time. While the high voltage battery is considered a large capacity battery and supports the low-voltage system when the low voltage battery needs to charge. Parking in shaded areas is highly recommended to ensure your battery life lasts longer and doesn't get drained quickly due to unnecessary use.

• Turn off the audible alarm feature in Sentry Mode settings, which can contribute to additional battery drain.

properly monitor the surrounding area without any potential interference from the car's motion. Additionally, Sentry Mode will automatically turn off if it detects that an occupant enters the vehicle, a key is detected and the driver places their foot on the brake pedal. Thus “Starting” the Tesla vehicle.

Tesla Dashcam is a feature that records the road ahead and the surrounding area while the car is in motion. We are thrilled to offer our comprehensive analysis of the Tesla Dashcam, detailed and in-depth, soon.

Does sentry mode alert your phone?

By following these guidelines, Tesla owners can help reduce battery drain while still enjoying the added security benefits of Sentry Mode.

Tesla Sentry Mode will alert the car's owner via the Tesla mobile app( if the car is in panic mode) when it detects suspicious activity. This includes an alert when Sentry Mode is enabled when motion is detected in the cameras' field of view and if the car is tampered with while Sentry Mode is active. The alert will describe the event. It will include an image or video clip of the incident, allowing you to identify and respond to potential issues quickly.

Can Tesla sleep in Sentry mode?

In summary

Yes, a Tesla vehicle can remain in Sentry Mode while the car is sleeping. The car will enter sleep mode when the car has been idle for a certain period. However, as you have learned Sentry Mode will remain active and still monitor the surrounding area. The car's battery will still be draining while in sleep mode. However, as you have learned the drain rate should be minimal. Sentry Mode should be turned off if the car is not used for an extended time.

This will help conserve the car's battery and ensure it is in optimal condition when it is ready to be driven again.

Related FAQs

Tesla Sentry Mode is a feature that allows owners to monitor the surroundings of their car while it is parked. It utilises the car's cameras and sensors to detect any suspicious activity and will alert the owner if it does. Sentry Mode can be enabled when the car is stationary, but it automatically turns off if it detects its motion. The battery drain rate of Sentry Mode can vary depending on factors such as ambient temperature and video settings. Nevertheless, it usually remains powered on for two to three days before its battery level drops too low. Therefore, if your car will not be used within that time frame, it's best practice to ensure you give the battery a full charge before use.

Can Sentry Mode record audio?

References:

No, Tesla Sentry Mode does not record audio. This is a feature that has been intentionally disabled to prevent any potential privacy issues. However, you can speak through the vehicles have a pedestrian warning speaker. You can press and hold the microphone button on the Tesla mobile app to transmit your voice through this speaker. Despite this, the car's cameras will still be actively recording video of the surrounding area, allowing you to view any suspicious activity that may have occurred. You can also adjust the video quality settings to ensure the footage captured is of the highest possible quality.

https://www.tesla.com/blog/sentry-mode-guardingyour-tesla

• Use a power source, such as a wall charger or mobile connector, to charge the car's battery while Sentry Mode is active and take use of free public chargers.

Can Sentry Mode be enabled while the car is moving?

No, Tesla Sentry Mode can only be enabled while stationary and in park. This ensures that the car's cameras can

https://www.pocket-lint.com/cars/news/tesla/160541what-is-tesla-sentry-mode-and-how-does-it-work/ https://www.youtube.com/watch?v=5CPqfxGbuIg

About The Author The author Rehan Arif's engi­neering background and interested in electric cars, SUVs, has helped him become an enthusiastic and frequent writer on a variety of electric vehicle subjects. Expect to see from from Rehan on other Tesla vehicles in future issues of Collision.

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 83

Moving Masses and Barrier Impact Dynamics Micky Marine SSi Phoenix, Inc.

84

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

A

s automobile impacts go a vehicle running into a flat, fixed, and rigid barrier is about as straightforward as it gets. The vehicle approaches the barrier at some speed; makes contact with the barrier; deforms; bounces off at a diminished speed; and comes to a stop shortly thereafter. Within this seemingly simple impact scenario, however, are some fairly interesting nuances. Shaw et al.1 seem to be the first in the open literature to hypothesize on the notion of effective mass transfer during the impact due to vehicle crush, stating, in regard to lumped-mass modeling of barrier crash tests, that “…more accuracy could be realized if the crushed masses in the model were allowed to vary with vehicle deformation, thus simulating the actual effective transfer of mass during a crash.” Twenty years later, Fossat 2 delved further into this notion and noted that “During a frontal crash, the real pushing mass is a function of time, because important parts of the car are stopped against the barrier far earlier than the passenger compartment. This variation in mass does not allow to derive straightforward [sic] the force generated by the car body during the impact.”

In treating the barrier impact as a variable-mass problem, Fossat presented an equation to determine mass versus time histories, and used these to determine the “force Fe(t) generated by the car structure during the impact” by multiplication of the mass versus time data with the accelerations measured on the car body.

The variable-mass conceptualization has been reiterated by some researchers 3, 4, 5 and it has been opined that multiplying the data recorded via accelerometers attached to the undamaged portion of the vehicle by the total vehicle mass will result in an over-estimation of the impact force and energy. Others have noted that an integration of accelerometer-based force data out to maximum displacement results in an energy loss value very close to the known approach energy of the test vehicle, while also noting inaccuracies in the integration of barrier load cell data when compared to the approach energy [6] and [7]. Here we will explore this issue a little further, starting with an examination of the variable mass concept.

The change in momentum of the system of Figure 1 is expressed as:

The force on the system is then expressed as:

Taking the limit, and noting that the ∆m∆v term is a second-order term and vanishes when the limit is taken,the force is expressed in differential form as:

Where all parameters (F, m, u, v) can vary with time.

Noting that this derivation is for the case in which masss leaving the system, it is equivalent to switch the sign on the (u – v) term and consider mass exiting thesystem to be negative transfer, and mass entering the system to be positive transfer. In doing so, we get:

Eguation 1

Variable-Mass Conceptualization Consider the situation where mass m, traveling at velocity v relative to a fixed reference frame, expels an incremental mass Dm traveling at a velocity u, also relative to a fixed reference frame, as depicted in Figure 1. From Newton’s Second Law, we know the force on a system is equal to the rate of change of the momentum (P) of the system and can be expressed as:

Figure 1: Variable Mass Momentum. www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 85

The (u – v) term in equation (1) is the relative velocity of the mass entering or leaving the system. This term is often moved over to the force side of the equation and is considered a thrust force; a term that is, of course, extremly relevant in the analysis of rocket flight.

For the fixed, rigid-barrier impact situation, mass elements are coming to a stop against the barrier (i.e., u = 0), and equation (1) reduces to:

ating two subsystems between which mass is transferred.

The time varying system boundary for this conceptualization of the barrier impact problem would be defined by the propagation of the structural deformation wave.

Contained-Mass Conceptualization Typically, in a barrier crash test there is no expulsion of mass, per se, during the impact. The vehicle remains largely intact and connected, though it does change shape through structural deformation. In keeping with this “intact” visualization, an alternative formulation of the barrier impact problem is to treat the vehicle as a contained system of mass elements that can move relative to one another as depicted in Figure 2.

The familiar-looking equation of motion for this formulation is expressed as:

Eguation 2

This equation can be integrated and rearranged to be expressed in terms of the time-varying mass function as:

Equation 4

Equation 3 This is the equation Fossat used in his reference 2 work where barrier load cell data was used for the integrated force function and the velocity (v) is derived through integration of data recorded by accelerometers installed on the undamaged portion of the test vehicle. Fossat multiplied the recorded vehicle accelerometer data by this varying mass function to determine what was called an effective force, Fe(t), which was claimed to be “strictly and directly connected with the structural performance of the body in white.” The body in white being the vehicle body without powertrain and other chassis components, etc. attached.

Note that test dummy (ATD) mass was not included in Fossat’s analysis and is not included in the above derivation.

The variable-mass conceptualization for an automobile striking a barrier is somewhat analogous to the falling chain problems that have been discussed in the literature (see references 8 and 9). This conceptualization implies a system boundary between the undamaged mass and the mass that is stacking up against the barrier, essentially cre86

Collision Magazine - Volume 17 Issue 1

Figure 2: Contained system of mass elements In this equation, mT is the total mass of the contained system, aCM is the acceleration of the system center of mass, and FEXT is the total external force acting on the system.

A passenger vehicle undergoing an impact with a rigid barrier is a body that can experience deformations sufficiently large that the acceleration of the center of mass will be different than that measured by an accelerometer affixed to the undamaged portion of the test vehicle. The deformation of the front end of the non-rigid test vehicle causes the center of mass to move rearward relative to the undamaged portion of the vehicle. Relative to a fixed reference-frame, this means the center of mass will not move toward the barrier as much as the undamaged part of the

www.collisionpublishing.com

vehicle. For barrier crash tests with ATDs in the vehicle, the position time-history of the center of mass of the system may be affected due to the fact that the ATD mass is, at best, compliantly-coupled to the vehicle. ATDs moving forward relative to the undamaged part of the vehicle may mitigate the vehicle-relative rearward movement of the system center of mass caused by structural deformation. The extent of this effect depends on the structural deformation of the vehicle, the total ATD mass relative to the vehicle, and the amount, and timing, of ATD mass excursion within the passenger compartment of the vehicle. Salient equations of motion for the contained-mass approach are provided below, derivations of which can be found in reference 10 (The initial vehicle system velocity, which is the same for the center of mass and the undamaged vehicle segment, is here designated as v0):

Equation 5

Equation 6

Equation 7

Equation 8 From these equations we see that the velocity of the center of mass is the sum of the momentum of the constituent system elements divided by the total mass of the system (eq. 5), and the change of momentum of the system is simply the change in velocity of the center of mass multiplied by the total mass of the system (analogous to a single particle of mass mT) (eq. 6). The total kinetic energy at any given time, however, is not analogous to the single particle problem in that it contains terms for the kinetic energy

of the constituent parts relative to the system center of mass (eq. 7). The work of the external force acting on the total system mass through a displacement of the center of mass is simply related to the kinetic energy change of the center of mass, as if a single particle of mass mT is moving with the center of mass (eq. 8). This integral does not, however, define the entirety of the work done on the contained system which includes work through interaction of the constituent masses (for more on this see reference 10).

Ultimately, the total work on the system is equal to the change in kinetic energy of the contained-mass system.

The system center of mass is located at a non-tangible point in space whose position cannot generally be determined through integration of accelerometer data, or tracked using available test video footage, like that of the displacement of the undamaged vehicle section. It is from crash tests with an array of load cells installed on the barrier that we can get a measure of the external force acting on the vehicle during impact. Dividing this external force data by the total vehicle system mass provides a time-history of what should be the center of mass acceleration, with subsequent integrations providing center of mass velocity and displacement. Vibrational, off-axis, and inertia effects have all been mentioned in the literature as potential sources of load cell inaccuracy 2, 6, 11 and, because the system center of mass is not a tangible, visible point in space, there is no readily available method to quantitatively compare the load cell-derived center of mass displacement calculations to assess their time-history accuracy.

There are, however, some things we should expect from reliable load cell data based on the contained-system equations above. For barrier impacts with no ATDs we should expect that the accelerometer data and the load cell-based center-of-mass acceleration data both integrate to zero velocity at the same time (i.e., TZVU = TZVC, or as close as numerical integration processes allow); that the maximum displacement of the center of mass (XMC) is less than the maximum undamaged vehicle displacement XMU); and that the delta-V, impulse, and energy loss counterparts for the respective sets of data are equal to one another at both time-of-zero-velocity and at the time the vehicle separates from the barrier (again, as close as numerical integration processes allow).

For barrier impacts with ATDs in the test vehicle, things are a bit more complicated. Often, in a barrier crash test, at the time the undamaged portion of the vehicle comes to stop against the barrier (TZVU), the ATDs are ob This force calculation is not a physically consistent means to determine the external force acting on a system with mass elements that move relative to one another. As men-

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 87

served to still be moving forward to some degree, which means the center of mass velocity is non-zero (though could be small) and TZVC is therefore necessarily greater than TZVU. The maximum displacement xMC may be less than or greater than xMU depending on structural deformation and ATD mass, excursion, and timing. Additionally, at TZVU we should expect the following qualitative results:

Equation 9

Equation 10

tioned above, it has been observed that an integral of the quasi force over undamaged vehicle displacement results in an energy loss value very close to the known approach energy at the moment of maximum undamaged vehicle displacement (i.e., maximum structural deformation), while integrations of load cell barrier data over this same displacement have not. This has led to some confidence in the quasi force over that of load cell barrier data for energy loss calculations. As it happens, the energy loss calculation using the quasi force will result in a value very near the known approach energy because it is mathematically built-in to do so. This is due to the underlying integration process as shown in equation 14 (subscript U denotes undamaged vehicle). In fact, any crash pulse function (e.g., a center of mass acceleration function) with an area greater than the impact velocity will reduce to this same kinetic energy change value when using the zero-velocity integral limit because it must.

It has been common practice to plot barrier load cell force data against the accelerometer-derived displacement of the undamaged portion of the vehicle. While this pro-

Equation 11 At the time the system center of mass comes to a stop (TZVC), the center of mass delta-V should be less than that of the undeformed portion of the vehicle:

Equation 14 Equation 12 And, lastly, at the time the vehicle separates from the barrier, the ATDs are often observed to either be moving with the vehicle or with a rearward velocity relative to the vehicle. In this situation, we should expect the center of mass delta-V to be equal to, or greater than, the undamaged portion of the vehicle:

Equation 13

A Barrier Crash Test Example

Note that in neither the variable mass nor the center of mass derivations do we find that the external impact force acting on the vehicle is determined through simply multiplying the acceleration measured on the undamaged portion of the test vehicle by the total mass of the vehicle (referred to herein as the quasi force).

88

Collision Magazine - Volume 17 Issue 1

duces a plot of the external force acting on the vehicle system as a function of dynamic vehicle deformation, an integration of this plot should not be expected to result in an accurate energy loss value at dMU ; it is not the proper integral to define the work done o n the vehicle system.

The barrier load cell data (the external force) is directly related to center of mass motion rather than motion of the undamaged vehicle body and a plot of the barrier load cell force as a function of undamaged vehicle displacement is more a mapping of the external force onto this displacement domain than the creation of a physically consistent force-displacement relationship.

We’ll move from the theoretical to the practical by examining a New Car Assessment Program (NCAP) frontal barrier crash test (NHTSA #6201) of a 2008 Nissan Pathfinder. ASCII data files for the test were downloaded from the NHTSA crash test database 12 and there were no indications of instrumentation or data acquisition problems for relevant data channels in either the test report or

www.collisionpublishing.com

the EV5 data channel summary file that accompanied the download material. Where applicable, all calculations using the crash test data were conducted utilizing SAE J211 digital filtering recommendations, and NHTSA’s “SignalBrowser” 13 was used to perform the filtering operations.

For this crash test evaluation, the filtered load cell data channels were summed to determine the total load cellbased impact force. Data from the left rear and right rear seat crossmember accelerometers were averaged then numerically integrated to determine undamaged vehicle velocity and undamaged vehicle dynamic displacement. The barrier load cell data were numerically integrated over two dynamic displacement data sets to compare energy loss curves. The two displacement data sets were calculated by: (1) double integration of the accelerometer data, as mentioned above, which produces the dynamic displacement of the undamaged portion of the test vehicle; and (2) double integration of the total barrier force divided by total vehicle mass (center of mass acceleration) to determine the center of mass displacement. Force versus time and force versus displacement data from these calculations areshown in Figure 3.In the right panel of this figure, the load cell force data is plotted against center of

mass displacement (Load Cell/C.M.); the load cell force data is mapped to the undamaged vehicle displacement (Load Cell/Undamaged); and the quasi force data is plotted against undamaged vehicle displacement (Quasi/Undamaged). In this figure we see that xMC is found to be less than xMU; the mapping of the load cell force data onto the undamaged displacement is a stretching of that data along the horizontal axis; and the quasi force has a similar general trend to the load cell data, but with different characteristics in terms of where peaks and valleys occur.

The data from this frontal barrier crash test satisfy the qualitative conditions discussed above. The velocity versus time plot of Figure 4 demonstrates some of these conditions where we see that TZVC is greater than TZVU with the ATDs observed in the crash test video continuing to move toward the barrier at TZVU (see upper images of Figure 5); the center of mass delta-V is less than that of the undamaged portion of the vehicle at both TZVU and TZVC (also satisfying the qualitative impulse condition); and the center of mass delta V is larger than that of the undamaged portion of the vehicle around the time the vehicle separates from the barrier at approximately 150 milliseconds - with the ATDs observed in the crash test video

Figure 3: Nissan Pathfinder Force Plots www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 89

to be moving rearward relative to the vehicle (see lower images of Figure 5).

An energy loss versus dynamic displacement plot for this crash test is shown in Figure 6 with the respective curves found through integration of the force versus displacement curves of Figure 3. In this plot, as discussed above, wsee that the Quasi/Undamaged data lands very near the known approach energy value at xMU, and the Load Cell/C.M. data in turn lands very near the known approach energy value at xMC. We also see in Figure 6 that the energy loss curve for the Load Cell/Undamaged case lands at xMU, as it mathematically must, but at an energy loss other than the approach energy value. In this case, the calculated value is noticeably greater (in magnitude) than the approach energy value, which is consistent with the calculated overpredictions of energy loss reported in references [6] and [14].

At this point it seems fair to ask: Do any of the three curves presented in Figure 6 provide a meaningful representation of energy loss as a function of vehicle structural deformation? The Load Cell/C.M. curve provides a representation of center of mass kinetic energy change as

a function of center of mass displacement, not as a function of structural deformation; the Load Cell/Undamaged curve, as noted above, represents an energy loss derived from an improper energy loss integral and clearly results in an inaccurate energy loss value; while the Quasi/Undamaged curve is based on a force calculation that does not evolve from derivations using fundamental principles.

Recalling the kinetic energy relationship of equation 7, the total change in kinetic energy for the contained-mass vehicle system can be expressed as shown below in equation 15. The calculation to create the Load Cell/C.M. curve in Figure 6 includes only the first term of equation 15, which, while being valid for the change in kinetic energy of the center of mass, is an incomplete accounting of the energy loss of the vehicle system. The second term of this equation is related to the undamaged vehicle segment mass that can move at a velocity different than that of the center of mass; the third term is related to the portion of vehicle mass stacking up against the barrier which, because it is stopped against the barrier, has a velocity relative to the center of mass simply equal to the center of mass velocity; and the fourth term is related to ATD

Figure 3: (Continued) 90

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Figure 4: Nissan Pathfinder Velocity Comparison Plot

Figure 5: ATD Position at Times BracketingTime-To-Zero-Velocity and Barrier Separation www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 91

Figure 6: Nissan Pathfinder Energy Loss Comparison Plot mass moving relative to the system center of mass within the occupant compartment. Focusing on the second term and third terms and using equation 5, we calculate the undamaged vehicle mass (mU) and the stack-up mass (mSt) time-history as equations 16 and 17.

With regard to the fourth term in equation 14, we note that in the Nissan Pathfinder crash test, Hybrid III 50thpercentile male ATDs were positioned in both front seat locations and one-year-old CRABI ATDs were positioned in child restraint systems installed at both rear outboard seat locations. The total ATD mass comprised approximately 7% of the total vehicle system mass. Instrumentation installed in both front ATDs included chest and pelvic accelerometers. Integrating this accelerometer data and averaging the chest and pelvic integrations for each ATD provides, for our purposes, a reasonable estimate of the ATD center of mass velocity up to time TZVU. The results of the front ATD velocity calculations are shown in Figure 7 along with the system center of mass velocity, 92

Collision Magazine - Volume 17 Issue 1

the undamaged vehicle segment velocity, and a marker for TZVU included for reference.

In Figure 8, the vehicle system kinetic energy change, using the ATD velocities along with equations 15 through 17 and Fossat’s mass time-history corrections 2, is plotted against undamaged vehicle displacement. Also included in this figure is the Quasi/Undamaged curve from Figure 6 for comparison. With the contained-mass kinetic energy change mapped onto the undamaged vehicle displacement, we end up with the Quasi/Undamaged energy loss calculation are not terribly different from one another.

This result indicates a potential usefulness in that an energy loss versus structural deformation proxy may be available to an analyst for those crash tests in which barrier load cell data is either not recorded or is not reliable.

The proxy energy loss (EP) is found through equation 18 in which the motion parameters aU, vU, and xU can all be very readily determined from accelerometer data recorded at some location on the undamaged portion of the test

www.collisionpublishing.com

vehicle. This energy loss proxy ultimately reduces to what we’ll call the quasi-kinetic energy change.

Lest we leave off with only one example comparing contained-mass kinetic energy change calculations to quasi force-derived energy loss, the same analysis procedure was applied to data from eight other NCAP frontal barrier crash tests. The resulting data plots from these analyses, along with vehicle year/make/model, and NHTSA test number, are presented in Appendix A. In each of these respective plots we again see a fairly close following of the contained-mass kinetic energy change calculations by those derived solely through undamaged-vehicle accelerometer data. That the quasi-kinetic energy change based on the total system mass and the velocity of the un-

damaged segment of the vehicle should approximate the contained-mass vehicle system change in kinetic energy, as represented in equation 19, is not evident from the derivation of the equations of motion through fundamental principles. Nonetheless, the quasi-kinetic energy change appears to be a simply-calculated approximation to the contained-mass vehicle system change in kinetic energy.

Thinking in terms of a force-displacement plot, the quasi force relationship to vehicle structural deformation is a compliment to the quasi-kinetic energy change, and one that can be integrated directly to an approximation of the vehicle energy loss.

We’ll wrap this article up by noting the following:

Equation 15

Equation 16

Equation 17

Equation 18

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 93

Figure 7: ATD Velocity Comparison Reliable barrier load cell data plotted against load-cell-derived center of mass displacement will provide an accurate accounting of the external force applied to the vehicle as a function of center of mass motion. Integrations of this data produce accurate values of the change in kinetic energy of the system center of mass, but not for that of the vehicle system as a whole. Reliable barrier load cell data plotted against undamaged vehicle displacement provide an accurate mapping of the external force acting on the vehicle system as a function of dynamic structural deformation. However, because the measured external force is related to the motion of the system center of mass rather than that of the undamaged portion of the test vehicle, integrations of this mapping should not be expected to result in accurate energy loss versus structural deformation values.

An accurate energy loss calculation for the vehicle system is found through the use of the appropriate change in kinetic energy equation for a contained-mass system (equation 15), and takes into account the change in center of 94

Collision Magazine - Volume 17 Issue 1

mass kinetic energy as well as the change in kinetic energy based on the motion of ment, the mass stacking up against the barrier, and ATD mass relative to the center of mass.

The multiplication of vehicle accelerometer data by total vehicle system mass (the quasi force) is a force calculation that does not appear in either the variable-mass or contained-mass formulations, and is not a proper determination of the external force acting on a vehicle system with mass constituents that move relative to the system center of mass. The quasi force calculation is simply a scaling of the mechanical response (acceleration) of the undamaged portion of the vehicle to the external force acting on the vehicle system and may therefore have some qualitative value to an analyst.

For the crash tests evaluated herein, an integration of the accelerometer-based quasi force over undamaged vehicledisplacement results in the quasi-kinetic energy loss, and appears to be a reasonable proxy for the contained-mass change in kinetic energy calculation plotted against this

www.collisionpublishing.com

Figure 8. Nissan Pathfinder Kinetic Energy Change versus Undamaged Vehicle Displacement

Equation 19

same displacement. This may be useful to an analyst in those situations where reliable barrier load cell data is not available.

References 1. Shaw, L., Brammeier, G., and Anderson, R., “Front End Structures Crash Response Characterization,” Society of Automotive Engineers Paper No.740571, 1974

2. Fossat, E., “Mathematical Models to Evaluate Structural Forces in Frontal Crash Tests,” Proceedings of the 14th International Technical Conference on Enhanced Safety of Vehicles, 94-S8-O-04, 1994 3. Monson, K, “Magnitudes and Mechanisms of Planar Restitution in Motor Vehicle Collisions,” Master’s Thesis, Brigham Young University, 1997 4. Woolley, R., Asay, A., and Buzemon-Jewkes, D., “Crash Testing with a Massive Moving Barrier as an Accident Re-

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 95

construction Tool,” Society of Automotive Engineers Paper No. 2000-01-0604, 2000

10. Greenwood, D., “Principles of Dynamics, 2nd Edition,” Prentice-Hall, Inc., New Jersey, 1988

5. Wood, D., Veyrat, N., Simms, C., and Glynn, C., “Limits for Survivability in Frontal Collisions: Theory and Real-Life Data Combined,” Accident Analysis & Prevention, Vol. 39, pp 679-687, 2007

11. Chao, Y., “Inertia Effect in Dynamic Impact Tests,” Society of Automotive Engineers Paper No. 2004 010814, 2004

6. Varat, M., and Husher, S., “Vehicle Impact Response Analysis Through the Use of Accelerometer Data,” Society of Automotive Engineers Paper No. 2000-01-0850, 2000 7. Bare, C., Peterson, D., Marine, M., and Welsh, K., “Energy Dissipation in High Speed Frontal Collisions,” Society of Automotive Engineers Paper No. 2013-010770, 20138. de Sousa, C., and Rodrigues, V., “Mass Redistribution in Variable Mass Systems,” European Journal of Physics, Vol. 25, 2004 8. de Sousa, C., and Rodrigues, V., “Mass Redistribution in Variable Mass Systems,” European Journal of Physics, Vol.25, 2004

12. National Highway Transportation Safety Administration Vehicle Crash Test Database, URL: www.nhtsa.gov/ research-data/research-testing-databases#/vehicle 13. National Highway Transportation Safety Administration Signal Analysis Software for Windows, URL: www. nhtsa.gov/databases-and-software/signal-analysis-software-windows 14. Hunter, R., Fix, R., Lee, F., and King, D., “Using Force-Displacement Data to Predict the EBS of Car into Barrier Impacts,” Society of Automotive Engineers Paper No. 2016-01-1483, 2016

9. Tiersten, M., “Force, Momentum Change, and Motion,” American Journal of Physics, Vol. 37, 1969

96

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Appendix A – Kinetic Energy Change Comparison

Figure A: 12015 Mitsubishi Mirage (#9030)

Figure A2: 2002 Daewoo Nubira (#4239) www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 97

Figure A3 : 2014 Honda Odyssey (#8487)

Figure A4: 2005 Chevrolet Express (#5265) 98

Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Figure A5: 1999 Dodge Grand Caravan (#2997)

Figure A6: 2004 Ford F150 SuperCab (#4890) www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 99

Figure A7 : 2004 Toyota Highlander (#4930)

Figure A8: 2006 Ford Fusion (#5546) 100 Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Go to www.collisoinsafety.net for class locations and schedules

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 101

CATAIR 2022 Crash Conference Michael Rosenfield RSR Engineering

Robert D. Anderson Biomechanics Analysis

T

he Canadian Association of Technical Accident Investigators and Reconstructionists (CATAIR) was founded in 1984, initially to provide all accident investigators, the majority of whom were serving as Police Officers within Canada, a professional and affordable mechanism in which to meet and share experiences and ideas. The association has grown from the concept stage, with an original membership of fewer than 20, to a maintained membership of approximately 300. Membership is maintained throughout Canada, the USA, Singapore, Australia, and Brazil.

The 2022 Crash Conference was held at the Ontario Police College, Aylmer Ontario, Canada.

102 Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

The college is on the site of WWII airfield, with a number of taxiways usable for testing. The largest is 75’ wide and 1600’ long, which allowed for a number of high-speed collisions.

The 2022 CATAIR Crash Conference featured pre-conference front– and rear-to-barrier crash tests using a BMW X-5 SUV. The X-5 was equipped with active head-restraints.

Reference instrumentation measured pre-crash and crash data to allow comparison with the EDR data from the Bosch-supported Airbag Control Module. ACM-measured delta-V was 6.8 mph rearward, and 7.5 mph forward.

There were five front-to-barrier impacts with gradually increasing magnitude before a non-deployment event was recorded for an ACM-recorded impact speed of 10 mph. A rear-to-barrier impact created a deployment event with activation of the active head restraint in an ACM-recorded impact speed of 9 mph.

The results of this testing is covered in more detail in “Performance of BMW Event Data Recorder in Instrumented Barrier and Vehicle-to-Vehicle Crashes”, in this issue of Collision Magazine.

The second pre-conference test measured vehicle accelerations and occupant forces when running over the Stop Stick® tire-deflation device that has three Teflon coated hollow steel quills. This device causes the tires that run over it to deflate in 20 to 30 seconds.

Attendees have the opportunity for an “on-scene” investigation experience, plus full access to documented crash examples at known speeds, Delta V’s, etc. This wealth of information is useful in supporting or demonstrating collision principles, vehicle and occupant dynamics, vehicle performance, as well as the opportunity to compare reconstruction methods against actual test results.

Certainly, the chance to compare the output from reference instrumentation to roadway evidence, EDR data, video analysis, etc. is invaluable. Specific examples of study from this test series would include type of events recorded by vehicles’ modules, as well as the accuracy and polarity of EDR reported parameters.

Besides vehicle accelerations and Delta V’s, and occupant accelerations and seat belt load cells, the instrumentation included vehicle angular rates, and impact speeds measured using Racelogic VBOX equipment. The documentation package, which is included in the conference materials, includes photographs, on-board, ground based and aerial drone video, as well as on-board and off-board high speed video. www.

www.collisionpublishing.com collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 103

The 2022 Crash Conference was held at the Ontario Police College, Aylmer Ontario, Canada.

The college is on the site of WWII airfield, with a number of taxiways usable for testing. The largest is 75’ wide and 1600’ long, which allowed for a number of high-speed collisions

Crash 1 was an angled impact into a concrete barrier at 50 mph 104 Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Vehicle was a 2017 Ford Explorer Interceptor

Breaching the barrier www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 105

Data captured by the vehicle’s ACM compared closely to that captured by test equipment As can be seen, the barrier did not withstand the vehicle impact 106 Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Crash 2 was a 2021 Toyota Tacoma ramp-induced rollover Pulled at 45 mph using a cable-and-pulley system www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 107

Final resting position

Crash 3 was a 2021 Toyota Tundra, driven by Phantom Driver remote-control at 48 mph, into the rear of a stopped 2017 Corolla 108 Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Impact alignment for the 3 car test

The throttle was dropped in the Tundra 1 second before impact to see if the Automatic Emergency Braking would mitigate the collision; it did not

Crash 4 Two-vehicle collision, both moving. Initial contact www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 109

Crash 4 was a 2021 Toyota Tundra, pulled by cable at 45 mph Into the rear of a 2005 Toyota Echo pulled by cable at 11 mph

Crash 5 was a 2021 Toyota Tacoma, driven by Phantom Driver remote-control at 69 mph, steered and counter-steered to induce a roll-over. The ABS/Vehicle Stability Control was disabled so that it didn’t counter the yaw 110 Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Crash 6 2021 Toyota Tundra pulled by cable at 51 mph. Ramp-induced rollover

Crash 6 midair

Crash 6 initial ground impact

Crash 7 High Speed Rear Quarter Crash where A 2016 BMW X5 was driven by Phantom Driver remote-control www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 111

A 2016 BMW X5 was drive into rear quarter of a 2008 Ford Freestyle at 79 mph

This resulted in a -26 mph delta-V to the BMW, and significant post-crash rotation of both vehicles 112 Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

Crash 8 was a crash where a 2013 Mini pulled by cable at 92 mph into a high barrier

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 113

From Crash 8, the Mini essentially cleared the barrier.

Summary Attendees had the opportunity for an “on-scene” investigation experience, plus full access to documented crash examples at known speeds, delta V’s, etc. This wealth of information is useful in supporting and demonstrating collision principles, vehicle and occupant dynamics, vehicle performance, as well as the opportunity to compare reconstruction and biomechanical methods against actual test results.

Certainly, the chance to compare the output from reference instrumentation to roadway evidence, CDR data, video analysis, etc. is invaluable.

114 Collision Magazine - Volume 17 Issue 1

Specific examples of study from this test series would include type of events recorded by vehicles’ Airbag Control Modules, accuracy of CDR reported parameters, postcrash decelerations, and the characteristic tire marks from the natural steering-induced rollover during Test 5, and the post-crash spin outs during Test 7.

Acknowledgements Thanks are due for the support and generosity of CATAIR, Ontario Police College. and the crash team, which includes: Crash Data Specialists, Accident Analysis and Reconstruction, 3 Axis Engineering, RSR Engineering, Biomechanics Analysis, and Collision Forensics, and many others.

www.collisionpublishing.com

www.collisionpublishing.com

Collision Magazine - Volume 17 Issue 1 115

116 Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com

120 Collision Magazine - Volume 17 Issue 1

www.collisionpublishing.com