Building Information Modeling: Onderzoek naar het gebruik van IFCen MVD-modellen voor een studiebureau technieken

FACULTEIT INDUSTRIELE INGENIEURSWETENSCHAPPEN CAMPUS GENT

Building Information Modeling: Onderzoek naar het gebruik van IFCen MVD-modellen voor een studiebureau technieken

Dieter ROSSAERT

Promotor: Dr. ir. Ralf Klein

Masterproef ingediend tot het behalen van de graad van master of Science in de industriële wetenschappen: Bouwkunde

Co-promotor: Wim Tas

Academiejaar 2013-2014

© Copyright KU Leuven Zonder voorafgaande schriftelijke toestemming van zowel de promotor(en) als de auteur(s) is overnemen, kopiëren, gebruiken of realiseren van deze uitgave of gedeelten ervan verboden. Voor aanvragen tot of informatie i.v.m. het overnemen en/of gebruik en/of realisatie van gedeelten uit deze publicatie, wend u tot KU Leuven campus Gent, Gebroeders De Smetstraat 1, B-9000 Gent, +32 9 265 86 10 of via e-mail [email protected]. Voorafgaande schriftelijke toestemming van de promotor(en) is eveneens vereist voor het aanwenden van de in deze masterproef beschreven (originele) methoden, producten, schakelingen en programma’s voor industrieel of commercieel nut en voor de inzending van deze publicatie ter deelname aan wetenschappelijke prijzen of wedstrijden.

Voorwoord Het schrijven van dit eindwerk is een zeer leerrijke en interessante ervaring geweest. Het BIMconcept was voor mij volledig nieuw, maar ik ben de uitdaging aangegaan. Met behulp van dit eindwerk ben ik er in geslaagd om een duidelijk beeld te krijgen over BIM, meer bepaald over het gebruik van IFC-modellen. Ik ben er van overtuigd dat BIM, niet alleen voor mij, maar voor de volledige bouwsector verschillende opportuniteiten kan en zal bieden. Na deze thesis kan ik een punt zetten achter mijn studie Industrieel Ingenieur Bouwkunde. De realisatie van dit eindwerk heb ik te danken aan verschillende mensen. Zonder de hulp van deze mensen zou ik dit niet kunnen verwezenlijkt hebben. Via deze weg wens ik ze dan ook oprecht te bedanken. Oprechte dank aan mijn promotor, dr. ir. Ralf Klein, die mij de nodige richtlijnen, hulp en tijd heeft aangeboden bij het schrijven van mijn thesis. Ik ben hem dankbaar voor de vrijheid die hij mij schonk en het vertrouwen dat hij in mij had. In het bijzondere ben ik Wim Tas, zaakvoerder van Witas Ingenieursbureau bvba., zeer dankbaar. Wim heeft mij de mogelijkheid gegeven om stage te kunnen lopen bij Witas en op die manier een basis te creëren voor mijn eindwerk. Bij Wim en zijn collega’s kon ik steeds terecht met vragen of problemen. Dank voor het vertrouwen en de tijd die jullie in mijn thesis hebben gestoken. Tenslotte zou ik ook nog graag mijn familie, vrienden en vriendin willen bedanken voor hun steun en begrip. In het bijzonder Iris Rossaert en Jolien Kokx voor het verbeteren en nalezen van mijn eindwerk.

2

Abstract In dit eindwerk wordt aangehaald hoe men met behulp van BIM en het gebruik van IFC- en MVD-modellen bepaalde informatie-uitwisselingen tussen verschillende disciplines in de bouwsector kan optimaliseren. Er wordt gekeken naar de mogelijkheden die het softwareonafhankelijk bestandsformaat kan bieden in de huidige bouwsector. Er wordt nagegaan hoe zulke modellen kunnen gebruikt worden in de loop van de verschillende bouwfasen, welke participanten er in mee spelen en wat hun specifieke rollen daarin zijn. Verder zullen we nagaan welke aspecten er allemaal komen kijken bij het realiseren en ontwerpen van een procesafhankelijk MVD-model. In deze thesis werd getracht een goede basis te beschrijven voor eventueel verder onderzoek omtrent het gebruik van IFC.

3

Extended abstract

Building Information Modeling: Onderzoek naar het gebruik van IFC- en MVD-modellen voor een studiebureau technieken Dieter Rossaert Promotor: dr. ir. Ralf Klein I.

INLEIDING

Building Information Modeling (BIM) is een groeiende werkmethodiek in de huidige bouwwereld. Bij het ontwerpen van een project met behulp van BIM, staat een intelligent 3D-model centraal, alle relevante informatie is gekoppeld aan datzelfde model. Door gebruik te maken van BIM kan de samenwerking tussen de verschillende bouwpartners geoptimaliseerd worden. Aangezien men samenwerkt met een gedeeld model zorgt dit ervoor dat de verschillende participanten dichter bij elkaar komen te staan, wat bevorderend is voor de onderlinge communicatie. Aangezien men op een efficiëntere en flexibelere manier informatie kan achterhalen, gebruiken en toevoegen, worden er minder misvattingen en fouten gemaakt. Zo kan men op een zeer rendabele manier werken tijdens de volledige bouwcyclus van een project. Met behulp van Industry Foundation Classes (IFC) kan men het BIM-gebeuren nog beter bijsturen. IFC is een platformonafhankelijk bestandsformaat voor 3Dmodellen. Dit maakt het mogelijk om eenzelfde model tussen verschillende softwarepakketten van verschillende softwareontwikkelaars onderling uit te wisselen.IFC zorgt ervoor dat de verschillende bouwpartijen en hun gebruikte softwarepakketten dichter bij elkaar staan [1].

van IFC-modellen, meer bepaald Model View Definitions. Men zal nagaan waarom deze modellen worden gecreëerd en hoe deze interoperabiliteit een meerwaarde kan bieden voor de werkprocessen van een studiebureau technieken, meer bepaald: het ontwerp van een ventilatiesysteem. BuildingSMART is grondlegger van deze uitwisselingsstandaard en voorziet verschillende verduidelijkende richtlijnen die de basis vormen van dit onderzoek [2-3]. III.

METHODIEK

In dit onderzoek wordt duidelijk gemaakt hoe een IFC-model een praktische meerwaarde kan geven aan werkprocessen binnenin een studiebureau technieken. Door gebruik te maken van een Model View Definition (MVD) kan men een model gaan specificeren naar gelang het uit te voeren werkproces. De MVD zorgt ervoor dat de betrokken partij de nodige informatie uit het 3D-model ontvangt om hun opgelegde taken te kunnen uitvoeren. A. Information Delivery Manual De Information Delivery Manual (IDM) is een ontwikkelde standaard die helpt bij de verduidelijking en omkadering van bouwprocessen. Door gebruik te maken van deze standaard kan men een eenduidig beeld creëren van de verschillende bouwpartners en hun specifieke rol binnen de verschillende bouwfases. Zo kan men ook een beschrijving geven van de bedrijfsprocessen en het gebruik van de IFC-modellen. B. Model View Definitions

Figuur 1: Interactiemodel van de verschillende bouwpartners. Link het: traditioneelproces en recht het BIM-proces [4]

II.

DOEL

Met behulp van dit eindwerk is het de bedoeling om een duidelijk beeld te kunnen scheppen over het gebruik

De IDM-methodologie is bedoelt als basis voor de MVD. Een MVD zorgt er uiteindelijk voor dat het totale IFC-model wordt uitgefilterd naar de behoeften van de vragende partij. Met behulp van de gedefinieerde uitwisselingsbehoeftes (Exchange Requirements) en betrokken partijen uit de IDM, kan men een MVD gaan creëren. Door gebruik te maken van een MVD kan men informatie ontvangen die doelgericht en efficiënt kan gebruikt worden. De uitvoerende instanties hebben echter enkel informatie nodig die ze kunnen gebruiken voor verdere verwerking. Informatie die niet nuttig is, wordt gezien als onnodig en worden door de MVD overboord gegooid.

4

Oprechte dank voor mijn promotor dr. ir. Ralf Klein, waarbij ik steeds terecht kon komen met opmerkingen of vragen. REFERENTIES

Figuur 2: Verband tussen gebruikerseisen en hun oplossingen [4]

IV.

[1]

“Industry Foundation Classes (IFC) data model — buildingSMART.” [Online]. Available: http://www.buildingsmart.org/standards/ifc. [Accessed: 11-Aug-2014].

[2]

“buildingSMART.” [Online]. Available: http://www.buildingsmart.org/. [Accessed: 09Aug-2014].

[3]

“buildingSMART-Tech.” [Online]. Available: http://www.buildingsmart-tech.org/. [Accessed: 14-Jul-2014].

[4]

“Information Delivery Manual Guide Components and Development Methods.”

ARCHITECTURAAL ONTWERP NAAR STUDIEBUREAU TECHNIEKEN

Een studiebureau technieken wordt opgesteld voor het ontwerpen en dimensioneren van verschillende technieken in een gebouw. Het is een feit dat dit ontwerp pas gerealiseerd wordt na verschillende interacties tussen o.a. de bouwheer, architect, aannemer en het betreffende studiebureau. Indien men deze interactie wil bijschaven door gebruik te maken van een BIM-model, zal dit voornamelijk gebeuren tijdens de wisselwerking van de architect en het studiebureau. Aannemers en bouwheren zullen echter minder snel instaat zijn om gebruik te maken van zulke modellen. Het betreffende onderzoek focust zich dus vooral naar de informatie uitwisseling tussen de architect en het studiebureau. Stel dat men een studiebureau technieken aanstelt om een ventilatiesysteem te ontwerpen gebruik makend van een IFC/BIM-model, zal de architect de nodige gegevens moeten kunnen voorleggen aan het studiebureau zodanig dat hij zijn desbetreffende berekeningen kan uitvoeren. Door gebruik te maken van een specifieke MVD, zal het door de architect ontworpen gebouwenmodel uitgefilterd worden naargelang de gegevenseisen van het studiebureau. Aan de hand van het IDM-protocol kan men deze bedrijfsprocessen en uitwisselingsgegevens (Exchange Requirements) beschrijven en definiëren, om zo later de MVD te ontwikkelen en te implementeren in specifieke software. Dit geheel zorgt er voor dat het studiebureau zijn werk met behulp van een BIM-model, vlot en efficiënt kan uitvoeren. DANKWOORD Via deze weg zou ik graag iedereen bedanken die mij heeft bijgestaan tijdens de realisatie van deze thesis. Als eerste wil ik mijn stageplaats ‘Witas Ingenieursbureau bvba’ willen bedanken voor de mogelijkheid die zij mij gaven om dit onderzoek uit te voeren. In het bijzonder wil ik zaakvoerder ‘Wim Tas' bedanken voor de aangename en interessante hulp die hij mij heeft aangeboden.

to

5

Inhoudsopgave

Voorwoord ................................................................................................................................ 1 Abstract ..................................................................................................................................... 2 Extended abstract ..................................................................................................................... 3 Inhoudsopgave .......................................................................................................................... 5 Illustratielijst............................................................................................................................. 7 Tabellenlijst............................................................................................................................... 7 1

Building Information Modeling ...................................................................................... 8 1.1

Inleiding ....................................................................................................................... 8

1.2

Collaboratie van bouwpartners .................................................................................... 9

1.3

Voordelen BIM .......................................................................................................... 10

1.4

Traditionele werkmethodiek ...................................................................................... 10

2

BuildingSMART ............................................................................................................. 13

3

Industry Foundation Classes ......................................................................................... 15

4

5

3.1

IFC 2x3 ...................................................................................................................... 15

3.2

IFC Schema Representations ..................................................................................... 17

Information Delivery Manual ....................................................................................... 21 4.1

IDM visie ................................................................................................................... 23

4.2

IDM doel.................................................................................................................... 23

4.2.1

Bouwfasen .......................................................................................................... 23

4.2.2

Actoren ............................................................................................................... 26

Model View Definitions .................................................................................................. 28 5.1

6

Soorten MVD’s.......................................................................................................... 29

5.1.1

Coordination View Version 2.0 ......................................................................... 29

5.1.2

ThermalSimulation ............................................................................................. 29

5.1.3

Hand-Over to Facility Management ................................................................... 30

Het ontstaan van een MVD ........................................................................................... 31 6.1

Voorbereidend werk .................................................................................................. 31

6.2

IDM-methodologie .................................................................................................... 32

6.2.1

Identificeren processen en actoren ..................................................................... 32

6.2.2

Identificeren uitwisselingprocedures .................................................................. 32

6.2.3

Creatie van de Exchange Requirements ............................................................. 32

6.3

MVD-methodologie................................................................................................... 33

6.3.1

Uitbreiden naar Exchange Requirements Models .............................................. 33

6

6.3.2 6.4 7

Creatie van de uiteindelijke MVD ..................................................................... 34

Implementatie en gebruik .......................................................................................... 34

De rol van het studiebureau .......................................................................................... 35 Bedrijfsprocessen van een studiebureau technieken ................................................. 36

7.2

Het studiebureau en hun participanten ...................................................................... 37

7.3

Optimalisatie m.b.v. een MVD-model ...................................................................... 37

8

7.1

MVD architecturaal ontwerp naar ventilatie .............................................................. 39 8.1

Process Model............................................................................................................ 39

8.1.1

Overview ............................................................................................................ 40

8.1.2

Process Diagram ................................................................................................. 42

8.1.3

Specification of Proces ....................................................................................... 43

8.1.4

Specification of Data Objects ............................................................................ 47

8.1.5

Specification Of Exchange Requirements .......................................................... 50

8.1.6

Specification of Decision Gateways.................................................................. 51

Exchange Requirements ............................................................................................ 52

8.3

Exchange Requirements Model ................................................................................. 54

8.4

MVD Diagrams ......................................................................................................... 57

9

8.2

Enkele aandachtspunten ................................................................................................ 59 Gebouwtype ............................................................................................................... 59

9.2

Deelprocessen ............................................................................................................ 59

9.3

MVD ventilatie in kaart gebracht .............................................................................. 62

10

9.1

Besluit .............................................................................................................................. 63

Literatuurlijst ......................................................................................................................... 64 Bijlage I: Gebruikte software ................................................................................................ 67 Bijlage II: Handleiding IFC Export in Revit 2014 .............................................................. 68 IFC Mapping File ................................................................................................................. 69 Toevoegen van Shared Parameters: IfcExportAs en IfcExportType ................................... 70 Bijlage III: Voorbeeld IFC-export vanuit Revit: ventilatiesysteem .................................. 73 Vergelijking luchtkanaal ...................................................................................................... 74 Vergelijking luchtgroep ........................................................................................................ 78 IFC Entiteiten voor families ................................................................................................. 78 Bijlage IV: Opbouw van een IFC-model .............................................................................. 80

7

Figurenlijst Figuur 1: Interactiemodel van de verschillende bouwpartners. Links het traditioneelproces rechts het BIM-proces ............................................................................................................... 3 Figuur 2: Verband tussen gebruikerseisen en hun oplossingen ................................................ 4 Figuur 3: Vergelijking traditioneel- en BIM ontwerpproces .................................................. 11 Figuur 4: Interactiemodel tussen de verschillende participanten. Links het traditioneel model, rechts het gedeeld BIM-model ................................................................................................ 12 Figuur 5: Logo van BuildingSMART ...................................................................................... 13 Figuur 6: Schematische weergave van BuildingSMART’s standaarden ................................ 14 Figuur 7: Grafische weergave EXPRESS datamodel (EXPRESS-G) .................................... 16 Figuur 8: IFC-tekstbestand ....................................................................................................... 17 Figuur 9: Voorbeeld van mogelijke eigenschappen voor het ventilatieroosterobject ............. 18 Figuur 10: Voorbeeld van een grafische weergave van klassen en hun attributen .................. 18 Figuur 11: Basis 2X3 IFC Schema ........................................................................................... 19 Figuur12: Links: IFC behandelt alle elementen over alle projectfasen. Rechts: IDM behandelt specifieke elementen in een bepaalde projectfase ................................................................... 22 Figuur 13:Verband tussen gebruikerseisen en hun oplossingen ............................................. 22 Figuur 14: De levenscyclus van een bouwproject bestaande uit verschillende fasen ............. 24 Figuur 15: Actoren en hun rollen ............................................................................................ 26 Figuur 16: Uniclass classificatie ............................................................................................. 27 Figuur 17: Ontwikkelingsdiagram MVD ................................................................................. 28 Figuur 18: Schematische voorstelling van de ThermalSimulation MVD ................................ 29 Figuur 19: Overview van de Hand-over to Facility Management MVD ................................. 30 Figuur 20: HESMOS Workflow grafiek .................................................................................. 31 Figuur 21: Ventilatieontwerp in het globale bouwproces (grijs) ............................................. 38 Figuur 22: Scoop MVD ............................................................................................................ 40 Figuur 23: Proces Diagram ...................................................................................................... 42 Figuur 24: Basisopbouw ERM Diagrams ................................................................................ 54 Figuur 25: Variable Concept Wall van de Architectural Design to Building Energy Analysis MVD......................................................................................................................................... 55 Figuur 26:Variable Concept Wall van de Architectural Design to Circulation/Security Analysis MVD.......................................................................................................................... 55 Figuur 27: Relatie tussen ERM en MVD Diagrams ................................................................ 56 Figuur 28: Basisopbouw MVD Diagrams ................................................................................ 57 Figuur 29: Voorbeeld HVAC MVD Diagram uit de Concept design to building energy Analysis MVD.......................................................................................................................... 57 Figuur 30:Instantiation Diagram en implementatieafspraken .................................................. 58 Figuur 31: Taakbeschrijving dimensioneren fase 1 ................................................................. 60 Figuur 32: Taakbeschrijving dimensioneren fase 2 ................................................................. 61

Tabellenlijst Tabel 1: Vergelijking van IDM-standaardfasen met de meest gebruikelijke Belgische bouwfasen................................................................................................................................. 26 Tabel 2: Illustratie van het toekennen van IFC-klassen ........................................................... 33 Tabel 3: De rol van de bouwpartners in de verschillende bouwfasen ...................................... 35

8

1 Building Information Modeling 1.1 Inleiding Bij de start van deze opleiding stond ik er nog niet bij stil hoeveel er komt kijken bij het realiseren van een bouwproject. De meesten zullen eerst denken aan de verschillende taken die moeten vervuld worden om zo’n project te kunnen volbrengen, alsook aan de beroepen en functies die nodig zijn om dit te realiseren. Hierbij spelen bijvoorbeeld de architect, aannemer, arbeiders en ingenieurs een cruciale rol. Uiteraard heeft iedereen, volgens zijn of haar opleiding, een bepaalde taak in het realiseren van een bouwproject. Echter, zonder een transparante en verstaanbare communicatie tussen de verscheidene partijen, is het onmogelijk om projecten tot een goed einde te brengen. Zo kan het voorvallen dat een stabiliteitsingenieur een balk dimensioneert en vervolgens concludeert dat de afmetingen niet overeenkomen met de eisen van de architect. De architect en het stabiliteitsbureau moeten dit probleem dan samen oplossen. Ook bij deze stap is communicatie een bepalende factor. Het is dus duidelijk een must dat deze partijen goed met elkaar moeten kunnen samenwerken om het proces vlekkeloos te doorlopen en de kans op extra faalkosten zo laag mogelijk te houden of te elimineren. In de praktijk zien we dat dit vaak minder vlot verloopt dan we hopen of verwachten. Om de samenwerking tussen de verschillende partijen te vereenvoudigen is er BIM: Building Information Modeling. Via BIM is het mogelijk om alle relevante informatie gedurende het hele bouwproces op te slaan in de vorm van een 3D-model. Het model kan dan tussen de verschillende partijen onderling uitgewisseld worden. Dit resulteert in een digitaal, object georiënteerd 3D-model waarbij alle partijen die betrokken zijn in het bouwproces, met hetzelfde model werken. In de volgende paragraaf volgt een korte verduidelijking van het begrip ‘BIM’. Via BIM is het mogelijk een digitaal gebouw te creëren. Aan de verschillende gebouwelementen in het gebouw kan, ter verduidelijking, allerhande informatie gekoppeld worden. Op die manier bekomt men een grote databank aan informatie. Zo hebben we in een standaard woning vaak verschillende ramen, deuren, trappen, stopcontacten, verlichting etc. Aan al deze elementen wordt dus in het model informatie geïmplementeerd. Via het model wordt bijvoorbeeld duidelijk wat voor type ramen er gebruikt worden, wat de dimensies zijn van de gebruikte luchtkanalen, uit welk materiaal deuren bestaan), wie de fabrikant is, wat de oppervlakten en/of functies van bepaalde ruimten zijn etc. Dit alles wordt in het BIMmodel bijgehouden waarbij de gebouwelementen met hun eigenschappen, relaties en afhankelijkheden, parametrisch worden vastgelegd. Het is zelfs mogelijk om een factor tijd en kosten mee te geven (4D respectievelijk 5D). Hierdoor wordt alle relevante data die benodigd is voor het ontwerp, uitvoering en beheer van een gebouw in een integraal model samengebracht en kan deze worden gebruikt voor analyses en stimulaties, voorafgaand aan de daadwerkelijke realisatie van een bouwwerk. Het model bevat dus niet alleen geometrische representaties maar ook informatie die het geheel intelligenter maakt. Het is de bedoeling dat alle betrokken partijen werken via hetzelfde BIM-model en met informatie die steeds beschikbaar en actueel is. We kunnen concluderen dat BIM een intelligent concept is dat inzicht biedt in het sneller, economischer en duurzamer creëren en beheren van bouwprojecten. Het wordt meer en meer gebruikt in de huidige bouwwereld. Steeds meer opdrachtgevers, vooral dan bij grote

9

projecten, stellen BIM als voorwaarde bij hun aanbestedingen. Het klassieke bouwproces wordt vooral gekenmerkt door versnippering en fragmentatie: iedereen doet zijn eigen taak op zijn eigen manier zonder veel oog voor een efficiënte samenwerking tussen de verschillende partijen. BIM zal hier verandering in brengen. De projectpartners werken samen via elektronische communicatieplatforms waar alle informatie centraal wordt opgeslagen en beheerd. In de Verenigde Staten, Verenigd Koninkrijk en Nederland is BIM al enkele jaren geïntegreerd. In België is het BIM-gebeuren aan het groeien, vooral op architecturaal vlak is er al zeer veel geëvolueerd. De laatste jaren zien we een sterke opmars van het gebruik van BIM binnen de civiele technieken [5].

1.2 Collaboratie van bouwpartners Zoals reeds vermeld is het doel van BIM om een zo goed mogelijke samenwerking tussen de verschillende projectpartners te realiseren. Een transparante en eenduidige kijk op het model zorgt ervoor dat miscommunicatie vermeden wordt, wat op zijn buurt leidt tot een vermindering van eventuele faalkosten. Het BIM-model kan bevorderlijk zijn voor volgende belanghebbenden [6]: -

De opdrachtgever, die zijn of haar wensen, eisen en prestaties kan opleggen. Men kan met verschillende softwarepakketten het model virtueel weergeven en nagaan of er weldegelijk aan de wensen van de opdrachtgever voldaan wordt. Zodoende kan men correcties of veranderingen aanbrengen.

-

De ontwerpinstanties, die het project volledig digitaal zullen opbouwen en voorstellen. BIM bevordert de coherentie tussen het architecturale, structurele en technische domein. Een betere communicatie tussen deze verschillende domeinen resulteert in een beter teamwork en kan leiden tot het creëren van nieuwe, creatieve ideeën waar zowel de opdrachtgever, architect als studiebureau baat bij hebben.

-

De controlerende instanties, die het project kunnen toetsen aan de regelgevingen. Zo kan men eenvoudig nagaan of het project al dan niet bepaalde certificaten kan behalen zoals bijvoorbeeld een brandveiligheidcertificaat.

-

De uitvoerende partijen, die instaan voor de effectieve realisatie. BIM zal voor de uitvoerende partijen vooral meer voeling creëren voor de planning van de bouw. Men kan eenvoudiger planningen opstellen, bestellingen opnemen en personeel inzetten wat uiteindelijk leidt tot een sterke efficiëntieverhoging.

-

De gebruikers, die het model kunnen gebruiken voor onderhoud (facility management). Ook hier biedt BIM meer inzicht op de planning en onderhoud. Men kan bijvoorbeeld eenvoudig nagaan waar leidingen liggen indien er veranderingen moeten aangebracht worden of indien men genoodzaakt is om bepaalde ruimten een nieuwe verflaag te geven, kan men makkelijk achterhalen hoeveel verf er juist nodig is.

10

1.3 Voordelen BIM Het belangrijkste voordeel van BIM is het feit dat de communicatie tussen de verschillende bouwpartijen geoptimaliseerd wordt. Dit resulteert in een vlotte en efficiënte samenwerking. Men is in staat om voor verschillende situaties snellere en duidelijkere besluiten te realiseren. Naast een optimale samenwerking en de hiermee gaande duidelijkheid zijn er nog voordelen aan het gebruik van BIM [1-3]: -

Besparing op de bouwkosten, in de huidige economische toestand is het belangrijk dat bouwbedrijven zo efficiënt mogelijk werken. Men streeft naar zo laag mogelijke kostenoverschrijdingen en faalkosten. Met behulp van BIM heeft men een goed inzicht op eventuele extra kostenoverschrijdingen en kosten voor aanpassingen tijdens de ontwerpfase dit in tegenstelling tot de traditionele werkmethodes. Door de visualisatie en implementatie van informatie kunnen allerhande alternatieven vooraf aangetoond en vergeleken worden, wat leidt tot optimalisatie en tijdwinst.

-

Duurzaamheid en constructieve veiligheid, de volledige lifecyclecost kan geëvalueerd worden bij de aanvang van het project. Men kan reeds in een vroeg stadium de effecten van het ontwerp op de eindrealisatie analyseren.

-

Consistente informatie, alle views uit een bepaald project zijn consistent, ongeacht of het nu 2D-, 3D-, of numerieke views zijn. Het zijn allemaal directe representaties van informatie uit dezelfde onderliggende database. We bedoelen daar mij dat bijvoorbeeld een raam uit een bepaald planzicht, hetzelfde raam is in zijaanzicht en het zelfde raam is in een mogelijk gegenereerde meetstaat.

-

Flexibel model, de relaties tussen de elementen zorgen voor een samenhangend en flexibel bouwmodel waarbij wijzigingen in welke view dan ook gesynchroniseerd worden in het totale bouwmodel en dus ook in alle andere views of representaties. Daarbij zorgen de relaties tussen de elementen, de parameters, dat ze elkaar aansturen. Zo veranderen bijvoorbeeld de maten van een vloer als de wand opschuift. Eens de parameters werden ingegeven, wordt het heel eenvoudig om wijzigingen aan te brengen doordat alle gegevens op elkaar zijn afgestemd.

1.4 Traditionele werkmethodiek Als we het BIM-proces vergelijken met de traditionele werkmethodes, merken we op dat BIM veel efficiënter, flexibeler en gebruiksvriendelijker is. BIM vergroot het inzicht tijdens het hele bouwproces voor alle participanten. Men kan op elk moment gemakkelijker fouten opsporen en hierop kan direct ingespeeld worden (clash detection). Stel bijvoorbeeld dat een architectenbureau werkt met een traditioneel tekenprogramma zoals AutoCad. Men heeft enkele plannen, aanzichten en detailtekeningen getekend waarbij achteraf wordt opgemerkt dat de ingetekende ramen niet de juiste zijn. De ontwerper zal dus elke tekening afzonderlijk moeten aanpassen. Wat concreet betekent dat men alle ramen moet

11

hertekenen en men eventueel rekening zal moeten houden met andere gebouwelementen. Dit is een zeer tijdrovend proces en zal op zijn beurt dus doorwegen als extra kost. In onderstaande grafiek heeft men de BIM-methodologie tegenover het traditioneel proces geschetst. Hieruit kunnen we afleiden dat er voor het BIM-model hoofdzakelijk een verschuiving van werkzaamheden naar de vroegere fasen van het ontwerpproces plaatsvindt. Ten opzichte van het traditionele ontwerpproces vraagt 3D-modelleren om de invoer van meer gedetailleerde gegevens tijdens het vroegere ontwikkelingsstadium. Deze investering wordt echter wel in latere fasen terugverdient (Figuur 3) [3-5].

Figuur 3: Vergelijking traditioneel- en BIM ontwerpproces [8]

De grijze lijn in bovenstaande grafiek geeft de mogelijke beïnvloeding van de kostenkwaliteitsverhouding weer. We zien dat er in het begin van het ontwerpproces nog veel speling is: de kosten-kwaliteitsverhouding kan nog optimaal beïnvloed worden. Maar in latere fasen van het ontwerpproces, waar er dus meer concrete informatie vastligt, heeft men minder ruimte om de kosten-kwaliteitsverhouding te beïnvloeden [8]. De paarse lijn toont het verloop van de kosten bij ontwerpwijzigingen in de loop van het ontwerpproces. Dus hoe verder men in het proces zit, hoe meer het zal kosten om wijzigingen aan te brengen. Men beoogt voor de BIM-methodologie dat men het zwaartepunt van de ontwerpinspanningen naar voor schuift, zodanig dat de beïnvloedingsmogelijkheden van kosten en kwaliteit hoog zijn om de kosten voor ontwerpwijzigingen zo laag mogelijk te houden. Bij het traditionele tekenproces ligt het zwaartepunt van de inspanningen bij het technisch ontwerp en de prijsvorming. Dit zijn fasen waarin de beïnvloedingsmogelijkheden van kosten en kwaliteit relatief laag zijn, terwijl de kosten van ontwerpwijzigingen hoog liggen. De opzet van het BIM-model is het creëren van een gedeeld projectmodel waarbij alle participanten direct in verbinding staan met dit model. De informatie kan met iedereen gedeeld worden, waardoor onderlinge communicatie geoptimaliseerd wordt. De verschillende

12

partijen komen zo dichter bij elkaar te staan. Dit biedt de mogelijkheid om meer aspecten vanuit een ander perspectief te benaderen en de kwaliteit van het eindproduct te verbeteren. In de traditionele werkmethodologie is het zo dat iedere participant van een bepaald project het werk verricht dat hem opgelegd wordt. Men zal zich vooral focussen op hetgene wat van hem verwacht wordt en niet op het totaalconcept. Doordat BIM werkt met een gedeeld model, zorgt dit ervoor dat de betrokken partijen dichter bij elkaar staan. Dit geeft de mogelijkheid om beter samen te werken en te communiceren. Men geeft ook de opportuniteit om bepaalde taken anders te interpreteren en uit te werken dan de traditionele werkmethodiek (Figuur 4).

Figuur 4: Interactiemodel tussen de verschillende participanten. Links het traditioneel model, rechts het gedeeld BIM-model [10]

Het is niet vanzelfsprekend om deze overgang in te voeren, veranderingen in de praktijk zijn namelijk niet te onderschatten. Alle participanten moeten hun traditionele werkmethodes aanpassen, hun kijk veranderen en eventueel andere of meerdere verantwoordelijkheden opnemen[11]. Over het algemeen worden veranderingen in werkmethodiek met weinig enthousiasme onthaald. Dit omdat het BIM-model meer verantwoordelijkheden en investeringskosten met zich meebrengt. Het bedrijf moet hiervoor extra budget uitrekenen en eventuele opleidingen voorzien. De doorslaggevende factor hierbij is dat men het rendement van deze wijzigingen kan aantonen.

13

2 BuildingSMART BuildingSMART (Figuur 5) is een internationale non-profitorganisatie en ontwikkelt open standaarden voor Building Information Modeling: openBIM. De ontwikkeling van de standaarden is gebaseerd op ISO-standaarden (International Standardization Organization). BuildingSMART voorziet aldus internationale standaarden voor verschillende (gebouw)termen, processen en datagegevens [3].

Figuur 5: Logo van BuildingSMART

De visie van BuildingSMART is: “Sustainability by building SMARTER”[12] De missie van BuildingSMART is: “Contribute to the sustainable build environment through SMARTER information sharing and communication using open international standards in the building and construction sector, private and public.”[12] Samengevat streeft BuildingSMART dus naar een neutraal en onafhankelijke standaard zodat men niet afhankelijk is van externe bedrijven, softwareontwikkelaars ed.. Men wil zo transparant en open mogelijk functioneren zodanig dat men onafhankelijkheid kan verkrijgen. Met behulp van deze interoperabiliteit is men instaat om gebouwmodellen slimmer en interessanter te maken voor alle betrokken partijen. Alle opbrengsten die BuildingSMART zou realiseren worden integraal geïnvesteerd in het verder ontwikkelen van de standaarden. Op die manier verkrijgen we een non-profitorganisatie. Men is reeds een tiental jaren bezig met het oprichten van standaarden voor het gebruik van object-georiënteerde-technologie in de bouw- en faciliteitmanagementsector. Hiervan wordt de laatste jaren, meer en meer gebruik gemaakt [6,8]. BuildingSMART heeft 3 basis standaardmodellen uitgewerkt (Figuur 6): -

Industry Foundation Classes (IFC) of het data-uitwisselingsformaat, de IFC vormen buildingSMART’s specificatie voor 3D-gebouwenmodellen [14]. IFC maakt het mogelijk om BIM-gegevens uit te wisselen tussen verschillende softwareapplicaties. Het IFC-protocol maakt het mogelijk om geometrische beschrijvingen in 3D weer te geven met exacte locaties van gebouwelementen en hun onderlinge relaties. Men heeft alsook de mogelijkheid om eigenschappen, materiaalbeschrijvingen, specificaties etc. te koppelen aan het model.

-

Information Delivery Manual (IDM) of de procesbeschrijving, IDM is de standaard voor het beschrijven van verschillende processen en deelprocessen omtrent het globale bouwverloop [14]. Naast een beschrijving van de verschillende bouwprocessen en hun

14

noodzakelijke gegevens, schept IDM ook een beeld over welke actoren er deelnemen binnen deze processen en wat hun specifieke rollen zijn. -

BuildingSMART Data Dictionary (bSDD) of de semantiek, onder bSDD verstaan we de standaard waarin verschillende gebouwtermen worden verklaard [14]. Het is als het ware een woordenboek waarin de betekenis en context van de gebouwobjecten wordt verduidelijkt. Zo kan men een eenduidig beeld creëren, zonder miscommunicatie, over de vocabulaire van de verschillende elementen.

Figuur 6: Schematische weergave van BuildingSMART’s standaarden [14]

15

3 Industry Foundation Classes BIM wordt pas efficiënt wanneer projectgegevens met andere partijen kunnen worden gedeeld. Men kan dit doen met behulp van het IFC-bestandsformaat: een open medium dat kan gebruikt worden door verschillende softwareprogramma’s. IFC is een gedefinieerd standaard formaat om BIM-modellen te beschrijven, het omschrijft hoe gebouwinformatie wordt opgeslagen tijdens de volledige levenscyclus van een gebouw. IFC is een objectgeoriënteerd datamodel en vertegenwoordigt informatie over (gebouw)elementen, processen, representaties, systemen, berekeningen etc. voor verschillende beroepen [15]. IFC kan gebruikt worden voor het uitwisselen en delen van BIM-informatie tussen verschillende softwarepakketen, ontwikkeld door verschillende softwareverkopers. De meest gebruikte softwareapplicaties hebben inheemse bestandsformaten (native dataformats). Dit zorgt ervoor dat het model opgeslagen moet worden in dat bepaalde formaat om er verder mee te kunnen werken. Met behulp van het IFC-formaat wil BuildingSMART zich onafhankelijk opstellen tegenover deze specifieke softwareverkopers. Het IFC-dataformaat is dus een ontwikkelde open standaard die data-uitwisseling realiseert tussen verschillende softwareprogramma’s. Zo kan een IFC-model dat gecreëerd is in Revit, geopend en bewerkt worden via ArchiCAD door een architect en kan een bouwkundig ingenieur op zijn beurt het model openen via bijvoorbeeld Tekla. Deze interoperabiliteit maakt het eenvoudiger om een efficiëntere samenwerking tussen de verschillende partijen van het bouwproject te realiseren. Concreet is het IFC-formaat een uitwisselingsformaat en geen bewerkingsformaat. We spreken dus over een statisch formaat. Indien men toch bewerkingen wil uitvoeren met hetzelfde model, zal men dit eerst moeten converteren naar het formaat van het welbetreffende programma. Als men bijvoorbeeld een warmteverliesberekening wilt uitvoeren met Revit, moet men het IFC-model eerst importeren en dan converteren naar een .rvt-formaat. In de praktijk ondervindt men nog veel problemen met deze conversie aangezien de meeste programma’s een eigen interpretatie en andere referenties hebben voor de objecten. Ondertussen zijn er al meer dan 150 softwareprogramma’s [16] wereldwijd die het IFC formaat ondersteunen waaronder AutoCAD, Revit, ArchiCAD, DDS-CAD etc. (bijlage I) BuildingSMART voorziet tevens ook een certificering voor softwareontwikkelaars die IFC willen implementeren in hun programma. In de loop der jaren werden er al een hele reeks verschillende versies ontwikkeld. Versie 2X3 wordt vandaag de dag het meeste gebruikt, maar zal snel weer vervangen worden door de nieuwere versie, IFC4, die in maart 2013 gelanceerd werd [5,6].

3.1 IFC 2x3 Doordat BuildingSMART een open medium is, kan men gemakkelijk allerlei handleidingen terugvinden. Hierdoor krijgen gebruikers of softwareontwikkelaars een beter inzicht in het IFC- gebeuren. De IFC 2x Edition 3 Model Implementation Guide [17] is zo een handleiding voor IFC 2x3 specifiek voor softwareontwikkelaars. Met behulp van deze gids kan men een beeld scheppen over de implementatie van de IFC-standaard. De implementatiegids bevat een inleiding in het gebruik van het IFC Schema Specifcation, documentatie in verband met correcte implementaties, verklaringen van de beschikbare tools en tenslotte enkele voorbeelden van IFC-bestanden met verschillende elementen uit een gebouwinformatiemodel.

16

Het IFC-schema is geschreven in EXPRESS versie 1[18], een datamodellering taal gebaseerd op de ISO standaard 10303-11:1994. De EXPRESS-bestanden krijgen de extensie .exp met zich mee. IFC bestanden (het effectieve model) worden afgeleid van het STEP physical file format (SPF) [19], gedefinieerd in ISO10303-21, en krijgen de extensie .ifc. Dit STEP formaat volgt de in EXPRESS geschreven IFC-schema’s. STEP is een onafhankelijke taal om 3D-geometrieën en bijbehorende informatie weer te geven [20]. Een EXPRESS datamodel kan op twee manieren benaderd worden: tekstueel en grafisch. De tekstuele voorstelling is de belangrijkste, maar de grafische weergave (EXPRESS-G) maakt het mogelijk om het model makkelijker te begrijpen. EXPRESS-G geeft dus een duidelijk beeld van de verschillende gebruikte klassen, typen en onderlinge relaties (Figuur 7).

Figuur 7: Grafische weergave EXPRESS datamodel (EXPRESS-G) [17]

De basis SPF-structuur verdeelt elk bestand in een hoofding en een deel bestaande uit allerhande data. De hoofding geeft informatie over de gebruikte IFC-versie, het softwarepakket dat het bestand geëxporteerd heeft, datum en tijd, naam van de gebruiker, bedrijf etc. Het datadeel bevat alle instanties van de entiteiten van het IFC-model en kan dus zeer groot worden. Elke instantie heeft een uniek STEP id, een naam van de entiteit en een lijst van attributen. Naast de mogelijkheid om een IFC-bestand te kunnen openen met verschillende softwarepakketten, kunnen we het model ook openen via een teksteditor zoals bijvoorbeeld Notepad. Indien we dit doen, krijgen we een vrij omslachtig en groot tekstbestand dat makkelijk uit duizenden regels kan bestaan. Het tekstbestand is een zogenaamd STEPbestand, het bestaat uit regelnummers en verwijzingen. Met behulp van deze opeenvolgende regelnummers en verwijzingen kan het IFC-model gegenereerd worden (Figuur 8). In bijlage IV kan dit verder uitgewerkte voorbeeld, teruggevonden worden.

17

Figuur 8: IFC-tekstbestand

3.2 IFC Schema Representations Een IFC-model is opgebouwd uit een verzameling van vooraf gedefinieerde klassen. Elk gebouwenobject kan in principe onderverdeeld worden in zo een klasse. Een klasse groepeert dus objecten die dezelfde kenmerken en eigenschappen hebben [21]. Onder eigenschappen verstaan we attributen zoals bijvoorbeeld het type, de vorm, het materiaal, de warmteweerstand etc. De eigenschappen kunnen verplicht of optioneel zijn, in relatie zijn met andere klassen, verschillende waarden aannemen etc. Bekijken we bijvoorbeeld naar een raam (object) in de respectievelijke klasse raam, dan heeft het raam verschillende eigenschappen meegekregen vanuit zijn klasse. Zo zal men een beschrijving kunnen geven over de kleur, prijs, type, materiaal etc. (Figuur 9).

18

Figuur 9: Voorbeeld van mogelijke eigenschappen voor het ventilatieroosterobject [21]

De klassen en attributen van een IFC-model kunnen grafisch weergegeven worden (EXPRESS-G). Dit zorgt er voor dat het model ‘makkelijker’ leesbaar is. Elke klasse wordt weergegeven in een geel kader. De attributen worden dan weer afgebeeld aan de hand van een lijn met een eindpunt. De eindpunt verbindt de klasse met een bepaald datatype ( eventueel een andere klasse) (Figuur 10).

Figuur 10: Voorbeeld van een grafische weergave van klassen en hun attributen [21]

BuildingSMART heeft een architectuur opgebouwd om de verschillende klassen te verduidelijken. De structuur is opgebouwd uit verschillende modules en volgen een strikte hiërarchie. Binnen de structuur zijn er vier conceptlagen gedefinieerd: Resource Layer, Core Layer, Interoperability Layer en de Domain/ApplicationsLayer. Deze lagen opereren volgens het ladder principe: in elke laag mag een klasse refereren naar een andere klasse in dezelfde laag of naar een onderliggende laag, maar niet naar een bovenliggende laag (Figuur 11) [15,16].

19

Figuur 11: Basis 2X3 IFC Schema [21]

Resource Layer,

De Resource Layer is het laagste niveau binnen de hiërarchie. De objecten binnen deze laag zullen niet afhangen van andere klassen uit het model (mits enkele uitzonderingen). We kunnen deze klassen vergelijken met de wortels van een boom, zonder deze definities kunnen bovenliggende objecten niet of beperkt gedefinieerd worden. Alle instanties betreffende de geometrie zijn verzameld en gedefinieerd in de IfcGeometryResource. Indien men aan bepaalde objecten uit de kern of hogere lagen, geometrische representaties wil bijvoegen dan zal men die ophalen uit de IfcGeometryResource-klasse [23].

Core Layer,

De CoreLayer vormt de basisstructuur of het hart van een IFCobject en definieert abstracte aspecten die met behulp van hogere lagen zullen gespecificeerd worden. Fundamentele concepten omtrent type definities, relaties, attributen en rollen worden hierin bepaald [23].

20

Interoperability Layer,

De InteroperabilityLayer voorziet modules voor het definiëren van objecten die behoren tot twee of meerdere Domain/Application-klassen [23].

Domain/Applications Layer,

De Domain/Applications Layer voorziet een verdere specificatie van de objecten. De objecten kunnen verder gedefinieerd worden afhankelijk van hun bedrijfsdomein. Men voorziet negen domeinen: architectuur, elektriciteit, HVAC, faciliteit management etc. Zij leveren de hoogste specificatie op van de objecten en vormen op deze manier de belangrijkste laag voor de gebruikers (Figuur 11) [23].

Praktisch gezien kunnen we concluderen dat een IFC-model bestaat uit verschillende klassen: de IFC-klassen. De IFC-klassen starten steeds met de afkorting Ifc. Idealiter zou elk object uit een model onder de juiste klasse geïmplementeerd moeten worden. Alle objecten die bijvoorbeeld te maken hebben met verwarming, ventilatie of koeling kunnen we terugvinden in het HVAC domein (Domain/Applications Layer). IfcAirTerminalType is een voorbeeld van een objectklasse dat men terugvindt in het HVAC-domein. Het type element IfcAirTerminalType definieert een lijst van algemeen gedeelde eigenschappen en representaties voor luchtroosters [21]. Als men bijvoorbeeld een luchtrooster wil modelleren, moet dit luchtrooster onder de klasse IfcAirTerminalType vallen zodanig dat men het luchtrooster kan binden aan specifieke kenmerken, eigenschappen en relaties die kenmerkend zijn voor luchtroosters. In bijlage II en III wordt weergegeven hoe men objecten in Revit 2014 exporteert en classificeert (mapping) in de respectievelijke IFC-klassen.

21

4 Information Delivery Manual Het IFC-model beschikt over een breed assortiment aan specificaties voor bouwprojecten. De informatie die het model omkadert, geeft een meerwaarde aan de werkomstandigheden voor alle instanties die met het project te maken hebben: architecten, ingenieurs, arbeiders, faciliteit managers etc. De informatie die uit het model kan gehaald worden, kan een verduidelijkend beeld geven over de volledige levenscyclus van het gebouw. Het kan bepaalde aspecten en problemen aankaarten tijdens de verschillende bouwfasen zoals bijvoorbeeld in de ontwerpfase, constructiefase en beheerfase [24]. Het is de bedoeling dat de informatie die aan het model hangt een meerwaarde biedt aan de verschillende partijen die aan het project meewerken. Een IFC-model geeft een duidelijk en handig beeld over het totaalconcept van een project. Praktisch gezien is het echter niet de bedoeling dat elke partij met het volledige schema werkt. Het geeft namelijk geen beeld van de ontwikkelingen tijdens de verschillende bouwfasen. Concreet is het dus niet voor iedereen noodzakelijk om al deze informatie voor zijn of haar werk op te nemen. Men kan met enkele specifiek, gerichte gegevens zijn of haar taak reeds uitvoeren, zonder een beeld te moeten hebben van andere informatie. De informatie die geen dienst kan bieden voor de specifieke taak van een partij wordt als nutteloos gezien en men hoeft deze dus niet op te nemen. Indien dit toch gebeurt, kan de persoon in kwestie in verwarring geraken en eventueel te vermijden fouten maken. Het IFC-model kan pas goed geïntegreerd worden in de werkomgeving indien de gebruikers efficiënte en betrouwbare informatie toekrijgen. De gebruikers moeten zich vertrouwd voelen met de software en er van overtuigd zijn dat de data die die ze doorzenden of ontvangen accuraat en sufficiënt zijn voor de taken die ze moeten uitvoeren. Stel dat men vraagt aan een stabiliteitsbureau om de stabiliteit van een bepaalde woning te controleren. Dan is men genoodzaakt voldoende gegevens te verzamelen omtrent het betrekkende gebouw om deze taak te kunnen uitvoeren. Informatie als: afmetingen van het gebouw, materiaaleigenschappen, lengte van overspanningen etc. zijn hiervoor noodzakelijk. Het is belangrijk dat deze gegevens betrouwbaar, efficiënt en accuraat zijn. Gegevens die geen meerwaarde bieden aan het studiebureau mogen achterwege gelaten worden. Zo zal men bijvoorbeeld informatie aangaande de esthetische aspecten van het gebouw, zoals de kleur, type van de ramen, afwerkingslagen, armaturen, als nutteloos aanzien voor het stabiliteitsbureau. Deze gegevens kunnen dan wel weer interessant zijn voor andere partijen zoals bijvoorbeeld de binnenhuisontwerper. De IDM, Information Delivery Manual [24], geeft een oplossingsmethodologie weer voor deze probleemstelling. Het definieert en beschrijft bepaalde werkprocessen en bepaalt ook welke gegevens de verschillende partijen nodig hebben om hun werk op een correcte manier te kunnen uitvoeren. Zo zal men beschrijven wat de taak van een bepaalde partij inhoudt, welke gegevens ze als input nodig hebben, welke gegevens ze als output moeten leveren etc. Op deze manier kunnen ze hun rol in het bouwproces op de juiste manier uitvoeren. Het complete IFC-schema biedt de mogelijkheid om verschillende aspecten te implementeren uit de bouwwereld, zowel op architecturaal vlak als HVAC, faciliteit management, stabiliteit, brandwering etc. Dit kunnen we ook uit de boomstructuur afleiden in Figuur 11. Het bevat verschillende entiteiten, datatypes en eigenschappen (IFC-componenten) die deze aspecten in beeld brengen. Het is echter niet de bedoeling dat we al deze facetten in één model gieten. Het is gebruikelijker dat men een bepaald deel van het totaalconcept gaan aanhalen om de noden

22

tussen twee participanten te kunnen verwezenlijken. Dit kan worden gerealiseerd door middel van de IDM-methodologie (Figuur 12).

Figuur 12: Links: IFC behandelt alle elementen over alle projectfasen. Rechts: IDM behandelt specifieke elementen in een bepaalde projectfase [4]

Het is dus de bedoeling dat zowel de gebruikers als de softwareontwikkelaars vat krijgen op de IFC-componenten die nodig zijn om een bepaalde projectfase te kunnen uitvoeren. De softwaregebruikers moeten er zeker van zijn dat de IFC-componenten voldoen aan hun noden. De softwareontwikkelaars moeten oplossingen (Solutions) vinden om de behoeften (Requirements) van de gebruikers te kunnen realiseren. Ze moeten weten hoe IFC de behoeften van de gebruikers kan tegemoet komen. Ze moeten de juiste IFC-componenten kiezen en deze moeten op zich ook voldoen aan de eisen van de gebruikers. Het is echter niet altijd mogelijk voor softwareontwikkelaars om te voldoen aan alle noden van de gebruiker (Figuur 13).

Figuur 13:Verband tussen gebruikerseisen en hun oplossingen [4]

23

4.1 IDM visie De visie van de Information Delivery Manual is het beschrijven van werkprocessen en hun informatie specificaties in de levenscyclus van AEC/FM projecten. Zodanig dat de uit te voeren taken verbeterd en geoptimaliseerd kunnen worden [4].

4.2 IDM doel Een belangrijk aspect binnen IDM is het verzamelen van informatie voor de AEC/FMindustrie. Zo zal men aankaarten welke processen genoodzaakt zijn om informatie door te spelen naar verschillende participanten, wat deze informatie juist is en hoe deze tot een betere werkmethodologie leidt. Deze informatie zal nodig zijn voor het definiëren van de werkprocessen binnen het AEC/FM-project en het specifiëren van de IFC-mogelijkheden. Anderzijds wil IDM een basis vormen voor de consequente ontwikkeling van project, specifieke procesmodellen. IDM definieert binnen het procesmodel verschillende fasen en tracht de resultaten binnen elke fase te beschrijven en te kijken hoe deze kunnen opgevangen worden in daaropvolgende fasen. Als laatste tracht IDM te zorgen voor een overeenkomst tussen de verschillende deelnemers, over welke informatie er verwacht wordt bij de uitwisseling en of deze informatie al dan niet steek houdt. Hierbij zal men de effectieve gebruikers (actoren) identificeren en hun specifieke rol in het project definiëren. Men gaat na welke informatie belangrijk is voor welke actor en tracht deze gegevens op een efficiënte en gemakkelijke manier over te brengen, zodanig dat ze te begrijpen zijn voor de uiteindelijke gebruikers [4]. 4.2.1 Bouwfasen Het realiseren van een bouwproject verloopt in verschillende aaneensluitende bouwfasen. Het is belangrijk dat men een duidelijk beeld heeft over wie een rol speelt binnen deze fasen en wat hun functie juist inhoudt. Zo zal men partijen moeten aanstellen die de verantwoordelijk op zich nemen omtrent het ontwerp en detailleren van het gebouw. De architect zal eerst een ruwe schets maken voor de bouwheer. Waarop de bouwheer dan weer feedback geeft, zodanig dat er eventuele aanpassingen kunnen doorgevoerd worden. Daaropvolgend kan het uiteindelijke ontwerp getekend worden. Nadat het architecturaal ontwerp gerealiseerd is, kan men een studiebureau aanstellen die de implementatie van technische systemen voor zijn rekening neemt. Communicatie tussen de verschillende partijen is erg cruciaal om een feilloos geheel af te leveren. Indien men bijvoorbeeld een conflict aantreft betreffende de te installeren technieken en de geometrische opbouw van het gebouw, moet men de architect aanspreken en samen naar de best passende oplossing zoeken. Een goede verstandhouding tussen de verschillende participanten leidt tot aangenaam en vlot werk. Met behulp van een juiste keuze aan Exchange Requirements kan men deze communicatie al sterk optimaliseren (Figuur 14). De Exchange Requirements worden zodanig gekozen dat men zonder problemen een bepaalde taak kan uitvoeren. De uit te voeren instantie beschikt m.b.v. de Exchange Requirements over de nodige informatie om hun specifieke taak te kunnen volbrengen. Feit is dat elk bedrijf een eigen interpretatie heeft over welke gegevens voor hen belangrijk zijn. Ook op de

24

verschillende opeenvolgende bouwfasen heeft men een eigen kijk en meestal verschillen ook deze met die van andere bedrijven. Elke gebruiker heeft zijn eigen toenadering tot de verschillende fasen en hun Exchange Requirements. Om consequent te kunnen werken is er nood aan een bepaalde standaard die zorgt dat er eenheid bestaat over de keuze van de bouwfasen en welke rol de participant daarin speelt. Zonder deze eenduidige consequentie kan men niet efficiënt te werk gaan. Indien er geen stramien is, zou iedereen vrij kunnen kiezen hoe ze een bepaalde bouwfase noemen en welke rol ze daarin spelen. Dit probleem speelt zich vooral af in de huidige werkcondities van de bouwwereld wereldwijd. Nu men in de overgangsfase zit naar digitalisering is een standaard zeer cruciaal om chaos en miscommunicatie te vermijden.

Figuur 14: De levenscyclus van een bouwproject bestaande uit verschillende fasen [25]

De gedefinieerde projectfasen uit het IDM-concept zijn overgenomen van de projectfasen van het Generic Process Protocol (GPP). Deze projectfasen worden genummerd van 0 tot 10. Fase 0 staat voor de voorbereidingsfase. Tijdens deze fase vergt men de nodige voorbereidingen voor het starten van het bouwproject. Fase 10 wordt gezien als het einde van de levenscyclus van het gebouw: de afbraak en eventuele recyclage [4]. Meestal hebben bedrijven een eigen werkmethode en volgen ze een eigen gekozen procedure om zo gestructureerd mogelijk te kunnen werken. De identificatie van projectfasen en hun rol die ze daarin spelen zal dus verschillen t.o.v. een ander bedrijf. Dit is zeker het geval wanneer we bedrijven zouden vergelijken op internationaal gebied. We kunnen de gestandaardiseerde IDM-fasen reflecteren naar lokale bouwfasen. Zodanig dat de gestandaardiseerde fasen kunnen vervangen worden door de lokaal gebruikte bouwfasen. Vervolgens kunnen de gekozen Exchange Requirements dan afgewogen worden naar deze lokale fasen. Het is belangrijk dat de standaardfasen binnen de grenzen van de lokale fasen blijven en omgekeerd. De verschillende fasen moeten dus voldoen aan een 1:1, 1:veel of veel:1-relatie. De fasen mogen elkaars grenzen dus niet overschrijden, zo mag een lokale fase niet starten in het midden van een standaardfase en eindigen in een andere daaropvolgende standaardfase [4]. In volgende tabel zien we hoe de IDM-standaardfasen kunnen ingedeeld worden naar Belgische bouwfasen. Binnen deze Belgische bouwfasen werden in deze studie geen standaarden gevonden. De meest gebruikelijke opeenvolgende fasen staan hieronder en in Tabel 1 beschreven [9].

25

-

Initiatiefase, in deze fase gaat men opzoek naar allerlei randinformatie voor de realisatie van het gebouw. Men zal samen met de vragende en uitvoerende partijen op zoek gaan naar wat er juist gecreëerd moet worden en hoe dit zal verlopen. Men moet dus voldoende weet hebben omtrent de vooropgestelde eisen en de eventuele beperkingen op vlak van budget en tijd. Als men dus voldoende geïnformeerd is over het uit te voeren concept, kan men overgaan naar de volgende fase.

-

Voorontwerp, het ontwerpteam zal een ruwe schets maken aan de hand van de gegevens uit de initiatiefase. Dit ontwerp wordt aan de vragende partij voorgelegd en onderling met het ontwerpteam besproken. Er wordt gekeken of het ontwerp aan de vooropgestelde wensen en eisen voldoet. Communicatie tussen architect en studiebureau(s) of andere experten speelt ook hier weer een belangrijke rol. Men kan eventuele complexe uitvoeringen of problemen aankaarten, waarop verder kan worden ingespeeld.

-

Definitief ontwerp, in deze fase is het ontwerp volledig afgewerkt en kan het doorgespeeld worden naar de uitvoerende instanties. Men kan nu duidelijkere en meer gedetailleerdere tekeningen voorleggen samen met de te gebruiken materialen. Het is dus de bedoeling om geen vragen meer open te laten omtrent de uitvoering, alles moet duidelijk zijn. Na een akkoord kan men starten met het maken van de aanbestedingen.

-

Aanbestedingsfase, men zal offertes laten opstellen tegen welke prijs een bouwbedrijf een bepaalde opdracht zal uitvoeren. De verschillende offertes worden met elkaar vergeleken. Uiteindelijk kan men met de gekozen partijen te werk gaan.

-

Uitvoeringsfase, hier zullen de uiteindelijke werken worden uitgevoerd. Aannemers zullen de voorgelegde en goedgekeurde plannen volgen en uitvoeren zodanig dat de uitvoering voldoet aan de eisen van de bouwheer.

-

Opleveringsfase, in deze fase zijn de uitgevoerde taken door aannemers afgewerkt en klaar. De opdrachtgever zal de uitgevoerde taken aanvaarden indien deze conform de eisen en wensen zijn uitgevoerd. De bouwheer zal echter als tegenprestatie de financiële afspraken navolgen. Men maakt echter ook nog een onderscheid tussen voorlopige en definitieve oplevering. Bij de voorlopige oplevering heeft men nog een kans om eventuele gebreken of fouten te herstellen. De definitieve oplevering vindt plaats één jaar (of langer) na de bouwwerkzaamheden.

-

Gebruiks- en onderhoudsfase, in deze fase zal men het gebouw gaan gebruiken en onderhouden.

-

Sloop, nadat het gebouw werd afgeleefd kan de uiteindelijke afbraak volgen.

26

Tabel 1: Vergelijking van IDM-standaardfasen met de meest gebruikelijke Belgische bouwfasen

0

Portfolio requirements

1

Conception of need

2

Outlinefeasibility

3 4

Substantive feasibility Outline conceptual design

Beschrijving Nodige documenten voorzien voor het kunnen verwezelijken van een project Opstellen van de mogelijke oplossingen en controleren op de haalbaarheid Analyseren an de mogelijke oplossingen uit fase 1,en de best passende oplossingen vastleggen Financiële goedkeuring verkrijgen Identificeren van de te ontwerpen elementen

5

Full conceptual design

Conceptontwerp klaar maken voor detailuitwerking

Definitief ontwerp

6

Coordinated design

Ontwerpen klaarmaken voor verdere ontwikkeling en volledige financiële goedkeuring

Aanbestedingsfase

7 8 9

Production information Construction Operation and maintenance

10

Disposal

IDM-standaardfasen

Aanbestedingen vastleggen De uitvoering van de bouwwerken Gebruik en onderhoud van het product Ontmantelen en afbreken van de gebouwelementen rekening houdend met gezondheid- en veiligheidsreglementering

Belgische bouwfasen

Initiatiefase

Voorontwerp

Uitvoeringsfase Opleveringsfase Gebruiks- en onderhoudsfase Sloop

4.2.2 Actoren Onder het begrip ‘actoren’ vallen alle mensen die het uiteindelijke werk uitvoeren in een welbepaald bedrijfsproces. Actoren kunnen zowel individuen, groepen als organisaties zijn die elk een eigen identiteit meedragen (Figuur 15) [4].

Figuur 15: Actoren en hun rollen [4]

Binnen het IDM-concept is deze identiteit niet zo belangrijk, maar wel de rol die de actoren uitoefenen. Het is die rol die belangrijk is voor het bepalen van de befaamde Exchange

27

Requirements. Actoren worden dus gezien als mensen die een bepaalde functie spelen op een bepaald punt in de tijd. Elke actor kan gelijktijdig meer dan één rol op zich nemen. Op dat moment is er een verschil tussen de actor zelf en de verschillende rollen die men kan vervullen. Het is belangrijk om een consistente lijst op te stellen met de verschillende functies die de actoren kunnen spelen binnen hetzelfde project. Dit zorgt alsook voor een consistentie qua definities voor de Exchange Requirements. De keuze van naamgeving omtrent de rol van de actoren wordt in de IDM-methodologie gebaseerd op de Uniclass classificatie (Figuur 16).

Figuur 16: Uniclass classificatie [4]

28

5 Model View Definitions Het geïntegreerde IFC-schema houdt dus geen rekening met de manier waarop informatie gecreëerd en gedeeld wordt met andere participanten. Deze kwestie wordt opgelost en uitgevoerd met behulp van Model View Definitions (MVD), de views van het IFC-model. Een ‘Model View’ is de manier waarop een bepaalde gebruiker of softwaretoepassing naar het (deel van een) IFC-model kijkt. De IFC-standaard heeft een breed arsenaal aan entiteiten voor verschillende gebouwelementen, datatypes en eigenschappen die daar aan vasthangen. Het is dus niet de bedoeling dat elk softwarepakket al deze elementen zal implementeren om aan de noden van hun gebruikers te voldoen . Een IFC-model bevat een zeer uitgebreid gamma aan informatie maar niet alle informatie is dus even belangrijk voor elke partij. Het is de bedoeling dat men streeft naar een datauitwisseling die geschikt is voor de gebruiker. De informatie moet zo compleet en efficiënt mogelijk worden doorgestuurd zodanig dat de gebruiker zijn taak op een correcte manier kan uitvoeren. Het is dus de bedoeling om een balans te vinden tussen de wensen van de gebruikers, de mogelijkheden voor de softwareontwikkelaars en het documenteren van het resultaat. Voordat de gebruikers met behulp van IFC en software hun werk kunnen uitvoeren, moet hun software capabel zijn om IFC-formaten te kunnen lezen en schrijven. IDM definieert de informatie die zal moeten worden uitgewisseld. Deze informatie wordt Exchange Requirements genoemd [4]. De MVD’s staan in voor de implementatie van deze informatie in de bepaalde software. Eens deze geïmplementeerd is, kan men de informatie uitwisselen tussen de verschillende bouwfasen. Dit zal verder nog verduidelijkt worden (Figuur 17).

Figuur 17: Ontwikkelingsdiagram MVD [26]

29

5.1 Soorten MVD’s Er bestaan al verschillende ontworpen Model View Definition’s met elk hun eigen doel [27]. Concreet zal een MVD een model gaan uitfilteren naar gelang de noodzakelijke outputgegevens. Het model wordt zodanig in orde gemaakt dat een bepaalde partij aan de hand van dat aangepaste model hun werkprocessen kunnen uitvoeren. Een MVD zorgt er dus voor dat het model wordt klaargestoomd zonder dat de vragende partij daar moeite voor moet doen. Zonder de MVD zal de uitvoerende partij dus zelf gaan zoeken naar de nodige gegevens om hun taken te kunnen uitvoeren. BuildingSMART heeft een standaard ontwikkeld voor het documenteren van de uit te wisselen informatie. IDM bepaald en definieert de grenzen van de uit te wisselen informatie. Op basis van deze bepalingen en hun afsprakenstelsel zal een MVD ontwikkeld worden. Deze MVD kan dan geïmplementeerd worden in bepaalde softwarepakketten. Nadat de implementatie voltooid is kan de softwaregebruiker, met behulp van die MVD, het model klaarmaken en doorgeven naar de volgende participant. 5.1.1 Coordination View Version 2.0 De Coordination View is het eerste MVD dat gecreëerd werd door buildingSMART en is ook de meest gebruikte. Deze MVD richt zich vooral op de uitwisseling van architecturale, structurele en technische gebouwinformatie tijdens de ontwerpfasen. Het bevat definities omtrent alle elementen die nodig zijn om de communicatie tussen deze verschillende disciplines te realiseren [27]. 5.1.2 ThermalSimulation Deze MVD is bedoeld om binnenklimaat- en energiesimulaties te kunnen uitvoeren. Het is dus de bedoeling om met behulp van de ontvangen gegevens, kennis te krijgen over hoe het binnenklimaat in een woning is en fluctueert. Men moet weet hebben over bijvoorbeeld de binnen- en buitentemperatuur, CO2- waarden, relatieve vochtigheden, luchtstroomsnelheid etc. Deze verschillende eigenschappen en hun waardes moeten dus onderling uitgewisseld worden (Figuur 18) [27].

Figuur 18: Schematische voorstelling van de ThermalSimulation MVD [27]

30 5.1.3 Hand-Over to Facility Management De Basic FM Hand-over MVD specificeert de vereiste gegevens en dataformaten die de architecturale BIM-softwarepakketten moeten exporteren naar IFC-bestandformaten en FMsoftwareprogramma’s. Faciliteitmanagement wordt gezien als het proces dat zich richt op het onderhoud en beheer van gebouwen. Zo zal het belangrijk zijn om kennis te krijgen over de verschillende zones in het gebouw, vloertypes, geografische locatie, meubelen, afwerkingslagen etc. (Figuur 19) [27].

Figuur 19: Overview van de Hand-over to Facility Management MVD [27]

31

6 Het ontstaan van een MVD Indien men een bedrijfsproces wil gaan optimaliseren met behulp van IFC-modellen of meer bepaald door gebruik te maken van specifieke MVD’s, is men genoodzaakt om te weten hoe men juist zo een procesafhankelijke MVD opstelt en creëert. Om de opeenvolgende stappen bij de creatie van een MVD te verduidelijken, verwijzen we naar de onderstaande workflow grafiek (Figuur 20). Deze grafiek is opgesteld door HESMOS, een Europees ICT-project dat zich bezig houdt met BIM-gebaseerde processen, simulaties, monitoring en visualisatie voor energie-efficiëntie en faciliteitmanagement (Universiteit Dresden Duitsland). De HESMOSworkflow grafiek is zodanig opgesteld dat de verschillende componenten uit de IDM/MVDmethodologie eenvoudig kunnen verduidelijkt worden [28].

Figuur 20: HESMOS Workflow grafiek [28]

6.1 Voorbereidend werk Voordat de IDM-methodologie effectief kan toegepast worden, is het de bedoeling dat men voorbereidend werk uitvoert. Men gaat achterhalen wat juist het doel en bereik is van de te

32

optimaliseren werkprocessen. Meestal is het zo dat de processen zich over verschillende bouwfasen verspreiden. Men moet dus een duidelijk beeld kunnen scheppen van wat de scoop van het proces is en in welke fasen het zich juist bevindt [28]. Het is de bedoeling om een idee te krijgen voor welke taken de MVD zal gebruikt worden. Stel dat we bijvoorbeeld willen een MVD opstellen voor het berekenen van een ventilatiesysteem, dan moet men nagaan in welke fasen men zich bevindt en wat eventueel binnen of buiten de scoop valt. De MVD zou dus een meerwaarde kunnen geven aan het werk van een studiebureau technieken die vooral hun taken uitvoeren tijdens de ontwerpfasen. Met behulp van het ontvangen ontwerp van de architect zal het studiebureau het ventilatiesysteem kunnen creëren. Nadat het systeem is gedimensioneerd en ontworpen zal men aan de aannemer en bouwheer tijdens respectievelijk de uitvoeringsfase en opleveringsfase de nodige informatie bezorgen. Zodanig dat ook deze partijen hun werk kunnen verrichten.

6.2 IDM-methodologie Volgende stappen volgen de IDM-methodologie, die eerder al aangehaald werd. Men zal eerst de verschillende (deel)processen en actoren identificeren. Vervolgens lokaliseren en beschrijven we de verschillende uitwisselingsprocedures binnen de scoop van de MVD. Tenslotte zullen we de essentiële Exchange Requirements gegevens bepalen en definiëren [28]. 6.2.1 Identificeren processen en actoren Men gaat na welke processen en welke actoren er juist plaatsvinden binnen de scoop van de te bepalen MVD. Men zal de rol van de actoren en hun uit te voeren taken definiëren. Zo kan men onderzoeken waar er verschillende uitwisselingsprocedures nodig zijn tussen de verschillende partijen en de opeenvolgende fasen [28]. 6.2.2 Identificeren uitwisselingprocedures Een volgende stap is het identificeren en lokaliseren van uitwisselingprocedures tussen de verschillende bedrijfsprocessen. Men gaat na tussen welke activiteiten er nood is aan informatie-uitwisseling en onderzoekt wat juist de uiteindelijke bedoeling is van deze uitwisseling. Men moet nagaan of de informatie al dan niet kan worden doorgespeeld via een BIM-model of via andere media (tabellen, uitvoeringsplannen, schetsen etc.). Het is ook belangrijk om weten wie de informatie moet leveren en aan wie deze uiteindelijk bezorgd moet worden [28]. 6.2.3 Creatie van de Exchange Requirements We gaan na welke informatie noodzakelijk is voor het realiseren van de bedrijfsprocessen. Het is belangrijk dat elke partij de informatie ontvangt die ervoor zorgt dat ze hun taak kunnen uitvoeren, niet meer of minder. Men zal voor de verschillende gebouwelementen hun specifieke gegevens en eigenschappen opzoeken die nuttig kunnen zijn voor het uitvoeren van

33

de taken. Ter verduidelijking is het interessant om een korte beschrijving te geven over de gewenste gegevens en op welke manier ze worden weergegeven (eenheden, datatype etc.). Men kan ook vermelden of de gegevens verplicht of optioneel zijn [28].

6.3 MVD-methodologie De technische implementatie start door de gekozen Exchange Requirements te plaatsen naar het respectievelijk IFC-schema, Exchange Requirements Models. Op deze manier kunnen de gegevens uitgedrukt worden in het befaamde IFC-model. Als laatste stap wordt de uiteindelijke MVD gecreëerd als deelverzameling van het volledige IFC-schema. Algemeen is het de bedoeling om weet te hebben hoe de informatie en het gebouwmodel wordt uitgewisseld en welke standaard en configuratie er gebruikt zal worden. Afhankelijk van de situatie is het al dan niet noodzakelijk om de laatste 2 stappen uit te voeren. Zoals te zien op Figuur 20 kan men ook afronden na de 3de IDM-stap of na de 1ste MVD-stap [28]. 6.3.1 Uitbreiden naar Exchange Requirements Models Voor elke gekozen Exchange Requirement (ER) zal men een uitwisselingsformaat kiezen. In ons geval is dat dus het IFC-formaat. Gebaseerd op de keuze van de Exchange Requirements zal men de elementen mappen naar hun representatie in het IFC-formaat. Men zal aandachtig moeten kijken naar de correcte representaties van de verschillende gebouwelementen. Het is namelijk niet eenvoudig om te weten welke elementen er allemaal onder welke bepaalde IFCentiteit vallen [28]. Ter illustratie zullen we een fictieve MVD bespreken waar men als Exchange Requirements enkele brandbeveiligingstoestellen met bepaalde eigenschappen gekozen heeft. Stel dat we een BIM-model hebben waarin een gebouw volledig is uitgewerkt maar een veiligheidsinspecteur heeft enkel nood aan het krijgen van informatie over het aantal sprinklers, haspels en brandkranen. Het is nu de bedoeling dat we het model gaan uitfilteren door de Exchange Requirements te bepalen. Aan deze Exchange Requirements zullen we dan de juiste IFC-types en -eigenschappen van deze brandbeveiligingstoestellen gaan koppelen in dit uitgewerkt voorbeeld type, debiet, lengte, drukklasse en kleur. Dit kunnen we verwezenlijken door gebruik te maken van de door BuildingSMART opgestelde index van IFC-types en -eigenschappen (Tabel 2) [21]. Tabel 2: Illustratie van het toekennen van IFC-klassen

34 6.3.2 Creatie van de uiteindelijke MVD Nadat men de Exchange Requirements heeft gekoppeld aan het IFC-data-uitwisselingsformaat kan de MVD gedefinieerd worden. Men kan echter ook eerst nagaan of de gekozen Exchange Requirements niet samen vallen met reeds gedefinieerde MVD’s. Indien dit het geval is kan men deze MVD’s gaan gebruiken of aanpassen [28].

6.4 Implementatie en gebruik Nadat de software geïmplementeerd wordt met de MVD kan men een certificering behalen. Dit is een soort kwaliteitscontrole zodanig dat men er vanuit mag gaan dat de implementatie op een correcte manier verliep. De gebruikers kunnen zo met voldoende betrouwbaarheid hun softwareprogramma’s en de beschouwde MVD gebruiken [28].

35

7 De rol van het studiebureau Het studiebureau treedt op doorheen het volledige architecturaal ontwerpproces en de uitvoeringsfasen. In de eerste plaats vervult het bureau een raadgevende functie. Men zal een analyse uitvoeren van de mogelijke problemen en hun oplossingsmethodologie bepalen. Daaropvolgend zal het bureau de nodige informatie verzamelen en deze eventueel laten beoordelen door externe deskundigen. Vervolgens zal men de ingezamelde gegevens verwerken, samenvatten en de bekomen resultaten analyseren. Ten slotte zal het studiebureau advies en een eigen interpretatie geven over de bekomen resultaten. Men zal de cliënt bepaalde aanbevelingen voorschotelen en deze eventueel ook doorvoeren [29][30]. Men moet ervan overtuigd zijn dat het gewenste resultaat zal bekomen worden. Zo zal men het gebouw en de betreffende installaties correct moeten gebruiken, beheren en onderhouden. De doelstellingen moeten correct ingeregeld, uitgevoerd en met doordachte kennis van zaken ontworpen zijn. Het is de bedoeling dat de systemen zo ontworpen, geïnstalleerd en getest worden dat ze in staat zijn om gebruikt en onderhouden te worden conform de verwachte prestaties. Het is dus duidelijk dat het studiebureau zal participeren tijdens de verschillende bouwfasen van het gehele bouwproces. In onderstaande tabel zien we deze opeenvolgende bouwfasen. De gele arcering toont aan welke bouwpartners tijdens welke fase van het bouwproces deelnemen. De blauwe arcering duidt de hoofdactiviteiten van de bouwpartners aan. We zien dus dat een studiebureau technieken zal deelnemen vanaf het voorontwerp tot de oplevering. Hun hoofdactiviteiten liggen echter wel tijdens het definitief ontwerp (Tabel 3). Tabel 3: De rol van de bouwpartners in de verschillende bouwfasen Bouwpartners Initiatiefase Voorontwerp

Definitief ontwerp

Bouwfasen Aanbestedings- Uitvoeringsfase fase

Oplevering

Gebruik- en onderhoudsfase

Sloop

Bouwheer Architect Studiebureau Aannemer EPB-verslagever

Tijdens de voorontwerpfase zal het studiebureau samen met de bouwheer en architect naar de best mogelijke oplossing kijken. Onderlinge communicatie en eenduidigheid zijn hier zeer belangrijk. Na het definitieve ontwerp zal het studiebureau de technische doelstellingen gerealiseerd hebben. Zo zal men uitvoeringsdetails, materiaalkeuzes, technische beschrijvingen etc. kunnen voorleggen aan de andere bouwpartners. Het studiebureau zal tijdens de aanbestedingsfase optreden als de raadgevende partij. Men zal advies verlenen naar de werfleider en aannemers voor betreffende uitvoeringen, werkwijzen, keuze van goed presterend materiaal en het eventueel bestuderen van alternatieven. Het studiebureau kan tijdens deze aanbestedingsfase ook nuttig zijn voor de bouwheer en de EPBverslaggever. Tijdens de oplevering van de werf blijft het studiebureau belangrijk. Zowel de bouwheer als de toekomstige gebruikers van het gebouw hebben bepaalde wensen, behoeften en verzoeken welke zouden moeten uitgevoerd worden. Men zal de garantie verzekeren dat de gestelde

36

doelstellingen nagekomen worden en uitkijken naar competenties door middel van de werf op de voet te volgen. Het studiebureau heeft tenslotte ook nog de mogelijkheid om een as-builtdossier voor te leggen van de geïnstalleerde technieken.

7.1 Bedrijfsprocessen van een studiebureau technieken Een studiebureau of ingenieursbureau technieken heeft als doel om klantgericht studie en advies te verlenen in de bouwsector, meer bepaald op het vlak van technische installaties. De diensten die verleend kunnen worden, gelden voor zowel architecten, installateurs, particulieren, bouwheer etc. Van bij de start van ieder project worden duidelijke afspraken gemaakt met de opdrachtgever; zowel op gebied van samenwerkingsovereenkomst als op gebied van de implementatie van technische uitrustingen. Hierbij wordt rekening gehouden met de eisen van de bouwheer en de architect en wordt alles duidelijk in kaart gebracht onder de vorm van plannen, schema’s en bestekken. Op deze manier weet de installateur exact hoe hij zijn installatie moet uitvoeren en zal de bouwheer een correcter beeld krijgen over de stand van zaken. De uiteindelijke uitvoering van de technische installaties wordt ter plaatste opgevolgd zodat er tijdig kan worden bijgestuurd indien er problemen of fouten optreden [29] [30]. Volgende technische studies kunnen geleverd worden door een studiebureau technieken : -

Verwarming, industriële verwarming en vloerverwarming Koeling en industriële koeling Klimatisatie en/of luchtbehandeling (bevochtiging, ontvochtiging) Industriële leidingen Warmtepompen Air Handling Units (AHU) Ventilatie en industriële ventilatie Air-conditioning Luchtverwarming Elektriciteit en industriële elektriciteit PV-cellen Data en telefonie Hoogspanning Inbraakbeveiliging Domotica Automatisering Sanitair (aanvoer en afvoeren) Hydraulische en pneumatische installaties

37

7.2 Het studiebureau en hun participanten -

De eigenaar van de woning, deze heeft een bepaald verzoek dat gerealiseerd moet worden rekening houdend met bepaalde randvoorwaarden zoals de eisen, budget, planning, etc. Architect, deze zal instaan voor het ontwerp van het gebouw. De architect speelt de geometrische structuur door naar het studiebureau en zal bepalen welke verschillende functionaliteiten de gebruikte ruimten zullen hebben.

-

Aannemer, deze heeft de resultaatsverplichting en zal leidinggevend zijn omtrent de uitvoering. De aannemer(s) moet rekening houden met de verschillende dimensies van zowel het gebouw als installaties zodanig dat men weet heeft waar men al dan niet voorzieningen moet voorzien voor de plaatsing van de installaties.

-

Toekomstige bewoners, deze zijn de uiteindelijke gebruikers van de woning. Ook zij hebben bepaalde behoeften en wensen die vervuld moeten worden. Hiernaast is het ook belangrijk dat de bewoners weten waar de technische installaties zich bevinden in de woning en heeft men ook nood aan technische knowhow indien er technische defecten zouden optreden.

-

Studiebureau voor bijzondere technieken, moeten bepaalde vragen, waarvan het betrekkende studiebureau geen weet heeft, invullen.

-

EPB-adviseur, deze zal instaan voor het berekenen van energieprestaties. Het studiebureau is genoodzaakt om gegevens omtrent thermische isolatie, energieprestatie en binnenklimaat door de spelen naar de EPB-verslaggever, zodanig dat deze het energieprestatiecertificaat (EPC) kan leveren.

7.3 Optimalisatie m.b.v. een MVD-model Indien men onderling samenwerkt met behulp van een BIM-model kan een architect zijn ontwerp afwerken en daaraan bepaalde informatie koppelen die in zijn ogen belangrijk zijn. Deze informatie zal niet voor elke participant even belangrijk zijn. Zo zal een studiebureau dat opgesteld is voor het berekenen van betonbalken het niet belangrijk vinden om te weten wat de U-waarden van de isolatie zijn. Maar voor een energieanalist zullen deze gegevens dan weer wel een noodzakelijke bron aan informatie vormen om hun werk tot een goed einde te kunnen brengen. Voor een studiebureau technieken geldt hetzelfde. Indien een studiebureau is aangesteld om sanitaire voorzieningen, HVAC-systemen, verwarming, ventilatie, elektriciteit etc. te modeleren voor een bepaald project, heeft men voldoende gegevens nodig om dit te kunnen verwezenlijken. De rol, plaatsing en deelnemende partijen voor een studiebureau technieken hebben we in voorgaande paragrafen aangehaald. Het gamma aan te berekenen technieken is dus zeer breed. Zodus zal de nodige, te ontvangen informatie ook zeer uitgebreid zijn. Om deze verschillende informatie te verzamelen moet men weten hoe de informatieoverdracht zal gebeuren en meer bepaald met welk medium. Zo zal een architect gebruik kunnen maken van een BIM-model, maar een bouwheer of aannemer zullen minder snel grijpen naar het werken

38

met zo een model en zullen hun eisen en wensen eerder doorspelen via verbale- of schriftelijk communicatie. Normaliter is het de bedoeling dat de gegevensuitwisseling tussen de verschillende participanten informatie voorziet voor het bepalen van al deze technieken. Bijvoorbeeld bij de onderlinge interactie tussen architect en een studiebureau technieken, is het de bedoeling dat de architect het studiebureau voorziet van voldoende informatie om hun werk te kunnen uitvoeren. Zo zal het handig zijn om te weten welke bouwmaterialen en hun U-waarden gebruikt werden. Men kan dan warmteverliezen berekenen die op hun beurt interessant kunnen zijn voor het dimensioneren van verwarming of koeling. Om een ventilatiesysteem te kunnen dimensioneren, is het belangrijk om te weten welke type ruimtes er gebruikt worden en waar deze zich bevinden. Voor het uitzetten van de elektriciteit is het dan weer nuttig om te weten waar een telefoon, televisie of computer zal worden geplaatst. Het is dus duidelijk dat voor elke installatie een bepaald aantal gegevens nodig zijn die niet bepaald noodzakelijk zijn voor andere installaties. In volgende paragrafen zullen we onderzoeken wat de noodzakelijke gegevens en informatiebronnen zijn voor het dimensioneren van een ventilatiesysteem. Dit is slechts een deelaspect van wat een studiebureau technieken in de praktijk zal uitvoeren. Het is de bedoeling om een basis te vormen voor het ontwikkelen van MVD die ervoor zorgt dat de onderlinge samenwerking tussen architect en studiebureau technieken, meer bepaald voor de ontwikkelen van het ventilatiesysteem, geoptimaliseerd wordt. De MVD zal ervoor zorgen dat het betreffende studiebureau het ventilatiesysteem kan berekenen met behulp van de gekregen informatie van de architect. De plaatsing van het ventilatieontwerp tijdens de volledige bouwcyclus start tijdens het voorontwerp, maar vindt vooral plaats tijdens het definitief ontwerp (Figuur 21). Tijdens het voorontwerp zal men een bepaald ventilatiesysteem kiezen en schetsen. Dit zal men dan voorleggen aan de vragende partijen en de eventuele problemen en suggesties aanvullen. In het definitief ontwerp zal het ventilatiesysteem volledig ontworpen worden. Tijdens deze fase moet alles duidelijk zijn en er mogen geen vragen meer zijn omtrent de uitvoering (zie 4.2.1 Bouwfasen). Verder zal het studiebureau ook nog een meer bescheiden rol spelen tijdens de uitvoeringsfase en de opleveringsfase. Het zal dan namelijk uitvoeringsplannen, technische handleidingen en asbuilt dossiers moeten kunnen voorleggen.

Figuur 21: Ventilatieontwerp in het globale bouwproces (grijs)

39

8 MVD architecturaal ontwerp naar ventilatie Om een procesbeschrijving te kunnen definiëren en documenteren, is het gebruikelijk om de Information Delivery Manual van BuildingSMART te volgen. Het IDM-concept is een uitgeschreven verduidelijkende richtlijn die ons helpt om de juiste werkprocessen en actoren te beschrijven en vormt een noodzakelijke basis voor de uiteindelijke MVD. De IDMmethodologie is opgebouwd uit verschillende opeenvolgende basisdefinities [4].

8.1 Process Model In een Process Model of Process Map wordt een bepaald werkproces verduidelijkt. Het doel van de uit te voeren taken wordt aangehaald. De gebruiksmiddelen en noodzakelijke inputen outputgegevens worden beschreven. Het aantal activiteiten en hun volgorde worden aangehaald. Het is dus de bedoeling dat we voor een bepaald werkproces de grenzen zullen afbakenen, de onderliggende activiteiten vastleggen en tenslotte kiezen we de nodige Exchange Requirements om de activiteiten te ondersteunen. De opbouw van een Process Map ziet er als volgt uit [4]: -

Overview, in deze sectie wordt het globaal proces samengevat en eventueel geïllustreerd door middel van een figuur of grafiek. Met behulp van een korte beschrijving over de Process Map wordt duidelijk gemaakt waar de scoop van de MVD juist ligt. Het is de bedoeling om de Process Map te beschrijven op een niet te technische manier. Het is gericht naar de uiteindelijke gebruiker en niet naar de softwareontwikkelaar. De Overview moet zeker antwoord geven op volgende vragen:    

Welk onderwerp is betrokken in het proces? Wanneer is het proces relevant? In welke verschillende bouwfasen vindt het plaats? Welke partijen zijn betrokken in het proces?

-

Specification of Process, hier zullen alle processen uit de Process Map geïdentificeerd en beschreven worden. Deze worden dan weer gegeven met behulp van een grafiek waar men een duidelijk beeld schept over de onderlinge relaties [31-32] . Het maakt niet uit hoe uitgebreid de processen beschreven worden, zolang de boodschap maar duidelijk overkomt naar de gebruiker.

-

Specification of Data Objects, onder Data Objects verstaan we een verzameling aan data welke geëxporteerd of geïmporteerd worden naar de Process Map. Voor elk Data Object dat geen Exchange Requirement is, wordt er een korte beschrijving en plaatsing verwacht. Hierin vermeld men wat het Data Object inhoudt en wat ermee bereikt kan worden. Deze Data Objects verschillen met de Exchange Requirements aangezien deze informatie niet samenhangt met het BIM-model. De informatieoverdracht wordt gerealiseerd via een ander medium. Zo zal een aannemer of bouwheer informatie willen ontvangen welke zij kunnen bekijken zonder de nodige

40

software. Dit kan bijvoorbeeld onder de vorm van tabellen, grafieken, tekst en plannen. -

Specification Of Exchange Requirements, een Exchange Requirement is een bepaald type van data in de Process Map dat gelokaliseerd is in het informatie model (BIMmodel). De omschrijving van een Exchange Requirement gebeurt uitgebreider in vergelijking met de standaard Data Objects.

-

Specification Of Decision or Coordination Point Gateways, een Coordination Point Gateway is een punt tijdens het proces waar informatie samengebracht wordt. Deze informatie wordt dan vergeleken en uiteindelijk zal men een beslissing nemen over welke actie(s) men nadien zal uitvoeren.

8.1.1 Overview Een studiebureau technieken is betrokken bij het realiseren van heel wat technische installaties in een gebouw. Zowel tijdens de ontwerpfasen, constructiefasen als tijdens de asbuiltfase kan er beroep worden gedaan op het advies en diensten van het studiebureau. Tijdens de ontwerpfasen zijn er belangrijke interacties tussen zowel bouwheer, architect en studiebureau. Men moet vooraf kunnen verzekeren dat er geen problemen zullen optreden tijdens latere fasen. Het studiebureau zal tijdens de constructiefase de betreffende uitvoeringen op de voet volgen en eventueel bijsturen waar nodig. Tenslotte zal men tijdens de as-builtfase voldoende informatie moeten voorzien naar de uiteindelijke gebruikers. Volgende figuur toont aan waar dus de scoop van deze MVD ligt (Figuur 22). Praktisch gezien is het zo dat een studiebureau technieken aangesteld wordt om alle technische installaties voor een gebouw te dimensioneren en ontwerpen. Het zou dus ideaal zijn dat men een MVD opstelt waarbij al de noodzakelijke gegevens voor het bepalen van deze verschillende technieken kunnen geleverd worden. In volgende aanhalingen zullen we ons echter focussen op het berekenen van één van deze systemen, namelijk: een ventilatiesysteem. Met andere woorden: de scoop van de MVD wordt dus verkleind.

Figuur 22: Scoop MVD

Tijdens de ontwerpfasen is het dus de bedoeling dat het betreffende studiebureau gegevens ontvangt waarbij zij dan uiteindelijk het ventilatiesysteem mee kunnen gaan dimensioneren. Hetzelfde wordt verwacht van het studiebureau zelf. Zij zullen gebruiksvriendelijke

41

informatie, omtrent het gekozen ventilatiesysteem, moeten voorzien voor de uitvoerende en beherende partijen. De MVD gebruikt als input volgende data: -

Basis projectgegevens zoals de naam, het adres, het gebouwtype etc. Gebouwgeometrie Gebouworiëntatie Weergave van de binnen- en buitenmuren, vloeren, daken etc. Weergave van de ramen, deuren en openingen Functie en type van de verschillende ruimte Aantal en type van de (warmte afgevende) toestellen binnenin de ruimtes (pc’s, projectoren, ovens, douche, fornuizen etc.)

De output resultaten zijn volgende data: -

Type ventilatiesysteem dat gekozen werd Aantal en type roosters dat gekozen werd Gebruikelijke luchtkanalen (dimensies) Regelbare toevoer- of afvoeropeningen in vensters of deuren Uitvoeringsplannen voor plaatsing en eventuele nazorg mogelijkheden Technische fiches van de gebruikte toestellen Gebruikelijke debietinstellingen Systeemkost, elektriciteitsverbruik, ventilatieverliezen, energierecuperatie …

8.1.2 Process Diagram

42

Figuur 23: Proces Diagram

43 8.1.3 Specification of Proces 8.1.3.1 Klaarmaken gebouwenmodel voor ventilatieontwerp Type Documentatie

Taak Men gaat ervan uit dat de architect een afgewerkt gebouwenmodel met alle gebruikelijke gebouwelementen heeft ontworpen. Dit model geeft een voorlopig voorstel weer van het gebouw, inclusief de afmetingen en plaatsing van de functionele en niet-functionele ruimten. Het gebouwenmodel zou beeld moeten scheppen over: -

3D geometrie van het gebouw Gebouw oriëntatie Weergave van de binnen- en buitenmuren, vloeren, daken etc. Weergave van de ramen, deuren en openingen De ligging en oriëntatie ten opzichte van het noorden Informatie over de verschillende type ruimtes …

In deze fase zal men het gebouwenmodel klaarmaken voor het studiebureau zodanig dat deze met een zo efficiënt mogelijke bron aan informatie, het ventilatiesysteem kan bepalen. Het komt erop neer dat men met behulp van de MVD het model zodanig zal uitfilteren waardoor onnodige gegevens achterwege gelaten worden. Om ventilatieberekeningen uit te voeren is het niet nodig om gegevens betreffende interieur of afwerking te ontvangen. Met behulp van de MVD kan men doelgericht informatie delen. 8.1.3.2 Exporteren naar IFC-model Type Documentatie

Taak Eens het model is voorbereid op de ventilatieberekeningen, gaat men het exporteren naar het IFC-formaat.

8.1.3.3 Valideren ER ventilatiemodel Type Documentatie

Taak Met behulp van de MVD wordt er verzekerd dat de doorgestuurde gegevens kunnen gebruikt worden in verdere berekeningen. Men moet echter het model gaan valideren en nakijken of er eventueel fouten of gebreken in staan. Indien dit het geval is, zal men de architect hierover aanspreken en hem op de fouten toewijzen. Ingeval er geen fouten of problemen worden opgemerkt zal men met het model verdere stappen realiseren.

44 8.1.3.4 Analyseren van de gegevens Type Documentatie

Taak In deze taak gaat men aan de hand van verschillende informatiebronnen (naast het BIM-model) opzoek naar verschillende gegevens die bepalend kunnen zijn voor het bepalen van het uiteindelijke ventilatiemodel. -

Inplantingsplan en omgeving, men zal nagaan over welk type woning men de ventilatieberekening zal maken. Ook hinderlijke bronnen in de nabije omgeving kunnen bepalend zijn zoals rookgassen, buren, drukke omgeving, vervuilde lucht etc.

-

Gebouwenschil, men gaat na hoe luchtdicht de desbetreffende woning is.

-

Technieken, men gaat na welke toestellen er worden gebruikt. Zijn er risico’s op CO-vergiftiging en andere gevaren? Wat voor type toestellen worden er gebruikt (open/gesloten, toevoer van de verbrandingslucht, rookafvoer, onderdrukken etc.).

-

Planning, men zal op voorhand nagaan hoe en wanneer het systeem zal gerealiseerd worden. Gebeurt de realisatie al dan niet in fasen?

-

Budget, men gaat na wat het budget is voor de ventilatievoorzieningen in samenspraak met architect en bouwheer.

-

Regulatie, men gaat na wat de regulaties zijn omtrent het ventilatiesysteem. Welke eisen worden er opgesteld van hogere instanties? Hierbij bedoelen we bijvoorbeeld de minimum opgelegde ventilatiedebieten.

8.1.3.5 Ventilatiesysteem kiezen Type Documentatie

Taak Hier zal men een keuze maken voor welk systeem er wordt gekozen (systeem A,B,C of D). De keuze van het ventilatiesysteem gebeurd vroeg in het bouwproces en is vaak een persoonlijke keuze van de opdrachtgever. Het studiebureau zal advies geven bij de systeemkeuze. Afhankelijk van verschillende factoren zoals natuurlijke of mechanische toevoer en/of afvoer kan men deze keuze maken, rekening houdend met verscheidene aandachtspunten zoals risico’s op onvoldoende luchtkwaliteit, tocht, geluidsoverlast, geluidshinder van de omgeving, inwendige condensatie, systeemkost, elektriciteitsverbruik, ventilatieverliezen, energierecuperatie etc. [31-32].

45

8.1.3.6 Dimensioneren Type Documentatie

Taak Het ventilatiesysteem zal hier volledig worden gedimensioneerd. De taakomschrijving Dimensionering bestaat uit een aantal verschillende onderliggende processen die ook een bepaald stramien volgen, weliswaar afhankelijk van het type ventilatiesysteem [31-33] . -

Bepalen van de ontwerpdebieten, met behulp van de minimumdebieten (zie 8.1.3.4 Analyseren van de gegevens en 8.1.4.6 Regulering) worden de ontwerpdebieten vastgelegd. Meestal liggen deze ontwerpdebieten hoger dan de minimumdebieten. Vervolgens stelt men een balans op van de toe- en afvoerdebieten per ruimte en de doorstroomdebieten.

-

Kiezen van een regelstrategie, er worden keuzes gemaakt omtrent manuele bediening, kloksturing, aanwezigheidsdetectie, CO2-detectie etc.

-

Dimensioneren en keuze van natuurlijke toevoeropeningen en toevoerkanalen, afhankelijk van debietcapaciteit, producteigenschappen, plaatsing, onderhoudsbaarheid, luchtdichtheid etc.

-

Dimensionering en selectie van natuurlijke afvoeropeningen en afvoerkanalen, afhankelijk van de capaciteit, producteigenschappen, luchtdichtheid etc.

-

Dimensionering en selectie van de doorstroomopeningen, men bepaald de doorstroomopeningen tussen ‘natte’ en ‘droge’ ruimtes.

-

Ontwerp en dimensionering van het mechanisch distributienetwerk, hier zal men de ventilatiegroep, ligging van systeemcomponenten, ligging van de tracés en de diameter van de kanalen bepalen (systemen B, C en D).

-

Selecteren van de ventilator of ventilatorgroep en definitieve keuze van de componenten.

8.1.3.7 Valideren keuze ventilatiesysteem Type Documentatie

Taak Hier gaat men na of het gekozen ventilatiesysteem voldoet voor de bouwheer. Men zal het ventilatiesysteem voorleggen en aankaarten. Indien het gekozen systeem niet voldoet aan de wensen van de bouwheer, zoals bijvoorbeeld een te dure installatiekost is of een te hoog verbruik, zal men

46 zoeken naar een andere oplossing. 8.1.3.8 Voorbereiding uitvoeringsfase Type Documentatie

Taak Tijdens dit proces zal men informatie bundelen over de te plaatsen installatie. Zo kunnen bijvoorbeeld technische fiches en liggingsplannen een duidelijk beeld scheppen voor de taken van de aannemer en installateur. Het is de bedoeling dat het studiebureau voldoende informatie kan voorzien voor de uitvoerende partijen.

8.1.3.9 Uitvoeringen ruwbouw Type Documentatie

Taak Tijdens dit proces wordt er verwacht van de aannemer om voorbereidingen te treffen in de ruwbouw met betrekking op de latere installatiemogelijkheden van het ventilatiesysteem. Concreet kan de aannemer bijvoorbeeld een uitsparing voorzien in de muur daar waar later een luchtkanaal zal moeten worden geïnstalleerd.

8.1.3.10 Installeren Type Documentatie

Taak Gedurende deze taak zal men het ontworpen ventilatiesysteem installeren. Voor het uitvoeren van deze taak zal de installateur installatiegegevens nodig hebben van het studiebureau (zie 8.1.4.10 Installatiegegevens).

8.1.3.11 Voorbereiden as-builtfase Type Documentatie

Taak Het studiebureau zal het ventilatiemodel aanpassen zoals ze zijn uitgevoerd op de werf. Meestal zijn er aanzienlijke verschillen met het ontwerp en de uiteindelijk installatie. Het studiebureau zal de uitvoeringsplannen zo nauwkeurig mogelijk aanpassen en aanvullen met de nodige gegevens. Indien dit gerealiseerd is, kan men het as-builtdossier klaarmaken en doorspelen naar de uiteindelijke gebruiker(s).

8.1.3.12 Onderhouden Type

Taak

47 Documentatie

Hier zal de bouwheer genoodzaakt zijn om het ventilatiesysteem te onderhouden, met behulp van de informatie die het studiebureau en de aannemer(s) hebben doorgespeeld (zie 8.1.4.12 Onderhoudsgegevens). Op deze wijze kan men bijvoorbeeld te weten komen waar en wanneer er ventilators of ventilatieroosters gereinigd moeten worden.

8.1.4 Specification of Data Objects 8.1.4.1 Opmerkingen 1 Type Documentatie

Data Object Nadat het studiebureau het BIM-model heeft doorgekregen, zal men het gaan controleren op onduidelijkheden of beperkingen. Indien er opmerkingen gevonden worden over het te bestuderen model zal men deze terug doorspelen naar de architect. De architect zal aan de hand van die gegevens het model aanpassen en later terug doorsturen.

8.1.4.2 Planning Type Documentatie

Data Object De bouwplanning zorgt voor een bepaalde richtlijn: hoe een bouwproject zou moeten verlopen in de tijd, productie en geld. Men zal op voorhand afspraken, leveringen, werkzaamheden en processen afspreken zodanig dat het bouwproces optimaal kan verlopen. Een studiebureau technieken zal strikt rekening moeten houden met de bouwplanning. Zo zullen er tijdslimieten zijn vastgesteld waarvan men verwacht dat het werk binnen die tijdslimiet gerealiseerd wordt.

8.1.4.3 Budget Type Documentatie

Data Object Hierin wordt het budget aangehaald dat men voorziet voor het ventilatiesysteem. Het is de bedoeling dat het studiebureau een systeem bepaalt dat niet boven dit budget uitreikt. De gekozen installaties hangen dus nauw samen met het vooraf bepaalde budget.

8.1.4.4 Inplantingsplan Type Documentatie

Data Object Een inplantingsplan geeft duidelijk weer hoe een gebouw is opgesteld in de naaste omgeving. Het inplantingsplan is altijd op schaal getekend en bevat een verduidelijkende legende. Het is de bedoeling dat de impact van de omgeving op het gebouw, en omgekeerd, kan worden ingeschat. Een inplantingsplan bevat naastliggende gebouwen en eventueel hun functie, begroeiingen, (openbare) wegen, grachten en hindernissen. Met dit plan

48 kan het studiebureau rekening houden voor het ontwerp van het ventilatiesysteem. Zo kan men bijvoorbeeld kijken naar geur- en geluidsbronnen in de nabije omgeving. 8.1.4.5 Speciale technieken Type Documentatie

Data Object Met deze data bedoelen we de verzameling aan informatie omtrent speciale technieken die zullen geïnstalleerd worden in het gebouw. Onder speciale technieken verstaan we bepaalde installaties die de luchtkwaliteit (COuitstoot, warmte, geuren etc.) drastisch kunnen veranderen.

8.1.4.6 Regulering Type Documentatie

Data Object Onder regulering verstaan we de verzameling aan gegevens omtrent wetmatigheden, eisen en regulaties van de plaatselijke instanties. Deze regulering hangt samen met de ligging en het type van de woning dat men bestudeert: residentieel, niet-residentieel of renovatie. Met betrekking tot de regulering kan men zich o.a. deze vragen stellen: -

Welke eisen worden er gesteld aan de verschillende ventilatie componenten? Welke eisen worden er opgelegd omtrent hygiëne en gezondheid? Hoe worden de basisdebieten bepaald en begrensd? Wat zijn de opgelegde eisen voor het volledige ventilatiesysteem? Wat zijn de eisen omtrent de uiteindelijke uitvoering?

In België voorziet de regelgeving op de energieprestaties van gebouwen (EPB) regulaties in verband met ventilatie [31-33]. 8.1.4.7 Voorlopig resultaat ventilatieontwerp Type Documentatie

Data Object Nadat men het ventilatiesysteem heeft ontworpen, zal men dit voorstel voorleggen aan de bouwheer (en eventueel aan de architect en/of aannemer(s)). Men zal aan de hand van voorlopige uitvoeringsplannen, bestekken, technische fiches, raming etc. het systeem bestuderen. Indien er problemen of opmerkingen aan het licht komen, zullen deze terug doorgespeeld worden naar het studiebureau. Bij goedkeuring van het gedimensioneerde systeem zullen verder stappen doorgevoerd worden.

49

8.1.4.8 Opmerkingen 2 Type Documentatie

Data Object Nadat het studiebureau een voorstel van het ventilatiesysteem heeft voorgelegd, zal de bouwheer dit model nakijken. In Opmerkingen 2 komen de opmerkingen, verdere eisen en eventuele suggesties voor aanpassingen van de bouwheer.

8.1.4.9 Uitvoeringsgegevens Type Documentatie

Data Object Het betreffende studiebureau zal genoodzaakt zijn om de aannemer te kunnen informeren over de te plaatsen installatie. Zo zal men een overzicht krijgen over op welke plaatsen men rekening moet houden met het ventilatiesysteem. De gegevens kunnen nuttig zijn voor eventuele uitsparingen in binnen- en buitenmuren, voor regelbare toevoer- en afvoerkleppen en voor het schrijnwerk. Ook voor de coördinatie en werfplanning kunnen de gegevens gedienstig zijn. Deze gegevens zorgen ervoor dat de aannemer(s) goed geïnformeerd zijn omtrent de ligging van het systeem. Zodanig dat ze rekening kunnen houden met de ventilatievoorzieningen: -

Uitvoeringsplannen Bestek Aanbestedingsdossier …

8.1.4.10 Installatiegegevens Type Documentatie

Data Object De installateur heeft, net zoals de aannemer(s), ook nood aan gegevens omtrent de ligging en dimensionering van het systeem. Naast dezelfde uitvoeringsgegevens als voor de aannemer zal de installateur ook gegevens nodig hebben die niet belangrijk zijn voor de aannemer. Informatie betreffende de in te stellen debieten, ligging van specifieke ventilatiecomponenten etc. zijn onder meer specifieke gegevens voor de installateur. Naast de uitvoeringsgegevens zal deze informatie de installateur ook helpen bij de installatie van het ventilatiesysteem: -

Basisinstellingen

50 -

Handleidingen Gegevens van fabrikanten en leveranciers …

8.1.4.11 Opmerkingen 3 Type Documentatie

Data Object De werkelijke uitvoering van het systeem verloopt meestal anders dan dat ze getekend is op de uitvoeringsplannen. Wijzigingen worden terug doorgespeeld 3 naar het studiebureau zodanig dat zij de uitvoeringsplannen kunnen aanpassen (as-builtplannen).

8.1.4.12 Onderhoudsgegevens Type Documentatie

Data Object Deze informatie helpt de uiteindelijke gebruiker bij het onderhouden van het systeem. Het is de bedoeling om de gebruiker te informeren omtrent de verschillende gebruikte componenten, de basisinstellingen, de onderhoudsmogelijkheden etc. Onder deze informatie vindt men o.a. volgende zaken: -

Technische fiches Uitvoeringsplannen As-built plannen Handleidingen Gegevens van fabrikanten en leveranciers

8.1.5 Specification Of Exchange Requirements 8.1.5.1 ER_Ventilatie Type Documentatie

Data Object Hierin staan alle noodzakelijke gegevens die de architect kan leveren voor het bepalen van het ventilatiesysteem. Zonder deze input aan informatie zal het studiebureau niet instaat zijn om het systeem te dimensioneren. Deze data-uitwisseling tussen architect en studiebureau gebeurt door middel van het BIM-model. De MVD zal hierop worden gebaseerd.

51 8.1.6 Specification of Decision Gateways 8.1.6.1 Ontwerpeisen OK? Type Documentatie

Decision Gateway Het studiebureau gaat na of de ontwerpgegevens voldoen aan zijn eisen. Indien deze niet voldoen, wordt de architect opgelegd om zijn ontwerp anders te modelleren.

8.1.6.2 Systeem OK? Type Documentatie

Decision Gateway In samenspraak met de bouwheer (en eventueel architect en aannemer(s)) zal men het ontworpen systeem al dan niet goedkeuren.

52

8.2 Exchange Requirements De informatie-uitwisseling van de architect naar het studiebureau via een BIM-model moet er voor zorgen dat het studiebureau het ventilatieontwerp kan uitvoeren met de nodige gegevens. Deze uitwisselingsgegevens (8.1.5.1 ER_Ventilatie) zullen zich in deze fase vooral spiegelen als gegevens omtrent gebruikte gebouwelementen, ruimtes en gebouwgeometrie. De gegevens van de architect die belangrijk zijn voor het ontwerpen van een ventilatiesysteem bestaan uit: -

De naam, adres, eigenaar, type etc. van het project. De geometrie van het gebouw inclusief maten (lengtes, oppervlaktes, volumes, etc.) zodanig dat men verschillende planzichten kan genereren en bestuderen. Identificatie en geometrie (oppervlakte) van de verschillende ruimtes zodanig dat men weet heeft over de grootte en functie van elke ruimte is. Weergave van de basis gebouwelementen zoals de muren, daken, vloeren, ramen, deuren etc. Ligging van de ramen, deuren en openingen zodanig dat men eventueel rekening kan houden met de plaatsing van regelbare toevoer- en afvoeropeningen. Weergave van de isolatie zodanig dat men weet welke ruimtes al dan niet tot het beschermd volume behoren.

Project Stage

0 1 2 3 4 5 6 7 8 9 10

Portfolio requirements Conception of need Outline feasibility Substantive feasibility Outline conceptual design Full conceptual design Coordinated design and procurement Production information Construction Operation and maintenance Disposal

 

53 Type van informatie Project/gebouw informatie Project

Site Gebouw

Eenheden

Classificatie Ruimtelijke informatie Ruimtes (spaces)

Noodzakelijke informatie

Verplicht

Identificatie Eigenaar/client information Model auteur Aanmaakdatum Adres Hoogteligging van het terrein Identificatie Globale coördinaten Classificatie Orientatie ten opzichte van het noorden Hoogteligging (tegenover de hoogteligging van het terrein) Lengte eenheid Oppervlakte eenheid Volume eenheid Classificatie

X

Identificatie Beschrijving Classificatie Binnen- of buitenruimte Voorwaarden voor de ruimtes 3D geometrie Ruimte lengte Ruimte breedte Ruimte hoogte Ruimte oppervlak Ruimte netto volume

X

Optioneel

X X X X X X X X X X X X X

X

Gebouwelementen informatie muur (binnen of buiten), dak, Identificatie vloer, verlaagd plafond, trap Locatie etc. Beschrijving (type, opbouw) 3D geometrie Ramen Identificatie Locatie Beschrijving (type) 3D geometrie Raam lengte Raam breedte Raam hoogte Deuren Identificatie Locatie Beschrijving (type) Deurkieroppervlakte 3D geometrie Deur lengte Deur breedte Deur hoogte Opening Identificatie Locatie 3D geometrie Douche, bad, dampkap etc. Identificatie Locatie 3D geometrie

X X X X X X X X

X X X X X X X X X X X X X X X X X X X X X X X X X

X

X

54 Bovenstaande data kan door softwareontwikkelaars gebruikt worden om een Exchange Requirments Model op te stellen (zie 8.3 Exchange Requirements Model) en hieruit later de MVD te ontwikkelen en implementeren (zie 8.4 MVD Diagrams).

8.3 Exchange Requirements Model De laatste fase van de IDM-methodologie is het opstellen van het Exchange Requirements Model (ERM). Het Exchange Requirements Model is een grafische weergave van de Exchange Requirements. In deze grafische weergave wordt duidelijk weergegeven welke datagegevens (Exchange Concepts) zullen uitgewisseld worden en wat de onderlinge relaties zijn. Wanneer men het ERM dan uiteindelijk heeft opgesteld, kan men beginnen met de ontwikkeling van de MVD die dan in de software kan geïmplementeerd worden. Een ERM-diagram dient als een technische implementatie van de Exchange Requirements. De uitwisselingsgegevens in het ERM worden weergegeven onder Generic Concepts. Men onderscheidt hieronder de variabele concepten en de statische concepten. Een statisch concept zal een corresponderende IFC-entiteit hebben en een variabel concept is opgebouwd uit verscheidene statische concepten. In Figuur 24 zien we de basisopbouw van de Generic Concepts uit een ERM. De statische concepten worden weergegeven in het lichtblauw en de variabele in het donkerblauw. We merken op dat elk variabel concept in verschillende diagrammen dezelfde naam heeft, maar hun onderliggende statische concepten kunnen wel verschillen. Dit maakt het mogelijk om gebouwelementen voor te stellen op verschillende manieren met verschillende eigenschappen.

Figuur 24: Basisopbouw ERM Diagrams [36]

Ter verduidelijking zullen we twee reeds bestaande MVD’s aanhalen. We bekijken een MVD die de gegevens voorziet van het architecturaal ontwerp naar energieanalyseberekeningen (Figuur 25) en vervolgens een MVD die de gegevens voorziet naar het analyseren van de veiligheid binnen een gebouw (Figuur 26). We vergelijken het variabel concept ‘Wall’. Zo zullen er bij het ERM van de energieanalyseberekening statische concepten worden toegevoegd omtrent fotovoltaïsche eigenschappen van de muur. Voor de veiligheidsanalyse zijn deze gegevens overbodig. Echter, zullen hier wel gegevens omtrent hoogte, breedte en dikte van de muur worden bijgevoegd. Het type muur en de geometrie worden dan weer wel weergegeven in beide ERM’s. Merken we ook op dat er bepaalde statische concepten lichtgrijs gearceerd zijn. Dit betekent dat deze concepten optioneel zijn en dus niet noodzakelijk moeten worden doorgegeven. Indien deze toch worden meegegeven, kan dit enkel een meerwaarde geven voor de uit te voeren activiteit. Zo zullen waarden omtrent gebruikte type materialen in de muur verplicht zijn bij de energieanalyse, maar optioneel voor de veiligheidsanalyse.

55

Figuur 25: Variable Concept Wall van de Architectural Design to Building Energy Analysis MVD [27]

Figuur 26:Variable Concept Wall van de Architectural Design to Circulation/Security Analysis MVD [27]

56

Een Exchange Requirements Model is dus opgebouwd uit een verzameling van Exchange Concepts. Met behulp van de ERM kunnen we deze uitwisselingspakketten implementeren in de software. Deze worden MVD Concepts genoemd. Men zal de Exchange Concepts binden met de passende IFC-entiteiten. Zodus zijn de Exchange Concepts, op ERM niveau, onafhankelijk van elke IFC Model View Definition. Een MVD wordt gecreëerd door een groep van concepten te definiëren waarbij men de onderlinge relaties tussen de concepten vastlegt. Een belangrijk mechanisme bij het bepalen van een ERM is het feit dat de verschillende pakketten uitwisselingsinformatie (ofwel concepten) hergebruikt kunnen worden (Reusable Exchange Concepts). Bij het creëren van een ERM is het dus mogelijk om vooraf gedefinieerde concepten op te halen en te hergebruiken. Er zijn reeds enkele tools ontworpen die het ontwikkelen van een MVD vereenvoudigen. Een voorbeeld van zo een tool is de BLIS-toolkit. Deze toolkit kan nagaan welke concepten al dan niet eerder werden gedefinieerd.

Figuur 27: Relatie tussen ERM en MVD Diagrams [36]

De ERM zijn bedoeld als een leesbare versie van de gedefinieerde benodigdheden uit de IDM-methodologie. Het ERM-diagram bepaalt de scoop van uitwisselingsdata over bepaalde variabele concepten. MVD Concepts en MVD Diagrams beschrijven hoe de Exchange Concepts uit het ERM geïmplementeerd kunnen worden in software. ERM Diagrams worden altijd weergegeven in blauw en moeten verstaanbaar zijn voor de bedrijfsparticipanten, mensen die geen weet hebben van de IFC-entiteiten of software implementaties. MVD Diagrams worden altijd weergegeven in het oranje en zijn gericht naar softwareontwikkelaars (Figuur 27).

57

8.4 MVD Diagrams MVD Concepts maken het mogelijk om Exchange Concepts uit het ERM te realiseren in software. De MVD Diagram definieert alsook de scoop van wat moet worden uitgewisseld. Voor elk Exchange Concept in de ERM bestaat er één of meerdere MVD Concepts die definiëren hoe de data die beschreven zijn in die Exchange Concept zal geïmplementeerd worden in de software (Figuur 28).

Figuur 28: Basisopbouw MVD Diagrams [36]

De MVD Concepts definiëren hoe hun respectievelijke Exchange Concepts zal gebonden worden aan de specifieke IFC-entiteiten. Zij kiezen dus hoe het IFC-model zal gebruikt worden om de nodige gegevens uit te wisselen. Zo zal men bijvoorbeeld kiezen dat een label uitgewisseld wordt door gebruik te maken van het IFC-object IfcLabel. Ook bij de MVD Concepts wordt beroep gedaan op het hergebruiken van reeds gedefinieerde concepten. Dit helpt de softwareontwikkelaar aanzienlijk. Men kan gebruik maken van reeds aangemaakte concepten zodat dubbelwerk vermeden wordt. Ook heeft elke MVD een kleine, samenvattende beschrijving. Zodanig dat men bij het ontwikkelen van een nieuwe MVD kan nagaan of z’n MVD al dan niet bestaat. Indien men gelijkenissen vindt met een andere MVD, maar deze toch niet geheel dezelfde zijn, kan men ook een bestaande MVD aanvullen of bewerken. Een voorbeeld van een HVAC MVD-binding kan men hieronder terugvinden (Figuur 29: Voorbeeld HVAC MVD Diagram uit de Concept design to building energy Analysis MVD.

Figuur 29: Voorbeeld HVAC MVD Diagram uit de Concept design to building energy Analysis MVD [27]

58 Elk MVD Concept of binding heeft een Instantiation Diagram. Hierin worden de verschillende IFC-entiteiten bevestigd, samen met hun onderlinge relaties. De entiteiten die in het geel gemarkeerd zijn hebben extra implementatieafspraken. Deze Implementation Agreements zeggen ons iets meer over hoe bepaalde entiteiten aangehaald worden (Figuur 30).

Figuur 30:Instantiation Diagram en implementatieafspraken [27]

59

9 Enkele aandachtspunten 9.1 Gebouwtype Eerder werden de participanten, taken, uitwisselingsgegevens, uitwisselingsformaten en plaatsing binnen de verschillende bouwfasen besproken van een MVD van architecturaal ontwerp naar ventilatie. Er werd echter nog niet stil gestaan bij welk type gebouw men een ventilatieberekening kan uitvoeren. Er kan in België namelijk onderscheid gemaakt worden tussen een ventilatieberekeningen voor residentiële en niet- residentiële gebouwen. Doordat er onderscheid gemaakt wordt tussen het ventilatieontwerp voor deze verschillende gebouwtypes, zal men andere wetmatigheden, eisen of aanbevelingen (zie 8.1.4 Specification of Data Objects) gebruiken. Bij residentiële gebouwen, zoals woningen of appartementen, zal gebruik gemaakt worden van de Belgische norm NBN D 50-001. Voor niet-residentiële gebouwen zoals ziekenhuizen, scholen, industriële gebouwen etc. wordt gebruik gemaakt van de Europese norm NBN EN 13779 [31- 33]. In België bepaalt de EPB-regelgeving bijvoorbeeld de minimum ontwerpdebieten. Voor residentiële gebouwen worden de luchttoevoer, -doorvoer en –afvoer minimum ontwerpdebieten bepaalt naargelang het type ruimte. Voor niet-residentiële hangt het opgelegde minimum debiet voor de afvoerlucht af van het gebruik en de voorziene bezettingsgraad van de ruimte die op hun beurt afhangen van de ETA-luchtkwaltiteitsklassen. Daarnaast worden ook verschillende EPB-eisen opgesteld omtrent het dimensioneren van natuurlijke toevoer- en afvoeropeningen voor zowel residentiële als niet-residentiële gebouwen. Zo bestaat er de debiet-eis in een residentiële woning waar men het (ontwerp)debiet moet weten bij elke opening met een drukverschil van 2Pa, bij nietresidentiële gebouwen is dit bij een drukverschil van 2Pa en 10Pa. In niet-residentiële gebouwen worden tenslotte ook nog eisen opgesteld aan de componenten van een mechanisch ventilatiesysteem. Bij residentiële gebouwen worden er dan geen specifieke eisen gesteld rond die componenten (ventielen, kanalen en mechanische luchtgroepen) [35]. De opgelegde eisen kunnen ook afhangen van de locatie van het gebouw. Zo kunnen EPBeisen verschillen van gewest tot gewest. Bepaalde eisen moeten nageleefd worden in het Vlaamse Gewest, maar kunnen in het Waals gewest gewoon aanbevelingen zijn en visa versa. Het Brussels Hoofdstedelijk Gewest stelt bijkomende eisen met betrekking tot mechanische ventilatie. Men vereist bijvoorbeeld bij nominale debieten groter dan of gelijk aan 5.000m³/h, zoals in restaurants of cafetaria’s, dat er een debietregeling geïnstalleerd wordt waarbij rekening wordt gehouden met het effectief aantal aanwezige personen [35].

9.2 Deelprocessen In het uitgewerkte IDM-protocol (8 MVD van architecturaal ontwerp naar ventilatie), vinden we in het Proces Diagram terug (Figuur 23). Hierin staan de verschillende opeenvolgende taken van een studiebureau voor het ontwerpen van een ventilatiesysteem. Elke taak kan eventueel nog verder onderverdeeld worden in deelprocessen. Door uitvoering van deze opeenvolgende deelprocessen wordt de bovenliggende taak uitgevoerd.

60 Ter illustratie bekijken we de taak 8.1.3.5 Dimensioneren. Zoals reeds aangehaald, zal in deze taak het ventilatiesysteem volledig gedimensioneerd worden. Dit ontwerp kan pas gerealiseerd worden nadat de onderliggende taken zijn uitgevoerd. De keuze van het ventilatiesysteem is bepalend voor verdere uitwerking van de taken. Afhankelijk van het gekozen ventilatiesysteem zullen een aantal taken al dan niet worden verwerkt. In Figuur 31 zien we hoe men het gekozen ventilatiesysteem verder uitwerkt tot en met het voorlopig resultaat [33].

Figuur 31: Taakbeschrijving dimensioneren fase 1

Aan de hand van de vereiste minimumdebieten opgesteld in regulatiedocumenten, kan men de ontwerpdebieten bepalen. De minimumdebieten worden bepaald voor elke ruimte in het beschermde volume van de woning, in functie van de vloeroppervlakte en het type ruimte. Deze minimumeisen worden opgelegd voor zowel luchttoevoer, afvoer als doorvoer. De ontwerpdebieten liggen hoger dan de minimumdebieten, zodanig dat er rekening kan gehouden worden met eventuele onzekerheden bij de berekeningen en afwijkingen. Verder gaat men na of de totale toevoer en afvoer in balans zijn en houdt men eventueel rekening met systeem afhankelijke eigenschappen zoals recirculatie bij systeem D [33]. Een volgende stap in het ventilatieontwerp is het kiezen van een regelstrategie. Het studiebureau gaat hier keuzes maken omtrent bepaalde regelcomponenten zoals manuele besturing, klokbediening, CO2-sensors, aanwezigheidsdetectie etc.[33]. Tenslotte wordt er een voorlopig resultaat vastgelegd met voorlopige keuzes van de ventilatiecomponenten. Met behulp van dit resultaat kan men weet krijgen over de kostprijs van het geheel en de nodige plaats voor de luchtgroep en kanalen. Dit kan men dan voorleggen aan de architect of opdrachtgever (8.1.4.7 Voorlopig resultaat ventilatieontwerp) zodanig dat deze partijen feedback kunnen geven [33].

61 Nadat het voorlopig resultaat is goedgekeurd door de vragende partijen kan men het systeem verder dimensioneren. Ook hier blijft de verdere dimensionering afhankelijk van het gekozen ventilatiesysteem. Zo zal men niet genoodzaakt zijn om natuurlijke toe- en afvoeropeningen te dimensioneren bij het ontwerp van een systeem D. Bij het bepalen van een systeem A is het dan weer niet nodig om een mechanisch distributienetwerk te ontwerpen (Figuur 32).

Figuur 32: Taakbeschrijving dimensioneren fase 2

Bekijken we in het bijzonder het deelproces ‘Ontwerpen en dimensioneren van het mechanisch distributienetwerk’ voor een systeem D. Hier zal men het netwerk van de kanalen, de plaatsing van de luchtgroep en luchtventielen, de ligging van de tracés en de diameter van elk kanaal bepalen. Men zal het systeem zodanig ontwerpen dat de gewenste prestaties op vlak van akoestisch comfort, energieverbruik en luchtdebiet kunnen gerealiseerd worden. Dit resultaat kan men creëren door rekening te houden met verschillende criteria zoals de luchtsnelheid, drukverliezen, omvang van de kanalen, positie van de ventielen etc. Vaak wordt de oplossing die het best bij deze criteria past iteratief gevonden [33]. Het deelproces ‘Ontwerpen en dimensioneren van het mechanisch distributienetwerk’ kan men nog opsplitsen in verdere onderliggende taken. Zo zal men afhankelijk van verschillende criteria gaan kijken waar de ventilatiegroep het best zal geplaatst worden, waar men de luchttoevoer- en lucht afvoeropeningen plaatst, hoeveel ventielen er per ruimte moeten voorzien worden en waar deze geplaatst zullen worden, of er geluidsdempers moeten voorzien worden en tenslotte hoe men het netwerk uiteindelijk zal dimensioneren. Indien al deze taken en hun onderliggende taken werden uitgevoerd kan men verdergaan in het totaalproces. Uit Figuur 23: Proces Diagram zien we dat na het dimensioneren kan gestart worden met het voorbereiden van de uitvoeringsfase.

62

9.3 MVD ventilatie in kaart gebracht Wanneer er een samenwerking is tussen bijvoorbeeld een studiebureau technieken en een architect kan het zijn dat beide partijen werken met verschillende softwarepakketten. Indien ze werken met een BIM-model kunnen ze opteren om het model uit te wisselen via het softwareonafhankelijk-bestandsformaat IFC. Door gebruik te maken van een MVD kan de onderlinge gegevensuitwisseling geoptimaliseerd worden. Het studiebureau ontvangt dan enkel gegevens die betrekking hebben met hun uit te voeren taken, zoals het ontwerp van een ventilatiesysteem (zie hoofdstuk 8 MVD architecturaal ontwerp naar ventilatie). Het studiebureau kan echter ook nog aangesteld worden voor het dimensioneren van andere technieken zoals verwarming, koeling etc. In de praktijk zou het interessanter zijn om een MVD op te stellen die al de nodige gegevens voorziet van de architect naar het studiebureau voor het bepalen van alle technieken met betrekking tot HVAC en dus niet enkel die voor ventilatie. Concreet zal dit resulteren in het uitbreiden van de Exchange Requirements. Zo heeft men bij het ontwerp van een ventilatiesysteem andere inputgegevens nodig dan bij het dimensioneren van de verwarmingsinstallatie. Bijkomende inputgegevens voor een verwarmingsinstallatie vanuit het architecturaal ontwerp zijn bijvoorbeeld zonnetoetredingsfactoren, irradiatie, U-waarden etc. Men moet echter bij de dimensionering van de verwarmingsinstallatie wel rekening houden met het gekozen ventilatiesysteem (wordt er verwarmd via luchttransport, m-factor, etc.). Men zal dus eerst het ventilatiesysteem dimensioneren en pas in een latere fase zal men het verwarmingssysteem ontwerpen. We merken echter op dat de U-waarden, zonnetoetredingsfactoren etc. vooral productafhankelijk zijn. De vraag is nu of het de taak is van de architect om deze gegevens aan het model toe te voegen om toch maar aan de eisen van het studiebureau te voldoen. Dit is zeer tijdrovend en praktisch onhaalbaar. Een oplossing voor dit probleem zou bijvoorbeeld zijn dat fabrikanten hun specifieke producten digitaliseren waarbij men alle relevante informatie aan het product kan koppelen. Deze bibliotheken kunnen dan opgehaald worden in de BIM-software door de architecten.

63

10 Besluit Building Information Modeling (BIM) is een opkomende werkmethode die toelaat een intelligent 3D-model op te bouwen aan welk verschillende relevante informatie kan worden gekoppeld. Het model kan gebruikt worden door verschillende participanten die elk hun aandeel kunnen leveren aan het compleet maken van het uiteindelijke project. Met behulp van Industry Foundation Classes (IFC) kan het model doorgestuurd worden tussen verschillende softwarepakketten. Een Model View Definition (MVD) definieert een onderdeel van het volledige IFC-schema. Deze MVD is nodig om aan de noden van bepaalde Exchange Requirements te voldoen tussen specifieke bouwpartners. De Information Delivery Manual (IDM) ondersteunt enerzijds de manier waarop men deze Exchange Requirements definieert en anderzijds omkadert deze gids de actoren en plaatst binnen een bedrijfsproces. Het gebruik van IFC- en MVD-modellen kan een aanzienlijke meerwaarde geven aan de onderlinge communicatie tussen verschillende bouwpartners. IFC is een onafhankelijk uitwisselingsformaat dat het mogelijk maakt om op een eenvoudige manier gebouwinformatie uit te wisselen tussen verschillende participanten, onafhankelijk van welk softwarepakket ze gebruiken. Om deze informatie doelgericht en efficiënt te kunnen uitwisselen kan men verder gebruik maken van MVD-modellen. Doordat men deze aangehaalde modellen implementeert binnen een bedrijf ontstaat een eenduidig beeld van de uit te wisselen informatie en kan deze op een efficiënte manier toevertrouwd worden aan de verschillende uitvoerende partijen. Naast de informatie omtrent de uit te voeren taken is het ook belangrijk om te weten waar en wanneer men juiste deze modellen zal gebruiken. In deze thesis werd literatuuronderzoek gedaan naar het gebruik van IFC- en MVD-modellen. Na het verwerken van deze informatie werd binnen dit onderzoek meer specifiek ingegaan op het uitwerken van een IDM voor een MVD ventilatie. Binnen deze uitwerking werd het gebruik van de MVD aangekaart met een Process Model dat duidelijkheid geeft over waar de MVD zal moeten gebruikt worden, welke informatie erin moet zitten (Exchange Requirements) en hoe deze verder kan doorgestuurd worden naar de uitvoerende partijen. Meer en meer bedrijven trachten vandaag de dag over te stappen naar BIM. Indien men BIM op een rendabele en efficiënte manier wil gebruiken, moet men investeren in de nodige opleidingen en software. Deze vernieuwing vraagt voor de bedrijven veel geld en vooral tijd. De uiteindelijke overgang naar het functioneel toepassen van IFC zal voor de bedrijven nog meer tijd kosten. Het is om deze reden dat het gebruik van IFC tussen bouwbedrijven in België nog in zijn kinderschoenen staat.

64

Literatuurlijst [1]

“Industry Foundation Classes (IFC) data model — buildingSMART.” [Online]. Available: http://www.buildingsmart.org/standards/ifc. [Accessed: 11-Aug-2014].

[2]

“buildingSMART.” [Online]. Available: http://www.buildingsmart.org/. [Accessed: 09-Aug-2014].

[3]

“buildingSMART-Tech.” [Online]. Available: http://www.buildingsmart-tech.org/. [Accessed: 14-Jul-2014].

[4]

“Information Delivery Manual Guide to Components and Development Methods.”

[5]

“Bimplan.” [Online]. Available: http://www.bimplan.be/. [Accessed: 08-Aug-2014].

[6]

“deBIMspecialist, onafhankelijk, deskundig advies rondom BIM / Wat is BIM / Voor wie?” [Online]. Available: http://www.debimspecialist.nl/wat_is_bim/voor_wie/. [Accessed: 08-Aug-2014].

[7]

“BIM | Architectuur + Advies.” [Online]. Available: http://www.voenw.nl/home/bim/. [Accessed: 08-Aug-2014].

[8]

“BIM | vijf koppen | Vergelijking BIM met traditionele werkmethodiek.” [Online]. Available: http://vijfkoppen.nl/bim-kennis/. [Accessed: 08-Aug-2014].

[9]

D. Spekkink, “Detailniveau BIM per fase,” pp. 1–32, 2012.

[10] M. A. T. Lê, F. Mohus, O. K. Kvarsvik, and M. Lie, “The HITOS Project - A Full Scale IFC Test.” [11] “Om welk soort BIM-proces zouden werkgevers moeten vragen?” [Online]. Available: http://www.2cmanagement.nl/?tag=bim. [Accessed: 14-Jul-2014]. [12] “Introduction — Foreword.” [Online]. Available: http://www.buildingsmarttech.org/ifc/IFC4/final/html/foreword.htm. [Accessed: 09-Aug-2014]. [13] “bSI Vision & Mission — buildingSMART.” [Online]. Available: http://www.buildingsmart.org/organization/copy_of_new-page. [Accessed: 09-Aug2014]. [14] T. Liebich, “buildingSMART Data Standards,” 2012. [15] “Basic Informations IFC.” [Online]. Available: http://www.ifcwiki.org/index.php/Basic_Informations. [Accessed: 09-Aug-2014]. [16] “All Applications by Category — BuildingSMART.” [Online]. Available: http://www.buildingsmart-tech.org/implementation/implementations. [Accessed: 09Aug-2014].

65 [17] T. Liebich, “IFC 2x3 Implementation Guide,” 2009. [18] “EXPRESS (data modeling language) - Wikipedia, the free encyclopedia.” [Online]. Available: http://en.wikipedia.org/wiki/EXPRESS_(data_modeling_language). [Accessed: 09-Aug-2014]. [19] “ISO 10303-21 - Wikipedia, the free encyclopedia.” [Online]. Available: http://en.wikipedia.org/wiki/ISO_10303-21. [Accessed: 09-Aug-2014]. [20] M. De Riet, “Session 6 - IFC for interoperability.” . [21] T. Liebich, “Technical Corrigendum 1.” [Online]. Available: http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/. [Accessed: 09-Aug-2014]. [22] J. Wix, “What is IFC ? What is buildingSMART ?” [23] International Alliance of Interoperability (IAI), “IFC Object Model Guide,” vol. 2. [24] Bips, “IDM Method Guide,” no. March, 2014. [25] “The Role of Building Information Modeling in Design-Build Projects.” [Online]. Available: http://www.bccomfort.com/building+information+modeling/4/40/. [Accessed: 10-Aug-2014]. [26] F. Grobler, “IDM-MVD : How do they provide solutions to user requirements ?,” no. April, 2010. [27] “IFC Solutions Factory - The Model View Definition site.” [Online]. Available: http://www.blis-project.org/IAI-MVD/. [Accessed: 10-Aug-2014]. [28] “HESMOS.” [Online]. Available: http://hesmos.eu/. [Accessed: 10-Aug-2014]. [29] “Studiebureau Technieken : enerdo.” [Online]. http://www.enerdo.be/technieken. [Accessed: 10-Aug-2014].

Available:

[30] “Studiebureau Technieken : Voorstelling S&A.” [Online]. http://www.sabvba.com/index.php. [Accessed: 10-Aug-2014].

Available:

[31] I. D. M. Technical and T. January, “Quick Guide Business Process Modeling Notation,” no. January, 2007. [32] “Bizagi - Business Process Management (BPM) – BPMS and Workflow.” [Online]. Available: http://www.bizagi.com/. [Accessed: 17-Aug-2014]. [33] Optivent, “WTCB Praktijkrichtlijn Ventilatiesystemen in woningen IWT project OPTIVENT,” 2013. [34] D. E. Nayer, “WTCB Stappenplan voor comfortabel en energiezuinig ventileren,” no. 60.

66 [35] “Basisprincipes van ventilatie en rol van de actoren - WTCB.” [Online]. Available: http://www.wtcb.be/homepage/index.cfm?cat=publications&sub=infofiches&pag=42& art=1. [Accessed: 17-Aug-2014]. [36] D. D. Richard See, Jan Karlshoej, “An Integrated Process for Delivering IFC Based Data Exchange Authors,” 2011. [37] “Software voor bouwontwerp | Revit-reeks | Autodesk.” [Online]. Available: http://www.autodesk.nl/products/revit-family/overview. [Accessed: 17-Aug-2014]. [38] “Solibri | Imagine. Reliable Information on Demand.” [Online]. Available: http://www.solibri.com/. [Accessed: 17-Aug-2014]. [39] “Data Design System - Open BIM Solutions Provider for MEP Engineers.” [Online]. Available: http://www.dds-cad.net/. [Accessed: 17-Aug-2014]. [40] “IFC Exporter for Revit | Free software downloads at SourceForge.net.” [Online]. Available: http://sourceforge.net/projects/ifcexporter/. [Accessed: 17-Aug-2014]. [41] “Help: Exporting a Project to IFC.” [Online]. Available: http://help.autodesk.com/view/RVT/2014/ENU/?guid=GUID-14037C31-EBAD-41A89099-E6DD65BB626E. [Accessed: 17-Aug-2014]. [42] “Help: Loading and Modifying an IFC Mapping File.” [Online]. Available: http://help.autodesk.com/view/RVT/2014/ENU/?guid=GUID-B85CE60D-2868-427EA37C-37C4F09D6016. [Accessed: 17-Aug-2014]. [43] “Help: Specifying IFC Entities for Families.” [Online]. Available: http://help.autodesk.com/view/RVT/2014/ENU/?guid=GUID-7119A8C3-A0EE-45688C35-750410D867C9. [Accessed: 17-Aug-2014]. [44] “IFC export parameters.” [Online]. Available: http://revit.autodesk.com/library/html/index.html. [Accessed: 16-Aug-2014].

67

Bijlage I: Gebruikte software Om het IFC-gebeuren praktisch te verduidelijken, zijn er verschillende te gebruiken softwareprogramma’s op de markt. Het is belangrijk om softwareprogramma’s aan te halen die weldegelijk IFC-capabel zijn, zodanig dat we de modellen onderling kunnen vergelijken. Het is soms handig om een andere weergave van het model in een ander softwarepakket te gaan bestuderen. Dit doordat de informatie die we uit het ene pakket halen vaak anders wordt weergegeven dan een ander softwarepakket.

Revit 2014 Revit is speciaal ontwikkeld voor Building Information Modeling. Het is een driedimensionaal tekenpakket ontwikkeld door softwaregigant Autodesk. Revit is een objectgeoriënteerd softwareprogramma waar alle elementen uit een bepaald model gezien worden als afzonderlijke objecten. Dit is één van de grote verschillen met de traditionele 2Dtekenprogramma’s zoals bijvoorbeeld AutoCad, waarbij alle elementen lineair getekend worden zonder de koppeling van relevante parameters of informatie [37].

Solibri Model Viewer Solibri Model Viewer is een gratis softwareprogramma waarmee alle IFC-bestandsformaten en Solibri Model Checker bestanden kunnen geopend worden. Het is een zeer gebruiksvriendelijk en interessant programma indien men modellen wil voorstellen of bekijken [38].

DDS-CAD Viewer DDS-CAD Viewer is ook een gratis softwareprogramma waarmee men verschillende bestandsformaten kan openen, alsook IFC-bestandsformaten. DDS staat voor Data Design System en is onderdeel van de Nemetschek Groep. Men kan met behulp van DDS-CAD Viewer aantonen hoe bepaalde elementen geconverteerd zijn naar hun passende IFC-klasse. DDS-CAD viewer ondersteund ook het open Bim Collaboration Format (BCF) waar mogelijke fouten (clashes) worden op aangehaald [39].

Open Source IFC Exporter De Open Source IFC Exporter voor Revit 2014 is een applicatie die gratis kan gedownload worden. Het bevat up-to-date verbeteringen voor de standaard IFC-export in Revit. Het is geen noodzaak om deze applicatie te downloaden maar het is aangeraden voor gebruikers die de kwaliteit van hun IFC- export willen verbeteren. Bij het installeren van de applicatie zal men het ingebouwde IFC-export mechanisme in Revit vervangen door deze verbeterde versie. De applicatie zal ook meerdere malen per jaar geüpdatet worden zodanig dat eventuele bugs of extra export mogelijkheden kunnen voorzien worden [40].

68

Bijlage II: Handleiding IFC Export in Revit 2014 Het is mogelijk om vanuit Revit een bepaald project te exporteren naar verschillende bestandsformaten. Zo voorziet Revit ook de mogelijkheid om een ontwerp te exporteren naar een IFC-bestandsformaat. Deze exportmogelijkheid vindt men terug onder het Application Menu waar men naast de ribbons voor het aanmaken van nieuwe projecten, het openen van bestaande projecten en het opslaan van gecreëerde ontwerpen, een ribbon voorziet voor de export naar andere bestandsformaten. Onder deze ribbon vinden we dan uiteindelijk de mogelijkheid om een project naar IFC te exporteren (Figuur I) [41].

Figuur I: Revit 2014 Export

Als we op de Export-Ribbon klikken vraagt Revit waarin men de IFC-file wil opslaan. Men kan ook kiezen in welk type IFC-formaat men de file wil opslaan. Wij verkiezen het type IFC 2x3 (*.ifc). Het is alsook mogelijk om verdere exportopties te definiëren: -

Current view only, maakt het mogelijk om de elementen te exporteren die zichtbaar zijn in de huidige view. Elementen die tijdelijk verborgen zijn of categorieën die gemarkeerd zijn als Not Exported worden niet doorgegeven naar het geëxporteerde bestand.

69 -

Split walls and columns by story, maakt het mogelijk om muren en kolommen die over meerdere verdiepingen verlopen, op te splitsen naar muren en kolommen per verdieping. Base quantities, exporteert basishoeveelheden van de elementen uit het model. Deze basishoeveelheden worden geometrisch gegenereerd uit het model. Include Space Boundaries, exporteert Space Boundaries. Zo zal men randvoorwaarden in de verschillende ruimtes binnen het model, alsook randvoorwaarden aan de buitenkant exporteren, zoals bijvoorbeeld thermische eigenschappen.

Revit maakt het mogelijk om met behulp van de IFC Mapping File, de verschillende families in te delen naar gelijkaardige IFC-klassen. Men kan dit doen door een nieuwe IFC Mapping File aan te maken of door een bestaande IFC Mapping File op te roepen. Door deze IFC Mapping File aan te maken, zal men de gewenste families correct exporteren naar zijn of haar IFC-tegenhanger. Dit is enkel mogelijk indien met dit correct invoert weliswaar!

IFC Mapping File De IFC Mapping File kan men terugvinden door te klikken op de IFC Options ribbon die men vindt onder het Application Menu, bij Export – Options. We krijgen een tabel waar men drie kolommen weergeeft met respectievelijk: Category, IFC Class Name en Type (Figuur II). Elke rij, in de kolom Category, staat voor een bepaalde element, categorie of deelcategorie. Voor elk standaard gebouwelement worden er automatisch passende IFC-klassen toegewezen. Voor de elementen die niet automatisch geclassificeerd worden naar hun IFC-klasse, wordt er Not Exported geschreven. In de laatste kolom kan men de export nog aanvullen door er de specifieke object exportlocatie aan toe te wijzen. Men moet er wel voorzorgen dat de IFCklassen en types correct geschreven worden, dus volgens de IFC-standaarddefinities. Indien men een categorie niet wil exporteren, schrijft men: Not Exported [42].

Figuur II: Revit 2014 Mapping tabel

70 Concreet is het dus de bedoeling dat wanneer men een bepaald model naar een IFCbestandsformaat wil exporteren, men voor de gewenste categorieën, er de passende IFCklasse bij moet schrijven. Indien gewenst, kan men de export nog verder specifiëren door er een bepaald type aan toe te wijzen. Zo weet het IFC-model dan welk type bij het gebouwelement toebehoort.

Toevoegen van Shared Parameters: IfcExportAs en IfcExportType De Shared Parameters zullen we toevoegen door gebruik te maken van de Family Editor. Onder de Create of Modify tab vinden we de Family Properties, waar we vervolgens Family Types zullen selecteren (Figuur III) [43].

Figuur III: Family Properties ribbon

Er opent zich een venster waar er verschillende parameters worden weergegeven van een bepaald type familie. We klikken vervolgens onder Parameters op Add. Het Parameter Properties venster wordt nu geopend. We selecteren Shared Parameter en vervolgens de gewenste parameter (Figuur IV).

Figuur IV: Toevoegen van Shared Parameters

71

Tenslotte stellen we de Shared Parameter op door op Edit te klikken. Er verschijnt een venster waar gevraagd wordt om de Shared parameter file te selecteren. Deze file moet dus verschillende parameters definieren zoals onder andere IFCExportAs en IFCExportType. Autodesk heeft zelf zo een tekstbestand ter beschikking gesteld. Revit gebruikers kunnen deze online downloaden [44]. Nadat we IFCExportParameters.txt hebben gedownload kunnen we dit bestand selecteren als Shared parameter file [Figuur V].

Figuur V: Toevoegen van de Shared Parameter File

De Paramater group krijgt nu de naam IFC properties waarin een hele reeks parameters worden weergegeven. Vervolgens drukken we op ‘Ok’ en kan men een parameter selecteren. We zoeken meer bepaald naar de parameters IfcExportAs en IfcExportType in de gegenereerde lijst (Figuur VI).

Figuur VI: Shared Parameters

72 Nadat we deze twee Shared Parameters hebben toegevoegd, zien we in het Family Type venster dat er twee parameters zijn bijgekomen. Onder de kolom Value kunnen we nu een waarde geven aan deze twee parameters (IFC-klasse) (Figuur VII).

Figuur VII: Aangepaste Family Types

73

Bijlage III: Voorbeeld IFC-export vanuit Revit: ventilatiesysteem Als illustratie van een export van Revit naar IFC, bekijken we een eenvoudig model van een ventilatiesysteem dat instaat voor de toevoer van verse lucht. Het systeem bestaat uit: een luchtgroep, luchtkanalen en 6 ventilatieroosters. Elk element in het ventilatiesysteem heeft vanuit Revit specifieke kenmerken en eigenschappen meegekregen. Deze vinden we terug in het eigenschappenvenster als we een element selecteren (Figuur VIII).

Figuur VIII: Ventilatiesysteem in Revit 2014 (.rvt)

Als we dit model exporteren naar IFC, gebruikmakend van de standaard IFC Mapping File zonder extra exportopties op te leggen, kunnen we het gecreëerde IFC-model openen met bijvoorbeeld Solibri Model Viewer (bijlage I) (Figuur IX).

Figuur IX: Ventilatiesysteem in Solibri Model Viewer (.ifc)

Als we dan het IFC-model vergelijken met het model uit Revit, kunnen we op het eerste zicht besluiten dat de conversie geslaagd is. Dit omdat alle elementen overgedragen zijn: we hebben nog steeds een luchtgroep, luchtkanalen en 6 ventilatieroosters. Indien we hier dieper op ingaan en kijken naar de informatie gekoppeld aan de elementen in het IFC-model en deze vergelijken met die uit het Revit-model dan kunnen we onderstaande besluiten concluderen.

74

Vergelijking luchtkanaal We vergelijken een luchtkanaal (aangeduid in het groen) uit het ventilatiesysteem en gaan na of alle informatie correct is overgedragen vanuit Revit naar het IFC-model (Figuur X).

Figuur X: Ventilatiekanaal uit het IFC-model (solibri)

Ook in dit geval kunnen we besluiten dat de informatie goed overgebracht werd. Toch merken we een verschil in een aantal eigenschappen waaronder het gebruik van eenheden tussen de verschillende softwarepakketten (Figuur XIIFiguur XIII). Zo vinden we in Revit voor de luchtstroming (flow) een waarde van 120 l/s, terwijl dit in Solibri 0.12m³/s bedraagt. Bij de dimensies van het luchtkanaal zien we bij de breedte in Revit een waarde van 300mm en in Solibri een waarde van 0.984ft (1 voet = 304.8mm). Verder zien we ook nog dat het systeemtype behouden blijft: namelijk ‘supply air’. Het IFC-model onthoudt ook de onderlinge relaties die verbonden zijn met het luchtkanaal (Figuur XI).

Figuur XI: Bijhorende relaties van het luchtkanaal

75

Figuur XIII: Eigenschappenvenster van luchtkanaal uit Revit 2014 (.rvt) Figuur XII: Eigenschappenvenster van luchtkanaal uit Solibri (.ifc)

76 Bekijken we hetzelfde model in andere IFC-viewer, een DDS-CAD Viewer (bijlage I), dan wordt er duidelijk weergegeven in welke IFC-klassen de verschillende gebouwelementen worden opgeslaan. Zo vinden we onder IfcFlowTerminal de zes ventilatieroosters, onder IfcFlowSegment vinden we alle luchtkanalen uit het systeem en onder IfcFlowFitting vinden we alle tussenstukken voor de luchtkanalen zoals bochten, T-stukken etc. Tenslotte vinden we onder IfcBuildingElementProxy de luchtgroep terug (Figuur XIV).

Figuur XIV: DDS-CAD viewer IFC-classificatie

Verdiepen we ons in het gedeelte IfcFlowTerminal met de 6 IfcAirTerminalType’s dan moeten we eerst een betere opvatting krijgen over de klasse IfcFlowTerminal. Onder IfcFlowTerminal verstaan we een distributie-element dat verbonden is met een bepaald verdeelsysteem dat ofwel in het begin van het systeem gevestigd is of aan een uiteinde. Een ‘terminal’ is het punt waar een bepaald systeem in verbinding staat met de buitenomgeving. Zo ziet men een lavabo of een toilet ook als een terminal, aangezien deze op het einde liggen van het sanitair systeem. In dit voorbeeld worden de ventilatieroosters gezien als een terminal. Concreet bevat de (super)klasse IfcFlowTerminal dus verschillende types terminal. Zo hebben we onder IfcFlowterminal, de klasse IfcAirTerminalType maar ook IfcSanitaryTerminalType, IfcStackTerminalType, IfcWasteTerminalType etc. Als we nu in Revit kijken naar de IFC Mapping File en specifieker naar de familie Air Terminals, dan zien we dat deze familie geconverteerd wordt naar IfcAirTerminal. Dit is ook hetgeen de DDS-CAD Viewer bevestigt (Figuur XV).

77

Figuur XV: Air Terminal zonder type specificatie uit de Revit Mapping File

We merken op dat in de IFC Mapping File het type niet ingevuld is. Dit vinden we ook terug met behulp van de DDS-CAD Viewer namelijk: Notdefined – 600x600 Face 300x300 Connection. In Revit weten we welk type ventilatierooster in het systeem zit namelijk een rechthoekige verspreider (diffuser). In het IFC-model weten we dit niet. Deze informatie wordt niet doorgegeven aangezien Revit niet weet naar welk type IfcAirTerminal deze verspreiders moeten geconverteerd worden. We moeten dit dus aan Revit ‘vertellen’ (Figuur XVI).

Figuur XVI: Air Terminal met type specificatie uit de Revit Mapping File

Plaatsen we het passende type Air Terminal dan in de IFC Mapping File, dan weet Revit het juiste type naar waar men de categorie of familie Air Terminals moet converteren. Let op: dit moet in de juiste syntax geschreven worden zoals IFC het definieert:in hoofdletters. Bekijken we het resultaat dan in de DDS-CAD Viewer, dan merken we op dat het model nu wel weet welk type ventilatieroosters in het model zit (Figuur XVII).

Figuur XVII: DDS-CAD viewer met aangepaste IFC-classificatie

78 Het model dat we geconverteerd hebben, is een zeer eenvoudig model. Het bevat slechts één type ventilatieroosters, namelijk 6 rechthoekige verspreiders. Bekijken we nu een ingewikkelder model, met verschillende types ventilatieroosters zoals rechthoekige verspreiders, roosters en cirkelvormige verspreiders etc. dan klopt deze werkmethode niet. Indien we deze ventilatieroosters zouden willen specifiëren met behulp van de IFC Mapping File, dan hebben we met een probleem te kampen. Er zijn namelijk verschillende types ventilatieroosters en slechts één alomvattende familie in de Mapping File hierdoor kunnen we deze verschillende types niet definiëren. Mochten we dit toch doen en bijvoorbeeld naast de categorie Air Terminals het type definiëren als DIFFUSER, dan zouden alle ventilatieroosters gedefinieerd worden als een verspreider en zou dit dus niet correct zijn.

Vergelijking luchtgroep Hetzelfde probleem zien we bij de conversie van de luchtgroep. Deze wordt geconverteerd naar de klasse IfcBuildingElementProxy, wat betekent dat men de luchtgroep ziet als een standaard gebouwelement, zonder verdere specificatie. Men zal gebouwelementen dus converteren naar deze klasse indien men een tekort aan specifieke informatie heeft, zodanig dat men het element toch nog geometrisch kan weergeven maar zonder ‘nuttige functie’ in het model. In Revit wordt de luchtgroep ondergebracht in de categorie Mechanical Equipment waar alsook boilers, radiators, pompen etc. inzitten. Mochten we nu de luchtgroep willen converteren dan zou de passende IFC-klasse IfcAirTerminalBoxType zijn. Plaatsen we deze klasse naast de categorie Mechanical Equipment dan zouden dus alle verschillende types die onder deze categorie zitten, converteren naar die specifieke klasse. Wat dus duidelijk niet klopt, want een boiler is zeker en vast geen AirTerminalBoxType, maar zou wel moeten geschreven worden naar IfcBoilerType.

IFC Entiteiten voor families Revit exporteert bouwelementen naar een IFC-bestand op basis van de Revit (sub)categorieën waartoe de elementen behoren. Zo zal Revit een muur exporteren naar de klasse IfcWalllStandardCase, omdat een muur een element is dat valt onder de categorie ‘wall’. In veel gevallen is er een logisch verband met de categorie en de IFC-klasse en zijn de standaardinstellingen vanzelfsprekend. Maar om nauwkeurig te werken, kan men voorstander zijn om bepaalde elementen van een familie naar een passende IFC-klasse te exporteren. Dit probleem hebben we bij bovenstaande vergelijkingen besproken. De luchtgroep behoorde daar tot de categorie Mechanical Equipment naast bijvoorbeeld de boilers, radiators, pompen etc. Men wil de export nu niet meer realiseren op basis van de categorie, maar op basis van de families. Dit probleem kunnen we oplossen door het toevoegen van extra parameters meer bepaald de shared parameters genaamd IfcExportAs en IfcExportType. De waarde voor de parameter IfcExportAs zal bepalen in welke klasse de familie geëxporteerd wordt. De waarde voor de parameter IfcExportType zorgt voor een extra specificatie van de IFC-klasse, tot welk type het element behoort.

79 Een Shared Parameter zijn parameters die men kan toevoegen bij een families of projecten en vervolgens kunnen gedeeld worden met andere families en projecten. Ze geven je de mogelijkheid om specifieke gegevens, die niet vooraf gedefinieerd zijn, aan een familiebestand of project toe te voegen. Shared parameters zijn handig als je een schema wil maken waar je verschillende categorieën van families wil weergeven. Shared parameters zijn opgeslagen in een afzonderlijk tekstbestand zodanig dat je deze parameters kunt benaderen vanuit verschillende families of projecten. In bijlage I kan men terugvinden hoe een Shared Parameter kan worden toegevoegd.

80

Bijlage IV: Opbouw van een IFC-model Naast de mogelijkheid om een IFC-bestand te kunnen openen met verschillende softwarepakketten, kunnen we het model ook openen via een teksteditor zoals bijvoorbeeld Notepad. Indien we dit doen, krijgen we een vrij omslachtig en groot tekstbestand dat makkelijk uit duizenden regels kan bestaan. Het tekstbestand is een zogenaamd STEPbestand, het bestaat uit regelnummers en verwijzingen. Met behulp van deze opeenvolgende regelnummers en verwijzingen kan het IFC-model gegenereerd worden [20].

Figuur XVIII: IFC-model geopend in Notepad

Bovenaan vinden we de koptekst terug waar we de gegevens van de gebruiker, de datum en het type IFC-bestandsformaat in terugvinden. De lijnen na de koptekst tot en met #100 vertellen ons iets meer over de basisinstellingen van het project zoals eenheden, basispunten, etc. Als we naar één bepaald object in een model kijken met behulp van Solibri, kunnen we een object selecteren. Na dubbel aanklikken komt het eigenschappenvenster tevoorschijn (Figuur XIX).

81

Figuur XIX: Eigenschappenvenster van een luchtkanaal

Zo vinden we allerlei informatie die samenhangt met het geselecteerde object. We vinden onder meer welke naam en welk type het geselecteerde object heeft en bijvoorbeeld ook in welk systeem het object zich vertoeft. We zien ook dat aan het object een BATID-nummer is mee gegeven, namelijk 575671. Elk object in het project heeft zijn eigen uniek BATIDnummer. Als we dit nummer nu gaan opzoeken in het tekstbestand dan vinden we onder lijn 1121 volgende coderegel: #1121= IFCFLOWSEGMENT('3JOkaCBd11oxyWQUPV0Zao',#41,'Rectangular Duct:Radius Elbows / Tees:575671',$,'Rectangular Duct:Radius Elbows / Tees:142431',#1108,#1119,'575671'); We kunnen hier uit afleiden dat het object werd opgeslagen als een ventilatiekanaal (IFCFLOWSEGMENT). Aan het ventilatiekanaal wordt verder nog de naam, het type, de GUID (Globally Unique Identifier) '3JOkaCBd11oxyWQUPV0Zao' en zijn BATID-nummer meegegeven. We merken op dat regel #1121 nog naar volgende lijnen verwijst: Lijn 41: #41= IFCOWNERHISTORY(#38,#5,$,.NOCHANGE.,$,$,$,1385719371); Waaruit we kunnen afleiden dat er geen update voor het betreffende project is uitgevoerd. Lijn 1108 tot en met lijn 1119: #1107= IFCAXIS2PLACEMENT3D(#6,$,$); #1108= IFCLOCALPLACEMENT(#96,#1107); #1109= IFCCARTESIANPOINT((-5.68434188608080E13,1.08002495835535E-12)); #1111= IFCAXIS2PLACEMENT2D(#1109,#23); #1112= IFCRECTANGLEPROFILEDEF(.AREA.,'Radius Elbows Tees',#1111,3691.76461091832,299.999999999999);

82 #1113= IFCCARTESIANPOINT((13740.0879922932,8698.56316392256,2850.)); #1115= IFCAXIS2PLACEMENT3D(#1113,#19,#15); #1116= IFCEXTRUDEDAREASOLID(#1112,#1115,#19,300.); #1117= IFCSHAPEREPRESENTATION(#73,'Body','SweptSolid',(#1116)); #1119= IFCPRODUCTDEFINITIONSHAPE($,$,(#1117)); Waaruit we kunnen afleiden dat deze codelijnen, de coördinaten omschrijven van het object. Wat ons dus iets vertelt over hoe het object georiënteerd is in het model en hoe het er zal uit zien. Vervolgens vinden we nog een aantal codelijnen, waarin de eigenschappen van het object worden gedefinieerd. Lijn #1151 verteld ons dat we deze eigenschappen kunnen vinden vanaf #1121 tot #1149. Lijn 1151: #1151=IFCRELDEFINESBYPROPERTIES('1XUWGXbiTDFR83wqtADG3$ ',#41,$,$,(#1121),#1149); Het ventilatiesysteem is oorspronkelijk ontworpen in Revit, waar er met behulp van verschillende parameters specifieke eigenschappen aan elk object werden mee gegeven. In dit geval waren dat bijvoorbeeld het wrijvingsgetal van het kanaal, de drukverlies, de dimensies, de snelheid van de lucht in het kanaal, het getal van Reynolds, etc.. Nadat we het project converteerden in een IFC-formaat werden deze eigenschappen dus mee gegeven aan het ventilatiekanaal. Wat we kunnen zien in volgende lijnen: Lijn 1124 – 1149: #1124=IFCPROPERTYSINGLEVALUE('SystemName',$,IFCTEXT('Mecha nical Supply Air 2'),$); #1125= IFCPROPERTYSINGLEVALUE('Overall Size',$,IFCTEXT('300 mmx300 mm'),$); #1126=IFCPROPERTYSINGLEVALUE('Friction',$,IFCREAL(0.000357551 2807683),$); #1127= IFCPROPERTYSINGLEVALUE('Mark',$,IFCTEXT('15'),$); #1128= IFCPROPERTYSINGLEVALUE('Free Size',$,IFCTEXT('300 mmx300 mm'),$); #1129=IFCPROPERTYSINGLEVALUE('AdditionalFlow',$,IFCVOLUMET RICFLOWRATEMEASURE(0.),$); #1130=IFCPROPERTYSINGLEVALUE('PressureDrop',$,IFCREAL(0.0043 3069279832326),$); #1131=IFCPROPERTYSINGLEVALUE('Width',$,IFCREAL(0.9842519685 03937),$); #1132=IFCPROPERTYSINGLEVALUE('LossCoefficient',$,IFCREAL(0.478 493716185176),$); #1133=IFCPROPERTYSINGLEVALUE('Velocity',$,IFCREAL(0.729075532 225138),$); #1134= IFCPROPERTYSINGLEVALUE('Size',$,IFCTEXT('300x300'),$); #1135=IFCPROPERTYSINGLEVALUE('BottomElevation',$,IFCLENGTH MEASURE(2850.),$); #1136=IFCPROPERTYSINGLEVALUE('EquivalentDiameter',$,IFCREAL(

83 1.07595013762778),$); #1137=IFCPROPERTYSINGLEVALUE('Flow',$,IFCVOLUMETRICFLOW RATEMEASURE(0.02),$); #1138=IFCPROPERTYSINGLEVALUE('TopElevation',$,IFCLENGTHME ASURE(3150.00000000001),$); #1139=IFCPROPERTYSINGLEVALUE('Length',$,IFCLENGTHMEASURE (3691.76461091832),$); #1140=IFCPROPERTYSINGLEVALUE('StartOffset',$,IFCLENGTHMEAS URE(3000.00000000001),$); #1141=IFCPROPERTYSINGLEVALUE('VelocityPressure',$,IFCREAL(0.0 0905067851851851),$); #1142=IFCPROPERTYSINGLEVALUE('Area',$,IFCAREAMEASURE(4.43 011753310198),$); #1143=IFCPROPERTYSINGLEVALUE('Offset',$,IFCLENGTHMEASURE( 3000.00000000001),$); #1144=IFCPROPERTYSINGLEVALUE('EndOffset',$,IFCLENGTHMEAS URE(3000.00000000001),$); #1145=IFCPROPERTYSINGLEVALUE('SystemClassification',$,IFCTEXT( 'Supply Air'),$); #1146=IFCPROPERTYSINGLEVALUE('Height',$,IFCREAL(0.9842519685 03937),$); #1147=IFCPROPERTYSINGLEVALUE('HydraulicDiameter',$,IFCREAL(0 .984251968503937),$); #1148=IFCPROPERTYSINGLEVALUE('Reynoldsnumber',$,IFCREAL(444 2.09644295454),$); #1149=IFCPROPERTYSET('2agc1X_mX8vQIJZpqizwzQ',#41,'Lining',$,(#61 7,#1128));