AEC.WEB - Magazin: IAI / IFC

<body stylesrc="../magbody.htm" bgcolor="#FFFFFF" link="#306531" vlink="#4A4A4A" alink="#800000">  <table border="0" cellspacing="0" width="100%"> <tr> <td bgcolor="#DEDEDE" colspan="2" valign="middle" align="center" width="147"><nobr><a href="javascript:history.back()" target="_self"><img src="../../i/zurueck2.gif" hspace="5" vspace="16" alt="1 Seite zurück" border="0" WIDTH="20" HEIGHT="15"></a><a target="_top" href="../index.htm"><img src="../../i/zurueck.gif" border="0" vspace="15" hspace="5" WIDTH="15" HEIGHT="20"></a><nobr><br> <img src="../../i/m-leer.gif" width="150" height="2"></nobr></nobr></td> <td bgcolor="#DEDEDE" width="98%"><strong><a name="Seitenanfang"></a>  <script type="text/javascript"> var iam_data = { "st":"baulinks", // site/domain "cp":" AECmap" // code } iom.c(iam_data,1); </script>  <span class="ueb">IAI / IFC:</span><br> <span class="u3">Der Turmbau zu Babel am Ende des 20. Jahrhunderts</span></strong></td> </tr> <tr> <td bgcolor="#000000" colspan="3" width="729">    </td> </tr> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br>   erste Fassung:<br> 6.11.1997</td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3><strong>  <br> Kapitelübersicht:</strong></h3> <p class="kr-neu"><a href="#1"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Informationen sammeln und Know-how verfügbar machen</strong></p> <p class="kr-neu"><a href="#2"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a><strong> Planung und Projekt organisieren</strong></p> <p class="kr-neu"><a href="#3"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Wer ist die IAI? Wer die Internationale ALLIANCE für INTEROPERABILITY?</strong></p> <p class="kr-neu"><a href="#4"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Was macht die IAI?</strong></p> <p class="kr-neu"><a href="#5"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Was bedeutet "Interoperabilität"?</strong></p> <p class="kr-neu"><a href="#6"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a><strong> vorübergehend abschließend<br>   </strong></td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td bgcolor="#000000" width="729">    </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> kursiv markierte Links verweisen auf GLOSSAR.de</td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3>  <br> <strong><a name="1">Informationen</a> sammeln und Know-How verfügbar machen</strong></h3> <p>Architekten und ihre Partner stehen unter einem zunehmenden Druck, mehr Qualität für geringere Honorare mit strafferen Zeitplänen abliefern zu müssen. Bislang haben moderne Technologien noch keinen signifikanten Nutzen für das Bauwesen erbracht. Zwar haben Büroautomationswerkzeuge wie Textverarbeitung oder Tabellenkalkulation für Verbesserungen gesorgt, und bestehende AEC- (CAD-und AVA-)Werkzeuge haben außerdem <strong>EINZELNE</strong> Aspekte im Designprozeß wesentlich verbessern können, allerdings von entscheidender Wirkung bezüglich Qualität und Produktivität bei Architekturdienstleistungen waren sie bis jetzt noch nicht - weil die <strong>VERBINDUNG</strong> der Einzelkomponenten noch kränkelt.</p> <p>Vom ersten Entwurf über die Werkplanung mit der Einbeziehung der technischen Gewerke bis zur Ausschreibung und Vergabe gehen mannigfach Informationen (wichtige und unwichtige) durch viele Hände. Und das setzt sich fort bei der Herstellung und dem Betrieb eines Bauwerkes bis hin zum Abriß. <strong>Schön</strong>, wenn all dieses Know-How (gefiltert oder ungefiltert) den Planungspartnern, auf der Baustelle und später bei der Gebäudeverwaltung zur Verfügung steht und der Wissenpool ständig weiter ausgebaut werden kann. <strong>Dumm</strong>, wenn sich trotz aller modernen Technik die Werkzeuge (gemeint ist die EDV) der am Bau beteiligen Personen bzw. Firmen nicht oder nur unvollständig verstehen und Informationen immer wieder verpuffen oder unter den Tisch fallen.</p> <p>Die zunehmende Informationsmenge kann zwar leicht elektronisch dargestellt und manipuliert werden, aber die Technik ist (noch) nicht (ausreichend) in der Lage, die verschiedenen Informations-Formate so konsequent zu managen, wie es in der Praxis benötigt wird. Das Problem hat einen Namen: "<strong>Datenaustausch</strong>". Projekt-Daten müssen ausgetauscht werden, <img src="dta-st1a.gif" align="right" hspace="4" vspace="4" WIDTH="300" HEIGHT="282"><ul> <li>weil verschiedene Unternehmen an einem Projekt arbeiten: Architektur- und (Fach)Ingenieurbüros, Bauunternehmen und Behörden, Bauherren, Dienstleister und Lieferanten;</li> <li>weil viele unterschiedliche Systeme für unterschiedliche Aufgaben verwendet werden: Entwurf, Werkplanung, Statik, TGA, Präsentation, Ausschreibung und Vergabe, Kalkulation, Facility Management und</li> <li>wegen der Einbeziehung von Fremddaten: aus dem Kataster- und/oder Bebauungsplan, Bauteil-Katalogen, ...</li> </ul> <p>Mit verschiedenen Datenaustauschstandards hat die Branche in der Vergangenheit versucht, das babelonische Treiben in den Griff zu bekommen - was man zur Zeit nicht als geglückt bezeichnen kann. Denn noch immer verständigt man sich nur auf der Basis des kleinsten gemeinsamen Nenners (und einigt sich meistens auf das DXF-Format) - eine Situation, die Informationsverluste UNvermeidbar macht. Besonders alphanumerische, bauteilbeschreibende Informationen, die sich ständig neu ergeben können oder spontan - aber dokumentiert - neu überdacht werden müssen, bleiben auf der Strecke. Allerdings kann man diese aktuelle Situation nicht nur den Datenaustausch-Standards ankreiden. Ohne bauteil-(objekt-)orientierte <a target="_new" href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_a.htm#aec">AEC</a>-Systeme sind auch die besten Datenaustausch-Mechanismen machtlos (siehe auch <a href="f-aec1.htm">(R)EVOLUTION im Architekturbüro</a>), denn solange beispielsweise ein CAD-System nur wie ein elektronisches Zeichenbrett eingesetzt wird und CAD-Zeichnungen nur aus Strichen bestehen, können BAUTEILinformationen nicht sinnvoll und langfristig einbezogen werden.<br>   </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> </td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3><strong><a name="2">Planung</a> und Projekt organisieren</strong></h3> <p>Nimmt man als Beispiel ein einfaches Fenster (ein sehr beliebtes Beispiel). Es erscheint während einer Projektierung in unterschiedlichen Formen an unterschiedlichen Stellen: <ul> <li>in Grundriß-, Schnitt und Ansichtsplänen,</li> <li>in Massenermittlungen, Ausschreibungen und Kostenvoranschlägen,</li> <li>in der Statik und im Wärmeschutznachweis,</li> <li>in Baubeschreibungen und Vertragsdokumenten, ...</li> <li>in Präsentationen</li> <li>(und im Kopf des Bauherren  was aber sowieso ein Problem ist, und sich nie ändern wird).</li> </ul> <p>Was nun aber, wenn das Fenster geändert werden muß? Der Architekt ist für die Koordinierung der Änderungen verantwortlich - ein schwieriges Unterfangen, da heutzutage der gleiche Vorgang bzw. Gegenstand in verschiedenen Dokumenten vertreten ist, die physikalisch an unterschiedlichen Orten aufbewahrt werden und sich unter der Kontrolle unterschiedlicher Personen befinden.<br> Eine weitere Herausforderung ist für den Architekten mit der Bereitstellung von Gebäudedaten in elektronischer Form für die Nutzung durch den Bauherren bzw. seinen Vertreter (Gebäudeverwaltung) gegeben. Informationen und Inhalte, wie sie für die Gebäudeverwaltung benötigt werden, differieren naturgemäß von dem, was im Designprozeß zur Anwendung kommt. Sehr häufig müssen Gebäudedaten auch in ein bestehendes Verwaltungssystem integriert werden. Und als ob all dieses nicht ausreichend wäre, hat jeder Bauherr unterschiedliche Anforderungen und jedes Bauwerk einen unvergleichbaren Verwendungszweck. Gegenwärtig sind diese Prozesse des Datenaustausches nicht automatisierbar und erfordern viel Handarbeit, sie verursachen zum Teil erhebliche zusätzliche Kosten und bergen viele Gefahren z.B. in Form von Übertragungsfehlern oder Datenverlusten.</p> <p align="left">Informationen und Know-How besser managen sowie Planung und Projekte effizienter organisieren - diesen Ansprüchen hat sich die IAI - die <strong>Internationale </strong>(ehemals: Industrie)<strong> Allianz für Interoperabilität</strong> angenommen.</p> <h3 align="left"><strong><img src="../../links/i/iai.gif" align="left" hspace="4" vspace="4" WIDTH="86" HEIGHT="86"></strong><a name="3"></a><strong>Wer ist die IAI? <br> Wer die Internationale ALLIANCE für INTEROPERABILITY?</strong></h3> <p>Die IAI ist ein gemeinnütziges Bündnis im Bauwesen, das 1995 in den USA gegründet wurde. Laut eigenen Angaben (siehe <a href="http://iaiweb.lbl.gov" target="_blank">http://iaiweb.lbl.gov</a>) berücksichtigt die IAI Architekten, Ingenieure, Vertragsunternehmer, Bauherren sowie Facility-Manager (Gebäudeverwalter), Bauunternehmen, Softwareentwickler, Dienstleister, öffentliche Stellen, Forschung-Labors und Universitäten. Es gibt nationale Gruppen (sogenannte "Chapters") in Nordamerika, Deutschland, England, Frankreich, Singapur, den nordeuropäischen Ländern und Japan.</p> <p>Über 600 Unternehmen arbeiten international in der IAI mit. Auch zahlreiche deutsche (Bau-)Softwarehersteller (z.B. Autodesk, IEZ, Nemetschek, RoCAD, Microsoft) sowie Anwender (Dresdner Bank, Planungsgruppe Obermayer, Phillip Holzmann) sind (oder waren) lAI-Mitglieder. Eine aktuelle Mitgliederliste kann im Internet (noch einmal: <a href="http://iaiweb.lbl.gov" target="_blank">http://iaiweb.lbl.gov</a>) eingesehen werden. (Das deutschsprachiges IAI-Chapter mit einer ebenfalls aufschlußreichen Mitgliederliste findet man im übrigen unter <a href="http://www.opb.de/iai/" target="_blank">http://www.opb.de/iai/</a>). Die Organisationsform der IAI ist in allen Ländern identisch: <ul> <li>An der Spitze steht ein <strong>Vorstand</strong>, zuständig für administrative Aufgaben. </li> <li>Für die Abstimmung und Zusammenfassung der erarbeiteten Basisdatenmodelle sowie für die Organisation der Zusammenarbeit auf internationaler Ebene ist das <strong>Integrationskomitee</strong> verantwortlich. </li> <li>Die Definition der Basisdatenmodelle erfolgt in <strong>Fachgruppen</strong> (in Deutschland für die Bereiche Architektur, Konstruktion, Gebäudetechnik, Kosten, Facility Management und Verkehr).</li> <li><strong>Arbeitskreise</strong> stellen ferner die Verbindung zu Hochschulen und zur Forschung sowie die Implementierung in die Anwendungsprogramme sicher.</li> </ul> <h3 align="left"><img src="../../links/i/iai.gif" align="left" hspace="4" vspace="4" WIDTH="86" HEIGHT="86"><img src="dta-st2a.gif" align="right" hspace="4" vspace="4" WIDTH="300" HEIGHT="283"><strong><a name="4">Was</a> macht die IAI?</strong></h3> <p>Die IAI verfolgt das Ziel, die vielen Teilaspekte der <a target="_new" href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_a.htm#aec">AEC</a>/<a target="_new" href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_f.htm#fm">FM</a>-Industrie zu integrieren / in einem Datenmodell zusammenzuführen (die IAI selber betont diese Kombination "AEC/FM"), indem sie eine gemeinsame, universelle Sprache definiert hat und die Definition ständig weiterentwickelt  man spricht von "Industrie-Foundation-Classes (IFC)". Diese Definition erfaßt <ul> <li>alle dem Architekten bekannten Leistungsphasen (Entwurf, Planung, Konstruktion, Vergabe, ...), </li> <li>bezieht den Erstellung des Gebäudes mit ein und</li> <li>berücksichtigt seinen Lebens-Zyklus und das Gebäude-Management </li> <li>bis hin zum Abriß.</li> </ul> <p>Das IFC-Datenmodell baut auf bestehenden Entwicklungen auf, Baudaten zwischen verschieden Programmen auszutauschen. So entsprechen die IFC-Basisdaten weitgehend dem STEP-Standard (Standard for the Exchange of Product Model Data - siehe auch <a href="http://www.steptools.com" target="_new">http://www.steptools.com/</a> und. <a href="http://www.scra.org/uspro//stds/stepage.html" target="_new">http://www.scra.org/uspro//stds/stepage.html</a>). STEP ist ursprünglich ein von der Fahrzeugindustrie motivierter und genormter Standard zum Austausch produktdefinierender Daten, die neben den Geometriedaten eines Bauteils, topologische und technologische Informationen zur vollständigen Produktbeschreibung enthalten. <br>   </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> </td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%">Zu den Motivationsgründen der IAI, IFC zu entwickeln, zählen Erkenntnisse wie:<ul> <li>Bauherren erwarten mehr <strong>Flexibilität und Qualität</strong> in ihren Gebäudeentwürfen, damit sie dem wachsenden Druck in ihrem eigenen Geschäft besser gewachsen sind. </li> <li>Die <strong>Entwicklungs- und Herstellungsprozesse</strong> nahezu aller Produkte reduzierten sich von mehreren Jahren auf einige Monate. Die baulichen Einrichtungen, ihre Errichtung und ihre Anpassungsmöglichkeiten müssen damit Schritt halten.</li> <li>Geschätzt bis zu 30% der <strong>Gebäudekosten</strong> werden durch die gegenwärtigen Abläufe im Bauwesen nutzlos verbraten. Bauherren verlangen Gebäude / Facilities, die billiger zu errichten, zu erhalten und zu betreiben sind.</li> <li><strong>Know-How</strong>, das sich im Planungsprozeß, bei der Ausschreibung, während der Bauausführung und danach ansammelt, sollte beim Weg durch die Instanzen nicht verpuffen sondern gesammelt werden:</li> </ul> <p align="center"><img src="dta-st3.jpg" WIDTH="450" HEIGHT="250"></p> <ul> <li>Gebäude enthalten Erzeugnisse, die irgendwo auf dem Globus hergestellt werden. Auch der AEC/FM-Prozeß wird immer globaler  worauf man sich einstellen muß.</li> </ul> <p>Ob nun global verteilt große Geschäftshäuser geplant werden oder im Umkreis von 20 Kilometern alle Beteiligten für den Neubau eines Einfamilienhauses zu finden sind  die Anforderung an die Planung und Realisation einer architektonischen Aufgabe sind gestiegen. Verbessert werden müssen<ul> <li>die Kommunikation, </li> <li>die Produktivität, </li> <li>die Zeitplanung und deren Einhaltung,</li> <li>das Kosten- und Qualitäts-Niveau.</li> </ul> <p>Die IAI will dazu beitragen, "die kollektive Macht der Industrie auszunutzen, um einen Kommunikations-Standard zu setzen, der zukünftig die Zusammenarbeit und die globale Expansion im Bauwesen fördert."<br>   </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> </td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3><a name="5">Was</a> bedeutet "Interoperabilität"?</h3> <p>"Interoperabilität" ist ein Kunstwort, das die Fähigkeit beschreibt, Daten untereinander austauschen zu können. Interoperabilität ermöglicht allen Projektbeteiligten die interdisziplinäre Nutzung von Daten aus einem großen, flexiblen Informationspool über alle "Lebensphasen" eines Bauwerkes - also von der Planung über die Erstellung bis hin zur Nutzung. </p> <p>Technisch gesehen wird die Form wichtiger, im Kernmodell enthaltener Objekte wie Wände, Fenster oder Türen mit Hilfe "impliziter Geometrie" (über Parameter erzeugte Geometrie) beschrieben. Damit werden Mehrdeutigkeiten oder Fehlinterpretationen vermieden, wie sie bei Verwendung "expliziter Geometrie" (über Polygone definierte Geometrie) auftreten können. Da sich aber nicht alle Objekte über Parameter eindeutig beschreiben lassen, ist ein Rückgriff auf "explizite Geometrie" vorgesehen: in diesen Fällen wird auf bestehende ISO-Normen bzw. STEP-Standards zurückgegriffen.</p> <p>Alle projekt- und gebäudebeschreibenden Inhalte werden in einem Datenmodell beschrieben - das gilt für organisatorische Dinge (Adresse des Bauherren), für das geometrische Modell wie zum Beispiel auch für die Oberflächenbeschreibung eines einzelnen Bauteils. Kann ein an sich IFC-kompatibles Programm mit einzelnen Informationen im Datenbestand nichts anfangen, weil beispielsweise k-Werte für ein Statikprogramm keine Relevanz haben, dann muß das jeweilige Programm aber trotzdem diese Informationen verwahren und sie beim Speichern der eigenen Daten wieder berücksichtigen. Einmal eingegebene Daten dürfen nicht unter den Tisch fallen!</p> <p>Daten zwischen unterschiedlichen Plattformen werden über ASCII-Dateien (*.IFC) ausgetauscht. In Zukunft sollen Objekte aber mit Hilfe einheitlicher Standards zur Beschreibung von "shared objects" direkt transferiert werden. Ob dabei der UNIX-Standard CORBA (Common Object Request Broker) oder doch eher der Windows-Standard COM / <a href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_o.htm#ole">OLE</a> verwendet wird, ist zur Zeit noch offen. Der Trend geht aufgrund der Verbreitung von Windows allerdings deutlich in Richtung COM / OLE. Innerhalb der AutoCAD-Welt erfolgt der Datenaustausch weiterhin mit Hilfe von DWG-Dateien, welche die gesamte IFC-Datenstruktur beinhalten. </p> <h3><strong><a name="6">vorübergehend</a> abschließend ...</strong></h3> <p>Die Vorteile der IAI-Strategie liegen auf der Hand. Der gemeinsame Daten-Zugriff aller Anwendungen erspart die mehrfache Dateneingabe. Es kann sichergestellt werden, daß alle Planungsbeteiligten Zugriff auf alle Projektinformationen haben. IFC vermeidet Informationsverluste und Fehler durch unzureichend funktionierende Datentransferprogramme. Vom Aufbau eines großen Daten- und Know-how-Pools profitieren alle am Bau beteiligten Parteien, der Bauherr bzw. sein Verwalter und letztendlich auch die Abrißfirma. Derzeit noch manuell ausgeführte Prozesse können automatisiert werden (Stichworte: "dynamische Updates", "Kostenkalkulation", "automatische Steuerung von Gebäudekontrollsystemen").</p> <p>Bei aller Euphorie sollte aber nicht vergessen werden,<ul> <li>daß der Einsatz eines IFC-basierenden Datenmodells nur Sinn macht, wenn durchgehend bauteil- bzw. objektorientiert gearbeitet wird (siehe noch einmal <a href="f-aec1.htm">(R)EVOLUTION im Architekturbüro</a>).</li> </ul> <center><table border="0" cellspacing="4"> <tr> <td align="right" valign="top" class="normalabst"><strong><u>klassisches CAD:</u></strong><br> Bauteile bestehen<br> aus vielen einzelnen<br> Elementen</td> <td align="center" valign="top" class="normalabst"><img src="obj-o1.gif" align="top" vspace="3" WIDTH="300" HEIGHT="213"></td> </tr> <tr> <td align="right" valign="top" class="normalabst"><u><strong>objektorientiertes CAD:</strong></u><br> Bauteile bestehen aus jeweils<br> einem Element und<br> angeschlossene Objekte<br> (z.B. Wände) können<br> auf sie reagieren</td> <td align="center" valign="top" class="normalabst"><img src="o-ani.gif" align="top" vspace="3" WIDTH="300" HEIGHT="213"></td> </tr> </table> </center><ul> <li>Zur Zeit ist die Technik noch nicht so weit, daß alle Planungsbeteiligten ständig IN einem IFC-Datentopf arbeiten können. Stattdessen holen sie sich AUS dem gemeinsamen Datentopf den aktuellen Datenbestand, konvertieren ihn (oder auch nicht), machen ihre Bearbeitungen LOKAL und legen dann 2 Stunden oder 2 Wochen später den geänderten Datenbestand in dem gemeinsamen IFC-Datentopf wieder ab. Was passiert aber, wenn zwischenzeitlich andere Partner ihre Änderungen oder Ergänzungen viel schneller vorgenommen haben? Wessen Eingaben fallen dann unter den Tisch? Eine Art von Datenfluß-Organisation ist weiterhin von Nöten (siehe redundante Daten / Redundanz)<br> Solange die IFC-Schnittstelle nur als verbesserter, DXF-ähnlicher Datenaustausch-Mechanismus agiert, der immer nur den gesamten Datenpool berücksichtigt und nicht einzelne Inhalte abgleichen kann, ist nur der halbe Weg bis zur optimalen Datenhaltung beschritten. Ziel muß es sein, daß überhaupt nicht mehr mit eigenen, lokalen Datenbeständen gearbeitet wird, sondern alle direkt auf einen Topf zugreifen.</li> <li>Anfang 2000 bietet einige Firmen wie Autodesk oder Nemetschek ein IFC Import/Export-Dienstprogramm an, das ggfls. kostenlos von der jeweiligen Website heruntergeladen werden kann und das meistens die aktuellen IFC 1.5.1-Spezifikationen unterstützt.<br>   </li> </ul> </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="right" bgcolor="#000000"><font color="#AFD8B0"><strong>  </strong></font></td> </tr> <tr> <td align="right"><p class="kringelliste"><font color="#000000"><strong>© Alfons Oebbeke, Neustadt 1997 - 2001<br>   <br> </strong></font><a href="#Seitenanfang" target="_self"><img src="../../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> zurück zum Seitenanfang<br> <a target="_top" href="../index.htm"><img src="../../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> zur Magazin-Übersicht<br> <a target="_top" href="http://www.aecweb.de"><img src="../../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a>oder Titelseite ("home")</td> </tr> </table> <span class="ueb">IAI / IFC:</span><br> <span class="u3">Der Turmbau zu Babel am Ende des 20. Jahrhunderts</span></strong></td> </tr> <tr> <td bgcolor="#000000" colspan="3" width="729">    </td> </tr> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br>   erste Fassung:<br> 6.11.1997</td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3><strong>  <br> Kapitelübersicht:</strong></h3> <p class="kr-neu"><a href="#1" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Informationen sammeln und Know-how verfügbar machen</strong></p> <p class="kr-neu"><a href="#2" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a><strong> Planung und Projekt organisieren</strong></p> <p class="kr-neu"><a href="#3" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Wer ist die IAI? Wer die Internationale ALLIANCE für INTEROPERABILITY?</strong></p> <p class="kr-neu"><a href="#4" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Was macht die IAI?</strong></p> <p class="kr-neu"><a href="#5" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Was bedeutet "Interoperabilität"?</strong></p> <p class="kr-neu"><a href="#6" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a><strong> vorübergehend abschließend<br>   </strong></td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td bgcolor="#000000" width="729">    </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> kursiv markierte Links verweisen auf GLOSSAR.de</td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3>  <br> <strong><a name="1" target="_self">Informationen</a> sammeln und Know-How verfügbar machen</strong></h3> <p>Architekten und ihre Partner stehen unter einem zunehmenden Druck, mehr Qualität für geringere Honorare mit strafferen Zeitplänen abliefern zu müssen. Bislang haben moderne Technologien noch keinen signifikanten Nutzen für das Bauwesen erbracht. Zwar haben Büroautomationswerkzeuge wie Textverarbeitung oder Tabellenkalkulation für Verbesserungen gesorgt, und bestehende AEC- (CAD-und AVA-)Werkzeuge haben außerdem <strong>EINZELNE</strong> Aspekte im Designprozeß wesentlich verbessern können, allerdings von entscheidender Wirkung bezüglich Qualität und Produktivität bei Architekturdienstleistungen waren sie bis jetzt noch nicht - weil die <strong>VERBINDUNG</strong> der Einzelkomponenten noch kränkelt.</p> <p>Vom ersten Entwurf über die Werkplanung mit der Einbeziehung der technischen Gewerke bis zur Ausschreibung und Vergabe gehen mannigfach Informationen (wichtige und unwichtige) durch viele Hände. Und das setzt sich fort bei der Herstellung und dem Betrieb eines Bauwerkes bis hin zum Abriß. <strong>Schön</strong>, wenn all dieses Know-How (gefiltert oder ungefiltert) den Planungspartnern, auf der Baustelle und später bei der Gebäudeverwaltung zur Verfügung steht und der Wissenpool ständig weiter ausgebaut werden kann. <strong>Dumm</strong>, wenn sich trotz aller modernen Technik die Werkzeuge (gemeint ist die EDV) der am Bau beteiligen Personen bzw. Firmen nicht oder nur unvollständig verstehen und Informationen immer wieder verpuffen oder unter den Tisch fallen.</p> <p>Die zunehmende Informationsmenge kann zwar leicht elektronisch dargestellt und manipuliert werden, aber die Technik ist (noch) nicht (ausreichend) in der Lage, die verschiedenen Informations-Formate so konsequent zu managen, wie es in der Praxis benötigt wird. Das Problem hat einen Namen: "<strong>Datenaustausch</strong>". Projekt-Daten müssen ausgetauscht werden, <img src="dta-st1a.gif" align="right" hspace="4" vspace="4" WIDTH="300" HEIGHT="282"><ul> <li>weil verschiedene Unternehmen an einem Projekt arbeiten: Architektur- und (Fach)Ingenieurbüros, Bauunternehmen und Behörden, Bauherren, Dienstleister und Lieferanten;</li> <li>weil viele unterschiedliche Systeme für unterschiedliche Aufgaben verwendet werden: Entwurf, Werkplanung, Statik, TGA, Präsentation, Ausschreibung und Vergabe, Kalkulation, Facility Management und</li> <li>wegen der Einbeziehung von Fremddaten: aus dem Kataster- und/oder Bebauungsplan, Bauteil-Katalogen, ...</li> </ul> <p>Mit verschiedenen Datenaustauschstandards hat die Branche in der Vergangenheit versucht, das babelonische Treiben in den Griff zu bekommen - was man zur Zeit nicht als geglückt bezeichnen kann. Denn noch immer verständigt man sich nur auf der Basis des kleinsten gemeinsamen Nenners (und einigt sich meistens auf das DXF-Format) - eine Situation, die Informationsverluste UNvermeidbar macht. Besonders alphanumerische, bauteilbeschreibende Informationen, die sich ständig neu ergeben können oder spontan - aber dokumentiert - neu überdacht werden müssen, bleiben auf der Strecke. Allerdings kann man diese aktuelle Situation nicht nur den Datenaustausch-Standards ankreiden. Ohne bauteil-(objekt-)orientierte <a target="_new" href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_a.htm#aec">AEC</a>-Systeme sind auch die besten Datenaustausch-Mechanismen machtlos (siehe auch <a href="f-aec1.htm" target="_self">(R)EVOLUTION im Architekturbüro</a>), denn solange beispielsweise ein CAD-System nur wie ein elektronisches Zeichenbrett eingesetzt wird und CAD-Zeichnungen nur aus Strichen bestehen, können BAUTEILinformationen nicht sinnvoll und langfristig einbezogen werden.<br>   </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> </td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3><strong><a name="2" target="_self">Planung</a> und Projekt organisieren</strong></h3> <p>Nimmt man als Beispiel ein einfaches Fenster (ein sehr beliebtes Beispiel). Es erscheint während einer Projektierung in unterschiedlichen Formen an unterschiedlichen Stellen: <ul> <li>in Grundriß-, Schnitt und Ansichtsplänen,</li> <li>in Massenermittlungen, Ausschreibungen und Kostenvoranschlägen,</li> <li>in der Statik und im Wärmeschutznachweis,</li> <li>in Baubeschreibungen und Vertragsdokumenten, ...</li> <li>in Präsentationen</li> <li>(und im Kopf des Bauherren  was aber sowieso ein Problem ist, und sich nie ändern wird).</li> </ul> <p>Was nun aber, wenn das Fenster geändert werden muß? Der Architekt ist für die Koordinierung der Änderungen verantwortlich - ein schwieriges Unterfangen, da heutzutage der gleiche Vorgang bzw. Gegenstand in verschiedenen Dokumenten vertreten ist, die physikalisch an unterschiedlichen Orten aufbewahrt werden und sich unter der Kontrolle unterschiedlicher Personen befinden.<br> Eine weitere Herausforderung ist für den Architekten mit der Bereitstellung von Gebäudedaten in elektronischer Form für die Nutzung durch den Bauherren bzw. seinen Vertreter (Gebäudeverwaltung) gegeben. Informationen und Inhalte, wie sie für die Gebäudeverwaltung benötigt werden, differieren naturgemäß von dem, was im Designprozeß zur Anwendung kommt. Sehr häufig müssen Gebäudedaten auch in ein bestehendes Verwaltungssystem integriert werden. Und als ob all dieses nicht ausreichend wäre, hat jeder Bauherr unterschiedliche Anforderungen und jedes Bauwerk einen unvergleichbaren Verwendungszweck. Gegenwärtig sind diese Prozesse des Datenaustausches nicht automatisierbar und erfordern viel Handarbeit, sie verursachen zum Teil erhebliche zusätzliche Kosten und bergen viele Gefahren z.B. in Form von Übertragungsfehlern oder Datenverlusten.</p> <p align="left">Informationen und Know-How besser managen sowie Planung und Projekte effizienter organisieren - diesen Ansprüchen hat sich die IAI - die <strong>Internationale </strong>(ehemals: Industrie)<strong> Allianz für Interoperabilität</strong> angenommen.</p> <h3 align="left"><strong><img src="../../links/i/iai.gif" align="left" hspace="4" vspace="4" WIDTH="86" HEIGHT="86"></strong><a name="3" target="_self"></a><strong>Wer ist die IAI? <br> Wer die Internationale ALLIANCE für INTEROPERABILITY?</strong></h3> <p>Die IAI ist ein gemeinnütziges Bündnis im Bauwesen, das 1995 in den USA gegründet wurde. Laut eigenen Angaben (siehe <a href="http://iaiweb.lbl.gov" target="_blank">http://iaiweb.lbl.gov</a>) berücksichtigt die IAI Architekten, Ingenieure, Vertragsunternehmer, Bauherren sowie Facility-Manager (Gebäudeverwalter), Bauunternehmen, Softwareentwickler, Dienstleister, öffentliche Stellen, Forschung-Labors und Universitäten. Es gibt nationale Gruppen (sogenannte "Chapters") in Nordamerika, Deutschland, England, Frankreich, Singapur, den nordeuropäischen Ländern und Japan.</p> <p>Über 600 Unternehmen arbeiten international in der IAI mit. Auch zahlreiche deutsche (Bau-)Softwarehersteller (z.B. Autodesk, IEZ, Nemetschek, RoCAD, Microsoft) sowie Anwender (Dresdner Bank, Planungsgruppe Obermayer, Phillip Holzmann) sind (oder waren) lAI-Mitglieder. Eine aktuelle Mitgliederliste kann im Internet (noch einmal: <a href="http://iaiweb.lbl.gov" target="_blank">http://iaiweb.lbl.gov</a>) eingesehen werden. (Das deutschsprachiges IAI-Chapter mit einer ebenfalls aufschlußreichen Mitgliederliste findet man im übrigen unter <a href="http://www.opb.de/iai/" target="_blank">http://www.opb.de/iai/</a>). Die Organisationsform der IAI ist in allen Ländern identisch: <ul> <li>An der Spitze steht ein <strong>Vorstand</strong>, zuständig für administrative Aufgaben. </li> <li>Für die Abstimmung und Zusammenfassung der erarbeiteten Basisdatenmodelle sowie für die Organisation der Zusammenarbeit auf internationaler Ebene ist das <strong>Integrationskomitee</strong> verantwortlich. </li> <li>Die Definition der Basisdatenmodelle erfolgt in <strong>Fachgruppen</strong> (in Deutschland für die Bereiche Architektur, Konstruktion, Gebäudetechnik, Kosten, Facility Management und Verkehr).</li> <li><strong>Arbeitskreise</strong> stellen ferner die Verbindung zu Hochschulen und zur Forschung sowie die Implementierung in die Anwendungsprogramme sicher.</li> </ul> <h3 align="left"><img src="../../links/i/iai.gif" align="left" hspace="4" vspace="4" WIDTH="86" HEIGHT="86"><img src="dta-st2a.gif" align="right" hspace="4" vspace="4" WIDTH="300" HEIGHT="283"><strong><a name="4" target="_self">Was</a> macht die IAI?</strong></h3> <p>Die IAI verfolgt das Ziel, die vielen Teilaspekte der <a target="_new" href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_a.htm#aec">AEC</a>/<a target="_new" href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_f.htm#fm">FM</a>-Industrie zu integrieren / in einem Datenmodell zusammenzuführen (die IAI selber betont diese Kombination "AEC/FM"), indem sie eine gemeinsame, universelle Sprache definiert hat und die Definition ständig weiterentwickelt  man spricht von "Industrie-Foundation-Classes (IFC)". Diese Definition erfaßt <ul> <li>alle dem Architekten bekannten Leistungsphasen (Entwurf, Planung, Konstruktion, Vergabe, ...), </li> <li>bezieht den Erstellung des Gebäudes mit ein und</li> <li>berücksichtigt seinen Lebens-Zyklus und das Gebäude-Management </li> <li>bis hin zum Abriß.</li> </ul> <p>Das IFC-Datenmodell baut auf bestehenden Entwicklungen auf, Baudaten zwischen verschieden Programmen auszutauschen. So entsprechen die IFC-Basisdaten weitgehend dem STEP-Standard (Standard for the Exchange of Product Model Data - siehe auch <a href="http://www.steptools.com" target="_new">http://www.steptools.com/</a> und. <a href="http://www.scra.org/uspro//stds/stepage.html" target="_new">http://www.scra.org/uspro//stds/stepage.html</a>). STEP ist ursprünglich ein von der Fahrzeugindustrie motivierter und genormter Standard zum Austausch produktdefinierender Daten, die neben den Geometriedaten eines Bauteils, topologische und technologische Informationen zur vollständigen Produktbeschreibung enthalten. <br>   </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> </td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%">Zu den Motivationsgründen der IAI, IFC zu entwickeln, zählen Erkenntnisse wie:<ul> <li>Bauherren erwarten mehr <strong>Flexibilität und Qualität</strong> in ihren Gebäudeentwürfen, damit sie dem wachsenden Druck in ihrem eigenen Geschäft besser gewachsen sind. </li> <li>Die <strong>Entwicklungs- und Herstellungsprozesse</strong> nahezu aller Produkte reduzierten sich von mehreren Jahren auf einige Monate. Die baulichen Einrichtungen, ihre Errichtung und ihre Anpassungsmöglichkeiten müssen damit Schritt halten.</li> <li>Geschätzt bis zu 30% der <strong>Gebäudekosten</strong> werden durch die gegenwärtigen Abläufe im Bauwesen nutzlos verbraten. Bauherren verlangen Gebäude / Facilities, die billiger zu errichten, zu erhalten und zu betreiben sind.</li> <li><strong>Know-How</strong>, das sich im Planungsprozeß, bei der Ausschreibung, während der Bauausführung und danach ansammelt, sollte beim Weg durch die Instanzen nicht verpuffen sondern gesammelt werden:</li> </ul> <p align="center"><img src="dta-st3.jpg" WIDTH="450" HEIGHT="250"></p> <ul> <li>Gebäude enthalten Erzeugnisse, die irgendwo auf dem Globus hergestellt werden. Auch der AEC/FM-Prozeß wird immer globaler  worauf man sich einstellen muß.</li> </ul> <p>Ob nun global verteilt große Geschäftshäuser geplant werden oder im Umkreis von 20 Kilometern alle Beteiligten für den Neubau eines Einfamilienhauses zu finden sind  die Anforderung an die Planung und Realisation einer architektonischen Aufgabe sind gestiegen. Verbessert werden müssen<ul> <li>die Kommunikation, </li> <li>die Produktivität, </li> <li>die Zeitplanung und deren Einhaltung,</li> <li>das Kosten- und Qualitäts-Niveau.</li> </ul> <p>Die IAI will dazu beitragen, "die kollektive Macht der Industrie auszunutzen, um einen Kommunikations-Standard zu setzen, der zukünftig die Zusammenarbeit und die globale Expansion im Bauwesen fördert."<br>   </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> </td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3><a name="5" target="_self">Was</a> bedeutet "Interoperabilität"?</h3> <p>"Interoperabilität" ist ein Kunstwort, das die Fähigkeit beschreibt, Daten untereinander austauschen zu können. Interoperabilität ermöglicht allen Projektbeteiligten die interdisziplinäre Nutzung von Daten aus einem großen, flexiblen Informationspool über alle "Lebensphasen" eines Bauwerkes - also von der Planung über die Erstellung bis hin zur Nutzung. </p> <p>Technisch gesehen wird die Form wichtiger, im Kernmodell enthaltener Objekte wie Wände, Fenster oder Türen mit Hilfe "impliziter Geometrie" (über Parameter erzeugte Geometrie) beschrieben. Damit werden Mehrdeutigkeiten oder Fehlinterpretationen vermieden, wie sie bei Verwendung "expliziter Geometrie" (über Polygone definierte Geometrie) auftreten können. Da sich aber nicht alle Objekte über Parameter eindeutig beschreiben lassen, ist ein Rückgriff auf "explizite Geometrie" vorgesehen: in diesen Fällen wird auf bestehende ISO-Normen bzw. STEP-Standards zurückgegriffen.</p> <p>Alle projekt- und gebäudebeschreibenden Inhalte werden in einem Datenmodell beschrieben - das gilt für organisatorische Dinge (Adresse des Bauherren), für das geometrische Modell wie zum Beispiel auch für die Oberflächenbeschreibung eines einzelnen Bauteils. Kann ein an sich IFC-kompatibles Programm mit einzelnen Informationen im Datenbestand nichts anfangen, weil beispielsweise k-Werte für ein Statikprogramm keine Relevanz haben, dann muß das jeweilige Programm aber trotzdem diese Informationen verwahren und sie beim Speichern der eigenen Daten wieder berücksichtigen. Einmal eingegebene Daten dürfen nicht unter den Tisch fallen!</p> <p>Daten zwischen unterschiedlichen Plattformen werden über ASCII-Dateien (*.IFC) ausgetauscht. In Zukunft sollen Objekte aber mit Hilfe einheitlicher Standards zur Beschreibung von "shared objects" direkt transferiert werden. Ob dabei der UNIX-Standard CORBA (Common Object Request Broker) oder doch eher der Windows-Standard COM / <a href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_o.htm#ole" target="_self">OLE</a> verwendet wird, ist zur Zeit noch offen. Der Trend geht aufgrund der Verbreitung von Windows allerdings deutlich in Richtung COM / OLE. Innerhalb der AutoCAD-Welt erfolgt der Datenaustausch weiterhin mit Hilfe von DWG-Dateien, welche die gesamte IFC-Datenstruktur beinhalten. </p> <h3><strong><a name="6" target="_self">vorübergehend</a> abschließend ...</strong></h3> <p>Die Vorteile der IAI-Strategie liegen auf der Hand. Der gemeinsame Daten-Zugriff aller Anwendungen erspart die mehrfache Dateneingabe. Es kann sichergestellt werden, daß alle Planungsbeteiligten Zugriff auf alle Projektinformationen haben. IFC vermeidet Informationsverluste und Fehler durch unzureichend funktionierende Datentransferprogramme. Vom Aufbau eines großen Daten- und Know-how-Pools profitieren alle am Bau beteiligten Parteien, der Bauherr bzw. sein Verwalter und letztendlich auch die Abrißfirma. Derzeit noch manuell ausgeführte Prozesse können automatisiert werden (Stichworte: "dynamische Updates", "Kostenkalkulation", "automatische Steuerung von Gebäudekontrollsystemen").</p> <p>Bei aller Euphorie sollte aber nicht vergessen werden,<ul> <li>daß der Einsatz eines IFC-basierenden Datenmodells nur Sinn macht, wenn durchgehend bauteil- bzw. objektorientiert gearbeitet wird (siehe noch einmal <a href="f-aec1.htm" target="_self">(R)EVOLUTION im Architekturbüro</a>).</li> </ul> <center><table border="0" cellspacing="4"> <tr> <td align="right" valign="top" class="normalabst"><strong><u>klassisches CAD:</u></strong><br> Bauteile bestehen<br> aus vielen einzelnen<br> Elementen</td> <td align="center" valign="top" class="normalabst"><img src="obj-o1.gif" align="top" vspace="3" WIDTH="300" HEIGHT="213"></td> </tr> <tr> <td align="right" valign="top" class="normalabst"><u><strong>objektorientiertes CAD:</strong></u><br> Bauteile bestehen aus jeweils<br> einem Element und<br> angeschlossene Objekte<br> (z.B. Wände) können<br> auf sie reagieren</td> <td align="center" valign="top" class="normalabst"><img src="o-ani.gif" align="top" vspace="3" WIDTH="300" HEIGHT="213"></td> </tr> </table> </center><ul> <li>Zur Zeit ist die Technik noch nicht so weit, daß alle Planungsbeteiligten ständig IN einem IFC-Datentopf arbeiten können. Stattdessen holen sie sich AUS dem gemeinsamen Datentopf den aktuellen Datenbestand, konvertieren ihn (oder auch nicht), machen ihre Bearbeitungen LOKAL und legen dann 2 Stunden oder 2 Wochen später den geänderten Datenbestand in dem gemeinsamen IFC-Datentopf wieder ab. Was passiert aber, wenn zwischenzeitlich andere Partner ihre Änderungen oder Ergänzungen viel schneller vorgenommen haben? Wessen Eingaben fallen dann unter den Tisch? Eine Art von Datenfluß-Organisation ist weiterhin von Nöten (siehe redundante Daten / Redundanz)<br> Solange die IFC-Schnittstelle nur als verbesserter, DXF-ähnlicher Datenaustausch-Mechanismus agiert, der immer nur den gesamten Datenpool berücksichtigt und nicht einzelne Inhalte abgleichen kann, ist nur der halbe Weg bis zur optimalen Datenhaltung beschritten. Ziel muß es sein, daß überhaupt nicht mehr mit eigenen, lokalen Datenbeständen gearbeitet wird, sondern alle direkt auf einen Topf zugreifen.</li> <li>Anfang 2000 bietet einige Firmen wie Autodesk oder Nemetschek ein IFC Import/Export-Dienstprogramm an, das ggfls. kostenlos von der jeweiligen Website heruntergeladen werden kann und das meistens die aktuellen IFC 1.5.1-Spezifikationen unterstützt.<br>   </li> </ul> </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="right" bgcolor="#000000"><font color="#AFD8B0"><strong>  </strong></font></td> </tr> <tr> <td align="right"><p class="kringelliste"><font color="#000000"><strong>© Alfons Oebbeke, Neustadt 1997 - 2001<br>   <br> </strong></font><a href="#Seitenanfang" target="_self"><img src="../../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> zurück zum Seitenanfang<br> <a target="_top" href="../index.htm"><img src="../../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> zur Magazin-Übersicht<br> <a target="_top" href="http://www.aecweb.de"><img src="../../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a>oder Titelseite ("home")</td> </tr> </table> <span class="ueb">IAI / IFC:</span><br> <span class="u3">Der Turmbau zu Babel am Ende des 20. Jahrhunderts</span></strong></td> </tr> <tr> <td bgcolor="#000000" colspan="3" width="729">    </td> </tr> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br>   erste Fassung:<br> 6.11.1997</td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3><strong>  <br> Kapitelübersicht:</strong></h3> <p class="kr-neu"><a href="#1" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Informationen sammeln und Know-how verfügbar machen</strong></p> <p class="kr-neu"><a href="#2" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a><strong> Planung und Projekt organisieren</strong></p> <p class="kr-neu"><a href="#3" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Wer ist die IAI? Wer die Internationale ALLIANCE für INTEROPERABILITY?</strong></p> <p class="kr-neu"><a href="#4" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Was macht die IAI?</strong></p> <p class="kr-neu"><a href="#5" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Was bedeutet "Interoperabilität"?</strong></p> <p class="kr-neu"><a href="#6" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a><strong> vorübergehend abschließend<br>   </strong></td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td bgcolor="#000000" width="729">    </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> kursiv markierte Links verweisen auf GLOSSAR.de</td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3>  <br> <strong><a name="1" target="_self">Informationen</a> sammeln und Know-How verfügbar machen</strong></h3> <p>Architekten und ihre Partner stehen unter einem zunehmenden Druck, mehr Qualität für geringere Honorare mit strafferen Zeitplänen abliefern zu müssen. Bislang haben moderne Technologien noch keinen signifikanten Nutzen für das Bauwesen erbracht. Zwar haben Büroautomationswerkzeuge wie Textverarbeitung oder Tabellenkalkulation für Verbesserungen gesorgt, und bestehende AEC- (CAD-und AVA-)Werkzeuge haben außerdem <strong>EINZELNE</strong> Aspekte im Designprozeß wesentlich verbessern können, allerdings von entscheidender Wirkung bezüglich Qualität und Produktivität bei Architekturdienstleistungen waren sie bis jetzt noch nicht - weil die <strong>VERBINDUNG</strong> der Einzelkomponenten noch kränkelt.</p> <p>Vom ersten Entwurf über die Werkplanung mit der Einbeziehung der technischen Gewerke bis zur Ausschreibung und Vergabe gehen mannigfach Informationen (wichtige und unwichtige) durch viele Hände. Und das setzt sich fort bei der Herstellung und dem Betrieb eines Bauwerkes bis hin zum Abriß. <strong>Schön</strong>, wenn all dieses Know-How (gefiltert oder ungefiltert) den Planungspartnern, auf der Baustelle und später bei der Gebäudeverwaltung zur Verfügung steht und der Wissenpool ständig weiter ausgebaut werden kann. <strong>Dumm</strong>, wenn sich trotz aller modernen Technik die Werkzeuge (gemeint ist die EDV) der am Bau beteiligen Personen bzw. Firmen nicht oder nur unvollständig verstehen und Informationen immer wieder verpuffen oder unter den Tisch fallen.</p> <p>Die zunehmende Informationsmenge kann zwar leicht elektronisch dargestellt und manipuliert werden, aber die Technik ist (noch) nicht (ausreichend) in der Lage, die verschiedenen Informations-Formate so konsequent zu managen, wie es in der Praxis benötigt wird. Das Problem hat einen Namen: "<strong>Datenaustausch</strong>". Projekt-Daten müssen ausgetauscht werden, <img src="dta-st1a.gif" align="right" hspace="4" vspace="4" WIDTH="300" HEIGHT="282"><ul> <li>weil verschiedene Unternehmen an einem Projekt arbeiten: Architektur- und (Fach)Ingenieurbüros, Bauunternehmen und Behörden, Bauherren, Dienstleister und Lieferanten;</li> <li>weil viele unterschiedliche Systeme für unterschiedliche Aufgaben verwendet werden: Entwurf, Werkplanung, Statik, TGA, Präsentation, Ausschreibung und Vergabe, Kalkulation, Facility Management und</li> <li>wegen der Einbeziehung von Fremddaten: aus dem Kataster- und/oder Bebauungsplan, Bauteil-Katalogen, ...</li> </ul> <p>Mit verschiedenen Datenaustauschstandards hat die Branche in der Vergangenheit versucht, das babelonische Treiben in den Griff zu bekommen - was man zur Zeit nicht als geglückt bezeichnen kann. Denn noch immer verständigt man sich nur auf der Basis des kleinsten gemeinsamen Nenners (und einigt sich meistens auf das DXF-Format) - eine Situation, die Informationsverluste UNvermeidbar macht. Besonders alphanumerische, bauteilbeschreibende Informationen, die sich ständig neu ergeben können oder spontan - aber dokumentiert - neu überdacht werden müssen, bleiben auf der Strecke. Allerdings kann man diese aktuelle Situation nicht nur den Datenaustausch-Standards ankreiden. Ohne bauteil-(objekt-)orientierte <a target="_new" href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_a.htm#aec">AEC</a>-Systeme sind auch die besten Datenaustausch-Mechanismen machtlos (siehe auch <a href="f-aec1.htm" target="_self">(R)EVOLUTION im Architekturbüro</a>), denn solange beispielsweise ein CAD-System nur wie ein elektronisches Zeichenbrett eingesetzt wird und CAD-Zeichnungen nur aus Strichen bestehen, können BAUTEILinformationen nicht sinnvoll und langfristig einbezogen werden.<br>   </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> </td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3><strong><a name="2" target="_self">Planung</a> und Projekt organisieren</strong></h3> <p>Nimmt man als Beispiel ein einfaches Fenster (ein sehr beliebtes Beispiel). Es erscheint während einer Projektierung in unterschiedlichen Formen an unterschiedlichen Stellen: <ul> <li>in Grundriß-, Schnitt und Ansichtsplänen,</li> <li>in Massenermittlungen, Ausschreibungen und Kostenvoranschlägen,</li> <li>in der Statik und im Wärmeschutznachweis,</li> <li>in Baubeschreibungen und Vertragsdokumenten, ...</li> <li>in Präsentationen</li> <li>(und im Kopf des Bauherren  was aber sowieso ein Problem ist, und sich nie ändern wird).</li> </ul> <p>Was nun aber, wenn das Fenster geändert werden muß? Der Architekt ist für die Koordinierung der Änderungen verantwortlich - ein schwieriges Unterfangen, da heutzutage der gleiche Vorgang bzw. Gegenstand in verschiedenen Dokumenten vertreten ist, die physikalisch an unterschiedlichen Orten aufbewahrt werden und sich unter der Kontrolle unterschiedlicher Personen befinden.<br> Eine weitere Herausforderung ist für den Architekten mit der Bereitstellung von Gebäudedaten in elektronischer Form für die Nutzung durch den Bauherren bzw. seinen Vertreter (Gebäudeverwaltung) gegeben. Informationen und Inhalte, wie sie für die Gebäudeverwaltung benötigt werden, differieren naturgemäß von dem, was im Designprozeß zur Anwendung kommt. Sehr häufig müssen Gebäudedaten auch in ein bestehendes Verwaltungssystem integriert werden. Und als ob all dieses nicht ausreichend wäre, hat jeder Bauherr unterschiedliche Anforderungen und jedes Bauwerk einen unvergleichbaren Verwendungszweck. Gegenwärtig sind diese Prozesse des Datenaustausches nicht automatisierbar und erfordern viel Handarbeit, sie verursachen zum Teil erhebliche zusätzliche Kosten und bergen viele Gefahren z.B. in Form von Übertragungsfehlern oder Datenverlusten.</p> <p align="left">Informationen und Know-How besser managen sowie Planung und Projekte effizienter organisieren - diesen Ansprüchen hat sich die IAI - die <strong>Internationale </strong>(ehemals: Industrie)<strong> Allianz für Interoperabilität</strong> angenommen.</p> <h3 align="left"><strong><img src="../../links/i/iai.gif" align="left" hspace="4" vspace="4" WIDTH="86" HEIGHT="86"></strong><a name="3" target="_self"></a><strong>Wer ist die IAI? <br> Wer die Internationale ALLIANCE für INTEROPERABILITY?</strong></h3> <p>Die IAI ist ein gemeinnütziges Bündnis im Bauwesen, das 1995 in den USA gegründet wurde. Laut eigenen Angaben (siehe <a href="http://iaiweb.lbl.gov" target="_blank">http://iaiweb.lbl.gov</a>) berücksichtigt die IAI Architekten, Ingenieure, Vertragsunternehmer, Bauherren sowie Facility-Manager (Gebäudeverwalter), Bauunternehmen, Softwareentwickler, Dienstleister, öffentliche Stellen, Forschung-Labors und Universitäten. Es gibt nationale Gruppen (sogenannte "Chapters") in Nordamerika, Deutschland, England, Frankreich, Singapur, den nordeuropäischen Ländern und Japan.</p> <p>Über 600 Unternehmen arbeiten international in der IAI mit. Auch zahlreiche deutsche (Bau-)Softwarehersteller (z.B. Autodesk, IEZ, Nemetschek, RoCAD, Microsoft) sowie Anwender (Dresdner Bank, Planungsgruppe Obermayer, Phillip Holzmann) sind (oder waren) lAI-Mitglieder. Eine aktuelle Mitgliederliste kann im Internet (noch einmal: <a href="http://iaiweb.lbl.gov" target="_blank">http://iaiweb.lbl.gov</a>) eingesehen werden. (Das deutschsprachiges IAI-Chapter mit einer ebenfalls aufschlußreichen Mitgliederliste findet man im übrigen unter <a href="http://www.opb.de/iai/" target="_blank">http://www.opb.de/iai/</a>). Die Organisationsform der IAI ist in allen Ländern identisch: <ul> <li>An der Spitze steht ein <strong>Vorstand</strong>, zuständig für administrative Aufgaben. </li> <li>Für die Abstimmung und Zusammenfassung der erarbeiteten Basisdatenmodelle sowie für die Organisation der Zusammenarbeit auf internationaler Ebene ist das <strong>Integrationskomitee</strong> verantwortlich. </li> <li>Die Definition der Basisdatenmodelle erfolgt in <strong>Fachgruppen</strong> (in Deutschland für die Bereiche Architektur, Konstruktion, Gebäudetechnik, Kosten, Facility Management und Verkehr).</li> <li><strong>Arbeitskreise</strong> stellen ferner die Verbindung zu Hochschulen und zur Forschung sowie die Implementierung in die Anwendungsprogramme sicher.</li> </ul> <h3 align="left"><img src="../../links/i/iai.gif" align="left" hspace="4" vspace="4" WIDTH="86" HEIGHT="86"><img src="dta-st2a.gif" align="right" hspace="4" vspace="4" WIDTH="300" HEIGHT="283"><strong><a name="4" target="_self">Was</a> macht die IAI?</strong></h3> <p>Die IAI verfolgt das Ziel, die vielen Teilaspekte der <a target="_new" href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_a.htm#aec">AEC</a>/<a target="_new" href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_f.htm#fm">FM</a>-Industrie zu integrieren / in einem Datenmodell zusammenzuführen (die IAI selber betont diese Kombination "AEC/FM"), indem sie eine gemeinsame, universelle Sprache definiert hat und die Definition ständig weiterentwickelt  man spricht von "Industrie-Foundation-Classes (IFC)". Diese Definition erfaßt <ul> <li>alle dem Architekten bekannten Leistungsphasen (Entwurf, Planung, Konstruktion, Vergabe, ...), </li> <li>bezieht den Erstellung des Gebäudes mit ein und</li> <li>berücksichtigt seinen Lebens-Zyklus und das Gebäude-Management </li> <li>bis hin zum Abriß.</li> </ul> <p>Das IFC-Datenmodell baut auf bestehenden Entwicklungen auf, Baudaten zwischen verschieden Programmen auszutauschen. So entsprechen die IFC-Basisdaten weitgehend dem STEP-Standard (Standard for the Exchange of Product Model Data - siehe auch <a href="http://www.steptools.com" target="_new">http://www.steptools.com/</a> und. <a href="http://www.scra.org/uspro//stds/stepage.html" target="_new">http://www.scra.org/uspro//stds/stepage.html</a>). STEP ist ursprünglich ein von der Fahrzeugindustrie motivierter und genormter Standard zum Austausch produktdefinierender Daten, die neben den Geometriedaten eines Bauteils, topologische und technologische Informationen zur vollständigen Produktbeschreibung enthalten. <br>   </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> </td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%">Zu den Motivationsgründen der IAI, IFC zu entwickeln, zählen Erkenntnisse wie:<ul> <li>Bauherren erwarten mehr <strong>Flexibilität und Qualität</strong> in ihren Gebäudeentwürfen, damit sie dem wachsenden Druck in ihrem eigenen Geschäft besser gewachsen sind. </li> <li>Die <strong>Entwicklungs- und Herstellungsprozesse</strong> nahezu aller Produkte reduzierten sich von mehreren Jahren auf einige Monate. Die baulichen Einrichtungen, ihre Errichtung und ihre Anpassungsmöglichkeiten müssen damit Schritt halten.</li> <li>Geschätzt bis zu 30% der <strong>Gebäudekosten</strong> werden durch die gegenwärtigen Abläufe im Bauwesen nutzlos verbraten. Bauherren verlangen Gebäude / Facilities, die billiger zu errichten, zu erhalten und zu betreiben sind.</li> <li><strong>Know-How</strong>, das sich im Planungsprozeß, bei der Ausschreibung, während der Bauausführung und danach ansammelt, sollte beim Weg durch die Instanzen nicht verpuffen sondern gesammelt werden:</li> </ul> <p align="center"><img src="dta-st3.jpg" WIDTH="450" HEIGHT="250"></p> <ul> <li>Gebäude enthalten Erzeugnisse, die irgendwo auf dem Globus hergestellt werden. Auch der AEC/FM-Prozeß wird immer globaler  worauf man sich einstellen muß.</li> </ul> <p>Ob nun global verteilt große Geschäftshäuser geplant werden oder im Umkreis von 20 Kilometern alle Beteiligten für den Neubau eines Einfamilienhauses zu finden sind  die Anforderung an die Planung und Realisation einer architektonischen Aufgabe sind gestiegen. Verbessert werden müssen<ul> <li>die Kommunikation, </li> <li>die Produktivität, </li> <li>die Zeitplanung und deren Einhaltung,</li> <li>das Kosten- und Qualitäts-Niveau.</li> </ul> <p>Die IAI will dazu beitragen, "die kollektive Macht der Industrie auszunutzen, um einen Kommunikations-Standard zu setzen, der zukünftig die Zusammenarbeit und die globale Expansion im Bauwesen fördert."<br>   </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> </td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3><a name="5" target="_self">Was</a> bedeutet "Interoperabilität"?</h3> <p>"Interoperabilität" ist ein Kunstwort, das die Fähigkeit beschreibt, Daten untereinander austauschen zu können. Interoperabilität ermöglicht allen Projektbeteiligten die interdisziplinäre Nutzung von Daten aus einem großen, flexiblen Informationspool über alle "Lebensphasen" eines Bauwerkes - also von der Planung über die Erstellung bis hin zur Nutzung. </p> <p>Technisch gesehen wird die Form wichtiger, im Kernmodell enthaltener Objekte wie Wände, Fenster oder Türen mit Hilfe "impliziter Geometrie" (über Parameter erzeugte Geometrie) beschrieben. Damit werden Mehrdeutigkeiten oder Fehlinterpretationen vermieden, wie sie bei Verwendung "expliziter Geometrie" (über Polygone definierte Geometrie) auftreten können. Da sich aber nicht alle Objekte über Parameter eindeutig beschreiben lassen, ist ein Rückgriff auf "explizite Geometrie" vorgesehen: in diesen Fällen wird auf bestehende ISO-Normen bzw. STEP-Standards zurückgegriffen.</p> <p>Alle projekt- und gebäudebeschreibenden Inhalte werden in einem Datenmodell beschrieben - das gilt für organisatorische Dinge (Adresse des Bauherren), für das geometrische Modell wie zum Beispiel auch für die Oberflächenbeschreibung eines einzelnen Bauteils. Kann ein an sich IFC-kompatibles Programm mit einzelnen Informationen im Datenbestand nichts anfangen, weil beispielsweise k-Werte für ein Statikprogramm keine Relevanz haben, dann muß das jeweilige Programm aber trotzdem diese Informationen verwahren und sie beim Speichern der eigenen Daten wieder berücksichtigen. Einmal eingegebene Daten dürfen nicht unter den Tisch fallen!</p> <p>Daten zwischen unterschiedlichen Plattformen werden über ASCII-Dateien (*.IFC) ausgetauscht. In Zukunft sollen Objekte aber mit Hilfe einheitlicher Standards zur Beschreibung von "shared objects" direkt transferiert werden. Ob dabei der UNIX-Standard CORBA (Common Object Request Broker) oder doch eher der Windows-Standard COM / <a href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_o.htm#ole" target="_self">OLE</a> verwendet wird, ist zur Zeit noch offen. Der Trend geht aufgrund der Verbreitung von Windows allerdings deutlich in Richtung COM / OLE. Innerhalb der AutoCAD-Welt erfolgt der Datenaustausch weiterhin mit Hilfe von DWG-Dateien, welche die gesamte IFC-Datenstruktur beinhalten. </p> <h3><strong><a name="6" target="_self">vorübergehend</a> abschließend ...</strong></h3> <p>Die Vorteile der IAI-Strategie liegen auf der Hand. Der gemeinsame Daten-Zugriff aller Anwendungen erspart die mehrfache Dateneingabe. Es kann sichergestellt werden, daß alle Planungsbeteiligten Zugriff auf alle Projektinformationen haben. IFC vermeidet Informationsverluste und Fehler durch unzureichend funktionierende Datentransferprogramme. Vom Aufbau eines großen Daten- und Know-how-Pools profitieren alle am Bau beteiligten Parteien, der Bauherr bzw. sein Verwalter und letztendlich auch die Abrißfirma. Derzeit noch manuell ausgeführte Prozesse können automatisiert werden (Stichworte: "dynamische Updates", "Kostenkalkulation", "automatische Steuerung von Gebäudekontrollsystemen").</p> <p>Bei aller Euphorie sollte aber nicht vergessen werden,<ul> <li>daß der Einsatz eines IFC-basierenden Datenmodells nur Sinn macht, wenn durchgehend bauteil- bzw. objektorientiert gearbeitet wird (siehe noch einmal <a href="f-aec1.htm" target="_self">(R)EVOLUTION im Architekturbüro</a>).</li> </ul> <center><table border="0" cellspacing="4"> <tr> <td align="right" valign="top" class="normalabst"><strong><u>klassisches CAD:</u></strong><br> Bauteile bestehen<br> aus vielen einzelnen<br> Elementen</td> <td align="center" valign="top" class="normalabst"><img src="obj-o1.gif" align="top" vspace="3" WIDTH="300" HEIGHT="213"></td> </tr> <tr> <td align="right" valign="top" class="normalabst"><u><strong>objektorientiertes CAD:</strong></u><br> Bauteile bestehen aus jeweils<br> einem Element und<br> angeschlossene Objekte<br> (z.B. Wände) können<br> auf sie reagieren</td> <td align="center" valign="top" class="normalabst"><img src="o-ani.gif" align="top" vspace="3" WIDTH="300" HEIGHT="213"></td> </tr> </table> </center><ul> <li>Zur Zeit ist die Technik noch nicht so weit, daß alle Planungsbeteiligten ständig IN einem IFC-Datentopf arbeiten können. Stattdessen holen sie sich AUS dem gemeinsamen Datentopf den aktuellen Datenbestand, konvertieren ihn (oder auch nicht), machen ihre Bearbeitungen LOKAL und legen dann 2 Stunden oder 2 Wochen später den geänderten Datenbestand in dem gemeinsamen IFC-Datentopf wieder ab. Was passiert aber, wenn zwischenzeitlich andere Partner ihre Änderungen oder Ergänzungen viel schneller vorgenommen haben? Wessen Eingaben fallen dann unter den Tisch? Eine Art von Datenfluß-Organisation ist weiterhin von Nöten (siehe redundante Daten / Redundanz)<br> Solange die IFC-Schnittstelle nur als verbesserter, DXF-ähnlicher Datenaustausch-Mechanismus agiert, der immer nur den gesamten Datenpool berücksichtigt und nicht einzelne Inhalte abgleichen kann, ist nur der halbe Weg bis zur optimalen Datenhaltung beschritten. Ziel muß es sein, daß überhaupt nicht mehr mit eigenen, lokalen Datenbeständen gearbeitet wird, sondern alle direkt auf einen Topf zugreifen.</li> <li>Anfang 2000 bietet einige Firmen wie Autodesk oder Nemetschek ein IFC Import/Export-Dienstprogramm an, das ggfls. kostenlos von der jeweiligen Website heruntergeladen werden kann und das meistens die aktuellen IFC 1.5.1-Spezifikationen unterstützt.<br>   </li> </ul> </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="right" bgcolor="#000000"><font color="#AFD8B0"><strong>  </strong></font></td> </tr> <tr> <td align="right"><p class="kringelliste"><font color="#000000"><strong>© Alfons Oebbeke, Neustadt 1997 - 2001<br>   <br> </strong></font><a href="#Seitenanfang" target="_self"><img src="../../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> zurück zum Seitenanfang<br> <a target="_top" href="../index.htm"><img src="../../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> zur Magazin-Übersicht<br> <a target="_top" href="http://www.aecweb.de"><img src="../../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a>oder Titelseite ("home")</td> </tr> </table>  <span class="ueb">IAI / IFC:</span><br> <span class="u3">Der Turmbau zu Babel am Ende des 20. Jahrhunderts</span></strong></td> </tr> <tr> <td bgcolor="#000000" colspan="3" width="729">    </td> </tr> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br>   erste Fassung:<br> 6.11.1997</td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3><strong>  <br> Kapitelübersicht:</strong></h3> <p class="kr-neu"><a href="#1" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Informationen sammeln und Know-how verfügbar machen</strong></p> <p class="kr-neu"><a href="#2" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a><strong> Planung und Projekt organisieren</strong></p> <p class="kr-neu"><a href="#3" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Wer ist die IAI? Wer die Internationale ALLIANCE für INTEROPERABILITY?</strong></p> <p class="kr-neu"><a href="#4" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Was macht die IAI?</strong></p> <p class="kr-neu"><a href="#5" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> <strong>Was bedeutet "Interoperabilität"?</strong></p> <p class="kr-neu"><a href="#6" target="_self"><img src="../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a><strong> vorübergehend abschließend<br>   </strong></td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td bgcolor="#000000" width="729">    </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> kursiv markierte Links verweisen auf GLOSSAR.de</td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3>  <br> <strong><a name="1" target="_self">Informationen</a> sammeln und Know-How verfügbar machen</strong></h3> <p>Architekten und ihre Partner stehen unter einem zunehmenden Druck, mehr Qualität für geringere Honorare mit strafferen Zeitplänen abliefern zu müssen. Bislang haben moderne Technologien noch keinen signifikanten Nutzen für das Bauwesen erbracht. Zwar haben Büroautomationswerkzeuge wie Textverarbeitung oder Tabellenkalkulation für Verbesserungen gesorgt, und bestehende AEC- (CAD-und AVA-)Werkzeuge haben außerdem <strong>EINZELNE</strong> Aspekte im Designprozeß wesentlich verbessern können, allerdings von entscheidender Wirkung bezüglich Qualität und Produktivität bei Architekturdienstleistungen waren sie bis jetzt noch nicht - weil die <strong>VERBINDUNG</strong> der Einzelkomponenten noch kränkelt.</p> <p>Vom ersten Entwurf über die Werkplanung mit der Einbeziehung der technischen Gewerke bis zur Ausschreibung und Vergabe gehen mannigfach Informationen (wichtige und unwichtige) durch viele Hände. Und das setzt sich fort bei der Herstellung und dem Betrieb eines Bauwerkes bis hin zum Abriß. <strong>Schön</strong>, wenn all dieses Know-How (gefiltert oder ungefiltert) den Planungspartnern, auf der Baustelle und später bei der Gebäudeverwaltung zur Verfügung steht und der Wissenpool ständig weiter ausgebaut werden kann. <strong>Dumm</strong>, wenn sich trotz aller modernen Technik die Werkzeuge (gemeint ist die EDV) der am Bau beteiligen Personen bzw. Firmen nicht oder nur unvollständig verstehen und Informationen immer wieder verpuffen oder unter den Tisch fallen.</p> <p>Die zunehmende Informationsmenge kann zwar leicht elektronisch dargestellt und manipuliert werden, aber die Technik ist (noch) nicht (ausreichend) in der Lage, die verschiedenen Informations-Formate so konsequent zu managen, wie es in der Praxis benötigt wird. Das Problem hat einen Namen: "<strong>Datenaustausch</strong>". Projekt-Daten müssen ausgetauscht werden, <img src="dta-st1a.gif" align="right" hspace="4" vspace="4" WIDTH="300" HEIGHT="282"><ul> <li>weil verschiedene Unternehmen an einem Projekt arbeiten: Architektur- und (Fach)Ingenieurbüros, Bauunternehmen und Behörden, Bauherren, Dienstleister und Lieferanten;</li> <li>weil viele unterschiedliche Systeme für unterschiedliche Aufgaben verwendet werden: Entwurf, Werkplanung, Statik, TGA, Präsentation, Ausschreibung und Vergabe, Kalkulation, Facility Management und</li> <li>wegen der Einbeziehung von Fremddaten: aus dem Kataster- und/oder Bebauungsplan, Bauteil-Katalogen, ...</li> </ul> <p>Mit verschiedenen Datenaustauschstandards hat die Branche in der Vergangenheit versucht, das babelonische Treiben in den Griff zu bekommen - was man zur Zeit nicht als geglückt bezeichnen kann. Denn noch immer verständigt man sich nur auf der Basis des kleinsten gemeinsamen Nenners (und einigt sich meistens auf das DXF-Format) - eine Situation, die Informationsverluste UNvermeidbar macht. Besonders alphanumerische, bauteilbeschreibende Informationen, die sich ständig neu ergeben können oder spontan - aber dokumentiert - neu überdacht werden müssen, bleiben auf der Strecke. Allerdings kann man diese aktuelle Situation nicht nur den Datenaustausch-Standards ankreiden. Ohne bauteil-(objekt-)orientierte <a target="_new" href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_a.htm#aec">AEC</a>-Systeme sind auch die besten Datenaustausch-Mechanismen machtlos (siehe auch <a href="f-aec1.htm" target="_self">(R)EVOLUTION im Architekturbüro</a>), denn solange beispielsweise ein CAD-System nur wie ein elektronisches Zeichenbrett eingesetzt wird und CAD-Zeichnungen nur aus Strichen bestehen, können BAUTEILinformationen nicht sinnvoll und langfristig einbezogen werden.<br>   </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> </td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3><strong><a name="2" target="_self">Planung</a> und Projekt organisieren</strong></h3> <p>Nimmt man als Beispiel ein einfaches Fenster (ein sehr beliebtes Beispiel). Es erscheint während einer Projektierung in unterschiedlichen Formen an unterschiedlichen Stellen: <ul> <li>in Grundriß-, Schnitt und Ansichtsplänen,</li> <li>in Massenermittlungen, Ausschreibungen und Kostenvoranschlägen,</li> <li>in der Statik und im Wärmeschutznachweis,</li> <li>in Baubeschreibungen und Vertragsdokumenten, ...</li> <li>in Präsentationen</li> <li>(und im Kopf des Bauherren  was aber sowieso ein Problem ist, und sich nie ändern wird).</li> </ul> <p>Was nun aber, wenn das Fenster geändert werden muß? Der Architekt ist für die Koordinierung der Änderungen verantwortlich - ein schwieriges Unterfangen, da heutzutage der gleiche Vorgang bzw. Gegenstand in verschiedenen Dokumenten vertreten ist, die physikalisch an unterschiedlichen Orten aufbewahrt werden und sich unter der Kontrolle unterschiedlicher Personen befinden.<br> Eine weitere Herausforderung ist für den Architekten mit der Bereitstellung von Gebäudedaten in elektronischer Form für die Nutzung durch den Bauherren bzw. seinen Vertreter (Gebäudeverwaltung) gegeben. Informationen und Inhalte, wie sie für die Gebäudeverwaltung benötigt werden, differieren naturgemäß von dem, was im Designprozeß zur Anwendung kommt. Sehr häufig müssen Gebäudedaten auch in ein bestehendes Verwaltungssystem integriert werden. Und als ob all dieses nicht ausreichend wäre, hat jeder Bauherr unterschiedliche Anforderungen und jedes Bauwerk einen unvergleichbaren Verwendungszweck. Gegenwärtig sind diese Prozesse des Datenaustausches nicht automatisierbar und erfordern viel Handarbeit, sie verursachen zum Teil erhebliche zusätzliche Kosten und bergen viele Gefahren z.B. in Form von Übertragungsfehlern oder Datenverlusten.</p> <p align="left">Informationen und Know-How besser managen sowie Planung und Projekte effizienter organisieren - diesen Ansprüchen hat sich die IAI - die <strong>Internationale </strong>(ehemals: Industrie)<strong> Allianz für Interoperabilität</strong> angenommen.</p> <h3 align="left"><strong><img src="../../links/i/iai.gif" align="left" hspace="4" vspace="4" WIDTH="86" HEIGHT="86"></strong><a name="3" target="_self"></a><strong>Wer ist die IAI? <br> Wer die Internationale ALLIANCE für INTEROPERABILITY?</strong></h3> <p>Die IAI ist ein gemeinnütziges Bündnis im Bauwesen, das 1995 in den USA gegründet wurde. Laut eigenen Angaben (siehe <a href="http://iaiweb.lbl.gov" target="_blank">http://iaiweb.lbl.gov</a>) berücksichtigt die IAI Architekten, Ingenieure, Vertragsunternehmer, Bauherren sowie Facility-Manager (Gebäudeverwalter), Bauunternehmen, Softwareentwickler, Dienstleister, öffentliche Stellen, Forschung-Labors und Universitäten. Es gibt nationale Gruppen (sogenannte "Chapters") in Nordamerika, Deutschland, England, Frankreich, Singapur, den nordeuropäischen Ländern und Japan.</p> <p>Über 600 Unternehmen arbeiten international in der IAI mit. Auch zahlreiche deutsche (Bau-)Softwarehersteller (z.B. Autodesk, IEZ, Nemetschek, RoCAD, Microsoft) sowie Anwender (Dresdner Bank, Planungsgruppe Obermayer, Phillip Holzmann) sind (oder waren) lAI-Mitglieder. Eine aktuelle Mitgliederliste kann im Internet (noch einmal: <a href="http://iaiweb.lbl.gov" target="_blank">http://iaiweb.lbl.gov</a>) eingesehen werden. (Das deutschsprachiges IAI-Chapter mit einer ebenfalls aufschlußreichen Mitgliederliste findet man im übrigen unter <a href="http://www.opb.de/iai/" target="_blank">http://www.opb.de/iai/</a>). Die Organisationsform der IAI ist in allen Ländern identisch: <ul> <li>An der Spitze steht ein <strong>Vorstand</strong>, zuständig für administrative Aufgaben. </li> <li>Für die Abstimmung und Zusammenfassung der erarbeiteten Basisdatenmodelle sowie für die Organisation der Zusammenarbeit auf internationaler Ebene ist das <strong>Integrationskomitee</strong> verantwortlich. </li> <li>Die Definition der Basisdatenmodelle erfolgt in <strong>Fachgruppen</strong> (in Deutschland für die Bereiche Architektur, Konstruktion, Gebäudetechnik, Kosten, Facility Management und Verkehr).</li> <li><strong>Arbeitskreise</strong> stellen ferner die Verbindung zu Hochschulen und zur Forschung sowie die Implementierung in die Anwendungsprogramme sicher.</li> </ul> <h3 align="left"><img src="../../links/i/iai.gif" align="left" hspace="4" vspace="4" WIDTH="86" HEIGHT="86"><img src="dta-st2a.gif" align="right" hspace="4" vspace="4" WIDTH="300" HEIGHT="283"><strong><a name="4" target="_self">Was</a> macht die IAI?</strong></h3> <p>Die IAI verfolgt das Ziel, die vielen Teilaspekte der <a target="_new" href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_a.htm#aec">AEC</a>/<a target="_new" href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_f.htm#fm">FM</a>-Industrie zu integrieren / in einem Datenmodell zusammenzuführen (die IAI selber betont diese Kombination "AEC/FM"), indem sie eine gemeinsame, universelle Sprache definiert hat und die Definition ständig weiterentwickelt  man spricht von "Industrie-Foundation-Classes (IFC)". Diese Definition erfaßt <ul> <li>alle dem Architekten bekannten Leistungsphasen (Entwurf, Planung, Konstruktion, Vergabe, ...), </li> <li>bezieht den Erstellung des Gebäudes mit ein und</li> <li>berücksichtigt seinen Lebens-Zyklus und das Gebäude-Management </li> <li>bis hin zum Abriß.</li> </ul> <p>Das IFC-Datenmodell baut auf bestehenden Entwicklungen auf, Baudaten zwischen verschieden Programmen auszutauschen. So entsprechen die IFC-Basisdaten weitgehend dem STEP-Standard (Standard for the Exchange of Product Model Data - siehe auch <a href="http://www.steptools.com" target="_new">http://www.steptools.com/</a> und. <a href="http://www.scra.org/uspro//stds/stepage.html" target="_new">http://www.scra.org/uspro//stds/stepage.html</a>). STEP ist ursprünglich ein von der Fahrzeugindustrie motivierter und genormter Standard zum Austausch produktdefinierender Daten, die neben den Geometriedaten eines Bauteils, topologische und technologische Informationen zur vollständigen Produktbeschreibung enthalten. <br>   </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> </td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%">Zu den Motivationsgründen der IAI, IFC zu entwickeln, zählen Erkenntnisse wie:<ul> <li>Bauherren erwarten mehr <strong>Flexibilität und Qualität</strong> in ihren Gebäudeentwürfen, damit sie dem wachsenden Druck in ihrem eigenen Geschäft besser gewachsen sind. </li> <li>Die <strong>Entwicklungs- und Herstellungsprozesse</strong> nahezu aller Produkte reduzierten sich von mehreren Jahren auf einige Monate. Die baulichen Einrichtungen, ihre Errichtung und ihre Anpassungsmöglichkeiten müssen damit Schritt halten.</li> <li>Geschätzt bis zu 30% der <strong>Gebäudekosten</strong> werden durch die gegenwärtigen Abläufe im Bauwesen nutzlos verbraten. Bauherren verlangen Gebäude / Facilities, die billiger zu errichten, zu erhalten und zu betreiben sind.</li> <li><strong>Know-How</strong>, das sich im Planungsprozeß, bei der Ausschreibung, während der Bauausführung und danach ansammelt, sollte beim Weg durch die Instanzen nicht verpuffen sondern gesammelt werden:</li> </ul> <p align="center"><img src="dta-st3.jpg" WIDTH="450" HEIGHT="250"></p> <ul> <li>Gebäude enthalten Erzeugnisse, die irgendwo auf dem Globus hergestellt werden. Auch der AEC/FM-Prozeß wird immer globaler  worauf man sich einstellen muß.</li> </ul> <p>Ob nun global verteilt große Geschäftshäuser geplant werden oder im Umkreis von 20 Kilometern alle Beteiligten für den Neubau eines Einfamilienhauses zu finden sind  die Anforderung an die Planung und Realisation einer architektonischen Aufgabe sind gestiegen. Verbessert werden müssen<ul> <li>die Kommunikation, </li> <li>die Produktivität, </li> <li>die Zeitplanung und deren Einhaltung,</li> <li>das Kosten- und Qualitäts-Niveau.</li> </ul> <p>Die IAI will dazu beitragen, "die kollektive Macht der Industrie auszunutzen, um einen Kommunikations-Standard zu setzen, der zukünftig die Zusammenarbeit und die globale Expansion im Bauwesen fördert."<br>   </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="center" width="142" bgcolor="#DEDEDE" valign="top"><p align="center"><img src="../../i/m-leer.gif" width="140" height="20"><br> </td> <td width="8" background="../../i/trennlin.jpg">  </td> <td valign="top" width="98%"><h3><a name="5" target="_self">Was</a> bedeutet "Interoperabilität"?</h3> <p>"Interoperabilität" ist ein Kunstwort, das die Fähigkeit beschreibt, Daten untereinander austauschen zu können. Interoperabilität ermöglicht allen Projektbeteiligten die interdisziplinäre Nutzung von Daten aus einem großen, flexiblen Informationspool über alle "Lebensphasen" eines Bauwerkes - also von der Planung über die Erstellung bis hin zur Nutzung. </p> <p>Technisch gesehen wird die Form wichtiger, im Kernmodell enthaltener Objekte wie Wände, Fenster oder Türen mit Hilfe "impliziter Geometrie" (über Parameter erzeugte Geometrie) beschrieben. Damit werden Mehrdeutigkeiten oder Fehlinterpretationen vermieden, wie sie bei Verwendung "expliziter Geometrie" (über Polygone definierte Geometrie) auftreten können. Da sich aber nicht alle Objekte über Parameter eindeutig beschreiben lassen, ist ein Rückgriff auf "explizite Geometrie" vorgesehen: in diesen Fällen wird auf bestehende ISO-Normen bzw. STEP-Standards zurückgegriffen.</p> <p>Alle projekt- und gebäudebeschreibenden Inhalte werden in einem Datenmodell beschrieben - das gilt für organisatorische Dinge (Adresse des Bauherren), für das geometrische Modell wie zum Beispiel auch für die Oberflächenbeschreibung eines einzelnen Bauteils. Kann ein an sich IFC-kompatibles Programm mit einzelnen Informationen im Datenbestand nichts anfangen, weil beispielsweise k-Werte für ein Statikprogramm keine Relevanz haben, dann muß das jeweilige Programm aber trotzdem diese Informationen verwahren und sie beim Speichern der eigenen Daten wieder berücksichtigen. Einmal eingegebene Daten dürfen nicht unter den Tisch fallen!</p> <p>Daten zwischen unterschiedlichen Plattformen werden über ASCII-Dateien (*.IFC) ausgetauscht. In Zukunft sollen Objekte aber mit Hilfe einheitlicher Standards zur Beschreibung von "shared objects" direkt transferiert werden. Ob dabei der UNIX-Standard CORBA (Common Object Request Broker) oder doch eher der Windows-Standard COM / <a href="http://www.archmatic.com/phpclick/gouralt.php4?http://www.glossar.de/glossar/amglos_o.htm#ole" target="_self">OLE</a> verwendet wird, ist zur Zeit noch offen. Der Trend geht aufgrund der Verbreitung von Windows allerdings deutlich in Richtung COM / OLE. Innerhalb der AutoCAD-Welt erfolgt der Datenaustausch weiterhin mit Hilfe von DWG-Dateien, welche die gesamte IFC-Datenstruktur beinhalten. </p> <h3><strong><a name="6" target="_self">vorübergehend</a> abschließend ...</strong></h3> <p>Die Vorteile der IAI-Strategie liegen auf der Hand. Der gemeinsame Daten-Zugriff aller Anwendungen erspart die mehrfache Dateneingabe. Es kann sichergestellt werden, daß alle Planungsbeteiligten Zugriff auf alle Projektinformationen haben. IFC vermeidet Informationsverluste und Fehler durch unzureichend funktionierende Datentransferprogramme. Vom Aufbau eines großen Daten- und Know-how-Pools profitieren alle am Bau beteiligten Parteien, der Bauherr bzw. sein Verwalter und letztendlich auch die Abrißfirma. Derzeit noch manuell ausgeführte Prozesse können automatisiert werden (Stichworte: "dynamische Updates", "Kostenkalkulation", "automatische Steuerung von Gebäudekontrollsystemen").</p> <p>Bei aller Euphorie sollte aber nicht vergessen werden,<ul> <li>daß der Einsatz eines IFC-basierenden Datenmodells nur Sinn macht, wenn durchgehend bauteil- bzw. objektorientiert gearbeitet wird (siehe noch einmal <a href="f-aec1.htm" target="_self">(R)EVOLUTION im Architekturbüro</a>).</li> </ul> <center><table border="0" cellspacing="4"> <tr> <td align="right" valign="top" class="normalabst"><strong><u>klassisches CAD:</u></strong><br> Bauteile bestehen<br> aus vielen einzelnen<br> Elementen</td> <td align="center" valign="top" class="normalabst"><img src="obj-o1.gif" align="top" vspace="3" WIDTH="300" HEIGHT="213"></td> </tr> <tr> <td align="right" valign="top" class="normalabst"><u><strong>objektorientiertes CAD:</strong></u><br> Bauteile bestehen aus jeweils<br> einem Element und<br> angeschlossene Objekte<br> (z.B. Wände) können<br> auf sie reagieren</td> <td align="center" valign="top" class="normalabst"><img src="o-ani.gif" align="top" vspace="3" WIDTH="300" HEIGHT="213"></td> </tr> </table> </center><ul> <li>Zur Zeit ist die Technik noch nicht so weit, daß alle Planungsbeteiligten ständig IN einem IFC-Datentopf arbeiten können. Stattdessen holen sie sich AUS dem gemeinsamen Datentopf den aktuellen Datenbestand, konvertieren ihn (oder auch nicht), machen ihre Bearbeitungen LOKAL und legen dann 2 Stunden oder 2 Wochen später den geänderten Datenbestand in dem gemeinsamen IFC-Datentopf wieder ab. Was passiert aber, wenn zwischenzeitlich andere Partner ihre Änderungen oder Ergänzungen viel schneller vorgenommen haben? Wessen Eingaben fallen dann unter den Tisch? Eine Art von Datenfluß-Organisation ist weiterhin von Nöten (siehe redundante Daten / Redundanz)<br> Solange die IFC-Schnittstelle nur als verbesserter, DXF-ähnlicher Datenaustausch-Mechanismus agiert, der immer nur den gesamten Datenpool berücksichtigt und nicht einzelne Inhalte abgleichen kann, ist nur der halbe Weg bis zur optimalen Datenhaltung beschritten. Ziel muß es sein, daß überhaupt nicht mehr mit eigenen, lokalen Datenbeständen gearbeitet wird, sondern alle direkt auf einen Topf zugreifen.</li> <li>Anfang 2000 bietet einige Firmen wie Autodesk oder Nemetschek ein IFC Import/Export-Dienstprogramm an, das ggfls. kostenlos von der jeweiligen Website heruntergeladen werden kann und das meistens die aktuellen IFC 1.5.1-Spezifikationen unterstützt.<br>   </li> </ul> </td> </tr> </table> <table border="0" cellspacing="0" width="100%"> <tr> <td align="right" bgcolor="#000000"><font color="#AFD8B0"><strong>  </strong></font></td> </tr> <tr> <td align="right"><p class="kringelliste"><font color="#000000"><strong>© Alfons Oebbeke, Neustadt 1997 - 2001<br>   <br> </strong></font><a href="#Seitenanfang" target="_self"><img src="../../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> zurück zum Seitenanfang<br> <a target="_top" href="../index.htm"><img src="../../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a> zur Magazin-Übersicht<br> <a target="_top" href="http://www.aecweb.de"><img src="../../i/m-spiral.gif" border="0" WIDTH="16" HEIGHT="17"></a>oder Titelseite ("home")</td> </tr> </table> </body>