Page tree

Comparison between Event Data Recorder (EDR) and Data Storage System for Automated Driving (DSSAD)

This document aims at providing a comparison between Event Data Recorder (EDR) and Data Storage System for Automated Driving (DSSAD) , as a first outcome of the joint GRVA/GRSG informal group on EDR/DSSAD, per the request of WP.29 at their 178 th session (June   2019), the revised Framework Document ECE/TRANS/WP.29/2019/34/Rev.1 and the informal group terms of reference as reflected in the official report of that WP.29 session (Annex   VII).

This document was reviewed, completed and corrected by GRVA at their 4 th   session (24-27   September   2019) and GRSG at their 117 th session (8-11   October 2019).

GRVA and GRSG both provided guidance to the IWG regarding the scope (categories of vehicle) of the future regulatory texts. The square brackets (   [   ]   ) in the table mean that some values and provisions need further work within the IWG.

 

EDR-DSSAD:  Comparison table

 

Items

EDR for conventional vehicles

EDR for ADs

 

DSSAD

(L3-L4)

Scope

(categories of vehicles in the text)

Step1: Passenger cars and light duty vehicles (Vehicle categories according to R.E.3: M1, N1)

 

Step 2: Heavy duty vehicles (Vehicle categories according to R.E.3: M2,M3,N2, N3)

Step1: Passenger cars and light duty vehicles of automation level 3 or 4 with ALKS

 

Step 2: Heavy duty vehicles

 

System

 

 

 

Purpose

(why do the contracting parties want to introduce this function into the vehicle?)

Accident analysis

 

Research, monitoring, liability, legal responsibility

What the system should not do

-      Detecting who is driving

-      Identifying the owner/holder of the vehicle on the basis of the stored data.

-      [Allowing for the tracking of the owner/the user/the holder of the vehicle]

-      Providing information about the surroundings of the vehicle

-      Providing data that are already available in the EDR

-      Identifying the user/owner/holder of the vehicle

-      [Allowing for the tracking of the owner/the user/the holder of the vehicle]

Recording period

[X s] b efore event / [X ms ] after event

May be longer for AD system than for conventional vehicles

As long as ALKS is engaged/stand-by.

System storage capabilities

 

At least [1 to 3] events

 

-           Several months (relevant figure TBD) anticipated, or

-           several thousands of interactions anticipated,

whichever is achieved first.

Capability to record data during a crash event

 

Resistance to high deceleration and mechanical stress of a severe impact

TBD

Data survivability after a crash event

Resistance to high deceleration and mechanical stress of a severe impact

Trigger to initiate the data storage

“Event” (e.g. crash): physical occurrence that causes the trigger threshold to be met

“Interaction”:

-           change in the system operation status, or

-           demand for a change in the system operation status

Battery restitution

All data mandatory per the table of EDR parameters must be stored after an event.

Final requirement to be aligned on demand from ACSF informal group

Environmental robustness (vibrations, etc.)

Out of scope: the vehicle is crashed when data are stored, and not subject to any specific vibrations or other environmental aggression

Requirements fully linked to those of DSSAD

Malfunction detection

NA*

*EDR malfunction is not detrimental to occupant safety

Requirements fully linked to those of ALKS.

DSSAD will self-diagnose via ALKS

PTI

TBD

TBD

Data technique

 

 

 

Where to store (in the vehicle vs. the cloud)

Technology neutral provisions; the request is that “data are available and retrievable”

Data format

The final authorized user (will be defined by national legislation) must get the data in a comprehensive format, without any risk of corruption.

Data element

TBD

TBD

Storing duration

Not less than 10 days after EDR is triggered

Several months if EDR is not triggered (to be determined according to storage capacity)

 

Not less than 10 days after EDR is triggered (same as EDR)

Retrieval means

Technical regulation is technology neutral

 

Accuracy

According to the table of EDR parameters

-           Accuracy relevant for the purpose (research, monitoring, reliability, legal responsibility)

-           The “data elements” must be stored in the order of occurrence.

Access means

Technical regulation is technology neutral

Erasing means

FIFO type, when the memory is full, by overwriting

Sampling rate

About 100   Hz, depending on the parameter

NA

Data identification (this data really belongs to that vehicle)

-           VIN incorporated in data set if data are stored outboard

-           VIN optional in data set if data are stored inboard

Triggering parameter

Examples: high deceleration, airbag inflation, AEBS activation, ESF activation, etc.

Significant interactions between the ALKS and the human driver, when ALKS is engaged or in standby mode, and significant system changes or malfunctions.