RICHARD POHL AND HELKO GLATHE

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.

This report presents the application of some common methods as part of

a complex, up-to-date development process for embedded systems. A
complete example is developed for the specification of an occupant
restraint system.

3
01.I ntroduction

The development of embedded systems in the automotive sector from

software and hardware components is tied to high quality standards to
ensure safe operation under all circumstances. Classical quality assurance
achieves this goal through validation and verification. In modern software
development projects, this is also achieved by the standardization of the
development process. Examples of such standards include ASPICE for pro-
cess maturity models [KH08] and ISO 26262 [ISO11] for the development
of safety-relevant electrical-electronic systems for motor vehicles.

ISO 26262 describes a function-driven development process that ensures

functional safety, in particular through the additional definition of safety
requirements. This standard makes use of three main methods to meet saf-
ety requirements at different stages of the development process. These are
essentially hazard and risk analysis for the determination of safety goals,
inductive analysis (FMEA) and deductive analysis (FTA). In the meantime,
development processes (for example process FMEA) are also investigated
with regard to functional safety [VDA06].

Current approaches to the development of embedded systems are based

on the idea of continuous hardware and software co-designs over sever-
al abstraction levels. This report shows how methods for functional safety
can be applied in such a context at different levels of abstraction. It uses a
process framework by Pohl and Sikora for the development of embedded
systems [PS09] as an example.

To provide a consistent example this report uses a fictitious occupant

restraint system. This is characterized by the fact that it has a substantial
portion of software and hardware components and is highly dependent on
the environment of the vehicle. A typical occupant restraint system consists

4
01. Introduction

of various pressure and acceleration sensors connected via microcontrol-

lers to ignition coils to ensure safe pyrotechnic deployment of airbags. This
example serves as a basis for demonstration and further investigation of
approaches to ensure functional safety.

This report is structured as follows: Section 2 introduces our idea of a

​​ fictiti-
ous occupant restraint system. Section 3 describes the approach followed
in the report, including the process framework used and the approaches
to functional safety methods. Section 4 illustrates the system context of the
occupant restraint system. Section 5 describes a functional system archi-
tecture and the associated functional safety methods. Section 6 deals with
the technical architecture. Section 7 summarizes the results and provides
a brief outlook of their possible further applications.

5
02. Our fictitious occupant
restraint system

To illustrate the challenge, we will specify a realistic example in form of a

passenger car restraint system. From relevant websites and in the techni-
cal literature, it is possible to see that such a system can be designed to
be as complex and variable as possible. As a layman, one might think
that the vehicle somehow detects a crash and then magically inflates
specific airbags in the vehicle, thus protecting the occupants from life-threa-
tening collisions with the interior. If one discusses the issue more intensively,
however, it can be seen that the airbag is only a small component of a
complex occupant restraint system in which sensors and actuators, as well
as other systems, are involved. For example, the triggering time of the
airbag, the time for complete inflation of the airbag, as well as the strength
of the belt tensioning, must have a precisely matched interplay.

The next question is whether or not specific characteristics of human beings

play a role in this coordination of overall functionality. Should the vehicle
also automatically determine the occupants’ weight, body size and other
factors, to protect them even more accurately before impact?

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

In our fictitious case we describe an occupant impact protection or occu-

pant restraint system that consists of the following sensors and actuators:

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

Functionally, our occupant protection is as follows: An airbag releases au-

tonomously as soon as the control unit send the Boolean release signal to
the specific airbag. At the same time, the control unit transmits a Boolean
signal to the relevant belt tensioners, whereupon they tighten the respecti-
ve belt according to a fixed preset value. Both types of actuators, airbags
and pretensioners, are static in their operation when triggering. They are

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

The detection of a crash, with a need to additionally protect the occupant

by the intervention of the occupant restraint system, essentially results from
the following factors:

Triggering the front airbags:

• A frontal pressure sensor detects a deformation of specific severity

• The longitudinal acceleration sensor detects an impact of a specific se-
verity
• Depending on the deformation position (i.e. the position of the pressure
sensors that have triggered) or the impact angle, either both front air-
bags or one of them release

Triggering the side airbags:

• An acceleration sensor detects negative acceleration on one side

• Pressure sensors on one of the two sides detect deformation of specific
severity
• Side airbags on the relevant side are released in the front and rear area

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.

Figure 1. Goal scenario-based approach

10
03. A pproach

According to ISO 26262, a system is defined as a set of elements that rela-

te at least one sensor, a control device and an actuator to each other. The
sensor and the actuator can be part of the system or external components
[ISO11]. According to [PS09], three abstraction levels are defined for the
development of the system according to its structure and the development
activities:

• Entire system level: embedding the system context, system objecti-

ves, system functions and integration of the system with its environment.

• Subsystem level: functional decomposition of the system in subsys-

tems. Part of this level is the objectives, functions and interactions of the
subsystems.

• Component level: realization of the functionality in software and/or

hardware. Here the goals, functions and interactions of the hardware
components are important.

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.

• Fault Tree Analysis (FTA) – an analysis method for the detection of

the causes of faults and their correlation. Fault tree analysis begins with
the (technical) components of a system and considers failures of the
components and their effects on individual functions of the system.

Under ISO 26262 the safety requirements of a hierarchy of different levels

of abstraction [BJ13] must also be verified:

• Safety Goals are located at the level between the system and the
environment. They contain targets for the prevention of unacceptable
dangers and risks.

• Functional Safety Requirements describe concrete requirements

for the vehicle and its systems for achieving safety goals.

12
03. A pproach

• Technical Safety Requirements describe requirements for an elec-

trical or electronic system (E/E system) that is part of an overall system.

• Hardware or Software Requirements describe requirements for

components and parts, and are therefore the requirements for the imple-
mentation of functional safety requirements.

This hierarchy can be compared with the abstraction stages of the

development process by considering the methods for functional safety.
Figure 2 provides an overview of an example safety-oriented development
process.

Figure 2. Functional safety in the development process

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:

• Occupants – for example the deployment of airbags in the event of a

crash. In our case we simplify a car to consider only two types of occu-
pants, the driver and any front and rear passengers.
• Driver – for example to report an error.
• Engine control – for example to determine the on/off state of the
ignition.
• Vehicle battery – which is disconnected by the system in the event of
an accident.
• Longitudinal acceleration – for example to determine the severity
of a crash.
• Lateral acceleration – for example to determine whether the side
airbags should be triggered.

14
04. System context

Different interfaces exist for interacting with these elements. These include
the following sensors, actuators and man-machine interfaces:

• Instrument cluster airbag warning light – to provide error

messages for the driver.
• Seat occupancy sensor – to detect whether an occupant or, for
example, a child seat is present.
• Belt buckle sensor – to detect whether a belt is closed (this is a
prerequisite for the safe use of airbags).
• CAN-Bus – used for communication with other systems such as the
engine control system.
• Acceleration sensors – to measure the magnitude of longitudinal and
lateral acceleration.
• Pressure sensors – to measure whether the outer skin of the vehicle is
deformed, to verify acceleration values.
• (Multi-stage) ignition of the airbag – to ensure the deployment
of the airbag in the event of a crash. There are several ignition stages,
which, depending on the type of accident, cause different behaviour
with regard to the speed and extent of airbag inflation.
• Belt tensioners – triggers to tighten the seat belts.
• Belt force limiter – to regulate the force applied to the seat belt.
• Battery cut-off – to disconnect the battery in the event of an accident.

15
04. System context

The context diagram (Figure 3) shows these elements in the context of

incoming and outgoing data flows. The belt force limiter is not shown,
since no direct data flow takes place here. Nevertheless, it is relevant to
the development of the occupant restraint system and is therefore within the
context of the system.

Figure 3. Context diagram of the example occupant restraint system

16
04. System context

Specification of the system context

As discussed above, the development process of our example follows a

goal-scenario-based approach. Firstly, general objectives are defined,
which the system should fulfil. These goals are then ’operationalized‘ by
means of scenarios – that is, in the context of a sequence of steps. Through
this representation, objectives can be validated and supplemented.

Figure 4 shows an extract of the target tree for the airbag system for
occupant protection.

Figure 4. Target tree for the target ‘occupant protection’

17
04. System context

Applications/use cases of the system

The objectives can be represented within their context in the documenta-

tion in the form of use cases [OMG15]. Initially use cases are considered
without a closer look at the internal system behaviour, i.e. only the parti-
cipation of the respective actors is taken into account. Figure 5 shows an
overview of the use cases for the system.

Figure 5. Use case diagram for the occupant restraint system

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

UC-2 Waiting at an intersection

Normal procedure
1. The driver stops at an intersection.
2. The system does not release an airbag.
3. The driver moves off.

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

Functional safety at the context level

Ensuring the functional safety of a system means ensuring an adequate

absence of danger. A danger is a system state in which potential injury
may occur to a user. More precisely, this is defined by the terms danger
and risk. A hazard is a potential source of injury, while risk is the probabili-
ty of injury. Danger is present when the risk of a hazard is no longer within
the acceptable range. The degree of risk that is acceptable for a particular
type of hazard has been regulated by laws and standards for some years
[H11].

Figure 7. Functional architecture of the occupant restraint system

20
04. System context

The consideration of functional safety at the overall system level is primarily

based on safety goals. These are specific system objectives that are inte-
grated into a target hierarchy for the system. Safety goals are the starting
point for the proof of functional safety, as required by relevant standards
such as ISO 26262 [ISO11]. Safety objectives are usually determined by
considering the hazards during operation of the system.

Examples of safety goals for an airbag system are:

• In all circumstances the airbag must deploy in the case of an accident

(SG1). This objective is the result of the risk of an airbag failure in an
accident.

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

Safety goals can be represented in a target tree, as shown in Figure 4. As

a rule they contribute to the overall target of the system. Explicit considera-
tion of safety goals in the early phase of system development ensures that
they are taken into account in further refinement of the system.

21
05.F unctional architecture

Based on the system context described above, this section describes a

functional architecture for the system. In classical software engineering
approaches, e.g. [DM79], a functional architecture is defined as a logical
decomposition of the system into functions that are visible to the user. In this
sense, logical means that abstractions are made from restrictions imposed
by the technology, for example, from necessary distribution across several
hardware units. The specification of the functional system architecture is the
starting point for the application of further methods for ensuring functional
safety within the development process, such as failure mode and effects
analysis (FMEA).

Figure 8: Example of the functional system architecture for safety functions

22
05. Functional architecture

Functional architecture of the occupant restraint system

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:

• Evaluate seat occupancy

• Release the airbag
• Calculate crash severity

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

These functions essentially include:

• Detection of sensor values – for example evaluation of seat occu-

pancy, belt status, acceleration values ​​and ignition signal.
• Determination of crash severity – as the basis for determining the
ignition sequence of the airbags.
• Determination of the triggering time for the front airbags
– this can vary depending on the severity of the crash, the seat occu-
pancy and the belt status.
• Further actions in the event of a crash – for example triggering
belt tensioners and side airbags and disconnecting the battery. All these
actions can vary depending on the nature and severity of the crash.

Functional and quality requirements can be derived from the functional

architecture for individual functions of the system, for example:

• The system should monitor lateral acceleration every 2 ms.

• The system should calculate a moving average value over 10 ms from
the instantaneous acceleration values.
• The system should provide the moving average value every 2 ms.
• The system shall complete the calculation of the moving average
within 2 ms.

A requirements catalogue was created for the evaluation system that

covers several functions.

24
05. Functional architecture

Functional safety

To support functional safety at the functional architecture level, it is possib-

le to analyze the dangers and risks associated with individual functions of
the system. One of the most important methods is failure mode and effects
analysis (FMEA) [W13, VDA06]. FMEA is a structured process carried out
with a group of experts, the results of which are systematically determined.
Table 1 illustrates the individual considerations of FMEA for our example.

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:

• The local impact of the error

• The error effects on the next higher level of the system
• Faults on the overall system level
• An error probability estimation on a standardized scale
• An error estimate on a standardized scale
• Details of the recognizability and average detection time of an error,
including estimation against standardized scales
• Risks as a result of an error, error probability, recognizability and
detection time
• Investigations and other actions
• Any avoidance actions/requirements to be derived

25
05. Functional architecture

The results of FMEA can be so-called compensating actions. These supple-

ment the functional architecture with functions that cannot be experienced
by the user, but serve as a safeguard. Examples of such safety functions
(Figure 8) are:

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

Technical aspects are not considered at the functional architecture level.

Considering the functional architecture, a function may fail or run too slowly.
Considering the technical architecture (component structure), however, it
is possible to analyze how failures are best minimized by also considering
the interaction of the hardware with the environment. This would, however,
be a follow-up action from FMEA.

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

Technical decomposition of the system into physical components based on

the functional system architecture is defined in the next step of refinement.
For example, software functions for controllers and hardware functions are
distributed to physical components such as sensors.

The longitudinal acceleration sensor interface can be implemented by

various technologies for example. Acceleration sensors can mechanically
measure the deflection of a weight. More interesting however is the ques-
tion of how a control sensor appears to the system. In this example pressu-
re sensors could be used instead of acceleration sensors, to measure the
deformation of the vehicle’s body as a function of the acceleration due to
impact at a specific acceleration threshold.

The following diagram shows a proposal for technical implementation of

the component structure of part of the occupant restraint system for the
passenger airbag activation subsystem. The crash sensor and the internal
acceleration sensor are used for redundant measurement of accelerati-
on, while the backup sensor measures deformation of the body to indi-
rectly provide a control value for acceleration. Further redundancy is thus
introduced by the repeated use of a similar component (an acceleration
sensor) separately from the functional architecture.

28
06. Technical architecture

Figure 9. Technical component structure of the passenger airbag subsystem

In our example, internal acceleration sensors are installed in conjunction

with external acceleration and pressure sensors that provide a consistent
overall value for the acceleration and acceleration control values. The two
functions for calculating the crash severity and its control value are distri-
buted to two physically separate controllers. In addition, there is a circuit
with decision logic and an ignition actuator.

29
06. Technical architecture

Functional safety at the component level

Functional safety at the component level can be supported by methods

such as FMEA in the same way as at the functional level. In doing so, the
individual functions are examined, but not the functions themselves, rather
their individual technical components. In addition to the functional aspects,
physical effects can now be investigated in detail.

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

This report presents possibilities for integrating methods to support func-

tional safety into a development process for embedded systems. The in-
tegration of methods is explained by means of an ongoing example, an
occupant restraint system. In doing so, particular emphasis is placed on a
representation that is reasonably realistic in terms of complexity.

The integration of methods for functional safety is considered in this report

individually for each of the abstraction levels of the system – overall sys-
tem level, functional architecture and technical decomposition. This consi-
deration results in a classification of methods to support functional safety,
regardless of the idea that in embedded systems the technical component
always represents the unit to be viewed. Functional safety should therefore
be considered in all phases of the development process in which techni-
cal decomposition of the system is not yet fully defined. The assignment of
methods for the functional safety of a system to the respective abstraction
levels shown in this report shows a way how to do it.

Integration and application of functional safety was carried out entirely

manually for this report. This provides an interesting starting point for future
work, and also for the integration of automated tools into the development
process, for example to support traceability. It is still an open challenge to
classify common methods of functional safety according to their applica-
bility to different levels of abstraction in system development. This report is
only one example: these approaches should be tested in a larger study on
an industrial scale.

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.

• [DM79] De Marco, T.: Structured Analysis and System Specification.

Prentice-Hall, 1979.

• [H11] Hillebrand, M.: Funktionale Sicherheit nach ISO 26262 in der

Konzeptphase der Entwicklung von Elektrik/Elektronik Architekturen
von Fahrzeugen, Dissertation. Karlsruher Institut für Technologie, 2011.

• [ISO11] ISO 26262-1:2011(en): Road vehicles – Functional safety –

Part 10: Guideline on ISO 26262. International Standardization Or-
ganization, 2011.

• [OMG15] Object Management Group: OMG Unified Modeling

Language (OMG UML). Version 2.5, March 2015. Retrieved online
at http://www.omg.org/spec/UML/2.5/PDF/ on December 30th,
2016.

• [PS09] Sikora, E; Pohl, K.: COSMOD-RE – Verzahnung des Architek-

turentwurfs mit dem Requirements Engineering. OBJEKTspektrum, On-
line-Themenspecial: Architekturen, 2009.

• [KH08] Hörmann, Klaus, et al.: Automotive SPICE in Practice: Survi-

ving Implementation and Assessment. Rocky Nook, 2008

• [VDA06] VDA: VDA-Band 4 Sicherung der Qualität vor Serieneinsatz

- Produkt- und Prozess-FMEA, 2. Auflage, 2006 (Loseblattsammlung).

33
08 Q uellenverzeichnis

• [W13] Werdich, M. (Hrsg.): FMEA - Einführung und Moderation:

Durch systematische Entwicklung zur übersichtlichen Risikominimie-
rung. Springer Berlin Heidelberg, 2013.

34