Failure Mode and Effect Analysis

MSR-Teilprojekt MEDOC

Failure Mode and Effect Analysis
Strukturelle Grundlagen der MSRFMEA DTD
[ msrfm-sp]
Version: 1.6
Dieses Dokument beschreibt die Strukturellen Grundlagen für die Ablage von FMEA-Daten in SGML mit Hilfe der msrfmea.dtd. Diese Strukturen entsprechen der einer System-FMEA.
Das Dokument beschreibt Anforderungen und Einsatzszenarien der msrfmea.dtd. Es werden Kenntnisse der FMEA-Methodik vorausgesetzt.


1. Einführung

Failure Mode and Effect Analysis
1. Einführung

FMEA ist eine systematische Vorgehensweise zur Identifikation von Fehlerquellen und Fehlerwirkungsketten. Dieses Verfahren ist für verschiedene Bereiche (Geräte, Systeme, Software, aber auch für Abläufe und Prozesse) anwendbar.
Abbildung 1: Übersicht über die systematische FMEA
Die prinzipielle Vorgehensweise ist [image] :
  • Die betrachtete Domäne wird hierarchisch strukturiert (<fm-structure>), wobei die Struktur aus Strukturelementen <fm-structure-element> aufgebaut wird (s. Systemstruktur in einer FMEA). Jedes Strukturelement wird schrittweise verfeinert, d.h. in Unterstrukturen zerlegt (<fm-se-decomposition>).
  • Gleichzeitig wird jedem Strukturelement eine Menge von Funktionen/Merkmale [image] (<fm-se-functions>) zugeordnet (s. Funktionen an Strukturelementen).
  • Die funktionalen Zusammenhänge werden in einem Funktionsnetz (Funktionsnetz) dargestellt. Dieses Netz entsteht durch Verknüpfen der den Strukturelementen zugeordneten Funktionen. Für jede Funktion werden die Voraussetzungen (ebenfalls Funktionen) erfasst, unter denen die Funktion korrekt arbeitet (<fm-prerequisites>).
  • Den Funktionen werden ihre Fehlfunktionen (<fm-fault>) zugeordnet. Durch die Verknüpfung von Fehlfunktionen (Fehlernetz) zu Ursachen (<fm-causes>) entstehen Fehlernetze (vgl. Fehlernetz im Formblatt).
  • Die Fehlfunktionen werden hinsichtlich ihrer Auswirkung (<fm-significance>) sowie der möglichen Maßnahmen zur Entdeckung (<fm-detection-tasks>), Vermeidung (<fm-counter-tasks>) bzw. Schadensbegrenzung (<fm-limitation-tasks>) untersucht und mit einem Risikoprioritätsfaktor (<risc-priority-factor>) bewertet.
  • Das Ergebnis der FMEA wird in einem Formblatt dargestellt (Formblatt komplett bearbeitet).
Abbildung 2: Systemstruktur in einer FMEA
Abbildung 3: Funktionen an Strukturelementen
Abbildung 4: Funktionsnetz
Abbildung 5: Fehlfunktionen
Abbildung 6: Fehlernetz
Abbildung 7: Fehlernetz im Formblatt
Abbildung 8: Formblatt komplett bearbeitet
Die Abbildung der FMEA-Methodik auf die msrfmea.dtd entspricht folgender Verweishierarchie:
Struktur
  !
  +->Strukturelement
      !
      +->Strukturelement ...
      !
      +->Funktion (typisierbar)
           !
           +->Fehlfunktion
                !
                +->Maßnahmenpakete
                    !
                    +->Maßnahmenbündel
                         !
                         +->Aktionen

In Prozeß-FMEAs spricht man von eher von Merkmalen als von Funktionen
Zum besseren Verständnis der Zusammenhänge von Methode und DTD werden schon hier die SGML-Elemente angegeben.


2. Ziele der MSRFMEA.DTD

Failure Mode and Effect Analysis
2. Ziele der MSRFMEA.DTD

Die FMEA ist ein Baustein in der System-Entwicklung. Die DTD wurde entwickelt, um die spezifischen FMEA-Werkzeugen erfassten Daten in anderen Entwicklungsschritten verwenden zu können. Dazu gehören beispielsweise:
  • Aufbau von Standards (Katalogen, Bibliotheken)
  • Terminverfolgung
  • FMEA-übergreifende Auswertungen
  • Langfristige Datenhaltung (Archivierung)
  • Generierung von Prüfabläufen aus FMEA
  • Datenaustausch mit anderen Systemen (z.B. CAD, CASE, QFD)


2.1. Prozeßmodelle füdie DTD

2.1. Prozeßmodelle für die DTD

Die folgenden Use Cases wurden beim Entwurf der DTD betrachtet.


2.1.1. Hinzuladen von Maßnahmen bzw. Funktionskatalogen

In eine bestehende oder neu aufzubauende FMEA sollen Maßnahmen bzw. Funktionskataloge hinzugeladen werden:
  • Die DTD kann teilweise bedatet werden, d.h. es ist möglich, Maßnahmen ohne Strukturelemente zu transportieren. Daher enthält die DTD auch keine Rückverzeigerung (z.B. von Funktionen auf Strukturelemente).
  • Für die Identifizierung der Objekte müssen IDs vergeben werden. Im Konfliktfall kann ein lesendes System neue IDs vergeben und die vorgefundenen IDS unter Angabe des ursprünglichen Werkzeuges ablegen (<fm-idtables>.)


2.1.2. Manipulation der FMEA mit anderen Werkzeugen

In diesem Szenario wird die FMEA exportiert, mit anderen Werkzeugen manipuliert, und wieder importiert. Beispiel für diese Anwendung ist das Hinzufügen weitere Sprachvarianten durch ein externes Übersetzungsbüro.
  • Die Objekt-ID kann zur Resynchronisation verwendet werden, darf daher nicht extern manipuliert werden. Es gibt keine Einschränkungen hinsichtlich Änderungen, solange IDs nicht betroffen sind. ID-Änderungen unterbrechen die Prozeßkette.
  • Im Fall nicht strukturverändernder Manipulation sind die Auswirkungen bekannt, so daß der Ereignisraum begrenzt wird. Es brauchen z.B. keine Löschungen von Objekten behandelt zu werden.


2.1.3. FMEA-Erstellung auf Basis von Engineering-Tool Daten

In diesem Szenario wird in FMEA-Tool eine Datenanreicherung vorgenommen. Die Komponenten/Funktionsstruktur kommt aus dem Entwicklungswerkzeug z.B. durch Auswertung von Instanzen der MSRSYS.DTD.
Hierbei ist problematisch, wenn im Engineering-Tool im Rahmen der Weiterentwicklung eine Strukturveränderung stattfindet. Es erfolgt die Synchronisation mit ID´s, wobei folgende Fälle zu betrachten sind:
neue ID Objekt ist neu entstanden

fehlende ID Objekt ist gelöscht

ID bereits vorhanden Es muß geprüft werden, ob das Objekt sich geändert hat.

Dieser Fall kann ggf. durch Synchronisation mit Änderungsdatum unterstützt werden. Dafür wird das Attribut [t] vorgesehen, welches Zeitstempel aufnehmen kann.


2.1.4. Wiederherstellen einer FMEA aus der SGML-Instanz

In diesem Szenario wird die FMEA nach SGML exportiert und zu einem späteren Zeitpunkt wieder hergestellt. Es ist allerdings nicht notwendig die im FMEA-tool abgelegten Verwaltungsdaten (z.B. Historie) wieder herzustellen. Das Wiedereinlesen einer SGML-Datei entspricht einer "automatisierten Neueingabe".


2.1.5. Modularisierung

Modularisierung von FMEAs ist methodisch noch in der Diskussion und wird daher beim ersten Schritt nicht priorisiert betrachtet. Schnittstellendefinition (<fm-interface>) werden jedoch aufgenommen, um Erfahrungen gewinnen zu können.


3. Beschreibung der DTD

Failure Mode and Effect Analysis
3. Beschreibung der DTD

Inhalt dieses Kapitels:
  • 3.1. Grobstruktur der DTD
  • 3.2. Abbildung der FMEA-Methodik auf die DTD
  • 3.3. Strukturelle Besonderheiten


3.1. Grobstruktur der DTD

Die grobe Struktur der DTD ist in Grobstruktur der DTD dargestellt. Sie folgt im wesentlichen der Reihenfolge einer systematischen FMEA (vgl. Übersicht über die systematische FMEA).
Abbildung 9: Grobstruktur der DTD
Die Bedeutung der Elemente auf oberster Ebene ist:
<short-name> Dieser dient zur identifikation der SGML-Datei, insbesondere bei dokumentübergreifenden Verweisen. Es kann z.B. die Kurzbezeichung eines Produktes (z.B. LLR) verwendet werden. Ein Exportfilter könnte hier auch den Basisnamen der Datei verwenden.

<admin-data> Dies dient zur Aufnahme von Verwaltungsinformationen.

<fm-head> Dies enthält die am Projekt beteiligten Firmen (<companies>) sowie Informationen zu den beteiligten FMEA-Teams (<fm-teams>). Weitere Einzelheiten finden sich in 3.2.7. Teamverwaltung.

<fm-tool-data> Dient zur Aufnahme werkzeugspezifischer Informationen, insbesondere hinsichtlich der ID-Verwaltung (3.3.2. Unterstützung von Tool-Besonderheiten). In <misc-data> innerhalb von <fm-tool> kann ein Werkzeug private Daten hinterlegen, z.B. um einen optimierten Wiederimport zu gewährleisten.

<fm-structures> Hier werden Strukturen des Systems bzw. des Prozesses hinterlegt (vgl. 3.2.1. Systemstruktur). Über <fm-structure-root> findet man den Einstieg in den Strukturbaum.

<fm-structure-elements> Hier werden die Einzelkomponenten des Systems beschrieben (vgl. 3.2.1.1. Strukturelemente). An den Strukturelementen hängen die entsprechenden Funktionen (<fm-se-functions>). An den so referenzierten Funktionen hängen wiederum die Fehlfunktionen.

<fm-functions> Dies ist der Pool sämtlicher im System vorhandener Funktionen (strukturübergreifend). Diese werden dann aus den Strukturelementen heraus referenziert (weitere Einzelheiten siehe 3.2.2. Funktionen).

<fm-faults> Dies ist der Pool sämtlicher Fehler, die im System auftreten können. Diese werden aus den Funktionen heraus referenziert (weitere Einzelheiten siehe 3.2.3. Fehlfunktionen).

Die DTD erlaubt es, daß ein Fehler in mehreren Funktionen referenziert wird. Es wird aber empfohlen, dies nicht zu nutzen, da keine verwendungsspezifischen Eigenschaften angegeben werden können.
<fm-actions> Dies ist der Pool sämglicher Maßnahmen, die im System auftreten können. Diese werden aus den Fehlern heraus referenziert.

Die DTD erlaubt es, daß eine Maßnahme in mehreren Fehlern referenziert wird. Es wird aber empfohlen, dies nicht zu nutzen, da keine verwendungsspezifischen Eigenschaften angegeben werden können.
<fm-function-types> Dies enthält die im System vorhandenen Funktionstypen (vgl.3.3.1. Hierarchisierte Typen)

<fm-fault-types> Dies enthält die im System vorhandenen Fehlfunktionstypen (vgl.3.3.1. Hierarchisierte Typen)

<fm-action-types> Dies enthält die im System vorhandenen Maßnahmentypen (vgl.3.3.1. Hierarchisierte Typen)

<locs> Dies enthält die Elemente zur dokumentübergreifenden Referenzierung.


3.2. Abbildung der FMEA-Methodik auf die DTD

Inhalt dieses Kapitels:
  • 3.2.1. Systemstruktur
  • 3.2.2. Funktionen
  • 3.2.3. Fehlfunktionen
  • 3.2.4. Risikoprioriätszahl
  • 3.2.5. Behandlung von Maßnahmen
  • 3.2.6. Behandlung von Aktionen
  • 3.2.7. Teamverwaltung


3.2.1. Systemstruktur

Die Systemstruktur entsteht dadurch, daß aus Strukturelementen in <fm-se-decomposition> wiederum auf Strukturelemente verwiesen wird.
Dabei ist zu beachten:
  • Dabei sind direkte oder indirekte Rekusionen nicht erlaubt.
  • Die DTD erlaubt die mehrfache Verwendung (Referenzierung) von Strukturelementen. Das ist methodisch jedoch nicht vollständig definiert (insbesondere deshalb, weil das Funktionsnetz vom Strukturbaum unabhängig ist). Zunächst wird daher empfohlen, eine mehrfache Verwendung zu vermeiden. Eine künftige Version der DTD wird ggf. über Typ- und Vererbungskonzepte eine bessere Unterstützung bieten.
Abbildung 10: Strukturen
Folgende Informationen über eine Struktur werden angelegt:
<fm-structure-class> Hier wird der "typ" der FMEA abgelegt. Beispielhafte Werte sind

design | für "Konstruktions-FMEA"
system | für "System-FMEA"
process | für "Prozeß-FMEA"
<fm-structure-owner> Verweist auf ein Team-Member. Diese Person ist der Verwalter bzw. Verantwortliche für diese Struktur.

<fm-interface> Diese ist im Vorgriff auf ein mögliches Modulkonzept realisiert worden. Es kennzeichnet Funktionen, Fehlfunktionen und Strukturelemente, die für übergeordnete FMEAs verwendbar bzw. sichtbar sind.

<fm-structure-root> Dies bezeichnet das Strukturelement, welches die Wurzel der Struktur darstellt.

<fm-orphan-home> Dies bezeichnet das Strukturelement, welches alle nicht verankerten Strukturelemente, Funktionen, Fehlfunktionen und Maßnahmen aufnimmt.

<form-sheets> Dieses nimmt alle Formblätter auf, die in der FMEA ausgegeben werden sollen3.2.1.2. Formblätter.

<misc-data> Hier können benutzerdefinierte Datenfelder übertragen werden, die für alle Formblätter einer Struktur gelten.


3.2.1.1. Strukturelemente

Die DTD erlaubt es, daß eine Funktion in mehreren Strukturelementen referenziert wird. Es wird aber empfohlen, dies nicht zu nutzen, da keine verwendungsspezifischen Eigenschaften angegeben werden können.
In <part-number> kann die Sachnummer des Strukturelementes angegeben werden. Damit wird ein Bezug z.B. zur Produktdatenverwaltung möglich.
Die Hierarchie von Strukturelementen entsteht über <fm-structure-decomposition> (weitere Einzelheiten siehe 3.2.1. Systemstruktur).
Der Umfang von Formblättern wird durch Bezug auf die enthaltenen Strukturelemente bestimmt.
Abbildung 11: Strukturelemente


3.2.1.2. Formblätter

In <fm-form-sheet> werden Informationen zu den jeweiligen Formblättern einer Struktur dargestellt. Diese sind im einzelnen:
<user-cover-sheet> Hier können Informationen zu benutzerbezogenen Deckblättern abgelegt werden.

<misc-data> Hier können Datenfelder übertragen werden, die nur für das spezielle Formblatt gelten.

<fm-form-sheet-presentation> Hier kann das Ergebnis des Formblattes in Form der <ncoi> - Struktur abgelegt werden. In der Regel kommen hier CALS-Tabellen zum Einsatz.

Diese Information ist inhaltlich redundant. Sie muß daher beim Einlesen einer Instanz in ein FMEA-Werkzeug ignoriert werden.
<fm-structure-element-refs> Hier werden die Strukturelemente angegeben, der FMEA auf dem Formblatt ausgegeben werden soll. Es ist zu beachten:

  • Die Formblätter beziehen sich auf ein Strukturelement.
  • Elemente einer Struktur in einem Formblatt zusammengefaßt werden.


3.2.2. Funktionen

In <fm-functions> werden strukturübergreifend alle Funktionen (<fm-function>) des Systems zusammengefaßt. Über <fm-function-ref> können sie z.B. zum Aufbau des Funktionsnetzes referenziert werden.
Abbildung 12: Struktur der Funktionen
<fm-function-class> Dieses Element erlaubt eine Klassifizierung der Funktionen. Es entspricht der standard-Vorgehensweise in MSR. Hinweise zur Verwendung liegen noch nicht vor.

<fm-prerequisites> Hier wird auf andere Funktionen verwiesen, deren korrektes Funktionieren gegeben sein muß. Dadurch wird das Funktionsnetz etabliert. Es dürfen keine direkten oder indirekten Rekursionen auftreten.

<fm-fault-refs> Hier wird auf die möglichen Fehler einer Funktion verwiesen. Analog zur Zuordnung von Funktionen und Strukturelementen wird empfohlen, daß ein <fm-fault> nur von einer <fm-function> referenziert wird.


3.2.3. Fehlfunktionen

Fehlfunktionen werden unter <fm-fault> abgelegt.
<fm-fault-class> Dieses Element erlaubt eine Klassifizierung der Fehlfunktionen. Es entspricht der standard-Vorgehensweise in MSR. Hinweise zur Verwendung liegen noch nicht vor.

<fm-fault-type-ref> Dieser Verweis dient zur Typisierung der Fehlfunktion (vgl. 3.3.1. Hierarchisierte Typen).

<fm-causes> Hier wird auf andere Fehlfunktionen verwiesen, deren Eintreten die vorliegende Fehlfunktion bewirkt. Dadurch wird das Fehlernetz etabliert. Es dürfen keine direkten oder indirekten Rekursionen auftreten.

<significance> Dieses Element erlaubt die Beurteilung der Bedeutung (B-Note) der Fehlerfolge sowohl als verbaler Hinweis in <desc> wie auch als ein Faktor für die Risiko-Prioritätszahl (<risc-priority-factor>). Der Wert liegt zwischen 1 und 10, wobei 10 einer hohen Bedeutung entspricht.

<fm-task-history> Hier werden die Maßnahmen zum Umgang mit dem Fehler abgelegt (vgl. 3.2.5. Behandlung von Maßnahmen).

Abbildung 13: Fehlfunktionen


3.2.4. Risikoprioriätszahl

Die Risikoprioritätszahl dient zur Bewertung des Risikos innerhalb des betrachteten Systems. Die Risikoprioritätszahl (RPZ) kann aus der Instanz errechnet werden und wird daher nicht abgelegt. Sie berechnet sich entsprechend:
RPZ = B-Note * A-Note * E-Note
Dabei steht:
B-Note Bedeutung der Fehlerfolgen auf Gefahr, Gesetz, Kosten usw. Diese wird erfaßt in <risk-priority-factor> innerhalb von <significance> in <fm-fault>.

A-Note Auftretenswahrscheinlichkeit. Diese wird erfaßt in <risk-priority-factor> innerhalb von <fm-counter-tasks>.

E-Note Entdeckungswahrscheinlichkeit. Diese wird erfaßt in <risk-priority-factor> innerhalb von <fm-detection-tasks>.


3.2.5. Behandlung von Maßnahmen

Maßnahmen werden über die Kette <fm-task-history> und <fm-task-sets> bei den Fehlfunktionen (<fm-fault>) referenziert.
Dabei repräsentiert <fm-task-sets> eine Menge von Maßnahmenbündeln (<fm-task-set>), die zu einem bestimmten Datum (<date-1>) erarbeitet wurden.
Abbildung 14: Maßnahmenbündel
Ein einzelnes Maßnahmenbündel umfaßt Erkennungsmaßnahmen (<fm-detection-tasks>) und Vermeidungsmaßnahmen (<fm-counter-tasks>). Die einzelnen Maßnahmen (<fm-task>) bestehen aus dem Verweis auf die zugeordnete Aktion (<fm-action-ref>) sowie dem Faktor zur Berechnung der Risiko-Prioritätszahl.
In <fm-detection-tasks> dürfen nur <fm-action>s referenziert werden, deren <fm-action-class> den Wert fm-action-detect trägt. Desgleichen dürfnen in <fm-counter-tasks> nur <fm-action>s referenziert werden, deren <fm-action-class> den Wert fm-action-counter trägt.
Die DTD erlaubt es, daß eine Aktion (<fm-action>) in mehreren Tasks referenziert wird (<fm-action-ref>). Es wird aber empfohlen, dies nicht zu nutzen, da keine verwendungsspezifischen Eigenschaften angegeben werden können.
Der Faktor für die Risikoprioritätszahl (<risk-priority-factor>) wirkt abhängig vom Typ der Maßnahme, im vorliegenden Fall abgeleitet vom Kontext:
<fm-detection-tasks> Dies entspricht der E-Note. Damit wird die Wirkung der Maßnahme auf die Entdeckung des Fehlers bewertet. Ein kleiner Wert entspricht einer hohen Wirkung. Der Wert liegt zwischen 1 und 10.

<fm-counter-tasks> Dies entspricht der A-Note. Damit wird die Auftretenswahrscheinlichkeit des Fehlers unter Berücksichtigung der Maßnahme bewertet. Ein kleiner Wert entspricht einer geringen Ausfallwahrscheinlichkeit.


3.2.6. Behandlung von Aktionen

Die Maßnahmen bestehen aus der Durchführung von Aktionen <fm-action>, welche aus <fm-task-set> referenziert werden (3.2.5. Behandlung von Maßnahmen).
Abbildung 15: Aktionen
Die einzelnen Aktionen sind beschrieben durch:
<fm-action-class> Die ist die Klasse (oder der Zweck) der Aktion. Mögliche Werte sind fm-action-detect für Entdeckungsmaßnahmen und fm-action-counter für Vermeidungsmaßnahmen.

<fm-action-type-ref> Dies ordnet der Aktion einen Typ zu.

<team-member-ref> Dies benennt den Verantwortlichen für die Aktion

<fm-task-schedule> Dies definiert den Zeitplan für die Aktion. Dabei kann unter <desc > auch ein Kommentar abgelegt werden.

<fm-action-state> Dies enthält den Status der Aktion. Mögliche Werte sind:

finished Die Aktion ist abgeschlossen

untouched Die Aktion wurde noch nicht gestartet

inProgress Die Aktion läuft noch.

rejected Die Aktion wurde verworfen. Grund für das Verwerfen wird in <desc> bei <fm-task-schedule> dokumentiert.


3.2.7. Teamverwaltung

Die FMEA-Teams werden als eigene Objekte in <fm-teams> zusammengestellt. Die Teams können damit unabhängig von der Firmenzugehörigkeit ihrer Mitglieder zusammengestellt werden.
Die Team-Mitglieder werden innerhalb von <company> beschrieben und innerhalb von <fm-team> referenziert.


3.3. Strukturelle Besonderheiten

Die MSRFMEA.DTD wurde so weit wie möglich entsprechend dem Applikationsprofil von MSR Structure principles of the MSR application profile aufgebaut. Darüber hinaus gelten folgende Hinweise:
  • Die DTD wurde redundanzfrei [image] gestaltet. Daher sind nicht enthalten:
    • Vorverdichtungen
    • Rückverzeigerungen (z.B. von Fehlerursache auf die Fehlerfolge)
  • Zunächst wird reiner Text zur Ablage von Bemerkungen unterstützt. In künftigen Entwicklungen ist denkbar, <ncoi> voll zu unterstützen (wenn z.B. ein XML-Editor als OLE-Objekt verfügbar und in die einschlägigen FMEA-Tools integriert ist).
  • Das Konzept <short-name> in MSR wird kann zur Darstellung von Strukturnummern verwendet werden [image] .

Wenn in der FMEA-Vorgehensweise dereinst echte Kurzbezeichner eingeführt sind, ist in der MSRFMEA.DTD ein extra Element für die Strukturnummern vorzusehen.
abgesehen von form-sheet-presentation, welches das Formblatt als CALS-Tabelle aufnehmen kann, um eine einfache Übernahme in Dokumentationssysteme zu gewährleisten


3.3.1. Hierarchisierte Typen

Über die prinzipielle Vorgehensweise bei FMEA hinaus bietet die msrfmea.dtd die Möglichkeit, für Funktionen, Fehlfunktionen und Maßnahmen vorderfinierte Typen anzugeben (<fm-function-types>, <fm-fault-types>, <fm-action-types>).
Diese Objekte können über die Typen auch hierarchisiert werden. Dies geschieht dadurch, daß z.B. ein <fm-function-type> seinerseits wieder auf Typen verweist (<fm-function-type-decomposition>). Diese Hierarchisierung führt zu konsistenten Namensgebungen. Mit Fortentwicklung der FMEA-Methodik kann die Hierachie zu einer Vererbung von Eigenschaften ausgebaut werden, die über den reinen Namen hinausgehen.
Diese Hierarchie darf jedoch nicht mit dem Funktions- bzw. Fehlernetz verwechselt werden.


3.3.2. Unterstützung von Tool-Besonderheiten

Für die Identifizierung der Objekte müssen IDs vergeben werden. Es ist möglich, daß ein Werkzeug auf den Aufbau der IDs angewiesen ist. In diesem Fall ist es möglich, daß unter <fm-idtable> werkzeugspezifische alias-IDs <idc> hinterlegt werden.
Unter <fm-id-prefix> kann ein Werkzeug den präfix hinterlegen, der zum Aufbau der IDs verwendet wird. Damit ist es auch möglich, fremde IDs zu erkennen.
In <misc-data> innerhalb von <fm-tool> kann ein Werkzeug private Daten hinterlegen, z.B. um einen optimierten Wiederimport zu gewährleisten.


3.3.3. Erweiterungen des MSR Applikationsprofils

Gegenüber MSR Applikationsprofil V1.1.0 wurden folgende Erweiterungen vorgenommen:
  • Alle Elemente erhalten ein Attribut ([t]) zur Aufnahme von Zeitstempeln.
  • <admin-data> wurde um <lite-revisions> ergänzt. Dieses Element erlaubt eine vereinfachte Angabe von Revisionen, wenn alle am Projekt beteiligten Partner die gleiche Revisionierung verwenden. Die synchrone Zuordnung von Revisionsbezeichnern aus verschiedenen Firmen ist damit nicht mehr möglich.


A. Glossar

Failure Mode and Effect Analysis
A. Glossar

Archivierung
Archivierung ist die langfristige Ablage von Daten in einer Form, die mit künftigen - z.T. zum Archivierungszeitpunkt noch nicht absehbaren Werkzeugen wieder bearbeitbar ist.
Backup
Backup ist die kurzfristige Sicherung gegen Medienausfall. Backup wird in der Regel auf Basis der Arbeitsdateien durchgeführt
FMEA
Fehlermöglichkeits- und Einflußanalyse, eine systematische Vorgehensweise zur System- und Riskioanalyse.
Formblatt-FMEA
Bei der Formblatt-FMEA werden die Felder eines Formblatt brainstorm artig gefüllt. Eine systematische Vorgehensweise wird nicht methodisch erzwungen. Das Layout des Formblattes stellt die einzige methodische Stütze dar.
System-FMEA
System-FMEA ist eine strukturierte Analyse nach Strukturelementen, Funktionsverknüpfungen und Fehlfunktionsverknüpfungen durchführt, Maßnahmen festlegt und terminlich verfolgt. Aufgrund der Struktur und ihrer Verknüpfungen wird ein systematisches Vorgehen sichergestellt. Das Layout des Formblattes ist methodisch nicht relevant und kann weitgehend automatisch generiert werden.


B. Zusätzliche Anmerkungen zum Dokumentstand 1.5 am 04.10.99

Failure Mode and Effect Analysis
B. Zusätzliche Anmerkungen zum Dokumentstand 1.5 am 04.10.99

Status dieses Dokument: wd


Technische Begriffe

Failure Mode and Effect Analysis
Technische Begriffe

Produkte
msrfmea.dtd, msrfmea.dtd, msrfmea.dtd
MSRSYS.DTD
Programmcode
design
finished
fm-action-counter, fm-action-counter
fm-action-detect, fm-action-detect
inProgress
process
rejected
system
untouched
SGML Attribute
t, t
SGML Elemente
admin-data, admin-data
companies
company
date-1
desc, desc
desc
fm-action, fm-action
fm-action-class, fm-action-class
fm-action-ref
fm-action-state
fm-action-type-ref
fm-action-types, fm-action-types
fm-actions
fm-causes, fm-causes
fm-counter-tasks, fm-counter-tasks, fm-counter-tasks
fm-detection-tasks, fm-detection-tasks, fm-detection-tasks
fm-fault, fm-fault, fm-fault, fm-fault, fm-fault
fm-fault-class
fm-fault-refs
fm-fault-type-ref
fm-fault-types, fm-fault-types
fm-faults
fm-form-sheet
fm-form-sheet-presentation
fm-function
fm-function-class
fm-function-ref
fm-function-type
fm-function-type-decomposition
fm-function-types, fm-function-types
fm-functions, fm-functions
fm-head
fm-id-prefix
fm-idtable
fm-idtables
fm-interface, fm-interface
fm-limitation-tasks
fm-orphan-home
fm-prerequisites, fm-prerequisites
fm-se-decomposition, fm-se-decomposition
fm-se-functions, fm-se-functions
fm-significance
fm-structure
fm-structure-class
fm-structure-decomposition
fm-structure-element
fm-structure-element-refs
fm-structure-elements
fm-structure-owner
fm-structure-root, fm-structure-root
fm-structures
fm-task
fm-task-history, fm-task-history
fm-task-schedule
fm-task-set, fm-task-set
fm-task-sets
fm-team
fm-teams, fm-teams
fm-tool, fm-tool
fm-tool-data
form-sheets
idc
lite-revisions
locs
misc-data, misc-data, misc-data, misc-data
ncoi, ncoi
part-number
risc-priority-factor, risc-priority-factor
risk-priority-factor, risk-priority-factor
short-name, short-name
significance, significance
team-member-ref
user-cover-sheet
Werkzeuge
FMEA-Tool
FMEA-Werkzeug, FMEA-Werkzeug


Untitled

Wenn in der FMEA-Vorgehensweise dereinst echte Kurzbezeichner eingeführt sind, ist in der MSRFMEA.DTD ein extra Element für die Strukturnummern vorzusehen.


Untitled

Zum besseren Verständnis der Zusammenhänge von Methode und DTD werden schon hier die SGML-Elemente angegeben.


Untitled

abgesehen von form-sheet-presentation, welches das Formblatt als CALS-Tabelle aufnehmen kann, um eine einfache Übernahme in Dokumentationssysteme zu gewährleisten


Untitled

In Prozeß-FMEAs spricht man von eher von Merkmalen als von Funktionen