Technical Bulletin

Driver Status Monitoring
Dossier GuidanceVersion 1.0.1

June 2023
TB 036

TitleVersionDocument Number
AuthorDate
Related Documents
StatusApplication Date

Driver Status Monitoring – Dossier Guidance
1.0.1
TB 036
Euro NCAP
June 2023
Euro NCAP Assessment Protocol - SA Safe Driving - v10.2
Information
1st January 2023

Copyright ©Euro NCAP 2023 - This work is the intellectual property of Euro NCAP. Permission is granted
for this material to be shared for non-commercial, educational purposes, provided that this copyrightstatement appears on the reproduced materials and notice is given that the copying is by permission ofEuro NCAP. To disseminate otherwise or to republish requires written permission from Euro NCAP.

Preface
DISCLAIMER: Euro NCAP has taken all reasonable care to ensure that the information
published in this document is accurate and reflects the technical decisions taken by theorganisation. In the unlikely event that this protocol contains a typographical error or any
other inaccuracy, Euro NCAP reserves the right to make corrections and determine theassessment and subsequent result of the affected requirement(s).

EUROPEAN NEW CAR ASSESSMENT PROGRAMME (Euro NCAP)

Table of Contents

1.

Introduction ..................................................................................................................... 1

2.

Driver Status Monitoring Dossier Guidance ................................................................... 2
2.1

System overview ...................................................................................................... 2

2.2

Predicted DSM score ............................................................................................... 3

2.3

Noise variables ......................................................................................................... 4

2.4

Detection of driver status ......................................................................................... 8

2.5

Vehicle response requirements .............................................................................. 10

2.6

Validation method / test campaign ........................................................................ 12

2.7

KPI Reporting ........................................................................................................ 13

1.

Introduction

The assessment of Driver Status Monitoring (DSM) systems is detailed in the Euro NCAP
Assessment Protocol – Safety Assist, Safe Driving. This assessment is based on information
provided to Euro NCAP by the Original Equipment Manufacturer (OEM) along with spot
testing that is conducted by the Euro NCAP laboratories.
Euro NCAP requires the OEM to provide a dossier, that contains sufficient technical detail of
all DSM assessment areas. This must be provided to the Euro NCAP Secretariat before any
testing begins.
This Technical Bulletin is supplementary to the assessment protocol and provides guidance
regarding the structure and content required in the dossier. The dossier must contain a full andcomprehensive description of the DSM system detailing all hardware, its capabilities andjustification to demonstrate that the system covers a wide variety of the driver population andis robust. Further details of how this can be achieved is detailed in the subsequent sections of
this Technical Bulletin.
NOTES:- The prerequisites for scoring in the DSM assessment are detailed in Section 3.3 of the
Safe Driving protocol. The information provided by the OEM may consist of a rangeof formats including flowcharts, photographs, videos, plots and written descriptions of
the system functionality.
- The information in this document is for guidance only and only complements theassessment protocol. If any information is missing or contradicting the information in
the assessment protocol, it is the responsibility of the OEM to ensure that the
information required in the assessment protocol is provided.

Version 1.0.1
June 2023

1

2.

Driver Status Monitoring Dossier Guidance

The dossier must contain all of the sections detailed below and be structured in the same order.
Where a system does not have a particular functionality, the related chapter must not be skipped
and the reasoning behind this absence should be elaborated.
Table of contents:
1. System Overview
2. Predicted DSM score
3. Noise variables
3.1. Driver
3.2. Occlusion
3.2.1. Prerequisite
3.2.2. Inform if degraded3.3. Driver behaviours
4. Detection of driver status
3.1 Distraction
3.2. Fatigue
3.3. Unresponsive driver
5. Vehicle response requirements
6. Validation method / test campaign
7. Annexes
Note: include references to and location of supporting documentation (pictures, videos etc)

2.1 System overview
This section is intended to summarise the main system functionalities as well as reflectingthat it meets the general requirements specified in the protocol. It shall include, but is not
limited to, the items detailed inTable 2-1.
Table 2-1 Sample of the OSM system overview[Vehicle Make] – [Model] : [System Name]
System Features & Functionality
Default ON at the start of every journey
Fitted as standard equipment
Number of steps required to deactivate the system
Monitoring typeOperational speed range (Direct monitoring systems) [km/h]
Operational speed range (Indirect monitoring systems) [km/h]
Fatigue Detection
Distraction Detection
Unresponsive Driver
Sudden Sickness detection (For information)
Driver Under Influence detection (For information)
Cognitive Distraction detection (For information)
Version 1.0.1
June 2023

Result☐Yes ☐No☐Yes ☐No☐Direct ☐Indirect☐Yes ☐No☐Yes ☐No☐Yes ☐No☐Yes ☐No☐Yes ☐No☐Yes ☐No2

To be included:- Schematics, pictures, videos, etc. to detail the type of sensor(s) involved in thesystem, their location in the vehicle, their function/role, and all their relevant
specifications (e.g. camera Field of View). Furthermore, if applicable, provide a listof the constituent elements of indirect monitoring (e.g. steering input, vehicle
dynamics), and indicate in detail how their data feed complement/contribute to theoverall system performance.
- For direct monitoring systems, specify in a drawing all the delimited areas/regions in
the vehicle interior (from the driver’s perspective) at least for each of the gazelocations specified in the protocol, and if applicable, additional areas/regions which
the system takes into account to assess driver distraction.
- Details regarding the warning(s) to indicate the constituent components, i.e. audible,
visual and haptic components along with their location and duration.

2.2 Predicted DSM score
The OEM shall reflect a predicted score for the DSM based on system performance acrossthe different test cases, as reflected in Table 2-2.
Table 2-2 Predicted DSM score
Distraction Scenario

Movement
Type
Owl

Long
Distraction

Away from road / nondriving task

Driving task

Distraction

Away from road / nondriving task
Short
Distraction(VATS)

Driving task
Away from road (multilocation)

Phone Use

Phone Use Detection Basic
Phone Use Detection Advanced

Predicted score
Warning

Intervention

Sub
Total

Total

LizardBody Lean
Owl
LizardOwl
LizardOwl
LizardLizardOwl +LizardLizardDrowsiness
Fatigue

Microsleep
Sleep

Unresponsive Driver
Total

Version 1.0.1
June 2023

3

2.3 Noise variables
This chapter shall provide a quick overview of the system capabilities with regard to Noise
Variables requirements, whereas further detail is given in the following subchapters. Table 2-3
Summary of noise variables specified in the protocol and it serves as a guidance to check thatthey have been addressed in the dossier.
Table 2-3 Summary of noise variables (checklist) – For direct monitoring systems only

Category

Driver

Occlusion

Driverbehaviours

Noise variable
Age
Sex
StatureSkin complexion
Eye lid aperture
Lighting
EyewearFacial Hair (short)
Hand on Wheel
Facial occlusion
EyewearEyelash Makeup
Facial Hair (long)
EatingTalking
Laughing
Singing
Smoking & vaping
Eye scratching & rubbing
Sneezing

Addressed in
dossier(Checklist)

SystemRequirement

☑
☑
☑
☑

Must

☑
☑
☑
☑
☑
☑
☑

Inform driver if
degraded

☑
☑
☑
☑
☑
☑
☑
☑
☑

Information only:(indicate system
performancedegradation for eachof the behaviour
variables)

To be included:
A matrix which for all noise variables listed in Table 2-3 (as well as the addressed noise
variable combinations) reflects at a glance:- The system capabilities/performance (e.g. true positive ratio and false positive ratio)- Quick statement of system reaction when impaired (totally or partially)

Version 1.0.1
June 2023

4

2.3.1

Driver

The dossier shall include evidence that the system is capable of monitoring a driver populationthat falls within the required ranges of all the variables reflected in Table 2-4.
Table 2-4 Driver noise variables

DRIVER Noise variables
REQUIRED RANGE
Youth (16-18) – aged (≥80)
All
Adult Female 5th%-ile – Adult Male 95th%-ile
Fitzpatrick Skin Type (1 - 6)
From 6.0mm up to 14.0mm

VARIABLE
Age
Sex
StatureSkin complexion
Eyelid aperture
Requirement: Must

To be included:
Evidence demonstrating the system performance against a dataset which includes the rangeof population variables in Table 2-4 (using real human-beings with the required physicalproperties).

2.3.2 Occlusion
2.3.2.1 Prerequisite
The dossier shall include evidence showing that the DSM system performance is not degradedwhen put under the variables and ranges summarised in Table 2-5 . Note that it is not required
to demonstrate all occlusion variable combinations.

Table 2-5 Occlusion elements and ranges (Prerequisite)

VARIABLE
Lighting
EyewearFacial hair

OCCLUSION Noise variables (Prerequisite)
REQUIRED RANGE
Daytime – night-time (lux levels specified in the protocol)
Clear glasses and sunglasses (transmittance specified in the protocol)
Short facial hair (length specified in the protocol)

Requirement: Must
To be included:
Evidence demonstrating the system performance against a dataset which includes all therequired variables in Table 2-5, with a reasonable sampling of combinations, but with noneed to report against each variable separately. This is to be reported with a standard test
subject and with 2 or more subjects near the extremes of the values reflected in Table 2-4.
See reporting options on 2.7 KPI Reporting.

Version 1.0.1
June 2023

5

2.3.2.2 Inform if degraded
The dossier must provide evidence reflecting the system performance (and eventually, system
reaction upon impairment) when facing the ‘Inform if degraded’ elements and ranges listed inTable 2-6. Note that it is not required to demonstrate all occlusion variable combinations.
The “Inform if degraded” assessment shall be made during normal driving (i.e. not during a
distraction or fatigue sequence). It is allowed to use synthetic data acquired with driving
simulator, providing this data is representative and high quality.
Table 2-6 Occlusion elements and ranges (Inform if degraded)

OCCLUSION Noise variables (Inform if degraded)
VARIABLE
REQUIRED RANGE
Hand on wheel
One hand on wheel at 12 o’clock position
Facial occlusion
Face-mask, hats, long head hair fringe obscuring eyes
EyewearSunglasses with a <15% transmittance
Eyelash makeup
Thick eyelash make-up
Facial hairLong facial hair (>150mm in length)
Requirement: Inform if degraded
To be included:
Evidence demonstrating the system performance against a dataset which includes all therequired variables in Table 2-6, with a reasonable sampling of combinations, but with noneed to report against each variable separately. This is to be reported with a standard test
subject and with 2 or more subjects near the extremes of the values reflected in Table 2-4.
See reporting options on 2.7 KPI Reporting.
Infographics (e.g. schematics, videos…) illustrating the warning/information type, withsupporting evidence that these are issued no later than the required time after the system isimpaired.
Details, with justification, as to why a particular situation (combination of noise variables)
leads to performance degradation (total or partial).
Similarly, where a system is able to perform under conditions beyond the required noise
variables identified by Euro NCAP, the OEM is encouraged to include details of where thisis the case and illustrate the system capabilities.

Version 1.0.1
June 2023

6

2.3.3

Driver Behaviours monitoring

The dossier shall describe if and how the DSM system performance is affected by the driver
behaviours shown in
Table 2-7.
This is for monitoring purposes only, hence there are no performance requirements.
Table 2-7 Driver behaviour elements

Driver Behaviours
EatingTalking
Laughing
Singing
Smoking / vaping
Eye scratching / rubbing
Sneezing
Requirement: Monitoring (No performance requirement)
To be included-

List of driver behaviours that affect the system performance (including but notlimited to all the elements reflected in Table 2-7).
Evidence demonstrating performance degradation of the system when put against thelisted driver behaviours. This is to be reported with a standard test subject as aminimum (optionally with 2 or more subjects near the extremes of the values
reflected in Table 2-4). See reporting options on 2.7 KPI Reporting.

Version 1.0.1
June 2023

7

2.4 Detection of driver status
The driver status may fall into ‘distracted’, ‘fatigued’, and ‘unresponsive’ minimum
categories (Table 2-8). If alternative or additional inputs are deemed necessary for the system
to classify the driver status, the dossier shall include a section describing such inputs andjustifying the safety benefits.
Table 2-8 Detection of driver status

Distraction
Long Distraction
Short Distraction (VATS)
Phone Usage
2.4.1

Fatigue
Drowsiness
Microsleep
Sleep

Unresponsive drivere.g. Sudden Sickness

Distraction

The dossier shall include evidence that the system is able to classify a driver as ‘distracted’,as well as how the system differentiates such distraction (Long Distraction / ShortDistraction), in each of the scenario, movement type and gaze location combination shown in
the protocol.
Table 2-9 Distraction scenarios (summary)

Driver Status
Long
Distraction
Short Multiple
Distraction(VATS)
Phone Usage

Scenario
Away from forward road,non-driving task
Driving task
Away from forward road(one location)
Driving task
Away from road (multiple
locations)
Basic Phone Detection
Advanced Phone
Detection

Movement

Gaze locations

Owl
LizardBody Lean

Various

To be included:-

Video showing driver classification & system status in all the driver distraction
elements listed in Table 2-9, ideally reflecting live system parameters (Figure 2-1)
Minimum operational requirements above which the system is able to classify adriver as distracted (as per the elements listed in Table 2-9).
Detail and justification of any alternative system input(s) / strategies other than gazelocation to assess distraction, if applicable (e.g. combination with steering input).
Description of OEM-specific identification of the timing the distraction is being
counted from.

Version 1.0.1
June 2023

8

Figure 2-1 Live system parameters embedded in video (Source: YouTube – Tesla)

2.4.2

Fatigue

The dossier shall include evidence that the system is able to classify different stages of driver
fatigue (drowsiness, microsleep, sleep) and the system requirements to achieve suchclassification. In the case of the OEM not being able to satisfy the driver’s fatigue classification,or the approach being different / going beyond the requirements (specified in the protocol), thedossier shall reflect a description and justification for such lack of performance or alternative
approach.
Table 2-10 Fatigue status

DriverstatusDrowsiness
Microsleep
Sleep

Requirements
Driver reaches (at least) KSS level >7
Eye closure duration <3s seconds
Slowed reflexes, frequent nodding (or other behaviours declared by
the manufacturer to correlate to microsleep)
Eye closure >3 seconds

To be included:-

Video showing driver classification & system status in all required driver fatigue
status (Drowsiness, Microsleep, Sleep), ideally reflecting live system parameters(Figure 2-1).
Minimum system requirements to achieve driver fatigue status classification.
Detail and justification of any alternative system input(s) / strategies other than theones indicated (e.g. KSS scale for Drowsiness, eye closure for Microsleep…), if
applicable.

Version 1.0.1
June 2023

9

2.4.3

Unresponsive driver

The dossier shall include evidence that the system is able to classify the driver under ‘Sudden
Sickness’ and the minimum system requirements to achieve such classification. If the OEM
uses more advanced systems using different/ additional inputs to determine the driver isunresponsive (as specified in the protocol), these should be detailed in the dossier.
Table 2-11 Unresponsive driver conditions

DriverStatusUnresponsive
DriverRequirements
Driver who either does not return their gaze to the forward roadview within the required time after the inattention warning being
issued, or
Driver whose gaze has been away from the forward road view, oreyes has been closed for more than the required time.

To be included:-

Video showing driver classification & system status in the indicated scenarios
described in Table 2-15, ideally reflecting live system parameters (Figure 2-1).
Minimum system requirements to achieve unresponsive driver status classification.
Detail and justification of any alternative system input(s) / strategies other than theones indicated, if applicable.

2.5 Vehicle response requirements
The dossier shall describe with detail the vehicle response (warnings / system intervention)for each of the inattention categories specified in the protocol (Table 2-12), providing foreach of them additional supporting information in the form of pictures, schematics, videos,etc. Further details on how to approach high sensitivity FCW and/or LDW (if chosen as asystem intervention strategy) are specified in the protocol.
Table 2-12 Inattention categories for which vehicle response is required

Distraction
Long Distraction

Fatigue
Drowsiness

Short Distraction (VATS)
Phone Usage

Microsleep
Sleep

Version 1.0.1
June 2023

Unresponsive driver
Sudden Sickness (Example)

10

2.5.1

Distraction
Table 2-13 Vehicle response requirements - Distraction

Driver Status
Long
Distraction
Short
Multiple
Distraction(VATS)

Phone Usage

Warning Requirements
Immediate visual +(haptic or audible)
warning issued when:- Vehicle speed
20km/hand- Driver isclassified as
distracted (either
for long
distraction,
VATS or phone
usage)

Intervention Requirements- High sensitivity FCW
setting, activated ≤1
second of continuous
gaze away from forward
road viewor- Low level braking
intervention, beginning
immediately after thedriver is classified as
distractedor- Any other intervention
that the OEM considers
to be appropriate.

To be included:-

Description and infographics (e.g. schematics, pictures…) illustrating theintervention approach used.
Video showing driver, system status and system response for each of the distraction
scenarios, evidencing that the system intervenes at the right time.
If a different approach other than the ones indicated is used, details on the alternative
approach and the evidence of the safety benefits of its implementation shall be
included.

2.5.2

Fatigue
Table 2-14 Vehicle response requirements - Fatigue

Driver status
Drowsiness
Microsleep
Sleep

Warning
Requirements
Immediatevisual + (haptic
or audible)

Intervention Requirements- High sensitivity FCW and LDW
setting, to be activated immediately
after driver is classified as drowsy
or- Any other intervention that the
OEM considers to be appropriate.

To be included:-

Description and infographics (e.g. schematics, pictures…) illustrating theintervention approach used.
Video showing driver, system status and system response for each of the fatigue
scenarios, evidencing the appropriate system intervention.
If a different approach other than the ones indicated is used, details on the alternative
approach and the justification behind it shall be included.

Version 1.0.1
June 2023

11

2.5.3

Unresponsive driver
Table 2-15 Vehicle response – Unresponsive driver

Driver status

Intervention Requirements

Unresponsive
DriverA minimum risk manoeuvre, meeting the requirements of
UNECE R79 risk mitigation function, should be initiated,
where the distinct warning phase begins <1 second after adriver is classified as unresponsive.

To be included:-

Description and infographics (e.g. schematics, pictures…) illustrating the details of
the minimum risk manoeuvre.
Video showing driver, system status and system response, evidencing that the system
initiates the minimum risk manoeuvre at the right time.
If a different approach other than the minimum risk manoeuvre as described in UN
R79 is used, details on the alternative approach and the justification behind it shallbe included.

Note: include references to and location of supporting documentation (pictures, videos etc)

2.6 Validation method / test campaign
This section shall describe the approach and process followed by the OEM in validating thesystem performance. This section will help illustrate the degree of effort which was put into
validating the system performance, and whether the system was aimed to accomplish minimum
protocol requirements, or intended to go beyond them.
To be included (but not limited to):Preliminary study/research taken into account (e.g. accidentology, test campaigns, own fleet
data…), type of validation method used (e.g. physical, simulation) and details about eachmethod, noise variables taken into account during testing (e.g. driving conditions, lighting
conditions, driver gender/ethnicity, sensor partial/total blindness…), test population sample.

Version 1.0.1
June 2023

12

2.7 KPI Reporting
2.7.1

Average and Standard Deviation True Positive Ratio

In this approach, performance for each detection requirement is provided based on
testing against data which includes all the noise factors required by the protocol (I.e.
OEMs provide evidence of performance in the presence of noise factors).
It consists of:• Report the test case count for each detection requirement.
• Report the average and standard deviation of the true positive rate for eachdetection requirement, across all subjects in the dataset.
• Report the content of the dataset used to measure performance, with categories
for all the demographic aspects and noise factors specified in the protocol.
To illustrate the approach, an example of 20 subjects covering the demographic
requirements is given to populate the performance in each of the 43 required
distraction cases (fatigue cases shall be included as well on top of distraction cases).
Additionally, an example of the case count used for each distraction case in thepresence of the specified noise factors is given.
2.7.1.1 Dataset demographics
The following example illustrates the used subject count for the required demographic
requirements. A table with fatigue requirements shall also be provided.
Property
StatureSex
AgeComplexion

Eyelid Aperture
Total

Version 1.0.1
June 2023

0-5
6-94
95-100Male
Female
16-18
19-79
80+
I
II
III
IV
V
VI
0-6
7-11
12+

Subject Count
1
18
1
12
8
1
18
1
6
5
2
4
1
2
3
16
1
20

Proportion
5%
90%
5%
60%
40%
5%
90%
5%
30%
25%
10%
20%
5%
10%
15%
80%
5%
100%

System Requirement
Must Support
Must Support
Must Support
Must Support
Must Support
Must Support
Must Support
Must Support
Must Support
Must Support
Must Support
Must Support
Must Support
Must Support
Must Support
Must Support
Must Support

13

2.7.1.2 Dataset Noise Factors
The following example shows a small dataset satisfying noise factor requirements.
There are 43 unique distraction cases considering all specified glance targets. Thereare 20 subjects. If each subject records every case once, there are 860 cases total.
Property
Occlusion<1 LuxLighting
2-100k>100k
None
Eyewear
BenignBlocking
None
Facial Hair
Short (<20mm)
Long (>150mm)
Blocking
Hand PositionNon-blocking
None
Face Masks
Facial Occlusion
Hat
Long Hair
None/Light
Eye Makeup
Heavy
Secondary Behaviors
EatingTalking
Laughing
Singing
Smoking/Vaping
Eye Scratching
Sneezing
Total

Version 1.0.1
June 2023

Case Count

Proportion

System Requirement

43
774
43
716
129
15
688
129
43
39
821
731
43
43
43
817
43

5%
90%
5%
83%
15%
2%
80%
15%
5%
5%
95%
85%
5%
5%
5%
95%
5%

Must Support
Must Support
Must Support
Must Support
Must Support
Inform If DegradedMust Support
Must Support
Inform If Degraded
Inform If DegradedMust Support
Must Support
Inform If Degraded
Inform If Degraded
Inform If DegradedMust Support
Inform If Degraded

43
43
43
43
43
43
43
860

5%
5%
5%
5%
5%
5%
5%
100%

Information Only
Information Only
Information Only
Information Only
Information Only
Information Only
Information Only

14

2.7.1.3 Performance
The following example illustrates the number of cases tested to generate the associated
TPR average and standard deviation. The example reflects only the 43 required
distraction cases (it shall be further expanded with fatigue cases).
TPR = true positive rate. For noise factors rated "must support", true positive means
detecting distraction. For those rated "inform if degraded" true positive means
detecting distraction or correctly reporting degraded. Each subject will have a
different TPR, resulting in a standard deviation and average TPR across all subjects inthe dataset.

Behavior

GlanceTargetGlanceBehavior

Owl
NonDriving
Task
LizardLong
Distraction

Body
Lean
Owl
Driving
Task
LizardOwl
Short
Distraction(VATS)

Driving
Task
LizardAway
From Road(SingleTarget)Version 1.0.1
June 2023

Owl

Glance Target

Driver Side Window
Passenger Side
Window
Passenger Footwell
Passenger FaceIVI Display
IVI Display
Glovebox
Passenger Footwell
Rear Passenger
Rear Mirror
Passenger Side
MirrorDriver Side Mirror
Instrument Cluster
Driver Side Mirror
Rear Mirror
Rear Mirror
Passenger Side
MirrorDriver Side Mirror
Instrument Cluster
Driver Side Mirror
Rear Mirror
IVI Display
Passenger Side
Window
Passenger Footwell

Test
Case
Count

TPR
AverageAcrossSubjects(%)

TPR
Standard
Deviation
AcrossSubjects
(%)

100

40
40
60

60

60

60

60

15

Away
From Road(Multiple
Targets)

LizardDriver Side Window
IVI Display
Passenger Footwell

60

Lizard

Any

20

Owl

Basic
(VisualDistraction)
Phone Use

LizardAdvanced(Cognitive
Distraction)

2.7.2

LizardDriver Side Knee
Passenger Side Knee
Driver Lap
Driver Side
Dashboard
OEM Charging dock
Driver Side Knee
Passenger Side Knee
Driver Lap
Driver Side
Dashboard
Upper Wheel Rim
Center Steering
Wheel
OEM Charging dock
Held At On Road
Held At Instrument
Cluster
Forward view ofWindscreen

100

140

60

Standard test subject + 2 Extreme test subjects of driving population

Where required, the OEM shall evidence the performance of the DSM when put underocclusion variables, by using a KPI per used test subject (or group of test subjects):- Standard test subject: falling within driving population range of Table 2-4- Extreme test subject #1: extreme (upper) of driving population range Table 2-4- Extreme test subject #2: extreme (lower) of driving population range Table 2-4

Version 1.0.1
June 2023

16