HET ONDERZOEK / ONZE INTERPRETATIE
buildingSMART beschrijft IDS als een specificatie voor het controleren van alfanumerieke IFC-informatie, zonder geometrische controles. Dat onderscheid is belangrijk bij tools die algemeen als BIM-checker worden gepresenteerd.
Drie vragen vragen om verschillende controles
Heeft elk relevant object een materiaalcode? Dat is een informatie-eis. Voldoet de vrije breedte tussen twee gemeten vlakken aan de afgesproken projectgrens? Dat is een geometrische test. Past de uitstraling van de ontvangst bij de klant? Dat is een ontwerpbeoordeling. Alles onder ‘AI-validatie’ scharen verhult verantwoordelijkheid en de betekenis van een positief resultaat. Leg per eis invoer, methode en verwachte onderbouwing vast.
- 01Goedgekeurde eis
- 02Uitvoerbare regel
- 03Modelbewijs
- 04Besluit van de beoordelaar
Illustratieve controleketen. Maak altijd onderscheid tussen ‘niet getest’ en ‘goedgekeurd’.
Een deurbreedtecontrole begint bij de meetdefinitie
Neem als illustratieve projecteis voor deur D-02 een vrije doorgang van minimaal 900 mm. Dit is een aangeleverde projectgrenswaarde, geen uitspraak over wettelijke eisen. Een eigenschap met de naam Width kan het deurblad, een opening of een familieparameter beschrijven; alleen de naam bewijst geen vrije doorgang. De regel vraagt daarom een afgesproken meetdefinitie en twee geïdentificeerde begrenzingsvlakken bij een vastgelegde deurstand. Als die vlakken niet betrouwbaar uit het model te halen zijn, luidt het resultaat niet getest. In de tekening op deze pagina is de voorbeeldmeting 870 mm: een tekort van 30 mm. Model- en objectidentificatie, coördinatentransformatie, eenhedenconversie en regelrevisie horen bij dat resultaat. Zonder die gegevens is een getal lastig te reproduceren of te betwisten.
Begin met één model en expliciete regels
Kies voor een illustratieve interieurpilot één modelrevisie en enkele regels: verplichte objectnamen, ingevulde materiaalreferenties en een maatcontrole op basis van aangeleverde projecteisen. Stel in SketchUp, Revit, Fusion of een IFC-uitwisseling eerst vast welke eigenschappen en geometrie de interface werkelijk beschikbaar maakt. Een ontbrekende waarde is niet nul. Een niet-ondersteund object is niet goedgekeurd. Beide moeten als onopgelost in de resultaten staan.
Scheid extractie, toetsing en toelichting
Een onderhoudbare checker scheidt drie functies. De modeladapter haalt geometrie en eigenschappen op zonder over naleving te beslissen. De evaluator past goedgekeurde regels toe op genormaliseerde gegevens. De rapportagelaag presenteert het bewijs en kan AI gebruiken voor toelichting. Zo kan bij een wijziging van de ontwerptool de adapter worden vervangen zonder de betekenis van de regel te herschrijven. Een record in een Python-pilot kan model_revision, object_id, rule_id, measured_mm, required_mm en extraction_status bevatten. De evaluator classificeert ontbrekende, niet-eindige of niet-ondersteunde invoer eerst als niet getest en vergelijkt daarna geldige waarden. Hij mag een te kleine meting niet stilzwijgend naar boven afronden. Een eventuele tolerantie hoort in de afgesproken regeldefinitie en het rapport. Een assistent kan code voorstellen; beoordeling van de meetmethode en tests blijft een aparte technische taak.
| Invoersituatie | Gemeten / vereist | Verwacht resultaat |
|---|---|---|
| Geldige extractie | 920 / 900 mm | PASS |
| Geldige extractie | 870 / 900 mm | FAIL |
| Begrenzingsvlak ontbreekt | — / 900 mm | NOT TESTED |
| Eenheid onduidelijk | 0.87 / 900 | NOT TESTED |
900 mm is de voorbeeldprojecteis, geen wettelijke uitspraak. De meting hangt af van de afgesproken geometrische definitie.
Gebruik code voor metingen en AI voor toelichting
Een Python-routine kan een vastgelegde voorwaarde toetsen en object-ID, gemeten waarde, eenheid en regelversie teruggeven. Een assistent kan controles uit een briefing voorstellen of uitzonderingen toelichten, maar een beoordelaar moet de vertaling naar regels goedkeuren. Houd testresultaat en toelichting gescheiden. Schrijft de assistent ‘acceptabel’ terwijl de meting niet voldoet, dan blijft het negatieve resultaat zichtbaar in het rapport.
Test de fouten die een geslaagde demonstratie verbergt
De testset bevat een voldoende brede opening, een bewust te smalle opening, een ontbrekend object, een niet-ondersteund deurtype en een eenhedenfout. Voeg een gespiegelde of getransformeerde instantie toe als de adapter die zegt te ondersteunen. Verandert het resultaat wanneer dezelfde geometrie in wereldcoördinaten wordt verplaatst, dan wijst dat op een transformatiefout. Wordt 0,87 gelezen als millimeters in plaats van meters, dan is dat een eenhedenfout. Een leeg model dat nul fouten meldt zonder nul dekking te vermelden, toont een rapportagefout. Deze gebreken vragen verschillende verwachte uitkomsten. De bruikbare samenvatting is daarom “18 van 22 toepasselijke objecten getoetst; 2 voldoen niet; 4 niet getest”, en niet alleen “2 problemen”. Dekking, uitsluitingen en onopgeloste extractie blijven zichtbaar, ook in een verkorte toelichting.
Gebruik het rapport als hulpmiddel bij beoordeling
Toon geslaagde, afgekeurde en niet-uitgevoerde controles. Geef een directe verwijzing naar het object of de relevante weergave, plus modelrevisie en uitvoeringstijd. Test met een bewust fout model en ontbrekende gegevens. Alleen een schoon voorbeeld goedkeuren bewijst geen bruikbare foutdetectie. De pilot moet betrouwbaar en uitlegbaar problemen signaleren met beheersbare beoordelingstijd. Dat is geen automatische ontwerpgoedkeuring of bewijs van wettelijke conformiteit.
Verbind het resultaat met de correctieronde van de ontwerper
Een rapport is het bruikbaarst wanneer elke bevinding een reproduceerbaar aanzicht opent of een herkenbaar object selecteert in de ontwerpomgeving. Alleen een screenshot veroudert na een modelwijziging. De beoordelaar heeft de revisie, de getoetste voorwaarde en een route naar de brongeometrie nodig. Geaccepteerde uitzonderingen worden vastgelegd bij een regel en revisie, met reden en verantwoordelijke; ze wissen de oorspronkelijke afwijking niet. Een gewijzigd model activeert vervolgens opnieuw de relevante controles. Voor een eerste integratie kan een betrouwbare export- en reviewcyclus voldoende zijn, zonder live plug-in. Native integratie, IFC-uitwisseling en bestandsverwerking hebben verschillende onderhoudskosten. De keuze hangt af van de werkelijke modellen en toegangsrechten van het bureau. Dat wordt vastgesteld in een technische pilot, niet afgeleid uit de merknaam van de software.