Lars Schnieder - René S.

Hosse

Safety of the
Intended
Functionality
Guide
Refining the safety of the
target function on the way to
autonomous driving
essentials
essentials provide up-to-date knowledge in a concentrated form. The essence of
what matters as "state of the art" in the current professional discussion or in
practice. essentials informs quickly, uncomplicatedly and understandably

• as an introduction to a current topic from your field of expertise

• as an introduction to a subject area that is still unknown to you
• as an insight to be able to have a say on the topic

The books in electronic and printed form present the expert knowledge of
Springer specialist authors in a compact form. They are particularly suitable for
use as eBooks on tablet PCs, eBook readers and smartphones. essentials:
Knowledge modules from business, social sciences and the humanities, from
technology and the natural sciences, as well as from medicine, psychology and
the health professions. By renowned authors from all Springer publishing brands.

Other volumes in the series http://www.springer.com/series/13088

Lars Schnieder - René S. Hosse

Safety of the Intended

Functionality Guide
Refining the safety of the
target function on the way to
autonomous driving
Lars Schnieder René S. Hosse
ESE Engineering ESE Engineering
Software-Development GmbH Software-Development GmbH
Braunschweig, Germany Braunschweig, Germany

ISSN 2197-6708ISSN2197-6716 (electronic)

essentials
ISBN 978-3-658-25022-5ISBN978-3-658-25023-2eBook)
https://doi.org/10.1007/978-3-658-25023-2

The German National Library lists this publication in the Deutsche Nationalbiblio- graphie;
detailed bibliographic data are available on the Internet at http://dnb.d-nb.de.

Springer Vieweg
© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2019
The work including all its parts is protected by copyright. Any use not expressly permitted by
copyright law requires the prior consent of the publisher. This applies in particular to
duplications, adaptations, translations, microfilming and storage and processing in electronic
systems.
The reproduction of common names, trade names, product designations, etc. in this work does
not justify the assumption that such names are to be considered free in the sense of trademark
and brand protection legislation and may therefore be used by anyone, even without special
identification.
The publisher, the authors and the editors assume that the data and information in this work are
complete and correct at the time of publication. Neither the publisher, nor the authors, nor the
editors make any warranty, express or implied, as to the content of the work, any errors or
statements. The publisher remains neutral with regard to geographic assignments and area
designations in published maps and institutional addresses.

Springer Vieweg is an imprint of the registered company Springer Fachmedien Wiesbaden

GmbH and is part of Springer Nature
The address of the company is: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany
What you can find in this essential

• A definition of the term Safety of the intended functionality (SOTIF)

• Explanation of the basic concepts and methods in the design of safety in use
with a practical example.
• One explanation is that in the engineering of automotive applications, usability
safety is a third design task on an equal footing with functional safety and
cybersecurity.
• A presentation of the motivation for a structured design approach
of safety in use as a contribution to a sustainable improvement in road safety
("Vision Zero").
• Explanation of the structured development approach of the safety in use
from the conception of driver assistance and vehicle automation to implementation and
successful property validation.
• Presentation of the spectrum of measures in the design of driver assistance and
Vehicle automation aimed at controlling identified risks from incorrect
execution of their target function.

V
Foreword

The ubiquitous buzzword of the digitalization of traffic means in concrete terms

an increase in driver assistance and vehicle automation in road traffic vehicles.
Vehicles are increasingly networked with each other and with their environment.
Future vehicles will perceive their environment to a greater extent, interpret
increasingly complex traffic situations, and perform driving maneuvers
independently to a greater perspec- tive degree. Against this background, the
careful safeguarding of increasingly complex vehicle functions is the order of the
day.
The authors are familiar with the current developments in the standardization
landscape of the automotive industry in their work in the assessment of safety-
relevant electronic control systems for motor vehicles. According to prevailing
legal opinion, standards are a generally accepted benchmark of what is legally
required. For all those involved in the development of driver assistance and
vehicle automation, standards contain clear recommendations on the design of
development processes and features to be taken into account in product design.
The standards landscape for automotive applications is currently being
consolidated on the basis of initial experience in the design of functionally safe
control systems for motor vehicles (ISO 26262, 2nd Edition). Parallel to this,
international standardization projects are underway for the activities presented in
this essential to ensure safety of the intended functionality (SOTIF). The
automotive industry is developing a comprehensive understanding of safety. The
aim of the current standardization activities is to achieve a coordinated interaction
between safety of use, security against attack (cybersecurity, cf. an essential also
published by the authors at Springer) and the "classic" view of functional safety.
The motivation of this essential is to present this holistic understanding of
security with a special focus on security of use.

VII
 VIIIVoreword

This essential is aimed at all practitioners involved in the development of

driver assistance and vehicle automation for road traffic. The addressees are - in
accordance with the complexity of the topic under consideration - necessarily
interdisciplinary. This essential is addressed to engineers and computer scientists
in charge of development and property protection as well as to engineering
psychologists and lawyers dealing with product liability issues. We would like to
thank our partners in various companies in the automotive industry and in the
international research community. The understanding of a holistic safety
paradigm in the automotive industry documented in this essential has been
developed on the basis of many exciting expert dialogs.
trie has grown.

Brunswick Dr.-Ing. Lars Schnieder

October 2018 René S. Hosse
Table of contents

1 Everything can be explained more easily with an example ........................1

2 SOTIF - What it is and what it is not ...........................................................3
2.1 Delimitation to the correctness of the
Safety function (ISO 26262) ...................................................................4
2.2 Distinction from compromise prevention of the safety function (SAE J
3061). ...................................................................................................... 6
2.3 Completeness of the safety function according to
ISO PAS 21448 ....................................................................................... 7
3 Why do we need SOTIF?...............................................................................9
3.1 The risk of the unknown and uncertain
System states ......................................................................................... 11
3.2 The risk of known and uncertain system states .....................................12
4 The SOTIF procedure model ...................................................................... 13
4.1 Basic structure of the SOTIF process building......................................13
4.2 Process steps according to ISO/SAE J 21448 at a glance .....................15
4.3 Relations to neighboring disciplines ..................................................... 16
5 Case study on the design of SOTIF ............................................................ 19
5.1 SOTIF Concept Phase ........................................................................... 19
5.1.1 Function and system description ............................................... 20
5.1.2 Methods of Functional Hazard Analysis
and Risk Assessment ................................................................. 22
5.2 SOTIF Implementation Phase ............................................................... 28
5.2.1 Measures of system improvements ...........................................28
5.2.2 Measures of limitation of the target function ............................29

IX
 XIndex

5.2.3
Measures of return of responsibility
for the driving task to the driver ................................................ 30
5.2.4 Measures to control the
reasonably foreseeable misuse .................................................. 31
5.3 Verification and validation of SOTIF requirements ............................... 32
5.3.1 Proof of concept - preliminary verification and
Validation of SOTIF requirements ............................................34
5.3.2 Property validation - final verification
and validation of
SOTIF requirements .................................................................. 35
5.3.3 Product monitoring - confirmation of the
Verification and validation through field experience ................. 36
6 Conclusion and Outlook ................................................................................ 39

Literature43........................................................................................................
Everything can be explained
more easily with an example 1

The aim of this essential is to provide a practical guide for the application of the
Safety of the Intended Functionality (SOTIF) methods in the development of
safety-relevant electronic control systems for motor vehicles. In order to achieve
this goal, the theoretical and normative principles of the safety of the intended
function are first presented in the chapters presented, and these are then illustrated
again in a practical manner using a real accident example that occurred due to an
uncertainty in the intended function. Due to the comprehensive reappraisal of a
fatal accident with a Tesla Model S from May 07, 2016 by the National Traffic
Safety Board (NTSB) in the United States of America, this accident is used to
illustrate the previously presented concepts (NTSB 2017):

At 04:36 1on the afternoon of May 7, 2016, a westbound

Example
direction on U.S. Highway 27 A with a tractor-drawn semitrailer. At the time
of the collision, the tractor-trailer was turning from the two oncoming lanes
across the two westbound lanes onto a minor roadway. The passenger car
struck the right side of the turning semitrailer, drove under it, and exited the
highway to the right, breaching the side drainage ditch, two pasture fences,
and coming to a final stop only at a utility pole. The occupant of the vehicle
died immediately as a result of the accident. The accident analysis revealed
that the accident vehicle crashed while various automatic driving functions
(lane departure warning, adaptive longitudinal guidance and emergency brake
assist) were active.

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 20191

L. Schnieder and R. S. Hosse, Guide Safety of the Intended Functionality,
essentials, https://doi.org/10.1007/978-3-658-25023-2_1
2 1 Everything is easier to explain with an example

The investigation report (NTSB 2017) makes it clear that many different
factors contributed to the accident. The various causes contributing to the
accident (including the design of the sensor system, the design of the human-
machine interaction, and a foreseeable misuse or improper use of the vehicle
automation system by the driver) have many points of relationship to the design
of a robust and safe target function. This is exactly the subject of the SOTIF
approach.

Accident sequence from 07 May 2016 (NTSB 2017)

SOTIF - What it is and what it is not2

From the perspective of engineering science, safety is usually defined as

"freedom from unacceptable risks". On closer examination, however, this abstract
concept of safety requires concretization, since current standardization activities
for the comprehensive concept of "safety" have crystallized various sub-concepts,
each of which in itself makes different contributions to the overarching goal of
"safety".
"safer" vehicles can afford.
For this essential, the focus on safety-relevant electronic control systems for
motor vehicles is important. On the one hand, these can be active safety systems
(for example, vehicle dynamics control). These are designed to prevent accidents.
On the other hand, they can also be passive safety systems. These are designed to
reduce the severity of accidents (e.g. airbags). Safety-relevant electronic control
systems for motor vehicles include safety-oriented environment perception, data
processing and a response that varies in individual cases (from informing or warning
the driver to intervention). Other safety-oriented measures such as the design
optimization of the vehicle in terms of greater crash resistance or electrical safety
are not the subject of this essential.
In relation to the focus of this essentials described above, the current view in
the automotive industry is that safety is the coordinated interaction of functional
safety, safety of the intended functionality (SOTIF) and cyber security; these
three areas combine to form an integral approach (see Fig. 2.1).
These three sub-concepts are presented and distinguished from each other in
the following.

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 20193

L. Schnieder and R. S. Hosse, Guide Safety of the Intended Functionality,
essentials, https://doi.org/10.1007/978-3-658-25023-2_2
4 2 SOTIF - What it is and what it is not

Fig. 2.1 Axes of safety for safety-related electronic control systems for motor vehicles

2.1 Distinction from the correctness

of the safety function (ISO
26262)

Functional safety is the part of safety that depends on the correct functioning of
the safety-related system and other risk-reducing measures (i.e., the identified
safety functions). The goal is to evaluate the potential functional failure and
implement appropriate measures to avoid systemic failures and random failures.
In this way, the residual risk is reduced to an acceptable level. Functional safety is
comprehensively described in ISO 26262 and represents the industry-wide
standard in the development of safety-related electronic control systems for motor
vehicles. With the completion of the revision of ISO 26262 (so-called 2nd
Edition), this objective of functional safety is sharpened. This focus is illustrated
in Table 2.1 by comparing the relevant text passages of the different editions of
the standard. Here, the definitions of the initial version (issue date 2011) are
shown on the left and the definitions of the revised standard (published in the
final draft in October 2018) on the right. In the comparison of the two
2.1 Distinction from the correctness of the safety function (ISO 26262)5

Tab. 2.1 Comparison of hazard and risk analysis requirements between ISO 26262:2011 and
ISO 26262:2016
ISO 26262:2011 ISO 26262:2018a
3-7.4.2.2.1 The hazards shall be 3-6.4.2.2 The hazards shall be determined
determined systematically by systematically based on the
using adequate techniques possible malfunctioning
behavior of the item

3-7.4.2.2.2 Hazards shall be defined 3-6.4.2.3 Hazards caused by

in terms of the conditions malfunctioning behavior of
or behavior that can be the item shall be defined at
observed at the vehicle level the vehicle level
aAs onlythe DIS (Draft Inter- national Standard) version of ISO 26262:2018 is officially
available at the time of publication of this essential, it is referenced here.

Definition components that are omitted from standards are shown in strikethrough
and those that are added are shown in bold.
In addition to the sharpening of the scope, clause 5.4.2.3 of ISO 26262:2018
additionally refers to the sub-disciplines of attack safety (cf. clause 2.2 here) and
safety of the intended function (cf. clause 2.3) as relevant for the development of
safety-relevant electronic control systems for motor vehicles.
The principles for implementing functional safety in automotive applications
are the subject of this essential only to the extent that it serves to delimit the
specific activities aimed at safety in use (see below).
 Definition With the design goal of functional safety, methods for controlling
systematic errors and random errors are specifically applied in system design. For
this purpose, a risk analysis is first carried out in which various driving
maneuvers are structured according to their frequency of occurrence.
the reliability, controllability in the event of a functional failure, and the severity of possible
The risk analysis is used to assess the probability of damage. The results of the
risk analysis are used to derive safety integrity requirements (Auto- motive Safety
Integrity Level, ASIL) for individual safety functions, which describe the scope
of measures to be taken against systematic and random faults.
Systematic errors always have the same critical effect. They have their
causes in the system development. One example of this is incorrect or incomplete
implementation of safety requirements, which results in a
6 2 SOTIF - What it is and what it is not

erroneous system design. ISO 26262 requires the implementation of

comprehensive measures to avoid systematic errors. Examples include the
mandatory implementation of confirmation measures (functional safety audits,
independent confirmation reviews, and the assessment of functional safety by
independent persons).
Random errors occur at runtime of the system. Examples include failures of
electronic components in the hardware used or failures and corruption in data
transmission. ISO 26262 requires concrete technical safety mechanisms to control
random errors. The starting point is always error detection, for example by self-
monitoring of the system during operation, the subsequent assumption of the safe
state in the event of detected deviations, and the maintenance of the safe state.

2.2 Demarcation from the

Compromise prevention of the safety function (SAE J
3061)

Cybersecurity aims at preventing the compromise of security functions. The focus

here is on protecting the security-relevant electronic control system under
consideration from threats from the system environment. Threat vectors act from
outside on the security-relevant electronic control system under consideration and
can negatively influence its correct functioning. As a result, this subdiscipline is
closely related to functional safety (see section 2.1) and safety in use (see section
2.3):

• Attacks from the outside can leverage security functions that have been
implemented in a targeted manner and thus have a negative impact on
functional security.
• Attacks from outside can deliberately provoke previously unknown insecure
system behavior and thus have a negative impact on the security of use.

Attack security is the subject of a current international standardization project

(SAE J 3061). Attack security is not considered in this essential. Cybersecurity is
presented in another essential written by the authors.
2.3 Completeness of the safety function according to ISO PAS 214487

 The design goal of preventing the compromise of the security function is

achieved through dedicated technical measures that originate in an identification
of threats and an analysis of the risks corresponding to them. Based on this,
comprehensive
technical for attack protection have been worked out. These include among others
Protective measures such as PIN or password protection or a digital signature for
control programs to prevent the execution of unauthorized software in the system
under consideration (Schnieder and Hosse 2018).

2.3Completeness ofthe safety function

according to ISO PAS 21448

The safety in use considers the safety of the target function, or target functional
safety, to be provided by the system under consideration. In this context, the
system under consideration must not pose any intolerable hazards to persons if it
is used as intended or if it is expected to be used incorrectly. Hazards may arise
due to incomplete specification or expected (mis)use of the functions. The subject
of safety of intended use (SOTIF) is currently being developed in an international
standardization project.
The completeness of the safety function is at the heart of this essentials
and will be considered in more detail in the following sections.
 The objective of safety of intended function (SOTIF) is to improve
knowledge about the possible system behavior even in previously unknown
application scenarios. A hazard in the sense of target functional safety occurs
when a system, while complying with all the predefined
specified requirements can nevertheless be transferred to an unsafe state.
and, as a result, an accident can occur.
Why do we need SOTIF?
3

Even if a considered safety-relevant electronic control system for motor vehicles

is free of faults and safe in the sense of functional failure according to the
definition of ISO 26262, safety violations may still occur due to previously
unforeseen system behavior: The possible event space in road traffic can basically
be divided into a set of safe events and unsafe events (see Fig. 3.1). Unsafe events
are represented by areas 2 and 3 in Fig. 3.1. The safe events are defined by the
areas 1 and 4. Furthermore, the event space can be divided into known events and
unknown events. The set of known events is represented by the areas 1 and 2. The
unknown events, on the other hand, are defined by the areas 3 and 4. The
intersection of the characteristics "known/unknown" and "certainty/uncertainty"
of possible events results in four possible combinations:

• Range of known and safe system states (area 1)

• Range of known and uncertain system states (area 2)
• Area of unknown and uncertain system states (area 3)
• Area of unknown and safe system states (area 4)

The goal of SOTIF is to define a structured design process for the avoidance of
safety violations caused by a faulty target function. A target function is
considered to be faulty if the system behavior is not sufficiently known and
specified. Therefore, SOTIF elaborates dedicated sector 3, unknown and unsafe
events. After methods

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 20199

L. Schnieder and R. S. Hosse, Guide Safety of the Intended Functionality,
essentials, https://doi.org/10.1007/978-3-658-25023-2_3
10 3 Why do we need SOTIF?

Fig. 3.1 Differentiation of the event space according to familiarity and safety

are applied that reduces the amount of unknown and unsafe events, hazard control
measures can be taken that reduce the amount of unsafe events now known,
making the system safer.
In addition to vehicle manufacturers, SOTIF will also play an increasingly
important role in the future for suppliers of complex safety-related electronic
control systems for motor vehicles. Due to the increase in complexity of today's
control units, especially in the area of driver assistance systems and high
automation, the structured consideration of an unknown uncertain system
behavior becomes more important. As long as the systems only reach a level of
automation of Level 2 (partially automated, partial automation) according to SAE
J 3016, a higher safety relevance than the safety integrity level ASIL B for the
ECUs should not be reached the safety target ASIL B should not be exceeded.
However, as soon as the driver is removed from the driving process, the safety
targets for the auto- mation functions increase up to a safety integrity level ASIL
D. In contrast to ISO 26262, the SOTIF PAS does not yet contain a metric that
assigns a safety relevance to a function.
3.1 The risk of unknown and uncertain system states11

3.1 The risk of unknown and uncertain system

states

In contrast to known uncertain events, the control of currently unknown and

uncertain system states represents a greater challenge. Due to the trends of
digitalization and automation, the automobile is currently undergoing a disruptive
change. In particular, the increasing complexity and variety of today's vehicle
control systems makes it massively more difficult to detect and control all
existing hazards with the current methods of functional safety. Driving scenarios
not foreseen in the system design or unexpected interdependencies of the vehicle
systems with each other or their interaction with the driver in terms of human-
machine interaction increase the degree of unknown risks.

Example 2
In the future, new sensor technologies will be used in vehicles. The target
function can be negatively influenced at various levels of sensor data
processing. For example, it is possible for physical effects to falsify the raw
data from sensors. The ISO SOTIF document gives the example of a limited
detection performance of an imaging sensor due to deposits on the road
surface. Even the next higher level of sensor data processing - the extraction of
object data - can lead to unsafe system states, for example, through the use of
faulty object hypotheses, which do not necessarily have to be known in
advance. For example, an object hypothesis valid for pedestrians cannot be
applied to skateboarders (speed too high). As a result, an object is not
recognized as such, so that the safety-oriented reaction of the vehicle
automation system does not take place in this case.

Due to the large number of possible traffic situations, it is only possible to test all
possible situations in advance with extremely high effort. Therefore, one goal of
SOTIF is to reveal possible unexpected system behavior at an early stage through
targeted measures.
12 3 Why do we need SOTIF?

3.2 The risk of known and uncertain

system states

One of the main tasks of SOTIF is to ensure that the probability of a hazardous
event is sufficiently low, in which the system cannot safely handle a particular
use case and the people involved are not able to mitigate the hazardous event. If
such an unsafe use case is known, it can be targeted for hazard control. This
involves a structured treatment of recognized hazards through targeted system
improvements, measures to restrict the target function, a targeted return of
responsibility for the driving task to the driver, and measures to control reasonably
foreseeable misuse by the user.
The SOTIF procedure model4

This chapter presents the basic structure of the SOTIF process building. The
individual steps of the SOTIF process model are then explained. A presentation of
how SOTIF relates to other design disciplines (essentially functional safety
according to ISO 26262) concludes this chapter.

4.1 Basic structure of the SOTIF

process building

Even though SOTIF is related to function development according to ISO 26262,

it should be regarded as an independent design task. In this context, suitable
"contact points" must be found with the neighboring disciplines in the
development of safety-relevant electronic control systems for motor vehicles.
So far, ISO/SAE J 21448 (which describes SOTIF) does not provide for an
independent engineering process as it has been proven in practice for ISO 26262
or as provided for in the SAE J 3061 standard. Currently, SOTIF basically
provides for a concept phase, however, after the SOTIF analysis has been
performed, the requirements are given directly to the concept phase of ISO, see
Fig. 4.1.
A comparison of the process buildings of ISO 26262 and ISO/SAE J 21448
reveals at first glance three elementary weaknesses of the current ISO/SAE J
21448:

1. Early validation in simulated realities: Contrary to what is suggested in

ISO/SAE J 21448, validation activities based in simulated realities should be
performed early on (i.e., in the concept phase of a system development).

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 201913

L. Schnieder and R. S. Hosse, Guide Safety of the Intended Functionality,
essentials, https://doi.org/10.1007/978-3-658-25023-2_4
14 4 The SOTIF procedure model

Func onal and Residual Risk

System Evalua on
Specifica on Func onal
SOTIF Safety
Func onal Defini on
Valida on: Vehicle
Assessmen t
System Descrip on Evaluate Valida on
Unknown Use Test
SOTIF Risk HARA Cases
Iden fica on
and Evalua on
Func onal
SOTIF
Hazardous UseSafety
Verifica on: Veri-
CaseConcept
Iden fica on Evaluatefica on
known UseTest
Func onal Technical Cases
Improvement Safety
to reduce the SOTIF Concept
risk Func onal
Concept Risk
Mi ga on
SOTIF V&V Verifica on &
Strategy Valida on
SOTIF Process
HW & SW
Dev. ISO 26262 Process

Fig. 4.1 Process building of ISO/SAE J 21448

realities of executable models. This is intended to prevent the entire

development cycle having to be run through again in accordance with ISO
26262 if validation is carried out at system level late in the product
development process.
2. The increasing complexity of vehicle automation is pushing existing
approaches to empirical validation to their limits. In particular, the occurrence
of events classified as unknown/unsafe cannot be ruled out even after the
systems have been placed on the market. Product monitoring by manufacturers
and, if necessary, market monitoring by state regulatory authorities, including
independent accident investigations in the case of highly automated vehicles
(Federal Ministry of Transport and Digital Infrastructure 2017), are becoming
increasingly important in this context. In the event that unsafe conditions are
identified, manufacturers must take immediate action in the sense of structured
processing of the identified "product safety defects". In the light of supreme
court rulings by the Federal Court of Justice, this is also referred to as the duty
to manage hazards.
3. To date, the management of SOTIF has not been provided for in ISO/SAE J
21448. However, for SOTIF - analogous to the procedure for the correct
implementation of the security function, or also with regard to the
implementation of an "attack-proof" security function - it makes sense to
establish targeted methods in the organization that help to ensure that the
requirements of the "SOTIF engineering" required by ISO/SAE J 21448 are
implemented correctly. Such management ensures that all activities required to
demonstrate SOTIF are performed and documented in a form that can
withstand independent scrutiny.
4.2 Process steps according to ISO/SAE J 21448 at a glance15

4.2 Process steps according to ISO/SAE J

21448 at a glance

The SOTIF procedure is carried out in several phases that build on each other.
These are explained below.
SOTIF concept phase as the beginning of SOTIF activities:

• Creating the function and system specification: The creation of the function
and system specification is the starting point for the development of
automation functions. As a document accompanying development, it is always
adapted to new findings. The main contents are the description of the goals of
the intended function and the dependencies of the function on other vehicle
functions and systems, relevant environmental conditions and interactions in
terms of the design of the human-machine interface.
• Identification of SOTIF risks: This is followed by a systematic identi
fication of the hazards caused by the malfunction of the function under
consideration. Analogous to the procedure of ISO 26262, an evaluation of the
recognized hazards can also be made here according to frequency (Exposure,
E), severity (Severity, S) and controllability (Controllability, C). The
difference here, however, is that for the classification of hazardous events, a
delayed or absent reaction of the driver to control the critical driving maneuver
is also taken into account.
• Identification and evaluation of hazardous use cases The aim of the ana-
lyse is a targeted identification of system weaknesses. System weaknesses are
triggering events that can result in unintended system behavior. Triggering
events result, for example, from sensors, algorithms or actuators that are not
appropriate for the application. However, SOTIF also considers humans as a
possible triggering event in the sense of non-intended use of the developed
system (foreseeable misuse).

SOTIF implementation phase following the concept phase presented earlier:

• SOTIF risk reduction measures: SOTIF risk reduction measures include

system improvements (sensors, algorithms, and actuators), functional
limitations on the automation function, returning responsibility for the driving
task to the driver, and measures aimed at reducing the effects of reasonably
foreseeable misuse.
16 4 The SOTIF procedure model

SOTIF verification phase following the implementation phase:

• Verification of SOTIF: The system and its components (sensors, algo- rithms,
and actuators) must be verified to show that they behave as expected in known
uncertain scenarios and are adequately covered by the tests performed.

SOTIF validation phase for final proof of the safety of the target function:

• Validation of the SOTIF: The system and its components are validated to show
that they do not cause any unreasonable risk in real test cases. For this
purpose, a suitable cumulative test length is calculated on the basis of
empirically determined accident figures of current vehicle systems. An
appropriate (i.e. realistic and representative) distribution of the cumulative test
length among different test scenarios (e.g. driving on the highway, driving in
the dark, driving in the rain) is determined on the basis of the current
distribution of annual mileage among specific driving scenarios.

4.3 Relations to neighboring disciplines

As can be seen in Fig. 4.1, SOTIF has reference points in particular to the concept
phase and the safety validation of ISO 26262. The results ofthe SOTIF concept
phase are incorporated into the definition of the object under consideration (so-
called item according to ISO 26262). The specification of the safety function
outlined in the preliminary result of the SOTIF process is then implemented
"functionally safe" by following ISO 26262.
An approach to structuring the adjacent neighboring disciplines of functional
security and cybersecurity is shown in Fig. 4.2. While each discipline performs an
analysis of the undesired behavior at the vehicle level, this is used to define
requirements at the vehicle level for the item under consideration. For example, the
ISO provides for the safety goals of the item. Functional requirements are then
also defined at vehicle level. These functional requirements are specified at the
component level in the form of technical requirements. The technical requirements
are then used to separate the requirements for the hardware and software of the
relevant object of consideration.
4.3 Relations to neighboring disciplines17

Fig. 4.2 Relationships to the neighboring disciplines of functional security and cyber security

The "X" shown in Fig. 4.2 as a placeholder in the requirements hierarchy can
be replaced by the terms "Safety", "Security" and "SOTIF". Therefore, a system
will have a "Functional Safety Concept" as well as a "Functional Security
Concept" and a "Functional SOTIF Concept".
It is the responsibility of the manufacturer to design the development
processes in such a way that the requirements from the three disciplines can be
managed, or that a system is able to map a dedicated concept for safety, security
and SOTIF.
Case study on the design of SOTIF5

The design of SOTIF is illustrated below with an example. For the sake of
simplicity, reference is made to a published report of an independent accident
investigation of an accident involving a vehicle with automated driving functions
in the sense of a retrospective view; compare this with the example of the Tesla
Model S accident from 2016 briefly presented in chapter 1.
The goal of SOTIF is, of course, a prospective system analysis and subsequent
design of driver assistance and vehicle automation. However, the results of the
accident investigation and the concrete design recommendations listed therein are
well suited to provide an understanding of the concrete implementation of SOTIF.

5.1 SOTIF Concept Phase

In the concept phase, the hazards and risks are methodically derived from a
description of the vehicle automation function. This is the starting point for the
subsequent system implementation.

In the example
Example 3 of the Tesla Model S accident, it involved a driver-
supporting (L2) automation system. (Gasser et al. 2012) The driver still has the
responsibility for safety:

• On the one hand, the driver takes in information about the vehicle
environment directly through his own sensory perception. On the other
hand, they also receive information indirectly via the display functions of the
vehicle automation system.

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 201919

L. Schnieder and R. S. Hosse, Guide Safety of the Intended Functionality,
essentials, https://doi.org/10.1007/978-3-658-25023-2_5
20 5 Case study on the design of SOTIF

• Based on this information, the driver performs control actions that

indirectly affect the lateral and longitudinal guidance of the vehicle. These
are translated by the vehicle's automation components into concrete (i.e.
direct) control of actuators such as steering and brakes.

This generic action diagram, shown in the following figure, already illustrates
which hazards can contribute to a failure of the target function (sensors,
algorithms, actuators, foreseeable driver error).

Driver
indirect Indirect perception
operating action via displays in the
of the vehicle
driver Direct perception of the
Vehicle with assistance function traffic environment

Sensitization of the
Immediate
traffic environment
execution of
driving
maneuvers

Vehicle in traffic environment

Generic action diagram of the human-machine interaction of an L2 automation At

the vehicle level, there are basically two hazards:

• Autopilot performs an unsafe driving maneuver

• The driver does not correct the autopilot misbehavior

5.1.1 Function and system description

The function and system description is the starting point for the design of an
automation function. It is constantly adapted to new findings during development.
In addition to the desired behavior of the vehicle automation in control operation,
it describes in particular the existing limits of the functionality. Special
importance is given to the consideration of
5.1 SOTIF concept phase 21

Malfunctions, i.e. the system behavior in the event of detected limitations (so-
called degradation) and corresponding warnings or takeover requests to the
driver.
The functional description according to SOTIF can be made in the usual way
Example 4
as already provided for in the item definition according to ISO 26262. The use
case of the system plays a particularly important role here, since it must be
known exactly under which conditions the system is to be used.

Driver Control Inputs Autopilot HMI

enables mode
overrules/deactivates disables objects
set speed target speed
signs
Autopilot
Autopilot Process Model
Autopilot HMI
Control Actions: - Enable/Disable Autopilot
• Provide Trajectory- Target Speed
Missing • Status Mode
Feedback • ObjectsFeedbacks :
Driver Operative • SignsData Fusion and Assessment
Process Awareness • Target Speed- Assessed Environment Model

Control Inputs: DriverMissing Feedback

Driver Control Inputs • Driver Operative Process
• Overrule/Deactivate Awareness

provides trajectory assessed environment model

Accident Causation
Trajectory Follow- Data Fusion and Assessment
Up Controller Process Model

Control Actions: Feedbacks:

• Assessed- Vehicle Dynamics
Environment Model - Visual Environment
• Radar Data

camera radar
vehicle dynamics
Data Data

INS Camera Radar

22 5 Case study on the design of SOTIF

Functional description of the Tesla Autopilot

The figure shows a graphical description of the target function of the
autopilot in the form of a control structure with the components involved and
the inputs and outputs, as well as the processes in the autopilot. The autopilot
has access to the sensors INS (inertial sensor), camera and radar.

5.1.2 Methods of Functional Hazard Analysis and Risk

Assessment

The SOTIF DPAS (ISO/SAE J 21448) lists a number of possible hazard analysis
methods that are capable of identifying hazards in terms of target functional
safety. In order to reduce the risk of the unknown in the development of safety-
relevant electronic control systems for motor vehicles, a method is required that
captures the driver-vehicle-driving environment system as a socio-technical
system (Hosse et al. 2012).
In principle, various methods can be used to identify and analyze unknown
unsafe events at the system level. One method is the HAZOP (Hazard and
Operability Study), which tries to identify basic possible failure mechanisms by
using key words (e.g. too early, too late, too little, too much). In the following
explanations, the STAMP/STPA method is used to reveal cybernetic principles
(control loops). Often it is the violation of basic cybernetic structural principles
that leads to the occurrence of accidents.
The STAMP/STPA method (Systems-theoretic accident model and pro-
cesses, STAMP/Systems-theoretic process analysis, STPA) is a model-based
hazard analysis method developed by the US safety researcher Nancy Leveson,
which analyzes a safety-relevant system in a structur- ed manner by means of a
semi- formal model (the so-called Safety Control Structures) (Leveson 2011).
STAMP is a prospective approach to system analysis that aims at the conscious
safety-oriented design of SOTIF.
The goals of STAMP are:

• Definition of control limits for safe behavior of the safety-relevant system

• Sociotechnical understanding of safety in complex systems.
5.1 SOTIF concept phase 23

• Develop strategies for managing hazardous system conditions.

• Support of optimization and adaptation processes in case of environmental
influences
• Admission of error tolerances
• Ensure disclosure and reversibility of errors.

STAMP is a model concept of risk genesis, STPA its application as a hazard

analysis method to a real system. This methodology can be applied during a
system development. STAMP uses the so-called safety control structures of a
system to ana- lyze control loops, identify the safety-critical operating processes of
a system, and uncover deficient control structures. STPA is a top-down ana- lysis
that is successively refined, leading to a deeper understanding of the system. In
general, it can be shown that STPA detects significantly more hazards in a system
than, for example, the inductive analysis method FMEA (Failure Modes and
Effects Analysis) or the deductive analysis method FTA (Fault Tree Analysis).
Another method provided by STAMP is CAST (Cau- sal analysis based on
STAMP). This is a retrospective approach. The idea here is that accident analyses
also result in a deeper understanding of incorrectly implemented protective
functions. This approach also has regular relevance in the SOTIF approach. If, for
example, an "unreasonable risk" occurs in the course of validation due to an
unpredictable system behavior, CAST contributes to the explanation of this test
deviation and leads to the identification of suitable SOTIF measures.

The system-level
Example 5 hazards have already been defined, see
Section 5.1 The Safety Control Structure must then be defined. For the Model S
system, this looks as follows:
 24

Driver

enables,
performs steering
disables, overtake request
angleengagetargetspeed
set speed
Driver
Steering Accelerator Control
Other tasks Brake pedal Autopilot HMI
Wheel pedal Inputs
enables, mode,
disables, objects,
overrules/deactivates target speed,
set speed
signs

Autopilot

provides delta/ provides delta/ provides delta/

target action provides trajecto y assessed environment model
target action target action

Trajectory Follow-Up
Data Fusion and Assessment
Controller
provides delta/
target action
5
Vehicle
Ca
Steering
system
Brake System Drivetrain Dynamics INS Camera Radar se
Controllers st
controls controls controls ud
y
Vehicle Dynamics on
th
e
de
sig
Vehicle in its Environment
n
of
SO
TIF
5.1 SOTIF concept phase 25

Safety Control Structure of the Autopilot

The rectangles represent the controllers (e.g. driver, autopilot), actuators (e.g.
brake pedal), sensors (e.g. camera, radar) and safety-relevant processes (e.g.
vehicle in its environment). The arrows indicate the flow of information/energy
between the respective system elements.
The figure shows that the driver is modeled and analyzed as an integral part
of the system in the hazard and risk analysis within the framework of the
STPA. Therefore, the foreseeable misuse of the assistance is already taken into
account in the concept phase.
After the Safety Control Structure of the driver has been created, the
Unsafe Control Actions (UCA) can be determined. For the example shown
above, the following selected UCAs result:

Control action Required but not Unsafe action Incorrect Stopped too soon/
provided provided timing applied too long
Overrule/ Driver inputs do Driver inputs
Deactivate not overrule Auto- deactivate
pilot Autopilot too
late
Enable Autopilot is ena-
bled unintended
Send mode Autopilot does Autopilot
status not send mode sends mode
status status when not
enabled
Provide asses- Environment Environment Environment (Same) model
sed environ- model not pro- model provided model provi- provided too long
ment model vided when not ded too late
(not updated) required

In order to identify the UCAs, the Control Actions are reasoned through by
means of a guide word method of the error cases of the Control Action (here:
required but not provided, unsafe action provided, etc.). Subsequently, the
combinatorics of the Control Actions are evaluated in terms of whether one of
the described failure cases leads to a potentially dangerous state. This results
in the UCAs. The inversion of the UCAs then results in the SOTIF
requirements for compliance with the safety of the target function.
In this example, the safety control structure of the driver must also be
analyzed in addition to the safety control structure of the driver, since the
driver also acts as a controller in the system due to the L2 automation and
assumes safety relevance:
 26

Tesla Motors
update
status logs
enable functions
driving data sets goals
sent changelogs defines customer
authoring defines customer
coverage expectations
Tesla Model S defines image

driving information Digital Instruction

changelog Marketing
drive (steer, accelerate, brake) Manual on Delivery
Autopilot on/off
Instrument cluster Change log teachesinstructs surveys sources reviews

Autopilot mode functions

vehicles & road signs instructions forms
action instructions limitations attitude
Driver 5
disturbances by other
Operator Process Model Social media Ca
humans/activities, etc.
contributes se
Other Vehicles st
Performs Road Signs ud
Environmental Conditions y
Other Tasks Driving Environment on
Feedback
th
Relevant Focus Control Action
e
de
sig
n
of
SO
TIF
5.1 SOTIF concept phase 27

Safety Control Structure of the driver

In addition to the vehicle, the influence from the driver's wider
environment is now also shown: Drivers often learn a certain traffic behavior
due to social effects. This is described by the effect of "social learning" and
can be integrated as an element in the control structure. The STPA provides as
a result that the driver can perform the following UCAs (selected):

Control action Required but not Unsafe action Incorrect timing Stopped too
provided provided soon/applied
too long
Steer Driver does not Driver steers
steer Model S Model S too late
when required
Enable Driver enables
autopilot when
not allowed

During the analysis of the Tesla Model S accident carried out here, some
UCAs could be identified which were not complied with. These are listed in
the following table:

No. Unsafe Control Actions Safety constraint

UCA 1 Autopilot does not send correct Autopilot must send objects to Auto-
objects to Autopilot HMI when pilot HMI when required
required
UCA 2 Autopilot does not send correct road Autopilot must send road signs to
signs to Autopilot HMI when required Autopilot HMI when required
UCA 3 Data Fusion and Assessment does not Data Fusion and Assessment must
provide correct assessed environment provide assessed environment
model to Autopilot when required model to Autopilot when required
UCA 4 Driver does not brake Model S Driver must brake Model S
when required when required
UCA 5 Driver performs other tasks when Driver must not perform other
not allowed tasks when not allowed

The accident report showed that the primary cause of the accident was the
driver's lack of reaction, but it also showed that the autopilot was not able to
execute the correct hypothesis during object detection or to keep the driver
sufficiently engaged in the driving process (e.g. by detecting steering wheel
movement).
28 5 Case study on the design of SOTIF

After identifying potential missing system functions that may lead to unsafe
system behavior, the SOTIF implementation can be performed.

5.2 SOTIF Implementation Phase

In the following, four different measures are presented that can be used to control
detected errors. Together, these measures ensure that the SOTIF risk can be
reduced to an acceptable level. As a rule, several measures must be combined to
achieve the desired safety-oriented effect.

5.2.1 Measures of the system improvements

Complex vehicle automation systems are characterized by the processing chain of

acquisition, processing and intervention in the driving task, as shown
schematically below in the structure of a control loop (cf. the figure in Example 3,
Section 5.1). Each of these elements offers the possibility of a specific
improvement of the target function:

One of several
Example 6 possible starting points for system improvement in the
The control loop is the sensor system (measuring element). The example of
the investigation report (NTSB 2017) mentions the networking of vehicles in
the sense of cooperative assistance as a starting point for system improvement.
V2V (vehicle-to-vehicle) systems transmit warnings and safety-related
information between vehicles. If all vehicles are equipped with these systems,
this results in an improved perception of the vehicles' surroundings. A new
data source with reliable and accurate data is opened up, so that collision risks
that are beyond the range of the vehicles' own sensors can be detected. If this
data is fused with existing vehicle data, this can lead to a significant
improvement in active safety functions.
5.2 SOTIF Implementation Phase 29

Control loop concept

5.2.2 Measures of limitation of the target function

Hazards resulting from incorrect execution of the target function can be avoided
or their impact reduced by functionally restricting the target function. In
assistance systems, for example, a driving task is continuously automated. The
driver performs either the longitudinal or lateral guidance of the vehicle himself,
while the other driving task is automated within limits. It is important to
understand that even the automated driving task is only performed by the driver
assistance system to a limited extent ("within limits"). The system limits can be
clarified using examples in the accident report (NTSB 2017). Different
limitations are distinguished here:

• Immediate (technically enforced) restrictions. Examples are:

– Dependence of the specific warning of the TACC (traffic aware adap- tive
cruise control) depending on the set maximum value of the acceleration.
– Limitation of the maximum speed depending on the detected permissible
speed for the current road category
– Assessment of the driver's attentional focus on the driving task with
appropriate safety-oriented response in the event of a detected driver
distraction.
– The automatic lateral and longitudinal guidance is only active when the
driver's seat belt is closed.
30 5 Case study on the design of SOTIF

• Indirect restrictions due to instruction of the driver. Examples are:

– Warning that the intended scope of the TACC function is limited to straight,
highway-like roads without cross or oncoming traffic.
– Warning that the intended scope of lane departure warning is limited to
motorway-like roads where vehicles can only enter the road on marked
acceleration lanes or leave the road only via clearly marked deceleration
lanes.
– Warning that the use of the assistance function does not replace attentive
observation of the traffic situation and the system status of the auto- matic
function and that hands must therefore always be kept on the steering
wheel.

5.2.3 Measures of returning the responsibility for the

driving task to the driver

Driver assistance systems up to high automation divide the perception of the

driving task between humans and machines. The goal of vehicle automation
design is to relieve humans of unpleasant or over-demanding tasks. Highly
automated vehicles must recognize their own system limits and prompt the driver
to take over the driving task "with sufficient time reserve" if necessary. To ensure
a safe and comfortable handover, the vehicle must guarantee that it will take over
longitudinal and lateral guidance for a certain period of time before the driver can
resume the driving task. The following parameters influence the value of an
optimal takeover time, which has yet to be determined (Cacilo et al. 2015).

• Speed of the highly automated vehicle

• Performance/visibility of the sensors
• Redundancy strategies in case of system failure
• System boundaries and speed of their occurrence
• Driver latency (with/without distraction by non-driving activities).
• Behavioral psychological and legal assessment of the "reasonableness" of
assuming responsibility in emergency situations.
• Possible emergency maneuvers in the event of a failure to take over
5.2 SOTIF Implementation Phase 31

Example 7
In the case of the vehicle involved in the accident, it was envisaged that in the event that
the valid-
If the maximum permitted speed on the section of road cannot be detected, a
maximum ACC speed of 45 mph is set as the fallback level. In this case, the
responsibility for accelerating above this threshold is returned to the driver. If
the driver takes his foot off the gas pedal, the system brakes the vehicle to the
threshold value of 45 mph.

5.2.4 Measures to control reasonably foreseeable

misuse

The intended use of a product results from its function. In contrast, the use of a
product in a manner not intended by the vehicle manufacturer, but which may
result from foreseeable human behavior, is referred to as foreseeable misuse. The
reasons for foreseeable misuse can be differentiated on the basis of the three basic
processes of human information processing:

• Perception: For example, the driver does not understand and cannot operate
the system due to complicated user guidance. Also, the driver may not be able
to understand the information relevant to him or her because of a
"Information overload" does not recognize.
• Evaluation: As a consequence of previously mentioned erroneous perceptions,
the driver may make a wrong decision.
• Action: The driver's action may fail because he or she may make a mistake due
to poor concentration. A driver may also deliberately ignore traffic or behavior
rules. In addition, the system may be so difficult to operate that it is impossible
for him to perform the action correctly.

In the case
Example 8 of the vehicle involved in the accident, there was already at the level of
perception
an error on the part of the driver. In this case, the driver did not understand the
limitations of the automation system. He did not know about the systematics of
the protective function. This led to an erroneous evaluation ("overestimation of
the automation"). The driver relied on the automation or overestimated its
effectiveness.
32 5 Case study on the design of SOTIF

This in turn led to an erroneous action in that he did not pay attention to the
traffic environment. This human error - facilitated by the inadequate
recognition of the driver's attention being diverted from the driving task - led
to the accident.

The design of the human-machine interface (MMS) is of great importance in

preventing foreseeable misuse. The MMS can also be used to check the intended
use of advanced driver assistance systems (ADAS) and prevent misuse. In this
context, information - for example regarding the driver's condition - must be
recorded. At the same time, a conscious design of the information output is
required. A targeted warning of the driver and precise control of his attention is
an important factor in increasing the safety of automated vehicles.
Insofar as an automation system achieves a degree of automation up to level 2,
the driver still acts as a safety barrier - in the event of an unexpected functional
failure of the technical system, it is the driver's task to control the functional failure
and, in this case, to take over control of the vehicle again. In the sense of ISO
26262, this type of safety function would also have to be interpreted according to
the laws of ASIL classification. Thus, insofar as a functional failure leads to a
fatal accident, the safety function must be implemented in accordance with the
safety integrity level ASIL D. This in turn has implications for the monitoring of
this safety function - in this case the driver. However, in order to prevent the
misuse of partially automated systems (in which the driver does not assume the
necessary safety function), in some current series-production vehicles, for example,
sensors determine whether the driver is holding his hands on the steering wheel,
whereupon it is concluded that the system is being used as intended (so-called
hands-off detection). If the system registers the driver's hands on the steering
wheel, it assumes that the driver is capable of monitoring the driving situation
appropriately. Otherwise, visual, acoustic or haptic warnings are provided in a
targeted manner.

5.3 Verification and validation of SOTIF

requirements

The proof that the system to be developed fulfills its intended target function is
based - as in functional safety - on the fundamental concepts of verification and
validation. In the context of SOTIF, this is understood to mean the following:
5.3 Verification and validation of SOTIF requirements 33

• Verification: Proof that the specified target function has been implemented
correctly. For example, requirements-based tests are used to prove that the
system has been implemented in accordance with the specification. However,
this requires a complete and correct system specification. Verification aims to
show that the developed system can handle known uncertain events.

In the concretely
Example 9 discussed example, a verification of the requirements would have
z. For example, a test case could have been used to test the reaction time of the
driver with the current system design in different driving maneuvers. Although
the specific case that led to the accident would certainly not have been
uncovered, the time span between detection of the driver's distraction and
feedback from the system to take over the steering could have been shorter.

• Validation: Examination of the system under consideration to ensure that it is

suitable for the intended use. In this process, the developed vehicle automation
component is deliberately exposed to a large number of driving scenarios with
many varied parameters (static traffic objects such as road signs, dynamic
traffic objects such as other vehicles, and different environmental conditions
such as rain or snow) to see whether it always leads to the intended system
behavior. In contrastto verification, validation is intended to show that no critical
events occur during the operation of the developed system in a defined scope
of test drives. From this it is concluded that the occurrence of unknown unsafe
events is sufficiently rare and on this basis a production release can be issued.

A concrete
Example 10test case for validating the system could be created, for example, by Varia-.
The validation of the system could have been carried out outside the
predefined traffic infrastructure environment. In the concrete example, the
system could have been validated outside the predefined traffic infrastructure
environment. For example, it is not yet intended that automation systems
cannot be activated for certain infrastructures, nor on inappropriate
infrastructures (a highway pilot should also only be activatable on a highway,
but not on a country road - although the speed profile is comparable). The
validation according to SOTIF thus provides for the deliberate extension of the
previously defined operational environment of the system and the use of the
system in a context that has not yet been taken into account.
34 5 Case study on the design of SOTIF

5.3.1 Proof of Concept - preliminary verification

and validation of SOTIF requirements.

System developments in the automotive industry are costly and time-consuming.

In order to be certain that the intended automation concept is fundamentally
suitable for the intended application, it must be examined at an early stage. This
prevents the entire development cycle from being run through, at the end of
which a negative statement from the verification and validation tests ultimately
prevents the release of the function under consideration.
Since neither complete developed products (as a combination of hardware and
software) are available at this point, nor has their integration into the complete
vehicle taken place, the only verification method in the early phase of system
development is limited to testing executable models in simulation environments.
High-performance simulation systems realistically represent as many influences
as possible (physics, traffic, function, vehicle and driver models, sensor data and,
if necessary, communication). This approach is referred to as "model in the loop"
(MIL).
In principle, such a simulation-based approach offers several advantages
(Beglerovic et al. 2018).

• Variation: Since the different parameters of driving scenarios can be easily varied,
a higher test coverage will in principle be easier to implement.
• Reproducibility: Since vehicle automation via its sensor technology factors
such as road users, weather conditions and dynamic obstacles into their
maneuvers, there is no sufficient reproducibility of all possible test scenarios
in real driving tests. Since simulations take place under controlled conditions,
repeated test execution will lead to the same test results.
• Acceleration of test execution: The increasing complexity from the
Vehicle automation has resulted in a sharp increase in the effort required to
test assistance systems. The number of variations of different influences is so
high that not all possible scenarios can be reproduced in a real test
environment. A simulation-based approach allows the driving maneuver under
consideration to be performed faster than in real time. Tests can also be carried
out in parallel in several instances of the simulation models.
5.3 Verification and validation of SOTIF requirements 35

can be carried out. This represents an opportunity to significantly accelerate

test activities, or makes a test possible in the first place.
• Costs: For simulation studies, costly integration in real-world systems can be avoided.
vehicles can be dispensed with. There are also no further costs, for example
for test drivers.

5.3.2 Property validation - final verification and

validation of SOTIF requirements

Before a system is released, it must be proven that it reliably fulfills the intended
target function. During development, simulation-based test methods are applied
to the various integration stages of the product before tests can be carried out
under real conditions.

Simulation-based test stages The development process takes place in various

stages. The development results are successively integrated "bottom-up" and
accordingly tested simulatively at each level. This is done in parallel with the
progress in the development of simulation-based tests at different system scales.

• Software-in-the-loop (SIL): Software code can be generated automatically

from the executable models. This can be tested at an early stage using critical
driving scenarios.
• Hardware-in-the-loop (HIL): In this case, the code is written on the intended
hardware for execution. Individual ECUs can be embedded in a simulation
context or several ECUs can be tested in a network in the sense of integrated
HIL. The setup and maintenance of HIL environments are very costly.
However, the benefits of testing under controllable environmental conditions
usually outweigh these disadvantages.
• Vehicle-in-the-loop (VIL): Here, the function is integrated into a vehicle.
and the entire vehicle is integrated into the simulation environment. VIL tests
are advantageous because the driving maneuvers to be carried out in the test
can be
36 5 Case study on the design of SOTIF

the traffic environment can be simulated reproducibly and no real vehicles are
required. Furthermore, in this early test phase, any risk to test drivers and the
system environment can be ruled out (Wagener and Katz 2018).

Current research considers a combination of virtual testing (allowing many

permutations of test parameters and randomized test scenarios) and real testing of
individual use cases. The Virtual Assessment of Automation in Field Operation
(VAAFO) approach. VAAFO integrates the advantages of real and virtual tests
by recording real driving situations of (series) vehicles in real operation and
equipped with sensors for highly automated driving. These recordings (e.g.,
sensor data and driver behavior) are then transferred as input variables to the
simulations so that the automation functions can be tested in real situations
without risk.

Tests under real conditions Once the systems have been sufficiently tested in
the laboratory, they are then tested under real conditions.

• Tests on test tracks: Automobile manufacturers operate drivable courses that

serve as testing grounds for the functions under investigation. The aim here is
to obtain measurement data and detect errors in the system. The product can
also be taken to its limits, which cannot be reached in real-world operation on
public roads.
• Testing and trial runs: These are runs
on public roads to gather experience under real-world conditions. The aim is
to test the vehicle's systems under real-world conditions in order to identify
and eliminate any deficiencies and reveal system performance limits.

5.3.3 Product observation - confirmation of verification

and validation through field experience

The life of a product does not end when it is placed on the market. Unfortunately,
problems resulting from incorrectly or incompletely implemented functions often
only become apparent in the field, as the real example used for this essential
clearly shows. Although SOTIF is supposed to prevent exactly this, due to the
complexity and the large solution space, it will never be possible to avoid this
completely. Therefore
5.3 Verification and validation of SOTIF requirements 37

Since the ruling of the German Federal Court of Justice in the "Honda case" at the
latest, automobile manufacturers have been subject to the obligation of product
monitoring. Although this aspect is not considered in the current ISO document
on SOTIF, it is generally discussed for the introduction of increasingly highly
automated vehicles in road traffic (Federal Ministry of Transport and Digital
Infrastructure 2017). Methodological approaches are therefore also required for
the structured collection and evaluation of field experience, which will be
outlined below:

• Accident databases: Accident databases such as GIDAS (German in depth

accident study) collect data and reconstructed accident sequences. This
database is the basis for future ideas and concepts in research and development
in the automotive and supplier industry (Schnieder and Schnieder 2013).
• Driving Behavior Studies (Naturalistic Driving Studies): Driving Behavior Studies.
In addition to the accident data records, these are used to map real traffic
events. Scenarios in real mixed traffic are recorded so that driver behavior
patterns can be detected in addition to normal, critical and highly critical
situations. This information is of great importance for the system design of
(partially) automated driving functions and driver assistance systems (Preuk et
al. 2016).
Conclusion and outlook6

The concept of SOTIF together with cybersecurity and functional safety

represents a holistic approach to the safety of automotive control systems. With the
increasing complexity of automation functionsin vehicles, the correct implementation
of the target function becomes more important. SOTIF is a first approach to
increase the robustness of assistance systems. In the following, the strengths and
weaknesses of the SOTIF approach are discussed and the opportunities and risks
are highlighted.
One of the strengths of the SOTIF approach is that it rounds off the normative
understanding of safety and that safety in use now has equal status with functional
safety and cybersecurity in the engineering of automotive applications. All in all, this
makes it possible to achieve higher quality in the development of driver assistance
and vehicle automation.
Weaknesses of the SOTIF approach lie in its incomplete operationalization
compared to functional safety according to ISO 26262, which makes targeted
management ("What SOTIF risk is accepted?") difficult. Furthermore, it remains
unclear how exactly the independent verification (assessment) of SOTIF can be
designed.
The opportunities offered by the SOTIF approach lie in the fact that a higher
quality of vehicle automation can promote its acceptance in the long term. Since
the standardization landscape is currently being formed for all three aspects of
safety in use, functional safety and reliability in use, there is an opportunity to
work towards harmonizing these standards.
The risks of the SOTIF approach lie in the possible lack of industry-wide
coordination of a field data and scenario basis. Here, each manufacturer learns for
itself from the field observations. Synergies with regard to the broadest possible
scenario coverage may remain unused.

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 201939

L. Schnieder and R. S. Hosse, Guide Safety of the Intended Functionality,
essentials, https://doi.org/10.1007/978-3-658-25023-2_6
 406Conclusion and outlook

In summary, this presentation of opportunities, risks, strengths and weaknesses

of SOTIF leads to an appeal by the authors that in the future - as envisaged by the
Ethics Commission on Connected and Automated Driving appointed by the
German Federal Ministry of Transport and Digital Infrastructure - an independent
accident investigation be carried out with the resulting establishment of a
manufacturer-independent test database. Structured accidents with an independent
investigation of their underlying causes form the basis for obtaining valid test
case catalogs that can be applied equally by all manufacturers in the safety life
cycle of driver assistance and vehicle automation. If all three design disciplines
are then combined in a coordinated process model, there is realistic hope that
higher vehicle automation will bring us a great deal closer to the overriding goal
of "Vision Zero" (no fatalities and injuries in road traffic).
What you can take away from this
essential

• Understanding the importance of fully specifying safety functions for the safe
design of increasingly highly automated road traffic.
• Knowledge of which methods of system analysis can contribute to the completion of a
system.
The safety functions can be maintained at a constant level.
• Knowledge of the contribution of system improvements in the sense of
optimized system-technical chains (sensors, algorithms, actuators), as well as
the functional restriction of the considered function on the robustness of the
target function.
• Knowledge of the role played by the human factor in the design of a robust
The aim is to ensure that the human-machine interaction is appropriately
designed and that reasonably foreseeable misuse is systematically taken into
account.
• Knowledge of how a structured demonstration of robustness by measures
verification and validation along the life cycle of safety-relevant electronic
control systems for motor vehicles.

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 201941

L. Schnieder and R. S. Hosse, Guide Safety of the Intended Functionality,
essentials, https://doi.org/10.1007/978-3-658-25023-2
Literature

Beglerovic, Halil, Steffen Metzner, and Martin Horn. 2017. challenges for the validation
and testing of automated driving functions. In Advanced microsystems for automotive
applications 2017, ed. Zachäus et al. Wiesbaden: Springer.
Federal Ministry of Transport and Digital Infrastructure. 2017. final report of the ethics
committee on automated and connected driving. 2017.
Cacilo, Andrej, Sarah Schmidt, Philipp Wittlinger, Florian Herrmann, Wilhelm Bauer, Oliver
Sawade, Hannes Doderer, Matthias Hartwig, and Volker Scholz. 2015. highly automated
driving on highways - industrial policy conclusions. Study commissioned by the Federal
Ministry for Economic Affairs and Energy (BMWi).
Gasser, T., Arzt, C., Ayoubi, M., Bartels, A., Bürkle, L., Eier, J., Flemisch, F., Häcker, D.,
Hesse, T., Huber, W., Lotz, C., Maurer, M., Ruth-Schumacher, S., Schwarz, J., Vogt,
W. 2012. Legal consequences of increasing vehicle automation - Joint final report of
the project group. In Reports of the Federal Highway Research Institute, Bergisch-
Gladbach.
Hosse, René Sebastian, Daniel Beisel, Eckehard Schnieder. 2012. analyzing driver assistant
systems with a socio-technical hazard analyzing methodology. 5th International. Conference
on ESAR ("Expert Symposium on. Accident Research"). Hannover 7th/8th September
2012.
IEC 61882: Hazard and operability studies (HAZOP studies) - Application guide. 2016.
International Electrotechnical Commission.
ISO 26262: Functional safety - Road vehicles. 2011. International Standardisation Organisation.
Leveson, N.G. 2011. engineering a safer world. Massachusetts: MIT Press.
National Transportation Safety Board (NTSB). 2017. highway accident report - Collision
between a car operating with automated vehicle control systems and a tractor-
semitrailer truck near Williston, Florida, May 7 2016 (NTSB/HAR-17/02). Washington:
NTSB.
Preuk, Katharina, Lars Schnieder, Claus Kaschwich, Daniel Waigand, Eva-Maria Elmen-
horst. 2016. stresses of employees in the driving service of public transport - validation
and acceptance analysis of a psychomotor vigilance test in the test field AIM. 17th
Symposium Automation Systems, Assistance Systems and Embedded Systems for
Transportation (AAET), Braunschweig, February 10-11, 2016, 61-78.
Reif, Konrad. 2010. driving stabilization systems and driver assistance systems.
Wiesbaden: Vieweg + Teubner.

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 201943

L. Schnieder and R. S. Hosse, Guide Safety of the Intended Functionality,
essentials, https://doi.org/10.1007/978-3-658-25023-2
 44Literature

SAE J 3061: Cybersecurity guidebook for cyber-physical vehicle systems. 2016. society for
automotive engineers.
Schnieder, Lars, and René S. Hosse. 2018. automotive cybersecurity engineering guide -
securing connected vehicles on the road to autonomous driving. Berlin: Springer.
Schnieder, Eckehard, and Lars Schnieder. 2013. road safety - measures and models,
methods and measures. Berlin: Springer.
Wagener, Andreas, and Roman Katz. 2016. automated scenario generation for testing
advanced driver assistance systems based on post-processed reference laser scanner
data. Proceedings Driver Assistance Systems 2016. Wiesbaden: Springer.
Winner, Hermann, Stephan Hakuli, Felix Lotz, and Christina Singer, eds. 2015. Handbuch
Fahrerassistenzsysteme - Grundlagen, Komponenten und Systeme für aktive Sicherheit
und Komfort. Berlin: Springer.