34. Annual INCOSE International Symposium
Wir nehmen am 34. jährlichen INCOSE International Symposium in Dublin, Irland, teil. Mehr Informationen zu diesem Event finden Sie hier.
34. Annual INCOSE International Symposium Read More »
Suchergebnisse für: incose
Veranstaltungen Two Pillars
Veranstaltungen und Events Sie möchten uns persönlich kennenlernen? Wir bieten über das Jahr verteilt viele Gelegenheiten, persönlich mit uns in Kontakt zu kommen: Wir sind als Gast und Gastredner, als Aussteller und auch als Gastgeber bei vielen Events, Messen, Symposien und weiteren Veranstaltungen rund um Systems Engineering anzutreffen. Auf dieser Seite erhalten Sie einen Überblick über künftige und vergangene Events, unsere Webinare und sonstige Veranstaltungen, bei denen Sie Two Pillars persönlich antreffen. Save the Date: SE Get Together Wir laden gemeinsam mit der GfSE (Gesellschaft für Systems Engineering) zum Get Together in Paderborn ein: Die Veranstaltung ist kostenlos, für Snacks und Getränke ist gesorgt. Der nächste Termin ist: 10.10.2024 Weitere Informationen folgen Kommende Events und Webinare Auf diesen Veranstaltungen treffen Sie Two Pillars als nächstes. Lernen Sie uns und iQUAVIS kennen! Webinare zum Download Sie haben ein Live-Webinar verpasst? Kein Problem! Hier haben Sie die Chance, sich die Aufzeichnung anzusehen. All Posts Erfolgsgeschichten Forschung und Lehre iQUAVIS MA Interview MBSE News Veranstaltungen Back Anwendungsbeispiele Updates Back Wir sind Systems Engineer Lernen Sie den VariantenManager kennen – kostenloses Webinar 30. April 2024/ Varianz potenziert die Produktkomplexität um ein Vielfaches. Der VariantenManager hilft, diese Komplexität zu beherrschen. Der VariantenManager ist ein zusätzliches Feature für unsere MBSE-Software iQUAVIS, der dazu dient, Beziehungswissen abzubilden, Varianten… Weiterlesen Systems Engineering mit iQUAVIS – kostenloses Webinar 13. Februar 2024/ Systems Engineering ist ein ganzheitlicher und interdisziplinärer Ansatz für die Produktentwicklung und das Projektmanagement. Unser Consultant und MBSE-Experte Matthias Greinert hat in einem Live-Webinar über “Systems Engineering mit iQUAVIS” gezeigt,… Weiterlesen Veranstaltungsarchiv All Posts Veranstaltungen TdSE 2023 – Two Pillars wieder dabei 11. August 2023/ Unter dem Titel “Zukunft braucht Mut” findet der TdSE 2023 vom 15. bis 17. November in Würzburg statt. Auch Two Pillars ist als Sponsor und langjähriges Mitglied der GfSE mit einem Ausstellerstand… Weiterlesen Tag des Systems Engineering 2022 – Two Pillars ist PLATIN-Partner 2. September 2022/ Der “Tag des Systems Engineering – TdSE” ist die wichtigste Veranstaltung der deutschsprachigen Systems Engineering-Community und feiert in diesem Jahr seinen 25. Geburtstag. Da ist klar: Two Pillars unterstützt auch… Weiterlesen R-F-L-P – Close the gap! Übergang von MBSE ins PLM mit iQUAVIS und CONTACT Elements 2. September 2022/ Two Pillars stellt sich innerhalb des MoSys-Projekts der Aufgabe, die R-F-L-P-Lücke mithilfe des Variantenmanagers in iQUAVIS zu schließen. Seit 2018 entwickelt Two Pillars gemeinsam mit dem japanischen IT-Konzern ISID das… Weiterlesen OWL MASCHINENBAU Kongress 2022: Vortrag mit HARTING Applied Technologies 2. September 2022/ Der OWL Maschinenbau Kongress fand am 18. August 2022 statt. Zum 20. Mal hat hat der owl maschinenbau e.V. eingeladen – in diesem Jahr nach Lemgo. Neben vielen Vorträgen mit… Weiterlesen Two Pillars auf der EMEASEC 2018 in Berlin 10. September 2018/ Vom 5. bis 7. November 2018 findet in Berlin im Hotel Mercure die EMEA Sector Systems Engineering Conference 2018 statt. Weiterlesen PM Forum 2018 8. September 2018/ Der bedeutendste Fachkongress für Projektmanagement im europäischen Raum erwartet auch in diesem Jahr wieder rund 1.000 PM-Entscheider und Projektverantwortliche. Weiterlesen
Veranstaltungen Two Pillars Read More »
TdSE 2023 – So entwickelte sich die größte SE-Konferenz – Interview
Unter dem Titel „Zukunft braucht Mut“ findet der TdSE 2023 vom 15. bis 17. November in Würzburg statt. Wir freuen uns schon sehr auf das interessante Programm, gute Vorträge und den Austausch mit anderen Systems Engineering Experten. Im Interview erinnert sich unser Geschäftsführer Dr. Christian Tschirner, der selbst jahrelang Hauptorganisator war, an die Anfangszeit des TdSE: „Zukunft braucht Mut“ – Tag des Systems Engineering 2023 in Würzburg Der TdSE findet jährlich statt und ist die Konferenz für Systems Engineering. Hier treffen sich Interessierte, Entscheider und natürlich Experten zum Thema aus verschiedenen Branchen und Bereichen: Vertreter aus Industrie, Forschung und Dienstleistung haben hier die Chance auf einen regen Austausch, der über den Tellerrand des Tagesgeschäfts hinausblickt. Teilnehmer der Konferenz sind z.B. Projektleiter, Innovationsmanager, Systems Engineers oder Systemarchitekten. Veranstaltet wird der TdSE von der GfSE, der Gesellschaft für Systems Engineering, der deutschen Sektion des International Council on Systems Engineering (INCOSE). Auch internationale Gäste „verirren“ sich immer häufiger auf die deutschsprachige Veranstaltung – bspw. aus Japan. Die Welt schaut auf Deutschland und seine Systems Engineering-Kompetenz. Interview mit Dr. Christian Tschirner zum TdSE damals und heute Sonja Feierabend Hallo Christian, als ehemaliger stellvertretender Vorsitzender der GFSE hast du lange den TdSE, den Tag des Systems Engineering, mitorganisiert. Wenn du dich jetzt mal so an die Anfangszeit zurückerinnerst, wie war das so? Erzähl doch mal. Christian Tschirner Die richtige Anfangszeit kenne ich gar nicht – aber ich habe 2010 in München und 2011 in Hamburg zum ersten Mal am TdSE teilgenommen und das ist für die Industrialisierung des SE in anderen Branchen als der Luft- und Raumfahrt tatsächlich im gewissen Sinne die „Anfangszeit“. Wir wollten damals in Paderborn das Thema Systems Engineering stärker auf unsere Forschungsagenda aufnehmen, mein Doktorvater, Jürgen Gausemeier, hatte mir damals die Aufgabe gegeben. Irgendwie hat es mich dann in den Fingern gejuckt, den TdSE auch einmal in Paderborn zu haben. So habe ich dann den Tag des Systems Engineering 2012 organisiert. Das war im Rahmen unserer Aktionen zum sogenannten „Advanced Systems Engineering“. Das ist ein Begriff, der heute in der Community schon recht weit verbreitet ist. Ich erinnere mich daran, dass ich als Neueinsteiger in die Community eine wunderbare Unterstützung erfahren habe, da diese Konferenz das zentrale Element der Systems Engineering Community in Deutschland, Österreich und der Schweiz ist. Was ich damals noch nicht so geahnt habe, war, dass aus den 90 Teilnehmern in Hamburg direkt mehr als 150 in Paderborn wurden. Das war ein großartiges Erlebnis, denn viele Leute haben zu dem Zeitpunkt noch gar nicht über Systems Engineering nachgedacht. In Paderborn war das erste Mal eine wichtige Schallmauer durchbrochen. In den Folgejahren habe ich die Organisation des TdSE dann irgendwie zufällig immer weitergemacht – es hat ja auch Spass gemacht. Aber da wurde es dann richtig anstrengend irgendwann, als die Teilnehmerzahlen Richtung 400 Teilnehmern wuchsen. Das ist eine stattliche Größe ist für eine auch heute immer noch nebenberuflich organisierte Konferenz. Sonja Feierabend War dann der TdSE immer in der Systems Engineering-Hochburg Paderborn? Christian Tschirner Oh nein – im Prinzip ist der TdSE ein Wanderzirkus, der jedes Jahr woanders stattfindet. Ich habe dann in 2013 in Stuttgart organisiert – erstmalig mit Tool Vendor Project, 2014 Bremen, 2015 Ulm, 2016 Herzogenaurach, 2017 Paderborn, 2018 Berlin und 2019 München und durch Corona 2020 als Online-Konferenz die Verantwortung übernommen. Dann hat es aber auch gereicht. 2016 war ein echtes Highlight für mich, weil die Firma SCHAEFFLER dort Gastgeber war. Sonja Feierabend Das ist ja wirklich eine Völkerwanderung! Wer kommt denn so zum TdSE? Christian Tschirner Die Teilnehmer haben sich seit der Anfangszeit dann schon ein wenig verändert. Es sind nicht nur mehr geworden, sondern es ist auch ein sehr durchmischtes Publikum. Während es anfangs maßgeblich Wissenschaftler und vor allen Dingen Berater waren, haben wir heute ungefähr ein Drittel GfSE-Mitglieder und Anwender aus der Industrie. Das sind Unternehmen wie Audi, John Deere, aber auch kleinere Unternehmen aus dem Mittelstand, dem Maschinen- und Anlagenbau, wie wir sie heute zu unseren Kunden zählen, zum Beispiel die Firma Harting oder auch Unternehmen wie Carl Meyer, Belimo oder Palfinger. Die anderen zwei Drittel verteilen sich auf Wissenschaft, Forschung und Beratung und natürlich Tool-Vendoren. Auch wenn wir immer vom „Drittelmix“ gesprochen haben – in München war die Industriequote bei gut 45%. Sonja Feierabend Ja, das ist ja dann schon eine bunte Mischung. Kannst du nochmal kurz was zu diesem „Tool Vendor Projekt“ sagen? Was hat das damit genau auf sich? Christian Tschirner Ja, ohne zu wissen, dass wir selber ab 2018 Tool Vendor wurden, habe ich damals mit Sven- Olaf Schulze das „Tool-Vendor-Projekt“ aufgesetzt. Tool Vendoren, also Softwareverkäufer, haben immer die Eigenschaft, dass sie sehr gutes Marketing und sehr guten Vertrieb machen, aber dabei die potenziellen Kunden sehr wenig Zeit und Möglichkeit haben, die Stärken und USPs der einzelnen Tools neutral vergleichen zu können. Da war der TdSE die zentrale Anlaufstelle, um möglichst viele Tool Vendoren – ich nenne nicht nur Two Pillars, ich nenne ganz offen auch eben beispielsweise PTC, Dassault oder Siemens und ganz viele andere, auch kleinere – einzuladen, damit sie in vergleichbaren Workshops die Stärken ihrer Werkzeuge anhand einer vordefinierten Aufgabe präsentieren können. So ist die Vergleichbarkeit sichergestellt. Deshalb hat sich seit 2013 lustigerweise das Beispiel der Kaffeemaschine als DAS Standardbeispiel für Tool Demonstrationen in der Community entwickelt. Häufig heißt es dann noch, warum habt ihr nicht was Komplexeres genommen. Ich antworte darauf: Jeder Kaffeemaschinenhersteller würde sich jetzt ärgern, denn für jeden ist ja immer das eigene System das aufwendigste und komplizierteste. Aber eine Kaffeemaschine ist gut nachvollziehbar, und auch weil wir sind ja nahezu täglicher Anwender von solchen Systemen sind und können uns dann relativ leicht und mühelos hineinversetzen können. Ein Auto, eine Hebebühne oder was weiß ich ist nicht so leicht zu verstehen. Sonja Feierabend Wenn du jetzt an den diesjährigen TdSE in Würzburg denkst: Was wird dein Thema, oder das Two Pillars-Thema sein? Christian Tschirner Fast wie ein Politiker muss ich jetzt antworten: Erstmal der Frage aus dem Weg gehen und sagen, dass ich mich sehr auf meinem 14. TdSE freue, an einem
TdSE 2023 – So entwickelte sich die größte SE-Konferenz – Interview Read More »
Systems Engineering
Warum eigentlich Systems Engineering? Technische Produkte integrieren heutzutage sehr tief die verschiedenen Disziplinen wie Mechanik, Elektronik, Software. Bei mechatronischen und intelligenten Systemen bringt das in der Produktentwicklung wachsende Herausforderungen mit sich: Die zunehmende Integration bedingt eine Vielzahl von Abhängigkeiten innerhalb eines zu entwickelnden Systems – dem System under Design. Hier bedarf es einer ganzheitlichen Methode, die alle Anforderungen interdisziplinär berücksichtigt und dabei unterstützt, der Komplexität Herr zu werden: Die Entwicklung solcher komplexen mechatronischen Systeme ist Ziel des Systems Engineering. Im Kern geht es darum: Die Kommunikation und Kooperation zwischen den Entwicklungsbeteiligten zu verbessern Ein einheitliches Aufgaben- und Systemverständnis aller Beteiligten zu erreichen sowie Disziplinübergreifende Entwicklungsaufgaben erkennen und lösen Das Model-Based Systems Engineering (MBSE) setzt für die Umsetzung dieser Nutzenpotentiale auf die modellbasierte Beschreibung des Systems und ist damit ein Katalysator für mehr Effektivität und Effizienz. Das Systemmodell als Kern des MBSE beschreibt Anforderungen, Funktionen und Lösungselemente des zu entwickelnden Systems. Diese Informationen liegen verknüpft vor und können bspw. für Risiko- und Auswirkungsanalysen genutzt werden. Unvollständige Lastenhefte oder unübersichtliche Pflichtenhefte gehören also der Vergangenheit an. Systems Engineering ist die Methode, die Ihre Produktentwicklung beschleunigt. iQUAVIS ist das Werkzeug, mit dem Sie diese Methode optimal umsetzen. Wissen Sie, was andere Unternehmen denken? * haben ein ausgeprägtes Bewusstsein für die Notwendigkeit von SE 35 % * sehen sich im int. Vergleich NICHT stark genug aufgestellt im SE 0 % * sind dabei, Systems Engineering und MBSE einzuführen 20 % * sehen Systems Engineering als Top Management-Thema 15 % *der befragten Unternehmen, Studie: Systems Engineering in Deutschland. Die deutsche Unternehmerlandschaft im Vergleich. 2021. Was ist Systems Engineering? Die meist verbreitete Definition von Systems Engineering stammt von INCOSE – dem International Council on Systems Engineering.INCOSE ist weltweit für Systemingenieure das, was bspw. der VDI in Deutschland für Ingenieure ist: „Ein interdisziplinärer Ansatz und ein Mittel, die Verwirklichung erfolgreicher Systeme zu ermöglichen. Der Ansatz zielt darauf, Kundenbedürfnisse und die notwendige Funktionalität früh im Entwicklungsprozess zu definieren, die Anforderungen zu dokumentieren und dann unter Berücksichtigung des Problems in seiner Gesamtheit mit dem Systementwurf und der Abstimmung mit dem Kunden fortzufahren. Systems Engineering betrachtet sowohl die wirtschaftlichen als auch die technischen Bedürfnisse des Kunden, mit dem Ziel, ein qualitativ hochwertiges Produkt zu erzeugen, das den Bedürfnissen der Nutzer gerecht wird.“ (INCOSE) Diese sehr technisch wirkende Definition ist der gemeinsame Nenner der Fachwelt. In Ergänzung dazu hat sich an der Kern-Community in Europa auch der Ansatz von Professor Reinhard Haberfellner durchgesetzt, der Systems Engineering als sozio-technischen Ansatz beschreibt. Er fasst diesen Ansatz im Systems Engineering-Männchen zusammen, das auch maßgeblich zur Gründung von Two Pillars beigetragen hat. Systems Engineering Männchen Jetzt komplexe sozio-technische Themen lösen! Der Ansatz von Haberfellner bezieht neben den Methoden und Werkzeugen verstärkt auch normative Grundprinzipien in den Mittelpunkt des Systems Engineering, ebenso erste Ansätze zum Change Management. Das bekannte SE-Männchen gliedert sich demnach in 3 Bereiche: 1. Im Kopf beginnt die Systems Engineering-Reise.Die SE-Philosophie gliedert sich in das Systemdenken und die wichtigsten Vorgehensweisen im Systems Engineering. 2. Die Füße geben in der SE-Anwendung festen Stand.Hier sind die Werkzeuge der Systemgestaltung und des Projektmanagements verankert. 3. Der Rumpf ist das Verbindungselement.Durch das Zusammenspiel von Kopf und Füßen wird das Projekt strukturiert durchlaufen; hier wird eine Idee in eine Lösung bzw. Produkt überführt. Der Kopf gibt die Richtung vor, die Füße tragen Ziel – und in der Mitte steht der Entwicklungsprozess. Am Puls der Forschung Die Two Pillars GmbH hat sich aus dem Fraunhofer IEM heraus gegründet. Bis heute ist Fraunhofer Gesellschafter von Two Pillars. Regelmäßig arbeiten wir in Forschungsprojekten und Think Tanks zusammen, um Systems Engineering voranzutreiben. Durch unsere breite Vernetzung in der Wissenschaft kooperieren wir mit verschiedenen Universitäten und Fachhochschulen und beteiligen uns an Projekten. Hier sehen Sie eine Auswahl unserer wissenschaftlichen Kooperationspartner und Projektbeteiligungen sowie wissenschaftlicher Publikationen. Titel TABLE HEADER 2 Model-based analysis and specification of functional requirements and tests for complex automotive systems Content 2 Content 1 Content 2 Forschungsprojekte Wir unterstützen regelmäßig Forschungsprojekte und arbeiten mit verschiedenen Hochschulen und Universitäten zusammen. Auf unserem Blog stellen wir einige davon vor. Automatisierte Codegenerierung – Ergebnis des MoSyS-Forschungsprojekts – mit Video 14. Mai 2024/No Comments Im März wurde das MoSyS-Forschungsprojekt abgeschlossen. Wir von Two Pillars waren Teil der Arbeitsgruppe, die über mehrere Jahre an dem… Weiterlesen MoSyS: Menschenorientierte Gestaltung komplexer System of Systems 23. November 2023/No Comments Im Oktober 2020 startete das Projekt MoSyS: „Menschorientierte Gestaltung komplexer System of Systems“ mit dem Ziel, neue Methoden, Hilfsmittel und… Weiterlesen Die Geschichte von Systems Engineering Systems Engineering etablierte sich im 20. Jahrhundert als Methode zur Entwicklung und Verwaltung komplexer Systeme. Die besondere Stärke liegt auf der ganzheitlichen Betrachtung von Systemen und deren Interaktionen, um die spezifischen Anforderungen zu erfüllen. Mit der zunehmenden Komplexität moderner Systeme haben sich jedoch auch die Ansprüche an das Systems Engineering erweitert. Infolgedessen entwickelte sich eine neue Methode, die diese Herausforderungen effektiv bewältigt: das Model-Based Systems Engineering (MBSE). Ein Hauptgrund für diesen Wandel ist die Notwendigkeit, den steigenden Anforderungen an die Systemkomplexität gerecht zu werden. MBSE ermöglicht es, komplexe Systeme auf einer abstrakteren Ebene zu modellieren und zu analysieren, was zu einem verbesserten Systemverständnis und -beherrschung führt. Durch den Modelleinsatz – Stichwort: digital twin – können Ingenieure verschiedene Aspekte eines Systems simultan betrachten und die Auswirkungen von Änderungen besser einschätzen. Ein weiterer Grund für den Übergang zu MBSE ist die zunehmende Interdisziplinarität in der Systementwicklung. Moderne Systeme erfordern die Zusammenarbeit verschiedener Fachdisziplinen wie Mechanik, Elektronik, Software und mehr. Durch den Einsatz von Modellen können diese Fachdisziplinen ihre Systemkomponenten unabhängig voneinander entwickeln und integrieren. Die Modelle dienen als gemeinsame Sprache und Schnittstelle, um einen reibungslosen Informationsfluss und eine effiziente Zusammenarbeit zu gewährleisten – über den gesamten Lebenszyklus! Systems Engineering ist keine Erfindung des 21. Jahrhunderts. Aber was sind spannende Meilensteine? 1930 1930 Bertalannfy – Allgemeine Systemtheorie 1940 1940 Bell Laboratories 1950 1950 Wiener – Kybernetik 1955 1955 RAND – Corporation 1955 1955 Hansen – Konstruktionssystematik 1965 1965 „A Methodology for Systems Engineering“ 1969 1969 Mil-Std 499 1970 1970 Deutscher Ingenieurtag: Systemtechnik 1972 1972 Mil-Std 499a 1973 1973 Haberfellner-Systems Engineering – Methodik und Praxis 1974 1974 Pahl/
Systems Engineering Read More »
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.
Modellbasierte Entwicklung und Traceability bei Honda – und iQUAVIS Read More »
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. 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 wenn ein „Fool with a Tool still a Fool“ ist – am Ende ist das
Two Pillars auf der EMEASEC 2018 in Berlin
Vom 5. bis 7. November 2018 findet in Berlin im Hotel Mercure die EMEA Sector Systems Engineering Conference 2018 statt.
Two Pillars auf der EMEASEC 2018 in Berlin Read More »