FMEA für Software-Umfänge
1. Zielsetzung (Warum?)
Anforderungsvalidierung und -optimimierung mit Unterstützung der FMEA
Das Modellieren von Funktionsnetzen im Rahmen der Entwicklung von FMEA ist entscheidend für:
- Erlangung eines umfassenden Systemverständnisses
- systematisches Identifizieren von Fehler- ursachen, -arten und -zusammenhängen im Fortgang der FMEA-Analysearbeit
Voraussetzungen für das zielführende Modellieren von Funktionsnetzen sind:
- kennen und Verstehen der Marktforderungen ("Stimme des Kunden")
- Entwicklung von verifizierbaren Vorgaben an den Designprozess (z. B. durch Lasten- und Pflichtenheft)
Soweit Softwareumfänge Gegenstand von FMEA sind, ist es wahrscheinlich, dass die Experten einen Weg einschlagen, der dazu führt, dass die für vielerlei nützlichen Signalpfade die Basis der FMEA-Funktionsanalyse bilden.
Der Modellierung von Signalpfaden in Form von Funktionsnetzen können bei FMEA-Entwicklungen Unsicherheiten, Inkonsistenzen und im Sinne der FMEA nicht zielführende hervorrufen.
Begründung:
Die Abbildung des Signalpfades als Funktionsnetz visualisiert nur einen Fehler des gesamten Signalpfades.
Zielsetzung der FMEA ist aber den Fehler und die zugeordneten Ursachen am Ursprungsort zu finden und dort effizient und effektiv zu vermeiden. Exakt dieses leistet ein Funktionsnetz für einen SW Umfang auf Basis des Signalpfades NICHT! Das Beispiel einer Reihenschaltung von n Heizkörpern (HK) belegt diese These nachvollziehbar:
Funktioniert der erste Heizkörper nicht, da der Durchfluss des Heizmediums behindert ist, kann der zweite Heizkörper seine Funktion "Wärme durch Konvektion und Strahlung an Umgebung abgeben" nicht leisten, obwohl er:
- keine Ursache zu dieser Fehlfunktion beisteuert und
- keinen Fehler besitzt / vollständig funktionsfähig ist.
Vermeidungs- und Entdeckungsmaßnahmen (z. B. anderes Design für Heizkörper) wäre teuer und unnötig!
2. Vorgehensweise (Wie?)
Daher geben wir folgende Empfehlungen:
Soweit signalpfadbasierte Funktionsnetze für das Systemverständnis oder andere Aufgaben gewünscht werden, modellieren Sie diese nach den aus der FMEA bekannten Darstellungen. Die Arbeitsergebnisse können einen Wert an sich darstellen.
Entwickeln Sie aus dieser Art von Netzen eher keine FMEA weiter mit der Negierung der Funktionen, Fehlernetzen usw.
Begründung:
- für die Systemfunktion "Wärme durch Konvektion und Strahlung an Umgebung abgeben" werden in einer Reihenschaltung die Funktionen des HK1 bis HK n benötigt
- verstehen Sie in diesem Kontext Funktionen als "UND-Verknüpfungen"
- es werden also die Funktionen des HK1 und HK2 und HKn zur Erfüllung der Gesamtfunktion benötig
- verstehen Sie in diesem Kontext Fehlerarten als "ODER-Verknüpfungen": Der Fehler "keine oder zu geringe Wärme durch Konvektion und Strahlung an Umgebung abgeben" ensteht durch Fehler des HK1 oder des HK2 oder des HKn.
Hier erkennen Sie wie wichtig es ist, den Ursprung des Fehlers zu entdecken, da die Fehlfunktion: "... keine Wärme ..." nicht aus einem Fehler des HKn kommt.
Erläuterne Definition
- Eine "Fehlfunktion" des Analyseobjekties liegt vor, wenn die beabsichtigte Funktion (Output) außerhalb des tolerierten Zielwertes liegt und die Ursache in der fehlerhaften Wandlung der Eingangsgrößen (Input) liegt. (Abb. 1)
- Es liegt keine Fehlfunktion des Analyseobjektes vor, wenn die beabsichtigte Funktion (Output) außerhalb des tolerierten Zielwertes und die Ursache in dem fehlerhaften Input des Analyseobjektes liegt. (Abb. 2)
Beispiele:
Prinzipdarstellung Blockdiagramm:
Beispiel: Um eine bestimmte Funktion in Teilsystem 2 zu erfüllen, benötigen Sie
in 3.1: Funktion B (Signal zu 3.2)
und 3.2: Funktion A (zu 2.2)
und 2.2: Funktion B (zu Ausgang)
Wichtig: Es werden immer nur die Ausgangssignale betrachtet.
Das Eingangssignal an 2.2 entspricht dem Ausgangssignal an 3.2. Dementsprechend ist 3.2 für die Richtigkeit des Ausgangssignals verantwortlich.
Prinzipdarstellung Systemstruktur (Abb. 3)
Systemstruktur mit Funktionen (Horizontale): Richtung der Funktionsnetze in der FMEA
90-Grad versetzte Signalpfade (Vertikale): Richtung der Signalpfade (nicht grundsätzlich geeignet für FMEA)
Prinzipdarstellung (Abb. 4)
Systemstruktur mit Funktionen (Horizontale): Richtung der Funktionsnetze in der FMEA
90-Grad versetzten Signalpfade (Vertikale): Richtung der Signalpfade (nicht grundsätzliche geeignet für FMEA)
Hinweise:
- Bei der Fehlerbetrachtung eines Systemelements wird immer von i.O. Eingangsgrößen ausgegangen. Die FMEA will die Fehler am Ursprungsort entdecken, also die Fehler die im Systemelement selbst verursacht werden.
- Kann in der Praxis die Richtigkeit des Eingangssignals nicht garantieren werden, dann bekommt das empfangende Systemelement die zusätzliche Funktion: "Plausibilisiere das Eingangssignal". Diese weitere Funktionalität hat nichts mit dem Signalverlauf zu tun, muss aber selbst dann auch wieder auf Fehlermöglichkeiten hin untersucht werden.
Dazu muss das empfangende Systemelement aber „wissen“, dass das Ausgangssignal des sendenden Systemelementes unsicher ist. Hier erlauben wir uns den Hinweis auf die Wichtigkeit der Abstimmung von Schnittstellen im Besonderen, wenn an der Erfüllung der Gesamtfunktionalität zwei oder mehr Zulieferer beteiligt sind.
Oftmals werden dabei von jedem Zulieferer zwar die Anforderung zum Kunden hin erfüllt, die gegenseitigen Anforderungen aber nicht überprüft.
- Die funktionale Abstimmung der Schnittstellen ist entscheidend. Besonders, wenn zur Erfüllung der Gesamtfunktionalität zwei oder mehr Zulieferer beteiligt sind.Oftmals werden dabei von jedem Zulieferer zwar die Anforderung zum Kunden hin erfüllt, die wechselseitigen Anforderungen der Systemelemente aber nicht überprüft.
- Es wird das Gedankenmodell empfohlen, dem Sender die „Verantwortung“ zuzuordnen. Einerseits muss dieser ein i. O. Signal garantieren, oder er ist verpflichtet den Empfänger über mögliche Unsicherheiten zu informieren.
3. Ergebnis
In einer im Sinne der Methode und der Unternehmensziele korrekt aufgebauten FMEA (Fehler kostengünstig am Ursprungsort vermeiden), entsprechen die Funktionsebenen exakt den Systemebenen.
Die FMEA ist nicht geeignet, Signalabläufe darzustellen, und auch nicht dafür gedacht.
Es ist jedem selbst überlassen, ob er dieses trotz alledem in einer FMEA-Software abbilden möchte. Daraus allerdings dann eine FMEA abzuleiten halten wir für nicht zielführend.