FMEA Integration in Requirements

Management as a Basis for an Automotive

SPICE© Level 3 Project

Ovi Bachmann1 and Bernhardt Steger2(B)

1 Grape GesmbH, Buxtehude, Germany
[email protected]
2 ISCN GesmbH, Graz, Austria

[email protected]

Abstract. In the development of embedded systems, different methods and tools

are used today for requirements management at system and software level and for
the design of the mechanics. This results in increased development efforts. On the
other hand, the different methods still do not lead to the possibility of evaluating
the proposed architecture at the system level at the earliest possible stage and
subjecting it to a risk assessment. The approach presented here - the so-called
Design-Centred Approach - is intended to close this gap by incorporating the
approach of a FMEA into requirements management - without causing additional
effort.

Keywords: Requirements management · FMEA · Automotive SPICE© ·

System engineering · Design centered approach

1 Introduction
In the development of mechatronic systems, attempts have been made for some time to
align the development processes of the mechanics and the system with those of hardware
and software development. In the automotive industry, the development processes of the
mechanics and the system are still strongly determined by the ISO 9001 [1] and IATF
16949 [2] standards, and those of the software by ISO 33020 (SPICE) [3].
There is currently no company in the automotive sector that does not make great
efforts to build bridges between the methods. To do this, software interfaces between
tools must be programmed. For example, tools that can integrate data from models such
as MATLAB Simulink into ALM tools are in great demand. Although there are tools
that offer the processing of FMEA in ALM tools, FMEA and requirements management
are processed completely in parallel because an integrative approach is missing. The
resulting duplication of work demotivates the developers and has therefore a negative
influence on the project result which in turn impacts the return on invest.
Due to the increasing complexity, analyses and methods are becoming more and
more important, on the one hand to keep them better under control, and on the other

© Springer Nature Switzerland AG 2021

M. Yilmaz et al. (Eds.): EuroSPI 2021, CCIS 1442, pp. 575–585, 2021.
https://doi.org/10.1007/978-3-030-85521-5_38
576 O. Bachmann and B. Steger

hand to find any failures (e.g. in the design) at low cost which means as early as pos-
sible. While in the software development meanwhile very often the specifications of
Automotive SPICE© [4] are used (i.e., software is created on the basis of requirements
and implemented according to the V-model), for the design of e.g. mechanics the method
FMEA is primarily used. Both methods have their advantages but also gaps - and on
system level both methods should be integrated to a functioning whole. There are inter-
esting approaches to fill these gaps with new analysis methods on system level. One
example is the method according to Roman Tizki [5] in which he explains that functions
are not equal to requirements.

2 System Engineering – Actual Approach

Actually, attempts are made to secure design decisions as early as possible in the project.
Also because of the ever-decreasing time-to-market, it is essential that system develop-
ment reaches assessable design decisions at an early stage [6]. Design decisions can be
evaluated by the already mentioned FMEA methodology by performing a risk assess-
ment of the functions to be executed. In addition to the FMEA, a simulation model
is often developed for this purpose. Model-based development is used to cover a high
degree of innovation through fast cycles for variants and to determine the most promising
variant at low cost. The introduction of evaluated design decisions would also be of great
benefit for software design. The functional safety standard, ISO 26262 [7], also aims in
this direction by mapping the contents of system, hardware and software development
each by a V-model and evaluating functions in terms of their risk. A combination of the
V-model and the FMEA for the development of a mechatronic system could thus look
as follows see Fig. 1:

functions of the detection

functions with detection measures measures of the
system FMEA
system FMEA

system requi- requirements with connected tests

systemtest
rements analysis

system architect- system

ural design integration
and test
software requirements detection
functions of the softwaretest
product FMEA analysis measures of the
product FMEA
software
software design integration
and test

software construction

Fig. 1. Development according to the V-Modell and the use of the FMEA methodology
 FMEA Integration in Requirements Management 577

2.1 System Cost Factors

It is rather easy to find numbers in the literature that show how the failure costs develop
over the project duration, as long as one looks in the area of software development. This
is significantly more difficult in the field of system development. The only publication
known to the author was found in a book on “Designing cost-effective space missions”
[8]. The system cost factors presented in the following table are errors found in the
electronics hardware. These costs were published without referencing the methodology
used.
Phase in which the change has to be made Resulting cost
Product design $1,000
Product test $10,000
Process design $100,000
Pre-production $1,000,000
Series production $10,000,000

It must be held in mind that this is the aviation industry, with much lower volumes
than in the automotive industry. Nevertheless, most developers agree that the costs per
phase increase by a factor of about 10. This results in a strong need to find defects as early
as possible in the development process. To accomplish this, many quality methods are
used, some of which have already been mentioned above. Some of these quality methods
can also be found in the current standards and must therefore be bindingly applied.
A second source of costs in the field are those dealing with law suits. Especially
any harm in the field caused by a functional safety violation is a permanent thread to all
OEMs. The example shown in Fig. 2 is most likely still vividly known by all readers.

Fig. 2. Famous case of costs due to a functional safety violation [9]

578 O. Bachmann and B. Steger

2.2 FMEA and Automotive SPICE©

As already mentioned above, modern system development works according to the V-

model. The engineering processes of the Automotive SPICE© VDA guideline [4] map
this V-model. Depending on the system to be developed, standards require a test coverage
of the requirements of up to 100% (this means that each requirement on the left branch of
the V-model must be linked to at least one test description with acceptance criterion on
the right branch. The SPICE standard originally explicitly required only that software
be considered as a subsystem in addition to the system. However, since this method
provides an excellent overview of the development progress and the project risk, the
electronics and in some cases even the mechanics were frequently mapped as well. This
has also been considered in the latest updates of the standard by including a plug-in
system in order to cover electronic hardware and mechanics as well.
Until 10 years ago, a functional system description was only required by FMEA.
The mechanics are described in the FMEA down to the component and characteristics
level. This often results in three or more levels below the system. The structure tree of
the FMEA is very similar to the architectural design.
In contrast to the test coverage with acceptance criterion in requirements manage-
ment, the FMEA describes failure functions that are linked to detection actions. These
are tests that are intended to detect a wrong layout of the product during development.
For example, it is irrelevant when considering whether an error occurred in the test
because the prototype was not correctly put on the test rig (since this is not a design
error). Whereas errors that occur because, for example, wrong material was used or an
incorrect welding process was selected are relevant for errors in the layout of the design.
In addition to detection, there is also prevention, which relates to design (a typical
example is a simulation or FEM calculation). A prevention measure serves to reduce
the probability of occurrence of the cause or to make it as good as impossible before
the feared negative event occurs. For example, for a mechanical connection, a bolted
connection is specified that can absorb 100% more force over its lifetime than it can
possibly occur in the system.
Based on the detection and prevention actions, it is possible - in contrast to require-
ments management - to provide an assessment of the design layout or design quality. This
assessment is done with the help of a risk priority number RPN. The RPN is calculated
as the product of three quantities:

1. probability of detection of a failure,

2. probability of occurrence of a failure, and
3. severity of the resulting damage.

An example for the calculation can be as follows:

A manufacturer determines the probability of a failure to be high (e.g., 9 out of 10),
the probability of detection to be medium (e.g., 5 out of 10), and the impact of the defect
to be low (e.g., 3 out of 10). Then the RPN is calculated as 9 × 5 × 3 = 135.
Whereas it has to be kept in mind that the definition of the risk according to Definition:
ISO 14971:2012 and ISO 14971:2019 is:
 FMEA Integration in Requirements Management 579

“A combination of the probability of occurrence of harm and the severity of that

harm” [10].
Having the risk for costs in mind as stated in table above this risk can also be set equal
to the project risk, which is a combination of functional failures and possible hazards in
the field.
There is one disadvantage to the FMEA that makes the combination with requirement
management desirable:
The use of interdisciplinary teams in the context of an FMEA is very time-consuming
and expensive - these costs are incurred immediately. Whereas, the reduced failure costs
do not decrease directly, but with a time delay, or do not occur at all and cannot be
calculated. There is no direct correlation between RPN and costs.
In a combination a modern way of system development thus extends the classical
V-model in a way as shown Fig. 3:

Fig. 3. Modern solution for functional safety and SPICE level 2

The hazard and risk analysis shall only be mentioned briefly here. It is required by
the safety standard and should be carried out at the beginning of the development. The
hazard and risk analysis initially considers only the functions at system level, estimates
the risk to operators and surrounding persons, and provides a risk rating. This value,
known as the safety integrity level, is taken as input to the FMEA, where it determines
the top-level severity. As a result, this rating generally influences the overall design of
the product. This influence propagates further into the subsystems down to the lowest
levels.
580 O. Bachmann and B. Steger

Depending on the project size, several teams work in the development in a project.
There is the safety team, which has the task of ensuring the functional safety of the
system, the system analysts/architects, who are responsible for the system requirements
and the system design, and then there are the subsystem owners, who usually make up
the largest number of developers. These are often spread across multiple departments. In
Fig. 3, the test was not mapped. It has to be understood that there is a shadow bubble for
each requirement bubble containing the test cases that must be linked to the requirements.

3 Problem and Impact Analysis

If you look at the explanations up to this point, it immediately becomes clear to anyone
working in this area that both FMEA and requirements management have functional
description and design as their basis. However, the focus of the consideration is very
different - and so is the result. Requirements management provides a large number of key
performance indicators that help to manage a development project. Especially temporal
trends of key performance indicators help to recognize whether the project has problems
and to intervene at an early stage (one example for a kpi is the number of linked and
passed test cases).
Automotive OEMs and suppliers must perform FMEAs to pass their ISO 9001 [1]
or IATF 16949 [2] audits. Gaps in FMEA can lead to costly rework or even prevent
certification. Despite this, FMEA implementation is often done with high resistance by
the developers. As a vehement advocate of the meaningfulness of the procedure, one
must unfortunately nevertheless state again and again that the FMEA is done too late, or
is sometimes even seen as process satisfaction. Under these circumstances, developers
are not motivated to carry out a FMEA. In many companies, project management of
the development via requirements management is better accepted. The control made
possible by the FMEA via the RPN (or AxE, etc.) is replaced by key performance
indicators (metrics) from requirements management, which cannot show development
risks in a topic-related manner [11].
Instead, design decisions are made using other methods such as DoE, design meet-
ings, 8-D reports, design for assembly, etc. However, these methods are not suitable for
developing entire systems with a high degree of complexity, but were developed for use
for example in task forces, or, as in the case of the design meeting, are usually not based
on a sophisticated method.
The Automotive SPICE© process model [4] is of the utmost importance for suppliers
in particular, as they are required by OEMs to develop according to a maturity level of
at least CL2 when developing mechatronic systems. This is regularly checked in assess-
ments and strong deviations lead to considerable additional costs up to downgrading
from A to C supplier (it is assumed that it is clear to everyone what this means). In the
past, this circumstance led to large investments in documentation systems. Without tool
support, it is almost impossible to meet the requirements of the standard. In a real system
such as an active rear axle steering system, the system description consists of up to 1,200
system level requirements and several hundred interface descriptions for the architecture
design. Each requirement or interface must be linked to at least one requirement from
the subsystem levels and additionally to at least one test case. For subsystems, electron-
ics has about 1,000 requirements and software has a few more. One can easily imagine
 FMEA Integration in Requirements Management 581

that some developers claim to spend close to 80% of their time on documentation. In
this context it is understandable that very few developers are enthusiastic about using a
second method like the FMEA with similar documents.

4 Functional Description and Design Evaluation

As seen in the previous chapters, there are two main approaches to developing embedded
systems today - both with advantages and disadvantages. So why not combine both
approaches? But if, how?
Based on the design ideas and the functional description as it is done in a simulation of
a system using a method like the one used when working with MATLAB Simulink – i.e.
a dynamic description of a system behavior, the authors developed the Design-Centred
Approach (DCA):
The DCA describes the approach to the system engineering in different layers of
abstraction. Each layer of abstraction consists of a functional specification and a traceable
deduced design decision – the architectural design. Within the architectural design there
are functional blocks. The description of a functional block is a functional specification.
These functional blocks are related to one another via signals. The signals between the
functional blocks are the interfaces of the system. The next lower layer (i.e. the layer
of a system element) describes comprehensible the functional blocks in specification
(functional description) and design (of the lower layer aka system element).
The advantage of this functional description of each functional block can be found
in the fact, that each description of a function block is actually a specification, which is
for each design element valid in itself. Possible false system behavior can be found by
expanding the functional description with failures that are linked to the functions. By
doing so, the source element of the failure can be identified on every layer and similarly
to the FMEA method it can be evaluated according to its detection and prevention action.
The traceability can be drawn by either using the approach, that each function takes
input signals to generate output signals, or by using the approach that a failure in a func-
tion corrupting the output of this function has automatically an impact on the depending
function(s) of same or higher layer. Applying the method to calculate a risk priority
number (RPN) – by assigning a severity (of the failure), a probability (of the failure
occurring), and a detection (i.e. a probability that the failure would not be detected
before the user was aware of it, based on the defined detection and prevention actions)
the DCA as a requirements management can be used to evaluate the layout of each
function as each failure needs a test in order to find a false layout.
This way, the following base practises of Automotive SPICE© CL1 [4] can be easily
fulfilled:

Level/Domain Process/Base practise ID Base practise

System SYS.3.BP5 Evaluate alternative system architectures.
Define evaluation criteria for the architecture [4]
Software SWE.2.BP6 Evaluate alternative software architectures.
Define evaluation criteria for the architecture [4]
(continued)
582 O. Bachmann and B. Steger

(continued)
Level/Domain Process/Base practise ID Base practise
Hardware HWE.2.BP6 Evaluate the hardware architecture and the
hardware detailed design. Analyse and evaluate
the hardware architecture and detailed design
against defined quantitative or qualitative criteria,
including risks, manufacturability, and verifiability
[18]
Mechanic MSE.2 BP7 Evaluate alternative mechanical system
architectures. Define evaluation criteria for
architectural design [19]

Additionally, innovative and new ideas can be secured, the development costs
estimated, and a clear basis for decision is delivered to the project team.

4.1 Example: Aircraft Tractor

The DCA has been used in project to develop a typical aircraft tractor with a so called
lifting device (s. Fig. 4).

Fig. 4. Lifting device of an aircraft tractor

Additionally, innovative and new ideas can be secured, the development costs
estimated, and a clear basis for decision is delivered to the project team.
 FMEA Integration in Requirements Management 583

Angel sensor
For Pivoting

ECU ECU
Electronic

Range sensor
For pulling

aircraft
tractor Pivoting
arm

Pulling
arm
Lifting device
Pivoting
cylinder

Pulling
cylinder

Lifting
cylinder

Frame

Fig. 5. (Simplified) structure tree for lifting device of aircraft tractor

The main function of the aircraft tractor is to push or pull aircrafts either away from
the dock, on the runway, or to the service hall. The design decision to have a lifting
device is because of the size and weight of modern planes. An Airbus A380 roughly
weighs 400 [tons]. To be able to push this weight with a standard rod aircraft tractor
the weight of the tractor at a µ of 0,5 between tire and road must be 70 [tons], which is
about the weight of the tank Leopard 2. Using a lifting device makes an overall tractor
weight of 16 [tons] possible.
Using DCA the final structure tree was as shown in Fig. 5 (in order to simplify the
graphics only the function block aircraft tractor, ECU and lifting device shall be looked
at. In the next Fig. 6 the functional description is always shown on the left side, the in-
and out signals of the function block are always shown on the right side):
The top level of the structure tree in Fig. 5 is on the left side. In Fig. 6 it goes from top
down. This means the functions of top architectural element aircraft tractor can be found
at the top. The next architectural level down shows the functions of the lifting device. On
the right side in Fig. 6 the Signals are shown which are used as input and output for the
functions. Just like in a FMEA the severity can be taken from the top level. Together with
the failure functions and false signals the RPN can be calculated (severity × probability
of occurrence × probability of detection). This way the requirements together with the
architectural design of the requirements management can be used just like in a FMEA
to determine project risks.
584 O. Bachmann and B. Steger

Fig. 6. (Simplified) structure tree for lifting device of aircraft tractor

5 Conclusion

FMEA and safety processes can be seamlessly integrated into a process for the devel-
opment of complex products using the Design-Centered-Approach to fully comply with
ISO 33020 SPICE [3], ISO 9001 [1], IATF 16949 [2], and ISO 26262 [7] standards. An
estimated 80% of duplicate work can be avoided as a result. The documentation effort
of the developers is significantly reduced.
At the same time, companies will be prepared for the new Automotive SPICE© 3.1
[4] standard, which requires design assessments not only at the system level, but also at
the software level. With the help of the DCA, 80% of the information from the existing
documentation systems can be used.
In many companies it is commonly done to simulate a complete system behavior in
pre-development. It can be very useful to import this information into a database. By
doing so applying the DCA can re-use this data and provide many of the requirements
needed for requirements management and also the FMEA.
In addition to the time savings, the DCA method enables a high degree of innovation
in development projects. Key metrics from requirements management can be used to
steer development projects, as can risk assessments of new design ideas. Risk assessment
is not only required by Automotive SPICE© 3.1 [4], but is the basis for fundamental
design decisions and therefore very helpful for design discussions within the department.
This way, time to market can be reduced based on valid design decisions.
 FMEA Integration in Requirements Management 585

References
1. ISO 9001:2015, Quality management systems—Requirements. https://www.iso.org/standard/
62085.html
2. IATF 16949:2016, Quality management systems—Particular requirements for the application
of ISO 9001:2008 for automotive production and relevant service part organizations. https://
www.iatfglobaloversight.org/
3. ISO/IEC 33020:2019, Information technology—Process assessment—Process measurement
framework for assessment of process capability. https://www.iso.org/standard/78526.html
4. Automotive SPICE© 3.1, Process Assessment Model, VDA QMC Working Group
5. Tizki, R.: Anforderungen sind nicht das gleich wie Funktionen. In: FMEA Konkret, vol.
11/2019
6. Ekert, D., Steger, B., Messnarz, R.: Functional roadmap - scheduling in complex mecha-
tronic projects. In: Barafort, B., O’Connor, R.V., Poth, A., Messnarz, R. (eds.) Systems,
Software and Services Process Improvement. EuroSPI 2014. Communications in Computer
and Information Science. Springer, Cambridge (2014)
7. ISO 26262:2018, Road vehicles—Functional safety. https://www.iso.org/standard/68383.
html
8. Cloud, Giffen, Larson, Swan: Designing Cost-Effective Space Missions: An Integrated,
Systems Engineering Approach, Teaching Science and Technology, Inc. (1999)
9. Automotive DRIVES, online course: Functional Safety Manager – Strategic Level, U1 Func-
tional Safety Strategy, U1.E1 Motivation and Introduction to Functional Safety, slide 8,
Updated Release 5.2 for DRIVES (2020)
10. ISO 14971:2019, Medical devices—Application of risk management to medical devices.
https://www.iso.org/standard/72704.html
11. Steger, B., Ekert, D., Messnarz, R., Stolfa, J., Stolfa, S., Velart, Z.: Metrics and dashboard for
level 2 – experience. In: Yilmaz, M., Niemann, J., Clarke, P., Messnarz, R. (eds.) Systems,
Software and Services Process Improvement. EuroSPI 2020. Communications in Computer
and Information Science, vol. 1251. Springer, Cambridge (2020)
12. Schönsmaul, S.: Integration of “Functional Safety” into quality management of KTM-
Sportmotorcycle AG, Functional Safety Management KTM-Sportmotorcycle AG, Austria,
Keynote Eurospi (2012)
13. Werdich, M., et al.: FMEA - Einführung und Moderation, Vieweg und Teubner 1. Auflage,
p. 193 (2011)
14. Bachmann, V., Messnarz, R.: Improving the software-development for multiple projects by
applying a platform strategy for mechatronic systems. In: Proceedings of the EuroSPI 2009
Conference, Wiley SPIP Journal, August 2010
15. Borgeest, K.: Elektronik in der Fahrzeugtechnik – Hardware, Software, Systeme und
Projektmanagement, 3. Auflage Springer Verlag, p.314 “Architekturbasierte Entwicklung”
16. Rizzo, S.: ALM und PLM - Ein erfolgreiches Team. http://de.slideshare.net/Polarion_Deutsc
hland/alm-und-plm-ein-erfolgreiches-team
17. NASA Johnson Space Center, Error Cost Escalation Through the Project Life Cycle. http://
ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100036670.pdf
18. PRM/PAM Hardware Engineering (HWE) 1, 2019, intacs Working Group
19. Process Assessment Model SPICE for Mechanical Engineering 1.7, 2020, intacs Working
Group
20. Bella, F., et al.: Automotive SPICE® 3.0. What is new and what has changed?. http://www.
kuglermaag.de/verbesserungskonzepte/automotive-spice/automotive-spice-v30.html
21. Korsaa, M., et al.: The SPI manifesto and the ECQA SPI manager certification scheme. J.
Softw. Evol. Process 24(5), 525–540 (2012)