Prüfen

Drei Prüfungen im Menüband „Prüfen“: gegen Anforderungen, gegen sich selbst, gegen die Vorgängerversion.

Alle drei Prüfungen schreiben ihre Funde in dieselbe Ablage — BCF. Damit landet ein Befund im selben Koordinations-Workflow wie eine Anmerkung aus einer Besprechung.

IDS-Prüfung — Modell gegen Anforderungen

Eine IDS (Information Delivery Specification, buildingSMART) beschreibt maschinenlesbar, was ein Modell mitbringen muss. Die Prüfung beantwortet: hält das gelieferte Modell diese Vorgabe ein?

Anforderungen holen

Zwei Wege, beide direkt im Prüf-Modus: „neoQ-IDS laden“ nimmt einen in neoQ gepflegten Katalog — „IDS-Datei laden (.ids)“ nimmt eine gelieferte Datei. Beide Quellen stehen gemischt in derselben Auswahlliste, die Herkunft steht davor.

Prüf-Modus öffnen

Prüfen → IDS → IDS-Prüfung. Links stehen ganz oben die drei Ausführen-Knöpfe, darunter die Schritte 1 · IDS, 2 · Modelle,3 · Regeln und die Prüfoptionen; unten das Ergebnis. Der Modus lässt sich jederzeit über den Chip in der Tab-Leiste beenden.

IDS und Modelle wählen

Die IDS aus Schritt 1 gilt als Vorgabe für alle Modelle. Sind mehrere geladen, bekommt jedes angehakte Modell in Schritt 2 eine eigene Auswahl — Trasse gegen den Trassen-Katalog, Brücke gegen den Brücken-Katalog. Eine leere Modellauswahl heißt leer, nicht „alle“. Nicht prüfbare Modelle sind durchgestrichen samt Grund.

Ausführen — drei Knöpfe

„Alles prüfen“ prüft IDS und aktive Regelsätze in einemLauf über dieselben Modelldaten. „IDS prüfen“ und „Regeln prüfen“ nehmen nur den einen Teil — wer gerade an einer Regel oder am Katalog arbeitet, sieht so nur den geänderten Teil. Dieselben Knöpfe stehen im Menüband (Prüfen → IDS bzw. Prüfen → Regeln). Welche Regelsätze mitlaufen, wird direkt in Schritt 3 angehakt; „Regeln bearbeiten“ führt in den Regel-Arbeitsbereich.

Lesen

Fortschritt und Abbruch stehen im Knopf-Block oben. Der Reiter Befunde ist der Einstieg: jede Ursache genau einmal, mit Klartext, betroffenem PropertySet, Anzahl und Anteil der Elemente, Klassenverteilung und den vorgefundenen Ist-Werten. Der Reiter Elemente zeigt den Einzelfall — eine Zeile je Element × Anforderung, gruppier- und filterbar, mit Excel-Kopieren.

Einen Befund prüfen

Ein Klick auf eine Zeile im Reiter Elemente fliegt das Objekt im 3D an und wählt es aus — das Eigenschaften-Fenster zeigt sofort seine Attribute und PropertySets, ohne dass man es im Modell suchen muss. Rechts steht die Befund-Karte mit Prüfkette (Soll/Ist je Station); die Pfeile ‹ › darin springen zum vorigen bzw. nächsten Befund der gefilterten Liste. Behebenlegt den Reparatur-Vorschlag in DataBuild ab — auch für Regelbefunde der Klasse A (Pflichtfeld, Wert aus Liste, Datentyp …), die dieselbe Reparatur brauchen wie ein IDS-Befund.

Eine Gruppe weitergeben (Gruppen-BCF)

Im Reiter Elemente lässt sich nach jeder Spalte gruppieren (Spaltenkopf in die Zone „Gruppieren“ ziehen, mehrstufig — etwa Klasse → Name). Jeder Gruppenkopf trägt dann zwei Knöpfe: Isolieren zeigt alle Elemente dieser Gruppe allein im 3D, BCF macht daraus ein Thema. Darin stecken alle GUIDs der Gruppe — so hinterlegt, dass das Werkzeug des Empfängers sie isoliert anzeigt. Die Beschreibung entsteht automatisch: Katalog und Prüfzeitpunkt, der Gruppenpfad als Titel, Anzahl Elemente und Befundzeilen, die Befunde als Häufigkeitsliste mit Soll und Ist, Spezifikationen, Klassen und die betroffenen Objekte mit GUID. Ein Element mit mehreren verletzten Anforderungen zählt als einElement; ein zweiter Klick auf dieselbe Gruppe legt kein zweites Thema an.

„Nur Geometrie“ geladene Modelle können nicht geprüft werden — sie tragen keine Eigenschaften und würden sonst grün melden, ohne geprüft worden zu sein. Die Prüfung weist sie deshalb ausdrücklich als nicht prüfbar aus.

Ein Befund, der (fast) alle betroffenen Objekte trifft, wird als systematischausgewiesen. Dann liegt die Ursache in Vorlage, Exporteinstellung oder Prozess — nicht am einzelnen Bauteil.

Fehler isolieren

Nur die durchgefallenen Bauteile sichtbar lassen.

Zurücksetzen

Ergebnis verwerfen, Einfärbung und Isolierung aufheben.

IDS-Lint

Prüft die Anforderungsdatei selbst auf Widersprüche und unerfüllbare Regeln — bevor ein Modell zu Unrecht durchfällt.

BCF

Themen für die Abstimmung — über Bericht je Spezifikation oder je Element, am Gruppenkopf der Elementliste für genau diese Gruppe. Export und Versionswahl (2.1/2.0/3.0) danach unter Prüfen → BCF.

Beheben

Macht aus einem Befund Reparatur-Vorschläge und legt sie in DataBuild → Reparatur zur Entscheidung. Jeder Vorschlag ist sichtbar, editierbar und abwählbar; das reparierte IFC entsteht erst beim Export.

Falscher Datentyp — „Nur Datentyp berichtigen“. Steht eine Eigenschaft im Modell als IfcText in der Datei, während die IDS IfcLabel fordert, ist inhaltlich alles richtig und nur der Datentyp falsch. Dafür hat jeder Eigenschafts-Vorschlag in DataBuild → Reparatureinen Schalter: Er schreibt allein den Datentyp und lässt den vorhandenen Wert je Element unangetastet — ein einzelner Wert im Wertfeld hätte die eigenen Werte aller betroffenen Elemente gleich überschrieben. Das Wertfeld ist dann gesperrt, und der Vorschlag ist ohne Wert anwendbar. Fehlt die Eigenschaft an einem Element wirklich, wird nichts angelegt: diese Elemente werden als übersprungen gemeldet, und der Vorschlag bleibt stehen. In der Datei steht die Berichtigung erst nach DataBuild → Export → IFC 4.3.

Meldet die Prüfung „Eigenschaft fehlt“, obwohl sie da ist? Jede Vorschlags-Karte nennt unter „Am Objekt vorhanden:“, was das Objekt in den zutreffenden Eigenschaftssets tatsächlich trägt. Fehlt der gesuchte Name dort, ist es ein Namensdreher oder das Nachbar-Set. Zu beachten: Die Prüfung wertet Eigenschaften am Bauteil und an seinem Typ aus — die Eigenschaften-Leiste des Viewers zeigt zusätzlich, was von übergeordneten Einheiten geerbt wird. Was dort sichtbar ist, muss am Bauteil selbst nicht hinterlegt sein.

Zweiter Lauf ohne Warten. Das Teure an einer Prüfung ist nicht das Prüfen, sondern das Lesen der IFC-Datei. Die gelesenen Modelldaten bleiben deshalb im Prüf-Worker liegen: Wer eine Regel nachschärft oder den Katalog ändert und erneut prüft, wartet nur noch auf die Auswertung. Die Zeile unter dem Gesamturteil sagt, wie lange Lesen und Prüfen gedauert haben und ob Modelle aus dem Zwischenspeicher kamen; mehrere Modelle werden gleichzeitig gelesen. Jede neu geladene oder geänderte Fassung eines Modells wird als neue Datei erkannt und neu gelesen — auch dann, wenn sie genauso groß ist wie die alte. Ein entladenes Modell verschwindet sofort aus dem Zwischenspeicher; im Zweifel „Zwischenspeicher leeren“.

Modelle ohne IDS und Regelsätze. Sind Regelsätze angehakt, prüft „Alles prüfen“ sie über alle ausgewählten Modelle — auch über ein Modell, dem keine IDS zugeordnet ist, und unabhängig davon, welcher Katalog den übrigen Modellen gilt. Die Regel „kein Bauteil ungeprüft“ sieht dabei, was jede IDS schon erfasst hat. Ohne Regelsatz bleibt ein Modell ohne IDS ungeprüft, und eine Meldung sagt das.

Abbrechen wirkt sofort, auch während die Modelldaten noch gelesen werden. Das Ergebnis ist dann als unvollständig gekennzeichnet; Meldung und Bericht nennen die Modelle, die nicht vollständig gelesen wurden. Stürzt die Prüfung im Hintergrund ab (etwa weil der Speicher nicht reicht), endet der Lauf mit einer Fehlermeldung statt hängen zu bleiben — der nächste Lauf startet frisch.

Ein neoQ-Katalog ist ein lebender Stand. Vor jedem Lauf wird er neu abgeleitet; hat er sich seit dem Laden geändert, sagt ein Hinweis das. Geprüft wird nie stillschweigend eine veraltete Momentaufnahme.

Läuft der optionale Python-Server, prüft dieser (IfcOpenShell) — eine Pille zeigt „Server“, sonst „lokal“ im Browser. Das erklärt, warum Ergebnisse je nach Serverzustand geringfügig abweichen können. Die Option „PropertySet strikt“ (voreingestellt an) verlangt die Eigenschaft im geforderten PropertySet — so schreibt es die Norm vor; ausgeschaltet ist die Prüfung nachsichtiger.

Prüfregeln — prüfen, wo eine IDS nicht zuschlägt

Eine IDS prüft nur dort, wo ihre Anwendbarkeit greift. Ist ein Bauteil falsch klassifiziert oder fehlt ihm genau die Eigenschaft, über die die Anwendbarkeit gebildet ist, meldet die Prüfung keinen Fehler, sondern gar nichts — das Bauteil gilt als „nicht anwendbar“, und das heißt nicht „in Ordnung“, sondern ungeprüft. Genau diese Lücke schließen eigene Regeln.

Regelsatz anlegen

Prüfen → Regeln öffnet den Arbeitsbereich. „Grundprüfung“legt eine Startvorlage an: Grundregeln je Bauteil (Name, GlobalId, Verankerung, PropertySet, keine Sammelklasse), der Blindfleck-Check „Kein Bauteil bleibt ungeprüft“, „Jede Spezifikation erfasst mindestens ein Bauteil“ und die Koordinatenprüfung.

Regel schreiben

Drei Zonen: Gilt für (IFC-Klassen, PredefinedTypes, Bedingungen), Prüft (Regelart und ihr Feld) und Befund (Schweregrad, Hinweis). Unten steht die Regel als ganzer Satz — was dort steht, wird geprüft. Neben „Gilt für“ zeigt eine Zahl, wie viele Bauteile die Anwendbarkeit trifft; trifft sie keines, warnt der Editor.

Ausführen

Prüfen → Ausführen. Ein aktiver Regelsatz genügt — es muss keine IDS geladen sein. Sind beide da, laufen sie im selben Lauf und stehen in einem Ergebnis.

Jedes Feld schlägt die möglichen Werte vor, mit Angabe der Herkunft: im Modell (kommt in den geladenen Dateien tatsächlich vor), neoQ (vom Projekt verlangt) oder IFC-Schema (von der Norm erlaubt). Frei eintippen bleibt möglich — man prüft ja gerade auf Werte, die noch fehlen, und die stehen in keinem Modell.

Regeln sind keine Lieferanforderungen. Was geliefert werden MUSS, gehört nach neoQ; eine Regel behauptet etwas über das, was geliefert WURDE. Der Editor weist darauf hin, wenn eine Regel in Wahrheit eine Anforderung ist, und bietet die Übernahme nach neoQ an.

Kollisionsprüfung

Prüfen → Kollision öffnet den Kollisions-Modus mit Panels um den geteilten Viewport. Geprüft werden Volumen-Durchdringung, Punkt-in-Volumen und Abstand (Delta).

Prüfungen anlegen

Links die Prüfungsliste. Eine Prüfung verbindet zwei Selektionsgruppen(A × B). Das Dropdown „Matrix erzeugen“ baut viele Prüfungen auf einmal — nach IFC-Disziplinen, nach Attribut, nach Eigenschaft, nach SmartViews oder schnell Modell A × Modell B. Jeder Dialog bietet eine Modell-Auswahl, damit die Matrix nicht über das ganze Projekt aufgeht.

Toleranzen setzen

Prüfen → Einstellungen: Mindest-Überlagerung, Volumentoleranz (Liter) und Volumenanteil samt Bezugsbauteil. „Speichern“ gilt für neue Prüfungen, „Auf alle Prüfungen anwenden" überträgt sie auf bestehende. Dort liegen auch die Vorlagen für automatisch erzeugte BCF-Themen (Titel, Beschreibung, Typ, Status, Priorität, Zuständigkeit, Screenshot-Anzahl) mit Platzhaltern wie {checkName}, {severity}oder {nameA}.

Ausführen und navigieren

Im Menüband stehen Ausführen/Abbrechen, die Status-Schnellschalter, die Trefferwanderung ◀ i/n ▶ und die Zusammenfassung nach Schwere (gesamt / kritisch / mittel / gering / neu). Der 3D-Fokus färbt Bauteil A rot und B grün. Die Ergebnisleiste unten zeigt die Treffer als Liste, Matrix und Detail.

Befunde festhalten

Export als BCF (je Treffer oder als Sammelthema je Regel), als XLSX oder als HTML. Je Treffer lassen sich Status, Zuständigkeit und Kommentar setzen, ein Schnitt an der Fundstelle legen und das Durchdringungsvolumen exakt nachrechnen.

Kollisionen innerhalb EINES Modells finden: Die Schnellmatrix „Modelle A × B" prüft normalerweise nur Modell gegen Modell. Dasselbe Modell in A und B zu kreuzen genügt daher nicht — dafür gibt es im Dialog das Häkchen „Auch innerhalb eines Modells prüfen (Diagonale)". Es legt je Modell, das auf beiden Seiten steht, eine Prüfung mit Vergleich „A ↔ A“ an; sie erscheint als Diagonalzelle der Matrix. Denselben Effekt erhält man von Hand über „+“in der Prüfungsliste: Vergleich auf „A ↔ A“ stellen und„Gleiches Modell“ angehakt lassen. Alternativ die Matrix nach IFC-Disziplinen (oder Attribut/Eigenschaft) mit nur diesem einen Modell im Scope erzeugen — dann wird Disziplin gegen Disziplin innerhalb der Datei geprüft.

Der Kollisions-Modus wird über den roten Chip „Kollision“ rechts in der Tab-Leiste geschlossen — nicht über das Menüband. Ein Wechsel auf „Eigenschaften“ in der Detailleiste beendet ihn nicht; zurück geht es über den Reiter KCC.

Versionsvergleich

Im Kontextmenü eines Modells in der Projektstruktur: „Neue Version laden…". Danach fragt die App: „Ersetzen & vergleichen" oder „Nur ersetzen"(ohne Bericht). Beim Vergleich werden beide Stände werden über die GlobalIdverglichen — hinzugefügt, entfernt, geändert (Attribute, Eigenschaften, Bounding-Box).

Tab

Der Tab „IFC Versionsvergleich“ listet die Unterschiede mit Filter und Gruppierung.

Overlay

Im 3D: neu = grün, geändert = gelb, entfernt = rot (als durchscheinendes Geistermesh, weil es in der neuen Datei nicht mehr existiert).

Bericht

HTML-Bericht mit vollständigen Eigenschaftsnamen und Alt/Neu-Gegenüberstellung; das Ergebnis wird zusätzlich als BCF-Themen festgehalten und reist damit im Projekt mit.

Technische Details: docs/ids-pruefung.md, docs/collision.md