Im Mai 2018 fand das letzte OKSTRA-Symposium bei der Bundesanstalt für Straßenwesen statt. Inzwischen sind 4 Jahre vergangen und es gab in dieser Zeit vielfältige Weiterentwicklungen, sowohl des OKSTRA® als auch des Datenschemas IFC. Der Bericht beantwortet die Fragen, was sich in den zurückliegenden 4 Jahren beim OKSTRA® und IFC getan hat und wie die Nutzbarkeit beider Datenformate bei Infrastrukturprojekten aus heutiger Sicht einzuschätzen ist. Thematisch werden damit die Entwicklungen beim OKSTRA® (bis Version 2.020) und die Erweiterung des IFC-Datenschemas für die Infrastruktur (Version IFC4.3) dargelegt, Schlussfolgerungen für Entwicklung und Anwendung beider Datenformate gezogen sowie auf offene Fragenstellungen hingewiesen.

Der Fachvortrag zur Veranstaltung ist im Volltext verfügbar. Das PDF enthält alle Bilder und Formeln.

1 Einleitung

Beim letzten OKSTRA-Symposium 2018 beschäftigte sich ein Vortrag mit einem Vergleich zwischen Objektkatalog Straßenwesen (OKSTRA®) und Industry Foundation Classes (IFC) als BIM-konforme Datenformat, das für die Infrastruktur erweitert wird. Die Ergebnisse dieses Vortrages können verkürzt damit zusammengefasst werden, dass OKSTRA® ein sehr detailliert definiertes Datenformat für den Straßenbau ist und in Deutschland flächendeckend angewendet wird. Im Gegensatz dazu handelt es sich beim IFC um ein Datenschema, welches seinen Ursprung im Hochbau hat, und einen Hersteller- und Produktunabhängigen Datenaustausch im Bauwesen ermöglichen soll. Die Weiterentwicklung des IFC-Datenschemas stand damals noch am Anfang, so dass erwartungsgemäß eine praktische Anwendung des IFC-Datenformates für Infrastrukturprojekte in Deutschland nicht empfohlen werden konnte.

Hauptergebnis des Vergleiches zwischen OKSTRA® und IFC im Rahmen des OKSTRA-Symposiums 2018 war, dass es zwischen beiden Datenformaten erhebliche Unterschiede gibt und diese bestimmen, welches Datenformat für welchen Anwendungsfall am besten geeignet ist. Als Handlungsempfehlungen aus dem Vergleich zwischen OKSTRA® und IFC für die Weiterentwicklung des OKSTRA wurden von (Frei, 2018) die folgenden Schwerpunkte herausgearbeitet:

• Integration von BIM-Anforderungen in den OKSTRA®(Volumenkörper, generische Objekte, Objektattribuierung),
• Erhöhung der Akzeptanz des OKSTRA® durch Schaffung einer Zertifizierung,
• Ausbau des parametrisierten Modells, B. des Deckenbuches,
• Übernahme möglichst großer Teilmengen der OKSTRA®-Objektdefinition in die neu zu schaffenden IFC-Infrastrukturobjekte!

Frei (2018) schlussfolgert, dass mit einer konsequenten Weiterentwicklung des OKSTRA® nach diesen Vorschlägen erreicht wird, dass es nicht um die Frage OKSTRA® oder IFC geht, sondern dass sich beide Datenformate/-schemen ergänzen, frei nach dem Motto OKSTRA® und IFC. Zur Beantwortung der Frage, ob diese Empfehlungen zur Weiterentwicklung des OKSTRA® in den letzten 4 Jahren erfolgreich umgesetzt werden konnten, ist es notwendig zu analysieren, welche Entwicklungsschritte in den letzten Jahren im OKSTRA® und dem IFC unternommen wurden. Haben sich die beiden Datenformate einander angenähert oder gibt es Unterschiede, die sich gegebenenfalls auch mit mittel- oder langfristiger Perspektive nicht oder nur sehr schwer beheben lassen?

2 Entwicklungen im Objektkatalog Straßenwesen (OKSTRA®)

Der Objektkatalog für das Straßen- und Verkehrswesen OKSTRA® ist eine Sammlung von Objekten aus dem Bereich des Straßen- und Verkehrswesens mit dem Ziel ein gemeinsames und einheitliches Verständnis dieser Objekte aus den betroffenen Fachbereichen zu erreichen. Die konsequente Anwendung des OKSTRA® führt zu einem standardisierten Austauschformat zwischen den unterschiedlichen Projektbeteiligten sowie auch zwischen den unterschiedlichen Softwareapplikationen aus dem Straßen- und Verkehrswesen. Einschränkend ist darauf hinzuweisen, dass der OKSTRA® als Datenaustauschformat zu verstehen ist, welches den Status eines Projektes zu einem bestimmten Zeitpunkt/Meilenstein darstellt. In diesem Sinne ist dies als Analogie zum gebräuchlichen PDF-Format für Textdokumente zu verstehen. Damit besteht gleichfalls eine Parallele zum IFC-Datenschema, zumindest so lange der Anwendungsfall „Design to Design“ nicht umgesetzt werden kann. Der Objektkatalog für das Straßen- und Verkehrswesen wurde durch das allgemeine Rundschreiben Straßenbau 12/2000 des Bundesverkehrsministeriums für den Bereich der Bundesfernstraßen offiziell eingeführt. Dieses Rundschreiben wurde später durch das allgemeine Rundschreiben Straßenbau 24/2010 ersetzt.

Der im Oktober 2021 erschienene Masterplan BIM Bundesfernstraßen (BMVI, 2021) listet neben dem Datenschema IFC auch den Objektkatalog Straßenwesen (OKSTRA®) als BIM-konformes Datenformat auf. OKSTRA® verfügt für den Straßenentwurf/Straßenbau über eine sehr große Detailtiefe. Dies zeigt sich auch bei der Weiterentwicklung des OKSTRA®-Klassenbibliothek (OKLABI) in den Jahren 2018 bis 2020.

2.1 Objektklassenbibliotheken

Eine Vielzahl von OKSTRA®-Schemen und Objektarten wurden in den letzten 4 Jahren neu entwickelt. Gleichfalls wurden viele neue Attribute schon existierenden Objektarten zugeordnet. Beispiele sind z. B. Anpassung an die ASB 2.04 (Anweisung Straßeninformationsbank) und die neue ASB-ING (Segment Bauwerksdaten) sowie die Aufnahme der REB-VB 21.000 und REB-VB 22.000 im Bereich der Mengenberechnung/Bauabrechnung. Die Weiterentwicklung des OKSTRA® berücksichtigte auch die BIM-Methodik. Ziel ist es, eine zu IFC vergleichbare Möglichkeit für die Abbildung generischer volumenbasierter 3D Geometrieobjekte mit zugeordneten semantischen Informationen zu schaffen. Diese können als Grundlage eines OKSTRA®-basierten Modellaustausches von 3D-Straßenplanungsmodellen dienen. Die OKSTRA®/IFC-Expertenworkshops im Rahmen des Projektes BIM4Infra2020 lieferten dazu Empfehlungen zur OKSTRA®-Schemaerweiterungen, die inzwischen auch teilweise umgesetzt wurden. In den Tabellen 1-3 sind die Weiterentwicklungen der OKLABI-Versionen 2018 bis 2020 aufgelistet.

OKLABI 2018:

Tabelle 1: Änderungsanträge OKLABI 2018 (Quelle: www.okstra.de/Änderungsanträge)

Zusammenfassend lässt sich feststellen, dass insgesamt 8 Änderungsanträge in den OKLABI 2018 aufgenommen wurden. Diese umfassen die Fachbereiche Betrieb, Grunderwerb, Vermessung, Arbeitsstellen-Management, Prüfdaten, Kostenmanagement und Intelligente Verkehrssysteme. Bei allen Änderungsanträgen lässt sich ein direkter oder mindestens indirekter Bezug zur BIM-Methodik erkennen. Dabei handelt es sich mehrheitlich um semantische Informationen, die definierten Fachobjekten/Fachbedeutungen zugewiesen werden.

OKLABI 2019

Tabelle 2: Änderungsanträge OKLABI 2019 (Quelle: www.okstra.de/Änderungsanträge)

Im OKLABI 2019 wurden 5 Anpassungen in den Fachgebieten Betrieb, Liegenschaftsverwaltung/Asset Management, der Modellierung von Ingenieurbauwerken nach ASB-ING, der Prüfdaten von Straßen infolge von Regelwerkserweiterungen sowie dem Kostenmanagement nach AKVS 2014 vorgenommen. Es wird deutlich, welche große Modelltiefe und Detaillierung der zugehörigen semantischen Informationen notwendig ist, um Straßenverkehrsanlagen in allen Leistungsphasen nach den geltenden technischen Regeln in Deutschland zu modellieren. Das international ausgerichtete IFC-Datenschema für Infrastruktur kann nur viel allgemeiner als Basis oder Fundament (für Klassen/Objekte und Merkmale/Attribute) dienen, welches durch regionale Regeln ergänzt wird. Hier kann der OKSTRA® eine wertvolle Grundlage sein.

OKLABI 2020

Im OKLABI 2020 wurden 7 Änderungsanträge aus den Bereichen Kostenmanagement. Mengenberechnung (REB21.000 und REB22.000), Volumengeometrie-Attribute, Prüfdaten von Straßen und die Anpassung des OKSTRA an die ASB 2.04 vorgenommen. Nachfolgend werden wegen dem direkten Bezug zur BIM-Methodik 3 Änderungsanträge detaillierter beschrieben. Die verbleibenden 4 Änderungsanträge werden in Tabelle 3 zusammengefasst.

• Änderungsantrag A0139: Einführung von Volumengeometrie-Attributen: Die Anwendung der BIM-Methodik erfordert die Erstellung und Nutzung von 3D-Objekten und Modellen. Diese sind nicht nur in der Planungs- und Bauphase zu nutzen, sondern werden in allen Phasen des Lebenszyklus angewendet. Gerade bei der Erstellung von Bestandsdokumentationen und Bestandsmodellen, kommen diese zum Einsatz. Der Änderungsantrag verfolgt deshalb das Ziel, geeigneten OKSTRA®-Objektarten ein zusätzliches optionales Volumengeometrie-Objekt hinzuzufügen, um die Objekte für die Anwendung in der BIM-Methodik nutzbar zu Dies erfordert eine generische Grundstruktur, die derzeit im OKSTRA® nicht vorhanden ist. Daher fehlt es auch an Objekt-/Eigenschafts-Vorlagen, die projektbezogene Vorgaben in einer generischen Struktur erlauben. Im Änderungsantrag A0139 wurde die folgenden Aufgaben definiert:

1. Nutzung der in früheren OKSTRA®-Versionen verfügbaren 3D-Volumengeometriebeschreibungsmöglichkeiten auf Grundlage von GML. Konkret bedeutet dies die Ergänzung von Volumengeometrie-Attributen an der Objektart Aufbauschicht, zu der bis zu den OKSTRA-Versionen 1.015/2.015 bereits die Volumengeometrie angegeben werden konnte. Als weitere Objektarten sind Sensor, Aufstellvorrichtung_Schild, Leitung, Gebäude, Geschoss, Mauerabschnitt, Öffnung und Zaun vorzusehen.
2. Integration einer zu IFC vergleichbaren Möglichkeit zur Abbildung generischer Objekte und deren zugehörigen (erweiterbaren) Eigenschaften (vgl. IfcBuildingElementProxy und IfcPropertySet). Dies bedingt die Einführung eines neuen Teilmodells zur Abbildung einer generischen Objektstruktur. Damit könnten auch freie Objekte, die nicht im OKSTRA Katalog vorgegeben sind, übertragen werden. Neben der BIM-Thematik könnte dies auch für die Berücksichtigung der neuen RAS-Verm-Objekte genutzt wer
3. Übertragung von Objekten und Objekteigenschaften durch Templates basierend auf der neuen generischen Objektstruktur ähnlich des IfcPropertySetTemplate. Die Umsetzung könnte durch ein neues Teilmodell die Definition eines separaten Datenschemas erfolgen.

Der OKSTRA® erlaubt die Beschreibung von Objekten volumenbasiert mit 3D-Geometrien. Damit können die in den Straßenentwurfsprogrammen erstellten 3D-Modelle auch mit dem OKSTRA® auf Grundlage der GML-Möglichkeiten übertragen werden. Mit dem OKLABI 2020 wurde Punkt 1 des beschriebenen Änderungsantrags A0139 umgesetzt.

• Änderungsantrag A0149: Aufnahme der neuen REB21.000 zur Mengenermittlung/Bauabrechnung in den OKSTRA®. Dabei sind die OKSTRA®-Objektarten Berechnung_REB_22013, Mengendefinition und Profillinie anzupassen und neue OKSTRA®-Objektarten zu definieren. So wurden die Objektarten Berechnungsabschnitt_V, Berechnungssabschnitt_O, Berechnungsbereich_V, Berechnungsbereich_O, Teilfläche_REB_21000, Teilfläche_V, Teilfläche_O, Strecke_REB_21000 eingefügt. Die neue Objektart Berechnungsabschnitt_V beschreibt das aus den Querprofilen zu berechnende Volumen und erbt von der Objektart Mengendefinition. Ein Berechnungsabschnitt setzt sich aus einem oder mehreren Berechnungsbereichen (Objektart Berechnungsabschnitt_V) Das optionale Attribut „Ergebnis“ (Datentyp Kubikmeter) enthält das Ergebnis der Mengenberechnung. Analog ist das Prinzip zwischen den Berechnungsabschnitt_O und den Berechnungsabschnitt_O dessen optionales Attribut „Ergebnis“ (Datentyp Quadratmeter) das Ergebnis der Mengenberechnung enthält, siehe Bild 1.

Bild 1: Objektart Berechnungsabschnitt_V und Berechnungsabschnitt_O (Änderungsantrag A0149, Dokument N0191.pdf, www.okstra.de)

• Änderungsantrag A0152: Aufnahme der neuen REB22.000 „Mengenermittlung/Bauabrechnung“ in den OKSTRA®. Dazu bedarf es neuer Objektarten sowie der Anpassung der existierenden OKSTRA®-Objektarten allgemeines Punktobjekt, Bruchkante und Im Rahmen dieses Änderungsantrages wird die Objektart allgemeines_Volumenobjekt eingeführt. Es vervollständigt den im OKSTRA® bereits vorhandenen Satz allgemeiner Geometrieobjekte. Das optionale Attribut „Volumengeometrie“ (Datentyp GM_MultiSolid) beinhaltet die gegebenenfalls auch mehrteilige Volumengeometrie. Das Pflichtattribut „fachliche Bedeutung“ (Datentyp CharacterString) dient der Zuordnung der Fachbedeutung aus einer Fachbedeutungsliste. Im Rahmen der Einführung des allgemeinen Volumenobjektes wurde die neue Symbolart „Volumen“ definiert. Diese wird für die Fachbedeutungen vergeben, die in allgemeinen Volumenobjekten verwendet werden. Die beiden Objektarten OF_Berechnung und V_Berechnung wurden ebenfalls neu eingeführt.
  
  Die Objektart OF_Berechnung dient zur Darstellung der Oberflächen, wobei diese wahlweise aus einem digitalen Geländemodell (DGM), einem DGM im Bereich eines Abrechnungspolygons oder aus dem von einem Abrechnungspolygon eingeschlossenem Flächeninhalt entstehen.
  
  Die Objektart V_Berechnung dient zur Darstellung von zu berechnenden Rauminhalten. Die Rauminhalte können ermittelt werden als Auftrag und Abtrag zwischen zwei DGM bzw. zwischen einem DGM und einer Horizontalebene (außerhalb und innerhalb eines Abrechnungspolygons) oder dem Rauminhalt zwischen zwei Horizontalebenen im Bereich eines Abrechnungspolygons. Dabei können die DGM durch Höhenversätze optional verschoben werden. Das Bild 2 beinhaltet die Darstellung der OKSTRA®-Objektart V_Berechnung.

Bild 2: Objektart V_Berechnung (Änderungsantrag A0152, Dokument N0193.pdf, www.okstra.de)

Mit den beiden eindeutigen Relationen „Ergebnisgeometrie_Auftrag“ und „Ergebnisgeometrie_Abtrag“ zum neuen allgemeinen Volumenobjekt können der Auftrag und der Abtrag als 3D-Volumenkörper angegeben werden. Der Geometrie-Datentyp GM_MultiSolid ermöglicht, dass beide Ergebnisgeometrien auch aus mehreren getrennten Körpern bestehen können. Die ermittelten Rauminhalte werden durch die (optionalen) Attribute „Auftrag“ und „Abtrag“ vom Datentyp Kubikmeter ausgegeben.

Tabelle 3: Änderungsanträge OKLABI 2020 (Quelle: www.okstra.de/Änderungsanträge)

Grundsätzlich ist festzustellen, dass die inhaltliche Tiefe des OKLABI 2020 durch die Änderungsanträge weiter zugenommen hat und der OKSTRA® an neue geltende Richtlinien in Deutschland angepasst wurde.

Durch die Umsetzung von Punkt 1 des o. g. Änderungsantrags A0139 im OKLABI 2020 wurden konkrete Ergebnisse der OKSTRA-IFC-Expertenworkshops umgesetzt und die BIM-Methodik im OKSTRA® abgebildet. Festzuhalten bleibt jedoch, dass die im Änderungsantrag beschriebenen Ergänzungen des OKSTRA® um die Abbildung generischer Objekte und deren zugehörigen (erweiterbaren) Eigenschaften sowie die Übertragung von Objekten und Objekteigenschaften durch Templates im OKLABI 2020 nicht umgesetzt wurden. Es bleibt zu hoffen, dass dies in zukünftigen Versionen des OKLABI vorgenommen wird.

OKLABI 20xx

Die in der Tabelle 4 aufgelisteten Änderungsanträge befinden sich gegenwärtig in der Umsetzung und werden damit Bestandteil nachfolgender OKSTRA®-Versionen.

Tabelle 4: In Bearbeitung befindliche Änderungsanträge des OKSTRA (Stand 1. 5. 2022) (Quelle: www.okstra.de)

3 Entwicklungen IFC4.3 Infrastruktur

3.1 Entwicklungsprozess IFC4.3

Industry Foundation Classes (IFC) ist ein Datenschema, das den Austausch hochwertiger geometrischer und semantischer Daten von Bauwerken ermöglicht und als ISO 16739 veröffentlicht wurde (ISO 16739-1, 2018). Seine Entwicklung begann in den 1990er-Jahren und erfolgte in mehreren veröffentlichten Versionen. Die Version IFC2x3 stellt die erste praxistaugliche Version dar und fand weitgehend Verwendung, sowohl von Softwareanbietern in ihren Produkten als auch von Experten in ihren Arbeitsabläufen. Die aktuelle offizielle Version IFC4 erweitert und vereinheitlicht die bestehenden Konzepte aus IFC2x3. Sie wurde erstmals 2012 von buildingSMART International (bSI) veröffentlicht und im folgenden Jahr als ISO 16739:2013 herausgegeben. Die Version IFC4 weckt ein immer größeres Interesse unter Fachleuten, einige Softwarehäuser haben bereits erste Softwareprodukte nach IFC4 zertifizieren lassen (bSI 2019).

Die Entwicklung der beiden oben genannten IFC-Versionen konzentrierten sich allerdings nur auf den Austausch von Gebäudemodellen und vernachlässigte den Infrastruktursektor völlig. In den letzten zehn Jahren stieg das Interesse an einer Erweiterung von IFC zur Unterstützung von Infrastruktur-Workflows immer weiter. Dieses Kapitel fasst die wichtigsten Ergebnisse der Projekte aus den letzten Jahren zusammen und bietet einen allgemeinen Überblick für Experten, die sich (noch) nicht intensiv mit diesem Thema befasst haben. Der Inhalt, überarbeitet durch entsprechende Anpassungen und Aktualisierungen, stammt überwiegend aus Jaud et al. (2020).

Als Reaktion auf die oben genannten Wünsche startete der bSI Arbeitsraum „Infrastructure Room“ mehrere Projekte, um eine Erweiterung des IFC auf den Bereich Infrastruktur zu realisieren. Alle Entwicklungen basierten auf der aktuellen offiziellen Version IFC4, die im Bild 3 in blau dargestellt ist.

Bild 3: Überblick über die bSI-Projekte, die den IFC-Standard für den Bereich Infrastruktur erweitern. Die Jahreszahl gibt das Fertigstellungsjahr des Projekts an, der Buchstabe „c“ kennzeichnet den Status „candidate standard“ (Jaud et al., 2020)

Die ersten beiden Projekte IFC-Alignment und IFC-Overall-Architecture (im Bild 7 grün dargestellt) konzentrierten sich auf die grundlegenden Konzepte, die in allen Infrastrukturbereichen zu finden sind, z. B. die Achse und Gradiente, Stationierung und Geländemodelle. Darüber hinaus wurde eine allgemeine Richtlinie für andere geplante Aktivitäten im Infrastrukturbereich entwickelt, z. B. die Wiederverwendung bestehender IFC-Entitäten, wo immer dies möglich ist.

Hierdurch soll der Aufwand für Softwareanbieter, die den IFC-Standard bereits unterstützen, verringert werden. Die Erweiterung wurde als IFC4.1 bezeichnet und erreichte nach Abschluss des IFC-Alignment-Deployment-Projekts den Status „final standard“.

Im Anschluss wurden domänenspezifische Projekte gestartet (im Bild 7 rot und orange dargestellt). Das IFC-Bridge-Fast-Track-Projekt konzentrierte sich auf eine Schemaerweiterung zur Unterstützung der semantisch reichhaltigen Modellierung von Brückenstrukturen. Die resultierende Erweiterung IFC4.2 erreichte Anfang 2019 den Status „candidate standard“. Parallel zu den Entwicklungen für Brücken wurden im Jahr 2018 vier Projekte gestartet: IFC Common Schema, IFC-Road, IFC-Ports & Waterways und IFC-Rail. Das erste Projekt konzentrierte sich auf gemeinsame Themen wie Geotechnik und Erdbau, während sich die anderen drei ihrer jeweiligen Infrastrukturdomäne widmeten: Straßen, Häfen und Wasserstraßen sowie Eisenbahnanlagen. Im Rahmen des IFC-Common-Schema-Projekts wurde auch die Harmonisierung zwischen den Projekten der einzelnen Bereiche überwacht. Das konzeptionelle Modell des IFC-Rail-Projekts erreichte Ende 2019 den Status „candidate standard“. Ein Harmonisierungsprozess auf der Grundlage eines einheitlichen UML-Modells führte alle konzeptionellen Modelle in der IFC4.3-Standarderweiterung zusammen. Das jüngste Projekt, welches noch in Bearbeitung ist, ist das IFC-Tunnel-Projekt, das im Bild 3 ganz rechts dargestellt ist. Das Projekt konzentriert sich auf die Erweiterung der IFC4.3-Spezifikation zur Unterstützung der Besonderheiten von Tunnelanlagen. Das Team hat vor kurzem das konzeptionelle Modell vorgestellt und fängt demnächst mit der Modellierung notwendiger Anpassungen im IFC-Datenmodell, die voraussichtlich IFC4.4 heißen wird, an.

In den letzten beiden Jahren liefen parallel zwei Projekte, die unter anderem mit der SoftwareValidierung betraut waren: IFC-Rail-Phase 2 und IFC-Infrastructure-Extensions-Deployment. Hier erstellten Domänenexperten, Softwareanbieter und Moderatoren gemeinsam sogenannte „Storylines“ und „Unit tests“, um die Anwendbarkeit der entwickelten IFC4.3-Schemaerweiterungen gründlich zu überprüfen und anhand der in den Anforderungsberichten spezifizierten IDMs (Information Delivery Manual’s) zu validieren. An beiden Projekten haben sich weltweit große und kleine Softwarehäuser, öffentlichen Behörden und Verwaltungen sowie private Planungs- und Bauunternehmen beteiligt und damit viel Aufmerksamkeit erregt. Am Ende haben die beteiligten Softwarehersteller die generelle Implementierbarkeit von IFC4.3 nachgewiesen. Weltweit prüften Fachexperten die Anwendbarkeit der IFC4.3-Schemaerweiterungen beim Austausch von Fachobjekten und zugehörigen semantischen Informationen nach den Vorgaben der gemeinsam erstellten „Storylines“.

Anschließend haben die Arbeitsgruppen „Infrastructure Room“ und „Railway Room“ gemeinsam das halbjährige Projekt „Certification MVDs for Infrastructure and Railway“ ins Leben gerufen. Damit sollten die notwendigen Anleitungen und Daten für eine sofortige Softwarezertifizierung nach der offiziellen Veröffentlichung des IFC-Standard entwickelt und dem Zertifizierungsteam zur Verfügung gestellt werden. Ein Hauptergebnis war, dass als Grundlage für einen reibungslosen Datenaustausch im Bereich der Infrastruktur die Model View Definition (MVD) „Alignment based Reference View (AbRV)“ dient. Dies geschieht analog zum Vorgehen in der Gebäudedomäne, die dafür die MVD „Reference View“ benutzt.

Alle Anleitungen und Daten basierten auf den gesammelten Beispielen aus den „Storylines“ und „Unit tests“ und sind öffentlich zugänglich auf https://github.com/bSI-InfraRoom/MVD-Infra-Test-Instructions.

Anfang März 2022 wurde der IFC4.3-Standard als „final standard“ bezeichnet und bei ISO eingereicht. Zum Zeitpunkt der Veröffentlichung dieses Berichts war noch nicht absehbar, wie viel Zeit die ISO-internen Arbeitsabläufe in Anspruch nehmen. Eine Veröffentlichung als ISO-Standard erfolgt voraussichtlich im Frühjahr 2023. Parallel überdenkt buildingSMART International (bSI) die Art und Durchführung von der Zertifizierung der Softwareprodukte. Mit dem Ziel einer Beschleunigung des Zertifizierungsprozesses und einer verbesserten Transparenz soll dieser eventuell komplett überarbeitet werden.

3.2 IFC4.3 Erweiterungen – Details

Gemäß den Leitlinien des IFC-Infra-Overall-Architecture-Projekts verwendeten die Projekte die bestehenden Entitäten und Konzepte wieder. Einen Überblick über die am IFC-Schema vorgenommenen Änderungen gibt Tabelle 5, in der die Gesamtzahl der Ergänzungen, Aktualisierungen und Verwerfungen für die verschiedenen Elemente des IFC-Standards aufgeführt sind.

Tabelle 5: Anzahl der Änderungen in IFC4.3 im Vergleich zu IFC4

Eine der wichtigsten Erweiterungen des Standards ist das Konzept der linearen Referenzierung, die auf ISO 19148:2012 basiert (ISO 2012). Hierfür wurden die Entitäten IfcPositioningElement, IfcLinearPositioningElement, IfcReferent und IfcRelPositions eingeführt, die die erforderliche Semantik für die Positionierung von Elementen relativ zu anderen Elementen modellieren. Die Verortung und Orientierung eines Objekts im Raum kann nun mit IfcLinear-Placement angegeben werden, so dass jedes IfcProduct entlang einer Achse platziert werden kann. Darüber hinaus wurde der Geometriekern um linear extrudierte Geometrien wie IfcSectionedSolidHorizontal und IfcSectionedSurface erweitert, die die Beschreibung von Objektgeometrien in einer für den Infrastrukturbereich üblichen Weise unterstützen: Extrusion mit veränderbaren Profilen entlang einer Raumachse. Das IFC-Schema unterstützt nun auch die mathematisch gängigen Definitionen sämtlicher Übergangsbögen mit von IfcSpiral abgeleiteten Klassen, unter anderem die IfcClothoid, die üblicherweise im Straßenbau Anwendung findet.

Weitere Ergänzungen und Änderungen im Vergleich zu IFC4 beinhalten z. B.:

• vielseitige Projekt- und Raumstrukturelemente, B. IfcFacility und IfcFacilityPart,
• Erweiterung des Produktbaums um neue Entitäten und neue vordefinierte Typen für Infrastrukturelemente, z. B. für Straßenschichten: IfcCourse, IfcCourseTypeEnum und IfcCourseType, bzw. für Erdarbeiten und Geotechnik: IfcEarthworksElement und IfcGeomodel,
• Standardisierung von Eigenschafts- und Mengensätzen für diverse Entitäten, z. B. Pset_ BearingCommon, und
• weitere Geometriedefinitionen, z. B. IfcOpenCrossProfileDef, IfcReferenceSegment und IfcSegmentedReferenceCurve.

4 Praxistauglichkeit

4.1 Vergleich OKSTRA® – IFC – Stand 2022

Die Tabelle 6 zeigt ausgewählte Merkmale von OKSTRA® und IFC. Während beide Standards nun generische semantische Objekte unterstützen, bestehen wesentliche Unterschiede in Bereichen der Anwendbarkeit und Qualitätssicherung. Zum Beispiel kommt OKSTRA® nur in Deutschland zur Anwendung und kann nur im XML-Format geschrieben werden. IFC kann hingegen in mehreren Formaten serialisiert werden und findet weltweit seinen Einsatz. Ein weiterer Unterschied ist die Qualitätssicherung der Implementierungen: während bSI eine Softwarezertifizierung für bestimmte Austauschszenarien anbietet, existiert für OKSTRA® ein Prüftool, dass die Korrektheit der Dateien überprüft, nicht aber die Softwarelösungen.

Tabelle 6: Vergleich OKSTRA vs IFC

Ein wesentlicher Unterschied zwischen OKSTRA® und IFC ist die Anpassungsfähigkeit des Datenmodells an individuelle Auftraggeberanfordungen (AIA). Während OKSTRA® auf die Anforderungen der deutschen Straßenbehörden (Regelwerke) abgestimmt wurde, wird IFC weltweit entwickelt und hat deshalb keinen direkten Bezug zu nationalen Regeln oder Vorschriften. Mit den sehr spezifischen Regeln des OKSTRA® kann der Im- bzw. Export der Daten zuverlässig implementiert und interpretiert werden und vereinfacht die Anwendung in Deutschland. Im Gegensatz dazu können mit IFC individuelle und nationale Anforderungen realisiert werden. Hierfür wird allerdings Experten Know-How sowie einiges an Vorarbeit benötigt. Zusammenfassend kann gesagt werden, dass OKSTRA® die AIA weitgehend eingebettet hat, während IFC sehr generell gehalten wurde und erst durch AIA und einen BIM-Abwicklungsplan (BAP) projektspezifisch eingesetzt werden kann.

Der IFC-Standard schließt eine Vielzahl neuer Fachgebiete/Domänen ein. In einigen Gewerken ist dieser Standard zunächst zu etablieren und muss sich in der produktiven Anwendung erst beweisen. Dazu sind durch die Softwarehäuser gute Prototypen zu implementieren, die mit den Anforderungen und den Prozessen in Firmen und Behörden zu validieren und ggf. anzupassen sind. OKSTRA® gilt hingegen als die derzeit im Straßenbau leistungsfähigste Schnittstelle in Deutschland und ist bereits seit vielen Jahren etabliert.

Der IFC-Standard gestattet die Nutzung bei zahlreichen Anwendungsfällen in der gesamten Baubranche. So können Projektbeteiligte ihre Daten miteinander verknüpfen, vergleichen und koordinieren. Da IFC auch in den benachbarten Fachgebieten der Baubranche angewendet wird, können fachübergreifende Projekte in Form unterschiedlicher Fachmodelle erstellt, bearbeitet und ausgetauscht werden. Das IFC-Datenschema ist damit das zentrale Tool zur Erstellung von BIM-konformen Modellen. Gemeinsam mit dem BIM Collaboration Format (BCF) für das Qualitäts- und Mängelmanagement bildet es die Grundlage des Building Information Modelling. Dies schließt jedoch nicht aus, dass der OKSTRA® ebenfalls zum Bestandteil von BIM wird. OKSTRA®-konforme Daten lassen sich ebenfalls in einem gemeinsamen Datenraum verwalten und sind damit auch Bestandteil der „Single Source of Truth“.

4.2 Forschungsaktivitäten

Zum Themenbereich rund um OKSTRA® und IFC (Datenaustausch, Datenformate, Standards, Harmonisierung) befinden sich derzeit einige Forschungsprojekte auf nationaler und internationaler Ebene in Bearbeitung. Exemplarisch sind hier ein paar Projekte aufgezählt, die in den letzten Jahren bearbeitet und zum Teil schon abgeschlossen wurden. Auf der Webpage www.okstra.de können im Bereich Forschungsaktivitäten die Ergebnisse weiterer laufender und bereits abgeschlossener Forschungsarbeiten eingesehen werden.

• Umsetzung des Stufenplans Digitales Planen und Bauen: Hier sei an die durchgeführten OKSTRA®-IFC Expertentreffen erinnert, dessen Ergebnis der oben beschriebene Änderungsantrag zur Einführung von Volumengeometrie-Attributen im OKSTRA® resultierte (BMVI, 2015). Der Stufenplan Digitales Planen und Bauen (BMVI, 2015) wird durch den Masterplan BIM Bundesfernstraße (BMVI, 2021) fortgesetzt und nachfolgend auch in einem Masterplan BIM Digitaler Zwilling ab 2025 münden.
• Building Information Modeling (BIM) im Straßenbau unter besonderer Berücksichtigung der Erhaltungsplanung: Da Fahrbahnbefestigungen einen erheblichen Finanzierungsbedarf bei der Straßenerhaltung verursachen, spielen sie eine wichtige Rolle bei der Planung von Erhaltungsmaßnahmen. BIM-Modelle erscheinen durch ihre Verknüpfung von geometrischen, ökonomischen und ökologisch-sozialen Daten besonders geeignet für das Erhaltungsmanagement. Derzeit wird bei der Erhaltungsplanung der OKSTRA® als Datenstandard in Kombination mit GIS-Systemen genutzt. In diesem Zusammenhang ist zu untersuchen, ob eine Anpassung des OKSTRA®-Standards für die Anwendung in der BIM-Methodik erforderlich machbar ist. Damit ist auch die Frage zu beantworten, wie geeignete BIM-Modelle für die Anwendung in der Erhaltungsplanung von freien Strecken bzw. POI (Points of Interest, z. B. Kreuzungspunkte) gestaltet sein müssen. (Quelle: Bundesanstalt für Straßenwesen (BASt))
• Analyse von Straßenbestandsobjekten aus Laserpunktwolken durch Mustererkennung/Objekterkennung einschließlich der Georeferenzierung: Mit dem Forschungsvorhaben sollen Methoden und Algorithmen entwickelt werden, die in der Punktwolke nach vorab definierten Mustern von Bestandsobjekten suchen und erkannte Objekte protokollieren und OKSTRA®-konform Eine Methode, die aus Punktwolken Bestandsobjekte analysieren kann, würde die notwendigen Vorarbeiten bei der Planung und beim Betrieb einer Straße gegenüber der bisherigen Arbeitsweise erheblich vereinfachen und beschleunigen. (Quelle: Bundesanstalt für Straßenwesen (BASt))
• IFC-Tunnel: Erweiterung von IFC-Datenschemas um die Besonderheiten des Hier werden vor allem geologische sowie geotechnische Modellierung und die Definition von Tunnelquerschnitten untersucht und gegebenenfalls in IFC neu modelliert. Bestehende Entitäten werden nach Bedarf angepasst, z. B. für die räumliche Struktur oder Georefenzierung.
• IFC 5: Das IFC Schema soll gründlich überarbeitet Es soll modernisiert, modularisiert sowie normalisiert werden. So soll der Objektbaum vereinfacht werden um ein „Late-Bind“ Ansatz für die zukünftige Versionen zu ermöglichen (Berlo et al., 2021).

4.3 Beispiel Abrechnungsdaten nach REB 22.013 mit OKSTRA und IFC

Zur Illustration der Anwendung des OKSTRA® und den IFC-Datenformats dient die Erstellung eines Abrechnungsdatensatzes nach REB 22.013. Dabei handelt es sich um eine Baugrube für ein Gebäude. Die Erzeugung von Abrechnungsdaten basiert auf der Analyse von zwei digitalen Geländemodellen. Das erste Modell stellt den Ausgangszustand vor der Baumaßnahme dar (Urgelände), das zweite Modell repräsentiert die Baugrube der Baumaßnahme als DGM. Beide Modelle werden miteinander verglichen und daraus die Massendifferenz gebildet. Diese bildet den Rauminhalt und stellt damit das Abrechnungsvolumen der Baugrube dar. Die Methode der Massenermittlung besteht in der Errechnung eines Rauminhaltes beider Geländemodelle auf einen definierten Bezugshorizont. Die Differenz beider Mengen ergibt folgerichtig den Rauminhalt der Baugrube, siehe Bild 4 (Hettwer; Steyer, 2018).

Über die Schaltfläche „Prüfdatei“ (siehe Bild 4) wird eine XML-Datei gemäß REB 22.013 im OKSTRA®-Format ausgegeben und im Projektpfad abgespeichert. Diese Prüfdatei kann im OKSTRA®-Prüfprogramm eingelesen, analysiert und dargestellt werden (siehe Bild 5). Das OKSTRA®-Prüfprogramm beinhaltet neben der Prüffunktionalität eine Vielzahl von weiteren Funktionen, z. B. das Vergleichen und Verschmelzen von verschiedenen Datenbeständen, die Transformation von Datenbeständen in ausgewählte Koordinatensysteme die Korrektur von Stationierungen oder OKSTRA®-ID.

Bild 4: OKSTRA® Ausgabe (VESTRA – REB Mengenberechnung)

Bild 5: OKSTRA® Prüfprogramm, links Datenstruktur, rechts Grafische Modelldarstellung

Das Ergebnis der Rauminhaltsberechnung lässt sich auch als BIM-Objekt mit den zugehörigen semantischen Informationen abspeichern und als IFC-Datei ausgeben. Das Bild 6 zeigt einerseits das IFC-Modell im IFC4.0, wo die einzelnen Objekte als Proxy-Elemente in ihrer Geometrie und mit den zugeordneten semantischen Informationen in einem IFC-Viewer dargestellt sind. Die rechte Seite von Bild 6 beinhaltet heute schon einen Blick in die nahe Zukunft. Es handelt sich um die Darstellung der gleichen Baugrube, die auf Grundlage des neuen IFC 4.3 Datenschemas für die Infrastruktur modelliert wurde.

Bild 6: Anzeige IFC Modell Baugrube im IFC-Viewer und TUM Open Infra Platform

5 Schlussfolgerungen und offene Fragen

Im Ergebnis dieses Vergleiches des Entwicklungsstandes von IFC4.3 und dem OKSTRA® und deren Anwendbarkeit können die nachfolgenden Schlussfolgerungen gezogen werden:

• Das IFC-Datenschema ist in vielen Bereichen des Planens und Bauens und der benachbarten Fachdisziplinen Dies dokumentieren die schon vorhandenen sehr umfangreichen Anwendungsfälle.
• Die Erweiterung des IFC-Datenschemas 4.3 für die Infrastruktur ist seitens bSI finalisiert und an die internationalen Normungsgremien übergeben worden.
• Inhaltlich stellt der IFC eine erste Erweiterung des IFC-Standards für die Infrastruktur dar und bildet ein internationales Fundament, auf dem nationale Standards mit Bezug zu entsprechenden technischen Richtlinien und Prozessen aufbauen müssen.
• Aus Sicht der Autoren besteht Abstimmungsbedarf zwischen Definitionen des IFC4.3 und den Arbeiten der Fachgruppe BIM im Verkehrswegebau zu den Klassen/Objekten und Merkmalen.
• Der OKSTRA® wurde in den letzten Jahren sehr umfangreich an neue Richtlinien im Straßenwesen angepasst und Im Vergleich zum IFC-Datenschema ist OKSTRA® das umfangreichere und inhaltlich detailliertere Datenformat.
• Der OKSTRA® ist weiterhin unter Berücksichtigung der BIM-Methodik zu entwickeln. Dies betrifft sowohl die Definition von Volumenkörpern als auch der zugehörigen Merkmale/Attribute.
• Es bleibt auch heute festzuhalten, dass beide Datenformate ihre Berechtigung haben und damit weiterhin parallel existieren Deshalb sollten beide Datenformate in die Ausschreibungen von BIM-Projekten im Verkehrswegebau durch die Bauherren gefordert werden.

Zwangsläufig führen die genannten Schlussfolgerungen zu offenen Fragen, die durch die weiteren Entwicklungen des OKSTRA® und IFC zu beantworten sind.

1. Unter der Annahme, dass OKSTRA® und IFC für Infrastrukturprojekte auch in Zukunft parallel existieren, lassen sich für die Anwendung beider Datenformate separate (spezifische) Anwendungsfälle definieren? Wie ist dies in der Praxis umsetzbar?
2. Inwiefern erscheint es sinnvoll und machbar die große Detailtiefe des OKSTRA® auf dem Gebiet der Straße in einem „Deutschen IFC-Property Set Straße“ oder ähnlichen Konzepten des IFC-Schemas umzusetzen? Reichen in diesem Zusammenhang die derzeit definierten generischen Klassen/Objekte im IFC4.3 zur Abdeckung der Anforderungen im Planungs-, Bau- und Betriebsrecht aus?
3. Durch die Weiterentwicklung des OKSTRA® wurden fachliche Bezüge zur BIM-Methodik (z. B. neue Verfahren zur Mengenberechnung) geschaffen. Es wurden bis heute jedoch nur wenige Schritte unternommen, den OKSTRA® durch die Definition von 3D-Objekten und deren zugehörigen semantischen Informationen BIM-ready zu Wie stellt sich die Strategie für den OKSTRA® unter Berücksichtigung des parallelen IFC-Standards dar? Wie ist in diesem Zusammenhang die Fachobjektliste der neuen RAS-Verm zu bewerten?
4. Ist es denkbar, dass andere BIM-konforme Datenformate wie BCF oder MVD in einen OKSTRA® Umfeld zu integrieren oder anzuwenden?

Literaturverzeichnis

OKSTRA (2022): OKSTRA Webseite (Änderungsanträge, Dokumente, Forschungsaktivitäten); verfügbar unter https://www.okstra.de (06.04.2022)

van Berlo, L.; Krijnen, T.; Tauscher, H.; Liebich, T.; van Kranenburg, A.; Paasiala, P. (2021): Future of the Industry Foundation Classes: towards IFC 5. Proceedings of the Conference CIB W78 2021, Luxembourg

BMVI (2015): Stufenplan Digitales Planen und Bauen, Einführung moderner, IT-gestützter Prozesse und Technologien bei Planung, Bau und Betrieb von Bauwerken

BMVI (2021): Masterplan BIM Bundesfernstraßen, Digitalisierung des Planens, Bauens, Erhaltens und Betreibens mit der Methode Building Information Modelling (BIM)

bSI (2019): IFC4 Software Certification Delivers First Milestone. Verfügbar unter https://www.buildingsmart.org/ifc4-software-certification-delivers-first-milestone/ (13.04.2022)

Frei, M. (2018): OKSTRA und IFC – Ein Vergleich, OKSTRA-Symposium 15./16. Mai 2018, Bergisch Gladbach

Hettwer, J.; Steyer, R. (2018): OKSTRA® in der Bauabrechnung – die Umsetzung der REB-VB 22.013 Ausgabe 2012, OKSTRA-Symposium 15./16. Mai 2018, Bergisch Gladbach

ISO 16739-1:2018 (2018): Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries – Part 1: Data schema. Standard, International Organization for Standardization, Geneva, CH.

Jaud, Št.; Esser, S.; Muhič, S.; Borrmann, A. (2020): Development of IFC schema for infrastructure. Proceedings of 6th international conference siBIM: Structured data are new gold, pp. 27–35. Online