Back

Author: Alexander Dobry, Knorr-Bremse Systeme für Nutzfahrzeuge GmbH, Germany

FMEA: Effective handling of complex systems

When a parts supplier evolves into a system supplier, it becomes necessary to rethink the way Failure Modes & Effects Analysis (FMEA) efforts are implemented. The only way to ensure the requisite completeness, continuity and timeliness of an FMEA is to use a clearly defined approach that takes into account a company’s own organizational and project structures. Knorr Bremse Systeme für Nutzfahrzeuge GmbH, Schwieberdingen, Germany, successfully applied a concept based on the procedure described in VDA Volume 4.2 to increase the transparency and clarity of its FMEAs.


As the number of subsystems and components that comprise a product increases, so does the necessity to distribute development tasks among different departments of an organization. While this increases the developers’ specialized knowled
e, it decreases their knowledge of the system as a whole. Therefore, the expert knowledge of all of the developers involved in a project must be merged to enable the analysis of potential effects for customers.

At Knorr Bremse, several departments at different locations around the world are involved in the development of the system, software, and electronic and mechanical components that go into an electronically controlled braking system. The increased complexity of the system had made it impossible for any one person or even the design team for any one subsystem to assess the effects of a failure or defect within the vehicle. It had also become impossible to create an interdisciplinary FMEA. As the system’s complexity grew, so did the size of the FMEA team, making it difficult to conduct FMEA sessions.

Change was necessary

Because development tasks are distributed among various project teams, and subsystems (software, electronics, and mechanical components) are often designed concurrently with overall system development (simultaneous engineering), it was difficult to establish and ensure the continuity of the FMEA (throughout system and design). A suitable approach was needed that would ensure the continuity and completeness of the FMEA and make it possible for each developer to analyze his components in the FMEA without having complete knowledge of the entire system. Thus, an FMEA structure was defined that would reappear in and follow the project structure. This structural consistency made it possible to clearly assign responsibilities for FMEA implementation and identify interfaces early on. Scio FMEA System, a project management software tool engineered by PLATO AG of Lübeck, Germany, was used to develop this structure. Scio FMEA System allows the projects to be clearly identified. A particular advantage for Knorr Bremse was that Scio FMEA System permits multiple systems to be assigned to one project, or a single subsystem to be assigned to multiple projects. This made it easy to find projects and subprojects containing different variants of a system or subsystem.

Resolving the problems inherent to multiple-location development also required a model that would ensure a uniform, comprehensible structure. An additional software tool, Scio Matrix Analysis, was extremely helpful here. The advantages of using matrix analysis over representing the system in a structure tree lie in the fact that the function, failure and system structures are set up almost simultaneously and that functional relationships are indicated within the matrix (Figure 1). Because the basic structure of the matrix and the procedure for setting up the matrix remain constant, questions of methodology take a back seat in FMEA sessions. It is easier to describe relationships, and the content of the FMEA is more uniform and more logical.

The structure of each matrix is based on the answers to three questions:

• What is the system or product to be analyzed?
• What customer needs/expectations, regulatory requirements, standards, etc. are associated with such a system or product (functions and/or requirements)?
• What subsystems make up the system or product? And which functions correspond to these subsystems (directly or indirectly)?

Using this approach, primary functions that are developed using software are mapped to subsystems of an anti-lock braking system (ABS) and then linked to their influence on the requirements for the overall system with an “X” in the matrix (Fig. 1). These links indicate direct relationships (via “function”) and indirect relationships (via “failure” only).


Fig. 1: Top-level representation of the requirements for an anti-lock braking system and its internal components (subsystem)

At the system level, only customer needs or regulatory requirements and the functions by which they are met are mapped to subsystems. No components are mapped or analyzed at the system level. The requirements that the relevant components must meet in order to fulfill a function are mapped at interfaces (Fig. 2). An interface is both a means of separating system from design and a means of linking the two. Interfaces make it possible for the teams to work independently at different locations. Design FMEAs and System FMEAs can run parallel to each other up to a certain stage of the development process.


Moving forward independently

Once the entire system is mapped in the matrix analysis module, the different teams can work separately on their subsystems, defining internal functions and describing potential failure modes. The system and design teams can work independently of each other and only have to work together at the interface to ensure that they have the same understanding of the function and failure descriptions. However, the failure modes at the interfaces should not be linked until their content has been coordinated between the system and design teams and no more major changes are expected. At this point, the teams can work independently again, linking the failures described at the interface as either causes (System FMEA) or consequences (Design FMEA), thus establishing the continuity of the FMEA.

When assigning actions, it is imperative that the prevention and detection actions at the system level are kept strictly separate and from those at the design level. Software actions that are taken to identify and prevent the effects of component failures must be assigned at the system level to the corresponding cause from the interface, and not to components (at the design level). Such actions should not be used to reduce design risks. Maintaining this separation helps minimize faulty entries due to insufficient knowledge of the entire system. In addition, it allows for clean modularization and, thus, makes it easier to reuse the components in another FMEA. However, it can also result in an unintentionally high Risk Priority Number (RPN) for the causes of component failure, as this additional action is not listed and cannot be used to reduce the RPN.

The terminal server solution supported by Plato AG and a multiple-user capability that enables multiple clients to work on the same FMEA database all over the world allow multiple employees at multiple locations to work on the FMEA at the same time. This makes it possible for developers to work at the component development level without knowing everything about the entire system.

Noticeable progress

This new approach has made FMEA generation clearer and more transparent. It is repeatable and easy to apply to any system development project. As a result, it has become easier to estimate the time involved in implementing an FMEA based on the possible number of components, functions and failures that need to be analyzed. The FMEAs are no longer structurally unique. They can be adapted or expanded to accommodate changes in operating and/or environmental conditions and customer needs. The FMEA team has also shrunk to just three to five people and participants’ knowledge of the system has increased during FMEA sessions. This has had a direct positive impact on development quality.


Back