A blog by Dr. Uwe-Klaus Jarosch, September 2025
Failure Mode and Effects Analysis is an analysis method for technical products and processes.
A central element of this method is the shared understanding of tasks, problems, and solutions within the team. This can be supported by illustrations of any kind, but at its core, it is about expressing these tasks, problems, and solutions in language.
Language is an incredibly powerful tool that we humans have learned to use to communicate and pass on our knowledge to others. In written form, the factor of time has also become irrelevant, as writing things down allows us to reread the written content at any later point in time.
Prerequisite: What has been written down is composed in such a way that it is understandable and unambiguous.
Therefore, tip #1: Write down the statements from the FMEA team and ask specifically whether the wording is correct and clearly understandable for everyone.
In FMEA moderation, a development task is broken down (structural analysis). Tasks are described for the structural elements (functions, requirements, characteristics). One or, in most cases, several possible cases of non-compliance (errors) are formulated for these tasks. According to the method at the lowest level, the cause level, measures for avoidance and detection are compiled.
These different building blocks of FMEA require different linguistic formulations and schemata.
My assertion: in a well-written FMEA, the wording of the description, possibly supplemented by comments, clearly indicates whether it is a system element, a function, an error, or one of the types of actions.
Let’s briefly go through the node elements of FMEA and their typical formulation characteristics:
Title of the FMEA:
Here, it should be clearly recognizable what type of FMEA it is and what the development object is. Under certain circumstances, it may also be useful to mention the development status, e.g., if a different FMEA is used for prototype construction than for pre-series and series production.
System elements:
System elements are linguistically uncritical. They clearly designate the part of product development that is to be considered here or the step in the process.
At the cause level, the system elements should serve as a sorting aid. In design FMEA, where work is carried out on the drawing until the product features are defined, I would consider “geometry”, “surface”, “material”, and “process requirements from the design” to be useful categories in the development of a mechanical component. In a manufacturing process, the four categories “machine/plant/tool”, “human”, “material”, and “environment” are crucial. There are also colleagues who simply overwrite a system element at the lowest level with “causes” and do not use any division into categories.
Tasks = Functions:
The term used for tasks in the FMEA methodology is “function.”
I find the term “function” somewhat difficult to understand, especially in its often ambiguous use. There are different approaches to describing tasks, as well as differences between FMEA types in the standards.
This is naturally also reflected in the wording used to describe the tasks.
A common guideline states: The function is formed by a noun and a verb.
This is usually not wrong, but in my opinion it is not sufficient to correctly describe tasks in the FMEA.
First, two questions arise:
and
First, let’s address the first question.
In my experience, it makes a big difference whether we describe what a product or process step should be able to do (function), whether we describe a supplementary requirement that must be taken into account as a boundary condition during development, or whether we talk about specific characteristics.
When it comes to what a product or process should be able to do, question 2 is central to the formulation.
We can understand the function as a “path to the goal.” This corresponds to the mathematical concept of a function. In mathematics, a function is the description of how an input variable is converted into an output variable.
The output variable Y = function of X and the function is given by Y= 2.7 – 3X + 0.5 X2
This functional term is followed by phrases that are primarily used in design FMEA to describe physical and technical tasks in the product:
The reduction gear converts a high speed into a low speed and a low torque into a high torque.
In this sentence, the orange word takes on the designation of the system element, which is helpful for understanding the function more easily, but is not absolutely necessary due to the assignment of the function to the system element.
The red words speed and torque are the actual objects of the function. And the verb “convert” explains the physical process.
This undoubtedly describes what this reduction gear is used for.
However, this function does not describe which state would satisfy the customer. There are two possible ways to do this: The first option assigns additional information to the function. This information is referred to as “requirements,” “specifications,” or “parameters” and specifies the development task. This also invokes additional boundary conditions that must be taken into account in the development.
Examples:
The reduction gear must achieve an efficiency of >90% during conversion.
The design must be suitable for maximum speed at the input and maximum torque at the output.
The reduction gear must be designed for operation with one maintenance per year over 20 years.
The gear must be able to operate in a temperature range from -40°C to +95°C, regardless of humidity.
The list of requirements can be expanded further.
Only with these specifications is it possible to highlight the difference to existing devices and clarify the actual development task.
Perhaps the gearbox should perform exactly the same as its predecessor, but with 15% less weight – a challenge.
The FMEA standards specify another important criterion for functions: functions must be rateabel.
The reason is simple: in the next step of the FMEA analysis, failures = deviations from the required function are to be described. However, an failure can only be detected if an rateable property is not fulfilled or is insufficiently fulfilled. How can we derive failures if we do not precisely express what the target is, what the requirement is?
If we look at the function of the reduction gear above, it is difficult to impossible to derive a deviation from this generic function – apart from “cannot convert”. But this fundamental negation of the function does not provide any insight for the risk analysis of this product.
With the requirement of rateability, I come to the conclusion that a function should not describe the path to the goal, but rather the desired development result.
I can then assess this state and systematically and logically derive deviations, failures from it.
The reduction gear permanently converts speed and torque at a ratio of 1:3.5 up to an input speed of 3000 rpm and up to an output torque of 200 Nm.
This functional description is more concrete and rateable because essential specifications (not all of them here) have been included in the formulation.
It is a question of style, not content, whether further conditions are mentioned as additional functions or as supplementary parameters or specifications.
The reduction gear converts speed and torque with an efficiency of >90%.
The only important thing is that the “functions” package contains the development targets. And this requirement then applies to the functions at all levels, from the higher-level integration of the gearbox into a larger system to the details at the characteristic level.
For the difference between function, requirement and characteristic I will provide a further blog post at a later point of time.
It becomes easier when formulating the cause or characteristic level: a characteristic with its boundary conditions does not require a verb. What has proven to be important for the readability of the FMEA is the inclusion of task or location designations.
If there are 25 similar but functionally different screw connections in the product or process, then groups should be formed and the function texts clearly distinguished according to their function.
Hence my tip #2: Formulate the function or requirement as a state to be achieved. This should also affect the tense used:
“Execute function” describes an activity. “Function is executed” describes a state. Leave the activities to the actions and formulate something that can be evaluated.
Failure Modes
According to FMEA theory, failures are deviations that can occur for a function. They do not have to occur, but it is neither impossible nor completely unlikely.
The text of the failure, regardless of the FMEA level, therefore describes a deviation.
Such deviations can be very similar. Therefore, in my opinion, it is imperative to find a unique error description for the detail currently being considered.
There are companies and fellow moderators who like to refer to error catalogs.
In my experience, however, this is an inadmissible generalization, similar to a function that is only entered generically without specification.
If there is an accurate and appropriate text available as a template, there is of course no reason not to use it. But if you observe the same error five times, then it is either really the identical error and does not need to be written down five times, but only linked sensibly in the error network, or there are five different error cases, which must then also be distinguishable. Otherwise, you will not be able to make meaningful distinctions based on consequences and causes, which is again an inadmissible generalization.
How should a failure mode be formulated?
First, the text of the failure mode must clearly refer to the function.
Then there are different failure cases in the Design FMEA. The AIAG-VDA-FMEA manual distinguishes between 7 basic types of design failures. Not all 7 need to be relevant. But more than one usually is. For example, a meaningful distinction can be made between total failure, non-function, or functional limitation due to functional reduction/degradation in mechanical systems.
Source: AIAG-VDA FMEA Manual (2019) chapter 2.4.2 (DE version)
It also makes a significant difference in the wording of the failure mode whether it is a design FMEA (design, system, MSR, machine FMEA) or a process FMEA.
Tip #3: In design, the task is to redesign and define something. Therefore, an error in design can only mean that something has been defined as “not,” “insufficient,” “not functional,” or “not manufacturable.”
In the process, the task is to implement a specification in production and manufacture within the tolerance. Therefore, a product characteristic or process parameter “out of tolerance” is a meaningful failure description.
Actions
In our FMEA, the linguistic design of actions still needs to be considered.
However, this topic deserves its own blog post.
Conclusions:
Stay curious
Uwe Jarosch