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
|
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 |
||
|
- 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. |
|
|
|
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 |
||
|
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. |
||