Instrumentarium für einen lösungsmusterbasierten Entwurf fortgeschrittener mechatronischer Systeme / Harald Anacker

Harald Anacker Instrumentarium für einen lösungsmusterbasierten Entwurf fortgeschrittener mechatronischer Systeme Band 354 der Verlagsschriftenreihe des Heinz Nixdorf Instituts © Heinz Nixdorf Institut, Universität Paderborn – Paderborn – 2016 ISSN (Print): 2195-5239 ISSN (Online): 2365-4422 ISBN: 978-3-942647-73-1 Das Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung der Herausgeber und des Verfassers unzulässig und strafbar. Das gilt insbesondere für Vervielfältigung, Übersetzungen, Mikroverfilmungen, sowie die Einspeicherung und Verarbeitung in elektronischen Systemen. Als elektronische Version frei verfügbar über die Digitalen Sammlungen der Universitätsbibliothek Paderborn. Satz und Gestaltung: Harald Anacker Hersteller: Verlagshaus Monsenstein und Vannerdat OHG Druck . Buch . Verlag Münster Printed in Germany Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufba r Geleitwort Das Heinz Nixdorf Institut der Universität Paderborn sowie die Fraunhofer Projektgruppe Entwurfstechnik Mechatronik sind interdisziplinäre Forschungszentren für das Zusammenwirken von Informatik und Technik. Das übergeordnete Ziel des von mir vertretenen Fachgebiets ist die Steigerung der Innovationskraft von Industrieunternehmen des Maschinenbaus und verwandter Branchen. Ein wesentlicher Erfolgsgarant und Schwerpunkt meines Fachgebiets ist das Systems Engineering für multidisziplinäre Systeme. Im Zeitalter von „Industrie 4.0“ führt der zunehmende Anteil an Informations- und Kommunikationstechnik zu einer Komplexitätssteigerung von mechatronischen Systemen und deren Entwicklungsprozessen. Interdisziplinäres Denken und Handeln sowie ein ganzheitliches Systemverständnis unter den beteiligten Akteuren werden wichtiger denn je. Ein wesentlicher Stellhebel zur Entwicklung komplexer mechatronischer Systeme ist die Wiederverwendung von Lösungswissen. Wir nutzen hierfür sog. Lösungsmuster, die Wissen zur Lösung von abstrakten Funktionen formal repräsentieren. In entsprechenden Ausprägungen führt ihr Einsatz zu einer signifikanten Effizienzsteigerung in der Entwicklung jedweder Artefakte. Vor diesem Hintergrund hat Herr Anacker ein Instrumentarium für einen lösungsmusterbasierten Entwurf fortgeschrittener mechatronischer Systeme entwickelt. Schlüsselelement ist die konsequente Übertragung des Paradigmas der Lösungsmuster auf die gesamte Produktentstehung. Hierfür werden diverse Lösungsmuster sowie deren Wechselwirkungen untereinander in einer Art Mustersprache abgebildet. Speziell für den fachdisziplinübergreifenden Entwurf liefert Herr Anacker Beschreibungsmittel für Lösungsmuster, eine Methode zur Identifikation von Lösungsmustern sowie eine Methode zur Anwendung von Lösungsmustern im Entwurf von komplexen technischen Systemen. Mit seiner Dissertation bewegt sich Herr Anacker auf einem hochaktuellen und sehr herausfordernden Gebiet, das z.T. noch grundlegende Impulse benötigt. Er leistet wesentliche integrative Beiträge zu mehreren Forschungsgebieten, die bislang eher isoliert betrachtet wurden: Wissensmanagement in der Produktentstehung, Entwicklungsmethodik des Maschinenbaus von morgen und Systems Engineering. Damit wird auch das hohe Maß der Kohärenz dieser drei Gebiete unterstrichen. Anhand anspruchsvoller Validierungsbeispiele belegt Herr Anacker zudem die Praxisrelevanz und -tauglichkeit des Instrumentariums. Paderborn, im Oktober 2015 Prof. Dr.-Ing. J. Gausemeier Instrumentarium für einen lösungsmusterbasierten Entwurf fortgeschrittener mechatronischer Systeme zur Erlangung des akademischen Grades eines DOKTORS DER INGENIEURWISSENSCHAFTEN (Dr.-Ing.) der Fakultät Maschinenbau der Universität Paderborn genehmigte DISSERTATION von Dipl.-Ing. Harald Anacker aus Paderborn Tag des Kolloquiums: 22. Mai 2015 Referent: Prof. Dr.-Ing. Jürgen Gausemeier Korreferent: Prof. Dr.-Ing. habil. Ansgar Trächtler Vorwort Die vorliegende Dissertation entstand während meiner Tätigkeit als wissenschaftlicher Mitarbeiter am Lehrstuhl für Produktentstehung am Heinz Nixdorf Institut der Universität Paderborn und während meiner Tätigkeit bei der Fraunhofer Projektgruppe Entwurfstechnik Mechatronik. Sie ist das Ergebnis meiner wissenschaftlichen Arbeit im Rahmen von Forschungs- und Industrieprojekten. Mein herzlicher Dank gilt Herrn Professor Dr.-Ing. Jürgen Gausemeier für die stets fordernde fachliche als auch persönliche Aus- und Weiterbildung in meiner Zeit als wissenschaftlicher Mitarbeiter. Ich danke ihm besonders für das große Vertrauen in meine Arbeit und in meine Person, das er mir auch in herausfordernden Zeiten stets entgegen gebracht hat. Herrn Professor Dr.-Ing. habil. Ansgar Trächtler danke ich für die Übernahme des Koreferats sowie die angenehme Zusammenarbeit in den zurückliegenden Projekten und während der andauernden Tätigkeit in der Projektgruppe. Besonders bedanken möchte ich mich bei Dr.-Ing. Roman Dumitrescu. Er war es, der mich noch während des Studiums in der Zeit als studentische Hilfskraft für den Weg hin zur Promotion begeisterte und daher maßgeblichen Anteil an dieser Weichenstellung in meiner beruflichen Laufbahn hat. Mit großer Dankbarkeit betrachte ich die zurückliegenden sieben gemeinsamen Jahre und seine konsequente Förderung meiner Person. Ferner danke ich allen Arbeitskollegen am Lehrstuhl und in der Projektgruppe für die tolle Zusammenarbeit und das angenehme Arbeitsklima. Für die stets konstruktiven Diskussionen im Rahmen meiner Dissertation danke ich besonders: Dr.-Ing. Frank Bauer, Anja Czaja, Stefan Dziwok, Peter Iwanek, Arno Kühn, Thomas Schierbaum und Thorsten Westermann. Darüber hinaus danke ich allen Studierenden, die mich bei meiner Arbeit durch ihre Masterarbeiten oder durch ihre studentische Hilfstätigkeit unterstützt haben. Besonders hervorzuheben ist der Dank an meine Familie: in erster Linie der Dank an meine Eltern, die mir das Studium und die Promotion ermöglicht und mich stets unterstützt haben; aber auch der Dank an meine Schwestern und Schwiegereltern für die fortwährende Motivation. Mein größtes Dankeschön gilt jedoch meiner Frau Jenni! Einfach Danke … … für die Kraft, die du mir die ganzen Jahre über gegeben hast, … für das Verständnis, das du mir entgegengebracht hast und … für die Geduld und das Zurückstecken, wenn die Abende oder die Wochenenden im Zeichen der Dissertation standen. … Paderborn, im Oktober 2015 Harald Anacker Liste der veröffentlichten Teilergebnisse [DAG10] DUMITRESCU, R.; ANACKER, H.; GAUSEMEIER, J.: Specification of Solution Patterns for the Conceptual Design of Advanced Mechatronic Systems. In: Proceedings of the International Conference on Advances in Mechanical Engineering (ICAME2010), 2.-5. Dezember, Shah Alam, Malaysia, 2010 [ADD+11] ANACKER, H.; DOROCIAK, R.; DUMITRESCU, R.; GAUSEMEIER, J.: Integrated Tool-Based Approach for the Conceptual Design of Advanced Mechatronic Systems. In: Proceedings of IEEE International Systems Conference (SysCon2011), 3.-6. April, Montreal, Kanada, 2011 [GSA+11] GAUSEMEIER, J.; SCHÄFER, W.; ANACKER, H.; BAUER, F.; DZIWOK, S.: Einsatz semantischer Technologien im Entwurf mechatronischer Systeme. In: 8. Paderborner Workshop Entwurf mechatronischer Systeme, HNI-Verlagsschriftenreihe, Band 294, 19.-20. Mai, Paderborn, 2011 [DAB+12] DUMITRESCU, R.; ANACKER, H.; BAUER, F.; GAUSEMEIER, J.; Computer Support for the Identification of Solution Patterns for the Conceptual Design of Advanced Mechatronic Systems. In: Proceedings of 11th Biennial Conference on Engineering Systems Design and Analysis (ESDA2012), 2.-4. Juli, Nantes, Frankreich, 2012 [ADG+12] ANACKER, H.; DUMITRESCU, R.; GAUSEMEIER, J.; DZIWOK, S.; SCHÄFER, W.: Solution Patterns of Software Engineering for the System Design of Advanced Mechatronic Systems. In: Proceedings of the 13th International Workshop on Research and Education in Mechatronics (REM2012), 21.-23. November, Paris, Frankreich, 2012 [GAC+13] GAUSEMEIER, J.; ANACKER, H.; CZAJA, A.; WASSMANN, H.; DUMITRESCU, R.: Auf dem Weg zu intelligenten technischen Systemen. In: 9. Paderborner Workshop Entwurf mechatronischer Systeme, HNI-Verlagsschriftenreihe, Band 310, 18.-19. April, Paderborn, 2013 [ASD+13] ANACKER, H.; SCHIERBAUM, T.; DUMITRESCU, R.; GAUSEMEIER, J.: Solution Patterns to support the knowledge intensive design process of intelligent technical systems. In: Proceedings of International Conference on Engineering Design (ICED 2013), 19.-22. August, Seoul, Korea, 2013 [ADG+13] ANACKER, H.; DUMITRESCU, R.; GAUSEMEIER, J.; LOW, C.-Y.: Identification of reusable Controller Strategies for the System Design of Advanced Mechatronic Systems. In: Proceedings of the 2nd International Conference on Advances in Mechanical Engineering (ICAME2013), 28.-29. August, Malacca, Malaysia, 2013 [ADG13] ANACKER, H.; DUMITRESCU, R.; GAUSEMEIER, J.: Solution Patterns for the integrated Design of Mechatronic Products and related Production Systems. In: Proceedings of the 14th International Workshop on Research and Education in Mechatronics (REM2013), 6.-7. Juni, Wien, Österreich, 2013 [ADG+14] ANACKER, H.; DUMITRESCU, R.; GAUSEMEIER, J.; IWANEK, P.; SCHIERBAUM, T.: Methodology for the identification of self-optimising potentials for mechatronic systems. In: Proceedings of 2nd Joint Symposium on System-integrated Intelligence: New Challenges for Product and Production Engineering (SysInt), 2.-4.Juli, Bremen, Deutschland, 2014 [ABG+14] ANACKER, H.; BAUER, F.; GAUSEMEIER, J.; SCHIERBAUM, T.: Systementwurf mit Hilfe von Lösungsmustern aus dem Semantic Web. In: GAUSEMEIER, J.; TRÄCHTLER, A.; SCHÄFER, W. (Hrsg.): Semantische Technologien im Entwurf mechatronischer Systeme – Effektiver Austausch von Lösungswissen in Branchenwertschöpfungsketten. Carl Hanser Verlag, München, 2014, S.142-164 [RAD14] RABE, M.; ANACKER, H.; DUMITRESCU, R.: Methodology for the Identification of Solution Patterns within Mechatronic Systems. In: Proceedings of Proceedings of the 15th International Workshop on Research and Education in Mechatronics (REM2014), 9.-11. September, Elgouna, Ägypten, 2014 Seite iv Inhaltsverzeichnis 6 Zusammenfassung und Ausblick ............................................................. 167 7 Abkürzungsverzeichnis ............................................................................ 171 8 Literaturverzeichnis ................................................................................. 173 Anhang A1 Ergänzungen zum Stand der Technik ...................................................... A-1 A1.1 Beispiele für Lösungsmuster nach SIMPSON ..................................... A-1 A1.2 Beispiel für ein Lösungsmuster nach CLOUTIER ................................ A-3 A1.3 Beispiele für Lösungsmuster nach GAUSEMEIER ET AL. ..................... A-5 A2 Ergänzungen zu Kapitel 4.2 – Das Paradigma der Lösungsmuster in der PE .......................................... A-7 A2.1 Beispiele für Lösungsmuster der strategischen Produktplanung ...... A-7 A2.2 Beispiele für Lösungsmuster der Produktentwicklung ...................... A-9 A2.3 Beispiele für Lösungsmuster der Produktionssystementwicklung .. A-10 A3 Ergänzungen zu Kapitel 4.3 – Lösungswissen für den Systementwurf .. A-13 Einleitung Seite 1 1 Einleitung Die vorliegende Arbeit ist im Rahmen von Grundlagenforschung am Heinz Nixdorf Institut sowie der anwendungsorientierten Forschung in der Fraunhofer Projektgruppe Entwurfstechnik Mechatronik des Fraunhofer-Instituts für Produktionstechnologie IPT entstanden. Kern der Arbeit sind Lösungsmuster für den Systementwurf, deren wissenschaftliche Untersuchung Gegenstand des Verbundprojekts ENTIME – ENTwurfstechnik Intelligente Mechatronik – war. Ziel des Projekts war ein Instrumentarium für den Einsatz semantischer Technologien im Entwurf intelligenter mechatronischer Systeme. Hierbei handelt es sich um Systeme, die ihr Verhalten selbstständig und bestmöglich auf das aktuelle Systemumfeld einstellen können. Im Projekt ENTIME wurde, in Kooperation mit mehreren Industrieunternehmen, eine fortlaufende Unterstützung des Entwicklungsprozesses durch die bedarfsgerechte Bereitstellung von Lösungswissen, z.B. Lösungsmuster, umgesetzt. In der Zeit bei der Fraunhofer Projektgruppe konnten die gewonnenen Erkenntnisse vertieft und neue Handlungsfelder eröffnet werden. Die Anwendung erfolgte im Rahmen des Spitzenclusters it´s OWL1. Die vorliegende Arbeit ordnet sich im Themenfeld Systems Engineering, speziell im Model-Based Systems Engineering (MBSE) ein und beschreibt ein Instrumentarium für einen lösungsmusterbasierten Entwurf fortgeschrittener mechatronischer Systeme. 1.1 Problematik Unser heutiges Leben ist mehr denn je geprägt durch den Einsatz technischer Systeme. Ob im häuslichen Umfeld, in der industriellen Produktion, Kommunikation oder Logistik, sie sind als Hilfsmittel für den Menschen nicht mehr wegzudenken. Es sind Erzeugnisse des modernen Maschinenbaus oder verwandter Branchen, wie z.B. der Automobilindustrie oder Medizintechnik. Die Systeme beruhen dabei auf dem synergetischen Zusammenwirken unterschiedlicher Fachdisziplinen wie Maschinenbau, Elektrotechnik sowie Regelungs- und Softwaretechnik. Der Begriff Mechatronik, bzw. mechatronisches System, bringt dies zum Ausdruck [VDI2206]. Aufgrund der voranschreitenden Entwicklung der Informations- und Telekommunikationstechnik steigt der Funktionsumfang mechatronischer Systeme rasant an. Es eröffnet sich die Perspektive von global verteilten Systemen, die über das Internet miteinander verbunden sind und im Verbund agieren. Ferner werden diesen Systemen Fähigkeiten implementiert, die so in der Vergangenheit nur von biologischen Systemen bekannt waren. Sie agieren teilweise autonom und sind in der Lage, flexibel auf sich ändernde Betriebssituationen zu reagieren. Derart fortgeschrittene mechatronische Systeme sind adaptiv, robust, vorausschauend und benutzungsfreundlich [GAC+13], [Dum10]. 1 Intelligente Technische Systeme OstWestfalenLippe (it´s OWL) Seite 2 Kapitel 1 Zentrale Herausforderungen in der Entwicklung dieser Systeme sind die verstärkte Interdisziplinarität und die steigende Komplexität des zu entwickelnden Systems selbst. Die Entwicklung kann nicht aus dem Blickwinkel einer einzelnen Fachdisziplin erfolgen. Unumstritten ist die Tatsache, dass die Expertise der involvierten Fachdisziplinen für die Ausarbeitung von Teilsystemen bzw. Komponenten essentiell ist. Grundlage einer erfolgreichen Entwicklung muss jedoch ein Denken und Handeln sein, bei dem das multidisziplinäre Gesamtsystem im Mittelpunkt steht. Andernfalls ist die Gesamtfunktionalität des zu entwickelnden Systems aufgrund von z.T. separat entstandenen Teillösungen nicht, bzw. nur mit langwierigen und kostspieligen Iterationen, zu gewährleisten. Ein Ansatz, der sich diesen Herausforderungen annimmt, ist das sog. Systems Engineering. Im Vordergrund des Systems Engineerings steht das Systemdenken. Es erstreckt sich über die gesamte Produktentstehung, ausgehend von einer ersten Produktidee bis hin zum Serienanlauf. Ziel ist ein einheitliches und ganzheitliches Systemverständnis bei allen beteiligten Akteuren. Ein wesentliches Handlungsfeld ist die fachdisziplinübergreifende Systemspezifikation während der modellbasierten Entwicklung. Kern ist ein sog. Systemmodell, das eine abstrakte und ganzheitliche Systembetrachtung ermöglicht. Es bildet als zentrales Modell die Plattform zur Kommunikation und Kooperation über die gesamte Entwicklung hinweg. Es wird während des Entwurfs in Zusammenarbeit mit allen beteiligten Disziplinen erarbeitet. Sobald detailreiche Spezifikationen von einzelnen Fachdisziplinen erforderlich werden, finden über das Systemmodell notwendige Synchronisationen statt. So werden beispielsweise Änderungen mit disziplinübergreifenden Auswirkungen im Systemmodell festgehalten und entsprechend kommuniziert [INC12], [HWF+12], [Alt12]. Ein weiterer Erfolgsgarant im Hinblick auf die Beherrschbarkeit derart komplexer Systeme liegt in der Wiederverwendung von einst erfolgreich eingesetztem Lösungswissen [AG12]. Ein in der Literatur vielfach beschriebener Ansatz zur Externalisierung von entwicklungsrelevantem Wissen sind sog. Lösungsmuster. Ein Lösungsmuster beschreibt ein Problem sowie den Kern der Lösung für dieses Problem [AIS+77]. Im Gegensatz zu einer detaillierten Lösung sind die Beschreibungen in einem Lösungsmuster abstrahiert, so dass dieses auf weitere Problemstellungen adaptiert werden kann. Die Interpretationen und Anwendungsgebiete von Lösungsmustern sind außerordentlich facettenreich [Clo06]. Lösungsmuster besitzen gegenüber weiteren Ansätzen im Kontext des Wissensmanagements wesentliche Vorteile, was die Forderung nach ihrem durchgängigen Einsatz in der Produktentstehung bekräftigt [Ris98]. Voraussetzung ist jedoch die grundlegende Übertragung des Paradigmas der Lösungsmuster auf die gesamte Produktentstehung. Hierzu bedarf es eines einheitlichen Begriffsverständnisses, Beispielmuster aller Bereiche sowie die Beschreibung ihres Zusammenspiels in einem übergeordneten Wirkgefüge. Ein besonderes Augenmerk muss dabei nicht zuletzt aufgrund der Potentiale des Model- Based Systems Engineering auf dem fachdisziplinübergreifenden Entwurf liegen. Fach- Einleitung Seite 3 disziplinspezifische Lösungsmuster existieren zahlreich, z.B. Wirkprinzipien im Maschinenbau oder Wirkmuster in der Softwaretechnik [ADG+09]. Im Hinblick auf die Besonderheiten in der Erstellung eines Systemmodells ist eine alleinige Zusammenführung von existierendem Lösungswissen wenig zielführend. Es bedarf vielmehr neuartiger z.T. multidisziplinärer Lösungsmuster. Die darin enthaltenen Informationen müssen in einer Terminologie spezifiziert sein, die alle beteiligten Entwickler2 gleichermaßen verstehen. Die adressierten Lösungsmuster müssen dabei, wenn immer möglich, nahtlos mit fachdisziplinspezifischen Lösungsmustern verknüpft werden können. Hierzu bedarf es einer geeigneten Strukturierung, um das Lösungswissen langfristig zu dokumentieren und Entwicklern adäquat zur Verfügung zu stellen. Der richtige Einsatz von Lösungsmustern im Systementwurf steigert die Effizienz signifikant. Hierfür bedarf es jedoch einer geeigneten Systematik für den Einsatz von Lösungsmustern. Es muss geklärt werden, wie Lösungsmuster für den Systementwurf identifiziert werden können und wie mit ihnen ein fortgeschrittenes mechatronisches System entworfen werden kann. 1.2 Zielsetzung Ziel der vorliegenden Arbeit ist ein Instrumentarium für einen lösungsmusterbasierten Entwurf fortgeschrittener mechatronischer Systeme. Es soll für ein einheitliches Verständnis von Lösungsmustern in der Produktentstehung sorgen und ferner den Systems Engineer zusammen mit einem interdisziplinären Entwicklerteam während den frühen Phasen des Entwurfs unterstützen. Das Instrumentarium soll sich aus insgesamt vier Bestandteilen zusammensetzen. Erster Bestandteil und zugleich Grundlage für die vorliegende Arbeit ist eine umfangreiche Beschreibung des Paradigmas der Lösungsmuster in der Produktentstehung. Anschließend findet bei der Erarbeitung der weiteren drei Bestandteile eine Fokussierung auf den Systementwurf statt. Als Techniken für eine Dokumentation des Lösungswissens für den Systementwurf werden eine einheitliche Strukturierung von Lösungsmustern und eine multidimensionale Skalierung erarbeitet. Diese müssen dem fachdisziplinübergreifenden Charakter des Systementwurfs gerecht werden und die Verzahnung in die beteiligten Fachdisziplinen verdeutlichen. Zwei weitere Bestandteile ergeben zusammen eine übergeordnete Systematik für den lösungsmusterbasierten Systementwurf. Einen Schwerpunkt bildet ein Vorgehensmodell zur Identifizierung von (multidisziplinären) Lösungsmustern auf Basis etablierter Produkte. Andererseits soll ein weiteres Vorgehensmodell die Anwendung von Lösungsmustern im Entwurf fortgeschrittener mechatronischer Systeme beschreiben. 2 Es wird im Folgenden die maskuline Form verwendet und zwar ausschließlich wegen der einfachen Lesbarkeit. Wenn beispielsweise von Entwicklern oder Ingenieuren die Rede ist, sind selbstredend auch Entwicklerinnen und Ingenieurinnen gemeint. Seite 4 Kapitel 1 Die Anwendbarkeit der Bestandteile soll an zwei Systemen nachgewiesen werden. So bildet ein bereits realisiertes System den Ausgangspunkt bei der Identifizierung von Lösungsmustern. Der lösungsmusterbasierte Systementwurf hingegen erfolgt anhand einer Neukonzeption. 1.3 Vorgehensweise Zunächst wird in Kapitel 2 die einleitende Problematik konkretisiert. Hierzu werden zu Beginn das Forschungsfeld der Arbeit abgesteckt und relevante Begriffe eingeführt. Betrachtungsgegenstand der vorliegenden Arbeit sind fortgeschrittene mechatronische Systeme. Nach der eingehenden Analyse ihrer Charakteristika und Leistungsstufen wird die Entwicklung derartiger Systeme beleuchtet. Es werden sowohl methodische Ansätze wie die VDI 2206 „Entwicklungsmethodik für mechatronische Systeme“ als auch Grundlagen und Handlungsfelder des Systems Engineerings sowie Model-Based Systems Engineerings untersucht. Da Lösungsmuster – und ein damit verbundenes Wissensmanagement – ein wesentliches Handlungsfeld der vorliegenden Arbeit sind, werden diese in einem eigenen Abschnitt umfassend erläutert. In einer Problemabgrenzung werden die grundlegenden Herausforderungen der vorliegenden Arbeit zusammengefasst. Die Problemanalyse schließt mit der Ableitung von Anforderungen an das angestrebte Instrumentarium. Gegenstand von Kapitel 3 ist eine Analyse des Stands der Technik. Den Startpunkt bildet die Untersuchung von übergeordneten Ansätzen zur Beschreibung des Paradigmas der Lösungsmuster in der Produktentstehung. Die nachfolgenden Abschnitte fokussieren den Systementwurf. Zunächst werden Techniken für eine abstrakte und fachdisziplinübergreifende Modellierung mechatronischer Systeme und somit für die Wissensrepräsentation in den Lösungsmustern untersucht. Anschließend werden fachdisziplinübergreifende Lösungsmuster analysiert. Da diese eng mit der Expertise der einzelnen Fachdisziplinen verbunden sind, werden ferner disziplinspezifische Lösungsmusteransätze diskutiert. Vorgehensmodelle, die zur Systematik für den Einsatz von Lösungsmustern im Systementwurf beitragen, setzen die Analyse des Stands der Technik fort. Den Abschluss bildet eine Gegenüberstellung der Ansätze mit den in Kapitel 2 ermittelten Anforderungen. Es wird ersichtlich, dass dringender Handlungsbedarf nach dem angestrebten Instrumentarium besteht. Kapitel 4 bildet den Kern der vorliegenden Arbeit. Es beinhaltet eine ausführliche Beschreibung des Instrumentariums für einen lösungsmusterbasierten Entwurf fortgeschrittener mechatronischer Systeme. Das Kapitel startet mit einem Überblick über die Bestandteile und ihrem Zusammenwirken. Anschließend werden die einzelnen Bestandteile vorgestellt. Den Anfang bildet die Herleitung einer für die gesamte Produktentstehung gemeinsamen Begriffswelt der Lösungsmuster. Diese bildet die Grundlage des Instrumentariums und resultiert in einem Wirkgefüge von Lösungsmustern in der Produktentstehung. Im Hinblick auf eine geeignete Dokumentation, wird eine einheitliche Einleitung Seite 5 Strukturierung von Lösungsmustern für den Systementwurf sowie deren Charakterisierung entlang dreier Dimensionen eingeführt. Die erzielten Resultate fließen in den darauf aufbauenden Einsatz von Lösungsmustern im Systementwurf ein und komplettieren die Vorgehensmodelle zur Identifizierung und Anwendung zu einer übergeordneten Systematik. Die Validierung der Arbeit erfolgt in Kapitel 5. Anhand von zwei ausgewählten Anwendungsbeispielen wird die durchgängige Anwendung des entwickelten Instrumentariums mit ihren einzelnen Bestandteilen gezeigt. Bei den Beispielen handelt es sich um den Demonstrator eines Forschungsprojekts und um ein Industrieerzeugnis, anhand derer die Erfüllung der aufgestellten Anforderungen validiert werden können. Die Anwendungsbeispiele eigenen sich hervorragend, um neben dem hohen wissenschaftlichen Neuheitsgrad, die Industrierelevanz der erzielten Ergebnisse zu unterstreichen. Eine Zusammenfassung der Arbeit ist Inhalt von Kapitel 6. Ferner wird ein Ausblick auf zukünftige Forschungsfelder gegeben. Der Anhang umfasst ergänzende Informationen zum Stand der Technik und zum Instrumentarium. Problemanalyse Seite 7 2 Problemanalyse Ziel der Problemanalyse sind Anforderungen an ein Instrumentarium für einen lösungsmusterbasierten Entwurf fortgeschrittener mechatronischer Systeme. Hierfür werden in Kapitel 2.1 wesentliche Begriffe definiert und die Ausrichtung der Arbeit beschrieben. Anschließend erfolgt in Kapitel 2.2 eine Erläuterung der Architektur und Funktionsweise fortgeschrittener mechatronischer Systeme. Den Schwerpunkt von Kapitel 2.3 bildet die interdisziplinäre Produktentstehung. In diesem Zusammenhang wird auf die Entwicklungsmethodiken mechatronischer Systeme und deren Herausforderungen eingegangen. Kapitel 2.4 analysiert anschließend Ansätze des Wissensmanagements und das Paradigma der Lösungsmuster für die Produktentstehung. Kapitel 2.5 umfasst eine Problemabgrenzung. Das Resultat der Analyse sind die Anforderungen an das Instrumentarium und deren Beschreibung in Kapitel 2.6. 2.1 Begriffsdefinitionen und Ausrichtung der Arbeit Gegenstand dieser Arbeit ist ein Instrumentarium für einen lösungsmusterbasierten Entwurf fortgeschrittener mechatronischer Systeme. Unter dem Begriff Instrumentarium ist ein kohärentes Wirkgefüge zu verstehen, das einzelne Bestandteile zur Lösung einer bestimmten Aufgabe beinhaltet und diese vereint. Solche Bestandteile sind u.a. Begriffsdefinitionen, Charakterisierungen, Abbildungen wechselseitiger Abhängigkeiten sowie Vorgehensmodelle3. Bei der Bewältigung bestimmter Aufgaben oder Problemstellungen greift der Mensch bewusst oder unbewusst auf ihm bekannte Muster zurück [Kas03]. Im Vordergrund dieser Arbeit stehen dabei sog. Lösungsmuster, die die Entwickler im Lösungsfindungsprozess während des Entwurfs mechatronischer Systeme unterstützen. Diese Muster repräsentieren relevantes, z.T. fachdisziplinübergreifendes Lösungswissen für ein spezifisches Problem innerhalb eines bestimmten Kontextes [AIS+77], [Bar98], [Has05]. Der Begriff Entwurf, bzw. Systementwurf oder Konzipierung, umfasst die Festlegung eines fachdisziplinübergreifenden Lösungskonzepts [VDI2206]. Dieses enthält alle wesentlichen physikalischen und logischen Wirkungsweisen des zukünftigen Produkts bzw. Systems4. 3 Ein Vorgehensmodell strukturiert die Entwicklungstätigkeiten nach aufgabenspezifischen Gesichtspunkten. Dabei wird in der Regel auf Hilfsmittel verwiesen, wie z.B. Methoden, Richtlinien oder auch Spezifikationstechniken/Modellierungssprachen. 4 „Ein System ist eine in einem betrachteten Zusammenhang gegebene Anordnung von Elementen, die miteinander in Wechselwirkung stehen. Diese Anordnung wird aufgrund bestimmter Vorgaben von ihrer Umgebung abgegrenzt“ [DIN 19226]. Seite 8 Kapitel 2 Das Instrumentarium dient der Entwicklung fortgeschrittener mechatronischer Systeme. Bei diesen handelt es sich um zunehmend intelligenter werdende technische Systeme, die auf dem synergetischen Zusammenwirken technischer Fachdisziplinen wie Maschinenbau, Elektrik/Elektronik und Informationstechnik sowie nicht technischer Disziplinen wie höhere Mathematik, Biologie oder Kognitionswissenschaft basieren [VDI2206, S. 14], [ADG+09, S. 5]. Zudem beinhaltet das Instrumentarium eine umfangreiche Übertragung des Paradigmas der Lösungsmuster auf die Produktentstehung. Durch die Fokussierung auf den fachdisziplinübergreifenden Entwurf schlägt die Arbeit zugleich eine Brücke zwischen etablierten Herangehensweisen aus der Konstruktionswissenschaft5 und dem Systems Engineering6. Es werden die Stärken beider Seiten herauskristallisiert und durch die Aufbereitung relevanten Lösungswissens in Form von Lösungsmustern miteinander gebündelt. 2.2 Mechatronische Systeme Durch die rasante Entwicklung der Informationstechnik ergeben sich für den modernen Maschinenbau vermehrt Möglichkeiten, erfolgversprechende Produktinnovationen umzusetzen. Der Begriff Mechatronik bringt dies zum Ausdruck. Es ist ein Kunstwort aus Mechanik und Elektronik und beschreibt das fachdisziplinübergreifende Zusammenwirken von Maschinenbau, Elektrotechnik und Informationstechnik [VDI2206], [GF06], [Ise08]. In der Literatur existiert eine Vielzahl von Definitionen. Eine häufig zitierte Beschreibung liefern HARASHIMA, TOMIZUKA und FUKUDA: „[Mechatronics is]… the synergetic integration of mechanical engineering with electronic and intelligent computer control in the design and manufacturing of industrial products and process” [HTF96, S. 1].7 Im Vergleich zu konventionellen Lösungen ist durch das Zusammenwirken unterschiedlicher Disziplinen eine erhebliche Funktionserweiterung technischer Systeme realisierbar. Neuartige Entwicklungen zeigen, dass sich bereits Systeme mit intelligenten bzw. autonomen Eigenschaften umsetzen lassen [ADG+09, S. 29ff.] 5 Die Konstruktionswissenschaft beschäftigt sich mit der Ableitung von Regeln zur Entwicklung technischer Systeme auf Basis der Analyse des Aufbaus technischer Systeme und der Beziehungen zu ihrem Umfeld [PBF+07, S. 10] 6 Systems Engineering (SE) ist eine Sichtweise bzw. ein Ansatz, in dessen Kern ein ganzheitliches Systemverständnis steht. Es werden Methoden und Prozesse zur Realisierung von komplexen technischen Systemen bereitgestellt [INC12]. 7 Übersetzung nach [VDI2206, S. 14]: „Mechatronik beschreibt das synergetische Zusammenwirken der Fachdisziplinen Maschinenbau, Elektrotechnik und Informationstechnik beim Entwurf und der Herstellung industrieller Erzeugnisse sowie bei der Prozessgestaltung.“ Problemanalyse Seite 9 Vor diesem Hintergrund erfolgt in Kapitel 2.2.1 zunächst eine Beschreibung der Grundstruktur mechatronischer Systeme. Kapitel 2.2.2 liefert anschließend eine Beschreibung der Klassen mechatronischer Systeme nach GAUSEMEIER ET AL. Ferner folgt in Kapitel 2.2.3 eine Charakterisierung fortgeschrittener mechatronischer Systeme. 2.2.1 Grundstruktur mechatronischer Systeme Mechatronische Systeme bestehen in der Regel aus einem Grundsystem, Sensorik, Aktorik und einer Informationsverarbeitung. Einfluss auf das System hat sowohl der Mensch über die Mensch-Maschine-Schnittstelle, als auch die Umgebung, in der das System betrieben wird [VDI2206]. Die Grundstruktur mechatronischer Systeme zeigt Bild 2-1. Bild 2-1: Grundstruktur eines mechatronischen Systems [vgl. VDI2206, S. 14] Grundsystem: Das Grundsystem stellt im Normalfall eine mechanische, elektromechanische, hydraulische oder pneumatische Struktur dar. Es ist somit das Kernelement der physikalischen Ebene. Technologische Weiterentwicklungen ermöglichen auch Kombinationen dieser Strukturen. Sensorik: In einem mechatronischen System werden sowohl ausgewählte Zustandsgrößen des Grundsystems als auch äußere Einflüsse der Umgebung von den Sensoren erfasst. Es folgt die Übermittlung der gewonnenen Messwerte an die Informationsverarbeitung. Informationsverarbeitung: Zentrales Element auf der logischen Ebene ist die Informationsverarbeitung. Ihre Aufgabe ist die Ermittlung aller relevanten Einwirkungen, um die Zustandsgrößen des Grundsystems mittels der Aktoren in geeigneter Weise zu beeinflussen. Logische Ebene Informationsverarbeitung Kommunikationssystem Mensch-Maschine-Schnittstelle Mensch Informationsverarbeitung Physikalische Ebene Grundsystem Aktorik Sensorik Umgebung Leistungsversorgung Legende Informationsfluss Energiefluss Stofffluss notwendige Einheit optionale Einheit Seite 16 Kapitel 2 Zusammenfassend lässt sich erkennen, dass der Controller, der reflektorische Operator und der kognitive Operator stark interagieren. Die beteiligten Disziplinen zur Umsetzung einer derart komplexen Informationsverarbeitung sind die Regelungstechnik, die Softwaretechnik, die höhere Mathematik sowie die Techniken der künstlichen Intelligenz. Fortgeschrittene mechatronische Systeme haben darüber hinaus die Fähigkeit, mit weiteren Systemen zu interagieren (Bild 2-5). Der resultierende Verbund aus einzelnen Systemen muss in der Lage sein, autark auf wechselnde, vom Menschen hervorgerufene Veränderungen reagieren zu können. Bild 2-5: Vom intelligenten Teilsystem hin zum vernetzten Cyber-physischen System [GTD13] Durch die Entwicklung des Internets, wie beispielsweise Cloud Computing, spielt der geographische Standort der einzelnen Systeme im Verbund keine Rolle mehr. Der Trend geht hin zur globalen Vernetzung. Das angestrebte Instrumentarium hat das Ziel, die Effizienz in der Entwicklung derart komplexer und miteinander interagierender mechatronischer Systeme zu erhöhen. Kern werden z.T. multidisziplinäre Lösungsmuster sein, mit deren Hilfe ein erstes Systemkonzept fachdisziplinübergreifend aufgestellt werden kann. Die Lösungsmuster decken dabei Lösungswissen über das Grundsystem, den Controller, den reflektorischen Operator sowie die Vernetzung zwischen den Systemen ab. Ihr Zusammenspiel in einem übergeordneten Wirkgefüge muss den Besonderheiten der vorgestellten Referenzarchitektur Rechnung tragen und für Transparenz im Hinblick auf fachdisziplinübergreifende Schnittstellen sorgen. Existierende Lösungsmuster für den kognitiven Operator werden berücksichtigt, aber nicht primär adressiert. Informations - verarbeitung Kommunikationssystem Vernetztes System SensorikAktorik Grundsystem Mensch Leistungsversorgung Mensch-Maschine- Schnittstelle Legende Informationsflussinterne Einheit Kommunikationssystem Kommunikationssystem Umgebung Teilsystem StoffflussEnergieflussexterne Einheit Informationsverarbeitung Nicht kognitive Regulierung Assoziative Regulierung Kognitive Regulierung Problemanalyse Seite 17 2.3 Interdisziplinäre Produktentstehung Im Folgenden wird in Kapitel 2.3.1 das 3-Zyklen-Modell der Produktentstehung nach GAUSEMEIER vorgestellt. Das Modell gliedert die durchzuführenden Tätigkeiten in der Entstehung mechatronischer Systeme. Da ein wesentlicher Schwerpunkt dieser Arbeit auf dem Bereich der Produktentwicklung liegt, wird in Kapitel 2.3.2 die VDI-Richtlinie 2206 beschrieben. Sie bildet nach wie vor den minimalen Konsens über eine Methodik zur Entwicklung mechatronischer Systeme. Anschließend werden in Kapitel 2.3.3 die Handlungsfelder des Systems Engineering analysiert. Komplettiert wird das Kapitel durch eine Untersuchung des Model-Based Systems Engineering in Kapitel 2.3.4. Durch den Vergleich der Konstruktionswissenschaft mit dem Systems Engineering wird das Handlungsfeld des zu erarbeitenden Instrumentariums aufgezeigt. 2.3.1 3-Zyklen-Modell nach GAUSEMEIER Der Produktentstehungsprozess nach GAUSEMEIER erstreckt sich von der Produkt- bzw. Geschäftsidee bis zum Serienanlauf. Nach Bild 2-6 setzt er sich aus folgenden Aufgabenbereichen zusammen: Strategische Produktplanung, Produktentwicklung und Produktionssystementwicklung. Kerngedanke des Modells ist, dass die durchzuführenden Aufgaben im Wechselspiel zueinander stehen und folglich in drei Zyklen durchlaufen werden [GP14, S. 25ff.]. Die einzelnen Zyklen und ihr Zusammenspiel werden im Folgenden näher erörtert. Bild 2-6: 3-Zyklen-Modell der Produktentstehung [GP14, S. 26] G RS (s) G M (s) Produktentwicklung Produktionssystem- entwicklung Strategische Produktplanung Von der Geschäftsidee... ...zum Serienanlauf. Geschäftsplanung Geschäftsstrategie Produktstrategie Geschäftsplan Potentialfindung Erfolgspotentiale, Handlungsoptionen der Zukunft Produktfindung Produkt- und Dienstleistungsideen Anforderungen Entwurf und Ausarbeitung Komponente A Komponente B Regelungstechnik Elektronik Softwaretechnik Mechanik Produktintegration Verifiziertes Gesamtsystem Produktkonzipierung Strategiekonforme, ganzheitliche Produktkonzeption Mechatronik Mechanik Softwaretechnik Elektronik Regelungstechnik Produktionssystemintegration Arbeitsplanung Materialfluss- planung Arbeitsmittel- planung Arbeitsablauf- planung Arbeitsstätten- planung Produktionssystemkonzipierung Ablauf Fabrik Logistik Mittel Strategiekonforme, ganzheitliche Produktionskonzeption Verifiziertes Produktionssystem Seite 18 Kapitel 2 Erster Zyklus: Strategische Produktplanung Die strategische Produktplanung umfasst die Aufgabenbereiche Potentialfindung, Produktfindung, Geschäftsplanung und Produktkonzipierung. Im Rahmen der Potentialfindung sind Erfolgspotentiale der Zukunft sowie die resultierenden Handlungsoptionen zu identifizieren. Die Szenario-Technik, Delphi-Studien, Trend- und Marktanalysen ermöglichen ein methodisches Vorgehen. Unter Berücksichtigung der gefundenen Potentiale kann im Rahmen der Produktfindung die Suche, Auswahl und Erschließung neuer Produkt- und Dienstleistungsideen durchgeführt werden. Grundlegende Hilfsmittel sind das Laterale Denken nach DE BONO, TRIZ oder Technologie-Roadmaps. Die Geschäftsplanung legt zunächst fest, wann, wie und auf welchen Marktsegmenten ein Unternehmen operieren wird. Die resultierende Geschäftsstrategie ist erforderlich, um eine Produktstrategie zu erarbeiten. Aus den Produktstrategien folgt ein Geschäftsplan. Dieser liefert den Nachweis, ob neue Produkte einen attraktiven Return on Investment (ROI) ergeben. Zweiter Zyklus: Produktentwicklung Die Produktentwicklung setzt sich aus den Aufgabenbereichen Produktkonzipierung, Entwurf und Ausarbeitung sowie Produktintegration zusammen. Die Verbindung der ersten beiden Zyklen erfolgt über die Produktkonzipierung. In diesem Aufgabenbereich steht die Entwicklung prinzipieller Lösungen für das angestrebte Produkt im Vordergrund. Unter Berücksichtigung der funktionalen Anforderungen erfolgen im Anschluss disziplinspezifische Entwürfe und die entsprechenden Ausarbeitungen. Die einzelnen Lösungen werden anschließend im Rahmen der Produktintegration zu einem verifizierten Gesamtsystem zusammengefasst. Dritter Zyklus: Produktionssystementwicklung Den Ausgangspunkt bildet die Konzipierung des Produktionssystems. Dabei sind die vier Aspekte Arbeitsablaufplanung, Arbeitsmittelplanung, Arbeitsstättenplanung und Produktionslogistik integrativ zu betrachten. Die vier Aspekte sind im Verlauf dieses dritten Zyklus weiter zu konkretisieren. Produkt- und Produktionssystementwicklung sind parallel und eng aufeinander abgestimmt voranzutreiben. Nur so wird sichergestellt, dass auch alle Möglichkeiten der Gestaltung eines leistungsfähigen und kostengünstigen Erzeugnisses ausgeschöpft werden. Demzufolge verdeutlichen die beiden waagerechten Pfeile in Bild 2-6 die enge Verbindung und den damit verbundenen hohen Abstimmungsbedarf von Produkt- und Produktionssystementwicklung. Dieser beginnt bereits in der Konzipierung und bleibt über den weiteren Verlauf der Konkretisierung in Entwurf und Ausarbeitung bestehen. Problemanalyse Seite 19 2.3.2 Entwicklung mechatronischer Systeme – VDI2206 Wie in Kapitel 2.2 beschrieben, beruhen mechatronische Systeme auf dem Zusammenwirken der Fachdisziplinen Maschinenbau, Elektrotechnik und Informationstechnik. Jede Disziplin deckt dabei weitere Spezialisierungsfelder ab: Im Maschinenbau sind dies die Mechanik, Hydraulik, Pneumatik, Mikrotechnik; in der Elektrotechnik sind es die Antriebstechnik, Leistungselektronik oder auch Mikroelektronik; in der Informationstechnik (Regelungstechnik und Softwaretechnik) sind dies die Automatisierungstechnik und die eingebettete Software [Ise08]. Diesem Zusammenspiel, auch der spezialisierten Handlungsfelder, muss eine geeignete Entwicklungsmethodik für mechatronische Systeme gerecht werden. In diesem Zusammenhang existieren zahlreiche Entwicklungsleitfäden bzw. Methodiken, die in der Regel jedoch auf einzelne Fachdisziplinen ausgerichtet sind. Zu nennen sind z.B. die VDI-Richtlinie 2221 [VDI2221], die Konstruktionslehre nach PAHL/BEITZ [PBF+07], das Y-Modell der Schaltungstechnik [BGH+96] und das V-Modell der Softwareentwicklung [BD93]. Eine Methodik, die in der Wissenschaft und Industrie derzeit den größten Konsens bildet, ist die VDI-Richtlinie 2206 „Entwicklungsmethodik für mechatronische Systeme“ [VDI2206]. Das grundsätzliche Vorgehen zur fachdisziplinübergreifenden Entwicklung mechatronischer Systeme gliedert sich in drei übergeordnete Bereiche. Diese sind der Problemlösungszyklus auf der Mikroebene, das V-Modell auf der Makroebene sowie die Prozessbausteine für wiederkehrende Arbeitsschritte. Problemlösungszyklus auf der Mikroebene Der Problemlösungszyklus auf der Mikroebene soll den Produktentwickler bei der Bewältigung vorhersehbarer, aber auch unerwarteter Probleme unterstützen. Er gliedert sich in die Schritte Situationsanalyse/Zielformulierung bzw. Zielübernahme/Situationsübernahme, Analyse/Synthese, Bewertung, Entscheidung sowie Planung des weiteren Vorgehens. Die Prozessplanung lässt sich dabei variabel an die jeweiligen Entwicklungsaufgaben anpassen. V-Modell auf der Makroebene Das V-Modell zur Beschreibung des grundsätzlichen Vorgehens bei der Entwicklung mechatronischer Systeme stammt ursprünglich aus der Softwaretechnik. Es wurde an die Entwicklungsanforderungen der Mechatronik angepasst (vgl. Bild 2-7). Vor dem Durchlaufen des V-Modells werden Anforderungen an das zu entwickelnde System spezifiziert. Den Abschluss des Vorgehens bildet das entwickelte Produkt. Die einzelnen Bestandteile und Prozessschritte werden nachfolgend detailliert beschrieben, wobei ein besonderer Fokus auf dem Systementwurf liegt. Anforderungen: In Anlehnung an die VDI 2221 gilt es zunächst in der Phase Planen und Klären der Aufgabe, die Anforderungen zu spezifizieren. Dies geschieht in Form einer Anforderungsliste, die die Basis für das weitere Vorgehen bildet. Hierbei wird Seite 20 Kapitel 2 zwischen funktionalen und nicht funktionale Anforderungen18 sowie Wünschen unterschieden. Bild 2-7: Das V-Modell als Makrozyklus (rechts) und die Tätigkeiten für den Prozessbaustein „Systementwurf“ nach [VDI2206, S. 32] Systementwurf: Der Systementwurf beginnt mit der Abstraktion der Aufgabenstellung zum Erkennen der wesentlichen Probleme. Es ist ein initialer Schritt zur Definition der Funktionen, die von dem System erfüllt werden müssen. Nach PAHL/BEITZ beschreibt eine Funktion den gewollten Zusammenhang zwischen einem Eingang und einem Ausgang eines Systems, mit dem Ziel eine Aufgabe zu erfüllen [PBF+07, S. 44]. Eine Funktion wird in der Regel durch eine Substantiv-Verb-Kombination beschrieben (z.B. „Drehmoment erzeugen“). Generell ist darauf zu achten, dass die Funktionen möglichst lösungsneutral formuliert sind. Die Darstellung der Funktionen erfolgt durch eine Funktionsstruktur oder eine Funktionshierarchie. Bei einer Funktionshierarchie steht an oberster Stelle die Gesamtfunktion. Diese wird so lange in Teilfunktionen zerlegt, bis passende Lösungsprinzipien19 gefunden werden [VDI2221, S. 10]. Insbesondere für maschinenbauliche Problemstellungen existieren Konstruktionskataloge, die dem Entwickler die Suche vereinfachen und ihm ein möglichst facettenreiches Spektrum an Lösungen präsentieren sollen [KK98], [Rot01]. 18 Der Ursprung dieser Unterteilung liegt in der Softwaretechnik. Für weitere Informationen sei an dieser Stelle verwiesen auf [BBK+09], [SBD+10]. Funktionale Anforderungen beziehen sich auf das Systemverhalten. Ein Beispiel für nicht funktionale Anforderungen sind z.B. Qualitätsanforderungen. 19 Die angesprochenen Lösungsprinzipien sind Kernbestandteil der vorliegenden Arbeit und werden daher in Kapiteln 2.4.4 und Kapitel 4.3. im Detail beschrieben. Modellbildung und -analyse Informationstechnik Elektrotechnik Maschinenbau Fachdisziplinspezifischer Entwurf Systementwurf Systemintegration Anforderungen Produkt Eigenschaftsabsicherung • • • • • • Phasen/Meilensteine Aufgaben/Tätigkeiten Planen und Klären der Aufgabe Lösungskonzept Anforderungsliste Systementwurf Abstraktion zum Erkennen der wesentlichen Probleme Aufstellen der Funktionsstruktur Gesamtfunktion – Teilfunktion Suche nach Strukturen zur Erfüllung von Teilfunktionen Wirkstruktur – Baustruktur Konkretisieren zu prinzipiellen Lösungsvarianten Bewerten und Auswählen Festlegung des domänenübergreifenden Lösungskonzepts Disziplinspezifischer Entwurf Resultate Problemanalyse Seite 21 Aufbauend auf den Suchergebnissen findet die Konzeptsynthese statt. Kernelement ist die sog. Wirkstruktur20. Diese bildet Systemelemente sowie deren Merkmale und Beziehungen zueinander ab. Die Wirkstruktur veranschaulicht somit den grundsätzlichen Aufbau und die prinzipielle Wirkungsweise des zu entwickelnden Systems. Zur besseren Übersichtlichkeit und Komplexitätsbeherrschung auf Gesamtsystemebene lassen sich mehrere Systemelemente zu logischen Gruppen zusammenfassen. Im Zuge der Konkretisierung wird die Wirkstruktur in stark vereinfachte Bau- und Komponentenstrukturen überführt. Eine Baustruktur stellt gestaltbehaftete Systemelemente (Synonym: Bauteile) und deren Anordnung im Raum sowie deren logische Aggregation zu Baugruppen dar [PBF+07, S. 56]. Sie ist Ausgangspunkt für den späteren fachdisziplinspezifischen Entwurf im Maschinenbau. Das Pendant zu nicht gestaltbehafteten bzw. informationsverarbeitenden Systemelementen ist die Komponentenstruktur. Diese beschreibt das Zusammenspiel von (Software-)Komponenten21 in einem Gefüge [Oes05]. Generell werden im Rahmen des Systementwurfs mehrere potentielle Lösungsvarianten erarbeitet. Diese werden unter bestimmten Gesichtspunkten, in der Regel mit einer Nutzwertanalyse bewertet, um die beste Variante herauszukristallisieren. Als Ergebnis des Systementwurfs liegt eine fachdisziplinübergreifende Produktkonzeption vor. Fachdisziplinspezifischer Entwurf: Im Anschluss an die Erstellung des Produktkonzepts erfolgt eine Konkretisierung der Lösungsansätze in den unterschiedlichen Fachdisziplinen. Dabei ist es erforderlich, die Funktionserfüllung durch detaillierte Rechnungen und Auslegungen sicherzustellen. Systemintegration: Im Rahmen der Systemintegration werden die ausgearbeiteten Lösungen zusammengeführt. Das Ergebnis ist der Gesamtentwurf des mechatronischen Systems. Eigenschaftsabsicherung: Die Eigenschaftssicherung dient während der Systemintegration der Ergebnisüberprüfung anhand der Anforderungen. Modellbildung und -analyse: Die Modellbildung und -analyse beinhaltet fortlaufend die rechnergestützte Entwicklung anhand von Modellen22. 20 Eine Abgrenzung zu Begriffen wie Systemmodell oder Produktmodell, die in der Literatur in diesem Zusammenhang häufig genannt werden, findet in Kapitel 2.3.4 statt. 21 SZYPERSKI definiert eine Softwarekomponente wie folgt: „A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties” [Szy02, S. 34]. 22 Nach STACHOWIAK ist: Ein Modell eine beschränkte Repräsentation (Abstraktions-, Verkürzungsmerkmal) von Entitäten und Beziehungen der realen Welt (Abbildungsmerkmal) mit einer eindeutigen Korrespondenz für ein festes Zeitintervall und für einen vorher festgelegten Zweck (pragmatisches Merkmal) [Sta73, S. 131f.]. Seite 22 Kapitel 2 Produkt: Das Resultat des V-Modells ist das Produkt. In der Regel ist es notwendig, das Vorgehensmodell mehrmals zu durchlaufen, um die Konkretisierung und den damit verbundenen Reifegrad des Endproduktes zu erhöhen. Prozessbausteine für wiederkehrende Tätigkeiten Für häufig wiederkehrende Tätigkeiten im Rahmen der Entwicklung werden sog. Prozessbausteine formuliert. Im Fokus des Systementwurfs steht dabei die Suche nach vorhandenen Lösungen in den unterschiedlichen Domänen, die zugleich Kern der vorliegenden Arbeit ist. Die Analyse dieses Vorgehensmodells verdeutlicht, dass die Ausarbeitungen stets domänenspezifisch erfolgen. Erst die Überprüfung der Funktionserfüllung gibt Aufschluss darüber, ob eine Kombination der einzelnen Lösungen möglich ist. Diese Vorgehensweise hat zur Folge, dass evtl. Unverträglichkeiten erst am Ende des Systementwurfs festgestellt werden können. VDI 2206 im Hinblick auf intelligente mechatronische Systeme Experten sind sich einig, dass eine Kluft zwischen der rasant ansteigenden Produktkomplexität fortgeschrittener mechatronischer Systeme und ihrer Beherrschung durch Entwicklungsmethodiken, wie der VDI 2206, besteht und zukünftig weiter ansteigen wird [GDS13]. Gründe liegen zweifelsohne in der voranschreitenden Entwicklung der Informations- und Telekommunikationstechnologien. Ihr Durchdringen des modernen Maschinenbaus erweitert die Systemgrenzen stetig. Die Rede ist heute von global verteilten cyber-physischen Systemen, die untereinander vernetzt sind und im Verbund agieren (vgl. Kapitel 2.2.3). Die Auswirkungen auf die gesamte Produktentstehung (vgl. Kapitel 2.3.1) sind enorm: Mehr Disziplinen als bisher müssen in die Entwicklung eingebunden werden (z.B. Experten zum Thema Sicherheit in global-verteilten Netzen); es müssen Produktstrategien neu durchdacht und Architekturen ggf. angepasst werden; neuartige Geschäftsmodelle sind zu entwickeln etc. Die Notwendigkeit, das System als Ganzes, zu betrachten, zu beherrschen, zu entwickeln und zu vermarkten ist derzeit größer denn je. Die VDI 2206 stößt dabei an ihre Grenzen. Ein Ansatz, dem in diesem Zusammenhang eine erfolgversprechende Rolle zugesprochen wird, ist das sog. Systems Engineering. 2.3.3 Systems Engineering „Das Ganze ist mehr als die Summe seiner Teile“ [Rop12, S. 25]. Dieser Grundgedanke des Systems Engineering ist bereits mehr als 2300 Jahre alt und geht zurück auf den Philosophen ARISTOTELES. Eine vielfach zitierte Definition von Systems Engineering liefert HITCHINS mit „Systems Engineering is the art and science of creating whole solutions to complex problems” [Hit07, S. 91]. Die Wurzeln liegen in der Systemtheorie, der Modelltheorie und der Kybernetik [Rop12, S. 25ff.]. Im Mittelpunkt des Systems Problemanalyse Seite 23 Engineerings, wie es heutzutage z.B. von der INCOSE23 vorangetrieben wird, steht das Systemdenken. Ziel ist das Verständnis und die Gestaltung komplexer Systeme [HWF+12, S. 33]. Die INCOSE definiert Systems Engineering wie folgt: „Systems Engineering ist ein interdisziplinärer Ansatz und soll die Entwicklung von Systemen methodisch ermöglichen. SE fokussiert ein ganzheitliches und zusammenwirkendes Verständnis der Stakeholder Anforderungen, der Entdeckung von Lösungsmöglichkeiten und der Dokumentation von Anforderungen sowie das Synthetisieren, Verifizieren, Validieren und die Entwicklung von Lösungen. Das gesamte Problem wird während der Konzeptentwicklung bis zur Systementwicklung betrachtet. Das Systems Engineering stellt hierfür geeignete Methoden, Prozesse und Best Practices bereit“ [INC12, S. 7].24 Für HABERFELLNER ET AL. ist Systems Engineering eine „methodische Komponente bei der Problemlösung“ [HWF+12, S. 27]. Es wird betont, dass die Methodik allein weder ausreicht, um ein Problem zu lösen, noch eine dominante Rolle spielen darf. HABERFELLNER ET AL. strukturieren Systems Engineering in die in Bild 2-8 dargestellten übergeordneten Bereiche: Die SE-Denkweise und den Problemlösungsprozess [HWF+12, S. 28ff.]. Bild 2-8: Konzept des Systems Engineering [vgl. HWF+12, S. 28] Die SE-Denkweise, die das Systemdenken und das SE-Vorgehensmodell umfasst, bildet den Kern des Systems Engineering. Das Systemdenken symbolisiert eine spezielle Denkweise, um komplexe Situationen, Sachverhalte und letztlich Systeme verstehen, strukturieren und gestalten zu können. Im Vordergrund steht die ganzheitliche Systembetrachtung. Dabei wird das System vor dem Hintergrund einer spezifischen Problemstellung oder Situation analysiert und notwendige Zusammenhänge aufgedeckt. Das Vorgehensmodell hingegen ist eine Art Leitfaden, um die gesamte Entwicklung in be- 23 INCOSE: International Council on Systems Engineering; siehe auch: www.incose.org 24 Deutsche Übersetzung des Originals [INC10] SE-Denkweise Systemdenken Vorgehensmodell Problemlösungsprozess Systemgestaltung Projektmanagement Techniken der Systemgestaltung Techniken des Projektmanagements Problem / Aufgabe Lösung Systemdenken: Denkweise, die es ermöglicht, komplexe Erscheinungen (Systeme) besser verstehen und gestalten zu können. Vorgehensmodell: Genereller Leitfaden, für die Um- oder Neugestaltung von Systemen. Seite 24 Kapitel 2 herrschbare Teilprozesse zu zergliedern. Je nach Komplexität des zu entwickelnden Systems kann das SE-Vorgehensmodell aus einzelnen Komponenten aggregiert werden. Hierbei sind vier Grundgedanken hervorzuheben [HWF+12, S. 57ff.]: • Top-Down-Vorgehen: Ziel ist es, ausgehend vom Ganzen, das Betrachtungsfeld schrittweise zu verkleinern, Lösungen (bzw. Lösungsmuster) zu finden und diese abschließend in der Synthese zusammenzuführen. • Varianten: Durch diesen Denkansatz sollen möglichst viele Lösungsmöglichkeiten bei der Systemsynthese ins Kalkül gezogen werden. Im Kontext des angestrebten Instrumentariums kann ein Lösungsmuster für den Systementwurf alle notwendigen Informationen über eine Variante repräsentieren. • Phasenablauf: Die Systementwicklung wird in eine zeitliche Reihenfolge gegliedert. • Problemlösungszyklus: Es handelt sich um einen Vorgehensleitfaden, der das Lösen von Problemen unterstützt. Ein Beispiel für einen derartigen Leitfaden ist das V-Modell der VDI-Richtlinie 2206 für die Entwicklung mechatronischer Systeme. Der zweite Bestandteil des SE-Konzepts ist der Problemlösungsprozess. Dieser wird unterteilt in die Systemgestaltung und das Projektmanagement. Letzteres repräsentiert organisatorische Aspekte wie die Verhandlung des Projektauftrags, Festlegung eines Projektteams etc. Die Systemgestaltung umfasst die Tätigkeiten für den inhaltlichen Aufbau einer Lösung. Im Rahmen des fachdisziplinübergreifenden Systementwurfs wird dabei die sog. Systemarchitektur25 erarbeitet, die nachgelagerte Entwicklungstätigkeiten determiniert. Dies geschieht auf Basis von Überlegungen und Entscheidungen aus der strategischen Produktplanung, wie z.B. einer Plattformstrategie. Gegenstand aktueller Forschungstätigkeiten im Systems Engineering ist die Beherrschung der Komplexität auf Gesamtsystemebene, insbesondere um in der frühen Phase die Basis für eine Konzeptentscheidung zu erarbeiten. In der Literatur werden dem Systems Engineering dabei folgende Aufgabenbereiche zugeordnet: Anforderungsdefinition, -analyse und -management; Systemdesign und -analyse; Verifikation und Validierung; Organisation und Koordination [INC12], [Wei06], [FMS12]. Die Effizienzsteigerung in diesen Aufgabenbereichen durch Nutzung abstrakter Modelle ist aktuell eine der Hauptforderungen aus der Industrie und Kern des sog. Model-Based Systems Engineering [GDS13]. Die steigende Komplexität fortgeschrittener mechatronischer Systeme erfordert mehr denn je eine ganzheitliche Abbildung und Herangehensweise (vgl. Kapitel 2.2.3). 25 Die Erläuterung der Systemarchitektur und die Einbettung im Kontext Model-Based Systems Engineering geschieht in Kapitel 2.3.4. Problemanalyse Seite 25 2.3.4 Model-Based Systems Engineering Ziel des Model-Based Systems Engineering ist ein fachdisziplinübergreifender Entwurf und die Analyse komplexer Systeme mit Hilfe von Modellen. Zentraler Baustein ist das sog. Systemmodell, das eine abstrakte und ganzheitliche Systembetrachtung ermöglicht (vgl. Bild 2-9). Es repräsentiert alle erforderlichen Informationen mit geeigneten Diagrammen, die alle partizipierenden Disziplinen gleichermaßen lesen und interpretieren können. Eine initiale Erstellung des Systemmodells erfolgt im Zusammenspiel aller beteiligten Disziplinen im Rahmen des Systementwurfs bzw. der Konzipierung. Es bildet die Basis für die Kommunikation und Kooperation entlang einer Produktentwicklung von der frühen Phase bis zur Verifikation und Validierung. Während des fachdisziplinspezifischen Entwurfs dient es in erster Linie zur transparenten Beschreibung der fachdisziplinübergreifend relevanten Informationen. Das Systemmodell ist erforderlich, um die Komplexität auf Gesamtsystemebene beherrschen und die Entwicklung managen zu können. Abstrakte und ganzheitliche Systembetrachtung Ein Systemmodell enthält sämtliche Informationen, um ein komplexes technisches System, wie z.B. ein mechatronisches System, ganzheitlich zu beschreiben. Drei Aspekte sind dabei wesentlich: Anforderungen, Systemarchitektur und Verhalten [Alt12, S. 9]. Anforderungen beschreiben, was das zu entwickelnde System leisten muss. Sie werden in der Regel in Textform festgehalten [Alt12, S. 10]. Es existieren jedoch auch Ansätze, Anforderungen formal mit Hilfe von Modellen zu beschreiben. Die Ursprünge dieser Herangehensweise liegen in der Informatik. Vielfach zitierte Arbeiten im Kontext Systems Engineering liefern HOOD ET AL. Sie erarbeiten Vorgehensweisen und grafische Modellierungssprachen, um Anforderungen fachdisziplinübergreifend verständlich und durchgängig zu spezifizieren [Hoo07, S. 46ff.] Anforderungen werden unterschieden in Wunsch-/Festforderung sowie funktionale/nicht funktionale Anforderungen26 [Alt12, S. 10f.], [PBF+07, S. 214ff.]. Festforderungen müssen erfüllt werden, andernfalls ist die erarbeitete Lösungsidee zu verwerfen. Wünsche sind hingegen optional. Es sollte jedoch versucht werden, diese zu erfüllen [PBF+07, S. 214ff.]. Funktionale Anforderungen machen Aussagen über das Systemverhalten, nicht funktionale Anforderungen beschreiben hingegen Qualitätsansprüche z.B. bzgl. Zuverlässigkeit, Effizienz oder Benutzbarkeit [ISO25010]. Definitionen und Synonyme vom Begriff Systemarchitektur existieren zahlreich. In Anlehnung an ULRICH und HABERFELLNER ET AL. beschreibt eine Systemarchitektur die Struktur eines Systems in Form von Funktionen, Systemelementen und deren Beziehungen zueinander, sowie die Zusammenhänge zwischen Funktionen und Systemelementen 26 Vgl. Kapitel 2.3.2 Seite 32 Kapitel 2 rung beruht dabei auf der Nutzung verschiedener organisationaler Speichermedien für Wissen. 2.4.4 Lösungsmuster – ein geeigneter Wissensmanagementansatz? Aufbauend auf grundsätzlichen Abläufen des Wissensmanagements setzt sich dieses Kapitel mit der Fragestellung auseinander, ob Lösungsmuster ein geeigneter Wissensmanagementansatz sind. Dies gilt sowohl zur Unterstützung des fachdisziplinübergreifenden Entwurfs, als auch für seine Einbettung in die Produktentstehung. In diesem Zusammenhang wird dabei der These gefolgt, dass aus einer Kombination der Stärken aus der Konstruktionswissenschaft und dem Systems Engineering die erfolgversprechende Gesamtmethodik für die Entwicklung fortgeschrittener mechatronischer Systeme resultiert. In diesem Zusammenhang sind folgende Forderungen aus der Industrie wesentlich für die Weiterentwicklung und Anwendbarkeit des Systems Engineering: Interdisziplinarität, Durchgängigkeit und Modellbasiertheit [GDS13]. Für die Identifizierung eines geeigneten Konzepts erfolgt daher zu Beginn eine Gegenüberstellung etablierter Ansätze für das Wissensmanagement mit den genannten Forderungen (vgl. Bild 2-13). Bild 2-13: Gegenüberstellung – Wissensmanagementansätze und Forderungen aus der Industrie Interdisziplinarität beschreibt die Art und Weise der Wissensrepräsentation und -prä- sentation. Das Konzept sollte für alle an der Produktentwicklung beteiligten Fachdisziplinen gleichermaßen verständlich sein. Modellbasiertheit steht für die Forderung nach einer Wissensrepräsentation in Form von Modellen und die damit einhergehende proaktive Integration in die Entwicklung. Die Eigenschaft Durchgängigkeit fordert die kontinuierliche Anwendung von nur einem Konzept über alle Phasen der Produktentwicklung hinweg. So muss beispielsweise Lösungswissen für die Konzipierung nahtlos mit dem Lösungswissen für den Softwareentwurf verbunden sein. Bewertung: = Potential nicht vorhanden = Potential vorhanden Interdisziplinarität Modellbasiertheit Durchgängigkeit Knowledge Maps/ Topic Maps Template Feature Wirkprinzipien Patente – Innovative Prinzipien Muster ... Problemanalyse Seite 33 Knowledge Maps oder Topic Maps ist ein Wissensmanagementansatz bei dem die individuelle Wissensaufbereitung mit Hilfe semantischer Technologien erfolgt. Ziel ist die Vernetzung modular aufgebauter textbasierter Dokumente, z.B. Steckbriefe über Lessons Learned oder Best Practices [Web10], [Mau11]. Der wesentliche Nachteil ist, dass die Wissenspräsentation nicht mit Modellen aus der Entwicklung oder Prozessplanung erfolgt, sondern textuell oder mit Hilfe von Skizzen. Ein Template (engl. für Vorlage) definiert eine stark vorstrukturierte Lösung im Sinne einer Schablone mit fest definierten Variationspunkten und Variablen. Es ist ein Ansatz, der je nach Ausprägung, den aufgezeigten Forderungen gerecht werden kann. In Anlehnung an die VDI 2218 sind Feature informationstechnische Elemente, die Bereiche von besonderem (technischen) Interesse von einzelnen oder mehreren Produkten darstellen [VDI2218]. Im Maschinenbau ist die Rede von Funktions-, Prinzip-, Bau- oder auch Form-Feature. Die Interpretation des Begriffs Feature ist über die Fachdisziplinen hinweg jedoch keineswegs einheitlich [MBD+05]. Eine vielfach zitierte Definition in der Softwareentwicklung liefern KANG ET AL. in der FODA (Feature Oriented Domain Analysis). Demnach ist in der Übersetzung des englischsprachigen Originals ein Feature: „Ein auffälliges oder unterscheidungskräftiges für den Kunden sichtbares Qualitätsmerkmal oder Charakteristikum eines oder mehrerer Softwaresysteme“ [vgl. KCH+90, S. 3]. Die unterschiedlichen Definitionen von Feature und Variationen bei der Nutzung sind Barrieren für eine durchgängige Übertragung auf die Produktentstehung. Wirkprinzipien28 sind vor allem im klassischen Maschinenbau bekannt und etabliert. Es existieren zahlreiche Konstruktionskataloge in Form von Büchern oder Softwarewerkzeugen [Rot01] [Lug06-ol]. Für ein durchgängiges Wissensmanagement über alle Bereiche der Produktentstehung eignen sich Wirkprinzipien nicht, sollten aber in geeigneter Weise berücksichtigt werden. Nach DUMITRESCU repräsentieren Wirkprinzipien elementare Lösungsprinzipien auf denen komplexe Lösungsmuster beruhen. Als Pendant auf Seiten der Software werden Verfahren oder Algorithmen genannt [Dum10]. Die Nutzung von Patenten ist außerordentlich erfolgversprechend in der systematischen Generierung von neuartigen Produktideen. So definierte z.B. ALTSCHULLER in der Theorie des erfinderischen Problemlösens (TRIZ) wiederkehrende innovative Prinzipien aus einer Analyse von ca. 200.000 Patenten; die Rede ist auch von wiederkehrenden Denkmustern zur Lösung von Problemen [GHK+06]. 28Ein Wirkprinzip beschreibt den Grundsatz, von dem sich eine bestimmte Wirkung zur Erfüllung einer Funktion ableitet (physikalischer, biologischer, chemischer Effekt (oder Effekte) sowie geometrische und stoffliche Merkmale in Verbindung mit einer Teilfunktion) [PBF+07, S. 54]. Seite 34 Kapitel 2 Bei der Definition der genannten Begriffe kommt es wiederholt zur Verwendung des Begriffs Muster. Die in der Literatur am häufigsten zitierte Definition von Mustern im Kontext der Produktentstehung geht zurück auf den Architekturtheoretiker ALEXANDER. Nach ALEXANDER beschreibt: „…jedes Muster ein in unserer Umwelt immer wieder auftretendes Problem sowie den Kern der Lösung dieses Problems, und zwar so, dass man diese Lösung millionenfach anwenden kann, ohne sich je zu wiederholen“ [AIS+95, S. 12]. Im Umgang mit Mustern ist es entscheidend, das gesamte Problem in Teilprobleme zu zerlegen, für die eine Lösung ausgearbeitet werden kann. Die anschließende Zusammenführung der Teil- bzw. Grundprobleme soll zur Lösung des übergeordneten Gesamtproblems führen. Der Anwender eines solchen Musters erhält erste Lösungsansätze für sein Problem bzw. Teilproblem. Aufgrund der Tatsache, dass in derartigen Mustern lediglich der Problem- und Lösungskern beschrieben wird, ist eine Anpassung an die jeweiligen Randbedingungen des Gesamtproblems notwendig. Um die Anwendung des Musters sicherzustellen, spezifiziert ALEXANDER zusätzlich eine sog. Mustersprache29. Diese Sprache soll dazu beitragen, die Muster in ein einheitliches, übersichtliches und zusammenhängendes Format zu bringen. Es stellt die verträgliche Verknüpfung zu über- und untergeordneten Mustern sicher. Hierzu definiert ALEXANDER vier Kategorien, die jedes Muster enthalten muss [AIS+95]: • Name und Beispielbild • Kontext: In dieser Kategorie ist der Kontext, in dem das Muster eingesetzt wird, beschrieben. Zusätzlich wird erklärt, wie es sich in übergeordnete Muster einfügen lässt. • Problem: In diesem Abschnitt des Musters erfolgt eine detaillierte Problembeschreibung. • Lösung: Die Darstellung der Problemlösung ist der wichtigste Teil eines Musters. Die Lösung wird dabei im Sinne einer Anleitung für den Anwender beschrieben. Abschließend folgt eine Erklärung über die Verknüpfung zu untergeordneten Mustern. BARTER und HASKINS liefern eine vereinfachte Definition, nach der „ein Muster definiert ist als eine Lösung für ein spezifisches Problem innerhalb eines bestimmten Kontextes“ [Bar98], [Has05]. Die Wissensrepräsentation eines Musters unterteilt sich dabei 29 Nach BECK wird „eine Menge von Mustern zur Mustersprache, wenn die Ausprägung von Mustern, zu weiteren Mustern führt, die anschließend betrachtet werden sollten“ [BC87]; Vergleich mit natürlicher Sprache: Lösungsmuster = Vokabeln; Beziehung zw. den Mustern = Grammatik; Lösungsmuster + Beziehungen = (Muster)Sprache Problemanalyse Seite 35 in die Kategorien Name, Problem, Lösung und Kontext. Der Kern ist somit eine verallgemeinerte Problem- und Lösungsbeschreibung. In der Definition ist ein Muster derart abstrakt, dass die zuvor genannten Ansätze teilweise als solche interpretiert werden können. Es ist daher eher ein übergeordnetes Konzept, das etablierte Herangehensweisen geeignet vereinen kann. So können die 40 innovativen Prinzipien von ALTSCHULLER als stark generalisierte Muster verstanden werden, auf die alle Problem- und Lösungsbeschreibungen zurückgeführt werden können. Je stärker ein Problem-Lösungspaar abstrahiert bzw. generalisiert wird, desto größer werden der Anwendungskontext und die Möglichkeiten der spezifischen Ausprägungen. Diesem Grundgedanken folgte ALTSCHULLER bei der Identifizierung der innovativen Prinzipien bei der Analyse von Patenten. Zahlreiche Untersuchungen und Diskussion zeigen, dass das Konzept der Muster bzw. Lösungsmuster den aufgezeigten Forderungen an ein durchgängiges Wissensmanagement gerecht werden kann. Bei einer konsequenten Übertragung auf die gesamte Produktentstehung besitzt der Musteransatz auch das Potential, die eingangs skizzierten Barrieren (strukturell, prozessual und politisch) zu überwinden (vgl. Kapitel 2.4). Auf Basis eines umfangreichen Überblicks nach RISING und weitergehenden Überlegungen von DEIGENDESCH, SANZ/ZALEWSKI und SUHM lassen sich folgende Vorteile von Lösungsmustern herausstellen [Ris98], [Ris00], [Dei09], [SZ03], [Suh93]: • Übertragbarkeit: Der Aufbau von Lösungsmustern unterliegt einer einheitlichen Struktur. Dies ermöglicht die Übertragbarkeit auf alle an der Produktentstehung beteiligten Bereiche. Lösungsmuster bieten somit die Möglichkeit der sprachenunabhängigen Wiederverwendung bzw. Repräsentation von Wissen. • Verbesserung der Kommunikation: Lösungsmuster verbessern die Kommunikation auf vielfältige Art und Weise. Sie verbessern die Kommunikation zwischen: 1) einem Entwickler und sich selbst, 2) Entwicklern innerhalb eines Teams (fachdisziplinspezifisch) sowie 3) Entwicklern mehrerer Teams (fachdisziplinübergreifend). Sie bilden folglich die Plattform zur Reflektion abgeschlossener Entwicklungstätigkeiten und somit entwicklungsrelevanten Wissens. • Langfristige Dokumentation: Lösungswissen in der Produktentstehung liegt häufig nur implizit vor, z.B. in langjähriger Erfahrung einzelner Mitarbeiter. Dieses Wissen kann in Form von Lösungsmustern externalisiert und somit Dritten zur Verfügung gestellt werden. Ein Lösungsmuster ist ein sehr gut wartbares Dokument, das fortwährend modifiziert und optimiert werden kann. Lösungsmuster eignen sich vor allem im Hinblick auf eine zielgerichtete Suche, da neben dem Musternamen, eine Vielzahl an Informationen das zugrunde liegende Problem charakterisiert. • Komplexitätsreduktion: Lösungsmuster tragen erheblich zur Komplexitätsreduktion umfangreicher Problemstellungen bei. Es bietet sich an, komplexe Ge- Seite 36 Kapitel 2 samtprobleme in elementare Probleme zu zergliedern. Dies schließt die Zerlegung der zugehörigen Lösungen mit ein. Lösungsmuster lassen sich daher voneinander abgrenzen, wobei sich starre Klassifikationen und Hierarchien als wenig zielführend erweisen. Vielmehr sind wechselseitige Beziehungen zwischen Lösungsmustern in geeigneter Form zu beschreiben. • Effizienzsteigerung: Mit Hilfe von Lösungsmustern lässt sich die Effizienz in Problemlösungsprozessen signifikant steigern. Es wird die Möglichkeit geschaffen, kollektives Erfahrungswissen zielgerichtet in neue Entwicklungsprojekte einzubringen. Gemäß der Zielsetzung von Ansätzen zum Best-Practice und Lessons-learned helfen Lösungsmuster, Erfolge aus der Vergangenheit hervorzuheben und Misserfolge zukünftig zu vermeiden. • Förderung der Kreativität: Lösungsmuster enthalten im Vergleich zu detaillierten Lösungen, abstrahierte (generalisierte) Informationen über eine Problem- Lösungskombination. Der Generalisierungsgrad lässt sich dabei keinesfalls einheitlich festlegen. Mit zunehmender Generalisierung steigt demzufolge die Größe des Anwendungskontextes eines Musters. Ihr Einsatz in einem Lösungsprozess erfordert daher immer eine spezifische Anpassung auf das jeweilige Problem. Eine Vielzahl dokumentierter Lösungsmuster gibt Entwicklern Impulse, ihre eigenen Denkmuster mit dem Wissen des Kollektivs zu reflektieren und zu erweitern. Lösungsmuster unterstützen folglich die Kreativität jedes Einzelnen; die Grundlage für die Entstehung von Innovationen. 2.4.5 Lösungsmuster in der Produktentstehung – Geschichte Das vorliegende Kapitel präsentiert die Analyse ausgewählter Lösungsmuster in ihrer geschichtlichen Entwicklung. Zweifelsohne beruhen die für die Produktentstehung relevanten Ansätze zu Lösungsmustern auf den Arbeiten des Architekturtheoretikers ALEXANDER [AIS+77]. Der Grundgedanke, Lösungswissen in Form von Problem- Lösungsbeschreibungen Dritten zur Verfügung zu stellen, wurde anschließend in der Informatik aufgegriffen. Große Popularität genießen dort nach wie vor die Arbeiten von BECK und CUNNIGHAM, der Gang of Four30, COPLIEN31 oder auch RISING [BC87], [GhJ+94], [Cop91], [Ris98]. Die Arbeiten setzen sich intensiv mit grundsätzlichen Fragestellungen im Kontext Lösungsmuster sowie Mustersprachen auseinander. Nach BECK ist eine Mustersprache das Ergebnis von zeitlich aufeinander aufbauenden Mustern. Dies bedeutet, dass die Anwendung von Mustern die Grundlage für die Auswahl weiterer Muster ist [BC87]. 30 G AMMA ET AL. verhalfen im Jahre 1994 mit dem Buch „Design Patterns – Elements of Reusable Object-Oriented Software“ den Entwurfsmustern zum Durchbruch in der Softwareentwicklung [GHJ+94]. Sie sind seitdem unter den Spitznamen „Gang of Four“ (GoF) bekannt. 31 James Couplien war einer der Mitbegründer der PLoP (Pattern Language of Programms) Konferenz. Problemanalyse Seite 37 Eine sehr generische, vor allem auch namentliche, Übertragung des Musteransatzes auf den Maschinenbau liefert GRABOWSKI in der Universal Design Theory [GL00], [GL03]. Er unterteilt Lösungsmuster grundsätzlich in Objektmuster und Prozessmuster. Mit Objektmustern lassen sich Problemlösungen beschreiben, die sich anhand von Objekten manifestieren. Sie sind innerhalb eines definierten Kontextes gültig und unterstützen den Lösungsfindungsprozess. Diese Muster repräsentieren die Gestalt des Objektes elementar und deklarativ32. Beispiele sind physische Erzeugnisse oder auch Softwarecode. Ein Prozessmuster beschreibt den aktiven Gebrauch von Objektmustern. Im Gegensatz zur deklarativen Wissensrepräsentation eines Objektmusters handelt es sich dabei um eine prozedurale Wissensrepräsentation. Ein Prozessmuster enthält somit eine Menge von Anweisungen, die zu einem bestimmten Ziel führen [Amb98]. Zusammenfassend lassen sich existierende Ansätze in die folgenden Kategorien unterteilen: Objektmuster, Prozessmuster und Mustersprache. Anhand dieser Unterteilung folgt die Gegenüberstellung von Lösungsmustern im Vergleich zwischen der Entwicklung mechatronischer Systeme und dem Systems Engineering. Die erwähnte Gegenüberstellung zeigt Bild 2-14. Fundamentale Arbeiten, auf denen die dargestellten Ansätze beruhen, sind farblich rot hervorgehoben. Es sind auch Ansätze aufgeführt, die von der Titulierung her von dem Begriff Lösungsmuster abweichen, jedoch durch die Wiederverwendung bestimmter Prinzipien oder Bausteine als Lösungsmuster interpretiert werden können. Auf Seiten der Entwicklung mechatronischer Systeme existieren traditionelle Ansätze (Objektmuster) der Regelungstechnik nach FÖLLINGER oder Wirkprinzipien im klassischen Maschinenbau nach PAHL/BEITZ [Foe72], [PB77]. Nach den Arbeiten von GAMMA ET AL. häuften sich die Ansätze auch mit entsprechender Titulierung. Zu nennen sind u.a. die Lösungsmuster nach GRABOWSKI, ALBERS oder auch DZIWOK [GL00], [AT11], [GSA+11], [DHT12]. Allen Ansätzen ist gemein, dass sie fachdisziplinspezifisch und innerhalb der Disziplin sehr fokussiert sind. So konzentriert sich beispielsweise ALBERS auf Entwurfsmuster in der Mikrotechnik. DZIWOK hingegen beschäftigt sich mit Koordinationsmustern für echtzeitkritische Softwarekommunikation. Eine Ausnahme bilden die Lösungsmuster für die Selbstoptimierung nach DUMITRESCU. Hier werden Ansätze der höheren Mathematik oder der künstlichen Intelligenz fachdisziplinübergreifend behandelt. Die Notwendigkeit nach wiederverwendbaren Prozessbausteinen beschreiben u.a. MURR, BICHLMAIER oder auch KAHL [Mur99], [Bic00], [Kah13]. Sie sind der hohen Dynamik im Entwicklungsgeschehen und der Forderung nach immer kürzer werdenden Time-To-Market Zeiten neuer Produktserien geschuldet. Diesen Anforderungen begegnen die genannten Ansätze unter Zuhilfenahme von Erfahrungswissen in 32„Die deklarative Wissensrepräsentation konzentriert sich auf die reine Beschreibung von Sachverhalten und macht grundsätzlich keine Angaben zur Anwendung des Wissens für eine konkrete Problemlösung“ [Suh93]. Seite 38 Kapitel 2 Form von Prozessbausteinen (Prozessmustern) während der Projekt- (bzw. Entwicklungsprozess-)planung. Bild 2-14: Geschichte von Lösungsmustern (Auszug) im Vergleich zwischen Systems Engineering und der Entwicklung mechatronischer Systeme Mustersprache 1980 1985 1990 1995 2000 2005 Systems Engineering Entwicklung mechatronischer Systeme G ASKA / G AUSE B ARTER S ALUSTRI S ANZ / Z ALEWSKI C LOUTIER H ASKINS A LEXANDER P AVAN F ÖLLINGER G AMMA ET . AL S UHM R OTH G RABOWSKI A LBERS D UMITRESCU D ZIWOK K AHL S IMPSON / S IMPSON P FISTER W EILKINS K ALAWSKY Legende R OELOFSEN fundamentale Arbeiten K OLLER / K ASTRUP M URR B ICHLMAIER 201019751970 P AHL / B EITZ D EIGENDESCH R ISING C OUPLIEN B ECK & C UNNIGHAM Objektmuster Prozessmuster kontextbezogene Arbeiten Problemanalyse Seite 39 Auch im Kontext Systems Engineering begann der Einsatz von Lösungsmustern nach den Arbeiten von GAMMA ET AL. Zu nennen sind hier u.a. die Arbeiten von GASKA/GAUSE oder CLOUTIER [GG98], [CD06]. Im Gegensatz zu den zuvor geschilderten fachdisziplinspezifischen Ansätzen z.B. von ALBERS wird die Nutzung von Lösungsmustern im Systems Engineering deutlich fachdisziplinübergreifender interpretiert. Dies bezieht sich weniger auf die Art der Wissensrepräsentation sondern vielmehr auf ihren Einsatz in vielen an der Produktentstehung beteiligten Bereichen. Dies verdeutlicht eine Übertragung des Lösungsmusteransatzes auch auf nicht technische Bereiche durch CLOUTIER [CD06]. Er nennt u.a. Organisationsmuster oder Geschäftsmuster sowie deren Zuordnung zu Systemarchitektur-, und Systementwurfsmustern. Es handelt sich hierbei in Bezug auf die Unterteilung nach GRABOWSKI um Objektmuster. Bei Systementwurfsmustern betont CLOUTIER ihren Neuheitsgrad und die Aktualität im Hinblick auf die steigende Komplexität der zu entwickelnden Systeme. Neben den bereits in Kapitel 2.4.4 aufgeführten Vorteilen von Lösungsmustern hebt CLOUTIER nachfolgende Eigenschaften gesondert hervor: • Die Beschreibung von Lösungsansätzen für das Gesamtsystem in Form von Mustern verbessert das gemeinschaftliche Verständnis aller partizipierenden Stakeholder. • Ihr fachdisziplinübergreifender Charakter fördert die Team-Kommunikation zwischen Mitgliedern des Systemarchitekturteams und den Entwicklungsteams (z.T. fachdisziplinspezifisch). • Mit Hilfe von Lösungsmustern lässt sich ein einheitliches Lexikon für Architekturteams erarbeiten. Es beinhaltet wiederverwendbare multidisziplinäre Lösungen für den Austausch zwischen den Systemarchitekten. • Die Standardisierung in Form einheitlicher Muster fördert die Effizienz in den frühen Phasen des Entwicklungsgeschehens auf Gesamtsystemebene. Ferner existieren im Systems Engineering Ansätze, die sich mit dem Themenfeld Mustersprache auseinandersetzen. Kern einer solchen Sprache sind Beschreibungen der wechselseitigen Beziehungen zwischen den Mustern [SS06]. Zu nennen sind hier u.a. die Arbeiten von PAVAN, SIMPSON oder auch PFISTER [PMZ03], [SS06], [PCH+11]. Sie beschreiben Beziehungsformen zwischen Mustern auf einer Meta-Ebene. Beziehungen können z.B. sein: äquivalent, nachfolgend zu betrachten, zusätzlich erforderlich, in Kombination nicht verträglich [PCH+11]. Relevante Mustersprachen (fachdisziplinübergreifend) bezogen auf den Kontext der vorliegenden Arbeit für die Entwicklung mechatronischer Systeme existieren nicht. Seite 40 Kapitel 2 2.5 Problemabgrenzung Zusammenfassend lässt sich festhalten, dass ein wesentlicher Stellhebel für eine effiziente Entwicklung fortgeschrittener mechatronischer Systeme die Wiederverwendung relevanten Lösungswissens ist. Zukünftig wird es in diesem Zusammenhang mehr denn je darauf ankommen, das zu entwickelnde System als Ganzes zu betrachten und zu beherrschen (Kap. 2.3.3). Die zunehmende Intelligenz in den adressierten technischen Systemen (Kap. 2.2) erfordert ein fachdisziplinübergreifendes Denken und Handeln über alle an der Produktentstehung beteiligten Bereiche hinweg (Kap. 2.3). Dies schließt, neben den vorrangig technischen Disziplinen, die nicht technischen Segmente wie z.B. den Vertrieb mit ein. Erfolgversprechende Entwicklungsmethodiken werden zukünftig aus dem Verschmelzen der Denkweisen der Konstruktionslehre (Kap. 2.3.2) und dem (Model-Based) Systems Engineering (Kap. 2.3.4) hervorgehen. Historisch betrachtet lassen sich dort signifikante Stärken für die Entwicklung komplexer technischer Systeme feststellen, die gleichermaßen für Entwicklungsmethodiken als auch für Wissensmanagementansätze mit Lösungsmustern gelten (2.4.5). In der Konstruktionslehre bzw. Entwicklung mechatronischer Systeme sind dies in erster Linie etablierte, jedoch fachdisziplinspezifische Ansätze z.T. basierend auf Objektmustern (z.B. Wirkprinzipien). Im Systems Engineering sind es vor allem die ganzheitlichen fachdisziplinübergreifenden Vorgehensweisen zur Unterstützung des modellbasierten Systementwurfs. Für das angestrebte Instrumentarium sind drei grundsätzliche Herausforderungen hervorzuheben: Ungeklärter Lösungsmusterbegriff/-überblick: Ansätze zur Wiederverwendung von Lösungswissen in Form von Mustern gibt es zahlreich. Die Interpretation und die Einsatzgebiete sind jedoch äußerst vielfältig. Dies reicht von Beispielen, über die Art der Darstellung, die damit einhergehende Strukturierung bis hin zur Charakterisierung. Gemeint sind z.B. Unterscheidungen wie Objektmuster, Prozessmuster, elementare oder komplexe Muster [GL00], [Suh93]. Da diese Typisierungen aus einzelnen Disziplinen (z.B. dem Maschinenbau) kommen, stellt sich die Frage nach ihrer Allgemeingültigkeit. Eine Beantwortung erfordert eine umfangreiche Übertragung des Mustergedankens auf die Produktentstehung, was die nicht technischen Bereiche einschließt. Es ist daher erforderlich aufbauend auf Strukturierungsansätzen für die Produktentstehung wie z.B. dem 3-Zyklen-Modell nach GAUSEMEIER und Musterhierarchien aus dem Systems Engineering, eine umfangreiche Beschreibung für Lösungsmuster in der Produktentstehung zu erarbeiten [GP14], [CD06]. Nur auf diese Weise kann eine Einbettung von Lösungsmustern für den Systementwurf in eine musterbasierte Produktentstehung gelingen. Damit einher geht die Notwendigkeit, Aufgabenbereiche der Lösungsmuster festzulegen, um sowohl ihre Eigenständigkeit als auch Interaktion aufzuzeigen. Problemanalyse Seite 41 Dokumentation interdisziplinären Lösungswissens: Die Entwicklung fortgeschrittener mechatronischer Systeme kann nur durch das Zusammenwirken verschiedener Fachdisziplinen erfolgreich sein. Eine Hauptschwierigkeit liegt in der aufwendigen Kooperation und Kommunikation auf Gesamtsystemebene während des Systementwurfs. Hier sind Konzepte zur frühzeitigen, durchgängigen und gleichberechtigten Behandlung des Lösungswissens aus den partizipierenden Disziplinen notwendig. Die Forderung nach Durchgängigkeit birgt besondere Anforderungen aufgrund von unterschiedlichen Denkweisen. Während die eine Disziplin oftmals zu Beginn einer Entwicklung sehr abstrakt in Form von Wirkprinzipien denkt, startet eine andere Disziplin mit formalen Spezifikationen (u.a. mit Hilfe von Modellbibliotheken). Im Rahmen des Systementwurfs müssen derartige Denk- und Herangehensweisen zusammengeführt werden, was ohne weiteres aktuell nicht möglich ist. Das für den Systementwurf notwendige Wissen muss daher geeignet, in Form von Lösungsmustern, aufbereitet und repräsentiert werden. Es muss zudem ein nahtloser Übergang in den fachdisziplinspezifischen Entwurf oder in formale Analyseschritte möglich sein. Hierzu sind Beziehungen zwischen den Lösungsmustern für den Systementwurf mit z.B. Wirkprinzipien oder fachdisziplinspezifischen Lösungsmustern (z.B. Software) zu beschreiben. Fehlende Entwicklungssystematik: Die heute etablierten Entwicklungssystematiken werden der Forderung nach einem durchgängigen Wissensmanagement, mit besonderem Fokus auf dem interdisziplinären Systementwurf, nicht gerecht. Sie fokussieren in der Regel nur einen bestimmten Bereich oder eine Disziplin; eine ganzheitliche Betrachtung von wiederverwendbaren z.T. fachdisziplinübergreifenden Produktartefakten findet – wenn überhaupt – nur ansatzweise statt. Die Folge ist in der Regel die Kombination von disziplinspezifischen Teillösungen, die nur selten die bestmögliche Gesamtlösung ergeben. Es ist daher eine Systematik erforderlich, mit der Lösungsmuster für den Systementwurf identifiziert, dokumentiert und angewendet werden können. Lösungsmuster für den Systementwurf werden zukünftig ein zentraler Baustein in der Entwicklung fortgeschrittener mechatronischer Systeme sein. Sie tragen durch ihren fachdisziplinübergreifenden Charakter und ihren systematischen Einsatz wesentlich zur Effizienzsteigerung im Entwurf und zur Komplexitätsbeherrschung auf Gesamtsystemebene bei. Es besteht daher Bedarf nach einem Instrumentarium für einen lösungsmusterbasierten Entwurf fortgeschrittener mechatronischer Systeme. Es nimmt sich den skizzierten Herausforderungen an und gliedert sich in die in Bild 2-15 abgebildeten Handlungsfelder (HF): Handlungsfeld 1: Das Paradigma der Lösungsmuster in der Produktentstehung Basis des Instrumentariums ist eine ausführliche Beschreibung von Lösungsmustern in der Produktentstehung. Grundlage ist eine einheitliche Definition von Lösungsmustern Seite 48 Kapitel 3 Folglich hat jede Disziplin spezialisiertes Lösungswissen, das auf bestimmte Probleme angewandt werden kann. Ziel ist die Übertragbarkeit dieses Lösungswissen auf fachfremde Bereiche. Es soll die Möglichkeit geschaffen werden, bei einem Problem ohne sichtbare Lösung in dem jeweiligen Fachbereich, auf Lösungswissen aus einem anderen Fachbereich zurückgreifen zu können [GL00]. Dieses generalisierte Lösungswissen soll in Form von Lösungsmustern repräsentiert werden. Für GRABOWSKI ET AL. entsteht ein Lösungsmuster aus Erfahrungswissen von Experten, das sich in konkreten Lösungen manifestiert hat. Nutzen entsteht genau dann, wenn das Wissen über das Problem sowie den Problemlösungsweg nachvollziehbar dokumentiert ist. Lösungsmuster helfen, einen Ausgangszustand in einen Folge- bzw. Zielzustand zu überführen. Wesentliche prozessrelevante Merkmale sind ein hoher Kreativitätsanteil, hoher Vernetzungsgrad der Vorgänge, unscharfe Informationen, hohe Entscheidungsintensität, geringer Formalisierungsgrad sowie geringe Wiederholhäufigkeit. Grundlage zur Darstellung eines solchen Prozesses ist die Beschreibung seiner Zustände sowie die zugehörigen Zustandsänderungen [GL03]. Wie bereits in Kapitel 2.4.5 geschildert, wird in der UDT zwischen Objekt- und Prozessmustern unterschieden. Bild 3-1 zeigt den Zusammenhang von Objekt- und Prozessmustern. Bild 3-1: Zusammenhang von Objekt- und Prozessmustern in der UDT [vgl. GL00] Es wird deutlich, dass es sich bei einem Objektmuster um eine statische Lösung handelt und bei einem Prozessmuster um einen in der Zeit ablaufenden Vorgang. Der Ablauf eines Entwicklungsprozesses unterscheidet sich in der Kaskadierung von Objekt- und Prozessmustern. Beispielhaft sind in Bild 3-1 zwei Alternativen für den Entwicklungsprozess dargestellt. Der Ausgangszustand (SS, start state) beinhaltet alle Informationen über die Problemstellung. Durch Objekt- und Prozessmuster werden Zwischenzustände (Si, intermediate states) und zuletzt der Zielzustand erreicht (ST, target state). Sind die Process Pattern PP (S S , S T ) PP (S S , S 2 ) S S S 2 OP (S, 2) PP (S n-1 , S T ) S n-1 S T OP (n-1, T) PP (S i , S i+1 ) S i S i+1 OP (i, i+1) . . . . . . Object Pattern OP (S, T) Alternative 1 Alternative 2 Legende OP = Object Pattern SiST = State = Target State= Start StateSS PP = Process Pattern Stand der Technik Seite 49 Voraussetzungen bekannt und es gibt bereits eine entwickelte Lösung, dann ist der Zielzustand direkt über bekannte Objektmuster OP(S,T) und Prozessmuster PP (SS, ST) zu erreichen (Alternative 1). Gibt es hingegen keine bekannten, passenden Objekt- und Prozessmuster, so ist die Expertise der Entwickler gefragt, um den Zielzustand sukzessive zu erreichen. In diesem Entwicklungsprozess werden stufenweise Prozessmuster mit unterschiedlicher Komplexität durchlaufen, wodurch verschiedene Wege aufgrund verschiedener Objektmuster zum Ziel führen (Alternative 2) [GL00]. Ferner definiert GRABOWSKI die folgenden fünf Hypothesen für die Unterteilung und die Anwendung von Lösungsmustern [GL00]: • Hypothese 1 (Hypothesis of finite basic elements): Auf jeder Abstraktionsebene existiert eine endliche Anzahl von Basiselementen. • Hypothese 2 (Hypothesis of finite abstraction levels): Es existiert eine endliche Anzahl von Abstraktionsebenen, um Produkte zu modellieren und Design- Prozesse zu beschreiben. • Hypothese 3 (Hypothesis of finite transitions): Die Anzahl möglicher Übergänge zwischen den einzelnen Abstraktionsebenen ist endlich. Dabei entsteht die Verknüpfung der Hierarchieebenen durch die Verbindungen zwischen den Basiselementen. • Hypothese 4 (Hypothesis of invention): Neue Produkte entstehen durch neue Kombinationen bekannter Basiselemente. Beispiele derartiger Basiselemente sind Funktionen oder physikalische Effekte. • Hypothese 5 (Hypothesis of solution finding): Jede Produktanforderung bezieht sich auf einen Lösungsbereich. Die Ableitung einer Gesamtlösung ist nur dann widerspruchsfrei, wenn die Anforderungen und deren Lösungen konsistent und verträglich kombiniert wurden. Bewertung: Die Universal Design Theorie enthält ein sehr abstraktes und theoretisches Modell zur Erklärung bestehender Zusammenhänge in der Entwicklung technischer Systeme mit Hilfe von Mustern. GRABOWSKI ET AL. treffen die Unterscheidung zwischen Objekt- und Prozessmuster, wobei eine starke Abhängigkeit zwischen den Musterarten betont wird. In der UDT werden die Überlegungen jedoch nicht auf strategische Bereiche in der Produktentstehung ausgedehnt. Zudem mangelt es an nachvollziehbaren Beispielen, was eine direkte Übertragung dieses theoretischen Modells auf die im Instrumentarium geforderten Anforderungen ausschließt. 3.1.2 Musterhierarchie nach CLOUTIER Im Gegensatz zu den eingangs geschilderten Überlegungen von GRABOWSKI ET AL. wird der Einsatz von Lösungsmustern im Systems Engineering deutlich bereichsübergreifender interpretiert. Dies bezieht sich weniger auf die Art der Wissensrepräsentation in den Seite 50 Kapitel 3 Mustern, sondern vielmehr auf ihren Einsatz in vielen an der Produktentstehung beteiligten Bereichen. Dies verdeutlicht die Musterhierarchie nach CLOUTIER (Bild 3-2), in der auch nicht technische Bereiche berücksichtigt werden [CD06]. Bild 3-2: Musterhierarchie nach CLOUTIER [vgl. CD06] Muster auf höchster Ebene sind demzufolge Organisations-, Geschäfts- und Leitbildmuster. Eine Hierarchiestufe tiefer nennt CLOUTIER Systemarchitekturmuster, von denen es fünf unterschiedliche gibt: Strukturmuster (Strukturierungskonzepte z.B. Differentialbauweise), Rollenmuster (charakteristische Rollen beteiligter Akteure), Anforderungsmuster (wiederkehrende Anforderungsbündel), Aktivitätsmuster (SE-Prozess- bausteine) und Prozessmuster (Verhalten des Systems). Unter den Anforderungsmustern folgen Muster auf Gesamtsystemebene. Diese konzentrieren sich auf Systementwurf, -analyse und -test. An die Systementwurfsmuster schließen sich noch weitere Mustertypen an, die in die fachdisziplinspezifischen Bereiche der Hardware- und Softwareentwicklung unterteilt werden. Als zentrale Mustertypen im Hinblick auf eine signifikante Effizienzsteigerung in der Entwicklung komplexer technischer Systeme nennt CLOUTIER Systemarchitektur- und Systementwurfsmuster (vgl. Bild 3-2, farblich hervorgehoben). Bewertung: Die Musterhierarchie liefert einen ersten Ansatz für eine breit aufgestellte Übertragung des Lösungsmusteransatzes auf die Entwicklung komplexer technischer Systeme. Es stellt sich jedoch die Frage, wie die genannten Muster konkret aussehen und wie diese zueinander in Beziehung stehen. Hierzu werden außer der Titulierung der Muster keine näheren Angaben gemacht. Die konsequente Weitergabe von Informationen und die Verzahnung der Muster über die Hierarchiestufen hinweg ist jedoch Grundvoraussetzung für deren durchgängige Nutzung. Organisationsmuster Geschäftsmuster Leitbildmuster Systemarchitekturmuster Unterschiedliche Typen von Systemarchitekturmustern Strukturmuster Rollenmuster Anforderungsmuster Aktivitätsmuster Prozessmuster – Muster für die Art und Weise des Aufbaus – Muster für die Beschreibung von Rollen – Muster für Anforderungen – Muster für den SE-Prozess – Muster für die vom System durchzuführenden Prozesse Strukturmuster Rollenmuster Anforderungsmuster Aktiviätsmuster Prozessmuster Systemanalysemuster Systementwurfsmuster Systemtestmuster SW Analysemuster SW Architekturmuster HW Entwurfsmuster Betriebsmuster SW Anforderungsmuster HW Anforderungsmuster SW Testmuster SW Entwurfsmuster Erzeugungsmuster Strukturmuster Verhaltensmuster Stand der Technik Seite 51 3.1.3 SE Entwurfsmuster-Metamodell nach PFISTER Nach PFISTER eignen sich Lösungsmuster in erster Linie zur Abstraktion und Generalisierung individueller Lösungen, die in einer übergeordneten Gesamtarchitektur eingebettet sind. Ein Lösungsmuster bietet die Möglichkeit, Expertise von Fachleuten Dritten zur Verfügung zu stellen. Es unterstützt die Anwender in der Identifizierung und Lösung von Problemen durch die Übertragung des bestehenden Wissens bzw. der Erfahrung auf das jeweils vorliegende Problem. PFISTER nennt als Ziele von Lösungsmustern [PCH+11]: • Leistungssteigerung (Umfang, Relevanz) • Verbesserung der Funktionssicherheit (etablierte Lösungen, mehrmals kontextbezogen eingesetzt und geprüft) • Effizienzsteigerung (Zeitersparnis von der Produktidee bis zum Serienanlauf) • Förderung von gemeinschaftlichem Arbeiten durch Austausch von Wissen auf einer gemeinsamen Plattform Diese Ziele können erreicht werden, indem relevante Expertise, basierend auf implementierten Lösungen oder Erkenntnissen aus lessons-learned-Prozessen, formalisiert abgelegt werden. Lösungsmuster sind folglich ein Mittel, um weiteren Entwicklern standardisierte Lösungen zugänglich zu machen. PFISTER empfiehlt die Anwendung von Lösungsmustern im Systems Engineering bei der Synthese von funktionalen und physikalischen Architekturen. In diesem Zusammenhang fungiert ein Lösungsmuster als ein kleines und gut handhabbares Artefakt, das selten isoliert sondern im Zusammenhang mit weiteren betrachtet werden sollte. Das relevante Lösungswissen in einem Lösungsmuster wird mit Hilfe abstrakter physikalischer oder funktionaler Modelle repräsentiert. Es definiert das Zusammenwirken von Systemkomponenten oder -funktionen in generalisierter Art und Weise. Nach PFISTER ist ein Lösungsmuster keine Kreativitätstechnik und beschreibt auch keine wiederverwendbare detaillierte Komponente. In erster Linie ist es das Ergebnis eines mehrmals vorkommenden Lösungsansatzes in ähnlichen Problemstellungen. PFISTER betont, dass Lösungsmuster genau dann zu Innovationen führen, wenn sie auf weitere Problemstellungen in einem ähnlichen Kontext übertragen und geeignet modifiziert werden [PCH+11]. Im Hinblick auf einen modellbasierten Systementwurf sollten Lösungsmuster durch eine formalisierte Sprache beschrieben und in einer Datenbank abgelegt sein. Ferner ist sicherzustellen, dass die Modelle in eine Entwicklungsumgebung eingebunden werden können. Lösungsmuster und ihr Zusammenwirken lassen sich durch Sprachen wie SysML, UML, STEP oder auch die Web Ontology Language (OWL) beschreiben. PFISTER definiert Lösungsmuster in UML oder SysML in Form parametrisierbarer Beziehungen. Hierzu werden unterschiedliche Klassen und Objekte definiert. Diese besitzen Seite 52 Kapitel 3 spezifische Rollen und Beziehungen untereinander. Die Lösungsmuster werden in ein übergeordnetes Metamodell für das Systems Engineering eingebettet. Das entsprechende UML-Diagramm33 ist in Bild 3-3 abgebildet. Bild 3-3: Metamodell für ein lösungsmusterbasiertes Systems Engineering nach PFISTER [vgl. PCH+11] Es basiert auf den Überlegungen von CLOUTIER (vgl. Kapitel 3.1.2), beschreibt jedoch im direkten Vergleich die Beziehungen und Ausprägungen der Klassen und Objekte in einem höheren Formalisierungsgrad. Die Lösungsmuster für Systems Engineering („Systementwurfsmuster“) sind durch Angaben wie „Lösungsmustername, Autor und Datum“ zu spezifizieren und verfügen in dem Metamodell über direkte Beziehungen zu den Klassen “Funktion” und „Bestandteil”. Die Lösungsmuster sind daher indirekt mit der Klasse „System“ (technisches System) verbunden, das Beziehungen zu weiteren Klassen und zu sich selbst besitzt. Innerhalb einzelner Klassen ist an entsprechender Stelle auf bestimmte Untergruppen bzw. Typen verwiesen, für die jeweils Auswahllisten existieren bzw. zu definieren sind. Ein Beispiel ist die Klasse “Bestandteil“ mit dem Typ „:BestandteilTyp“ bestehend aus Subsystem, Element, Komponenten und Teil (Part). Das Metamodel hat primär den Anspruch, Lösungsmuster in das übergeordnete Systems Engineering formal einzubetten. Eine detailliertere Spezifikation der Lösungs- 33 Für eine ausführliche Beschreibung der Notation UML siehe Kapitel 3.2.1.2. Systementwurfsmuster + Name + Autor(en) + Datum Kontext LifeCycle Mission System agiert in hat eine ist in einem * interagiert mit externen Systemen * setzt sich zusammen aus Subsystemen Anforderung 1…* Funktion + Name + Beschreibung + Domäne :Architektur + Typ :FunktionTyp + ist Teil eines Musters ist beteiligt * 1…* führt aus Bestandteil + Typ :BestandteilTyp + Domäne :Architektur + ist Teil eines Musters setzt sich zusammen aus 1…* ist beteiligt * * Dekomposition * Dekomposition Allokation Betrachtungseinheit + Typ :BetrachtungseinheitTyp Schnittstelle 1 Rolle 1 Rolle 1 von 1 zu 1…* führt aus 1 Übertragung << Aufzählung >> BetrachtungseinheitTyp Physikalisch Information Energie ...ggf. zu erweitern << Aufzählung >> FunktionTyp << Aufzählung >> Architektur Domäne << Aufzählung >> BestandteilTyp Rotatorisch Translatorisch Fest verbunden … ggf. zu erweitern Physik Service Energie Subsystem Element Komponente Teil (Part) Stand der Technik Seite 53 muster, auch mit Beziehungen zu weiteren Mustern, beschreibt PFISTER mit dem Metamodell in Bild 3-4 [PCH+11]. Das Lösungsmuster-Metamodell spezifiziert PFISTER ebenfalls formal mit der UML. Mögliche Beziehungsformen zu weiteren Lösungsmustern sind: Anti-Muster, Äquivalente Muster, Verwandte Muster oder zusätzlich erforderliche Muster. Neben den zuvor bereits genannten Informationen in einem Muster wie Name, Autor und Datum, gibt es weitere Beziehungen, die ein Lösungsmuster beschreiben. Dazu zählen u.a. Angaben über: die zugrundeliegenden Anforderungen, die das Lösungsmuster erfüllt; Applikationen, in denen es erfolgreich eingesetzt wurde; eine Begründung; Pseudonyme oder Schlüsselwörter, die bei der Suche nach Lösungsmustern in einer Datenbank hilfreich sein können [PCH+11]. Bild 3-4: Systementwurfsmuster-Metamodell nach PFISTER [vgl. PCH+11] Lösungsmuster lassen sich mit Hilfe von Funktionen und Bestandteilen des Systems gliedern. PFISTER betont hierbei die Notwendigkeit der modellbasierten Repräsentation. Es ist entscheidend, dass die Problembeschreibung (Funktionen und Anforderungen) durch Modelle abgebildet wird. Gleiches gilt für die Lösungsbeschreibung in Form von generalisierten und abstrakten Bestandteilen des Systems. Das in Bild 3-4 abgebildete Metamodell erlaubt dabei den Einsatz unterschiedlichster Modellierungssprachen. Je nach Einsatzzweck eigenen sich Sprachen für die jeweiligen Aspekte wie Dynamik, Funktionen, Verhalten, Struktur etc. [PCH+11]. Bewertung: PFISTER stützt sich in seinen Arbeiten auf die Überlegungen zur Musterhierarchie nach CLOUTIER. Er beschreibt mit Hilfe der Modellierungssprache UML weniger die unterschiedlichen Arten von Lösungsmustern wie Prozess- oder Testmuster, sondern vielmehr die allgemeine Einbettung der Entwurfsmuster ins Systems Engineering. PFISTER beschränkt sich dabei auf den Entwurf des technischen Systems. Vor- und Systementwurfsmuster + Name + Autor(en) + Datum Funktion (des Systems) + Name + Beschreibung + Domäne :Architektur + Typ :FunktionTyp + ist Teil eines Musters erfolgreich eingesetzt ist gegliedert durch Bestandteil (des Systems) + Typ :BestandteilTyp + Domäne :Architektur + ist Teil eines Musters + Name + Beschreibung Schnittstelle (des Systems) * Anti-Muster 1 von 1 zu * Äquivalente Muster * Verwandte Muster * zusätzlich erforderliche Muster Rolle Rolle ist gegliedert durch Allokation 1…* führt aus Applikation Begründung Pseudonym Anforderung (des Systems) + Name + Kommentar Schlüsselwörter Seite 54 Kapitel 3 nachgelagerte Bereiche im Sinne der Produktentstehung nach GAUSEMEIER finden keine Berücksichtigung. Dieses wäre aufgrund des hohen Formalisierungsgrads in der gewählten Detailtiefe auch sehr aufwändig. Im Hinblick auf die direkte Implementierung des Lösungsmusteransatzes sind die Ergebnisse von PFISTER sehr hilfreich. Es mangelt jedoch an einem allgemeinverständlichen Überblick über Lösungsmuster in der PE, nicht zuletzt durch das Fehlen von Beispielen. 3.1.4 SE Mustersprache nach SIMPSON Nach SIMPSON eignen sich Lösungsmuster in erster Linie zur langfristigen Speicherung von relevantem Lösungswissen über komplexe Sachverhalte. Unter einem Lösungsmuster versteht SIMPSON die Lösung eines bestimmten Problems innerhalb eines bestimmten Kontextes. Die speziell entwickelte Mustersprache basiert auf Lösungsmustern für das Systems Engineering aus der Literatur und weiteren identifizierten Mustern von SIMPSON. Eine Mustersprache wird beschrieben als eine Sammlung von Mustern und die Beschreibung von wechselseitigen Beziehungen. SIMPSON fasst auch grundsätzliche Überlegungen und Gliederungsansätze im Systems Engineering als Muster auf. Dazu gehören u.a. die drei abstrakten und zudem global anzuwendenden Lösungsmuster34 [SS06]: • Es kann alles in Form eines “Systems” beschrieben werden • Das “Problem-System” ist immer getrennt vom “Lösungs-System” • Es sind immer “mindestens drei Systeme” gemeinsam zu betrachten: Umfeld-System, Produkt-System, Produktionsprozess-System SIMPSON betont, dass es zahlreiche Beschreibungen gibt, die die globalen Lösungsmuster und deren Beziehungen untereinander weiter verfeinern und detailliert spezifizieren. Dennoch bilden die genannten Lösungsmuster die Grundlage für eine initiale Ontologie. Ziel ist ein übergeordnetes Rahmenwerk, in dem diverse Lösungsmuster der am Systems Engineering beteiligten Bereiche gespeichert, diskutiert und in Zusammenhang zueinander gesetzt werden können. Das Resultat eines mit Lösungsmustern gefüllten Rahmenwerks wäre eine Systems-Engineering-Mustersprache. Zur näheren Erläuterung werden im Folgenden Ansätze für die Mustersprache vorgestellt [SS06]. Formen von Systems Engineering Mustersprachen: Mustersprachen setzen sich nach SIMPSON aus genau zwei Komponenten zusammen: Mustern und den Beziehungen zwischen den Mustern. Die Beziehungen können dabei sehr unterschiedlich sein, sollten jedoch alle das Ziel verfolgen, eine logische und verträgliche Kombination von Lösungsmustern zu ermöglichen. SIMPSON nennt zwei unterschiedliche Arten zur Darstellung der Beziehungen in einer Mustersprache: Concept 34 Für weitere Details zu den Lösungsmustern sei auf die Originale im Anhang A1.1 verwiesen. Stand der Technik Seite 55 Map Style und Sequential Concept Map Style. Er betont dabei die Wichtigkeit einer grafischen Repräsentation zur Beherrschung der zugrundeliegenden Komplexität durch die Anwender. Concept Map Style: Grundgedanke dieser Repräsentationsform für eine Mustersprache ist eine Art Karte. Es handelt sich folglich um eine grafische Repräsentation von Lösungsmustern und deren Beziehungen. Es werden unterschiedliche Beziehungsformen definiert und die Lösungsmuster so in Beziehung zueinander gesetzt.35 Sequential Concept Map Style: Diese Darstellungsart baut auf der zuvor geschilderten Concept Map Sytle auf. Neben Querverweisen wie “in Kombination verträglich” oder “in Kombination nicht verträglich” spielt der zeitliche Aspekt eine wesentliche Rolle. Für die Abbildung zeitlicher Zusammenhänge schlägt Simpson drei unterschiedliche Herangehensweisen vor, die individuell mit Lösungsmustern ausgestaltet werden müssen: „Top-Down“; „Center-Out“ oder sequentiell. Bewertung: Als Grundlage für die Mustersprache definiert SIMPSON fundamentale Lösungsmuster im Gesamtkontext System Engineering. Es sind in erster Linie Gliederungsansätze wie die Differenzierung von einem Problem- und einem Lösungssystem. Es handelt sich um sehr allgemeine Gedankengänge, die sehr abstrakt ohne konkrete Beispiele präsentiert werden. Gleiches gilt für die Überlegungen zu der Mustersprache für das Systems Engineering. SIMPSON orientiert sich zwar an gängigen Definitionen für eine Mustersprache, es mangelt jedoch an Beispielmustern und an einer detaillierten Spezifikation der Beziehungsformen. Es werden grafische Darstellungsarten für die Mustersprache vorgeschlagen, eine konkrete Ausprägung bleibt aber aus. 3.2 Lösungswissen für den Systementwurf Um zeit- und kostenintensive Änderungen entlang einer Produktentwicklung so gering wie möglich zu halten, ist eine fachdisziplinübergreifende Systemkonzipierung unerlässlich. Bei der Festlegung des Systemkonzepts im Rahmen des Systementwurfs sind Entwickler aller beteiligten Disziplinen zusammenzuführen. Die Problemanalyse hat gezeigt, dass neben ihrer fachspezifischen Expertise auch Generalisten erforderlich sind, die das Gesamtsystem und relevante Schnittstellen im Blick behalten. Neben einer einheitlichen Terminologie, die die Plattform für eine barrierefreie Kommunikation bildet, bedarf es gleichermaßen einer einheitlichen Aufbereitung und Strukturierung von Lösungswissen aus den unterschiedlichen Disziplinen. Vor diesem Hintergrund werden im Kapitel 3.2.1 Spezifikationstechniken für die Systemmodellierung und somit für die multidisziplinäre Wissensrepräsentation in den Lösungsmustern betrachtet. Kapitel 3.2.2 untersucht fachdisziplinübergreifende Lösungsmuster, die vorrangig an die Gene- 35 Es handelt sich im übertragenen Sinne um eine Art Mind-Map mit Lösungsmustern als Kernelement. Seite 56 Kapitel 3 ralisten adressiert sind. Diese müssen nahtlos mit den fachdisziplinspezifischen Ansätzen verbunden sein, die abschließend in Kapitel 3.2.3 analysiert werden. 3.2.1 Techniken für die Wissensrepräsentation Relevantes Expertenwissen für den Systementwurf, das in den Lösungsmustern abgebildet werden soll, bedarf geeigneter Techniken für die Spezifikation und Repräsentation, d.h. Sprachen zur Darstellung von Artefakten und zugehörigem Wissen. Die Problemanalyse hat ergeben, dass das Wissen nach Möglichkeit in der gleichen Notation bzw. Beschreibungssprache abgebildet werden muss, die zum jeweiligen Zeitpunkt in der Entwicklung genutzt wird. Aus diesem Grund werden in den folgenden Kapiteln 3.2.1.1 bis 3.2.1.3 sowohl die semiformale Spezifikationstechnik CONSENS, als auch formale Spezifikationstechniken wie UML und SysML vorgestellt. Zusätzlich werden in Kapitel 3.2.1.4 und 3.2.1.5 die Sprachen PrEMISE und Modelica® analysiert. 3.2.1.1 CONSENS Am Heinz Nixdorf Institut Paderborn wurde im Rahmen des SFB 614 die Spezifikationstechnik CONSENS (CONceptual design Specification technique for the ENgineering of complex Systems) zur Beschreibung der Prinziplösung fortgeschrittener mechatronischer Systeme entwickelt [GFD+08a], [GFD+08b], [DDG+14]. CONSENS umfasst eine Modellierungssprache und eine Vorgehensweise, die im Rahmen des Systementwurfs eingesetzt wird. Die Modellierungssprache gliedert sich in die Aspekte Umfeld, Anwendungsszenarien, Anforderungen, Funktionen, Wirkstruktur, Verhalten und Gestalt (vgl. Bild 3-5). Diese Aspekte werden im Rahmen der Entwicklung rechnerintern durch Partialmodelle repräsentiert und im Folgenden näher erläutert. An dieser Stelle sei hervorgehoben, dass wechselseitige Beziehungen zwischen den Partialmodellen eine zentrale Rolle einnehmen. Die partialmodellübergreifenden Beziehungen werden zwischen den Konstrukten der Partialmodelle (z.B. Funktion und Systemelement) gebildet. Die sieben ausgearbeiteten Partialmodelle bilden die Ausgangsbasis für die anschließende fachdisziplinspezifische Konkretisierung. Umfeld: Dieses Partialmodell beschreibt das Umfeld sowie dessen Interaktion mit dem zu entwickelnden System. Dabei werden Einflussbereiche wie übergeordnete Systeme oder Einflüsse wie Wärmestrahlung oder Windkraft aufgezeichnet. Zusätzlich findet eine Untersuchung möglicher Wechselwirkungen einzelner Einflüsse statt. In diesem Zusammenhang ist eine Situation eine konsistente Menge von gemeinsam auftretenden Einflüssen. Ferner sind Ausprägungen von Einflüssen, die eine Zustandsänderung hervorrufen, als Ereignis zu kennzeichnen. Anwendungsszenarien: Anwendungsszenarien enthalten für einen bestimmten Fall das zu lösende Problem und deren Lösung. Sie beschreiben dabei in welcher Art und Weise sich das System in einem Zustand oder einer bestimmten Situation verhalten soll. Zu- Stand der Technik Seite 57 sätzlich enthalten sie Angaben, durch welche Ereignisse Zustandsübergänge stattfinden sollen. Anforderungen: Sämtliche Anforderungen an das zu entwickelnde System werden in einer Anforderungsliste zusammengetragen. Diese bildet die Grundlage der späteren Entwicklung und ist fortlaufend zu pflegen. Die Anforderungen werden dabei verbal beschrieben und ggf. durch Attribute und deren Ausprägungen konkretisiert. Mögliche Hilfestellung beim Aufstellen einer Anforderungsliste liefern PAHL/BEITZ in Form von Checklisten36 [PBF+07]. Funktionen: Eine Funktion beschreibt den Zusammenhang zwischen einer Eingangs- und einer Ausgangsgröße. Sie verfolgt dabei das Ziel, eine spezifische Aufgabe zu erfüllen [PBF+07]. Im Rahmen der Entwicklung erfolgt die Darstellung der Funktionen hierarchisch. Die Unterteilung der übergeordneten Funktionen in Subfunktionen findet solange statt, bis sich für die Funktionen sinnvolle Lösungen finden lassen. Funktionen sind demnach die Grundlage für die Anwendung von Lösungsmustern. Bild 3-5: Partialmodelle der Spezifikationstechnik CONSENS [GTS14, S. 38] 36 Für eine detaillierte Beschreibung sei zusätzlich auf [Rot01] und [Ehr03] verwiesen. Anforderungen 1 2 1.1 2.1 1.2 2.2 1.3 2.3 1.4 Geometrie Energie elektrische Energie verwenden Spannungsversorgung: 400 V möglichst geringer Energieverbr. Abstand Toolcenterpoint: 1000 mm Breite: max. 3500 mm Tiefe: max. 1500 mm Höhe: max. 1200 mm Umfeld Roboter 2 Spielobjekt Umwelt Roboter 1 Benutzer Untergrund Energiequelle Anwendungsszenarien AW 5: Erfolgreiches Spielen Beschreibung der Situation Beschreibung des prinzipiellen Verhaltens Wirkstruktur Kraftsensor Schläger Delta- Kinematik Antriebe Leistungselektronik Benutzerschnittstelle Informationsverarbeitung Roboter 1 Bewegungsbahn kontrollieren Sollwerte abrufen Sensorwerte abrufen Antriebe regeln Funktionen Gestalt Verhalten Produktkonzeption (kohärentes System von Partialmodellen) Aktiv Initialisierung Spielen Master Spielen Slave Standby E1 E2 E3 E5 E7 Defekt E9 E8 E4 E6 Seite 64 Kapitel 3 Vor dem Hintergrund der durch die Lösungsmuster angestrebten Wiederverwendung von Lösungswissen sind die bereits veröffentlichten Modellbibliotheken zu berücksichtigen. Die Modelica Association stellt in Form der sogenannten Modelica Standard Library eine Open-Source Bibliothek zur Verfügung, die Modelle aus Disziplinen wie der Elektronik, der Thermodynamik oder der Mechanik beinhaltet [Mod10]. Bewertung: Modelica® ist eine Sprache zur Beschreibung physikalischer Systeme. Sie eignet sich in erster Linie zur Anwendung in den Disziplinen Maschinenbau, Elektrotechnik und Regelungstechnik sowie in ihrem Zusammenspiel. Durch Modellierung des Verhaltens mit mathematischen Gleichungen ermöglicht die Sprache eine Auslegung der physikalischen Eigenschaften sowie deren rechnerunterstützte Simulation. Die Spezifikation der Informationsverarbeitung war zunächst nicht Ziel der Entwicklungen, sie beschränkte sich auf die Regelungs- und Steuerungstechnik. Erste Bibliotheken liefern aber z.T. bereits wiederverwendbare Bausteine für die Spezifikation von Echtzeitkoordination auf System oder Subsystemebene [PDS+12]. Durch den hohen Formalitätsgrad der Sprache birgt die Anwendung im Systementwurf jedoch gewisse Gefahren wie z.B. die Fokussierung auf bestimmte Teilaspekte in einer sehr hohen Detaillierungstiefe. Auch im Hinblick auf die Anforderung beim Managen des Entwicklungsgeschehens zu unterstützen, ist die Darstellung des Systems durch mathematische Gleichungen nicht zielführend. 3.2.2 Fachdisziplinübergreifende Lösungsmuster Der Ursprung fachdisziplinübergreifender Lösungsmusteransätze liegt im Systems Engineering. Die Analyse zweier exemplarisch ausgewählter Ansätze zeigt Kapitel 3.2.2.1 mit den Systemarchitekturmustern nach CLOUTIER sowie Kapitel 3.2.2.2 mit den Lösungsmustern mit SysML nach WEILKINS. Einen Ansatz mit Schwerpunkt Entwicklungsmethodik Mechatronik behandelt Kapitel 3.2.2.3, mit den Lösungsmustern für selbstoptimierende Systeme nach DUMITRESCU. 3.2.2.1 Systemarchitekturmuster nach CLOUTIER CLOUTIER beruft sich in seiner Definition von einem Lösungsmuster auf die Definition von GAMMA ET AL. und folglich auf den Architekten ALEXANDER. Ein Lösungsmuster benennt, motiviert und beschreibt dabei ein grundsätzliches Lösungsprinzip für wiederkehrende Entwurfsprobleme. Anwendungsschwerpunkt der Systemarchitekturmuster ist der objektorientierte Systementwurf. Ein Muster enthält Angaben zur Implementierung, d.h. die Übertragung auf ähnliche Problemstellungen, und Anwendungsbeispiele. Die Lösung wird repräsentiert durch generalisierte Objekte und Klassen. Diese Art der Aufbereitung ist notwendig, um das Lösungsmuster auf weitere Probleme adaptieren zu können [Clo06]. Stand der Technik Seite 65 Als Einsatzzweck nennt CLOUTIER die Erstellung der Systemarchitektur. Gemeint ist die Kunst und Wissenschaft komplexe technische Systeme sowie deren Entstehungsprozesse zu strukturieren und zu beherrschen. Aufgrund der steigenden Komplexität der Systeme kann dies nicht durch einen einzelnen Systemarchitekten erfolgen. Es ist vielmehr ein Team von Systemarchitekten notwendig, die sich mit ihrer spezifischen Expertise komplementär ergänzen, um den gesamten Entstehungsprozess gemeinsam zu managen. In diesem Zusammenhang sieht CLOUTIER Lösungsmuster als ein wesentliches Werkzeug zur Förderung der Kommunikation. Voraussetzung ist die in Bild 3-11 abgebildete einheitliche Strukturierung von Mustern (Ein Beispielmuster befindet sich im Anhang A1.2). Einheitliche Strukturierung der Lösungsmuster für das Systems Engineering Bild 3-11: Einheitliche Strukturierung von Systemarchitekturmustern nach CLOUTIER [vgl. Clo06, S. 42] Kategorie Erklärung zu den Kategorien Name Der Name soll dem Anwender den Nutzen des Musters prägnant vermitteln Aliasnamen Weitere Namen, durch die das Muster identifiziert werden kann Schlüsselwörter Schlüsselwörter , die die Lokalisierung des Lösungsmusters in einer Datenbank verbessern Problem - Kontext Eine prägnante Beschreibung des Problemumfeldes: Hierzu sind Anwendungsszenarien über Situationen zu spezifizieren, die das Problem charakterisieren Problem - beschreibung Was ist das Problem, für das dieses Lösungsmuster genutzt werden kann ? Heraus - forderungen Mögliche Probleme und/oder Einschränkungen, die bei der Implementierung bzw. Anwendung von dem Lösungsmuster auftreten können Lösung Eine Beschreibung über den Kern der Lösung bzw. das Lösungsprinzip Diagramme Ein oder mehrere Diagramme bzw. Modelle, die das Lösungsmuster repräsentieren Schnittstellen Beschreibung der Schnittstellen im Hinblick auf Veränderbarkeit von Parametern (z.B. Informations, Stoff- oder Energiefluss) Resultierender Kontext Erläuterung zum Kontext, in dem das Lösungsmuster eingesetzt werden kann Beispiel(e ) Ein oder mehrere Beispiele, in denen das Lösungsmuster eingesetzt wurde Funktions - nachweis Begründung über den erfolgreichen Einsatz des Lösungsmusters Übertragungs - möglichkeiten Hinweise zur Übertragbarkeit des Lösungsmusters auf weitere Problemstellungen Verwandte Muster Lösungsmuster , mit denen eine Kombination möglich ist oder ausgeschlossen werden kann Referenzen Weitere Informationen oder Literatur, die das Verständnis des Lösungsmusters fördern Autoren Wer hat das Lösungmuster dokumentiert? Seite 66 Kapitel 3 Die Aufgabenfelder und Fähigkeiten der Systemarchitekten sind dabei sehr vielseitig. Neben der Modellierung eines fachdisziplinübergreifenden Systemmodells stehen vor allem kommunikative Fähigkeiten im Vordergrund. Ein Systemarchitekt als Vermittler verantwortet die Abstimmung zwischen den Fachdisziplinen entlang des Entstehungsprozesses. Es gilt eine gemeinsame Plattform zu schaffen, über die sich alle am Produktentstehungsprozess beteiligten Akteure gleichermaßen austauschen können. Kernelement sind Systemarchitekturmuster, die die Verständlichkeit über die Fachdisziplinen hinweg sicherstellen, indem sie die spezifischen Lösungsansätze miteinander verbinden bzw. vereinen. Als wesentliches Alleinstellungsmerkmal der Systemarchitekturmuster beschreibt CLOUTIER die Dokumentation von Schnittstellen. Schnittstellen zu weiteren Architekturmustern, aber auch Schnittstellen zu fachdisziplinspezifischen Lösungsmustern. Hinzu kommen die Aggregation von Lösungsmustern und die Dokumentation der daraus resultierenden Beziehungen untereinander. Bewertung: CLOUTIER beschäftigt sich mit Lösungsmustern für die Systemarchitekturerstellung. Dies umfasst die Modellierung eines fachdisziplinübergreifenden Systemmodells sowie dessen fortlaufende Pflege über den Entstehungsprozess. CLOUTIER sieht den Nutzen im Lösungsmusteransatz in der Förderung der Kommunikation zwischen den Fachdisziplinen. Im Hinblick auf eine gemeinsame Plattform zum Austausch über Problem- und Lösungsprinzipien präsentiert er eine einheitliche Strukturierung von Systemarchitekturmustern. Diese sehr umfangreiche Art der Informationsdokumentation umfasst neben generalisierten Modellen auch Zusatzinformationen für den Anwender wie z.B. Nutzungs- und Implementierungshinweise. Ein wesentlicher Nachteil dieser Art der Repräsentation ist die Informationsflut und intransparente Darstellung lösungsmusterübergreifender Beziehungen. Gemeint sind Schnittstellen und wechselseitige Abhängigkeiten zu weiteren Lösungsmustern anderer Fachdisziplinen als auch Aggregationsbeziehungen. 3.2.2.2 Lösungsmuster mit SysML nach WEILKINS Nach WEILKINS ist ein Lösungsmuster ein Hilfsmittel, um erfolgreich eingesetztes Lösungswissen langfristig zu speichern und explizit darzustellen. Wie die Vielzahl der in der Literatur veröffentlichten Definitionen bezieht sich auch WEILKINS auf den Architekturtheoretiker ALEXANDER. Jeder Entwickler, besonders wenn er langjährige Berufserfahrung hat, verfügt über ein umfangreiches Repertoire an Lösungsmustern. Er setzt es tagtäglich bei der Bewältigung von Problemstellungen ein. Um ein Lösungsmuster zu definieren, ist es erforderlich, die erarbeitete Lösung generalisiert zu beschreiben und somit ihre Wiederverwendbarkeit und Übertragbarkeit zu ermöglichen [Wei14-ol]. Im Gegensatz zu zahlreichen Ansätzen für Entwurfsmuster fokussiert WEILKINS mit seinen Arbeiten die grafische Anordnung von Elementen. Er beschreibt die grafische Repräsentation des zu entwickelnden Systems bzw. seiner Subsysteme als Muster. Stand der Technik Seite 67 WEILKINS nutzt dabei die Spezifikationstechnik SysML für die Systemmodellierung. Im Hinblick auf die Verständlichkeit spielt dabei die Art und Weise der Anordnung eine entscheidende Rolle. Nach WEILKINS trägt das Layout der Diagramme wesentlich zur Effizienzsteigerung in der Systemmodellierung bei [Wei14-ol]. Bild 3-12 verdeutlicht drei identifizierte Layoutmuster von WEILKINS. Bild 3-12: Muster „bottom-up“, „top-down“ und „non-tree-style“ nach WEILKINS [vgl. Wei14-ol] Das Anwendungsbeispiel besteht aus einer „komplexen Sensoreinheit zur Identifizierung von Waldbränden“, die mit SysML abgebildet ist. Es sind unterschiedliche Abbildungsformen eines Produktbaumes dargestellt. Hierbei wird ein Gesamtsystem in seine Teilsysteme zerlegt und mit logischen Beziehungen verbunden. WEILKINS unterscheidet zwischen „bottom-up“, „top-down“ und „non-tree-style“. Bewertung: Der Ansatz nach WEILKINS verdeutlicht, wie facettenreich der Lösungsmusterbegriff im Kontext Systems Engineering interpretiert wird. Im Gegensatz zu der Vielzahl der Ansätze handelt es sich um Layoutmuster, die Hinweise zur Anordnung von Modellen geben. In Anlehnung an die Unterteilung nach GRABOWSKI (Kapitel 3.1.1) handelt es sich hierbei um eine Art Prozessmuster. Sie unterstützen die Entwickler nicht bei der Frage, was eine mögliche Lösung für das Entwurfsproblem (fachdisziplinübergreifend) ist. Es sind vielmehr sehr generische und abstrakte Hinweise, die sprachenübergreifend die Abbildung von Systemen mit Hilfe von Modellen betrifft. «block» Kontrolleinheit Drone «block» Drone «block» Drone Anknüpfung «block» Subsystem: Drone «block» Zentrale Kontrolleinheit «block» lokaler Sensor ecosystem «block» Sensor Kontrolleinheit «block» Thermosensor «block» Kamera «block» Rauchsensor «system» Sensoreinheit zur Detektion von Waldbrand «block» Kontrolleinheit Drone «block» Drone «block» Drone Anknüpfung «block» Subsystem: Drone «block» Zentrale Kontrolleinheit «block» lokaler Sensor ecosystem «block» Sensor Kontrolleinheit «block» Thermosensor «block» Kamera «block» Rauchsensor «system» Sensoreinheit zur Detektion von Waldbrand «system» Sensoreinheit zur Detektion von Waldbrand «block» Zentrale Kontrolleinheit «block» Drone «block» Subsystem: Drone «block» Kontrolleinheit Drone «block» Drone Anknüpfung «block» lokaler Sensor ecosystem «block» Thermosensor «block» Kamera «block» Rauchsensor «block» Sensor Kontrolleinheit bottom-up top-down non-tree Seite 68 Kapitel 3 3.2.2.3 Lösungsmuster für selbstoptimierende Systeme nach DUMITRESCU DUMITRESCU schlägt Lösungsmuster für die Wissensexternalisierung und Wiederverwendung zur Integration kognitiver Funktionen in mechatronische Systeme vor. Die erarbeitete Spezifikation der Lösungsmuster eignet sich sowohl zur Aufnahme von Lösungen mit physikalischem als auch informationstechnischem Schwerpunkt. Hauptaugenmerk liegt jedoch auf letztgenannten Lösungsansätzen, vorrangig aus den Bereichen der künstlichen Intelligenz und der höheren Mathematik. Bild 3-13 gibt einen Überblick über die einheitliche Spezifikation eines Lösungsmusters für Selbstoptimierung nach DUMITRESCU. Die Lösungsmuster werden in sechs Aspekte gegliedert, die nachfolgend erläutert werden. Die Wissensinhalte werden mit Hilfe der Spezifikationstechnik CONSENS dargestellt [Dum10, S. 129ff.]. Bild 3-13: Einheitliche Spezifikation eines Lösungsmusters nach DUMITRESCU [Dum10, S. 130] Merkmale Als „Merkmale“ werden charakteristische Eigenschaften des Lösungsmusters festgehalten, die u.a. zum Abgleich mit den Anforderungen in einer Neuentwicklung genutzt werden können. Es wird zwischen Merkmalen für die Informationsverarbeitung und Merkmalen für das (physikalische) Grundsystem eines mechatronischen Systems unterschieden. DUMITRESCU schlägt nachfolgende Liste an Eigenschaften für das Grundsystem vor: Einsatzbedingungen, Geometrie, Stoffliche Merkmale, Kinematik, Montage, Normung. Es wird betont, dass diese Liste keinen Anspruch auf Vollständigkeit besitzt. Vielmehr ist diese Liste fortwährend zu erweitern, sobald die Lösungsmuster als Wissensmanagementansatz im Unternehmen implementiert sind. Zu den charakteristischen Merkmalen für Lösungen der Informationsverarbeitung zählt DUMITRESCU: Einsatzbe- Verhalten Spezifikation durch Aktivitäten und Zustände Wirkstruktur Beteiligte Systemelemente und ihr Zusammenwirken Lösungsmuster (LM) Funktionen Funktionshierarchie, die durch das LM erfüllt wird Lösungsprinzipien Relevante Verfahren oder LM für die Umsetzung OCM Aktor Sensor Grundsystem Merkmale Charakteristische Merkmale des Lösungsmusters Einsatzbedingungen … Geometrie … Stoffliche Merkmale … Echtzeitfähigkeit ... Art der Berechnung ... Kontext Beispiele, in denen das LM eingesetzt worden ist Z1 Z2 Z3 E2 E1 µ H F G N R H Verfahren Physik. Effekt Gesamtfunktion 1. Teilfunktion 2. Teilfunktion K Stand der Technik Seite 69 dingungen; Zeitpunkt der Aktivität, Echtzeitfähigkeit; Modellierbarkeit, Art der Berechnung, Entität, Signalart, Modellierungs-/Programmiersprache, Datenstruktur.41 Funktionen Dieser Aspekt beschreibt die Aufgabe eines Lösungsmusters in Form von „Funktionen“. Im einfachsten Fall ist dies genau eine Funktion. Analog z.B. zur Aggregation von Bauteilen zu einer Baugruppe können komplexere Lösungen mehrere Funktionen umfassen. Die Funktionen und die entsprechenden Zusammenhänge werden in einer Funktionshierarchie dargestellt. DUMITRESCU unterscheidet, in Anlehnung an die drei prinzipiellen Flussarten mechatronischer Systeme zwischen stoffbestimmten (z.B. Stoff transportieren), energiebestimmten (z.B. Energie umwandeln) und informationsbestimmten Funktionen (z.B. Informationen erfassen). Aufbauend auf dem zuvor erläuterten Aspekt Merkmale, komplettiert der Aspekt Funktionen die Problembeschreibung eines Lösungsmusters. DUMITRESCU konzentriert sich hierbei auf kognitive Funktionen wie z.B. „planen“ oder „lernen“. Wirkstruktur In Anlehnung an ALEXANDER umfasst jedes Lösungsmuster neben einer Problemauch eine Lösungsbeschreibung. In der Spezifikation von DUMITRESCU bildet die „Wirkstruktur“ den Kern der Lösungsbeschreibung. Es werden Systemelemente dargestellt, die in ihrem Zusammenwirken die definierten Funktionen erfüllen42. Verhalten Der Aspekt „Verhalten“ komplettiert die Lösungsbeschreibung eines Musters. DUMITRESCU betont die Relevanz dieses Aspekts vor allem in Bezug auf Lösungswissen für die Selbstoptimierung. Er unterteilt diesen Aspekt in die beiden Bereiche Verhalten – Aktivitäten und Verhalten – Zustände. • Das Partialmodell Verhalten – Aktivitäten stellt Ablaufdiagramme dar. Diese repräsentieren in welcher Reihenfolge ein Systemelement seine Funktionen ausführt. Insbesondere bei kognitiven Prozessen sollte, unter Berücksichtigung des Selbstoptimierungsprozesses, Bezug auf die Hauptaktivitäten Situationsanalyse, Zielbestimmung und Verhaltensanpassung genommen werden43. 41 Für eine detaillierte Erläuterung sei auf [Dum10, S. 131f.] verwiesen. 42 Für weitere Informationen bzgl. einer Wirkstruktur sei auf Kapitel 3.2.1.1 verwiesen. 43 Die Situationsanalyse umfasst neben der Aufzeichnung relevanter Zustandsgrößen des Systems auch die Wahrnehmung äußerer Einflüsse. Eine Voraussetzung für einen Lerneffekt ist das Speichern sämtlicher Systemzustände, um einen Abruf zurückliegender Aufzeichnungen zu ermöglichen. Ziel der Zielbestimmung ist die Definition neuer z.T. konfliktär zueinander stehenden Systemziele (z.B. bei einer Bahn: max. Leistung, min. Verbrauch). Als Entscheidungsgrundlage dienen die zuvor gewonnenen Informationen. Unterschieden wird zwischen der Auswahl, Anpassung und Generierung von Zielen. Im Rahmen der Verhaltensanpassung werden Veränderungen bzw. Neueinstellung der Systemparameter vorgenommen [ADG+09, S. 6ff.] Seite 70 Kapitel 3 • Neben Aktivitäten eignen sich vor allem Zustandsdiagramme, um informationstechnische Abläufe darzustellen. Ferner können mit diesen Diagrammen auch sich ändernde Zustände von passiven Elementen abgebildet werden. DUMITRESCU hebt die Interdisziplinarität dieser Diagramme hervor, da die Dokumentation von Zuständen und Zustandsübergängen für jedes Lösungsmuster aller beteiligten Fachdisziplinen relevant sein kann. Lösungsprinzipien Jedes Lösungsmuster beruht auf mindestens einem „Lösungsprinzip“ bzw. einem Verfahren. Diese sind die Grundlage für die Implementieren eines Lösungsmusters im Rahmen der Produktentwicklung. Verfahren umfassen nach DUMITRESCU44 die Abfolge von physikalisch-technischen, chemischen, biologischen oder informationstechnischen Wirkungsabläufen, die zur Realisierung einer gewünschten Funktion notwendig sind. Ein Verfahren konkretisiert eine Funktion. Bei der Definition von Lösungsmustern für die Selbstoptimierung werden zwei Verfahrensarten unterschieden: Physikalische Effekte und informationsverarbeitende Verfahren. Kontext Die Lösungsmusterspezifikation wird komplettiert durch den „Kontext“. Dieser beschreibt, in welchen zurückliegenden Projekten das betrachtete Lösungsmuster erfolgreich eingesetzt wurde. Somit muss jede vollständige Spezifikation eines Lösungsmusters mindestens ein Beispiel beinhalten. Die Kontextbeschreibung setzt sich zusammen aus einer Bezeichnung, einer kurzen Beschreibung in Textform sowie einer aussagekräftigen Skizze. Im Idealfall liegt die Einbettung des Lösungsmusters in das Gesamtsystem in den von DUMITRESCU gewählten Partialmodellen vor: Funktionen, Wirkstruktur und Verhalten. Ferner spielen die Querverweise eine wichtige Rolle. Sie geben den Entwicklern wichtige Hinweise für die Anwendung des Lösungsmusters in einer Neuentwicklung. Bewertung: DUMITRESCU präsentiert eine einheitliche Spezifikation von Lösungsmustern, mit deren Hilfe kognitive Funktionen in mechatronische Systeme integriert werden können. Es werden unterschiedliche Kategorien definiert. Das Hinterlegen von notwendigen Informationen erfolgt vorrangig modellbasiert durch Nutzung der Spezifikationstechnik CONSENS. Die Strukturierung ist gut geeignet, um multidisziplinäre Lösungsansätze darzustellen. Die Navigation über den Aspekt Kontext und eine ergänzende Erklärung im Aspekt Lösungsprinzipien ist für einen kleinen Anwendungsbereich wie z.B. künstliche Intelligenz ausreichend. In einer umfangreichen Übertragung auf alle am Systementwurf beteiligten Fachdisziplinen, wie sie im Rahmen der vorliegenden Arbeit angestrebt wird, ist mit einem deutlichen Komplexitätsanstieg in den wechselseitigen Abhängigkeiten zu rechnen. In diesem Zusammenhang ist es notwendig, die Strukturie- 44 Die Definition von DUMITRESCU beruht auf den Arbeiten von SAUER. Für weitere Informationen sei an dieser Stelle auf [Sau06, S. 74f.] verwiesen. Stand der Technik Seite 71 rung zu vereinfachen und Darstellungsformen zu erarbeiten, die die Beziehungen untereinander und zu den Fachdisziplinen transparent abbilden. 3.2.3 Fachdisziplinspezifische Lösungsmuster Für die Wiederverwendung von Lösungsprinzipien existieren zahlreiche fachdisziplinspezifische Ansätze. Aus diesem Grund untersucht Kapitel 3.2.3.1 mit den Lösungsmustern nach SUHM sowie Kapitel 3.2.3.2 mit den Entwurfsmustern nach SALUSTRI Ansätze für den klassischen Maschinenbau. Ein Ansatz zur Spezifikation von Koordinationsmustern der Softwaretechnik wird in Kapitel 3.2.3.3 beschrieben. Den Abschluss bildet die Analyse von Ansätzen aus der Regelungstechnik. Hierzu werden in Kapitel 3.2.3.4 und 3.2.3.5 die Arbeiten von FÖLLINGER und SANZ/ZALEWSKI untersucht. 3.2.3.1 Lösungsmuster im Maschinenbau nach SUHM Lösungsmuster für den klassischen Maschinenbau, die über die etablierten Wirkprinzipien45 oder Lösungsprinzipien aus der VDI-Richtlinie 2727 hinausgehen, liefert SUHM [VDI2727]. Die Muster repräsentieren Expertise, z.B. über Gestaltungsrichtlinien oder den Einsatz typischer Lösungselemente (z.B. Radiallager). Der Aufbau eines Lösungsmusters ist in Bild 3-14 beispielhaft dargestellt. SUHM unterteilt ein Lösungsmuster in die Kategorien Voraussetzungen, Lösung sowie Umgebung [Suh93, S. 78ff.]. Bild 3-14: Steckbrief eines Lösungsmusters [Suh93, S. 79] • Voraussetzungen: Diese Kategorie enthält Angaben aus vorangegangenen Konstruktionsphasen, die als Voraussetzungen für das vorliegende Muster gelten. 45 Vgl. Kapitel 2.4.4 Lösungsmuster Radiallager Radiallagerung DIN 615, DIN 617,... Bezeichnung Quelle Symbol (Kraft) leiten Radialkraft, Axialkraft wartungsfrei wälzen 0,3 … 5000 kN < 10000 min -1 Welle Lagerblock, Gehäuse keine, Sprengring, Mutter Funktionsgröße Wartung Relativbewegung Tragzahl Drehzahl sitzt auf sitzt in Sicherung innen Funktionsoperation Voraussetzungen Lösung Umgebung Seite 72 Kapitel 3 • Lösung: Es wird eine Lösungsbeschreibung in parametrisierter Form angegeben. • Umgebung: Beschreibung der Lösungsumgebung innerhalb der gleichen Konstruktionsphase, die bereits vorhanden ist oder noch ausgearbeitet werden muss. SUHM betont in seiner Arbeit die Notwendigkeit, komplexe Problemstellungen und somit auch die zugehörigen Lösungen bzw. Lösungsmuster einem Strukturierungsmodell unterzuordnen. Dazu definiert er drei generische Hierarchietypen, entlang derer ein spezifisches Lösungsmuster für den Maschinenbau charakterisiert werden kann (Bild 3-15) [Suh93, S 80ff.]. Bild 3-15: Strukturierung der Lösungsmuster [Sch06, S. 41] in Anlehnung an [Suh93, S. 80ff.]] • Konkretisierungshierarchie: Diese Ebene beschreibt den Einsatz der Muster in unterschiedlichen Entwurfsphasen. Grundgedanke ist, bei zunehmender Konkretisierung zunächst mit abstrakten Lösungsmustern zu arbeiten und diese später zu verfeinern und zu detaillieren. Diese Herangehensweise und Hierarchieebene soll dem Arbeiten in unterschiedlich abstrakten Konstruktionsphasen gerecht werden. • Spezialisierungshierarchie: Diese Hierarchie steht für die Konkretisierung eines Musters in einer speziellen Entwurfsphase. So wird bei der Lösung einer bestimmten Problemstellung mit einem sehr allgemeinen Lösungsmuster begonnen. Unter Berücksichtigung weiterer Merkmale, die anschließend festgelegt Getriebe Welle Lager Einschränkung Lösungsmuster 2 Lösungsmuster 1 Relation komplex elementar Anforderung Funktion Prinzip abstrakt konkret Gestalt allgemein speziell mech. Getriebe Riemengetriebe Muster in unterschiedlichen Entwurfsphasen Konkretisierung von Mustern Detaillierung in einer Entwurfsphase Spezialisierung von Mustern Komplexitätsreduktion durch Zerlegung Dekomposition von Mustern Stand der Technik Seite 73 werden, wird die Lösung entlang einer Spezialisierungshierarchie sukzessive verfeinert. • Dekompositionshierarchie: Diese Ebene bildet die Zerlegung eines komplexen Musters in elementare Muster ab. Die Dekompositionshierarchie soll es ermöglichen, die Komplexität des anstehenden Problems zu zerlegen und somit beherrschbar zu machen. Analog zum Komplexitätsgrad des Problems soll der Lösungsraum mit den entsprechend komplexen und elementaren Lösungsmustern eingeschränkt werden. Im Rahmen der vorliegenden Arbeit stellt insbesondere die Komplexitätsreduktion durch die Unterteilung in elementare und komplexe Lösungsmuster einen bedeutenden Ansatz dar. Nach SUHM lassen sich komplexe Lösungsmuster grundsätzlich in elementare Lösungsmuster zergliedern. Aufgrund der damit einhergehenden hohen Granularität, lässt sich jede Konstruktionsaufgabe durch Kombination von elementaren Lösungsmustern lösen. Der Zusammenhang zwischen komplexen und elementaren Lösungsmustern nach SUHM ist anhand eines Lagersitzes auf einer Welle in Bild 3-16 dargestellt. Bild 3-16: Zusammenhang zwischen komplexen und elementaren Lösungsmustern [Suh93, S. 81] Bewertung: Die Lösungsmuster nach SUHM konzentrieren sich auf die Beschreibung rein maschinenbaulicher Problemstellungen. Die Darstellung von Wissensinhalten erfolgt textuell in tabellarischer Form. Dies ermöglicht zwar eine grundsätzliche Übertragung auf weitere Disziplinen, stellt aber einen bedeutenden Mehraufwand bei der Erstellung der Lösungsmuster dar. Vorteilhafter wäre die Darstellung durch die in der Entwicklung verwendeten Modelle oder Beschreibungssprachen. Positiv hervorzuheben sind die Überlegungen zu den unterschiedlichen Dimensionen, mit denen sich Lösungsmuster charakterisieren und voneinander abgrenzen lassen. Der dadurch entstehende Lösungsraum beschränkt sich jedoch, wie alle Überlegungen von SUHM, auf den klassischen Maschinenbau. Folglich sind im Rahmen der vorliegenden Arbeit einige positive Aspekte aufzugreifen und entsprechend der Interdisziplinarität des Systementwurfs zu erweitern. komplexe Lösungsmuster Lösungsmuster Abdichtung Lösungsmuster Wellenabschnitt- Lagersitz Lösungsmuster Lagerung elementare Lösungsmuster Lösungsmuster Dichtfläche Lösungsmuster Sitz Lösungsmuster Dichtring Lösungsmuster Rotationsteil Seite 80 Kapitel 3 Bild 3-20: Lösungsmuster „Feedback“ nach SANZ/ZALEWSKI [SZ03] Bewertung: SANZ/ZALEWSKI bilden in der Regelungstechnik eine Ausnahme, indem sie typische Problemstellungen der Regelungstechnik und zugehörige Lösungsansätze als Lösungsmuster titulieren und entsprechen dokumentieren. Die aufgezeigten Beispiele sind dabei größtenteils deckungsgleich mit den Arbeiten von FÖLLINGER. Bei der zu erarbeitenden einheitlichen Strukturierung müssen die gezeigten Ansätze der Regelungstechnik entsprechend berücksichtigt werden. Hinzu kommen Anforderungen von SANZ/ZALEWSKI an die Art der Wissensrepräsentation und die Besonderheiten bei dem Versuch, eine Lösungsmusterklassifikation zu erstellen. Die im Rahmen der vorliegenden Arbeit angestrebte multidimensionale Skalierung muss den Übergang von der natürlichen Sprache hin zu formalen Modellen sowie dem kontinuierlich ansteigenden Detaillierungsgrad gerecht werden. 3.3 Systematiken für den Einsatz von Lösungsmustern Ein lösungsmusterbasierter Systementwurf erfordert eine geeignete Systematik. Die Problemanalyse hat gezeigt, dass die Systematik zwei Handlungsfelder abdecken muss. Zum einen bedarf es einer methodischen Unterstützung wie auf Basis bestehender Systeme bzw. Teilsysteme relevantes Lösungswissen identifiziert und in Lösungsmuster überführt werden kann50. Zum anderen ist ein Entwicklungsleitfaden notwendig, der die 50 Der Fokus im Rahmen dieser Arbeit liegt bei der Identifizierung von Lösungsmustern auf dem methodischen Vorgehen. Er ist daher von rechnerunterstützten Ansätzen aus der Softwaretechnik, die unter den Begriffen Data Mining oder Pattern Mining bekannt sind, zu differenzieren [HK01]. Name: Feedback Aliasnamen: Closed-loop control, Feedback control, Output feedback Problem: Das System verhält sich nicht wie gewünscht. Die Reaktionsantwort ist z.B.: zu langsam, zu instabil, zu nichtlinear oder zu oszillierend. Ziel: Das Verhalten eines Systems (Output) folgt einer vorgegebenen Referenz (Set Point). Kontext: Das System hat einen sensierbaren Output und einen variablen Input. Es ist ein Referenzsignal vorhanden. Herausforderungen: a) Das Verhalten der Strecke wird durch Störungen beeinflusst. B) Genaue Kenntnisse über die Strecke sind nicht immer in der erforderlichen Detaillierung vorhanden. Lösung: Der Eingangswert der Strecke wird determiniert durch den Controller. Der Eingangswert für den Controller ergibt sich aus der Differenz zwischen der Führungsgröße und der Rückführungsgröße. Diagramm: Begründung: Die unmodellierte Dynamik der Strecke und die Störgrößen machen eine perfekte open-loop Regelung unmöglich. Die Sensierung des tatsächlichen Verhaltens ist unerlässlich. Varianten: PI-Regler; PID-Regler; PD-Regler Bekannte Anwendungen: ….. Verwandte Muster: Feedforward Real-Time Computer (Controller) Plant (Controller) Störgröße Geregelte Variablen Rückführungsgröße Regelgröße Führungs größe Stand der Technik Seite 81 Nutzung der im Rahmen dieser Arbeit zu entwickelnden Lösungsmuster allgemeinverständlich widerspiegelt. Aus diesen Gründen beschäftigt sich Kapitel 3.3.1 mit einer Methode zur Identifizierung von Systemarchitekturmustern. Kapitel 3.3.2 und 3.3.3 untersuchen Vorgehen für einen lösungsmusterbasierten Systementwurf. 3.3.1 Identifizierung von Systemarchitekturmustern nach KALAWSKY KALAWSKY beschäftigt sich in seinen Arbeiten mit Systemarchitekturmustern. Er untersucht einerseits die Erstellung von Systemarchitekturen mit Hilfe von Lösungsmustern und andererseits die Identifizierung von Systemarchitekturmustern auf Basis bestehender Systeme. Bild 3-21 präsentiert ein von KALAWSKY erarbeitetes Vorgehensmodell zur Definition von Systemarchitekturmustern. Es ist die komprimierte Abbildung eines hochgradig iterativen Prozesses. Dieser ist geprägt durch die Kommunikation und Kooperation des Systemarchitekten mit den Experten der in der Systementwicklung involvierten Fachdisziplinen. Dem Systemarchitekten wird eine Schlüsselrolle bescheinigt, denn er ist für die fachdisziplinübergreifenden Zusammenhänge zwischen den Teilsystemen verantwortlich [KJT+13]. Bild 3-21: Vorgehensmodell zur Identifizierung von Systemarchitekturmustern nach KALAWSKY [KJT+13, S. 289] Der erste Schritt im Vorgehensmodell zur Identifizierung von Systemarchitekturmustern ist die Festlegung des Betrachtungsgegenstandes. Es bildet die Grundlage aller folgenden Tätigkeiten. Anschließend gilt es zu untersuchen, ob für den Betrachtungsgegenstand (z.B. Gesamtsystem, oder nur bestimmte Teilsysteme) eine modellbasierte Spezifikation vorliegt. Hinweise auf die Verwendung einer bestimmten Spezifikationstechnik werden nicht gegeben. Das weitere Vorgehen wird hinsichtlich zweier unterschiedlicher Ausgangssituationen bestimmt: Liegt eine Spezifikation vor, so kann direkt mit der Analyse begonnen werden; liegt keine Spezifikation vor, so ist die Architektur entsprechend zu modellieren und anschließend mit Experten zu diskutieren [KJT13]. Darauf aufbauend folgt die Extraktion von sog. Lösungsmusterkandidaten. Diese geben erste Anhaltspunkte für ein potentielles Lösungsmuster. Es handelt sich um eine detaillierte Lösung, die noch nicht auf den Problem- und Lösungskern abstrahiert ist. Um Dopplungen zu vermeiden, wird daher zunächst ein Abgleich mit existierenden Lösungsmustern vorgenommen. Handelt es sich um ein neuartiges Lösungsmuster, so wird Modellierung der Architektur Review durch Experten Lösungsmuster spezifizieren Review durch Experten LM in Datenbank speichern Kandidaten mit bestehenden LM abgleichen Extraktion von LM- kandidaten Analyse der Architektur Architektur ist noch nicht dokumentiert Betrachtungsgegenstand festlegen Architektur ist bereits dokumentiert Überarbeitung erforderlich Seite 82 Kapitel 3 dieses durch den Systemarchitekten entsprechend spezifiziert. Da an einem Systemarchitekturmuster unterschiedliche Fachdisziplinen beteiligt seinen können, ist ein Review des erarbeiteten Lösungsmusters mit den Experten unumgänglich. Die Folge können mehrere Iterationen sein, bis alle erforderlichen Informationen im Lösungsmuster spezifiziert sind. Den Abschluss bildet die langfristige Sicherung des erstellten Lösungsmusters in einer Datenbank [KJT13]. Bewertung: Das Vorgehensmodell zur Identifizierung von Systemarchitekturmustern ist sehr generisch. Es beschreibt die durchzuführenden Tätigkeiten und die Vorgehensweise des Systemarchitekten, der aufgrund seines fachdisziplinübergreifenden Know- Hows die Schlüsselperson ist. Dem Ansatz von KALAWSKY mangelt es jedoch an nachvollziehbaren Beispielen in Bezug auf das Handlungsfeld komplexer technischer Systeme. Dies betrifft sowohl die zu verwendende Spezifikationstechnik, eine Lösungsmusterstruktur als auch die Systemarchitekturmuster. Es wird nicht ersichtlich, wie der iterative Prozess von einer Systemspezifikation über Lösungsmusterkandidaten hin zu Lösungsmustern durchzuführen ist. Das Vorgehensmodell liefert lediglich einen groben Rahmen. 3.3.2 Musterbasierter Entwurf mechatronischer Systeme nach GAUSEMEIER ET AL. Eine generische Vorgehensweise für den lösungsmusterbasierten Entwurf mechatronischer Systeme liefern GAUSEMEIER ET AL. Dabei wird zwischen Lösungsmustern und Lösungselementen unterschieden. GAUSEMEIER unterteilt Lösungsmuster je nach Disziplin in Wirkprinzipien und Wirkmuster51 [ADG+09, S. 173ff.]. Diese werden mit zunehmender Konkretisierung durch Lösungselemente, also Katalog- oder Normteile, ersetzt. Für einen effizienten Zugriff und eine langfristige Sicherung der Lösungsmuster sowie -elemente wird ein Semantic Web erarbeitet. Bild 3-22 zeigt schematisch den Entwurf mechatronischer Systeme unter Zuhilfenahme von Lösungswissen aus dem Semantic Web [GAC+13]. Der fachdisziplinübergreifende Entwurf mechatronischer Systeme beginnt mit der Zielbestimmung. Im Rahmen der Aufgabenanalyse wird die Aufgabenstellung abstrahiert, um den Kern der Entwicklungsaufgabe zu identifizieren. Anschließend wird eine Umfeldanalyse durchgeführt, in der die Randbedingungen und Einflüsse auf das System ermittelt werden. Die gesammelten Erkenntnisse werden nach der Definition aller möglichen Anwendungsszenarien in einer Anforderungsliste festgehalten. Diese ist Basis für die Definition der erforderlichen Funktionalität des Gesamtsystems in Form einer Funktionshierarchie [GAC+13]. 51 Einige ausgewählte Beispiele befinden sich im Anhang A1.3. Stand der Technik Seite 83 Bild 3-22: Systematik für die Nutzung von Lösungsmustern und -elementen in der Entwicklung mechatronischer Systeme [GAC+13] Auf Grundlage der Zielbestimmung erfolgt die Auswahl von Lösungsmustern. Eingangsinformationen sind die spezifizierten Funktionen und Anforderungen. Die anschließende Auswahl und Kombination potentieller Lösungsmuster erfordert kreatives Denken und Know-how der beteiligten Ingenieure. Auf Basis der ausgewählten Lösungsmuster werden die Wirkstruktur, Verhaltensmodelle und eine erste Grobgestalt entwickelt. Dies geschieht unter Zuhilfenahme der in den Lösungsmustern bereitgestellten Informationen. Diese werden genutzt und je nach zugrundeliegendem Entwurfsproblem individuell konkretisiert. Erfüllen die gefundenen Lösungsmuster nicht alle im Rahmen der Zielbestimmung spezifizierten Funktionen, so müssen zusätzliche Lösungskonzepte erarbeitet werden. Je nach Größe des Gesamtsystems wird dieses bereits während des Systementwurfs in Module unterteilt. Die einzelnen Module werden daraufhin verfeinert und anschließend wieder zusammengeführt. Das Ergebnis ist die Prinziplösung [GAC+13]. Es folgt der fachdisziplinspezifische Entwurf, der mit der Auswahl der entsprechenden Lösungselemente beginnt. Hierzu werden die in der Prinziplösung enthaltenen Informationen genutzt, in die Terminologien der beteiligten Disziplinen übersetzt und anschließend detailliert. So werden beispielsweise detaillierte Parameterbereiche (Bauraum, max. Drehzahl etc.) festgelegt. Diese Informationen sind notwendig, um im Semantic Web geeignete Lösungselemente auszuwählen, die den verwendeten Lösungsmustern durch semantische Annotationen zugeordnet sind. Mit Auswahl der Lösungselemente endet der Zugriff auf Lösungswissen im Semantic Web. Es folgt der fachdisziplinspezifische Entwurf, dessen Ergebnis durch die Bau- und Komponentenstruktur repräsentiert wird [GAC+13]. zunehmende Konkretisierung Konstrukte der Zielbestimmung Semantic Web Konstrukte der Wirkstruktur Konstrukte der Baustruktur Konstrukte des Verhaltens Konstrukte der Komponentenstruktur Bauteil/ Baugruppe Bauteil/ Baugruppe Bauteil/ Baugruppe Anforderung Umfeldelement Funktion Anwendungsszenario (Text, Skizze) Softwarekomponente Softwarekomponente Softwarekomponente Merkmale Kontext Funktionen Umsetzung Modelle K Wirkstruktur Verhalten Aktivität Aktivität Zustand Systemelement Systemelement Systemelement Seite 84 Kapitel 3 Bewertung: GAUSEMEIER ET AL. liefern ein allgemeingültiges Vorgehen für einen musterbasierten Systementwurf. Ausgangspunkt sind Informationen aus der strategischen Produktplanung mit ersten Anforderungen an das zu entwickelnde System. Das Ergebnis ist das entwickelte System, repräsentiert durch Bau- und Komponentenstruktur. Da- bei wird auf Lösungswissen – Lösungsmuster und -elemente – aus dem Semantic Web zurückgegriffen. Vor dem Hintergrund der zu erfüllenden Anforderungen an das Instrumentarium ist zu klären, ob die Unterteilung in Lösungsmuster und -elemente ausreichend ist. Es werden beispielhaft Lösungsmuster aus den verschiedenen Disziplinen beschrieben, ihre systematische Herleitung, einheitliche Strukturierung sowie Anordnung im Wissensraum fehlt jedoch. Einer detaillierten Beschreibung des fortlaufenden Wechselspiels zwischen einem Entwurfsraum und möglichen Wissensraum wird der analysierte Ansatz nicht gerecht. 3.3.3 Musterbasierter Entwurf der selbstoptimierenden Informationsverarbeitung nach DUMITRESCU Zusätzlich zu der einheitlichen Strukturierung der Lösungsmuster für Selbstoptimierung beschreibt DUMITRESCU mit Hilfe eines Vorgehensmodells (vgl. Bild 3-23) den musterbasierten Entwurf der s.o. Informationsverarbeitung. Übergeordnetes Ziel ist die Integration kognitiver Funktionen in mechatronische Systeme unter Berücksichtigung der in der VDI2206 festgehaltenen Vorgehensweise für den Systementwurf. Der Fokus liegt dabei auf dem Entwurf der intelligenten Informationsverarbeitung. Weitere Disziplinen wie z.B. der Maschinenbau finden nur partiell Berücksichtigung [Dum10]. Das Vorgehensmodell, gegliedert in Phasen und Meilensteine, gibt einen Überblick über die wesentlichen Tätigkeiten und zu erarbeitenden Resultate. Die Darstellung ist idealtypisch. Die Anwendung ist geprägt durch Iterationen und Rücksprünge in vorangegangene Phasen. Die einzelnen Phasen und die durchzuführenden Tätigkeiten werden im Folgenden erläutert. Ausgangspunkt für das Vorgehensmodell ist ein nicht vollständig konzipiertes mechatronisches System. Das zu entwickelnde System enthält noch keine spezifizierte Informationsverarbeitung [Dum10]. Systemanalyse: In der ersten Phase wird der aktuelle Entwicklungsstand des mechatronischen Systems analysiert. Ziel ist die Aufdeckung von Nutzenpotentialen für kogniti- ve Funktionalitäten im System. Hierzu schlägt DUMITRESCU im Kern eine detaillierte Ausarbeitung des Zielsystems (vgl. Kapitel 2.2.3) unter Berücksichtigung von Einflüssen aus dem Systemumfeld vor. Liegen als Ergebnis Potentiale für kognitive Funktionen vor, folgen die Phasen 2 bis 4. Hat die Analyse ergeben, dass keine Potentiale vorliegen, ist das Vorgehensmodell beendet und es wird mit klassischen Entwurfsmethoden (z.B. VDI 2206) fortgefahren. Funktionssynthese: Kern der zweiten Phase ist die Spezifikation notwendiger kognitiver Funktionen. Mit Hilfe eines Funktionsverbenkatalogs ermöglicht es DUMITRESCU Entwicklern aus technischen Disziplinen die zu erarbeitende Informationsverarbeitung Stand der Technik Seite 85 funktional zu beschreiben. Die Funktionen werden in einer Funktionshierarchie abgebildet. Eine Entwurfsschablone erleichtert die Spezifikation und ist auf höchster Ebene gegliedert in die wesentlichen Phasen des Selbstoptimierungsprozesses (vgl. Kapitel 2.2.3). Bild 3-23: Vorgehensmodell für den lösungsmusterbasierten Entwurf nach DUMITRESCU [Dum10, S. 100] Lösungsauswahl: Im Hinblick auf das zu entwickelnde Instrumentarium ist die dritte Phase des Vorgehensmodells wesentlich. Auf Basis der zuvor erarbeitenden Funktionshierarchie werden geeignete Lösungsmuster gesucht und ausgewählt. Der Abgleich erfolgt dabei über die Funktionshierarchie und den gleichnamigen Aspekt in der Strukturierung der Lösungsmuster für Selbstoptimierung (vgl. Kapitel 3.2.2.3). Im Falle eines Misserfolgs bei der Suche über die Funktionen schlägt DUMITRESCU eine weitere Suchmöglichkeit vor. Demnach ist es auch möglich, direkt nach Verfahren zu suchen, auf denen die Lösungsmuster für Selbstoptimierung beruhen. Systemspezifikation: Ziel der letzten Phase ist die Komplettierung der Prinziplösung des Gesamtsystems. Hierzu wird mit Hilfe der in den Lösungsmustern enthaltenen Informationen die Wirkstruktur, die Aktivitäten sowie die Zustände spezifiziert. Der Schwerpunkt liegt dabei auf der Konzipierung der Informationsverarbeitung, die in geeigneter Weise mit dem jeweiligen Entwicklungsstand des Grundsystems zusammenzuführen ist. Die entwickelte Spezifikation in Anlehnung an die Strukturierung des OCM (vgl. Kapitel 2.2.3) und die ausgewählten Lösungsprinzipien bilden die Grundlage für die Implementierung der kognitiven Informationsverarbeitung durch die entsprechenden Experten im späteren Verlauf der Entwicklung. Potentiale durch kognitive Funktionen Funktionshierarchie des OCM Lösungsmuster, Lösungsprinzipien Prinziplösung mit OCM-Spezifi kation Phasen/Meilensteine Aufgaben/Methoden Resultate Systemanalyse ●Einfl üsse aus dem Umfeldmodell identifi zieren. ●Zielrelevanz der Einfl üsse prüfen. ●Zielabhängigkeit feststellen. ●Potentiale und Zielsystem ableiten. ●Relevante Funktionsverben identifi zieren. ●Funktionen durch geeignete Funktionssubstantive bilden. ●Funktionshierarchie aufstellen. ●Lösungsmuster bzw. Lösungsprinzipien zur Umsetzung der Funktionen suchen. ●Ggf. Lösungen kombinieren und vergleichen. ●Lösungsmuster bzw. Lösungsprinzipien auswählen. ●Aspekte der Lösungsmuster entnehmen. ●Wirkstruktur und Verhalten des OCM spezifi zieren. ●Prinziplösung fertigstellen. ●Ggf. neue Lösungsmuster dokumentieren. 2 Funktionssynthese Lösungsauswahl Systemspezifi kation 1 3 4 Seite 86 Kapitel 3 Bewertung: Das Vorgehensmodell für einen musterbasierten Entwurf der Informationsverarbeitung fortgeschrittener mechatronischer Systeme ist gut auf die zugehörige Strukturierung der Lösungsmuster abgestimmt (vgl. Kapitel 3.2.2.3). Es wird dem Anspruch gerecht, Dritte in die Lage zu versetzen, eine kognitive Informationsverarbeitung zu spezifizieren. Dem Vorgehensmodell mangelt es jedoch an einer allgemeinverständlichen Darstellung zur Identifizierung und Definition von Lösungsmustern. Ferner ist der Betrachtungshorizont auf Ansätze zur Integration von Kognition im Hinblick auf einen ganzheitlichen Systementwurf zu eng gefasst. 3.4 Bewertung und Handlungsbedarf Ein Vergleich des Stands der Technik mit den abgeleiteten Anforderungen aus Kapitel 2 führt zu folgender Bewertung, die Bild 3-24 zusammenfasst: A1) Ganzheitlichkeit: Eine sehr umfangreiche Übertragung des Paradigmas der Lösungsmuster auf die Produktentstehung bzw. das Systems Engineering liefert CLOUTIER. Diese gilt es auf etablierte Strukturierungskonzepte, wie etwa das 3-Zyklen-Modell der Produktentstehung nach GAUSEMEIER, zu übertragen und zu erweitern. A2) Charakterisierung von Lösungsmustern: Einen Anhaltspunkt für die Charakterisierung von Lösungsmustern liefert GRABOWSKI mit der UDT. Weitere Arbeiten, die im Hinblick auf diese Anforderung relevant sind, beschreiben Lösungsmuster und ihre Wirkbeziehungen auf einer Meta-Ebene. Dazu zählen die Arbeiten von PFISTER und SIMPSON. Die vorliegenden Erkenntnisse sind bei der Charakterisierung von Lösungsmustern und ihrer Abgrenzung untereinander (Objekt-/ Prozessmuster, verträgliche Kombination von LM etc.) zu berücksichtigen und zu konkretisieren. A3) Einheitliche Strukturierung nach ALEXANDER: Der Großteil der untersuchten Lösungsmusteransätze orientiert sich an der Definition eines Lösungsmusters nach ALEXANDER. Ferner wird die Notwendigkeit der Interdisziplinarität und des Zusammenwirkens unterschiedlicher Disziplinen betont. In diesem Zusammenhang präsentiert ausschließlich DUMITRESCU eine einheitliche Strukturierung von Lösungsmustern. Diese ist jedoch auf wenige Lösungsansätze zur Entwicklung einer kognitiven Informationsverarbeitung abgestimmt. Der Informationsumfang der präsentierten Lösungsmuster ist im Hinblick auf einen ganzheitlichen Systementwurf zu hoch. Es ist daher eine Strukturierung erforderlich, die sich auf die wesentlichen Informationen konzentriert. Weitere Informationen wie z.B. über Wirkbeziehungen sind gesondert darzustellen. A4) Interdisziplinarität und Verständlichkeit: Als Spezifikationstechniken zur Darstellung des relevanten Lösungswissens und zur Modellierung komplexer technischer Systeme eignet sich in erster Linie CONSENS. Neben der Repräsentation einzelner Aspekte werden auch bestehende Querbeziehungen zwischen den Aspekten und Beziehungen zu fachdisziplinspezifischen Modellen beschrieben. Stand der Technik Seite 87 A5) Durchgängige Dokumentation: Erste Überlegungen für eine durchgängige Dokumentation liefert SUHM. Er definiert einen Wissensraum mit unterschiedlichen Dimensionen, jedoch abgestimmt auf die Bedürfnisse des Maschinenbaus. Diese Dimensionen sind aufzugreifen und auf die Besonderheiten im fachdisziplinübergreifenden Systementwurf anzupassen. Gefordert ist ein multidimensionaler Wissensraum, in dem Lösungsmuster für den Systementwurf durchgängig dokumentiert werden können. Bild 3-24: Bewertung des untersuchten Stands der Technik anhand der Anforderungen Bewertungsskala: = nicht erfüllt = teilweise erfüllt = voll erfüllt Legende: = Lösungsmuster = Systems Engineering = Produktentstehung = Informationsverarbeitung Anforderungen Ganzheitlichkeit Charakterisierung Einheitliche Strukturierung Interdisziplinarität und Verständlichkeit Durchgängige Dokumentation Systematische Vorgehensweise Geschlossener SECI-Kreislauf Abstraktion und Generalisierung Orientierung an etablierten Standards A1 A2 A3 A4 A5 A6 A7 A8 A9 Universal Design Theory nach G RABOWSKI Musterhierarchie nach C LOUTIER SE Entwurfsmuster-Metamodell nach P FISTER SE Mustersprache nach S IMPSON Lösungswissen für den Systementwurf Techniken für die Wissensrepräsentation CONSENS UML SysML PrEMISE Modelica ® Disziplinübergreifende LM Systemarchitekturmuster nach C LOUTIER Lösungsmuster mit SysML nach W EILKINS Lösungsmuster für selbstoptimierende Systeme nach D UMITRESCU Disziplinspezifi sche LM Lösungsmuster im Maschinenbau nach S UHM Entwurfsmuster nach S ALUSTRI Koordinationsmuster der Softwaretechnik nach D ZIWOK Ansätze der Regelungstechnik nach F ÖLLINGER Muster der Regelungstechnik nach S ANZ /Z ALEWSKI Identifzierung von Systemarchitekturmustern nach K AWALSKI Musterbasierter Entwurf mechatronischer Systeme nach G AUSEMEIER Musterbasierter Entwurf s.o. IV nach D UMITRESCU Überblick über Lösungsmuster Systematiken für den Einsatz von LM in der PE = selbstoptimierend LM SE PE IV s.o. Seite 88 Kapitel 3 A6) Systematische Vorgehensweise: Die Systematik für den Einsatz von Lösungsmustern muss eine zielgerichtete und systematische Vorgehensweise darstellen. Dieses gilt für die Identifizierung von Lösungsmustern und einen lösungsmusterbasierten Systementwurf gleichermaßen. Hierzu bedarf es Vorgehensmodelle, die notwendige Phasen, Hilfsmittel und Resultate beschreiben. Keiner der untersuchten Ansätze erfüllt in Bezug auf den Einsatz von Lösungsmustern eine derart umfangreiche Vorgehensweise. A7) Geschlossener SECI-Kreislauf: Da sich etablierte Systematiken im Kontext Wissensmanagement an dem SECI-Kreislauf orientieren, muss das angestrebte Instrumentarium dieser Anforderung gerecht werden. Keiner der untersuchten Ansätze erfüllt isoliert betrachtet diese Anforderung in Gänze. Es ist ein holistischer Ansatz zu erarbeiten, der die Identifizierung, Dokumentation und Anwendung von Lösungsmustern zyklisch durchläuft. A8) Abstraktion und Generalisierung: Ein Vorgehen zur Identifizierung und Ableitung von Lösungsmustern, das dieser Anforderung gerecht wird, liefert KALAWSKY. Dieses ist auf die Entwicklung fortgeschrittener mechatronischer Systeme zu übertragen und zu detaillieren. Ferner sind die Zusammenhänge zum multidimensionalen Wissensraum und der damit verbundenen langfristigen Dokumentation der identifizierten Lösungsmuster herauszustellen. A9) Orientierung an etablierten Standards im Systementwurf: Von den untersuchten Ansätzen zu den Lösungsmustern orientieren sich vorrangig DUMITRESCU und GAUSEMEIER ET AL. an etablierten Standards für den Systementwurf. Die erzielten Ergebnisse sind aufzugreifen und im Vorgehensmodell für einen lösungsmusterbasierten Systementwurf zu berücksichtigen. Der Fokus muss dabei auf dem systematischen Zusammenspiel zwischen den Tätigkeiten im Entwurf und dem zu definierenden Wissensraum liegen. Keiner der untersuchten Ansätze, als auch keine Kombination bestehender Ansätze erfüllt alle Anforderungen in vollem Umfang. Ein entscheidender Mangel ist die unzureichende Verzahnung zwischen Lösungsmustern für den Systementwurf und deren Einbettung in den Gesamtkontext Produktentstehung. Ferner fokussieren viele Ansätze nur Teilaspekte des Gesamtproblems wie z.B. die Typisierung von Lösungsmustern auf sehr hohem Abstraktionsniveau (Objektmuster, Prozessmuster etc.). Eine einheitliche Strukturierung von Lösungsmustern für den Systementwurf und eine zugehörige multidimensionale Skalierung zur durchgängigen Dokumentation, fehlen. Zudem existiert keine Systematik, die Angaben darüber enthält, wie Lösungsmuster für den Systementwurf identifiziert werden und wie mit Hilfe von Lösungsmustern ein fortgeschrittenes mechatronisches System fachdisziplinübergreifend entworfen wird. Es besteht demnach dringender Handlungsbedarf nach einem Instrumentarium für einen lösungsmusterbasierten Entwurf fortgeschrittener mechatronischer Systeme. Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 89 4 Instrumentarium für einen lösungsmusterbasierten Entwurf Der aus Kapitel 3 resultierende Handlungsbedarf verdeutlicht, dass es derzeit kein Instrumentarium für einen lösungsmusterbasierten Entwurf fortgeschrittener mechatronischer Systeme entsprechend den in Kapitel 2 definierten Anforderungen gibt. Ein solches Instrumentarium bildet den Kern der vorliegenden Arbeit. Es wird in diesem Kapitel auf theoretischer Basis erläutert. Kapitel 4.1 gibt einen Überblick über das Instrumentarium und seine wesentlichen Bestandteile. Die Basis bildet eine Beschreibung des Paradigmas der Lösungsmuster in der Produktentstehung. Dieses ist Gegenstand von Kapitel 4.2. Anschließend findet eine Fokussierung auf den Systementwurf statt. Kapitel 4.3 stellt eine einheitliche Strukturierung von Lösungsmustern vor. Zudem werden die Lösungsmuster anhand mehrerer Dimensionen charakterisiert, um darauf aufbauend die Zusammenhänge in dem entwickelten multidimensionalen Wissensraum allgemeinverständlich abzubilden. Es folgt eine Systematik für den Einsatz von Lösungsmustern. Kapitel 4.4 beinhaltet ein Vorgehensmodell für die Identifizierung von Lösungsmustern auf der Basis etablierter Systeme. In Kapitel 4.5 wird die Vorgehensweise für einen lösungsmusterbasierten Systementwurf beschrieben. Die Verifikation des Instrumentariums, insbesondere der Systematik, ist anschließend Gegenstand von Kapitel 5. 4.1 Das Instrumentarium im Überblick Das Instrumentarium für einen lösungsmusterbasierten Entwurf fortgeschrittener mechatronischer Systeme besteht aus vier Bestandteilen, die in diesem Kapitel erläutert werden. Es bildet den Kern der vorliegenden Arbeit. Das Instrumentarium hat den Anspruch, dem aufgezeigten Handlungsbedarf aus der Problemanalyse gerecht zu werden und setzt sich daher wie folgt zusammen (Bild 4-1): • Eine umfangreiche Übertragung des Paradigmas der Lösungsmuster auf die Produktentstehung bildet die Grundlage. Hierzu werden die unterschiedlichen Lösungsmuster beschrieben und in einem Wirkgefüge vereint. • Lösungswissen für den Systementwurf wird im Hinblick auf eine geeignete Dokumentation einheitlich strukturiert. Relevante Artefakte für den Systementwurf lassen sich so fachdisziplinübergreifend in unterschiedlichen Spezialisierungs- und Aggregationsniveaus repräsentieren. Etablierte Techniken für die Modellierung von Systembestandteilen werden genutzt und geeignet erweitert. • Ein Vorgehensmodell zur Identifizierung von Lösungsmustern, das durchzuführende Tätigkeiten, deren Ergebnisse sowie notwendige Hilfsmittel definiert, um auf Basis von realisierten Systemen, Lösungsmuster zu identifizieren und zu dokumentieren. Seite 96 Kapitel 4 alle fachdisziplinübergreifend relevanten Informationen abzubilden. Es ist als eine Art Koordinationsschicht zu verstehen, über die alle Aktivitäten in der Entwicklung gesteuert werden. Die Modelle auf der fachdisziplinübergreifenden Ebene werden bis zu jenem Zeitpunkt konkretisiert, ab dem disziplinspezifische Modelle hinsichtlich eines zu analysierenden Aspekts erforderlich werden. Zu analysierende Aspekte bei der Entwicklung von CPS sind beispielsweise die Dynamik eines Mehrkörpersystems oder die sichere und verteilte Kommunikation oder Koordination. Es handelt sich um Synthese- und Analyseschritte, die formale Modelle erfordern und größtenteils fachdisziplinintegrierend sind. Dies bedeutet, dass fachdisziplinspezifische Artefakte im Zusammenspiel betrachtet werden. Folglich existiert eine Zwischenschicht, die sog. Disziplinorientierte Mechatronik- Ebene. Diese Ebene repräsentiert die zuvor erwähnten Artefakte, die losgelöst von den zu analysierenden Aspekten erarbeitet und betrachtet werden müssen. So besitzt jedes mechatronische System beispielsweise eine Regelung oder mechanische Komponenten. Das Zusammenspiel der Entwurfsschritte in den einzelnen Ebenen kann unterschiedlich ausfallen. Dennoch sind alle Ebenen essentiell. Dies verdeutlichen die beiden folgenden Szenarien von Entwicklungstätigkeiten über die drei Ebenen hinweg. Das dynamische Verhalten dient dabei als zu analysierender Aspekt. Es wird davon ausgegangen, dass das System in der Entwicklung hinsichtlich weiterer Aspekte analysiert wird. Szenario 1: Die abgebildeten Piktogramme (in diesem Fall bezogen auf die Spezifikationstechnik CONSENS) auf der disziplinübergreifenden Ebene symbolisieren die relevanten Aspekte beim Systementwurf. Aufbauend auf den Anforderungen und einer funktionalen Beschreibung des Systems folgt die Modellierung von Struktur- und Verhaltensmodellen (Bild 4-3, 1. dunkelroter Pfeil). Ab einem bestimmten Zeitpunkt sind disziplinspezifische Erkenntnisse für die weitere Konkretisierung erforderlich. Es erfolgt eine Überführung der Informationen z.B. in die Fachdisziplinen Regelungstechnik, Maschinenbau und Softwaretechnik (Bild 4-3, orangener Pfeil-links). Über einen gewissen Zeitraum wird beispielsweise die Gestalt oder eine Regelung formal in entsprechenden Softwarewerkzeugen erarbeitet. Hierbei kommt es in der Regel zu detaillierten Anforderungen, die z.T. Auswirkungen auf die anderen beteiligten Disziplinen haben können (Bild 4-3, rote parallele Pfeile). Anschließend folgt eine Synchronisation der Entwicklungsergebnisse auf der disziplinübergreifenden Ebene (Bild 4-3, orangener Pfeil- Mitte). Die Modelle werden entsprechend konkretisiert. Ferner werden Verweise auf die disziplinspezifischen Informationen vorgenommen. Von der fachdisziplinübergreifenden Ebene aus wird eine initiale Untersuchung der Dynamik auf der disziplinintegrierenden Ebene angestoßen (Bild 4-3, orangener Pfeil-rechts). Hierzu werden die formalen Modelle der Zwischenschicht zusammen mit den Schnittstelleninformationen der fachdisziplinübergreifenden Schicht an die disziplinintegrierende Ebene übermittelt. Die Informationen werden zusammengeführt, ggf. detailliert und anschließend simuliert und Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 97 analysiert. Die Ergebnisse werden zur weiteren Koordination des Entwicklungsgeschehens an die übergreifende Ebene übergeben. Dieses Zusammenspiel und die Absicherung der unterschiedlichen Eigenschaften geschehen fortlaufend unter Berücksichtigung aller relevanten Aspekte der unteren Ebene bis zum fertig entwickelten Produkt. Szenario 2: Dieses Szenario unterscheidet sich von Szenario 1 in der erstmaligen Erstellung formaler Modelle (Bild 4-3, orangener Pfeil-links). Im Hinblick auf z.B. die frühestmögliche Analyse der Dynamik wird nicht als Erstes ein disziplinorientierter Entwurf angestoßen. Stattdessen findet beispielsweise ein integrierter Software- und Regelungsentwurf auf der aspektspezifischen Ebene statt [GTS14]. In diesem Fall werden kontinuierliche Verhaltensanteile der Regelungstechnik mit ereignisdiskreten Verhaltensanteilen der Softwaretechnik im direkten Zusammenspiel entworfen, simuliert und analysiert. Die mittlere Ebene wird dabei gedanklich ausgelassen. Trotzdem werden die disziplinspezifischen Artefakte auf dieser Ebene indirekt erstellt und sind folglich (als eine Art Speicher für mechatronische Artefakte) mitzuführen. Dies ist notwendig, um der steigenden Anzahl zu analysierender Aspekte eines CPS adäquat zu begegnen. Dies verdeutlicht die Initiierung einer Analyse der verteilten Koordination im Anschluss an die der Dynamik. Hierzu sind z.B. von denen bis dato erstellten formalen Modellen nur die über die ereignisdiskrete Software relevant. Diese sind im gewählten Beispiel um spezifische Informationen bzgl. Datenverwaltung oder Dynamik in Netzwerken durch Experten weiterer Disziplinen zu ergänzen. Bei der Initiierung dieser disziplinintegrierenden Entwurfsschritte wird ausgehend von der obersten Ebene auf die separierten Informationen der Mechatronik-Ebene zurückgegriffen. Andernfalls würde sich eine nur sehr schwer beherrschbare Komplexität in der Vernetzung zwischen den CPS- spezifischen Aspekten auf der untersten Ebene ergeben. Die fortlaufende Berücksichtigung der einzelnen Mechatronik-Artefakte ist daher ein entscheidender Stellhebel zur Bewältigung der steigenden Anzahl CPS-spezifischer Aspekte und dessen Zusammenwirken. Grundvoraussetzung dieser Vorgehensweise ist die abstrakte Darstellung aller fachdisziplinübergreifenden Informationen durch semiformale Modelle auf einer Art Koordinationsebene. Auf den geschilderten Zusammenhängen fußt die nachfolgende Erläuterung der an der Produktentwicklung beteiligten Lösungsmuster. Einen Überblick über die identifizierten Lösungsmuster zeigt Bild 4-4. Systemmodell Wie eingangs beschrieben, ist das zentrale Element in der Produktentwicklung das sog. Systemmodell. Eng mit dem Systemmodell verknüpft sind Anforderungen auf Systemebene. Der erste Schritt bei der Erstellung eines Systemmodells und somit der Konzipierung des Gesamtsystems ist die Anforderungsspezifikation. Hierbei werden, wie auch bereits im Rahmen der strategischen Produktplanung, Anforderungsmuster genutzt. Ebenfalls in Absprache mit der strategischen Produktplanung folgt die Erarbeitung einer Systemarchitektur. Bei der Gestaltung der Architektur muss unterschiedlichen Anforde- Seite 98 Kapitel 4 rungen Rechnung getragen werden – Kundenanforderungen, gesetzlichen Anforderungen, Anforderungen aus der Entwicklung, der Fertigung, Montage etc. Systemarchitekturmuster für mechatronische Systeme haben ihren Ursprung im Maschinenbau. Zu nennen sind z.B. die Integral- oder Differentialbauweise nach PAHL/BEITZ, sowie die Unterteilung nach SCHUH in Baukästen, Module, Baureihen und Pakete [PBF+07], [Sch12]. Bild 4-4: Lösungsmuster in der Produktentwicklung Auf Basis der Architektur folgt der Systementwurf. Bei der Suche nach erfolgversprechenden Lösungsmustern hat sich die Funktionsbeschreibung als zentraler Meilenstein etabliert. Die Gliederung der gewünschten Funktionalität erfolgt in der Regel in einer Funktionshierarchie. Die Gesamtfunktion wird solange in Teilfunktionen unterteilt, bis sich für die Funktionen sinnvolle Lösungen finden lassen [VDI2221]. Dieser Vorgehensweise wurde in der Vergangenheit stark im Maschinenbau gefolgt, was die etablierten in der Regel fachdisziplinspezifischen Entwurfsmuster54 wie Wirkprinzipien oder Funktions- und Prinzipfeature55 etc. verdeutlichen [PBF+07], [Rot01], [KK98]. Aus der Analyse des Stands der Technik geht hervor, dass insbesondere im Systems Engineering (vgl. CLOUTIER, Kapitel 3.1.2) eine enge Verknüpfung zwischen Entwurfsmustern und sog. Entwicklungsprozessmustern gesehen wird. Es zeigt sich, dass z.B. generische Ablauffolgen zum Lösen technischer Probleme, wie „Functions, Requirements, Architecture, Tests“ als sog. FRAT-Muster interpretiert und dokumentiert sind [SS06]. Dieser Interpretationsweise folgend, lassen sich auch Referenzprozesse zur Entwicklung mechatronischer Systeme sowohl auf Makro- (Systementwurf, fachdisziplinspezifischer Entwurf und Ausarbeitung, Systemintegration) als auch auf Mikro-Ebene (Zielbestimmung, Synthese, Analyse) als Prozessmuster interpretieren [VDI2206]. Weitere Beispiele für feingranulare wiederverwendbare Prozessbausteine liefern beispielsweise KAHL, BICHLMAIER, MURR [Kah13] [Bic00], [Mur99]. Bei der Planung von Entwick- 54 Der Schwerpunkt dieser Dissertation liegt auf z.T. mechatronischen Systementwurfsmustern für fortgeschrittene mechatronische Systeme. Diese sind im Hinblick auf die gestellten Anforderungen an dieses Instrumentarium zu entwickeln. Eine detaillierte Erläuterung findet daher in den nachfolgenden Kapiteln, insb. Kapitel 4.3, statt. 55 S. Anhang A2.2 Produktentwicklung Systemmodell Anforderungsmuster Mechatronik Mechanik Softwaretechnik Elektronik Regelungstechnik Architekturmuster Entwicklungsprozessmuster Hard- und Software Elektronik Komponente A Komponente B Software Mechanik Anforderungsmuster Entwurfsmuster Simulations(Analyse-)muster mechatronische Systementwurfsmuster Systemanalysemuster Teststrategiemuster G RS (s) G M (s) Regelung Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 99 lungsprozessen erhält die Rollen- und Aufgabenverteilung eine zunehmend größere Bedeutung. Diese werden in einigen Ansätzen aus dem Stand der Technik ebenfalls als Muster interpretiert und in direkten Zusammenhang zu Entwicklungsprozessmustern gesetzt56 [CD06]. In Bezug zu den in Bild 4-3 schematisch dargestellten Ebenen in der Entwicklung fortgeschrittener mechatronischer Systeme, lassen sich auch auf der fachdisziplinübergreifenden Ebene Analysen durchführen und somit Systemanalysemuster ableiten. Diese Muster enthalten z.B. Angaben darüber, welche Analysen zur Absicherung bestimmter Eigenschaften eingesetzt werden können. So existiert z.B. bereits eine Wissensbasis, die Erfahrungswissen zur frühzeitigen Analyse der Zuverlässigkeit mechatronischer Systeme bereitstellt [Gau10]. Ein weiteres Handlungsfeld des Systemmodells ist die Abstimmung mit der Produktionssystementwicklung im Hinblick auf eine Teststrategie. Je nach Komplexität und Architektur des Systems sind unterschiedliche Teststrategiemuster erforderlich. Diese beinhalten Angaben über Zusammenhänge, welche Eigenschaften und Funktionalitäten des Systems beispielsweise mit einem Komponententest, Modultest oder Systemtest getestet werden. Dieses Zusammenspiel mit der Produktionssystementwicklung, speziell der Montage, muss im Systemmodell frühzeitig berücksichtigt und konzipiert werden. Hard- und Software Wie bereits beschrieben und in Bild 4-3 visualisiert, werden zu einem bestimmten Zeitpunkt in der Entwicklung erarbeitete Informationen im Systemmodell in den fachdisziplinspezifischen Entwurf der Hard- und Software übergeben. In einem ersten Schritt werden in der Regel detaillierte disziplinspezifische Anforderungen definiert, die auf der fachdisziplinübergreifenden Ebene keine Relevanz haben (z.B. Anforderungen an echtzeitkritisches Verhalten). In diesem Zusammenhang lassen sich erneut Anforderungsmuster spezifizieren. Diese, sowie die im Folgenden erläuterten Lösungsmuster, betreffen alle Disziplinen gleichermaßen (vgl. Bild 4-4). Aufbauend auf den Anforderungsmustern werden mit Hilfe von Entwurfsmustern die erforderlichen Artefakte in den einzelnen Disziplinen synthetisiert. Diesbezüglich ist in Industrie und Forschung eine Vielzahl von Ansätzen vorhanden, um den in der Regel rechnerinternen Prozess zu beschleunigen (Koordinationsmuster der Software [DHT12] oder Gestaltungsfeature in CAD-Systemen). Damit einher geht auch die Anwendung von Simulations- bzw. Analysemustern. Dies verdeutlicht das nachfolgende Beispiel aus dem Maschinenbau. Im Maschinenbau werden beispielsweise nach Festlegung der groben Gestalt auf der fachdisziplinübergreifenden Ebene, erste Gestaltmodelle am CAD-System erarbeitet. 56 Einen ausführlichen Überblick über Rollen und Aufgaben im Hinblick auf die Erstellung eines fachdisziplinübergreifenden Systemmodells liefert KAISER [Kai13, S. 33ff.]. Seite 100 Kapitel 4 Unter Berücksichtigung der Restriktionen im Systemmodell werden Anforderungen an das Material, die Geometrie und z.B. die Belastung (Belastungsformen) spezifiziert. Bei dem anschließenden Entwurf werden beispielsweise Phasen, Nuten oder auch Bohrungen am Bauteil platziert. In diesem Zusammenhang existieren gestalterische Richtlinien, die auf langjähriger Expertise beruhen und als Entwurfsmuster interpretiert werden können. Diese enthalten z.B. Angaben über die Anzahl, Durchmesser und Abstände von Bohrungen je nach zugrundeliegendem Belastungsprofil. In modernen CAD-Systemen sind diese Zusammenhänge bereits hinterlegt und unterstützen den Entwickler beim Entwurf. Unmittelbar im Anschluss wird auf Basis der formalen Modelle rechnerintern eine Simulation und somit eine Analyse der erarbeiteten Ergebnisse durchgeführt. Hinsichtlich der Festigkeit lassen sich Bauteile beispielsweise mit Hilfe der Finite-Element- Methode57 und zugehörigen Softwarewerkzeugen bewerten. Bei dieser Methode wird das zu untersuchende Bauteil in eine endliche Anzahl nicht unendlich kleiner Elemente unterteilt. Die auf diese Weise entstehende Gitterstruktur kann über den Verlauf eines Bauteils variieren. Je nach z.B. Form, Material und geforderter Güte der Analyse, lässt sich die Granularität der aufzubauenden Gitterstrukturen bestimmen. Wissen zur Beschleunigung dieser Analysen ist z.T. bereits Softwarewerkzeugen implementiert und lässt sich folglich als eine Art Simulations- oder Analysemuster interpretieren. Aufgrund des anhaltenden Trends zu intelligenten technischen Systemen zufolge wird es zukünftig vermutlich vermehrt zu einem fachdisziplinintegrierten Entwurf und einer Analyse hinsichtlich unterschiedlicher Aspekte wie beispielsweise der Dynamik kommen. Damit einher geht das Potential, weitere Lösungsmuster zu identifizieren. 4.2.2.3 Lösungsmuster in der Produktionssystementwicklung Die Produktionssystemkonzipierung, als erster Schritt der Produktionssystementwicklung, beginnt bereits im Wechselspiel mit der Produktkonzipierung. Hierbei werden alle für das Produktionssystem relevanten Aspekte fachdisziplinübergreifend in einem Produktionssystemmodell abgebildet [GLL12]. Auf Basis dieses Modells erfolgt anschließend die Erstellung eines Arbeitsplans bestehend aus einem Arbeitsablauf-, Arbeitsstätten-, Materialfluss- und Arbeitsmittelplan. Produktionssystemmodell Notwendige Aspekte des Produktionssystemmodells sind u.a. Anforderungen, Gestalt des Produktionssystems, Prozesse oder auch Ressourcen. Anforderungen an das Produktionssystem werden maßgeblich vom Produktkonzept determiniert. Dieser Kausalkette folgend lassen sich Anforderungsmuster beschreiben (vgl. Bild 4-5). Diese bein- 57 Die gewählte Methode dient der Erklärung von Simulations- und Analysemustern und wird daher nicht in Gänze beschrieben. Für detaillierte Informationen sei an dieser Stelle auf einschlägige Literatur verwiesen. Vgl. z.B. [Kle10] Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 101 halten als zugrundeliegendes Problem charakteristische Eigenschaften des Produktkonzepts und als Lösungsbeschreibung zugehörige Anforderungsbündel an das zu konzipierende Produktionssystem. Charakteristische Eigenschaften könnten z.B. sein: verwendete Technologie (z.B. MID58) oder geplante Stückzahl. Bild 4-5: Lösungsmuster in der Produktionssystementwicklung Auf Basis der spezifizierten Anforderungen folgt die Produktionssystemkonzipierung unter Zuhilfenahme von Entwurfsmustern. Als Eingangsinformationen dient dabei neben den Anforderungen der bis dato erarbeitete Stand des Produktkonzepts. Ist beispielsweise die Technologie zur Umsetzung des Produkts oder einer Teilkomponente ausgewählt, lassen sich das Produktionssystemmodell und die darin enthaltenen Aspekte sukzessive synthetisieren. Ein Beispiel für eine mögliche Strukturierung von Lösungsmustern für die Produktionssystemkonzipierung zeigt Bild 4-6. In Anlehnung an die Kategorien nach dem Architekturtheoretiker ALEXANDER unterteilen sich die Lösungsmuster in die Kategorien Name, Problem, Lösung und Kontext. Das zugrundeliegende Problem wird symbolisiert durch einen dreidimensionalen spritzgegossenen Schaltungsträger. Als Kern der Lösung lassen sich beispielsweise unterschiedliche Prozessketten zur Herstellung eines solchen Schaltungsträgers aufführen [Fra13]. In Bild 4-6 werden diese verdeutlicht durch die Partialmodelle Ressourcen und Prozesse. Zusätzlich ist es sinnvoll, spezifische Merkmale, Expertise über einzelne Feature – als eine Art spezialisiertes Muster59 – oder den Kontext, zu beschreiben. Unmittelbar im Zusammenspiel mit den Entwurfsmustern lässt sich mit Hilfe von Simulationsmustern das synthetisierte Produktionssystemkonzept untersuchen. Diese Zusammenhänge verdeutlicht das skizzierte Anwendungsbeispiel der Herstellung eines 3D-Schaltungs- trägers im Anhang A2.3. Analysemuster in Bezug auf das Produktionssystemmodell existieren beispielsweise bzgl. Herstellungskosten [GLL12]. 58 Vgl. [Fra13] 59 Ein Beispiel für ein spezialisiertes Muster der Technologie MID befindet sich im Anhang A2.3. Produktionssystem- entwicklung Arbeitsplan Materialfluss- planung Arbeitsmittel- planung Arbeitsablauf- planung Arbeitsstätten- planung Produktionssystemmodell Ablauf Fabrik Logistik Mittel Anforderungsmuster Produktionssystementwurfsmuster Anforderungsmuster Entwurfsmuster Simulations- (Analyse-)muster Simulations(Analyse-)muster Seite 102 Kapitel 4 Bild 4-6: Strukturierung für Entwurfsmuster für die Produktionssystemkonzipierung Analog zu den bereits beschriebenen Artefakten in der Produktentstehung lassen sich, auch im Hinblick auf die Teilbereiche des Arbeitsplans, Anforderungsmuster identifizieren. Die darauf aufbauende Planung und Umsetzung der zugehörigen notwendigen Artefakte wie ein Arbeitsmittelplan oder ein Arbeitsstättenplan beruhen auf langjähriger Expertise. Diese ist umfangreich dokumentiert und steht der in Kapitel 4.2.1 formulierten Definition zur Folge, als Lösungsmuster bzw. Entwurfsmuster zur Verfügung. Als Beispiele sind u.a. die Zusammenhänge hinsichtlich erforderlicher Werkzeuge zum Umformen, Urformen etc. aus der VDI3320 zu nennen [VDI3320-2]. Als Entwurfsmuster für den Aufbau von Arbeitsstätten existieren heutzutage zahlreiche Normungen zur Arbeitsplatzgestaltung in jeglicher Form. Diese enthalten u.a. Informationen zu den Bereichen Ergonomie oder Anordnung. Im Bereich der Materialflussplanung lassen sich z.B. die Entwurfsmuster „Just-in-Time“ oder „Just-in-Sequence“ aufführen. Zur Validierung bestimmter Zusammenhänge werden auch im Bereich der konkreten Arbeitsplangestaltung Simulations- bzw. Analysemuster eingesetzt. So existieren beispielsweise Arbeiten für die simulative Unterstützung der Arbeitsplanung und Arbeitssteuerung durch eine Cloud-Anwendung. Ein virtuelles Abbild einer Werkzeugmaschine soll ein automatisiertes Einrichten der Maschinen und eine effiziente Auftragsdisposition ermöglichen. Die dafür erforderliche Expertise der Fertigungsplaner wird rechnerintern in Form von Mustern in die Cloud-Anwendung integriert [BGP+14]. 4.2.3 Wirkgefüge der Lösungsmuster in der Produktentstehung Wie die vorangegangen Kapitel anhand ausgewählter Beispiele verdeutlichen, lassen sich Lösungsmuster in allen Bereichen der PE zur Unterstützung der wiederkehrenden Tätigkeiten – Zielbestimmung, Synthese, Analyse – identifizieren. Ferner existieren Zusammenhänge zwischen den einzelnen Lösungsmustern. Dies betrifft die Lösungsmuster innerhalb eines spezifischen Bereichs der Produktentstehung, wie z.B. der Produktentwicklung (s. Kapitel 4.3.3.4), als auch bereichsübergreifend. Eine Übersicht der im Vorfeld beschriebenen Lösungsmuster und ihre Relationen über die PE hinweg zeigt Bild 4-7. Die Strukturierung orientiert sich dabei an den wesentlichen Handlungsfeldern in der Produktentstehung: Strategische Produktplanung, Produktentwicklung, Produktionssystementwicklung. Dieser Struktur folgend, lassen sich Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 103 auf einer übergeordneten Ebene grundsätzliche Zusammenhänge herstellen. Diese werden nachfolgend auszugsweise erläutert. Bild 4-7: Wirkgefüge von Lösungsmustern in der Produktentstehung Integrative Betrachtung von Lösungsmustern Die integrative Betrachtung von Lösungsmustern ist genau dann erforderlich, wenn bestimmte bereichsübergreifende Aktivitäten integrativ ablaufen müssen. Zu erwähnen sind u.a. der integrative Entwurf von Produkt- und Produktionssystemkonzept. Daraus resultiert der direkte Zusammenhang zwischen den Systementwurfsmustern und den Entwurfsmustern für das Produktionssystemmodell. Ein weiteres Beispiel lässt sich aus den Forderungen an die Weiterentwicklung des Systems Engineering für die Entwicklung intelligenter technischer Systeme ableiten. Gemeint ist die integrative Betrachtung von Produkt und Projekt. Hieraus resultiert die bilaterale Verbindung von Systementwurfsmustern und Entwicklungsprozessmustern als ein wesentlicher Baustein für die Projektplanung. Zeitlich aufeinander aufbauende Betrachtung von Lösungsmustern Die Problemanalyse hat verdeutlicht, dass aus einer beliebigen Menge von Lösungsmustern eine sog. Mustersprache wird, wenn die Anwendung eines Musters zu weiteren Mustern führt, die anschließend betrachtet werden sollten [BC87]. Diese Beziehungsform zieht sich in Bild 4-7 konsequent durch die gesamte Produktentstehung. Als Beispiel sei der Zusammenhang zwischen den Produktstrategiemustern und den Systementwurfsmustern zu nennen. Die Festlegung auf ein Produktstrategiemuster oder auf eine Kombination von Produktstrategiemustern (Beispiel modularer Querbaukasten in Strategische Produktplanung Geschäftsmodell Erfolgspotential Produkt-/ Technologiestrategie Arbeitsplan Produktionssystemmodell Anforderungsmuster Produktionssystementwurfsmuster Anforderungsmuster Entwurfsmuster Simulations(Analyse-)- muster Simulations(Analyse-)muster Produktentwicklung Verhaltensmuster pot. Kunden Produktstrategiemuster Technologiestrategiemuster Anforderungsmuster Geschäftsmodellmuster Kooperationsmuster Produktionssystementwicklung Hard- und Software Anforderungsmuster Entwurfsmuster Simulations- (Analyse-)muster Integrative Betrachtung von Lösungsmustern Zeitlich aufeinander aufbauende Betrachtung von Lösungsmustern Legende Retrospektive Betrachtung von Lösungsmustern zur Analyse und Erweiterung Anforderungsmuster Architekturmuster Entwicklungsprozessmuster mechatr. Systementwurfsmuster Systemanalysemuster Teststrategiemuster Systemmodell Seite 104 Kapitel 4 der Automobilindustrie: Plattformstrategie, Modulstrategie und Baukastenstrategie) determinieren die Auswahl und somit die für die Entwicklung zur Verfügung stehenden Lösungsmuster signifikant. Dies ist insbesondere der Fall, wenn ein Neuprodukt gemäß der festgelegten Strategie entwickelt werden muss. Retrospektive Betrachtung von Lösungsmustern zur Analyse und Erweiterung Eine weitere Relation ist die retrospektive Betrachtung von Lösungsmustern. Im Nachgang einer erfolgreichen Produkt- und Produktionssystementwicklung ist zu analysieren, aus welchen angewendeten detaillierten Lösungsmustern abstrakte Lösungsmuster für zeitlich vorgelagerte Entwicklungstätigkeiten identifiziert werden können. Als erklärendes Beispiel sind die im Rahmen der Produktentwicklung verwendeten Entwurfsmuster der Fachdisziplinen Maschinenbau, Regelungstechnik und Softwaretechnik zu nennen. Auf Basis einzelner Muster oder einer bestimmten Kombination dieser Muster lassen sich z.T. mechatronische Systementwurfsmuster identifizieren und definieren. Im Hinblick auf ihren Einsatzzweck unterscheiden sich die Lösungsmuster und die darin enthaltenen Informationen beispielsweise in ihrer Detailtiefe60. In Ergänzung enthalten sie relevante Informationen über die Schnittstellen zwischen den ehemals disziplinspezifischen Lösungsansätzen. Weitere grundsätzliche Zusammenhänge und Besonderheiten Es ist darauf hinzuweisen, dass neben den Beziehungen über die gesamte Produktentstehung weitere Wechselwirkungen und Besonderheiten bestehen. Ein sehr allgemeiner Zusammenhang bezieht sich dabei auf Lösungsmuster zur Erstellung von Prozessen und Objekten. Ferner existieren Wechselwirkungen zwischen Lösungsmustern in der Entwicklung einzelner Artefakte (z.B. Systemmodell). Darüber hinaus gibt es Besonderheiten in der Verträglichkeit von Lösungsmustern gleichen Typs. Abschließend wird ersichtlich, dass wiederholte Nennungen von Lösungsmustern gleichen Typs vorkommen, diese jedoch deutliche Unterschiede in ihrem Detaillierungsgrad und der Repräsentationsart der bereitgestellten Informationen aufweisen. • Prozess- und Objektmuster: Bei der Erstellung von Prozessabläufen in unterschiedlichen Bereichen der Produktentstehung können Lösungsmuster unterstützend eingesetzt werden. Dabei kann es zu Verweisen auf Lösungsmuster kommen, die der Synthese von Objekten dienen (vgl. Definition in Kapitel 4.2.1). Dies muss nicht zwangsläufig der Fall sein. • Wechselwirkungen zwischen Lösungsmustern in der Entwicklung einzelner Artefakte: Analog zu der zeitlichen Reihenfolge in der Betrachtung von Lösungs- 60 Die Art der Zusammenhänge zwischen Systementwurfsmustern und z.B. den Entwurfsmustern der Softwaretechnik oder der Regelungstechnik ist ein Schwerpunkt der vorliegenden Dissertation. Eine detaillierte Beschreibung folgt in Kapitel 4.3 speziell in Kapitel 4.3.3. Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 105 mustern auf höchster Ebene in der Produktentstehung, besteht ein zeitlicher Zusammenhang während der Entwicklung einzelner Artefakte. So determinieren beispielsweise ausgeprägte Anforderungsmuster die Auswahl von Systementwurfsmustern. • Verträglichkeit von Lösungsmustern gleichen Typs: In der Regel kommt es im Rahmen einer lösungsmusterbasierten Produktentstehung bei der Erstellung der einzelnen Artefakte zur Kombination von Lösungsmustern. Hierbei ist darauf zu achten, dass die einzelnen Lösungsmuster in Kombination verträglich sind. Die wechselseitige Beziehung von unverträglichen Lösungsmustern ist als sog. Anti- Pattern-Beziehung festzuhalten. • Wiederholte Nennung von Lösungsmustern gleichen Typs: Im Wirkgefüge der Lösungsmuster in Bild 4-7 wird ersichtlich, dass sich z.B. Anforderungsmuster wiederholen. Hierbei gilt es zu beachten, dass zwar der Aufbau und die Zielstellung von Lösungsmustern gleich sein kann, sie sich jedoch signifikant im Konkretisierungsgrad des bereitgestellten Wissens unterscheiden. Anforderungsmuster in der strategischen Produktplanung beziehen sich in der Regel auf sehr allgemeine Themen wie gesetzliche Rahmenbedingungen und Marktanforderungen im Hinblick auf das Gesamtsystem. Im Gegensatz dazu beziehen sich z.B. Anforderungsmuster in der Produktentwicklung, etwa in der Softwaretechnik, auf detaillierte Anforderungen z.T. auf Subsysteme. Für das aufgeführte Beispiel der Software können dies z.B. Deadlines für Synchronisationsvorgänge einzelner Softwarekomponenten sein. 4.3 Lösungswissen für den Systementwurf Die vorangegangenen Kapitel zeigen, dass für den Entwurf fortgeschrittener mechatronischer Systeme Lösungswissen von allen beteiligten Disziplinen und deren Experten notwendig ist. In erster Linie handelt es sich dabei um implizites Wissen. Als implizites Wissen wird im Rahmen dieser Arbeit jenes Wissen verstanden, das zunächst stillschweigend verfügbar ist. Es ist entweder personengebunden oder liegt unerkannt in weiteren Wissensquellen vor wie z.B. Entwicklungsdokumenten oder Computermodellen. Eine Besonderheit im Systementwurf liegt darin, dass das Lösungswissen aus den unterschiedlichen Disziplinen gleichwertig behandelt und miteinander kombiniert werden muss. Dieses Kapitel nimmt sich daher den Herausforderungen an, Lösungswissen zu externalisieren und eine geeignete Technik für den Umgang mit diesem Lösungswissen zu erarbeiten. Primäres Ziel ist es, Lösungswissen fachdisziplinübergreifend und allgemeinverständlich zu repräsentieren (Kapitel 4.3.1). Die dafür notwendige Strukturierung gilt es anschließend anhand ausgewählter Beispielmuster zu validieren (Kapitel 4.3.2). Durch die Kombination von ehemals i.d.R. fachdisziplinspezifisch geprägten Lösungsmustern entsteht neuartiges und für den Systementwurf charakteristisches Lösungswissen; Wissen über Schnittstellen und somit über wechselseitige (z.T. multidis- Seite 112 Kapitel 4 Bild 4-11: Aspekte des Lösungsmusters „Aktion befehlen“ Die Lösungsbeschreibung umfasst die Partialmodelle Wirkstruktur, Verhalten-Zustände und Verhaltens-Sequenz. Beide Systemelemente verfügen über einen Port vom Typ „peer“, was die Gleichberechtigung der Systemelemente widerspiegelt. Beide Systemelemente befinden sich zu Beginn der Kooperation in dem Zustand „inaktiv“. Sie haben jeweils die Möglichkeit, die Interaktion zu starten. Wird ein Sendevorgang von außen initiiert, sendet entweder „Systemelement 1 oder 2“ eine Aufforderung an das jeweils andere Systemelement. Die Reaktion auf die Anfrage ist für das jeweils andere Systemelement nicht mehr von Interesse. Lösungsmuster “Informationsaustausch initiieren”: Bild 4-12 veranschaulicht die ausgearbeiteten Aspekte des Lösungsmusters “Informationsaustausch initiieren“. Die Funktionshierarchie und somit die Problembeschreibung des Lösungsmusters erstreckt sich über drei Ebenen. Es handelt sich um einen Auszug aus dem Lösungsmuster „Zusammenarbeit synchronisieren“. Die Funktionshierarchie umfasst im Kern die Funktionalitäten rund um das „Senden und Empfangen von Anfrage und Antwort“, wobei die Antworten in „Zusagen“ und „Absagen“ zu unterscheiden sind. Die prinzipielle Wirkungsweise des Lösungsmusters lässt sich sehr prägnant an dem Partialmodell Verhalten-Sequenz erkennen. Zu Beginn der Kooperation sind beide Systemelemente mit Ports vom Typ „peer“ im Zustand „inaktiv“. Beide Systemelemente haben wie in den Beispielen zuvor jeweils die Möglichkeit, eine Anfrage zu senden, um den Informationsaustausch zu beginnen. Das Systemelement, das die Anfrage gesendet hat, wechselt anschließend in den Zustand „auf Antwort warten“. Das andere Systemelement wechselt seinerseits in den Zustand „Anfrage auswerten“. Ist die Anfrage ausgewertet, positiv oder negativ, folgt als Reaktion wieder ein Informationsfluss zurück. Dem anderen Systemelement wird entweder eine „Zusage“ oder eine „Absage“ für den Austausch erteilt. Im Anschluss an die Interaktion wechseln beide Systemelemente in den Zustand „inaktiv“ und warten erneut auf einen Reiz von außen. Das untere Ende der Lebenslinie im Partialmodell Verhalten-Sequenz ist folglich erreicht. Funktionen Verhalten - Sequenz Legende Wirkstruktur Systemelement 1 Systemelement 2 peer peerpeer peer Aktion befehlen Aktion befehlen Aufforderung senden Aufforderung empfangen Verhalten - Zustände E 1a Aufforderung gesendet E 1b Aufforderung empfangen inaktiv E 1b Aufforderung Aufforderung Zustände Funktion Port Zustandsmaschine Ereignis Alternative Informationsfluss Start Lebenslinie Systemelement logische Beziehung E 1a Systemelement 2 Systemelement 1 A B Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 113 Bild 4-12: Aspekte des Lösungsmusters „Informationsaustausch initiieren“ 4.3.2.2 Multidisziplinäres Lösungsmuster „Servoantrieb“ Eine Anforderung an Lösungsmuster für den Systementwurf ist ihre Interdisziplinarität. Dementsprechend sind auch fachdisziplinspezifische Ansätze in die Terminologie der frühzeitigen Konzipierung zu transformieren, um eine Interaktion der Lösungsansätze untereinander zu gewährleisten. Letzteres verdeutlichen die zuvor beschriebenen Beispiele der Softwaretechnik in Kapitel 4.3.2.1. Im vorliegenden Kapitel wird ergänzend ein multidisziplinäres Lösungsmuster beschriebenen, das maschinenbauliche und regelungstechnische Anteile enthält. Es handelt sich um das Lösungsmuster „Servoantrieb“. Die wesentlichen Aspekte –Funktion, Wirkstruktur und Merkmale – sind in Bild 4-13 abgebildet und werden im Folgenden kurz erläutert. Problem: Hauptfunktion eines Servoantriebs ist, wie bei vielen anderen elektrischen Antrieben, die Funktion „Drehmoment erzeugen“. Eine Besonderheit beim Servoantrieb ist im Vergleich zu Elektromotoren die bereits implementierte Regelung. Neben den beiden Funktionen „Magnetfeld erzeugen“ und „Drehmoment abstützen“ hat daher die Funktion „geregelten Stromfluss erzeugen“ eine ganz entscheidende Bedeutung. In der Regel gibt der Entwickler bei der Implementierung eines Servoantriebs lediglich die gewünschten Sollwerte für diejenigen Parameter vor, über die der Servoantrieb eingeregelt wird. Dieses wird physikalisch mit Hilfe des Stromflusses am Antrieb umgesetzt und durch die Funktionen „Stromfluss regeln“ und „elektrische Energie von externer Energiequelle“ in der Funktionshierarchie ausgedrückt. Die Funktion „Stromfluss regeln“ unterteilt sich weiter in Funktionen wie z.B. „Sollwerte zuführen“ oder „Stellgröße berechnen“. Funktionen Wirkstruktur Systemelement 1 Systemelement 2 peer peer Informationsaustausch initiieren Informationsaustausch initiieren Verhalten - Zustände E 1a Anfrage gesendet E 1b Anfrage empf. E 2a Ablehunug empf. E 2b Ablehnung ges. E 3a Zusage empfangen E 3b Zusage gesendet auf Antwort warten inaktiv E 2a E 1a E 1b E 3a E 3b E 2b Anfrage auswerten Verhalten - Sequenz Port peer des Systemelements 1 initiiert Anfrage für Zusammenarbeit Port peer des Systemelements 2 initiiert Anfrage für Zusammenarbeit A: B: Legende Zustände Funktion Port Zustandsmaschine Ereignis Alternative Informations- fluss Start Lebenslinie Systemelement logische Beziehung Antwort empfangen Anfrage senden Anfrage erhalten Antwort senden Zusage senden Ablehnung senden Zusage empfangen Ablehnung empfangen peer peer Systemelement 2 Systemelement 1 A Anfrage Zusage Ablehnung A 2 Anfrage Zusage Ablehnung A BB A 1 B 1 B 2 Seite 114 Kapitel 4 Bild 4-13 zeigt zudem die wesentlichen Merkmale bzw. Parameter. Es wird zwischen zwei Wertearten unterschieden. Es gibt Parameter, dessen Ausprägungen vom Entwickler während des Systementwurfs ermittelt werden müssen. Hierzu zählen das „Nennmoment“, das „Maximalmoment“, die „Nenndrehzahl“ und die „Motorkonstante“. Diese verdeutlichen ein wesentliches Charakteristikum eines Lösungsmusters, nämlich, dass es während des Entwurfs auf die jeweilige Problemstellung adaptiert werden muss. Ferner gibt es Parameter, für die Standardwerte existieren. Es handelt sich hierbei um gängige Werte für die „Netzspannung“ (z.B. 400 V) und die „Verzögerung des Stromregelkreises“ (z.B. 1 ms). In dem beispielhaft dargestellten Lösungsmuster sind die Werte in den Merkmalen daher schon vorgegeben. Selbstredend ist es möglich, die Lösung um diese Werte weiter zu generalisieren, um einen größeren Einsatzbereich abdecken zu können. Lösung: Die Lösung wird durch das Partialmodell Wirkstruktur abgebildet. Das in Bild 4-13 dargestellte weiße Systemelement im Hintergrund symbolisiert den „Servoantrieb“. Beziehungen nach außen existieren lediglich zu den Umfeldelementen „Informationsverarbeitung“, „Energieversorgung“ und „Umwelt“ (mittels einer mechanischen Verbindung). Letztere ist erforderlich, um das erzeugte Drehmoment gegenüber der Umgebung abzustützen. Ausgangsgröße des Musters ist der Energiefluss „Drehmoment“. Bild 4-13: Aspekte des Lösungsmusters „Servoantrieb“ Magnetfeld erzeugen geregelten Stromfluss erzeugen Stromfluss regeln el. Energie von externer Energiequelle zuführen Ist-Werte senden Stellgröße berechnen Sollwerte zuführen Sollwerte (phi) senden Sollwerte (omega) senden Ist-Werte sensieren Drehmoment abstützen Funktionen Merkmale Wirkstruktur Umwelt E-Motor inkl. Drehpotentiometer Ist- Wert Ist- Wert Stellgröße Sollwerte (phi) Sollwerte (omega) Drehmoment el. Energie el. Energie Hilfsführungs- größe mechanische Verbindung User-Eingabe User-Eingabe User-Eingabe User-Eingabe 400 V 0,001 s ≈ 1,35 • UNet ≈ KM ≈ UZ ≈ MN • ωN ≈ Mmax • 100,75 • lg PN - 4,9539 Nenndrehzahl Nennmoment Maximalmoment Drehmomentkonstante Netzspannung Verzögerungszeit des Stromregelkreises Zwischenkreisspannung Spannungskonstante Maximale Drehzahl Nennleistung Rotorträgheit omega_N (ωN) M_N (MN) M_max (Mmax) K_M (KM) U_Net (UNet) T_i (Ti) U_Z (UZ) K_S (KS) ωmax P_N (PN) KS 1000 Regelung (Winkel) Regelung (Drehzahl) Informationsverarbeitung Energieversorgung Drehmoment erzeugen Legende FunktionPort Alternative EnergieflussSystemelement Informationsfluss Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 115 Die Besonderheit des Lösungsmusters liegt im Zusammenspiel der Regelung mit dem physikalischen Systemelement „Elektromotor“. Dieser beinhaltet eine ganze Reihe weiterer Systemelemente, die der Einfachheit halber in dem Lösungsmuster nicht detailliert abgebildet sind. Es handelt sich dabei in erster Linie um den sog. „Anker“ und den sog. „Stator“. Auf der „Ankerwelle“ befinden sich „Drahtwicklungen“, welche von dem „Kommutator“ mit einem Stromfluss versorgt werden. Der „Sollstrom“, der in den „Drahtwicklungen“ eingestellt wird, ist das Ergebnis der „Regelung“ und wird mittels sog. „Bürsten“ auf den „Kommutator“ übertragen. Die „Ankerwelle“ ist gegenüber dem „Motorgehäuse“ gelagert. Eine Drehbewegung der „Ankerwelle“ ist jedoch nur möglich, wenn sich diese in einem „Magnetfeld“ befindet. Das benötigte „Magnetfeld“ wird vom „Stator“ erzeugt, der fest mit dem „Gehäuse“ verbunden ist. Der „Servoantrieb“ verfügt zusätzlich über ein „Drehpotentiometer“ auf der „Ankerwelle“. Die „Regelung“ ist direkt mit dem „Antrieb“ verbunden. Er wird über die beiden Parameter „Winkel“ und/oder die „Drehzahl“ geregelt (vgl. Wirkstruktur). Die „Regelung“ erfolgt nach dem Prinzip einer Kaskadenregelung, die als Lösungsmuster der Regelungstechnik interpretiert werden kann und in Kapitel 3.2.3.4 beschrieben ist. Aggregation des Lösungsmusters „Servoantrieb“ Wie bereits beschrieben kann ein Lösungsmuster teilweise oder vollständig aus weiteren Lösungsmustern aggregiert werden. In dem Beispiel „Servoantrieb“ handelt es sich um die Lösungsmuster „Elektromotor“ und „Kaskadenregelung“ (vgl. Bild 4-14). Im Gegensatz zu dem Beispiel aus dem vorangegangenen Kapitel baut die Kaskade somit nicht unmittelbar aufeinander auf. Vielmehr ist der „Servoantrieb“ ein Beispiel dafür, wie unabhängige Lösungsmuster miteinander verbunden werden können. Analog zu den beschriebenen Beispielen aus der Softwaretechnik beruhen die Lösungsmuster für den Systementwurf auf Lösungsprinzipien der partizipierenden Fachdisziplinen. Bei dem Elektromotor sind dies in erster Linie Prinzipien aus dem Maschinenbau und der Elektrotechnik. Die „Kaskadenregelung“ ist eine spezifische Herangehensweise in der Regelungstechnik. Eine Verfeinerung und Beschreibung weiterer charakteristischer Merkmale für Lösungsmuster für den Systementwurf fortgeschrittener mechatronischer Systeme folgt im anschließenden Kapitel. Bild 4-14: Aggregation des Lösungsmusters „Servoantrieb“ und/ oder und/ oder Muster der Regelungstechnik Regelung Strecke - (Multidisziplinäre) Lösungsmuster für den Systementwurf beruhen auf Elektromotor Kaskadenregelung Servoantrieb Wirkprinzip des Maschinenbaus F a * a = F b * b F a F b ab Wirkprinzip der Elektrotechnik F = I + ( 1 x B ) • • • • NS ist Teil von... ist Teil von... Seite 116 Kapitel 4 4.3.3 Charakterisierung von Lösungsmustern für den Systementwurf Die der Arbeit zugrundeliegende Problemanalyse und der analysierte Stand der Technik haben gezeigt, dass Lösungsmuster entlang unterschiedlicher Dimensionen charakterisiert werden. Dies ist auch erforderlich, um den Umgang mit den Lösungsmustern im Rahmen der Produktentwicklung zu ermöglichen (identifizieren, speichern, anwenden, erweitern, in Beziehung zueinander setzen). Die in dieser Arbeit adressierten Lösungsmuster für den Systementwurf, deren Strukturierung Gegenstand des vorangegangenen Kapitels ist, besetzen die Schnittstellen zwischen fachdisziplinspezifischen Ansätzen und vereinen diese in geeigneter Art und Weise. Um den Ansprüchen an einen lösungsmusterbasierten Systementwurf gerecht zu werden, wird in diesem Kapitel ein speziell auf die Eigenschaften der Lösungsmuster abgestimmter multidimensionaler Wissensraum vorgestellt. Demnach lassen sich Lösungsmuster, die für den Systementwurf sowie für vor- und nachgelagerte Entwurfsschritte relevant sind, entlang der drei Dimensionen Art der Wissensrepräsentation, Spezialisierung des Lösungswissens und Aggregation des Lösungswissens beschreiben und voneinander abgrenzen. 4.3.3.1 Dimension 1: Art der Wissensrepräsentation Lösungsmuster dienen in erster Linie zur Repräsentation relevanten Lösungswissens. Ein Alleinstellungsmerkmal der im Rahmen dieser Arbeit betrachteten Lösungsmuster für den Systementwurf ist die Darstellung des Lösungswissens. Grundvoraussetzung für eine effiziente Einbindung relevanten Lösungswissens in den Entwurf ist die Repräsentation des Wissens in einer geeigneten Terminologie. Geeignet bedeutet in diesem Fall, dass zum jeweiligen Einsatzzeitpunkt der Lösungsmuster das Wissen analog zur eingesetzten Sprache bzw. Terminologie des zugehörigen Entwurfsschrittes repräsentiert wird. Diesbezüglich lässt sich auf höchster Ebene zwischen textbasierter bzw. dokumentenbasierter und modellbasierter Darstellung unterscheiden (vgl. Bild 4-15). Textbasiert festgehaltene Lösungsmuster haben in der Regel eine längere Historie. Zu erwähnen sind u.a. Wirkprinzipien des Maschinenbaus oder der Elektrotechnik. Auf diese können die Entwickler in Form zahlreicher Konstruktionskataloge zurückgreifen. In der modernen Entwicklung mechatronischer Systeme werden Artefakte des Systems größtenteils durch computerinterne Modelle abgebildet. Beweggründe für die Verwendung von Modellen zum Entwurf und zur Eigenschaftsabsicherung des Systems sind die Kosten- und Zeitersparnisse beim Bau und Test realer Prototypen. Je nach Entwicklungszeitpunkt und Einsatzzweck unterscheiden sich die Modelle hinsichtlich ihres Formalisierungsgrads. Wie die Erläuterung der Entwicklung fortgeschrittener mechatronischer Systeme wie beispielsweise einem CPS in Kapitel 4.2.2.2 verdeutlicht, erfordert eine „Disziplinübergreifende System-Ebene“ die Nutzung semiformaler Modelle. In den darunterliegenden Ebenen, der „Disziplinorientierten Mechatronik-Ebene“ und der „Disziplinintegrierenden Aspektspezifischen-Ebene“, werden hingegen formale Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 117 Modelle genutzt. Diese sind nötig, um spezifische Eigenschaften wie z.B. das dynamische Verhalten von Mehrkörpersystemen zu simulieren und zu analysieren. Bild 4-15: Zusammenhänge zwischen Lösungsmustern für den Systementwurf hinsichtlich „Wissensrepräsentation“ und „Spezialisierung“ Analog zum Formalisierungsgrad der Modelle in der Entwicklung verhält es sich mit den Modellen zur Repräsentation des zugehörigen Lösungswissens. So werden die Informationen in einem Lösungsmuster für den Systementwurf mit Hilfe semiformaler Modelle dargestellt während im Regelungs- oder Softwareentwurf formale Modelle in den Lösungsmustern oder in spezifischen Modellbibliotheken verwendet werden. An dieser Stelle sind die Beziehungen zwischen den unterschiedlichen Ebenen hervorzuheben. Die beispielhafte Erläuterung von Lösungsmustern in den Kapiteln 4.3.2.1 und 4.3.2.2 hat gezeigt, dass Abhängigkeiten untereinander bestehen. So beruht beispielsweise das Lösungsmuster „Elektromotor“ auf dem Wirkprinzip „Lorentz-Kraft“ und das Lösungsmuster „Feedback“ auf regelungstechnischen Prinzipien. Ziel ist es, die Komplexität in den einzelnen Lösungsmustern für den Systementwurf so gering wie möglich zu halten. Hierzu ist es erforderlich, die vorhandenen Beziehungen mehrdimensional abzubilden und die Informationen in einem Lösungsmuster zu fokussieren. kommunizieren Regelschleife Antrieb client 1 client 2 Synchronisation formal semiformal modelbasiert textbasiert generalisiert Spezialisierung des Lösungswissens Art der Wissensrepräsentation spezialisiert Anlage Beobachter Anlage + - Elektrischer Antrieb Komponenten synchronisieren Aufgaben delegieren Feedforward Feedbackward Servoantrieb FaFb a b • • • • NS z.B. Muster der Regelungstechnik oder Softwaretechnik z.B. Wirkprinzipien beruht auf... beruht auf... beruht auf... Seite 118 Kapitel 4 4.3.3.2 Dimension 2: Spezialisierung des Lösungswissens Die zweite Dimension, entlang derer ein Lösungsmuster gegenüber anderen abgegrenzt werden kann, ist die Spezialisierung des Lösungswissens. Dies verdeutlicht das in Bild 4-15 dargestellte Beispiel von Antrieben. So ist ein „Servoantrieb“ beispielsweise ein „elektrischer Antrieb“, der wiederum ein „Antrieb“ ist. Die zweite Dimension ist erforderlich, um die kreative Leistung von Entwicklern bestmöglich zu unterstützen. Je höher der Generalisierungsgrad eines Lösungsmusters, desto weniger verliert sich der Entwickler, insbesondere zu Beginn einer Produktentwicklung, in unnötigen Detailfragen. Die zweite Dimension verläuft daher parallel zur fortschreitenden Konkretisierung im Entwurf.62 Es zeigt sich nach wie vor, dass Entwickler große Schwierigkeiten haben, von bekannten Denkmustern abzuweichen. Sie schaffen es oftmals nicht, z.T. fachfremde Lösungsprinzipien bei der Aufgabenbewältigung mit ins Kalkül zu ziehen. Dies führt dazu, dass sie sich auf bereits erfolgreich eingesetzte Lösungen beschränken und das Innovationspotential durch vorhandene Technologien nicht umfassend ausschöpfen. Aufgrund des hohen Zeit- und Kostendrucks verlassen die Entwickler zu früh eine lösungsneutrale Denkweise und wägen unterschiedliche Lösungskonzepte zu wenig ab. Die im Rahmen dieser Arbeit definierte Dimension zum Spezialisierungsgrad wirkt dem entgegen. Je generalisierter ein Lösungsmuster ist, desto größer ist folglich auch sein Anwendungskontext. Bei der Definition von einem Lösungsmuster bewegt sich der Entwickler i.d.R. vom Spezialisierten zum Generalisierten. Dies verdeutlicht folgendes Beispiel, das in der zuvor genannten Richtung zu interpretieren ist: Ein 6-Achs- Roboter für das Punktschweißen in einer Fertigungslinie vom Audi A8 ist ein 6-Achs- Roboter für das Punktschweißen ist ein 6-Achs-Roboter zum Einsatz in einer Fertigung ist ein 6-Achs-Roboter ist ein Roboter. Ein einheitliches Generalisierungsniveau, das bei der Definition von Lösungsmustern erreicht werden muss, existiert nicht. Die Beziehungen sind vielmehr relativ zueinander zu beschreiben. Ferner entfällt bei dem erarbeiteten Ansatz eine aufwändige Definition einer Klassifikation von Lösungsmustern. Diese resultiert zwangsläufig durch die festgehaltenen Relationen zwischen den Lösungsmustern. Auf diese Weise wird eine Übertragbarkeit des Ansatzes auf unterschiedliche Unternehmen und Branchen sichergestellt. Es handelt sich bei dem Lösungswissen um unternehmensinternes Know-how, was wiederum zu sehr individuellen Lösungsmustern und Beziehungen führen kann. Nach einer entsprechenden rechnerinternen Implementierung des hier vorgestellten Wissensraums, haben die Entwickler die Möglichkeit, sich entlang der Beziehungen von den generalisierten zu den spezialisierten Lösungsmustern zu navigieren. Sie besitzen somit in der frühen Phase der Entwicklung ein möglichst facettenreiches Angebot 62 Vgl. hierzu den Entwurfsraum nach GAUSEMEIER in [GP14, S. 27] Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 119 an generalisierten Lösungsmustern. Je nach Bedarf haben sie zudem die Möglichkeit, spezifisches Lösungswissen hinzuzuziehen. 4.3.3.3 Dimension 3: Aggregation des Lösungswissens Die dritte Dimension im multidimensionalen Wissensraum verdeutlicht Bild 4-16. Für ein besseres Verständnis ist die Ebene der Wissensrepräsentation nicht dargestellt. Wie bereits geschildert liegt der Schwerpunkt auf den Lösungsmustern für den Systementwurf, in denen das Wissen mit Hilfe von semiformalen Modellen abgebildet wird. Es handelt sich bei der dritten Dimension um die Aggregation des Lösungswissens. Diese Dimension orientiert sich u.a. an Erkenntnissen von SUHM (vgl. Kapitel 3.2.3.1). SUHM schlägt vor, komplexe maschinenbauliche Problemstellungen und zugehörige Lösungen in elementare Lösungsmuster zu gliedern. Dies erweitert ihren Einsatzbereich und ihre Anwendbarkeit durch die Entwickler. Dieser Gedankengang wird für z.T. multidisziplinäre Lösungsmuster aufgegriffen und auf diese übertragen. Wie Bild 4-16 zeigt, verläuft die Dimension für die Aggregation des Lösungswissens vom Elementaren zum Komplexen. Elementare Lösungsmuster befinden sich bespielhaft im Vordergrund. Die schemenhaft eingezogenen Ebenen dienen lediglich der besseren Visualisierung der Zusammenhänge und verdeutlichen die wechselseitigen Beziehungen zueinander. Ein Beispiel für ein elementares Lösungsmuster ist die Interaktionsform zweier Softwarekomponenten „Aufgabe delegieren“. Dieses Muster ist zugleich Bestandteil des komplexeren Lösungsmusters „Zusammenarbeit synchronisieren“ (vgl. Kapitel 4.3.2.1). Somit ist die Übertragbarkeit der Überlegungen von SUHM auf die Softwaretechnik gegeben. Ein Beispiel für den Zusammenhang zwischen Maschinenbau und Elektrotechnik ist ein „elektrischer Antrieb“, der wiederum das elementare Lösungsmuster „Presspassung“ enthält. Als Beispiel für ein komplexes Beispiel bestehend aus mehr als einem elementaren Lösungsmuster sind „interagierende Deltaroboter“ zu nennen. Es handelt sich um autark agierende Deltaroboter, die im Verbund eine spezifische Aufgabe erfüllen. Dieses Lösungsmuster setzt sich u.a. zusammen aus den Lösungsmustern „Delta-Kinematik“, „elektrischer Antrieb“ oder auch „Zusammenarbeit synchronisieren“. Der Komplexitätsgrad der Lösungsmuster geht einher mit dem Komplexitätsgrad der zugrundeliegenden (Teil-)Lösungen, die den Ausgangspunkt bei der Definition der Lösungsmuster bilden. So ergeben sich analog zur Gliederung von Systemen und Subsystemen komplexere und elementarere Lösungsmuster. Der Wissensraum bietet Entwicklern die Möglichkeit, Relationen bzgl. des Komplexitätsgrads relativ zueinander festzuhalten. Seite 120 Kapitel 4 Bild 4-16: Zusammenhänge zwischen Lösungsmustern für den Systementwurf hinsichtlich Spezialisierung und Aggregation Die Dimension „Aggregation des Lösungswissens“ unterstützt die beiden typischen Vorgehensweisen im funktionsorientierten Entwurf. Vorausgesetzt der Wissensraum ist mit Lösungsmustern gefüllt und die wechselseitigen Beziehungen sind beschrieben, sind sowohl ein top-down als auch ein bottom-up Suchvorgang möglich. Beim topdown Vorgehen navigiert der Entwickler beginnend bei den komplexen Lösungsmustern durch den Wissensraum. Beim bottom-up Vorgehen startet der Entwickler bei möglichst elementaren Lösungsmustern. 4.3.3.4 Multidimensionaler Wissensraum Zusammenfassend resultiert aus den Erläuterungen von Kapitel 4.3.3.1 bis 4.3.3.3 ein multidimensionaler Wissensraum, der die notwendigen Lösungsmuster für eine Produktentwicklung beinhaltet. Ferner bietet der Wissensraum die Möglichkeit, wechselseitige Beziehungen relativ zueinander abzubilden. Bild 4-17 zeigt den multidimensionalen Wissensraum mit seinen bereits erläuterten Dimensionen. Der Raum ist beispielhaft mit etablierten Ansätzen gefüllt. Vor der Erläuterung wird jedoch kurz auf das Thema der Multidimensionalität eingegangen. Multidimensionalität Aufgrund der zunehmenden Interdisziplinarität in der Entwicklung fortgeschrittener mechatronischer Systeme verschmelzen Disziplingrenzen und zugehörige Sichten wie Interagierende Deltaroboter Servoantrieb Elektrischer Antrieb Komponenten synchronisieren Se rv oa n t ri eb El e k tr i sc h er A n t r ieb K omponente n y synchronisieren synchronisieren generalisiert Spezialisierung des Lösungswissens spezialisiert Aggregation des Lösungswissens elementar komplex ist Teil von... ist Teil von... Delta- Kinematik SW- Koordination Aufgabe delegieren Lagersitz Presspassung Regelschleife Feedforward Feedbackward ist Teil von... Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 121 Struktur, Verhalten oder Gestalt zunehmend. Die in Kapitel 4.3.2 vorgestellten Beispiele verdeutlichen dies. Die im Rahmen dieser Arbeit entwickelte einheitliche Strukturierung von Lösungsmustern wird diesen Gegebenheiten insofern gerecht, da die Aspekte des Musters je nach Schwerpunkt mit Struktur- und/oder Verhaltensmodellen dargestellt werden können. Deshalb werden unterschiedliche Sichten oder Fachdisziplinen nicht explizit differenziert. Sie sind in einer weiteren – nicht visualisierten – Dimension vielmehr als Filter zu interpretieren. Während des Systementwurfs ist es durchaus sinnvoll, den Wissensraum und seine darin enthaltenen Muster nach fachdisziplinspezifischen Aspekten zu filtern, z.B. wenn die Auslegung des dynamischen Verhaltens des Gesamtsystems im Vordergrund steht. Hierbei bietet es sich z.B. an, gezielt nach gestalterischen Aspekten zu suchen, da diese die Dynamik vorrangig beeinflussen können. Im weiteren Verlauf der Entwicklung, wenn von der fachdisziplinübergreifenden in die disziplinorientierte Ebene gewechselt wird, sollte ebenfalls ein Filter bzgl. Fachdisziplinen verwendet werden. Dies erleichtert die Navigation ausgehend von den bereits verwendeten Lösungsmustern auf Gesamtsystemebene. Bild 4-17: Multidimensionaler Wissensraum für Lösungsmuster in der Produktentwicklung Handlungsfeld: Lösungsmuster für den Systementwurf Das Handlungsfeld der Lösungsmuster für den Systementwurf verdeutlicht Bild 4-17. In Bezug zu etablierten Ansätzen zur Wiederverwendung von Lösungswissen und zur Unterstützung des kreativen Entwicklungsprozesses sind die adressierten Lösungsmuster auf der semiformalen Ebene einzuordnen. Eine Ebene höher, nämlich im Bereich der textbasierten Ansätze, befinden sich u.a. TRIZ (vgl. Kapitel 2.4.4) und Wirkprinzipien des Maschinenbaus. Durch das Prinzip der Widerspruchsanalyse und der starken Abstraktion von realen Problemstellungen ist TRIZ auf den Großteil technischer Problemgeneralisiert spezialisiert textbasiert elementar komplex Art der Wissensrepräsentation formal Spezialisierung des Lösungswissens semiformal Aggregation des Lösungswissens Muster nach S ANZ /Z ALEWSKI Koordinationsmuster nach D ZIWOK ET AL . Lösungsmuster nach D UMITRESCU TRIZ Wirkprinzipien des Maschinenbaus Handlungsfeld: Lösungsmuster für den Systementwurf modellbasiert Seite 128 Kapitel 4 gen zur ersten Phase wird davon ausgegangen, dass eine vollumfängliche mechatronische Vorgehensweise bei der Erstellung des Produkts nicht vorliegt. Ist dies jedoch der Fall und es existiert das sog. Systemmodell, kann die Erstellung der erforderlichen Partialmodelle übersprungen werden. Für die Abbildung des Systems und der internen Wirkzusammenhänge wird die Spezifikationstechnik CONSENS eingesetzt. Es werden sowohl die Wirkstruktur als auch die erforderlichen Verhaltensmodelle erstellt. Eine besondere Herausforderung liegt in der Wahl der Modellierungstiefe und der damit einhergehenden Hierarchisierung. Vor allem bei sehr komplexen Systemen bietet sich die Abgrenzung von Subsystemen bzw. logischen Gruppen an, um eine effektive Identifizierung von Lösungsmustern zu ermöglichen. Zusammenfassend wird in der Phase folgendes Hilfsmittel eingesetzt: • Spezifikationstechnik CONSENS (vgl. Kapitel 3.2.1.1) Das Resultat der Phase „Informationsakquisition“ ist ein Systemmodell des zu analysierenden Systems. Es umfasst die Abbildung der Struktur und des Verhaltens sowie deren wechselseitigen Beziehungen. 4.4.2 Phase 2: Systemanalyse Ziel der zweiten Phase ist die Identifizierung von Lösungsmusterkandidaten. Einen ersten Anhaltspunkt bei der Identifizierung von Lösungsmustern liefern dabei mechatronische Funktionseinheiten innerhalb des Systems. Gemäß der Definition von Lösungsmustern erfüllen diese eine bestimmte Funktion, oder Kombination von Funktionen. In einem ersten Schritt der Systemanalyse wird daher eine funktionale Beschreibung des Systems aufgestellt. Dies erfolgt in Form einer Funktionshierarchie. Im Gegensatz zur Erstellung einer Funktionshierarchie mit zunehmender Konkretisierung im Rahmen des Entwurfs beginnt die retrospektive Modellierung nicht bei der Hauptfunktion. Es handelt sich hingegen um ein Bottom-up-Vorgehen. Die Aufnahme der Funktionen orientiert sich dabei an den bereits vorhandenen Strukturierungen im System. Dies sind auf der einen Seite physikalische Module oder Baugruppen und auf der anderen Seite informationsverarbeitende Module bzw. Gruppen von Komponenten. Je nach Hierarchisierung aus Phase 1 werden für die Systemelemente in der Wirkstruktur und in den Verhaltensmodellen die zugehörigen Funktionen aufgenommen. Abschließend erfolgt die Analyse des Systems hinsichtlich funktionaler Zusammenhänge. Im besten Fall existiert eine 1:1-Beziehung zwischen physikalischen und informationsverarbeitenden Modulen, so dass sich mechatronische Funktionseinheiten mit einer übergeordneten Funktion direkt als Lösungsmusterkandidat ableiten lassen. Andernfalls gilt es, funktionale Zusammenhänge zwischen physikalischen und informationsumsetzenden Systemelementen auf Basis der Funktionshierarchie herauszustellen. Zusammenhängende Elemente werden samt Verhaltensbeschreibung und der zugehörigen Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 129 Funktion extrahiert und in die Strukturierung der Lösungsmuster für den Systementwurf überführt. Die für diese Phase erforderlichen Hilfsmittel sind: • Spezifikationstechnik CONSENS (vgl. Kapitel 3.2.1.1) • Einheitliche Strukturierung von Lösungsmustern für den Systementwurf (vgl. Kapitel 4.3.1) Als Resultat der Phase „Systemanalyse“ liegen Lösungsmusterkandidaten vor. Kandidat bedeutet, dass eine Funktion bzw. Kombination von Funktionen als Problembeschreibung vorliegt. Die Lösungsbeschreibung umfasst den zugehörigen Ausschnitt aus der Wirkstruktur und den Verhaltensmodellen. Die Problem- und Lösungsbeschreibung ist folglich zu diesem Zeitpunkt noch nicht generalisiert und der Kandidat kann ggf. verworfen werden. Dies klärt sich in den folgenden Phasen. 4.4.3 Phase 3: Interaktive Analyse Aufbauend auf Phase 2 erfolgt eine interaktive Analyse der Lösungsmusterkandidaten. Diese ist notwendig, da sich in der Regel in den LM-kandidaten langjährige Erfahrung einzelner Entwickler oder Entwicklerteams verbirgt. Verwendete Lösungsmuster in einem Unternehmen sind meist historisch gewachsen und einzelnen Fachdisziplinen zuzuordnen. Die angestrebten Lösungsmuster für den Systementwurf beanspruchen ihren Neuheitsgrad dahingehend, dass sie Lösungsprinzipien der einzelnen Fachdisziplinen in einem übergeordneten Muster vereinen. Je unabhängiger die einzelnen Fachdisziplinen traditionell an abstrakten Lösungskonzepten gearbeitet haben (z.B.: auf Basis von Wirkprinzipien oder Wirkmustern der Softwaretechnik) desto wichtiger wird eine fachdisziplinübergreifende Analyse der zuvor identifizierten LM-kandidaten. Diese muss in interaktiven Diskussionen oder Workshops erfolgen, da die Erfahrung der Mitarbeiter maßgeblich für Definition der Lösungsmuster erforderlich ist. Das erste Analysekriterium sind daher die Beziehungen zu fachdisziplinspezifischen Lösungsprinzipien bzw. -mustern. Diese sind je nach Unternehmen bereits mehr oder weniger ausführlich dokumentiert. Mit Hilfe der im Rahmen dieser Dissertation erarbeiteten charakteristischen Dimensionen von Lösungsmustern werden wechselseitige Beziehungen herausgearbeitet. In einem weiteren Schritt werden die Beziehungen zwischen den Lösungsmusterkandidaten für den Systementwurf untersucht. Dies geschieht zum einen durch die direkte Analyse auf Basis der in Phase 1 erstellten Wirkstruktur. Die bereits spezifizierten Beziehungen zwischen den Systemelementen in der Wirkstruktur geben einen ersten Aufschluss über die Vernetzung der LM-kandidaten. Zum anderen werden die LM- kandidaten hinsichtlich ihrer Beziehungen zueinander in den multidimensionalen Wissensraum überführt. Die Charakterisierung konzentriert sich dabei über die gesamte Phase 3 hinweg an den Dimensionen „Art der Wissensrepräsentation“ und „Aggregation des Lösungswissens“. Folgende Hilfsmittel werden in dieser Phase eingesetzt: Seite 130 Kapitel 4 • Spezifikationstechnik CONSENS (vgl. Kapitel 3.2.1.1) • Einheitliche Strukturierung von Lösungsmustern für den Systementwurf (vgl. Kapitel 4.3.1) • Beziehungen zwischen den Lösungsmustern (vgl. Kapitel 4.3.3) • Multidimensionaler Wissensraum (vgl. Kapitel 4.3.3.4) Das Resultat der Phase „interaktive Analyse“ sind ausgewählte Lösungsmusterkandidaten, die hinsichtlich ihrer Vernetzung untereinander und zu fachdisziplinspezifischen Lösungsmustern analysiert sind. 4.4.4 Phase 4: Dokumentation von Lösungsmustern In einer abschließenden Phase werden die Lösungsmuster für den Systementwurf definiert und dokumentiert. Hierzu sind die detaillierten Informationen aus den Partialmodellen Wirkstruktur, Verhalten und Funktionen in die vorgegebene Strukturierung von Lösungsmustern zu überführen. Ferner sind spezifische Merkmale für das jeweilige Lösungsmuster zu definieren. Während der Definition eines Lösungsmusters und der Überführung von Informationen aus dem Systemmodell in die LM-Struktur wird die dritte Dimension im Wissensraum benötigt. Um die Übertragbarkeit eines Lösungsmusters auf weitere Problemstellungen zu ermöglichen, ist ein gewisser Generalisierungsgrad in der Lösungsbeschreibung erforderlich (vgl. Definition Kapitel 4.2.1). Demzufolge sind die bis dato vorliegenden Informationen in dem Systemmodell auf das zugrundeliegende Problem zugeschnitten. Bei der Aufbereitung der Informationen hin zu einem Lösungsmuster werden diese schrittweise generalisiert. Einen einheitlichen Generalisierungsgrad von Lösungsmustern für den Systementwurf gibt es nicht. Je nach gewünschter Übertragbarkeit auf weitere Problemstellungen ist der Grad individuell zu definieren. Es bietet sich eine schrittweise Vorgehensweise an, bei der die einzelnen Zwischenstufen des Generalisierungsprozesses im Wissensraum relativ zueinander in Beziehung gesetzt werden. Die erforderlichen Hilfsmittel zur Durchführung dieser Phase 4 sind: • Spezifikationstechnik CONSENS (vgl. Kapitel 3.2.1.1) • Einheitliche Strukturierung von Lösungsmuster für den Systementwurf (vgl. Kapitel 4.3.1) • Beziehungen zwischen den Lösungsmustern (vgl. Kapitel 4.3.3) • Multidimensionaler Wissensraum (vgl. Kapitel 4.3.3.4) Das Resultat dieser Phase „Dokumentation von Lösungsmustern“ sind Lösungsmuster für den Systementwurf. Diese sind gemäß der vorgegebenen Strukturierung spezifiziert und im Wissensraum entlang der charakteristischen Dimensionen in Beziehung zueinander gesetzt. Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 131 4.5 Vorgehensmodell für einen lösungsmusterbasierten Systementwurf Gegenstand dieses Kapitels ist ein Vorgehensmodell für einen lösungsmusterbasierten Systementwurf fortgeschrittener mechatronischer Systeme. Im Sinne der VDI2206 wird die Herangehensweise eines funktionsorientierten Entwurfs aufgegriffen. Das Vorgehen wird in der frühen Phase einer Produktentwicklung, dem sog. Systementwurf, eingesetzt. Es konzentriert sich dabei in erster Linie auf die Wiederverwendung etablierten Lösungswissens. Das Vorgehensmodell beschreibt etablierte Entwurfsschritte unter Berücksichtigung der neuartigen z.T. multidisziplinären Lösungsmuster. Eine derart enge Verzahnung ist erforderlich, da der Einsatz von Lösungsmustern nicht losgelöst vom Entwicklungsgeschehen betrachtet werden kann. Werden beispielsweise für bestimmte Problemstellungen keine passenden Lösungsmuster gefunden, müssen neuartige Lösungen durch die Entwickler erarbeitet und mit den übrigen ausgewählten Lösungsmustern kombiniert werden. Das Vorgehensmodell gliedert sich in fünf aufeinanderfolgende Phasen. Bild 4-21 verdeutlicht den Ablauf der Phasen, Aufgaben und Resultate. Bild 4-21: Vorgehensmodell für einen lösungsmusterbasierten Systementwurf Eingangsinformationen sind, in Anlehnung an die Strukturierung nach GAUSEMEIER, Erkenntnisse aus der strategischen Produktplanung (vgl. Kapitel 2.3.1). Ferner sind im Rahmen der Produktentwicklung bereits erste Architekturkonzepte des zu entwickelnden Systems beschrieben. Das Vorgehen für einen lösungsmusterbasierten Systement- Aufgabenbeschreibung Lösungsmuster Konkretisierte Aufgabenbeschreibung Spezialisierte Lösungsmuster Phasen/Meilensteine Aufgaben/Methoden Resultate Initiale Zielbestimmung ●Erstellung des Umfeldmodells ●Defi nition von Anwendungsszenarien ●Defi nition von ersten allgemeinen Anforderungen ●Erstellung einer Funktionshierarchie ●Abgleich zwischen Aufgabenbeschreibung und Lösungsmustern ●Auswahl und Kombination von Lösungsmustern ●Konkretisierung der Anforderungsbeschreibung ●Ggf. Dekomposition von Funktionen ●Abgleich zwischen detaillierter Aufgabenbeschreibung und spezialisierten Lösungsmustern ●Auswahl und Kombination von Lösungsmustern 2 Suche nach Lösungsmustern Konkretisierung der Zielbestimmung Suche nach spez. Lösungsmustern 1 3 4 Prinziplösung ●Erstellung der Wirkstruktur ●Erstellung von Verhaltensmodellen Lösungsmusterbasierte Systemmodellierung 5 Seite 132 Kapitel 4 wurf gliedert sich in insgesamt fünf Phasen. Es beginnt mit einer initialen Zielbestimmung und endet mit einer fachdisziplinübergreifenden Prinziplösung. Innerhalb der einzelnen Phasen werden Hilfsmittel zur Durchführung der Aufgaben angewendet. Es handelt sich z.T. um bestehende Hilfsmittel aus dem Stand der Technik als auch um Neuentwicklungen des vorliegenden Instrumentariums. Bei der folgenden Erläuterung der einzelnen Phasen, Aufgaben und Resultate wird auf den Bezug zu den Hilfsmitteln näher eingegangen und entsprechend in die vorangegangenen Kapitel verwiesen. 4.5.1 Phase 1: Initiale Zielbestimmung Ausgehend von einer im Vorfeld entwickelten Produktstrategie und Architekturkonzeption erfolgt die erste Phase des Vorgehensmodells: Die initiale Zielbestimmung. Die Beschreibung der Phase ist angelehnt an die wiederkehrenden Tätigkeiten im Rahmen einer jeden Produktentwicklung: Zielbestimmung, Synthese, Analyse. Ziel ist eine erste Grundlage, auf der ein interdisziplinäres Entwicklerteam nach potentiellen Lösungsmustern suchen kann. Die Phase klärt folglich die Aufgabenbeschreibung für die weiteren Entwicklungsschritte. Das Abstraktionsniveau ist zu diesem Zeitpunkt noch sehr hoch. Grundgedanke ist es, den Entwicklern auf Basis einer ersten vage formulierten Aufgabe ein möglichst facettenreiches Spektrum an Lösungsmustern anzubieten. Andernfalls ist die bereits skizzierte Gefahr zu hoch, sich in zu diesem Zeitpunkt der Entwicklung in zu spezifischen Details zu verlieren. Zunächst wird das Umfeld des zu entwickelnden Systems analysiert. Es folgt die Definition von Anwendungsszenarien. Auf Basis der erzielten Erkenntnisse und den in der strategischen Produktplanung bereits erarbeiteten Markt- und Kundenanforderungen werden Anforderungen an das technische System spezifiziert. Hierzu werden die i.d.R. sehr abstrakt gehaltenen Anforderungen der strategischen Produktplanung in technische Anforderungen übersetzt. Die Dokumentation geschieht in Form einer Anforderungsliste, gemäß der Strukturierung nach PAHL/BEITZ. Anschließend wird eine Funktionshierarchie abgeleitet. Im Gegensatz zur Funktionsstruktur beinhaltet die Hierarchie keine Aussagen über die Zusammenhänge zwischen den Funktionen, was aus folgendem Grund vorteilhaft ist. Es ist im Verlaufe der ersten Phase des Vorgehensmodells darauf zu achten, die Anforderungs- und Funktionsdokumentation so lösungsneutral wie möglich auszuführen. Dies ist Grundvoraussetzung zur Ausschöpfung des vollen Innovationspotentials in der anschließenden Phase Auswahl von Lösungsmustern. Gelingt dies nicht, legen sich Entwickler unbewusst auf ihnen bekannte Lösungsmuster fest. Zur Durchführung der ersten Phase werden die entsprechenden Partialmodelle und Konstrukte der Spezifikationstechnik CONSENS angewendet. Es wird in erster Linie davon ausgegangen, dass es sich bei dem Entwicklungsgegenstand um eine Neuentwicklung Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 133 handelt. Im Falle einer Anpassungsentwicklung ist sicherzustellen, dass bereits vorliegende Entwicklungsdokumente auf das erforderliche Abstraktionsniveau gebracht werden. Dies kann dann z.B. die Umfeld-, Anforderungs- und Funktionsbeschreibung betreffen. Die Inhalte sind auf den Kern des Entwicklungsgegenstandes zu reduzieren. Je nach Komplexität und Anpassungsfähigkeit des umliegenden Gesamtsystems sind bereits vorhandene Schnittstellen im Umfeldmodell detailliert zu spezifizieren. Ein Beispiel ist die Modifikation einer neuen Scheinwerfergeneration in einem Automobil bei bereits vorgegebenen Umgebungsbedingungen (Bauraum, elektr. Versorgung etc.) Zusammenfassend werden in der Phase initiale Zielbestimmung folgende Hilfsmittel eingesetzt: • Kategorien zur Anforderungsspezifikation nach PAHL/BEITZ [PBF+07] • Spezifikationstechnik CONSENS (vgl. Kapitel 3.2.1.1) Das Resultat der Phase „initiale Zielbestimmung“ ist eine erste Aufgabenbeschreibung. Diese umfasst im Kern eine Anforderungs- und Funktionsbeschreibung auf einem sehr hohen Abstraktionsniveau. 4.5.2 Phase 2: Suche nach Lösungsmustern Ziel einer ersten Suche und Auswahl von Lösungsmustern ist die grobe Einschränkung des zur Verfügung stehenden Suchraums. Auf Basis der Funktionshierarchie lassen sich zwei grundlegende Suchstrategien – Top-Down oder Bottom-Up – durchführen. Beim Top-Down-Ansatz startet die Suche bei der Hauptfunktion. Wird keine Lösung gefunden, werden die einzelnen Ebenen der Hierarchie nacheinander durchlaufen. Zielsetzung ist, möglichst schnell Lösungsmuster mit einem hohen Aggregationsgrad für die vorliegende Entwicklungsaufgabe zu identifizieren. Dies vermeidet zeit- und kostenaufwändige Neuentwicklungen für Systembestandteile, die bereits etabliert sind. Die Bottom-Up-Suchstrategie startet auf der untersten Ebene der Hierarchie und fokussiert die Lösungsalternativen für die einzelnen Teilfunktionen. Dies bietet sich beispielsweise an, wenn für ein bestehendes System eine alternative Umsetzung betrachtet werden soll. Die gefundenen Lösungen ermöglichen in diesem Fall Potentiale für Optimierungen. In dieser zweiten Phase des Vorgehensmodells navigiert das Entwicklerteam auf der Suche nach passenden Lösungsmustern durch den multidimensionalen Wissensraum. Die grundsätzliche Richtung ist dabei immer vom generalisierten zum spezialisierten. Je nach Strategie kann sowohl mit der Suche nach elementaren als auch nach komplexen Lösungsmustern begonnen werden. Bei der Suche werden die in der ersten Phase spezifizierten Anforderungen und Funktionen mit der Problembeschreibung in den Lösungsmustern abgeglichen. Aufgrund der sehr lösungsneutralen Funktionsbeschreibung ist das Suchergebnis zu Beginn sehr vielseitig. Die Anforderungen dienen einer ersten Einschränkung. Der hohe Generalisierungsgrad in den Lösungsmustern unterstützt die Entwickler in ihren kreativen Entwurfsprozessen. Ziel ist es, alle Funktionen mit poten- Seite 134 Kapitel 4 tiellen Lösungsmustern jedweden Generalisierungsgrads zu erfüllen. Dabei kann ein Lösungsmuster 1-n Funktionen erfüllen, dies hängt von seiner Komplexität ab. Für Funktionen, für die kein Lösungsmuster gefunden wird, sind neuartige Konzepte durch die Entwickler zu erarbeiten. Nach Auswahl der Lösungsmuster werden diese in einem morphologischen Kasten gesammelt und auf Kombinierbarkeit geprüft. Dies geschieht auf der Basis von Entwicklerexpertise. Die nachfolgende Aufzählung fasst die benötigten Hilfsmittel zusammen: • Lösungsmuster für den Systementwurf (vgl. Kapitel 4.3.1 und 4.3.2) • Beziehungen zwischen den Lösungsmustern (vgl. Kapitel 4.3.3) • Multidimensionaler Wissensraum (vgl. Kapitel 4.3.3.4) • Morphologischer Kasten [PBF+07] Das Resultat dieser „Suche nach Lösungsmustern“ ist ein morphologischer Kasten, der potentielle Lösungsmuster unterschiedlicher Spezialisierungsniveaus (i.d.R. stark generalisiert) beinhaltet und diesen den zuvor gestellten Funktionen zeilenweise gegenüberstellt. 4.5.3 Phase 3: Konkretisierung der Zielbestimmung Die Auswahl und Kombination von Lösungsmustern in Phase 2 führt in der Regel aufgrund der bereitgestellten Merkmale zu neuen Erkenntnissen bei den Entwicklern. Die Merkmale, die in den ausgewählten Lösungsmustern zugeordnet sind, erfordern eine Konkretisierung der zuvor in Phase 1 spezifizierten Zielbestimmung. Zum einen kann es erforderlich sein, existierende Anforderungen zu konkretisieren oder Restriktionen zu analysieren. Zum anderen können durch die Merkmale neue Anforderungen hinzukommen. Jedes ausgewählte Lösungsmuster liefert dem Entwickler folglich weitere Merkmale, die in die Anforderungsliste für das Gesamtsystem aufgenommen werden müssen. Ein Beispiel, das diesen Zusammenhang verdeutlicht, ist das Lösungsmuster „elektrischer Antrieb“. Dieses wird z.B. auf Basis der Funktion Welle antreiben als geeignetes Lösungsmuster in Phase 2 ausgewählt. Es erfolgt somit zwangsläufig die Festlegung auf die Verwendung von elektrischer Energie anstelle z.B. pneumatischer Energie. Folglich muss die Anforderungsliste in dieser Phase um die Notwendigkeit einer Versorgungsspannung ergänzt werden. Dies wiederum bedingt weitere Anforderungen, etwa Schutz vor Umgebungseinflüssen wie z.B. Feuchtigkeit etc. Ähnlich wie mit den Anforderungen verhält es sich mit der Funktionshierarchie. Die funktionale Beschreibung ist entscheidend für die Problemklärung sowie für ein einheitliches Verständnis unter den Entwicklern. Mit einer Konkretisierung der Anforderungen geht z.T. eine Verfeinerung der Funktionshierarchie einher. Durch eine weitere Hierarchisierung der zu erfüllenden Funktionen kann das gewünschte Systemverhalten disziplinübergreifend konkretisiert werden. So hat die Wahl eines Lösungsmusters Einfluss auf die Anzahl der zu erfüllenden Subfunktionen und bedingt eine erneute Suche. An Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 135 dieser Stelle sei das Beispiel des „elektrischen Antriebs“ zur Verdeutlichung noch einmal aufgegriffen. Die Funktion, auf Basis derer das Lösungsmuster ausgewählt wurde, ist „Welle antreiben“. Potentielle Subfunktionen, die nach Auswahl des Lösungsmusters Verfeinerungsschritte der Funktionshierarchie darstellen, sind z.B. „elektrische Energie in mechanische Energie wandeln“ und „Drehmoment abstützen“. Die letztgenannte Funktion hat wiederum Auswirkungen auf weitere ausgewählte Lösungsmuster bzw. angrenzende Komponenten im Gesamtsystem. Wie bereits erwähnt, handelt es sich bei der Darstellung eines Phasen-Meilenstein- Diagramms um eine idealtypische Darstellung. An dieser Stelle ist darauf hinzuweisen, dass insbesondere die Phasen drei und vier iterativ durchlaufen werden. Die für diese Phase benötigten Hilfsmittel sind: • Spezifikationstechnik CONSENS (vgl. Kapitel 3.2.1.1) • Informationen aus den Lösungsmustern (vgl. Kapitel 4.3.1) Als Resultat der Phase „Konkretisierung der Zielbestimmung“ liegt eine Aufgabenbeschreibung vor, bestehend aus einer konkretisierten Anforderungsliste und Funktionshierarchie. 4.5.4 Phase 4: Suche nach spezialisierten Lösungsmustern Die Suche nach spezialisierten Lösungsmustern verläuft prinzipiell analog zur ersten Suche in Phase 2. Ausgangspunkt ist die in Phase 3 spezifizierte detaillierte Aufgabenbeschreibung. Als weitere Information stehen den Entwicklern die bereits ausgewählten Lösungsmuster zu Verfügung. Diese sind zudem Startpunkt für die Suche nach spezialisierten Lösungsmustern. Im Gegensatz zu untersuchten Ansätzen aus dem Stand der Technik (vgl. Kapitel 3.3.2 und 3.3.3), bietet die geführte Suche einen neuen Ansatz. Die Entwickler werden ab dem Zeitpunkt erster abstrakter Vorstellungen vom System bei der Einschränkung des Suchraums so unterstützt, dass Ihnen zu jedem Zeitpunkt die größtmögliche Anzahl an alternativen Lösungsmustern zur Verfügung steht. Ausgehend von den ausgewählten Lösungsmustern navigieren die Entwickler vom generalisierten zum spezialisierten, um das System im Entwurf weiter zu konkretisieren. Zur Verdeutlichung der geschilderten Zusammenhänge wird an dieser Stelle erneut das Lösungsmuster „elektrischer Antrieb“ verwendet. Ein spezialisiertes Lösungsmuster, das diesem Lösungsmuster oder der Lösungsmusterklasse angehört, ist z.B. das Lösungsmuster „Servoantrieb“. Dieses wiederum steht mit den spezialisierteren Lösungsmustern „Servo-Synchronantrieb“ und Servo-Asynchronantrieb“ in Beziehung. Durch die Definition und die Abbildung derartiger wechselseitiger Beziehungen ist es den Entwicklern möglich, sukzessive den Suchraum einzuschränken oder umgekehrt, bei Ausschluss von Lösungsmustern zu erweitern. Folgende Auflistung gibt einen Überblick über die zu verwendenden Hilfsmittel: Seite 136 Kapitel 4 • Lösungsmuster für den Systementwurf (vgl. Kapitel 4.3.1 und 4.3.2) • Beziehungen zwischen den Lösungsmustern (vgl. Kapitel 4.3.3) • Multidimensionaler Wissensraum (vgl. Kapitel 4.3.3.4) • Morphologischer Kasten [PBF+07] Das Resultat der vierten Phase ist eine Auswahl und Kombination spezialisierter Lösungsmuster. Erstrebenswert ist ein solcher Spezialisierungsgrad, der unmittelbar im Anschluss an den Systementwurf eine Überführung der Informationen in aussagekräftige formale Simulationen ermöglicht. 4.5.5 Phase 5: Lösungsmusterbasierte Systemmodellierung Die abschließende Phase des Vorgehensmodells ist die lösungsmusterbasierte Systemmodellierung. Die Kombination der Lösungsmuster aus Phase 4 markiert den Startpunkt für den Aufbau der Struktur- und Verhaltensmodelle auf fachdisziplinübergreifender Gesamtsystemebene. Jedes ausgewählte Lösungsmuster beinhaltet für die jeweilige Problemstellung generalisierte Informationen, die den Entwickler bei der Synthese unterstützen. Dies führt bei der Modellierung der Partialmodelle zu einer signifikanten Zeitersparnis. Bei der Erstellung der Wirkstruktur werden für jedes Lösungsmuster die bereitgestellten Systemelemente und internen Beziehungen innerhalb eines Musters aus dem Wissensraum abgerufen. In der Regel ist es erforderlich, die bereitgestellten Lösungsmuster auf die jeweils spezifische Problemstellung der Entwicklungsaufgabe zu adaptieren. Dies geschieht sowohl über die Modifikation der Systemelemente als auch über die Modifikation der Flussbeziehungen. Ferner ist es Aufgabe des Entwicklers, die Systemelemente der Lösungsmuster zu einem in sich verträglichen Gesamtsystem zu kombinieren. Gemäß der Spezifikationstechnik und Methode CONSENS sind in Ergänzung zur Wirkstruktur die in Beziehungen stehenden Partialmodelle zu erarbeiten. Dies geschieht analog zur Modellierung der Wirkstruktur mit den generalisierten Verhaltensmodellen (z.B. Verhalten-Zustände) der Lösungsmuster. Die Erstellung der Partialmodelle geschieht im Wechselspiel. Eine Besonderheit stellt das im Rahmen dieser Arbeit entwickelte Partialmodell Verhalten-Sequenz dar. Es bildet eine Ausnahme bei der Verbindung der Systemelemente in der Wirkstruktur durch die Entwickler. So beinhalten die entwickelten Lösungsmuster der Softwaretechnik detaillierte Informationen zu einer bidirektionalen Kommunikation zwischen mindestens zwei Systemelementen. Diese Anteile des Verhaltens werden unmittelbar in die Wirkstruktur integriert. Die Hardware, auf der die Software später ausgeführt wird, ist nicht Teil der Modellierung. Die erforderlichen Hardwarekomponenten werden erst während der nachfolgenden Konkretisierung und tatsächlichen Implementierung ausgewählt. Die erforderlichen Hilfsmittel für die letzte Phase sind: • Spezifikationstechnik CONSENS (vgl. Kapitel 3.2.1.1) Instrumentarium für einen lösungsmusterbasierten Entwurf Seite 137 • Erweiterung von CONSENS um Verhalten-Sequenz (vgl. Kapitel 4.3.2.1) • Informationen aus den Lösungsmustern (vgl. Kapitel 4.3.1) Am Ende der Phase „Lösungsmusterbasierte Systemmodellierung“ liegt als abschließendes Resultat eine fachdisziplinübergreifende Spezifikation des fortgeschrittenen mechatronischen Systems vor. Falls es ist im Rahmen des Entwurfs, aufgrund nicht vorhandener Lösungsmuster, zu Neuentwicklungen gekommen ist, sollten diese im Anschluss an die gesamte Entwicklung gemäß des Vorgehens aus Kapitel 4.4 in den Wissensraum aufgenommen werden.