AyMINE – Technischer Bericht (Englisch)
Module
Aufgaben-, Projekt- und Qualitätsmanagement
Aufgaben-, Projekt- und Qualitätsmanagement
Systemrechte für das Task-Management-Modul
Task Management Modul Verwaltung
Benachrichtigungen und Nachrichten
Benachrichtigungen an sich selbst
FMEA – Auftretenswahrscheinlichkeit
FMEA – Wahrscheinlichkeit der Entdeckung
Fehleranalyse für eine einzelne Eigenschaft eines Bauteils oder Prozesses
Methodik und Qualitätsmanagementsystem
Probleme, Tickets und ihre Verwaltung
8D report – Systemunterstützung
Kundenservice Antwortgenerierung
Qualifikation, Fähigkeit / Geschicklichkeit
GDPR und Verzeichnis der Qualifikationen
Qualifikation des Benutzers oder Kontakt
Rechte zur Verwaltung der Qualifikationen von Nutzern
Kontakte, Verzeichnisse
System-Berechtigungen und CRM-Modul-Einstellungen
Adressbuch von Personen und Firmen
Massenversand von Nachrichten in Übereinstimmung mit der GDPR
Melden Sie sich ab und stellen Sie Einstellungen ein
für Massenmails
Wie man die Daten einer Person richtig vergisst
Web-Management und Automatisierung
Web-Management und Automatisierung
Benutzerdokumentation für AyMINE
Empfangen einer Nachricht über das Web
Grundlegende Service-Einstellungen
Zugriff auf eine Website speichern
HR-Modul
Abteilung verwalten / division data
Personalistics – Benutzerberechtigungen
Registrierung von Arbeitsuchenden
Sicherheit der Personalverwaltung
Ein Überblick über Ihr eigenes Mitarbeiter
Synchronisierende Mitarbeiter und Benutzer des Systems
Produkte, Vermögenswerte, Kauf und Verkauf
Produkte, Vermögenswerte, Kauf und Verkauf
Angebot und Preis Zugriffsrecht
Erhaltener Auftrag für Waren oder Dienstleistungen
Produkteigenschaft oder Produktelement
Finanzmanagement
Metriken und Messungen
Technische Module
Sabre-Modul
Konnektor zwischen AyMINE und Enterprise Architect
Datenbanklink zur Enterprise Architect Datenbank
Konnektor zwischen AyMINE und Enterprise Architect
Systemmodule
Framework – Systembasis
Richtlinie zur Aufbewahrung von Passwörtern
Überblick über Module und Datentypen
AyMINE — Anwendung für Windows
Drag & Drop zwischen den Datensätzen
Gesten und Tastenkombinationen
Konfigurieren Sie, wie Ihr System aussieht und funktioniert
Mehr darüber, wie das System funktioniert
Private Notizen und Tags für Objekte
Systemverwaltung
Beziehungen zwischen den Datensätzen
Formatierte Texte in der Anwendung
Gateway-Einstellungen für externe -Nachrichten
Sichere Geschäftskommunikation
FMEA-Analyse
Die FMEA dient dazu, mögliche Probleme mit der Funktionsweise eines Produkts durch eine detaillierte Analyse aller seiner Komponenten und Eigenschaften zu identifizieren.
- FMEA – Detaillierte Analyse
- Risikobewertung
- Maßnahmen zur Risikominderung definieren
- Schritt 3: FMEA-Bericht
- Wichtig zu wissen
- RPN vs. AP – Unterschiede in der FMEA-Bewertung
- Weitere Informationen
Eine vollständige Beschreibung der FMEA finden Sie auf einer separaten Seite hier. Diese Seite befasst sich mit den Besonderheiten der FMEA für Produkte.
Beschreibung des FMEA-Prozesses
Eine vollständige Beschreibung der FMEA finden Sie auf einer separaten Seite hier](/doc/de/tsk/tskFMEA). Diese Seite befasst sich mit den Besonderheiten der FMEA für Produkte.
Beschreibung des FMEA-Prozesses
FMEA – Detaillierte Analyse
Die FMEA ermöglicht auf der Grundlage der Produktstruktur die Analyse, welche Eigenschaften, Funktionen und Betriebsmodi jede Komponente des Produkts hat. Diese dienen dann als Schlüsselgrundlage für die eigentliche FMEA-Analyse.
In Übereinstimmung mit der Methodik unterstützt AyMINE die FMEA-Analyse wie folgt:
- Analyse einzelner Teile und deren spezifischer Eigenschaften (strukturelle Analyse)
- Funktionale Analyse (dynamische Analyse)
- Beschreibung der Betriebsmodi.
Für jedes Element werden potenzielle Gefahren und Risiken analysiert, die entstehen könnten, und es werden Maßnahmen vorgeschlagen.
Funktionen
Funktionen beschreiben, was das Produkt tut und wie es sich verhält. Eine typische Funktionsbeschreibung umfasst Eingang/Stimulus, Datenverarbeitung und Ausgang.
Wichtige FMEA-Fragen:
- Auf welche Eingaben ist die Funktion nicht vorbereitet (z. B. Abweichung der Eingabewerte durch Überhitzung)?
- Wie wird sichergestellt, dass ein Funktionsausfall das Produkt oder seine Umgebung (einschließlich des Benutzers) nicht gefährdet?
- Wie kann sich das Produkt erholen, wenn die Funktion ausfällt?
Alle potenziellen Probleme müssen im Rahmen der Analyse dokumentiert werden.
Betriebsmodi
Für jedes Produkt müssen alle Betriebsmodi beschrieben werden, einschließlich solcher, die nur kurzzeitig auftreten können. Typische Betriebsmodi sind:
- Ausgeschaltet (entweder ohne Stromversorgung oder im Standby-Modus)
- Getrennt (alle Eingänge getrennt, z. B. wegen eines Fehlers in der Umgebung)
- Diagnostik vor dem Start
- Normalbetrieb
- Betrieb im eingeschränkten Modus
- Betrieb im Notfallmodus (Safety)
- Abschaltung
- ...
Die Modi müssen dokumentiert werden, idealerweise mit einer Zustandskarte oder zumindest mit einer Beschreibung, wie und unter welchen Umständen der Übergang in einen bestimmten Zustand erfolgt. (Die Zustände können direkt im System verknüpft werden – das ist jedoch nur sinnvoll, wenn die Verknüpfungen tatsächlich für die Analyse genutzt werden.)
Bei der Analyse ist es wichtig zu bewerten:
- Welche Funktionen des Produkts im jeweiligen Modus verfügbar sind,
- Welche Anforderungen an das System gestellt werden können und ob das Produkt diese im jeweiligen Modus erfüllen kann. Falls nicht, welche Konsequenzen das haben könnte,
- Welche Ressourcen (z. B. Stromverbrauch) im jeweiligen Modus benötigt werden und was passiert, wenn diese nicht verfügbar sind oder ausfallen.
Eigenschaften
Eigenschaften umfassen alle weiteren Merkmale des Produkts, die für die funktionale und sicherheitstechnische Analyse wichtig sind. Typischerweise umfassen diese:
- Emissionen (z. B. elektromagnetische Strahlung, Vibrationen, Lärm, Wärme)
- Größen-/Volumenänderungen
- Haltbarkeit unter äußeren Bedingungen (z. B. Lebensdauer in Bezug auf Temperatur, Feuchtigkeit usw.)

Risikobewertung
Für jede Funktion, jeden Betriebsmodus und jede Eigenschaft wird im Rahmen der FMEA beschrieben, welche Risiken bei einem Ausfall bestehen, und diese Risiken werden bewertet. Das System unterstützt Sie dabei, für jede Eigenschaft kritische Kennzahlen zu identifizieren (die Links erklären die Bedeutung der Bewertungsmaßstäbe):
- Wahrscheinlichkeit, dass die Situation eintritt
- Fähigkeit, das Problem rechtzeitig zu erkennen
- Schwere der Auswirkungen auf Menschen, insbesondere auf ihre Sicherheit
Jede dieser Werte muss einzeln festgelegt werden, und das System füllt die Werte automatisch vor und berechnet die Gesamtbewertung ("Risiko-Rating"). Dadurch erhalten Sie eine vollständige Übersicht, welche Risiken besonders beachtet werden müssen.
Maßnahmen zur Risikominderung definieren
Für Risiken, deren Gesamtrating den für das Produkt festgelegten Schwellenwert überschreitet, müssen Maßnahmen zur Reduzierung festgelegt werden. Das System ermöglicht es Ihnen, direkt zwei grundlegende Arten von Maßnahmen zu definieren:
- Anforderungen an das entwickelte Produkt
- Sicherheitsmaßnahmen im Zusammenhang mit der Herstellung des Produkts (einschließlich zugehöriger Kontrollen)
Beide Maßnahmenarten können direkt von der identifizierten Eigenschaft aus erstellt werden. Es ist wichtig, diese Maßnahmen entweder aus der Eigenschaft heraus zu erstellen oder sie mit der Eigenschaft zu verknüpfen, um Informationen darüber zu bewahren, wie das Risiko tatsächlich reduziert wurde. Dies ermöglicht es Ihnen, nachzuweisen, welche Maßnahmen ergriffen wurden, und zu analysieren, ob diese angemessen sind. Umgekehrt wird bei Anforderungen und Verfahren deutlich, warum diese erforderlich sind.
Schritt 3: FMEA-Bericht
Sobald die Analyse abgeschlossen ist, kann der gesamte FMEA-Bericht mit der FMEA-Funktion generiert werden. Die Analyse erstellt einen Bericht direkt in AyMINE im HTML-Format – so können Sie vor dem Export in PDF weitere Informationen hinzufügen, falls erforderlich. Dadurch können Sie problemlos Informationen einfügen, die der Kunde wünscht.
Obwohl der generierte FMEA-Bericht prinzipiell bearbeitbar ist, sollte er nicht für die eigentliche Analyse verwendet werden – Sie würden die Konsistenz mit der Produktdokumentation verlieren.
Wichtig zu wissen
Dokumentation ist entscheidend
Eine gründliche Dokumentation der FMEA ist unerlässlich für die Entwicklung. Die FMEA-Analyse ist nicht nur bei der Produktentwicklung erforderlich, sondern über den gesamten Lebenszyklus hinweg:
- Wenn ein Problem auftritt, das z. B. mit einem 8D-Report behandelt wird, ist die FMEA eine wesentliche Grundlage.
- Wenn Sie eine neue Produktversion entwickeln, benötigen Sie nur eine Differenz-FMEA. Sie sparen sich den Großteil der Arbeit, jedoch nur, wenn Sie nachweisen können, dass Sie die ursprüngliche FMEA kennen – einschließlich ihrer Schlussfolgerungen und wie diese umgesetzt wurden.
- Sie wird natürlich für Audits benötigt.
- Sollte es je zu einer Überprüfung kommen, ob Sie alles Notwendige für die Zuverlässigkeit des Produkts getan haben, ist eine gut dokumentierte FMEA ein zentraler Nachweis für einen verantwortungsvollen Ansatz.
Spezielle Eigenschaften von Produkteigenschaften
Die FMEA-Dokumentation sollte kritische Produkteigenschaften abdecken, insbesondere deren Einfluss auf die Sicherheit oder Cybersicherheit.
Für jede Produkteigenschaft können Sie benutzerdefinierte Typen und Tags basierend auf den Anforderungen Ihrer Analyse definieren. Sie können auch Tags verwenden, die gemeinsam mit Anforderungen und Verfahren genutzt werden. Wenn diese Tags verwendet werden, übertragen sie sich automatisch auf Anforderungen und Verfahren, die aus der FMEA erstellt wurden – so stellen Sie sicher, dass nichts verloren geht (wie von Standards wie [ISO 26262](https://www.iso26262.cz/, ISO62061 und anderen gefordert).
RPN vs. AP – Unterschiede in der FMEA-Bewertung
Der Standard von 2019 (FMEA-Handbuch) empfiehlt die Verwendung des Action Priority (AP)-Indexes anstelle des Risk Priority Number (RPN). Die Berechnung und das Ergebnis unterscheiden sich. Während RPN als Produkt der Werte für Schweregrad (S = Severity), Auftretenswahrscheinlichkeit (O = Occurrence) und Erkennbarkeit (D = Detection) berechnet wird, wird AP mit einer Tabelle aus denselben Werten umgerechnet. AP ähnelt der ASIL-Bewertung nach ISO 26262.
Das FMEA-Handbuch erläutert:
RPN ist kein adäquates Werkzeug zur Priorisierung, da alle drei Dimensionen (S, O, D) gleich gewichtet werden. Dadurch können zwei Risiken mit sehr unterschiedlichen Schwere- und Auftretens-Werten denselben Score erhalten, was Teams verwirrt.
Wesentliche Unterschiede zwischen AP und RPN:
- Wenn S und O beide sehr hoch sind, hat die Priorität den höchsten Rang, unabhängig von D.
- Wenn mindestens einer der Werte S oder O sehr hoch ist, hat AP mindestens eine mittlere Priorität.
Faktisch reduziert AP die Bedeutung der Erkennbarkeit in der Gesamtbewertung.
AyMINE unterstützt RPN und AP, weil:
- AP ist für die Priorisierung gemäß aktueller FMEA-Methodik erforderlich.
- RPN liefert genauere Vergleiche (1.000 mögliche Werte gegenüber 3 AP-Stufen).