Einige Grundueberlegungen ueber IT-gestuetzte Entwurfssysteme 9. Februar 2001 Einige Grundüberlegungen über IT-gestützte Entwurfssysteme 1 Allgemeines Die Schiffbauer waren eine der ersten Ingenieurdisziplinen, die in größerem Stil rechnergestützte Methoden zur Erledigung ihrer Aufgaben eingesetzt haben. Hauptanwendungsgebiete waren die Erfassung der Schiffsform sowie alle Arten von volumetrischen Berechnungen, da diese Berechnungen die Hauptarbeit beim Schiffsentwurf darstellten und somit das wesentliche Hindernis waren, um den Entwurf signifikant zu beschleunigen. Die ersten rechnergestützten Methoden bildeten zunächst die Verhaltensweise des Ingenieurs im Rechner ab. Erst später entstanden die numerischen Verfahren als eigenständige ingenieurwissenschaftliche Disziplin. Wir wollen nun zunächst die Frage erörtern, warum man Rechner bzw. rechnergestützte Verfahren überhaupt einsetzt und worin deren Gewinn für den Entwurfsprozeß liegt oder liegen könnte. Mögliche Argumente für den Rechnereinsatz könnten z.B. vordergründig lauten: • Der Rechner kann die teuren und schwierigen Menschen preiswert ersetzen. • Recher arbeiten viel schneller und zuverlässiger, ihre Ergebnisse sind reproduzierbar. • Ist ein Prozeß erst einmal für einen Rechner aufbereitet, wird er automatisiert durchgeführt, der Mensch muß nur noch den Rechner kontrollieren, so daß man nicht mehr so hochqualifizierte Menschen braucht. • Expertenwissen kann im Rechner gespeichert werden und wird damit auch für Nichtexperten zugänglich, ebenfalls ein Argument dafür, um nicht so hochqualifizierte Menschen zu benötigen. Natürlich sind diese Sichtweisen falsch, da sie vor allem vernachlässigen, daß Rechner im Gegensatz zu Menschen nicht kreativ sind. Folglich können sie auch die Menschen genau dann nicht ersetzen, wenn Kreativität gefragt ist. Genau diese spielt aber beim Entwurfs-und Konstruktionsprozeß aller Dinge aber die entscheidende Rolle. Worin liegt nun der eigentliche Vorteil der Rechneranwendung gerade in diesen Ingenieursdisziplinen? Ich denke, daß es im wesentlichen zwei verschiedene Mechanismen sind, die den Rechnereinsatz begründen: Auf der einen Seite geht es darum, besonders stumpfsinnige Arbeiten, die keinerlei Kreativitätsanteile enthalten, zu automatisieren und den Menschen davon freizuhalten. Das ist die sofort einleuchtende Komponente. Allerdings wird dadurch nicht bewirkt, daß Dinge wesentlich schneller erledigt werden, denn die Automatisierung des Prozesses verlangt geradezu danach, diesen Prozeß (häufig sinnloserweise) mehrfach duchzuführen, eben weil es so einfach geht. Etwas griffiger formuliert: Die Arbeit nimmt in dem Maße zu, wie zu ihrer Erledigung Geräte zur Verfügung stehen. Auf der anderen Seite findet diese Denkweise bei den Anwendern der Informations-Techologie große Akzeptanz: Der Rechner erledigt genau die Arbeiten, die vorher der Mensch erledigt hat, auf die gleiche Weise. Der Prozeß bleibt derselbe wie ohne Rechnereinsatz, was für Menschen gewohnt und daher bequem ist. Ein Umdenken ist nicht erforderlich. Auf der anderen Seite stellt uns die Informationstechnik eine vollkommen neue Technologie zur Verfügung, und es ist denkbar und zugleich wahrscheinlich, daß Prozesse unter Verwendung dieser Technologie vollkommen anders gestaltet werden müssen, um die Technologie auf die effizienteste Weise zu nutzen. Hierbei spielt der Reengeneering-Gedanke eine erhebliche Rolle: Wie sieht der zu modellierende Prozeß aus, wie sollte er idealerweise aussehen, und wie würde er aussehen, wenn sich die Rahmenbedingungen vollkommen ändern ? Dabei ist nicht entscheidend, wie der zu modellierende Prozeß derzeit aussieht, sondern es zählt, wie der Prozeß unter den durch die neue (Informations)Technologie gegebenen Bedingungen idealerweise aussehen wird. Nur wenn man den Reenegeneering -Gedanken wirklich ernst nimmt, ist zu erwarten, daß der volle Nutzen der Informationstechnik sich produktivitätsverbessernd auf den modellierten Prozeß auswirkt. Stefan Krueger (TKB) $E4TEXT/veroeffentl/vorlesung/allgcad/allgcad.tex [email protected] 1/5 Einige Grundueberlegungen ueber IT-gestuetzte Entwurfssysteme 9. Februar 2001 Häufig bietet die Informationstechnik sogar Lösungen an, bevor klar ist, welche Probleme eigentlich gelöst werden sollen. Ein klassisches Beispiel (HAMMER und CHAMPY, 1996) hierfür ist die Ablehnung der Xerox-Patente durch IBM mit der Begründung, daß der Preis für eine mit dieser Technologie erstellte Kopie niemals gegenüber einer mit Kohlepapier ausgestatteten Sekterärin wettbewerbsfähig sein könne. Dabei wurde völlig übersehen, daß sich die Technologie selbst ihren eigenen Bedarf schaffen würde, den heutzutage nicht einmal Heerscharen von mit Kohlepapier ausgerüsteten Sekretärinnen bewältigen könnten. Daraus folgt, daß die Beeurteilung von informationstechnischen Lösungen heutzutage nicht mehr allein aufgrund von marktwirtschaftlichen Überlegungen erfolgen darf (z.B. BERTRAM 1994), sondern daß in der überwiegenden Anzahl der Anwendungen vor allem strategische Überlegungen den Ausschlag geben müssen (HAMMER und CHAMPY 1996). Dabei liegt auf der Hand, daß sich die prozeßverbessernde Komponente der Informationstechnologie im diametralen Gegensatz zur Anwenderakzeptanz befindet: Menschen neigen nämlich im allgemeinen dazu, jegliche Form von Veränderung, insbesondere ihre Arbeit belangend, abzulehnen (daher resultieren auch die in allen Unternehmen immer wieder festgestellten Schwierigkeiten bei der Durchführung von IT-Projekten, und heute beschäftigen sich folgerichtig Scharen von Unternehmensberatern genau mit dieser Frage). Wir können also folgendes feststellen: Der eigentliche Gewinn durch den Rechnereinsatz liegt sowohl in der Beschleunigung von vorhandenen Prozessen (bei hoher Anwenderakzeptanz) als auch in der Neuformulierung von Prozessen (trotz niedriger Anwenderakzeptanz). 2 Eigenschaften schiffbaulicher Entwurfssysteme Kehren nach diesem Exkurs zum schiffbaulichen Entwurfsprozeß zurück. Wie sollte man nun ein schiffbauliches Entwurfssystem konzipieren? Welche ernstzunmehmenden schiffbaulichen Entwurfssysteme gibt es, und wie können sie in den durch die obigen Überlegungen gekennzeichneten Rahmen eingeordnet werden? Unter einem schiffbaulichen Entwurfssystem verstehe ich hierbei ein Rechnersystem, in dem alle Fähigkeiten abgebildet sind, die den schiffbaulichen Entwurfsprozeß ausmachen. Im Gegensatz zu den CAX-Systemen, die im wesentlichen darauf abzielen, bereits vorhandene Dinge zu beschreiben, bildet ein Entwurfssystem gewissermaßen eine Werkzeugsammlung für den eigentlichen Schöpfungfsprozeß eines technischen Objektes (inverses Problem). Es versteht sich von selbst, daß ein Entwurfsystem vollständig sein muß, d.h. es muß alle relevanten Entwurfsaspekte abdecken. Gleichzeitig muß ein solches System so flexibel sein, daß nicht nur beliebige Schiffe, sondern auch andere artverwandte technische Gebilde damit entworfen werden können. Folgende Systeme erfüllen meiner Ansicht nach die genannten Anforderungen, und daher findet sich eines dieser Systeme bei jeder größeren Werft im Einsatz: • NAPA, NAPA Oy, Finnland • FORAN, Senermar, Spanien • TRIBON INITIAL DESIGN, KCS, Schweden • E4, FSG, Deutschland Naturgemäß ist das NAPA-System in Nordeuropa weit verbreitet, FORAN wird mehr von den Südeoropäern bevorzugt. TRIBON INITIAL DESIGN ist aus dem von KCS aufgekauften BMT-System hervorgegangen und versteht sich als logische Ergänzung zu den TRIBON-Konstruktionssystemen. Daneben gibt es eine Reihe von Spezialprodukten speziell für die Yachtszene, die hier -eben aus Gründen mangelnder Vollständigkeit- nicht aufgeführt werden. Ich würde sagen, daß FORAN und TRIBON INITIAL DESIGN dem derzeitigen Stande nach eher zu den klassischen Entwurfssystemen gehören, d.h. daß der Entwurfsprozeß oder seine Teilschritte stark dem Anwenderverhalten nachempfunden sind. NAPA geht da einen Schritt weiter, und E4 ist das System, das durch die rein gesamtprozeßorientierte (Werftprozeß, versteht sich ) Denkweise gekennzeichnet ist, allerdings an einigen Stellen zu Lasten der Anwenderakzeptanz (eben wegen des implementierten Reengeneering-Gedankens). Stefan Krueger (TKB) $E4TEXT/veroeffentl/vorlesung/allgcad/allgcad.tex [email protected] 2/5 Einige Grundueberlegungen ueber IT-gestuetzte Entwurfssysteme 3 9. Februar 2001 Offene Architektur oder Monolith - Vor-und Nachteile Im Abschnitt Allgemeines zum Entwurfsumfeld wurde die überragende strategische Bedeutung des Entwurfsprozesses und der ihn treibenden Werkzeuge herausgearbeitet. Dabei wurde festgestellt, daß • die Verkürzung der Entwicklungszeit entscheidende Bedeutung hat. Dies bedingt nicht nur, daß Einzelprozesse beschleunigt werden müssen, sondern vor allem auch, daß bisher sequentielles Abarbeiten parallelisiert wird (Concurrent engineering). • wesentliches Gewicht auf die Qualität der Berechnungswerkzeuge, insbesondere der numerischen Verfahren (1st principles) gelegt werden muß. Daraus ergeben sich nun unmittelbar die wesentlichen Anforderungen an eine zu entwickelnde ITLandschaft unter der Voraussetzung, daß das Unternehmen (eben die Werft) einen Fokus auf die Produktentwicklung hat. • Die IT-Architektur muß das parallele Abarbeiten des Entwurfes auf einem vernünftigen Granularitätsniveau ermöglichen. Das bedeutet, daß im Gegensatz zu kommerziellen Systemen (gemeint ist dies nicht im Sinne von professionell, sondern von der Art, wie sie im kommerziellen Bereich, also Buchhaltung, Materialsteuerung etc. eingesetzt werden) nur die Vorgänge parallelisiert werden müssen, die auch technisch vom Prozeßablauf sinnvoll sind (sinnlos wäre es z.B., wenn gleichzeitig zwei Leute die Schiffsform ändern würden, wobei jeder gerade einen Spant bearbeitet). Da technische Systeme im Gegensatz zu kommerziellen nie konsistent sein können, (eben weil der Entwurfsprozeß dies geradezu fordert, sonst könnte man kein einziges Schiff entwerfen), ist es besonders wichtig, die Methoden und Datenhaltung so anzulegen, daß zwar Inkonsistenzen akzeptabel sind, diese aber mit der Zeit z.B. durch automatische Nachpflege der Modelle per se ausheilen. • Da einerseits die Entwicklungskapazität jeder Organisation begrenzt ist, und andererseits aber Berechnungsmethoden eingefordert werden, die auf dem neusten Stand von Wissenschaft und Technik sind (und folglich nicht von einer Organisation allein entwickelt und gepflegt werden können), ist es entscheidend, auf das Entwicklungspotential von anderen, die auf einem bestimmten Fachgebiet führend sind, zugreifen zu können. Diese Spezialisten entwickeln naturgemäß Softwarebausteine, die keinen allgemeinen Entwicklungsrichtlininen (z.B. einheitliche Programmiersprache, Nutzerinterface etc.) unterworfen sind. Will man diese Potentiale gewinnbringend nutzen, dann muß man die Aufgabe lösen, beliebig heterogene Softwarebausteine in ein einheitliches System zu integrieren, das außerdem noch dem unternehmenseigenen Prozeßmodell folgen muß, also je nach Organisation verschieden ist. Stefan Krueger (TKB) $E4TEXT/veroeffentl/vorlesung/allgcad/allgcad.tex [email protected] 3/5 Einige Grundueberlegungen ueber IT-gestuetzte Entwurfssysteme 9. Februar 2001 User Interface Mensch AUI (Tickle TK) GUI (Cal2Phigs) Heap M1 Mn Post n Pre n Post1 Pre1 Datenbasis-Interface-Modul (COSMOS) Datenbasis-Extrakt aus angeforderten Gruppen Platte Multi-User-Management H G R M W S D S ... ... ... ... ... ... ... ... ... Datenbasis: Formal unabhängige Datengruppen Interface-Layer zu "externen" Partnern HSVA Klasse NCG FSG/TK ....... Abbildung 1: IT-Architektur eines offenen Methodenbanksystems mit Multi-User-Funktionalität (FSGE4) Daraus ergibt sich, daß nur offene, strikt modular angelegte Methodenbanksysteme (s.a. NOWACKI) beide Anforderungen gleichzeitig erfüllen können. Da offensichtlich in dieser prozeß- und entwicklungsorientierten Sicht der höchste Gewinn für den Entwurfsprozeß liegt, werden im folgenden die Mo- Stefan Krueger (TKB) $E4TEXT/veroeffentl/vorlesung/allgcad/allgcad.tex [email protected] 4/5 Einige Grundueberlegungen ueber IT-gestuetzte Entwurfssysteme 9. Februar 2001 dellierungsansätze beschrieben, die dem daraufhin entworfenen IT-Konzept (E4) zugrunde liegen. Die folgende Abbildung zeigt beispielhaft die grundlegende Software-Arhitektur eines offenen Methodenbanksystems mit Multi-User-Funktionalität. 4 Literatur BERTRAM, V. (1994) Investitionsbeurteilung von Software 28. Fortbildungskurs, IfS, Hamburg van der Bles, G.; Dirkse, C. (2000) Integrated Shipbuilding by Concurrent engineering 1st International EuroConference on Computer and Information Technology in the Marine Industries (COMPIT), Potsdam BÜHR, W., KEIL, H., KRÜGER, S. (1988) Rechnereinsatz im Projekt Proc. STG, Springer, 353-363 HAMMER, M., CHAMPY, J. (1996) Die tragende Rolle der Informationstechnik, in: Business Reengeneering - Die Radikalkur für das Unternehmen CAMPUS, 112-133 OSTVIK, I.; Konovessis, D.; Vassalos, D. (2000) A Ship Design Blackboard System 1st International EuroConference on Computer and Information Technology in the Marine Industries (COMPIT), Potsdam NOWACKI, H. (1988) System-Architekturen und Schnittstellen für den schiffstechnischen Konstruktionsprozeß Proc. STG, Springer, 343-351 Stefan Krueger (TKB) $E4TEXT/veroeffentl/vorlesung/allgcad/allgcad.tex [email protected] 5/5