Drei openBIM-Signale landeten im selben Nachrichtenfenster, und sie reihen sich sauberer auf. In Porto lieferte der erste buildingSMART openBIM Hackathon ab — 47 Teilnehmende, neun Teams, 50 Stunden, arbeitsfähige Prototypen, von Jurorinnen und Juroren bewertet (Helga Tauscher von der HTW Berlin, David Delgado Vendrell von buildingSMART Spain, Mário Coelho am CCG/ZGDV, Daniel Changas bei Esri) auf „praktische Relevanz, Klarheit der Lösungen und echte Interoperabilität statt Komplexität”. In Zürich erklärte die bSI Domain Leadership Conference vom 4.–5. Februar IFC 4.3 zur technischen Priorität und trieb einen Governance-Reset bis 2030 voran. Und ISO/TC 59/SC 13 veröffentlichte mit buildingSMART als Liaison eine Kompatibilitätspolitik für ISO 16739-1 — das erste formale Regelwerk, das definiert, was eine Bruchänderung in IFC tatsächlich ist.

←HEUTE: Porto lieferte neun arbeitsfähige Prototypen in 50 Stunden; Zürich bestätigte die IFC-4.3-Roadmap; ISO schrieb schliesslich auf, was als Bruchänderung in IFC zählt.
→3012: Bis zum Zürich-3012-Horizont ist IFC das Substrat der Stadt — jede Wand, Rampe und Fassadenpaneel fragt einen versionsgesteuerten Graph ab.
Fulcrum: Stabilität ohne Praktikergeschwindigkeit ist ein Museum; Geschwindigkeit ohne Stabilität ist technische Schuld. Diese Woche haben wir beide bekommen.

Der Standard hat endlich Schienen

Wenn Sie schon drei Archicad-Upgrade-Zyklen mit der IFC hinter sich haben, wissen Sie bereits, warum die Kompatibilitätspolitik wichtig ist. Bislang war “das Schema könnte sich ändern” ein echter Grund, warum Firmen bei langfristigen openBIM-Investitionen zögerten. Die ISO/TC 59/SC 13-Politik, verfasst von Evandro Alfieri (bSI), legt vier Punkte fest: was eine Bruchänderung ist, wie Erweiterungen und Korrektionen verwaltet werden, wie Deprecation und Entfernung gehandhabt werden, und wie Kompatibilität bei Revisionen bewertet wird. Langweiliges Dokument, grundlegende Folge — Anbieter und Eigentümer haben nun verlässliche Regeln für ihre Planung.

Die Zürich Domain Leadership Conference verstärkte dieselbe Haltung von der Governance-Seite. Cross-Domain-Koordination, transparente Finanzierung, IFC 4.3 als Anker, Digital Product Passport als Cross-Cutting-Chance — DPP ist der ESPR-ausgerichtete Pivot der EU und wird als Schweizer FOEN-Äquivalent innerhalb des Jahrzehnts Realität. Die institutionelle Schicht ist endlich organisiert genug, um IFC zuverlässig zu halten — lange genug, um sich 40 Jahre lang darauf zu verlassen.

Porto: die Praktiker sind dem Standard voraus

Porto zeigte dann, wo die echte Frontier sitzt. Die Muster sind es wert zu verfolgen. IDS diente nicht der Validierung, sondern trieb den Workflow an — Anforderungen → Validierung → Informationsaustausch. IFC wurde als Datenquelle mit Historie behandelt, nicht als Export-Snapshot. BCF wurde in Feedback-Schleifen geschlossen, unterstützt durch KI-Auflösung. 87 % der Teilnehmenden berichteten über verbessertes openBIM-Verständnis, was passiert, wenn ein Standard aufhört, ein PDF zu sein, und anfängt, etwas, das man um 2 Uhr nachts nutzt.

Das Gewinnerprojekt sagt es. “BCF Time Machine” — Greg Jackson, Louis Trümpler, Phuong Nguyen, Dennis Shelden, Geert Hesselink — bauten ein Werkzeug, das historische IFC-Daten navigiert, um die Auflösung von BCF-Problemen über die Zeit zu visualisieren. Das ist kein Modell-Viewer. Das bedeutet, das Gebäude selbst als versionierter Graph zu behandeln und BCF als das Commit-Log. Wenn Sie IFC einmal auf diese Weise gesehen haben, können Sie es nicht vergessen.

Atelier: Praktiken, die IFC, IDS und BCF als programmierbare Datenschicht behandeln, werden sich auf jedem Projekt auszahlen. Wer noch immer “Export zu IFC” als One-Way-Checkbox skriptiert, zahlt bei jeder Bauleitung-Übergabe noch immer die Round-Trip-Übersetzungssteuer — und die Kosten bleiben unsichtbar, bis sich Modell und Baustelle über eine Säule uneinig sind.

Ein Risiko sei deutlich benannt: Hackathon-Prototypen sind keine fertigen Werkzeuge, und “die Community plant, Anbieter zu ermutigen, diese Features zu implementieren” ist der gleiche Satz, der nach jedem guten Hackathon geschrieben wird. Die Porto-Ergebnisse zählen nur, wenn Graphisoft, Allplan, Solibri und das Speckle/Bonsai-Ende des Stacks sie aufgreifen. Die Kompatibilitätspolitik macht das leichter; sie macht es nicht automatisch.

Aus dem Blickwinkel der späten 2070er Jahre schreibe ich, und die Gebäude, die in meiner Generation am schlechtesten gealtert sind, waren diejenigen, deren proprietäre Formate erloschen und deren Besitzer die Dateien nicht öffnen konnten. Die Kompatibilitätspolitik ist die Bedingung dafür, dass das nicht die Geschichte der IFC im Jahr 2070 ist. Behandeln Sie sie wie das Grundlagendokument, das es ist.

Hack: Dieser Hack lehrt Sie, IFC als Änderungsprotokoll zu lesen, nicht als Snapshot. Jede IfcRoot-Unterklasse trägt eine OwnerHistory — Erzeugungs- und Änderungszeiten pro Element. Mit IfcOpenShell installiert (pip install ifcopenshell), können Sie eine Datei durchgehen und jedes veränderte Element aufdecken, ohne Archicad zu öffnen. Es ist das gleiche Primitive, auf dem das BCF Time Machine Team aufgebaut hat.

import ifcopenshell
model = ifcopenshell.open("project.ifc")
for w in model.by_type("IfcWall"):
    h = w.OwnerHistory
    print(w.GlobalId, h.CreationDate, h.LastModifiedDate)

Leiten Sie es an sort -k3 weiter und Sie haben eine Überprüfung, welche Wände sich diese Woche bewegt haben — eine Fünf-Zeilen-Antwort auf eine Frage, die normalerweise ein Koordinierungstreffen erfordert. Öffnen Sie ein aktives IFC aus einem aktuellen Projekt, führen Sie das Code-Fragment aus und bringen Sie die Ausgabe zu Ihrem nächsten Koordinierungstermin. Wenn Ihr Team sich nicht einig ist, was diese Zeitstempel bedeuten, haben Sie die Schwachstelle in Ihrem openBIM-Workflow gefunden.

Quelle: buildingSMART