Entwicklung und Implementierung einer Softwarearchitektur zur automatisierten Leitungssatzgenerierung Von der Fakultät für Luft- und Raumfahrttechnik und Geodäsie der Universität Stuttgart zur Erlangung der Würde eines Doktors der Ingenieurwissenschaften (Dr.-Ing.) genehmigte Abhandlung vorgelegt von Dipl.-Ing. Roland Weil geboren in Mainz Hauptberichter: Priv.-Doz. Dr.-Ing. Stephan Rudolph Mitberichter: Prof. Dr.-Ing. Björn Annighöfer Mitberichter: Prof. Dr.-Ing. Jörg Franke Tag der mündlichen Prüfung: 16.09.2024 Institut für Flugzeugbau Universität Stuttgart 2024 Danksagung Die vorliegende Dissertation ist das Ergebnis vieler Jahre intensiver Forschung und per- sönlicher Hingabe, die ohne die Unterstützung zahlreicher Menschen und Organisationen nicht möglich gewesen wäre. An dieser Stelle möchte ich all denen danken, die mich auf diesem Weg begleitet und unterstützt haben. Mein besonderer Dank gilt zunächst meinem Betreuer Priv.-Doz. Dr.-Ing. Stephan Rudolph, der mich stets mit seinem wertvollen Feedback und seinem unermüdlichen Engagement unterstützt hat. Ohne seine fachliche Anleitung und seine motivierenden Ratschläge wäre diese Arbeit nicht möglich gewesen. Ebenso danke ich den beiden Mitberichterstattern Prof. Dr.-Ing. Björn Annighöfer vom Institut für Luftfahrtsysteme (ILS) der Universität Stuttgart und Prof. Dr.-Ing. Jörg Franke vom Lehrstuhl für Fertigungsautomatisierung und Produktionssystematik (FAPS) der Friedrich-Alexander-Universität Erlangen-Nürnberg für ihre Zeit und ihren Einsatz bei der Begutachtung dieser Dissertation. Ein herzliches Dankeschön geht an meine Kolleginnen und Kollegen der Ingenieurge- sellschaft für intelligente Lösungen und Systeme mbH (IILS mbH), am Institut für Flug- zeugbau (IFB) und dem Institut für Statik und Dynamik der Luft- und Raumfahrtkonstruk- tionen (ISD) der Universität Stuttgart. Mein besonderer Dank gilt Peter Arnold, Marcel Anselment, Johannes Beichter, Dr.-Ing. Michael Bölling, Julian Borowski, Jonas Braiger, Christian Butz, Johannes Bürkle, Marc Eheim, Jürgen Freund, Dr.-Ing. Johannes Groß, Nico Hahn, Simon Heimbach, Stefan Hess, Dennis Kaiser, Felix Löser, Dr.-Ing. Christian Messe, Dr.-Ing. Martin Motzer, Moritz Neumaier, Dr.-Ing. Marius Riestenpatt genannt Richter, Jens Schmidt, Dr.-Ing. Claudia Schopper, Dr.-Ing. Dominik Schopper, Prof. Dr.- Ing. Markus Till, Christopher Voss und Hannes Wellmann, die mit ihrem Fachwissen und ihrer freundschaftlichen Unterstützung wesentlich zum Gelingen dieser Arbeit beigetragen haben. Ein herzliches Dankeschön gilt auch meinen Studentinnen und Studenten, insbe- sondere an Sebastian Böhme, Jonathan Bohn, Nikolai Hoffmann und Suheyla Yildiz für ihre wertvollen Beiträge zu dieser Arbeit. Nicht zuletzt möchte ich mich auch bei den Kolleginnen und Kollegen der Airbus De- fence and Space GmbH, der Airbus Operations GmbH, der Ariane Group AG, der Fokker Elmo B.V., des Instituts für Raumfahrtsysteme der Universität Stuttgart (IRS), der Lisa Dräxlmaier AG, der RLE International GmbH und der Tesat-Spacecom GmbH & Co. KG für die Unterstützung und die gute Zusammenarbeit danken. Ihre Beiträge in bilateralen Industrieprojekten und öffentlichen Forschungsvorhaben wie z. B. IDEaliSM (ITEA4), PHAROS (Clean Sky 2), FORTIFIER (ERA-Net-MANUNET), A3-DR und ASHRAM (Na- tionales Raumfahrtprogramm) haben wesentlich zur praktischen Relevanz dieser Arbeit beigetragen und gezeigt, dass die in dieser Arbeit vorgestellten Technologien industriell anwendbar sind. Abschließend möchte ich mich ganz von ganzem Herzen bei meinen Eltern, Geschwistern, Freunden und meiner Partnerin Melanie bedanken, die mich während dieser gesamten Reise uneingeschränkt unterstützt haben. Eure Ermutigung und euer unerschütterlicher Glaube an mich waren der Schlüssel, um diese Dissertation zu verwirklichen. Ich danke allen, die in irgendeiner Weise an diesem Weg teilgenommen haben, und freue mich darauf, ihn in Zukunft gemeinsam fortzusetzen. https://itea4.org/project/idealism.html https://cordis.europa.eu/project/id/865044 https://www.zukunft-der-wertschoepfung.de/projekte/eranet-durch-kuenstliche-intelligenz-verbesserte-digitale-fabrik-fuer-die-fertigung-von-kabelbaeumen-manunet-fortifier/ https://doi.org/10.2314/KXP:1748096605 https://doi.org/10.2314/KXP:187833946X Kurzfassung In der Entwicklung moderner technischer Systeme nimmt durch die zunehmende Elek- trifizierung und Digitalisierung von Produktfunktionen der Anteil der elektrischen und elektronischen Systemkomponenten stetig weiter zu. Dabei gewinnt der Leitungssatz als zentrales und verbindendes Element der Energie- und Signalverteilung aufgrund seiner immer weiter steigenden Größe und Komplexität industrieübergreifend in der System- entwicklung immer mehr an Bedeutung. Die Komplexität und Größe der Leitungssätze beeinflusst dabei maßgeblich die Prozessketten von der Entwicklung bis zur Fertigung und kann insbesondere durch die dabei anfallenden manuellen Tätigkeiten zum Zeit- und Kostentreiber in der Gesamtentwicklung werden. Eine weitgehende algorithmische Auto- matisierung dieser Tätigkeiten bietet daher ein großes Potenzial zur Effizienzsteigerung dieser Prozessketten in der Industrie. Das Hauptziel dieser Arbeit ist die Entwicklung und Implementierung einer Softwarear- chitektur für die automatisierte Generierung von 3D-Leitungssätzen im industriellen Kon- text. Die Anforderungen an diese Softwarearchitektur werden aus verschiedenen Bereichen der Industrie, wie z. B. der Luft- und Raumfahrt oder dem Automobilbau abgeleitet und umfassen Aspekte wie Bauraumgeometrie, Komponentendaten, Elektrologik, Entwurfsre- geln und Konsistenzprüfung. Ein weiterer Schwerpunkt liegt auf der Leistungsfähigkeit der Algorithmen bei der Verarbeitung detaillierter Datensätze sowie auf der Effizienz beim Umgang mit den zahlreichen Änderungen, die für den Systementwicklungsprozess typisch sind. Das Konzept der Softwarearchitektur gliedert den Prozess in sequenzielle Teilaufgaben, die von eigenständigen Softwarefunktionalitäten übernommen werden. Die lose Kopp- lung dieser Funktionalitäten untereinander und der Datenaustausch über ein gemeinsames, robustes Datenmodell ermöglicht die Integration der Architektur in bestehende Software- plattformen und erleichtert darüber hinaus die Wartung und Anpassung der Software im Kontext eines sich im ständigen Wandel befindlichen Entwurfsprozesses für Leitungssätze. Die Realisierung dieser Funktionalitäten erfolgt durch zahlreiche Softwarekomponenten, die in einer Schichtenstruktur organisiert sind. Die abstrakte Core-Schicht beinhaltet dabei die allgemeinen Komponenten mit Funktionen zur Verwaltung und Ausführung von Work- flows, zur Konvertierung zwischen Datenmodellen oder zur Modellierung und Simulation von Mehrkörpersystemen. Die zentrale Harness-Schicht baut auf den Komponenten der Core-Schicht auf und beinhaltet die für die Generierung von 3D-Leitungssätzen notwendi- gen Komponenten. Zu diesen Komponenten gehören u. a. die Algorithmen zur Erzeugung von Leitungssatztopologien, die automatisierte Verlegung von Einzelleitungen in diesen To- pologien sowie die physikalische Simulation des 3D-Leitungssatzes. Die Verwaltung und Integration der gesamten Software in eine bestehende Softwareplattform wird durch die Komponenten der konkreten Platform-Schicht realisiert. Die Komponenten der Platform- Schicht enthalten alle Funktionen zum Import und Export externer Datenformate sowie zur Steuerung und Visualisierung des gesamten Generierungsprozesses. Dazu gehört auch die Steuerung des Datenaustausches zwischen den verschiedenen Harness-Komponenten über das zentrale Datenmodell in der unabhängigen DataModel-Schicht. Die Softwarearchitektur wurde im Rahmen dieser Arbeit auch softwaretechnisch im- plementiert, in das Framework der Software Design Cockpit 43® (kurz DC43®) integriert und anhand von drei Anwendungsbeispielen demonstriert. Diese Beispiele zeigen u. a. die schrittweise Entwicklung anhand eines akademischen Leitungssatzmodells, die Varianten- generierung für ein Flugzeugleitwerk und den Änderungsprozess an einem Leitungssatz eines Kleinsatelliten in einer fortgeschrittenen Entwicklungsphase. Anhand dieser sehr unterschiedlichen Szenarien konnte die beschleunigte Erzeugung von 3D-Leitungssätzen mit Hilfe von Algorithmen im industriellen Kontext erfolgreich gezeigt werden. Die vorgestellte Architektur ermöglicht eine flexible Anpassung an die sich ständig ändernden Anforderungen in der Leitungssatzentwicklung. Die entwickelten Komponen- ten finden auch Anwendung in anderen Bereichen des Ingenieurwesens, wie z.B. dem automatisierten Entwurf von Hohlleitern oder der automatisierten Verlegung von Biege- rohren in beliebig komplexen geometrischen Bauräumen. Die Integration in Plattformen wie das DC43®-Framework ermöglicht darüber hinaus die Kombination verschiedener Automatisierungslösungen für optimierte Ergebnisse in unterschiedlichen ingenieurwis- senschaftlichen Aufgabenstellungen, wie z. B. 3D-Packing, der 3D-Verrohrung und der 3D-Leitungssatzgenerierung. Abstract With the electrification and digitalisation of modern products, the significance of electrical and electronic components within technical systems is increasingly important. As a result, the growing size and complexity of the wire harness, which is the central and connecting element for power and signal distribution, is becoming increasingly important in a wide range of industries. The size and complexity of the wire harness has a significant impact on the entire process chain from design to production, and the manual tasks involved can be time consuming and costly. The extensive automation of these tasks through the use of algorithms offers significant potential for increasing the efficiency of industrial processes. The main objective of this thesis is to design and implement a software architecture that can automatically generate 3D wire harnesses in an industrial context. The requirements for the software architecture are derived from various industrial sectors such as aerospace and automotive. These requirements include key features such as the installation space geometry, component data, electrical schematics, design principles and consistency. In addition, the thesis focuses on the ability of the algorithms to handle complex data sets and to efficiently manage the frequent changes that occur during the system development process. The wire harness generation process is broken down into sequential subtasks performed by independent software functionalities. These functionalities are loosely coupled and allow data to be exchanged via a common, robust data model, making it easy to integrate the architecture into existing software platforms and to maintain and adapt the software in the context of an ever-changing wiring harness design process. These functionalities are realised by means of a large number of software components that are organised in a layered structure. The Core-layer contains the basic modules respon- sible for workflow management and execution, data model conversion, and multi-body sys- tem modelling and simulation. The Harness-layer, which is based on the Core-components, contains specific components required for 3D harness generation. These components inclu- de the algorithms for generating harness topologies, the automated routing of individual wires in these topologies and the physical simulation of the 3D harness. The integration of the software into an existing software platform is realised by the components of the concre- te Platform-layer. These components include all functionalities for importing and exporting external data formats and for controlling and visualising the entire generation process. This includes the handling of the data exchange between the different Harness-components using the central data model in the independent DataModel-layer. As part of this thesis, the software architecture has been implemented, integrated into the framework of the Design Cockpit 43® (DC43®) software and demonstrated in three different use cases. These demonstrate the sequential development based on an academic harness model, the generation of variants for an aircraft tail unit and the modification process on a small satellite harness in an advanced development phase. Through these very different use cases, the acceleration of 3D wire harness generation in an industrial context using algorithms has been successfully demonstrated. The architecture presented allows flexible adaptation to the constantly changing require- ments in wiring harness design. The components developed can also be used in other areas of engineering, such as the automated design of waveguides or the automated design of bending pipes in complex geometric environments. The integration into platforms such as the DC43® framework also enables the combination of different automation solutions for optimised results in various engineering tasks, such as 3D packing, 3D piping and 3D wire harness generation. Inhaltsverzeichnis Abkürzungsverzeichnis xi 1 Einleitung 1 1.1 Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Grundlagen und Stand der Technik 5 2.1 Der Leitungssatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 E/E-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2 Elemente des Leitungssatzmodells . . . . . . . . . . . . . . . . . 8 2.1.3 Prozess Leitungssatzentwicklung . . . . . . . . . . . . . . . . . 10 2.2 Algorithmen und Standards . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.1 Pfadfindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.2 Mehrkörpersimulation . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.3 Datenstandards . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3 Softwareplattform und Bibliotheken . . . . . . . . . . . . . . . . . . . . 22 2.3.1 Graphenbasierte Entwurfssprachen . . . . . . . . . . . . . . . . 23 2.3.2 Design Cockpit 43® . . . . . . . . . . . . . . . . . . . . . . . . 23 3 Anforderungen und Konzept 25 3.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1 Prozess-Randbedingungen . . . . . . . . . . . . . . . . . . . . . 25 3.1.2 Effizienz des Prozesses . . . . . . . . . . . . . . . . . . . . . . . 27 3.1.3 Qualität des Leitungssatzes . . . . . . . . . . . . . . . . . . . . . 28 3.1.4 Softwareentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2.1 Prozessschritte . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2.2 Softwarefunktionalitäten . . . . . . . . . . . . . . . . . . . . . . 32 3.2.3 Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.4 Implementierung und Integration . . . . . . . . . . . . . . . . . 37 ix x Inhaltsverzeichnis 4 Aspekte der Softwarearchitektur 39 4.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.2 DataModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2.1 VEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3.1 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3.2 Convert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3.3 Physics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.4 Harness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.4.1 Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.4.2 Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.4.3 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.4.4 Pathfinding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.4.5 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 4.4.6 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 4.5 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 4.5.1 HarnessGeneration . . . . . . . . . . . . . . . . . . . . . . . . . 132 4.5.2 Import und Export . . . . . . . . . . . . . . . . . . . . . . . . . 133 4.5.3 Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 5 Anwendungsfälle 139 5.1 Akademischer Anwendungsfall . . . . . . . . . . . . . . . . . . . . . . . 139 5.2 Leitwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 5.3 Kleinsatellit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 6 Zusammenfassung 169 6.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Literaturverzeichnis 173 Abkürzungsverzeichnis AABB axis-aligned bounding box BFS breadth-first search BOM Bill of material BVH bounding volume hierarchy CAD Computer-aided Design CAS Computeralgebrasystem CFD Computational Fluid Dynamics CSV Comma-separated values DC43® Design Cockpit 43® DFS depth-first search E/E Elektrik/Elektronik EMF Eclipse Modeling Framework EMV elektromagnetische Verträglichkeit ESD elektrostatische Entladung EWIS Electrical Wiring Interconnection System FBW Fly-by-Wire FEM Finite-Elemente-Methode FLP Flying Laptop GUI Graphical User Interface IDE Integrated Development Environment xi xii Abkürzungsverzeichnis IFB Institut für Flugzeugbau IFE In-flight Entertainment IRS Institut für Raumfahrtsysteme JT Jupiter Tesselation KSK Kundenspezifischer Kabelbaum MKS Mehrkörpersimulation NBA* New Bidirectional A* OCC Open CASCADE® PCDU Power Control and Distribution Unit PLOC Payload On-board Computer PNBA* Parallel New Bidirectional A* SPG Solution Path Generator STEP Standard for the Exchange of Product model data STL Standard Tessellation Language UI User Interface UML Unified Modeling Language VDA Verband der Automobilindustrie VEC Vehicle Electric Container VTK Visualization Toolkit XML Extensible Markup Language 1 Einleitung Bei der Entwicklung moderner technischer Systeme gewinnen Elektrik und Elektronik (kurz E/E) immer mehr an Bedeutung. Der Leitungssatz als zentrale Komponente zur Energie- und Signalverteilung ist dabei ein elementarer Bestandteil dieser Systeme und hat in der Vergangenheit industrieübergreifend an Größe und Komplexität zugenommen. In der Automobilindustrie ist dieser Anstieg laut [2, S. 1] unter anderem auf die stetige Zunahme elektrisch und elektronisch realisierter Funktionen zurückzuführen. Dadurch hat sich die Anzahl der zu vernetzenden Komponenten so stark erhöht, dass der Leitungssatz zur teuersten und schwersten E/E-Komponente angewachsen ist. In einem gut ausgestatte- ten Fahrzeug der Mittelklasse können heutzutage beispielsweise mehr als 3 km bzw. 40 kg Kabel verbaut sein. Zusätzlich erhöhen der Einsatz neuer Technologien wie Hochvoltleitun- gen oder erhöhte Anforderungen an den Schutz vor Umwelteinflüssen die Komplexität des Leitungssatzes. Der größte Treiber der Komplexität ist jedoch die Varianz, die der Leitungs- satz abdecken muss. Diese Komplexität ergibt sich aus der Kombination verschiedener Fahrzeugvarianten sowie der freien Wahl des Kunden bezüglich der Ausstattungsmerkmale. Diese beeinflussen nicht nur die Anzahl und Art der Komponenten und deren elektrologi- sche Vernetzung, sondern auch deren geometrische Position. Der Variantenreichtum bietet jedoch auch die Möglichkeit, durch Konzepte wie dem kundenspezifischen Kabelbaum (kurz KSK) den Leitungssatz zumindest teilweise hinsichtlich Gewicht und Kosten zu optimieren, was wiederum die Komplexität insbesondere in der Entwicklung weiter erhöht. Ein ähnliches Bild zeigt sich in der Luftfahrtindustrie, wie [57, S. 1f] festgestellt. Seit dem ersten Einsatz elektrischer Geräte an Bord von Flugzeugen hat sich das sogenannte EWIS (engl. Electrical Wiring Interconnection System) stetig weiterentwickelt und ist expo- nentiell in Größe und Komplexität gewachsen. Die Gründe für das stetige Wachstum liegen vor allem in der Weiterentwicklung der Avioniksysteme, der Einführung der elektronischen Flugzeugsteuerung (engl. Fly-by-Wire) und der Einführung von Systemen für das In-flight Entertainment (kurz IFE). Der Leitungssatz in modernen Verkehrsflugzeugen wie dem Boeing 787 Dreamliner umfasst bspw. mehr als 3.500 Steckverbinder und 40.000 Kabel mit einer Gesamtlänge von über 100 km. Aufgrund seiner Auswirkungen auf Gewicht, Volumen, Kosten und Flugsicherheit ist der Leitungssatz daher von erheblicher Bedeutung. 2 Auch in Raumfahrtanwendungen ist nach [33, S. 1f] eine zunehmende Komplexität des Leistungssatzes zu beobachten. Auch hier zählt der Leistungssatz zu den komplexesten elek- trischen Komponenten. Neben der hohen Anzahl der zu vernetzenden E/E-Komponenten tragen auch die hohen Anforderungen an Ausfallsicherheit, elektromagnetische Verträg- lichkeit (kurz EMV), elektrostatische Entladung (kurz ESD), Schutz gegen Wärme und Strahlung oder mechanische Befestigung unter hohen Beschleunigungs- und Vibrationsbe- lastungen zur Größe und Komplexität des Leitungssatzes bei. Bei einem großen Satelliten kann der Leitungssatz beispielsweise aus mehr als 50.000 Kabeln mit etwa 1.000 Steck- verbindern bestehen. Die Gesamtlänge aller Leitungen eines solchen Leitungssatzes kann mehr als 20 km und die Gesamtmasse mehr als 100 kg betragen. Der Leitungssatz hat somit einen erheblichen Einfluss auf die Leistungsfähigkeit des elektrischen Systems und einen bedeutenden Anteil an der Gesamtmasse des Raumfahrtsystems. Nach [2, S. 1] ist die Komplexität des Leitungssatzes daher auch das bestimmende Element in der Prozesskette von der Entwicklung über die Arbeitsvorbereitung bis zur Fertigung und Montage. Einerseits erfordern notwendige Optimierungen und neue Tech- nologien die Integration von immer mehr zusätzlichen Tätigkeiten in die Prozesskette. Andererseits führt der hohe Zeit- und Kostendruck dazu, dass immer mehr Tätigkeiten zu kostengünstigeren Anbietern in den unterschiedlichsten Regionen des globalen Marktes verlagert werden. Diese inhaltliche und organisatorische Diversifizierung hat zur Folge, dass es keine einheitliche Prozesskette gibt. Vielmehr handelt es sich um eine Vielzahl unterschiedlichster Aktivitäten, die je nach Bedarf eines Unternehmens oder Projekts organisiert werden. Die unternehmensspezifische Implementierung solcher Entwicklungs- prozesse führt nach [34, S. 26ff] in der Regel zu komplexen Prozess- und Toolketten. Eine besondere Herausforderung für diese Prozess- und Toolketten besteht darin, dass die Entwicklung des Leitungssatzes sowohl vom Entwicklungsstand der zu vernetzenden Komponenten, als auch vom Entwicklungsstand der Systemgeometrie abhängig ist. Dies hat zum einen eine vergleichsweise hohe Änderungsrate zur Folge, auch weil insbesondere in frühen Entwicklungsstadien meist mit unvollständigen Datensätzen und auf Basis von Annahmen gearbeitet werden muss. Zum anderen bedeutet dies, dass diese Prozesskette nach [2, S. 2] und [33, S. 3] damit auch immer auf dem kritischen Pfad zum Ende eines Projektes liegt. Als besonders problematisch erweist sich dabei, dass nach [3, S. 2] diese Prozessketten viele manuelle Tätigkeiten beinhalten. Diese manuellen Eingriffe sind je- doch in der Regel nicht prozesssicher und stellen weder kalkulierbare noch beherrschbare Risiken hinsichtlich Zeit und Qualität dar. Dies betrifft zum einen die Arbeitsvorbereitung und Fertigung, aber auch die Konstruktion des 2D-Layouts oder der 3D-Geometrie des Leitungssatzes in der Entwicklung. Einleitung 3 Der 3D-Leitungssatz wird nach [34, S. 25] heute in der Regel manuell in einer CAD- Software (Abk. für Computer-aided Design) modelliert. Ziel des Modells ist unter anderem die Reservierung des notwendigen Bauraums für den Leitungssatz im Gesamtmodell des Systems. Darüber hinaus können anhand des 3D-Modells auch die Längen der einzelnen Leitungen ermittelt werden. Das Modell hilft z. B. auch bei der Definition eines Halterungs- konzeptes für den Leitungssatz. Die Auslegung des 3D-Leitungssatzes hängt stark von der Elektrologik und der Bauraumgeometrie ab. Letztere umfasst nicht nur die Form und Lage der zu vernetzenden E/E-Komponenten, sondern auch alle anderen geometrischen Bauteile des Gesamtsystems im zusammengebauten Zustand. Dies bedeutet, dass nicht nur Änderungen an der Elektrologik und den E/E-Komponenten, sondern auch Änderungen an allen anderen Bauteilen eine mehr oder weniger aufwändige manuelle Änderung des 3D-Modells des Leitungssatzes zur Folge haben können. Die Erzeugung und Pflege des 3D-Leitungssatzes in einer CAD-Software stellt somit insgesamt eine besonders zeitinten- sive Tätigkeit innerhalb der Prozesskette dar, die aufgrund der nicht unerheblichen Lizenz- und Lohnkosten auch entsprechend hohe Kosten verursacht. Die algorithmische Automatisierung einer manuellen Tätigkeit bietet somit ein großes Potenzial zur Kosten- und Zeiteinsparung in der Prozesskette der Leitungssatzentwicklung. In den letzten Jahren wurden hier bereits wichtige Beiträge im Bereich des automatisierten Entwurfs von 3D-Leitungssätzen von [59], [64] oder [18] geleistet, die auch die Mach- barkeit algorithmischer Lösungen demonstrieren konnten. Allerdings beschränkt sich der Einsatz dieser Lösungen meist auf akademische oder stark vereinfachte Beispiele, die noch keine industrielle Reife aufweisen. 1.1 Ziel der Arbeit Ziel dieser Arbeit ist der Entwurf und die Implementierung einer Softwarearchitektur zur automatisierten Generierung von 3D-Leitungssätzen für den industriellen Einsatz. Diese Architektur soll alle Schritte dieses Prozesses abdecken, sodass sie nahtlos in die Prozess- ketten der Leitungssatzentwicklung in verschiedenen Industriezweigen integriert werden kann. Dazu wird der Prozess in verschiedene, aufeinander aufbauende Teilaufgaben un- terteilt. Die Umsetzung dieser Teilaufgaben erfolgt durch eigene Funktionalitäten, die als eigenständige Softwarekomponenten realisiert werden sollen. Für den industriellen Einsatz müssen die Komponenten zum einen Schnittstellen für die in der Industrie verwendeten Datenformate zum Import und Export von Daten bereitstellen. Zum anderen müssen die Komponenten in der Lage sein, Daten in industrieller Detailtiefe zu verarbeiten bzw. zu 4 1.2 Aufbau der Arbeit generieren. Für die Generierung eines 3D-Leitungssatzes in industrieller Qualität sollen verschiedene Algorithmen implementiert und optimiert werden. Besonderes Augenmerk soll dabei auf die 3D-Topologie des Leitungssatzes gelegt werden. Durch die Optimie- rung der Pfadfindungsalgorithmen und den Einsatz vereinfachter Mehrkörpermodelle in Physiksimulationen sollen einerseits die industriellen Anforderungen an die Qualität der 3D-Topologie erreicht und andererseits die Laufzeit des Prozesses minimiert werden. Der Austausch zwischen diesen Komponenten soll lose über ein gemeinsames Datenmodell erfolgen, wodurch die Komponenten unabhängig und austauschbar werden. Darüber hin- aus soll dieses modulare System auch die softwaretechnische Integration in bestehende Softwareplattformen erleichtern. Eine solche Integration soll exemplarisch im Software- Framework Design Cockpit 43® (kurz DC43®) realisiert werden. Dies beinhaltet unter anderem auch die Umsetzung einer grafischen Benutzeroberfläche (engl. Graphical User Interface oder kurz GUI) sowie die Visualisierung der verschiedenen Funktionalitäten in einer 3D-Ansicht. 1.2 Aufbau der Arbeit Die vorliegende Arbeit ist in sechs Teile gegliedert. Nach der Einleitung werden in Kapitel 2 (Grundlagen und Stand der Technik) die für das Verständnis dieser Arbeit notwendigen Grundlagen geschaffen. Dies umfasst zum einen eine Einführung in die Thematik der E/E-Architektur im Allgemeinen und den dazugehörigen Leitungssatz im Speziellen. Zum anderen werden die für die Umsetzung der Automatisierung notwendigen Algorithmen, Standards und Softwarebibliotheken vorgestellt. Aus den Prozessbeschreibungen zur Ent- wicklung von Leitungssätzen sowie den algorithmischen Möglichkeiten werden anschlie- ßend in Kapitel 3 (Anforderungen und Konzept) die Anforderungen an die Softwarearchi- tektur abgeleitet und ein grundlegendes Konzept skizziert. Das folgende Kapitel 4 (Aspekte der Softwarearchitektur) befasst sich dann mit der Umsetzung dieses Konzepts und stellt den Kern dieser Arbeit dar. Die zur Softwarearchitektur gehörenden Softwareschichten und -komponenten zur Realisierung und Steuerung der algorithmischen Automatisierung wer- den hier detailliert beschrieben. In Kapitel 5 (Anwendungsfälle) wird die Anwendung der implementierten Architektur anhand mehrerer Anwendungsfälle demonstriert. Der Schwer- punkt liegt dabei auf der Durchführung von Änderungen der Randbedingungen innerhalb von Systeme mit industrieller Komplexität. Die Arbeit schließt mit einer Zusammenfassung und einem Ausblick in Kapitel 6 (Zusammenfassung). 2 Grundlagen und Stand der Technik In diesem Kapitel sollen die für diese Arbeit notwendigen Grundlagen erläutert werden. Der Fokus liegt hierbei zunächst auf der Definition des Begriffs Leitungssatz. Dazu werden zunächst die verschiedenen Modelle der E/E-Architektur allgemein vorgestellt und an- schließend die für diese Arbeit relevanten Elemente des Leitungssatzmodells beschrieben. Darüber hinaus wird der konventionelle Entwicklungsprozess skizziert und auf relevan- te Vorarbeiten im Bereich der Automatisierung des Leitungssatzentwurfs eingegangen. Ein weiterer Schwerpunkt liegt auf der Vorstellung von Algorithmen und Methoden zur Pfadfindung und zur physikalischen Mehrkörpersimulation. Zusätzlich werden die zur Implementierung verwendeten Softwarebibliotheken vorgestellt. 2.1 Der Leitungssatz Der Leitungssatz (alt. Kabelbaum, engl. wire, wiring, cable harness) beschreibt im Allge- meinen die Gesamtheit aller Hardware-Komponenten (Leitungen, Kabel, Steckverbinder, Halterungen), die für die Energie- und Signalverteilung innerhalb eines Systems notwendig sind [43, S. 450; 24]. Im Kontext des Gesamtsystems stellt der Leitungssatz somit einen Teil der Hardware-Implementierung der E/E-Architektur dar [48, S. 10]. 2.1.1 E/E-Architektur Der Begriff Elektrik/Elektronik (kurz E/E) bezeichnet nach [42, S. 211f] und [43, S. 154f] alle elektrischen und elektronischen Aspekte eines Systems. Die E/E-Architektur umfasst somit den Entwurf aller elektrischen und elektronischen Komponenten, deren Vernetzung (Topologie) sowie den dazugehörigen Leitungssatz. Um E/E-Systeme vollständig zu be- schreiben, werden in der Industrie verschiedene E/E-Architekturmodelle verwendet. Diese Modelle beschreiben das Gesamtsystem aus verschiedenen Sichten und spiegeln die Er- gebnisse der verschiedenen Integrationsschritte der E/E-Architektur in das System wider. Grundsätzlich gibt es in der E/E-Architektur zwei verschiedene Arten von Modellen: Lo- gische Modelle, die die Funktionalität unabhängig von der zugrunde liegenden Hardware 6 2.1 Der Leitungssatz abstrakt beschreiben und Implementierungsmodelle, die die elektrischen und elektroni- schen Komponenten spezifizieren und die Funktionen der Hardware zuordnen. Anzahl und Art der Modelle, die Hersteller und Zulieferer zur vollständigen Beschreibung von E/E-Systemen benötigen, variieren. Die in Abb. 2.1 vorgestellten Modelle haben sich je- doch in der Praxis bewährt und stellen ein notwendiges Grundgerüst zur Beschreibung des E/E-Umfangs dar. Lo gi sc he M od el le Im pl em en tie ru ng s- M od el le Funktionsmodell Technologiemodell Knotenmodell Hardwaremodell der elektronischen Komponenten Softwaremodell der elektronischen Komponenten Netzwerkmodell Kommunikation Netzwerkmodell Energieversorgung Bauraum- und Leitungssatzmodell Abbildung 2.1: Modelle der E/E-Architektur nach [43, S. 155] Logische Modelle. Funktionsmodelle beschreiben nach [43, S. 155] eine Wirkungs- kette, die dazu dient, die Funktion und deren Verbindung zu Sensoren und Aktoren in groben Funktionsblöcken darzustellen, ohne auf die spezifische technologische Umset- zung einzugehen. Das Technologiemodell ermöglicht die Entscheidung über die technische Umsetzung der spezifizierten Funktionsblöcke, ohne diese bereits zu Baugruppen wie elek- tronischen Steuergeräten zusammenzufassen. Es entsteht eine technologische Wirkungs- kette mit Technologiebausteinen, die beschreibt, ob die Funktionsblöcke in Hardware oder Software realisiert werden. Grundlagen und Stand der Technik 7 Implementierungsmodelle. Der erste Schritt bei der Implementierung ist nach [43, S. 155] die Erstellung des Knotenmodells, bei dem die Technologiebausteine der technologi- schen Wirkungsketten an verschiedenen Orten zu Gruppen, den Knoten, zusammengefasst werden. Diese Knoten repräsentieren alle erforderlichen Komponenten der E/E-Architektur. Das Hardwaremodell der elektronischen Komponenten bildet die Struktur der elektroni- schen Hardware eines spezifischen Knotens ab und entsteht durch die Zuordnung der Funk- tionsblöcke, die in Hardware realisiert werden sollen. Auf der anderen Seite beschreibt das Softwaremodell der elektronischen Komponenten die Funktionsblöcke und die Basis- software, die in Software umgesetzt werden sollen. Die Funktionsblöcke, die in Software umgesetzt werden sollen, werden in funktionale Software und Regelungssoftware unterteilt und als Anwendungssoftware bezeichnet. Das Netzwerkmodell Kommunikation stellt alle Systemkomponenten dar, die über eine Kommunikation verfügen und somit direkt oder indirekt miteinander verbunden sind. Durch die Zuordnung der Technologiebausteine zu Knoten entsteht auch ein Netz elektrischer Verbraucher, das eine angemessene Versorgung erfordert. Das Netzwerkmodell Energieversorgung umfasst die Energieversorgung und Absicherung dieser einzelnen Komponenten, ohne dabei die spezifischen Einbauorte im Fahrzeug zu berücksichtigen. Aus dem Netzwerkmodelle lässt sich nun eine detaillierte Be- schreibung aller Verbindungen zwischen den Systemkomponenten in einer gemeinsamen Elektrologik (alt. Verbindungsliste, engl. schematics oder connectivity) zusammenfassen. Im Bauraum- und Leitungssatzmodell werden nun die definierten Systemkomponenten einem bestimmten Einbauort im Fahrzeug zugeordnet. Die Verbindungen aus der Elek- trologik zur Kommunikation zwischen den Steuergeräten und zur Energieversorgung der elektrischen Verbraucher werden nun als physische Leitungen realisiert und zu Kabelsträn- gen zusammengefasst. Es entsteht der sogenannte Leitungssatz. Dabei sind verschiedene Randbedingungen zu berücksichtigen, wie z. B. das Fertigungskonzept des Fahrzeugs oder die Struktur des Leitungssatzes, die die möglichen Verlegepfade in der Bauraumgeometrie beschreiben. In der Konzeptphase der Fahrzeugentwicklung genügt in der Regel ein zwei- dimensionales Modell für die E/E-Architektur, während in späteren Entwicklungsphasen ein detailliertes dreidimensionales Modell zum Einsatz kommt. Hardware. Die Gesamtheit aller Hardware-Systemelemente einer E/E-Systemarchitektur wird in der Automobilindustrie nach [60, S. 181] zusammenfassend als Bordnetz bezeichnet. Dieses umfasst neben dem Leitungssatz bspw. auch Sensoren, Aktoren, elektronische Steu- ergeräte, Generatoren, Energiespeicher, Spannungswandler, Sicherungen und elektrische Antriebe. 8 2.1 Der Leitungssatz 2.1.2 Elemente des Leitungssatzmodells Die Informationen, die zur Beschreibung eines Leitungssatzes benötigt werden, können nach [2, S. 5] in drei Hauptbereiche unterteilt werden: Elektrologik, Komponentendaten und Geometriedaten in 2D und 3D. Im Folgenden werden die für diese Arbeit relevanten Elemente dieser Bereiche technisch beschrieben, wobei sich die Nomenklatur hauptsäch- lich an der deutschen Automobilindustrie orientiert. 2.1.2.1 Elektrologik Die Elektrologik ist nach [2, S. 5] eine detaillierte Beschreibung der elektrischen Signale und Verbindungen, die über den Leitungssatz übertragen werden. Die Beschreibung setzt sich dabei aus drei grundlegenden Elementen zusammen: Systemkomponenten, Kompo- nentenanschlüsse und Verbindungen. Die Systemkomponenten (alt. Komponentenknoten, engl. component nodes) repräsentieren die E/E-Elemente wie Aktoren, Sensoren, Steuer- geräte, aber auch Verbindungsstecker (engl. connectors) oder Spleiße (engl. splices). Die Komponentenanschlüsse (engl. component ports) repräsentieren die Pins einer System- komponente. Die Verbindungen (engl. connections) stellen nun die Konnektivität zwischen den zugehörigen Komponentenanschlüssen aus der Sicht einer einadrigen Leitung dar. Basierend auf der Verbindungsliste (alt. Von-Zu-Liste, engl. from-to-list) ist es möglich, Verbindungsgruppen wie z. B. mehradrige Kabel und anschließend Verlegewege von Ka- beln auf der Leitungssatztopologie zu definieren [29, S. 24, 30]. 2.1.2.2 Komponentendaten Die Komponentendaten (alt. Stammdaten, engl. master data) bezeichnen im Kontext des Leitungssatzes nach [2, S. 5] die detaillierte technische Beschreibung der einzelnen Kom- ponenten, die zum physischen Leitungssatz gehören. Zu diesen Komponenten gehören unter anderem Steckverbinder, Leitungen oder Halterungen. Steckverbinder. Ein Steckverbinder repräsentiert nach [29, S. 71, 170, 190] grund- sätzlich ein Kontaktmodul oder Steckergehäuse (engl. connector housing). In der Regel wird ein Steckverbinder in einen entsprechenden Gegensteckverbinder gesteckt, um ei- ne Verbindung herzustellen. Im Kontext dieser Arbeit sind insbesondere Eigenschaften wie die Geometrie des Steckverbinders und der Segment-Abgangspunkt (engl. segment connection point) mit einer Abgangsrichtung (engl. outlet direction) relevant. Der Segment- Abgangspunkt gibt einen Punkt an, an dem der Steckverbinder an die Leitungssatztopologie angehängt werden kann. Grundlagen und Stand der Technik 9 Leitung und Kabel. Unter einer Leitung (alt. Leiter, engl. wire) versteht man nach [48, S. 10] einen elektrisch isolierten metallischen Leiter (Ader mit Isolierung), der zwei oder mehr Pins miteinander verbindet. Im Gegensatz dazu besteht ein Kabel (engl. cable) aus einem oder mehreren Leitern und kann zusätzlich eine Abschirmung besitzen. Im Kontext dieser Arbeit sind der Außendurchmesser und der minimale Biegeradius von Leitungen und Kabeln die entscheidenden Eigenschaften dieser Komponenten [29, S. 198]. Halterung. Eine Halterung (engl. fixing) wird nach [29, S. 271] verwendet, um den Leitungssatz in einer bestimmten Position zu fixieren. Die Eigenschaften der Kompo- nente beschreiben, wie der Leitungssatz an einem nicht zum Leitungssatz gehörenden Bauraumelement befestigt wird. 2.1.2.3 Leitungssatztopologie Die Leitungssatztopologie (engl. harness topology) ermöglicht eine detaillierte Beschrei- bung der Verlegewege von Kabeln in dreidimensionalen Räumen [2, S. 5]. Sie setzt sich aus Topologie-Knoten und -Segmenten zusammen [29, S. 339]. Knoten. Ein Topologie-Knoten (engl. topology node) stellt nach [29, S. 95f, 336, 223] einen abstrakten Punkt im Leitungssatz dar, der keine konkreten Koordinaten besitzt. Er dient lediglich als Verknüpfungspunkt für Topologie-Segmente und hat keine eigene räum- liche Ausdehnung. Entsprechend ihrer Verknüpfung mit Topologie-Segmenten können Topologie-Knoten grundsätzlich in drei Typen unterteilt werden: Endknoten (engl. end- node), die am Ende eines Segments auftreten, Durchgangsknoten (engl. inliner-node), die zwischen zwei Segmenten liegen, und Ausbindungsknoten (engl. junction-node), die mit drei oder mehr Segmenten verbunden sind. Topologie-Knoten markieren somit die Punkte in der Leitungssatztopologie, an denen Topologie-Segmente beginnen und enden. Durch die Zuordnung von kartesischen Koordinaten können Topologie-Knoten im dreidimensionalen Raum positioniert werden. Segmente. Topologie-Segmente (engl. topology segments) sind nach [29, S. 224f, 337f] ein logisches Konstrukt zur Beschreibung der physischen Darstellung einer Leitungssatzto- pologie. Ein Topologie-Segment stellt einen Abschnitt innerhalb des Leitungssatzes dar, in dem keine elektrischen Zwischenkontakte vorhanden sind. Das bedeutet, dass am An- fang und am Ende eines Topologie-Segments dieselben Leitungen bzw. Kabel ein- und austreten. Diese Anfangs- und Endpunkte werden jeweils durch eine Verknüpfung mit 10 2.1 Der Leitungssatz einem Topologie-Knoten definiert. Durch die Zuordnung von Kurvenbeschreibungen, wie z. B. Splines, kann der Verlauf von Topologie-Segmenten im dreidimensionalen Raum geometrisch definiert werden. 2.1.2.4 Leitungssatzrouting Ein Leitungssatzrouting (engl. harness routing) ist nach [29, S. 108, 314, 331] abstrakt betrachtet die Zuordnung einer logischen Verbindung bzw. einer physischen Leitung oder eines Kabels zu einem Pfad in der Leitungssatztopologie. Dieser Pfad ist ein kontinuier- licher Weg durch die Topologie ohne Unterbrechungen und kann durch eine geordnete Liste von Topologie-Segmenten definiert werden. Ein Leitungssatzrouting im Allgemeinen bezeichnet auch die Gesamtheit aller Einzelleitungsroutings eines Leitungssatzes. 2.1.3 Prozess Leitungssatzentwicklung Wie in Abschnitt 2.1.1 beschrieben, ist der Leitungssatz ein Teil der Hardware-Implemen- tierung der E/E-Systemarchitektur, im Automobilbereich auch Bordnetz genannt. Nach [3, S. 1f] ist die Entwicklung des Bordnetzes einem ständigen Wandel unterworfen. Generell ist industrieübergreifend eine zunehmende Komplexität der E/E-Systeme sowie die grund- sätzliche Forderung nach Gewichts-, Volumen- und Kostenreduktion des Bordnetzes zu beobachten. Damit steigt auch die Komplexität des Entwicklungsprozesses selbst. Zum einen hat sich die Anzahl der unterschiedlichen Aktivitäten erhöht, zum anderen sind diese Aktivitäten in zunehmend globalisierten Märkten auch unternehmensübergreifend verteilt. Der Prozess der Bordnetzentwicklung ist somit komplex und unterscheidet sich in der Praxis zwischen den einzelnen Unternehmen und teilweise auch zwischen den Produkten eines einzelnen Unternehmens. Deswegen muss festgehalten werden, dass es keinen allge- meingültigen Entwicklungsprozess für das Bordnetz gibt. Die effiziente Umsetzung eines Entwicklungsprozesses mit den notwendigen Tätigkeiten stellt einen entscheidenden Fak- tor in der Wertschöpfung der Produktentwicklung dar und wird daher teilweise als sensibles Unternehmenswissen angesehen und entsprechend geschützt bzw. nicht offengelegt. Makroskopisch lassen sich aber die notwendigen Tätigkeiten wie in Abb. 2.2 darstellen. Ausgangspunkt für die Entwicklung des physischen Leitungssatzes sind die im System eingesetzten Komponenten. Aus diesen lassen sich die Anforderungen an die elektrische Auslegung mit logischen Verbindungen und Schaltplänen ableiten. Gleichzeitig wird ein dreidimensionales Modell des Leitungssatzes erstellt, um sicherzustellen, dass innerhalb des Bauraums ausreichend Platz für den Leitungssatz und seine Komponenten reserviert Grundlagen und Stand der Technik 11 wird. Diese beiden Entwicklungsaspekte müssen zusammengeführt werden, um eine Doku- mentation zu erstellen und die Daten für die Fertigung aufzubereiten. Anschließend kann der Leitungssatz gefertigt und geliefert werden. Komponenten- entwicklung Elektrologik Geometrie Produktdefinition Kabelbaum Fertigung Abbildung 2.2: Makroprozesse der physischen Bordnetzentwicklung nach [3, S. 2] 2.1.3.1 Unterstützung durch Softwarewerkzeuge Für die Durchführung von Tätigkeiten in der Entwicklung des Leitungssatzes kann nach [3, S. 3f] heute auf eine Vielzahl von unterstützenden Softwarewerkzeugen zurückgegriffen werden, was zu gewissen Gestaltungsmöglichkeiten bei der Realisierung des Entwicklungs- prozesses führt. Bei der Auswahl der Werkzeuge ist zu klären, welche Prozessaktivitäten durch ein bestimmtes Werkzeug unterstützt werden können, ob es sich innerhalb oder außerhalb der eigenen Systemlandschaft befindet, ob Standardwerkzeuge eingesetzt wer- den oder ob eine individuelle Lösung erforderlich ist. So wird z. B. die 3D-Geometrie des Leitungssatzes in der Regel manuell in CAD-Softwaretools erstellt, während die Elek- trologik meist in einem anderen Planungswerkzeug ausgelegt wird. Die Software für die nachfolgende Fertigungsplanung wiederum wird nicht selten von den Kabelkonfektionären selbst entwickelt. Dies führt in der Praxis zu einer komplexen Softwarelandschaft mit einer Vielzahl von spezialisierten Softwarewerkzeugen. Dies erfordert auch eine Vielzahl von Schnittstellen für den Datenaustausch zwischen den Werkzeugen, die jedoch nur teilweise auf bewährten Datenstandards basieren. Da der Leitungssatz in der Regel sehr hohen Än- derungsraten unterliegt, stellen insbesondere die manuellen Konstruktionstätigkeiten, aber auch die Schnittstellenvielfalt einen Aufwandstreiber und potenzielle Fehlerquellen im Entwicklungsprozess dar. Dies führt in den meisten Fällen zu höheren Entwicklungszeiten und -kosten. 12 2.1 Der Leitungssatz 2.1.3.2 Automatisierung im Entwicklungsprozess Um den Aufwand im Entwicklungsprozess zu reduzieren, liegt es nahe, manuelle Konstruk- tionstätigkeiten zu automatisieren. Insbesondere der Bereich des digitalen 3D-Leitungssat- zes bietet ein großes Potenzial, durch den Einsatz von Algorithmen Entwicklungszeiten und -kosten einzusparen. Bereits in [59] wird ein algorithmisches Verfahren zur Verlegung von Einzelkabeln in einer CAD-Geometrie beschrieben. Das Verfahren verbindet sequenziell Start- und Zielpunkte innerhalb eines Suchraumes mit CAD-Geometrie. Die Berücksichtigung der vorvernetzten Geometrie erfolgt durch spezielle Entwurfsregeln. Dazu wurde die Heuris- tik des verwendeten A*-Pfadfindungsalgorithmus entsprechend erweitert. Die Heuristik ermöglicht es, die Verlegung von Kabeln z. B. in die Nähe von Bauteilen zu erzwingen, um sie dort später mit Halterungen befestigen zu können. Das Verfahren demonstriert anhand einfacher Testfälle mit wenigen Kabeln das prinzipielle Potenzial von Pfadfin- dungsalgorithmen, die resultierenden Pfade erreichen jedoch nicht die Qualität manuell konstruierter Kabel. Auch ist es nicht möglich, die Halterungen als Randbedingungen in den Entwurfsregeln zu berücksichtigen. Um die Halterungen als Randbedingung zu berücksichtigen, wird die 3D-Routing- Automatisierung in [64] als zweistufiges Optimierungsproblem behandelt. Gegenstand der Optimierung ist die Anzahl und Position der Halterungen und Ausbindungen. Die Halterungen werden im ersten Schritt generiert und dienen als Zwischenpunkte für ei- ne vereinfachte Pfadfindung. Im zweiten Schritt erfolgt die eigentliche Generierung des 3D-Leitungssatzgeometrie als Netzwerktopologie auf Basis der Halterungen und Ausbin- dungen. Die Qualität der 3D-Ergebnisgeometrie kann dadurch deutlich verbessert wer- den. Allerdings ist die Leistungsfähigkeit des Ansatzes stark vom Detaillierungsgrad der Bauraumgeometrie abhängig und setzt in der Praxis eine deutliche Vereinfachung der Bauraumgeometrie voraus. Dieses Problem wird in [18] durch die Optimierung von Algorithmen zur Pfadfindung und Geometriebehandlung prototypisch behandelt und eine Lösung für beliebig komplexe Geometrien vorgestellt. Der Ansatz ermöglicht zum einen die Verlegung und Bündelung einer Vielzahl von Einzelkabeln in großen Bauräumen (dazu auch [45]). Zum anderen unterstützt der Ansatz auch die Generierung von Leitungssatztopologien auf Basis von festen Halterungen (dazu auch [41]). Da sich diese Algorithmen in der Praxis als sehr leistungsfähig erwiesen haben, bilden die Erkenntnisse und Entwurfsentscheidungen aus diesem Ansatz die wesentliche Grundlage für die in dieser Arbeit vorgestellte Architektur. Grundlagen und Stand der Technik 13 Neben dem Entwurf des digitalen 3D-Leitungssatzes bieten aber auch andere Bereiche Potenzial zur Automatisierung. So besteht z. B. die dem Entwurf des 3D-Leitungssatzes nachgelagerte Fertigungsvorbereitung ebenfalls aus repetitiven, zeitaufwändigen und meist manuellen Tätigkeiten. Auch für diesen Bereich wird in [58] ein wesentlicher Beitrag geleistet, indem Technologien zur weitgehenden Automatisierung der Erzeugung von Fertigungszeichnungen für den Leitungssatz entwickelt wurden. 2.2 Algorithmen und Standards Um die technischen Herausforderungen der Automatisierung in der vorliegenden Arbeit zu bewältigen, werden in der Softwarearchitektur verschiedene Algorithmen integriert und bewährte Datenstandards verwendet. Im Folgenden werden Algorithmen und Standards vorgestellt, die für die diese Arbeit von zentraler Bedeutung sind. 2.2.1 Pfadfindung Viele Probleme im Bereich der Technik lassen sich nach [46, S. 73–75, 93] auf das Pro- blem der Suche nach einem Pfad in einem Graphen verallgemeinern. Beispiele für solche Probleme sind das Routing von Telefon- oder Internetverkehr, das Layout von Leiterplat- ten oder die Bewegungsplanung von Robotern. Im Bereich der Künstlichen Intelligenz kann die Pfadfindung (engl. pathfinding) durch Suchalgorithmen gelöst werden. Einer der bekanntesten Vertreter ist der A*-Suchalgorithmus. Im Folgenden werden die Grundlagen zum Verständnis des A*-Algorithmus und der verwendeten parallelen Variante hergeleitet. 2.2.1.1 Graphen Graphen sind nach [27, S. 142ff] grundlegende diskrete Strukturen, die in der Informatik zur Darstellung komplex strukturierter Informationen verwendet werden. Ein Graph G = (V,E) besteht aus einer Menge von Knoten V und einer Menge von Kanten E, die Paare dieser Knoten verbinden. Es gibt verschiedene Arten von Graphen, die häufig in Algorithmen verwendet werden: • Ungerichtete Graphen (engl. undirected graphs) stellen die Kanten E = (u,v) Beziehungen zwischen den Knoten u und v dar, ohne die Richtung der Beziehung zu berücksichtigen. • Gerichtete Graphen (engl. directed graphs) berücksichtigen die Richtung einer Kante E, indem zwischen den Kanten E = (u,v) und E = (v,u) unterschieden wird. 14 2.2 Algorithmen und Standards • Gewichtete Graphen (engl. weighted graphs) ordnen einer Kante E = (u,v) einen numerischen Wert zu, das sogenannte Gewicht (engl. weight). Ein Pfad in einem Graphen stellt die Verbindung zwischen zwei Knoten über eine Liste benachbarter Kanten des Graphen dar. 2.2.1.2 Breitensuche Die Breitensuche (engl. breadth-first search oder kurz BFS) ist nach [46, S. 81ff] ein einfa- cher Suchalgorithmus für Graphen und gehört zur Kategorie der uninformierten Suchal- gorithmen. Der Begriff uninformiert bedeutet, dass diesem Algorithmus keine weiteren Informationen über den Zustand zur Verfügung stehen, die über die in der Problemdefiniti- on angegebenen hinausgehen. Bei der Breitensuche wird zuerst der Startknoten expandiert, dann alle Nachfolger des Startknotens, dann deren Nachfolger und so weiter. Im Allgemei- nen werden alle Knoten einer bestimmten Tiefe des Graphen expandiert, bevor die Knoten der nächsten Ebene expandiert werden. In einem endlichen Graphen findet die Breitensuche immer einen Pfad zwischen zwei Knoten, sofern diese verbunden sind. Die Breitensuche wird als vollständig betrachtet, d. h. wenn es eine Lösung gibt, wird sie diese auch finden. Die Zeitkomplexität des Algorithmus kann als O(|V |+ |E|) beschrieben werden, wobei |V | die Anzahl der Knoten und |V | die Anzahl der Kanten im Graphen darstellt. Im un- günstigsten Fall wird also jeder Knoten und jede Kante expandiert. Die Platzkomplexität kann daher für endliche Graphen mit O(|V |) beschrieben werden. Der Speicherbedarf und die Laufzeit sind daher problematisch. Außerdem ist der resultierende Pfad zwar minimal in Bezug auf die Anzahl der Knoten, aber nicht unbedingt kostenoptimal für gewichtete Graphen. 2.2.1.3 Uniforme Kostensuche Um eine kostenoptimale Lösung für gewichtete Graphen zu finden, kann die Breitensuche nach [46, S. 83ff] zur sogenannten uniformen Kostensuche erweitert werden. Im Gegensatz zur Breitensuche wird bei der uniformen Kostensuche der Knoten n mit den geringsten Pfadkosten g(n) expandiert, die sich aus der Summe aller Gewichte vom Startknoten bis zum aktuellen Knoten n berechnen. Bei der uniformen Kostensuche werden die Knoten also in der Reihenfolge ihrer optimalen Pfadkosten expandiert und nicht in der Reihenfolge der minimalen Anzahl von Expansionsschritten. Die uniforme Kostensuche liefert somit eine kostenoptimale Lösung, kann aber im ungünstigsten Fall eine deutlich höhere Zeit- und Platzkomplexität aufweisen als die Breitensuche. Grundlagen und Stand der Technik 15 2.2.1.4 Tiefensuche Im Gegensatz zur Breitensuche wird bei der Tiefensuche (engl. depth-first search oder kurz DFS) nach [46, S. 85ff] immer zuerst der tiefste Knoten der aktuellen Suche expandiert. Die Tiefensuche ist zwar nicht optimal, hat aber bei wenigen langen Pfaden Vorteile hinsichtlich der Platzkomplexität. 2.2.1.5 Bidirektionale Suche Um den Speicherbedarf und insbesondere die Laufzeit zu reduzieren, können Graphen- Suchalgorithmen nach [46, S. 90f] auch bidirektional umgesetzt werden. Bei der bidirektio- nalen Suche werden zwei parallele Suchvorgänge gleichzeitig ausgeführt: ein Suchvorgang beginnt beim Startknoten und bewegt sich vorwärts, der andere beginnt beim Zielknoten und bewegt sich rückwärts. Ziel ist es, dass sich diese beiden Suchen in der Mitte treffen, wobei der dann gefundene Lösungspfad nicht unbedingt optimal sein muss. 2.2.1.6 Bestensuche Eine deutlich effizientere Suchstrategie verfolgen nach [46, S. 92] die sogenannten in- formierten Such-Algorithmen. Der Begriff informiert bedeutet, dass der Suchalgorithmus problemspezifisches Wissen nutzt, das über die Definition des eigentlichen Problems hinausgeht. Ein solcher Ansatz wird allgemein auch als Bestensuche bezeichnet. Die Bestensuche ist ein Graphen-Suchalgorithmus, bei dem ein Knoten n auf Basis einer Be- wertungsfunktion f (n) zur Expansion ausgewählt wird. Die Bewertungsfunktion wird als Kostenschätzung interpretiert, sodass der Knoten mit der niedrigsten Bewertung zuerst ex- pandiert wird. Die Suchstrategie einer Bestensuche wird also durch die Bewertungsfunktion bestimmt. Teil dieser Bewertungsfunktion f (n) ist in der Regel eine heuristische Funktion h(n), die die günstigsten Kosten des Pfades vom aktuellen Knoten n zu einem Zielknoten schätzt. Heuristische Funktionen sind die gebräuchlichste Form, dem Suchalgorithmus zusätzliches Wissen über das Problem zur Verfügung zu stellen. 2.2.1.7 Greedy Eine einfache Variante der Bestensuche ist nach [46, S. 92f] der sogenannte Greedy- Algorithmus. Diese Suchstrategie expandiert immer den Knoten, der dem Zielknoten am nächsten liegt. Die Bewertungsfunktion entspricht dabei der heuristischen Funktion, d. h. f (n) = h(n). Der Suchvorgang versucht also, sich in jedem Schritt dem Ziel so weit wie 16 2.2 Algorithmen und Standards möglich zu nähern. Mit einer guten heuristischen Funktion kann die Komplexität erheblich reduziert werden, allerdings führt die Strategie in vielen Fällen nicht zu einer optimalen Lösung. 2.2.1.8 A*-Algorithmus Die am weitesten verbreitete Form der Bestensuche ist die in [26] beschriebene A*-Suche. Ihre Funktionsweise ist in [46, S. 93ff] wie folgt zusammengefasst. Die A*-Suche bewertet Knoten durch eine Kombination aus optimalen Pfadkosten und einer heuristischen Funktion: f (n) = g(n)+h(n). Da g(n) die Pfadkosten vom Startknoten zum Knoten n und h(n) die geschätzten Kosten des optimalen Pfades von n zum Ziel darstellen, definiert f (n) insgesamt die geschätzten Kosten des optimalsten Pfades vom Startknoten zum Ziel durch n. Um den kostengünstigsten Pfad zu finden, muss also immer der Knoten mit dem kleinsten Wert von g(n)+h(n) expandiert werden. Sofern die heuris- tische Funktion h(n) bestimmte Bedingungen erfüllt, ist die A*-Suche sowohl vollständig als auch optimal. Die erste Bedingung ist, dass h(n) niemals die Kosten zum Erreichen des Ziels überschätzt (zulässige Heuristik). Da g(n) die tatsächlichen Kosten sind, um n auf dem aktuellen Pfad zu erreichen, und f (n) = g(n)+h(n), ergibt sich als unmittelbare Kon- sequenz, dass f (n) auch niemals die tatsächlichen Kosten eines Pfades durch n überschätzt. Ein offensichtliches Beispiel für eine zulässige Heuristik im geometrischen Kontext ist die euklidische Distanz von Knoten n zum Ziel. Eine zweite Bedingung ist die Monotonie (alt. Konsistenz) der Heuristik. Die Heuristik h(n) gilt als monoton, wenn für jeden Knoten n und jeden Nachfolger n′ von n die geschätzten Kosten für das Erreichen des Ziels von n aus nicht größer sind als die Schrittkosten für den Weg zu n′ plus die geschätzten Kosten für das Erreichen des Ziels von n′ aus: h(n) ≤ c(n,n′)+ h(n′). Die euklidische Distanz als Heuristik ist ebenfalls monoton. Für jede monotone Heuristik gilt der A*-Algorithmus auch als optimal effizient. Das bedeutet, dass kein anderer optimaler Algorithmus garantiert weniger Knoten expandiert als der A*-Algorithmus. Zusammenfassend kann gesagt werden, dass der A*-Algorithmus als vollständig, optimal und optimal effizient gilt. Trotz dieser Eigenschaft ist die Platzkomplexität vergleichbar mit allen anderen Graphen-Suchalgorithmen, da der A*-Algorithmus alle expandierten Knoten speichern muss. Aufgrund der Komplexität werden oft Varianten verwendet, die nur suboptimale Lösungen liefern. In jedem Fall bietet die Verwendung einer guten Heu- ristik immer noch enorme Einsparungen gegenüber der Verwendung einer uninformierten Suche. Grundlagen und Stand der Technik 17 Bidirektionaler A*-Algorithmus. Für den A*-Algorithmus sind auch bidirektionale Varianten bekannt und in [38] und [39] beschrieben. Dabei werden beide A*-Suchvorgänge gleichzeitig zwischen einem Startknoten s und einem Endknoten t durchgeführt. Auf der einen Seite wird s als Start und t als Ziel gewählt, auf der anderen Seite werden s und t ver- tauscht. Unabhängig davon wird eine Seite als Hauptseite (engl. primary, ▷) und die andere als Gegenseite (engl. opposite, ◁) definiert. In einer ersten Phase (main phase) breiten sich beide Suchvorgänge so lange aus, bis sie sich im Suchraum zwischen s und t treffen, also beide denselben Knoten n expandiert haben und somit ein Verbindungspfad gefunden ist, der allerdings nicht optimal sein kann. In der anschließenden zweiten Phase (post-phase) wird dann der tatsächlich optimale Pfad gesucht. Diese zweite Phase kann deutlich verkürzt werden, wenn sogenannte balancierte Heuristiken (engl. balanced heuristic) eingesetzt werden. Eine Heuristik heißt balanciert, wenn die Summe der Heuristiken beider Seiten für jeden Knoten n konstant bleibt: h▷(n)+h◁(n) = c. NBA*- und PNBA*-Algorithmus. Eine Weiterentwicklung stellt der sogenannte NBA*- Algorithmus (engl. Abk. für New Bidirectional A*) dar, der in [38] und [39] vorgestellt wird. Dieser verallgemeinert die Heuristik auch auf nicht-balancierte Heuristiken und redu- ziert damit Laufzeit und Speicherbedarf. Wie bei jedem bidirektionalen Suchalgorithmus werden zwei Suchvorgänge gleichzeitig, aber nicht notwendigerweise parallel ausgeführt. Eine übliche Methode, um eine gleichzeitige Ausführung zu erreichen, ist die alternierende Ausführung der einzelnen Expansionsschritte. Eine Implementierung mit echter paralleler Berechnung stellt der sogenannte PNBA*- Algorithmus (engl. Abk. für Parallel New Bidirectional A*) dar, der in [44] vorgestellt wird. Er ähnelt dem NBA*-Algorithmus, nutzt aber Speicherarchitekturen, die auf Parallelität ausgelegt sind. 2.2.2 Mehrkörpersimulation Ein Mehrkörpersystem besteht nach [21, S. 1, 39, 60f] aus einer Menge von Starrkörpern, die durch Gelenke miteinander verbunden sind und auf die unterschiedliche Kräfte ein- wirken können. Die Mehrkörpersimulation beschreibt die Modellierung und Simulation von Mehrkörpersystemen. Die Konzepte zur Simulation von Starrkörpern (engl. rigid body simulation) existieren schon lange, wurden aber durch den Einsatz von Computern neu belebt und verändert. Mit seiner Rechenleistung kann der Computer die Kräfte, Beschleu- nigungen und verwandte Parameter berechnen, die mit der Bewegung eines Starrkörpers zusammenhängen. Dabei dienen die Bewegungen der Starrkörper als Näherung für ein rea- 18 2.2 Algorithmen und Standards les physikalisches System. Heutzutage werden Mehrkörpersimulationen in einer Vielzahl von Anwendungen eingesetzt, darunter insbesondere Computerspiele, Animations- und Virtual-Reality-Software, Simulatoren, Bewegungssteuerungssysteme und verschiedene Konstruktions- und Analysewerkzeuge. Starrkörper. Ein Starrkörper (engl. rigid body) ist nach [17, S. 14f] ein physikalisches Konzept, das einen idealisierten Körper darstellt. Er wird durch den Bereich seiner Masse definiert. Dieser besteht aus einer endlichen Menge von Massenpunkten, die eine unver- änderliche relative Position zueinander haben. Der Starrkörper bleibt also auch unter dem Einfluss äußerer Kräfte in Form und Größe unverändert (starr). Ein Starrkörper hat eine Lage und eine Orientierung sowie eine lineare und eine rotatorische Geschwindigkeit. Die Dynamik eines Starrkörpers wird durch seine Bewegungsgleichung beschrieben, die den Zusammenhang zwischen den auf das System einwirkenden Kräften und den von ihnen erzeugten Beschleunigungen beschreibt. Die Lösung dieser Bewegungsgleichungen lie- fert eine Beschreibung der Positionen, Bewegungen und Beschleunigungen der einzelnen Starrkörper eines gesamten Mehrkörpersystems in Abhängigkeit von der Zeit. Kontaktgeometrie. Die Kontaktgeometrie bezieht sich nach [21, S. 39f, 227] auf die geometrische Form (engl. shape), die einem starren Objekt zugeordnet werden kann. Eine Geometrie für Starrkörper wird in der dynamischen Mehrkörpersimulation benötigt, um Kollisionen zwischen den Körpern identifizieren zu können. Gelenk. Nach [21, S. 39] besteht die Wirkung eines Gelenks (engl. joint) darin, den beiden Starrkörpern, die es verbindet, eine Bewegungseinschränkung (engl. constraint) aufzuerlegen, indem es Relativbewegungen in bestimmten Richtungen zulässt, in anderen jedoch nicht. Genauer gesagt besteht die Wirkung eines Gelenks darin, eine Zwangskraft in das System einzuführen. Diese Kraft hat die besondere Eigenschaft, dass ihr genauer Wert unbekannt, ihre Wirkung auf das System jedoch bekannt ist. Sie nimmt den Wert an, der erforderlich ist, damit die resultierende Bewegung der Bewegungseinschränkung entspricht. Kollisionserkennung. Die Bewegungen der Starrkörper in einem Mehrkörpersystem können zu Durchdringungen zweier Körper mit Kontaktgeometrie führen. Eine natürliche Bedingung für ein Mehrkörpersystem ist, dass sich die Starrkörper niemals durchdrin- gen. Die sogenannte Kollisionserkennung (engl. collision detection) beschreibt nach [21, Grundlagen und Stand der Technik 19 S. 228f] und [17, S. 295f] den Prozess der Bestimmung, ob sich zwei Körper gerade schneiden oder zu einem zukünftigen Zeitpunkt schneiden werden. In einer dynamischen Simulation wird ermittelt, wo und wann sich die Körper schneiden werden und daraus eine Kollisionsantwort (engl. collision response) berechnet. Bei der Anwendung der Kollisi- onsantwort werden zum Zeitpunkt der Kollision Impulse auf die beiden Körper ausgeübt, damit diese nicht ineinander eindringen und ihre Bewegung physikalisch korrekt fortsetzen, z. B. nach dem elastischen Stoß. Sowohl die Kollisionserkennung als auch die Berechnung der Kollisionsantwort sind rechenintensive Prozesse. 2.2.3 Datenstandards Zur Beschreibung und Umsetzung der in dieser Arbeit vorgestellten Softwarearchitektur werden verschiedene Software-Standards verwendet. In diesem Abschnitt werden daher zunächst die relevanten Elemente der UML und deren grafische Notation vorgestellt. Dar- über hinaus wird der Datenstandard VEC zur Beschreibung von Leitungssätzen eingeführt und kurz erläutert. 2.2.3.1 UML Die UML (engl. Abk. für Unified Modeling Language) ist nach [10, S. 1] eine Modellie- rungssprache für die Analyse, den Entwurf und die Implementierung softwarebasierter Systeme sowie für die Modellierung von Geschäftsprozessen und ähnlichen Abläufen. Sie basiert auf bewährten Verfahren aus den Bereichen Modellierungssprachen, objektorientier- te Programmierung und Architekturbeschreibungssprachen. Die abstrakte Syntax der UML bietet Systemarchitekten, Softwareingenieuren und Softwareentwicklern eine Vielzahl von Modellierungskonzepten, um Teil- oder Gesamtmodelle großer Systeme zu entwerfen. Die Semantik der Konzepte ist dabei technologieunabhängig und beschreibt lediglich, wie die Konzepte von Computern umgesetzt werden sollen. Darüber hinaus spezifiziert die UML eine Vielzahl von Diagrammtypen zur grafischen Darstellung der einzelnen Modellierungs- konzepte. Dies ermöglicht auch den Einsatz grafischer Modellierungswerkzeuge sowie den Austausch von Modellinformationen zwischen verschiedenen Werkzeugen. Klasse. Die Klasse (engl. class oder classifier) ist nach [10, S. 99ff] ein grundlegendes Konzept der UML. Eine Klasse repräsentiert eine Klassifizierung von Instanzen entspre- chend ihrer Merkmale. Diese Merkmale umfassen unter anderem die Eigenschaften und das Verhalten der Instanzen und sind ein Teil (engl. member) der Klasse. Die Eigenschaften 20 2.2 Algorithmen und Standards werden durch Attribute (engl. attributes), das Verhalten durch Operationen (engl. operati- ons) definiert. Die Standardnotation für eine Klasse ist ein Rechteck mit durchgezogener Linie, das den Namen der Klasse enthält. Der Name der Klasse ist zentriert und fett ge- druckt und beginnt mit einem Großbuchstaben. Der Name einer abstrakten Klasse ist zusätzlich kursiv gedruckt und wird mit der textuellen Anmerkung {abstract} unter dem Namen versehen. Durch horizontale Linien unter dem Namen können Bereiche für die unterschiedlichen Merkmale der Klasse definiert werden. Der erste Bereich unter dem Na- men enthält z. B. die Liste der Eigenschaften. Der zweite Bereich unter den Eigenschaften enthält die Operationen (siehe Abb. 2.3). Klassen werden durch Generalisierungen (engl. generalizations) hierarchisch organisiert. Eine Generalisierung definiert nach [10, S. 102, 138] eine taxonomische Beziehung zwi- schen einer allgemeineren Klasse und einer spezifischeren Klasse. Wenn eine (spezifische- re) Klasse generalisiert wird, erbt sie bestimmte Merkmale der allgemeineren Klasse. D. h., sie verhält sich so, als ob die Merkmale der allgemeineren Klasse in ihr selbst defi- niert wären. Eine Generalisierung wird als Linie mit einem nicht ausgefüllten Dreieck als Pfeilspitze zwischen den Klassen dargestellt. Die Pfeilspitze zeigt auf die Klasse, die die allgemeinere Klasse darstellt (siehe Abb. 2.3). Schnittstelle. Eine Schnittstelle (engl. interface) ist nach [10, S. 171f, S. 211] eine Art Klasse, in der eine Menge von öffentlichen Merkmalen nur deklariert wird. Inter- faces können nicht instanziiert werden, sondern werden von einer Klasse realisiert und implementiert. Das bedeutet, dass diese realisierende Klasse eine öffentliche Fassade prä- sentiert, die der Spezifikation der Schnittstelle entspricht. Eine Schnittstelle wird wie eine Klasse dargestellt und zusätzlich durch das Schlüsselwort≪interface≫ über dem Namen der Schnittstelle gekennzeichnet. Eine Realisierungsbeziehung zwischen einer Klasse und einer Schnittstelle wird durch eine Realisierung (engl. Realization) definiert. Eine Realisie- rung wird durch eine gestrichelte Linie mit einem nicht ausgefüllten Dreieck als Pfeilspitze dargestellt (siehe Abb. 2.3). Assoziation. Eine Assoziation (engl. association) spezifiziert nach [10, S. 199ff] eine semantische Beziehung zwischen zwei (binär) oder mehr Klassen. Eine Assoziation de- klariert, dass Verbindungen (engl. links) zwischen den Instanzen der assoziierten Klassen existieren können. Die Enden von Assoziationen können unter anderem mit Multiplizitäten und Navigierbarkeiten versehen werden. Die Multiplizitäten an den anderen Enden der Assoziation bestimmen die Anzahl der Links. Navigierbarkeit bedeutet, dass Instanzen, die Grundlagen und Stand der Technik 21 zur Laufzeit durch Links verbunden sind, von Instanzen an anderen Enden der Assoziation effizient angesprochen werden können. Eine binäre Assoziation wird normalerweise durch eine durchgezogene Linie dargestellt, die zwei Klassen verbindet, oder durch eine durchge- zogene Linie, die eine einzelne Klasse mit sich selbst verbindet. Eine offene Pfeilspitze am Ende einer Assoziation zeigt explizit an, dass dieses Ende navigierbar ist (siehe Abb. 2.3). associationName 0..* ClassName + attributeName: AttributeType = initialValue + operationName(parameterName: ParameterType): ReturnType AbstractClassName {abstract} �interface� InterfaceName Abbildung 2.3: Klassen und Schnittstelle Komponente. Eine Komponente (engl. component) ist nach [10, S. 208f] eine modulare Einheit mit klar definierten Schnittstellen, die innerhalb eines Softwaresystems beliebiger Größe und Komplexität verwendet wird. Sie ist eine in sich geschlossene und austauschbare Einheit, die den Zustand und das Verhalten von Klassen kapselt und entweder während des Entwurfs oder zur Laufzeit durch eine andere Komponente mit ähnlicher Funktionalität und kompatiblen Schnittstellen ersetzt werden kann. Eine Komponente wird ähnlich wie eine Klasse als Rechteck dargestellt, jedoch mit einem speziellen Komponentensymbol in der rechten oberen Ecke. Dieses Symbol besteht aus einem kleinen Rechteck, aus dem links zwei kleinere Rechtecke herausragen (siehe Abb. 2.4). Paket. Das Paket (engl. package) spielt nach [10, S. 29, 241ff] eine zentrale Rolle bei der Strukturierung und Organisation von Modellen in der UML. Es dient dazu, Elemente wie Klassen, Interfaces und andere Modellelemente zu gruppieren und hierarchisch zu organisieren. Dabei stellt es einen Namensraum zur Verfügung, der eine eindeutige Iden- tifizierung und Organisation der gruppierten Elemente ermöglicht. Darüber hinaus kann ein Paket den Inhalt anderer Pakete importieren, indem es die darin enthaltenen Elemente in seinen eigenen Namensraum integriert. Ein Paket wird in Diagrammen durch eine Re- gisterkarte (alt. Reiter, Tab) in Form eines großen Rechtecks mit einem kleinen Rechteck an der linken Seite des großen Rechtecks dargestellt. Der Import eines Pakets wird durch einen gestrichelten Pfeil mit offener Spitze symbolisiert, der vom importierenden Paket zum importierten Paket zeigt (siehe Abb. 2.4). 22 2.3 Softwareplattform und Bibliotheken ComponentName PackageNameA PackageNameB Abbildung 2.4: Pakete und Komponente 2.2.3.2 VEC Der VEC (Abk. für Vehicle Electric Container) ist nach [3, S. 1] ein etablierter Standard für den digitalen Austausch von Bordnetzdaten. Seit Juni 2011 wird dieser Standard vom VDA (Abk. für Verband der Automobilindustrie) und ProSTEP iViP veröffentlicht und von einer Projektgruppe Fahrzeugelektrik definiert und gepflegt. Diese Projektgruppe setzt sich aus Automobilherstellern und Kabelbaum-Konfektionären zusammen. Hauptziel des VEC- Standards ist laut [3, S.3f] die vollständige elektronische Auswertbarkeit, Standardisierung und Offenheit für den Austausch aller Daten der Bordnetzentwicklung. Das Modell des Standards ist in [29] detailliert definiert und umfasst eine umfangreiche Sammlung von über 400 Klassen, die in der UML beschrieben sind. Die Klassen decken verschiedene Bereiche der Leitungssatzentwicklung ab, darunter Elektrologik, Geometrie, Komponen- tenentwicklung, Produktionsdefinition und Fertigung bzw. Fertigungsvorbereitung. 2.3 Softwareplattform und Bibliotheken Die automatisierte Generierung von Leitungssätzen ist nach [49, S. 5f] ein notwendiger Schritt im Prozess des automatisierten Entwurfs komplexer Systeme. Die umfassende Beschreibung solcher Systeme wird durch die Verwendung graphenbasierter Entwurfsspra- chen ermöglicht. Diese Automatisierung kann mit Hilfe der Software Design Cockpit 43® erfolgen, die speziell für die Erstellung und Ausführung graphenbasierter Entwurfsspra- chen entwickelt wurde. Die vorgestellte Architektur wird im technologischen Rahmen graphenbasierter Entwurfss- prachen realisiert und eingesetzt. Der folgende Abschnitt gibt eine kurze Einführung in das Konzept dieser Entwurfssprachen sowie in die Funktionalitäten der Software Design Cockpit 43®. Grundlagen und Stand der Technik 23 2.3.1 Graphenbasierte Entwurfssprachen Graphenbasierte Entwurfssprachen (engl. graph-based design languages) sind nach [49, S. 6f] ein neuer Ansatz zur ganzheitlichen Beschreibung von Ingenieurentwürfen. Ähnlich wie in natürlichen Sprachen bilden Wörter das Vokabular und Regeln die Grammatik. Die Wörter repräsentieren die Bausteine des Entwurfs, auf die die Regeln angewendet werden. Das Vokabular wird als UML-Klassenmodell beschrieben, während die Regeln als Mo- delltransformationen fungieren und in einem erweiterten UML-Objektmodell beschrieben werden. Das Produktionssystem, bestehend aus einem Ablaufmodell der Regeln, wird in einem UML-Aktivitätsmodell beschrieben. Durch die Ausführung des Produktionssystems wird der gesamte Entwurf erstellt und in einem zentralen Modell, dem Entwurfsgraph (engl. design graph), gespeichert. Aus dem Entwurfsgraphen können nun domänenspe- zifische Modelle wie 3D-Geometrie, Finite-Elemente-Darstellungen oder CFD-Modelle abgeleitet werden. Eine softwaretechnische Implementierung zur Erstellung und Ausfüh- rung von Entwurfssprachen ermöglicht somit die computergestützte Automatisierung von Entwurfs- und Fertigungswissen, was zu effizienteren Entwurfszyklen führt. 2.3.2 Design Cockpit 43® Das Design Cockpit 43® (kurz DC43®) ist eine von der IILS mbH entwickelte Software zur Entwicklung graphenbasierter Entwurfssprachen auf Basis der Eclipse Modeling Frame- work (kurz EMF) [49, S. 7f]. Als integrierte Entwicklungsumgebung (engl. Integrated Development Environment oder kurz IDE) stellt DC43® eine Vielzahl von Funktionalitäten zum Erstellen, Ausführen und Debuggen sowie zum (domänenspezifischen) Export gra- phenbasierter Entwurfssprachen zur Verfügung. Die Erstellung von Vokabular, Regeln und Produktionssystemen erfolgt grafisch oder Java-Code-basiert über UML-Schnittstellen. Die UML-Modelle können über entsprechende Diagrammtypen wie UML-Klassendiagramme und UML-Aktivitätsdiagramme visualisiert werden. Die Ausführung und das Debugging erfolgt über den Entwurfssprachen-Compiler, wobei der resultierende Entwurfsgraph zu Analysezwecken ebenfalls grafisch visualisiert werden kann. Der Export des Entwurfs- graphen in domänenspezifische Modelle (CAD, MKS, FEM, CFD und mehr) erfolgt über sogenannte Plugins. Die Plugin-Technologie des Eclipse-Frameworks ermöglicht eine fle- xible Erweiterung der Funktionalität der Software. 24 2.3 Softwareplattform und Bibliotheken Die Software DC43® integriert eine Vielzahl von Bibliotheken zur Unterstützung der Modellgenerierung, entweder als Kernfunktionalität oder als Plugin-Funktionalität, die auch von der Implementierung zur automatischen Generierung von Leitungssätzen genutzt werden. Sie sind hier im Folgenden kurz aufgelistet: Lösungspfadgenerator. Der Lösungspfadgenerator (engl. Solution Path Generator oder kurz SPG) ist eine Funktionalität zur Erzeugung und Lösung komplexer Gleichungs- systeme mit Hilfe eines integrierten Computeralgebrasystem (kurz CAS). Geometriegenerierung. Die Generierung und Bearbeitung von 3D-Geometrie erfolgt über eine Schnittstelle zum integrierten CAD-Kernel Open CASCADE® (kurz OCC). 3D-Visualisierung. Die Visualisierung von Geometriedaten erfolgt über eine Schnitt- stelle zum integrierten Visualierungsframework VTK (engl. Abk. für Visualization Toolkit), beschrieben in [52]. Physiksimulation. Die Simulation der Starrkörperphysik erfolgt über eine Schnittstelle zur Bullet Physics Library, die in [12] beschrieben ist. Leitungssatz. Die Implementierung der in dieser Arbeit vorgestellten Architektur zur Generierung von Leitungssätzen wurde ebenfalls als Plugin für DC43® realisiert. 3 Anforderungen und Konzept Ziel dieses Kapitels ist es, die Anforderungen an die Softwarearchitektur für eine automa- tisierte Generierung von Leitungssätzen abzuleiten und zu erläutern. Basierend auf den Anforderungen wird anschließend ein Konzept für einen automatisierten Generierungspro- zess und die entsprechende Softwarearchitektur skizziert. 3.1 Anforderungen Für eine produktive Anwendung der automatisierten Generierung von Leitungssätzen müs- sen die unterschiedlichen Anforderungen der Industrie berücksichtigt werden, wobei die Anforderungen verschiedener Industriezweige wie Luft- und Raumfahrt oder Automo- bilbau durchaus unterschiedlich sein können. Darüber hinaus sind verschiedene Phasen des Systementwurfs wie Vorbereitung und Konzeption oder Entwurf und Entwicklung zu berücksichtigen. Ziel der Konzeptionsphase ist es z. B., mit vergleichsweise geringem Zeitaufwand eine grobe Abschätzung des Leitungssatzes vornehmen zu können, während der detaillierte Entwurf des Leitungssatzes fertigungsgerechte Daten liefern muss. Es ist auch nicht auszuschließen, dass sich aus den individuellen Entwurfsprozessen eines Unternehmens, zusätzliche spezielle Anforderungen an den digitalen Leitungssatz ergeben. 3.1.1 Prozess-Randbedingungen Ausgangspunkt für die Konstruktion eines 3D-Leitungssatzes sind die Randbedingungen wie Bauraumgeometrie, Komponentendaten, Elektrologik oder spezifische Konstruktions- regeln. Diese werden in der Regel in verschiedenen spezialisierten Softwarewerkzeugen erstellt und können aus diesen als Datensatz exportiert werden. Für die Verarbeitung im automatisierten Generierungsprozess müssen diese Daten dann importiert werden. 3.1.1.1 Bauraumgeometrie Die Bauraumgeometrie umfasst alle geometrischen Entitäten, die nicht Teil des Leitungssat- zes sind. Dazu gehören die durch den Leitungssatz verbundenen E/E-Komponenten, vom 26 3.1 Anforderungen Leitungssatz unabhängige Systemkomponenten und Strukturteile sowie unsichtbare Kon- struktionshilfskörper oder -flächen. Entscheidend für den automatisierten Generierungspro- zess ist hierbei, ob diese geometrischen Entitäten vom zu generierenden Leitungssatz nicht geschnitten werden dürfen, also als Hindernisse zu berücksichtigen sind. Bauraumgeome- trien können entweder als CAD-Körper oder als tesselierte Oberflächenbeschreibungen vorliegen. Häufig verwendete Datenformate sind z. B. STEP, JT oder STL und müssen in den automatisierten Generierungsprozess importiert werden können. 3.1.1.2 Komponentendaten Unter dem Begriff Komponentendaten werden die logischen und geometrischen Spezifika- tionen aller Komponenten eines Leitungssatzes zusammengefasst (siehe Abschnitt 2.1.2.2). Dazu gehören z. B. Steckverbinder, Halterungen oder die Leitungen selbst. Geometrische Komponentendaten wie Steckverbindertypen oder Halterungstypen liegen in modernen Prozessen als sogenannte qualifizierte Geometrien in zentralen Datenbanken vor. Es kann aber auch vorkommen, dass die Daten über verschiedene Datenbanken als logische und geometrische Informationen fragmentiert vorliegen und erst durch den automatisierten Ge- nerierungsprozess in einem Teilprozess importiert und zusammengeführt werden müssen. Als Austauschformate werden hier typischerweise CSV, XLS oder XML für die logischen Informationen und STEP, JT oder STL für die geometrischen Informationen verwendet. 3.1.1.3 Elektrologik In der Elektrologik werden alle Leitungsverbindungen unter Angabe des zu verwenden- den Leitungstyps definiert (siehe Abschnitt 2.1.2.1). Eine einzelne Verbindungsdefinition umfasst hier zusätzlich mindestens die Identifikation der Instanz einer E/E-Komponente, die Identifikation einer Instanz des angesteckten Steckverbinders an dieser Komponente sowie die Nummer des Pins innerhalb des Steckverbinders für beide Enden der Verbin- dung. Die Elektrologik wird in der Regel in spezialisierten Softwarewerkzeugen erstellt und muss im XLS- oder XML-Format aus der Softwarearchitektur in den automatisierten Generierungsprozess importierbar sein. 3.1.1.4 Entwurfsregeln Entwurfsregeln wie z. B. Mindestabstände zwischen EMV-Klassen oder Mindestbiegeradi- en von Leitungssegmenten sind entweder in entsprechenden Normen oder in firmeninternen Konstruktionsrichtlinien festgelegt. Diese Daten liegen in der Regel nur selten digital und Anforderungen und Konzept 27 maschinell verarbeitbar vor. Der automatisierte Generierungsprozess muss daher die Mög- lichkeit bieten, das Datenmodell für die automatisierte Leitungssatzgenerierung um diese Randbedingungen als Systemparameter zu erweitern. 3.1.1.5 Konsistenz und Vollständigkeit Da die oben aufgeführten Daten der Bauraumgeometrie, der Komponentendaten und der Elektrologik in der Regel aus unterschiedlichen Softwaretools und Datenbanken stammen, kann es zu Inkonsistenzen zwischen den Datensätzen kommen. Insbesondere in der Kon- zeptphase, aber auch in den frühen Entwicklungsphasen ist die Wahrscheinlichkeit sehr hoch, dass die Daten unvollständig sind. Die Softwarearchitektur muss daher in der Lage sein, mit inkonsistenten und unvollständigen Daten umzugehen. 3.1.1.6 Ausnahmen Grundsätzlich wird angestrebt, aus den vorhandenen Datensätzen und den allgemeinen Entwurfsregeln vollautomatisch einen Leitungssatz zu generieren. In der Praxis ist jedoch eine strikte Einhaltung aller Regeln, insbesondere bei komplexen Systemen, kaum möglich. Beim Entwurf von Leitungssätzen werden daher in der Regel eine Vielzahl von system-, produkt- oder unternehmensspezifischen Ausnahmen zugelassen. Da es nicht möglich ist, diese individuellen Ausnahmen vorab vollständig in generischen Algorithmen abzubilden, muss die Softwarearchitektur die Möglichkeit bieten, individuelle Entwurfsentscheidungen in allen Bereichen des Leitungssatzentwurfs zu berücksichtigen. 3.1.2 Effizienz des Prozesses Der automatisierte Prozess muss einen erheblichen Geschwindigkeitsvorteil gegenüber dem konventionellen, manuellen Konstruktionsprozess aufweisen. Dies betrifft zum einen den Aufbau eines Modells, aber auch die Verarbeitung der im Entwicklungsprozess häufig auftretenden Änderungen. 3.1.2.1 Aufbau eines Modells Beim Aufbau eines Modells müssen die notwendigen Randbedingungen effizient definiert werden können. Dies gilt einerseits für die Definition der Bauraumgeometrie, der Kompo- nentendaten und der Elektrologik, die in vielen Fällen auch als vorgegebene Datensätze aus anderen Quellen importiert und zusammengeführt werden müssen. Andererseits gilt 28 3.1 Anforderungen dies auch für die Definition der algorithmischen Regeln zur Generierung der Leitungssatz- architektur. 3.1.2.2 Verarbeitung von Änderungen Änderungen von Randbedingungen machen einen Großteil des Aufwands in der modernen Entwicklung von Leitungssätzen aus. Die effiziente Durchführung eines Änderungsprozes- ses spielt daher in der Softwarearchitektur eine sehr wichtige Rolle. Folgende Fälle treten dabei besonders häufig auf: • Positions- oder Lageänderungen von Systemkomponenten innerhalb eines Leitungs- satzes oder in einen anderen Leitungssatz hinein • Überschneidung mit neuen oder geänderten Systemkomponenten • Änderungen der Elektrologik • Änderung des Leitungsschutzes • Änderung des Befestigungskonzepts • Änderungen von E/E-Komponenten • Anpassung einzelner Leitungslängen für Fertigung oder Integration • Änderung der Bauraumgeometrie • Änderungen von EMV-Klassifizierungen • Änderung der Mindestabstände zu Systemkomponenten 3.1.3 Qualität des Leitungssatzes Die wichtigsten Anforderungen betreffen die Qualität des digitalen Leitungssatzes. Wie bei der manuellen Konstruktion in einem CAD-System müssen auch bei der algorithmischen Generierung von digitalen Leitungssätzen bestimmte Randbedingungen berücksichtigt werden. Dabei gibt es allgemeine Randbedingungen, die für jeden Leitungssatz gelten, und speziellere Randbedingungen, die nur für bestimmte Systemanwendungen gelten. Die wichtigsten Randbedingungen wurden aus [43], [24], [54] und [47] zusammengestellt und sind hier im Folgenden aufgelistet. 3.1.3.1 Leitungslänge Da sich eine große Leitungslänge negativ auf die elektrische Leistungsfähigkeit der Leitun- gen und auf die Kosten des Leitungssatzes auswirkt, ist die Minimierung der Leitungslänge das Grundprinzip bei der Auslegung von Leitungssätzen. Die meisten anderen Anforderun- gen stehen dieser Längenoptimierung in der Regel entgegen. Anforderungen und Konzept 29 3.1.3.2 Biegeradien Im generierten Leitungsverlauf dürfen bestimmte Mindestbiegeradien nicht unterschritten werden. Zum einen gibt es hier den vom Leitungshersteller in der Leitungsspezifikation beschriebenen Mindestbiegeradius, bei dessen Unterschreitung die physikalische Integri- tät der Leitung verletzt wird und eine fehlerfreie Funktionalität nicht mehr gewährleistet werden kann. Zum anderen gibt es auch system- oder firmenspezifische Vorgaben für Mindestbiegeradien der Leitungssatzsegmente, die meist aus Fertigungs- oder Integrations- anforderungen abgeleitet werden. 3.1.3.3 Befestigung von Leitungen Um Beschädigungen und Leitungsbrüche zu vermeiden, müssen Leitungen, die Beschleu- nigungs- oder Schwingungskräften ausgesetzt sind, in bestimmten Mindestabständen an geeigneten Stellen im Bauraum befestigt werden. 3.1.3.4 Bündelung von Leitungen Um die Anzahl der Befestigungen gering zu halten, ist es zweckmäßig, Einzelleitungen gebündelt zu verlegen und zu befestigen. Dies geschieht in der Regel durch das Zusam- menfassen mehrerer Leitungen in Leitungssatzsegmente. Abhängig vom verwendeten Befestigungsverfahren kann bei der Bündelung gefordert werden, dass ein bestimmter maximaler Segmentdurchmesser nicht überschritten wird. 3.1.3.5 Kollisionsfreiheit Es ist sicherzustellen, dass die Segmente und damit die Leitungen des Leitungssatzes sich nicht mit der bestehenden Bauraumgeometrie geometrische überschneiden. Dies gilt auch für die Segmente untereinander, mit Ausnahme der Bereiche in der Nähe der Segmentaus- bindungen. 3.1.3.6 Mindestabstand zwischen Systemkomponenten und Leitungen Systemkomponenten, die Wärme oder elektromagnetische Wellen abstrahlen oder mecha- nischen Bewegungen ausgesetzt sind, können die physikalische Integrität einer Leitung gefährden. Es kann daher erforderlich sein, bei der Verlegung der Leitungen einen Min- destabstand zu diesen Systemkomponenten einzuhalten. Auch bei der Bündelung von 30 3.1 Anforderungen Leitungen ist zu beachten, dass bei bestimmten Systemen Leitungen unterschiedlicher EMV-Klassen nur mit einem Mindestabstand zueinander verlegt werden dürfen. 3.1.3.7 Genauigkeit Um den generierten Leitungssatz fertigen zu können, muss der Verlauf der Leitungen und die daraus resultierende Leitungslänge unter Berücksichtigung der Fertigungstoleranzen der tatsächlichen Länge im System entsprechen. Dies spielt später in der Berechnung der Massen oder einer Einbausimulation, für die ggf. auf Überlängen gefordert werden, eine wichtige Rolle. 3.1.4 Softwareentwurf Für einen produktiven Einsatz der automatisierten Generierung von Leitungssätzen in Unternehmen muss eine Implementierung der Softwarearchitektur in der Regel in bereits bestehende, individuelle Software- und Prozesslandschaften integriert werden. Daraus lassen sich verschiedene spezifische Anforderungen an die Softwarearchitektur ableiten. 3.1.4.1 Datenmodelle Für eine gute Integration in die Softwarelandschaft der Industrie ist es wichtig, dass dem digitalen Leitungssatz ein robustes und langlebiges Datenmodell zugrunde liegt. Es muss möglich sein, darin die notwendigen Randbedingungen für den Prozess, aber auch den resultierenden Leitungssatz in der geforderten Qualität abbilden zu können. Die Softwarear- chitektur muss daher auch in der Lage sein, Informationen zwischen den Datenmodellen auszutauschen. 3.1.4.2 Flexibilität und Erweiterbarkeit Wie in Abschnitt 2.1.3 beschrieben, ist die Bordnetzentwicklung einem ständigen Wandel unterworfen. Auch die verwendeten Algorithmen und Technologien entwickeln sich, wie in der Softwareentwicklung üblich, ständig weiter. Daher ist es wichtig, die Architektur so modular zu gestalten, dass die verschiedenen Teile der Softwarearchitektur leicht aus- tauschbar und erweiterbar sind. Dieser modulare Ansatz soll auch die Wart- und Testbarkeit erhöhen, was insbesondere bei den komplexen Algorithmen zur Pfadfindung wichtig ist. Anforderungen und Konzept 31 3.1.4.3 3D-Visualisierung der Prozessschritte Eines der wichtigsten Ergebnisse des automatisierten Prozesses ist die 3D-Geometrie des Leitungssatzes. Wie bei allen geometrischen Entwurfsprozessen kann eine gute Visuali- sierung zum besseren Verständnis der Ergebnisse beitragen und die Fehlersuche erheblich erleichtern. Daher ist es wichtig, dass die Softwarearchitektur nicht nur die Ergebnisse, sondern auch die automatisierten Teilschritte dreidimensional visualisieren kann. 3.1.4.4 Systemanforderungen Für eine gute Integration in bestehende Entwicklungsprozesse ist es von Vorteil, wenn eine Implementierung der Softwarearchitektur auf aktuellen Rechnersystemen lauffähig ist, die derzeit für den manuellen Entwurf von Leitungssätzen verwendet werden. Dies bedeutet, dass die Anforderungen der verwendeten Algorithmen an Massenspeicher, Arbeitsspeicher und CPU nicht höher sein sollten als die Systemanforderungen der Softwarewerkzeuge für die Entwicklung der Systemkomponenten oder der Elektrologik. 3.2 Konzept Aus den in den vorangegangenen Abschnitten zusammengetragenen Anforderungen soll im Folgenden ein vereinfachtes Konzept für den Prozess der automatisierten Generierung von Leitungssätzen abgeleitet werden. In einem ersten Schritt wird ein Prozessablauf skizziert, der die Grundlage für das Konzept bildet. Anschließend werden die Softwarefunktionalitä- ten zur Realisierung der Prozessschritte vereinfacht dargestellt. 3.2.1 Prozessschritte Der automatisierte Prozess kann in drei grundlegende Schritte unterteilt werden und ist in Abb. 3.1 als Aktivitätsdiagramm dargestellt. Definiere Rand- bedingungen Erzeuge Leitungssatz- topologie Route Leitung auf Leitungssatz- topologie Simuliere Leitungssatz Exportiere Ergebnisse Abbildung 3.1: Prozessfluss 32 3.2 Konzept Definition der Randbedingungen. Die Definition der Randbedingungen beinhaltet einerseits den Import von Randbedingungen wie der Bauraumgeometrie und der Elektrolo- gik über Schnittstellen sowie die Ergänzung dieser Randbedingungen bei Unvollständigkeit. Andererseits erfordert dieser Schritt auch eine implizite Definition der Leitungssatztopo- logie durch den Anwender. Diese Definition enthält Anweisungen für die algorithmische Erzeugung des Leitungssatzes im nächsten Schritt. Automatisierte Leitungssatzgenerierung. Der zweite Schritt stellt die eigentli- che automatisierte Generierung des Leitungssatzes mittels Algorithmen auf Basis der importierten Randbedingungen dar. Dieser Schritt ist vollautomatisch durchzuführen und kann wiederum in drei sequenziell aufeinanderfolgende algorithmische Zwischenschritte unterteilt werden: • die Erzeugung einer Leitungssatztopologie mittels Pfadfindung im Bauraum, • die algorithmische Verlegung der Einzelleitungen mittels Pfadfindung auf Basis der im ersten Schritt erstellten Leitungssatztopologie und • die anschließende physikalische Simulation der gesamten Leitungssatztopologie unter Berücksichtigung der im zweiten Schritt verlegten Einzelleitungen. Export der Ergebnisse. Im letzten Schritt werden die Ergebnisse in ein gewünschtes Zielformat exportiert. Auch dieser Schritt kann grundsätzlich vollautomatisch erfolgen. 3.2.2 Softwarefunktionalitäten Ausgehend von den in Abb. 3.1 dargestellten sequenziellen Prozessschritten ist es nun möglich, eine Modularisierung in voneinander unabhängige Software-Funktionalitäten vorzunehmen. Abb. 3.2 zeigt diese abgeleiteten Funktionalitäten und ihre Beziehungen zueinander. Hervorzuheben ist, dass die einzelnen Funktionalitäten auf einem gemeinsamen zentralen Datenmodell arbeiten und nicht direkt miteinander kommunizieren. Import und Definition Topologie- erzeugung Leitungs- routing Physik- simulation Export Datenmodell Abbildung 3.2: Softwarefunktionalitäten und Datenfluss Anforderungen und Konzept 33 3.2.2.1 Import und Definition Mit der Funktionalität Import und Definition können, wie in Abb. 3.3 dargestellt, alle Randbedingungen wie Bauraumgeometrie, Komponentendaten und Elektrologik aus inter- nen und externen Daten importiert, zusammengeführt und in ein konsistentes Datenmodell geschrieben werden. Datenmodell Import und Definition Komponenten- daten Elektro- logik Geometrie Externe Toolumgebung Abbildung 3.3: Datenfluss der Funktionalität Import und Definition Die Funktionalität übernimmt dabei drei Aufgaben: Konsistenzprüfung. Bei der Konsistenzprüfung müssen Datenobjekte aus unterschied- lichen Datenquellen, die im Produkt dieselbe Entität darstellen, identifiziert und zusam- mengeführt werden. Dies kann auf Basis einer generalisierten Zuordnungsregel oder mit Hilfe von unternehmens- oder produktspezifischen Zuordnungsmatrizen erfolgen. Vollständigkeitsprüfung. Bei der Vollständigkeitsprüfung werden die importierten Daten auf fehlende Entitäten geprüft. Fehlende Objekte können in bestimmten Fällen durch vordefinierte Standardobjekte ersetzt werden. Definition Leitungssatztopologie. Die Funktionalität umfasst alle Werkzeuge zur Definition der Architektur für die Topologie des Leitungssatzes auf der Grundlage der importierten externen Daten. Dies beinhaltet die Möglichkeit, implizite Regeln für die Algorithmen zur automatischen Pfadfindung zu definieren, wie z.B. die Verbindungsanwei- 34 3.2 Konzept sung eines Anschlusses an eine Hauptroute1 oder Nebenroute2. Aber auch die Möglichkeit, explizite Randbedingungen wie konkrete Zwischenpunkte für einen Pfad zu definieren. Es ist wichtig, dass die Funktionalität Inkonsistenzen, Unvollständigkeiten oder auch Defizite bei der Definition der Leitungssatztopologie protokolliert. 3.2.2.2 Topologieerzeugung Die Funktionalität Topologieerzeugung setzt die algorithmische Generierung der Lei- tungssatztopologie um. Aufgabe dieser Funktionalität ist es, ein geometrisches Netzwerk zu erzeugen, das alle E/E-Komponenten verbindet, von denen Leitungen ausgehen. Dieses resultierende Netzwerk bildet die Grundlage für die im nächsten Prozessschritt folgen- de algorithmische Leitungsverlegung. Diese Vernetzung erfolgt durch die sequenzielle Erzeugung einzelner geometrischer Pfade mittels eines Pfadfindungsalgorithmus unter den gegebenen Randbedingungen. Start- und Endpunkte einer einzelnen Pfadfindungs- anweisung können dabei nicht nur vorgegebene E/E-Komponenten wie Steckverbinder und Halterungen sein, sondern auch Abschnitte des zu erstellenden Netzwerks selbst. Die gesamte Erzeugung der Leitungssatztopologie gliedert sich in die folgende Abfolge: 1. Auslesen der Randbedingungen aus dem Datenmodell 2. Ausführen aller Pfadfindungsanweisungen in vorgegebener Reihenfolge a) Ableitung der vom Pfadfindungsalgorithmus benötigten Start- und Endpunkt- menge aus Start- und Endobjekt der Pfadfindung b) Algorithmische Pfadfindung unter gegebenen Randbedingungen c) Integration des gefundenen geometrischen Pfades in das bestehende geometri- sche Netzwerk 3. Schreiben der resultierenden Leitungssatztopologie in das Datenmodell Da sich das Netzwerk und damit ggf. auch die sich ergebenden Start- und Endpunkt- mengen während des Gesamtprozesses ständig ändern, hat die vorgegebene Reihenfol- ge der einzelnen Pfadfindungsanweisungen einen erheblichen Einfluss auf die sich er- gebende Leitungssatztopologie. Auch die Definition expliziter Randbedingungen, wie z. B. Halterungen als Zwischenpunkte im Netzwerk, kann das Ergebnis stark beeinflus- sen. Die algorithmische Erzeugung der Leitungssatztopologie ist daher in der Regel der aufwendigste Teil der Leitungssatzgenerierung. 1Eine Hauptroute bezeichnet den primären, vorgegebenen Weg oder Verlauf, den Kabel in einem komplexen System, wie einem Fahrzeug, Flugzeug oder Gebäude, nehmen, um die effiziente Verlegung, Anbindung und Wartung der Kabel zu gewährleisten. 2Eine Nebenroute ist ein sekundärer, alternativer Weg für die Verlegung von Kabeln, der genutzt wird, wenn die Hauptroute nicht ausreicht oder um zusätzliche Komponenten anzubinden, wobei sie oft eng an die Hauptroute angebunden ist, aber in separaten Bereichen verläuft. Anforderungen und Konzept 35 3.2.2.3 Leitungsrouting Die Funktionalität Leitungsrouting realisiert die Verlegung der Einzelleitungen zwi- schen den E/E-Komponenten. Dies geschieht durch eine vereinfachte algorithmische Pfad- findung für jede logische Verbindung auf der Leitungssatztopologie. Die resultierenden Pfade setzen sich dann aus einer Liste von Leitungssatzsegmentverläufen zusammen. Die Pfade der Einzelleitungen auf der Leitungssatztopologie entsprechen dann dem tatsäch- lichen physischen Verlauf der Leitungen im Leitungssatz. Das gesamte Leitungsrouting gliedert sich in die folgende Abfolge: 1. Auslesen der benötigten Daten, wie z.B. Verbindungen, Leitungssatztopologie oder Leitungskomponentendaten aus dem Datenmodell 2. Für alle logischen Verbindungen a) Pfadfindung auf Leitungssatztopologie b) Aktualisierung der Segmentdurchmesser 3. Zurückschreiben der Leitungsführungen in das Datenmodell Wie im zweiten Prozessschritt werden die Pfadfindungsanweisungen für die einzelnen Leitungen sequenziell ausgeführt. 3.2.2.4 Physiksimulation Die Funktionalität Physiksimulation passt den geometrischen Verlauf der Segmente an die durch das Einzelleitungsrouting geänderten physikalischen Randbedingungen an. Dies sind im Wesentlichen die geänderten Segmentdurchmesser, die Biegesteifigkeiten der nun in den Segmenten liegenden Leitungen sowie die Abgangsrichtungen der Leitungen bei Steckverbindern oder Halterungen. Dabei wird der gesamte Leitungssatz als physikalisches Mehrkörpermodell approximiert. Das Gesamtmodell beinhaltet auch die Bauraumgeome- trie, um entsprechende Randbedingungen wie Kollisionsfreiheit und Mindestabstände zu Systemkomponenten weiterhin in der Simulation berücksichtigen zu können. Die gesamte physikalische Simulation gliedert sich in folgenden Ablauf: 1. Auslesen von Leitungssatztopologie, Leitungsrouting und E/E-Komponenten des Leitungssatzes sowie der Bauraumgeometrie aus dem Datenmodell und Aufbau eines integrierten Mehrkörpermodells 2. Ausführen der vereinfachten Simulation des Mehrkörpermodells 3. Zurückschreiben der geänderten Segmentverläufe in das Datenmodell Sind mehrere unabhängige Leitungssätze vorhanden, können diese grundsätzlich auch nacheinander simuliert werden. Bei der Simulation eines Leitungssatzes müssen jedoch 36 3.2 Konzept alle anderen Leitungssätze als statische Bauraumgeometrie in das Modell geladen werden, um Kollisionen zwischen den Leitungssätzen zu vermeiden. Aus Laufzeitgründen wird die Physiksimulation oft vereinfacht, um eine Echtzeitfähigkeit in der Ausführung zu erreichen. 3.2.2.5 Export Die Export-Funktionalität hat die Aufgabe, aus dem im Datenmodell gespeicherten Ge- samtresultaten der automatisierten Leitungssatzgenerierung Teilergebnisse auszuleiten und in entsprechende externe Datensätze zu schreiben. Dies können Stücklisten für die Fer- tigung, die geometrische Beschreibung des Leitungssatzes für ein extern verwendetes CAD-Tool oder auch Zusatzinformationen für die elektrologische Beschreibung wie z.B. Leitungslängen sein. Datenmodell Export Produkt- definitionGeometrie Sonstiges Externe Toolumgebung Abbildung 3.4: Export Abb. 3.4 zeigt beispielhaft den Datenfluss aus dem Datenmodell in die gewünsch- ten externen Datenformate über die Export-Funktionalität. Wie bei der Funktionalität Import und Definition sind diese Schnittstellen branchen-, unternehmens- oder sogar produktabhängig. 3.2.3 Datenmodell Das zentrale