Two Pillars

Autorenname: Christian Tschirner

Systems 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!

Matthias Greinert Two Pillars

Interview mit Matthias Greinert

Matthias Greinert arbeitet als MBSE Consultant und steht unseren Kunden beratend und helfend zur Seite – persönlich und remote. Im Interview erzählt er uns ein bisschen was von sich und seiner Arbeit bei Two Pillars. Was ist Dein Lieblingsbrettspiel (Gesellschaftsspiel) und warum?Momentan spiele ich, den Umständen geschuldet, fast nur Kinderspiele (Monopoly Junior ist super). Grundsätzlich mag ich Spiele mit einem hohen Strategieanteil wie Risiko, Siedler von Catan, etc. Verschiedene Strategien auszuprobieren und die des Gegner zu durchkreuzen macht dabei den Reiz für mich aus. Was ist Dein Lieblingsgericht und warum?Ich koche tatsächlich sehr gerne, daher habe ich eigentlich nicht das eine Lieblingsgericht. Wenn ich mich heute entscheiden müsste, wäre es wohl meine selbstgemachte Pizza. Die lange Teigführung und dass ich jedes Mal ein klein bisschen besser werde macht mir Spaß und am Ende kommt ein individuell gestaltbares Gericht heraus. Aber der Hauptgrund ist wohl, dass mein Ältester sie für die beste Pizza der Welt hält. Das geht natürlich runter wie Öl (vor allem, weil er sonst fast alles blöd findet, was ich koche ?). Was ist Dein Lieblingsreiseziel und warum?Wenn ich mal reise, dann zieht es mich meist irgendwo in die Natur. Dabei hat es mir Wasser am meisten angetan. Das weite Meer, ein idyllischer See oder ein plätschernder Fluss. Entspannung pur! Kannst Du noch etwas zu Deiner Arbeit bei Two Pillars sagen? Z.B. bist Du ja auch am Projekt MoSys beteiligt…Im Forschungsprojekt MoSyS arbeite ich gemeinsam mit namhaften Partnern aus Industrie und Forschung an der Entwicklung neuer Methoden und Hilfsmittel für die Gestaltung technischer Systeme. Dabei geht es beispielsweise um Lösungsmuster im Kontext von SystemofSystems und dem Digitalen Zwilling. Die gewonnenen Erkenntnisse fließen in iQUAVIS ein, damit wir Ihnen MBSE auf dem neuesten Stand der Forschung bieten können. 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/

Interview mit Matthias Greinert Weiterlesen »

Honda modellbasierte Entwicklung

Modellbasierte Entwicklung und Traceability bei Honda – und iQUAVIS

Das Honda Automobile R&D Center begann 2008 mit der Forschung zur modellbasierten Entwicklung. Herr Hideyuki Adachi, verantwortlich für die Forschung und Entwicklung von Honda-Motoren, erklärt uns den Ansatz für die modellbasierte Entwicklung und wie er dabei auf das Werkzeug iQUAVIS gestoßen ist. „Technology Breakdown“ als Startschuss ins Systems Engineering Startpunkt für die modellbasierte Entwicklung bei Honda war die Etablierung des „Technology Breakdown“ – eine klassische Systems Engineering-Methode: Hierbei werden strukturiert Informationen über die einzelnen Funktionen und Leistungsanforderungen des Produkts zusammengetragen und mit den Designelementen gematcht, die die Anforderungen realisieren. Das matching erfolgt über explizit modellierte Beziehungen zwischen den Anforderungen und den Designelementen. „Bei der modellbasierten Entwicklung, die auf Leistungsanforderungen basiert, klären wir die relevanten Designelemente, bevor wir die notwendigen Elemente auswählen und ein Modell zur Verifizierung erstellen. Daher war dieser Technology Breakdown der erste wichtige Schritt“, erklärt Hideyuki Adachi. Wenn die modellbasierte Entwicklung realisiert wird, kann die Entwicklungsarbeit reibungslos von der vor- zur nachgeschalteten Seite des Entwurfs verlaufen. Unerwartete Nacharbeiten werden vermieden. Unser Hauptanliegen ist, Nacharbeiten zu reduzieren und mit weniger Personal das gleiche Ergebnis wie heute zu erzielen. Wenn wir dies realisieren, können wir unsere Ressourcen noch stärker der Grundlagenforschung und fortschrittlichen Technologieprojekten widmen – quasi das „Futter für morgen“. – Hideyiku Adachi, Mitglied bei INCOSE Hideyuki Adachi – Mitglied bei INCOSE – begann, die Methode des Technolgy Breakdown zu fördern. Dabei wurde ein Tabellenkalkulationstool für die Organisation von Anforderungen und Entitäten und ihrer Beziehungen verwendet. Das zog natürlich Akzeptanzprobleme mit sich – wenngleich die Methode selbst große Zustimmung fand. „Ganz gleich, wie sehr man mit dem Technology Breakdown fortfährt – es war schwierig, die Arbeitsabläufe im Verhältnis zu den Ergebnissen des Technology Breakdown zu betrachten. Es war auch schwierig, direkt das optimale Verifikationsverfahren ohne Nacharbeiten zu definieren.“ Es gibt hunderte von Elementen, die mit einer Anforderung verbunden sind. Die Entscheidung, was zuerst zu tun ist, hängt von erfahrenen Ingenieuren ab. Ein Ingenieur weiß, welche Technologie zu verwenden ist, was am besten zu tun ist und was zu welchem Zeitpunkt gut ist. Er sieht jedoch nicht alle Anforderungen des gesamten Produkts – was bei neuen Themenstellungen trotz Erfahrung Schwierigkeiten bereiten kann. Ein extremes Beispiel: ‚hohe Leistung, aber geringe Kraftstoffeffizienz‘ oder ‚geringes Gewicht, aber nicht langlebig‘ wird nicht zur Optimierung des gesamten Motors führen. Um dieses Problem zu lösen, brauchte Honda ein System, das die gesamten Beziehungen zwischen Entwurfselementen und Verifikationsverfahren von Anfang an erfasst: Stichwort „Traceability“. iQUAVIS Funktionen „Ich dachte ‚dass ist es, was wir brauchen‘, als ich iQUAVIS auf dem von ISID und iTiD consulting 2009 organisierten Seminar begegnete. Ich sah, dass das, was wir versuchten, in iQUAVIS realisiert ist.“ – Hideyiku Adachi iQUAVIS bietet Funktionen wie z.B. einen „Technology Breakdown Tree“, der die Beziehung zwischen Anforderungen und Designelementen beschreibt, ein „Functional Block Diagram“, das die logische Konsistenz zwischen den Funktionen zeigt, und eine „Korrelationsmatrix“, die die Stärke der Abhängigkeit zwischen korrelierten Elementen anzeigt. Es ist einfach, Probleme mit Hilfe dieser Funktionen zu identifizieren. Darüber hinaus sind patentierte analytische Technologien für die Untersuchung von Verfahren und die Erstellung von Zeitplänen hilfreich. Herr Adachi beschloss zunächst, einen Versuch mit iQUAVIS in der Entwicklung der Motorkalibrierung durchzuführen – dem arbeitsintensivsten Prozess. „Wir dachten, dass es einfach ist, in dieser Phase der Entwicklung Ergebnisse wie den arbeitsreduzierenden Effekt zu erzielen“, sagte Herr Adachi. Als Vorbereitung auf die Eingabe von Daten in iQUAVIS schloss sich iTiD Consulting Herrn Adachi und den Ingenieuren jeder Abteilung an und führte 5 Monate lang zweimal wöchentlich vierstündige Workshops zur Organisation von Informationen durch. „In dem Workshop definierten wir Beziehungen und den Grad der Abhängigkeit von allen Kombinationen von Anforderungen und Elementen, was mehr als mehrere tausend Knotenpunkte umfasste, als ein Werk des Technologiezusammenbruchs“, erinnert sich Herr Adachi, „iQUAVIS ermöglichte es uns, sofort zu wissen, welche Aufgabe und in welcher Reihenfolge wir arbeiten sollten und wie viel Zeit wir dafür benötigen. Darüber hinaus ermöglichte es uns iQUAVIS, die Auswirkungen der Investition zusätzlicher Ressourcen zu berechnen. Wenn zum Beispiel ein Problem gefunden wird, muss man wissen, wie lange die Neugestaltung dauern wird. Es ist möglich zu schätzen, dass es 11 Monate dauert, wenn die Aufgaben in serieller Reihenfolge ausgeführt werden, oder etwa 6 Monate, wenn Sie die Lieferung ohne Einschränkung der Ressourcen priorisieren. Da sie mit Aufträgen verbunden ist, ist diese Schätzung sehr genau und effektiv für die Entwicklung des Risikomanagements.“ Herr Adachi weist auf den Sinneswandel der Ingenieure hin, der nicht nur durch QUAVIS, sondern auch durch die Workshop-Erfahrungen herbeigeführt wurde. „Durch die Workshops haben wir die Fähigkeit erlangt, unsere Arbeit objektiv zu sehen. Um unsere Organisation wachsen zu lassen, müssen wir die gegenwärtige Situation objektiv bewerten und herausfinden, was als nächstes zu tun ist. Es hat vielleicht nicht so direkte Auswirkungen wie iQUAVIS, aber ich glaube, dass der Workshop auch einen großen Wert hatte, der uns eine objektive Perspektive brachte. 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/

Modellbasierte Entwicklung und Traceability bei Honda – und iQUAVIS Weiterlesen »

Dr. Christian Bremer Two Pillars

Interview mit Dr. Christian Bremer

Im heutigen Interview stellt sich Dr. Christian Bremer vor, Geschäftsführer und Gründer von Two Pillars. Was ist Deine Position bei Two Pillars? Welche Tätigkeiten übst Du dort aus?Ich bin einer der Gründer von Two Pillars, Geschäftsführer und verantwortlich für Forschung und Entwicklung. Das heißt ich koordiniere zum Beispiel unsere Arbeit in Forschungsprojekten aber auch unsere Entwicklungen. Dabei versuchen wir zum einen vorauszuschauen, und neue Anwendungsfälle umzusetzen, zum anderen aber auch, Anwenderfeedback einzuholen um unser Produkt – iQUAVIS – immer weiter zu verbessern. Warum arbeitest Du gerne für Two Pillars?Bei Two Pillars kann ich im Prinzip das in einem Software-Werkzeug umsetzen, was ich zuvor am Fraunhofer-Institut zum Thema MBSE erarbeitet habe. Das ist einfach eine spannende Aufgabe! Was macht Two Pillars für Dich besonders?Two Pillars ist ein junges Unternehmen, in dem wir viel gestalten können. Die Mitarbeiter haben ein breites Tätigkeitsprofil, das macht die Arbeit hier bei Two Pillars total abwechslungsreich. Außerdem sind wir ein tolles Team, das sich gegenseitig motiviert. Welchen Freizeitaktivitäten gehst Du nach?Ehrlich gesagt ist meine Freizeit hauptsächlich meinen Kindern gewidmet, da bleibt dann neben dem Beruf wenig Zeit für Hobbys im eigentlichen Sinn. Wenn ich doch mal Zeit finde gehe ich gerne Klettern, insb. Bouldern. 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/

Interview mit Dr. Christian Bremer Weiterlesen »

Georg Kaczmarek Softwareentwickler

Interview mit Georg Kaczmarek

Unser Softwareentwickler Georg Kaczmarek verrät uns im Interview, warum er gern bei Two Pillars arbeitet und erklärt, wie er iQUAVIS weiterbringt. Guten Tag, Georg! Wie geht’s dir und was machst du so bei Two Pillars?Hallo, mir geht’s gut. Also ich bin Softwareentwickler! Und was mache ich natürlich? Ich entwickele die iQUAVIS Software weiter durch Module und Plugins. Und natürlich kümmere mich generell um alle anfallenden Softwarethemen. Kannst du auf deine Tätigkeit noch etwas genauer eingehen? Gibt es ein Symbol oder Gegenstand, der deine Tätigkeit hier beschreibt?Also da habe ich hier mal einen selbstgebauten Prozessor: Den habe ich mir selbstständig erarbeitet und eben diesen Prototypen zusammengestellt. Genauso ist es auch mit allen anfallenden Softwarethemen. Ich sammle erst das nötige Verständnis und setze es dann in die Tat um. Softwarewünsche verstehen, in Code übersetzen und diesen weiterentwickeln, das ist, was ich mache. Kurze Zwischenfrage: Kaffee oder Tee?Ich trink meinen Kaffee immer schwarz! Two Pillars, das ist ja jetzt nicht nur eine Person. Was würdest du sagen: Wie schätzt du das Team ein und gibt es etwas, das du ganz besonders daran schätzt?Also was ich hier am meisten schätze, ist auf jeden Fall das freundliche Miteinander. Man kann auch über Alltägliches mit den Kollegen sprechen. Meist entstehen so interessante Diskussionen, die mich in meiner Arbeit weiter motivieren und vorantreiben. Chefs und Mitarbeiter sind per du. Insgesamt haben wir hier flache Hierarchien, die das Arbeiten noch angenehmer machen. Das hört sich echt spannend an. Du hast das Thema Motivation angesprochen. Gibt es etwas, was das dich antreibt oder dich persönlich auszeichnet und dir im Arbeitsalltag weiterhilft? Ja auf jeden Fall. Das gibt es! Ich spiele schon seit Jahren das Brettspiel Go. Es ist ein Hobby von mir, bei dem ich gelernt habe, dass es nicht immer nur eine Lösung zum Erreichen des Ziels gibt. Man muss also ständig an sich arbeiten, da man nie das Ziel der Perfektion erreichen kann, es geht immer irgendwie besser. Bei der Arbeit sieht es ähnlich aus, man muss am Ball bleiben, innovativ sein, um weiterzukommen und nicht stehenzubleiben und Trends und Neuerungen nicht zu verpassen. Kannst du aus deiner Erfahrung einem Neueinsteiger mit einem ähnlichen Interesse Tipps geben?Naja, klar! Am Ball zu bleiben ist das Wichtigste, aber auch versuchen immer offen für neues zu sein und dabei darf man dann auch nicht zu selbstkritisch sein. Generell eine Selbstreflexion dessen, was man tut, ist gut. Nur so kann man über sich selbst hinaus wachsen, Neues kennenzulernen und Spaß an der Entwicklung haben. Das ist sehr weise. Bestimmt hilft dies Neueinsteigern weiter. Jetzt ist die Zeit leider schon etwas fortgeschritten. Aber sag uns doch noch kurz, was sind deine Ziele, die du für dich in Zukunft bei Two Pillars umsetzen willst?Also mein Ziel ist es, die Softwareentwicklung des Unternehmens weiterzubringen und mit meinen Kenntnissen zur Steigerung des Funktionsumfangs von iQUAVIS beizutragen. Ich wünsche dir viel Erfolg dabei dies in die Tat umzusetzen. Besten Dank für das Interview. Machs gut!Danke, hat mir Spaß gemacht. Dann wollen wir die Tasten mal wieder zum Glühen bringen! 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/

Interview mit Georg Kaczmarek Weiterlesen »

FMEA Maschinenbau

FMEA: So vermeiden Sie Risiken in der Produktentwicklung

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/

FMEA: So vermeiden Sie Risiken in der Produktentwicklung Weiterlesen »

MBSE Software iQUAVIS

So meistern Sie mechatronische Projekte mit MBSE

Kennen Sie das? Sie schreiben in einem klassischen Textverarbeitungsprogramm ein Kundenangebot. Sie geben eine Struktur vor, in der alle bekannten Informationen gesammelt werden. Doch schnell wird es unübersichtlich. Ihr Entwicklungsprojekt hängt zwischen Anforderung und Management, und es kommt zu schwer identifizierbaren Widersprüchen. Als Ingenieur laufen Sie den Informationen hinterher und bemühen sich in mühseliger Kleinarbeit, Anforderungen, Lösung und Kosten zu erfassen. Mit MBSE und der passenden MBSE Software erleichtern Sie sich den Arbeitsalltag und sorgen für gut vorbereitete und laufende Projekte – gerade in der Entwicklung mechatronischer Projekte. Produktivität mit MBSE steigern Top-ausgebildete Mitarbeiterinnen und Mitarbeiter schaffen mit den etablierten Herangehensweisen trotzdem immer wieder das Unmögliche – aber genau genommen doch nicht so schnell und nur mit viel Aufwand: Kommt dann der Auftrag, wird wieder von Null gestartet. Das Lastenheft wird aufgrund seiner Unübersichtlichkeit im wahrsten Sinne des Wortes zur Last. Da häufig ein sog. Systemkonzept nicht explizit erstellt wurde, kommt es zu zeit- und kostenintensiven Abstimmungen, Nacharbeiten und schlimmstenfalls verspäteter Auslieferung – Überstunden häufen sich. Modellbasiertes Arbeiten in der frühen Projektphase kann hier die Produktivität steigern. Damit ist nicht die Simulation spezifischer Fragestellungen gemeint; Modellbasiertes Systems Engineering (MBSE) führt je nach Ausgestaltung von Tag 1 an alle Aufgaben und alles Wissen rund um das Projekt zusammen und bereitet spezifische Anwendungen vor. Das heißt, auch die Simulation wird unterstützt und strukturiert geplant. Aber: Grundsätzlich wird im MBSE mit graphischen Herangehensweisen das Produkt spezifiziert und die notwendigen Ergebnisse des Entwicklungsprozesses erzeugt; z.B. FMEA oder das notwendige Parameterset für die Simulation – nur für alle verständlich. Damit das gelingt, bringen gute Systems Engineering-Werkzeuge die zwei Kernelemente erfolgreichen Engineerings zusammen: Systemarchitekturentwicklung und Projektmanagement, wie es z.B. das Werkzeug iQUAVIS ermöglicht. Dadurch werden eindeutige Anforderungen, aussagekräftige Pflichtenhefte, widerspruchsfreie Spezifikationen und eine barrierefreie Zusammenarbeit möglich. Gerade herausfordernde mechatronische Entwicklungsprojekte werden so regelrecht mit einem Booster versehen. MBSE Software iQUAVIS Viele MBSE-Werkzeuge stammen aus der Softwareentwicklung. Studien von der Fraunhofer-Gesellschaft haben gezeigt, dass dadurch große Anwendungsbarrieren aufgebaut werden. Solch neuartige Werkzeuge sollen unterstützen und nach einer kurzen Einarbeitungsphase sich wie selbstverständlich in den Prozess einfügen. In einer wissenschaftlichen Veröffentlichung konnte gezeigt werden, dass iQUAVIS da anders aufgestellt ist; es kommt aus den maschinenbaulichen Anwendungsdomänen. Zusammengeflossen in iQUAVIS sind ursprünglich Werkzeuge aus den Bereichen Qualitäts-, Projekt- und Risikomanagement, also Themen, die gerade in der Mechatronikentwicklung essentiell sind. So ist es nicht verwunderlich, dass iQUAVIS für ISID Quality Visualisation steht. Bislang nur in Japan verfügbar – mit über 50.000 Installationen in wenigen Jahren – wird iQUAVIS seit Juli 2018 auch in der D-A-CH-Region über den Systems Engineering-Spezialisten Two Pillars GmbH vertrieben, mit einer Spezialisierung auf den Maschinen- und Anlagenbau. Kern von iQUAVIS ist eine einfache Systemmodellierung. Wie in einer Office-Anwendung können komplexe Produkte einfach und intuitiv modelliert werden – ohne die Untiefen der SysML oder anderer Modellierungssprachen zu verstehen. Im sogenannten Systemmodell sind die Anforderungen, die Struktur und das Verhalten des betrachteten Systems enthalten. Die verschiedenen Daten und Informationen sind miteinander verknüpft. Die Darstellung und Bearbeitung kann auf unterschiedliche Weisen erfolgen – in Form von Diagrammen, Tabellen oder Matrizen. Durch die frühzeitige Modellierung von Produkthierarchien und Produktstrukturen – inklusive der notwendigen Zusammenhänge – wird auch das Projektmanagement möglich – Ressourceneinsatz, Nachverfolgung von Aufgaben, Issue-Tracking und Kommunikation ohne Umwege über andere Systeme. Um das interdisziplinäre Systems Engineering zu etablieren, werden Rollen definiert, die das Projekt vorantreiben. Arbeiten in der Cloud Immer wichtiger in der Zusammenarbeit wird dabei, dass Software in einer Cloud bereitgestellt wird. So kann überall und jederzeit auf wichtige Informationen zugegriffen werden – und auch aktuell. Für den europäischen Markt setzen sich immer mehr die Anwendungen von Microsoft durch: die „MS Azure Cloud“ – sie überzeugt durch ihre Kostenstruktur und höchste Sicherheitsanforderungen. Um nicht zu stark abhängig von der Bandbreite der Internetverbindung zu sein, sind vollständig cloudbasierte Lösungen nicht immer Mittel der Wahl. Ist die Software als „Cloud-Client-Konzept“ ausgelegt, können mit einem schlanken Client spezielle Operationen unterstützt werden. Prozesse und Datenspeicherung liegen in der Cloud, arbeiten ist aber dennoch möglich. Damit steht dank MBSE klaren und nachvollziehbaren Anforderungen von Tag 1 über das gesamte Projekt nichts mehr im Wege. Die Vorteile liegen auf der Hand: Viele Werkzeuge sind am Markt verfügbar. So leicht der Einsatz von Werkzeugen wie iQUAVIS ist, ganz ohne Unterstützung von außen kann es dennoch nicht komplett funktionieren. Grundsätzlich gilt, dass ein Thema wie MBSE nicht ohne externe Expertenbegleitung starten sollte – sich langfristig aber natürlich selbst steuern muss: Die Japaner sagen dazu: erst ichigan dann hitoridachi. 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/

So meistern Sie mechatronische Projekte mit MBSE Weiterlesen »

Das Systemmodell mit iQUAVIS

In diesem Artikel geben wir Ihnen einen Überblick über das Systemmodell mit iQUAVIS. Dabei gehen wir fokussiert auf das Modellkonzept ein. Zur methodischen Erarbeitung eines Systemmodells bietet sich bspw. die Methode CONSENS an, die wir in einem separaten Beitrag erläutern. Grundstruktur: Anforderungen, Struktur und Verhalten Für eine umfassende Systemmodellierung müssen unterschiedliche Sichten auf das zu entwickelnde System berücksichtigt werden. Diese beschreiben verschiedene Blickwinkel auf das System. Grundsätzlich kann man dabei die Blickwinkel Anforderungen, Struktur und Verhalten unterscheiden. Für diese Blickwinkel gibt es jeweils spezifische Sichten, die die Erarbeitung und Nutzung der Informationen ermöglichen. Für den Blickwinkel Anforderungen kommen grundsätzlich Baumstrukturen in Frage (die übrigens auch gut tabellarisch abgebildet werden können). Dabei werden in der Regel verschiedene Modellelemente für Anforderungen und für Tests genutzt. Diese werden zum einen untereinander verknüpft. Zum anderen werden sie mit allen verschiedenen Modellelemente aus dem Bereich Struktur oder Verhalten verknüpft, um so die Traceability in den Rest des Systemmodells zu ermöglichen. Für den Blickwinkel Struktur werden in der Regel Blockdiagramme bzw. (in iQUAVIS) Entitäten als Modellelemente genutzt. Eine Entität stellt ein Lösungselement dar, das aus verschiedenen Domänen kommen kann. Es kann ein physischen Bauteil repräsentieren oder ein Softwareelement oder ähnliches. Im Bereich der Struktur können wiederum unterschiedliche Blickwinkel eingenommen werden, die zum Beispiel das Umfeld oder die interne Struktur in den Fokus nehmen. Für den Blickwinkel Verhalten gibt es zahlreiche Beschreibungstechniken. Typisch sind Sequenzdiagramme, die einen konkreten Ablauf präzise beschreiben, mithin die Formalisierung eines Use-Case Beschreibung darstellen. Funktionsabläufe bzw. Aktivitätsdiagramm stellen einen gewünschten Ablauf mit allen möglichen Alternativen dar. Zustandsdiagramme werden genutzt, um die Betriebszustände des modellierten Systems zu definieren. Innerhalb eines Zustands wird das Verhalten, das zuvor mit Aktivitätsdiagrammen beschrieben wurde, aufgerufen. Entscheidend ist, die erwähnten Diagramm bzw. Beschreibungstechniken nicht nur einzeln zu betrachten, sie stellen für sich immer nur eine Sicht auf das Systemmodell dar. Das Systemmodell beinhaltet auch Verknüpfungen zwischen den Modellelementen, die die Traceability ermöglichen. So sind bspw. die Use-Cases jeweils mit einem Umfeldelement verknüpft. Die Wirkstruktur ergibt sich aus der Fokussierung auf eine Entität (typischerweise auf das zu modellierende System). Das Sequenzdiagramm ist häufig eine Ausdetaillierung eines Use-Cases und folglich mit ebendiesem verknüpft. Zustände verweisen auf Systemelemente, in denen sie laufen und auf Aktivitätsdiagramm, die sie aufrufen. Diese Aktivitäten werden ihrerseits wieder durch (andere) Systemelemente ausgeführt und daher allokiert. Anforderungen können auf verschiedene der genannten Modellelemente verknüpft werden, wobei sich bewährt hat, sie (nur) auf Funktionen oder Entitäten zu verbinden. Verkettung R-F-L-P Wie angedeutet ermöglicht das Systemmodell vielfältige Verknüpfungen. Um hier einen strukturierten Ansatz zu finden hat sich das R-F-L-P Konzept etabliert. Es verknüpft Anforderungen (R) mit Funktionen (F), diese wiederum mit Logischen Elementen (L), welche schließlich auf die physischen Elemente (P) verknüpft werden. Der Aspekt Anforderungen ist grundsätzlich in das Konzept des Requirements Engineering zu integrieren. Daher sind Quellen für Anforderungen insb. die Umfeldanalyse sowie die Use-Case-Betrachtung. Auch Testfälle sind im Prinzip Bestandteil der Anforderungsbetrachtung. Anforderungen werden dann auf die Funktionen verknüpft, die diese umsetzen. Dabei ist der Umgang mit funktionalen Anforderungen recht intuitiv. Auch nicht-funktionale Anforderungen können teilweise auf Funktionen verknüpft werden, wenn sie bspw. die Performance einer Funktion präziseren. Im Fall anderer Anforderungen wie bspw. einer Farbe ist dies nicht unbedingt sinnvoll machbar. An dieser Stelle ist die Verknüpfung direkt auf ein Systemelement möglich. Die Logische Beschreibung stellt eine Zwischenebene dar, zwischen der lösungsneutralen Definition von Funktionen und der konkreten Benennung eines Bauteils auf physischer Ebene. Sie bietet die Chance, Bauteile zusammenzufassen, die räumlich im System verteilt sind. Ebenso können Abhängigkeiten (in Form von Informations-, Energie- und Materialflüssen) zwischen den logischen Elementen analysiert werden. In einer frühen Projektphase werden logische Elemente eher im Sinne von Wirkprinzipien angelegt. Beispielsweise könnte eine Hubbewegung beabsichtigt sein, durch einen mechanischen Scherenhub oder einen pneumatischen getriebenen Zylinder realisiert werden könnte. Solche Konzeptentscheidungen würden das System maßgeblich verändern. Es gilt daher, eine entsprechende Analyse auf logischer Ebene zu machen. Mit fortschreitendem Projektverlauf wird das Wissen über die logischen Elemente präziser. Sie sollten soweit gepflegt werden, wir es für ein konsistentes Systemmodell notwendig ist. In einer solchen späteren Phase im Projekt dienen logische Elemente häufig auch der Moduldefinition. Wichtig ist, sie logische Elemente nur soweit herunterzubrechen, dass die modellierte Information für mehr als eine Disziplin relevant ist. Findet man sich in einer Situation wieder, in der man eigentlich nur noch Informationen modelliert, die nurnoch für eine Disziplin relevant ist, gehört das in die physische Ebene. Die Definition der physischen Systemelemente erfolgt in der Regel im Bereich der CAD Werkzeuge und wird entsprechend durch PDM/PLM Werkzeuge organisiert. Das Systemmodell in iQUAVIS wird daher in der Regel auf ein solches Werkzeug verknüpft, auf Basis entsprechender Werkzeugintegrationen. 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/

Das Systemmodell mit iQUAVIS Weiterlesen »

MBSE

Was ist MBSE?

Was ist eigentlich MBSE? In diesem Artikel gehen wir auf die Grundlagen des Modul Based Systems Engineering ein und erklären das Grundprinzip dahinter. Traditionell basiert Produktentwicklung im Idealfall auf gut gelenkten Dokumenten, wie z.B. dem Lastenheft in Word – was jedoch an die Grenzen der Leistungsfähigkeit in heutigen Entwicklungsprojekten und -organisationen stößt. Die voranschreitende Entwicklung der Informations- und Kommunikationstechnik hat in Verbindung mit den für die verteilte globale Wertschöpfung nicht geeigneten Ansätzen der „Powerpoint-Entwicklung“ die Idee eines modellbasierten Systems Engineerings hervorgebracht: Model-Based Systems Engineering (MBSE). MBSE: Model-Based Systems Engineering Anders als in der weitgehend etablierten modellbasierten Entwicklung – repräsentiert beispielsweise durch CAD, FEM und auch durchaus Ansätzen wie Modelica – stehen im MBSE nicht fachdisziplinspezifische Artefakte im Mittelpunkt, sondern eine fachdisziplinübergreifende Beschreibung des Systems: das Systemmodell. Je nach Ausgestaltung soll dies von allen Disziplinen für unterschiedliche Zwecke genutzt werden. Meistens wird es für das Anforderungsmanagement als Hauptanwendungszweck genutzt, aber im Kern geht es um die Systemarchitektur zur Beschreibung der Wirkungsweise eines mechatronischen Systems inkl. seines Verhaltens. MBSE ist damit die Weiterentwicklung des klassischen Systems Engineering – häufig wird es kurz definiert als „die formalisierte Anwendung von Modellen zur Unterstützung sämtlicher Aufgaben im Produktlebenszyklus“. Das Systemmodell unterstützt dabei grundsätzlich die Zusammenarbeit und Kommunikation aller im Projekt vertretenen Disziplinen; und das bereits sehr früh im Projekt – im Prinzip von der ersten Sekunde an. Aber langsam: Model-Based Systems Engineering liefert Methoden, mit denen Systemdenken wirksam unterstützt werden kann und auch abstraktes Wissen gesichert werden kann. Mit dem Systemmodell soll von Beginn des Lebenszyklus eine fachdisziplinübergreifende Systemspezifikation konsistent beschrieben und genutzt werden. Laut INCOSE ist MBSE “the formalized application of modeling to support system requirements, design, analysis, verification, and validation, beginning in the conceptual design phase and continuing throughout development and later life cycle phases” [INC07] Anwendung von MBSE Damit ist der Anwendungszweck des MBSE sehr breit gefasst. Zunächst kann es dazu dienen, das Planen und Klären der Aufgabe zu unterstützen. Wir empfehlen, bereits mit dem Produktmanager oder dem Vertrieb im Sinne des MBSE zusammenzuarbeiten. So können Kundenbedürfnisse viel leichter und eindeutiger in erste technische Spezifikationen übersetzt werden. So wird sukzessive eine Systemarchitektur entwickelt und die Modul- und Komponentenspezifikation vorangetrieben – und hierauf aufbauend wieder neue Aufgaben in der Projektarbeit ausgesteuert werden. Nach obiger Definition müsste das Systemmodell sich im Verlauf eines Lebenszyklus jedoch auch weiterentwickeln – je nach verfolgtem Zweck. Die möglichen Anwendungszwecke sind mannigfaltig! Ein guter Freund von uns – Rob Cloutier – sagt immer: Modellierung als Grundlage des MBSE ermöglicht Mit diesem Verständnis wird deutlich: MBSE ersetzt nicht die Modelle der Fachdisziplinen, sondern ergänzt sie. Zudem ist über die rein technische Sicht auch eine sozio-technische Komponente des MBSE erkennbar. INCOSE ist überzeugt, dass sich das MBSE als zentrales Paradigma der Systementwicklung etablieren wird. Versteht man MBSE als logische Weiterentwicklung des klassischen Systems Engineerings ist es im Einklang mit den Normen wie z.B. der ISO/IEC15288 auch Grundlage für die zahlreichen technischen oder techniknahen Managementaktivitäten im Lebenszyklus und damit viel stärker an den Entwicklungsprozess gekoppelt als häufig diskutiert. Damit werden die zwei Säulen des Systems Engineering, schön dargestellt mit dem „SE-Männchen“, auch nachvollziehbar, auf denen komplexe Projekte erfolgreich aufbauen: Systemarchitekturentwicklung und Projektmanagement. Wie geht MBSE eigentlich? – TUN ist unsere Antwort. So leicht ist es natürlich nicht, daher hier einmal noch ein Einblick in die absoluten Basics der Ansätze: Zur Erstellung des Systemmodells als Kern des MBSE bedarf es einer Beschreibungssprache, einer Methode und eines Werkzeug – z.B. iQUAVIS. Und motivierte Mitarbeiter, die etwas verändern und verbessern wollen! Trotz einiger Unklarheiten hinsichtlich des Begriffs „Systemmodell“ – über die Inhalte des Systemmodells herrscht weitgehend Einigkeit: Systemanforderungen, Systemarchitektur und Systemverhalten, nachfolgend noch einmal kurz erklärt. Systemanforderungen Es werden funktionale und nichtfunktionale Anforderungen unterschieden. Funktionale Anforderungen spezifizieren das Verhalten des Systems und dessen Komponenten. Nichtfunktionale Anforderungen definieren Eigenschaften eines Systems wie Zuverlässigkeit, Benutzbarkeit oder Änderbarkeit. Systemarchitektur Die Architektur beschreibt die Struktur des Systems und seiner Komponenten, ebenso die Schnittstellen zwischen den Komponenten und zu den Systemgrenzen. Für den Bereich des Maschinenbaus umfasst das häufig auch erste Gestaltinformationen, z.B. in Form von Hüllkurven oder Skizzen. Systemverhalten Durch die Architektur und die funktionalen Anforderungen ist das System beschrieben. Anforderungen sind jedoch häufig informale Textdokumente. Durch eine Formalisierung könnten Informationen rechnergestützt abgeleitet werden. Dies ist Aufgabe der Modellierung des Systemverhaltens. Inhaltlich sollte das Systemmodell mindestens die fachdisziplinübergreifend relevanten Informationen der Entwicklungsaufgabe enthalten. Genau genommen müssten das auch die für mehrere Disziplinen relevanten fachdisziplinspezifischen Daten sein – also sämtliche vom Systems Engineering betroffenen Disziplinen. Wie Sie dann in die Produktentwicklung mit iQUAVIS starten, erfahren Sie in dem verlinkten Beitrag. Modellierungssprachen des MBSE Wie in einer echten Sprache unterliegt der Aufbau einer Modellierungssprache gewissen Regeln. Dies sind die entsprechende Syntax und Semantik: Syntax Die Syntax legt fest, wie die einzelnen Systemelemente in ihrer Art und in ihrem strukturellen Aufbau gestaltet sind. Die abstrakte Syntax ist das Regelsystem, das die Elemente und Bezeichnungen der Sprache definiert. Ähnlich zur natürlichen Sprache (Wörter, Buchstaben, …) sind es in den Modellierungssprachen Systemelemente, Ports, Merkmale der Elemente und die Beziehungen der Elemente untereinander. Die konkrete Syntax ist die grafische Repräsentation der abstrakten Syntax. Mit ihr werden grafische Modelle erstellt, deren Elemente auf die Elemente der abstrakten Syntax verweisen. Semantik Die Semantik legt fest, wie Modellkonstrukte miteinander verknüpft werden müssen, um eine Bedeutung zu haben (statische Semantik). Dies geschieht durch Bedingungen gegen die abstrakte Syntax. Die Bedeutung der Modellkonstrukte ist in der dynamischen Semantik enthalten. Modellierungsmethoden des MBSE („MBSE-Methoden“) Eine Modellierungsmethode definiert die Abfolge von Operationen, die zur Erstellung der einzelnen Modelle durchgeführt werden. Der Ablauf der meisten MBSE-Methoden orientiert sich an den Schritten Anforderungsdefinition, Design, Analyse, Verifikation und Validierung. Die Modellierungsmethode muss klar definieren, welche Informationen zu welchem Zeitpunkt wie detailliert notwendig sind – was jedoch eher die Ausnahme ist, da die Tiefe der Modellierung weder in Sprache noch in Methode vorgegeben sind. Grundsätzlich muss daher neben der Leistungsfähigkeit einer Modellierungsmethode auch immer ihre Wirtschaftlichkeit berücksichtigt werden. Sie enden mit der Erstellung der Architektur. Werkzeuge im MBSE Mit dem zur Erstellung des Systemmodells notwendigen Werkzeug wird häufig eine Software-Lösung in Verbindung gebracht. Und auch

Was ist MBSE? Weiterlesen »

Nach oben scrollen