Content uploaded by Francis Hoogendijk
Author content
All content in this area was uploaded by Francis Hoogendijk on Oct 14, 2021
Content may be subject to copyright.
- 1 -
© 2020 by EVU
EVU2021-081
Reverse engineering and evaluation of
Tesla vehicle logs
F.C. Hoogendijk, MSc
Netherlands Forensic Institute (NFI)
Abstract
Tesla Motors has allowed access to their vehicle's Event Data Recorders (EDR) since 2018. Raw
data can be obtained from the Restraints Control Module (RCM) and contains the last 5 seconds
prior to a deployment event as per 49 CFR Part 563. Online translation of that raw data is offered,
but only for Tesla's sold in North-America. However, the vehicle's gateway also continuously logs
data over the course of its lifetime and contains far more signals, and over a longer period of time,
than EDR does. These logs reside on an accessible SD-card and its contents have been reverse
engineered and validated in experiments with a reference vehicle. This paper addresses the con-
tents and structure of these vehicle logs. How to access this data and what precautions should be
taken for the acquisition and analysis is also covered.
Zusammenfassung
Tesla Motors erlaubt seit 2018 den Zugriff auf die Ereignisdatenschreiber (EDR) ihres Fahrzeugs.
Rohdaten können vom Rückhaltesteuerungsmodul (RCM) abgerufen werden und enthalten die letz-
ten 5 Sekunden vor einem Bereitstellungsereignis gemäß 49 CFR Part 563. Online-Übersetzung
Davon werden Rohdaten angeboten, jedoch nur für in Nordamerika verkaufte Tesla. Das Gateway
des Fahrzeugs protokolliert jedoch auch kontinuierlich Daten im Laufe seiner Lebensdauer und
enthält weit mehr Signale und über einen längeren Zeitraum als EDR. Diese Protokolle befinden
sich auf einer zugänglichen SD-Karte und ihr Inhalt wurde in Experimenten mit einem Referenzfah-
rzeug rückentwickelt und validiert. Dieses Dokument befasst sich mit dem Inhalt und der Struktur
dieser Fahrzeugprotokolle. Außerdem wird erläutert, wie auf diese Daten zugegriffen werden kann
und welche Vorsichtsmaßnahmen für die Erfassung und Analyse getroffen werden sollten.
Introduction
Tesla Motors collects vast amounts of data from
its fleet of vehicles for various purposes. Some
of these are: troubleshooting; evaluation of vehi-
cle quality, analysis and research to improve ve-
hicle and system designs. The data is recorded
on the vehicle and periodically uploaded to
Tesla’s servers. This data can be officialy re-
quested by Police or other authorities and by
court order. Tesla can also use this data to de-
fend itself in any way it sees fit [1]. Such data
was used in the analysis of the first recorded fa-
tal crash of a Tesla vehicle while on autopilot.
The crash occurred on May 7, 2016 in Williston,
Florida and was investigated by the National
1
This technical paper was accepted for the 29th Annual Congress of the European Association for Accident
Research (EVU) after peer review.
Transportation Safety Board (NTSB). The re-
ports of this investigation are published in a
docket on their website [2].
Only 4 monts after the Florida crash, a fatal sin-
gle-vehicle crash with a Tesla vehicle occurred
in the town of Baarn, the Netherlands which
caught our interest [3]. At the time Tesla vehi-
cles did not contain an Event Data Recorder
(EDR) as per 49 CFR Part 563 [4] or rather
Tesla had not yet released their download tool
[5]. There was no available method to objec-
tively check Tesla’s claims on the vehicle speed
or system operation.
More recently however, Tesla has provided
means for owners to access data associated
Francis Hoogendijk - Reverse engineering and evaluation of Tesla vehicle logs
- 2 -
with their account [6], likely to comply with pri-
vacy regulations. Owners may also choose to
opt-out of sharing data with Tesla [7]. We have
not tested or investigated obtaining data this
way, nor the effects of opting out of data shar-
ing.
We have reverse engineered the logs present
on physical storage media in Tesla vehicles in
order to objectively investigate them. This paper
will give an overview of the information that can
be obtained from these logs with examples of
several vehicles.
Outline
The Tesla vehicle logs differ per vehicle type
and have changed over time. We will therefore
first describe common system architecture and
will then expand on each kind of log we have
analyzed in separate sections. We will also
briefly cover the Autopilot system logs and the
differences in Autopilot generations with respect
to the information that can be obtained from
them.
Tesla system architecture
Most Tesla vehicles share a similar common ar-
chitecture to some extent, when not considering
hard- and software versions. We’ll describe the
architecture at a broad level:
There’s the MCU which serves as the infotain-
ment and is attached to the central touchscreen.
The MCU is a Debian-based Linux system
which is situated on a Printed Circuit Board
(PCB) that also houses the gateway . This gate-
way is an automotive-grade freescale microcon-
troller running FreeRTOS that interfaces with
the vehicles CAN buses on one side and to the
MCU via Ethernet on the other through a switch
placed on the same PCB. Then there’s the Au-
topilot (AP) unit which connects to multiple vehi-
cle CAN buses and from AP generation 2 and
newer also to the Ethernet network. The AP unit
is also a Debian-based Linux system.
Model S and Model X vehicles share the same
MCU which, at the time of writing, has 2 genera-
tions: MCU1 and MCU2. Therefore they also
share the same gateway and the same log file
structure. A different system is used in the
Model 3 and Model Y vehicles; they also both
use the same MCU, which is different than the
Model S and X. The MCU and AP are placed to-
gether in a shared housing, which also incorpo-
rates liquid cooling, called the ‘car computer’. In
contrast, both the Model S and X have a sepa-
rate air-cooled AP module.
Model S and X gateway logs
The SD card that contains the vehicle logs is
connected to the gateway. Since the gateway is
placed in the center of several CAN buses, it
has access to most of the relevant messages
describing the vehicle and systems state and is
thus ideally suited to selectively log this infor-
mation. Acquiring the SD card requires part of
the dashboard to be disassembled until the
MCU is able to tilt towards the rear of the vehi-
cle. On newer MCU’s there is a slot on the top
of the housing through which the SD card can
be reached. If the slot is not present, the MCU
needs to be removed from the vehicle and dis-
assembled to acquire the SD card.
For Model S and X vehicles the SD card is 4GB
in size containing a single FAT32 partition. The
‘log’ directory in the root of this filesystem
contains up to 5 files with a ‘.log’ extension
which contain up to 300MB of binary data
encoded in a proprietary format. We reverse
engineered the file structure and created tools
to extract the logged signals from them. The
writeup of the reverse engineering and the tools
can be found on the NFI GitHub page [8].
The log files encode signal-based timeseries
data. Each signal has a unique identifier and
contains timestamped (UTC) datapoints. Some
signals are logged periodically, othersignals
only when their value changes. These
datapoints then need to be decoded to
engineering units to be used in an analysis. We
found that each identifier corresponds to an
encoding to engineering units through the same
way a signal is normally encoded in a CAN
frame. By reverse engineering the gateway
firmware, combined with information from the
MCU eMMC storage on how signals are
encoded in CAN frames (equivalent to CAN
DBC files), we were able to translate a large
number of signals.
The eMMC storage on the MCU also contains
several regular Linux log files that may be
relevant for investigations in: ‘/var/log’, but these
are human readable and therefore will not be
covered in more detail here.
For some traffic accident cases in which Dutch
Police requested the logs from Tesla’s servers
and also copied the SD card, we decoded these
logs and determined that they exactly match the
data supplied by Tesla. Tesla however only
Francis Hoogendijk - Reverse engineering and evaluation of Tesla vehicle logs
- 3 -
supplies a specific subset of signals, only the
ones requested, for a specific timeframe,
whereas the log files contain all the recorded
signals. Note that the 5 log files kept for Model
S and X vehicles may contain over a year worth
of data [9] depending on the amount of vehicle
usage.
Validation
We were able to record CAN traffic on several
buses of one Model S vehicle and afterwards
create an image of the SD card. After correcting
for a static time difference of about 0.5 seconds
between the CAN log timestamps and the
timestamps of the gateway log, we were able to
line up the data as can be seen in Figure 1. As
an example we plotted the longitudinal and lat-
eral acceleration signals of the ESP module. This
specific CAN message is transmitted at a fre-
quency of 50Hz while the log records it at 1Hz.
This also illustrates the logging strategy we de-
duced from the gateway firmware; periodic sig-
nals are logged by recording the most recent
value seen on the bus and the value is not aver-
aged over time.
Model 3 gateway logs
The Model 3 uses a slightly newer gateway than
the Model S and X which is still a freescale auto-
motive-grade microcontroller from the same fam-
ily. The gateway still performs similar tasks, but
the logging file format has completely changed.
These logs now reside on a 8GB micro-SD card.
Acquiring this micro-SD card requires access to
the ‘car computer’ located in the passenger foot-
well, behind the glovebox. On Autopilot genera-
tion 2 and 2.5 systems, there is a metal cover on
Figure 1: Model S and X gateway log validation
Figure 2: Metal cover of AP2.5 car computer re-
moved
Francis Hoogendijk - Reverse engineering and evaluation of Tesla vehicle logs
- 4 -
the bottom left corner (when viewing it from the
footwell) that can be unscrewed to reach the
PCB and subsequently the SD card as shown in
Figure 2.
On Autopilot generation 3 systems, there are
only two small slot in the underside of the unit.
One of which is for the micro-SD card as shown
in Figure 3.
On early vehicles with a software version pre-
2020, the log format was message-based in con-
trast to the signal-based logs on the Model S and
X gateways. The log files are still placed in a di-
rectory called: ‘log’ in the root of the micro-SD
card and also have the ‘.log’ extension. In es-
sence these logs contain complete CAN frames,
but they are subsampled in time and filtered to
remove for instance frames containing GPS in-
formation. The file format also replaced variable
length structures for fixed-length ones, allowing
for more efficient loading and indexing of the
data. Again, see our GitHub page for more de-
tails [8].
High Resolution Logs
There is also a ‘HRL’ directory on the Model 3
micro-SD card which contains files with the .HRL
extension. The HRL acronym appears to stand
for High Resolution Logs, as we found when de-
compiling the vehicle’s on-board diagnostic sys-
tem: odin. As the name suggests, these files are
high resolution CAN logs of the three CAN buses
physically connected to the gateway. These logs
can be triggered and only record a short (in the
order of tens of seconds) period of data. We did
not determine the exact kinds of triggers yet, but
triggering the crash algorithm wakeup of the air-
bag module seems to be one of them.
The gateway continuously keeps a ringbuffer of
a subset of messages in memory as a pre-trigger
and will, upon triggering, record all subsequent
CAN messages in the same structure as visual-
ized in Figure 4. In later software versions, we
observed the HRL files to grow in size, spanning
up to a minute of time.
In early software versions, it seemed that there
was a fixed number of HRL files that would be
kept on the gateway’s micro-SD card. This
changed in later software versions, but we do not
know from which version this is. More recently
the HRL files are transmitted to the MCU upon
completion and subsequently uploaded to
Tesla’s servers.
Since the HRL files contain all CAN messages
after the trigger, including GPS data, it serves as
an additional piece of information to link the
logged data to the accident under investigation.
This was not possible on the Model S and Model
X logs. In those it is only possible if a
timestamped airbag deployment signal is availa-
ble.
Figure 4: : HRL pre- and post-trigger behaviour
Figure 3: AP3 car computer slots in underside
Francis Hoogendijk - Reverse engineering and evaluation of Tesla vehicle logs
- 5 -
Validation
Unfortunately, we were not able to validate
Model 3 gateway logs on an actual vehicle by re-
cording CAN messages like we did for the Model
S logs. However, given that both the regular log
files and the HRL files are message-based and
originating from CAN messages, we expect to be
able to find the same messages in both the reg-
ular log files and the HRL file in overlapping
timespans. In order to illustrate this point, see Fi-
gure 5 which shows four individual wheel speed
signals during an impact. The HRL signals are
plotted as a line and the corresponding data-
points from the log are a scatter plot to minimize
visual clutter. Note that even the low resolution
log file stores these signals at 5Hz. The HRL
stores them at their original transmission rate of
50Hz. Also note how the front right wheel locks
up at impact, which is plausible given that this ve-
hicle rear-ended a semi-trailer with that corner.
Another interesting phenomena occurrs about
one second later; the datapoints from the regular
log are absent for rougly one second and then
appear lumped up within milliseconds from
eachother afterwards. These points do actually
line up with the HRL data if they would be spaced
out as if they had their regular period.
We assume this happens because the logging
task in the RTOS of the gateway is separated
from the task that writes the data to the log file.
The logging task sends the messages to the log
writing task in a queue structure. Appearently the
logging task executed at the proper times, other-
wise the data values would not line up with the
HRL. We assume a task or procedure got exe-
cuted with a priority that was higher than the log
writing task. When it was time for the log writing
task to execute, it stored the queued messages
and assigned them the timestamp of the moment
they were written. During normal operation, the
difference in time between recording the data
and assigning it a timestamp when writing should
be negligible, up to one or two milliseconds at
most. This is actually visible when comparing the
log and HRL data in detail. We have observed
this deffered logging behavior on other pre-2020
software Model 3 crash vehicles too and it may
be something to consider when analyzing log
data provided by Tesla if it exhibits such lumped
data points.
Current CL gateway log format
Starting with software versions in 2020 the gate-
way logs transitioned to yet another file format.
The old log files seem to remain untouched on
the micro-SD card and will no longer be filled up.
The new log files are stored in a directory ‘CL’ in
the root of the filesystem. In this format the logs
switched back to being signal-based but are now
combined with an indexing system for more effi-
cient looking up of data. Just like in the Model S
and X logs this means data is stored as
timeseries with a unique identifier. However, the
translation from an identifier to engineering unit
now changes for each software version, unlike
Figure 5: HRL versus log data on pre-2020 Model 3 software
Francis Hoogendijk - Reverse engineering and evaluation of Tesla vehicle logs
- 6 -
the Model S and X logs where that translation re-
mained fixed. To make matters worse, we were
unable to emulate the firmware and could there-
fore not automate the process of determining this
translation. This was because this microcontrol-
ler uses the Variable Length Encoding (VLE) fea-
ture of the PowerPC architecture for which there
is little support in conventional emulation tools at
the time of writing. It is still possible to look up
specific signals by manually tracing them in a de-
compiler (we used Ghidra [10]). This process
quickly becomes excessively time-intensive
though.
We did find one heuristic for singling out the four
wheel speeds and steering wheel angle signals:
these are stored more frequently than other sig-
nals. So sorting signals by the number of data-
points in a given timespan will quickly reveal
them. An example of this (a different more recent
Model 3 crash) is shown in Figure 6 where we
plot the HRL signals as lines and overlay a scat-
ter plot for the CL signals. Note that we used the
HRL scaling factors to scale the CL signals. This
figure also shows an additional feature of this
new encoding on the front left (red) wheel. Note
how no new data points are recorded in the CL
when the signal value is unchanging, while it is
periodic otherwise. Also note that this behavior
should not be confused with the deferred logging
artefacts of the older log format. In this CL format
this is actually by design and aids in reducing
storage space required for logging.
Autopilot
The autopilot module may, in certain conditions,
also contain relevant information for traffic acci-
dent investigations. The earliest Tesla Model S
vehicles did not have any autopilot functionality.
In early 2015, they came equipped with Autopilot
generation 1 based on Mobileye’s EyeQ3 hard-
ware using a frontal camera. By late 2016, the
autopilot system was upgraded to generation 2
which is based on Nvidia’s Drive PX2 system, us-
ing 8 camera’s enabling surround vision. A revi-
sion on this system in 2018 was dubbed genera-
tion 2.5 which was used until autopilot generation
3 was introduced in mid 2019. The third genera-
tion is based on silicon designed by Tesla [11].
AP1
We analyzed the first generation Autopilot unit
in a Model S once down to performing a chip-off
of the onboard NOR flash chip. This chip con-
tained 8 grayscale images similar to those
found on the SD card with a .pgm extension as
shown in [3]. This matches the NTSB Williston
report description of the process with which the
events are recorded from volatile memory to
non-volatile storage on the Autopilot module [2].
They are subsequently transferred to the gtw
SD card over CAN at the end of a drive, a pro-
cess which can take up to 40 minutes according
to the NTSB report [2]. So if power is discon-
nected by first responders at an accident scene
on these first generation Autopilot vehicles, and
images are not be present on the SD card, they
Figure 6: CL signals as scatter plot with hexadecimal identifiers and scaled with the same factor as ESP
wheel speed signals. The wheel speed signals from the HRL are overlayed as line plot.
Francis Hoogendijk - Reverse engineering and evaluation of Tesla vehicle logs
- 7 -
could still be present on the Autopilot’s NOR
flash. Also, if power is lost immediately during a
severe crash, it’s likely that no image data is
stored at all. This of course holds true for all au-
topilot generations.
AP2 and AP2.5
The second generation autopilot systems are far
more capable than the first generation and can
store so called ‘snapshots’ of events deemed in-
teresting by Tesla. This is the primary mecha-
nism by which Tesla implements fleet-learning
[12]. A specific kind of snapshot is triggered upon
airbag deployment which can store a few hun-
dred megabytes worth of relevant data. These
snapshots contain images and video’s of all 8
camera’s, high resolution CAN logs of both trans-
mitted and received messages as well as hu-
man-readable text logs from ‘/var/log’ on the sys-
tem. There is more data stored in these snap-
shots which we are not able to parse yet. An
anonymous Tesla hacker aliased @greenthe-
only [13] can however parse more information,
such as objects detected by Autopilot’s vision
system and radar. Obtaining these snapshots re-
quires creating a physical image of the eMMC
storage as they are often deleted after a suc-
cessful upload to Tesla. Then tools like Photo-
Rec [14] can be used to recover them. Tools to
process the image, video and CAN data from
these snapshots are also on our GitHub page [8].
AP3
On the third generation of autopilot a more mod-
ern storage medium is used: Universal Flash
Storage (UFS). It also is encrypted by default and
to date we do not know how to obtain snapshot
data from these systems.
AP versus gtw logs
Since snapshots on AP2 and AP2.5 systems
contain CAN logs of the same buses as the gate-
way logs, we can compare them side by side.
The snapshots CAN logs are in a directory ‘raw’
which contains both a ‘canrx.can’ and ‘cantx.can’
file. The files have the same structure and con-
tain the messages received and transmitted by
the Autopilot computer respectively. An im-
portant detail here is that everything in the snap-
shots is timestamped in seconds of runtime, i.e.
the time the autopilot unit has been running for.
This requires a synchronization step to compare
the AP CAN logs with the gateway logs, which
have UTC timestamps. In the context of analyz-
ing a traffic accident, we do this by matching the
Figure 7: Comparison of gateway CAN logs and AP snapshot CAN logs
Francis Hoogendijk - Reverse engineering and evaluation of Tesla vehicle logs
- 8 -
first occurrence of the airbag module’s collision
message. The result of this is visualized in Figure
7, where this synchronization moment of the col-
lision is highlighted by a vertical black line (this is
the same crash as Figure 5). The snapshot CAN
log spans a few minutes, whereas the HRL only
spans a few tens of seconds. The regular gate-
way log of course may span for however long fits
on the SD, up to years. Also note that the HRL
contains a pre- and post-trigger section whereas
the AP snapshot will stop shortly after the trigger
and only contains data from before that moment.
Another observation is that the snapshot’s ‘raw’
CAN frames are stored with nanosecond resolu-
tion but actually seem to be processed at 100Hz
on the autopilot computer as shown in Figure 8.
In contrast, the HRL CAN frames are
timestamped as soon as they are recorded with
millisecond resolution. For clarity the same verti-
cal black line as in Figure 7 is drawn to show the
first CAN frame with the collision message. Note
how it is likely (but not exactly) the transition be-
tween pre-trigger and post-trigger behavior in the
HRL.
The last noteworthy difference is in the CAN
frames which are logged. By analyzing the oc-
curence of CAN messages and transmission pe-
riods, we were able to deduce the mapping be-
tween bus identifiers and names as shown in
Table 1. We labeled bus id 2 in the snapshots
raw CAN logs as the radar bus by elimination, as
this is the only bus that is connected to the Auto-
pilot module and not to the gateway.
All CAN messages (arbitration ID’s) present in
the snapshot are a subset of those present in the
HRL when comparing each bus individually. We
therefore assume that HRL’s contain unfiltered
CAN data in the post-trigger section, whereas the
snapshot raw CAN log is filtered by what is rele-
vant for the Autopilot module. Unfortunately we
have not been able to test our assumption that
HRL’s contain all CAN messages yet. This could
be done by recording all three buses simultane-
ously but would also require the triggering of an
event to start the recording of an HRL. Which
specific events would do so, other than a deploy-
ment event, is yet unknown to us.
HRL
RAW
Vehicle
0
3
Party
1
0
Chassis
2
1
Radar
-
2
Table 1: CAN bus names of bus identifiers in
HRL and RAW logs for Model 3
Figure 8: Snapshot versus HRL timestamps
Francis Hoogendijk - Reverse engineering and evaluation of Tesla vehicle logs
- 9 -
Autopilot behaviour
All log formats we described contain data
regarding the operation of driver assistance
systems which are absent in EDR files.
Depending on which log files are available the
level of detail may vary. Analyzing such system
state signals is preferably done using multiple
linked interactive plots to also view signals like:
vehicle speed, throttle, steering wheel angle
and braking. For this paper though, we will only
highlight some situation details as examples
due to limited space.
The first example shows throttle application by
the driver being recorded as an ‘override’ state
of the cruise control in Figure 9.
A second example of information about the
driver assistance systems is shown in Figure
10. This figure illustrates the activation of
Autopilot after the driver taps the right stalk
down twice in short succession.
Discussion
Tesla vehicles record detailed logs including the
operational state of its driver assistance systems.
The encoding of these logs is proprietary and re-
quires reverse engineering efforts to analyze.
The envisioned update to EDR regulations, in-
cluding the Data Storage System for Automated
Driving (DSSAD) [15] might possibly make this
information more accessible to investigators. We
are not aware of other vehicle manufacturers that
currently record data at such level of detail over
long periods of time.
Having this kind of data available enables more
detailed investigations of accidents, particularly
on the role of the driver assistance systems. As
an example: in a Dutch case it has shown how a
driver became overly confident in the perfor-
mance of the Autopilot system. He was dis-
tracted for several seconds after failing to notice
he only activated the adaptive cruise control and
not the lane keeping assistant. This caused the
Tesla to veer into oncoming traffic, resulting in a
fatal crash [16].
Another application of objective analysis of the
vehicle logs is the investigation of Sudden Unin-
tended Acceleration (SUA) events. In these
events the driver may think the system is at fault,
making him or her less likely to accept logs sup-
plied by Tesla. Furthermore, the HRL logs in
Model 3 vehicles can provide a very detailed pic-
ture of throttle application in these cases as it
contains the signal at its original transmission
rate in contrast to the regular log or EDR data
which would otherwise be the only information to
use.
Even though the regular gateway logs do not
contain any GPS information, it is still possible to
reconstruct a driven route to some extent. If one
knows or assumes a location and heading in
time, it is feasible to use the vehicle speed, steer-
ing wheel angle and lateral acceleration signals
as dead-reckoning information. This approach
was used by us [3] and also by NTSB investiga-
tors [9].
Figure 9: Driver overriding cruise control
Figure 10: Driver activates Autopilot by double
tapping the right stalk downwards
Francis Hoogendijk - Reverse engineering and evaluation of Tesla vehicle logs
- 10 -
References
[1] Tesla Motors, "Model 3 owners manual," [Online].
Available:
https://www.tesla.com/sites/default/files/model_3_ow
ners_manual_north_america_en.pdf. [Accessed
2021-5-14].
[2] NTSB, "Docket HWY16FH018," [Online]. Available:
https://data.ntsb.gov/Docket?ProjectID=93548.
[Accessed 2021-5-14].
[3] Spek A, „Anatomy of a car-following accident,“
Proceedings of the 29th Annual Congress of the
European Association for Accident Research, 2021.
[4] NHTSA, "National Highway Traffic Safety
Administration, Rule 49 CFR Part 563, Event Data
Recorders," [Online]. Available:
https://one.nhtsa.gov/Laws-&-Regulations/Vehicles.
[Accessed 2021-5-14].
[5] Tesla Motors, "Tesla EDR Resources," [Online].
Available: https://edr.tesla.com. [Accessed 2021-4-
15].
[6] Tesla Motors, “Obtain a Copy of the Data Associated
With Your Tesla Account,” [Online]. Available:
https://www.tesla.com/support/privacy. [Accessed
2021-7-1].
[7] Tesla Motors, “Privay & Legal,” [Online]. Available:
https://www.tesla.com/about/legal. [Accessed 2021-
7-1].
[8] NFI, "teslalogs," [Online]. Available:
https://github.com/NetherlandsForensicInstitute/teslal
ogs. [Accessed 2021-5-14].
[9] NTSB, "AUTOMATION AND DATA SUMMARY
FACTUAL REPORT, Mountain View, CA
HWY18FH011," [Online]. Available:
https://data.ntsb.gov/Docket?NTSBNumber=HWY18
FH011. [Accessed 2021-5-14].
[10] National Security Agency, "Ghidra," [Online].
Available: https://ghidra-sre.org/. [Accessed 2021-5-
14].
[11] tesla-info.com, "Tesla feature differences by
hardware," [Online]. Available: https://tesla-
info.com/blog/tesla-feature-differences-by-
hardware.php. [Accessed 2021-5-14].
[12] Bouchard Y, "Tesla’s Deep Learning at Scale: Using
Billions of Miles to Train Neural Networks," [Online].
Available: https://towardsdatascience.com/teslas-
deep-learning-at-scale-7eed85b235d3. [Accessed
2021-5-14].
[13] twitter, "greentheonly," [Online]. Available:
https://twitter.com/greentheonly. [Accessed 2021-5-
14].
[14] cgsecurity, "PhotoRec," [Online]. Available:
https://www.cgsecurity.org/wiki/PhotoRec. [Accessed
2021-5-14].
[15] UNECE, "Comparison between Event Data Recorder
(EDR) and Data Storage System for Automated
Driving (DSSAD)," [Online]. Available:
https://unece.org/DAM/trans/doc/2019/wp29/WP29-
179-19.pdf. [Accessed 2021-5-14].
[16] De Rechtspraak, "Dutch court verdict of case
ECLI:NL:RBOBR:2019:5057," [Online]. Available:
https://linkeddata.overheid.nl/front/portal/document-
viewer?ext-id=ECLI:NL:RBOBR:2019:5057.
[Accessed 2021-5-14].
Contact
Netherlands Forensic Institute
Dept. Forensic Digital Technology / Automotive
Laan van Ypenburg 6
2497GB, The Hague, The Netherlands
E-mail:
verkeer@nfi.nl
Tel:
+31 70 8886490
