ZDB direkt Zuse 2005.pdf - Zentralverband Deutsches Baugewerbe

Weitere Magazine

Empfehlungen

Info

6 Ein Bau-Produktmodell als Schlüssel zur Software-Integration Universitätsprofessor Dipl. Ing. Architekt Richard Junge Fachgebiet CAAD, Fakultät für Architektur der TU München Wenn man in einer Baufirma aufgewachsen ist, von Kindesbeinen an das Büro, den Bauhof, die Baustellen kennt und dann den Beruf des Architekten ergreift, dann kann es einem nur ums Bauen gehen. Der architektonische Entwurf ist dazu der erste Schritt. Bauen ist ein vielschichtiger Prozess, mit vielen Beteiligten. Die HOAI weist dem Architekten bereits in der Phase des Entwurfes das „Integrieren der Leistungen anderer an der Planung fachlich Beteiligter“ zu. Bei der Ausführungsplanung heißt es: „Erarbeiten der Grundlagen für die anderen an der Planung fachlich Beteiligten und Integrierung ihrer Beiträge bis zur ausführungsreifen Lösung“. Das stellt nicht nur einen hohen Anspruch an Wissen und Können, sondern im Zeitalter der Software lässt es ganz mächtig den Wunsch, den Druck nach Software-Integration entstehen. Mein erster ernsthafter Anlass mich mit Computern zu befassen datiert von 1978. Seinerzeit sah ich mich in einem sehr großen, komplexen Auftrag gezwungen, Kostenplanung, –steuerung und –kontrolle auf der Basis von Kostenelementen durchzuführen. Der Gedankengang war folgender, einfacher: Plant man Kosten mit Kostenelementen und setzt dann CAD-Systeme ein, die wiederum mit Bauteilen arbeiten (und nicht mit purer Geometrie), dann müsste doch der Computer schon dieses und jenes Faktum kennen, das mit diesen Bauteilen verknüpft ist. Als Folge daraus wäre zu schließen, dass man diese Fakten nicht nochmals irgendwo anders wieder neu eingeben muss. Mengenermittlungen klappten schon sehr gut, die Zuweisung der Mengen zu Kostenelementen oder LV- Positionen auch. Kostenelemente bestehen letztlich aus LV-Positionen nach einer ganz bestimmten „Rezeptur“. Man kann also eine so aufgebaute Kostenberechnung umsortieren und erhält ein Roh-LV. Das funktionierte auch. Verzweiflung kam allerdings auf, als die ja gerade erst in Entwicklung befindliche Codierungsstruktur des Mutter –LV und des Kostenelemente -Kataloges verbessert werden mussten. Unmöglich war es, die im Raum- und Gebäudebuch festgelegten Qualitäten automatisiert, z.B. für die Kostenberechung, auszuwerten. Warum? Weil alles nur in Form von Daten vorlag, deren Bedeutung nicht mitabgespeichert wurde. Diese kam erst durch den mit den Programmen arbeitenden Menschen dazu. Das zeigte sich besonders, als es die ersten Versuche gab, mit Ingenieuren außerhalb des eigenen Büros zusammen zu arbeiten. Dieselben Probleme oder Grenzen gab es natürlich auch in dem Projekt ISYBAU – Integrierter System BAU – des Bundesbauministerium und der Landesbauverwaltungen Bayern, bei dem ich beratend tätig war. Wir machten halt alle denselben Fehler. Wir glaubten, dass eine solche Integration über Daten, die in Datenbanken gehalten werden, wenn man sie nur gescheit genug codiert, möglich sei. Zu einem neuen Gedankengang kam ich, als ich in einem Soziologiebuch die Definition von Kommunikation las. Daraufhin stellte ich einen Vortrag unter den Slogan „Integration durch Kommunikation“. Das Übertragen von Worten erfolgt über Schallwellen. Kommunikation kann aber erst stattfinden, wenn die Bedeutung dieser Worte im jeweiligen Zusammenhang richtig verstanden werden. Erst dann kann darauf sinnvoll geantwortet oder gefragt werden. Man kann das deutlich machen, wenn man sich die Runde eines Bau- Jour-Fixe vorstellt. Jeder in dieser Runde hat sein, von seiner Disziplin und Aufgabe geprägtes, fachliches Modell. Was er sieht, interpretiert er demgemäss. Dennoch aber können sich diese Fachleute in aller Regel gut untereinander verständigen. Sie kommunizieren. Zwischen diesen fachlichen Modellen existieren offensichtlich Verbindungen, ein Verständnis, auf dessen Grundlage man kommunizieren,
sinnvoll Fragen stellen und Antworten geben kann. Nur ein ganz einfaches Beispiel: Wenn ein Statiker mir als Architekten sagt, eine bestimmte Wand müsse eine aussteifende Funktion übernehmen, aus Beton bestimmter Qualität sein usw., dann braucht er mir keine grundlegenden Erläuterungen geben. Es wird sofort und unmittelbar verstanden. Seine Information wird bestimmte Konsequenzen im weiteren Planungs- und Bauprozess haben und es ist auch ziemlich klar welche. Es muss also heißen: Integration zwischen fachlichen Modellen läuft über Kommunikation. Jetzt kommt etwas Neues dazu: Jeder dieser Fachleute benutzt Computer für seine Tätigkeiten. Und hier scheitert die Kommunikation. Das, was diese Fachleute noch fertig bringen, nämlich zu kommunizieren, geht nun mit ihren Computern nicht mehr. Hier liegen nur noch Daten vor, die einer Interpretation durch den Fachmann bedürfen. Eine Zeichnung ist lediglich ein Stück Papier mit Strichen darauf. Wenn wir, Bauingenieure, Architekten darin lesen, dass beispielsweise aufgrund einer bestimmten Schraffur dieses Mauerwerk, jenes Beton ist, oder dass hier eine Treppe, dort ein Aufzugsschacht ist, können wir das Dank unseres fachlichen Mo- dells. Gegenprobe: Was sieht denn der Laie, der Nichtfachmann auf diesem Blatt? Der Sprung von dieser Papierzeichnung hin zu einem computergestützten Design ist gleich null. Auch wenn ein CAD-System benutzt wird, das nur auf Geometrien basiert, ist das Ergebnis nur ein Datensatz, der nur Geometrie enthält. Die Bedeutung entsteht erst im Kopf des Betrachters. Es ist kein Unterschied zur händisch erstellten Zeichnung vorhanden. Soll eine Kommunikation zwischen den Software-Systemen ermöglicht werden, genauso wie es zwischen Personen geschieht, dann muss man einen Weg finden, diese fachlichen Modelle abzubilden und auf die Computerwelt zu übertragen. Und das ist möglich! Aber auch hier ging es zunächst mit untauglichen Mitteln weiter, bis ich die im STEP Umfeld entwickelte Technik der Produktmodelle anwandte. Über mehrere Schritte kam ich zu einer Modelarchitektur, die es erlaubt, Bauprodukt-Modelle zu bauen, ohne vorab die Größe oder Entwicklungsrichtung des Modells zu kennen. So konnte man also mit dieser ungeheuren Aufgabe eines Bauprodukt- Modells beginnen und auch nach kurzer Zeit schon Ergebnisse nutzen. Im folgenden soll nun gezeigt werden, dass die Arbeit an diesen Konzepten den Forschungsbereichverlassen hat und in die industrielle Umsetzung gegangen ist. Internationale Standardisierung – IFC Man kann sich vorstellen, dass man auf dieser Basis intelligentere Software schaffen kann. Um zu breiten Anwendungen zu kommen, muss noch ein sinnvoller Standard gefunden werden. Ohne diesen würde statt einer gemeinsamen Sprache, ein babylonisches Gewirr entstehen. Diesen Standard zu schaffen, bemüht sich ein Industriekonsortium unter dem Namen „International Aliance for Interability“ – IAI. Ich war einer der Initiatoren dieser Vereinigung und nach diversen technischen, und später organisatorisch politischen Aufgaben, bin ich heute Ehrenvorstand. Der dort geschaffene Standard nennt sich „Industrie-Foundation-Classes“ – IFC. Das Konsortium hat elf Chapter – in Deutschland, Skandinavien, Großbritannien, Frankreich, Italien, Spanien, USA, Australien, Singapore, Korea und Japan. Das deutsche Chapter hat ca. 60 Mitglieder, international sind es ca. 650. Sie kommen aus Ingenieur- oder Baufirmen, aus Softwarehäusern oder auch Verbänden. Mit den Beiträgen der Mitglieder wird die Standardisierung finanziert. Gerade in diesem Jahr ist ein deutlicher Zuwachs des Interesses an IFC zu verzeichnen. Es beginnt sich am Markt durchzusetzen als ein Format, das den Vorgängern deutlich überlegen ist. Baugenehmigung per Internet Eine revolutionäre Weiterung dieses Ansatzes für integrierende Systeme ist das sogenannte Corenet-Plan-Checking- System. Es geht dabei darum, Bauanträge über das Internet einzureichen und von einem Computer automatisch zu prüfen und zu genehmigen. Ein solches Projekt betreibt die Regierung von Singapore. Als ich 1995 zu diesem Projekt um Rat gefragt wurde, glaubte man, dass sich die grafischen Elemente der CAD-Datensätze so interpretieren lassen würden, dass man darauf die Prüfung der Regelkonformität aufbauen könnte. Man war ziemlich entsetzt, als ich sagte, das würde nicht gehen. Ich schlug einen anderen Weg vor. Man hat dann zwar den Prototypen nach dem alten Projektplan fertig gestellt, aber doch langsam begonnen, den neuen Weg parallel zu verfolgen, weil der alte Prototyp nicht hielt, was er sollte. Man kann sich, denke ich, vorstellen, dass wenn man eine Baueingabe als einen Datensatz bekommt, der nicht nur Geometrien 7
Seite 1 und 2: Direkt Aktuelles vom Deutschen Baug
Seite 3 und 4: Konrad-Zuse-Medaille 2005 Mit der V
Seite 5: So war es nur folgerichtig, dass er
Seite 9 und 10: Zur Person Prof. Richard Junge: Mei
Seite 11 und 12: Professor Roland Vollmar, Universit
Seite 13 und 14: Nachfolgemaschine Z3 teilfinanziert
Seite 15 und 16: Die Träger der Konrad-Zuse-Medaill

ZDB direkt Zuse 2005.pdf - Zentralverband Deutsches Baugewerbe

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?