Produktfunktion

Kurz erklärt

Die Produktfunktion ist das Herzstück der Design-FMEA. Sie beschreibt präzise, welches Leistungsvermögen ein Bauteil oder System erbringen muss, um die Anforderungen des Lastenhefts zu erfüllen. Durch die explizite Definition des Soll-Zustands mittels aktivem Verb und Subjekt wird die methodische Grundlage geschaffen, um Fehlfunktionen (den Ist-Zustand) logisch abzuleiten. Sie dient als Filter, um Designanforderungen von der bloßen Spezifikation in einen funktionalen Kontext zu überführen und bildet damit die Basis für die Risikobewertung nach dem VDA/AIAG-Standard. Ohne eine fundierte Produktfunktion ist die gesamte nachgelagerte Fehleranalyse abstrakt und für den Ingenieur unbrauchbar.

Definition

Eine Produktfunktion ist die systematische, zweckgerichtete verbale Repräsentation einer Leistungsanforderung an ein Strukturelement innerhalb eines technischen Systems. Fachlich korrekt formuliert, besteht sie zwingend aus einer Kombination von einem aktiven Verb, das die beabsichtigte technische Tätigkeit definiert (z. B. „kühlen“, „abdichten“, „übertragen“, „fixieren“), und einem Subjekt, welches das physikalische Merkmal oder Medium benennt, auf das sich die Funktion bezieht (z. B. „Kühlmittel leiten“). Die Definition erfolgt im Rahmen des dritten Schritts der VDA/AIAG-FMEA-Methodik und dient als methodischer Abgrenzungspunkt zwischen dem (physikalisch beschriebenen) Was und dem (technisch umgesetzten) Wie. Sie übersetzt komplexe Lastenheftanforderungen in eine technisch eindeutige Sprache, die als logischer Ankerpunkt für die Identifikation potenzieller Fehlerarten dient. Eine gültige Produktfunktion muss messbar oder technisch verifizierbar sein, um bei einer Abweichung das „Nicht-Erfüllen“ als Fehlerart (Failure Mode) identifizieren zu können. Die Abgrenzung ist hierbei zentral: Während die Anforderung den Grenzwert (z.B. Temperatur < 90°C) angibt, beschreibt die Funktion den Prozess (z.B. Wärme abführen).

Bedeutung im Fachkontext

Im Kontext des Qualitäts- und Systems-Engineering bildet die Produktfunktion das entscheidende Bindeglied zwischen der Systemarchitektur und der Risikoanalyse. Sie fungiert als operative Übersetzungsschicht, die geometrische CAD-Modelle und abstrakte Lastenhefte in eine funktionale Logik überführt. Im siebenschrittigen FMEA-Prozess nach VDA/AIAG verankert, sorgt sie dafür, dass die Fehleranalyse nicht auf einer rein spekulativen Basis erfolgt, sondern auf der Unfähigkeit des Systems basiert, seine definierte Funktion zu erfüllen. Dies ermöglicht eine strukturierte Rückverfolgbarkeit (Traceability): Vom Kundenwunsch über die Produktfunktion bis hin zur messtechnischen Überprüfung. Damit verhindert sie das Entstehen von „Funktions-Lücken“ in der Design-Phase, in denen Wechselwirkungen zwischen Schnittstellen oder Nebenfunktionen oft übersehen werden.

Input, Verarbeitung, Output, Outcome, Impact

Schritte der Methode in Übersicht

Der FMEA-Prozess umfasst sieben Schritte: 1. Planung, 2. Strukturanalyse, 3. Funktionsanalyse, 4. Fehleranalyse, 5. Risikoanalyse, 6. Optimierung, 7. Ergebnisdokumentation. Diese Schritte bilden einen sequenziellen, aber iterativen Prozess.

Beschreibung der Einzelschritte mit Ziel & Vorgehen

1. Planung: Ziel ist die Abgrenzung des Analyseobjekts. Vorgehen: Definition des Systemumfangs anhand von Lastenheften. Qualität: Vollständigkeit der erfassten Anforderungen. ### 2. Strukturanalyse: Ziel ist die Visualisierung der Hierarchie. Vorgehen: Zerlegung in System-Strukturbaum. Qualität: Konsistente Abbildung der Schnittstellen. ### 3. Funktionsanalyse: Ziel ist die Definition der Soll-Leistung. Vorgehen: Formulierung mittels Verb-Subjekt-Logik. Qualität: Eindeutigkeit der Funktionen. ### 4. Fehleranalyse: Ziel ist die Risiko-Identifikation. Vorgehen: Ableitung von Fehlern aus Funktionsversagen. Qualität: Logische Konsistenz der Fehlerkette. ### 5. Risikoanalyse: Ziel ist die Bewertung. Vorgehen: Bestimmung von S, O, D Werten. Qualität: Datenbasierte Plausibilität. ### 6. Optimierung: Ziel ist die Risikominimierung. Vorgehen: Implementierung präventiver Maßnahmen. Qualität: Nachweis der Wirksamkeit. ### 7. Ergebnisdokumentation: Ziel ist die Wissenssicherung. Vorgehen: Reporting und Stakeholder-Kommunikation. Qualität: Nachvollziehbarkeit für Folgeprojekte.

Anwendung und Vorgehen

Die operative Umsetzung der Funktionsanalyse folgt einem methodisch stringenten Ablauf, der den Kern des VDA/AIAG-Standards bildet. Nach Abschluss der Strukturanalyse, bei der das Produkt in ein logisches System von Bauteilen und Subsystemen zerlegt wurde, beginnt die eigentliche Funktionszuweisung.

Systematische Vorgehensweise:

1. Funktionale Zuordnung: Für jedes Element im Strukturbaum (System, Subsystem, Komponente) werden die spezifischen Funktionen definiert. Hierbei wird „von oben nach unten“ (Top-Down) vorgegangen: Was muss das Gesamtsystem leisten, und welche Teilfunktionen müssen die einzelnen Komponenten beisteuern, um dieses Ziel zu erreichen?
2. Die Verb-Subjekt-Logik: Jede Funktion wird nach dem Schema [Aktives Verb] + [Subjekt/Medium] formuliert. Ein Beispiel für ein Kühlsystem wäre: „Kühlmittel (Subjekt) zirkulieren (Verb)“ oder „Wärme (Subjekt) abführen (Verb)“. Vermeiden Sie qualitative Adjektive wie „schnell“ oder „zuverlässig“; diese gehören in die Spezifikationsdokumente (Requirements), nicht in die Funktionsbeschreibung selbst.
3. Schnittstellen-Betrachtung: Besondere Aufmerksamkeit gilt den Übergängen. Funktionen müssen nicht nur innerhalb eines Bauteils definiert werden, sondern auch an den Schnittstellen zu angrenzenden Elementen. „Drehmoment übertragen“ beschreibt die Funktion an der Schnittstelle zwischen Welle und Zahnrad.
4. Verknüpfung im Funktionsnetz: Die Funktionen werden in einem sogenannten Funktionsnetz miteinander verknüpft. Damit wird sichtbar, welche Funktion eine übergeordnete Funktion (z. B. „Fahrzeug beschleunigen“) erst ermöglicht.

Dieses Vorgehen transformiert statische CAD-Daten in ein dynamisches Wirkmodell, das als verlässliche Basis für die anschließende Fehleranalyse dient.

Anwendungsgebiete

Die Methode der Funktionsanalyse ist branchenunabhängig, findet jedoch in hochkomplexen Umgebungen ihre kritische Anwendung:

• Automotive Engineering: Hier ist die Design-FMEA gemäß VDA/AIAG Standard. Typische Anwendungen sind Antriebsstränge, Bremssysteme oder Fahrerassistenzsysteme (ADAS). Die Funktionsanalyse stellt sicher, dass beispielsweise ein Sensor nicht nur „Signale sendet“, sondern „Abstandswerte mit definierter Frequenz übermittelt“.
• Medizintechnik: Entsprechend der ISO 14971 ist die funktionale Definition essenziell für das Risikomanagement. Bei einem Infusionsgerät definiert die Produktfunktion den präzisen Durchfluss; jede Abweichung von dieser Funktion wird als potenzielles Patientenrisiko (Failure Mode) eingestuft.
• Systemarchitektur in der Elektronik: Bei der Entwicklung komplexer Steuergeräte (ECUs) hilft die Funktionsanalyse, zwischen Hardware- und Software-Funktionen zu differenzieren. So kann „Datenpakete verarbeiten“ als funktionale Anforderung an den Prozessor klar von „Gehäuse kühlen“ abgegrenzt werden.
• Fertigungs- und Prozessplanung (PFMEA): Auch wenn es um Produktionsprozesse geht, wird die Funktionslogik genutzt. Statt „Bauteil prüfen“ wird die Funktion präzisiert zu „Merkmalsgeometrie innerhalb der Toleranzgrenzen verifizieren“.

Typische Fehler und Missverständnisse

In der Praxis führt die unsaubere Formulierung von Produktfunktionen oft dazu, dass die FMEA ihre Wirksamkeit verliert.

• Verwechslung von Funktion und Anforderung: Dies ist der häufigste Fehler. Eine Anforderung ist: „Die Dichtung muss einem Druck von 10 bar standhalten.“ Die Funktion hingegen ist nur: „Druck halten“. Das „Wie gut“ (die 10 bar) ist ein Attribut, das in der Fehleranalyse bei der Bestimmung des Failure Modes (z. B. „Druckverlust bei < 10 bar“) wichtig wird, aber nicht in den Funktionsnamen gehört.
• Fail-Formulierungen als Funktionen: Formulierungen wie „Vermeidung von Überhitzung“ sind keine Funktionen, sondern Ziele einer Präventionsmaßnahme. Die korrekte Funktion lautet stattdessen „Wärme ableiten“.
• Zu geringer Granularitätsgrad: Wenn Funktionen zu global definiert werden (z. B. „Auto bewegen“ für ein ganzes Fahrzeug), lassen sich daraus keine spezifischen Fehler ableiten. Jede Ebene im Strukturbaum benötigt ihre spezifischen Funktionen.
• Ignorieren von Nebenfunktionen: Oft werden nur die Hauptfunktionen definiert. Dabei führen gerade Nebenfunktionen (z. B. „Geräusche dämpfen“ oder „Vibrationen entkoppeln“) bei Versagen oft zu massiven Kundenbeschwerden.

Abgrenzung und Grenzen

Die Produktfunktion ist ein mächtiges Werkzeug, hat jedoch definierte Grenzen:

• Kein Ersatz für Sicherheitsanalysen: Die FMEA und damit die Funktionsanalyse beschreiben, was das Produkt tun soll. Eine funktionale Sicherheitsanalyse (z. B. ISO 26262 für ASIL-Einstufungen) geht tiefer in die Wahrscheinlichkeit und Beherrschbarkeit katastrophaler Ausfälle ein. Die FMEA liefert den Input, ist aber keine Ersatz-Methodik.
• Das „Was“ nicht das „Wie“: Die FMEA-Funktionsanalyse beschreibt die Absicht. Wie das Design technisch realisiert wird (z. B. durch eine Schraubverbindung oder eine Schweißnaht), wird im Strukturbaum und in der Detaillierung der Maßnahmen definiert. Wer versucht, das „Wie“ bereits in die Funktionsbeschreibung zu schreiben, erstickt die Kreativität der Design-Phase.
• Komplexitätsgrenze: Bei hochgradig vernetzten Software-Systemen stoßen manuelle Funktionsnetze an ihre Grenzen. Hier ist eine modellbasierte Systementwicklung (MBSE) in Kombination mit FMEA notwendig, um die Konsistenz über tausende Schnittstellen hinweg zu wahren.