Interdisziplinäre Konstruktionsmethoden und -prozesse

1 Einleitung

Statistiken der letzten Jahre bestä­tigen eine permanente Veränderung des Produktentwicklungsprozesses [1]. Diese Veränderungen resultieren aus veränderten Marktbedingungen sowie aus neuen Anforderungen an das Produkt aus Kundensicht. Eine Zunahme der Produktkomplexität resultiert einerseits aus deutlich stärkeren „Multi-Market“-Produkten sowie Derivaten und Variantenvielfalt, und andererseits aus dem stetigen Anstieg von Elektronik und Software. Der Einsatz von Elektronik und Software ist in den letzten Jahren stetig gestiegen und liegt beispielsweise in der Automobilindustrie bei etwa 40 %. Wenn mechatronische Komponenten, Produkte oder Systeme nicht nur untereinander kommunizieren, sondern sich auch mit dem Internet der Dinge und Dienste vernetzen, spricht man von Cyber-Physical Systems (CPS) [2, 3] oder cybertronischen Systemen (CTS) [4]. Diese Trends führen zu einem vollständigen Umdenken bei Entwicklungsmethoden, -prozessen und IT-Infrastrukturen für die inter­disziplinäre Produktentwicklung. Dieser „mind shift“ basiert auf organisatorischer und systemtechnischer Unterstützung entlang allen Engineering-Aktivitäten über den gesamten Produktlebenszyklus hinweg, von den frühen Phasen der Anforderungserhebung bis zum Recycling des Produkts über alle Disziplinen (Mechanik, Elektrik/Elektronik, Software und Services) und darüber hinaus über die Grenzen eines Unternehmens entlang der Wertschöpfungskette. Für die disziplinübergreifende Entwicklung von Produkten und Systemen fehlen etablierte, industriell genutzte Methoden, Verfahren und Vorgehensmodelle. Die in den Disziplinen entwickelten heutigen, vollkommen disjunkten Entwicklungsmethoden und -prozesse, führen zu disziplinorientierten Silos, in denen wir ausgebildet werden, denken und arbeiten. Eine Übersicht über disziplinorientierte und mechatronische Vor­gehensmodelle in der Produktentwicklung zeigt Bild 1.

Nach einem kurzen Überblick über aktuelle disziplinspezifische und interdisziplinäre Entwurfsansätze und -standards aus den Bereichen Mechanik, Elektronik, Software, Mechatronik und Systems Engineering werden die Forschungsarbeiten des Lehrstuhls für Virtuelle Produktentwicklung (VPE) der TU Kaiserslautern zum Thema interdisziplinäre Produktentwicklung vorgestellt, welche sich zu einem ganzheitlichen Ansatz zur Entwicklung cyber­tonischer Systeme integrieren lassen.

2 Stand der Technik

Basierend auf einem funktionalen Ansatz wurden in Europa in den 60er und 70er Jahren ganzheitliche Entwurfsmethoden des Maschinenbaus vorgeschlagen. Typische Vertreter waren Franke, Kesselring, Rodenacker und insbesondere Pahl/Beitz [10]. Heutzutage basieren fast alle etablierten Entwurfsmethoden im Maschinenbau auf den Artefakten Anforderung, Funktion, Logik bzw. Wirkstruktur und Prinziplösung sowie auf vier wesent­lichen Prozessschritten – Planung und Klärung der Aufgabe, Konzeption, Ausfüh­rungsentwurf und Detailentwurf. Nach Andreasen [6], French [7], Malmquist und Svensson [8], Ehrlenspiel und Meerkamm [9] sind die wesent­lichen Schritte der Produkt­entwicklung die Definition von Funktionen und deren Realisierung nach prinzipiellen Lösungen. Diese Kon­zepte wurden auch Grundlage der VDI-Richtlinie 2221 [11]. Einen anderen Ansatz stellt das Münchner Konkretisierungsmodell von Ponn/Lindemann [12] dar. Hier spielen die An­forderungen eine besondere Rolle, die alle Konkretisierungsebenen der Lösung (Funktions-, Wirk- und Bau­ebene) beeinflussen.

In der Elektrotechnik und Elektronik (E/E) ergibt sich vor allem auf Grund sehr verschiedener Anwendungsgebiete und eines rasanten Technologiewandels ein breiteres Bild an Konstruktionsansätzen. Ein wesent­liches Klassifikationsmerkmal für die jeweiligen Entwurfsmodelle ist der Grad an Technologieunabhängigkeit. Zu diesen Modellen gehören zum Beispiel der Top-Down- und der Bottom-Up-Entwurf [5, 13] sowie das daraus hervorgegangene Jo-Jo-Modell. Zu den bekanntesten technologieunabhängigen Modellen zählt das durch Gajski und Kuhn entwickelte Vorgehens­modell, auch als Y-Diagramm bekannt [14]. Es beschreibt die Sichtweisen im Hardwareentwurf, insbesondere für die Entwicklung von integrierten Schaltkreisen in den Domänen Verhalten, Struktur, und Geometrie. Die Domänen sind als Achsen des „Y“ dar­gestellt. Ein weiterer pragmatischer Ansatz für den Entwurfsprozess integrierter Schaltungen wurde von Lienig ent- wickelt [15].

Im Bereich der Softwareentwicklung zeigen Entwicklungsmethodiken ähnlich der Vorgehensweise in der Elektronik häufig andere Muster – etwa neben der Funktions- eine starke Verhaltensorientierung [16]. Mit dem Ziel die Softwareentwicklung produktiver und effizienter zu gestalten, wurden unter dem Begriff „Software Engineering“ mehrere phasenorientierte Modelle entwickelt, die den Softwaredesignprozess unterstützen [17], zum Beispiel das Wasserfall-, Prototyp- oder Spiralmodell. Boehm führte 1979 einen Designansatz ein, dessen Konzept sich heute in Ansätzen aller Arten von Ingenieurdomänen durchgesetzt hat – das V-Modell [18]. Aufgrund des hohen Aufwands und der schwierigen Repro­duzierbarkeit bei der Erstellung und Pflege komplexer Software erfolgt die Entwicklung zu den genannten Ansätzen in einem strukturierten, streng phasenorientierten und hoch formalisierten Verfahren, wobei der Entwicklungsprozess in überschaubare, zeitlich und inhaltlich begrenzte Phasen unterteilt wird. Durch die Entwicklung von objektorientierten und modell­getriebenen Konzepten im Software Engineering entstand die Unified Modeling Language (UML). Designprozesse, die die Fähigkeiten dieser Konzepte nutzen, sind der Unified Software Development Process (USDP) [19] und der Rational Unified Process (RUP) [20]. Designansätze, die auf schnelle Implementierung und Flexibilität während des Designprozesses abzielen und nicht auf spezifischen Designprozeduren basieren, nennt man agile Softwareentwicklungsansätze [21].

Der Begriff Mechatronik wurde erstmals 1969 von Ko Kikuchi [22] verwendet. Anfänglich bezog sich der Begriff nur auf die elektrotechnische und elektronische Funktionserweiterung mechanischer Bauteile und Geräte. Die Software hat ihre Bedeutung in der Mecha­tronik erst viel später gewonnen [16]. Mechatronische Designansätze basieren auf einem allgemeinen Verständnis des Designprozesses [23], auf dem mechanischen Designprozess von Pahl und Beitz [24] oder auf Varia­tionen des V-Modells [25][26]. Der etablierteste Ansatz ist die Designrichtlinie VDI 2206 [27].

Parallel wurde seit den 60er Jahren insbesondere bei der amerikanischen Luft- und Raumfahrt und in großen Militärprojekten Systems Engineering (SE) als interdisziplinärer, dokumentengetriebener Ansatz zur Entwicklung und Umsetzung komplexer, technischer Systeme und Projekte eingeführt. Systems Engineering beruht auf der Annahme, dass ein System in Hinsicht auf seine Funktionalität mehr ist als die Summe seiner Subsysteme, und dass aus diesem Grund der Fokus not- wen­digerweise auf die Betrachtung der Gesamt­zusammenhänge gelegt werden sollte. Nach den Vorgaben der INCOSE ist das Systems Engineering eine Disziplin, deren Aufgabe die Erstellung und Ausführung eines interdisziplinären Prozesses ist, der garantieren soll, dass Kunden- und Stakeholder-Anforderungen qualitativ hochwertig, zuverlässig, kostengünstig und in vorgegebener Zeit über den gesamten Produktlebenszyklus erfüllt werden können [28]. Mehrere Standards definieren den SE-Prozess (IEEE 1220 [29], ANSI / EIA 632 [30]; ISO / IEC 15288 [31]). Weitere Entwicklungs- ansätze des Systems Engineering, welche in der Industrie und Forschung Beachtung gefunden haben sind der Harmony-SE-Ansatz des Softwareanbieters IBM [32], die Object-Oriented Systems Engineering Method (OOSEM) [33], die Vitech Model-based Systems En­gineering Methodology [34], die JPL State Analysis [35], die Object-Process Methodology [36], das Zackman Frame­work [37] oder der Rational Unified Process for Systems Engineering (RUP SE) [38], welcher sich aus dem Rational Unified Process [19] der Soft­ware­entwicklung ableitete.

Während klassische Methoden des Systems Engineering dokumenten- basiert sind, ermöglicht Model-Based Systems Engineering (MBSE) als Weiterführung des Systems Engineering, ein Entwicklungskonzept, welches auf die Integration von Modelle entlang des Systemlebenszyklus setzt [33]. Es basiert insbesondere auf entwicklungsphasenspezifischen, digitalen Systemmodellen, die entlang des Produkt­entwicklungsprozesses erstellt und integriert werden. Das Problem der Integration der Komponenten während des Entwicklungsprozesses kann durch die Verwendung formaler Modellierungssprachen möglichst früh in Angriff genommen werden, indem die Korrelationen zwischen Systemanforderungen, Funktionen, Verhalten und Struktur definiert werden. Eine Vielzahl dieser MBSE-Ansätze konzentriert sich insbesondere auf die Spezifikation der Systemarchitektur in der frühen Entwicklungsphase. Die Ansätze sind entweder auf die Anwendung der Systems Modeling Language (SysML) ausgelegt [39], wurden hinsichtlich einer Nutzung der SysML angepasst [40, 41] oder nutzen eine Modellierungs- sprache, welche sich aus der SysML ableitet [42, 43]. Die durchgängige, modell­basierte Entwicklung ist in der virtuellen Produktentwicklung von zentraler Bedeutung und ist somit auch eine wesent­liche Herausforderung an die Optimierung des PEP für mechatro­nische und insbesondere für cybertronische Produkte beziehungsweise Systeme. Dies umfasst sowohl die Inte­gration der Modelle der verschiedenen Entwicklungsphasen als auch die Integration der Modelle zur Überwachung und Analyse der operativen Nutzung des Systems (Digital Master, Digital Twin).

Zusammenfassend kann festgestellt werden, dass Ansätze für die Gestaltung interdisziplinärer und stark vernetzter Systeme existieren (vgl. Bild 1), aber je nach Forschungsrichtung immer noch eine starke Disziplin­orien­tierung aufweisen [44]. Aktuelle interdisziplinäre Entwurfsansätze und -konzepte, welche auf dem MBSE-­Gedanken basieren, bilden eine hervorragende Grundlage für die Entwicklung solcher Systeme, müssen jedoch neu überdacht und erweitert werden, um die komplexen Anforderungen zu erfüllen. Insbesondere können hier die Integration von Disziplinen – auch der vierten Disziplin, der Dienstleistung – das Management von Systeminfor­mationen über den gesamten Lebenszyklus ( Digitalisierung der Prozesskette bis hin zum Digital Twin als eine Basis Service-orientierter Geschäftsmodelle) sowie die Gewährleistung einer kon­tinuierlichen Entwicklung ohne Medienbrüche und Informationsverlust genannt werden.

3 Entwicklungsmethoden und Prozessmodelle für das Engineering

Der Lehrstuhl für Virtuelle Produktentwicklung (VPE) der Technischen Universität Kaiserslautern (TUK) beschäftigt sich mit der Entwicklung und Integration neuer Methoden, Prozesse und IT-Architekturen zur Unterstützung der Entwicklung integrierter, inter­disziplinärer und vernetzter Sys­teme. Um die steigende Komplexität dieser Systeme zu beherrschen und Durchgängigkeit sowie Rückverfolgbarkeit über alle Phasen des Lebens­zyklus zu gewährleisten, sind im Rahmen der Forschungsaktivitäten des Lehrstuhls mehrere aufeinander aufbauende Vorgehensmodelle in den letzten Jahren entstanden, die im Folgenden kurz vorgestellt werden.

3.1 MVPE-Modell

Das MVPE-Modell [45] basiert auf dem interdisziplinären V-Modell der VDI-Richtlinie 2206 [27]. Es erweitert das systematische Vorgehen zur Entwicklung mechatronischer Systeme um Aspekte des Model-based Systems Engineering (MBSE) sowie um ein System Lifecycle Management (SysLM)- Konzept zur Verwaltung der entstehenden Daten entlang des gesamten Lebenszyklus (Bild 2).

Die Erweiterung um Aspekte des MBSE betrifft insbesondere die linke Seite des V-Models. Diese lässt sich aus Sicht der Modell­bildung in die drei Abschnitte Modell­bildung und Spezifikation, Modell­bildung und erste Simulation sowie Disziplinspezifische Modellbildung unterteilen. Parallel zu diesen überlappenden Ebenen werden Informationsartefakte beziehungsweise Modell­objekte, die in den Autorensystemen und -sprachen modelliert werden, in Anforderung (A), Funktion (F), Element der logischen Architektur (L) und Element der physikalischen Ausprägung (P) unterteilt. Durch seman-tische Links zwischen den Modellierungselementen kann sowohl eine „horizontale“ als auch eine „vertikale“ Rück­verfolgbarkeit sichergestellt werden. Die „vertikale“ Rückverfolgbarkeit erfolgt durch die hierarchische Untergliederung von Systemelementen. Die Verknüpfung zwischen den Modell­typen (A-F-L-P) erlaubt eine „hori­zontale“ Rückverfolgbarkeit über die System­spezifikationsphasen [45]. Das MVPE-­Modell ist ein übergeordnetes Vorgehensmodell, das seinen Schwerpunkt auf die Prozessebene und die IT-Architektur legt. Es enthält aber auch konstruktionsmethodische Anknüpfungspunkte.

Die Erweiterung des V-Modells umfasst darüber hinaus die Verwaltung lebenszyklusrelevanter Systeminformationen ab der ersten Phase der Produktentwicklung sowie zusätzliche Inte­grations- und Absicherungsäste, die nur auf digitalen Modellen basieren. Die Integration und Verwaltung der entstehenden Informationen aus der Produktentwicklung sowie allen wei­teren Phasen des Lebenszyklus erfolgt über einen sogenannten System Life­cycle Management Backbone [45].

3.2 mecPro² Modellrahmenwerk

Im Rahmen des Forschungsprojektes mecPro² – Modellbasierter Entwicklungsprozess cybertronischer Produkte und Produktionssysteme [4] – wurde eine Beschreibungssystematik ent­wickelt, welche unter Verwendung der Modellierungssprache SysML das Ziel verfolgt, schrittweise die Zusammenhänge cybertronischer Systeme in einem Systemmodell abzubilden. Inner­halb der mecPro² Beschreibungssystematik bildet das mecPro²-Modellrahmenwerk (Bild 3, linke Seite) das Grundgerüst, entlang dessen das zu entwickelnde technische System beschrieben wird.

Der Aufbau des Modellrahmenwerks basiert dabei auf den Grundgedanken ausgewählter Entwicklungsmethoden [12, 45, 47] verschiedenster Disziplinen [39].

Das entstehende Systemmodell bildet den Kern der Systemspezifikation und dient als Bindeglied zu den disziplin-spezifischen Partialmodellen. Die Beschreibung des technischen Systems erfolgt über mehrere Ebenen mit zunehmender Lösungskonkretisierung. Die Ebenen sind dabei entlang der drei Achsen Detaillierung, Konkretisierung und Variabilität angeordnet. Die Achse der Detaillierung umfasst die Informationsanreicherung des Systemmodells ohne Einschränkung des Lösungsraums. Ist eine weitergehende Detaillierung ohne Lösungskonkretisierung jedoch nicht mehr möglich, erfolgt der Übergang auf eine tiefere Ebene. Da die Lösungskonkretisierung im Regelfall nicht ohne die Betrachtung von Alternativen erfolgen sollte [12], tritt hier zwangsläufig auch die dritte Achse der Variabilität zum Vorschein [39].

Das Modellrahmenwerk lässt sich zudem in einen Anforderungs- und einen Lösungsraum unterteilen. Der Anforderungsraum wird durch die Kontextebene abgedeckt und dient der Systemanalyse. Neben der Übersetzung und Synchronisation von natürlichsprachlichen und modellbasierten Anforderungen, erfolgt hier vor allem auch die Betrachtung des zu entwickelnden technischen Systems hinsichtlich der variierenden Kontexte, in dem es als Teil eines oder mehrerer cybertro­nischer Systeme eingesetzt werden kann. Der Lösungsraum umfasst die nachfolgenden drei Ebenen und dient dem Systemdesign. Die Funktions­ebene dient dabei der Erzeugung einer lösungsneutralen Beschreibung der Systemfunktionalität in Form einer funktionalen Systemarchitektur. Die Wahl des Konzepts zur Realisierung der gewünschten Systemfunktion erfolgt entlang der Prinzip- und technischen Lösungsebene. Während auf der erst­genannten Ebene das wesentliche Prinzip, also die Grundidee, zur Realisierung einer Funktion bestimmt wird, erfolgt auf der letzteren Ebene die Wahl der technischen Umsetzung dieser Idee.

3.3 Systemkonkretisierungsmodell nach Pfenning

Das Systemkonkretisierungsmodell (SKM) [46] (Bild 3, rechte Seite) baut wie das mecPro²-Modellrahmenwerk ebenfalls auf dem Münchner Produktkonkretisierungsmodell (MKM) nach Lindemann/Ponn auf [12], um hier vor allem das Konzept der Abstraktionsebenen, der orthogonalen Positionierung des Anforderungsraumes auf den Lösungsraum und die generelle Drei­dimensionalität zur Realisierung der grafischen Einordnung der Achsen Zerlegen/Zusammenfügen, Variieren/Einschränken und Abstrahieren/Konkretisieren zu verwirklichen.

Darüber hinaus übernimmt es aus anderen disziplinspezifischen Vorgehensmodellen Konzepte, wie den Verifika­tionsraum, um der rechten Seite des V-Modells gerecht zu werden und einen Raum für ausführbare Modelle (Simulationsmodelle) zu schaffen. Zum anderen erkennt es wie im MBSE oder auch im Vorgehensmodell nach Gajski [14] an, dass auf jeder Ebene sowohl Struktur (Architektur) als auch Ver­halten beschrieben werden kann. Der Lösungsraum als solcher ist in UML/SysML beschrieben. Das SKM sieht zudem explizit die Verwendung von Modelltransformationen aus dem System­modell in Simulationsmodelle (akausale und kausale 1D-Simulation) vor. Neben der Tatsache, dass es sich beim SKM um ein interdisziplinäres Makrovorgehensmodell handelt, versucht es zudem eine Überführungsmöglichkeit aus feingranularen Graphen (Systemmodell) in einen eher grobgranularen AFLPT-Graphen (Anforderungen, Funktionen, Logische Elemente, Physische Elemente und Testfälle) zu verwirklichen. Hierzu werden sogenannte Zwischenartefakte eingeführt, die in MBSE-spezifischen Modellierungsmethoden auftauchen und methodisch die Lösungsfindung auf allen Ebenen des SKMs und bei deren Übergang unterstützen. Diese Zwischenartefakte werden allerdings nicht wie die übrigen Lösungselemente (auch Ankerelemente genannt) in den PLM-Backbone übertragen, welcher eine rein aus AFLPT bestehende Ontologie vorsieht.

3.4 Vergleich der Ansätze und Ausblick

Wie in Bild 3 zu sehen, verfügen das mecPro²-Modellrahmenwerk und das SKM über eine große Menge an Anknüpfungs­punkten zum MVPE-­Modell. Bei den ersteren beiden ist vor allem die Aufteilung des Modells in einen Anforderungs- und einen Lösungsraum zu nennen, wobei ins­besondere der Lösungsraum sich bei beiden Ansätzen in einen dreidimensionalen Raum entlang der Achsen zur Konkretisierung und Detaillierung des Systems sowie der Darstellung und Betrach­tung von Lösungsvarianten aufspannen lässt. Beide Ansätze ver­folgen wie auch das MVPE Modell den A-F-L-P-Ansatz, jedoch auf unter­schied­lichen Detaillierungsstufen. Während das SKM und das MVPE-Modell den Ansatz 1:1 abdecken, befindet sich das mecPro²-Modellrahmenwerk auf einer detaillierteren Ebene. Zum einen werden die Anforderungen auf der Kontextebene aus einer natürlichsprachlichen Form in eine modell­basierte überführt und zum anderen ist der Findungsprozess der logischen Lösun­gen über die Prinzip- und tech­nische Lösungsebene gestreckt. Die physische Ausgestaltung der logischen Lösungen stand jedoch nicht mehr im Fokus des Forschungsprojektes und ist somit genau so wenig im Modell­rahmenwerk zu finden, wie der Veri­fikationsraum des SKM, welcher wiederum die rechte Seite des „V“ des MVPE-Models abdeckt. Allgemein ist anzumerken, dass sowohl das mecPro²- Modell­rahmenwerk als auch das SKM das zu entwickelnde System eher hinsichtlich des Problemlösungsprozesses und aus einem methodischen Blickwinkel betrachten, während das MVPE-Modell den Fokus mehr auf die übergeordneten Prozessschritte und die oberste Ebene der IT-Architektur über den gesamten Lebenszyklus legt.

Aufgrund der großen Schnittmenge der Entwicklungsansätze entstand am Lehrstuhl für Virtuelle Produkt- entwicklung die Idee, diese in einem ganzheitlichen Ansatz – der „^VPESystemDevelopment_Methodology“ – für die Entwicklung cybertronischer Systeme zusammenzuführen. Während das MVPE-Modell im Sinne der Definition einer Systems Engineering Methodologie nach Martin [48] für die Darstellung des Prozesses übernommen werden kann und lediglich hinsichtlich der Lebens­zyklusphasen heutiger tech­nischer Systeme angepasst wird, verschmelzen das mecPro²-Modell­rahmenwerk sowie das SKM nach Pfenning zum Kaiserslauterner Systemkonkretisierungsmodell (KSKM), welches den methodischen Support des Prozesses insbesondere während der Systementwicklung bereitstellt. Die toolseitige Unterstützung und Umsetzung von Prozess und Methode erfolgt entlang des Fünf-Ebenen-IT-Architektur-Konzepts zur Bildung eines digi­talen Modells in der Unternehmens-­IT-Architektur [49][50]. Bild 4 zeigt die wesentlichen Bestandteile der neuen ^VPESystemDevelopment_Methodology.

Eine detaillierte Beschreibung dieses ganzheitlichen Ansatzes zur Entwicklung und Verwaltung cybertronischer Systeme über alle Phasen des Lebens­zyklus, sowie eine detailliere Beschreibung des Zusammenspiels der einzelnen Komponenten erhalten Sie im zweiten Teil dieses Artikels.

Literatur

[1] Porter, M; Heppelmann, J.: Wie smarte Produkte den Wettbewerb verändern. In: Harvard-Business-Manager – das Wissen der Besten. Jhrg. 36, HeftNr.. 12 (2014), S. 34–60. – ISSN: 0945–6570.

[2] Lee, E. A.: Cyber Physical Systems: Design Challenges. Technical Report No. UCB/EECS-2008–8, University of California, Berkeley, 2008

[3] Broy, M.: Cyber-Physical Systems – Innovation durch softwareintensive eingebettete Systeme. Springer-Verlag, Berlin, 2010

[4] Eigner, M.; Koch, W.; Muggeo, C.: Modellbasierter Entwicklungsprozess cybertronischer Systeme. Springer, Berlin, 2017

[5] Ponn, J.; Lindemann, U.: Konzeptentwicklung und Gestaltung technischer Produkte – Systematisch von Anforderungen zu Konzepten und Gestaltlösungen. Springer, Berlin, 2011

[6] Andreasen, M.M.: Machine Design Methods Based on a Systematic Approach. Ph.D. Thesis, Lund University, 1980

[7] French, M. J.: Conceptual design for engineers. Springer, London, 1999

[8] Malmqvist, J.; Svensson, D. (Hrsg.): A Design Theory Based Approach Towards Including QFD Data In Product Models. Proceedings of the 1999 ASME Design Engineering Technical Conferences. Las Vegas, Nevada, USA, 1999

[9] Ehrlenspiel, K.; Meerkamm, H.: Integrierte Produktentwicklung. Carl Hanser, München, 2013

[10] Pahl, G.; Beitz, W.: Konstruktionslehre. Springer Vieweg, Berlin, 1977

[11] VDI 2221 – Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte. Beuth, Berlin, 1994

[12] Ponn, J.; Lindemann, U.: Konzeptentwicklung und Gestaltung technischer Produkte – Systematisch von Anforderungen zu Konzepten und Gestaltlösungen. Springer-Verlag, Berlin, Heidelberg, 2011

[13] Rauscher, R.: Entwurfs­methodik hochintegrierter anwendungsspezifischer digitaler Systeme. Pro-Universitate-Verlag, Sinzheim, 1996

[14] Gajski, D.D.; Abdi, S.; Gerstlauer, A.; Schirner, G.: Embedded system design. Springer, Boston, 2009

[15] Lienig, J.: Layoutsynthese elektronischer Schaltungen – Grundlegende Algorithmen für die Entwurfsautomatisierung. Springer Berlin Heidelberg, 2006

[16] Andreasen, M. M.: Vorgehensmodelle und Prozesse für die Entwicklung von Produkten und Dienstleistungen. In: (Schäppi, B.; Andreasen, M. M.; Kirchgeorg, M.; Radermacher, F. J. Eds.): Handbuch Produktentwicklung, Carl Hanser, pages 247–263, München, 2005

[17] Pomberger, G.; Pree, W.: Software-Engineering. Carl Hanser, München, 2004

[18] Boehm, B.W.: Guidelines for Verifying and Validating Software Requirements and Design Specifications. Proceeding of the ‚ 79 Euro IFIP Conference, London, September 25–28, North-Holland Pub. Co. Amsterdam, 1979

[19] Rumbaugh, J.; Jacobson, I.; Booch, G.: The Unified Modeling Language Reference Manual, Pearson Education, 2010

[20] Kruchten, P.: The rational Unified Process (Addison-Wesley object technology series). Addison-Wesley, Reading, 1999

[21] Beck, K.; Andres, C.: Extreme Programming Explained: Embrace Change, 2nd Edition. Addison-Wesley Professional, 2005

[22] Harashima, F.; Tomizuka, M.; Fukuda, T.: Mechatronics – What Is It, Why, and How? An editorial, IEEE/ASME Transactions on Mechatronics, Vol. 1 No. 1, 1996

[23] Isermann, R.: Mechatronische Systeme. Grundlagen. Springer, Heidelberg, 2008

[24] Gausemeier, J.; Lückel, J.: Entwicklungsumgebungen Mechatronik: Methoden und Werkzeuge zur Entwicklung mechatronischer Systeme. Heinz Nixdorf Institut, Paderborn, 2000

[25] Bender, K.: Embedded Systems – qualitätsorientierte Entwicklung. Springer, Heidelberg, 2005

[26] Nattermann, R.; Anderl, R.: Approach for a Data-Management-System and a Proceeding-Model for the Development of Adaptronic Systems. Proceedings of the IMECE2010, Vancouver, Canada, ASME, New York, 2010

[27] VDI 2206: Entwicklungsmethodik für mechatronische Systeme – Design methodology for mechatronic systems. Beuth, Berlin, 2004

[28] INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. Wiley, New Jersey, 2015

[29] IEEE 1220–2005 – IEEE Standard for Application and Management of the Systems Engineering Process. IEEE, New York, N.Y., 2011

[30] ANSI/EIA 632: Processes for Engineering a System. SAE International, USA, 2003

[31] ISO/IEC/IEEE 15288:2015 Systems and Software Engineering –System Life Cycle Processes. 2015

[32] Hoffmann, H.: Systems Engineering Best Practices with the Rational Solution for Systems and Software Engineering – Deskbook Release 4.1 – Mod-el- Based Systems Engineering with Rational Rhapsody and Rational Harmony for Systems Engineering. IBM Corporation, 2011

[33] Friedenthal, S.; Moore, A.; Steiner, R.: A Practical Guide to SysML. Morgan Kaufmann, 2012

[34] Long, J.E.: Systems Engineering (SE) 101 – CORE^®: Product & Process Engineering Solutions. Vitech training materials, Vitech Corporation, Vienna, VA, 2000

[35] Estefan, J.: Survey of Model-Based Systems Engineering (MBSE) Methodologies. INCOSE MBSE Initiative, http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf

[36] Dori, D.: Model-Based Systems Engineering with OPM and SysML. Springer Science+Business Media, New York, 2016

[37] Zachman, J.A.: A framework for information systems architecture. In: IBM Systems Journal, 26, pages 276–292, 1987

[38] Cantor, Murray: Rational Unified Process for Systems Engineering, RUP SE Version 2.0. IBM Rational Software white paper, IBM Corporation, 2003

[39] Eigner, M.; Dickopf, T.; Schulte, T.; Schneider, M.: mecPro² – Entwurf einer Beschreibungssystematik zur Entwicklung cybertronischer Systeme mit SysML. In: (Schulze, S.-O.; Muggeo, C. Eds.): Tag des Systems Engineering 2015. Hanser, Munich, 2015

[40] Gabrisch, S.; Tenbergen, B.: SPES2020 – Zusammenfassendes Deliverable D2.1C: SysML Profil für Enterprise Architect zur Modellierung modellbasierter Anforderungen im SPES – Requirements View. http://spes2020.informatik.tu-muenchen.de/results/D2.1.C.pdf

[41] Iwanek, P.; Kaiser, L.; Dumitrescu, R.; Nyßen, A.: Fachdisziplinübergreifende Systemmodellierung mechatronischer Systeme mit SysML und CONSENS. In: Maurer, M., Schulze, S.-O. (Eds.), Tag des Systems Engineering, Stuttgart, November 6–8, 2013, pages 337–346, Carl Hanser Verlag, München, 2013

[42] Grundel, M.; Abulawi, J.; Moeser, G.; Weilkiens, T.; Scheithauer, A.; Kleiner, S.; Kramer, C.; Neubert, M.; Kümpel, S.; Albers, A.: FAS4M – No more: “please mind the gap!” In: Maurer, M., Schulze, S.-O. (Eds.), Tag des Systems Engineering, Bremen. November 12–14, 2014, pages 65–74, Carl Hanser Verlag, München, 2014

[43] Roques, P.: MBSE with the ARCADIA Method and the Capella Tool. ERTS² 2016 – 8th European Congress on Embedded Real Time Software and Systems. Toulouse France, January 27–29, 2016

[44] Gausemeier, J.; Dumitrescu, R.; Steffen, D.: Systems Engineering in industrial practice. Paderborn, 2015

[45] Eigner, M.; Roubanov, D.; Zafirov, R. Hrsg.: Modellbasierte Virtuelle Produktentwicklung. Springer Vieweg, 2014

[46] Pfenning, M.: Durchgängiges Engineering durch die Integration von PLM und MBSE. Schriftenreihe VPE, TU Kaiserslautern, 2017

[47] Pohl, K. et al.: Model-Based Engineering of Embedded Systems. The SPES 2020 Methodology. Springer-Verlag, Berlin, Heidelberg, 2012

[48] Martin, J.N.: Systems Engineering Guidebook: A Process for Developing Systems and Products. Lucent Technologies, 1997

[49] Eigner, M.; Stelzer R.: Product Lifecycle Management – Ein Leitfaden für Product Development und Life Cycle Management. Springer-Verlag, Berlin, Heidelberg, 2009

[50] Eigner, M.; Dickopf, T.; Apostolov, H.: System Lifecycle Management – An Approach for Developing Cybertronic Systems in Consideration of Sustain-ability Aspects. In: Takata et al. (Eds.), Procedia CIRP – The 24th CIRP Conference on Life Cycle Engineering, Kamakura, Japan, March 8–10, 2017, pages 128–133, Elsevier Procedia, 2017