Grundbegriffe aus der IFC-Terminologie

Nachfolgend finden Sie die wichtigsten Grundbegriffe aus der IFC-Terminologie erläutert.

IAI

Die Internationale Allianz für Interoperabilität ist eine 1994 von führenden Software-Herstellern ins Leben gerufene Initiative mit dem Ziel, ein offenes und plattformunabhängiges Datenmodell zu schaffen, mit dem sich der Lebenszyklus eines Gebäudes nachbilden lässt. Durch die Definition bestimmter Standards und Vorgaben für die Datenstruktur soll dabei die Anbindung einer größtmöglichen Anzahl von Applikationen erreicht werden.

Die ursprünglich unter dem Namen Industry Alliance for Interoperability gegründete Initiative verstand sich von Anfang an als ein für jedermann offenes Konsortium und wurde 1997 in International Alliance for Interoperability umbenannt. Eine erneute Namensänderung gab es 2005; seither firmiert der Zusammenschluss unter der Bezeichnung buildingSMART.

buildingSMART

Das aus der IAI hervorgegangene Konsortium teilt sich heute unter dem Dach der buildingSMART International in einzelnen Länderorganisationen auf und wird in Deutschland durch den Verein buildingSMART e.V. vertreten.

Mit derselben Zielsetzung, den Planungs-, Ausführungs- und Bewirtschaftungsprozess von Gebäuden digital möglichst komplett zu erfassen und allen Beteiligten zur Verfügung zu stellen, entwickelt und definiert buildingSMART Standards und Vorgaben, wie diesbezügliche Gebäudemodelle erstellt und strukturiert werden können. In der Initiative sind, sowohl in Deutschland als auch international, die führenden Software-Hersteller aus dem Bausektor, aber auch Forschungs- und Bildungseinrichtungen vertreten.

Die ALLPLAN GmbH hat sich von Anfang an als Pionier in der Initiative engagiert und setzt einen starken Fokus auf Verbesserung und Weiterentwicklung der offenen Programmschnittstellen und Formate.

IFC-Version

Analog zu den überwiegend versionsbezogenen Datenformaten einer Software gibt es auch in IFC "alte" und "neue" Formate. Je nach Aufbau, Aktualität und Inhalt unterscheidet IFC die Formate IFC2x2, IFC2x3, IFC4 sowie IfcXML.

Das offizielle und momentan aktuelle Format ist IFC4. Dennoch wird nach wie vor IFC2x3 eingesetzt, vor allem wenn ältere Softwareprodukte verwendet werden, die (noch) keine IFC4 Schnittstelle besitzen. In ALLPLAN sind sowohl Export als auch Import im Format IFC4 möglich.

IfcXML dagegen liefert keine Modelldaten als solche, sondern diese werden rein textlich beschrieben. Die Datei kann mit jedem gängigen XML-Editor gelesen werden. Das Format kommt daher hauptsächlich dann zum Einsatz, wenn eines der beteiligten Programme nicht über eine "klassische" IFC-Schnittstelle verfügt. Aufgrund der ausführlichen Beschreibung ist die IfcXML-Datei wesentlich größer als eine reine IFC-Datei.

IFC Class und IFC Entity

Alle Standardobjekte aus Architektur, Haustechnik, Statik, Facility Management und anderen Fachdisziplinen sind in IFC als "Entitäten" definiert, die sich zu einzelnen Klassen zusammenfassen lassen. Jede Entität entspricht einem speziellen IFC-Bibliothekselement, dem beim Datenaustausch ein entsprechend benanntes Objekt zugeordnet wird.

Mit jeder IFC-Version wird diese Bibliothek um neue Entitäten erweitert, um den Umfang und damit den potentiellen Anwendungsbereich von BIM/IFC beständig auszubauen. Damit ein Objekt dem richtigen Bibliothekseintrag zugeordnet werden kann, muss es neben der korrekten Bezeichnung zusätzlich bestimmte Eigenschaften aufweisen, die per Definition zwingend erforderlich sind. Beim Verwenden der zugehörigen Werkzeuge, etwa Stütze oder Raum, werden dem erzeugten (CAD-)Objekt automatisch die hierfür passende Entität und die richtige Klassifizierung zugewiesen, sofern diese in IFC existiert. Als solches wird es dann in das IFC-Modell übertragen.

Über das Attribut IFC Entity lässt sich die Klassifizierung beeinflussen und nachträglich verändern, wenn z. B. ein Architekturelement nicht als das Bauteil übertragen werden soll, mit dessen Werkzeug es erzeugt wurde. Zudem können frei modellierte 3D- und Mengenkörper mit einer IFC Entität versehen werden, um sie als vordefiniertes Bibliothekselement mit einer bestimmten Funktion und Bedeutung zu übertragen.

IFC PredefinedType

Um die bereits durch die Zuweisung der passenden Entität festgelegte Bedeutung und Zweckbestimmung noch genauer zu definieren, lässt sich den Modellkomponenten über das Attribut IFC PredefinedType zusätzlich ein sogenannter "PredefinedTyp" zuweisen. Dieser stellt eine Art Unterklassifizierung dar und bezieht sich immer auf die Entität, ist also von dieser abhängig. Hierbei handelt es sich um eine Liste, die je nach Entität unterschiedlich umfangreich sein kann. Zudem existieren nicht für alle Entitäten auch PredefinedTypen, sondern in erster Linie für solche, die in ihrer Bedeutung eher allgemein gehalten sind.

So lassen sich etwa Fundamente, für die es in IFC nur das Bibliothekselement IfcFooting gibt, über den zugehörigen PredefinedTyp noch einmal in Einzelfundament (Pad_Footing), Hohlkastengründung (Caisson_foundation), Streifenfundament (Strip_footing) usw. unterscheiden.

Der PredefinedTyp kann je nach verwendeter Software und Funktion entweder automatisch zugewiesen oder aber nachträglich ergänzt werden. Im Gegensatz zur Entität ist er allerdings für die korrekte Übertragung per IFC nicht zwingend erforderlich. Daher enthalten die Listen auch immer den Eintrag "undefiniert", wenn keine genauere Unterscheidung getroffen werden kann oder soll.

Base Quantities

Jedes Zeichnungselement, egal ob 2D oder 3D, wird durch seine Geometrie definiert. Dazu zählen die Abmessungen sowie die räumliche Lage im Koordinatensystem, die es in Beziehung zum Gesamtmodell setzt. Die Abmessungen werden beim Erzeugen durch Anklicken entsprechender Punkte und/oder elementspezifisch im jeweiligen Eigenschaftendialog eingegeben, die Lage durch das Platzieren im Zeichenbereich.

Im Gegensatz zu den "normalen" (alphanumerischen) Attributen handelt es sich bei den Geometriedaten nicht um feste, sondern um dynamische Werte. Sie werden bei jedem Aufrufen des Elements neu berechnet, so dass sich Formänderungen sofort ablesen lassen und eine Wertänderung unmittelbar Auswirkungen auf die Geometrie hat.

Diese für die Identifikation zwingend notwendigen Angaben, etwa Höhe, Länge und Dicke bei einer Wand, ergeben sich in erster Linie intern aus der geometrischen Beschreibung, die die visuelle Darstellung erzeugt. Sollen sie zusätzlich als feste, vorab berechnete Werte in der IFC-Datei enthalten sein, kann über eine entsprechende Exportoption die Übertragung in das Paket Base Quantities (Basisgeometrie) aktiviert werden.

In diesem Fall liegen für jedes Objekt im Hinblick auf Geometrie und räumliche Lage seine wesentlichen Kenngrößen in zweifacher Form vor: als "dynamische" Angaben, die bei jedem Aufruf berechnet werden, und als feste, "alphanumerische" Zahlenwerte. Gerade AVA Programme benötigen häufig diese festen Angaben, da sie dynamische Werte nicht verarbeiten können.

Property Set (kurz: PSet)

Jedem Element lassen sich zu seiner genaueren Beschreibung und zur Erhöhung des Informationsgehaltes über die Base Quantities hinaus beliebige Attribute und Eigenschaften zuweisen. Sie werden je nach Inhalt und Zweckbestimmung gruppiert und zu sogenannten Property Sets (PSets) zusammengefasst.

Dabei gibt es für jedes Element, das sich per IFC übertragen lässt, ein eigenes allgemeines Eigenschaftenpaket (PSet_WallCommon, PSet_DoorCommon usw.), das alle diejenigen Angaben enthält, die zusätzlich zur Benennung im Minimum für eine eindeutige Identifizierung notwendig sind. Es kann je nach Objekt unterschiedlich umfangreich sein.

Einzelne Bauteile, vor allem die Ausbauelemente Türen, Fenster, Räume usw. besitzen darüber hinaus weitere vordefinierte Attributgruppen, etwa für die Glaseigenschaften oder spezifische Herstellerinformationen. Zudem sind mittlerweile im Hinblick auf Nachhaltigkeitsaspekte eigene Pakete für den "ökologischen Fußabdruck" eines Bauteils (PSet_EnvironmentalImpact…) hinzugekommen.

IFC Subset

Beim Austausch von Daten als Bauwerksmodell über das IFC-Format ist es sinnvoll, nicht alle darin enthaltenen Informationen zu übergeben. Je nachdem, welche Fachrichtungen beteiligt sind und in welcher Phase des Gesamtprozesses der Austausch erfolgt, wird nur selten ein Komplettpaket benötigt, und die Anschlussprogramme können für sie irrelevante Informationen in der Regel auch gar nicht auswerten.

Daher lassen sich aus dem Gesamtpaket für die Übertragung einzelne Untergruppen, sogenannte Subsets, ausgliedern. In diesen sind für spezifische Anwendungsfälle reduzierte und gefilterte Informationen enthalten, um den Austausch zu optimieren. Zum einen verringert sich dadurch die Datenmenge, zum anderen erhöht sich die Verarbeitungsgeschwindigkeit innerhalb der Anschlussprogramme.

Mit jedem Subset wird das Modell und seine Komponenten unter einem bestimmten Blickwinkel betrachtet und dementsprechend dargestellt. Momentan existieren innerhalb des Gesamtformats IFC je nach verwendeter Version (IFC2x3 bzw. IFC4) unterschiedliche Untermengen, die abhängig von der Art des Datenaustauschs und der Information zur Anwendung kommen.

Die gängigsten hierbei sind:

• IfcCoordinationView
• IfcReferenceView
• IfcDesignTransferView
• IfcStructuralAnalysisView
• IfcFMHandOverView

Zudem stehen die Subsets nicht nur teilweise mit einer bestimmten IFC-Version in Verbindung, sondern haben in gleicher Weise wie das "Mutterformat" IFC ebenfalls Versionsbezeichnungen, da sie parallel mit diesem weiterentwickelt und angepasst werden.

MVD

Parallel zu dem Begriff IfcSubset existiert die Abkürzung MVD (für ModelViewDefinition). Ein View ist dabei identisch mit einem Subset und steht für eine bestimmte Auswahl bzw. einen begrenzten Objekt- und Datensatz aus dem Gesamtmodell. Es wird damit definiert, was übergeben werden soll.

So sieht beispielsweise der Statiker eine Stütze anders als der Architekt: Aus Sicht des Statikers handelt es sich bei einer Stütze um ein senkrechtes Objekt zur Abtragung von Vertikallasten mit spezifischen Auflagerungen am Kopf- und Fußende. Für den Architekten dagegen ist es ein Bauteil mit einem bestimmten Material und einer Oberfläche, das sich plastisch gestalten und räumlich anordnen lässt. Daher wird in der jeweiligen ViewDefinition neben dem enthaltenen Objektsatz auch bestimmt, in welcher Form und mit welchen Informationen die Objekte dargestellt werden sollen, also wie etwas übergeben werden soll.