Informations-
bedarfstiefe.
Ein LOD-300-Modell gibt es nicht. Informationen werden je Bauteil angefordert, für einen Zweck und zu einem Datenübergabepunkt.
Was ist ein LOD 300?.
Der Vertrag fordert ein „LOD-300-Modell“. Wer es bestellt, meint das eine, wer modelliert, etwas anderes. Was geliefert wird, weiß niemand, bis es da ist.
So viel wie nötig.
Und so wenig wie möglich. Der Informationsbedarf ergibt sich nicht aus einer Zahl, sondern aus vier Vorfragen.
Drei Arten von Information.
Was gezeichnet, was geschrieben und was beigefügt wird. Jede Art wird getrennt und mit eigener Tiefe angefordert.
Die Form in fünf Fragen.
„Mehr Detail“ sagt nichts aus. Festzulegen sind Detaillierung, Dimensionalität, Lagegenauigkeit, Erscheinungsbild und ob die Form veränderbar ist.
Erst klären, was es ist.
Daten haben zwei Teile: das Objekt eindeutig identifizieren und es mit Merkmalen beschreiben, die Name, Wert und Einheit haben.
Gezeichnet ist nicht entschieden.
Eine Tür kann samt Drücker gezeichnet und trotzdem nicht entschieden sein. Detail ist, was hineingesteckt wird; Fertigstellungsgrad, worauf man sich verlassen kann.
Von 100 bis 500.
Von 100 bis 400 wächst die Verlässlichkeit jedes Bauteils; 350 koordiniert die Gewerke, und 500 ist nicht mehr, sondern das auf der Baustelle Verifizierte. Klicken Sie und sehen Sie sich eine Tür an.
Jedes Bauteil, seine Tiefe.
Zum selben Datenübergabepunkt kann das Tragwerk feststehen und die Möblierung kaum skizziert sein. Deshalb wird Bauteil für Bauteil in einer Matrix angefordert.
Mehr ist nicht besser.
Jede angeforderte Information muss erstellt, geprüft und gepflegt werden. Was niemand nutzt, ist verlorene Arbeit und Rauschen für alle, die suchen.
Information reift.
Angefordert wird, was zum jeweiligen Übergabepunkt entschieden werden kann. Wer eine Angabe zu früh verlangt, zwingt dazu, sie zu erfinden.
Gemessenes hat Toleranz.
Entsteht das Modell aus einem Aufmaß, gibt die Stufe auch an, wie weit das Modellierte von der Wirklichkeit abweicht.
Von der Zahl zur Anforderung.
Wählen Sie ein Objekt und einen Zweck: Die Informationsbedarfstiefe ergibt sich aus diesem Paar, nicht aus einem Etikett für das ganze Modell.
Von LOD zu LOIN.
Es begann als Skala eines Softwareherstellers und ist heute eine ISO-Norm. Unterwegs hat es dreimal den Namen gewechselt.
Die Norm in einem Schema.
Vier Vorfragen und drei Informationsarten, jede mit ihren Aspekten. Die Norm definiert keine nummerierten Stufen, sondern wie man sie beschreibt.
Sie gehört in den Vertrag.
Die Anforderungen der Organisation werden auf Projekt und Informationsaustausch heruntergebrochen. Dort legt jede Anforderung die Informationsbedarfstiefe fest.
Das Wörterbuch der LOD.
Sie definiert mit Abbildungen, was jede Stufe für jeden Bauteiltyp bedeutet. Seit 2025 übersetzt sie jede Stufe in die Aspekte der ISO 7817-1.
Jedes Land, seine Kürzel.
Dasselbe Konzept heißt in den USA LOD, in Deutschland LOG und LOI und in Chile NDI. Europa nähert sich der Informationsbedarfstiefe an.
Damit „Feuer“ überall dasselbe heißt.
Ein Merkmal zu fordern nützt wenig, wenn es jeder anders nennt. Datenkataloge legen Name, Typ, Einheit und zulässige Werte fest.
Leitfaden und digitales Format.
Teil 1 erklärt das Konzept. Teil 2 wird die Anwendung mit Beispielen zeigen, Teil 3 macht daraus eine maschinenlesbare Datei.
„Fein“ ist nicht LOD 400.
Die Programme haben einen Detaillierungsgrad der Ansicht, der nur festlegt, welche Linien in welchem Maßstab gezeichnet werden. Über den Stand des Bauteils sagt er nichts.
Jedes Programm, seine Schublade.
Parameter, Eigenschaften, Attribute: Der Name ändert sich, die Idee nicht. Wichtig ist, sie einmal zu definieren und im ganzen Projekt wiederzuverwenden.
Vom Parameter ins IFC.
Ein sauber ausgefüllter Wert im Programm kommt nicht im IFC an, wenn niemand festlegt, in welchem Property Set er ausgegeben wird. Das wird im Exporter eingestellt.
Die Anforderung kommt ins Programm.
Mehrere Programme importieren bereits eine IDS und legen die geforderten Merkmale an. So modellieren Sie mit dem Wissen, was geprüft wird.
Die Matrix in einer Datenbank.
Bei Hunderten von Objekten und Meilensteinen stößt eine Tabellenkalkulation an Grenzen. Plattformen speichern die Anforderungen und exportieren sie zum Modellieren und Prüfen.
Die Cloud hinkt noch hinterher.
Cloud-Viewer filtern nach Merkmalen, aber eine IDS-Prüfung direkt in der Plattform ist noch die Ausnahme und meist separat kostenpflichtig.
Ein Platz für jeden Wert.
IFC hat bereits ein Feld für fast alles, was eine Informationsbedarfstiefe fordert. Das Standardfeld zu nutzen, statt ein eigenes zu erfinden, ist schon der halbe Weg.
Die halbe Anforderung in einer Datei.
Die IDS trägt Zweck und Meilenstein im Kopf und fordert Daten aus dem IFC. Die Geometrie bleibt außen vor: Sie kann sie nicht fordern.
Was der Betreiber braucht.
Nach Bauende braucht es nicht die ganze Geometrie, sondern welche Anlagen es gibt, wo sie sind und wie man sie wartet. COBie ist diese Teilmenge.
Vier Fragen je Lieferung.
Vorhanden, mit Wert, mit gültigem Wert und mit der geforderten Form. Die ersten drei lassen sich automatisieren, die vierte nicht ganz.
Drei Türen, eine besteht.
Eine IDS fordert von jeder Tür den Feuerwiderstand im Format der europäischen Klassifizierung und ob sie außen liegt. Wir prüfen das an drei Testtüren.
Eine IDS, mehrere Prüfer.
Da IDS offen ist, können Liefernde und Empfangende mit verschiedenen Werkzeugen prüfen und kommen zum selben Ergebnis.
Die Form wird separat geprüft.
Noch prüft kein offener Standard, ob eine Geometrie den geforderten Detaillierungsgrad hat. Man kombiniert Regeln, Messung und eine Prüfung per Stichprobe.