Functional Safety Embedded Systems: Integration of in The Development Process of
Functional Safety Embedded Systems: Integration of in The Development Process of
Functional Safety Embedded Systems: Integration of in The Development Process of
INTEGRATION OF
FUNCTIONAL SAFETY
IN THE DEVELOPMENT PROCESS OF
EMBEDDED SYSTEMS
APRIL 2017
I ndex
A bstract 3
01. Introduction 4
02. O ur fictitious occupant restraint system 6
03. A pproach 10
04. System context 14
05. Functional architecture 22
06. Technical architecture 28
07. Summary and outlook 32
Literature 33
2
A bstract
Over the past few years the development of embedded systems for
automotive applications has increasingly used methods to protect against
malfunctions against the background of relevant safety standards including
ISO 26262 and IEC 61508. In practice, the application of these methods
often depends heavily on the underlying development process, which
makes it difficult to understand the practical application in practice.
3
01.I ntroduction
4
01. Introduction
5
02. Our fictitious occupant
restraint system
We also note that not only a single sensor, but a whole series of different
sensors, help to determine a crash situation. This is because, just as one
would expect to rely on the actuators for occupant protection in the mo-
ment of a crash, one would also like to have certainty that they will not
trigger unintentionally, which could be dangerous or even life-threatening.
In addition, there is a number of special cases: there may be child seats,
wheelchair devices and many more.
6
02. O ur fictitious occupant restraint system
• Pressure sensors and crash sensors at the front and sides of the vehicle
• Front airbags for driver and passenger
• Side airbags, front left/right and rear left/right
• A control unit with longitudinal and transverse acceleration sensors
• Seatbelts with belt tensioners for driver, passenger and rear seats
• Airbags, directly connected to the control unit without additional bus
communication
• Belt tensioners, also connected directly to the control unit without addi-
tional bus communication
• A manual on/off switch for the passenger airbag
• A warning lamp in the instruments for a manually deactivated passen-
ger airbag
• A warning lamp in the instruments for an occupant restraint system mal-
function
The goal of our fictitious occupant restraint system is to protect the driver
and passenger from a crash of a specific severity before an impact to the
front passenger area, in such a way that injuries to the front occupants are
minimized. At the same time, passengers in the rear seats must be preven-
ted from moving too far into the front interior by belt tensioners.
7
02. O ur fictitious occupant restraint system
therefore not controllable in exactly how they perform their function: the in-
flation of an airbag or the tightening of a belt always proceeds in the same
manner and speed. The belt tensioners and airbags are coordinated with
one another on the basis of specific standards and assumptions in such a
way that, as a rule, an occupant gently dips into the airbag when impac-
ting it, and so typically is not adversely affected.
If the system recognizes the presence of a child seat on the passenger side,
the passenger’s airbag is switched off and/or must not trip. Whether the
child seat identification information is part of the occupant restraint system,
or this information comes from another system, is an architectural decision
for vehicles. In our case this detection comes from a separate system via a
bus signal. The manual on/off switch for the passenger airbag, however,
is part of our system and is also connected directly to the control unit wi-
thout bus communication.
8
02. O ur fictitious occupant restraint system
9
03.A pproach
The process framework based on [PS09], which is the basis for this report,
initially starts from the definition of general goals for the system. These goals
are then presented, extended and validated by scenarios. An initial system
architecture is defined in parallel on the basis of the system environment
(context). Based on objectives, scenarios and context or architecture, an
iterative process of refinement and consolidation begins, which is repea-
ted for each of the abstraction stages of the system (system, subsystem and
component level). The end of this process is the specification of detailed
requirements. The strategy shown in Figure 1 within an abstraction level is
also referred to as a goal scenario-based approach.
10
03. A pproach
11
03. A pproach
Methods for functional safety can now be applied for each of these abs-
traction levels. Examples of such methods for the verification of safety tar-
gets and the determination of safety requirements according to [VDA06]
are (see [H11]):
• Failure Mode and Effects Analysis (FMEA) – a design tool for the
systematic analysis of failure conditions and the resulting effects on the
system. FMEA considers error conditions for each element of the sys-
tem individually, and can thus be applied at different levels. Thus FMEA
at the functional level can consider fault conditions of functions, while
FMEA at the level of technical components may involve physical faults
and technical faults.
• Safety Goals are located at the level between the system and the
environment. They contain targets for the prevention of unacceptable
dangers and risks.
12
03. A pproach
13
04.S ystem context
When designing embedded systems, the integration of the system into its
context plays a decisive role. Current approaches to system development,
e.g. [PS09], first define the actors and systems in the context by conside-
ring the system to be developed as a closed unit (black box).
The occupant restraint system interacts with the following elements in its
environment:
14
04. System context
Different interfaces exist for interacting with these elements. These include
the following sensors, actuators and man-machine interfaces:
15
04. System context
16
04. System context
Figure 4 shows an extract of the target tree for the airbag system for
occupant protection.
17
04. System context
18
04. System context
Detailed descriptions of each use case are created in a second step. Figure
6 shows this for the use case ’Waiting at an intersection’.
Alternative procedure
1. The driver stops at an intersection.
2. The system does not release an airbag.
3. Another vehicle drives at about 35 km/h into the front of the
waiting vehicle.
4. The driver's airbag releases.
5. The driver is hit by the airbag.
Negative sequence 1
1. The driver stops at an intersection.
2. The system releases the driver’s airbag.
3. The driver is hit by the airbag.
Negative sequence 2
1. The driver stops at an intersection
2. The system releases the airbag for the empty passenger seat.
3. The driver temporarily takes the vehicle out of operation.
Figure 6. Example of the use case ‘Waiting at an intersection’
It should be noted that both the normal and alternative procedures for
target fulfilment – here the safety target ‘occupant protection’ and its
partial targets – report [S1]. Only the negative processes cover situations
that do not lead to the goal. These negative procedures are an indication
of potential hazards.
19
04. System context
20
04. System context
• The airbag must not deploy when there is no accident (SG2). This objec-
tive results from the danger to the driver or a passenger of unintentional
deployment of an airbag.
21
05.F unctional architecture
22
05. Functional architecture
The starting points for the design of the functional system architecture are
the system objectives in our example. Use cases will have been descri-
bed at the overall system level based on these objectives. These describe
the interactions of the system with actors from the context. Functions of the
system can be derived from these by refinement. Examples of such
functions might be:
The system functions are linked by the data transmitted between them.
For example, the function ‘trigger airbag’ requires the type and severity
of the crash to be measured, as well as the seat occupancy, to determi-
ne the desired output. These input values are supplied by other functions
(in the example, ‘Calculate crash severity’ and ‘Evaluate seat occupancy’).
The overall context of the functional architecture can be represented in a
data flow diagram (DFD). Figure 8 shows a DFD for the passenger restraint
system we developed.
The units of the functional architecture are also called logical units of the
system. They are the functions on the basis of which text descriptions for
use cases are created, and functional and qualitative requirements can be
defined.
23
05. Functional architecture
24
05. Functional architecture
Functional safety
In FMEA all possible fault or failure states are considered for each
system function. For each error condition, the effects that the error has on the
system are determined individually. These are, for example:
25
05. Functional architecture
• The occupant restraint system should have several control sensors becau-
se of its criticality.
• The control unit for calculation of the triggering time should be designed
redundantly in order to trigger a majority decision in the case of a con-
trol unit fault.
FMEA thus offers the advantage that it can reveal design restrictions for
technical components when applied at the functional level. Of course, the
technical safety aspects and their effects on the functional system design
have to be considered later in a further safety analysis.[S2]
26
05. Functional architecture
Item Possible Possible Phase of local Next Effect on (P) Probal- (S) (D)Recog- Time until Risklevel Actions/ Avoidance
fault con- reason/ mission effects of higher system bility Strength nition uncover- P’S (+D) Following / Require-
dition meacha- th e error livel of level ing Examina- ments
nisms error tions
Evaluate Measured defective Crash too high ac- Trigger time Airbag (B) Remote (V) Critical None N/A unaccept- Adjust requires
longitudinal longitudinal sensor cleration is of airbag is triggers to able hardware redundant
acceler- acceleration deteermind miscalcu- early design (control-)
ation is to long lated sensors
longitudinal Measured defective Crash too small Trigger time Airbag (B) Remote (V) Critical None N/A unaccept- Adjust requires
acceler- longitudinal sensor accleration of airbag is triggers to able hardware redundant
ation acceleration is deteer- miscalcu- late design (control-)
is to short mind lated sensors
longitudinal Measured defective Normal too high ac- Airbag is Airbag trig- (B) Remote (V) Cata- None N/A unaccept- Adjust requires
acceler- longitudinal sensor Drive cleration is triggerid gers without strophic able hardware redundant
ation acceleration deteermind while a reason design (control-)
is to long driving sensors
longitudinal Measured defective Normal too small no effect no effect (B) Remote (I) No effect None N/A low none none
acceler- longitudinal sensor Drive accleration
ation acceleration is deteer-
is to long mind
Table 1. Extract of FMEA results template for the occupant restraint system
27
06.T echnical architecture
28
06. Technical architecture
29
06. Technical architecture
There are also methods that can be used to support the functional safety
of the overall system based on technical components, to validate them
against other results. Fault tree analysis (FTA) is one such method. Figure 10
shows a fault tree for the side airbags in the example system.
Figure 10: Fault tree for the occupant restraint system based on technical components
30
06. Technical architecture
The fault tree examines the branches for possible fault conditions in indi-
vidual components, here for example of the seat occupancy sensor and
detection of a crash. These are ultimately linked to a faulty system state (the
top event) by means of logical AND and OR links over several levels. This
shows the possible effects of linking various errors or failures.
Individual errors of components can be detected from the fault tree analy-
sis and faults can be assigned to the functional or overall system level. The
focus is on the interaction of different defective components. Further analy-
sis methods can also be applied to the error tree. For example, the occur-
rence probability of the top-level event can be determined by the probabi-
lities of the individual component errors. This makes it possible to determine
the extent to which a redundantly designed component increases safety in
relation to occurrence of the top-level event. In addition, measures can be
defined on the basis of the fault tree to avoid the top-level event or reduce
its risk.
31
07. S ummary and outlook
32
L iterature
• [BJ13] Birch, John, et al.: Safety cases and their role in ISO 26262
functional safety assessment. International Conference on Computer
Safety, Reliability, and Security. Springer Berlin Heidelberg, 2013.
33
08 Q uellenverzeichnis
34