Preventive and Active Safety Applications

Integrated Project
Contract number FP6-507075
eSafety for road and air transport

Code of Practice
for the
Design and Evaluation
of ADAS

Version number V5.0

Aug. 2009
 Code of Practice for the Design and Evaluation of ADAS

Foreword
The Code of Practice (CoP) comprises a suitable ADAS (Ad-
vanced Driver Assistance System) description concept including
ADAS specific requirements for system development. It summa-
rises best practices and proposes methods for risk assessment
and controllability evaluation. The Code of Practice has been pro-
duced by a group of experts within the RESPONSE 3 project, a
subproject of the integrated project PReVENT, a European auto-
motive industry activity, co-funded by the European Commission,
to contribute to road safety by developing and demonstrating pre-
ventive safety applications and technologies.

The RESPONSE 3 project ended in October 2006 delivering the

Code of Practice in its version 3.0. This document is a retranslation
of a German adaption.

The contact persons for the German adaption are:

Andreas Knapp (DCAG, D)

Markus Neumann (VW, D)
Martin Brockmann (FORD subc, D)
Rainer Walz (BMW, D)
Thomas Winkle (AUDI, D)

Response3_CoP_e_v5.0.doc Aug. 2009 ii

 Code of Practice for the Design and Evaluation of ADAS

Revision chart and history log

Version Date Reason
3.0 31.10.2006 Deliverable of the RESPONSE 3 project

3.04 31.10.2007 Draft of a english adaption according to German

version 3.5
3.6 10.12.2007 Included remaining open topics of comment sheet
and harmonized most recent changes with german
version (now also 3.6)
3.6.1 26.9.2008 Clarification of formulations and typo correction in
Annexes A.1 and A.2
4.0 15.12.2008 Formal revision of entire document (including
annexes) for distribution to ACEA members; no
change of content
5.0 13.8.2009 Formal revision of document for release by ACEA

Response3_CoP_e_v5.0.doc Aug. 2009 iii

 Code of Practice for the Design and Evaluation of ADAS

Table of contents
Foreword ....................................................................................... ii
Revision chart and history log ....................................................... iii
Table of contents ........................................................................... iv
Figures ...................................................................................... vi
Tables ...................................................................................... vi
1 Introduction.............................................................................1
1.1 Motivation ............................................................................1
1.2 Scope ..................................................................................2
2 Terms and Definitions ............................................................4
2.1 Definition of an Advanced Driver Assistance System
(ADAS) ................................................................................4
2.2 Glossary ..............................................................................4
2.3 Abbreviations.......................................................................9
3 Development process...........................................................11
4 Controllability........................................................................13
4.1 Final proof of controllability by an interdisciplinary expert
panel..................................................................................14
4.2 Final proof of controllability by means of a test with naive
subjects .............................................................................15
4.3 Final proof by direct recommendation of controllability sign-
off issued by the ADAS development team.......................15
5 Recommendations ...............................................................16
5.1 Definition phase.................................................................17
5.2 Best concept selection ......................................................19
5.3 Proof of concept ................................................................21
5.4 Detailed design..................................................................22
5.5 Verification.........................................................................23
5.6 Validation and sign-off.......................................................24

Response3_CoP_e_v5.0.doc Aug. 2009 iv

 Code of Practice for the Design and Evaluation of ADAS

ANNEXES ................................................................................... A2
Annex A Response procedures ................................................ A3
A.1 Checklist A – System specification................................... A3
A.2 Checklist B – Evaluation concepts for system ......................
specification.................................................................... A24
A.3 Hazard analysis and risk assessment procedure ........... A41
Annex B Recommendations for controllability evaluation ....... A46
B.1 Condense hazardous situations ..................................... A46
B.2 Conducting a test with subjects...................................... A47
B.3 How to setup pass-fail criteria ........................................ A50
B.4 How to evaluate controllability by experts ...................... A50
Annex C General methods for safety analysis ........................ A52
C.1 Early risk assessment by HAZOP .................................. A52
C.2 Failure Modes and Effects Analysis (FMEA) .................. A53
C.3 Fault tree analysis (FTA) ................................................ A54
C.4 Hardware in the loop (HIL) testing.................................. A55
Annex D General methods of assessment.............................. A57
D.1 Expert panel ................................................................... A57
D.2 HMI concept simulation .................................................. A59
D.3 Driving simulator test ...................................................... A60
D.4 Driving tests with professional test drivers ..................... A61
D.5 Car clinic with naive subjects ......................................... A63
Annex E Definition ADAS........................................................ A66
Annex F Documentation sheet................................................ A72
Annex G Criteria for HMI concept selection ..................................
(background information) .................................................. A74
G.1 Classification and evaluation according to driving tasks A74
G.2 Driver information perception ......................................... A75
G.3 Driver’s field of work ....................................................... A79
G.4 HMI architecture principles............................................. A81
Annex H References ............................................................... A83

Response3_CoP_e_v5.0.doc Aug. 2009 v

 Code of Practice for the Design and Evaluation of ADAS

Figures
Figure 1: Phases of a development process ................................11
Figure 2: Elements of a safety process and controllability ...............
concept.................................................................................12
Figure 3: Controllability Workflow. Dashed lines suggest revision
due to new information .........................................................14
Figure 4: The three driving task levels......................................... A4
Figure 5: Level of automation .................................................... A14
Figure 6: Methodology of risk assessment ................................ A41
Figure 7: Collection of driving situations .................................... A46
Figure 8: Extracting controllability related situations ................. A47
Figure 9: Driving task levels ...................................................... A68
Figure 10: Driver Assistance systems ....................................... A69
Figure 11: Examples of Driver Assistance systems................... A70
Figure 12: Simplified demonstration of field of view limits ......... A77
Figure 13: Limits of acoustic perception. ................................... A78
Figure 14: Detailed description of foot well and reach areas..... A79

Tables
Table 1: Abbreviations..................................................................10
Table 2: Mapping of phases from the developing process ..............
to sections in chapter 5 ........................................................16
Table 3: Categorisation of Severity ........................................... A43
Table 4: Categorisation of Exposure ......................................... A44
Table 5: Categorisation of Controllability for risk assessment ... A44
Table 6: Automotive Safety Integrity Level (ASIL) assignment.. A45
Table 7: Driver assistance systems and ADAS criteria ............. A67
Table 8: Concept comparison for HMI ....................................... A74
Table 9: Haptic perception......................................................... A79

Response3_CoP_e_v5.0.doc Aug. 2009 vi

 Code of Practice for the Design and Evaluation of ADAS

1 Introduction

1.1 Motivation
Advanced driver assistance systems will play a major role in road
safety in Europe. Experience gained from research on ADAS
shows, that many ideas have been applied in prototypes with
safety features, but only few have been introduced in series pro-
duction.
Existing technical limits as well as liability issues are currently de-
laying the market introduction of Advanced Driver Assistance Sys-
tems.
Resulting from the Response 1 project (1998 - 2001) the creation
of a Code of Practice (CoP) was proposed for the development
and validation of ADAS. This implies to establish “principles” for
the development and evaluation of ADAS on a voluntary basis, as
a result of a common agreement between all involved partners and
stakeholders, mainly initiated by ADAS manufacturers.
The proposal to establish such a Code of Practice was confirmed
by the Commissions Communication COM(2003) 542 of 15 Sep-
tember 2003.
The requirements for the Code of Practice have been elaborated
within the project RESPONSE 2 (2002 – 2004).
RESPONSE 3 has now finally developed the CoP to provide the
vehicle industry with the tools and common understanding to over-
come and to help managing the problems about safety concerns
and liability of Advanced Driver Assistance Systems.
The application of the CoP is a possibility to demonstrate that
state-of-the-art procedures in ADAS development have been ap-
plied, including risk identification, risk assessment and evaluation
methodology.
The current status of development makes it very difficult to de-
scribe the state-of-the-art knowledge of ADAS, because there are
so many systems with different technology addressing even more
different assisting functions.
This links the liability discussion to the question when a product is
called “defective”. The term "defective product" is used in the Euro-
pean Product Liability Directive not only in a technical sense but
also in the context of the use of a product. There it says: A product
is defective if it does not provide the safety a person is entitled to
expect, taking into account all circumstances, including: (a) the
presentation of the product; (b) the use to which it could reasona-
bly be expected to be put; (c) the time when the product was put
into circulation. This includes requirements for system design,
dependability, comprehensibility, predictability and misuse resis-
tance.
The RESPONSE 3 consortium is now encouraging all people in-
volved in the ADAS development to benefit from applying the
Code of Practice in their companies

Response3_CoP_e_v5.0.doc Aug. 2009 1

 Code of Practice for the Design and Evaluation of ADAS

1.2 Scope
The Code of Practice applies to advanced driver assistance sys-
tems (ADAS). It is not specifically intended to be applied to sys-
tems providing vehicle stabilisation (such as ABS and ESP) or
mere information and communication systems (such as navigation
systems and telephones). It may be applicable to systems includ-
ing vehicle to vehicle communication, but will not cover these
completely.
ADAS are designed to actively support the driver in the primary
driving task to either increase comfortable or safe driving. (see
Table 7 in Annex E for a list of systems). Systems that support the
driver by issuing warnings without intervention are not within the
scope of this CoP although the recommended approach and the
provided checklists may prove valuable also for these kinds of sys-
tems.
In contrast to conventional driver assistance systems, ADAS re-
quire the detection and evaluation of the vehicle environment with
the respective sensors and a complex signal processing depend-
ing on the driving task to be supported. This also includes collec-
tion and evaluation of infrastructure data if available. This func-
tional extension means a significant increase in system design
complexity since the vehicle environment is incorporated into the
assistance function. Due to the system limits of environmental
sensing systems, the usage of the assistance functionality will also
be limited. This implies that a direct interaction between the driver
and the system is necessary. This interaction has to be controlla-
ble also with regard to current legislation (Vienna Convention)
The CoP serves as a support tool for the engineer engaged in the
development of ADAS. CoP not only means a compilation of cur-
rently available procedures, but also offers clues for determining
activities to be performed during the individual development
phases.
Focus of the CoP is the system design against the background of
system controllability and the total vehicle from the field of view of
Human Machine Interaction. Of course system influences due to
occurring defects/errors do play an important role as well as ADAS
behaviour at system limits and foreseeable misuse.
Moreover, the CoP is also intended for automotive manufacturers
and suppliers dealing with specification, realisation and assess-
ment of ADAS. The CoP has been compiled by gathering best
practices of the partner companies and also considers legal re-
quirements and the RESPONSE 2 results
The CoP deals with specification and assessment of advanced
driver assistance systems during the entire development phase.
Therefore, it will not address issues arising after SOP (start of pro-
duction).
The CoP structure allows implementation as part of a company
specific development or quality process. Requirements are sup-
plied for each development stage and are clearly separated from
checklists and method descriptions in the document in order to
provide an overview for each task. The use of the checklist proce-
dure assists in the specification of ADAS in order to also consider

Response3_CoP_e_v5.0.doc Aug. 2009 2

 Code of Practice for the Design and Evaluation of ADAS

aspects which may not be obvious right from the beginning. The
hazard and risk analysis procedure provides assistance in setting
up a systematic analysis of driving situations in order to determine
potential risks.
The CoP also comprises the description of methods and tools for
the assessment of ADAS safety.
The CoP should not stipulate a uniform ADAS design. It should be
valid for various vehicle types and systems with many complexity
and integration levels for the application in all ADAS.
All in all the CoP aims at serving as a guideline assisting persons
involved in ADAS development to adhere to the state-of-the-art
knowledge with respect to risk identification and risk assessment
as well as methodology for the evaluation of driver controllability.

Response3_CoP_e_v5.0.doc Aug. 2009 3

 Code of Practice for the Design and Evaluation of ADAS

2 Terms and Definitions

2.1 Definition of an Advanced Driver Assistance System (ADAS)

This definition gives an overview and classification of ADAS as a
basis for the correct application of the CoP.
Driver Assistance Systems are supporting the driver in their pri-
mary driving task. They inform and warn the driver, provide feed-
back on driver actions, increase comfort and reduce the workload
by actively stabilising or manoeuvring the car.
They assist the driver and do not take over the driving task com-
pletely, thus the responsibility always remains with the driver.
ADAS are a subset of the driver assistance systems.
ADAS are characterised by all of the following properties:
• support the driver in the primary driving task
• provide active support for lateral and/or longitudinal control
with or without warnings
• detect and evaluate the vehicle environment
• use complex signal processing
• direct interaction between the driver and the system
With respect to the well-known categories of driving tasks, ADAS
are mainly focussing on the manoeuvring level. For a detailed de-
scription of driving tasks and typical ADAS please refer to Annex
E.

2.2 Glossary
1. Abbreviated Injury Scale: An anatomical scoring system for
ranking the severity of injury (Association for the Advancement
of Automotive Medicine).
2. Adaptive Cruise Control: Enhancement to conventional
cruise control systems, which allows the subject vehicle to fol-
low a forward vehicle at an appropriate distance by controlling
the engine and/or power train and potentially the brake. (ISO
15622)
3. Advanced Driver Assistance Systems (ADAS): See chapter
2.1 for a definition of ADAS.
4. Action: An event initiated by the driver or the application
5. Action slip: A human action deviating from the intended plan,
e.g. the driver want to shift gears but unintentionally pressed
the brake pedal due to a missing clutch in cars with automatic
transmission. An action slip often occurs if the driver is ab-
sentminded and may increase in frequency under stress. [Red
97]1

1
[Red 97]: Redmill, F ; Rajan, J: Human factors in safety critical
systems; butterworth-Heinemann 1997, p. 49

Response3_CoP_e_v5.0.doc Aug. 2009 4

 Code of Practice for the Design and Evaluation of ADAS

6. Architecture: The fundamental organisation (both Hardware

and Software) of a system embodied in its components, inter-
action among components, and to the environment, and the
principles guiding its design and evolution.
7. Automotive safety integrity level (ASIL): One of four steps to
specify the risk and its requirements for risk reduction with D
representing the highest and A the lowest risk reduction class
(ISO/WD 26262-1).
8. Behavioural Changes (Adaptation): Changes of the driver
behaviour, which may occur following the introduction of
changes to the road-vehicle-driver system.
9. Code of Practice (CoP): Guidelines for procedures and proc-
esses that may be used during specification and realisation of
ADAS in order to state reasonable safety and duty of care.
[IP_D4 06]2
10. Collision Avoidance: System for warning and avoidance of a
pending collision. [IP_D4 06]2
11. Collision Mitigation: System that minimises the impact forces
of a collision for vehicle occupants or unprotected road users to
alleviate the effects of an accident. This can be achieved e.g.
by autonomously applying the brakes of a vehicle before during
and after a first collision.
12. Concept phase: Development phase beginning with the first
sketch and ending with the transfer to the serial development.
According to the generic development process described in the
this Code of Practice the concept phase can be divided in a
definition phase, a phase of comparison of alternative concepts
and finally a decision and proof of one concept (see Figure 1).
13. Comprehensibility: Degree to which information is understood
that is conveyed to the driver; the quality to be comprehensible;
capability to be understood
14. Controllability: likelihood that the driver can cope with driving
situations including ADAS-assisted driving, system limits and
system failures (for a detailed discussion see chapter 4).
NOTE: this definition differs from ISO 17287
15. Definition Phase The first development subphase of the con-
cept phase where the system definition is drafted (see Figure
1).
16. Development phase: The time in the product life cycle where
the system is developed from the first idea to production.
17. Driver Distraction: The process of diverting the attention of
the driver from the driving-task to something else.
18. Driver Intent: The aim of the driver to perform an action.

2
[IP_D4 06]: PReVENT IP public deliverable IP D4 on Functional
Requirements

4
see definition of „valid subject“ in glossary
Response3_CoP_e_v5.0.doc Aug. 2009 5
 Code of Practice for the Design and Evaluation of ADAS

19. Error: The difference between the desired and actual value or
performance of a system or human action.
20. Failure: The inability of a component or system to perform its
intended function as designed. Failure may be the result of one
or many faults.
21. Failure Mode And Effect Analysis (FMEA): A method to ex-
amine potential failures in a system or process, to evaluate
consequences and define remedial actions (see C.2 for a de-
tailed description).
22. Fault: An abnormal condition or defect at the component or
sub-system level which may lead to a failure.
23. Fault Tree Analysis (FTA): A deductive analysis method that
begins with a general conclusion (a system-level undesirable
event) and then attempts to determine the specific causes of
this conclusion (see C.3 for a detailed description).
24. Function: a) A description of what something does or is used
for; b) A routine that returns a result.
25. Functional Requirements: A description what the system is
required to do. Functional requirements make the basis of the
scope of work of the project, defining user functions, system
limitations, types of inputs and outputs, etc.
26. Functionality: A set of functions associated with software or
hardware.
27. Harm: Physical injury or damage to the health of people either
directly or indirectly as a result of damage to property or to the
environment (EN 61508).
28. Hazard: Potential source of harm (EN 61508).
29. Hazard and Operability Study (HAZOP): A systematic quali-
tative technique to identify process hazards and potential oper-
ating problems using a series of guide words to study process
deviations (see C.1 for a detailed description).
30. Hazardous Situation: Circumstance in which a person is ex-
posed to hazard(s) (EN 61508)
31. Homologation: The granting of approval by an official authority
based on a set of strict rules or standards to determine whether
such approval should be given
32. Human Factors: An umbrella term for psychological, cognitive
and social influencing factors regarding the interaction between
humans and technology. Subarea of ergonomics.
33. Human Machine Interaction (HM Interaction): All the possi-
ble modes by which an interaction (direct or indirect) between
the driver and one or more vehicle systems occurs.
34. Human Machine Interface (HMI): Element or sub-element of a
system with which the driver can interact, i.e. all the input and
output devices (e.g. knobs, switches, levers, displays), which
permit the interaction between the driver and one or more vehi-
cle systems.

Response3_CoP_e_v5.0.doc Aug. 2009 6

 Code of Practice for the Design and Evaluation of ADAS

35. Impact analysis: Determines which areas and previous work

products are impacted by an intended change.
36. Intervening system: A system that triggers actuators like a
braking or steering system based on environmental sensor in-
formation to avoid e.g. a lane departure or to mitigate a forward
collision. Intervening systems usually include a preceding warn-
ing phase, therefore showing characteristics of both, ADAS and
active safety systems.
37. In-vehicle Information System (IVIS): A system supporting
the driver in the navigation task, i.e. giving information to sup-
port the driver in reaching their destination. Also referred as
“driver information system”.
38. Macroscopic Effects: Effects (and consequences) that are
shown by a system considered as a whole. In other words, they
are the “global behaviour”, due to the interactions between the
single elements of a system; opposite to macroscopic effects,
there are the microscopic ones, which are due to the single
elements constituting a system. In this CoP the “system as a
whole” is often considered to be the traffic system while the
“single elements” are the cars.
39. Malfunction: Referring to a system that is not performing its in-
tended function.
40. Manoeuvring Level: The second of the three levels of a driv-
ing task (see also stabilisation and navigation level). Tasks re-
lated with adhering to traffic rules and avoiding collisions are
within this category.
41. Misuse: Use of the (TICS) functions intended by the manufac-
turer to be used while driving in a way or manner not intended
by the manufacturer and which may lead to adverse conse-
quences (ISO 17287). Note the difference to “abuse” which is
not covered by the CoP.
42. Naïve subject: An expression for a person that tests the ADAS
under evaluation with no more experience and prior knowledge
of the system than a later customer would have.
43. Navigation Level: The highest of the three levels of a driving
task (see also stabilisation and manoeuvring level). Tasks re-
lated with finding a route to the driver’s destination are within
this category.
44. Normal Operation: a system working under standard condi-
tions (inside its operative range).
45. Open item list: Means to collect, document and track issues or
questions that cannot immediately be answered while working
on a certain topic (e.g. an open question from a checklist). See
also Figure 3.
46. Outlier: In statistics, an outlier is a single observation “far
away” from the rest of the data.
In most samplings of data, some data points will be further
away from their expected values than what is deemed reason-
able. This can be due to systematic error, faults in the theory
that generated the expected values, or it can simply be the

Response3_CoP_e_v5.0.doc Aug. 2009 7

 Code of Practice for the Design and Evaluation of ADAS

case that some observations happen to be a long way from the

centre of the data. Outlier points can therefore indicate faulty
data, erroneous procedures, or areas where a certain theory
might not be valid. However, a small number of outliers are ex-
pected in normal distribution.
Outliers have to be removed from the dataset in order to
achieve correct results and draw the correct conclusions after
an experiment.
47. Perceptibility: The possibility for the driver to perceive infor-
mation that is presented to them by the system (see also: per-
ception)
48. Perception: In psychology and in cognitive sciences, it is the
process of acquiring, interpreting, selecting, and organizing
sensory information.
49. Physical Control Loop: A control loop describes algorithms
arranged as to regulate the output at a setpoint. The algorithms
are using feedback to continuously optimise the output. The
term “physical” describes the fact that the driver is within the
loop, i.e. the feedback of the driver to the system action (or
warning) is needed in order for the algorithm the work as in-
tended.
50. Predictability: The degree to which a correct prediction of a
system's state can be made either qualitatively or quantita-
tively.
51. Primary Driving Task: Those activities that the driver has to
undertake to maintain longitudinal and lateral vehicle control
within the traffic environment (ISO 17287). Namely, all aspects
involved to control a vehicle.
52. Proof of Concept: The (optional) last development subphase
of the concept phase to justify the preceeding steps (see Figure
1).
53. Risk: Combination of the probability of occurrence of harm and
the severity of that harm (EN 61508).
54. Road Users: All type of subjects (including vehicles, pedestri-
ans, cyclists etc.), which use the road and its layout.
55. Secondary Driving Task: Additional driver activities that are
not directly related to the vehicle control e.g. tuning the radio,
changing settings of the air conditioning, programming the
navigation system.
56. Series Development: The development phase after the con-
cept phase. The targeted development of a system concept for
a specific car series.
57. Sign-off: The last step during product development concluding
that the system is ready for production; based on evidence col-
lected during development.
58. Situational Awareness: The perception of the elements in the
environment within a volume of time and space, the compre-
hension of their meaning and the projection of their status in
the near future.

Response3_CoP_e_v5.0.doc Aug. 2009 8

 Code of Practice for the Design and Evaluation of ADAS

59. Specification (framework): A set of requirements that have to

be met by a system.
60. Stabilisation Level: The lowest of the three levels of a driving
task (see also stabilisation and manoeuvring level). Tasks re-
lated to keeping the car under control (lateral and longitudinal).
61. System: A collection of components organised to accomplish a
specific function or set of functions.
62. System Limit: The operational limitations of a system. A limita-
tion is defined during development or implicitly introduced due
to physical/technical constraints, a restriction of operative sce-
narios, intrinsic functionality of hardware components etc.
63. System State: The state in which a system (or its sub-system)
actually is.
64. Usability: Concept comprising the effectiveness, efficiency and
satisfaction with which specified users can achieve specified
goals in a particular environment (ISO 17287).
NOTE As well as effectiveness, efficiency and satisfaction, us-
ability involves learnability, controllability, error robustness and
adaptability.
65. Use Cases: An intended or desired flow of events or tasks that
occur within the vehicle and are directed to or coming from the
driver in order to accomplish a certain system-driver interaction
66. Valid subject: A valid subject is a participant of an experiment
who took part in the whole experiment, where the complete
dataset is available and no reason for declaring the dataset as
an outlier is given.
67. Validation: The process of evaluating a system or component
during or at the end of the development process to determine
whether it satisfies the expectations.
68. Vehicle: In the CoP specifically motorised road vehicles, i.e.
cars, trucks, buses and motorcycles.
69. Verification: Assuring, e.g. by testing, that a component, a
sub-system, a system or a process is working as required and
specified.
70. Vigilance: The process of paying close and continuous atten-
tion or readiness to detect and effect an adequate response to
unforeseen, small and specific changes of environment; proper
attention in proper time.
71. Workload: Degree of mental, physical and perceptual effort
required by the driver to undertake a particular task (ISO
17287).
Also mental workload: the specification of the amount of in-
formation processing capacity that is used for task perform-
ance.

2.3 Abbreviations
Abbreviation Meaning
AAM Alliance of Automobile Manufacturers (US)

Response3_CoP_e_v5.0.doc Aug. 2009 9

 Code of Practice for the Design and Evaluation of ADAS

ACC Adaptive Cruise Control

ADAS Advanced Driver Assistance System
AIDE Adaptive Integrated Driver-vehicle InterfacE (EC
funded project)
AIS Abbreviated Injury Scale
ASIL Automotive Safety Integrity Level
C Controllability
CoP Code of Practice
DAS Driver Assistance System
DIN Deutsches Institut für Normung e.V. (German orga-
nisation for standardisation)
DUT Device Under Test
E Exposure to a situation where hazards exist
ECU Electronic Control Unit
ESoP European Statement of Principles on the Design of
Human Machine Interaction
ESP Electronic Stabilisation Programme
f frequency (of occurrence of a hazardous event)
FMEA Failure Modes and Effects Analysis
FMECA Failure Modes, Effects and Criticality Analysis
FTA Fault Tree Analysis
H&R Hazard analysis and Risk assessment
HAZOP HAZard and OPerability study
HIL Hardware In the Loop
HMI Human Machine Interface
I/O Inputs/Outputs
ISO International Organisation for Standardisation
IVIS In-Vehicle Information System
MAIS Maximum AIS (Abbreviated Injury Scale)
POST Power On Self Test
R Risk
S potential Severity of the resulting harm or damage
SoP Start of Production
SUV Sport Utility Vehicles
TICS Transport Information and Control System

Table 1: Abbreviations

Response3_CoP_e_v5.0.doc Aug. 2009 10

 Code of Practice for the Design and Evaluation of ADAS

3 Development process
Following, please find a generic development process provided to
facilitate a classification of the elements described in the CoP. This
generic development process reflects in general the logical se-
quence of product development phases of a product development
as well as selected milestones, but not necessarily their time se-
quence (Figure 1). Therefore, it corresponds to a simplified pres-
entation of reality. Possible iteration loops accompanying individ-
ual development phases are not shown.

Concept Phase Series Development

Best concept Proof of Detailed Validation

Definition phase Verification
selection Concept Design &Sign off

Requirements System Start of

Specification Specification Production

Figure 1: Phases of a development process

Since RESPONSE 3 is focussing on safety aspects of HM Interac-

tion, Figure 2 shows activities regarding HMI development. This
does not necessarily represent a separate development process,
but the activities are normally integrated into the product develop-
ment process.
In respect to this CoP the specific safety relevant aspects are now
considered. Principally the ADAS safety aspects may be classified
in three categories. HM Interaction and the related controllability is
analysed
• within system limits (normal operation, ADAS assisted driv-
ing),
• at system limits and
• with system failures.
All categories are evaluated by means of measures confirming
controllability with respect to possible risks 0(Annex A.3). Depend-
ing on the risk evaluation, requirements for the safety concept as
well as the HMI are derived
For a system with safety implications additional safety related ac-
tivities are performed. For the automobile industry requirements for
a safety related development process are formulated in a domain
specific safety standard. This is presently done in the ISO TC22 /
SC3 / WG 16.
Figure 2 shows additional elements of a general safety process (in
white) and activities regarding controllability (in yellow). The ele-
ments of a general safety process are depicted, as the elements of

Response3_CoP_e_v5.0.doc Aug. 2009 11

 Code of Practice for the Design and Evaluation of ADAS

the CoP may be included into a company specific safety process.

The CoP itself will focus on the activities regarding controllability.
The concept of controllability is described in chapter 4. Regarding
the safety of ADAS (for a definition of ADAS see chapter 2.1 and
Annex E) the concept of controllability is the central issue. Accord-
ing to legal requirements, an ADAS is considered safe, as long as
the driver is able to control the vehicle.

Concept Phase Series Development

Best concept Proof of Detailed Validation

Definition phase Verification
selection Concept Design &Sign off

Hazard
Safety Proof of
analysis
Requirements Safety
and risk
assessment

Controllability Controllability
Controllability Controll. Confirmation
Safety
Assessment Prelim. Sign final proof
Concept
off
HMI Sign off
concept HMI Realisation & SoP
freeze
Definition and
Draft HMI Detailed HMI HMI HMI
Comparison of
concept Specification Verification Validation
HMI concepts

Elements of a general safety process

Activities regarding controllability
Activities regarding human machine interaction

Figure 2: Elements of a safety process and controllability concept

The development process described above has only to be applied

completely with regard to a new development of an ADAS system.
In case of modifications (derivate or change) of existing systems,
an impact analysis should be performed to assess the relevant ar-
eas affected by the modification.
The vehicle manufacturer is responsible for the application and
documentation of the CoP. If development tasks and services are
performed by a supplier, the supplier must be informed about the
CoP and/or relevant information of the ADAS interfaces and the in-
tegration into the vehicle. Responsibilities need to be agreed be-
tween the vehicle manufacturer and the supplier.

Response3_CoP_e_v5.0.doc Aug. 2009 12

 Code of Practice for the Design and Evaluation of ADAS

4 Controllability
In this CoP controllability is a key requirement. Controllability refers
to the entire ADAS-driver-environment interaction comprising:
• normal system use within system limits,
• usage at and beyond exceeding system limits and
• usage during and after system failures.
Controllability is dependent on
• the possibility and driver’s capability, to perceive the criti-
cality of a situation,
• the drivers capability to decide on appropriate countermea-
sures (e.g. override, system switch-off) and
• the driver’s ability to perform the chosen countermeasure
(e.g. reaction time, sensory-motor speed, accuracy).
Safety of usage requires controllability. Compared to controllability
other design requirements are of secondary importance.
Controllability is a basic parameter in the automotive risk assess-
ment (as described in the draft of the functional safety standard
ISO WD 26262-3). Within this hazard analysis and risk assess-
ment according to ISO/WD 26262 (H&R), controllability of safety
related electronic devices has to be estimated in an early devel-
opment stage.
The CoP assists controllability evaluations and later confirmation
by providing checklists and references to state-of-the-art evalua-
tion methods. The annexes provide checklists corresponding to
the input to the H&R. Results from the H&R and checklist ques-
tions lead to open items that should be compiled in an Open Item
List for further tracking of the development status. The list can also
be used to derive a controllability evaluation plan.
Figure 3 provides an overview of a possible controllability related
workflow.
At the end of the ADAS development the CoP recommends a Con-
trollability Final Proof to confirm that sufficient controllability is
achieved for the series-production version of the system.
For this purpose, the ADAS development team has to verify that
drivers will react in relevant scenarios as previously anticipated or
in another appropriate way. The data utilised may be from the
H&R, the checklists and the results of tests that have been con-
ducted according to the evaluation plan.
Three approaches regarded as equal are offered by the CoP to fi-
nally prove that the driver can and will react in an expected and
appropriate way (Figure 3):
• Final proof of controllability by an interdisciplinary expert
panel (chapter 4.1)
• Final proof of controllability by a test with naive subjects
(chapter 4.2)

Response3_CoP_e_v5.0.doc Aug. 2009 13

 Code of Practice for the Design and Evaluation of ADAS

• Final proof by direct recommendation of controllability sign-

off by the ADAS development team (chapter 4.3)
The ADAS development team is free to choose the appropriate
way separately for each particular scenario i.e. a mixed approach
is possible.
When the controllability relevant design of the system is confirmed
by the ADAS development team a recommendation for sign-off
can be given from the Code of Practice point of view.

Definition Phase
Checklist A (Annex A.1) Situations H&R (Annex A.3)

Best Concept Selection Safety Concept Estimated

Controllability
Levels
Proof of Concept

Open Item List

Checklist B (Annex A.2)
Evaluation Plan

Detailed Design
ADAS Development Team
Verification - Developer
- other Specialists
Validation

Consult Expert from e. g.:

- Functional Safety
Controllability
- Product Analysis Controllability Confirmation Test
Confirmation
- Psychology / Human Factors
-…
yes

Recommendation
Sign-Off for Sign-Off

Figure 3: Controllability Workflow. Dashed lines suggest revision

due to new information

4.1 Final proof of controllability by an interdisciplinary expert panel

The controllability estimations are reviewed by an interdisciplinary
Expert Panel. This Expert Panel for Final Proof is a cross-
functional group of individuals (the ADAS development team and
additional specialists). It is recommended to include members of
other departments in the panel to ensure “external” expertise and
an independent view on the controllability esimations.
The Expert Panel has to judge and confirm the controllability esti-
mates. Therefore, the members of the panel must be familiar with
the system in adequate situations. The judgment can be based on
analogies, literature and previous studies during development
phase etc. When in doubt, the Expert Panel will gather additional
information for clarification. For this purpose a test might also be
performed.

Response3_CoP_e_v5.0.doc Aug. 2009 14

 Code of Practice for the Design and Evaluation of ADAS

4.2 Final proof of controllability by means of a test with naive subjects

Absolute controllability does not exist. A statistical verification that
99 % of the drivers “pass” a test in a certain traffic scenario is not
realistic because an unfeasible huge number of subjects would be
necessary to demonstrate this.
Consequently, the Code of Practice recommends a different ap-
proach.
Practical testing experience revealed that a number of 20 valid
data sets per scenario can supply a basic indication of validity. A
data set is not considered as being valid if a subject fails due to a
reason that is not system related (e. g. due to motion sickness in a
driving simulator). The test design should consider the possibility
of the occurrence of outliers. Criteria for the classification of out-
liers should be established according to the state of the art in hu-
man factors testing. In order to enlarge the data basis it is possible
to perform retests with the same subjects, prerequisite is that the
effect on the subject behaviour is negligible.
To demonstrate controllability in accordance to the CoP naive sub-
jects should be tested in relevant scenarios. Naive means that the
subjects have no more experience and prior knowledge of the sys-
tem than a later customer would have. The test-scenario is
“passed” if the subject reacts as previously anticipated or in an
adequate way to control the situation.
To show a controllability level of at least 85 % in a scenario all 20
out of 20 valid data4 sets must fulfil the pass criteria.
Testing can be carried out in any of the following ways (see Annex
D):
• On public roads,
• on proving grounds or
• in a simulator.

4.3 Final proof by direct recommendation of controllability sign-off issued by

the ADAS development team
In some projects all open issues on the Open Item List are tackled
easily by the ADAS development team themselves. In addition dur-
ing development a sufficient number of tests in a technical status
representing the final system design may have been conducted
with positive results.
In this case the controllability evaluation of the system may be con-
firmed by the ADAS development team and a recommendation for
sign-off can be given directly.

Response3_CoP_e_v5.0.doc Aug. 2009 15

 Code of Practice for the Design and Evaluation of ADAS

5 Recommendations
The objective of this chapter is to present the recommendations for
a safe development of ADAS. The content of this chapter is struc-
tured according to the generic development process introduced in
Figure 1 and Figure 2. Table 2 references the activities of the ge-
neric development process.
The entire concept phase splits into the parts ‘definition phase’,
‘best concept selection’ and ‘proof of concept’. Comparison of
concept alternatives and the selection of one of them is economi-
cally reasonable. Consequently, the definition phase deals with
drafting HM Interaction concepts. Subsequently the drafted HM In-
teraction concepts are compared and the most suitable one is
chosen for realisation. Finally, the concept selected has to be
specified in the proof of concept section. Note that general ADAS
development topics are only covered to the extent that controllabil-
ity specific topics can be described.

Main phase Sub phase Recommended steps

Concept 5.1 5.1.2 Draft HM interaction concept and con-
phase Definition trollability safety concept
phase
5.2 Best 5.2.2 HM interaction concept specification
concept
5.2.3 Selection of HM interaction concept
selection
5.3 Proof of 5.3.2 Preparation of preliminary sign-off
concept
5.3.3 Controllability preliminary
Series de- 5.4 Detailed 5.4.2 Detailed HM interaction design
velopment design
5.5 5.5.2 Verification of HM interaction
Verification
5.6 5.6.2 Controllability confirmation and final
Validation proof
and sign-off
5.6.3 Sign-off

Table 2: Mapping of phases from the developing process to sec-

tions in chapter 5

The recommendations are described as activities. Each activity is

presented in the same format. The tasks of each activity are pre-
sented in chronological order.

Response3_CoP_e_v5.0.doc Aug. 2009 16

 Code of Practice for the Design and Evaluation of ADAS

Activity A: Name of activity (optional activities without grey shading)

requires: reference to prerequisites

a) Name of task
• Explanation of subtask
• Explanation of subtask
► Reference to Annex

a) Name of task
• Explanation of subtask
► Reference to Annex

5.1 Definition phase

5.1.1 Objective
The objective of this section is to develop a level of comprehen-
sion of the intended system and its environment to an extent that
other development cycle activities may be performed satisfactorily.
Recommendations that need to be considered at the start of a sys-
tem development will be listed in this chapter.

5.1.2 Draft HM interaction concept and controllability safety concept

At least one ADAS concept is drafted in this subphase. Every con-
cept should be drafted according to the set of recommendations of
this section, which are related to the main aspects: ADAS func-
tionality, ADAS HM Interaction, ADAS usage, ADAS standards and
ADAS hazards & risks.

Activity A: ADAS functionality

a) Assigning function name

• Introduce a suitable name for the ADAS function

b) Drafting functionality
• Define system states, modes, transitions and actions
• Characterise situational limits and initial sensor require-
ments
• Sketch system behaviour under situational limits
• Clarify interaction with other systems
► Annex A.1

Response3_CoP_e_v5.0.doc Aug. 2009 17

 Code of Practice for the Design and Evaluation of ADAS

Activity B: HM Interaction
requires: 5.1.2 A, D

a) Drafting HM Interaction
• Sketch driver activities to operate the system
• Characterise transferred information
• Define take over procedures
► Annex A.1

b) Drafting physical layout

• Consider an integration of the HM Interaction concept in
the vehicle
• Draft controls and displays (system input and output)
► Annex A.1

Activity C: Usage
requires: 5.1.2 A, B, D

a) Defining domain
• Characterise the intended market for the ADAS
• Describe the type of vehicle for which the ADAS is in-
tended
• Draft the environment and roads in which the ADAS is
used
• Characterise the user group of the ADAS
► Annex A.1

b) Characterising use
• Draft operating scenarios
• Sketch user expectations, misinterpretation, overestima-
tion
► Annex A.1
c) Characterising misuse
• Draft non operating scenarios
• Identify reasonably foreseeable misuse
• Find possible measures to avoid misuse
► Annex A.1

Response3_CoP_e_v5.0.doc Aug. 2009 18

 Code of Practice for the Design and Evaluation of ADAS

Activity D: Standards
requires: 5.1.2 A

a) Ensuring conformity
• Look for relevant standards and regulations
► Annex A.1

Activity E: Preliminary Hazard analysis and risk assessment

requires: 5.1.2 A, B, C, D

a) Identifying hazards
• Identify possible hazardous situations and the relevant
sources of hazards within the drafted ADAS function
for normal operation, system failure and system limits.
► Annex A.1, B.1

b) Analysing hazards
• Perform hazard analysis paying specific attention to
the controllability aspect
► Annex A.3

c) Assessing risk
• Perform a risk assessment for the analyzed hazards
► Annex A.3

5.2 Best concept selection

5.2.1 Objective
In this part of the concept phase suitable criteria for discriminating
various concepts are defined. Based on these criteria the results
can be used to select a concept.
The selected HM Interaction concept will be incorporated into a de-
tailed specification as part of the overall system requirements
specification.

5.2.2 HM interaction concept specification

The concept specification is a general development activity. The
detailed definition of system limits is part of the company individual
design strategy and therefore not covered here.

Response3_CoP_e_v5.0.doc Aug. 2009 19

 Code of Practice for the Design and Evaluation of ADAS

Activity A: Controllability concept

requires: 5.1.2 E

a) Specifying the controllability concept

• Specify HM Interaction based on the draft concept and
controllability results from a risk assessment
► Annex A.1, A.2

Activity B: HM Interaction
requires: 5.1.2 B,

a) Specifying system transitions

• Identify driver initiated transitions that correspond to
operator control actions
• Identify system initiated transitions, caused by chang-
ing environmental conditions as well as exceeding the
system limits
• Identify system initiated transitions, caused by system
failure or failures of other iteracting systems
► Annex A.1

b) Specifying system dialogs

• Describe the system feedback to the driver for control-
lability relevant system states and transitions
• Describe the input/output modalities and dialogs
► Annex A.1

c) Specifying physical layout

• Consider controllability aspects of system states and
transitions for specification of the controls and displays
► Annex A.1

5.2.3 Selection of HM interaction concept

Activity A: Evaluation criteria
requires: 5.1.2 E

a) Defining criteria
• Define criteria for the evaluation of the concepts con-
sidering controllability requirements based on the risk
assessment
► Annex A.3, B.3

Response3_CoP_e_v5.0.doc Aug. 2009 20

 Code of Practice for the Design and Evaluation of ADAS

Activity B: Selection of concept

requires: 5.2.2 B

a) Finding a best concept

• Evaluate the concepts and select the most suitable
one according to the defined requirements. Check if
the HMI is suitable for the intended task in normal op-
eration, at system limits and with system failures
► Annex A.2, A.3

5.3 Proof of concept

5.3.1 Objective
In this part of the concept phase the drafted and selected ADAS
concept has to be specified focusing on controllability. The struc-
ture of this activity is presented in the detailed HM Interaction
specification section.
In order to finalise the concept specification a concept sign-off or
equivalently a preliminary sign-off is recommended. The structure
of this activity is supplied in the concept sign-off section.

5.3.2 Preparation of preliminary sign-off

The preliminary sign-off is an optional activity, which might be nec-
essary or desirable for various reasons, e.g. the transfer of activi-
ties from a research to a serial development department.
Even if this is not the case it is still recommended to start with veri-
fication and validation as early as possible in order to minimise the
risk of critical findings at a late stage of product development.
However it is at the discretion of the developer when these activi-
ties are performed and therefore the recommended activities are
optional in this early stage of product development.
Optional activities in this document have a white heading instead
of a grey heading.

Activity A: Review of HM Interaction specification (optional)

requires: 5.2.2 B

a) Define a validation strategy

• Document the procedure in a preliminary review plan
for the specified HM Interaction concept.
►Chapter 5.6 gives an overview on activities that are required in
the validation phase

b) Performing the review

• Review the HM Interaction concept specification ac-
cording to the plan and identify possible problem areas
► Chapter 5.6

Response3_CoP_e_v5.0.doc Aug. 2009 21

 Code of Practice for the Design and Evaluation of ADAS

Activity B: Further proceeding (optional)

requires: 5.1.2 A, 5.2.3 B

a) Considering additional tests

• Check for further tests necessary to assess controlla-
bility (controllability relevant topics that can be clearly
identified as easily controllable, according to the state
of the art in the area of human factors, need not be
tested).
• Perform necessary tests (in cases of doubt or in lack of
experience tests are recommended)
► Annex B, Annex D

b) Documenting important topics

• Document the achieved results
• Document the open controllability topics and the re-
quired phase of development necessary to perform a
certain test.
► Chapter 5.6.2 Activity C, Open item list (Chapter 4, Figure 3)

5.3.3 Controllability preliminary sign-off

Activity A: Preliminary sign-off (optional)
requires: 5.3.2 A, B

a) Deciding on concept sign-off

• Sign-off the HM Interaction concept or initiate appro-
priate rework. (the responsible person / project man-
ager etc.)

5.4 Detailed design

5.4.1 Objective
During the detailed design phase the development is continued
based on the selected ADAS concept and the HM Interaction con-
cept that was specified.

5.4.2 Detailed HM interaction design

Activity A: HM interaction detailed Design (optional)
requires: 5.1.2 A, 5.2.3 B, 5.3.2 B

Response3_CoP_e_v5.0.doc Aug. 2009 22

 Code of Practice for the Design and Evaluation of ADAS

a) Designing HM Interaction architecture

• Develop functional subdivisions
• Define which functions are performed by the driver, by
hardware, software or in combinations.
• Consider relevant user tasks and activities
• Define input and output by systematically detailing relevant
system states & transitions and the related interactions be-
tween driver and system
► Annex A.1

b) Designing physical layout

• decide on the appropriate physical layout of the input
and output devices (controls and displays)
► Annex A.1

c) Integrating into overall design

• integrate ADAS HM Interaction design into overall de-
sign regarding
- prioritisation of system outputs (e.g. warnings
and messages) in relation to other functions
- driver workload
► Annex A.1

Activity B: Update hazard analysis and risk assessment

requires: 5.1.2 E, 5.4.2 A

a) Updating hazard analysis and risk assessment

• update by including information from detailed design of
HM interaction
► Annex A.3

5.5 Verification

5.5.1 Objective
In this context verification relates to the HM Interaction design.
That is, checking and documenting if and how the controllability re-
lated requirements of the developed HM Interaction design are ful-
filled. Successful verification ends with the release of the HM In-
teraction design; otherwise rework needs to be performed.

5.5.2 Verification of HM interaction

Activity A: HM Interaction verification
requires: 5.4.2 A

Response3_CoP_e_v5.0.doc Aug. 2009 23

 Code of Practice for the Design and Evaluation of ADAS

a) Verifying HM Interaction
• Verify the design based on its specification concerning
HM interaction requirements for system and human
performance
► Annex C

b) Documenting verification
• Document and report the verification results.
• Initiate necessary further actions if a non-conformance
to requirements is found
► Chapter 5.6.2 Activity C, Open item list (Chapter 4, Figure 3)

5.6 Validation and sign-off

5.6.1 Objective
At the end of the development process a sign-off is carried out to
confirm that the system complies with the specified controllability
related requirements.
Controllability confirmation and the final proof may require specific
actions and documents.

5.6.2 Controllability confirmation and final proof

The validation strategy is defined in the validation plan. It is possi-
ble to refer to earlier results e.g. from the preliminary controllability
sign-off during the proof-of-concept phase, if still applicable.

Activity A: Planning validation scenarios

requires: 5.4.2 A, B

a) Identifying driving situations

• Consider the following situations
- normal operation
- behaviour at functional limits
- behaviour in case of system failures
• Compile a list of relevant driving situations for system
validation and build reasonable clusters
► Annex B.1

Response3_CoP_e_v5.0.doc Aug. 2009 24

 Code of Practice for the Design and Evaluation of ADAS

Activity B: Planning approach for final proof (done by the ADAS

development team)
requires: 5.6.2 A

a) Selecting the appropriate strategy for each scenario

• Controllability confirmation by an independent expert
panel (chapter 4.1)
• Controllability check by a test with naive subjects
(chapter 4.2)
• Direct recommendation of Controllability Sign-Off by
the ADAS development team (chapter 4.3)
► Chapter 4, Annex B.2, B.3, B.4

Activity C: Final proof

requires: 5.6.2 A, B

a) Controllability confirmation
• The experts perform the validation strategy, decide if
the design has passed and give a recommendation for
sign-off
► Annex D

b) Documenting controllability
• Document information that is sufficient to reproduce
the recommendation for sign-off (e.g. approach,
equipment, assumptions, decisions, test conditions)
• Compile a set of documents to confirm the controllabil-
ity for the system sign-off. If the documentation is al-
ready available a collection of references is sufficient.
Documents from the risk assessment procedure,
i.e.
- System and HM Interaction concept description
- Identified hazards
- Assessed risks
- Used checklists
- Assumptions
Controllability related HM Interaction requirements,
i.e.
- Requirements and references to risks

Response3_CoP_e_v5.0.doc Aug. 2009 25

 Code of Practice for the Design and Evaluation of ADAS

5.6.3 Sign-off
Activity A: Sign-off
requires: 5.6.2 D

a) Signing-off the system

The responsible person (project manager etc.) can sign-off con-
trollability
► Annex F

Response3_CoP_e_v5.0.doc Aug. 2009 26

 Preventive and Active Safety Applications
Integrated Project
Contract number FP6-507075
eSafety for road and air transport

Annexes to the
Code of Practice
for the
Design and Evaluation
of ADAS

Version number V5.0

Aug. 2009

Response3_CoP_e_v5.0.doc Aug. 2009

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

ANNEXES

A.1 Checklist A – System specification................................... A3

A.2 Checklist B – Evaluation concepts for system ......................
specification.................................................................... A24
A.3 Hazard analysis and risk assessment procedure ........... A41
Annex B Recommendations for controllability evaluation ....... A46
B.1 Condense hazardous situations ..................................... A46
B.2 Conducting a test with subjects...................................... A47
B.3 How to setup pass-fail criteria ........................................ A50
B.4 How to evaluate controllability by experts ...................... A50
Annex C General methods for safety analysis ........................ A52
C.1 Early risk assessment by HAZOP .................................. A52
C.2 Failure Modes and Effects Analysis (FMEA) .................. A53
C.3 Fault tree analysis (FTA) ................................................ A54
C.4 Hardware in the loop (HIL) testing.................................. A55
Annex D General methods of assessment.............................. A57
D.1 Expert panel ................................................................... A57
D.2 HMI concept simulation .................................................. A59
D.3 Driving simulator test ...................................................... A60
D.4 Driving tests with professional test drivers ..................... A61
D.5 Car clinic with naive subjects ......................................... A63
Annex E Definition ADAS........................................................ A66
Annex F Documentation sheet................................................ A72
Annex G Criteria for HMI concept selection ..................................
(background information) .................................................. A74
G.1 Classification and evaluation according to driving tasks A74
G.2 Driver information perception ......................................... A75
G.3 Driver’s field of work ....................................................... A79
G.4 HMI architecture principles............................................. A81
Annex H References ............................................................... A83

Response3_CoP_e_v5.0.doc Aug. 2009 A2

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Annex A Response procedures

A.1 Checklist A – System specification

A.1.1 Scope
Checklist A refers to the specification of Advanced Driver Assis-
tance Systems (ADAS).
It supports the concept phase in the development process (see
chapter 3). It serves as a support tool in the preparation of the sys-
tem specification in the definition phase. The checklist is based on
the current state-of-the-art.
This checklist is intended as reference material for vehicle manu-
facturers and suppliers engaged in specification and implementa-
tion of ADAS. It provides support in ADAS specification and con-
sideration of aspects, which might not be evident at first considera-
tion. This checklist does not require a uniform ADAS design. It is
applicable for various ADAS with varying complexity and integra-
tion levels as well as various vehicle models. This checklist helps
to structure the ADAS concept description and therefore allows a
comprehensive and consistent system specification.

Application of checklists
Checklist A supports the development team. The checklist com-
prises general questions concerning the ADAS system and system
environment. The answers of the development team lead to a the
ADAS system specification. Open items are identified for further
activities and compiled in the “To do” column.
The completed checklist and specification are part of the docu-
mentation recommended for the (preliminary) sign-off. You may
use your own (company adapted) check lists, which should be
comparable to checklist A.

A.1.2 Structure of checklist A

Supported task (Table A1 - A3)
System users (Table A4, A5)
Vehicle type (Table A6, A7)
Market (country of application), (Table A8)
Homologation//Type approval and standards/traffic law conformity
(Table A9 - A12)
Functional Description (Table A13)
User requirements vs. user expectations (Table A14 - A17)
Situational and sensor limits (Table A18 - A23)
Human Machine interface and interaction (Table A24 - A27)
Preparation of hazard analysis (Table A28 - A32)
Product information (Table A33)
Maintenance/Repair (Table A34)
Response3_CoP_e_v5.0.doc Aug. 2009 A3
 Annexes to the Code of Practice for the Design and Evaluation of ADAS

A.1.3 Checklist A

Supported driving task

Please give a detailed description of the supported driving task. It
will assist you in determining whether your system is an ADAS.
Background:
"Horizontal structuring” of the driving task is demonstrated below:

Navigation
Interface parameters: driving time, direction
at junction, motorway exit
Manoeuvring
Interface parameters: desired
acceleration, desired yaw rate
Stabilisation

Figure 4: The three driving task levels

In addition, there is a general “human information processing be-

haviour”. Principally, all human activities are affected:
Perception
Recognition
Decision
Action.

Question: Typical examples: Answer/Comments: To do:

A1-1. Which driver operation level Object recognition

is supported by the ADAS? (radar, camera),
a) Perception navigation notice, a) y/n
b) Recognition steering, braking b) y/n
c) Decision c) y/n
d) Action d) y/n
A1-2. Which driving task is sup-
ported by the ADAS?

a) Navigation level Finding a suitable route to a) y/n

destination.

b) Manoeuvring level Adhering to traffic rules, b) y/n

avoiding collisions.

c) Stabilisation level Steering and operating of c) y/n

accelerator and brake

d) If Navigation or stabilisation level d) y/n

applies: Check whether your sys-
tem complies with the ADAS defini-
tion.

Warning and assisting/intervening ADAS

With respect to responsibility referring to the driving task it makes
sense to classify the system as mentioned below. Please deter-
mine the system category the ADAS belongs to.

Warning systems
Response3_CoP_e_v5.0.doc Aug. 2009 A4
 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Warning systems are systems merely supplying information to the

driver (e.g. visual or acoustic)
The following questions are also applicable for intervening systems
providing additional information to the driver.
The responsibility for correct operation is always with the driver,
even if the necessary information is missing or misleading
For example: Blind Spot Monitoring System:
If an object is not detected in the blind spot because it is not in the
range of the physical limits of the sensor, the driver will not be in-
formed about the object.
Therefore, the HMI should be designed in such a way, that the
driver will not solely rely on the system, but will also double check
the situation.

Question: Typical examples: Answer/Comments To do:

A2-1. a) Are direct measurements Direct measurement a) y/n
presented to the driver? ACC: Information on
b) Is the information presented in a distance (in meters) to the b) y/n
comprehensible way? preceding object.
Indirect measurement:
Acoustic park assistant:
variation of sound fre-
quency as measure for
the distance to the de-
tected object.
A2-2. Are the selected senses for Visual, auditive, haptic, y/n
information and warnings suitable? kinaesthetic

A2-3. a) Have the effects of unex- Blind Spot Monitoring a) y/n

pected information for the specifica- System:
tion of warnings and information If an object in the blind
been considered? spot is not detected by
the system because it is
b) Have the effects of missing in- outside the physical limits b) y/n
formation for the specification of of the applied sensor, the
warnings and information been system will not inform the
considered? driver about the object.
Subsequently the driver
c) If yes, which measures are will interpret that there is c) ___________________
taken? no object in the field of
view of the sensor, and
will change lanes.

Assisting / intervening systems

During the operation of a system the responsibility for the driving
task always remains with the driver. Therefore, all the assisting
functions should be designed in a way that the driver can always
override them. Exceptions to the ability to override may exist for in-
tervening systems if the driver cannot take over the driving task
because of lack of reaction time or the relevant driving status for
the driver is no longer under control.
These systems may be classified as follows:
• Driver is able to override the function:
The driver may override the system in operation at any
point in time.

Response3_CoP_e_v5.0.doc Aug. 2009 A5

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

• Driver is not able to override:

Driver inputs cannot override the system operation, and no
on / off switch is available in the vehicle.

Question: Typical examples: Answer/Comments: To do:

A3-1. Is the driver able to override ACC: If the ACC is in y/n

the system in operation at any point operation the driver may
in time? override the ACC control
any time. By depressing
the accelerator pedal the
driver may accelerate the
vehicle.
A3-2. Did you check whether a y/n
driving status is no longer control-
lable by the driver?
A3-3. a) Are ADAS initiated situa- a) y/n
tions foreseeable when reaction
time is not sufficient?
b) If yes, please describe for a later b) __________________
hazard analysis and risk assess-
ment

System users
Intended user group
Please specify the user group the system under development is in-
tended for:

Question: Typical examples: Answer/Comments: To do:

A4-1. What are the intended user

groups for ADAS?
a) Professional drivers Truck, bus, taxi drivers, a) y/n
driving instructors
b) Private persons Commuters, leisure trips b) y/n

Abilities and restrictions

Please specify the system users:

Question: Typical examples: Answer/Comments: To do:

A5-1. Age of system user:

a) All age groups 16-99 Young inexperienced or a) y/n
older drivers with physical
handicaps
b) Core user group? b) from … until
A5-2. Physical dimensions (Anthro- Physical dimensions
pometrics) affect field of view, reach
a) Have all sizes and weights been area, operation forces, a) y/n
considered? etc.
b) If no, state restrictions? b) __________________

Question: Typical examples: Answer/Comments: To do:

A5-3. Driving training Theoretical or practical

a) Particular driving training or knowledge. Restricted a) y/n
qualification standard required? driver’s license exclu-
sively for vehicles with
b) If yes, please state automatic transmission. b) __________________
A5-4. Driving habits:

Response3_CoP_e_v5.0.doc Aug. 2009 A6

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

a) Have similar ADAS systems Change from ACC to a) y/n

been marketed in other vehicles? conventional cruise con-
b) Did you consider these systems trol. b) y/n
in order to avoid operational confu-
sion?
A5-5. Driving style / personality
a) Does the ADAS require a driver Adaptive systems and a) y/n
identification? change of driver,
ACC setting of personal
b) If yes, please state which warning thresholds b) __________________
A5-6. Foreseeable misuse
a) How and in which way may the ACC used in fog a)
ADAS be misused?

b) Which information, warnings or b)

measures are required?
A5-7. Risk compensation:
a) Are significant changes in behav- Inappropriate speed, a) y/n
iour expected after short-term reduced attention to traffic
ADAS use? situation, increased driv-
b) If yes, how would these changes ing task distraction b) __________________
become obvious?
c) Are significant long-term c) y/n
changes in the driving behaviour
expected?
d) If yes, please state d) __________________
A5-8. Psychomotoric perform-
ance Reduced reaction ability
a) Are there special requirements to of older persons concern- a) y/n
psychomotoric performance? ing speed and operation
accuracy
b) If yes, please state b) __________________
A5-9. Physical restrictions
a) Would physical restrictions of the Sensoric, auditive, mental a) y/n
driver influence safe ADAS opera- performance, mobility,
tion? amblyopia(poor eye-
sight),,
colour blindness, ambly-
acousia (hardness of
b) If yes, please state the kind of hearing), b) __________________
restrictions shoulder check problems
A5-10. Cultural driver backgroud Traffic regulations and
a) Is there significantly different behaviour, lane change, a) y/n
behaviour in countries where the distance behaviour,
system will be marketed effecting speed level, left-hand
ADAS use? traffic
b) If yes, please state which b) __________________
A5-11. System expectations
a) Can user expectations be differ- Vehicle changes, rental a) y/n
ent when using similar ADAS from cars
various manufacturers?
b) If yes, please state b) __________________

Vehicle type
The following questions could be important if the ADAS system is
intended for various vehicle types or if it is transferred to other ve-
hicle types, and if the system is adjusted to them.
Example: View obstructions from within trucks or SUVs due to
design.

Question: Typical examples: Answer/Comments: To do:

A6-1. Is the system designed for a Only passenger vehicles y/n

particular vehicle type and thus for for transport of persons
a vehicle specific function?
A6-2. a) Are there any system Visual obstruction caused a) y/n
properties which are influenced by by truck or SUV design
application in other vehicle type or
Response3_CoP_e_v5.0.doc Aug. 2009 A7
 Annexes to the Code of Practice for the Design and Evaluation of ADAS

designs?
b) If yes, please specify b) __________________

State vehicle type the system is developed for.

The following classification refers to the European driving licence
classification according to regulation 91/439 EWG. The mentioned
main classes are applied in all EU member states, whereas sub-
classes (e.g. A1, B1, S, T, L) only apply on a national basis.

Vehicle classes

Question: Typical examples: Answer/Comments: To do:

A7-1. Class A,
National Subclasses A1, A2, M
a) Is the ADAS system intended for a) y/n
this class of vehicle? motorcycles with or
b) If yes, are there any vehicle spe- without side-car b) y/n
cific preconditions and effects that
must be taken into consideration
during the development phase?
c) If yes, please specify. c) ___________________
A7-2. Class B
National Subclass B1
a) Is the ADAS system intended for a) y/n
vehicles of this class? Motor vehicles and three-
b) If yes, is it necessary to consider wheel motor vehicles of b) y/n
any specific preconditions and ef- an authorized mass of not
fects? more than 3.500 kg and
c) If yes, which? not more than eight seats. c) ___________________
Trailer of a limited
authorised mass of not
more than 750 kg are
permitted.
A7-3. Class C
National Subclass C1
a) Is the ADAS system intended for a) y/n
vehicles of this class? Motor vehicles, except
b) If yes, is it necessary to consider class D, of authorized b) y/n
any specific preconditions and ef- mass of more than 3.500
fects? kg.
c) If yes, which? Trailers of a limited c) ___________________
authorised mass of not
more than 750 kg are
permitted.
A7-4. Class D
National Subclass D1
a) Is the ADAS system intended for a) y/n
Motor vehicles for pas-
vehicles of this class?
senger transport with
b) If yes, is it necessary to consider b) y/n
more than eight seats,
any specific preconditions and ef-
excluding driver seat
fects?
Trailers of a limited
c) If yes, which? c) ___________________
authorised mass of not
more than 750 kg are
permitted.

Question: Typical examples: Answer/Comments: To do:

A7-5. Class E
a) Is the ADAS system intended for a) y/n
vehicles of this class?
Trailer of a gross weight
b) If yes, is it necessary to consider b) y/n
of more than 750 kg in
any specific preconditions and ef-
combination with classes
fects?
B, C, D (special regula-

Response3_CoP_e_v5.0.doc Aug. 2009 A8

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

c) If yes, which? tion class B) c) ___________________

A7-6. National Subclasses T, L, S

a) Is the ADAS system intended for a) y/n
vehicles of this class? Small three-wheel motor
b) If yes, is it necessary to consider cycles and four-wheel b) y/n
any specific preconditions and ef- light motor vehicles max.
fects? 45 km/h
c) If yes, which? c) ___________________

Agricultural and forestry

vehicles

Market (country)
Depending on the market the vehicle is intended for, varying condi-
tions may exist which influence the system design.

Question: Typical examples: Answer/Comments: To do:

A8-1. Infrastructure
a) Do extraordinary infrastructural Right or left-hand traffic, a) y/n
conditions have to be taken into lane width and quality,
consideration? lane markings
b) If yes, which? b) __________________
A8-2. Approval regulations
a) Are there any country specific FMVSS Federal Motor a) y/n
approval regulations which have to Vehicle Safety Standard
be taken into consideration for
ADAS?
b) If yes, please specify. b) __________________
A8-3. Vehicle population
a) Are there special vehicle popula- Proportion passenger a) y/n
tion profiles which influence ADAS? vehicle, SUV, truck etc.
b) If yes, which? b) __________________
(refer to 3.2 vehicle type)
A8-4. Target market
a) Do ADAS restrictions exist con- Country specific customer a) y/n
cerning the market? expectations
b) If yes, specify? b) __________________

Homologation / Type approval and compliance with standards and traffic law
Compile a list of all mandatory directives and regulations and of
applicable national and international standards.
Possible standards and regulations are shown in the following
overview:

Response3_CoP_e_v5.0.doc Aug. 2009 A9

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Type approval
In order to introduce a vehicle with all its components in a market,
it is necessary to comply with required market specific type ap-
proval regulations. Harmonised regulations apply for the EU mem-
ber states.

Question: Typical examples: Answer/Comments: To do:

A9-1. a) Do any national / interna- ECE regulations for steer- a) y/n

tional guidelines or regulations ing and braking
concerning the ADAS function ex-
ist?
b) If yes, please specify b) __________________
A9-2. a) Are existing guidelines and In the past: only direct a) y/n
regulations violated? operation of brake pedal
b) If yes, is it required to modify an by driver: Today: driver b) y/n
existing guideline to allow vehicle switches on ACC, then
approval with this ADAS function? automatic brake control
and brake light control

Compliance with directives and regulations is the minimum re-

quirement a product must meet in order to be marketed by a
manufacturer. Due to the traffic safety obligation of a manufacturer
it is also necessary to adhere to standards and technical specifica-
tions when designing a product.

General standards
The standardisation is a systematic harmonisation compiled by the
affected experts. Harmonisation may affect many areas, for in-
stance procedures, measurements, properties etc.
German standards, for instance, are created by the DIN
(Deutsches Institut für Normung e.V.).
European standards are created by the CEN/CENELEC (Euro-
pean Committee for Standardisation) of which the national stan-
dards institutes are members. European standards aim at a volun-
tary technical harmonisation in Europe. The introduction of stan-
dards may be requested by any national standards institute. The
International Organisation for Standardisation (ISO) is the compe-
tent authority for international standardisation. The national stan-
dards institutes are ISO members.
Please note: Always differentiate between general standards and
safety standards. Safety standards as for instance in USA and
Canada are laws and are of course legally binding
The application of a general standard, regardless whether national,
European or international is voluntary, even if the standard is con-
sidered a safety standard by certain product safety laws. However,
a product must be at least state-of-the-art (see "State-of-the-Art").
Deviating from the standards requires reasoning that the deviation
will not result in reduced safety in this specific case.
However, the application of a general standard may lead to the
presumption that a product is not defective and / or that the manu-
facturer has observed the necessary duty of care. Therefore, this
assumption may become binding, even if it is not legally binding.
Response3_CoP_e_v5.0.doc Aug. 2009 A10
 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Examples for standards for ADAS HM interaction design that

may be applied:
• ISO Ergonomic aspects of transport information and control
systems 15005 - 15008 Standards
• ISO/WD 26262 Road vehicles - Functional safety
• ISO 15622
• ISO 15623
• ISO Standard “Safety of Machinery”
• ISO 17287:2003 „Suitability“ Standard

Question: Typical examples: Answer/Comments: To do:

A10-1. a) Do ADAS function stan- ISO 15622 maximum a) y/n

dards exist or are they being pre- deceleration at ACC
2
pared? 3m/s
b) If yes, please specify. b)___________________
A10-2. a) Are the existing function a) y/n
standards violated?
b) If yes, is the specification of the b) y/n
ADAS function at least as safe as
the ADAS function which would
comply with this standard?
c) If yes, has a remedy been pro- c) y/n
vided or a reason been given why
this fact is not relevant?

Technical rules
A technical rule serves as an instruction to resolve a multitude of
issues in the field of engineering, and is accepted among experts
in the relevant specialist area. Accepted means that the experts
are familiar with this specification and that they apply it convinced
that the specification is correct. The application of a technical rule
by any manufacturer is voluntary, meaning that the manufacturers
may apply alternative procedures or techniques as long as they
prove safe.

Examples for technical rules and guidelines for ADAS HM

interaction design that may be applied:
• ESoP: European Statement of Principles of the Design of
HM Interaction
• AAM Guidelines
• MISRA Development Guidelines for Vehicle Based Soft-
ware

Question: Typical examples: Answer/Comments: To do:

A11-1. Do technical regulations for Internal regulations and y/n

the ADAS function exist? instructions from OEM or
suppliers

Response3_CoP_e_v5.0.doc Aug. 2009 A11

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Question: Typical examples: Answer/Comments: To do:

A11-2. a) Does the ADAS function a) y/n

comply with these technical regula-
tions?
b) If no, is the selected ADAS func- b) y/n
tion specification at least as safe as
the ADAS function which complies
with the technical specification?
c) If no, give reasons why this fact c)___________________
is not relevant?
d) If reasoning is not possible, d)___________________
which remedy must be provided?

A11-3. a) Are there any voluntary US-Market: Alliance of a) y/n

self-commitments between OEM? Automobile Manufactur-
ers AAM “Principles,
criteria and verification
procedures for driver
interactions in advanced
vehicle information and
communication systems”
ACEA 1999/125/EG CO2
b) If yes, please specify emission b) __________________

State-of-the-art
In addition to the existing regulations of type approval and existing
standards as well as technical specifications the state-of-the-art of
the respective product group must be considered in order to pro-
vide compliance with the traffic safety duty of a manufacturer.
The state-of-the-art is continually developing in a product group.
Amongst others the state-of-the-art defines itself through a com-
parison with of competitor products. In order to determine the rele-
vant technology status a competitor comparison is required.
Designers should take into consideration that the state-of-the-art is
constantly changing and therefore must consider future changes in
the market in order to ensure conformity with the state-of-the-art
throughout the period the product is marketed in.

Question: Typical examples: Answer/Comments: To do:

A12-1. a) Does a state-of-the-art Comparison to existing a) y/n

already exist for ADAS? systems
b) If yes, is the ADAS function in b) y/n
compliance with this state-of-the-
art?
A12-2. Is it ensured that the ADAS y/n
is in accordance with the state-of-
the-art at the time of marketing
regarding safety technological fac-
tors?

Response3_CoP_e_v5.0.doc Aug. 2009 A12

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Functional description
The following section will help to produce a detailed description of
the ADAS function.
The supported task must be described in detail and give a clear
definition of how the system supports the driver also beyond the
system limits.
At this development stage it makes sense to supply a structured
and complete description of the system to allow a logical hazard
analysis and risk classification. This is an important contribution for
the evaluation of the system effect on driver vehicle control.

Question: Typical examples: Answer/Comments: To do:

A13-1. Is a detailed systematic y/n

system description of the ADAS
function available?
A13-2. Has an overview of all sys- Possible presentation y/n
tem components and their tasks media are State Transi-
and interaction been supplied? tion diagrams, Petri Net
or lists
A13-3. Has an overview of system Button operation for y/n
status/system mode and intermodal switching on and off.
switching been supplied in connec- When is the system ac-
tion with the environmental situa- tive/not active? System is
tion? always active at ignition
on, temporary status
A13-4. Has an overview been sup- Controlled by driver. but- y/n
plied on activation, deactivation and ton, controlled by system
system-driver take-over proce-
dures?
A13-5. Has an overview been sup- System availability, sys- y/n
plied on system reactions to correct tem/vehicle reaction
and incorrect driver inputs?
A13-6. Has an overview been sup- y/n
plied on system reactions to sensor
inputs?
A13-7. a) Has an overview been a) y/n
supplied on means and possibilities
for the driver to intervene in system
actions?
b) If this possibility is given, please b) __________________
describe. Which possibilities are
available in which situation?
A13-8. Has an overview been sup- System limits may exist y/n
plied on the system behaviour at due to physical limits of
approaching or exceeding situ- the employed sensors
ational limits?
A13-9. Has an overview been sup- y/n
plied on differences between sys-
tem driving behaviour and regular
human driving behaviour in relevant
traffic situations?

User requirements vs. user expectations

It is advisable to check whether the system to be developed cre-
ates exaggerated or / and false user expectations, leading to incor-
rect system use and driving behaviour.
On the whole one can say, the higher the level of automation, the
higher the driver expectation regarding system reliability, situation
coverage, system accuracy and system performance.

Response3_CoP_e_v5.0.doc Aug. 2009 A13

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

User Expectations
Automatic

Invisible

Driver
Commanded

Driver
Monitored

Level of Automation
Figure 5: Level of automation

The following questions will assist in specifying technical user re-

quirements or system expectations.

Question: Typical examples: Answer/Comments: To do:

A14-1. a) Is special user knowledge Menu navigation knowl- a) y/n

required? edge
b) If yes, specify b) __________________
A14-2. a) Does the ADAS create ACC is keeping a safe a) y/n
special user expectations? distance
b) If yes, specify b) __________________
A14-3. a) Can it be expected that The Driver is expecting a) y/n
the automation level of the system from a Stop&Go system
may lead to higher user expecta- that it also brakes on
tions than the system actually of- stationary objects
fers?
b) If yes, which precautionary b) __________________
measures must be taken?
A14-4. a) May exaggerated or false User expectations regard- a) y/n
expectations concerning the extent ing radar 360 degrees
of system functions be expected? circumferential view from
b) If yes, which precautionary aircraft monitoring in b) __________________
measures must be taken? contrast to ACC Radar
with limited opening angle

Safety aspects of user expectations

The driver wants to drive a safe vehicle. This means safe vehicle
operation as well as occupant safety in real accident scenarios.
Therefore, an ADAS may be perceived by the customer as related
to an active safety system. Costumer expectation is mainly subject
to the marketing statements of the manufacturer. Customer expec-
tations may perceive a system as a safety system, although de-
velopers have possibly never designed it as a safety system.

Question: Typical examples: Answer/Comments: To do:

A15-1. Does the customer expect Active lane keeping y/n

the ADAS to be an active safety
system?
A15-2. Does the customer expect Reversible belt preten- y/n

Response3_CoP_e_v5.0.doc Aug. 2009 A14

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

the ADAS to be a passive safety sioner used as haptic

system? warning

Workload
In order to operate a vehicle safely the driver needs to be physi-
cally and mentally fit and able to operate a vehicle. ADAS can in-
fluence the driver’s workload.

Question: Typical examples: Answer/Comments: To do:

A16-1. In which way does the Take-over of a partial task

ADAS influence the driver work
load?

System reliability
Depending on the product, users have varying expectations con-
cerning system reliability. User expectations result from a multitude
of influencing factors, like presentation or marketing of the product,
advertisement statements or media presentations. The view of the
user is however not limited to the evaluation of relevant information
on new technologies, but also the knowledge about products used
in the past.

Question: Typical examples: Answer/Comments: To do:

A17-1. Have provisions been made Don’t use the word “safe” y/n
that the ADAS function will be mar- for an assistance system
keted under an appropriate name?
A17-2. Have provisions been made ACC: stationary obstacles y/n
that the system limits are consid- are not considered.
ered at the time of marketing the
ADAS?
A17-3. Have provisions been made ACC with distance control y/n
that the customer will be informed vs. cruise control without
about differences compared to distance control
similar systems?
A17-4. Have provisions been made No shoulder check using y/n
that the system will not create ex- Lane Change Assist
aggerated or misleading user ex-
pectations which could lead to in-
correct system use and driver be-
haviour?

Please be aware that you might be confronted with a multitude of

different user expectations due to the high number of potential us-
ers. The same applies to similar products or product names mar-
keted by competitors prior to or after market introduction of the
ADAS.

Response3_CoP_e_v5.0.doc Aug. 2009 A15

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Situational system and sensor limits

This chapter deals with the situation parameter range in which the
system works as expected by the driver. Please consider here the
influence of external conditions on the system and the driving be-
haviour.
A risk analysis may help in obtaining an initial overview concerning
relevant situations.
Please note: Do not mistake task related system limits for situ-
ational limits of the system.

Question: Typical examples: Answer/Comments: To do:

A18-1. a) Within which situational System reaction to mov- a) __________________

boundaries does the system work ing or stationary objects
as expected?
b) What are the main system limits? Sensor limits, processing b) __________________
time

Environmental conditions

Question: Typical examples: Answer/Comments: To do:

A19-1. Visibility
a) Has the ADAS been designed in a) Night vision support a) y/n
a way that it will support the driver with infrared cameras at
only in specific visibility conditions? night
b) Are there any system limits un- b) Camera based Lane b) y/n
der these visibility conditions which Keeping Assist with grey
impair reliable operation of the shade evaluation of the
ADAS function? camera image may not
work on roads where the
lane markings are cov-
ered with snow. Further
vision inhibiting factors:
snowfall, rain, mist/fog,
wind/gusts of wind, direct
c) If yes, give the most important sunlight, darkness/twilight c) ___________________
examples?
A19-2. Climate
a) Is system reliability ensured Humidity/water, tempera- a) y/n
under various climatic conditions? ture, dust, UV radiation,
b) Have combinations of climatic sensor soiling/icing b) y/n
influences been taken into consid-
eration?
c) Which measures must be taken c)___________________
for which influences?
A19-3. Electromagnetic compati- Transmitters (mobile
bility telephones, overhead
Is the ADAS function influenced by power cables), electro- y/n
electromagnetic waves under regu- magnetic waves emitted
lar operating conditions of the vehi- by other ADAS vehicles
cle?

Dynamic driving status with respect to system limits

Response3_CoP_e_v5.0.doc Aug. 2009 A16
 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Question: Typical examples: Answer/Comments: To do:

A20-1. a) Has the ADAS been in- Speed, longitudinal ac- a) y/n
tented to support the driver only in celeration/lateral accel-
one or more dynamic driving eration, dis-
status? tance/route/relative speed
b) If yes, under which conditions? in view of other traffic b) __________________
c) Are there any dynamic ADAS participants or objects, c) y/n
system limits impairing reliable yaw rate, lateral distance
operation? in view of lane limits,
other traffic participants or
d) If yes, which limits? objects, engine rotation d) __________________
speed, gear engaged

Infrastructure
Please consider implicit assumptions or prerequisites referring to
the system to be developed:

The infrastructure also comprises systems and facilities transmit-

ting information to the ADAS vehicle. The ADAS function may be
based on information made available via infrastructure?

Question: Typical examples: Answer/Comments: To do:

A21-1. a) Is the system intended for Permitted speed a) y/n

use in a certain environment?
b) If yes, please specify. b) __________________
A21-2. Objects Tunnels, bridges (also
a) Is it required to place particular traffic sign bridges), illu- a) y/n
emphasis on influences of objects mination poles, traffic
of the infrastructure on the ADAS? lights, guard rails, man-
hole covers, other staton-
b) If yes, please specify. ary objects in or outside b) __________________
the lane
A21-3. Infrastructural limits There is only limited
a) Is it foreseeable that further mar- availability of tyre filling a) y/n
ket specific infrastructural limits stations with tyre pres-
must be considered? sure control in the USA.
England has left-hand
b) If yes, please specify. traffic and the rest of b) __________________
Europe right-hand traffic.
A21-4. Road Highway, national road,
a) Are there any influences depend- local road, local road in a) y/n
ing on the kind of road building areas
b) If yes, please specify. b) __________________
A21-5. Lane geometry Lane dimensions, number
a) Must the influence of the road of lanes, uphill or downhill a) y/n
geometry be considered? grade, corner radius,
gradient
b) If yes, please specify. b) __________________
A21-6. Road surface Frictional coefficient and
a) Must any influences be consid- local distribution, lane a) y/n
ered concerning road surface? markings, potholes, lane
grooves, multi-colour lane
markings (USA, Canada,
b) If yes, please specify. Australia, or additional
markings at construction b) __________________
sites)

Question: Typical examples: Answer/Comments: To do:

Response3_CoP_e_v5.0.doc Aug. 2009 A17

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

A21-7. Lane boundaries Continuous or intermittent

a) Must any influences be taken lane boundaries, crash a) y/n
into consideration concerning to barriers, plants (trees or
lane boundaries? bushes) resulting in ob-
b) If yes, please specify. structed vision b) __________________
A21-8. Road construction/ con- Stationary objects (“chi-
struction sites canes“ serving speed
a) Must the influence of road work/ reduction), moving ob- a) y/n
construction sites be taken into jects (mobile barriers)
consideration?
b) If yes, please specify. b) __________________

Interaction of vehicles with and without ADAS

Question: Typical examples: Answer/Comments: To do:

A22-1. a) Does the ADAS and its Behaviour (manoeuvre) of a) y/n

function have effects on other traffic other traffic participants,
participants? trucks with and without
trailer, vans, vehicles with
and without trailer, motor
cycles, bicycles, pedestri-
ans, material and shape
of vehicles of other traffic
participants which are
difficult to be detected by
the sensor. Further mov-
ing objects within or
b) If yes, which effects can be ex- outside the lane (trees b) __________________
pected? swaying in the wind)
A22-2. a) Can special effects on Vehicles with identical a) __________________
other traffic participants be ex- ADAS
pected if other vehicles are also
equipped with ADAS?
b) If yes, which effects can be ex- b) __________________
pected?

Traffic conditions
Please consider effects under various traffic conditions

Question: Typical examples: Answer/Comments: To do:

A23-1. a) Can particular ADAS High traffic density (rush a) y/n

function effects under various traffic hour, traffic congestion),
conditions be expected? medium traffic density
(dense traffic), low traffic
b) If yes, under which traffic condi- density (smooth traffic b) __________________
tions? flow)

Human Machine Interface and interaction

Please take into consideration the variety of existing ADAS HM
Interfaces.
The questions below will help to describe the Human Machine In-
terface using the following structure.

Response3_CoP_e_v5.0.doc Aug. 2009 A18

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

System input
Direct driver input via ADAS controls

Question: Typical examples: Answer/Comments: To do:

A24-1. a) Which kind of input op- Buttons, control stalk, a) __________________

eration elements did you consider? rotary control, toggle
b) Why did you consider these? switch, thumb wheel,
voice entry b) __________________
A24-2. Are all inputs possible with Control stalk and addi- y/n
this operation element? tional adjustments in
infotainment system
A24-3. Which location is planned Control panel, center
for the operation elements? (field of console top / bottom,
view, reachability) see Annex G.2.1 door, roof module
A24-4. What kind of input does the
system allow:
a) Is it required that the system a) System switched a) y/n
can be switched on/off? on/off
b) Do further system states exist? b) System active / b) y/n
passive
c) Is it necessary for the driver to c) y/n
be aware of these system
states?
d) If yes, does the system provide d) Text message, pic- d) y/n
clear description/feedback on togram, operation
the system state? element illumination,
warning signal
e) Is the input of target data re- e) Navigation: desired e) y/n
quired? destination
- If yes, please state which? ACC: desired speed -___________________
and desired follow-
ing distance
f) Is it necessary to supply the f) Sensitivity, signal/ f) y/n
possibility of setting system pa- volume, brightness
rameters?
- If yes, please state which? -___________________
A24-5. a) Is personalisation re- Personalisation by means a) y/n
quired/intended? of „fingerprint“ person
recognition (note: key
b) If yes, specify medium? memory is not driver b) __________________
related)

Indirect driver input via non-ADAS control elements

Question: Typical examples: Answer/Comments: To do:

A25-1. a) May the ADAS system be Brake pedal operation a) y/n

operated with other vehicle control influences ACC (switch-
elements? off); operation of indicator
b) If yes, specify with which other influences LDW system b) __________________
vehicle control elements the system
may be influenced?
A25-2. a) Does the system change If the driver drakes, ACC a) y/n
status due to the operation of a concludes that driver
different subsystem? intends to decelerate and
subsequently ACC
b) If yes, specify which? switches off b) __________________

Response3_CoP_e_v5.0.doc Aug. 2009 A19

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

System feedback
Describe function and kind of system feedback.
Please check if system feedback may be switched off by the
driver. If this is the case, consider and describe the effect.

Direct system feedback

Methods of system feedback:

Question: Typical examples: Answer/Comments: To do:

A26-1. Which sensory modalities Visual, auditive, kinaes- ___________________

are used for system feedback? thetic
A26-2. a) Which kind of presenta- Warning lamp, monitor a) __________________
tion is used? display, loudspeaker
output
b) Have existing standards been Location, shape, colour b) y/n
taken into consideration? etc.
A26-3. What is the location of feed- Control panel, head up
back? display
A26-4. Which kind of feedback
does exist?
a) System information a) System status, System a) __________________
parameter
b) Warning b) „Sensor defective“ b) __________________
c) Instruction c) „Distance: Brake!“ c) __________________
A26-5. Which kind of information Texts, symbols, voice,
coding is used? noises
A26-6. Has the existing hierarchy of Infotainment (navigation, y/n
the overall vehicle concept been traffic messages, phone
taken into consideration for infor- call), warnings (priorities:
mation, warnings and feedback in brake, oil pressure, wind-
terms of the type of feedback? screen cleaning liquid)

Indirect system feedback

Describe the affected vehicle sub-systems:

Question: Typical examples: Answer/Comments: To do:

A27-1. a) Does the ADAS supply Steering system, engine a) y/n

feedback to other vehicle systems? control, suspension etc.
b) If yes, please specify. b) __________________

Response3_CoP_e_v5.0.doc Aug. 2009 A20

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Preparation of hazard analysis

The following questions will be helpful for the preparation of a haz-
ard analysis and risk assessment (H&R). The questions will also
help to check completeness of an analysis.

Top level hazards

Question: Typical examples: Answer/Comments: To do:

A28-1. Has a hazard analysis been y/n

performed?
A28-2. If no, define for every sys- Modes: active, switched
tem function the possible hazards off, stand-by etc.
at the top level. Please consider
every mode of the system status.

Operating modes

Question: Typical examples: Answer/Comments: To do:

A29-1. Define all operation modes. On, off, active, passive,

stand-by, graded there
may be several levels)

Failure modes
Failure modes may be structured according to the Questions A30-
A32. Please note that a detailed analysis of failure causes is not
the objective at this stage of delvelopment. This will be performed
in a later product development phase (e. g. by means of a FMEA)

Question: Typical examples: Answer/Comments: To do:

A30-1. Compile a list of all failure Function not available on

modes on the functional level. driver request, function
fails during operation
- completely
- partly
Function switches on
without request
False system output
- prompt response (too
early / too late)
- change of mode
- false output value

System limits
System limits can have the same effect on ADAS performance as
system failures. For example in case of ACC (speed range, road
curvature range)

Response3_CoP_e_v5.0.doc Aug. 2009 A21

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Question: Typical examples: Answer/Comments: To do:

A31-1. Evaluate the system limits Sensor limits (e. g. limited

stating the respective effect on the field of view, sensor
ADAS performance. blindness due to snow),
measuring error, misin-
terpretation or classifica-
tion of sensor data, data
processing limit, control
unit, hardware/software
limits, false alarms or
irritating system mes-
sages

Detection of system errors

Question: Typical examples: Answer/Comments: To do:

A32-1. Determine for each individ-

ual system error whether it is de-
tectable and how it is detected.
Please take the operation modes
into consideration.
A32-2. Is detection during self- y/n
diagnosis when switching on or off
sufficient?
A32-3. Is a continual self-diagnosis y/n
necessary?
A32-4. Define a remedy for each Change to default charac-
detected error. teristic, if vehicle speed is
unknown:
Driver information (audi-
tive, visual, permanent
warning)

Product information
In general, product information means information about ADAS via
all available media. Amongst others these are product advertise-
ments, direct distributor information (sales talks etc.), but also user
manuals.
In order to ensure correct system operation product information
should comprise the following:

Question: Typical examples: Answer/Comments: To do:

A33-1. Describe which product Print media, multimedia,

information is essential to ensure personal instruction
proper operation of ADAS
A33-2. Have existing user expecta- User expectations regard-
tions been considered in the prod- ing radar 360 degrees
uct description (e.g. owners man- circumferential view from
ual, maketing brochures)? aircraft monitoring in
contrast to ACC Radar
with limited opening angle

Maintenance / Repair
Please consider different elements for maintenance and system
diagnosis:

Response3_CoP_e_v5.0.doc Aug. 2009 A22

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Question: Typical examples: Answer/Comments: To do:

A34-1. a) Is it necessary to perform Hardware maintenance, a) y/n

maintenance work on the system to adjustment of sensors,
be developed during the entire cleaning, lubrication,
vehicle operation? integrity tests.
b) If yes, state maintenance proce- Software maintenance: b) __________________
dure for the system? updates, patches, self-
diagnosis
A34-2. a) Is it necessary to have Own system, sub- a) y/n
sub-system data available? systems of interfaces
b) If yes, please state which? b) __________________
A34-3. a) Which environment data Mileage, date, time stamp
should be stored?
A34-4. Where should the data be Control unit, installation
stored? location
A34-5. Which storage capacity is
required concerning data volume?
A34-6. Which signal should be the Airbag signal
triggering signal for data storage?
A34-7. Who will receive access to PIN query
the data?
A34-8. What equipment is neces- Workshop diagnosis
sary to read out diagnosis data and tester
evaluate them?
A34-9. What maintenance intervals Integration into vehicle
should be determined? maintenance schedule
A34-10. Who may or should per- User, workshop, others
form maintenance work?

Response3_CoP_e_v5.0.doc Aug. 2009 A23

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

A.2 Checklist B – Evaluation concepts for system specification

A.2.1 Introduction
This annex proposes an approach to evaluate the system specifi-
cation regarding controllability of the system. The evaluation is
based on a checklist.
The purpose of the checklist is to give the system developer clues
about system improvements. This implies that for a successful de-
velopment it is not necessary to answer all the questions with
“yes”.
The checklist questions are structured using a number of concepts
that focus the view of the evaluator on a specific topic and should
help to check the specification from different perspectives.
All of the concepts are related to, or contribute to the controllability
of the evaluated system and are presented in an order according
to the three levels of information processing where they fit best:
• Driver perception of the criticality of a situation
• Driver decision of an appropriate countermeasure
• Driver performance of the countermeasure

Overview of concepts
Driver perception:
• Predictability
• Emotional issues
• Trust
• Perceptibility (message transfer to driver)
• Vigilance
• Workload / Fatigue
Driver decision:
• Traffic safety / Risk
• Responsibility / Liability
• Learnability
• Behavioural changes
• Comprehensibility
• Error robustness
Driver performance:
• Misuse potential
• Macroscopic effects and driving efficiency
• Benefits / Acceptance
• Operability
• Control issues
Response3_CoP_e_v5.0.doc Aug. 2009 A24
 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Checklist layout
Each concept is presented in a separate subchapter. The con-
cepts are evaluated by means of questions presented in the form
of a checklist.
The first “Phase” column refers to the development phases as they
are defined in this document. A solid box means that the question
is applicable for this development phase.

■□□□
Definition Sign
phase off

Concept Proof of
competition phase concept
The phase column is for information only and to support the identi-
fication of the most relevant questions at each specific stage of
system development.
The second column contains the questions related to the particular
evaluation concept.
Column 3, 4 and 5 provide empty space to answer the question by
either checking “yes” or “no” or “Not suitable”. If “not suitable” is
checked a comment should be given, why the question is not suit-
able
The “comment” column at the end can also be used by the evalua-
tor for example to justify an answer, to refer to other activities or to
define further steps if the evaluator is uncertain about the answer.

Example:
The question in the example below is related to the concept of
“Predictability”. If it can be answered with “Yes” everything is OK. If
the answer is “No” then additional care should be taken during
system development to reach the goal of “conformity with driver
expectation”.
Phase Predictability Yes No Not suit- Comments
able

□□■□ 1. Are system reactions predictable in a sense that they

correspond to the previous experiences and expectations
derived from driving or using related systems
(conformity with user expectation)?

Response3_CoP_e_v5.0.doc Aug. 2009 A25

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

A.2.2 Predictability
Phase Predictability Yes No Not suit- Comments
able

□■□□ 1. Are system reactions that may occur understood by

other road users?

□■□□ 2. If it is likely that the system will change or increase the

variability in the behaviour of other road users (in dif-
ferent vehicles) in the traffic system: Will the driver or the
ADAS be able to predict the actions of other road users?
□□■□ 3. Are system reactions predictable in the sense that they
correspond to the previous experiences and expectations
derived from driving or using related systems (confor-
mity with driver expectation)?
□□□■ 4. Does the driver get a clear understanding of the different
modes of operation / system states?

A.2.3 Emotional issues

Phase Emotional issues Yes No Not suit- Comments
able

□■□□ 1. Have you considered (potential) traffic situations during

system development where the driver’s stress level
(workload) may be expected to be negatively changed
(too high / too low) when the system is available?
□□■□ 2. Has it been considered that the passenger’s comfort
may be negatively modified by the knowledge about
the presence of the system function (e.g. a warning that
is intended only for the driver)?

Response3_CoP_e_v5.0.doc Aug. 2009 A26

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

A.2.4 Trust
Phase Trust Yes No Not suit- Comments
able

□■■□ 1. Are warnings displayed in time with respect to the criti-

cality of the hazard?

□■■□ 2. Are system messages, which are relevant for the driving
task, appropriate (in type, frequency) with respect to the
situation?
□□■□ 3. Does a warning alert the driver only to genuine haz-
ards that have not been indicated earlier?

□□■□ 4. Do the system messages consider the different modes of

operation and traffic situations?

□□□■ 5. Is there a strategy to avoid the system issuing too many

warnings (false alarms), which the driver may begin to
ignore?

A.2.5 Perceptibility (message transfer to driver)

Phase Perceptibility (message transfer to driver) Yes No Not suit- Comments
able

□■■□ 1. Are multiple information channels used to convey criti-

cal messages? (e. g. acoustic in addition to optical dis-
play)?
□□■□ 2. Are the system messages perceptible for the driver in
typical ADAS related traffic situations?

□□■□ 3. Does the system provide appropriate timely feedback

about a system reaction in a given traffic situation (e. g.
take over request from adaptive cruise control)?

Response3_CoP_e_v5.0.doc Aug. 2009 A27

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Phase Perceptibility (message transfer to driver) Yes No Not suit- Comments

able

□□■□ 4. Is the presentation of information / warning (output) of

the new system consistent with the structure of al-
ready existing information / warnings of other systems (e.
g. type, presentation, timing)? Consider the whole vehicle
/ driver interface.
□□■□ 5. Does the location of the new system interface and op-
eration elements (input and output) fit the existing inter-
faces with respect to the relevance of the supported
task?
□□□■ 6. Can system outputs and information be perceived by
the driver quickly enough to enable them to react ap-
propriately (e. g. take over request from adaptive cruise
control)?
□□□■ 7. Is the driver sufficiently informed about the system
status and function at all times?

□□□■ 8. Are the system messages comprehensible and un-

ambiguous for the driver?

A.2.6 Vigilance
Phase Vigilance Yes No Not suit- Comments
able

□□■□ 1. Have you considered that the use of the system may
provoke monotonic situations (e.g. monitoring tasks), if
so will the driver remain attentive?

Response3_CoP_e_v5.0.doc Aug. 2009 A28

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Phase Vigilance Yes No Not suit- Comments

able

□□■□ 2. Can the operation or observation of the system be

achieved without a major change in the distribution of
attention relating to the driving task so that potentially
hazardous situations may not occur?
□□■■ 3. Does the HM Interaction of the system prevent the driver
from losing situational awareness (e.g. keeping the driver
“in the loop”, providing a consistent warning strategy)?

A.2.7 Workload / Fatigue

Phase Workload / Fatigue Yes No Not suit- Comments
able

□■■□ 1. Is the HMI layout constructed in a way such as to avoid

an overload of the driver’s sensory channels in ADAS
specific traffic situations?.
□□■□ 2. In case of an incorrect input: Can the desired result be
achieved with no or small correctional effort (e.g. with-
out increasing the stress level or workload for the driver)?
□□■□ 3. Have traffic situations been considered during system
development that may cause a higher stress level (work-
load) for the driver compared to driving without the sys-
tem?
□□■□ 4. Does the system require sufficient driver activity to avoid
the driver becoming inattentive or tired during system
supported driving?

Response3_CoP_e_v5.0.doc Aug. 2009 A29

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

A.2.8 Traffic safety / Risk

Phase Traffic safety / Risk Yes No Not suit- Comments
able

□■□□ 1. Are system reactions understood by other road users?

If not can they still control the situation (e. g. system
based deceleration without activation of brake lights)?
□■□□ 2. Is the reaction performance of other road users suffi-
cient to interact with a vehicle that is equipped with a rap-
idly (hard, intensive) reacting ADAS system?
□■□□ 3. Is the driver’s attention necessary to keep them in the
physical control loop while the system is running?

□■□□ 4. Does the design provide reliable system predictions if

the behaviour of other road users changes?

□■□□ 5. Is the vehicle controllable in the case of a system mal-

function by overruling or switching off the system?

□■□□ 6. Can system parameters be changed whilst driving

without causing unexpected behaviour?

□■■□ 7. Is the system function self - explanatory (i.e. without

user manual)?

□■■□ 8. Can the operation or observation of the system (e.g.

possible driver distraction by displays) be achieved with-
out a major change in attention distribution relating to
the driving task so that potentially hazardous situations
may not occur?
Phase Traffic safety / Risk Yes No Not suit- Comments
able

□□■□ 9. Have other driving tasks been considered during system

development to avoid a conflict with the operation of the
ADAS?

Response3_CoP_e_v5.0.doc Aug. 2009 A30

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

□□■□ 10. Have measures been taken to avoid the system function
irritating the driver while the system is operating (e. g. if
the driver is not familiar with a system function because
they are using a rental car)?
□□■□ 11. Is the driver informed if a detectable system malfunc-
tion occurs?

A.2.9 Responsibility / Liability

Phase Responsibility / Liability Yes No Not suit- Comments
able

■□□□ 1. If type approval rules or other laws prevent market

introduction of a system under development (Annex
A.1) is there a realistic possibility to change type ap-
proval rules or laws?
■■■■ 2. Have methods been applied that assist and optimise the
design process (e. g. ISO 9001, VDA quality manage-
ment, methods for safety and risk evaluation, checklists
…)?
□■□□ 3. Have you considered the possibility that specific skills
may be required for a safe operation of the system that
some drivers may not have (consider particularly inexpe-
rienced or physically impaired drivers)?
□■□□ 4. Has the need for special skills been taken into account?

Phase Responsibility / Liability Yes No Not suit- Comments

able

□■□□ 5. If the use of the equipped vehicle removes the driver

from the physical control loop, is this in line with cur-
rent legislation?

Response3_CoP_e_v5.0.doc Aug. 2009 A31

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

□■□□ 6. Is the vehicle behaviour predictable for other road us-

ers if they do not know whether the vehicle was equipped
or not equipped with the system?
□■□□ 7. Has the state-of-the-art been taken into consideration
(ask your domain experts e.g. active safety, HMI, vehicle
dynamics)?
□■■■ 8. Have legal requirements and standards been complied
with (ask your homologation or law department for more
information)?
□■■■ 9. Have demands of consumer protection organisations
been taken into consideration?

□□■□ 10. If special skills are needed: Was the restriction to a

specific user group explicitly addressed during devel-
opment (e.g. restriction to passenger car drivers)?
□□■□ 11. Does the system indicate that it is unsuitable for certain
groups of users (e.g. function permitted via personalisa-
tion; feedback with respect to operational readiness of a
personalised function shown in display)?
□□■□ 12. Is the system function intuitively understandable (i.e.
without the user manual)?

□□■□ 13. Has the possibility of misinterpretation of the system

function been considered?

□□■□ 14. Is it possible for the driver to deactivate or overrule a

system at any time, which assists a driving task?

Phase Responsibility / Liability Yes No Not suit- Comments

able

Response3_CoP_e_v5.0.doc Aug. 2009 A32

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

□□■■ 15. Can the system be operated safely by the driver with-
out having read the user manual before initial opera-
tion? This question refers to the situation, where the
driver has the opinion that it would be possible to use the
system intuitively.
□□■■ 16. Are the system limits clearly understandable for the
driver?

□□□■ 17. Does the user manual describe system functions, han-
dling and limits in an understandable way?

□□□■ 18. Are system messages unambiguously formulated and

easy to understand? This question refers to the situation
that misinterpretation may lead to a potentially hazardous
situation.

A.2.10 Learnability
Phase Learnability Yes No Not suit- Comments
able

□■□□ 1. If specific skills are required for safe use of the system,
is it possible for a driver to gain these specific skills dur-
ing vehicle operation?
□■□□ 2. If specific skills are required for safe use of the system,
or if the use of the system needs to be restricted to a
specific user group: (consider particularly inexperienced
or physically impaired drivers): Is this obvious for the
driver and does the driver know what to do?

Phase Learnability Yes No Not suit- Comments

able

Response3_CoP_e_v5.0.doc Aug. 2009 A33

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

□□■■ 3. Is it likely that the driver’s mental representation of the

system, which they will develop during operation, will cor-
respond to the technical function (compatibility of men-
tal and technical model)?

A.2.11 Behavioural changes

Phase Behavioural changes Yes No Not suit- Comments
able

□■□□ 1. Have you considered that the feedback from the vehi-
cle (e.g. haptic, visual) may confuse the driver if they
were used to performing the task in an unequipped vehi-
cle?
□■□□ 2. Does the system design avoid negative influence to ex-
ternal persons (other road users, overtaking / overtaken
drivers, etc) that have knowledge about the existence of
the system function in the vehicle?
□□■□ 3. Are the driver tasks with ADAS support still an essential
part of the overall vehicle operation in a way that the
driver will not neglect relevant tasks as a result of the
use, activation or deactivation of the new system (e.g.
less use of mirrors or shift of attention to secondary
tasks) as a result of the use, activation or deactivation of
the new system?
□□■□ 4. Have you considered that the system does not encour-
age the driver to overestimate their abilities and skills?

A.2.12 Comprehensibility

Response3_CoP_e_v5.0.doc Aug. 2009 A34

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Phase Comprehensibility Yes No Not suit- Comments

able

□■■□ 1. Is the behavioural pattern of the driver, concerning

system operation, taken into consideration for the opera-
tion of the new system (A behavioural pattern is a behav-
iour that has been acquired in the past by using existing
vehicle systems e. g. deactivate an operating cruise con-
trol by depressing the brake pedal)?
□□■■ 2. Are generally understandable, simple terms used for
system outputs and driver information?

□□■■ 3. Are the limitations of correct operation / system limits

comprehensible and predictable for the driver in different
environments, weather and visibility conditions (e.g. fog,
animals on the road)?
□□■■ 4. Are the limitations of sensory detection capabilities
understandable, particularly when compared to human
sensors especially where metaphors are used, e.g. the
"machine eye”?
□□□■ 5. Is it likely that the driver’s mental representation of the
system, which is developed when using the system, cor-
responds to the technical function (compatibility of
mental and technical model)?
□□□■ 6. Does the driver understand the system feedback to their
performed input / control actions (feedback could be e.g.
acoustical, optical or dynamic vehicle behaviour)?
□□□■ 7. Is the system function intuitively understandable (i.e.
without user manual)? If not, consider how to ensure that
user manual is read or if driver needs other training.
□□□■ 8. Does the user manual present system functions, han-
dling and limits in an understandable way?

Response3_CoP_e_v5.0.doc Aug. 2009 A35

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

A.2.13 Error robustness

Phase Error robustness Yes No Not suit- Comments
able

□■□□ 1. Are physical constraints (e.g. a threshold for a mini-

mum activation velocity) implemented to prevent incor-
rect operation?
□■□□ 2. Can the driver control the system if s/he wants to activate
the system and the system is not available? This refers
especially to the situation in which the driver is not in-
formed that the system is unavailable.
□■□□ 3. Have you considered the situations under the aspect of
unintentional activation/deactivation?

□□■□ 4. In case of an incorrect driver input: Can the desired result

be achieved with no or small correction effort?

A.2.14 Misuse potential

Phase Misuse potential Yes No Not suit- Comments
able

□■□□ 1. Is the system designed in such a way as to minimise the

possibilities of external manipulation or sabotage?

□□■□ 2. Have potential cases for misuse been considered by the

system designers?

□□■□ 3. Does the design of the system function discourage a

misuse potential with respect to ‘testing the limits’?

□□■□ 4. Does the system implementation consider the potential

usage of the system as an ‘entertainment’ system?

Response3_CoP_e_v5.0.doc Aug. 2009 A36

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Phase Misuse potential Yes No Not suit- Comments

able

□□□■ 5. If it is possible to adjust system parameters to different

traffic conditions (e.g. distance to front traffic) or envi-
ronmental conditions (e.g. view conditions): Is the driver
aware of the effects of these adjustments?
□□□■ 6. Is the driver supported in striving for safe driving when
using the system (minimise risk compensation)?

□□□■ 7. Does information about the system (manuals, graphics in

system messages, advertisement, press publications
etc.) raise realistic expectations without promoting
risky behaviour?
□□□■ 8. Does the system function support the driver’s duty to
exercise due diligence and avoid promoting thoughtless
or careless use, which can lead to safety-critical situa-
tions?

A.2.15 Macroscopic effects and driving efficiency

Phase Macroscopic effects and driving efficiency Yes No Not suit- Comments
able

□■□□ 1. If it is likely that the system will change or increase the

variability of the behaviour of other road users (dif-
ferent vehicles) in the traffic system: Have you consid-
ered if this change in variability could reduce the potential
gain of the introduction of a new ADAS?
□■□□ 2. If the driver will lose skills and capabilities when using
the system then have you considered that this could lead
to negative macroscopic effects e.g. traffic congestion or
increase in overall travelling time?

Response3_CoP_e_v5.0.doc Aug. 2009 A37

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Phase Macroscopic effects and driving efficiency Yes No Not suit- Comments
able

□■□□ 3. Does the use of the system support an efficient way of

driving?

□■□□ 4. Does the system support driving economy (e.g. reduction

of fuel consumption)?

A.2.16 Benefits / Acceptance

Phase Benefits / Acceptance Yes No Not suit- Comments
able

□■■□ 1. Is the presentation of warnings appropriate (in type,

frequency and timing) to the criticality of the hazard?

A.2.17 Operability
Phase Operability Yes No Not suit- Comments
able

□■■□ 1. Are physical impairments taken into consideration

concerning the prevention of incorrect operation?

□■■□ 2. Are all human-machine-interaction procedures inter-

ruptible by the driver once initiated?

□□■□ 3. Is it possible to undo, correct or change driver inputs

at any time?

Response3_CoP_e_v5.0.doc Aug. 2009 A38

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

A.2.18 Control issues

Phase Control issues Yes No Not suit- Comments
able

■■□□ 1. Can the driver control the system after a transition from
full system functionality to a degraded mode?

■■□□ 2. Can the driver control the system after an unintended or

accidental system deactivation?

■■□□ 3. Can the driver control the system after an unintended or

accidental system activation / use?

■■□□ 4. If the system can execute a function without being re-

quested or expected, can the driver control it?

□■□□ 5. Can the driver control the situation if they want to activate
the system and it is not available e.g. the car is currently
operated outside the system limits?
□■□□ 6. Have you considered the reaction to a system failure of
drivers with different driving education/experience? Con-
sider also the background of drivers from different cul-
tures / countries.
□■□□ 7. Is it always ensured that driver actions, which should
overrule the system, are intuitive, e.g. activating brake
pedal to switch off ACC?
□■□□ 8. Could the use of the equipped vehicle increase the
probability of loss of longitudinal and / or lateral con-
trol? Consider also the use of the vehicle if a system
failure occurs.
□■□□ 9. If the system is for use by a specific user group only:
Have you considered that specific skills or a special
training may be required for safe use of the system that
some drivers may not have (consider particularly inexpe-
rienced or physically impaired drivers)?

Response3_CoP_e_v5.0.doc Aug. 2009 A39

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Phase Control issues Yes No Not suit- Comments

able

□■■□ 10. Have you considered the possibility of system activa-

tion or deactivation in situations, in which it would lead to
potentially hazardous driving conditions?
□□■□ 11. Is the controllability in the case of a system failure also
ensured for a driver with impaired capability (e.g. eld-
erly person)?
□□■□ 12. Have you considered (if such data is available) that the
driver may lose relevant driving skills and capabilities
after long-term system use? This is especially relevant if
the system is suddenly unavailable or the driver changes
to a car without such an ADAS.
□□■□ 13. Is the system or vehicle still controllable in the case of a
system malfunction / automatic system deactivation e.g.
are the time windows sufficiently large, so that the driver
can take over control safely whenever necessary?
□□■□ 14. Are system messages, which are relevant for the driving
task, displayed in time with respect to the situation?

□□■□ 15. Have you considered that an erroneous system message

could lead to a driver-reaction, which leads to a poten-
tially hazardous situation (e.g. map based speed warn-
ings)?
□□■□ 16. Have you considered the possibility of action slips that
may occur during the operation of the system (e.g. acti-
vation of wrong control e.g. pressing the brake pedal with
the left leg after switching from a manual transmission to
an automatic transmission vehicle)?
□□□■ 17. Can the driver control the system regarding speed or
precision of their psycho-motor performance (particularly
in situations where the driver is required to take over)?

Response3_CoP_e_v5.0.doc Aug. 2009 A40

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

A.3 Hazard analysis and risk assessment procedure

The Hazard analysis and risk assessment procedure described in
this annex is currently being developed in the ISO TC22 / SC3 /
WG16 “Functional safety” for the automotive industry. The release
is expected in 2009. Parts of this chapter (A.3.2 – A.3.6) are di-
rectly linked to the ISO/WD 26262-3 in the version dated 2007-06-
28.

A.3.1 Objectives
The objective of the hazard analysis and risk assessment (H&R) is
to identify and categorise the potential hazards of the item5 and
formulate goals related to the prevention of these hazards in order
to achieve an acceptable residual risk. For this, the item is evalu-
ated with regard to its safety implications and a Automotive Safety
Integrity Level (ASIL) is assigned. The ASIL is determined by a
systematic evaluation of potentially hazardous driving or operating
situations. The rationale of the ASIL evaluation is documented and
takes into account the estimation of the impact factors severity,
probability of exposure and controllability..

Define a system
incl. functions
and boundaries

Assume failure
Find (critical) Freifahrt
scenarios
(black box)
Bes c hleunigungspotential bei hoher Geschwindigkeit sehr gering, in
hohe Ges chwindigkeit (v >180 km/h) Kom bin ation mit freier Fahrbahn /Geradeausfahrt -> unkritisch
Motormoment gem. Fahrerw unsch
<NIC HT SICHERHEITSRELEVANT> maxim ale Momentenerhöhung ohne Fahrerwunsch

situations Autobahn mittlere Geschwindigkeit (v < 180 km/h)

Freifahrt

Folgefahrt
Motormoment gem. Fahrerwuns ch
<SICHERHEIT SRELEVANT> max im ale Momentenerhöhung ohne Fahr erwunsch

hohe Querbeschleunigung

geringer Abstand

Spurwechsel

Eis glätte

Baus telle

Stau

.....

hohe Querbesc hleunigung

mit Gegenverkehr Motormoment gem. Fahrerwunsch
<SIC HERHEITSRELEVANT> maxim ale Momentenerhöhung ohne Fahr erwunsc h
Beispiel EGAS
Motormoment gem. Fahrerw unsch ohne Gegenverkehr
maximale Momentenerhöhung ohne Fahrer wuns ch
Pass strasse
..... Landstarße
..... stehend
Stau Motormoment gem. Fahrerw unsch
<SIC HERHEITSRELEVANT> maxim ale Momentenerhöhung ohne Fahr erwunsc h

.....

Zone 30 km/h

bis 60 km/h
Stadtverkehr
Zebras teifen

.....

Parkplatz

Sonstige W erkstatt

.....

Probability of
Situation ( Safety Relevant) Controllability Accidential Scenario if Controllability Task Loss and Damage
Exposition
will fail
Locality Driver/Vehicle
Street Expected Task of
Condition/ Failure/Malfunction
Traffic Other Dynam. Secondary Other Persons at Persons for Averting
Fall Nr. Location Environment Situation Characteristics Driving State System State Driver Characteristics Risk E Comment Danger C Comment State Changes Consequence S Comment ASIL
Motorway Preceding Straight Road High Speed System Mode: Persons in E3 ACC function will No detection of preceding Driver will brake and C1 Based on the high Accident/crash S3 based on the high A
Vehicles Difference Follow Mode Vehicles often be used on vehicles ACC will be deactivated speed difference with preceding speed difference
the motorway; to preceding vehicle fatal injuries or
situation is vehicle the driver death will be
common will be observe the expected
ACC functionality
(high attention)

Motorway Preceding and Straight Road System Mode: E4 ACC function will unexpected Driver will override C2 Following vehicle Crash with S3 fatal injuries or C
following Follow Control often be used on deceleration/braking system function; driver will expect following vehicle death will be
vehicles the motorway; Following vehicle will braking in this expected
brake traffic situation
(high attention)
Highway -low Oncomming Curve medium speed System Mode: E3 e.g. Driving on unexpected acceleration Driver will brake and C3 normal driver will destabilization of the Crash with S3 fatal injuries or C
traffic; free Free Flow Mode snowy, icy road ACC will be deactivated, have problems to vehicle oncomming death will be
driving Driver stabilizes car stabilize the car vehicle expected

Highway -low No Oncomming Curve medium speed System Mode: E3 e.g. Driving on unexpected acceleration Driver will brake and C3 normal driver will destabilization of the Car will leave S3 fatal injuries or C
traffic; free Free Flow Mode snowy, icy road ACC will be deactivated, have problems to vehicle road death will be
driving Driver stabilizes car stabilize the car expected

Combine situations and failures

and determine risk

Figure 6: Methodology of risk assessment

A.3.2 General remarks

For the analytical approach a risk (R = risk) can basically be de-
scribed as a function F of the frequency (f = frequency) of occur-
rence of a hazardous event and the potential severity of the result-
ing harm or damage (S = severity):
R = F(f,S)

5
Definition of “Item” in ISO/WD 26262: E/E system (i. e. a product
which can include mechanical components of different technolo-
gies) or a function which is in the scope of the development ac-
cording to this standard. (NOTE: There can be only one item per
development)
Response3_CoP_e_v5.0.doc Aug. 2009 A41
 Annexes to the Code of Practice for the Design and Evaluation of ADAS

The frequency of occurrence f is in turn influenced by several pa-

rameters:
One factor to be taken into account is how frequently and for how
long individuals find themselves in a situation where the aforemen-
tioned hazards exist (E = probability of exposure).
Another factor that influences the occurrence of an hazardous
event is the avoidance of specified harm or damage through timely
reactions of the persons involved (C = controllability).
The combination E x C represents the value for the probability that
external circumstances occur where a failure has the potential to
produce the aforementioned extent of specified harm or damage.
A further factor is the probability that the system to be imple-
mented may itself cause a hazardous event. This factor, which is
not considered in the formula above, is characterised by unde-
tected random hardware failures of the system components and by
hazardous systematic faults that remained in the system. Because
development in accordance with ISO/WD 26262 should lead to
safe systems, the resulting ASIL describes the minimum require-
ment to be fulfilled by the final system to avoid those failures. For
this reason, the probability is initially not considered in the risk as-
sessment

A.3.3 Input
The prerequisites for the hazard analysis and risk assessment are:
• Item definition: Description of the item, its interfaces, func-
tional requirements, already known safety and reliability re-
quirements, and the field of application of the item
• Failure modes and preliminary known hazards: Documen-
tation of failure modes and preliminary known hazards

A.3.4 Hazard analysis

The hazard analysis and risk assessment method comprises of
three steps:
1. Situation analysis and hazard identification: The goal of
situation analysis and hazard identification is to identify the
potential unintended behaviour of the item that could lead
to a hazardous event.
2. Hazard classification: The goal of hazard classification is to
determine for each failure mode considered the classes of
probability of exposure (E), controllability (C) and severity
(S) for each potentially hazardous driving situation.

Response3_CoP_e_v5.0.doc Aug. 2009 A42

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

3. Risk assessment: Risk assessment determines the re-

quired automotive safety integrity level.
The following sections give on overview on hazard classification
and risk assesment. Informative references from the annex of
ISO/WD 26262 are included in the tables.

Classification of the severity of a potential hazard

The severity of potential harm shall be estimated. The potential
severity shall be assigned to one of the severity classes S0,S1,
S2, S3 in accordance with Table 3.

Class S0 S1 S2 S3
Descrition No injuries light and Severe inju- Life-
moderate ries, possibly threatening
injuries life- injuries (sur-
threatening, vival uncer-
survival prob- tain) or fatal
able injuries
Reference for AIS 0 more than more than more than
single injuries Damage that 10% probabil- 10% probabil- 10% probabil-
(informative) cannot be ity of ity of ity of
classified AIS 1-6 (and AIS 3-6 (and AIS 5 and 6
safety related, not S2 or S3) not S3)
e.g. bumps
with the infra-
structure

Table 3: Categorisation of Severity

Classification of exposure in the initial situation

The driving or operating situations of vehicles range from everyday
parking and everyday driving in the city or on the highway to situa-
tions that require a constellation of various environmental parame-
ters and therefore occur extremely rarely. The probability of expo-
sure of the driving situations shall be classified into the classes E1
, E2, E3, E4 in accordance with Table 4. The given classes differ
between each class by an order of magnitude and represent a
rough classification of probability of exposure.
The proportion of vehicles equipped with the item shall not be
taken into account for the estimation of the probability of exposure.

Class E1 E2 E3 E4
Description Very low Low probabil- Medium prob- High probabil-
probability ity ability ity
Definition of Not specified < 1% of aver- 1% - 10% of > 10% of av-
duration/ age operating average oper- erage operat-
probability of time ating time ing time
exposure

Response3_CoP_e_v5.0.doc Aug. 2009 A43

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

(informative)

Table 4: Categorisation of Exposure

Classification of possible controllability

The evaluation of chances to avert danger, i.e. the controllability, is
an estimation of the probability that the driver or other traffic par-
ticipants cannot gain control of the hazardous event that is arising
and are not able to avoid harm or damage..
One assumes that the driver is in an appropriate condition for driv-
ing (for example not exhausted) with respect to general population,
has appropriate driver's training (has a driver's license) and is
complying with legal regulations. However, a reasonably foresee-
able misuse should also be taken into account.
The controllability by the driver or other traffic participants shall be
classified into the classes C1, C2, C3 in accordance with Table 5.
For situations which are regarded as simply distracting or disturb-
ing but as controllable in general, the class C0 may be introduced.
No ASIL assignment is required for hazards that are assigned to
class C0.

Class C0 C1 C2 C3
Description Controllable in Simply con- Normally con- Difficult to
(informative) general trollable trollable control or
uncontrollable
Definition Distracting More than More than The average
7
99% of aver- 85% of aver- driver or other
age drivers or age drivers or traffic partici-
other traffic other traffic pant is usually
participants participants unable, or
are usually are usually barely able, to
able to control able to control control the
the damage. the damage. damage.

Table 5: Categorisation of Controllability for risk assessment

A.3.5 Risk assessment

The Automotive Safety Integrity Level (ASIL) shall be determined
for each hazardous event using the estimation parameters severity
(S), probability of exposure (E) and controllability (C) in accor-
dance with Table 6.
The ASIL is named ASIL A, B, C and D, where ASIL A implies low
safety requirements and ASIL D implies high safety requirements.
In addition to these safety-related levels, there is also the class

7
in ISO/WD 26262 currently 90%. Considering the results of chap-
ter 4.2 Final proof of controllability by means of a test with naive
subjects the value of 85% is kept here
Response3_CoP_e_v5.0.doc Aug. 2009 A44
 Annexes to the Code of Practice for the Design and Evaluation of ADAS

QM, which stands for Quality Management. A requirement rated as

QM is not considered as a safety-related requirement.

C1 C2 C3
E1 QM QM QM
E2 QM QM QM
S1
E3 QM QM A
E4 QM A B
E1 QM QM QM
E2 QM QM A
S2
E3 QM A B
E4 A B C
E1 QM QM A
E2 QM A B
S3
E3 A B C
E4 B C D

Table 6: Automotive Safety Integrity Level (ASIL) assignment

A.3.6 Work products

• Documentation of failure modes and preliminary known
hazards
• List of potentially hazardous driving situations and operat-
ing conditions
• Documentation of driving situations and operating condi-
tions in the hazard analysis and risk assessment, including
severity, probability of exposure, controllability classification
and resulting ASIL
• Documentation of the safety goals

A.3.7 References
Detailed information for risk analysis can be found in:
ISO/WD 26262-3: Road Vehicles – Functional Safety

Response3_CoP_e_v5.0.doc Aug. 2009 A45

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Annex B Recommendations for controllability evaluation

B.1 Condense hazardous situations

ADAS Systems generate a large number of situations, where a
safe use of the system has to be considered (List of potentially
hazardous situations), if every possible circumstance is taken into
account. On the other hand many of these situations are very simi-
lar and might be tested or evaluated at the same time (e.g. ACC
looses target during daytime or during night time – on a motorway
or major country road …).
Due to practical reasons the scenarios for expert evaluation and
for test evaluation should be limited to most relevant ones.

B.1.1 How to get the complete list of potentially hazardous situations

After a system is defined situations are compiled in a list or in a ta-
ble considering
• where the system should work (normal function),
• where the system could be used but it is not designed for
(misinterpretation and potential misuse),
• where the system limits are reached (system limits)
• and where situations caused by malfunction of the system
(failure).
In each situation the driver may behave or react differently, de-
pending on additional conditions and circumstances (see Figure
7).

situation

locality driver/vehicle

street other driver/driving other

location vehicle
conditions characteristics behaviour characteristics

-motorway -routing -side wind -driver steers -coasting -state of other

-off road -surface -oncoming traffic -driver gets off -standing systems
-car park -slope -traffic jam vehicle -accelerate -ignition on
-... -... -cut in scenarios -... -... -heavily laden
-... -...

Figure 7: Collection of driving situations

B.1.2 How to condense potentially hazardous situations

The maximum number of system relevant situations makes it likely
that no important situation is left out or forgotten. On the other
hand there are many situations that are not safety relevant. After
deleting these not safety relevant situations there are a couple of

Response3_CoP_e_v5.0.doc Aug. 2009 A46

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

situations, which are not controllable and therefore technical solu-

tions are developed. Only the remaining ones take credit from con-
trollability (the driver is needed as part of the safety system).
Similar situations and conditions now can be condensed to a rea-
sonable number of scenarios that cover all controllability relevant
situations. (Figure 8)
The remaining list of situations is the basis to start controllability
evaluation.
Combination of
relevant situation
parameters

Safety
related
hazardous
situations
High
criticality, with Controllability
credit from related
controllability situations and
situation
parameters

Figure 8: Extracting controllability related situations

B.2 Conducting a test with subjects

Before conducting a driving test with subjects several prerequisites
have to be fulfilled. Objectives, methodological approach and ex-
perimental design have to be defined.
Further a decision for the test environment has to be made, test
equipment, skilled and trained test instructors and a trial plan are
needed to conduct a test with subjects.
The following checklist may assist in conducting your own empiri-
cal test trials.

Topic Action Examples / Comments Done

Test Specify each research hypothesis to be e.g. drivers react in time by depressing the
Hypotheses explored in the study in clear and explicit brake pedal after receiving an acoustic warn- 
terms ing in a specific situation XY
Experimental Specify the number and nature of any e.g. an experimental group driving with ADAS
design groups and a control group driving without ADAS 
Specify the dependency of any groups e.g. plan an independent or dependent meas-
ures design 

Response3_CoP_e_v5.0.doc Aug. 2009 A47

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Make a decision for the test environment On-the-road-trials - advantages

• On-the-road-trials - realistic environment
- normal driving behaviour
• Test track - high validity of results
• Simulator (see Annex D) On-the-road-trials - disadvantages
- difficult to create and instrument
- costly and time consuming
- not fully controlled
- potentially less safe, provoking of risk situa-
tions and failure states (fault injection) is often
too unsafe
Test track trials - advantages 
- Allows testing of (simulated) potentially haz-
ardous situations
- Fault injection possible
- Control of influencing variables (Reliability)
- safer than on-the-road trials, although an
element of risk is still involved
Test track trials - disadvantages
- Artificial situation
- No routine driving behaviour
- difficult to create and instrument
- expensive particularly if traffic conditions are
to be simulated
Specify procedures for controlling extra- e.g. randomise or permute the sequence of
neous variables test scenarios for the subjects to avoid se- 
quence effects
Specify the number and sequence of e.g. repeat measurements if possible; but
observations made on the groups some treatments may allow only a single
measurement, afterwards the subjects are
aware of and change their expectations, e.g. 
after fault injections or hazard braking ma-
noeuvres

Response3_CoP_e_v5.0.doc Aug. 2009 A48

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Topic Action Examples / Comments Done

Operational Specify the test scenarios including Due to the decision for the test drive type (test
Definition track, real traffic, simulator) the controllability
- traffic participants and their behaviour, of traffic and environmental conditions is more
- system status, or less difficult.

- environmental conditions,
- specific hazard situations
Specify an operational definition of each independent variables can be e.g. number of
of the following: buttons on steering wheel, ADAS normal use
or an ADAS system failure (fault injection)
All independent variables
dependent variables can be e.g. response
All dependent variables time, velocity, brake pressure, standard devia-
All controlled extraneous variables tion of steering angle, time-to-collision, time-to-
line-crossing, driver's comprehensibility of 
All other extraneous variables system status etc.
controlled extraneous variables can be e.g.
road type (urban, motorway or rural),
other extraneous variables can be e.g.
weather & road conditions, traffic density
Specify the briefing of subjects Is a familiarisation drive required so that the
participant can get used to the vehicle and
ADAS?
Is it intended to give information about the
ADAS to the subjects or will the subject be left
alone with the function and instrumentation? 
Further subjects may be asked to accomplish
a specific list of tasks.
Which instructions have to be given, when and
in which order?
Specify the test procedure with the run The test procedure needs to be detailed and
of events listed e.g. in a trial timetable
Pre-testing the whole test procedure can be 
very useful to identify and avoid possible prob-
lems as well as optimise and fine-tune the test
run.
Sample Specify the procedures for sample selec- Just describe how to make a test with the
tion average driver

A random sample is representing the real

population best and therefore the favoured 
procedure due to its reduced likelihood of bias.
With smaller sample sizes, the Quota sampling
is very popular ensuring the quota of subjects
of specified type (age, gender, driving experi-
ence, etc).
Specify the number of subjects (sample The sample size needed depends mainly on
size) the experimental design. 

Response3_CoP_e_v5.0.doc Aug. 2009 A49

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

B.3 How to setup pass-fail criteria

Pass-/fail criteria are necessary for the final proof of the controlla-
bility of ADAS systems.
No matter which method is chosen to do a final proof, the experts
have to make up their mind which driver reactions are relevant to
solve certain situations of system failure or malfunction.
Pass-/fail criteria are then generated as certain values in the ex-
pected driver reactions.
All these criteria can then be evaluated with any method men-
tioned in Annex D.
The list of risky situations is the basis for setting up the test sce-
narios and for the agenda for the Expert Panel. For a discussion of
the relevant driver behaviour a team of system engineers and hu-
man factors specialists is relevant. The first group provides knowl-
edge over the exact system functionalities, time lines and failure
mode "experience".
With the help of the human factors specialists the foreseeable
driver reactions can be estimated with high probability.
It is not possible to set up quantitative safety relevant measures for
future ADAS systems. A yes/no answer as pass/fail criterion is
needed.
Every risky situation that the driver may end up in must be consid-
ered. Taking into account driver controllability, at least one possil-
ble remedy must be specified by the developer.
For the final proof the test-scenario is “passed” if the subject reacts
as previously anticipated or in an adequate way to solve the situa-
tion.
Certain quantitative and qualitative measures to come to the result
of pass or fail have to be developed individually for each new sys-
tem by evaluation experts.

B.4 How to evaluate controllability by experts

To conduct the Expert Panel ADAS Verification the following
checklist may assist in the selection of expert and input collection
for assessments.

Topic Action Content Done

Selecting Par- Determine, which compe- Engineers from the ADAS development team 
ticipants tences are needed to be
included in the Expert HF department engineers
panel ADAS Verification

External engineers experts on vehicle dynamics and ADAS
compounds 
Safety systems experts 
Experts on vehicle integration 
Accident research experts 
Response3_CoP_e_v5.0.doc Aug. 2009 A50
 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Gathering Inputs Collect all inputs needed List of potentially hazardous scenarios coming from the
to the assessment Risk Analysis 
List of tasks to be performed in potentially hazardous situa-
tions. 
Answers to Response Check list B and/or complementary
Check-Lists 
List of open questions arising during the design process
(Open Item List) 
Vehicle equipped with the system under evaluation and the
definitive HMI 
Estimated controllability levels targeted 
Results of HM Interaction tests conducted during the de-
sign process 
Results of HM Interaction tests coming for similar systems
or HMI already tested. 
Results of previous expert panel assessments done during
the designing process 
Accident research data 
Carrying out the Making the assessment In static conditions, review the all questions coming from
verification pro- under static and dynamic checklists and Open Item List and verify that all problems 
cedure prepar- conditions are solved
ing sign-off
For scenarios including Experts look for weakness and inconsistencies.
recommendation 
- traffic participants and
For each situation the expert panel confirms anticipated
their behaviour,
driver reaction. 
- system status,
- environmental condi- Consider the case of more vulnerable users related to
tions, abilities involved in controllability
- specific hazard situa- 
tions
Additional testing If critical information to signing of is lacking, perform ap-
propriate testing. 
Editing Compile the result of the
verification in a document 

Response3_CoP_e_v5.0.doc Aug. 2009 A51

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Annex C General methods for safety analysis

C.1 Early risk assessment by HAZOP

HAZOP (hazard and operability study) is a procedure that has
been developed in the process industry (e.g., Kirwan, 1994), but
that has recently been proposed for application in assessing the
human and behavioural element in traffic safety measure evalua-
tions as well (Jagtman, 2004).
A HAZOP searches for every conceivable process deviation from
normal operation and then looks at possible causes and conse-
quences. The typical thing about a HAZOP is that the search is
done in a systematic way by a team of specialists from different
backgrounds, so as to minimise the probability that any essential
factors are overlooked.
The search is assisted by putting up a matrix of process parame-
ters and guide words. A combination of a process parameter (e.g.
‘flow’) and a guide word (e.g., ‘reverse’) is a cell in this matrix and
could form a possible deviation.

A) Input / Requirements
• System description, block diagrams etc. to discuss causes
and consequences
• Process parameters and guidewords

No(ne) (Too) (Too) Wrong Failure Un- Un-

high low of known expected
Speed
Direction
Location
Focus of
attention
Attention
Travel time
Speed
difference

• List of questions to be asked for each combination of proc-

ess and guidewords:
- Could the deviation occur?
- If so, how could it arise?
- What are the consequences of the deviation?
- Are the consequences hazardous or do they prevent
efficient operation?
- If so, can we prevent the deviation by changing the
design or the method of operation?
- If so, is the change reasonable?
• Experts representing all possible relevant disciplines

B) Effort
• Time consuming
• experts to discuss the causes and consequences

Response3_CoP_e_v5.0.doc Aug. 2009 A52

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

C) Output / Results
• Identification of potential deviations, causes and conse-
quences
• Hazardous potential and possible mitigation strategies of
deviations

D) Pro / Contra
Pro
• Structured approach, aims at completeness
• Detects hazards and proposes solutions

Contra
• Time consuming to discuss every combination of process
deviation and guideword
• Team of experts needs to be carefully chosen
• Well known method for processes, application to ADAS re-
cently in research

E) References
Jagtman, H.M. (2004). Road Safety by Design: A decision sup-
port tool for identifying ex ante evaluation issues of road safety
measures. Thesis, Delft University of Technology.
Kirwan, B. (1994). A Guide to Practical Human Reliability As-
sessment. Taylor & Francis

C.2 Failure Modes and Effects Analysis (FMEA)

The Failure Modes and Effects Analysis (FMEA) and Failure
Modes, Effects and Criticality Analysis (FMECA) are methods of
reliability analysis intended to identify failures with significant con-
sequences affecting the system performance in the application
considered.
The FMEA is based on that defined system, component or sub-
assembly level where the basic failure criteria (primary failure
modes) are available. In a narrow sense, the FMEA is limited to a
qualitative analysis of failure modes of hardware, and does not in-
clude human errors and software errors, despite the fact that cur-
rent systems are usually subject to both. In a wider sense, these
factors can be included in the FMEA.
FMEA is a technique for design review support and for assurance
and assessment, which should be put into use from the very first
steps of system design. FMEA is appropriate to all levels of system
design.
A logical extension of the FMEA is the consideration of criticality
and probability of occurrence of the failure modes. This criticality
analysis of the identified modes is widely known as FMECA.
FMEA is a standard procedure in the automotive industry whereas
FMECA is rarely used due to the difficulty of obtaining criticality
data at this stage of system development.

Response3_CoP_e_v5.0.doc Aug. 2009 A53

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

A) Input / Requirements
• Basic system description of the function, e.g. block dia-
gram, component drawings
• Expert(s) of the domain concerned

B) Effort
• Depends on complexity
• Panels of 6 to 8 experts from different domains depending
on subject covered by the assessment

C) Output / Results
• Starting from the basic element failure characteristic and
the functional system structure, the FMEA determines the
relationship between the element failures and the system
failure, malfunctions, operational constraints and degrada-
tion of performance or integrity.

D) Pro / Contra
Pro
• FMEA is a standard procedure in the automotive industry
Contra
• Multiple failures and redundancies are not covered by
FMEA

E) References
IEC 60812 – FMEA
VDA vol. 4 part 2.

C.3 Fault tree analysis (FTA)

Fault tree analysis is concerned with the identification and analysis
of conditions and factors, which cause or contribute to the occur-
rence of a defined undesirable event, usually one, which signifi-
cantly affects system performance, economy, safety or other re-
quired characteristics. FTA is often applied to the safety analysis of
systems.
The fault tree is particularly suited to analyse complex systems
comprising several functionally related or dependent subsystems
with different performance objectives. This is especially true when-
ever the system design requires a collaboration of many special-
ised technical design groups. Examples of systems to which fault
tree analysis is commonly applied include nuclear power generat-
ing stations, aeroplanes, communication systems, chemical and
other industrial processes.
The fault tree itself is an organised graphical representation of the
conditions or other factors causing or contributing to the occur-
rence of a defined undesirable event, referred to as “top event”.

Response3_CoP_e_v5.0.doc Aug. 2009 A54

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Fault tree analysis is basically a deductive (top-down) method of

analysis aimed at pinpointing causes or combinations of causes
that can lead to a defined top event. The analysis is mainly qualita-
tive but, depending on certain conditions may also be quantitative.
Reliability and availability prediction techniques, current test and
field use data may be used to establish the quantitative values.
The FTA is widely use in other industries but is also seen more
and more in the automotive industry.

A) Input / Requirements
• Basic system description of the function, e.g. block dia-
gram,
• Definition of undesired event
• Failure rates of basic events

B) Effort
• Depends on system complexity

C) Output / Results
• Probability of undesired event
• Conditions of other events under which the top event will
occur

D) Pro / Contra
Pro
• Delivers quantitative estimations on hazardous events
• FTA-Software is available
Contra
• Depends on failure rates of basic components. Failure
rates are often vague
• Dependencies between failures should be known

E) References
IEC 61025 – Fault tree analysis

C.4 Hardware in the loop (HIL) testing

HIL testing can be applied as soon as a hardware prototype of the
system or even a part of it (e.g. an electronic control unit of a car)
is available. The prototype, called Device Under Test (DUT), is
embedded “in a loop”, which is a software simulated virtual envi-
ronment resembling the real environment as closely as possible.
The DUT is operated under real time conditions.
The software simulation consists of various parts for a vehicle sys-
tem (all the parts that are not available in hardware) and the envi-
ronment. Towards the DUT all the communication including sensor
and actuator data has to be simulated. The underlying vehicle dy-
Response3_CoP_e_v5.0.doc Aug. 2009 A55
 Annexes to the Code of Practice for the Design and Evaluation of ADAS

namics simulation receives data from the DUT, and calculates the
vehicle response depending on the virtual driving state, road sur-
face, traffic situation and other system specific environmental data.
An optional visualisation can be used to observe the simulation
from a developer defined perspective. Depending on the design
stage, the availability of hardware and the required test accuracy
the parts of the system that are implemented in hardware (ECU
only, sensors, actuators,…) will vary.

A) Input / Requirements
• Hardware to be tested
• Simulation models of vehicle systems that are not available
in hardware
• Simulation models of vehicle dynamics and environment

B) Effort
• Test system needed
• Implementation of simulation software

C) Output / Results
• Real time behaviour of a new system

D) Pro / Contra
Pro
• Tests are under real time conditions
• Component testing and optimisation can be done before in-
tegration
• Tests are repeatable with exactly the same parameters
• Tests can be automated
• System behaviour a system limits can be tested
• Failures and potentially hazardous situations can be simu-
lated to test system response
Contra
• Overall vehicle simulation must be available, may be diffi-
cult for a new vehicle prior to system integration
• Quality of results depends on the quality of the simulation
models

Response3_CoP_e_v5.0.doc Aug. 2009 A56

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Annex D General methods of assessment

D.1 Expert panel

Expert panels’ assessment is an analytical approach that can be
used in each development phase. Depending on the subject vari-
ous expertises from experts of different domains is needed. There-
fore, expert panels may consist of: R & D engineers, human fac-
tors specialists, marketing specialists, accident research special-
ists, traffic psychologists etc.
Nevertheless, when controllability issues are concerned, human
factors specialists are essential in expert panels as their evaluation
takes into account scientific knowledge about human behaviour
and cognitive limits (e. g. reaction times, workload assessments,
etc.).

A) Input / Requirements
• From basic system description of the function, e. g. text,
block diagram, model to mock-ups and early prototypes.
• Use cases coming from preliminary task analysis.
• List of potentially hazardous situations to promote complete
assessment

B) Effort
• Low (use of experience + time)
• Panels of experts from various domains depending on sub-
ject covered by the assessment (number of functions, al-
ternative solutions etc.).
• A constant core team (leads to efficient discussion).

C) Output / Results
• Identification of potential or actual problems and causes
(diagnosis)
• Decision and choice support (amongst various solutions or
various warning modalities)
• Most important technical features
• Expert know-how should cover knowledge about bench-
mark and the state-of-the-art, if there are already similar
functions on the market or in the development process
• Possible difficulties
• Possible misuse situations
• Recommendation for Sign-Off

Response3_CoP_e_v5.0.doc Aug. 2009 A57

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

D) Pro / Contra
Pro
• Beneficial cross-checks resulting in various points of view
gathered, as experts can have various technical back-
grounds
• Rapid detection of critical problems and their causes
• Possible even with a low level of description or partial pro-
totypes in early development phases
Contra
• Based on previous experience, therefore limited efficiency
if fully innovative function
• Experts’ judgements are often divergent. Synthesis may
not always be easy to do

Response3_CoP_e_v5.0.doc Aug. 2009 A58

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

D.2 HMI concept simulation

HMI concepts are visualised by computer based rapid prototyping
tools. This enables developers to see what the system looks like
and how the interaction works. The HM Interface should be repre-
sented in real sizes, colours and sounds (and optional: position in
the vehicle). It is used to explore the interaction between driver
and system. Various HMI concepts might be compared using us-
ability criterions like interaction time, number of errors etc.

A) Input / Requirements
• Description of the system functions and transitions
• First concepts of HM Interface and Interaction

B) Effort
• Time for setup and the driver tests (depending on question
and method)

C) Output / Results
• Usability and comprehensibility of dialogue
• Checking how the system fits into the overall concept of
vehicle systems and the influence of the system on other
systems
• Easy comparison of various concepts

D) Pro / Contra
Pro
• No real hardware necessary, maybe suitable “rapid proto-
typing” software to show the functions
• Fast method available at very early system stages
• Gives an idea of system integration possibilities
Contra
• Interaction with driving task is ignored

E) References
Johansson, E., Engström, E., Cherri, C., Nodari, E., Toffetti, A.,
Schindhelm, A., and Gelau, A. (2005): Review of existing tech-
niques and metrics for IVIS and ADAS assessment. Del 2.2.1,
Project AIDE - IST-1-507674-IP.

Response3_CoP_e_v5.0.doc Aug. 2009 A59

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

D.3 Driving simulator test

Driving simulation uses models of vehicle dynamics and virtual
driving scenarios. This allows artificial driving situations and re-
peatable tests with various subjects. Potentially hazardous traffic
scenarios can also be tested because in contrast to real driving the
virtual scenario is harmless.
There are different types of simulators, e.g.
• Mock-up
• Fixed based simulator
• Moving base simulator

During the simulation subjective and objective methods can be

used to measure the performance of test subjects and methods in
the driving task:
• Subjective methods are ratings from the subject itself or an
observer using scales (e.g. NASA-TLX, ZEIS, modified
Cooper-Harper Rating Scale, etc.) and open or closed
questionnaires. They can be combined with video observa-
tion (robustness of behaviour, interview with video replay ->
reasons for reactions).
• Objective data can easily be derived from simulator log files
and physiological measurements on the subject. Typical
examples of quantitative and qualitative data from the driv-
ing scene are reaction times and lane keeping perform-
ance.
Controllability can be tested by some of these methods depending
on the kind of (potentially hazardous) situation to be explored.
Typical situations are: Testing in high risk situations, driver reac-
tions at system take over, testing of false alarms in certain situa-
tions and driver interaction if there is more than one ADAS in the
vehicle.

A) Input / Requirements
• Alternative system designs should be specified
• Appropriate sceneries have to be created
• Test design has to be created

B) Effort
• Effort depending on simulator type and duration of simula-
tion test

C) Output / Results
• Quantitative and qualitative data in repeatable situations
• Data output method in real hazardous situations

Response3_CoP_e_v5.0.doc Aug. 2009 A60

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

D) Pro / Contra
Pro
• ADAS hardware (prototype) is optional – Simulation can be
used in any development stage
• Comparison of alternative system concepts
• Parameters and restrictions are quite easy to control

Contra
• May lead to subject’s simulator sickness. This will influence
the test results.
• Exploring driver behaviour in high vehicle dynamics situa-
tions is difficult because of the missing or lacking accelera-
tion feedback. In these cases just the first reaction might be
similar to real driving.
• Due to the missing impression of acceleration, the driving
results at high vehicle dynamics are not transferable to real
driver behaviour in most cases.

E) References
Östlund, J. et al. (2004): Deliverable 2 – HMI and Safety-
Related Driver Performance. Human Machine Interface and the
Safety of Traffic in Europe. Project HASTE GRD1/2000/25361
S12.319626.

D.4 Driving tests with professional test drivers

Driving tests with professional test drivers provide useful feedback
based on empirical data. Professional drivers are trained to quickly
identify and diagnose actual and potential inadequacies of a sys-
tem. Their judgments are based on double competence: experi-
ence of multiple and different systems and the ability to express
their assessment in a quite standardised manner that is easy to
compare (mainly using scaled questionnaires or check lists).
Check lists are also useful to grant a complete review of critical
items.
Professional test drivers are mainly consulted for two purposes:
1. To make comparative assessments (to compare a system
against other systems on the market or comparisons between dif-
ferent solutions)
2. To assess a feature or a system behaviour according to an in-
ternalised reference (the test drivers play the role of “gold-
standard” or human metrics)
In addition, professional drivers may represent a particular portion
of global drivers’ characteristics distribution (i.e. elderly, young, tall,
short and so on) in order to match some of the particular needs of
those drivers’ classes.
Professional drivers are trained to quickly identify and diagnose
actual and potential inadequacies of a system. When controllability
issues are concerned, professional drivers can estimate, based on
Response3_CoP_e_v5.0.doc Aug. 2009 A61
 Annexes to the Code of Practice for the Design and Evaluation of ADAS

their actual and previous experience, whether or not a system can

be easily handled by an average driver group.
To make comparable judgements between professional drivers,
checklists may be useful to grant complete review of critically
items. Defining particular scenarios may also be necessary to
guide the assessment.

A) Input / Requirements
• Early prototypes and latest versions
• Test scenarios from preliminary task analysis and risk
analysis.
• Check-list of critical issues to provide complete assessment
and to compile remarks.

B) Effort
• The required number of professional test drivers depends
on the amount of work to do, completion, and other rele-
vant influences
• Test campaigns require time (static and dynamic condi-
tions) depending on number of test variations / vehicles
tested.

C) Output / Results
• Identification of potential or actual problems and causes
(diagnosis)
• Comparative results between concurrent HMI
• Helps to make a decision and choice (amongst various so-
lutions or thresholds)
• Most important technical features
• Possible misuse situations

Response3_CoP_e_v5.0.doc Aug. 2009 A62

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

D) Pro / Contra
Pro
• Rapid detection of critical problems and their causes
(where driving tests provide facts only after a long time of
use).
• Assessment possible even with partial prototypes
Contra
• As judgments are based on previous experience, their effi-
ciency may be limited for a fully innovative function
• Test results may be biased if the group of professional test
drivers does not represent the intended user group (age,
sex, level of training).
• Since the judgment of professional drivers may vary a lot,
synthesis may not always be easy to do and elimination of
extreme judgements may be necessary

E) References
Only a few formalised references are available. The method is
based on know-how and subjective appreciation.

D.5 Car clinic with naive subjects

The term "clinic" results from the fact that subjects are usually in-
vited to a special test location. In a static car clinic subjects evalu-
ate a vehicle without driving. In a dynamic car clinic the test per-
sons usually have to accomplish different driving tasks.
The dynamic car clinic as a tool allows to test driver behaviour and
performance while driving the vehicle equipped with the ADAS
system in defined situations in a realistic environment.
Experimental design, type of testing and test scenarios have to be
defined. This includes
1. A decision for test environment
In principle the car clinic can be carried out on public roads
(= highest validity) or on test tracks (= better repeatability and
safety).
2. Data to be collected
Depending on the ADAS function and the related test design
different measures are necessary, e. g.: speed, headway,
steering control, lateral control, gaze, handling errors, observer
ratings etc.
3. Test scenarios to be used
During controllability assessment process different test scenar-
ios may be considered and compared during controllability as-
sessment process. Test scenarios might include type of traffic,
road type, weather and road conditions.

Response3_CoP_e_v5.0.doc Aug. 2009 A63

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

4. The experimental design & sample selection

The design of the test trials needs to be carefully considered
e.g. choosing short term or long term testing with or without
control group and the sample size and selection.
5. The test procedure to be used
The test procedure needs to be detailed and documented e. g.
in a trial schedule.
6. The statistical analysis to be used
For each measure, the type of scale and the statistical analysis
should be specified, e.g. whether a mean or overall score,
minimum or maximum will be applied.
7. A health and safety risk analysis
A health and safety risk analysis of testing must ensure that
participants are not exposed to any risk.

A) Input / Requirements
• As described above detailed and extensive planning by
validation experts is needed
• Further requirements are a prototype vehicle equipped with
ADAS system and data recorder as well as an appropriate
test track and test environment

B) Effort
• A car clinic is time consuming (depends on necessary
sample size, number of test situations etc.)
• May require a high personnel effort (instructor, observer,
various collaborators) and a high monetary effort (for test
track, data recording equipment etc.)

C) Output / Results
• Detailed results about driver’s psycho-motor performance
(reaction time, forces etc.) and mental capabilities (com-
prehension, learnability) are gained

D) Pro / Contra
Pro
• This method provides comparably the most valid results
concerning driver's ability to control an ADAS in assisted
driving situations including system failures and limits
• Testing by average/normal drivers in almost real environ-
ments delivers realistic results
Contra
• May be very time-consuming

Response3_CoP_e_v5.0.doc Aug. 2009 A64

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

E) References
Becker, S., et al. (2000). Experimental Assessment of Driver
Assistance Systems: Method (RESPONSE Project TR4022,
Del. No. D5.1.1). Brussels: EC, DG XIII.
Johansson, E., et al: (2005): Review of existing techniques and
metrics for IVIS and ADAS assessment. Del 2.2.1, Project
AIDE - IST-1-507674-IP. Brussels: EC.
Östlund, J. et al. (2004): Deliverable 2 – HMI and Safety-
Related Driver Performance. Human Machine Interface And the
Safety of Traffic in Europe. Project HASTE GRD1/2000/25361
S12.319626.
Wiethoff, M. (2003). ADVISORS Final Report Annexes. EU pro-
ject ADVISORS, project no. GRD1/2000/10047.

Response3_CoP_e_v5.0.doc Aug. 2009 A65

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Annex E Definition ADAS

Driver Assistance Systems are supporting the driver in their pri-
mary driving task. They inform and warn the driver, provide feed-
back on driver actions, increase comfort and reduce the workload
by actively stabilizing or manoeuvring the car.
They assist the driver and do not take over the driving task com-
pletely, thus the responsibility always remains with the driver.
ADAS are a subset of the driver assistance systems.
ADAS are characterised by all of the following properties:
• support the driver in the primary driving task
• provide active support for lateral and/or longitudinal control
with or without warning
• detect and evaluate the vehicle environment
• use complex signal processing
• direct interaction between the driver and the system
Table 7 gives an overview on driver assistance systems, and high-
lights systems that do not fulfil the above given properties. The list
includes already existing systems as well as potential future sys-
tems that have been defined in Response 2 [ResD2 04].
System name ADAS Comment if no ADAS
yes no
Safe Speed (warning only) x warning only
Safe speed (intervention) x
Safe Following x
Vision Support (with object detection and x
intervention)
Vision Support (without object detection) x no assistance, no com-
plex signal processing
Vision support (adaptive lighting) x
Lane Keeping Support (active support) x
Driver Monitoring x No environmental sens-
ing
Vehicle Dynamics Monitoring (e.g. roll x No environmental sens-
over warning) ing
Pedestrian Protection
detection and warning x
automatic hood (impact detection) x Passive safety
Intersection assistant (active support) x
ESP, ABS x No environmental sens-
ing
Cruise Control, CC x No environmental sens-
ing
Speed Limiter x No environmental sens-
ing

Response3_CoP_e_v5.0.doc Aug. 2009 A66

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

System name ADAS Comment if no ADAS

yes no
Speed Alert Device
preset speed for winter tires x No environmental sens-
ing
environment based dynamic x
speedadaption
Advanced Front Light System x No environmental sens-
ing
Adaptive Brake Light x No environmental sens-
ing
Collision warning and braking x
Active Front Steering x No environmental sens-
ing
Lane Keeping Assist / Heading Control x
Adaptive Suspension System x Stabilisation level
Lane Departure Avoidance x
Rear Vision System x See vision support
Parking assistance (ultrasonic) x No complex signal
processing

Parking assistance (active guidance) x

Brake Assist + Preconditioning (no warn- x No environmental sens-
ing) ing
Adaptive Cruise Control (ACC) x
Rain Sensor Systems x No support in driving
task
Tyre Pressure Monitoring x No environmental sens-
ing
Night Vision System See vision support
Lane Change Assistance x
Blind Spot Monitoring x
ACC Stop & Go x
Automatic Emergency Brake
with possible interaction x
without possible interaction x Active safety system/ no
interaction

Table 7: Driver assistance systems and ADAS criteria

The driving task respectively driver activity may basically be classi-

fied into the following levels:
• Stabilisation Level
• Manoeuvring Level

Response3_CoP_e_v5.0.doc Aug. 2009 A67

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

• Navigation Level
Driving Task

Environment Driver Vehicle Charact.

Time
Road Net Navigation
> 10 sec
Level

Maneuvering
Driving Space 1 - 10 sec
Level

Lateral /
Stabilisation
Road Surface Longitudinal < 1 sec
Level
Dynamic

Vehicle Movement

Figure 9: Driving task levels (RESPONSE 1, Del. No. D2.2, page 29)

To every level of the above described driving tasks a correspond-

ing characteristic time period is allocated in which the respective
driving task is typically performed. In relation to this time period
and the driver action / reaction that is performed, required skills or
knowledge may be assigned to the respective driving task level.

Stabilisation level  automatic driver action

 skill-based

Manoeuvring level  driver makes decision and

applies acquired rules
 based on acquired rules

Navigation level  driver applies knowledge

 knowledge-based

The above mentioned considerations serve to form the following

groups:

Response3_CoP_e_v5.0.doc Aug. 2009 A68

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Driver Assistance Systems

Stabilisation
Navigation Skill based
Knowledge based
Systems of active safety
Information systems (IVIS)
e.g. ABS, ESP
e.g. Navigation System
Assistance in
emergency situations e.g.
Automatic Emergency Brake

Maneuvering
Rule based
Assistance of normal driving
e.g. Lane Change Assist

Advanced Driver Assistance Systems

Figure 10: Driver Assistance systems

Previous driver assistance systems (DAS) evaluate vehicle internal

data and support the driver on the stabilising or navigation levels.
Thus, the systems supporting the driver in vehicle stabilisation may
be classified as “active safety” systems. Systems supporting the
driver in the navigation task may be defined as driver information
systems.
Advanced Driver Assistance Systems (ADAS) support the driver
essentially on the manoeuvring level. In contrast to previous DAS it
is required to detect and evaluate the environment of the vehicle
by means of sensors. This also includes the collection and evalua-
tion of infrastructure based data if these are available. Depending
on the partial task of manoeuvring to be assisted by ADAS, the
driving respectively traffic situation will therefore be monitored and
evaluated by the system specific sensors. The interaction with the
driver is another key property of ADAS.
On the stabilisation level driver activities are performed by means
of automatic activities in short time frames (typically < 1 sec).
Driver Assistance Systems (DAS) are designed to support the
driver in difficult driving situations as for instance ESP. In contrast
to this, driver activities on the manoeuvring level are performed by
means of application of known rules in medium-range time frames
(typ. 1 – 10 sec). The driver will be supported by Advanced Driver
Assistance Systems (ADAS) in their “regular driving profile” of the
day-to-day driving tasks, as for instance Lane Keeping Assist.
They will provide support in safe vehicle operation. But there are
also ADAS available, which do assist on the manoeuvring level,
however only in emergency situations. They will intervene in situa-
tions, which no longer belong into the regular driving profile as for
instance an automatic emergency brake. Therefore, these ADAS
provide support in resuming a safe vehicle operating condition.
Examples for Driver Assistance Systems classification:

Response3_CoP_e_v5.0.doc Aug. 2009 A69

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Level of Automation
Stage of Supported Driver’s Information Processing

Electronic Stability Program (ESP)

Taking
Action

Adaptive Cruise Control (ACC)

Automatic Emergency Brake

Anti Blocking System (ABS)

Lane Keeping Assist

Lane Change Assist

Dual Mode Route Guidance
Processing
Information

Navigation Aid
Acquisition
Information

Supported
Level of
ADAS Driving Task
Navigation Maneuvering Stabilisation

Figure 11: Examples of Driver Assistance systems

Navigation Level
Navigation Support: The navigation system uses data from an ex-
isting data medium (CD-Rom or DVD) in connection with current
traffic news and calculates the desired driving route. The driver re-
ceives visible and/or acoustic information, which facilitate naviga-
tion respectively destination search. The vehicle steering task re-
mains with the driver.

Stabilisation Level
Electronic Stability Program (ESP) with vehicle integrated sensors
like for wheel torque, steering wheel angle or the vehicle yaw
movement the system evaluates whether the vehicle remains in a
driving physically stable state. If the vehicle exceeds a defined
threshold in the direction of under or over steering the drive and
brake system automatically takes over and performs a stabilising
intervention on the wheels. The driver has no direct influence on
this mechanism.
Manoeuvring Level
Adaptive Cruise Control (ACC): The ACC is one of the first ADAS.
This function is a further development of the CC (Cruise Control),
which allows the driver to only set a defined speed in the vehicle.
CC is not sensitive to the vehicle environment, in particular not to
the preceding traffic. The ACC however monitors the area in front
of the vehicle by means of a sensor (radar or lidar). If a vehicle
with a lower speed is in front of the vehicle the ACC will respond

Response3_CoP_e_v5.0.doc Aug. 2009 A70

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

with a vehicle deceleration in order to not exceed a pre-set dis-

tance to the preceding vehicle. Nowadays, the driver is always
able to interact.

Response3_CoP_e_v5.0.doc Aug. 2009 A71

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Annex F Documentation sheet

The documentation sheet may be used after completion of the
CoP as proof for implementation.
For documentation purposes you may attach the completed check-
lists to the documentation sheet.
A differentiation must be made between ADAS new development
or a further development of an existing ADAS. For a further devel-
opment it suffices to only document relevant modifications and
give a reference to the original system.
The documentation sheet serves as confirmation that the ADAS is
safe to use.

Response3_CoP_e_v5.0.doc Aug. 2009 A72

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Documentation Sheet
Code of Practice for ADAS:

Organisational unit:
______________________________________

Name of ADAS:
___________________________________________________________________________

Brief description of function:

___________________________________________________________________________
___________________________________________________________________________

ADAS new development

ADAS further development of system:
___________________________________________________________________________

This ADAS has been developed in compliance with the CoP and is recommended for sign off.

Date, signature

Response3_CoP_e_v5.0.doc Aug. 2009 A73

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Annex G Criteria for HMI concept selection

(background information)
For the integration and classification of an ADAS to be developed
the knowledge of already existing HM Interaction and vehicle ar-
chitecture is required. It makes sense to compare the possible HMI
concepts by means of the following matrix and perform a concept
evaluation.

Driving task Driver perception Work field driver Interaction

priorities
(Annex G.1) (Annex G.2) (Annex G.3)
(Annex G.3)
Criteria -primary - visual Operation areas - Safe driving
Navigation -w/o eye movement - Reach areas - Additional
tasks
Manoeuvring -foveal -Hand
Time re-
Stabilisation -periphery w/o / with torso
quirement
movement
-secondary -With eye movement
Operation
-Foot well
-tertiary -With turning of head frequency
- auditive
- haptic
HMI con-
cept 1
HMI con-
cept 2
HMI con-
cept n

Table 8: Concept comparison for HMI

G.1 Classification and evaluation according to driving tasks

Discriminating consideration of driving tasks serves to lead to a
classification of ADAS concerning importance for safe vehicle op-
eration. In order to assist the integration of the new ADAS system
into the vehicle the ADAS is classified into these driving tasks.
The primary tasks of the driver may be classified into the following
levels according to Response 1 (deliverable 4.1 / 4.2):

A) Primary tasks (vehicle operation, vehicle control)

• Navigation
The navigation level comprises mainly destination finding
via a suitable driving route
• Manoeuvring

Response3_CoP_e_v5.0.doc Aug. 2009 A74

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

The manoeuvring level comprises several sub-tasks (e. g.

track manoeuvring, collision avoidance, adhering to traffic
rules)
• Stabilisation
On the stabilisation level we may differentiate between the
sub-tasks longitudinal manoeuvring (e. g. vehicle speed
control) and transverse manoeuvring (e. g. cross wind bal-
ancing, rough lane surface, cornering).

B) Secondary tasks
(Source: Bubb H. “Umsetzung psychologischer Forschungsergeb-
nisse in die ergonomische Gestaltung von Fahrerassistenzsyste-
men“, 1992)
• Secondary reactive tasks: Driver reacts traffic related. This
includes for instance dipping headlights, operating wipers
but also clutch and gear shifting.
• Secondary active tasks: Driver acts. The task is not directly
traffic related. For instance driver wishes to receive current
information (navigation, traffic news).

C) Tertiary tasks (Source: Bubb H.)

Tertiary tasks are not directly linked to the driving task. They
merely serve to satisfy comfort, entertainment or general informa-
tion requests. These are amongst others radio, telephone or mis-
cellaneous entertainment devices.

G.2 Driver information perception

Humans receive information via their sensory organs. These re-
ceptors are also called sensory modalities and may percept vari-
ous stimuli and sensations in limited spectra.
Human perception varies from human to human. The performance
of senses typically deteriorates with increasing age.
Human perceptions may be classified in five senses:
• sense of smell (olfactory)
• sense of taste (gustatory)
• hearing (auditive)
• vision (visual)
• sense of touch and motion (haptic)
As for Human Machine Interface for the comparison of ADAS con-
cepts visual, auditive and haptic information perceptions are impor-
tant and are discussed in the following:

G.2.1 Visual information perception

Response3_CoP_e_v5.0.doc Aug. 2009 A75

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Concerning the design of display and control elements it must be

taken into consideration that human visual information perception
is limited by various conditions.

Limits of visual information perception in the field of view

The human eye may only see sharply in the area of approx. 3 de-
grees (foveal vision), while the periphery (peripheral vision) mainly
serves the recognition of movements and three-dimensional rec-
ognition.

Without eye and without head movement

If the gaze is fixed onto an object (foveal) sharp seeing is possible
in the fixation area (Figure 12: green (most inner) sight cone, area
approx. +/- 3°). Outside the fixation area, the so- called periphery
area the partly limited perception ability of the eye is compensated
by the brain. Perception in the periphery is largely limited to light /
dark contrasts. Here events may occur that a human may over-
look.

With eye and without head movement

Figure 12 shows the field of view without head movement within a
red vision cone. The field of view defines the maximum area,
which may be covered with a fixed head by eye movements only.
In order to cover the field of view it is necessary to direct the gaze
by eye movement onto a new location. During such a change of
gaze, a so-called saccade, the eye does not receive any informa-
tion. A sight cone of approx. +/- 15 degrees (Figure 12: Yellow
sight cone) is considered as optimal field of view. This area corre-
sponds to approximately half of the maximum field of view and
may be achieved by means of “comfortable” eye movements. The
maximum field of view (approx. +/- 35 degrees horizontally and –
20 to + 40 degrees vertically, see Figure 12) is shown in the red
sight cone.

Response3_CoP_e_v5.0.doc Aug. 2009 A76

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Figure 12: Simplified demonstration of field of view limits

With eye and with head movements

In order to cover further areas, a head movement with the required
time period is necessary. This is called the overall/entire field of
view.

Information perception limits depending on display

Considering the display design of the ADAS Human Machine Inter-
face further restriction must be taken into consideration.
Every human has a different colour perception. The sensitivity of
the receptors (cones on the retina) is genetically coded. There are
three kinds of colour sensors, which have a good perception of
blue, green and red. Also the ability of humans to perceive light is
not the same for all colours. There are humans who are not able to
differentiate between certain colours due to colour blindness. Re-
strictions in visual information perception due to colour recognition
deficits may be compensated by clear shapes. Here it may be of
help if a uniform optical picture language is used (e. g. standard
symbols ISO 2575).
Further perception limits are due to brightness influences (e. g. in-
solation, dazzling by opposite traffic) and darkness (e. g. driving at
night).

G.2.2 Acoustic information perception

The human audibility range is shown in Figure 13. With increasing
age the hearing ability decreases.
Figure 13 shows the bold bottom line as the human hearing
threshold level. The grey top line corresponds to the threshold of
pain. The thin lines in between are graphs of the same sound in-
tensity.
Response3_CoP_e_v5.0.doc Aug. 2009 A77
 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Figure 13: Limits of acoustic perception. Source Pompino-

Marschall (1995), page 145

G.2.3 Haptic information perception

Tactile perception describes surface sensitivity, which is also re-
ferred to as sense of touch. Sense of touch describes the percep-
tion of mechanical environmental influences via various mechano
receptors in the skin. In combination with the haptic perceptions
this information enables the brain to locate and evaluate touch,
pressure and temperature.
We differentiate the following:
Quality Receptor Character Adaptation
Pressure Merkel cells, Intensity detectors Slow
Ruffini bodies
(proportional)
Touch Meissner bodies, Speed detectors Fast
hair follicle recep-
(differential)
tors
Vibrations Vater-Pacini bod- Speed detectors Very fast
ies
Pain Free nerve end- Non-adapting
ing (Nozi recep-
tor)
Tempera- Warm and cold Proportional and Adaptation
ture receptor differential between 20
and 40 de-
grees Celsius

Response3_CoP_e_v5.0.doc Aug. 2009 A78

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Table 9: Haptic perception

Out of the mentioned sense qualities, for ADAS vibrations may be

used for driver information. All contact areas between body and
vehicle can be considered for applying the vibrations. Vibrational
perception has the lowest threshold of 150 – 300 Hz at the finger-
tips. Higher amplitudes are necessary outside this frequency range
and other application areas.
When driving a vehicle the perception of speed plays a significant
role. This speed is enabled by means of kinaesthetic as well as
vestibular perception. Kinaesthetic perception is a further compo-
nent of haptic perception, which enables recognition of the direc-
tion of motion via muscles, tendons and sinews. Vestibular percep-
tion recognises dislocation and change in location respective rota-
tion via the auris interna.

G.3 Driver’s field of work

The driver’s work field comprises the operation areas for the hands
(reach area) and the feet (foot well). For the following differentia-
tion of the operation areas it is a prerequisite that the driver sits up-
right in the driver seat and wears a seat belt.
Figure 14 gives and overview of reach areas, within which the
driver can operate in an upright seating position. We must differen-
tiate reach areas, which can be reached without torso movement
(Figure 14: Red areas) and the extended reach area, which can be
reached by slight torso movement respectively by turning the
shoulder (Figure 14: blue area). The foot well (Figure 14: Green
square) describes the area, which can be reached with the feet.

Figure 14: Detailed description of foot well and reach areas

Priorities of HMI Interaction

Response3_CoP_e_v5.0.doc Aug. 2009 A79
 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Required HM Interactions of ADAS and driver may be differenti-

ated according to importance related to the driving task.
The most important task is safe manoeuvring of the vehicle, which
is the primary task on the stabilisation level. Additional tasks are
for instance navigation operation or air condition setting.
From this consideration priority classes may be derived. The clas-
sification is mainly oriented on urgency, task fulfilment. Further
classifying factors are time need for the interactions and interaction
frequency.
Urgency
• very important (direct influence on traffic and operation
safety, information and activity in short time periods)
• important (influence on driving sequence, activity required
in short time periods)
• less important (relevance secondary, activity not time rele-
vant)
• more or less unimportant (gaze aversion possible without
time consequences, e. g. activity in vehicle at standstill)
Time requirement for interactions on control and display element
• short interaction times (< 1 sec.)
• medium interaction times
• long interaction times (>2 sec)

Response3_CoP_e_v5.0.doc Aug. 2009 A80

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Interaction frequency
• very frequent (repeatedly per journey)
• frequent (every journey)
• rarely (every x journey)
• very rarely (occasionally)
• not during journey (activity / display) only in vehicle at
standstill necessary respectively possible)

G.4 HMI architecture principles

The following interpretation notes serve to support a driver-suited
HMI design:
Regulations and standards (see Annex A, page 9)
• Type approval
In order to introduce a vehicle with all its components in a
market, it is necessary to comply with the required market
specific type approval regulations.
• Standards, HMI Standards
Standardisation is a systematic establishing of a standard
by the affected experts. The standardisation may affect
many areas, as for instance procedures, measurements,
properties etc. The application of a standard, regardless
whether national, European or international is voluntary,
even if the standard is considered a safety standard in cer-
tain product safety laws. However, the application of a
standard may lead to the presumption that a product is not
defective and / or the manufacturer has observed the nec-
essary duty of care. Therefore, this assumption may be-
come binding, even if it is not legally binding
• Technical rule
A technical rule serves as an instruction to resolve a multi-
tude of issues in the field of engineering, and which is ac-
cepted among experts in the relevant specialist area.
• State-of-the-art
In addition to the existing regulations of type approval and
existing standards as well as technical specifications, the
state-of-the-art of the respective product group must be
considered in order to ensure compliance with the traffic
safety duty of a manufacturer.
Consumer expectation
A defect-free design is a justified consumer expectation. The fol-
lowing principles serve as assistance to a driver-suited HMI de-
sign:
• Unambiguity of display and control elements is the design
objective

Response3_CoP_e_v5.0.doc Aug. 2009 A81

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

• A further objective in the design of control and display ele-

ments is self-descriptiveness resulting in intuitive correct
use.
• The influence of vehicle design on structure and location of
displays and control elements shall be evaluated taking into
consideration ergonomic and functional factors.
• It makes sense to adhere to the same arrangement and
structure of display and control elements within one pro-
duction series of an OEM.
• A uniform control logic facilitates intuitively correct opera-
tion for the driver
• The history of the HMI design serves as a significant basis
for further development
• Existing „mental models“ should be taken into considera-
tion when designing the new ADAS
• It makes sense to adhere to known functional principles (e.
g. switches with raster function in contrast to pushbutton)
• Innovation steps should not be too extensive. Often it
makes sense to either modify only the display elements or
only the control elements.
• Consider competitor solutions if available prior to the first
layout and design of new displays or control elements.
• Information from the dialogue between driver and ADAS
should fit into the hierarchy of the existing systems
• Suitability of various sense channels (visual, acoustic, hap-
tic) should be checked individually and also in combination
Stimulus satiation should be avoided. Take into consideration that
besides ADAS also other systems are interacting with the driver.
For the layout of system feedback consider possible driver reac-
tions to these ADAS interactions with the driver.

Response3_CoP_e_v5.0.doc Aug. 2009 A82

 Annexes to the Code of Practice for the Design and Evaluation of ADAS

Annex H References
[ResD2 04]: Becker, S. et al.;Response 2 Del. 2: “Risk Benefit
Analysis”; Project Report 2004
[ResD42 99]: Becker, S; Kopf, M. et al.; Response Del. 4.2:
“Checklist for theoretical Assessment of Advanced Driver Assis-
tance Systems: Methods, Results and Assessment of Applicabil-
ity”, Project report 1999
[IP_D4 06]: PReVENT IP public deliverable IP D4 on Functional
Requirements
[Schw 04]: Schwarz, J. (2004). RESPONSE II. WP3: Methodolo-
gies for Risk-Benefit Analysis.
[Red 97]: Redmill, F ; Rajan, J: Human factors in safety critical
systems; Butterworth-Heinemann 1997, p. 49

Response3_CoP_e_v5.0.doc Aug. 2009 A83