Maschinenbau

FMEA? – „Wir werden mögliche Fehler bei der Inbetriebnahme schon beheben, die Softwareentwicklung wird das richten.“ So oder so ähnlich wurden Projekte häufig begonnen. Lastenheft, Pflichtenheft – und dann loskonstruieren! Etwas überspitzt, aber so sah es vielleicht bis vor wenigen Jahren noch in den Entwicklungsstuben des Maschinen- und Anlagenbau aus. Glücklicherweise hat sich viel geändert und eine bewusste Konzeptphase mit guter Anforderungsanalyse geben dem Projekt Struktur und ein klares Ziel. Natürlich kann immer noch etwas schiefgehen. Hier bietet eine stärkere methodische Unterstützung der Konzeptphase enormes Potential, insbesondere, wenn einfache grafische Modellierungsmethoden eingesetzt werden. Dann können einfache Methoden schon viel früher als bislang erfolgen – wie z.B. die Fehlermöglichkeitseinflussanalyse (FMEA) auf Systemebene mit dem Werkzeug iQUAVIS. Verfügbarkeit von Informationen im Wissensdschungel Trotz eines aufkommenden Bewusstseins für methodisches Arbeiten in Entwicklungsprojekten sind die zahlreichen Methoden der Produktentwicklung noch unzureichend in das Tagesgeschäft eingebunden. Für die Anwendung von Methoden sind zielgerichtete Eingangsinformationen notwendig. Diese Eingangsinformationen sind im Regelfall jedoch nicht im Unternehmen verfügbar, da sie meist personengebunden sind. Falls doch, dann sind die Projektbeteiligten meist mit der Suche nach diesen Informationen beschäftigt – lange Lasten- und Pflichtenhefte erschweren die Suche und führen mehr zu „gutem Bauchgefühl“ als einem ingenieurmäßigen Vorgehen in der Entwicklung. Das lässt die Bereitschaft zum methodischen Arbeiten sinken – mit dramatischen Folgen! Regelmäßig bestätigen Umfragen die Befunde der 1960er Jahre: Ingenieure sind immer noch gut die Hälfte ihrer Arbeitszeit mit der Suche und Organisation von Informationen beschäftigt. Vom Pflichtenheft zum Systemmodell – und weniger Risiko Gleichzeitig steigt das Risiko in der Entwicklungsarbeit, weil Entscheidungen nicht auf Basis fundierter Daten und Analysen gefällt werden können. Ursache für den Mangel an Informationen sind der starke Einsatz an dokumentenbasierten Arbeitsweisen – gerade in den frühen Projektphasen. Das heißt, alle Aufgaben und Ergebnisse, die im Entwicklungsprojekt entstehen, werden im Regelfall in Dokumenten gespeichert: Pflichtenheft, Gesprächsprotokolle, Bestellspezifikationen, Vorlagen für das Qualitätsmanagement – um nur einige Beispiele zu nennen. Die Folge: Schnell entsteht eine unüberschaubare Menge von einzelnen Dokumenten, deren Inhalte nur mit großer Mühe aktuell und konsistent gehalten werden können. In der Entwurfs- und Ausarbeitungsphase werden dann hochdigitalisierte Werkzeuge wie z.B. CAD oder Simulationen eingesetzt. So sind auf der einen Seite die Daten der Entwurfs- und Ausarbeitungsphase digitalisiert, auf der anderen Seite aber die Beschreibungen der Planungs- und Konzeptphase in gewisser Weise „analog“ und nicht ohne weiteres überprüfbar. Diese Kluft erschwert und behindert methodisches Arbeiten. Modellbasiertes Arbeiten in der frühen Projektphase kann hier die Lösung sein. Damit ist nicht die Simulation spezifischer Fragestellungen gemeint. Modellbasiertes Systems Engineering (MBSE) führt von Tag 1 an alle Aufgaben und alles Wissen rund um das Projekt zusammen und bereitet spezifische Anwendungen vor. Im sogenannten Systemmodell sind von den Anforderungen bis in die Schnittstellenbeschreibung Daten rund um das Entwicklungsprojekt gespeichert und werden für konkrete Aufgaben im Projekt von den einzelnen Projektbeteiligten genutzt. Es beschreibt mittels verschiedener Sichten die Struktur (Funktionen, Komponenten, Wirkbeziehungen,… ) und das Verhalten (Abläufe, Zustände, …) des in der Entwicklung befindlichen Systems – häufig gerne als „mechatronische Zeichnung“ bezeichnet. Mit System zur System-FMEA Wie sieht so eine FMEA auf Basis eines Systemmodells aber nun aus? Grundlegend sind ein Modellierungswerkzeug und eine dazugehörige Modellierungsmethode – beispielsweise iQUAVIS vom japanischen Engineering- und IT-Spezialisten Dentsu Soken (ehemals ISID) und die Methode CONSENS von der Fraunhofer-Gesellschaft. Startpunkt ist der sogenannten Funktionsbaum. Hier werden ausgehend von der Gesamtfunktion – z.B. „Werkstück bearbeiten“ alle notwendigen Funktionen definiert und hierarchisch heruntergebrochen. Die Funktionen werden auf die realisierenden Systemelemente gemappt. Aus diesem Zusammenspiel ergibt sich automatisch die Basis für eine FMEA: Systemelemente realisieren Funktionen, die gewisse Fehlerzustände einnehmen können. Mit CONSENS werden die notwendigen Eingangsinformationen erstellt, iQUAVIS unterstützt bei der Datenpflege und fördert die Zusammenarbeit. So lässt sich die Risikoprioritätszahl berechnen ebenso können Maßnahmen und Verantwortlichkeiten abgeleitet werden – und durch den FMEA-Verantwortlichen auch die Umsetzung kontrolliert werden. Anders als in der dokumentenbasierten Arbeitsweise kann der Funktionsbaum nun auch für viele andere Aufgaben genutzt werden. Das beginnt bei einfachen Funktionsanalysen, geht über die Unterstützung der Kommunikation der Fachleute im Projekt bis hin zur Kalkulation von Funktionskosten. So ist ersichtlich, dass methodisches Arbeiten mit den entsprechenden Werkzeugen einen Nutzen bringt und sich dadurch das Risiko in Projekten reduzieren lässt. In dem folgenden Video sehen Sie, wie eine FMEA in iQUAVIS abläuft: Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden. Mehr Informationen Inhalt entsperren Erforderlichen Service akzeptieren und Inhalte entsperren Wie und wo anfangen? Wie machen es andere? Selbstredend handelt es sich beim MBSE um eine große Veränderung für ein Unternehmen. Unsere Kunden, die den Weg ins Systems Engineering eingeschlagen haben, bestätigen uns das regelmäßig. Ihre Erfahrungen schildern sie uns in der Interview-Reihe „Wir sind Systems Engineer“. Christian TschirnerSystems Engineering ist eine Lebensart – wer sie einmal kennt, kommt nicht von ihr los! Ich brenne dafür, das Engineering zu verändern. Weg von verwirrenden Lasten- und Pflichtenheften hin zu einer modellbasierten Spezifikation. Das hilft mir, viele Aufgaben eines Projekts besser zu bewältigen, mit Kollegen ein gemeinsames eindeutiges Systemverständnis zu bilden und immer die relevanten Aufgaben im Blick zu haben. Und außerdem: Ich bin überzeugt, dass innovative Geschäftsmodelle nur mit einem solchen Ansatz möglich werden: Smarte Services, Things that think, … Let’s go together! www.two-pillars.de/