Om dit te begrijpen, moet u weten dat we momenteel met twee algoritmen werken - één dat AutoCAD Architecture-modellen analyseert en één speciaal voor Revit-modellen. Beide worden actief onderhouden en ontwikkeld, waarbij het algoritme voor Revit het nieuwere, modernere algoritme is dat simpelweg meer kan. Dit maakt het bijvoorbeeld mogelijk om IFC-architecturen in gekoppelde modellen te analyseren, wat een voordelige scheiding van verantwoordelijkheden in BIM-processen mogelijk maakt. Deze optie wordt ook steeds vaker gevraagd door onze AutoCAD-klanten als vervanging voor het converteren van IFC naar AutoCAD Architecture-modellen. Omdat het betere de vijand is van het goede en er zelden iets is dat niet verbeterd kan worden, hebben we besloten om een nieuw algoritme te ontwikkelen dat de twee bestaande algoritmes vervangt en ons in staat stelt om alle vereiste scenario's te dekken. In dit artikel willen we graag onze gedachten erover met jullie delen, wat het verandert en wat het verbetert.
IFC-LINK VS. NATIVE ARCHITECTURE MODELLING
Je hebt waarschijnlijk in veel presentaties over open BIM en IFC gehoord dat IFC een transportformaat voor bouwmodellen is dat een groot aantal taken kan uitvoeren, behalve één: modellen zonder verlies overbrengen van het ene auteurssysteem naar het andere. Dit is vergelijkbaar met een PDF-document. Het is perfect om inhoud vast te houden, maar niet om een Microsoft Word-document netjes over te zetten naar LaTeX of Adobe Illustrator.
Als u nu probeert om een native Revit- of AutoCAD-architectuurmodel te maken vanuit een architectuurtoepassing, zoals ArchiCAD, via IFC, dan is dit slechts in zeer beperkte mate mogelijk vanwege de verschillende modelleeropties.
In het verleden hebben we deze manier gekozen tegen beter weten in om IFC modellen ook onder AutoCAD te kunnen analyseren. We hebben "echte" AutoCAD Architecture-wanden, -ramen en -deuren gegenereerd vanuit IFC-wanden, -ramen en -deuren. De nauwkeurigheid van de representatie kwam pas op de tweede plaats; het primaire doel was immers het bepalen van gebouwbelastingen. Een andere reden voor deze aanpak was de overheersende relatief goede kwaliteit van de in het veld bestaande IFC-bestanden. Na het importeren vertoonden sommige modellen zulke grote tekortkomingen dat ze handmatig gecorrigeerd moesten worden - en dat is alleen mogelijk als je een "echt" of native model genereert door te importeren.
Vanuit het perspectief van vandaag voldoen deze argumenten niet aan de eisen voor flexibiliteit en betrokkenheid van collaboratieve planningsprocessen. De deskundige MEP-planner kan en wil zich niet bezighouden met het aanpassen van verkeerd gemodelleerde/geëxporteerde gebouwen, vooral omdat, afhankelijk van het BIM-proces, frequente reconciliatie van modellen vereist is, wat zou leiden tot frequente correctieprocessen. Een ander knelpunt hier is de omkering van verantwoordelijkheden. Door het model te wijzigen, neemt de deskundige MEP-planner een taak op zich op een gebied waar eigenlijk alleen de architect bevoegd zou moeten zijn. Bovendien kan hij de resultaten van zijn werk nooit in het BIM-proces inbrengen. Ze gaan dus verloren. Tot slot, maar daarom niet minder belangrijk, brengt conversie naar native modellen altijd een extra interpretatiestap met zich mee. De geometrische correctheid van de componenten kan verloren gaan ten gunste van hun bewerkbaarheid.
Dit alles heeft ons al geholpen om in Revit de voorkeur te geven aan gekoppelde IFC-modellen boven geïmporteerde modellen, omdat geometrische correctheid belangrijker is voor de analyse van gebouwen dan de parametrische bewerkbaarheid van de modellen. In AutoCAD gaan we nu dezelfde kant op. In plaats van het model te "herscheppen" met muren, ramen en deuren, gebruiken we AutoCAD 3D-modellering om een exacte replica van het architectuurmodel te maken. Deze stap hebben we al gezet met versie 21 naast de bekende variant, maar nog zonder dit "exacte model" te kunnen analyseren. Tot nu toe dient het "slechts" als referentie voor verdere MEP-modellering van technische controlecentra, luchtkanaal- en leidingsystemen (zie Fig. 1).
Dit is waar onze volgende generatie van gebouwanalyse om de hoek komt kijken. Het nieuwe algoritme is onafhankelijk van het onderliggende gegevensmodel. Het kan voor alle modellen worden gebruikt zolang ze semantisch correcte oppervlakken in de driedimensionale ruimte leveren. Simpel gezegd hoeft het algoritme maar twee dingen te weten: waar is het oppervlak en wat is het oppervlak: Hoort het bij een muur, een raam, een vloer of een definitie van ruimte? Veel meer is er niet nodig!
ALLEEN NIEUWER OF OOK BETER?
Niet alles wat nieuw is, is per se beter. Ik weet zeker dat iedereen wel een paar voorbeelden kan bedenken. Als je eerlijk bent, is deze vraag soms niet eens zonder meer te beantwoorden. Nieuwe dingen kunnen voordelen hebben, maar ook nadelen. Het hangt er dus vanaf wat overheerst. Wij hebben de beslissing om een nieuw, uitgebreid algoritme te ontwikkelen niet zomaar genomen en hebben vooraf geprobeerd de voor- en nadelen te peilen. Om de beslissing op een begrijpelijke manier aan jullie te kunnen presenteren, moeten we toch kort het werkelijke verschil aangeven. Als we kijken naar een centraal probleem met de volgende vraag: "Welke muurstructuren en welke kamers bevinden zich achter dit muuroppervlak?", dan wordt deze vraag door de algoritmen op deze manier benaderd:
Terwijl onze vorige analyse selectief door muurvlakken kijkt om te zien wat er binnen en achter zit, controleert de nieuwe implementatie alle oppervlakken parallel aan de onderzochte muur (andere kamers, componentenlagen, ...) en bepaalt een set van mogelijk verschillende superstructuren door snijpunten te maken met al deze oppervlakken (zie Fig. 2).
Het nieuwe algoritme is dus betrouwbaarder in de analyse omdat er geen oppervlakken gemist kunnen worden en er geen verschil in de componentenstructuur onopgemerkt blijft. Deze methode is echter veel tijdrovender en "lijdt" meer onder bestaande maar mogelijk onnodige details. Naast een geschikte database zijn dus intelligente optimalisatiemechanismen nodig om te voorkomen dat acceptatie verloren gaat door lange analysetijden en kleinschalige resultaten.
Een ander voordeel van het nieuwe proces is de mogelijkheid om direct te werken met de ruimtedefinities die door de architect worden aangeleverd - ongeacht hun complexiteit. Het is dus niet nodig om ruimten te importeren of opnieuw te definiëren en, indien nodig, te leven met de nadelen of onnauwkeurigheden van de ruimtedefinities in het doelsysteem. Problemen met "niet perfect gesloten wandcontouren" en vergelijkbare kleine afwijkingen in het architectuurmodel behoren nu ook tot het verleden.
WAT ZIJN ONZE VEREISTEN VOOR GEBOUWMODELLEN?
De vereisten voor een te analyseren gebouwmodel zijn altijd hetzelfde, ongeacht of je werkt in de context van native modellering, d.w.z. "gesloten BIM", of het model ontvangt via het transportformaat, d.w.z. IFC.
Met IFC moet er nog één stap worden genomen om bij dit model te komen: de juiste instelling van de exportopties in de architectuursoftware. Laten we beginnen met de algemene vereisten voor een model:
- Het model moet gedefinieerde ruimtes hebben. Ruimtes zijn het uitgangspunt van elke analyse. Daarom is het noodzakelijk voor een algemene beschouwing dat alle gebouwgebieden "gevuld" zijn met ruimtes. In het beginstadium van de planning is het voldoende om grote gebieden of zones als "ruimtes" te definiëren. Een kleinschaligere beschouwing is alleen nodig als er echte ruimtebelastingen nodig zijn.
- In het model moeten grotere schachten als zodanig worden geïdentificeerd. Niet elke gleuf of verzonken spleet in een muur voor de afvoerpijp hoeft gemarkeerd te worden, maar de liftschacht of de grote schacht voor de luchtkanalen wel. Een van de redenen hiervoor is dat het gemakkelijker te detecteren is vanaf de "buitenkant": Als er geen andere kamer is en geen schacht achter een kameroppervlak, dan is het de "buitenkant". Dit kan leiden tot onjuiste metingen bij afwezigheid van gemarkeerde schachten. Een andere reden is natuurlijk de thermische overweging van deze ongeconditioneerde ruimtes. Het markeren van de schachten is een taak die meestal niet door de architect wordt gedaan. Daarom bieden we op elk platform tools waarmee je als professionele planner de definities kunt uitvoeren. Deze definities zijn zo ontworpen dat ze ook geldig blijven nadat het gebouwmodel is bijgewerkt. Ervan uitgaande dat de schacht nog steeds bestaat op ongeveer deze locatie.
- Een juiste indeling van de componenten is belangrijk voor de begrijpelijkheid en verwerkbaarheid van de analyseresultaten. Het is niet noodzakelijk dat een muur of een raam "echt" is, d.w.z. een eigen architectonische entiteit in het doelsysteem, het moet alleen op die plek worden gedefinieerd zodat de machine kan inlezen wat de componenten vertegenwoordigen. Dit komt doordat een glazen oppervlak in eerste instantie moeilijk te onderscheiden is van een betonnen oppervlak voor de gebouwanalyse. Het detecteert eenvoudigweg dat de "muurstructuur" op de plaats van het raam anders is dan de rest van de muur.
- Het grafische detail voor de analyse moet redelijk worden gekozen. Gemodelleerde dakpannen, afschuiningen op betonnen randen of valbeveiliging op buitenramen zijn voorbeelden van leuke details in het gebouwmodel, maar ze zijn niet erg bruikbaar voor de gebouwanalyse. Binnenafwerkingen, zoals plinten, schakelaars en stopcontacten, mogen ook niet worden meegenomen in de analyse. Kamergrenzen moeten niet elke muurnis en tegelvoeg weergeven, maar alleen zoveel individuele oppervlakken hebben als nodig is. Gemodelleerde deur- en raamklinken en kozijndetails hebben daarentegen geen invloed op de analyse omdat ze er niet voor gebruikt worden.
Naast deze algemene vereisten zijn er nog een paar andere dingen om rekening mee te houden bij het gebruik van IFC. Of je IFC 2x3 of IFC 4 gebruikt voor de export is van ondergeschikt belang. De formaatspecificaties die nodig zijn voor onze use case zijn allemaal al gedekt met IFC 2x3. De volgende aspecten zijn belangrijker:
- De juiste "MVD" (Model View Definition) moet worden gebruikt. De MVD definieert wat er in de IFC moet worden opgenomen en hoe het wordt beschreven. In het geval van IFC 2x3 is dat de "Coordination View" en in het geval van IFC 4 de "Reference View".
- Openingen (ramen/deuren) moeten worden gerefereerd via "openingen" in wanden.
- De grenzen van de ruimte moeten worden opgenomen. Het is belangrijk om de "grenzen van het eerste niveau" te exporteren, d.w.z. de eenvoudige ruimtelijke grenzen (zes vlakken in de eenvoudige rechthoekige ruimte).
- IFC4 kan ook "second level boundaries" transporteren - d.w.z. ruimtelijke grenzen die al verdeeld zijn tussen aangrenzende ruimtes. Dit wordt meestal zeer slecht geïmplementeerd door de auteursomgevingen, dus berekent ons algoritme deze informatie in elk geval onafhankelijk.
- Er moet worden gezorgd voor een correcte omzetting van de componenttypes naar de bijbehorende IFC-klassen. Zijn bijvoorbeeld ruimtedrempels geëxporteerd als IfcRelSpaceBoundary, muren als IfcWall en "gaten" voor ramen en deuren als IfcOpeningElement?
- De volgende grafische beschrijvingstypen (Representation Type) voor componenten en ruimten worden ondersteund: SolidModels (SweptSolid, Brep, CSG, Clipping) en SurfaceModel (Tesselation). Dit zijn de algemene types die kunnen worden gebruikt om alle essentiële zaken in kaart te brengen.
- Uitgelijnde projectcoördinaten. Minder belangrijk voor de initiële analyse, maar nog belangrijker voor coördinatietaken in het verdere verloop van het project. Stel ze in op een coördinatenstelsel. Dit betekent een "nulpunt" en een uitlijning van het gebouwmodel.
Met de gangbare professionele architectuurprogramma's is dit allemaal meestal mogelijk met "een druk op de knop", hoewel misschien niet bij de eerste poging. Er moet altijd een coördinatiefase worden ingepland waarin de verschillende exportopties worden uitgeprobeerd en vergeleken.
KUNNEN GEBOUWMODELLEN NOG MEER (NUTTIGE) GEGEVENS OPLEVEREN?
De geometrie van het gebouw en de topologie (aangrenzende kamers, schachten) zijn de belangrijkste gegevens om uit een bouwkundig gebouwmodel te halen. Daarnaast kan een model nog andere informatie bevatten - die ook toeneemt tijdens de planning - die direct kan worden opgenomen in de belastingsanalyses. Onder andere:
- materiaalinformatie. De exacte constructie van wanden, plafonds en daken kan direct in het model worden geleverd. Idealiter is de constructie al gemodelleerd. Dit betekent dat de afzonderlijke lagen van de componenten beschikbaar zijn met hun specifieke laagdiktes. Op deze manier kunnen zelfs moeilijke situaties zoals gedeeltelijke verkalking duidelijk worden geïdentificeerd.
- Terreingegevens. Van de eenvoudige invoer van een grondhoogte tot volledig gemodelleerde terreintopologieën, de informatie wordt gebruikt om de delen van het gebouw te bepalen die aan de buitenkant aan de grond grenzen.
- Doeltoestanden, d.w.z. gegevens zoals de met de gebouweigenaar overeengekomen doeltemperaturen voor verwarming en koeling, maar ook de vereiste airconditioning kunnen worden verankerd aan de zones of kamers van het model.
- Belastingen, zoals van personen, licht of machines, kunnen worden opgeslagen via specifieke gegevens of - afhankelijk van het platform - ruimteprofielen.
Als deze informatie niet in het model is opgeslagen, wordt deze op eenvoudige wijze in LINEAR Building vastgelegd. De op deze manier gedetecteerde gegevens blijven ook na updates van het gebouwmodel bestaan en hoeven niet steeds opnieuw te worden gedetecteerd.
Ze kunnen echter op elk moment worden aangevuld of overschreven door gegevens uit het model zodra dit laatste betrouwbare informatie oplevert.
GEBRUIKSCASES VANDAAG EN TOEKOMSTIG
Op het moment van publicatie van dit artikel is het nieuwe algoritme nog niet vrijgegeven voor productief gebruik. We moeten het nog productrijp maken met modellen uit de dagelijkse planning. Wie wil bijdragen - vooral met modellen uit echte projecten - wordt van harte uitgenodigd om contact met ons op te nemen via preview@~@linear.de.
De eerste use case zal de IFC-koppeling voor AutoCAD-gebruikers zijn. In de volgende stap schakelen we ook de bekende analyse van AutoCAD-architectuurmodellen over naar het nieuwe algoritme. Deze modellen blijven nog steeds de eerste keuze voor projecten die moeten worden uitgevoerd zonder (goede) 3D-modellen van de architect en waarbij de gespecialiseerde planner snel een eenvoudig rekenmodel maakt met behulp van de tools van de gebouwbeheerder.
In de laatste stap zijn we van plan om de nieuwe ideeën en mogelijkheden samen te voegen met de specifieke kenmerken van Revit-gebaseerde gebouwanalyse om te voldoen aan de hoogste kwaliteitsnormen op alle platforms.
Naast de voor de hand liggende voordelen van het nieuwe algoritme zelf, stelt het cross-platform gebruik ons in staat om verbeteringen en klantverzoeken voor alle gebruikers in één stap te implementeren en aan te bieden.
Javier Castell Codesal