Leitfäden für Bauherren
So funktioniert pragmaticBIM
Ein lebendiger, versionierter Projektplan - welche Information wozu, in welchem Modell und ab welcher Phase
Veröffentlicht
Simon Dilhas (Mitgründer abstract & BIM Pirate)
Jetzt kostenlos startenDie Webanwendung auf pragmaticBIM.ch macht aus der pragmaticBIM-Referenz und dem Elementplan einen lebendigen, versionierten Projektplan: welche Information gebraucht wird, wozu, in welchem Modell und ab welcher Phase. Planende konfigurieren ein Projekt aus den Referenzdaten oder einer eigenen Vorlage, publizieren es als projektspezifische Vorlage, und Modellierende prüfen IFC-Dateien gegen dieselben Regeln.
Der Ablauf
- Vorlage einfrieren - die Referenzdaten oder den gemeinsamen Katalog als Release publizieren. Nur dieser eingefrorene Stand kann Projekte erzeugen.
- Projekt anlegen und konfigurieren - aus diesem Release legt ein Admin ein neues GitHub-Repository an. Dann Projektziele und/oder Use Cases wählen, damit nur die Anforderungen dieses Gebäudes bleiben.
- Projekt einfrieren - das konfigurierte Projekt als eigenes Release publizieren. Erst dann erscheint es im Viewer (Frontend).
Die Idee
Die meisten Projekte starten von denselben Grundlagen guter Praxis. Sie unterscheiden sich in der Ambition (Ziele), in den Use Cases, die sie wirklich fahren, und in der Modellteilung (Architektur vs. HLK, Raummodell vs. Fassade). Die Webanwendung nutzt die Referenzdaten der pragmaticBIM-Referenz (oder eine eigene Master-Vorlage), friert sie als publiziertes Release ein und kopiert dieses Release in ein Projekt. Danach schlanken Sie die Anforderungen bis hin zum Elementplan ab und weisen sie diesem Gebäude zu.
Zwei Arbeitsorte
Editor - BIM-Koordinatoren und Organisations-Admins. Anmeldung mit GitHub. Hier schreiben Sie Anforderungen, mergen IDS anderer Planer und publizieren Versionen.
Viewer - alle, die den publizierten Plan brauchen. Anforderungen ohne Login lesen. Downloads und Modellchecks können einen E-Mail-Code verlangen.
Vom Master zum geprüften Modell
- Master-Vorlage - ein gemeinsamer GitHub-Katalog: Projektziele, Use Cases (Workflows), Domains, Modelle (Teilmodelle), Elemente, Attribute und erlaubte Werte.
- Ins Projekt kopieren - ein Admin legt ein Projekt aus einem publizierten Template-Release an. Jedes Projekt ist ein eigenes GitHub-Repository.
- Konfigurieren - Zielstufen und/oder Use Cases wählen, damit nur die relevanten Anforderungen im Projekt bleiben.
- Information Delivery Plan - festlegen, in welchem Modell (und welcher Phase) die Information jedes Elements erscheinen muss.
- Andere Planer mergen - buildingSMART-IDS-Dateien in einen Entwurf importieren und Anforderungen behalten, überspringen oder ergänzen.
- Prüfen und publizieren - Entwürfe ändern den Live-Plan erst, wenn ein Admin sie genehmigt. Publizieren dieses Projekts als Release erzeugt IDS, Excel und Reports für den Viewer.
- Prüfen - im Viewer Actions starten: ein IFC hochladen und gegen die publizierte IDS validieren.
Was die Wörter bedeuten
| Begriff | Bedeutung |
|---|---|
| Projektziel | Übergeordnetes Ziel (z. B. Ausbaustandard, Nachhaltigkeit) mit geordneten Sensitivitätsstufen (Ausprägungen). Eine höhere Stufe enthält alles darunter. |
| Workflow / Use Case | Eine konkrete BIM-Aufgabe (z. B. Flächen und Volumen, Kosten, Brand). Attribute sind für Use Cases erforderlich. |
| Domain | Disziplin oder Verantwortung (Architektur, HLK, Elektro). |
| Modell (Teilmodell) | Eine Liefereinheit unter einer Domain (Raummodell, Fassadenmodell). Das ist die Datei, in der wirklich modelliert wird. |
| Element | Ein Gebäudeobjekt (Wand, Tür, Raum) mit IFC-Entity und Attributen. |
| IDS | buildingSMART Information Delivery Specification - die maschinenlesbare Prüdatei. |
Live Data vs. Entwürfe
Im Editor ist Live Data der genehmigte Plan (nur lesen). Sie bearbeiten auf einem Entwurf, klicken Save, dann Submit for review. Ein Organisations-Admin nutzt Pending Reviews → Approve & Apply. Erst danach ändert Publish Version, was der Viewer zeigt.
Ein Projekt-Repository anzulegen reicht nicht. Live Data reicht nicht. Der Viewer sieht nur publizierte Projekt-Releases - dasselbe Einfrieren wie bei der Vorlage, jetzt für das Frontend.
Wer darf was
- Organisations-Admin - Projekte anlegen, Reviews genehmigen, publizieren, Benutzer und Viewer-Actions verwalten.
- Editor (GitHub-Collaborator) - Entwürfe bearbeiten und zur Prüfung einreichen.
- Viewer-Mitglied - E-Mail auf der Projekt-Zugriffsliste; Downloads und Actions nach Login-Code.