Mono5 2009

Black Box Data
from Accident Vehicles

Methods of Retrieval, Translation, and Interpretation
William Rosenbluth
Black Box Data from Accident
Vehicles: Methods of
Retrieval, Translation,
and Interpretation
William Rosenbluth
ASTM Stock Number: MONO5
ASTM International
100 Barr Harbor Drive
PO Box C700
West Conshohocken, PA 19428–2959
Printed in the U.S.A.

Library of Congress Cataloging-in-Publication Data
Rosenbluth, William, 1939–

Black box data from accident vehicles: methods of retrieval, translation, and interpretation/
William Rosenbluth.
p. cm.
Includes bibliographical references.
“ASTM Stock Number: MONO5.”
ISBN 978-0-8031-7003-2
1. Automotive event recorders. 2. Traffic accident investigation—Instruments. 3. Automobiles—Dynamics—Data
processing. 4. Automobiles—Crash tests. I. Title.
TL272.54.R67 2009
629.28’26—dc22
2009021150
Copyright © 2009 ASTM International, West Conshohocken, PA. All rights reserved. This material may not be reproduced
or copied, in whole or in part, in any printed, mechanical, electronic, film, or other distribution and storage media, with-
out the written consent of the publisher.
Photocopy Rights
Authorization to photocopy items for internal, personal, or educational classroom use of specific clients, is
granted by ASTM International provided that the appropriate fee is paid to ASTM International, 100 Barr Harbor
Drive, PO Box C700, West Conshohocken, PA 19428–2959, Tel: 610–832–9634; online:http://www.astm.org/
copyright/
Printed in
Newburyport, MA
September, 2009
Dedication
This book, as was my first, is dedicated to my wife, Jean Joy Rosenbluth. Her continuous support, encourage-
ment, and patience facilitated much of the work discussed herein. She is the best thing that ever happened to
me.
William Rosenbluth
Reston, VA
iv
Foreword
The objective of this publication is to build on the concepts presented in ASTM Monograph 41 by providing specific examples of
the translation and interpretation of raw downloaded hexadecimal data into engineering units useful to the engineering investi-
gator. This will include illustrations of specific data interpretation and scaling constructs and examples of specific spreadsheet
formulations to import and translate those data into useful engineering units.
Before proceeding with specific and detailed examples, and for those not familiar with ASTM Monograph 4, the broad
concepts used in the field are discussed in Chapter 1. Those well versed in the broad concepts can proceed directly to a more
detailed discussion of geometric conventions and crash data nomenclature covered in Chapter 2. Lastly, those well versed in
concepts, crash event geometric conventions, and crash event data nomenclature can proceed directly to the data examples in
Chapter 3.
In order to enhance chapter independence and immediate clarity, certain acronyms may be repeatedly defined in succeed-
ing chapters. This is to allow each chapter to be independently understood.
The principles and methods discussed in Chapters 2 and 3 are good engineering science, but they are only of academic
value unless they can be applied for a business purpose. Analysis and improvement of system designs is one such purpose.
Another such purpose is to conduct analysis for purposes of illuminating engineering issues in litigation. In that context,
the investigator is often tested as to his/her methods and their reliability, repeatability, usage by industry peers, and error rates.
Chapter 4 presents a discussion of some considerations regarding those tests and methods to assure that one can pass those
tests.
The reader should note that many different data retrieval and analysis situations may occur, and that, while this work is
designed to present a representative set of such situations, it cannot cover every possible situation.
1
Investigation and Interpretation of Black Box Data in Automobiles: A Guide to the Concepts and Formats of Computer Data in Vehicle Safety and Control Systems,
jointly published by the ASTM International, West Conshohocken, PA, and the Society of Automotive Engineers 共SAE兲, June 2001.
v
Acknowledgments
The author wishes to acknowledge and thank the following people whose interest, participation and contribu-
tions unquestionably enhanced the content and quality of this book:
Karen Bosch, Bosch Automotive Consulting, Inc., Phoenix, AZ, for her review of many preliminary drafts, for
her implementation of many of the spreadsheet examples discussed here, and for her contributions to the
practical illustration of these data.
Fred H. Chandler, Jr., Chandler & Sons Automotive, Sterling, VA, for his skilled participation in many of the tests
described herein, for his assistance with the design and testing of special test equipment for many of the tests
herein, for his exhaustive searching and obtaining the exemplars in many of the examples herein, for the use of
his inspection facility and for the use of his extensive automotive electronics commercial scanner and test tool
resources.
Dr. Eugen I. Muehldorf, TRW, retired, Potomac, MD, for his critical review of the physics, mathematics and
concepts referenced herein.
Gerald Rosenbluth, Automotive Consulting Services, Inc., Tempe, AZ, for the use of his extensive library of
specifications and service data, and for his professional inspection facilities, used to conduct some of the tests
documented herein.
Leon Russell, Esq., Russell & Shiver, Dallas, TX, for his support and encouragement of certain extended retrieval
and analysis methods which made new achievements possible.
Mark Shattuck, Kinetic Engineering, Woodside, CA for his critical and detailed review of the content and
reference integrity in the final draft.
Contents
Chapter 1—Introduction 1
Chapter 2—A Review of the Nomenclature, Mathematical and Geometric Conventions Used in Describing Crash
Event Data 2
2.1 Geometric Conventions for Crash Event Pulses 2

2.2 Deployment Metrics as Illustrated for Frontal Air Bag Systems 2
2.3 Electronic Data in Air Bag ECUs 3
2.4 The Steps to Achieve Engineering Units from Raw Data Inside an ECU/EDR 5
2.5 Deriving a Scaling and Transfer Relationship from the Data 9
Chapter 3—Examples and Exercises in Data Translation 11
3.1 Example 1: Creating a Linear Data List from Hex Data Blocks 12
3.2 Inductively Deriving a SLOT Factor from Component Specifications, Translating Acceleration
Data, and Interpreting that Data into Cumulative Velocity Loss „Delta V… 19
3.3 Deductively Identifying EEPROM Parameters from Published Data and Deductively Deriving
the Required SLOT Factors that Translate Raw EEPROM Data into Cumulative Velocity Loss
„Delta V… 25
3.4 Data Import Methods, Mapping Templates, and Introduction to Data Mining 42
3.5 Multibyte and Bitmap Translation as Applied to Diagnostic Trouble Codes „DTCs… 55
3.6 Analysis of EDR Accelerometer Running Data to Determine Acceleration Impingement Vectors 62
3.7 Analysis of ABS Wheel Speed Sensor Running Data to Determine Detected Pulse Rate
Consistency 68
3.8 Using Hardcopy Crash Test Data to Characterize Specific EDR Performance versus EDR Family
Performance 83
Chapter 4—EDR Data Considerations with/respect/to Evidentiary Reliability and Interrogation Procedures 90
4.1 The Role of Event Data and Data Translations 91

4.2 Veracity Requisites for EDR Data Retrieval 91
4.3 Rules for the Application of EDR Enginering Data in Litigation 92
4.4 Protocols, Procedures, and Practices used in Interrogating EDR Data where Proprietary Data
and/or Retrieval Methods are Involved 93
4.5 An Example Protocol for Interrogating EDR Data where Proprietary Data and/or Retrieval
Methods are Involved 94
4.6 An Example of Error Rate Calculations to Satisfy Litigation Tests 95
Subject Index 99
MON05-EB/Sep. 2009
1
Introduction
IN THE LAST FIVE YEARS IT HAS BECOME INCREAS- The nonvolatile electronic memory within most ECUs
ingly common knowledge that many automobiles and heavy retains its data even when the battery is disconnected.3 This
trucks incorporate devices which act as data recorders, trig- is functionally similar to contemporary digital photographic
gered by the occurrence of an abnormal driving event, such storage, which uses nonvolatile memory to accomplish that
as hard braking or a deceleration event greater than what identical function. Nonvolatile data storage can be accom-
can be physically experienced in normal road operations.1 A plished using flash memory or by using EEPROM.4
device that can do this is known generically as an event data Nonvolatile memory data are universally retrieved from
recorder 共EDR兲. EDRs can exist as a stand alone function, in- any particular ECU via a serial data interface. Serial data in-
dependently accumulating data from dedicated sensors, or terfaces can have many formats, data rates, and security
they can be more global, accumulating data from param- keys, so that accessing those data can be a very sophisticated
eters broadcast on a vehicle network 共data bus兲. exercise which often requires a small interrogating com-
Most commonly understood passenger EDRs for pas- puter to accomplish the data access. Although some EDR
senger vehicles are incorporated within an air bag electronic data can be retrieved with an electronic device called a
controller or an engine electronic controller, whereas most scanner,5 most require a microprocessor/data interface. Not-
commonly understood EDRs for heavy trucks are incorpo- withstanding what retrieval device is used, both operate in
rated solely within an engine controller. EDR-like subfunc- much the same way as a credit card terminal is used to query
tions can be incorporated into the operation of other system a central data bank to authorize a credit purchase, with a se-
devices such as antilock braking controllers, stability con- ries of “handshakes” to validate the data inquiry and re-
trollers, etc. Modern vehicles can often have more than one sponse.
device functioning as an EDR 共e.g., restraint controller and Since most vehicle ECUs are already communicating on
engine controller兲. EDR data, normally thought of as crash one or more intravehicle data networks, data retreival from
event related, can also be associated with the diagnostic most ECUs is often accomplished using a retrieval device
trouble code 共DTC兲 freeze frames.2 This is especially true connected to the appropriate vehicle network. These net-
with heavy truck data. Thus, the concept of vehicle black box work interfaces generally have standardized connection
data is actually an umbrella term, which implies using data ports, SAE J1962 and SAE J1587 being the most common.
components that may be obtained by interrogating several Contemporary ECU function is generally accomplished
different system units, but which can be assembled as an en- by a central integrated circuit combining an arithmetic core
semble to provide a set of electronically saved data useful to and several peripheral functions 共ALU, RAM, ROM, EE-
the accident investigator. PROM, Comm, etc.6兲. Such a combined device is typically re-
The feasibility of having EDR data is made possible by ferred to as a microcontroller unit 共MCU兲 or microprocessor
the incorporation of nonvolatile electronic memory in the unit 共MPU兲. Some MCUs/MPUs contain integrated EE-
vehicle functional control device. A computer control device PROM and some operate with EEPROM/flash memory in an
is generically known as an electronic control unit 共ECU兲. integrated circuit device external to the MCU.
ECUs are used in modern vehicles to perform logical and Notwithstanding where it resides, access to those non-
parametric control of various vehicle functions and systems, volatile data is generally accomplished via a serial 共network兲
and they have proven to be much more cost effective than data port on the ECU/EDR. That data port is where the re-
traditional mechanical or electromechanical techniques. trieval scanner/computer retrieves its data.7
1
Normal road operations, acceleration, and braking 共deceleration兲 have a theoretical limit of 1g 共where 1g is that acceleration of gravity兲. Typical vehicle maximum
acceleration values vary between 0.4 and 0.6g, and typical vehicle maximum deceleration values vary between 0.6 and 0.8g. Typical thresholds are 0.65– 0.75g
deceleration for hard braking and 1.5– 2.5g deceleration for a potential crash event 共calculation start threshold, “algorithm wakeup”兲.
2
DTCs are also called error codes. DTC freeze frame data are data parameters associated with and existing at the time of the confirmation of a DTC condition.
3
This can include calibration data, adaptive learning and optimization data, and, of course, crash-event-related data.
4
EEPROM= electrically erasable programmable read only memory. EEPROM is fabricated using a special semiconductor construction that allows it to retain
previously stored data even when the battery is disconnected. A similarly functioning technology, flash memory, is also used for this purpose. Flash memory is now
commonly used in portable data storage devices, the most common of which are digital camera removable memory cards.
5
Scanner= small hand held microprocessor capable of sending serial data commands to a vehicle ECU and then receiving and selectively recording/interpreting
ECU serial response data.
6
ALU= arithmetic logical unit; RAM= random access memory 共data not saved when power is removed兲; and ROM= read only memory 共data permanently frozen in
that memory, data not changed after initial write兲.
7
In some cases, that serial data port is not wired into the vehicle wiring harness and must be accessed via a special diagnostic connector.
1
Copyright © 2009 by ASTM International www.astm.org
MON05-EB/Sep. 2009
2
A Review of the Nomenclature, Mathematical
and Geometric Conventions Used in
Describing Crash Event Data
2.1 Geometric Conventions for Crash Event and lateral force inputs, and then evaluating the resultant
Pulses force effect with respect to the occupant secondary impact,
is found in U.S. Patent 6,424,898 关2.4兴. In that system, or-
SINCE CRASH EVENTS HAPPEN IN PHYSICAL SPACE, thogonal 共separate X axis and Y axis兲 accelerometer pulse
we must first define a standard set of coordinates and terms data are used in an algorithm to predict occupant impact ve-
of reference. locity with the vehicle interior and thus determine an
Vehicle position and velocity are described in terms of algorithm-based deployment metric.2
three global axes defined by three SAE standards: SAE In later examples we shall be examining the time to fire
J670e, Vehicle Dynamics Terminology 共SAE J670e, 1976-07兲 of various safety devices 共pretensioners, stage 1 air bags,
关2.1兴; SAE J1733, Sign Convention for Vehicle Crash Testing stage 2 airbags, etc.兲, and this geometric analysis should pro-
共SAE J1733, 1994-12兲关2.2兴; and SAE J211, Instrumentation vide some basis for the importance of those timing and
for Impact Test 共SAE J211-1, 1995-03兲关2.3兴. integrated-distance parameters.
The SAE source drawing defining these axis conven-
tions is shown in Fig. 2.1.1 and a geometric line drawing, as
applied to a passenger vehicle, is shown in Fig. 2.1.2. The 2.2 Deployment Metrics as Illustrated for
reader should note that these axes have a defined signing Frontal Air Bag Systems
convention 共i.e., there is a “⫹” and “⫺” direction兲, and one
has to carefully coordinate that signing convention when Frontal air bag systems are designed to respond to a frontal
formally discussing vehicle motion. impact measured as a crash pulse in the −X axis, as defined in
In addition to vehicle axes there are occupant axes. The SAE J1733 关2.2兴. Individual air bag accelerometer sensors
occupant head and torso axes are aligned with the vehicle are universally design axis sensitive, and frontal crash sen-
axes and are shown in Fig. 2.1.3. sors respond to force inputs which cause velocity changes
One key point in crash event analysis and occupant 共acceleration兲 along the −X axis 共also called the X design
safety protection is the relative translation of an occupant axis兲. An illustration of such a sensor is shown in Fig. 2.2.1.
共with inherent occupant axes兲 with respect to the fixed coor- Note also in Fig. 2.2.1 that the accelerometer output samples
dinates of the vehicle 共vehicle axes兲. In a crash event, the are operated on by the software processing algorithm in the
magnitude of that translation, and the time of that transla- MCU to achieve filtered, integrated, and accumulated values
tion, versus the deployment of safety devices can be key in which are continuously compared to predetermined re-
preventing occupant injury by hard contact with the vehicle sponse requirement thresholds. A good discussion of three
interior.1 An illustration of occupant translation 共occupant specific frontal algorithmic deployment metrics, based on
axes moving with respect to the vehicle axes after an impact vehicle acceleration, is found in U.S. Patent 5,483,449 关2.5兴.3
event兲 is shown in Fig. 2.1.4. A good discussion of an ap- Figure 2.2.2, from that reference, illustrates an algorithmic
proach in calculating the resultant effects of longitudinal approach to frontal deployment metrics.
1
The impact of the occupant with the vehicle, also called “secondary impact,” normally occurs after any vehicle impact. FMVSS 208 关2.8兴 defines certain require-
ments for occupant secondary impact protection.
2
U.S. Patent 6,424,898 关2.4兴 Abstract: A vehicle restraint control system provides sophisticated adaptable control of occupant restraints through the use of a
system level architecture to predict the nature of a crash event at the earliest possible time and an occupant injury model to tailor the restraint deployment in an
adaptable way to characteristics of the protected vehicle occupant共s兲 and the nature of the crash event. The occupant injury model derives the potential for injury
in a particular vehicle crash in real time as a function of occupant mass, vehicle interior stiffness, and occupant impact velocity with respect to the vehicle interior.
Peak vehicle crush zone velocity is used as a predictor of occupant impact velocity with the vehicle interior. Predicted occupant impact velocity is preferably
adjusted in response to the derived impact angle factor, which is derived from orthogonal lateral and longitudinal accelerometers in the vehicle occupant com-
partment. Vehicle longitudinal velocity may be integrated to predict occupant displacement, relative to the vehicle, as an additional factor used in the control
system.
3
The three metrics illustrated are “velocity boundary,” “energy boundary,” and “oscillation boundary.”
2
CHAPTER 2 䊏 A REVIEW OF THE NOMENCLATURE 3
Fig. 2.1.1—Vehicle direction and control axis system. 共Reprinted with permission from Fig. 3, SAE, J1733, © 2007, SAE International.兲
As stated in 2.1 above, just about every crash impact

2. Must-fire-at-or-above: 12 MPH BEV
event has a principal direction of force 共PDOF兲, which is not 共Deploy Threshold 1兲
exactly aligned with the orthogonal X, Y, or Z axis. In prac- 18 MPH BEV
tice, most PDOFs are treated as planar vectors having sub- 共Deploy Threshold 2兲
stantive components in the X and Y axes. The frontal 共longi- 3. Fire gray zone: 8+ to 12−
tudinal兲 vector component is derived from the PDOF MPH BEV
resultant crash pulse input. For frontal impacts, if the −X
axis vector component of a frontal PDOF crash pulse is deter-
mined to have sufficient magnitude over time, it will cause 2.3 Electronic Data in Air Bag ECUs
the restraint system MCU frontal algorithm to conclude that 2.3.1 Most air bag control ECUs use an EEPROM5 to save
a deployment metric 共criteria兲 was exceeded and thus issue a active and history DTCs and crash event records.6 EE-
deploy command for the appropriate safety actuators 共air PROM is nonvolatile memory, which means that it re-
bags, pretensioners, etc.兲. tains its data even when the battery is disconnected.
In most cases, air bag controller EDR suppliers create Dealer-level scanners are typically limited to DTC re-
an analysis matrix of air bag ECU algorithm response versus trieval while engineering level crash record data typi-
vehicle platform required performance. This is done for cally require a laptop computer and vehicle network
many test crash types and magnitudes, with acceleration interface.
data for those test crashes supplied by the vehicle manufac- EEPROM data are recorded as standard memory bi-
turer. It is a usual practice for the response threshold met- nary data 共bits containing “1” or “0”兲, but it is usually
rics, such as those described above, to be based on crash pa- listed in the hexadecimal7 numbering system. For vari-
rameters corresponding to measured manikin 共surrogate 5
EEPROM= electrically erasable programmable read only memory. EE-
occupant兲共secondary impact兲 injury parameters, as mea- PROM is fabricated using a special semiconductor construction that allows
sured in the actual test crashes. Thus, this matrix defines the it to retain previously stored data even when the battery is disconnected. A
de facto response thresholds of the subject air bag controller similarly functioning technology, flash memory, is also used for this pur-
pose. Flash memory is now commonly used in portable data storage devices,
共and the algorithm used within that device兲 in order for the the most common of which are digital camera removable memory cards.
vehicle manufacturer to meet the occupant safety criteria, as 6
DTC= diagnostic trouble code. DTCs can be current or historic and not cur-
measured in those test crashes. Typical contemporary, two- rently present 共i.e., memory DTCs兲. Crash event data are sometimes called
stage, and longitudinal deployment threshold metrics are data recorder, event data, etc.
7
Hexadecimal is a numbering scheme for representing 8 binary bits of
memory data 共1 byte兲. The hexadecimal scheme uses base 16 for each half of
1. Must-not-fire-at-or-below: 8 MPH BEV4 a byte 共4 bits兲. Each of the 16 values that are represented by the 4 binary bits
are represented by hex characters, e.g., 0–9, a–f hex represents 0–15 decimal.
The hexadecimal system is used because it is the most character-economical
4
BEV= barrier equivalent velocity. This is defined as the approach velocity of representation of such data 共e.g., full representation of 1 byte requires only
a test vehicle immediately before impact with a rigid nondeformable bar- two hex characters versus eight binary characters or three decimal charac-
rier. ters兲. Hexadecimal character formats are usually listed with a special prefix
4 BLACK BOX DATA FROM ACCIDENT VEHICLES 䊏
Fig. 2.1.2—Vehicle axis system with signed SAE J670e/J1733/J211

directions and labels.
ous versions of SRS controllers, as applied to different

model vehicles, the format and content of the EE-
PROM data change. Each version of EEPROM data
共typically identified by an electronic version ID兲 has a
specific format and interpretation scheme for the vari-
ous fields of data saved in that EEPROM version.
EEPROM can be physically resident in a separate Inte-
grated Circuit Package 共IC, chip兲, or it can be incorpo-
rated within the larger MCU package.
2.3.2 The ability to download and review the subject EDR
data in raw hexadecimal form often provides in-
Fig. 2.1.3—Axis conventions applied to anthropomorphic test
creased insight into the crash event process. With
dummy 共ATD兲 as used for crash testing. 共Reprinted with permis-
those data, certain subtle translations and interpreta- sion from Fig. 5, SAE, J1733, © 2007, SAE International.兲
tions or omissions, not noticeable in public data list-
ings, can be deduced, often to advantage.
Access to EDR data requires access either to certain by reviewing a specification of raw data translation to engi-
public serial data tools, to certain proprietary serial tools, or neering units. Below, as a first and tutorial example, we will
to the data as provided by the ECU designer/manufacturer. see the five specific steps in process to translate such raw
Alternatively, the data can be obtained by a direct data re- data, and an example of the derivation and proof of an em-
trieval from the nonvolatile memory device.
For serial data tools, the development of a custom net-
work interface and interrogation procedure to retrieve those
data is a long and arduous task. Examples of proprietary
tools to retrieve such data, and likely familiar to most investi-
gators, are the GM event data retrieval tool used with a
Vetronix Tech 1® 共EDRU兲 and the Ford/Visteon RCM data
interface/load box. Both of these devices were forensically
neutral8 and used in data downloads before the Bosch/
Vetronix CDR® came into common use.
Analysis of EDR data must be complimented by a
method to derive engineering units from those raw data or
to distinguish them from other alphameric characters. For example, the hex
value “A3” can be shown with either of two such common prefix examples, a
dollar sign 共$兲, such as $A3, or a “0x” such as 0xA3. In either usage, the hex
byte A3 is evaluated as 163 decimal. Some scientific calculators incorporate
a hexadecimal mode function that will convert numbers between the differ- Fig. 2.1.4—Superposition of vehicle axes and occupant axes, show-
ent representations 共binary, decimal, octal, and hexadecimal兲. ing occupant axis translation with respect to vehicle axes in re-
8
Both devices allowed umbilical interrogations and presented the proper sponse to an impact event pulse. Subportion of fig. 2.1.4. 共Re-
loads and interfaces to the subject SRS ECU, thus neither adding nor alter- printed with permission from Fig. 5, SAE, J1733, © 2007, SAE
ing data in the subject SRS ECU. International, see Fig. 2.1.3兲.
Fig. 2.2.1—Base vehicle axes showing sensor de-

sign axes, detecting accelerometer and thresh-
olds. See amplified deploy criteria in Fig. 2.2.2.
pirical SLOT9 factor that confirms that the empirical trans- vice. In many cases this can be approached by reviewing SAE
lation of acceleration values for successive sample time peri- and ISO guidelines and specifications for vehicle networks,
ods is correct. and then verifying which particular subspecification applies
for the ECU and data address range of interest.
2.4 The Steps to Achieve Engineering Units
One approach to determine the EEPROM address range
from Raw Data Inside an ECU/EDR and typical crash sensitivities for a particular ECU is to dis-
Retrieving the Crash-Related Data. For the serial data assemble it and study the key components on the printed cir-
network-access approach, the first problem to be solved is to cuit board 共PCB兲. Figure 2.4.0.1 shows a typical SRS ECU
develop the ability to communicate with the appropriate with the PCB disassembled from the case. Figure 2.4.0.2
ECU/EDR in order to read the data of interest inside that de- shows the MCU on that PCB to be a TI 共Texas Instruments®兲
MCU manufactured in 1999. Figure 2.4.0.3 shows the crash
9
“SLOT” information is defined by the Society of Automotive Engineers sensor on that PCB to be an AD 共Analog Devices®兲 acceler-
共SAE兲 Recommended Practice J2178-2 关2.6兴 to be Scaling, Limit, Offset and ometer. Those devices, respectively, have a specific EEPROM
Transfer Function specifications that allow hexadecimal encoded engineer-
address range and specific acceleration sensitivity.
ing data to be interpreted into engineering units such as psi, seconds, volts,
amps, Gs, etc. Additional network protocol clues can be derived from
Fig. 2.2.2—Illustration from U.S. Patent 5,483,449, showing an algorithmic process for determining if an air bag deployment threshold is
passed if a crash event magnitude exceeds combinations of various combinations of a velocity boundary, energy boundary, and oscillation
boundary—all versus time after the onset of a crash event.
Fig. 2.4.0.1—ECU/EDR printed circuit board 共PCB兲 as removed from Fig. 2.4.0.3—ECU/EDR accelerometer on PCB 共Analog Devices
its case. logo兲.
cerpt of actual data read with that method. This method,

when used correctly, does not alter the EEPROM IC data
contents. The advantage of this method is that the data are
retrieved in direct hexadecimal form. The disadvantage of
this method is that the ECU must be disassembled to gain
access to the EEPROM IC.
Considered globally, there are five steps involved in the
retrieval and translation of ECU/EDR event data. These five
steps are described as follows:
2.4.1 Interrogation of the Target ECU/EDR is the First
Step. This allows one to obtain the desired elec-
tronic information 关e.g., EEPROM/flash-memory
hexadecimal data兴. For the network serial data ac-
cess method, this information, a data stream, in-
variably encloses the desired data within interro-
gation commands and responses. This means that
the data stream appears as a succession of long
Fig. 2.4.0.2—ECU/EDR MCU on PCB 共Texas Instruments®兲. run-on sentences with no distinguishing punctua-
tion between data, commands, responses, or
checksums. So, since there is no visible difference
observing diagnostic 共DTC兲 scanner traffic with the ECU of
interest.10 Examples of a network interface monitor as used
to observe a standard diagnostic scanner network traffic ob-
servation are shown in Figs. 2.4.0.4, 2.4.0.5, 2.4.0.6, and
2.4.0.7.
Alternatively, for the direct retrieval of data from the
nonvolatile memory device, one must employ an in-circuit
EEPROM reader/programmer which allows one to retrieve
that data. Since there are many options of EEPROM parts
that can be used, and in many cases the EEPROM is in the
internal part of the MCU, the development of such an investi-
gation method is time consuming and tedious. Notwith-
standing that, it can produce results where serial data net-
work tools are blocked by advanced security methods.
Figure 2.4.0.8 shows an example of a discrete EEPROM IC.11
Fig. 2.4.0.9 shows an IC contact device, adjacent to and then
contacting an EEPROM IC, and Fig. 2.4.0.10 shows an ex-
10
This is also called network sniffing and several network tools are available
for this purpose.
11 Fig. 2.4.0.4—Observing network data traffic from aftermarket
IC= integrated circuit, usually describing a discrete packaged device sol-
dered to a printed circuit board 共PCB兲. scanner to and from the ECU/EDR of interest.
Fig. 2.4.0.5—Observing network data traffic from manufacturer/ Fig. 2.4.0.7—Data interrogation network interfaces 共CDR & AVT-
dealer scanner to and from the ECU/EDR of interest. 716 shown兲.
between the data and the commands, the com- of assembling the parsed data into a structured format
mands have to be trimmed from that data stream so that it can be easily read and interpreted. This often
by “parsing” that data stream so as to present the involves adding address identifiers and spaces be-
data only. Note also that the data stream does not tween data elements 共not found in the original data
include any spaces or line returns, so that the stream兲. Figure 2.4.3 shows how the excerpted data
parsing process is often line position dependent. placed into formatted rows, with 16 bytes per row ad-
Figure 2.4.1 shows an example of successive pairs dress. This means that every four rows of parsed data
of information requests followed by nonparsed in- bytes 共4 bytes兲 are concatenated to form a new row of
formation responses for an ECU of the type shown 16 bytes of formatted data.
in Fig. 2.4.0.1. 2.4.4 Translation is the fourth step. Translation is the pro-
2.4.2 Parsing is the second step. Parsing is the process of ex- cess of performing a numeric or logical evaluation of
tracting the desired electronic data from within the ac- the address-identified data elements. This evaluation
companying commands, responses, or checksums.
Figure 2.4.2 shows the data excerpted from the non-
parsed information responses in Fig. 2.4.1. Note that
the data are actually a succession of the last 4 bytes of
each response 共the second, fourth, sixth, eighth, etc.,
lines in Fig. 2.4.1, see underlined data兲.
Direct EEPROM reading methods avoid most of the
need for parsing.
2.4.3 Formatting the third step. Formatting is the process
Fig. 2.4.0.6—Benchtop interrogation of ECU data. Fig. 2.4.0.8—Discrete EEPROM IC from an SRS ECU PCB.
Fig. 2.4.0.9—IC direct contact device adjacent to, and then on, the discrete EEPROM IC.
can produce numeric parameters with appropriate en-

gineering units, or the translation can produce logical
and/or condition information based on the binary
共true/false兲 value of bits within data bytes. The key to
data element translation is the knowledge or the em-
pirical derivation of an appropriate SLOT factor for
the data byte of interest. Examples of data translations
can include acceleration, timing, seatbelt usage, in-
stantaneous velocity change, cumulative velocity
change, etc. Figure 2.4.4 shows the translation for a
portion of the translated data 共signed A/D count devia-
tion from a null or quiescent value兲 translated into ±g’s
using an appropriate SLOT factor 共in this case,
Fig. 2.4.0.10—Excerpt of actual EEPROM data read using the di-

rect IC contact device.
Fig. 2.4.1—Raw nonparsed interrogation data stream excerpt, in- Fig. 2.4.2—Parsed data excerpt, after stripping inline request/
cluding request/response pairs. response commands.
Fig. 2.4.3—Formatted data excerpt based on parsed data excerpt in Fig. 2.4.2.
0.5g / count兲. Note that, in addition to the g’s transla-

tion, the data position 共sample number兲 also repre-
sents the time, in milliseconds 共ms兲, after algorithm
wake-up during the crash pulse.
2.4.5 Interpretation of the translated data is the fifth step.
Data interpretation involves evaluation of the reported
and translated data with respect to their consistency
with physical and complementary-investigator find-
ings and conclusions 共e.g., reconstruction, biome-
chanics, human factors, etc.兲. In this case, the g values
in time are integrated 共interpreted兲 to form a cumula-
tive 共signed兲 velocity loss. This process is shown in Fig.
2.4.5.
The processes to create Fig. 2.4.4 共translation兲 and Fig.
2.4.5 共interpretation兲, for the specific data excerpts shown in
Fig. 2.4.3, are explored in detail in Chapter 3.2.
The figures above are derived from NHTSA EA03-010
关2.7兴.
2.5 Deriving a Scaling and Transfer

Relationship from the Data
As discussed above, the methodological standard for inter-
preting ECU data hexadecimal values is given as an SAE
SLOT factor. With that factor, any parameter or logical con-
dition set saved at that address can be readily interpreted
and used for engineering analysis. In general, while the ge-
neric SLOT format is available as a public record, the infor-
mation specific to any SLOT definitions in any particular
ECU/EDR device is rarely public data. So, one can attempt to
obtain these by a bit of reverse engineering. An example of
inductive reverse engineering is shown in Chapter 3.2 and an
example of deductive reverse engineering is shown in Chap-
ter 3.3.
Fig. 2.4.4—Translated data excerpt, longitudinal acceleration

based on full formatted data excerpt of Fig. 2.4.3. From NHTSA
EA03-010, Appendix E, Book 2, page 1106.
Fig. 2.4.5—Interpreted data excerpt, longitudinal cumulative velocity change 共Delta V兲 based on full translated data 共excerpt shown in Fig.
2.4.4兲. From NHTSA EA03-010, Appendix E, Book 2, page 1104.
of Controlling Deployment Thereof, Caruso, Christopher M.;

References Nunan, Douglas A.; Gray, Charles A.; 1996, United States
共http://www.freepatentsonline.com/5483449.html兲.
关2.1兴 SAE J670e, Vehicle Dynamics Terminology, Surface Vehicle
Recommended Practice, SAE International, 400 Common- 关2.6兴 SAE J2178-2 1999-03, Class B Data Communication Network
wealth Drive, Warrendale, PA 15096-0001. Messages—Part 2: Data Parameter Definitions, SAE Interna-
关2.2兴 SAE J1733, Sign Convention for Vehicle Crash Testing, Surface tional, 400 Commonwealth Drive, Warrendale, PA 15096-
Vehicle Recommended Practice, SAE International, 400 0001.
Commonwealth Drive, Warrendale, PA 15096-0001. 关2.7兴 NHTSA EA03-010, Alleged Failure of a Frontal Air Bag to De-
关2.3兴 SAE J211, Instrumentation for Impact Test, Surface Vehicle ploy in Frontal or Near-Frontal Crash; 2000 and 2001 model
Recommended Practice, SAE International, 400 Common- year Ford Taurus and Mercury Sable vehicles.
wealth Drive, Warrendale, PA 15096-0001. 关2.8兴 FMVSS 208 Title 49—Transportation, Chapter V National
关2.4兴 U.S. Patent 6,424,898, Vehicle Occupant Restraint Control
Highway Traffic Safety Administration, Department of Trans-
System Using a Crash Severity Model, Anishetty, Santosh,//
portation, Part 571—Federal Motor Vehicle Safety Stand-
Caruso, Christopher Michael// Little, David R.// Simp-
ards—Sec. 571.208, Standard No. 208; Occupant crash pro-
son, Russell L., 2002, United States 共http://www.
tection. S1. Scope. This standard specifies performance re-
freepatentsonline.com/6424898.html兲.
关2.5兴 U.S. Patent 5,483,449, Inflatable Restraint System and Method quirements for the protection of vehicle occupants in crashes.
MON05-EB/Sep. 2009
3
Examples and Exercises in Data Translation
ONE OF THE MOST EFFECTIVE METHODS OF TEA- functional explanations can be used as a guide for custom
ching is to present the student with a problem and then guide interpreters programmed in PHP, Python, etc.
him or her through a solution. Chapter 3 contains subchap- The primary spreadsheet product employed here in our
ters with problem examples chosen to illustrate a diversity of problem solutions is Corel Quattro Pro®. However, because
tools and techniques useful in interpreting nonvolatile many readers utilize Microsoft EXCEL® at the end of each
memory data. The solutions are presented in the form of chapter, a table of explicit functions is presented as parallel
spreadsheet, with step by step functional explanations.
columns with solution functions in both products for each
Using this technique, each of the subchapter example
key cell of the spreadsheet solution calculation. When math-
spreadsheets can then be used as a solution template for new
problems having similar functional structures. An addi- ematical formulas are shown in the text, they will be identi-
tional benefit of spreadsheet solution examples is that the fied as QP: formula or EX: formula so that the reader can im-
reader can utilize subfunctions of the presented spreadsheet mediately identify them.
solutions by cutting and pasting those subfunction cells into Lastly, the reader should note that, while Chapter 3 con-
new spreadsheets to form solutions for yet-unsolved data tains a representative set of EDR data analyses, it cannot
translation/interpretation problems. Lastly, the step by step possibly cover every conceivable analysis situation.
11
3.1 Example 1: Creating a Linear Data List 3.1.2.1 The first step is to import the S19 file as an ASCII
from Hex Data Blocks record set with one record 共sentence兲 per cell in
3.1.1 OFTEN, THE ECU/EDR INVESTIGATOR IS PRE- the spreadsheet. That record is then treated as an
sented hexadecimal data in the form of long run-on ASCII string. Successive records in the S19 record
sentences 共records兲 of hexadecimal data with no are imported to successive continuing 共lower兲
spaces or punctuation. One form of such data is called cells in the spreadsheet.
“S19” format data. An S19 data example is shown in 3.1.2.2 The next step, operating on each imported record
Fig. 3.1.1.1. The S19 format is derived from a Motorola 共sentence兲, is to select substrings in the record
representation of EEPROM data and it has an order string and copy those substrings to a desired for-
and format. It is defined in many places, including Fig. mat table matrix. Selecting the substring takes
5 of Application note AN1010/D 关3.1兴, shown here as the form QP: @MID共$A10,8,2兲.2 Thus, to properly
Fig. 3.1.1.2. For those readers wishing an introduction select the hex data value in address $0800 共corre-
to hexadecimal arithmetic, a brief tutorial is presented sponding to spreadsheet cell C10兲 we are taking
in Appendix A. the eighth and ninth characters in the string
Referring to Fig. 3.1.1.2: “S1130800AA42405
3.1.1.1 Each S19 file is a series of successive records 共sen- F14A2…” We use QP: @MID共$A10,8,2兲.3 Simi-
tences兲 in block data format. Block data format
larly, to properly select the hex data value in ad-
means that, in each record, the binary memory
dress $0801 共corresponding to spreadsheet cell
contents are represented as hexadecimal coded
D10兲 we are taking the tenth and eleventh charac-
binary data with no spacing or other punctuation
ter in the string “S1130800AA42405F14A2…” We
until the end of that record. Within each record, at
a fixed hexadecimal character position, there are use QP: @MID共$A10,10,2兲. A full 512-byte ex-
indicators of record type identifier, data byte ample showing how the S19 data of Fig. 3.1.1.1 is
quantity, the data starting address, the actual mapped into a more-usual block formatted hexa-
data, checksum, and a carriage return/linefeed decimal data table using substring selection is
共bytes $0D $0A兲. Note that when viewing an S19 shown in Fig. 3.1.2.2.
file with a text editor, the carriage return/linefeed 3.1.3 Now that we have our more familiar block formatted
bytes 共$0D, $0A兲 are treated as codes and are not hexadecimal data matrix, we can very readily refer to
usually displayed. individual data at specific addresses with relative ease.
3.1.1.2 Records always begin with a record type identi- However, operating on even a formatted block data to
fier. There are three options. “S0 ” = header perform data byte translations is still awkward and te-
record, “S1 ” = data record, and “S9 ” = last record dious. It is much more advantageous to create a linear
in the file. data list. We can accomplish this using a technique
3.1.1.3 Following the record type identifier is a 1-byte similar to that used in Sec. 3.1.2.2: however the pro-
quantity flag representing the number of bytes in cess of creating that data map is a bit more tedious.
the record 共including the starting address, data
3.1.3.1 The first step in that process is to copy the format-
bytes, and the checksum, but not including the
ted table to a fresh notebook page, and we will
quantity flag or the CR/LF bytes兲
name that page “HexTable.” If we just try to mark
3.1.1.4 Following the quantity flag is a pair of bytes repre-
the formatted hex table block in Fig. 3.1.1.2, we
senting the 16-bit starting address of the data in
EEPROM as an absolute address. will find that we are actually copying the sub-
3.1.1.5 Following the address byte pair are the hexadeci- string formulas: when we try to paste them on a
mal representations of the data to be stored. new notebook page, in a new file, we will have a
set of invalid cell references, and not the actual
3.1.1.6 Following the data is a checksum byte. This byte hex table values. This is solved by marking the col-
is the least significant byte 共LSB兲1 of the hexadeci- umns in the hex table and performing a “convert
mal sum of the length byte, two address bytes, to values” operation on that data. That freezes the
and the data bytes. parsed substring values at their indicated value,
3.1.2 Since using the concatenated S19 record is difficult, it but also eliminates the substring formulas. So, we
is usual to format those data. Fortunately, formatting do this “convert to values” operation on a copy of
an S19 data file is easy with a spreadsheet solution. the S19 translator spread sheet to preserve the
1
The least significant byte 共LSB兲 ignores the probable carry byte in the sum.
2
@MID extracts the first Num characters of string starting at StartNumber, which is the number of characters to the right of the first character 共character 0兲.
3
Starting with character count 0.
CHAPTER 3 䊏 EXAMPLES AND EXERCISES IN DATA TRANSLATION 13
Fig. 3.1.1.2—Figure 5 of motorola/freescale application note

AN1010/D. Copyright of Freescale Semiconductor, Inc, 2008, Used
by Permission. Note that the checksum algorithm specifies the in-
version of the LSB of the sum of the complete line. Thus when any
complete line is added, the LSB of the sum 共including checksum兲
should be $00.
hexadecimal address values in column B. If we in-

crement the column A decimal source as we pro-
ceed down 共using standard spreadsheet mono-
tonic incrementing functions to create the
successive decimal values兲, and just replicate the
hex conversion formula as we proceed down the
Fig. 3.1.1.1—Example of ECU/EDR data shown in “S19” format,
column, we can create our linear address list in a
including header and terminator records.
reasonably painless fashion.
As an example, starting with the address list, on
original as a template for our next assignment.4 the EEPROM page, fill column A with the desired
3.1.3.2 We can now copy our formatted 共converted to val- decimal address sequence. In this case, we start
ues兲 hex table data and paste these data onto a with a decimal value of 2,048 in cell A10. Placing
new notebook page in preparation for our next as- operatorQP:@NUMTOHEX64共A10,4兲 in cell B10,
signment, creating a linear EEPROM list. we get the hex ASCII representation, “0800.”
3.1.3.3 Referring to the fresh HexTable notebook page of Similarly, placing a decimal value of 2,049 in cell
Fig. 3.1.3.3, 共as derived from the formatted hexa- A11 and operator QP:@NUMTOHEX64共A11,4兲 in
decimal data block of Fig. 3.1.2.2兲, we can create a cell B11, we get “0801.” We can continue manu-
EEPROM linear list by mapping each element of ally in this manner or autofill column A for the full
block formatted data to a new line in a second address range of interest. A partial example of this
notebook page by selecting it using a similar but process is shown in Fig. 3.1.3.4.
interpage substring operator for each block in a 3.1.3.5 Next, to create our linear EEPROM list from the
new line. For example, assuming that we have our fresh HexTable, Fig. 3.1.3.3, we note that the first
block formatted data on a notebook page entitled address in the EEPROM list would be the value in
“HexTable” and that we wish to create the linear hex address 0800, and that is the contents of cell
list on a notebook page called “EEPROM,” we can “HexTable:B10.” This means that we want to map
proceed as follows: cell “HexTable:B10” to the data cell in the linear
3.1.3.4 On the EEPROM page, create column B with the list corresponding to hex address $0800. This
EEPROM linear addresses, starting at cell B10. means the value in cell “EEPROM:C10” must re-
Note that where the addresses are monotonic and fer to the value in cell “HexTable:B10.” This is ac-
hexadecimal, as here, we can create these from complished by putting that cell operator refer-
easily inserted decimal source data. For example, ence “QP:⫹HexTable:B10” in cell EEPROM:C10.
by starting with the decimal source value in col- Similarly, for the linear list value corresponding
umn A, we then convert those decimal values to to hex address $0801 共cell EEPROM:C11兲, we
must refer to the value in cell “HexTable:C10.”
4
In EXCEL®, this is accomplished using the “paste special values” function. This is accomplished by putting that cell operator
Fig. 3.1.2.2—Formatting S19 data from a concatenated data file 共showing data only兲.
reference QP:⫹HexTable:C10 in cell ample, taking our address $0801 hex value “42” in
EEPROM:C11. cell C11;
A section of this completed process is shown in 3.1.3.7.1 The binary coded Decimal value represented is
Fig. 3.1.3.5, where fresh HexTable values are seen 42 共i.e., each nibble standing alone as a binary
mapped to the linear list “Hex Data” column. digit兲. In this case, the whole-byte decimal
3.1.3.6 Because we do not know yet whether the map- evaluation does not apply.
ped value in the EEPROM linear list will be used 3.1.3.7.2 The ASCII character represented by $42 is “B.”
as a numeric quantity,5 a bitmap,6 a split bit- Such representations are useful in recording
map/numeric quantity, etc., it is a good policy to VINs, part numbers, or serial numbers. In this
perform a numeric translation of the mapped case, neither the nibble value nor the whole-
value in the EEPROM linear list in preparation byte decimal evaluation applies.
for our SLOT factor units translation. For ex- 3.1.4 Complex Numeric Translations
ample, taking our address $0800 hex value “AA” We have seen above how to translate single cell 共single
in cell C10; byte兲 contents with a numeric translation. However,
3.1.3.6.1 Decimal column entry D10 is QP: @ sometimes the engineering quantities we need to rep-
HEXTONUM共C10兲 = 170. This can be the basis resent exceed the maximum numeric integer value of a
of a numeric engineering unit translation. single byte 共$FF= 255 dec兲. In that case we can use
3.1.3.6.2 Binary column entry E10 is QP: @HEXTOBIN multiple bytes. For example, the maximum numeric
64共C10, 8兲 = 10101010. This can be the basis of a value of a 2-byte quantity is 共$FF FF= 65,535 dec兲. Fig.
bitmap engineering unit translation. 3.1.4, taken from a different EEPROM example, shows
3.1.3.7 Other data forms are equally valid and go beyond two examples of such a 2-byte translation, the first for
the above numeric translation. For another ex- a hex quantity of $ FF FF and a second for a hex quan-
5 tity of $ 08 A2. In each case, the first step is a concat-
Example numeric quantity= $B2 hex= 178 decimal
6
Example bitmap= $B2 hex= 10110010 binary, where each bit position rep-
enation of two prior cell quantities 共C32, C33兲 into a
resents a true or false value for some system parameter 共e.g., seatbelt buck- new combined cell 共F33兲, and that is performed by the
led, seat unoccupied, seat forward, etc.兲. following operator QP:@CATNH共2,C32,C33兲 in cell
Fig. 3.1.3.3—Fresh HexTable taken from the parsed S-19 file 共“HexTable” notebook page兲.
F33. Next we perform a standard numeric translation 3.1.5 We have now briefly traversed four data retrieval pro-
of the value in cell F33 共$FFFF兲 to determine the deci- cess steps:
mal value in cell G33. That is accomplished by the cell 1. Interrogation
G33 operator QP:@HEXTONUM共F33兲, which yields 2. Parsing
our numeric value of 65,535 dec. Similarly, we can 3. Format
evaluate the concatenation of prior cell quantities 4. Translation options
共C35, C36兲 into a new combined cell 共F36兲, with the op- 3.1.6 Operator Equivalence: Quattro Pro® vs Excel® Rec-
erator QP:@ ognizing that many readers use Excel®, the following
CATNH共2,C35,C36兲 in cell F36. Next we perform a is a table of Excel® operator equivalences for the
standard numeric translation of the value in cell F36 Quattro Pro® operators referenced in this section.
共$08A2兲 to determine the decimal value
in cell G36 with the cell G36 operator QP:@
HEXTONUM共F36兲, yielding a numeric value of
2,210 dec.
Multibyte numeric translation is just one translation
possibility. Later examples will show mixed-mode
translations of partial byte data and SLOT factors as
applied to numeric data translations.
Fig. 3.1.3.5—Fresh HexTable values mapped to hex linear data list.
can count our ten fingers. The decimal system is said to be a

“base 10” system because it is based on counting ten digits
共fingers兲. In that system, there are ten counting units, actu-
ally identified as 0–9, after which there is a carry to the next
higher position 共the tens position兲. Thus, the decimal num-
ber ten 共10兲 is actually a carry of a 1 in the 10s column and no
additional unit counts. We will refer to the decimal system as
“the conventional system.”
The hexadecimal numbering convention 共base 16兲 is
universally used as a shorthand way to represent binary
computer data because that is the most efficient way to rep-
Fig. 3.1.3.4—EEPROM address fill using number to hex conversion. resent binary computer output with no intermediate transla-
tions. If the computer output is intended to be numeric, the
Figure Cell
8-bit byte could take on 256 different patterns and, there-
Reference Reference Quattro Pro® Excel® fore, could stand for 256 different numbers 共0–255 decimal兲.
3.1.3.4 B10 @NUMTOHEX64共A10,4兲 ⫽DEC2HEX共A10,4兲 The hexadecimal shorthand takes each 8-bit byte 4 bits
3.1.3.4 B11 @NUMTOHEX64共A11,4兲 ⫽DEC2HEX共A11,4兲 at a time. Each half-byte, having 4 bits, can have 16 different
3.1.3.5 D10 @HEXTONUM共C10兲 ⫽HEX2DEC共C10兲 number states 共0–15 decimal兲. There is a defined convention
3.1.3.5 E10 @HEXTOBIN64共C10,8兲 ⫽HEX2BIN共C10,8兲 for assigning each number state a unique character. That
3.1.4 F33 @CATNH共2,C32,C33兲 ⫽CONCATENATE convention is to assign the characters 0–9, respectively, to
共C32,C33兲 the lowest ten hexadecimal states in numerical order and to
3.1.4 G33 @HEXTONUM共F33兲 ⫽HEX2DEC共F33兲
assign the characters A–F to the remaining six hexadecimal
states. Thus, for each hexadecimal digit, the 4-bit nibble cor-
Appendix A: An Introduction to Hexadecimal relation from hexadecimal representation to decimal num-
Arithmetic ber states is as follows: hex 0 – 9 = decimal 0–9, A 共hex兲 = 10
共decimal兲, B = 11, C = 12, D = 13, E = 14, and F = 15. Hexadeci-
共Used with permission from “Investigation and Inter- mal numbers are typically represented with the dollar sign
pretation of Black Box Data in Automobiles, Section 2.6.2, prefix, e.g., $21 共=33 decimal兲, to distinguish that number
© ASTM International, West Conshohocken, PA, 2001兲. from 23 decimal.
Typically, we first learn the decimal system because we To illustrate how the three different base systems relate
Fig. 3.1.4—2-byte hex quantity translations.
TABLE A.1—Comparison of equivalent hexadecimal, binary, and decimal numbers.

Hexadecimal Binary Decimal Hexadecimal Binary Decimal
00 0000 0000 00 17 0001 0111 23
01 0000 0001 01 18 0001 1000 24
02 0000 0010 02 19 0001 1001 25
03 0000 0011 03 1A 0001 1010 26
04 0000 0100 04 1B 0001 1011 27
05 0000 0101 05 1C 0001 1100 28
06 0000 0110 06 1D 0001 1101 29
07 0000 0111 07 1E 0001 1110 30
08 0000 1000 08 1F 0001 1111 31
09 0000 1001 09 20 0010 0000 32
0A 0000 1010 10 21 0010 0001 33
0B 0000 1011 11 22 0010 0010 34
0C 0000 1100 12 23 0010 0011 35
0D 0000 1101 13 24 0010 0100 36
0E 0000 1110 14 25 0010 0101 37
0F 0000 1111 15 26 0010 0110 38
10 0001 0000 16 27 0010 0111 39
11 0001 0001 17 28 0010 1000 40
12 0001 0010 18 29 0010 1001 41
13 0001 0011 19 2A 0010 1010 42
14 0001 0100 20 2B 0010 1011 43
15 0001 0101 21 2C 0010 1100 44
16 0001 0110 22 2D 0010 1101 45
to one another, Table A.1 shows that the first 46 共0–45兲 nu- nary system, the 10th count in the conventional system, and
meric values are side by side expressed as hexadecimal, bi- the 16th count in the hex system.
nary, and decimal numbers, respectively. From this compari-
son, we can see that all the numbering schemes start with 0, References
just as in the conventional system, and a base count, i.e., a
关3.1兴 AN1010/D, Motorola Semiconductor Application Note,
count equal to the number system’s base, forces a carry over
to the next position to the left: at the second count in the bi- MCHC6811 Programming From a Personal Computer, 1993.
3.2 Inductively Deriving a SLOT1 Factor from documentation is shown in Fig. 3.2.1. Once the key compo-
Component Specifications, Translating nents are identified, their individual operating specifications
Acceleration Data, and Interpreting that and characteristics can be accessed 共often online兲. Then,
Data into Cumulative Velocity Loss these specifications and characteristics can be combined to
„Delta V… inductively generate the SLOT factors that apply to the ECU
of interest. Using such specifications, a tutorial example of
3.2.1 Using an Inductive Engineering this process is shown below:
Method to Document and Confirm an ECU/ 3.2.1.1 Assume that we have identified a microcontroller
EDR SLOT Factor 共MCU兲 which uses an 8-bit A/D converter with a
+ 5.0000 V reference 共+Vref兲. We also assume that the
THE PREMISE OF INDUCTIVE REASONING IS DE- A/D counts are represented in MCU memory as a
fined in Wikipedia 关3.2.1兴, Stanford 关3.2.2兴, and Mercier 1-byte count 共8 bits兲, which is a linear representa-
关3.2.3兴 to consist of the process formulating laws 共or relation- tion of the sampled voltage 共VADIN兲 from 0 V to +Vref.
ships兲 based on limited observations of recurring patterns A 1-byte count has a lowest value 共$00兲 of 0 dec and a
for the phenomena of interest. In our case this applies to the maximum count of 共$FF兲 of 255 dec. We are further
derivation of appropriate scaling and translation factors to assuming that the A/D converter is linear, so that a
derive engineering units from saved 共nonvolatile兲 memory in detected value of VADIN will be a ratiometric value of
any particular crash event data recorder. counts 共0 / 255兲 proportional to the relationship of
An inductive process starts with an observed effect 共pro- VADIN / Vref.
cess outcome兲 and then ascends to the cause of that observed 3.2.1.2 Assume that we have identified a ±50g accelerom-
effect 共method of predicting the process outcome or solution兲 eter, having a voltage output, VACCL, which has an
and then ascends to the properties and nature of the method output sensitivity of 25g / V, or 1g / 0.0400 V or
to establish a law of solution 共repeatable method兲 that pro- 0.0400 V / 1g. Vaccl directly feeds the MCU A/D port
duces repeatable and valid results. Mercier 关3.2.3兴 further input, VADIN.4
defines four stages of the inductive process as follows: We also assume that the accelerometer uses a
共1兲 The observation of certain facts or effects 共process + 5.0000 VDD source and has a nominal quiescent
outcomes兲 which are presented to the senses. output value of 2.5000 V 共Vquiescent兲. That means that
共2兲 The hypothesis that the problem solution must be pro- a 0g value would be represented by an output voltage
duced by definite methodology 共and not by constantly of 2.5000 V, with +g values indicated by a value
recurring fortuitous coincidences兲. higher than 2.5000 V, and −g values indicated by a
A scientific hypothesis is the provisional explanation of value lower than 2.5000 V.5
certain observed facts. Using the stated 0.0400 V / 1g sensitivity, we can then
共3兲 A verification of the hypothesis, in a decisive manner, determine that our working ±50g analog input range
by repeated experiment. would be represented by a working voltage output
共4兲 A deduction, based on the repeated and independent range of ±2.0000 V about the quiescent value of
experimental validation, that the process outcome de- +2.5000 V 共50g ⫻ 0.0400 V / g = 2.000 V兲.
fined by the above stated hypothesis 共solution methodol- This form of accelerometer specification is common
ogy兲 is reliable and trustworthy. in the industry. A representative accelerometer
Thus for the problem of deriving appropriate scaling specification 共Motorola兲 is shown in Fig. 3.2.1.2.
and translation factors for engineering units in crash record 3.2.1.3 We can now determine the count value sensitivity of
data representations in EDR ECU EEPROM data, we have to each digital A/D count in the MCU as follows: the ac-
be able to observe repeated samples of those data and then celerometer output Vaccl directly feeds the MCU A/D
apply the logical inductive process to the problem and port input, VADIN. Thus, we can determine that, us-
method of determining the engineering parameters we may ing the 5.0000 V reference, each 8-bit A/D count cor-
be observing.2 responds to 5.0000/ 255 V / count, or 0.0196 V /
The first step in this determination is, for any particular count.6 Also, as we noted above, the A/D converter is
ECU, to observe and understand just what components were a linear ratiometric device, meaning that all counts
used in its design and fabrication. The most direct way to do have equal voltage weight 共hence equal acceleration
this is to open the ECU cover and photographically docu- weight兲 throughout the 255 count range.
ment its component structure, specifically, its accelerometer 3.2.1.4 Using those two detection/sensitivity specifications,
and its microcontroller.3 An example of such a photographic we can now calculate the subject MCU acceleration
1
“SLOT” information is defined by the Society of Automotive Engineers 共SAE兲 Recommended Practice J2178-2 关2.6兴 to be the scaling, limit, offset, and transfer
function specifications that allow the hexadecimal encoded engineering data to be interpreted into engineering units such as psi, seconds, volts, amps, gs, etc.
2
EDR= event data recorder ECU= electronic control unit EEPROM= electrically erasable programmable read only memory 共nonvolatile memory兲.
3
A microcontroller is a microprocessor which contains several otherwise peripheral functions within its single package. These can include RAM, ROM, EEPROM,
A/D converter, serial data controller, etc.
4
It may seem strange to use a four place precision for an even 共exact兲 quantity of two places: however this is done to allow a consistent four place precision in later
calculations where the results are not even or exact. This convention is followed for the balance of this section.
5
Stated in terms of A/D counts, 2.5000 V would be 127 or 128 counts, depending on the technique used for A/D converter detection resolution.
6
The unrounded result= 0.019 607 843. For uniformity and consistency, this is rounded to 0.0196 in the balance of this section. Note that for an 8-bit byte, there are
256 count notations, starting at 0 and ending at 255. Using 0 as a null value, there are 255 actual count values.
3.2.2 Evaluating Algebraic Acceleration

Using Count Values
In an ECU/EDR such as in our example, where the sample
period is 1 ms 共1 / 1,000 s = 0.0010 s = ms兲 and the zero accel-
eration value is a midrange voltage 共2.5 V nominal兲, the pe-
riod acceleration values have to be determined using signed
arithmetic, where the algebraic acceleration counts 共⫾兲 are
determined by the count value of Vaccl − Vquiescent. So, for ex-
ample, if the zero acceleration value is 2.5000 V 共Vquiescent兲,
that would be represented by a midrange count of $80 共128
dec兲. If our instantaneous accelerometer output value was
2.1760 V 共Vaccl兲, the A/D count would be $6F 共111 dec兲, and
the instantaneous acceleration would have a count value of
− $ 11 共−17 dec兲. We know from the above calculation that
each count has a weight 共SLOT factor兲 of 0.4900g / count. So,
the instantaneous acceleration 共ai兲 is −17 counts⫻ 0.4900g /
count= −8.3300g.7
3.2.3 Using Derived Engineering Units to
Calculate Cumulative Velocity Change
„Delta V…
3.2.3.1 We note from examples of the data that the A/D
counts reported in EDR data are reported at a fixed
1-ms periodic rate.
3.2.3.2 For each sample period, the average acceleration, as
sampled, will indicate the velocity change for that
period, Vp, such that Vp = ap ⫻ tp.
Distance
The units of Vp are
Time
共commonly expressed as m/s, ft/s, mi/h, etc.兲
Note that the units have to be consistent in either the
English or Metric system. As an example, if we repre-
sent the period acceleration in units of g 共the accel-
eration of gravity, 1g = 9.8067 m / s2兲, and the time du-
ration of the sample period is 1 ms 共1 ms= 1 / 1000 s兲,
then, from the above SLOT derived single period ac-
celeration value of −8.3300g, the velocity change for
that sample period Vp can be calculated as
Vp = ap ⫻ tp
Vp = − 8.3300g共0.001 s兲
9.8067 m 1s
Fig. 3.2.1—共a兲 ECU/EDR printed circuit board 共PCB兲 as removed = − 8.3300g ⫻ ⫻
from its case. 共b兲 ECU/EDR MCU on PCB 共Texas Instruments logo兲. s2 g 1000
共c兲 ECU/EDR accelerometer on PCB 共Analog Devices兲.
− 81.6898 m
Vp =
data byte acceleration sensitivity 共SLOT factor兲 as 1000 s
follows:
− 81.6898 m
0.0196 V 1g Vp = = − 0.08168 m/s
Each A/D count = ⫻ 1000 s
A/D count 0.0400 V
3.2.3.3 We also know that any real crash pulse will span
0.4900g multiple periods and that the successive period Vp
=
A/D count increments accumulate to comprise the delta V in a
Stanford 关3.2.2兴 further codifies the confidence of the crash pulse. Mathematically, the individual sample
hypothesis with a criterion of adequacy 共CoA兲, which indi- period velocity changes accumulate 共add algebra-
cates that after sufficient repeated tests 共experimental valida- 7
In many cases, acceleration values are evaluated at higher rates than once
tions兲, tests should clearly indicate which hypotheses 共meth- per time period, and their period values 共ap兲 represent the average of the 共ai兲
odologies兲 are true and which are false. values in a particular time period.
Fig. 3.2.1.2—Motorola 共freescale兲 accelerometer specification excerpt, MMA2202D: X axis sensitivity, micromachined accelerometer, 50g,
MMA2202D.pdf. Copyright of Freescale Semiconductor, Inc., 2008, Used by Permission.
ically兲 to form a cumulative 共multisample period兲 ve- through the following mathematical process.8
locity change. A 共multisample period兲 cumulative ve- −17 acceleration counts, using our derived SLOT factor
locity change is commonly known as “Delta V, 共DV兲,” of 0.4900g / count, evaluate to a period value of −8.3300g,
which is a common reconstruction representation of constant for each of 43 periods.
the velocity change during a crash event.
p=43
3.2.3.4 The cumulative change in velocity over multiple pe-
riods, Delta V 共DV兲, can be stated as a mathematical
DV = 兺a
p=1
p ⫻ tp = a1 ⫻ t1 + a2 ⫻ t2 + a3 ⫻ t3 ¯ a43 ⫻ t43
summation
Since we have the unique situation of 43 identical samples,
we can evaluate the series summation in a somewhat abbre-
End viated fashion as
DV = 兺a
Start
p ⫻ tp = a1 ⫻ t1 + a2 ⫻ t2 + a3 ⫻ t3 ¯ aend
DV = 共43兲共− 8.3300g ms兲
⫻ tend
3.2.3.5 Using the engineering values derived above, if we DV = − 358.19g ms

now evaluate the cumulative velocity change 共DV兲 8
Note that in this case, a −g sign implies, per SAE axis conventions, a retard-
for a fixed 共constant兲 acceleration count value of −17 ing force to the vehicle, such as would accrue in a frontal impact situation.
counts over 43 1-ms sample periods, we would go Refer to Figs. 2.1.1 and 2.1.2.
Fig. 3.2.5.3—Data acquisition summary of the ±50g accelerometer

Fig. 3.2.5.1—Tuned-pendulum fixture used to impinge a cali- values versus time 共the impinged acceleration pulse兲. The acceler-
brated acceleration pulse on an EDR mounted on a trolley. The ometer is internally filtered at about 1 kHz, and the data samples
trolley carries the EDR and is impacted by the tuned pendulum. are recorded at 5,000 sample words/s to avoid aliasing. Note that
After impact acceleration, the trolley travels down the runout the data are captured starting at 20 ms before the trigger point
track seen to the right of impact point. 共0 ms, −2.0g兲
− 3.5127 m 3600 s − 12,645.72 m 1 km

9.8067 m ms 1s DV = ⫻ = ⫻
DV = − 358.19 ⫻ ⫻ ⫻ s h h 1,000 m
s2 1 1,000 ms
− 12.6457 km
− 3,512.6618 m =
= h
1,000 s
Converting to SAE 共English兲 units
− 12.6457 km 1 mile − 7.8579 miles

DV = ⫻ =
DV = − 3.5127 m/s h 1.6093 km h
Note that we have maintained a rigorous consistency in
units in the above analysis.
Translating that DV into common units
3.2.4 Other Forms of Acceleration Reporting
Some EDRs report their crash-related velocity change data
in units of direct acceleration per time period 共a共t兲兲 or aver-
aged acceleration per time period 具a共t兲典 and others report
Fig. 3.2.5.2—±50g accelerometer mounted on the trolley. The ac-

celerometer records the instantaneous acceleration experienced
by the trolley 共and mounted EDR兲 in response to the tuned-
pendulum impact, thus causing the shaped impinged acceleration Fig. 3.2.5.4—EDR acceleration record for the impinged accelera-
time pulse. The accelerometer is continuously sampled by the data tion pulse of Fig. 3.3. Note that the EDR record starts at
1
acquisition system, thus creating a digital time acceleration record approximately− 2 2 g. This is a typical wake-up value for EDR algo-
共or acceleration pulse兲. rithm processing and EEPROM storage.
Fig. 3.2.5.5—Superposition of the calibrated external acceleration

data of Fig. 3.2.5.3 and the EDR internally stored acceleration Fig. 3.2.5.6—An extension of the acceleration record shows a com-
record of Fig. 3.2.5.4. Note that, for the duration of the EDR parison of calculated impinged Delta V 共derived from the example
record, after time synchronization, the values are substantially calibrated-acceleration pulse兲 versus the example EDR recorded
congruent. Also note that the example pulse was sufficient to fire Delta V 共derived from the example EDR-recorded-acceleration
the airbag squib 共shown as the twin+ volts differential fire pulse兲. pulse兲. Using the time to fire data in Fig. 3.2.5.5 共17.6 ms兲, one can
From this fire signal record, the time to fire can be determined now determine the Delta V at fire 共−4.9 mph兲, one of the useful
共17.6 ms for the specific test acceleration pulse兲. metrics in evaluating EDR/restraint controller performance.
their data in units of cumulative velocity through an elapsed that incorporates only a portion of the whole DV pulse. Thus
time period 共 ⬘v共t兲兲. Yet others report the summation product a proper validation test requires that we know the threshold
of ap ⫻ tp for a defined time period.9 and recording elapsed duration of the internally recorded
Defined pulse data. This sounds formidable, but it is actually almost
DV = 兺
Start
ap ⫻ tp = a1 ⫻ t1 + a2 ⫻ t2 + a3 ⫻ t3 ¯ aend ⫻ tdefined intuitively and visually derived when the comparative data
are viewed. Below, an example of the process is explained
and illustrated.
Defined time periods can include: One method of validating an empirically derived SLOT
1. Cumulative velocity at the time of pretensioner deploy constant consists of impinging a known calibrated accelera-
command. tion pulse on an EDR and then comparing the EDR accelera-
2. Cumulative velocity at the time of frontal stage 1 deploy tion record with the known input pulse. For confidence this
command. can be done several times and/or done over several calibra-
3. Cumulative velocity at the time of frontal stage 2 deploy tion levels around the pulse magnitude of interest. Addition-
command. ally, if the data acquisition system used to record the im-
4. Cumulative velocity at the time of side seat deploy com- pinged acceleration pulse has also available channels to
mand. record an air bag/pretensioner squib fire pulse, the time rela-
5. Cumulative velocity at the time of side head curtain de- tionship from the EDR acceleration record start to squib fir-
ploy command. ing decision can be documented 共for the test input accelera-
3.2.5 Validation of Empirically Derived SLOT tion pulse兲.
Constants An example of one of the calibration trial 共from a pro-
cess of several such trials兲 is illustrated the sequence of Figs.
Any inductively derived analysis must be validated to dem- 3.2.5.1, 3.2.5.2, 3.2.5.3, 3.2.5.4, and 3.2.5.5. This figure se-
onstrate that it is correct. A validation of an EDR DV induc- quence shows the acceleration-impingement fixture, the ex-
tive analysis can be viewed as the validation of an accelera- ternal recording accelerometer, the external acceleration
tion signature recording capability. If the EDR under record, the EDR acceleration record, the superposition of
analysis records either acceleration or DV, the validation the EDR record on the external acceleration record, and the
process can consist of impinging a known acceleration pulse squib fire pulse resulting from that external acceleration in-
on a test exemplar ECU/EDR, and then comparing that ex- put.
ternal known 共independently recorded兲 acceleration pulse Figure 3.2.5.6 shows a superposition of the 共calculated兲
with the ECU/EDR internally recorded acceleration pulse cumulative velocity changes for both the EDR and the exter-
data 共or its DV calculation based on that兲. nal acceleration pulse. That superposition shows that the cu-
Many EDRs report their data as a partial time function mulative velocity changes are essentially congruent 共thus
9
proving that the EDR is recording a true representation of
The reader should note that some less than mathematically rigorous docu-
ments 共or translated documents兲 state this value of SLOT factor as “accel-
the input pulse that was impinged upon it兲. Additionally, the
eration,” whereas its actual units are acceleration⫻ time 共⬘ap ⫻ tp for a de- time value data for the start of squib-fire time are shown in
fined time period兲. Such units can take the form of g s, g ms, etc. Fig. 3.2.5.5. This time, also called the time to fire 共TTF兲, can
Fig. 3.2.6—Spreadsheet Solution for cumulative velocity change 共mph兲.
be applied to Figure 3.2.5.6 to determine the cumulative ve- values: $6F, $71, $74, $70, $6B, $64, $61, $5E, $5D, $5F,
locity change at the time of the deploy command, $61, $5C, $59, $5C, $5F, $62, $68, $70, $72, $70, $71,
兩兺 v共t兲兩at fire command. $73, $71, $72, $73, $72.
Lastly, note that the EDR recording threshold and re- For this fact set, we can calculate the acceleration profile
cording elapsed duration of the internally recorded pulse and cumulative velocity loss 共DV兲 using a spreadsheet for-
data are visually observable when the comparative data are mulation, as shown in Fig. 3.2.6.
viewed in Figs. 3.2.5.5 and 3.2.5.6. The spreadsheet operators of Fig. 3.2.6 have been cov-
3.2.6 A Modified Problem Exercise ered in prior chapters and, thus, are not repeated here.
As a second problem exercise let us assume the following: References

1. 0.4900g per A/D count.
关3.2.1兴 Wikipedia, the free encyclopedia, Inductive reasoning, May
2. 4 ms per acceleration sample 共0.0040 s兲.
2007 共http://en.wikipedia.org/wiki/Inductive_reasoning兲.
3. Each A/D count represents the average acceleration for
a 1-ms period. 关3.2.2兴 Stanford Encyclopedia of Philosophy, Inductive Logic,
4. Each period average acceleration is evaluated as Vaccl February 2008 共http://plato.stanford.edu/entries/logic-induc
− Vquiescent. tive/兲.
5. Vquiescent has an A/D count value of $73. 关3.2.3兴 Mercier, C., Elements of Logic 90, University of Notre Dame,
6. There are 26 Vaccl count values having the following hex 2006.
3.3 Deductively Identifying EEPROM network interfaces such as the AVT 716® shown in Fig.
Parameters from Published Data and 3.3.1.1 and proprietary interrogation scripts 关3.3.4兴. Such in-
Deductively Deriving the Required SLOT1 terrogation methods can far exceed the information depth
Factors that Translate Raw EEPROM and vehicle coverage available in publically available
Data into Cumulative Velocity Loss „Delta V… interrogation/download tools such as the Bosch/Vetronix
CDR® 关3.3.5兴.2
HERE IN SECTION 3.3, WE WILL DISCUSS A PRO- Of course, individually developed tools require a far
cess called deductive analysis. As stated in “The Deductive higher understanding of network protocols and command
Essay” 关3.3.1兴 and in “The Method of Formal Logical Analy- syntax formats for the device under test than does the basic
sis” 关3.3.2兴, deductive analysis, or deductive reasoning, is the use of the Vetronix CDR®.
kind of analysis or reasoning which provides a verifiable hy- In this section we will be focusing on a 2000 model year
pothesis 共method兲 when one starts with a known and given- domestic vehicle EDR to demonstrate a deductive process
correct process outcome. Said another way, in Wikipedia for the development of a translation capability for data from
关3.3.3兴, if the process outcome is true 共a given兲, it is reason-
that EDR.3 As with the example in Fig. 3.3.1.1, there are no
able to expect that the solution method 共hypothesis兲 will be
public data retrieval and translation tool kits, such as the
true after having been verified over several different and in-
Vetronix CDR® for this EDR. However, using such indi-
dependent but known process outcomes.
vidual network interfaces and self-developed translation
In the case of an EEPROM data analysis methodology,
tools, the raw hexadecimal EEPROM data can be readily
deductive analysis begins with collected known solutions,
downloaded, parsed, and formatted. Figure 3.3.1.2 shows
specifications, facts, or subhypotheses, from which one at-
tempts to deduce a hypothesis 共solution method兲 for a par- typical formatted hexadecimal data for a 2000 model year
ticular outcome set. This often includes yet-unanalyzed raw EDR of the type we will be examining in the example below.
data. Then, once that deduced hypothesis 共solution method兲 Referring to Fig. 3.3.1.2, we can see that the EDR non-
is tested and found to be repeatable, it can be used with con- volatile memory 共EEPROM兲 contains 512 bytes of data in
fidence to solve new problems for other examples in that pro- address memory range $0800 through $09FF.4 With this as-
cess class, where the process outcome is not given. sumption established, to complete this assignment, we now
This is contrasted with Section 3.2 where we discussed have to identify the EEPROM data fields and the SLOT fac-
inductive analysis, which begins with no fixed solution. In tor content within those fields, in order to perform a transla-
that case, one or more problem solution hypotheses 共meth- tion of such EDR data. For this example, we shall consider
odologies兲 are repeatedly tested to see if they produce a re- the assignment to be complete when we identify the
sult that represents a repeatable, logically, and physically EEPROM locations of the longitudinal acceleration data, we
correct solution, from which we can gain confidence in that have developed a means to calculate a cumulative longitudi-
solution as it applies to new problems in that problem set. nal Delta V based on that data, and we have compared our
However with inductive analysis the solution was not guar- end calculation result 共time cumulative Delta V profile and
anteed, and thus, confidence in the solution is not absolute. end point兲 with a known good solution 共the manufacturer
Of course, in both cases, we gain confidence in our solu- calculation兲.5
tion methodology by repeated experimental validation to
show that the induced or deduced solution methodology 共hy-
pothesis兲 is actually reliable, repeatable, and trustworthy 3.3.2 Source Data for a Deductive Analysis
and has an acceptable error rate.
When receiving sufficient consumer complaints, and in the
interest of public safety, the U.S. Department of Transporta-
3.3.1 Background and Retrieval of EEPROM tion 共DOT兲 National Highway Safety Administration
Data 共NHTSA兲 conducts investigations into the performance of
certain vehicle systems. Such investigations are performed
A typical EDR interrogation, together with a typical hexa- by the Office of Defects Investigation 共ODI兲. A familiarity
decimal data table output 共after parsing and formatting兲 is with such investigations can reveal data helpful in the de-
shown in Fig. 3.3.1.1. This was accomplished with individual
1
“SLOT” information is defined by the Society of Automotive Engineers 共SAE兲 Recommended Practice J2178-2 共SAE J2178-2兲 to be the scaling, limit, offset,
and transfer function specifications that allow hexadecimal encoded engineering data to be interpreted into engineering units such as psi, seconds, volts,
amps, gs, etc.
2
As one example, for some EDRs the CDR reported event record identifies whether the SRS MIL 共system readiness lamp兲 was ON 共indicating an DTC/error condi-
tion兲 or OFF 共indicating no detected DTC/error conditions兲 at the time of the event. However, for some EDRs, analysis of the hexadecimal data can reveal which
DTC/error condition may have been present at the time of the event, or in history before the event.
3
Coverage not available with the Vetronix CDR®.
4
Note that the interrogation process discussed here uses an AVT 716 and is not part of the Vetronix CDR® menu functions. For units within its coverage scope, the
Vetronix CDR® produces equivalent hex data, but does not necessarily translate all of those data.
5
That is the essence of a deductive analysis as defined at the beginning of this section.
rogation and parsing method will also apply to the tar-

get ECU.
3.3.4 Next, if we look at Fig. 3.3.2.5, we can find a graphical
trace representing the longitudinal acceleration data,
with obvious 2-ms data points. Note that the begin-
ning data start at a bit less than −5g and that at about
76– 78 ms, the data spike to a bit over +15g. For pur-
poses of our deductive investigation, we are interested
in this, or any, profile or pattern that will help us iden-
tify the data field location in EEPROM.
3.3.5 Next, if we look for the data corresponding to that lon-
gitudinal acceleration trace, we find that in Fig. 3.3.2.4
in the column titled g’s. Note that each g’s value is asso-
ciated with a time point in milliseconds.
3.3.6 Next, if we look to the column immediately to the left
of g’s, we see two columns labeled “Raw data A/D
counts” and “Raw data offset adjusted A/D Counts.”
3.3.6.1 Focusing first on Raw data offset adjusted A/D
counts 共the column immediately to the left of g’s兲,
we see that the series of values in g’s 共−6.00, −5.50,
−4.00, −8.00, −10.50, −13.5, etc.兲 follows a pattern
with respect to Raw data offset adjusted A/D
counts wherein the g’s column is always exactly
1 / 2 the value of the Raw data offset adjusted A/D
counts 共respective corresponding values of −12,
−11, −8, −16, −21, −27, etc.兲. This is true for the
entire range of 40 values in these two columns.
So, it appears that, by observation, we have de-
duced a “SLOT factor” relationship for these col-
umns 共0.50⫻ adjusted A/D counts= gs兲.
3.3.6.2 Focusing next on the Raw data A/D counts col-
umn, we see corresponding values of 共150, 151,
154, 146, 141, 136, etc.兲. Carefully reviewing our
Fig. 3.3.1.1—Interrogation of typical EDR with AVT network inter- source material 共Fig. 3.3.2.4兲, we see that just be-
face using ISO 9141 network protocol. Parsed and formatted data low the Raw data A/D counts column there is a
shown on accompanying computer screen. box identifying that the x zero point 共counts兲 = 162
dec. This is shown more clearly in Fig. 3.3.6.2.
Recalling from Section 3.2.2 that one way of cre-
ating internal signed numeric values with integer
arithmetic is to perform a subtraction such that
ductive process. In this example, NHTSA/ODI investigation
the signed value of acceleration counts 共⫾兲 is
EA03-010 关3.3.6兴 contains, in its public records, information
stated as the count value of Vaccl − Vquiescent. So, to
that allows us to proceed with a deductive analysis that pro-
see if this method applies for the series we are ex-
vides us with a template that we can use for future analysis of
amining, if we let Vquiescent共counts兲 = 162 dec, and
similar EDRs 共not covered by the Vetronix CDR®兲.
then subtract Vquiescent共counts兲 from each succes-
There are approximately 11,000 pages of data in the
sive Raw data A/D counts value, we should get the
EA03-010 file. From these, five pages were helpful in devel-
corresponding Raw data offset adjusted A/D
oping the deductive translation process for the above ECU
counts value. Taking the values we noted above,
type. These five pages are shown in Figs. 3.3.2.1, 3.3.2.2,
we can create a table of relationships to test this
3.3.2.3, 3.3.2.4, and 3.3.2.5.
hypothesis. Table 3.3.6.2, below, does this and
3.3.3 We first note that for the target EDR 共P/N YF1A-
confirms that we have a correct set of relation-
14B321-BG, Fig. 3.3.2.1兲, the stated EEPROM header
ships for our beginning series of longitudinal ac-
information 共beginning EEPROM data contents兲共Fig.
celeration values.
3.3.2.2兲 appears to match the EEPROM header infor-
3.3.6.3 We have now confirmed raw data translated to en-
mation in the our prior downloaded reference 共Fig.
gineering unit relationship; however that accom-
3.3.1.2兲. This confirmation gives us some assurance,
plishment is only useful if we are given the deci-
but not a guarantee, that our already developed inter- mal data for each time period. In a real EDR data
Fig. 3.3.1.2—Typical formatted hex data table for type of 2000 model year EDR explored in the deductive translation example below. These
data were obtained using an AVT-716 network interface and postprocessing methods similar to those shown in Fig. 3.3.1.1.
exercise where the raw hexadecimal EEPROM

data will only be given, we have to know where the
longitudinal acceleration data are located. Thus,
the next project we have to address is to locate
those values in the EEPROM data retrieved from
an EDR.
This can be accomplished by viewing the known accel-
eration count data series as its hexadecimal equivalent data
series, and then attempting to locate that data within the tar-
get EDR hexadecimal data.
The first step is to create that hexadecimal equivalent
data series for the longitudinal acceleration data. This just
requires a spreadsheet exercise where each decimal count is
operated on by QP:@NUMTOHEX共cell#兲. This process, for
the longitudinal data in Fig. 3.3.2.4, is shown in Fig. Fig. 3.3.2.1—EA03-010 page 1101, Appendix E, Book 2 EDR, sub-
3.3.6.3.1. ject of our deductive translation development exercise.
Fig. 3.3.2.2—EA03-010 page 1105, Appendix E, Book 2, formatted hex data table retrieved from the EDR in Fig. 3.3.2.1. 共Similar to the
Formatted hex table in Fig. 3.3.1.2.
Next, we have to execute an exercise where we slide the 3.3.6.2兲. Borrowing from our deductive methodology used to
40 element hex data cells over the 512 cells in the EEPROM locate the longitudinal raw hexadecimal acceleration count
list to see if there is an exact match for the entire series. It data, we can convert our Vquiescent共counts兲 value to hexadeci-
turns out that there is a match if we start the comparison at mal, or $A2.
EEPROM address $099F and continue for 39 additional cells Now, studying the full formatted raw EEPROM data
to EEPROM address $09C6. table in Fig. 3.3.6.4, we see that there is only one location in
Borrowing a term from plane geometry, our calculated all of the 512 values that is congruent with $A2. That location
longitudinal acceleration raw count data are congruent with is at address $0974 共circled兲.6
the Fig. 3.3.2.4 raw target EEPROM data in cells $09FF 3.3.7 We are now ready to test whether the translation devel-
through $0906. Figure 3.3.6.3.2, shown right below Fig. opment we have deductively developed gives us a cor-
3.3.6.3.1, shows this excerpt of target EEPROM data as con- rect, reliable, and repeatable answer. To do this, we
gruent with our converted hexadecimal acceleration count have to extend our longitudinal acceleration table to
data. calculate the cumulative velocity loss 共Delta V兲 and
Figure 3.3.6.3.3 shows this same excerpt, deductively lo- then compare that with the reference calculation.
cated longitudinal acceleration values, circled as a portion of Note that the calculation has to reasonably match the
the whole formatted target EEPROM hex table. end-point boundary 共total Delta V兲 and the cumulative
Now that we know the process of creating our signed velocity loss profile in time.
共adjusted兲 acceleration count data, and we know where that The mechanical part of the job follows the procedures
data field resides in the raw target EEPROM data, we can used earlier in Section 3.2.5. In this case we take our
perform this translation with any new EEPROM data that full linear column of signed acceleration counts 共ad-
we are given. justed acceleration counts兲 multiplied by our derived
Oops, not so fast. We also have to identify the EEPROM SLOT factor 共0.5g / count兲 and accumulate velocity loss
location of the quiescent value for X acceleration. The quies-
cent value changes as the EDR is used. In this case the target
decimal value 共162兲 is given in our source material 共see Fig. 6
In real life, one cannot expect to be this lucky very often. Most often it takes
several successive trial and error passes to determine exact data addresses.
Fig. 3.3.2.3—EA03-010 page 1103, Appendix E, Book 2, Partial interpretation summary for formatted hex data of Fig. 3.3.2.2.
increments for the duration of the time series 共80 ms 3. The decimal value in cell E30 is 135 dec, using opera-
as seen on Fig. 3.3.2.4兲. tor QP:@HEXTONUM共D30兲.
A spreadsheet to do this is shown in Fig. 3.3.7. The 4. The binary value in cell F30 is 10000111, using opera-
spreadsheet is constructed with the following data and tor QP:@HEXTOBIN64共D30,8兲
operators: 5. The longitudinal sample # in cell I30 and the cum
1. The root decimal value is chosen to present the cor- time in cell J30 are taken from the source data.
rect EEPROM address value. The root value is simply 6. The period acceleration count in cell K30= QP: +E30
incremented by 1 for each succeeding address. − $E$24.
For the calculation set in row 30: 7. The acceleration 共gs兲 in cell L30= QP: @IF共D30
2. The address $09A4 source hex data are $87 in cell lo- = “ ” , 0 , +K30*$E$14兲.
cation D30. 8. The Accel 共fpsps兲 in cell M30= QP: +L30 * $E$13.
Fig. 3.3.2.4—EA03-010 page 1106, Appendix E, Book 2, detailed data translation for the formatted hex table of Fig. 3.3.2.2.
9. The incr vel 共fps兲 in cell N30= QP: +M30 * $E$17. scales matched between the two charts. From that
10. The cum vel 共fps兲 in cell O30= QP: +O29+ N30. overlay plot, we can observe that the deductively de-
11. The cum vel 共mph兲 in cell P30= QP: rived longitudinal Delta V calculation 共solid line兲 is a
+O30 * 3,600/ 5,280. reasonable and congruent match to the stated solution
3.3.8 Presenting the deductively derived longitudinal cumu- Delta V for both end point magnitude and for the cu-
lative Delta V in a more graphical sense, Fig. 3.3.8 mulative velocity loss profile versus time.
shows a chart version of the cumulative Delta V data in 3.3.10 As a second proof of our method, we can perform the
Fig. 3.3.7. above exercise on a fresh crash exemplar and see how
our deductively derived method compares with an
3.3.9 As one proof of our method, we can compare the de-
“approved” translation solution. In this case, the
ductively derived longitudinal cumulative Delta V
fresh crash exemplar is a non-CDR supported vehicle
with the published Delta V as shown in Fig. 3.3.2.5.
共00 midsize sedan兲, which has an apparently identical
Figure 3.3.9 shows this overlay, with velocity and time
Fig. 3.3.2.5—EA03-010 page 1104, Appendix E, Book 2, longitudinal acceleration and Delta V plotted with translated data from the
formatted HexTable of Fig. 3.3.2.2. Adj Accel count values= Vaccl − Vquiescent共counts兲共“Raw offset adjusted”兲. X zero point counts= 162 dec
= $A2.
Fig. 3.3.6.2—Confirming X acceleration quiescent count value from information source 共data excerpts from the data translation in Fig.
3.3.2.4兲.
TABLE 3.3.6.2—Test of deductive longitudinal data relationships hypothesis.

Time 共ms兲 0 2 4 6 8 10 12 etc.
“Raw data A/D counts” 150 151 154 146 141 135 136 etc
共dec兲
x zero point 共counts兲 162 162 162 162 162 162 162 etc.
共dec兲
“Raw data offset −12 −11 −8 −16 −21 −27 −26 etc.
adjusted A/D counts”
共dec兲
Deduced SLOT factor 0.5 0.5 0.5 0.5 0.5 0.5 0.5 etc.
共dec兲
Deduced g value 共dec兲 −6.00 −5.50 −4.00 −8.00 −10.50 −13.50 −13.00 etc.
Stated g value in −6.00 −5.50 −4.00 −8.00 −10.50 −13.50 −13.00 etc.
Reference 共dec兲
Confirmation of 冑冑冑冑冑冑冑 etc.
deduced
versus reference value
SRS topology as a known CDR supported vehicle 01

midsize sedan兲.
We can perform the interrogation with a proprietary in-
terface as was done for the data in Fig. 3.3.1.2. Alternatively,
we can accomplish this, utilizing a standard network inter-
face in a nonstandard mode. This can be accomplished with
a standard CDR, but using a special version software and a
special VIN so that the CDR performs the desired download
in spite of what would be a rejection in the normal user
mode.7 As an added bonus, in this special case, the CDR ac-
tually performs a correct translation of the data, so that we
can see how our deductively derived method compares with
an approved translation solution.
Figure 3.3.10.1 shows the interrogation of the exemplar
vehicle using CDR in special mode for a formally nonsup-
ported vehicle.
Figure 3.3.10.2 shows the formatted hex data table ob-
tained using CDR in a special mode for formally nonsup-
ported vehicle.
Figure 3.3.10.3 shows the last section of acceleration/
cumulative Delta V table from CDR translation, showing fi-
nal cumulative longitudinal Delta V and final cumulative lat-
Fig. 3.3.6.3.1—Hexadecimal equivalent data series for the longitu-
eral Delta V.
dinal decimal acceleration data in Fig. 3.3.2.4. The conversion is
accomplished by operating on each decimal count with
QP:@NUMTOHEX共cell#兲.
7
In this case that was accomplished with CDR V2.4 and a special VIN:
1FAFP53U31G111111. This special VIN forces the CDR interface into a
mode where certain security filters are not present.
Fig. 3.3.6.3.2—Excerpt of formatted hexadecimal EEPROM data table 共Fig. 3.3.2.2兲 showing 40 derived hexadecimal acceleration values for
longitudinal count series 共Fig. 3.3.6.1兲 matching 40 data values in EEPROM addresses $099F through $09C6. Since the 40 hex values match
exactly, this locates the address range for the longitudinal acceleration with a high degree of confidence.
Fig. 3.3.6.3.3—Deductively located longitudinal acceleration values circled as a portion of the whole formatted EEPROM hex table.
Figure 3.3.10.4 shows the CDR graphical plot of cumu- An added benefit of this exercise is that we have also
lative longitudinal Delta V versus longitudinal acceleration demonstrated an empirical way to reliably extend the cover-
for the downloaded hex data of Fig. 3.3.10.2. age utility of a CDR.
Figure 3.3.10.5 shows the deductively derived table of
period accelerations, period Delta V increments, and cumu-
lative Delta Vs for longitudinal and lateral crash pulses 共us-
ing the method of Section 3.3兲, operating on the raw data of 3.3.3 Operator Equivalence: Quattro Pro®
Fig. 3.3.10.2 as imported into an analysis spreadsheet simi- versus Excel®
lar to the one described earlier in this section. Note that the
The following are Excel® equivalents for the QuatroPro®
deductively derived acceleration/Delta V table and the CDR
formulations shown in the discussion above.
generated acceleration/Delta V tables are identical.
Figure 3.3.10.6 shows an overlay graphical comparison Figure Cell Quattro Pro® Excel®
of the deductively derived cumulative longitudinal velocity reference reference
共dashed line兲 versus CDR generated cumulative longitudinal 3.3.7 E30 @HEXTONUM共D30兲 =HEX2DEC共D20兲
3.3.7 F30 @HEXTOBIN64共D30,8兲 =HEX2BIN共D30, 8兲
velocity 共starred line兲.
3.3.7 K30 ‘+E30− $E$24 ‘=E30− E24
This completes the second proof of our method. We 3.3.7 L30 @IF共D30= “ ” , ‘=K30*E14
have thus followed our original requirement that we gain 0 , +K30*$E$14兲
confidence in our problem solution methodology by re- 3.3.7 M30 ‘+L30*$E$13 ‘=L30*E13
peated experimental validation to show that the induced or 3.3.7 N30 ‘+M30*$E$17 ‘=M30*E17
deduced solution methodology is reliable, repeatable, and 3.3.7 O30 ‘+O29+ N30 ‘=O29+ N30
3.3.7 P30 ‘+O30*3,600/ 5,280 ‘=O30*3,600/ 5,280
trustworthy.
In this deductive analysis example, we have confirmed
the reliability of our deductive analysis method by compar-
ing it with an approved translation solution for two indepen-
dent events.
Fig. 3.3.6.4—Locating the X acceleration quiescent point raw count data 共X zero point兲. Reviewing the formatted EEPROM table, we see
that there is only one location in all of the 512 values that is congruent with $A2. That location is at address $0974 共highlighted兲.
Fig. 3.3.7—Spreadsheet showing translation from acceleration to Delta V.

Fig. 3.3.8—Chart showing line plot of the deductively derived lon-

gitudinal cumulative Delta V shown in Fig. 3.3.7.
Fig. 3.3.10.1—共a兲 Interrogation of nonformally upported vehicle

with CDR and special VIN. 共b兲 CDR interface used for interrogation
of nonformally supported vehicle with CDR used in special mode.
Fig. 3.3.9—Overlay comparing the deductively derived longitudi-

nal cumulative Delta V 共solid line兲 with the published longitudinal
Delta V shown in Fig. 3.3.2.5 共dotted line兲. We can now observe
that the deductively derived Delta V calculation is an accurate and
reasonable match to the stated solution Delta V for both end
point magnitude and for the cumulative velocity loss profile ver-
sus time.
Fig. 3.3.10.2—Formatted hex data table obtained using CDR in special mode for formally nonsupported vehicle.
Fig. 3.3.10.3—Last section of acceleration/cumulative Delta V table from CDR translation, showing final cumulative longitudinal Delta V
and final cumulative lateral Delta V.
Fig. 3.3.10.4—CDR graphical plot of cumulative longitudinal Delta V versus longitudinal acceleration.
Fig. 3.3.10.5— Deductively derived table of period accelerations, period Delta V increments, and cumulative Delta Vs for longitudinal and
lateral crash pulses 共using the method of Section 3.3兲, operating on the raw data of Fig. 3.3.10.2 as imported into an analysis spreadsheet
similar to the one described earlier in this section. Note that the deductively derived acceleration/Delta V table and the CDR generated
acceleration/Delta V tables are identical.
Fig. 3.3.10.5— „Continued….
References
关3.3.1兴 The Deductive Essay, Essay Info Writing Center, 共http://
essayinfo.com/essays/deductiveគessay.php兲 1 May 07.
关3.3.2兴 The Method of Formal Logical Analysis 共http://www.rbjones.
com/rbjpub/methods/fm/fm013.htm兲 1997/12/16.
关3.3.3兴 Wikipedia, Deductive Reasoning, Wikipedia, the free ency-
clopedia 共http://en.wikipedia.org/wiki/Deductiveគreasoning兲
1 May 07.
关3.3.4兴 AVT-716, Advanced Vehicle Technologies, Inc. ®, Davidson-
ville Md. AVT-716 Multiple Interface for Vehicle Networks
Fig. 3.3.10.6—Overlay for Example 2. Showing graphical compari- 共J1850 VPW, J1850 PWM, KW2000-ISO 14230, GM ALDL
son of deductively derived cumulative longitudinal velocity
共dashed line兲 versus CDR generated cumulative longitudinal veloc- 8192 UART, ISO 9141-2, Chrysler CCD兲. The AVT-716 may be
ity 共starred line兲. Note that overlay is nearly perfectly congruent, operated to provide ECU interrogations using a provided util-
except for small variance at the lower right of traces. Note also ity 共AVTគTerm兲 and an interrogation script兲, or it may be oper-
that special VIN was used.
ated via a hard coded program. For general interrogations
such as discussed herein, the interrogation script method
provides the quickest and most reliable interrogation utility.
关3.3.5兴 Bosch/Vetronix CDR.® This product 共the CDR兲 consists of a
hardware kit called the Bosch Crash Data Retrieval System.
When used with hardware and software options, the CDR sys-
tem has the capability to download crash event data from the
airbag modules on selected GM, Ford and Chrysler vehicles,
and from selected PCMs on 2003–2007 Ford vehicles.
关3.3.6兴 NHTSA, EA03-010, Investigation; http://www-odi.nhtsa.dot.
gov/cars/problems/defect/results.cfm.
Search Results
Report Date: August 6, 2006 at 04:35 AM
NHTSA Action Number: EA03010
NHTSA Action Number: EA03010NHTSA Recall Campaign
Number: N/A
Make/Models: Model/Build Years:
FORD/TAURUS 2000–2001
MERCURY/SABLE 2000–2001
Manufacturer: FORD MOTOR COMPANY
Component: AIR BAGS:FRONTAL
Date Investigation Opened: July 2, 2003
Date Investigation Closed: June 23, 2004
Summary:
This investigation identified a total of 427 reports
alleging nondeployment of the frontal air bags. Of the
427 reports, two incidents 共fatal crashes兲 have been
identified as severe frontal crashes in which the
frontal air bags did not deploy. A defect trend has not
been identified at this time. Further use of agency
resources does not appear to be warranted.
Accordingly, this investigation is closed. The closing of
this investigation does not constitute a finding by nhtsa
that a safety-related defect does not exist. The agency
will take further action if warranted by the
circumstances. See attached summary report.
3.4 Data Import Methods, Mapping 07, Standard Guide for the Collection of Non-Volatile Memory
Templates, and Introduction to Data Mining Data in Evidentiary Vehicle Electronic Control Units 关3.4.1兴
provides a suggested procedure for evidentiary data down-
WE HAVE NOW GONE THROUGH SOME INDIVIDUAL loads of this type.
examples of data translation and we have touched on data Below, we will explore methods of achieving our objec-
import and mapping using spreadsheet tools. While these tives 共digital data input and mapping and identification of
examples are certainly valuable, an increased usage pattern precise translation parameters兲 when faced with varying cir-
for these methods and techniques can prove even more valu- cumstances.
able because they will save time when similar ECU types are
encountered in future investigations. For that reason, it is
valuable to create a data import and mapping template 3.4.1 Importing and Mapping Data Using a
共spreadsheet兲 for each of the many potential data types we Vetronix CDR® Retrieval Tool
will encounter in the ensemble of real world investigations.
Without question, the most commonly used EDR data re-
This can be likened to the use of form letters in various word
trieval tool is the Vetronix CDR. In many cases the CDR pro-
processors 共also often called templates as well兲. vides key and valuable information about a crash event.
A data import and mapping template is, by nature, spe- However, even when the CDR provides a report, it does not
cifically dependent on the means used to retrieve the data usually report on all the data that are retrieved. In some
from the ECU under investigation. In this section we will ex- cases, the CDR accepts an application VIN, retrieves the
plore the derivation of import and mapping templates from data, provides a data list but provides no report. In other
three such sources: 共1兲 a formatted hexadecimal data table cases, the CDR can be used to retrieve valid data for vehicles
from a Vetronix CDR1 interrogation, 共2兲 a generic unparsed not in its application list, but again provides no useful report.
hexadecimal interrogation log obtained by using an AVT The objective in this first exercise is to explain how the CDR,
-7182 network interface, and 共3兲 a formatted input table con- acting as a data retrieval tool, saves its data, and then to show
how to use a CDR user output as the source material for our
sisting of decimal values in a hexadecimal address array.
import and mapping template.
In general, the objective of any data template is to im-
port the data and then to create a linear data list which can
be translated 1 byte at a time, or in multibyte groups, into
engineering values.3 The first step in accomplishing this is to
understand the output format of whatever interrogation in-
terface tool we are using. We have seen in Section 3.1 is an
example where we imported a text file 共actually an “S19” file,
exported by another proprietary interrogation tool兲 and
parsed and formatted that file to produce a formatted hex
table and, ultimately, a linear address formatted hex data
list—with translations to decimal and binary for each and
every byte. In that case, the input S19 file was imported into a
spreadsheet as lines of text, after which we performed sub-
string and referenced-call operations to produce our format-
ted hex table and output linear list.
When addressing a data import and mapping problem,
it is most desirable to receive the data as a digital 共computer兲
data file. Because that is widely known, the availability of
digital data files is often limited and/or discouraged by those
providing the data. It is a common occurrence where the
downloading party makes an offer to provide hardcopy, or a
Fig. 3.4.1.1—CDR three pass interrogation process as viewed by
graphic file of the data 共essentially a photograph兲, neither of operator.
which is easily useful as data input to a spreadsheet. Other
variations of this are for the supplying party to offer the
source data and/or its translation, but in a scrambled fashion
with no slot factors associated with the data. ASTM E2493—
1
More information about the Bosch/Vetronix CDR® data retrieval tool can be found at Vetronix Corporation, 2030 Alameda Padre Serra, Santa Barbara, CA
93103-1716, USA, 1 800 321-4889, http://www.boschdiagnostics.com/testequipment/diagnostics/cdr/Pages/CDRHome.aspx.
2
More information about AVT network interface devices can be found at http://www.avt-hq.com/contact.htm, Advanced Vehicle Technologies, Inc., 1509 Manor
View Road, Davidsonville, MD 21035, USA, Phone: ⫹1-410-798-4038.
3
Some templates include translation intelligence. However, this is invariably design specific, so here we will limit our scope to generic data import and formatting.
Fig. 3.4.1.2—ECU #1 interrogation. Fig. 3.4.1.3—ECU #2 interrogation.
Fig. 3.4.1.4—Binary data file for CDR interrogation of ECU #1. Note that the rightmost column contains a literal ASCII representation of the
hexadecimal data contents.
Fig. 3.4.1.5—Binary data file for CDR interrogation of ECU #2. Note that the rightmost column contains a literal ASCII representation of the
In operation, the CDR interrogates the ECU under test three

times,4 and if those interrogations agree, the CDR postpro-
cesses the interrogated data into a formatted hex table and The full binary format data for the filename.cdr files pro-
translates selected sections of those data into an engineering duced for those respective ECUs, shown in Figs. 3.4.1.4 and
table or chart format. Additionally, the CDR identifies the en- 3.4.1.5, show the engineering design type and design level for
gineering design type and level of the ECU. Engineering de- those respective ECUs. Figures 3.4.1.6 and 3.4.1.7 show the
sign type and level are not shown in the standard CDR re- formatted hex data table provided to the user of the CDR
port. However this information may be obtained by reading 共considered the standard hex data兲.
the filename.cdr file in a binary format with any one of sev- If one carefully inspects the binary formatted filename.
eral text editors.5 Figures 3.4.1.2 and 3.4.1.3 show CDR cdr files, one will see the linear string of hex data 共wrapped
benchtop-umbilical interrogations of two different ECUs. across line entries兲. In this case, I have highlighted the re-
spective hex data in Figs. 3.4.1.8 and 3.4.1.9.
Given that the binary format file is viewable and print-
able, one could always retrieve those hex data manually
4 from the CDR file, but there are better ways of doing that. In
Each of those trials called a “pass.” See Fig. 3.4.1.1.
5
The examples used here were created with Textpad 4.7.3, Helios Software earlier CDR versions, the data were displayed page by page,
Solutions. including the formatted hex data table which could be cop-
Fig. 3.4.1.7—Hex data table for ECU #2.
One could always retrieve those hex data manually from

the CDR file, or one can generate the PDF file using the CDR
option for that. The PDF file, as generated by the CDR, allows
capture of the hex table in character form.
Using our first example, we see that the data are actually
packet information from that ECU.7 Since that packet infor-
mation cannot be copied from the CDR “Preview Report”
screen directly, we create a ⴱ.pdf file from the CDR source
Fig. 3.4.1.6—Hex data for ECU #1. data. Data from the PDF file can now be pasted into a note-
book page as rows 共sentences兲 of data and we can again re-
utilize the S19 formatting technique discussed in Section
ied in text character form for later pasting into a spreadsheet
3.1. This first step is shown in Fig. 3.4.1.10. Next, by using
notebook page. If such a table is listed in character form, it is
successive internotebook page references, we can create our
a simple matter to copy and paste the hex table onto a
goal of a linear data list.
spreadsheet using the CR/LF6 on successive data lines to
Figures 3.4.1.10 and 3.4.1.11 show the process steps in
form into successive spreadsheet data rows: however the
creating this linear list from a CDR input 共regardless of
horizontal space delimiters do not neatly drop successive
whether the CDR output is in raw EEPROM format, or in
data columns when one tries to paste those data into a
newer PID or DPID8 format兲.
spreadsheet. To accomplish that formatting, we have to re-
utilize the S19 formatting technique discussed in Section
3.1.
Later versions of the CDR application software only dis- 7
Packet information is assembled from various sources in the ECU 共RAM,
play the hex table in graphics form and do not permit the ROM, EEPROM, etc.兲 to provide data to the interrogating device.
8
user to view and copy an individual page of hex data; how- DPID= data packet identification number, usually for multiple data values
共per SAE J2190, p, 4兲. PID= parameter identification number, usually for a
ever the hex data are still there, it just requires import by a single data value 共per SAE J2190, p. 4兲. A DPID is typically a command code
different method. to retrieve one or more operating data values 共or PIDS兲 from an ECU while it
is being interrogated in a diagnostic mode. The data quantities retrieved by
PIDs and/or DPIDs are typically translated into engineering units by using
SLOT factors. SLOT factors are defined by SAE J2178-2 to be the scaling,
6
CR= Carriage Return, LF= Line Feed. These are standard printer controls limit, offset, and transfer function specifications that allow hexadecimal en-
used to wrap lines on a computer monitor and are used as line delimiters coded engineering data to be interpreted or mapped into engineering units
when importing data into a spreadsheet. such as DTCs, RPM, mph, lbf, psi, seconds, volts, amps, Gs, etc.
Fig. 3.4.1.8—Hex data outlined in full CDR binary file, ECU #1. Note that the rightmost column contains a literal ASCII representation of the
3.4.2 Introduction to Data Mining for the Examining Fig. 3.4.2.1 and its two translations, and
Data Examples in Section 3.4.1 comparing those translations to the ECU label, Fig. 3.4.2.2,
we see that ASCII translation matches the first two charac-
ters of serial number for hex data range $03.1–$03.2 and the
Now that we have imported and mapped those data into a last four characters of serial number for data range $04.2–
linear list, we can explore some techniques to mine those lin- $04.5. We also note that BCD translation matches the part
ear list data to see if we come up with some verifiable and number 共P/N兲 for data range $$06.1–$06.4. This provides a
useful data that may not be in the standard CDR report.9 One positive confirmation that the data we are examining are de-
most elementary form of data mining is to perform some rived from the unit bearing the label in Fig. 3.4.2.2 共and also
standard data translations and see if they produce some new shown in Fig. 3.4.1.2兲.
information, and then to see if that new information can be Next, if we look at the top of the CDR binary file, Fig.
verified. 3.4.2.3.a 共an excerpt of Fig. 3.4.1.4兲, we see that ECU #1 is
Taking our ECU #1 linear list in Fig. 3.4.1.11, let us per- identified as an “SDMG2000,” version “9117.” Now, looking
form those two translations for each data element and then at the BCD column in Fig. 3.4.2.1, we see that the first two
see if we have discovered some new and useful data. For the entries in the linear list 共bytes $01.1 and $01.2兲 are exactly,
translations, I chose an ASCII translation and a BCD transla- “91 17.” Looking further down the whole linear list there are
tion of each data element in the linear data list. This is no other entries for “91 17.” So, it is a good bet that for that
shown, for the first 25 entries, in Fig. 3.4.2.1. ECU type, the version is contained in the first two bytes of the
linear list. Lastly, we note that the vehicle VIN entered to pro-
duce this data record is shown as the first 17 ASCII-
translated characters of Figs. 3.4.1.8 and 3.4.2.3.a.
9
Data mining is the science of extracting previously unknown information
A similar process can be followed for ECU #2. Figure
from data. In our specific case there is no hope of any such meaningful data
extraction until the data are formatted in a linear list. Further, in a forensic 3.4.2.3.b 共an excerpt of Fig. 3.4.1.5兲, the CDR binary file for
investigation, we must confirm and validate that the extracted data are ac- ECU #2, identifies ECU type “ARM100” and version “0011.”
curate and correct.
Fig. 3.4.1.9—Hex data outlined in full CDR binary file, ECU #2. Note that the rightmost column contains a literal ASCII representation of the
Note that the rightmost version identifier matches data con- work protocol and network command format 共SAE J2178/1
tents at EEPROM address $0800 共also shown in Figs. 3.4.1.5 Jan95兲.10
and 3.4.1.9兲. Other processes confirm that EEPROM loca- The contents of the commands are standardized for the
tion. base OBD-II emission-related command set but are quite
discretionary for the set of ECUs that can be considered
3.4.3 Data Templates Using Hexadecimal event data recorders 共EDRs兲.
Data Stream Input In other cases, the ECU serial port is not connected to a
standard vehicle network. Where that is the case, a forensi-
Before there was a CDR and for those ECUs not covered by cally neutral test fixture 共breadboard兲11 must be constructed,
the CDR, there were certainly ways of reading the data from and a special wiring harness must be constructed, to allow
those vehicle ECUs. The most generic way of communicat- reasonably normal serial network communications to the
ing with a vehicle ECU consists of small control computer ECU of interest.
coupled to a network interface which transmits interroga- In this example, a forensically neutral breadboard was
tion commands to the vehicle ECU and then receives re- 10
For example the SAE J2178/1, Table 11, designated the physical address
sponses back from that vehicle ECU. In modern vehicles range for restraint controllers is $58–$5F. However most such controllers
most ECUs have an SAE J2178/1 compliant physical net- 共and EDRs兲 use physical address $58.
11
work address and communicate using a defined serial net- A test fixture that neither adds nor subtracts information from the device
under test 共DUT兲 and allows its full diagnostic operation.
Fig. 3.4.1.10—Imported DPID source data as text sentences 共one sentence per cell兲, mapped into a cell array having the DPID address and
each value in a separate cell 共one value per cell兲.
matting setup screen for parsing the traffic log of Fig. 3.4.3.2.
Figure 3.4.3.4 shows the parsed map of those import
data 共after the “parse” radio button was pushed兲. The parsed
outcome was a perfect text map of the hex data log 共Fig.
3.4.3.2兲. That parsing step imports the data log file into text
values in the spreadsheet cells. The text values are then
treated as hexadecimal source which can be translated into
numeric, bitmap, or binary representations.
Figure 3.4.3.5 shows the parsed outcome as pasted on to
a fixed location template to allow a correct intersheet cell ref-
erence from our hex table.
Figure 3.4.3.6 shows the hex table 共partial兲 as derived
from the fixed locations template.
Figure 3.4.3.7 shows the linear list 共partial兲 as derived
from the hex table in the usual way.
Now that we have completed this linear list creation
process, we can proceed to derive information about the
data contents using combinations of inductive, deductive,
and/or data mining techniques.
3.4.4 Handling a Data Array That Is Not

Quite Usual
Occasionally one encounters a data surprise. One such sur-
prise is to receive a data matrix and not quite be sure of what
number system is being used. Such is the case with our third
example.
Referring to the example of Fig. 3.4.4.1:
1. The data array looks like it should be an array of hex val-
ues, but there are three characters per cell and no alpha-
meric hex characters. Hence it is not likely hex.
2. The data array looks like it could be octal; however, there
are “8” and “9” characters, which are illegal octal char-
acters. Hence it is not likely octal.
3. The data array looks like that they could be decimal val-
Fig. 3.4.1.11—Map of Fig. 3.4.1.10 DPID addresses and each cell ues arranged as a hex table. Checking our data table, we
values mapped into a linear list 共partial table shown兲. see that the highest value is 255 and we know that it is FF
and the lowest value is 000 and we know that it is $00.
We know that those values are exactly consistent with
used for ECU operations, and an AVT 718 network interface
decimal values for hexadecimal notation. So, that is a
was used to communicate with the ECU via a special added
possibility that works.
electrical connector pin.12 Figure 3.4.3.1 shows the bread-
4. So, proceeding with that possibility, and to test that
board and the AVT-718 interface.
theory, we have to proceed to convert to a linear list and
The next step is to capture the communication log be-
see if some portion of that list can be confirmed in some
tween the interrogating tester 共laptop computer and AVT-
way.
718 interface兲 and the ECU. An excerpt of such a log for this
5. The first step is to convert to a hexadecimal array so that
breadboard setup is shown in Fig. 3.4.3.2. Note that the DUT
our prior developed analysis routines can be reutilized.
physical address 共$58兲 and the tester physical address 共$F0兲
That is accomplished by using the operator QP:@
appear as 共alternating兲 to-from pairs in every command and
NUMTOHEX共cellid兲 for each of the input data cells.
response line.
That translation of the table in Fig. 3.4.4.1 is shown in
The next and most necessary step is to parse the space-
Fig. 3.4.4.5.
delineated columns of 共mixed alphameric symbol兲 text into
6. Next we have to create a linear list in the usual fashion
column delineated cells of a spreadsheet as text 共required for
with linear list cell references operating on the hexa-
succeeding hex operators兲.13 Figure 3.4.3.3 shows the for-
decimal array with the following prototype operator:
12
In this ECU, the serial data port was not actually connected to the produc- ⫹HexTable:共cellid兲. Figure 3.4.4.6 shows the linear list.
tion vehicle wiring harness. So, a second exemplar connector was ob- 7. Next we have to try one or more of the usual data mining
tained, a connector pin extracted from that connector, and that connector techniques to see if the data we have imported to the lin-
pin was added to the breadboard connector.
13
The ability to parse space-delineated columns of 共mixed alphameric sym- spreadsheets, is to import the string concatenated data 共full sentences兲 into
bol兲 text into column delineated cells of a spreadsheet appears to be pecu- a series of row cells and then transpose substrings over to appropriate data
liar to QP8 and does not appear to work in later versions of QP or Excel. The cells to the right of each full sentence cell. Section 3.1, dealing with non-
author retains QP8 for this purpose. An alternative method, with later space-delimited sentences 共in S19 files兲, gives the methodology to do this.
Fig. 3.4.2.1—Linear list derived from Fig. 3.4.1.11 DPID addresses with ASCII and BCD translations.
ear list can provide some form of confirmation. Pro-

ceeding to make an ASCII translation of the successive
cell contents in our linear list 共QP:@HEXTOASC共cellid兲,
we see that a valid 17 digit VIN appears within the first
48 bytes, starting at address $1F00F and ending at ad-
dress $1F01F. Since that is a valid VIN 共2003 European
Sedan兲, and we can confirm it with other source materi-
als, we can now conclude that we are almost certainly
correct in our data translation assumptions.
Fig. 3.4.2.2—Label from ECU #1 referring to Fig. 3.4.2.1, linear list:

note that ASCII translation matches the first two characters of
serial number for hex data range $03.1–$03.2 and the last four
characters of serial number for data range $04.2–$04.5. Also note
that BCD translation matches part number 共P/N兲 for data range
$$06.1–$06.4.
Fig. 3.4.2.3.a—CDR binary file identifies ECU type “SDMG2000” and version “9117.” Note that this version matches BCD translation for
EEPROM bytes $01.1 and $01.2 共Fig. 3.4.1.6兲 and that the VIN entered to produce this data record is shown as the first 17 ASCII-translated
characters 共1GCEC14W21Z246174兲.
Fig. 3.4.2.3.b—CDR binary file for ECU #2 identifies ECU Type “ARM100” and version “0011.” Note that the rightmost version identifier
matches data contents at EEPROM address $0800 共Fig. 3.4.1.7兲 and that the VIN entered to produce this data record is shown as the first 17
ASCII-translated characters 共1FAFP5501A181391兲.
Fig. 3.4.3.1—Views of AVT-718 network interface and forensically neutral breadboard used to communicate to target ECU where addi-
tional serial communication lines were added to electrically access the ECU serial header pin.
Fig. 3.4.3.2—Network traffic log as seen by a network monitor

共excerpt for one 16-byte frame兲. Ⰶ-denotes Hex characters sent to
the Device Under Test 共DUT兲 --⬎ Denotes Hex characters received
from the DUT 共and interface transmit success 兵01 60其兲 “93” bytes Fig. 3.4.3.3—QP8 setup to import network traffic log into QP8
denote ‘transmit to DUT’ command mode “94” bytes denote “re- spreadsheet as text characters. This setup allows the user to parse
sponse from DUT” “58” bytes denote the physical address of the space-delineated columns of 共mixed alphameric symbol兲 text into
DUT “F0” bytes denote the physical address of the interrogating column delineated cells of a spreadsheet as text 共required for suc-
device 共共laptop computer and AVT-718兲 ceeding hex operators兲.
Fig. 3.4.3.4—Network traffic log imported into QP8 spreadsheet as text characters 共excerpt for one 16-byte frame兲.
Fig. 3.4.3.5—Network traffic log import as pasted on to template fixed locations to allow intersheet cell reference placement on to hex
table.
Fig. 3.4.3.6—Hex Table 共partial兲 derived from import fixed located array.
Fig. 3.4.3.7—Linear list 共partial兲 derived from Hex Table.
Fig. 3.4.4.1—Hardcopy array of data with cell values shown as decimal values.
Fig. 3.4.4.5—Data array converted with cell contents converted to hexadecimal values.
References
关3.4.1兴 ASTM E2493-07, Standard Guide for the Collection of Non-
Volatile Memory Data in Evidentiary Vehicle Electronic Con-
trol Units. ASTM standards may be obtained at the ASTM
website, www.astm.org, or contact ASTM Customer Service
at service@astm.org.
关3.4.2兴 SAE J2178/1 Jan95, Class B Data Communication Network
Messages, Detailed Header Formats, and Physical Address
Assignments. SAE Recommended Practice.
Fig. 3.4.4.6—Partial linear list of data with ASCII translation. Note

the VIN detected in the linear list translation.
3.5 Multibyte and Bitmap Translation as the decimal value of the concatenated hex representation in
Applied to Diagnostic Trouble Codes „DTCs… cell G29, QP:@HEXTONUM共G29兲. This shows that the deci-
mal value of the hex quantity $FF FF FF is 16,777,215 dec.
3.5.1 Evaluating Multibyte Hexadecimal
Quantities for a Single Positive Integer Value
3.5.2 Octal Coding for a Single Positive
CERTAIN DATA PARAMETERS REQUIRE MULTIBYTE Integer Value
representations to include a useful numeric range. For in-
stance, in Section 3.1.4, we saw how to concatenate two Hexadecimal arithmetic is a base 16 system. In a base 16 sys-
single cell contents in order to achieve a numeric translated tem, a single digit hexadecimal quantity is represented by
value greater than 255 decimal 共65,535 max兲. There are actu- one of 16 characters representing 16 unit quantities, 0–9,
ally many ways to use and encode multibyte parameter A–F. The highest single digit count is 15, and the next count is
records, and many of these uses and codings are incorpo- represented by a carry and 0 units 共$10兲.3 Each character po-
rated in vehicle ECUs, so let us work through several ex- sition in a respective base numbering system is represented
amples here for a 3-byte hexadecimal quantity and the vari-
by a place weight representing that numbering system. For
ous ways those coding can be used.
clarity, we can compare the character place weights in three
Building on the example in Section 3.1.4, let us illustrate
numbering systems below 共Table 3.5.2.1兲.
the decimal translation process for a 3-byte hexadecimal
Clarifying our Decimal versus Octal representations:
quantity. When multiple bytes are used to represent a param-
eter value, there is usually a designation for HiByte, Mid- Decimal ⫽ Octal
Byte, and LowByte representing the respective bit weights.1 3987 ⫽ 7623
For three bytes, the lowest value would be $00 00 00= 0 dec, 3⫻1000 ⫽ 3000 7⫻512 ⫽ 3584
and the highest value would be $FF FF FF= 16,777,215 dec. ⫹ 9⫻100 ⫽ 900 ⫹ 6⫻64 ⫽ 384
⫹ 8⫻10 ⫽ 80 ⫹ 2⫻8 ⫽ 16
Figure 3.5.1 shows three examples of such a 3-byte
⫹ 7⫻1 ⫽ 7 ⫹ 3⫻1 ⫽ 3
translation, the first for a hex quantity of $00 08 A2, a second
for a hex quantity of $1A 08 A2, and a third for a hex quantity 3987 dec ⫽ 3987 dec
of $FF FF FF. In each case, the steps are similar: 共1兲 a concat-
enation of three prior cell quantities into a new combined Now, if we know that certain nonvolatile memory quan-
cell and 共2兲 the numeric evaluation of the combined cell con- tities are designated in the octal system 共i.e., the SLOT factor
tents. Each example is discussed individually: identifies that quantity as an octal positive integer value兲, we
Taking our 3-byte quantity, $00 08 A2, found with can properly evaluate EEPROM quantities that may look
HiByte in cell D19, Midbyte in cell D20, and LoByte in cell like hexadecimal quantities, but in actuality are octal quanti-
D21, we first perform the concatenation operation to com- ties.
bine the values into one string in cell G21 using the following Figure 3.5.2 shows an example of a 2-byte octal transla-
operator: QP:@CATNH共3,D19,D20,D21兲. Next we perform tion, for an indicated memory quantity of “23 41.”
the standard numeric translation in cell H21 to determine Taking the 2-byte quantity, “23 41,” found with HiByte in
the decimal value of the concatenated hex representation in cell D32 and LoByte in cell D33, we first perform the concat-
cell G21, QP:@HEXTONUM共G21兲. This shows that the deci- enation operation to combine the values into one string in
mal value of the hex quantity $00 08 02 is 2,210 dec.2 cell I33 using the following operator:
Taking our 3-byte quantity, $1A 08 A2, found with
QP:@CATNH共2,D32,D33兲.4 Next we perform the standard
HiByte in cell D23, Midbyte in cell D24, and LoByte in cell
numeric translation in cell J33 to determine the decimal
D25, we first perform the concatenation operation to com-
value of the concatenated hex representation in cell I33,
bine the values into one string in cell G25 using the following
QP:@OCTTONUM共I33兲. This shows that the decimal value
operator: QP:@CATNH共3,D23,D24,D25兲. Next we perform
of the octal quantity “23 41” is 1249 dec.
the standard numeric translation in cell H25 to determine
We can prove this by a manual process:
the decimal value of the concatenated hex representation in
cell G25, QP:@HEXTONUM共G25兲. This shows that the deci- Focusing on Octal, 2431 ⇒ 2 ⫻ 512 ⫽ 1024
mal value of the hex quantity $1A 08 A2 is 1,706,146 dec. ⫹ 3 ⫻ 64 ⫽ 192
Taking our 3-byte quantity, $FF FF FF, found with ⫹ 4 ⫻ 8 ⫽ 32
HiByte in cell D27, Midbyte in cell D28, and LoByte in cell ⫹ 1 ⫻ 1 ⫽ 1
D29, we first perform the concatenation operation to com-
bine the values into one string in cell G29 using the following 1249 decimal
operator: QP:@CATNH共3,D27,D28,D29兲. Next we perform
the standard numeric translation in cell H29 to determine
1
Where the LowByte, lower nibble 共4 bits兲 represents a binary encoding of the 16 hexadecimal units, 0–9 and A–F.
2
Note that the decimal value of $00 08 A2 is identical to the value of $08 A2 = 2,210 dec 共from Section 3.1.4兲.
3
Similarly, in the decimal system, a base 10 system, the highest single digit value is a 9, and the next count is represented by a carry and 0 units 共10兲.
4
To our spreadsheet, the quantities are indistinguishable from hexadecimal quantities.
Fig. 3.5.1—Evaluating multibyte hexadecimal quantities for a single positive integer value.
TABLE 3.5.2.1—Comparative place weights for decimal, hexadecimal „Hex…, and octal numbering
systems „weights shown as decimal count…
Number Decimal Place 4 Place 3 Place 2 Place 1
system count weight weight weight weight
Decimal 1,000 100 10 1
Hex 4,096 256 16 1
Octal 512 64 8 1
Example representations for the same decimal count values
Decimal 3,987 3 9 8 7
Hex 3,987 0 F 9 3
Octal 3,987 7 6 2 3
Fig. 3.5.2—Octal coding for a single positive integer value.

Fig. 3.5.3—Inverted octal coding for a single positive integer value.
Fig. 3.5.4—Signed binary arithmetic as derived from hexadecimal data representation.

Fig. 3.5.5.1—A method of mapping bitmap values into translated DTC identifications.
$FF − $EA = $15

3.5.3 Inverted Octal Coding for a Single
Positive Integer Value $FF − FC = $03
There are also times when designers choose to represent Completing our evaluation by a manual process:
count values in nonvolatile memory as a countdown from
Octal, 15 03 ⇒ 1 ⫻ 512 ⫽ 512
the max hexadecimal value, $FF. For a yet more complex ex-
⫹ 5 ⫻ 64 ⫽ 320
ample, let us consider an example when the designer used a ⫹ 0 ⫻ 8 ⫽ 0
countdown scheme and chose to represent the quantity in ⫹ 3 ⫻ 1 ⫽ 3
octal format. In Fig. 3.5.3, cells D37–D38, we have what ap-
pears to be $EA FC. Now, if we know that this value is actu-
ally an inverted octal coding, we can proceed to evaluate the 835 decimal
intended quantity as follows:
The first step is to obtain the actual count from the indi- Our proof serves another purpose; it shows that, as usual,
there is more than one way to solve a problem correctly, and
cated value. Since we know that the zero count value in any
while the first method was more direct, the second method
byte is the max hex value of $FF, we can either hex subtract
provides some tutorial guidance that will be useful in later
the indicated value from $FF or we can perform a bitwise in-
examples.
version 共also called a 1 s complement inversion兲. Referring
to Fig. 3.5.3, we can perform the bitwise binary inversion of 3.5.4 Hexadecimal Representation of a
the respective binary values in cells F37 and F38 shown by Signed Binary Integer Value
calling in cells G37 and G38, QP:@INVB共F37兲 and
QP:@INVB共F38兲, respectively. Next we derive the hex value We have seen in Section 3.2.2 that we can obtain an MCU in-
of that binary inverted quantity by using in cells H37 and ternal value negative by performing a subtraction such as
H38 the operators QP: @BINTOHEX64共G37兲 and QP: when evaluating accelerometer output A/D counts by vACCL
@BINTOHEX64共G38兲, respectively. − vQUIESCENT.
Next we perform the concatenation operation to com- It is also useful to be able to represent nonvolatile
bine the H37 and H38 values into one string in cell I38 using memory quantities directly as negative values. This is univer-
the following operator; QP:@CATNH共2,H37, H38兲. Next we sally accomplished by using the 2’s compliment numbering
perform the standard numeric translation in cell J38 to de- system.5
termine the decimal value of the concatenated hex represen- In the 2’s compliment numbering system, the sign is in-
tation in cell I38, QP:@OCTTONUM共I38兲. This shows that dicated by the leftmost bit in a byte 共or in the leftmost bit in a
the octal-evaluated countdown value of the original indi- multibyte quantity兲. Using that bit, we let a “0” represent a
cated quantity of $EA FC 共octal “15 03”兲 is 835 dec. 5
Recall that if we tried to use the 1’s compliment numbering system, we
Checking our inverted-octal calculation by using a proof would have an ambiguous zero value, i.e., there would be two values that
with an alternate method: could represent zero, $00⇒0 positive and $FF⇒0 negative.
Fig. 3.5.5.2—A method of mapping bitmap values into at-event binary parameter status.
positive quantity and a “1” represent a negative quantity. The leftmost bit= “ 1 , ” so the 2’s compliment negative
Taking a one-byte quantity as an example, the maxi- value is 240− 256= −16. This is accomplished in cell G54 by
mum positive decimal quantity we can represent is ⫹127 the operator QP: @IF共共@BITTH共D54,7兲 = 1兲 , E54-256, E54兲
dec, $7F 共0111 1111 bin兲, zero dec is $00, ⫺1 dec is $FF 共1111 As a proof of this process, operating manually:
1111 bin兲 and ⫺128 dec, $80 共1000, 0000 bin兲 is the maxi-
$F0 = 1111 0000 bin 共negative number indicated兲
mum negative quantity we can represent.
In the 2’s compliment system positive numbers are rep-
1s compliment = 0000 1111
resented as usual hex/binary integer values 共through a maxi-
mum value兲, and negative numbers are represented by tak-
ing the binary inversion of a the indicated binary value and 2 ’ s compliment = 1 ’ s compliment + 1 = 0001 0000
adding 1. 2’s compliment negative values 共i.e., a leading 1 in
the quantity兲 can also be determined by taking the ‘256’ deci- Value = − 16
mal compliment of the indicated positive integer 共i.e., the in-
dicated decimal value minus 256兲. 3.5.5 Bitmap Encoding of Hexadecimal
Several examples of 2’s compliment arithmetic evalua- Data
tions are shown evaluated this way in Fig. 3.5.4 by using a
compound @IF operator. For example in cell D54 for a data There are many instances where it is required to represent
value of $F0. data in nonvolatile memory as a true/false condition. This is
Cell G10 QP: @IF共共@BITTH共$D10, 7兲 = 1兲 , “ B1108” , “ − ” 兲

Cell H10 QP: @IF共共@BITTH共$D10, 6兲 = 1兲 , “ B1107” , “ − ” 兲
Cell I10 QP: @IF共共@BITTH共$D10, 5兲 = 1兲 , ” B1106” , “ − ” 兲
Cell J10 QP: @IF共共@BITTH共$D10, 4兲 = 1兲 , “ B1105” , “ − ” 兲
Cell K10 QP: @IF共共@BITTH共$D10, 3兲 = 1兲 , “ B1104” , “ − ” 兲
Cell L10 QP: @IF共共@BITTH共$D10, 2兲 = 1兲 , “ B1103” , “ − ” 兲
Cell M10 QP: @IF共共@BITTH共$D10, 1兲 = 1兲 , “ B1102” , “ − ” 兲
Cell N10 QP: @IF共共@BITTH共$D10, 0兲 = 1兲 , “ B1101” , “ − ” 兲
A similar process applies for row 11 and row 12.

Fig. 3.5.5.3—Occupant status based on crash record data. Figure 3.5.5.1 shows the translation matrix for three dif-
ferent 4-byte condition sets of data bytes that could exist in
EEPROM data locations $1C10, $1C11, $1C12, and $1C13.
especially true of diagnostic trouble codes 共DTCs兲 and is also The first two data byte sets are used to verify the translation
true of conditions existing at an event 共e.g., seatbelt buckle method. And the third 共$10 00 03 04兲 is shown as a data ex-
status at crash event detect, brake apply status at crash event ample.
detect, etc.兲. True/false conditions are most concisely repre- The first data byte set 共$FF FF FF FF兲 is used to verify
sented by binary arithmetic, and so we can represent eight that all required translation matrix indications are shown in
such conditions by mapping their status to a binary posi- the bitmap translation matrix output.
tional bit status of a particular bit in a byte. Such a represen- The second data set 共$00 00 00 00兲 is used to verify that
tation is called a bitmap. Note that although such bytes also no indications are shown in the bitmap translation matrix
have a numeric representation, such a numeric representa- output when there source data indicate a null value.
tion has no meaning in a bitmap. The third data set 共$10 00 03 04兲 shows a typical data ex-
Although the concept of bitmaps is quite easily under- ample, with appropriate DTC flag matrix indications 共a
stood, the manual evaluation of bits in a byte and the word proper subset of the $FF FF FF FF bitmap translation matrix
correlation to DTC or other status conditions can be tedious. output兲.
However, bitmap representations can be very valuable. Two A second method of achieving bitmap translation is by
examples of this are shown in Figs. 3.5.5.1 and 3.5.5.2. including bitmap descriptive text in the running interroga-
Figure 3.5.5.1 shows a method of “mapping a bitmap” tion code so that the crash event bitmap status flags of the
into an easily read table showing a translated DTC identifica- crash record byte共s兲 are immediately obvious at the event
tion matrix using a spreadsheet conditional mapper data download. Figure 3.5.5.2 shows an example of this
关“1 ” ⇒ DTC= true, “0 ” ⇒ DTC= false兴. method where the at-event bitmap status flags of a crash
Referring to Fig. 3.5.5.1, the decimal and binary values record byte are immediately obvious and understood. Thus,
are derived in E10 and F10 by the usual methods 关e.g., because the initial interrogation log incorporates a bitmap
QP:@HEXTONUM共D10兲 and QP:@HEXTOBIN64共D10,8兲兴. translation by design, the at-event status data can be imme-
Translating the bit values to the positional codes in the diately translated without the need for a spreadsheet map-
DTC matrix is a bit more involved. That is because we re- ping function.
quire a translation matrix where each of the result cells has From that translated status, the at-event data can then
to have a unique DTC identifier dependent on the position of be easily mapped to a vehicle graphic. Using the example at-
a corresponding bit position in the hex data byte. Addition- event data record in Fig. 3.5.5.2, Fig. 3.5.5.3 maps the at-
ally, the adjacent matrix positions must remain unaffected event occupant buckle status, pretensioner deploys com-
by that positional identifier. The DTC values used in this il- mand status, and frontal air bag deploys command status to
lustration are derived from standard DTC range definitions such a graphic representation.
for body system codes in SAE J 2012 关3.5.1兴.
One solution to this is illustrated in Fig. 3.5.5.1. The po-
sitional translation of the data bytes is shown in the matrix in
columns G–N. For each data byte row, the matrix column po- 3.5.6 Operator Equivalence: Quattro Pro® vs
sition contains a unique conditional translation dependent Excel®
on the value of the corresponding data bit in the data byte for
that row. For the first row 共row 10兲, the operator required to Recognizing that many readers use Excel®, the following is
obtain that conditional translation, for the data byte in cell a table of operator equivalences for the Quattro Pro® opera-
D10, is shown as follows: tors referenced in this section.
Figure Cell
reference reference Quattro Pro® Excel®
3.5.1 G21 @CATNH共3,D19,D20,D21兲 =CONCATENATE共D19, D20, D21兲
3.5.1 H21 @HEXTONUM共G21兲 =HEX2DEC共G21兲
3.5.2 I33 @CATNH共2,I32,I33兲 =CONCATENATE共I32, I33兲
3.5.2 J33 @OCTTONUM共I33兲 =OCT2DEC共I33兲
3.5.3 G37 @INVB共F37兲共N/A兲
3.5.3 G38 @INVB共F38兲共N/A兲
3.5.3 H37 @BINTOHEX64共G37兲 =BIN2HEX共G37兲
3.5.3 H38 @BINTOHEX64共G38兲 =BIN2HEX共G38兲
3.5.3 I38 @CATNH共2,H37, H38兲 =CONCATENATE共H37, H38兲
3.5.3 J38 @OCTTONUM共I38兲 =OCT2DEC共I38兲
3.5.4 G54 @共共@BITTH共D54, 7兲 = 1兲 , E54− 256, E54兲 =IF共共d54, bit7兲 = 1 , E54− 256, E54兲
3.5.5.1 G10 @IF共共@BITTH共$D10, 6兲 = 1兲 , “ B1108” , “ − ” 兲 EXCEL condition statement as above,
共兲 Excel Hex bit eval= TBD
3.5.5.1 H10 @IF共共@BITTH共$D10, 5兲 = 1兲 , “ B1108” , “ − ” 兲共N/A兲 see above
3.5.5.1 I10 @IF共共@BITTH共$D10, 4兲 = 1兲 , “ B1108” , “ − ” 兲共N/A兲 see above
3.5.5.1 J10 @IF共共@BITTH共$D10, 3兲 = 1兲 , “ B1108” , “ − ” 兲共N/A兲 see above
3.5.5.1 K10 @IF共共@BITTH共$D10, 2兲 = 1兲 , “ B1108” , “ − ” 兲共N/A兲 see above
3.5.5.1 L10 @IF共共@BITTH共$D10, 2兲 = 1兲 , “ B1108” , “ − ” 兲共N/A兲 see above
3.5.5.1 M10 @IF共共@BITTH共$D10, 1兲 = 1兲 , “ B1108” , “ − ” 兲共N/A兲 see above
References
关3.5.1兴 SAE J2012 1999-03, Recommended Practice for Diagnostic
Trouble Code Definitions, SAE International, 400 Common-
wealth Drive, Warrendale, PA 15096-0001.
3.6 Analysis of EDR Accelerometer Running We next had to study the data record to confirm that,
Data to Determine Acceleration even with the redefined axes, the precrash acceleration data
Impingement Vectors signing was being properly recorded, and that proved to be
quite complex.
WE HAVE LARGELY BEEN FOCUSING ON TECH-
niques of EDR1 crash event data status snapshots. However, 3.6.2 The Complex Path of Matching Real
the techniques used for that are also useful in assisting with Axis Data to Standardized Axis
the mechanical analysis of accident crash dynamics over the Conventions and Azimuth Notation
course of an accident event. So, in this section, we are going
to investigate a problem where our assignment is to develop There is no axis matching requirement for the horizontal
a way to determine the true azimuth direction, with respect plane polar vector resultant magnitude. Calculating, and
to the instrumented host vehicle, of the accelerations that is simple enough.
共forces兲 impinged on a pivot point in that vehicle which is in
the process of yawing, rolling, and overturning during a
兩Ap兩 = q共Ax2 + Ay2兲
crash event. In the vehicle under investigation, the signed
rectilinear acceleration is captured, with several other pa- However, verifying the X and Y axis acceleration signals re-
rameters, as converted sample words at a rate of 20 sample- quires some thought.
words/second. Ultimately, the acceleration polar magnitude The first element of the axis confirmation process was to
and azimuth value will be used in a crash strength calcula- confirm just what acceleration signal represented true SAE
tion. J1733/J211/J670e X and Y axis signals. This requires that we
The vehicle is a race car traveling counterclockwise match the identified signals with the expected signals at
共CCW兲 around a serpentine race track having seven turns known stations of the test course so that we know, prior to
and several straightaways. The acceleration data are derived any new calculations, we have organized the reported data in
from a scalar translation function on the voltage output of a such a way that it is a consistent representation for normal
Crossbow® ±4g triaxial accelerometer. The accelerometer Z upright left-turn and right-turn responses of the race car ve-
axis was available but was not recorded. hicle as it traversed the turns in the racetrack.
To complete our assignment here, we must derive the re- Before starting that consistency check, let us review a
sultant polar acceleration vector magnitude and direction bit of the physics of an object 共vehicle兲 undergoing circular
on a clockwise 360° azimuth field starting from the recorded motion 共turning兲 on a planar surface. As confirmed in Haus-
signed rectilinear components. mann 关3.6.1兴, for an object in a controlled turn, in order to
continue with its circular motion,2 the object must be sub-
ject to a centripetal force acting toward the center of rotation
of such circular motion and acting along its radial line. Fig-
3.6.1 Matching the Real Data to ure 3.6.2.1 reviews this relationship. Since any such force
Standardized Axis Conventions has to be the product of the mass⫻ the centripetal accelera-
tion 共F = ma兲, and mass has no sign, we can immediately ob-
Chapter 2 and Section 3.2 give detailed discussions of accel-
serve the positive signed direction of that centripetal accel-
eration axes and signed reporting for standard SAE J1733/
eration 共force兲 to be inward toward the center of the turn.
J211/J670e X, Y, and Z axes.
Thus, for a vehicle undergoing a left turn, that centripetal ac-
The first step in this exercise is to map our standard
celeration must act toward the center of rotation along its ra-
clockwise 360° planar azimuth scale on the planar SAE
dial turn line 共i.e., toward the SAE −Y axis direction of the
J1733/J211/J670e X and Y axes. Figure 3.6.1 shows this map,
vehicle undergoing that turn兲.3
with an added definition of four quadrants. The quadrant
Conversely for a vehicle undergoing a right turn, that
identities will be necessary to later calculate absolute azi-
centripetal acceleration must act toward the center of rota-
muth angle.
tion along its radial turn line 共i.e., toward the SAE+ Y axis di-
The Crossbow® ±4g triaxial accelerometer has defined
rection of the vehicle undergoing that turn兲.
X and Y axes, but the instrumentation installer chose to re-
We are now ready to examine real data and compare
orient the labeled axes. So, we have to deal with the acceler-
that to real vehicle performance on the track and that is illus-
ometer signals such that the Crossbow Y axis is actually the
trated in Fig. 3.6.2.2. What we find is that positive lateral ac-
SAE X axis, and that the Crossbow X axis is actually the SAE
celeration values 共Y axis values兲 are reported for counter-
Y axis.
clockwise turns 共left turns兲, e.g., T1, T2, and T7, and that
1
EDR= event data recorder.
2
Versus flying off on a tangential line.
3
And we know that in real life, for a turning vehicle, that force is exerted by lateral friction of the road surface on the tires of the vehicle.
Fig. 3.6.1—Subject vehicle showing SAE J1733/211/670e X and Y

axes and 360° reference azimuth quadrants with accelerometer
axis overlay. Note the accelerometer as installed defines its +Y axis
pointing to the vehicle rear 共SAE −X axis兲 and its +X axis pointing
to the vehicle right 共SAE +Y axis兲.
negative acceleration values are reported for clockwise turns

共right turns兲, e.g., T3, T4, and T5. The sign of these reported Fig. 3.6.2.1—Diagram showing the relationship of centripetal ac-
values is contrary to the SAE convention, so, if we invert the celeration 共and force兲 for an object maintaining a constant angu-
stated Y acceleration signal, we can treat it as a true SAE Y lar velocity.
axis signal.
Next, we must review signing conventions used for the larity responses were correct according to SAE convention.
vehicle X axis. Examining recorded acceleration listings, we The model was dyanamically exercised in both CW and CCW
see that positive longitudinal acceleration values reflect in- turn scenarios. Figure 3.6.3.1 shows the correct alignment
creasing vehicle speed 共because of engine power input兲, and and signing of the model vehicle/accelerometer with respect
negative longitudinal acceleration values reflect decreasing to SAE Y axis conventions, producing a negative accelera-
vehicle speed 共because of braking input兲. Thus the longitudi- tion data record for the CCW 共left turn兲 and a positive accel-
nal acceleration data signed values are consistent with SAE eration data record for the CW 共right turn兲.
X axis definitions.4
Now that we know what is truly represented by the data
we have, we can address our original problem to develop a 3.6.4 Vector Magnitude and Azimuth
way to determine the true azimuth direction, with respect to Derivation from Longitudinal „X… and Lateral
the instrumented host vehicle, of the accelerations 共forces兲
„Y… Components
impinged on a pivot point in that vehicle which is in the pro-
cess of yawing, rolling, and overturning. The race car data acquisition system, MOTEC® 关3.6.2兴, pro-
vides for an export data in “CSV” format.5 CSV formatted
data readily import into spreadsheet rows and columns. So,
3.6.3 Empirical Validation of Physics Theory
we begin our acceleration vector analyses by exporting raw
Applied to Accelerometer Recording
data from the vehicle data acquisition system and importing
We can now continue with our data solution; however it is those data into one notebook page per lap of a spreadsheet
always a good practice to perform a sanity check on our hy- application. These export data fields include RPM, throttle,
pothesis and/or analytical method. This is particularly im- braking, steered angle, longitudinal acceleration, and lateral
portant when any seeming contradictions present them- acceleration. The spreadsheet fields were also augmented to
selves to the forensic investigator. In this case, a laboratory format and organize a composite data list consisting of feet/
experimental model was created to confirm the observed mph, entry-speed/braking-timing units with reciprocal
vehicle-upright and vehicle-inverted axis reporting with re- times and distances added for all laps that the subject vehicle
spect to SAE J1733/J211/J670e vehicle axis conventions. traversed. Figure 3.6.4.1 shows a sample of these spread-
To do this, a model vehicle was outfitted with a compa- sheet fields with the exported longitudinal acceleration in
rable accelerometer sensor and monitered by a laboratory column M and the exported lateral acceleration in column K
bench data acquisition system. Using this model, we could and our sign-corrected SAE-consistent lateral g’s in column
confirm that the X and Y axis accelerometer signal static po- L.
4
There is much more to this story, including double inversions, etc., but that
5
is not relevant to the purpose of this exercise. CSV= comma separated variable
Fig. 3.6.2.2—A portion of the acceleration record from our subject data acquisition system shows that positive lateral acceleration values
are reported for counterclockwise turns 共left turns, e.g., T2兲 and negative acceleration values are reported for clockwise turns 共right turns,
e.g., T4兲.
Using the longitudinal 共+X , −X兲 and lateral 共+Y , −Y兲 ac- Referring to Fig. 3.6.1, and the SAE J1733/211/670e X
celeration signals, we can then proceed with vector analysis and Y signed axis definitions, we can uniquely define each
by generating spreadsheet fields to derive the resultant mag- quadrant:
nitude and azimuth angle. Spreadsheet operators are en-
tered into cell locations in the first data row, and then the op- Quadrant 1 = + X, + Y
erator set from the first row of cells can be copy pasted down
the columns to populate the remaining data entries through- Quadrant 2 = − X, + Y
out the data set.
As noted above, we first calculate the resultant accelera-
Quadrant 3 = − X, − Y
tion in column R, where the acceleration magnitude is de-
fined as 兩A兩 = qAx2 + Ay2.
Referring to Fig. 3.6.4.1: To calculate the resultant accel- Quadrant 4 = + X, − Y
eration magnitude 兩G兩 for the first data row, the following op- The first step in calculating the azimuth angle is to assign
erator is entered into cell location R44: each X, Y data pair in column M 共longitudinal acceleration兲
QP: @SQRT共共L44ˆ 2兲 + 共M44ˆ 2兲兲. For example, for data and column L 共lateral acceleration兲 to the proper quadrant.
row 44, 兩A兩 = q共−0.8000兲2 + 共−1.1100兲2 = 1.3700g To do this, we designate columns U, V, W, and X in our
For the azimuth angle of the resultant acceleration, we spreadsheet as a logical flag to indicate quadrants Q1, Q2,
reference an intermediate quadrant notation, which we de- Q3, or Q4, and we program these cell locations with condi-
fine for all angular points in the 360° azimuth. tional statements that will place a quadrant flag in the appro-
Referring to Fig. 3.6.1, we define quadrant Q1 to cover priate column, depending on the signed data pairs as we
the +X, +Y coordinate values, quadrant Q2 to cover the +X, have defined them above.
−Y coordinate values, quadrant Q3 to cover the −X, −Y coor- Referring to the spreadsheet excerpt in Fig. 3.6.4.1, to
dinate values, and quadrant Q4 to cover −X, +Y coordinate assign a quadrant to the first acceleration X, Y pair in the
values.6 notebook page, the following spreadsheet conditional opera-
tors are entered into our quadrant-designator cell locations:
6
This succession of quadrant values is opposite to the standard Cartesian co-
ordinate counterclockwise quadrant numbering scheme, but is much more
easily mnemonically understood and used with a standard clockwise azi- geometric analyses. In any event, the quadrant definitions are intermediate
muth and standard clockwise time-equivalent scale such as used in SAE values, leading to correct azimuth results.
Fig. 3.6.3.1—An experimental data acquisition system and vehicle model corroborate SAE J1733/211/670e signing conventions and show
the correct alignment and Y axis signing of the model accelerometer with respect to SAE axis conventions.
The next step is to assemble all of the conditional flags gath-

Cell location U44, ered in columns U, V, W, and X into one cell in the Z column
for the single resolved quadrant for each X, Y data pair. To
QP: @IF共M44 ⬎ = 0#AND#L44 ⬎ = 0, “ Q1 ” , “ − ” 兲 accomplish this for the first data row 44, we place the follow-
Cell location V44, ing multiple-nested conditional statement into cell location
Z44,
QP: @IF共M44 ⬎ = 0#AND#L44 ⬍ = 0, “ Q2 ” , “ − ” 兲
QP: @IF共M44 ⬎ = 0#AND#L44 ⬎ = 0, “ Q1 ” ,@IF共M44
Cell location W44,
⬍0#AND#L44 ⬎ = 0, “ Q2 ” ,@IF共M44 ⬍ 0#AND#L44
QP: @IF共M44 ⬍ = 0#AND#L44 ⬍ = 0, “ Q3 ” , “ − ” 兲
⬍ = 0, “ Q3 ” ,@IF共M44 ⬎ = 0#AND#L44 ⬍ 0, “ Q4 ” , “
Cell location X44,
− ” 兲兲兲兲
QP: @IF共M44 ⬍ = 0#AND#L44 ⬎ = 0, “ Q4 ” , “ − ” 兲
e.g., the value returned by the conditional statement in
e.g., for data row 44, the longitudinal acceleration value in cell Z44 is Q3.
M44 is negative 共−X兲, the lateral acceleration value in L44 is Since our resultant acceleration magnitude derived in
negative 共−Y兲, so the values returned by the conditional column R is a vector that has been resolved along the X and Y
statements into our quadrant-designator cells are directions of its longitudinal and lateral components in the
rectangular coordinate system, we can now derive the geo-
Cell U44,− metric angle between the vector and either of its compo-
nents. Due to the orthogonality of the system, we can use ei-
Cell V44,− ther of the following relations: for the acceleration vector
A : Ax = A cos共␪兲 or Ay = A sin共␪兲.
Note that the angle derived will be between 0° and 90°.
Cell W44,Q3
To calculate the intermediate geometric angle for the
first acceleration vector in row 44, the following spreadsheet
Cell X44,− operator is entered into cell location AB44,
Fig. 3.6.4.1—Rectilinear acceleration from the data acquisition system imported into a spreadsheet application shows the recorded Lateral
g’s in field K and our sign-corrected SAE-consistent lateral g’s in field L. Additional spreadsheet fields are then generated to derive
resultant vector acceleration magnitude and azimuth angle from the raw data.
QP:@DEGREES共@ASIN共@ABS共K44/R44兲兲兲 We can see that the only valid term is for Z44= “ Q3”, and
so the resultant azimuth is returned as in cell AC44 as 180
e.g., the value returned in cell AB44 is 54.22°. + 54.22= 234.22°.
However, we know that we are in Q3, which exists from To complete the data set, we can now select cell loca-
180° to 270° azimuth. Thus, our intermediate geometric tions which we have programmed with spreadsheet opera-
angle 关SIN共@ABS共K44/R44兲, Cell AB44兲兴 has to be added to tors in the first data row: R44, U44, V44, W44, X44, Z44,
180°. So, the proper azimuth angle for that polar quantity is
AB44, and AC44 and copy paste down the columns.
180° +54.22°, or 334.22°.
Vector acceleration results from the above spreadsheet
We can now automate our derivation of the azimuth im-
pinge angle by adding or subtracting the intermediate geo- derivations can then be formatted graphically to pinpoint
metric angle from the appropriate quadrant reference in the where in the time line any abnormal acceleration peak pat-
respective cells in column Z. Reviewing the following multi- terns may have occurred.
ply nested operator for cell Z44: Figure 3.6.4.2 shows resultant polar magnitude in units
of g’s and linear elapsed time in seconds for the acceleration-
QP: @IF共Z44 = “ Q1 ” ,AB44,@IF共Z44 = “ Q2 ” ,180 data at issue.
Viewed in a different way, Fig. 3.6.4.3 shows resultant
− AB44,@IF共Z44 = “ Q3 ” ,180 + AB44,@IF共Z44
polar magnitude in g’s versus azimuth angle in degrees for
= “ Q4 ” ,360 − AB44, “ Err ” 兲兲兲兲 the acceleration data at issue.
Fig. 3.6.4.2—A graph of rectilinear acceleration from the data ac-

quisition system as imported into a spreadsheet application shows Fig. 3.6.4.3—Resultant force magnitude and azimuth angle versus
our sign-corrected SAE-consistent lateral g’s versus time for the time derived from signed rectilinear running acceleration data
time period of interest.
3.6.5 Operator Equivalence: Quattro Pro® vs

The results of this analysis satisfied the assignment and Excel®
were shown to be accurate even when the race car over-
Recognizing that many readers use Excel®, the following is
turned and traveled on its top.
a table of operator equivalences for the Quattro Pro opera-
tors referenced in this section.
Figure Cell
reference reference Quattro Pro® Excel®
3.6.3 W44 @IF共M44⬍⫽0#AND#L44⬍⫽0,“Q3”,“⫺”兲 “⫽IF共AND共M44⬍0,L44⬍⫽0兲,“Q3”,“⫺”兲”
3.6.3 Z44 @IF共M44⬎⫽0#AND#L44⬎⫽0,“Q1”,@IF共M44⬍ “⫽IF共AND共M44⬎⫽0,L44⬎⫽0兲,“Q1”,IF共AND共M44
0#AND#L44⬎⫽0,“Q2”,@IF共M44⬍0#AND#L44 ⬍0,L44⬎⫽0兲,“Q2”,IF共AND共M44⬍0,L44⬍0兲,“Q3”,I
⬍⫽0,“Q3”,@IF共M44⬎⫽0#AND#L44⬍0,“Q4”,“⫺ F共AND共M44⬎⫽0,L44⬎⫽0兲,“Q4”,“⫺”兲兲兲兲
”兲兲兲兲
3.6.4.1 R44 @SQRT共共K44ˆ2兲⫹共M44ˆ2兲兲 ‘⫽SQRT共共K44ˆ2兲⫹共M44ˆ2兲兲
3.6.4.1 U44 @IF共M44⬎⫽0#AND#L44⬎⫽0,“Q1”,“⫺”兲 ‘⫽IF共AND共M44⬎⫽0,L44⬎⫽0兲,“Q1”,“⫺”兲
3.6.4.1 V44 @IF共M44⬍0#AND#L44⬎⫽0,“Q2”,“⫺”兲 ‘⫽IF共AND共M44⬍0,L44⬎⫽0兲,“Q2”,“⫺”兲
3.6.4.1 W44 @IF共M44⬍0#AND#L44⬍0,“Q3”,“⫺”兲 ‘⫽IF共AND共M44⬍0,L44⬍0兲,“Q3”,“⫺”兲
3.6.4.1 X44 @IF共M44⬎⫽0#AND#L44⬍0,“Q4”,“⫺”兲 ‘⫽IF共AND共M44⬎⫽0,L44⬍0兲,“Q4”,“⫺”兲
3.6.4.1 Z44 @IF共M44⬎⫽0#AND#L44⬎⫽0,“Q1”,@IF共M ‘⫽IF共AND共M44⬎⫽0,L44⬎⫽0兲,“Q1”,
44⬍0#AND#L44⬎⫽0,“Q2”,@IF共M44⬍0#A IF共AND共M44⬍0,L44⬎⫽0兲,“Q2”,
ND#L44⬍⫽0,“Q3”,@IF共M44⬎⫽0#AND#L4 IF共AND共M44⬍0,L44⬍0兲,“Q3”,
4⬍0,“Q4”,“⫺”兲兲兲兲 IF共AND共M44⬎⫽0,L44⬍0兲,“Q4”,“⫺”兲兲兲兲
3.6.4.1 AB44 @DEGREES共@ASIN共@ABS共K44/R44兲兲兲 ‘⫽DEGREES共ASIN共ABS共K44/R44兲兲兲
3.6.4.1 AC44 @IF共Z44⫽“Q1”,AB44,@IF共Z44⫽“Q2”,180⫺ ‘⫽IF共Z44⫽“Q1”,AB44,IF共Z44⫽“Q2”,180⫺
AB44,@IF共Z44⫽“Q3”,180⫹AB44,@IF共Z4 AB44,IF共Z44⫽“Q3”,180⫹AB44,
4⫽“Q4”,360⫺AB44,“Err”兲兲兲兲 IF共Z44⫽“Q4”,360⫺AB44,“Err”兲兲兲兲
References 关3.6.2兴 The MoTeC High Performance Data Logging system. MoTeC
Systems, 5355 Industrial Dr., Huntington Beach, CA. 92649.
关3.6.1兴 Physics, Hausmann and Slack, Van Nostrand, 1957.
3.7 Analysis of ABS Wheel Speed Sensor ing adjacent to the magnetically sensitive end of the pickup
Running Data to Determine Detected Pulse coil, usually within 0.020– 0.030 in. of the coil frame. The ex-
Rate Consistency citer gear is attached to the wheel hub so that, when the
wheel rotates, the rotating gear teeth cause the pickup coil to
ASIDE FROM THE DOWNLOAD AND INTERPRETA- generate a repeating series of electrical voltage pulses 共also
tion of EDR information, an electronic data investigator can called a pulse train兲 whose frequency 共and amplitude兲 is pro-
be called upon to evaluate vehicle antilock braking systems portional to the wheel rotating speed. This pulse train signal
共ABSs兲 function. For this example, we will examine a method is sent to the ECU which contains amplitude clipping and fil-
to analyze data from a heavy truck air brake ABS system and tering circuits to provide a clean logic-level pulse train to a
its associated components. Our method identifies one poten- logic counter 共i.e., “1’s” and “0’s” to a binary logic counter兲.
tial ABS anomaly, provides a tool to identify this anomaly as The logic counter is then sampled periodically to produce a
a set of occurrences in voluminous data, and then provides pulse count per unit time 共a pulse rate ultimately propor-
a method of graphical representation to visualize that ano- tional to wheel rotational speed and thus to wheel linear
maly set versus wheel azimuth. speed兲. Individual wheel speeds are then compared to the
This anomaly set concerns potential spurious ABS speeds at other sensor-equipped wheels in the system to al-
wheel speed sensor 共WSS兲 pulses. This is important because low the ABS ECU to make an ABS ON/OFF decision. Figure
with certain ABS ECUs this may cause improper operation, 3.7.1.1 shows a typical wheel speed sensor as installed on
including isolation of the wheel apply signal, leading to ex- each wheel.
tended stopping distances.1 The frequency of the ac sinusoidal WSS signal is directly
Before proceeding with our data analysis, let us review proportional to wheel rotation speed. Figure 3.7.1.2 dia-
the fundamental operation of ABS brakes. grams a typical WSS voltage signal generated for two differ-
ent vehicle speeds. Comparatively speaking, at low wheel
speeds, the time to generate per/tooth pulses for each wheel
rotation will be long, whereas at high wheel speeds, the time
3.7.1 Antilock Braking System Operation for one wheel rotation will be shorter, so the peak signal fre-
The major components of heavy truck air brake ABS systems quency of the pulse train will increase.
consist of a central control computer 共the ABS ECU兲, indi- Figure 3.7.1.3 illustrates a simplified global architecture
vidual wheel speed sensors 共WSSs兲 and individual wheel for an ABS air brake apply and feedback system, in which the
modulator valves. In general operation, when the brakes are ABS ECU 共controller兲 monitors wheel rotational speeds via
applied and an excessive wheel slip is detected, the ECU op- electromagnetic wheel speed sensor 共WSS兲 inputs, and con-
erates the wheel modulator valves to first isolate the specific trols wheel brake friction surface apply3 via electrical sole-
wheel 共hold apply air pressure constant兲, and, if the excessive noid isolate/dump/reapply valves 共modulators兲 on the indi-
slip continues, dump 共release兲 the existing apply air pressure vidual wheel circuits. In Fig. 3.7.1.3:
until the wheel returns to a speed within the specified slip 1. Wheel speed sensors are located on each wheel to moni-
tolerance as compared to the remaining wheels.2 For the tor wheel rotation.
reader unfamiliar with ABS, a good and first overview on 2. Each WSS 共wheel speed sensor兲 communicates wheel
共passenger vehicle兲 antilock brakes in given in Carley 关3.7.1兴. rotation pulses to the central ECU.
A discussion of ABS principles as applied to truck air brake 3. The ECU interprets WSS signal pulses and calculates
systems is given in Buckman 关3.7.2兴 and details of truck air wheel speed and wheel speed acceleration rates for each
brake ABS function are given in Allied Signal 关3.7.3兴. wheel.
In operation, the ABS ECU is continuously monitoring 4. Based on WSS input, with the brakes applied, the ECU
all wheel speed sensors and compiling an aggregate running- detects excessive wheel slip and/or excessive wheel
average vehicle speed. In that way, once brakes are applied, speed deceleration and then operates the isolation/
the ABS ECU can quickly decide which individual wheel共s兲 dump 共modulator兲 valves as required to restore an ap-
may need brake apply modification. propriate wheel speed.
The wheel rotation speed is monitored by a wheel speed 5. Such braking adjustments can occur 5–10 times per sec-
sensor 共WSS兲, which is a magnetically biased pickup coil ond per wheel, and this exceeds the ability of a human
that generates an electrical pulse each time its magnetic cir- operator to accomplish such a function.
cuit is completed and interrupted. In vehicle applications, It has been shown that ABS braking function can greatly
the magnetic circuit 共relative兲 completion and interruption improve vehicle tracking, stability, and control in a mixed-
is caused by the teeth on a square toothed exciter gear, pass- friction-coefficient hard 共ABS兲 stop. However, there is no
1
Of course, the converse, missing WSS pulses, is equally important.
2
Wheel linear speed is a direct translation from the wheel rolling-radius x wheel rotational speed. Slip is the difference between wheel linear speed and vehicle
linear speed. ABS function is triggered when one or more wheels is detected to be turning with a linear speed significantly less than the average linear speed 共i.e.,
excessive slip兲 or the wheel speed deceleration exceeds a preset physical threshold 共e.g., ⬎1g = Ⰷ 21.94 mph/ s兲.
3
Controlled items can include both magnitude and duration.
Fig. 3.7.1.1—Conceptual cutaway drawing of a heavy truck wheel

showing the magnetically biased wheel speed sensor and pickup
coil which, together with the toothed exciter gear, produces a
pulse train signal when the wheel rotates.
free lunch. It does this at the cost of an increase in average Fig. 3.7.1.2b—ECU-internal logic pulse streams for the raw WSS
signals shown above. Voltage-clipped logic pulse streams form an
stopping distance 共considered to be an acceptable trade-off
orderly input for electronic counters.
for sustaining steering path control兲.
that wheel. Conversely, if the electrical pulse rate on a spe-

3.7.2 Potential Failure Modes in an ABS cific wheel varies higher than the balance of the sensor-
System equipped wheels, the ECU may start to reduce brake applica-
tion to other wheels 共or in the case of a combined ABS/
Because the basis of ABS operation is the WSS signal inputs,
Traction Control ECU兲, actually apply braking to that high
it is obvious that an erroneous wheel speed signal can cause
pulse-rate wheel. This example analysis focuses on a method
an otherwise correctly functioning ABS ECU to invoke ABS
to determine the reliability of a wheel speed sensor signal
control functions that are undesired because they do not rep-
from an example data pulse train.
resent the physical reality of wheel operation.
The first step in this analysis is to characterize actual
For instance, if the electrical pulse rate on a specific
wheel operations by defining several geometric constants.
wheel varies lower than the balance of the sensor-equipped
These include, rolling radius, effective rolling wheel circum-
wheels, the ECU will start to reduce braking application on
ference, rotational speed 共e.g., r/s兲, and linear speed 共e.g.,
Fig. 3.7.1.2a—Typical WSS output signal for two different wheel Fig. 3.7.1.3—Illustration of a simplified global architecture of an
speeds. Note that frequency and amplitude of the coil voltage ABS air brake apply and feedback system, in which the ECU con-
output vary as a function of wheel rotation speed. Also shown is a troller monitors wheel rotational speeds via electromagnetic
typical clipping level, which, when implemented in the ECU re- wheel speed sensor 共WSS兲 inputs, and controls wheel brake fric-
ceiver circuits, produces a usable logic pulse train of constant am- tion surface apply via electrical solenoid isolate/dump/reapply
plitude and varying frequency. valves 共modulators兲 on the individual wheel circuits.
Fig. 3.7.3.1—Custom wheel exciter, driven by a 230 V 3 phase 5 hp Fig. 3.7.3.3—Standard brake test device used as an exciter, shown
synchronous motor using an adjustable frequency synchronous here on rf wheel. This exciter is synchronous, but only drives the
motor controller. This device provides a fully powered 共5 hp兲 and wheel at a single speed of approximately 1.2 mph.
synchronous regulated truck wheel speed range of 10– 40 mph.
tor exciter which allows one to vary the rotational speed,

mph兲. It is also helpful to define factors for rolling radius ver- and, because of electronic control, a constant rotational
sus measured radius and effective circumference versus speed at any desired speed 共frequency兲 setting. That provides
measured circumference. a good basis for WSS signal analysis.
An example of such a wheel exciter is shown in Fig.
3.7.3.1. This is a custom exciter, driven by a 230 V, 3 phase
3.7.3 Equipment and Instrumentation to 5 hp synchronous motor using an adjustable frequency syn-
Accomplish Heavy Duty Truck chronous motor controller. This arrangement provides a
Wheel Rotation Tests fully powered 共5 hp兲 and synchronous regulated truck wheel
speed range of 10– 40 mph. Figure 3.7.3.2 shows this exciter
While, in theory, wheel sensor tests can be accomplished us- in operation at approximately 20 mph.
ing a road test, it is virtually impossible for road tests to pro- A second example wheel exciter 共a standard brake test
duce a known and uniform wheel rotation speed. Thus, it is device兲 is shown in Fig. 3.7.3.3. This exciter is synchronous
preferable to use electronically controlled synchronous mo- but only drives the wheel at a single speed of approximately
1.25 mph.
WSS data can be reported in several ways. Figure 3.7.3.4
shows a standard heavy truck ABS diagnostic program re-
port of a left front wheel being excited at approximately
20 mph. Neither that report nor any other feature of that
program, AComm 2.11 关3.7.4兴, provides an examination of
detailed WSS electrical signal properties.
Fig. 3.7.3.2—Custom wheel exciter in operation. As a safety pre-

caution, the exciter friction wheel defaults to a disengaged posi-
tion, so it must be manually applied. In this photo, Fred Chandler
Jr. is manually applying the device to drive an 11R-22.5 bus wheel Fig. 3.7.3.4—A Comm 2.11 report panel showing left front LF at
at a constant synchronous-regulated speed of approximately approximately 20 mph 共reported to be 19.81 mph兲 and 0 mph
20 mph. speeds on the remaining wheels.
Fig. 3.7.3.5—Data acquisition oscillograph with the wheel rotation synch signal shown below the WSS analog signal. Data taken at
approximately 20 mph.
To perform an engineering check detailed WSS electri- accounts for the effects of rolling radius/circumference ver-
cal signals, one must monitor WSS analog signal pulse ana- sus measured radius/circumference, etc.
log waveforms and the precise pulse count per each wheel To illustrate a precise analysis of WSS electrical signal
rotation. To accomplish that, one can add a wheel rotation properties, let us examine an actual example analysis for
synch transducer and use that to synchronize WSS pulses WSS output at approximately 1.2 mph with the wheel driven
per each wheel revolution. Then, one can know the WSS by a standard brake test device used as a wheel exciter, just as
shown in Fig. 3.7.3.3.
count concurrent with each wheel rotation synch signal. Fig-
In this case we have a measured free-air circumference
ure 3.7.3.5 shows a data acquisition oscillograph with the
of 10.9 ft 共unloaded wheel兲 and a measured rolling radius of
wheel rotation synch signal and the WSS analog signal data
19.5 in. 共loaded wheel兲, which are entered into cell locations
for the same wheel shown in rotating in Fig. 3.7.3.2 and E11–M11 and E8–M8, respectively, of the spreadsheet in Fig.
shown reported in Fig. 3.7.3.4. 3.7.4.1. From these measurements we can derive the
unloaded-wheel and loaded-wheel circumferences.
Operating our wheel with the brake tester exciter and
monitoring the rotation with an optical data acquisition
3.7.4 Mechanics of the Analysis of WSS pickup, we are able to precisely measure the full rotation pe-
Data Collected from Wheel Rotation Tests riod to be 5.9575 s. One single WSS synch pulse versus re-
peating WSS waveforms is shown in the analog sampled
The first step in such an analysis is to create a table of wheel waveform of Fig. 3.7.4.2.
rotational and linear speeds versus physical and excitation Using this rotation period time, we can calculate
parameters. In our example case, that table is shown in the a. The wheel rotation per second/minute and seconds per
spreadsheet excerpt in Fig. 3.7.4.1. That table shows calcula- rotation period. These are shown respectively in cells
tions of effective wheel speeds versus exciter drive speed and E17, E18, and E19 in Fig. 3.7.4.1.
Fig. 3.7.4.1—Spreadsheet excerpt showing calculations of effective wheel speeds versus exciter drive speed, accounting for rolling radius/
circumference versus measured radius/circumference, etc. Note that all ASA exciter tests were done with wheel off ground, thus, true
wheel speed is derived with free radius/circumference. Brake tester tests were done with load on wheel, thus, true wheel speed is derived
from RR radius/circumference.
b. The free-wheel linear circumferential speed as 1.8296

fps in cell E27 using 共free-wheel兲 circumference of 10.9
ft 共cell E11兲 and cell E27 operators; QP: +E11/ E17.
c. The free-wheel linear circumferential speed as 1.2475
mph in cell E29 using 共free-wheel兲 circumference of
10.9 ft 共cell E11兲 and cell E29 operators: QP: +E27
⫻ 共E25/ E24兲. By way of illustration, the units conver-
sion accomplished in cell E29 共from fps to mph兲 is ac-
complished in the following equation:
ft 3600 s mile
mph = ⫻ ⫻
s h 5280 ft
d. The loaded-wheel linear circumferential speed as
1.1685 mph in cell E30 using 共loaded-wheel兲 circumfer-
ence of 10.2102 共cell E10兲 and cell E30 operators: QP:
+E29⫻ 共E8 / E13兲. This is simply a ratiometric conver-
sion in accordance with the ratios of the loaded/ Fig. 3.7.4.2—Sample WSS data output of left front wheel from
unloaded wheel radii. 0.0 to 1.0 s showing the threshold setpoints for WSS signal and
also showing the superimposed wheel synch signal.
Fig. 3.7.6.1—Constants Used and Data Column Headers. Note that we have monitored the rotation synch on A5 共Analog Channel 5兲 and the
WSS signal on A6. Channel A0 was used for a manual start of frame synch. With respect to signal thresholds: a. We declare our rotation
synch valid when the rotation synch signal rises through 0.100 V 关well above quiescent+ noise and below any peak, a typical method in
such electronics兴. b. We declaring our WSS signal electrically valid when the WSS signal rises through 0.050 V 关well above quiescent
+ noise, a typical method in such electronics兴. WSS pulses are typically detected using differential amplifiers which readily discriminate such
levels. c. We declaring our WSS signal logically valid when the WSS electrical signal is valid for four continuous samples 共thus eliminating
spurious noise counts, even if above the 0.050 V threshold兲. d. We declare any WSS pulse cumulative evaluation invalid if any elect signal
does not meet the ⬎0.050 V criteria for one sample time. In that case, any successive electrical evaluation must start with the first electrical
pulse ⬎0.050 V.
Note that in this test the correct linear circumferential derived wheel rotation speeds, we can calculate the expected
speed is 1.1685 mph 共cell E30兲 because we are examining the pulse rate 共pulses·s, positive peaks兲 and this is shown row 22,
WSS performance of a loaded wheel 共in a brake test device兲. columns E, F, G, H, I, J K, L, and M for the respective wheel
However, for the exercises using the custom wheel exciter, driven speeds.
we are examining the WSS performance of a free-air 共un-
3.7.5 Reviewing an Actual WSS Signal as
loaded兲 driven wheel and thus the free-wheel calculations
Sampled With a Data Acquisition
apply 共row 29, cells F29–M29兲.
System and Filtered Against Noise Level
Having completed our examination of the example in
Column E, we can then simulate the effective linear circum-
Thresholds
ferential speed for shorter rotation periods 共driven by our Now, understanding the mechanics of wheel rotation and ex-
custom wheel exciter兲. pected WSS pulse rate output, we are now ready to monitor
We can do this in a very controlled manner because, an actual WSS signal and see if the actual WSS output
with our synchronous exciter, the drive wheel rotation 共rpm兲 matches the design theoretical output.
is ratiometrically synchronized to its excitation frequency For this example, the WSS output was digitally sampled
共adjusted by the drive controller and set using a digital read- by an A/D converter and data acquisition system operating at
out window兲. After manual application, with the driven 1000 sample words/s. One side of the WSS was at sensor
wheel up to speed, there is no slip. So, in this manner, we can ground, and so the “high” side of the sensor produced a peri-
set the desired linear 共synchronous兲 speed by manually set- odic waveform appearing as a series of positive and negative
ting the controller drive frequency. voltage peaks at a time period proportional to the wheel rota-
In this manner, the test wheel speeds in 5-mph incre- tion. Another channel was used to capture the wheel rotation
ments 共shown in row 29兲 are achieved with the respective fre- synch marker signals,4 which were used to designate the
quency settings shown in row 38. starting and ending point of a rotation period on the same
We also know that there are 100 teeth on the exciter ring 4
The wheel rotation synch marker signals were generated by a photo transis-
and that is a mechanical constant. Thus, using our now- tor pickup of a reflected light beam from an on-wheel reflector, producing a
signal of approximately 0.4 V 共quiescent ambient兲 to 1.8 V 共peak reflection兲.
Fig. 3.7.6.2—Data and calculation column headers, the first rotation synch, and first valid positive WSS pulse count. Note that there is a
dropout in cell G77 共WSS⬍ 0.050 V兲 after a prior electrically valid signal in cell G76, and thus the required four continuous electrical sample
count starts again in cell G78. After the four electrically valid signals, the first WSS pulse after rotation synch is shown 共three rows later兲 in
cell I81. Also shown is the absolute time stamp of that first WSS pulse 共cell C81 and cell J81, 0.4573 s兲 and the angular position 共after
rotation synch兲 of that first declared WSS pulse 共1.752°, cell B81兲.
time line as the WSS pulses 共resolved to 1 ms for this ex- umn headers. These constants establish the basis for inter-
ample兲. pretation and/or time synchronization of the raw data. Note
that we have monitored the rotation synch on A5 共Analog
Channel 5兲 and the WSS signal on A6. Channel A0 was used
3.7.6 Defining Filtering, Immunity, and for a manual start of frame synch. With respect to signal
Averaging/Threshold Variables to Simulate thresholds:
WSS Signal Processing by an ABS ECU 1. We are declaring our rotation synch valid when the rota-
tion synch signal rises through 0.100 V 关well above
The recorded digital samples of the wheel synch and the quiescent+ noise and below any peak, a typical method
WSS analog signals were saved as a csv file and thus easily in such electronics兴.
imported into a spreadsheet for analysis. That spreadsheet, 2. We are declaring our WSS signal electrically valid when
as excerpted for one rotation period, is over 6,000 rows deep, the WSS signal rises through 0.050 V 关well above
and we shall be examining portions of that here. Figures quiescent+ noise, a typical method in such electronics兴.
3.7.6.1, 3.7.6.2, 3.7.6.3, 3.7.6.4, 3.7.6.5, 3.7.6.6, 3.7.6.7, and WSS pulses are typically detected using differential am-
3.7.6.8 show key pages 共beginning, constants/headers, dou- plifiers which readily discriminate such levels.
ble count example, and final count summaries兲 of that 3. We are declaring our WSS signal logically valid when
spreadsheet.5 the WSS electrical signal is valid for four continuous
Figure 3.7.6.1 shows the constants used and data col- samples 共thus eliminating spurious noise counts, even if
5
Note that there is one data word row per sample word, each sample word is
above the 0.050 V threshold兲.
recorded at millisecond intervals 共for this example兲 and the rotation period 4. We are declaring any WSS pulse cumulative evaluation
for this test is 5957.5 ms as shown in cell E17 of Fig. 3.7.4.1. invalid if any elect signal does not meet the ⬎0.050 V
Fig. 3.7.6.3—WSS signal pulse #2 declaration when the WSS voltage value stays over 0.050 V for four continuous samples 共thus eliminating
spurious noise counts兲. Also shown is the absolute time stamp of that signal, and the apportioned rotation angle 共starting at 0° at rotation
synch1兲.
criteria for one sample time. In that case, any successive count for two false pulses and then allowed a valid pulse.
logical pulse evaluation must start with the first electri- Also shown is the absolute time stamp of that signal and the
cal pulse ⬎0.050 V. apportioned rotation angle 共starting at 0° at rotation
Figure 3.7.6.2 shows the data and calculation column synch1兲.
headers, the first rotation synch, and the first valid positive Figure 3.7.6.5 shows the WSS Signal pulse declaration
WSS pulse count. Note that there is a dropout in cell G77 showing the first occurrence of a double count pulse, in spite
共WSS⬍ 0.050 V兲 after a prior electrically valid signal in cell of the four-consecutive pulse over 0.050 V criterion. Here,
G76 and thus the required four continuous electrical sample the false pulse detector was triggered 共cell K2248兲 and the
count starts again in cell G78. After the four electrically valid cumulative false pulse accumulator was incremented 共cell
signals, the first WSS pulse after rotation synch is shown L2248兲. Also shown is the absolute time stamp of that signal,
共three rows later兲 in cell I81. Also shown is the absolute time and the apportioned rotation angle 共starting at 0° at rotation
stamp of that first WSS pulse 共cell C81 and cell J81, 0.4573 s兲 synch1兲.
and the angular position 共after rotation synch兲 of that first Figure 3.7.6.6 shows the WSS signal pulse declaration
declared WSS pulse 共1.752°, cell B81兲. showing the second occurrence of a double count pulse, in
Figure 3.7.6.3 shows the WSS signal pulse #2 declara- spite of the four-consecutive pulse over 0.050 V criterion.
tion when the WSS voltage value stays over 0.050 V for four Here, the false pulse detector was triggered 共cell K2367兲 and
continuous samples 共thus eliminating spurious noise the cumulative false pulse accumulator was incremented
counts兲. Also shown is the absolute time stamp of that signal 共cell L2367兲. Also shown is the absolute time stamp of that
and the apportioned rotation angle 共starting at 0° at rotation signal, and the apportioned rotation angle 共starting at 0° at
synch1兲. rotation synch1兲.
Figure 3.7.6.4 shows the WSS signal pulse declaration Figure 3.7.6.7 shows the WSS signal pulse declaration
showing the value of the four-consecutive pulse over 0.050 V showing the twelfth occurrence of a double count pulse, in
criterion. Here, this discrimination method inhibited a spite of the four-consecutive pulse over 0.050 V criterion.
Fig. 3.7.6.4—WSS signal pulse declaration showing the value of the four-consecutive pulse over 0.050 V criterion. Here, this discrimination
method inhibited a count for two false pulses, and then allowed a valid pulse. Also shown is the absolute time stamp of that signal, and
the apportioned rotation angle 共starting at 0° at rotation synch1兲.
Here, the false pulse detector was triggered 共cell K6008兲 and 3.7.7.1.1 The data acquisition time stamp is shown in Col-
the cumulative false pulse accumulator was incremented umn C. It is entered from the csv data import. Note
共cell L6008兲. Also shown is the absolute time stamp of that that the time progresses in 1-ms steps.
signal, the apportioned rotation angle 共starting at 0° at rota- 3.7.7.1.2 The rotation synch signal voltage is shown in Col-
tion synch1兲, and the WheelSynch2 signal, declaring the end umn D. It is entered from the csv data import.
of that rotation cycle. 3.7.7.1.3 The WSS signal voltage is shown in Column E. It is
Figure 3.7.6.8 shows the WSS signal pulse summary entered from the csv data import. Note that this
showing the twelfth occurrence of a double count pulse, the value oscillates between a positive value and a
WheelSynch2 signal, declaring the end of that rotation cycle, negative value because we have grounded one side
of the sensor input.
and the cumulative totals of positive pulse counts in that
The remaining descriptions describe calculations based on
single wheel revolution.
that data.
3.7.7.2 Referring to Fig. 3.7.6.1, cells C13–C15, the wheel ro-
3.7.7 Illustrating the Calculation Processes to tation period is defined by the time difference be-
Implement Noise Immunity and tween the first and second rotation synch markers.
We are declaring our rotation synch valid when the
Averaging/Threshold Variables and to
rotation synch signal rises through 0.100 V. Figure
Detect Added or Missing WSS Pulses for the 3.7.6.2 shows that our “RotSynch1” marker is de-
Real Data Shown in Sec. 3.7.6 clared in cell D52 at 0.4283 s, and this time is copied
to cell C14. The “RotSynch2” marker is seen in Fig.
Referring to the data cells in Fig. set 3.7.6, there are three
3.7.6.8, Cell D6019, at 06.3858 s, and this time is cop-
data channels used: ied to cell C13. This gives us a rotation period of
Fig. 3.7.6.5—WSS signal pulse declaration showing the first occurrence of a double count pulse, in spite of the four-consecutive pulse over
0.050 V criterion. Here, the false pulse detector was triggered 共cell K2248兲 and the cumulative false pulse accumulator was incremented
共cell L2248兲. Also shown is the absolute time stamp of that signal, and the apportioned rotation angle 共starting at 0° at rotation synch1兲.
5.9575 s calculated as QP: +C13− C14 in cell C15. 3.7.7.4 Next, we wish to establish a baseline count of WSS
3.7.7.3 That corresponding time period defines the number positive peak signal values for each revolution. This
of data sample words in one complete revolution of is so we can verify that there are no missing WSS
360° 共row 52– 6,019= 5,957.5 s兲. We also know that tone ring teeth in the actual wheel hub. We know that
the wheel is turning at a constant speed because it is there are supposed to be 100 teeth by design.
being driven by a synchronous motor. We can now In order to count the positive peak signals, we have
linearly assign a proportional section of the 360° ro-
to generate them in Column F by creating a condi-
tation to each sample. That is done in Column B
tional operator for each cell in the F column where
from cell B52–B6019. Since our total rotation time is
known and constant, our physical rotation 共degrees兲 we determine if the WSS value in the current corre-
is proportional to the time spent achieving each suc- sponding E column cell is 共1兲 greater than the WSS
cessive time point. Thus, we know that for any time signal threshold, 共2兲 greater than the previous ten, 共3兲
interval, our cumulative physical position is the po- greater than following ten values in the WSS data
sition at the last sample plus the time-proportional stream. The following example conditional state-
segment of the total rotation. So, as an example, the ment is taken from cell F149 as seen in Fig. 3.7.6.3:
cumulative angular rotation at cell B53 is accom-
plished by the following operators: @IF共@AND共$E149⬎$C$24,$E149⬎⫽$E150,$E149
⬎⫽$E151,$E149⬎⫽$E152,$E149⬎⫽$E153,$E149
QP: + B52 + 共C53 − C52兲 ⫻ 共$C$26/$C$15兲 ⬎⫽$E154,$E149⬎⫽$E155,$E149⬎⫽$E156,$E149
As proof of this method, the cumulative rotation for ⬎⫽$E157,$E149⬎⫽$E158,$E149⬎⫽$E159,$E149
the entire revolution is shown in Fig. 3.7.6.8, cell ⬎$E148,$E149⬎$E144,$E149⬎$E143,$E149
B6019, to be 360.000° as the rotation synch crosses ⬎$E142,$E149⬎$E141,$E149⬎$E140,$E149
0.1 V 共RotSynch2兲. ⬎$E139,$E149⬎$E138兲,E149,“”兲
Fig. 3.7.6.6—WSS signal pulse declaration showing the second occurrence of a double count pulse, in spite of the four-consecutive pulse
over 0.050 V criterion. Here, the false pulse detector was triggered 共cell K2367兲 and the cumulative false pulse accumulator was incre-
mented 共cell L2367兲. Also shown is the absolute time stamp of that signal, and the apportioned rotation angle 共starting at 0° at rotation
synch1兲.
共start兲 in Column H. An example of this is taken from

As can be observed, that expression correctly dis- the first valid WSS pulse after RotSynch1, cell H81.
cerns the peak positive voltage value for WSS pulse The operators in cell H81 are
#2 as 0.2555 V.
3.7.7.5 We then wish to establish, and operate on, only those
WSS signals whose electrical magnitude exceeds QP: @IF共@AND共G78 ⬎ 0,G79 ⬎ 0,G80 ⬎ 0,G81
0.050 V 共for the positive pulse determination兲. Fig-
ure 3.7.6.2 共Column G兲 shows the result of this calcu- ⬎ 0兲,G81, “ − ” 兲
lation 共pulse threshold filtering兲. This is accom-
plished by the relative operator QP: @IF共E76
⬎ 共$G$37兲 , E76, “ − ” 兲 in every cell of the G column This is accomplished by the relative operators in ev-
between RotSynch1 共row 52兲 and RotSynch2 共row ery cell of the H column between RotSynch1 共row
6019兲. 52兲 and RotSynch2 共row 6019兲.
3.7.7.6 We then have to “debounce” the raw WSS electrical 3.7.7.7 We next have to declare the first WSS pulse start in
signals over our threshold 共0.050 V兲 in Column G so Column I. We only want to declare the start of a pulse
that we can be confident that we have a strong WSS because that entry 共logical “0” or “1”兲 will be used for
pulse. This is accomplished in Column H by check- a pulse count at the end of the wheel rotation period.
ing whether any then current cell in Column H meets This is relatively simple because if there is an entry in
the current, contiguous and successive electrical the corresponding H column cell we copy its value,
pulse over threshold criteria for the current and unless we have already entered a value for that pulse.
three preceding Column G cells. If our criteria are Again using our first pulse example, the first indicat-
satisfied, we can then declare a valid WSS pulse ing operator in cell I 81 is
Fig. 3.7.6.7—WSS signal pulse declaration showing the twelfth occurrence of a double count pulse, in spite of the four-consecutive pulse
over 0.050 V criterion. Here, the false pulse detector was triggered 共cell K6008兲 and the cumulative false pulse accumulator was incre-
mented 共cell L6008兲. Also shown is the absolute time stamp of that signal, the apportioned rotation angle 共starting at 0° at rotation
synch1兲, and the Rotation Synch 2 signal, declaring the end of that rotation cycle.
QP: @IF共@AND共H80 = “ − ” ,@AND共H81 ⬎ 0,H82 2. We declare our WSS signal logically valid when the
WSS electrical signal is valid for four continuous
⬎ 0 兲兲 ,H81, “ − ” 兲 samples 共thus eliminating spurious noise counts,
even if above the 0.050 V threshold兲.
This is accomplished by the relative operators in ev- 3. We declare any WSS pulse cumulative evaluation in-
ery cell of the H column between RotSynch1 共row valid if any elect signal does not meet the ⬎0.050 V
52兲 and RotSynch2 共row 6019兲. criteria for one sample time. In that case, any succes-
3.7.7.8 If there is an entry in Column I, the corresponding sive logical pulse evaluation must start with the first
timestamp is entered in Column J. This is accom- electrical pulse ⬎0.050 V.
plished with the following operator: We have shown how these operators work for a valid pulse;
now let us examine how they work for an invalid pulse. One
QP: @IF共I81 ⬎ 0,C81, “ − ” 兲 way we can determine if there was a double pulse is to exam-
ine the entries prior to the current declared WSS logical
This is accomplished by the relative operators in ev- pulse but within the pulse time. Following on with our ex-
ery cell of the H column between RotSynch1 共row ample, this is done in cell K81 using the operator:
52兲 and RotSynch2 共row 6019兲.
QP: @IF共@AND共I81 ⬎ 0,@SUM共I51 . I80兲 ⬎ 0兲,2 “ − ” 兲
3.7.7.9. So far, we have shown how these operators work for
a valid pulse. Recall that our criteria, from 3.7.6, Note that here we are examine the prior 30 entries for a prior
Fig. 3.7.6.1 above are: valid pulse count in the current WSS logical pulse period. In
1. We declare our WSS signal electrically valid when the the case of the first WSS logical pulse, there are no such en-
WSS signal rises through 0.050 V 共see 3.7.7.5 imme- tries. However, turning out attention to Fig. 3.7.6.5, we see
diately above兲. an entry “2” in cell K 2248, indicating that there was a double
Fig. 3.7.6.8—WSS signal pulse summary showing the twelfth occurrence of a double count pulse, the WheelSynch2 signal 共cell D6019兲,
indicating the end of that rotation cycle, and the cumulative totals of positive pulse counts in that single wheel revolution.
count in that WSS logical pulse period. This is, of course, In this case, and for the criteria used, the operators
confirmed by examining the data in the G and H columns, defined above 共in our spreadsheet template兲 iden-
which show intuitively that there was a WSS electrical signal tify 12 extra pulses in one wheel revolution. These
dropout in cell G2244 共caused by an electrical level lower may or may not be discernable from relatively
than 0.050 V兲, and that restarted the pulse count process, re- qualitative data such as presented in Fig. 3.7.3.4,
sulting in two WSS logical counts for that pulse period. This but they are quantitatively identified using this
double pulse detection is accomplished by the relative op- technique.
erators in every cell of the K column between RotSynch1 3.7.7.12 One of the criteria for a valid engineering finding is
共row 52兲 and RotSynch2 共row 6019兲. the repeatability of the result. For that reason we
3.7.7.10 Lastly, we have to accumulate the double pulse compared three analyses such as the one above to
counts so, at the end, we know where we stand. This see if there were consistent results. We checked for
is done in Column L using the operator: consistent results in a more intuitive manner.
Knowing the rotational 共azimuth兲 angle at which
QP: @IF共K2248 ⬎ 0,L2247 + 1,L2247兲 the double pulses were detected, we plotted them
on a polar axis to check for angular 共azimuth兲 re-
共shown for cell L 2248兲 peatability. And, we found that Fig. 3.7.7.12 shows a
polar plot of the double pulse counts detected in
This double pulse count accumulation is accom- three separate data runs 共Runs A, B, and C兲 for the
plished by the relative operators in every cell of the identical physical RotSynch1 and RotSynch2.
L column between RotSynch1 共row 52兲 and Figure 3.7.7.12 shows a reasonable consistency of
RotSynch2 共row 6019兲. double counts from 125° to 240° azimuth. This
3.7.7.11 Recall that our assignment here was to identify if gives some direction as to where an exciter ring
there was any data anomaly in the presented data. runout or other rotational irregularity may be.
3.7.7.13 Now that we have completed our identification of 3.7.8 Operator Equivalence: Quattro Pro
the positive pulses for each cycle in Columns F–L, versus Excel
we can duplicate the analysis to identify the nega-
tive pulses. For the reader’s reference, the following table provides a
summary ofequivalent Excel® spreadsheet operators for the
same Quattro Pro® examples we have discussed.
Cell ref Quattro Pro® Excel®

B53 ‘⫹B52⫹共C53⫺C52兲*共$C$26/$C$15兲 ‘⫽B52⫹共C53⫺C52兲*共$C$26/$C$15兲
F149 ‘@IF共@AND共$E149⬎$C$24,$E149⬎⫽$E150, ‘⫽IF共AND共$E149⬎$C$24,$E149⬎⫽$150,$E
$E149⬎⫽$E151,$E149⬎⫽$E152,$E149⬎ 149⬎⫽$E151,$E149⬎⫽$E152,$E149⬎⫽$E153,
⫽$E153,$E149⬎⫽$E154,$E149⬎⫽$E155,$ $E149⬎⫽$E154,$E149⬎⫽$E155,$E149⬎⫽$E
E149⬎⫽$E156,$E149⬎⫽$E157,$E149⬎⫽$E 156,$E149⬎⫽$E157,$E149⬎⫽$E158,$E149⬎⫽
158,$E149⬎⫽$E159,$E149⬎$E148,$E149⬎ $E159,$E149⬎$E148,$E149⬎$E147,$E149⬎
$E147,$E149⬎$E146,$E149⬎$E145,$E149 $E146,$E149⬎$E145,$E149⬎$E144,$E149⬎
⬎$E144,$E149⬎$E143,$E149⬎$E142,$E149 $E143,$E149⬎$E142,$E149⬎$E141,$E149⬎
⬎$E141,$E149⬎$E140,$E149⬎$E139,$E149 $E140,$E149⬎$E139,$E149⬎$E138兲,E149,“ ”兲
⬎$E138兲,E149,“ ”兲
G68 ‘@IF共E76⬎共$G$37兲,E76,“⫺”兲 ‘⫽IF共E76⬎共$G$37兲,E76,“⫺”兲
H81 ‘@IF共@AND共G78⬎0,G79⬎0,G80⬎0,G81⬎ ‘⫽IF共AND共G78⬎0,G79⬎0,G80⬎0,G81⬎0兲,G81,
0兲,G81,“⫺”兲 “⫺”兲
I81 ‘@IF共@AND共H80⫽“⫺”, ‘⫽IF共AND共H80⫽“⫺”,
@AND共H81⬎0,H82⬎0兲兲,H81,“⫺”兲 AND共H81⬎0,H82⬎0兲兲,H81,“⫺”兲
J81 ‘@IF共I81⬎0,C81,“⫺”兲 ‘⫽IF共I81⬎0,C81,“⫺”兲
K81 ‘@IF共@AND共I81⬎0,@SUM共I51..I80兲⬎0兲,2 ‘⫽IF共AND共I81⬎0,SUM共I51:I80兲⬎0兲,2,“⫺”兲
,“⫺”兲
L2248 ‘@IF共K2248⬎0,L2247⫹1,L2247兲 ‘⫽IF共2248⬎0,L2247⫹1,L2247兲
Fig. 3.7.7.12—Showing a polar plot of the double pulse counts detected in three separate data runs 共Runs A, B, and C兲 for the identical
physical RotSynch1 and RotSynch2. A very consistent set of double counts exist in the 125°–240° azimuth 共from the physically fixed
RotSynch1 and RotSysch2兲. This gives some direction as to where an exciter ring runout or other rotational irregularity may be.
References Brakes, ABS and Beyond,” SAE International, SP-1406,

November 1998.
关3.7.1兴 Carley, L., Antilock Brakes, 2006, URL: http://www.aa1car. 关3.7.3兴 Allied Signal, Bendix Air Brake Handbook, September 1996.
com/library/abs1.htm. 关3.7.4兴 Bendix Corp., Commercial Vehicle Systems, ACom Diagnos-
关3.7.2兴 Buckman, L., “Commercial Vehicle Braking Systems, Air tics Users Guide, April 2003.
3.8 Using Hardcopy Crash Test Data to corded as an analog acceleration trace of 240-ms duration,
Characterize Specific EDR Performance with units of gs from each of the on-board accelerometers.
versus EDR Family Performance The crash test data hard copy acceleration curve is reported
on an X axis time scale marked in 4-ms intervals and a Y axis
ACCIDENT INVESTIGATION INVOLVES THE USE OF gs scale marked in 1g intervals. By contrast, in typical EDRs
data from a variety of sources. While digital electronic media we see sampling rate times resolved to 0.25– 1.0 ms and ac-
data sources are desirable, not all data are available in elec- celeration data resolved to 0.25– 0.5g.
tronic media. Sometimes data are only available in hard Resolution of the superimposed unit grid needs to be
copy form such as accident reconstruction reports, crash high enough to produce a continuous curve similar to the
test data, original equipment manufacturer 共OEM兲 specifi- original data. In this case, the digitized grid was selected to
cations, and component supplier specifications. This ex- produce a resolution of 0.1g at 1-ms intervals.
ample shows one method of utilizing crash test hard copy ac- The base grid is created in a spreadsheet notebook such
celeration data 共air bag must-deploy threshold tests1兲 that as Corel QuattroPro® or Microsoft Excel® with two fields
were tabulated and integrated to generate comparative ac- time and acceleration containing 0 values, transformed to a
celeration signatures and comparative Delta V profiles in or- spreadsheet graph, and then exported as a bitmap image.
der to determine whether the acceleration signature and The unit grid image file can then be scaled in a graphics ap-
Delta V profiles in a subject vehicle were above or below the plication such as Adobe Photoshop® to exactly line up with
performance for the crash test exemplars. This allowed a the scanned acceleration data axes and superimosed on top
quantitative comparison of the performance of the subject of the data image.
system 共and the subject crash pulse兲 versus the system 共and
crash pulse performance兲 of the crash test exemplars.
3.8.3 Spreadsheet Data Quantization and
3.8.1 The Analysis Problem Formatting
Crash test data in an EDR MCU is universally detected as a Numerical values digitized from the crash test acceleration
series of acceleration values versus time.2 When presented curves are entered into a spreadsheet, creating a separate
on a time line, these values can be connected by a trace and notebook page for each 240-ms crash test record.
curve. Accelerometer traces are typically presented as hard Figure 3.8.3.1 shows a spreadsheet field created for
copy in crash test reports. For example, Fig. 3.8.1 shows one sample time in ms 共Column G in the spreadsheet兲 by enter-
such sample crash test acceleration curve from the original ing the first value “1” in cell location G19. The spreadsheet
hard copy format. operator QP: +G19+ I is entered into cell location G20, pro-
In order to utilize that data in a comparative analysis, it
ducing the second sample time “2.” The operator in cell loca-
is necessary to have a digital time series representation of
tion G20 can then be copy-pasted down the column, quickly
that data. This is normally available from the crash test data
producing all 240 sample time values. A second spreadsheet
acquisition system; however, when it is not available, a hard
field is created for the digitized numeric values of accelera-
copy of that data trace can be used for that same purpose,
tion in gs 共the H column兲.
albeit with some extra work.
With the first 80-ms segment scanned acceleration
The first step in that extra work is the requirement to
curve with superimposed unit grid open in the graphics ap-
digitize the hard copy acceleration curves into a series of nu-
plication at a high zoom factor, numerical values can be ac-
meric acceleration values in order to then compare those test
curately determined to one-tenth of one unit block 共g兲 and
crash acceleration data to the acceleration data of interest.
entered into the spreadsheet for each 1-ms time sample.
Now that we have optimized our technique for the first
3.8.2 Digitization of Hard Copy Data 80-ms data segment, we can then build upon the digitized ac-
celeration record by continuing data entry of numeric accel-
The digitization process is started by generating a ratiomet- eration values appended to the same spreadsheet columns
ric digitization grid for each of the appropriate crash test for the second data segment 81– 160 ms and finally for the
traces, with the superimposed X and Y unit grid adjusted to third data segment 161– 240 ms by repeating the process of
match the axes on the original data 共stretched and/or shrunk superposing each scaled ratiometric digitization grid over
as needed along the X and Y axes兲. Figure 3.8.2 is an example its corresponding scanned hard copy acceleration curve.
of a digitization unit grid that was prepared to superimpose Once we have a complete digitized replica of the crash
over one of our exemplar crash tests. test acceleration versus time curve, we can then use the digi-
Next, using a flatbed scanner, the acceleration curve tized acceleration record to generate an acceleration signa-
pixel information was captured for each crash test in three ture curve using spreadsheet graphing functions. An initial
80-ms segments to keep scanned image file size manageable. verification of the potential usefulness of this digitization
We know from the original data that crash test data are re-
1
Nonconfidential or protected data available in hard copy format.
2
And those sample values may, or may not be, saved to non volatile memory at the end of an event.
methodology can be accomplished by visually comparing

the digitized spreadsheet-generated acceleration graph rep-
resented here by Fig. 3.8.3.2 with the original hard copy
curve, Fig. 3.8.1.
The spreadsheet can then be used to derive other useful
metrics from our digitized acceleration record. In Section
3.8.4 we will use derived cumulative velocity loss Delta V to
verify the accuracy of our digitization method.
To derive Delta V in the spreadsheet, we start with accel-
eration in units of gs and corresponding time samples in ms
in two of our spreadsheet fields similar to that of Fig. 3.8.3.1,
which shows time in the G column and acceleration in the H
column. We then calculate the cumulative velocity loss using
spreadsheet operations in four additional fields: accelera-
tion in ft/ s2 共Column I兲, incremental velocity loss per time
sample in ft/s 共Column J兲, cumulative velocity loss in ft/s
共Column K兲, and cumulative velocity loss in mph 共Column
Fig. 3.8.1—A sample of the raw data acceleration signature for a L兲. See Section 3.2 for a thorough discussion of acceleration
crash test 共air bag must-deploy threshold test兲 in its original hard- reporting and the Delta V mathematical formulas.
copy format shows the first 80 ms segment of recorded accelera- Referring to Fig. 3.8.3.1: To convert the first acceleration
tion in Gs for Test# T-BC0480, CRTS 12022, 90° front fixed barrier value in gs to units of ft/ s2, the following function is entered
crash, 14.1-mph BEV.
into cell location I19, QP: +H19*$C$7, where cell location C7
contains the value of the gravity acceleration constant
32.174 共ft/ s2兲.
Fig. 3.8.2—A ratiometric digitization grid was prepared for the first 80-ms data segment in sample Crash Test# C0480. The digitization grid
is calibrated to exactly match the X and Y axes and observed scaling of the crash test hard copy. We will then superimpose our unit grid
over the hard copy acceleration curve in order to translate the graphical data into numeric values.
Fig. 3.8.3.1—A spreadsheet application was used to capture and format digitized acceleration with corresponding sample time entries
共Columns G and H兲 from Crash Test # T-C1425 hard copy. Numerical values were determined to 0.1g and 0.001 s resolution from the
acceleration curve using our superimposed digitization grid. Cumulative velocity loss and other useful metrics were then derived for the
digitized acceleration record using spreadsheet operations 共Columns I, J, K, and L兲 to allow for quantitative comparison of crash test
performance versus the vehicle under investigation.
To define incremental velocity loss in ft/s in the first data 3.8.4 Validation of Acceleration Digitization
row, the following function is entered into cell location J19, Capability Using Delta V Analysis
QP: +I19*$C$11, where cell location C11 contains the value
of the time sample 0.001 共s兲. The next task is to verify that the digitization method is ad-
To define incremental velocity loss in ft/s in the first data equately accurate, repeatable and reliable to evaluate perfor-
row, the following function is entered into cell location K19, mance of a subject system. To accomplish this, we can use a
QP: +K18+ J19. comparative evaluation Delta V 共cumulative velocity loss ob-
To define the cumulative velocity loss in mph in the first tained by a time integration of the acceleration data curve兲
data row, the following function is entered into cell location derived by our analysis, and derived by an independent
L19, QP: +K19*$C$9 / $C$10, where cell location C9 contains means.
the time conversion constant 3,600 共s / h兲 and where cell lo- This kind of validation exercise can be achieved by per-
cation C10 contains the distance conversion constant forming the identical digitization process for an example
5,280 共ft/ mile兲. with a known translation output. One approach to this is to
To derive cumulative velocity loss in mph for all accel- take the manufacturer-certified translation output from a
eration values, the spreadsheet formulas in cell locations Vetronix Crash Data Retrieval® 共CDR兲 translation and com-
I19, J19, K19, and L19 are copy-pasted throughout the I, J, K, pare it to the product of the digitization exercise reported
and L columns to complete the data set. above.
Fig. 3.8.3.2—We can gain confidence regarding our digitization methodology by observing the comparable acceleration signature for our
digitized interpreted data versus the original hard copy crash test curve shown in Fig. 3.8.1. Our digitized crash test acceleration values
were obtained by superimposing a unit grid over the hard copy acceleration curve, formatting into a spreadsheet and then graphically
interpreted here for sample Crash Test # T-C0480
Fig. 3.8.4—The ultimate test of a digitization method is a comparison of cumulative velocity loss 共Delta V兲 as determined from three
independent sources. This figure shows the digitization method described herein to have sufficient accuracy, repeatability, and reliability
for engineering analysis.
Fig. 3.8.5.1—Evaluation of cumulative velocity loss curves for nine OEM must-deploy crash tests versus the Subject Vehicle cumulative
velocity loss curves 共derived via CDR兲 in order to determine whether Delta V in the subject vehicle was above or below the performance of
the crash test exemplar must-deploy thresholds.
Fig. 3.8.5.2—Table of key test crash data. Note that the TTF data allows a quantitative determination of the Delta V at deploy command,
and this can be compared to the Delta V for the unit of interest 共subject unit兲 as discussed above.
Fig. 3.8.5.3—Evaluation of cumulative velocity loss curves for nine OEM must-deploy crash tests versus the Subject Vehicle cumulative
velocity loss curves 共derived via CDR兲 in order to determine whether Delta V in the subject vehicle was above or below the performance of
the crash test exemplar must-deploy thresholds. Note that the subject vehicle was a non deploy case, and that several comparative crash
test vehicles showed deployments at equal or lower time magnitudes than the subject vehicle.
An example of this is shown in Fig. 3.8.4. 3.8.5 Derived Metrics and Data
The first step in this process is to interrogate an exem- Interpretation for Evaluating a Subject
plar EDR with a CDR and observe the hard copy acceleration System
curve and table-list acceleration values produced with the
CDR report. After the digitization methodology has been validated, we
The second step is to scan and capture the derived inte- can now proceed with confidence to develop metrics from
grated Delta V data from the hard copy report. crash test hard copies and apply those results to the subject
The third step is to integrate the table-list acceleration accident. Additional metrics can be derived from the crash
values and independently derive the integrated Delta V test data to comparatively evaluate air bag performance in
based on the CDR acceleration record. the subject vehicle with respect to OEM specifications. Fig-
The fourth step is to digitize the hard copy acceleration ure 3.8.5.1 shows a 115-ms duration graphical overlay of
curve in the manner identified above and integrate that data Delta V data from nine must-deploy crash tests, for a similar
to produce acceleration values and a Delta V curve using our vehicle, produced by the vehicle manufacturer. Overlayed on
digitization method.
those traces is the Delta V trace for the vehicle under analy-
Figure 3.8.4 shows an overlay of the Delta V curves pro-
sis.
duced by all three methods. This verifies the accuracy, re-
Figure 3.8.5.2 shows tabulation of data for additional
peatability, and reproducibility of the digitization methodol-
metrics derived from the nine crash tests for evaluation of
ogy.
the subject vehicle. These metrics include time to fire 共TTF兲 the digitization methodology is first proven as it was here.
for the test crashes. The following are Excel® equivalents for the Quatro-
Figure 3.8.5.3 shows a 50-ms duration graphical inter- Pro® formulations shown in the discussion above.
pretation of Delta V data from the same nine must-deploy
crash tests, for a similar vehicle, produced by the vehicle Figure Cell
manufacturer. Overlayed on those traces is the Delta V trace ref ref Quattro Pro® Excel®
for the vehicle under analysis. 3.8.3.1 B10 ‘+G19+ 1 ‘=G19+ 1
Now observing the TTF timing range for the test crashes 3.8.3.1 I19 ‘+H19 * $C$7 ‘=H19 * C7
and observing the cumulative Delta V magnitudes of the test
3.8.3.1 J19 ‘+I19 * $C$11 ‘=I19 * C11
crashes versus the vehicle under analysis, we can quantita-
tively compare the response of the vehicle under analysis to 3.8.3.1 K19 ‘+K18+ J19 ‘=K18+ J19
the test crashes provided. 3.8.3.1 L19 ‘+K19 * $C$9 / $C$10 ‘=K19 * C9 / C10
This kind of comparison could only be effectively de-
fended when the accuracy, repeatability, and reliability of
MON05-EB/Sep. 2009
4
EDR Data Considerations with/respect/to
Evidentiary Reliability and Interrogation
Procedures
THE PRINCIPLES AND METHODS DISCUSSED IN web site release which says that EDR data were first in-
Chapters 2 and 3 are good engineering science, but they are cluded in the 2001 model year 关4.6兴.
only of academic value unless they can be applied for a busi- 6. Examples of Toyota EDR data for 2004 Camry, Solara,
ness purpose. Analysis and improvement of system designs and Sienna vehicles are given in Evaluation of Event
is one such purpose. Another purpose may be to conduct a Data Recorders in Full Systems Crash Tests, Niehoff et al.
safety systems performance analysis for purposes of litiga- 关4.7兴.
tion issues. A third purpose may be to document vehicle con- 7. Examples of Toyota EDR data for 2004 Camry, 2003
ditions at the time of a an AE1 event 共such as when the ve- Lexus ES300, and 2005 Corolla vehicles have been
hicle under examination has struck another vehicle2兲. achieved by ASA 关4.8兴.
There are several references to the parameter content of
8. Examples of Hyundai EDR data for the 2004 Elantra
passenger vehicle EDRs and the reliability of such data and
have been achieved by ASA 关4.9兴.
the availability of such data.
9. Ford EDR data retrieval strategy is documented in Cur-
1. NHTSA has published a Final Rule response to various
rent Ford Event Data Recorders, Wheelock, Robert J.
petitions 关4.1兴. This reference gives a global overview of
共Bob兲关4.10兴. However, this does not include 2002–2005
EDR content for those manufacturers who choose to in-
clude EDRs on their vehicles. Additionally, a discussion Ford Explorer EDR data.
of EDR policies by manufacturer is found in Kowalick, 10. Examples of 2002-2005 Ford Explorer EDR data 共non-
Fatal Exit, The Automotive Black Box Debate 关4.2兴. CDR-covered vehicles兲 have been achieved by ASA
2. With respect to EDR data retrieval, a list of the vehicles 关4.11兴.
covered by the most common EDR data retrieval tool, 11. A discussion of the pitfalls and considerations involved
the Bosch CDR® is available at http://www.cdr-system. with acquiring and using EDR data is contained in a
com/coverage/index.html 关4.3兴. Vehicles included in Trial Magazine article, How to Challenge Black Box Data,
CDR coverage are most post-1990 G.M. 共and G.M. S.I.R. Van Gaasbeck 关4.12兴 and in certain correspondence, L.
based兲 vehicles, selected post-2000 Ford vehicles and se- Russell to S. Van Gaasbeck 关4.13兴.
lected post-2004 Chrysler vehicles. However, certain ad- 12. A wide ranging discussion of the use of EDR data for
ditional vehicles 共i.e., non-CDR-covered vehicles兲 also highway crash data analysis is given in a 2004 report en-
have EDR data content. Some references to vehicles titled Use of Event Data Recorder 共EDR兲 Technology for
with and without EDR information are shown below. Highway Crash Data Analysis, Gabler et al. 关4.14兴. This
3. As identified in Auto Week 关4.4兴, Nissan has disclosed report also identifies the data content of then-current
the inclusion of a Vehicle Status Data Recorder 共VSDR兲 G.M. and Ford EDR devices.
on at least one of its latest higher end models.
4. Certain Volvo vehicles contain EDR information includ- Whatever the purpose of the investigation, in most in-
ing, seatbelt buckle status, accelerator and/or the brake vestigations, and especially in litigation issues, the investiga-
status, vehicle speed, and steering status. However, to
tor is often tested as to his/her methods and their reliability,
access Volvo EDR information, special 共proprietary兲
repeatability, error rates, and usage/acceptance by industry
equipment must be used in a direct harness connector
peers. Below is a discussion of some considerations regard-
umbilical mode. No commercial equipment is known to
ing those tests and methods to assure that one can pass those
access Volvo EDR modules 关4.5兴.
5. The Toyota EDR data content plan is listed in an official tests.
1
AE is an acronym 共Algorithm Enable兲 which is variously called algorithm wakeup or G-trigger. An “event” does not necessarily mean that the airbags deployed. It
means that the vehicle experienced a velocity change causing an acceleration so that the on-board EDR deployment algorithm calculation process was enabled
共AE兲 and thus recorded certain vehicle operating parameters. For instance, in a rollover event, one may wish to know vehicle speed, brake status, throttle status,
etc. In other cases, even with non-deploy events, certain PCM event recorders keep a continuous multi-parameter record in a circular buffer—which must be read
in a special fashion to avoid overwriting.
2
In such cases, the striking vehicle is often called the bullet vehicle and the impacted vehicle is often called the target vehicle.
90
CHAPTER 4 䊏 EDR DATA CONSIDERATIONS 91
conditions at the time it was recorded. Thus if a later interro-

gation process alters or erases data it is unacceptable, or if
the data are shown to be inaccurate or corrupted, it is not
generally usable.
In the litigation realm, a forensically neutral data re-
trieval process incorporates a method and a protocol to re-
trieve EDR data with the highest assurance of not changing
or disturbing that data, either by erasure or overwriting.
With an in-vehicle installed EDR, a forensically neutral
interrogation process is generally achieved by interrogating
an ECU connected to its normal vehicle circuits.
With an EDR out of its installed vehicle condition, a fo-
rensically neutral interrogation can be accomplished with a
load box/interface/test-bed containing proper electrical
loads and interfaces, or by using an exemplar vehicle as a test
bed or via a direct EEPROM read.
Generally, to be forensically neutral, an out of vehicle
data retrieval fixture 共load box or data interface兲 must in-
clude provisions for actuator 共squib, solenoid, etc.兲 dummy
loads, sensor detection loads, MIL loads,3 serial feedback or
for seatbelt switch status, so that any ECU undergoing such
test-via-umbilical-interrogation will see only a correct oper-
ating environment during power-on and continuous loop
checks 共just as it would in a vehicle兲.4
In certain cases, where some partial data may be
changed by the power on and/or interrogation process, such
data changes should be identified before the interrogation
process starts. Certain data changes may be acceptable if
they do not change the data of interest, and all parties agree
to that in advance.5
ASTM E2493-07, “Standard Guide for the Collection of
Non-Volatile Memory Data in Evidentiary Vehicle Elec-
tronic Control Units” is a summary of such a procedure
关4.15兴.
Fig. 4.2.1—Load boxes from two domestic manufacturers as used
to interrogate EDRs in a forensically neutral bench top mode.
Several examples help illustrate the point.
Figure 4.2.1 shows load boxes from two domestic manu-
facturers as used to interrogate EDRs in a forensically neu-
4.1 The Role of Event Data and Data tral bench top mode.
Translations Figure 4.2.2 shows a nonmanufacturer test fixture as
used to interrogate an EDR in a forensically neutral bench
Event data and data translations can be an important part of top mode. Figure 4.2.3 shows a time sequence of operation
system development and functional performance investiga- where the MIL is ON for power on bulb test and then OFF
tions. In such a role these data can be used to: during continuous run operations 共including interrogation
1. Identify safety systems performance for a given crash procedures兲. Since this is normal vehicle operation, a dem-
event 共deploy timing, deploy/nondeploy decisions, seat- onstration such as this, with appropriate other ECUs having
belt usage, occupant position, etc.兲. known DTCs, can be used to confirm the veracity of a proper
2. Identify vehicle parameters existing at a crash event forensically neutral test fixture.
共speed, brake status, accelerator status, engine status,
Figure 4.2.4.a shows two parameters as reported by the
steer angle, trigger data, etc.兲.
EDR under test to a commercial scanner 共Driver and Passen-
3. Identify EDR parameters with respect to accident sta-
tions 关for multistation accident events兴共pre-event data, 3
MIL= Malfunction Indicator Lamp, a generic term for visual system failure
postevent data, trigger data, etc.兲. indicator. Specific MIL’s can be called “Airbag Lamp,” “Engine Lamp,” “ABS
4. Identify pre-existing conditions for a given accident Lamp,” etc.
4
event 共DTCs, DPIDs, etc.兲. The situation can get yet more complicated when modern anti-theft mea-
sures are incorporated into the ECU. In such cases, the ECU non volatile
5. Confirm/corroborate other-expert analyses 共reconstruc-
data save all or part of the VIN, and specific manufacturer security proce-
tion, biomechanics, occupant kinematics, etc.兲. dures must be considered.
5
Certain data changes are unavoidable, e.g., incrementing an ignition cycle
4.2 Veracity Requisites for EDR Data counter because of power on. Certain data changes may be avoidable only at
Retrieval great effort or expense, e.g., providing a data bus driven MIL simulator. So,
if the MIL condition is not of interest, and the MIL error condition is identi-
A key requisite for the use and value of event data and data fied prior to interrogation, such an interrogation generated error may be ac-
translations is that such data accurately represent the actual ceptable.
A converse example showing forensic non-neutrality is

shown in multipart Fig. 4.2.5. In these examples, a com-
monly used commercial interrogating tool 共CDR®兲 is not fo-
rensically neutral when used in a direct umbilical mode to
interrogate the SRS ECU 共i.e., a direct connection to the SRS
ECU兲. In that mode, certain external fault codes will be
added 共or redetected兲 because there is no provision for
proper dummy-load resistors in the tool cabling. Depending
on the data lock status of an event record, this may be an im-
portant consideration.
4.3 Rules for the Application of EDR

Enginering Data in Litigation
In litigation, an engineering opinion or conclusion, stated
with reasonable engineering certainty, must meet certain
Fig. 4.2.2—A non-manufacturer test fixture as used to interrogate
an EDR in a forensically neutral bench top mode. clear tests. These tests are summarized below, but a more
complete discussion of these tests, and various judicial per-
ceptions and interpretations are found in Refs. 关4.17–4.21兴.
ger Squib Resistances兲 and Fig. 4.2.4.b shows the two 2.0 ⍀ 1. It must be founded on an underlying methodology of
resistors used to simulate the Driver and Passenger Squib scientific tests, and documentation of test results 共charts,
Resistances.6 Resistor values are read using guides such as graphs, etc.兲, which are reliable, as shown by publication of
Resistor Color Codes 关4.16兴. Thus, since the EDR is reporting test methods and/or other by peer acceptance of test meth-
the values to be 2.0 ⍀ 共2.0 ⍀, Fig. 4.2.4.a兲, and the load resis- ods.
tor values can be visually determined to be 2 ⍀ ± 5 % 共Fig. 2. It must be repeatable by any peer scientist/engineer
4.2.4.b兲, we know in this case that the EDR under test is cor- using the conditions and/or data recorded in the subject
rectly reporting electrical reality. tests. That is, allow other investigators to repeat the subject
A demonstration such as this, with appropriate varia- tests on the same ECU and derive the same test results.
tions or multiple calibration points, can be used to confirm 3. It must have a reasonable error rate and that error
the reliability of a proper forensically neutral test fixture. rate must be accepted by other practitioners in that field of
engineering testing and inquiry.
6
Note that although the figures in this book are monochrome, the reader is 4. It must be consistent with industry or commonly ac-
assured that the four color bands from the end toward the middle 共right to
left in this case兲 are RED, BLACK, GOLD, GOLD. These are interpreted as: cepted standards that define or direct the tests and results
RED 共1st digit, value= 2兲, BLACK 共2nd digit, value= 0兲, GOLD 共3rd digit, postulated.
decimal multiplier, # 0s, except when a tolerance color 共e.g., gold兲, meaning 5. It must pass a test of relevance and linkage to the facts
preceding values are divided by 10兲, GOLD 共4th digit, tolerance, gold= 5 %,
silver= 10 %兲. Thus the value for the two resistors marked with RED, at issue in the subject litigation.
BLACK, GOLD, GOLD bands, is 2.0 ohms 共2.0 ⍀兲 with a 5 % tolerance.
Fig. 4.2.3—A time sequence of operation for the non-manufacturer test fixture where the MIL is ON for power on bulb test and then OFF
during continuous run operations 共including interrogation procedures兲.
4.4 Protocols, Procedures, and Practices used

in Interrogating EDR Data where
Proprietary Data and/or Retrieval Methods
are Involved
Where several parties have an interest in the data retrieved
from an EDR, it is generally a wise idea to document the
steps and equipment to be used for data retrieval in a written
protocol for that data retrieval. Such a protocol generally
specifies the test bed, the interrogation hardware and soft-
ware, and the distribution of the retrieved data.
Examples of the terms to be included is this type of pro-
tocol include:
1. A description of the test bed/load box 共if not in the origi-
nal vehicle兲.
2. A description of the interrogation hardware and soft-
ware to be used to interrogate the ECU and retrieve the
data.
3. A demonstration of the test bed/load box and the inter-
rogation hardware/software as used on a known exem-
plar ECU.7 This presubject-test proof of the data interro-
gation process is often called a baseline because it shows
the operation of the hardware and software in a known
normal and forensically neutral mode.
Fig. 4.2.4—Two parameters as reported by the EDR under test to a 4. Identification of the data to be shared as a result of the
commercial scanner 共Driver and Passenger Squib Resistances兲. The data retrieval. Such data can include:
two 2.0 ohm resistors used to simulate the Driver and Passenger 共1兲 Photodocumentation of data on scan tools or lap-
squib resistances for the readings shown in Figure ???. Note that tops.
although the figures in this book are monochrome, the reader is 共2兲 Hardcopies of raw data.
assured that the four color bands from the end towards the
共3兲 Computer files of such data.
middle 共right to left in this case兲 are RED, BLACK, GOLD, GOLD.
These are interpreted as: RED 共1st digit, value= 2兲, BLACK 共2nd 共4兲 Video documentation of data collection.
digit, value= 0兲, GOLD 共3rd digit, decimal multiplier, # 0s, except 5. Identification of the translations/interpretations of the
when a tolerance color 兵e.g., gold其, meaning preceding values are retrieved data. Considerations here can include:
divided by 10兲, GOLD 共4th digit, tolerance, gold= 5 %, silver 共1兲 Raw data 共hexadecimal formatted data兲.
= 10 %兲. Thus the value for the two resistors marked with RED, 共2兲 Data translations/interpretations created by com-
BLACK, GOLD, GOLD bands, is 2.0 ohms 共2.0 Ω兲 with a 5 % mercial tools.
tolerance.
7
An exemplar is an example ECU having the same design and functional re-
sponse as the subject ECU.
Fig. 4.2.5—In these examples, a commonly used commercial interrogating tool 共Vetronix CDR®兲 is not forensically neutral when used in a
direct umbilical mode to interrogate the SRS ECU 共i.e., a direct connection to the SRS ECU兲. In that mode, certain external fault codes will
be added 共or re-detected兲 because there is no provision for proper dummy-load resistors in the tool cabling.
共3兲 Data translations/interpretations created by propri- OEM or aftermarket scanners 共e.g., Tech-II, Mastertech,
etary tools. NGS, Consult, DRB-II, MT2500, CS2000, CDR, etc.兲.
共4兲 Data files versus image files. 4. In either situation 共on-vehicle, off-vehicle, benchtop se-
共5兲 The time of data sharing 共i.e. at the retrieval or later兲. rial data via standard harness connector, or direct EE-
共6兲 The media on which data may be shared 共hardcopy, PROM read兲, where an nonstandard scanner is to be
data files on floppy disk, data files on USB mass stor- used 共e.g., proprietary investigator interface or propri-
age device, data files on CDROM, etc.兲. etary mfr/supplier interface兲, an exemplar DUT 共ECU兲
共7兲 Data may be shared, by prior agreement, when the will be first interrogated in a test fixture with the best
translations/interpretations become available. achievable forensic neutrality 共benchtop fixture or ex-
共8兲 In general, the methods and intelligence to derive the emplar vehicle, as agreed by the parties兲 using the same
data 共e.g., translation source code兲 are considered to method and protocol as intended for the subject DUT.
be confidential, protected, or trade secret data. Thus, This is done to prove the integrity of the test fixture, re-
while the work product 共data charts and/or tables in trieval, and communication protocol and interrogation
common engineering units兲 may be shared, the system.
methods and intelligence used to derive that work 5. In all cases the participating investigators shall agree on
product 共e.g., translation source code兲 are generally the feasibility of 共damaged兲 subject vehicle operational
not shared. risk before electrical connections are made and/or
power is applied. Power supply through a fused jumper
may be suggested.
4.5 An Example Protocol for Interrogating 6. Given the joint decision to proceed, the following proce-
EDR Data where Proprietary Data dures apply:
and/or 7. Power off test fixture 共or subject/exemplar vehicle as test
Retrieval Methods are Involved fixture兲.
There can be many ways to reduce the above considerations 8. Select DUT.
to a working practice. Below is an example of a protocol for 9. Install DUT.
EDR data retrieval using a proprietary data interface and 10.1. For standard harness-connector interrogations using
software and using a forensically neutral test bed. The proto- a forensically neutral test fixture, power on test fixture
col below includes considerations for serial data access via 共or subject/exemplar vehicle as test fixture兲 with DUT
the EDR harness connector and considerations for data ac- installed. Observe MIL codes and other-indicator sta-
cess via a direct EEPROM umbilical 共which may be accom- tus. Visually record.
plished via a serial or parallel protocol兲. 10.2. For direct-EEPROM data retrievals, connect device
EXAMPLE PROTOCOL access probe head as appropriate.
1. A written protocol is established, distributed, and 11.1. For standard harness-connector interrogations using
agreed to by the parties interested in the litigation- a forensically neutral test fixture, as appropriate, in-
related data retrieval. terrogate DUT with standard scan tool to record scan-
2. Data to be shared at the data retrieval event are identi- ner data 共service DTCs & service PIDs兲. Record serial-
fied and agreed to such data may include: ized copy to master notes.
共1兲 Raw interrogation data log with commands and re- 11.2. For standard harness-connector interrogations using
sponses a forensically neutral test fixture, interrogate DUT
共2兲 Parsed hexadecimal data 共data stripped of com- with commercial or proprietary serial interrogation
mands and responses but not necessarily formatted兲 tool to retrieve extended DTC/PID information and/or
共3兲 Formatted hexadecimal data 共data in the formatted nonvolatile memory information 共RAM, ROM,
with address headers so that the contents of indi- EAROM, EEPROM, etc.兲. Save data to file.
vidual data cells can be identified by eye兲 11.3. For direct-EEPROM data retrievals, retrieve non-
共4兲 Calculated equivalents of the hexadecimal data 共not volatile memory information 共RAM, ROM, EAROM,
necessarily identified per engineering units兲 EEPROM, etc.兲. Save data to file.
共5兲 Translated data in identified engineering units 共per 12. For standard harness-connector interrogations using a
SLOT factors兲 forensically neutral test fixture, reinterrogate with stan-
The involved parties should reach prior agreement regard- dard scan tool to record scanner data 共service DTCs &
ing what data is to be provided at the time of the data collec- service PIDs兲. Record serialized copy to master notes.
tion, and what data is to be provided at a later time. 13. If no exceptions, power down, and remove DUT.
3. The test conductor will perform two test series, with two 14. If not in as-saved data, create hex table, and distribute to
devices under test 共DUT兲. The first series should involve all parties attending 共serialized copy to master notes兲.
an exemplar device 共to provide a baseline verification of 15. All parties review.
the test fixture兲 and the second series should involve the 16. Select next DUT as applicable and repeat steps 5–15.
subject ECU. The subject ECU may have been removed 共For subject DUT, repeat DTC/PID & EEPROM retrieval
or may still be in the subject vehicle. procedure twice.兲
An exception to these dual DUT procedures would be 17. End test operations.
the interrogation of on-vehicle ECUs, through the SAE 18. At the end of the tests, all parts are to be secured and re-
J1962 port 共or Manufacturer diagnostic port兲 with all sys- packed as received. Subject DUTs, if removed, are to be
tems connected in the subject vehicle, and using standard packed in sealed signature-confirmed wrapping.
Fig. 4.5.1—Showing a data retrieval process using a proprietary data interface and software, used with a combination of two forensically
neutral test beds 关a benchtop fixture for an exemplar ECU and an accident vehicle with the subject ECU in situ兴. This process satisfied the
requirements of ASTM E2493-07.
An example of a process that followed the above protocol is not said in 关4.13兴, Reference 关4.12兴, is that I was the expert
shown in Figs. 4.5.1 and 4.5.2. Figure 4.5.1 shows a propri- who performed the independent download.
etary data interface and software used with a combination of
two forensically neutral test beds 共a benchtop fixture for an 4.6 An Example of Error Rate Calculations to
exemplar ECU and the subject accident vehicle with the sub- Satisfy Litigation Tests
ject ECU in situ兲. Figure 4.5.2 shows the data shared with the
Because download work product such as discussed in Sec-
parties 共the formatted EEPROM data table and the resultant
tion 4.5 was to be used in litigation, it was also necessary to
calculated acceleration/Delta V兲. Note that, by preagree-
characterize the possible error in that process. For the ex-
ment, no proprietary data were shared and the participants
amples shown in Figs. 4.5.1 and 4.5.2, the work of develop-
agreed to no photographs of proprietary data on computer ing and verifying a SLOT factor to translate raw EEPROM
screens. This process satisfied the requirements of ASTM data to engineering units 共acceleration, gs兲 was extended to
E2493-07 关4.15兴. include an error analysis. For that case, a test acceleration
A second example that followed this process is shown in pulse was impinged on a previously undeployed exemplar
Fig. 4.5.3. Here we see the second EEPROM download of a ECU, causing a deploy command. The error analysis was
subject SRS ECU 共the EDR in this case兲, done in accordance achieved by:
with the protocol above. The first download was done by the 4.6.1 Plotting and comparing the resulting ECU record 共ac-
component supplier 共TRW兲 and the second download was by celeration兲 with the external accelerometer. This is
an independent expert using verified forensically neutral shown in Fig. 4.6.1.
equipment. Both downloads produced identical data. This 4.6.2 Plotting and comparing the cumulative time inte-
download event is referenced by Van Gaasbeck 关4.12兴 in a grated acceleration product 共cumulative velocity,
section entitled “Unnecessary off-Vehicle Tests.” Van Gaas- Delta V兲 for both the ECU acceleration with the exter-
beck 关4.13兴, Reference 关4.12兴, discusses this directly. What is nal accelerometer. This is shown in Fig. 4.6.2.
Fig. 4.6.1—Comparison of ECU acceleration with the external

accelerometer.
Fig. 4.5.2—Showing the data shared with the parties by pre-

agreement 共the formatted EEPROM data table and the resultant
calculated acceleration/Delta V兲. Note that, by pre-agreement, no
proprietary data was shared. This process satisfied the require-
ments of ASTM E2493-07. Formatted EEPROM data table Calcu-
lated Acceleration/Delta V Fig. 4.6.2—Comparison of ECU acceleration generated Delta V
with external accelerometer generated Delta V.
Fig. 4.5.3—Shows the second EEPROM download of a subject SRS

ECU 共the EDR in this case兲, done in accordance with verified foren-
sically neutral equipment. The first download was done by the
ECU supplier manufacturer and the second download was by an
independent consultant 共the Author兲 using an AVT 716® for EE-
PROM download and a Snap-On MT-2500® for DTC confirmation Fig. 4.6.3—ECU acceleration generated Delta V with external ac-
共both seen in the photos兲. The MT-2500 confirmed forensic neu- celerometer generated Delta V overlayed with deviation 共error,
trality and both the ECU supplier and the independent EEPROM %兲 of the ECU generated Delta V versus the mean cumulative
downloaded data were identical. velocity 共Delta V兲, over the integration time
Fig. 4.6.4—An example of independently derived data, following the method of impinging a defined test acceleration pulse on a previ-
ously undeployed exemplar ECU, and then comparing the impinged pulse with the EDR internal record. This example was derived using an
exemplar 2003 Lexus ES300 ECU, and is one of the examples included in Ref. 关4.8兴. Note that in this example, the impinged acceleration is
shown as a line trace, the EDR acceleration is shown as a circle markers, the impinged-acceleration-derived DeltaគV is shown as a line trace
and the EDR-derived DeltaគV is shown as triangle markers. The EDR driver squib1 fire time is also shown 共as noted by the voltage difference
across the 2 Ω squib in the top half of the chart兲.
4.6.3 Plotting the deviation of the ECU generated Delta V References

versus the mean cumulative velocity 共Delta V兲, over the
integration time. This is shown in Fig. 4.6.3. 关4.1兴 NHTSA 49CFR Part 563, NHTSA Final Rule response to vari-
This deviation 共error兲 plot shows the error rate to be ous petitions. Full text found in The Federal Register, Vol. 73,
less then ±3 %. One reference to EDR data, Niehoff No. 9, Monday, January 14, 2008/Rules and Regulations.
et al. 关4.7兴, shows, for a sample of 28 test crashes, an 关4.2兴 Kowalick, T., Fatal Exit, The Automotive Black Box Debate,
average mean error of ±5.8 % for EDR-reported Delta Wiley, New York, 2004.
V versus test-accelerometer-based Delta V8 Thus less 关4.3兴 Bosch CDR coverage, Vehicles covered by the most common
then ±3 % the error rate derived in the tests here are EDR data retrieval tool, the Bosch CDR® 共http://www.cdr-
well within accepted industry standards for EDR re- system.com/coverage/index.html兲.
porting accuracy. 关4.4兴 Auto Week, Black Box on Board, Nissan Vehicle Status Data
4.6.4 Another example of independently derived data is Recorder 共VSDR兲 on GT-R, 24Sep08 共http://www.autoweek.
shown in Fig. 4.6.4. In this example, using an exemplar com/apps/pbcs.dll/article?AID⫽/20080924/FREE/
2003 Lexus ES300 ECU, and following the method of 809189970/1023/THISWEEKSISSUE兲.
impinging a defined test acceleration pulse on a previ- 关4.5兴 Volvo Volvo Cars of Canada Corp. Privacy Policy 共http://
ously undeployed exemplar ECU, the impinged-pulse- www.volvocanada.com/Privacy.aspx?lng⫽2兲.
关4.6兴 Toyota Event Data Recorders, Data Content and era of intro-
derived DeltaគV was compared DeltaគV derived from
duction 共http://www.toyota.com/about/our_business/opera
the with the EDR internal acceleration record. It can
tions/sales/EventDataRecorder.html兲共September 26, 2008兲,
be seen from this figure that the external-
16Mar09 Proprietary EDR tool development.
accelerometer-derived DeltaគV is congruent with the
关4.7兴 Niehoff, P., Gabler, H., Brophy, J., Chidester, J., Hinch, J.,
EDR-derived DeltaគV, thus intuitively satisfying the ac-
Ragland, C., Evaluation of Event Data Recorders in Full Sys-
ceptable error rate criteria.
tems Crash Tests, National Highway Traffic Safety Adminis-
This is one of the examples discussed in item 7 of the in-
tration Paper No. 05-0271 共http://www.harristechnical.com/
troduction to this chapter. Note that in this example, the
downloads/05-0271-W.pdf兲.
driver squib1 fire pulse is also shown 共as recorded by the data
关4.8兴 ASA derivation of Toyota EDR data, March, 2009, ASA Inc.,
acquisition system兲 so that the time to fire 共TTF兲 may also be
Reston, VA. Proprietary EDR tool development.
discerned from the EEPROM data—if it is actually stored in
关4.9兴 ASA derivation of Hyundai EDR data, February, 2009, ASA
that data.
Inc., Reston, VA. Proprietary EDR tool development.
8
Niehoff, et al., Table 2, average % error, frontal. 关4.10兴 Wheelock, R. J. 共Bob兲, Ford Automotive Safety Office, Cur-
rent Ford Event Data Recorders, SAE Government / Industry Volatile Memory Data in Evidentiary Vehicle Electronic Con-
Meeting, May 15, 2007 trol Units,” 2007. Published by ASTM International, West
关4.11兴 ASA derivation of 2002–2005 Ford Explorer EDR data, Janu- Conshocken, PA, 19428–2959.
关4.16兴 Capgo, Inc., Resistor Color Codes 共http://www.capgo.com/
ary, 2009, ASA Inc, Reston, VA. Proprietary EDR tool develop-
Resources/Measurement/MeasHome/Resistors/
ment.
Resistors.html兲.
关4.12兴 Van Gaasbeck, S., How to Challenge Black Box Data, Trial
关4.17兴 Graham, S. J., Abandoning New York’s “General Acceptance”
Magazine, 01-FEB-07. Requirement: Redesigning Proposed Rule of Evidence 702共b兲
关4.13兴 Van Gaasbeck, Reference 共12兲, Personal communication with After Daubert v. Merrell Dow Pharmaceuticals, Inc. Volume
Leon R. Russell, Law Offices of Leon R. Russell, P.C., Dallas, 43, Number 1 of the Buffalo Law Review, Spring 1995, pages
Tex. Russell warns that “companies know far more about the 229–61.
airbag systems they manufacture than plaintiff’s counsel ever 关4.18兴 Oppenheim, E. B., Scientific Evidence in Medical Negligence
will. Documentation describing air bag systems is usually Litigation Part II.
cryptic and difficult to decipher. It is essential then that plain- 关4.19兴 Kesan, J. P., Ph.D., A Critical Examination of the Post-Daubert
tiff’s counsel retain an expert on black boxes not only to help Scientific Evidence Landscape.
counsel understand the air bag system specifications but also 关4.20兴 Samelman, T. R., Junk Science in Federal Courts: Judicial Un-
derstanding of Scientific Principles, Daubert v. Merrell Dow
to test the critical components of the system to assure that
Pharmaceuticals, Inc., 509 U.S. 579 共1993兲.
they functioned as designed.”
关4.21兴 Sanders, Joseph, University of Houston Law School, Shari S.
关4.14兴 Gabler, H. C. Gabauer, D. J. and Newell, H. L., Rowan Univer-
Diamond, Northwestern University Law School and Ameri-
sity, Glassboro, New Jersey, Michael E. O’Neill, George Ma- can Bar Foundation, Neil Vidmar, Duke University Law
son Law School, Arlington, Virginia, Use of Event Data Re- School, Legal Perceptions of Science and Expert Knowledge,
corder 共EDR兲 Technology for Highway Crash Data Analysis, Psychology, Public Policy, and Law, 2002, Vol. 8, No. 2, 139–
December 2004. 153, Copyright 2002 by the American Psychological Associa-
关4.15兴 ASTM E2493-07, “Standard Guide for the Collection of Non- tion, Inc.
MON05-EB/Sep. 2009
Subject Index
A E
ABS EDR accelerometer analysis, 62–67

operation, 68–69 EDR data
potential failure modes, 69–70 evidentiary reliability and, 90–98
wheel speed sensor, 68–82 interrogation procedures and, 90–98
WSS signal processing by, 74–76 litigation rules, 92–93
acceleration reporting, 22 veracity requisites for, 91–92
accident investigation, 83 EDR performance versus EDR family performance, 83–89
algebraic acceleration using count values, 19 EEPROM data, 12–17
analysis, EDR accelerometer, 62–67 electronic control unit 共ECU兲, 1
azimuth notation, 62–63 electronic data in air bag ECUs, 3–5
azimuth derivation, vector magnitude and, 63–67 engineering units from raw data Inside ECU/EDR, 5–9
equipment and instrumentation, heavy duty truck wheel
rotation tests, 70–71
error rate calculations for litigation, 95–97
B event data and data translations, 91
event data recorders 共EDRs兲, 1
base 10 system, 16 evidentiary reliability and EDR data considerations
bitmap encoding, hexadecimal data and, 60 and, 90–98
example protocol, interrogating EDR data, 94–95
Excel, 33–40, 60–61, 67, 81–82
calculate cumulative velocity change, Delta V, 19

F
complex numeric translations, 15–16
forensically neutral data retrieval process, 91
formatting, 7
spreadsheet data quantization and, 83–88
D formula, 11
frontal air bag systems, deployment metrics, 2–3
data import methods, 42–54
data interpretation
derived metrics and, 88–89 G
for evaluating subject system, 88–89
data mining, 42–54, 46–47
geometric conventions for crash event, 2
data templates using hexadecimal data stream input,
47–49
data translations, 11
event data and, 91 H
deduction, 18
deductive analysis, source data for, 26–33 handling data array that is not quite usual, 49–54
Delta V handshakes, 1
cumulative velocity change, 19 hard copy data digitization, 83
validation of acceleration digitization capability, 88 hardcopy crash test data, EDR performance, 83–89
deployment metrics, frontal air bag systems, 2–3 heavy duty truck wheel rotation tests, 70–71
derived engineering units, to calculate cumulative hex data blocks, linear data list from, 12–17
velocity change, 19 hexadecimal arithmetic, 16–17
derived metrics, and data interpretation for evaluating hexadecimal data
subject system, 88–89 bitmap encoding, 60
deriving scaling and transfer relationship from data, 9–10 data templates using, 47–49
diagnostic trouble codes 共DTCs兲, 60 hexadecimal representation of signed binary integer
multibyte and bitmap translation as, 55–61 value, 59–60
digitization, hard copy data, 83 hypothesis, 18
99
100
I protocols, interrogating EDR data, 93–94
importing and mapping data, using Vetronix CDR Q

retrieval tool, 44–46
inductive engineering method to document and confirm Quattro Pro, 33–40, 60–61, 67, 81–82
an ECU/EDR SLOT factor, 18–19
inductive reasoning, 18
R
interpretation, 9
interrogating EDR data
example protocol, 94–95 repeatable method, 18
protocols, 93–94 retrieving crash-related data, 5–9
interrogation, 6 retrieval of EEPROM data, 25–26
EDR data considerations and, 90–98
inverted octal coding for single positive integer S
value, 58–59
signed binary integer value, hexadecimal representation
of, 59–60
L single positive value
inverted octal coding for, 58–59
lateral components, vector magnitude, 63–67 multibyte hexadecimal quantities for, 55
linear data list from hex data blocks, 12–17 octal coding for, 55–58
litigation source data for deductive analysis, 26–33
EDR engineering data rules, 92–93 spreadsheet data quantization and formatting, 83–88
error rate calculations for, 95–97
longitudinal components, vector magnitude and, 63–67
T
M time to fire 共TTF兲, 23

translation, 7–9
mapping templates, 42–54
matching real data to standardized axis conventions, 62 V
multibyte and bitmap translation as applied to diagnostic
trouble codes 共DTCs兲, 55–61 validation
multibyte hexadecimal quantities for single positive acceleration digitization capability using Delta V
integer value, 55 analysis, 88
empirically derived SLOT constants, 22–23
vector magnitude, 63–67
N and azimuth derivation, 63–67
lateral components, 63–67
noise immunity, 76–81 and longitudinal components, 63–67
nonvolatile memory, 3 vehicle black box data, 1
nonvolatile memory data, 1 veracity requisites for EDR data retrieval, 91–92
verification, 18
O Vetronix CDR retrieval tool, 44–46
octal coding for single positive value, 55–58 W

operator equivalence, 33–40
wheel rotation tests, 71–73
wheel speed sensor. See WSS
P WSS
ABS, 68–82
parsing, 7 data from wheel rotation tests, 71–73
potential failure modes, ABS, 69–70 signal processing by ABS ECU, 74–76
process outcome, 18 signal review, 73–74
William Rosenbluth has 48 years of professional experience with complex
electro-mechanical, electronic and computer components and systems. He was
employed by the IBM Corporation for 21 years, and for the past 23 years he has
been principal engineer for Automotive Systems Analysis, Inc. (ASA), in Reston,
Virginia. At ASA, he specializes in the analysis and diagnosis of computer-
related vehicle control systems and in the retrieval and analysis of electronic
crash-event data in accident vehicles (black box data).
Mr. Rosenbluth is a Diplomate of the International Institute of Forensic

Engineering Sciences (D-IIFES), a Fellow of the American Academy of Forensic
Sciences (AAFS), a member of the Society of Automotive Engineers (SAE),
ASTM International, and a life member of the Institute of Electrical and
Electronics Engineers (IEEE) and the IEEE Computer Society.
At IEEE and AAFS, he has co-authored and/or presented over 60 papers

dealing with automotive engineering investigations, co-instructed a continuing
education short course, and organized engineering technical sessions. His
engineering achievements were recognized by the AAFS in 1999 when he
was presented with the Andrew H. Payne, Jr. Special Achievement Award
for Pioneering New Procedures, Outstanding Professional Performance and
Outstanding Forensic Engineering Leadership.
He holds three U.S. Patents, including one for a device to measure air bag
static deployment throw and velocity using digital data acquisition.
His publications include a prior book, Investigation and Interpretation of

Black Box Data in Automobiles, co-published by ASTM and SAE in June
2001, a Chapter on air bag systems data and diagnosis in Forensic Accident
Investigation, Motor Vehicles-2, published by Lexis Law Publishing and papers
in the Journal of Forensic Sciences and Sensors Magazine.
Mr. Rosenbluth was chairman of the ASTM E30.05/WK 4150 Standards

Development Group that produced E2493-07: Standard Guide for the Collection
of Non-Volatile Memory Data in Evidentiary Vehicle Electronic Control Units. That
Standard Guide, developed with participants from industry, government and
private sectors, was approved and published by ASTM in April 2007.
He lives with his wife Jean in Reston, Virginia.
www.astm.org
ISBN: 978-0-8031-7003-2
Stock #: MONO5

Mono5 2009

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mono5 2009

Uploaded by

Copyright:

Available Formats

Black Box Data

from Accident Vehicles

ASTM Stock Number: MONO5

Printed in the U.S.A.

Rosenbluth, William, 1939–

2.1 Geometric Conventions for Crash Event Pulses 2

Chapter 3—Examples and Exercises in Data Translation 11

4.1 The Role of Event Data and Data Translations 91

As stated in 2.1 above, just about every crash impact

Fig. 2.1.2—Vehicle axis system with signed SAE J670e/J1733/J211

ous versions of SRS controllers, as applied to different

Fig. 2.2.1—Base vehicle axes showing sensor de-

cerpt of actual data read with that method. This method,

can produce numeric parameters with appropriate en-

Fig. 2.4.0.10—Excerpt of actual EEPROM data read using the di-

0.5g / count兲. Note that, in addition to the g’s transla-

2.5 Deriving a Scaling and Transfer

Fig. 2.4.4—Translated data excerpt, longitudinal acceleration

of Controlling Deployment Thereof, Caruso, Christopher M.;

Fig. 3.1.1.2—Figure 5 of motorola/freescale application note

hexadecimal address values in column B. If we in-

Fig. 3.1.3.5—Fresh HexTable values mapped to hex linear data list.

can count our ten fingers. The decimal system is said to be a

Fig. 3.1.4—2-byte hex quantity translations.

TABLE A.1—Comparison of equivalent hexadecimal, binary, and decimal numbers.

3.2.2 Evaluating Algebraic Acceleration

3.2.3.5 Using the engineering values derived above, if we DV = − 358.19g ms

Fig. 3.2.5.3—Data acquisition summary of the ±50g accelerometer

− 3.5127 m 3600 s − 12,645.72 m 1 km

− 12.6457 km 1 mile − 7.8579 miles

Fig. 3.2.5.2—±50g accelerometer mounted on the trolley. The ac-

Fig. 3.2.5.5—Superposition of the calibrated external acceleration

Fig. 3.2.6—Spreadsheet Solution for cumulative velocity change 共mph兲.

As a second problem exercise let us assume the following: References

rogation and parsing method will also apply to the tar-

exercise where the raw hexadecimal EEPROM

TABLE 3.3.6.2—Test of deductive longitudinal data relationships hypothesis.

SRS topology as a known CDR supported vehicle 01

Fig. 3.3.7—Spreadsheet showing translation from acceleration to Delta V.

Fig. 3.3.8—Chart showing line plot of the deductively derived lon-

Fig. 3.3.10.1—共a兲 Interrogation of nonformally upported vehicle

Fig. 3.3.9—Overlay comparing the deductively derived longitudi-

Fig. 3.3.10.5— „Continued….

Fig. 3.4.1.2—ECU #1 interrogation. Fig. 3.4.1.3—ECU #2 interrogation.

In operation, the CDR interrogates the ECU under test three

Fig. 3.4.1.7—Hex data table for ECU #2.

One could always retrieve those hex data manually from

3.4.4 Handling a Data Array That Is Not

ear list can provide some form of confirmation. Pro-

Fig. 3.4.2.2—Label from ECU #1 referring to Fig. 3.4.2.1, linear list:

Fig. 3.4.3.2—Network traffic log as seen by a network monitor

Fig. 3.4.3.7—Linear list 共partial兲 derived from Hex Table.

Fig. 3.4.4.6—Partial linear list of data with ASCII translation. Note

Example representations for the same decimal count values

Fig. 3.5.2—Octal coding for a single positive integer value.

Fig. 3.5.3—Inverted octal coding for a single positive integer value.

Fig. 3.5.4—Signed binary arithmetic as derived from hexadecimal data representation.

$FF − $EA = $15

Cell G10 QP: @IF共共@BITTH共$D10, 7兲 = 1兲 , “ B1108” , “ − ” 兲

A similar process applies for row 11 and row 12.

Fig. 3.6.1—Subject vehicle showing SAE J1733/211/670e X and Y

negative acceleration values are reported for clockwise turns

The next step is to assemble all of the conditional flags gath-