Dieses Thema enthält 13 Antworten, hat 5 Stimmen, und wurde zuletzt vor vor 10 Stunden, 57 Minuten von  Herbert aktualisiert.

14 Antworten anzeigen - 1 bis 14 (von insgesamt 14)
  • Autor
    Beiträge
  • #27655

    Riccardo Stüber
    Participant

    Hallo in die Runde,

    ich habe bereits ein wenig mit dem P-Diagramm der Version 7.0.0010 experimentiert und möchte den Ansatz schon mal sehr loben. Das geht aus meiner Sicht absolut in die richtige Richtung.
    Einige Dinge stören mich aber auch noch, die ich hier jetzt anregen oder zu Diskussion stellen möchte.

    „Mangel“
    „Input“ als Produktmerkmal ist nicht logisch und verwirrt. Zudem steht ein ProdM nicht direkt unter der Funktion im Strukturfenster.

    Vorschlag:
    „Funktionsinput“ als eigener Objekttyp, direkt unter der Funktion anzuzeigen. Solange das nicht geht, wäre es zumindest besser, den Input auch als Anforderung zu deklarieren, vielleicht mit im Text vorgestellten „Input: “

    „Mangel“
    „Output“ als Anforderung ist noch ein wenig nachvollziehbar aber auch verwirrend

    Vorschlag:
    „Funktionsoutput“ als eigener Objekttyp, der wie eine Anforderung gehandhabt werden kann, direkt unter der Funktion anzuzeigen. Solange das nicht geht, vielleicht mit im Text vorgestellten „Output: “

    „Mangel“
    „Störgrößen“ als Prozessmerkmale sind ein wenig nachvollziehbar, aber bei Teil-zu-Teil-Varianz nicht.

    Vorschlag:
    „Störgröße“ als eigener Objekttyp, der wie ein Merkmal gehandhabt werden kann und der wie bisher in einem separaten Systemelement auftaucht.

    „Mangel“
    „Steuergrößen“ sind Produktmerkmale. Dies ist im Design richtig, aber im Prozess sind es die Prozessmerkmale. Leider funktioniert das auch bei Einstellung „Prozess-FMEA“ nicht. Nach manuellem Umwandeln verschwindet das Merkmal als Steuergröße. Zudem werden die Steuergrößen nicht automatisch mit der Funktion verknüpft, die sie steuern. Das wäre aber logisch. Man kann das leider auch nicht händisch tun im P-Diagramm, sondern muss separat in einen anderen Editor

    Vorschläge:

    – „Steuergrößen“ als eigenen Objekttyp oder ProdM in DFMEA und ProzM in der PFMEA.

    – Automatische Verknüpfung bei Eintrag in das P-Diagramm sowie manuelle Verknüpfung ermöglichen

    – Bereits verknüpfte Merkmale automatisch ins P-Diagramm übernehmen!?

    Beste Grüße
    Riccardo Stüber

    #27656

    John Rainer
    Participant

    Hallo Herr Stüber,

    vielen Dank für Ihre Rückmeldung.

    Im Vorfeld der Umsetzung des P-Diagramms gab es Überlegungen ob die Bestandteile des P-Diagramms (z.B. Störgrößen, Eingangsgrößen, etc. ) als eigene Objekte modelliert werden sollen oder ob wir bereits vorhandene Objekttypen für diese Größen verwenden. Letztendlich haben wir uns für den jetzigen Ansatz entschieden. Der Vorteil ist, dass die Komplexität des Datenmodells nicht noch weiter steigt und der Anwender auf bekannte Objekttypen zurückgreifen kann. Der Nachteil ist, dass es mitunter zu Zweideutigkeiten kommen kann. Aus der Vergangenheit kann man sagen, dass es bei neuen Konzepten, im Laufe der Zeit, immer zu Anpassungen kommt. Das ist ja auch gut so.

    Zu Ihren Punkten:

    Grundsätzlich ist das Einführen neuer Objekttypen innerhalb einer Version nicht möglich, so dass ein Teil Ihrer Vorschläge leider nicht auf diese Weise gelöst werden können.

    1. Input

    Vorstellbar wäre, dass neben Produktmerkmalen auch beispielsweise Funktionen als Input verwendet werden können.

    2. Output

    Hier gilt das Gleiche wie beim Input. Der Grundgedanke war hier, dass Anforderungen an eine Funktion als erwarteter bzw. beabsichtigter Output gesehen werden können.

    3. Störgröße

    Die Verwaltung der Störgrößenkategorien im Data Manager bietet die Möglichkeit, pro Störgrößenkategorie festzulegen, ob für die jeweilige Kategorie ein Produkt- oder Prozessmerkmal verwendet werden soll.

    4. Steuergröße

    Auch hier wäre eine Erweiterung dahingehend denkbar, dass man nicht nur Produkt-, sondern auch andere Objekttypen zulässt.

     

    Anmerkungen zum P-Diagramm und auch anderen Komponenten sind natürlich willkommen. Wir werden diese sammeln, deren Umsetzbarkeit prüfen und im Sinne der Anwender umsetzen, sofern möglich.

    John Rainer
    APIS Informationstechnologien GmbH

    • Diese Antwort wurde vor vor 1 Monat, 2 Wochen von  John Rainer bearbeitet.
    #27659

    Riccardo Stüber
    Participant

    Hallo Herr Rainer,

    vielen Dank für die Antworten! Unter dem Aspekt, dass vorerst keine neuen Objekte in Frage kommen, würde ich folgende Vorschläge machen:

    1. Input
    Input auch als Anforderung, denn nur so kann man diese auch eindeutig einer Funktion zuordnen in der Strukturliste. Ich persönlich würde mit dann eben Input oder Output davor schreiben. 🙂

    2. Output
    So lassen, wie es ist.

    3. Störgröße
    So lassen wie es ist.

    4. Steuergröße
    Produktmerkmale in der DFMEA wie bisher, in der PFMEA müssten es aber Prozessmerkmale sein.

    Noch ein Nachtrag:
    Mir ist noch aufgefallen, dass Fehlfunktionen, die an einer Anforderung zu einer Funktion hängen, zum Beispiel am gewünschten Output, sich nicht im Fehlfunktionenfeld anzeigen lassen. Dies wäre noch gut, weil logisch. Natürlich lässt sich das manuell umgehen, wenn man die Fehlfunktion direkt an die Funktion verschiebt. Aber es könnte verwirren, bevor man darauf kommt.

    Generell aber noch mal ein dickes Lob, weil das echt in eine aus meiner Sicht gute Richtung läuft. 🙂

    #27854

    Peter
    Participant

    Hallo zusammen,

    ich möchte gerne folgendes Anmerken:

    Der Editor ist ein Hilfsmittel, wie sie später die Punkte anordnen obliegt dem FMEA Verständnis.

    Ich finde das Tool Klasse und bin gerade am ausprobieren.

    Aber:

    1. Input:

    Muss nicht unbedingt eine Funktion sein, ein Input ist meistens eine Anforderung des betrachteten Systems. Aber eine Anforderung in APIS lässt sich nur einer Funktion zuordnen oder man kopiert diese öfter, was aber der Baumstruktur widersprechen würde. Daher, eine Anforderung ist nicht nur an einer Funktion gekoppelt, sondern kann das kpl. System beeinflussen. Daher ist der Ansatz von APIS hier meiner Meinung nach i.O.

    2. Output

    siehe oben

    3. Störgröße

    Störgrößenkategorien im Data Manager finde ich einen sehr guten Ansatz, die Praxis wird hier über die Zeit zeigen ob und was man Optimieren soll.

    4. Steuergröße

    Dieser Bereich muss Diskutiert werden da momentaner Ansatz i.O. ist aber hier müsste man sich evtl. noch etwas Überlegen.

    Fazit meinerseits: Das Tool ist meiner Meinung nach ein Hilfsmittel kann aber das „Logische Teamdenken“ und den Ansatz des Boundarys nicht vollautomatisch umsetzen, dies muss es meiner Ansicht nach auch garnicht. Denn über jedes Merkmal über das wir im Team sprechen hilft der Risikoanalyse und hilft das System besser zu verstehen.

    Daher finde ich den Ansatz in APIS momentan sehr gut und andere Tools bieten das Momentan gar nicht oder nur sehr Oberflächig.

    Gruß

    #27855

    John Rainer
    Participant

    Hallo,

    erst mal vielen Dank für die Rückmeldung.

    1. Input

    Eine Anforderung als Input wäre prinzipiell (im Sinne des Datenmodells) denkbar. Wenn die Anforderung (Input) allerdings nicht bei der betrachteten Funktion verankert ist, dann müsste die IQ-Software, bei Direkteingabe im P-Diagramm, eine Funktion erzeugen, bei der diese Anforderung verankert wird. Ähnlich wie jetzt für Störgrößen und Lenkungsgrößen eigene Elemente  durch die IQ-Software erzeugt werden.

    Würde man die Input-Anforderung bei der betrachteten Funktion verankern, wie aktuell auch den Output, dann könnte dies über ein Attribut gesteuert werden.

    Hinweis: Boundary-Diagramme könne in der IQ-Software über den Editor für das Block-Diagramm umgesetzt werden. Diagramme können zum einen über sysML importiert werden. Zum anderen können Sie Grafikdateien importieren und für die importierte Grafik Regionen definieren, denen Sie beliebige Objekte (Strukturelemente, Funktionen, …) aus der FMEA zuordnen können.

    John Rainer
    APIS Informationstechnologien GmbH

    #27856

    Peter
    Participant

    Hallo Hr.Rainer,

    danke für die Rückinfo, das mit den Boundary Diagrammen ist mir bewusst, ich wollte zum Ausdruck bringen das ich erstmals mit dem Programm dies intensiv nutzen muss, um mir hier eine Aussage zu erlauben.

    Zum Thema Anforderungen bin ich der Meinung das eine Anforderung nicht einer einzigen Funktion angeordnet ist!Dies kann in Ausnahmefällen so sein (z.B. Anforderung Gehäuse muss aus Alu (AlMn) sein), aber die Realität zeigt das wir Anforderungen haben (vor allem vom Kunden) welche sich weitervererben und nicht nur einer Funktion angehören, das wäre fast zu schön um wahr zu sein 🙂

    • Diese Antwort wurde vor vor 1 Monat von  Peter bearbeitet.
    #27907

    Riccardo Stüber
    Participant

    Hallo zusammen,

    ohne hier eine Diskussion vom Zaun brechen zu wollen – aber Funktionale Anforderungen sind meiner Meinung nach in der Regel EINER Funktion zugeordnet. Das ein Gehäuse aus Alu oder grün oder blau sein muss, ist KEINE funktionale Anforderung, sondern eine nichtfunktionale bzw. eine schlichte Vorgabe, aus der sich nichts weiter ergibt als das man sie erfüllen muss. Was soll man denn da hinterfragen? Fehler: „Ist nicht aus Aluminium“, Vermeidungsmaßnahme: „mach es doch aus Aluminium“, E-Maßnahme: „Prüfe, ob es aus Aluminium ist.“
    Deshalb betrachte ich sowas gar nicht in der FMEA, sondern überlasse das dem Anforderungsmanagement. Bei komplexen Produkten sprengt eine derartige Betrachtung absolut den Rahmen jeder FMEA und das macht kein Teammitglied lange mit, ohne die Augen zu verdrehen 😉 Die Schritte der FMEA enthalten nicht umsonst keinen Schritt „Anforderungsanalyse“.

    Um Beim P-Diagramm zu bleiben. Funktionen im physikalischen Sinne haben immer einen Input. Der ist keine Anforderung, sondern eine physikalische Größe (eine Anforderung wiederum kann aber ein Grund sein, eine Funktion zu definieren). Zum Beispiel elektrische oder mechanische Leistung. Die Funktion wandelt oder überträgt diesen Input. Zum Beispiel: „Mechanische Leitung in elektrische Leistung wandeln“ (Generator). Deshalb hat der Output wieder eine physikalische Größe, der nur dieser Funktion zugeordnet werden wird. Möglicherweise gibt es auch Fälle, wo die selben Größen noch einer anderen Funktion zugeordnet werden müssen. Da finde ich kein Beispiel.

    Insofern ist der Weg, in der IQ-Software „Anforderungen“ als Input oder Output zu gehen zu gehen, eh erst mal ein „Behelf“. Ich fände es jedoch wichtig, dass Input und Output auch in der Strukturliste sichtbar der Funktion zugeordnet sind.

    Herbstliche Grüße!

    #27908

    Riccardo Stüber
    Participant

    Nachtrag: Nun fielen mir doch Beispiele ein, wo ein Input gleichzeitig mehreren Funktionen dienen kann, z.B., Netzspannungsversorgung. Jedoch wäre das nach wie vor kein Problem, diese dann eben mehreren Funktionen wiederholt zuzuordnen.

    #27909

    mwerdich
    Participant

    Hallo zusammen,

    Es sind bereits viele gute Gedanken bei APIS in die Software eingeflossen. Folgend unser (FMEAplus) methodischer Umsetzungsvorschlag:

    Input“ und (gewollter) „Output“ sind Einflüsse aus Blockdiagramm mit Signalpfad-Verbindungen. Also entweder (meist) Merkmale (Glühbirne: „Strom“ rein „Licht“ raus) oder Funktionen (Steuerung Kran: „Joystick bewegen“ rein und „Motoren ansteuern“ raus). Diese kommen oft aus der gleichen Ebene und meist aus nicht modellierten, da externen, Systemelementen (häufig aus Systemschnittstellen z.B. aus der Steckdose). APIS: die In- und Outputs könnten im Datamanager oder in Systemelementen (außerhalb der betrachteten FMEA) verwaltet werden.

    Es geht im P-Diagramm in erster Linie darum, Faktoren („Steuergrößen“) also Funktionen, Produktmerkmale, Prozessmerkmale, Anforderungen oder/und Maßnahmen zu finden um das Produkt gegen die Störgrößen robust zu machen um den gewünschten idealen Output zu erreichen.

    Störgrößen“ sind entweder Fehler aus beeinflussenden Systemelementen (Umwelt, Kundennutzung, System-Interaktion), die bisher nur sehr selten in den FMEA-Strukturbäumen zu finden sind, oder Fehler von Funktionen und Anforderungen des betrachteten Produktes (Teil zu Teil Unterschiede, Alterung). Der APIS Ansatz die Störgrößen im Datamanager zu verwalten halten wir für sehr gut und übersichtlich.

    Die „Fehler“ sind vielmehr die unerwünschten Nebenwirkungen (also „Abweichung von der idealen Produkt-Funktion“ z.B. Wärme bei Glühbirne)

    #27969

    Riccardo Stüber
    Participant

    Noch ein Nachtrag zum P-Diagramm allgemein.
    Hier sollte das Verknüpfen von Funktions- und Fehlernetzen per Special-Drag innerhalb des P-Diagramms und aber auch in andere Editoren ermöglicht werden, wie das in anderen Editoren bereits auch ist. Zudem sollten hier eingetragene  Lenkungsgrößen aus meiner Sicht automatisch aus Ursachenrichtung an die Funktion, die sie lenken, geknüpft werden oder eben zumindest per Special-Drag geknüpft werden können. Bereits an die fokussierte Funktion verknüpfte Merkmale sollten automatisch als Lenkungsgrößen eingeblendet werden.

    Und ganz wichtig wäre noch immer, dass bei Einstellung des Projektes auf Prozess- oder Logistik-FMEA die Steuergrößen Prozessmerkmale sein sollten (aus meiner Sicht sogar müssen!)

    Nur im Design sind es die auszulegenden Produktmerkmale.

    • Diese Antwort wurde vor vor 2 Tage, 19 Stunden von  Riccardo Stüber bearbeitet.
    #27982

    Peter
    Participant

    Hallo Hr.Werdich,

     

    kann ihnen hier zustimmen. Sehe das fast genauso. Die Problemetik ist wohin mit diesen Punkten wir Behelfen uns hier, aber es sollte über APIS direkt gehen.

    Zitat:

    Die „Fehler“ sind vielmehr die unerwünschten Nebenwirkungen (also „Abweichung von der idealen Produkt-Funktion“ z.B. Wärme bei Glühbirne)

    Genau hier aber liegen die Fehler welche evtl. Entscheidend für die Vorgehensweise der Konstruktion sind, wenn z.B. die Wärme der Glühbirne, die Anforderungen des Kunden bzgl. max. Temp. übersteigt hat man die Glühbirne falsch ausgelegt und muss eine Konstruktive Änderung herbeiführen.

    Darum ist wie sie korrekt gesagt haben das Block Diagramm oder Boundary Diagramm hier meiner Ansicht nach enorm wichtig.

    Ebenfalls die Abgrenzung des Systems welches man im Vorfeld Definieren sollte.

    Aber ich finde es Klasse das man sich hier austauschen kann, so sieht man das man nicht alleine die Problematik hat 🙂

    Gruß

     

    • Diese Antwort wurde vor vor 1 Tag, 18 Stunden von  Peter bearbeitet. Grund: Form und Rechtschreibung korrigiert
    #27989

    Herbert
    Participant

    Zum Beitrag von mwerdich: „Störgrössen“ sind entweder Fehler …. ; würde ich so nicht zustimmen. Meine Interpretation ist eher Störgrössen sind Einflüsse auf die Funktion, also Randbedingungen, oder Anforderungen an die Funktionserfüllung die bei der Auslegung, den Design Entscheidungen zu berücksichtigen sind um die Abweichungen von der idealen Funktion im erlaubten Rahmen zu halten. Die ideale Funktion, Wirkungsgrad 1 wird in der realen Welt nie erreicht, deshalb macht der „Output“ Ideale Funktion auch nur mit Angabe einer zulässigen Abweichung, Varianz Sinn – Reale Funktion im erlaubten Rahmen. Darüber Hinausgehende Abweichungen sind Fehler. Energieverluste sind nicht per sé Fehler. Glühbirne: Strom rein, Licht und Wärme raus. Die Wärme kann durchaus der gewünschte Output sein, zum Beispiel Brutkasten des Taubenzüchters. Hier wäre das Licht ein nichterwünschter oder nichtstörender Nebeneffekt der akzeptiert wird. Die Steuergrösse wäre die gewählte Wattzahl der Glühbirne. Störgrössen für den Brutkasten Systemdesigner wäre (Teil zu Teil Toleranz) die Toleranz des Glühfadendurchmessers, der Länge und Anzahl der Windungen, der Legierungsbestandteile und erlaubter Volumenanteile. Im Gegensatz zum Glühbirnendesigner, für den diese Produktmerkmale, Glühfadendurchmesser, Länge und Anzahl Windungen Steuergrössen sind, mit denen er die Lichtabgabe steuern kann. Damit möchte ich zu meinem Statement kommen: Das Tool muss diese Flexibilität unterstützen und darf sie nicht einschränken. Was wäre, wenn man die Objekte beschreiben kann und später definiert, diese Beschreibung ist eine Funktion, ein Merkmal, ein Fehler, eine Anforderung, etc. ? Es geht doch um die Technik und nicht darum ein Tool zu befriedigen. Wenn die Texte, dann in den Katalogen einsortiert sind, kann man Sie für die FMEA widerverwenden. Ein virtuelles Blatt Papier mit Mehrwert.

    #27990

    Peter
    Participant

    Hallo Herbert,

    Ihre Aussage ist so i.O. wenn die Wärme gewünscht ist, wird diese nicht gewünscht ist es ein Fehler bzw. wie Sie es nennen eine Randbedingung, Störgröße etc.

    Wie dem auch sei, meiner Ansicht nach ist es wichtig, wie sie auch schon korrekt sagen, die Funktionsfindung. Diese lebt und wird Detaillierter je mehr Informationen ich über das System kenne, egal ob Störgrößen, Anforderungen etc.

    Diese sind entweder nötig um die Funktion zu erfüllen, oder die Störfunktionen, welche den Konstrukteur evtl. behindern die Funktion zu erfüllen, bei beiden kann es Risiken geben. Darum geht es bei der FMEA, die Risiken der Konstruktion so früh wie möglich darzustellen und Risikotechnisch zu Bewerten. Darum ist der Ansatz mit dem Diagramm Optimal meiner Ansicht nach.

    Wie Sie schon richtig sagen ist das Tool in APIS noch am Anfang aber schon jetzt sehr gut, die Zukunft wird hier sicher noch einige Updates bringen. Ich finde das den großen Vorteil von APIS, diesen „Freiraum“, dass man eben genau das tun kann, je strikter ich etwas vorgebe (Programmtechnisch) umso weniger Freiraum hat man. Bei einem Thema wie diesem bin ich gespannt wie sich das Entwickelt und bin froh das APIS uns das zur Verfügung gestellt hat.

    Schlussendlich muss ich aber auch sagen das dieses Thema ziemlich komplex ist und eine ich sag mal „einfache Abarbeitung“ nicht so gelingen wird. Man muss sich mit den Experten zusammen setzen und sich wirklich tiefgreifende Gedanken über das System machen, je genauer wir hier sind umso besser das Resultat der FMEA.

    #28001

    Herbert
    Participant

    Hallo Peter, genau das ist das Problem, das wir uns in unseren Definitionen und Formulierungen nicht genau ausdrücken bzw.. genau die Definition fehlt. Wenn die gewünschte Funktion das Licht ist, ist der Fehler Kein Licht, oder Lichtintensität zu gering, oder etc. . Wärmeabgabe ist kein Fehler sondern ein zu tolerierender Nebeneffekt, kann aber sehr Wohl auch wieder eine Randbedingung oder Anforderung für den Lampenschirm Designer sein. Ohne Erhitzung des Drahtes gibt es kein Licht, da kann man doch nicht von Fehler reden (hier widerspreche ich der Aussage von @mwerdich, oben) Das bedeutet für die Struktur, dass, wollte man das graphisch abbilden, ein orthogonales Netz, in Relation zum Funktionsnetz, aufspannen müsste um die Wechselwirkungen zwischen den Systemelementen/Funktionen aufzuzeigen (hier stimme ich @mwerdich zu). Das kann man aber auch sehr gut in einem Blockdiagramm sichtbar machen. Was mir fehlt und was auch im AIAG&VDA sehr sehr … sagen wir mal schwach beschrieben ist was man mit dem P-Diagram überhaupt in der FMEA bezwecken möchte?

    • Diese Antwort wurde vor vor 10 Stunden, 31 Minuten von  Herbert bearbeitet.
14 Antworten anzeigen - 1 bis 14 (von insgesamt 14)

Sie müssen angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.