Calculeren met BIM - BouwIQCalculeren met BIM Ing. J. Witteman, mei 2009 Technische Universiteit Eindhoven, faculteit Architecture, Building and Planning, afdeling Design and Decision

Calculeren met BIM

Ing. J. Witteman, mei 2009

Technische Universiteit Eindhoven, faculteit Architecture, Building and Planning,

afdeling Design and Decision Support Systems

Onderzoek naar de mogelijkheden om bouwkosten

met behulp van een Bouw Informatie Model te bepalen

Afstudeercommissie:

Prof. Dr. Ir. B. de Vries, Technische Universiteit Eindhoven

Ir. J. Beetz, Technische Universiteit Eindhoven

Ir. H. Hendriks, deBIMspecialist

Contactgegevens:

Ing. Jeroen Witteman

06 26 896 687

[email protected]

www.calculerenmetbim.nl

Model omslag:

studio 5b, www.lets-hire-terry.com

V

Voorwoord

U heeft het afstudeerrapport ‘Calculeren met BIM’ in handen. Een beschrijving van het proces en de resultaten van het onderzoek naar mogelijkheden om bouwkosten met behulp van een Bouw Informatie Model te bepalen. Het onderzoek dat de afsluiting is van mijn studie aan de Technische Universiteit Eindhoven en het begin van mijn werkzaamheden in de praktijk, die in het verlengde van dit onderzoek zullen liggen.

Deze rapportage is mede geschreven voor mijn ‘grootste sponsoren’; mijn ouders

en daarmee, naar ik hoop, leesbaar voor een groter publiek dan dat van de bouwkundigen alleen. Naast hen hebben velen een bijdrage geleverd aan het voltooien van dit onderzoek. Van hen wil ik in het bijzonder bedanken: Yvonne Tijssen voor haar geduld, Sebastiaan Jonker – die ik tevens veel succes wens met zijn verdere afstudeerperiode – voor zijn stimulans die ik ook van Ludo van Meeuwen en andere vrienden heb mogen ontvangen, Bauke de Vries voor zijn deskundige begeleiding gedurende vrijwel mijn gehele studie en mijn afstudeerperiode in het bijzonder, Jacob Beetz voor zijn ingebrachte kennis en deBIMspecialist Hans Hendriks voor zijn expertise en deelname aan de begeleidingscommissie.

Ten behoeve van haar onafhankelijkheid is dit onderzoek uitgevoerd op de

Technische Universiteit Eindhoven, maar er zijn velen geweest die mij belangeloos van nodige informatie hebben voorzien, waaronder Jo Dukers van bouwkosten- en managementbureau Dukers & de Cock en Ad de Jongh van ICN Solutions. Hen bedank ik voor hun vrij gemaakte tijd, verstrekte informatie en geopende deuren tot informatiebronnen betreffende bouwkosten, respectievelijk het Bouw Informatie Model.

Ik wens u veel leesplezier toe. Eindhoven, mei 2009 Jeroen Witteman

VII

Samenvatting

De term ‘calculeren’ in de titel van dit afstudeeronderzoek is synoniem voor het inschatten van kosten door de bouwkostendeskundige in de verschillende fasen van het traditionele bouwproces. Een proces met veel en wisselende partijen en omstandigheden met een eindproduct dat altijd uniek is. Communicatie is in dit proces een sleutelbegrip om informatie over te dragen. Een begrip dat weliswaar bijdraagt aan de voortgang van het proces, maar ook het proces stagneert door verlies aan informatie bij elke overdracht.

Beperking van dit verlies is mogelijk door de informatie niet meer over te dragen,

maar te delen. Knelpunten daarbij zijn de fysieke afstand tussen de wisselende partijen en het gebruik van onuitwisselbare, discipline gebonden (software) middelen. Een oplossing is het gebruik van een Bouw Informatie Model (BIM). Anders dan bij traditionele bouwkundige tekeningen bevat dit model niet alleen geometrische informatie, maar ook informatie waarmee het BIM door de verschillende projectpartijen is verreikt en waarmee zij hun discipline eigen resultaten weer kunnen genereren. Een door BuildingSmart ontwikkeld bestandsformaat Industry Foundation Classes (IFC) maakt het bovendien mogelijk de gegevens software onafhankelijk met verschillende partijen uit te wisselen gedurende het gehele bouwproces.

Binnen dit bouwproces heeft de bouwkostendeskundige, naast zijn kosten-

schattende functie, een controlerende en sturende functie. Zijn sturende invloed op kostenbepalende beslissingen is in de beginfasen het grootst, omdat dan nog alternatieve oplossingen mogelijk zijn het ontwerpprobleem op te lossen. De inschattingen van kosten worden daarbij gebaseerd op aannamen voor de kwaliteit van hetgeen ontworpen moet worden en ervaringsgetallen uit het projectverleden. Door de definitieve keuzes die het ontwerpteam gedurende de fasen maakt, kan steeds meer informatie worden bepaald uit het ontwerp en neemt de sturende invloed af. De controlerende functie van de ervaringsgetallen wordt dan steeds belangrijker.

Uit het onderzoek ‘Calculeren met BIM’ blijkt dat een IFC model voldoende

mogelijkheden biedt om informatie op te nemen die nodig is voor het maken van

VIII

een kostenschatting. Uit enkele casus blijkt echter dat gangbare modelleer-pakketten waarmee de modellen worden opgebouwd deze mogelijkheden nog niet optimaal benutten. De beschikbare gegevens sluiten daardoor onvoldoende aan bij de ervaringsgetallen van de bouwkostendeskundige. Gezien de enorme hoeveelheid ervaringsgetallen en de huidige kennis van de bouwkostendeskundige om op zijn vakgebied het ontwerpproces te controleren en te sturen, is het onwaarschijnlijk dat het inschattingsproces zich als zodanig op korte termijn aan zal passen aan de mogelijkheden van BIM. In het kader van dit onderzoek naar de mogelijkheden om bouwkosten met behulp van een Bouw Informatie Model te bepalen, is daarom gekeken naar mogelijkheden het BIM in de huidige werkmethodiek toepasbaar te maken.

Gebleken is dat het de ondersteunende werkzaamheden zijn waarbij de

toepassing van BIM – en het IFC model in het bijzonder – enorme positieve invloed kan hebben op de accuraatheid waarmee de bouwkostendeskundige op wijzigingen in het ontwerpproces kan inspringen. Het eindproduct van dit onderzoek is dan ook een ontwerp van een model dat kosten inschat op basis van een door de bouwkostendeskundige gekozen kwaliteit en een koppeling met een IFC bestand. De kwaliteit wordt gebaseerd op ervaring uit het verleden en heeft in beginsel een ramingfunctie voor het actuele project. Naarmate het IFC model gedurende het proces groeit, zal de oorspronkelijk gekozen kwaliteit een controlerende functie krijgen en zal de informatie uit het model bepalend zijn voor de inschatting. Gebruik van dit ontwerp kan bijdrage leveren aan de vereenvoudiging van de ondersteunende werkzaamheden en er toe leiden dat de nadruk van de werkzaamheden van de bouwkostendeskundige op de kostendeskundige kant komt te liggen. Het ontwerp is ondersteund met een prototype dat enkele van de kernactiviteiten van het ontwerp in een werkende omgeving kan nabootsen.

Inhoudsopgave

Voorwoord ........................................................................................................... V

Samenvatting ....................................................................................................... VII

Hoofdstuk 1 Introductie .................................................................................... 13

1.1 Probleemveld ......................................................................................................... 14

1.2 Aanleiding ............................................................................................................. 14

1.3 Doelstelling ............................................................................................................ 15

1.4 Onderzoeksvraag .................................................................................................. 15

1.5 Het onderzoek ....................................................................................................... 15

Hoofdstuk 2 Bouwkosten .................................................................................. 17

2.1 Het bouwproces ..................................................................................................... 17

2.2 Detailniveaus ........................................................................................................ 18

2.3 Bouwfasen ............................................................................................................. 19

2.4 Ramen, begroten, calculeren ................................................................................ 20

2.5 Kengetallen ........................................................................................................... 22

2.6 Begrotingsstructuur ............................................................................................. 23

Hoofdstuk 3 Projectanalyse .............................................................................. 25

3.1 Resultaten ............................................................................................................. 26

3.2 Referentiemethoden ............................................................................................. 28

3.3 De factor kwaliteit ................................................................................................ 29

3.4 Het (traditionele) inschattingsproces .................................................................. 31

Hoofdstuk 4 Het Bouw Informatie Model (BIM) .......................................... 33

4.1 Tekenen en modeleren ......................................................................................... 33

4.2 Een centraal model ............................................................................................... 35

4.3 BuildingSmart ....................................................................................................... 36

Hoofdstuk 5 Industry Foundation Classes (IFC) ......................................... 39

5.1 De IFC structuur .................................................................................................. 39

5.2 Eigenschappen ...................................................................................................... 44

5.3 Ruimtelijke structuur ........................................................................................... 48

Calculeren met BIM

Hoofdstuk 6 Projectinformatie ........................................................................ 51

6.1 Informatiestructuur .............................................................................................. 52

6.2 Detailniveau .......................................................................................................... 54

6.3 Kengetallen ........................................................................................................... 55

6.4 Hoeveelheden ........................................................................................................ 57

6.5 Probleemgebieden ................................................................................................. 59

Hoofdstuk 7 De IFC Cost Estimator (ICE) .................................................... 61

7.1 Het (nieuwe) inschattingsproces ......................................................................... 62

7.2 Beschikbare middelen .......................................................................................... 63

7.3 Het concept ............................................................................................................ 64

7.4 Het ontwerp ........................................................................................................... 67

7.5 Overzicht ............................................................................................................... 71

Hoofdstuk 8 Prototype van ICE ....................................................................... 73

8.1 Mogelijkheden prototype ...................................................................................... 73

8.2 Kwaliteit definiëren .............................................................................................. 74

8.3 Inlezen IFC model................................................................................................. 75

8.4 Entiteiten selectie ................................................................................................. 77

8.5 Prijzen opbouwen .................................................................................................. 79

8.6 Model vernieuwen ................................................................................................. 79

8.7 Verreiken model .................................................................................................... 80

Hoofdstuk 9 Conclusies en aanbevelingen ................................................... 87

9.1 Begripdefinities ..................................................................................................... 87

9.2 Resultaten ............................................................................................................. 88

9.3 Ontwerp ................................................................................................................. 89

9.4 Aanbevelingen ....................................................................................................... 90

Hoofdstuk 10 Literatuurlijst .............................................................................. 91

Bijlage 1. Digitale bijlagen

Bijlage 2. Procedure voor het gebruik van het prototype

Bijlage 3. Verklarende woordenlijst

Bijlage 4. Case lijst

Bijlage 5. Representatie van de instantie IfcWallStandardCase

Bijlage 6. Handelingen prototype ICE

Introductie

13

Hoofdstuk 1

Introductie

,,No tool can deliver a full estimate automatically from a building model. If a vendor advertises this, they don’t understand the estimating process.’’

Eastman et al. (2008)

De bouwsector wordt er doorgaans van beticht weinig innovatief te zijn. Daarmee doelt men vooral op de uitvoeringskant van het bouwproces, de daarbij behorende arbeidsintensiviteit en de onveranderende verhouding van 1 cement, 2 zand en 3 grind. De voorbereidingszijde echter, is de afgelopen decennia wel degelijk aan een sterk veranderende werkmethodiek onderhevig geweest. Arbeidsintensieve, handmatige tekenen berekenwerkzaamheden hebben plaats gemaakt voor werkzaamheden die met behulp van ondersteunende software applicaties worden verricht. In de ontwikkeling van deze werkmethodiek (Figuur 1-1) zien we in het laatste stadium de eerste mogelijkheden omtrent het 3 dimensionaal modelleren van bouwprojecten ontstaan. Het voordeel van deze methodiek, waarbij elementen met behulp van objecten worden gemodelleerd in plaats van dat zij met lijnen worden getekend, is te vinden in de eenheid en samenhang van het gemodelleerde. Wijzigingen in het model zijn direct zichtbaar in de uit het model gegenereerde plattegronden, aanzichten en doorsneden.

De ontwerpende partijen binnen het bouwproces worden met deze nieuwe

middelen voorzien in hun behoefte om efficiënter de ontwerpopgave aan te pakken. Toch is er nog een stap te maken in het automatiseringsproces van het voortraject. Kenmerkend voor het bouwproces is namelijk de diversiteit aan deelnemende partijen en het altijd unieke eindproduct.

Calculeren met BIM

14

Figuur 1-1; Ontwikkeling van de werkmethodiek van het bouwkundig ontwerpen

1.1 Probleemveld De ontwerpende partijen zijn zich ervan bewust dat niet alle andere partijen –

zoals de constructeur, de aannemer en de calculator – binnen het proces beschikken over de middelen waarmee zij de basis leggen van het voortraject; het (3 dimensionale) ontwerp. Om de informatie van dit ontwerp over de partijen te kunnen verspreiden, wordt deze ‘platgeslagen’ naar tekst en informatie-arme tekeningen welke bij de overige deelnemers door afwijkende inzichten anders kunnen worden geïnterpreteerd. Er ontstaan verkleurde weergaven van hetgeen de ontwerper in beginsel bedacht had. Op basis van die verkleurde weergaven worden nieuwe, discipline-eigen, gegevens geproduceerd.

Van die deelnemende partijen is de bouwkostendeskundige de hoofdrolspeler in dit onderzoek. Momenteel is de meetlat nog altijd zijn instrument om de hoeveelheden uit de platgeslagen informatie te bepalen. Een bezigheid, die naar schatting zo’n 60% van zijn beschikbare werktijd in beslag neemt1.

1.2 Aanleiding De internationale organisatie Building Smart doet een poging de volgende stap

in het automatiseringsproces te zetten door een werkmethodiek te ontwikkelen waarbij met een centraal model aan behoeften van de andere disciplines voldaan kan worden. Het 3D model, waarin tevens eigenschappen van gemodelleerde elementen zijn opgenomen, kan in deze methodiek door verschillende partijen worden gebruikt door de introductie van het universele formaat IFC (Industry Foundation Classes).

Deze manier van werken vindt onder de noemer BIM (Bouw Informatie Model) veel aandacht2. Het werken met één model door meerdere partijen wordt daarbij

1 Bron: presentatie Ibis4Bim, 27 november 2008 te ´s-Hertogenbosch 2 Tal van artikelen zijn te vinden in vakbladen als Cobouw en CAD Magazine

tekentafel tekenpakketten (lijnen) modelleerpakketten (elementen)

Introductie

15

ondersteund, maar de universele uitwisselbaarheid van IFC wordt vaak achterwege gelaten. Evenementen als de ‘BIM Caseweek’, waarbij grote professionele opdrachtgevers3 betrokken worden, zorgen voor een groot draagvlak om BIM op de Nederlandse markt in praktijk te brengen wat aanleiding is geweest om dit onderzoek naar de mogelijkheden van een BIM voor de bouwkostendeskundige te doen.

1.3 Doelstelling Dit onderzoek richt zich op de rol van de bouwkostendeskundige in het

bouwproces en op de voor hem beschikbare manieren om bouwkosten met behulp van een Bouw Informatie Model te bepalen. Het doel van dit onderzoek kan als volgt worden geformuleerd;

Een randvoorwaarde bij deze doelstelling is, dat de kwaliteit van de resultaten

ten opzichte van de traditionele methoden niet in het geding mogen komen.

1.4 Onderzoeksvraag Om het doel te bereiken, is de inleidende stelling van dit rapport (Eastman,

Teicholz, Sacks en Liston, 2008) vertaald naar een vraag. Ervan uitgaande dat een BIM zekere informatie bevat is de vraag niet óf bouwkosten met behulp van een Bouw Informatie Model kunnen worden bepaald, maar onder welke voorwaarden;

1.5 Het onderzoek Voor dit onderzoek is het onderzoeksmodel van Schema 1-1 opgesteld. De

voorstudie, waarin een literatuurstudie is verricht naar de termen calculeren (het 3 Gemeentewerken Rotterdam als opdrachtgevende partij in 2007 en de Rijksgebouwendienst in

2008

Het doel van dit onderzoek is om met behulp van een Bouw Informatie Model bouwkosten te bepalen.

‘Onder welke voorwaarden is het mogelijk om bouwkosten met behulp van een Bouw Informatie Model te bepalen?’

Calculeren met BIM

16

doel) en BIM (het middel) is in mei 2008 afgerond met een afstudeerplan dat aanleiding voor dit onderzoek geweest is. Relevante delen van deze voorstudie zijn terug te vinden in deze rapportage.

Schema 1-1; onderzoeksmodel

Deze rapportage zal antwoorden geven op de deelvragen die leiden tot beantwoording van de onderzoeksvraag. In Hoofdstuk 2 en Hoofdstuk 3 wordt antwoord gegeven op de vraag hoe de bouwkostendeskundige binnen het traditionele proces zijn rol vervult en waaruit zijn werkzaamheden bestaan. Hoofdstuk 4 gaat in op de term ‘Bouw Informatie Model’ en de wijze waarop deze modellen momenteel in Nederland worden gebruikt. Het universele uitwisselformaat IFC wordt in Hoofdstuk 5 toegelicht. Hoofdstuk 6 vergelijkt de benodigde gegevens voor de bouwkostendeskundige met de in een BIM aanwezige gegevens. Tevens worden hier de eerste aanzetten gegeven tot mogelijke oplossingen om de aansluiting tussen de gegevens te verbeteren. Aan de hand van het gedane onderzoek zal in Hoofdstuk 7 een ontwerp voor een model worden omschreven dat dient om de doelstelling van dit onderzoek te bereiken. Dit model is uitgewerkt in een prototype dat in Hoofdstuk 8 aan de orde zal komen.

literatuur- en vakstudie

projectinformatie onderzoek

bepalen randvoorwaarden

ontwikkelen prototype

afstudeerplan

concept eindrapportage

definitieve eindrapportage

begripdefinitie

plandefinitie

methode bepalen

slotconclusies

voorstudie onderzoek ontwikkeling

Bouwkosten

17

Hoofdstuk 2

Bouwkosten

De term ‘Calculeren’ in de titel van dit afstudeerplan is eigenlijk geen juiste term. Calculeren heeft betrekking op het opstellen van bouwkosten aan de hand van een ontwerp dat klaar is om uitgevoerd te worden. Vrijwel alle gegevens zijn dan dus bekend. Werkzaamheden van de bouwkostendeskundige vinden echter ook al in eerdere fasen van het bouwproces plaats, waarin bouwkosten worden opgesteld in de vorm van een raming of begroting.

Dit hoofdstuk omschrijft de traditionele werkzaamheden van de bouwkosten-

deskundige gedurende het bouwproces.

2.1 Het bouwproces Het bouwproces begint met een behoefte aan huisvesting en het initiatief tot de

ontwikkeling daarvan. Bouwkosten spelen vanaf dat moment een prominente rol bij de toetsing van de haalbaarheid van het initiatief. Van de bouwkosten-deskundige wordt dan ook verwacht om een reële inschatting van de kosten te maken. Omdat er dan nog weinig gegevens beschikbaar zijn, wordt een inschatting gemaakt op basis van aannamen en opgedane kennis uit het verleden. De aannamen staan symbool voor de keuzevrijheid die de betrokken partijen hebben om het ontwerpprobleem op te lossen. Naarmate er, gedurende het bouwproces, meer definitieve keuzes worden gemaakt om te komen tot een eindproduct, neemt deze keuzevrijheid af. Poortman (1990) omschrijft deze afname van de keuzevrijheid als een gevolg van het afvallen van alternatieve keuzemogelijkheden gedurende het proces (Figuur 2-1).

Afname van de keuzevrijheid leidt tot afname van het aantal aannamen in de kostenschatting en toename van de nauwkeurigheid daarvan.

Calculeren met BIM

18

Figuur 2-1; Keuzevrijheidverloop gedurende het proces. (Bron: Poortman, 1990)

2.2 Detailniveaus Om de toename van de nauwkeurigheid te kunnen onderbouwen, wordt het

project opgedeeld in meerdere detailniveaus, waarbij in een piramideachtige structuur de opbouw van het project af te lezen is. Elk detailniveau is een verfijning van het bovenliggende – meer algemene – detailniveau (Figuur 2-2). Het hoogste detailniveau is het niveau dat het gehele project of gehele gebouw vertegenwoordigd. Het laagste detailniveau is het niveau waar de benodigde hoeveelheid materiaal, arbeid, materieel en onderaanneming uit kan worden afgeleid dat nodig is om hetgeen op het bovenste niveau is omschreven te kunnen realiseren – het MAMO niveau4.

Het opdelen van het project in meerdere eenheden is een projectafhankelijke

opgave, waarbij het aantal niveaus en de verdeling daarvan wordt bepaald door de complexiteit, de omvang en de diversiteit aan bijvoorbeeld materialen van het totale project.

4 MAMO staat voor de afkorting van materiaal, arbeid, materieel en onderaanneming

Bouwkosten

19

Figuur 2-2; Detailniveaus van een project (Bron: Jonge, 2005)

2.3 Bouwfasen Bouwkosten spelen gedurende het hele bouwproces een rol. Het proces dat niet

alleen bestaat uit het realiseren van het object, maar ook uit het traject dat vooraf gaat aan de start van de uitvoering en de periode van ingebruikname. Om alle achtereenvolgende, bij dit traject behorende handelingen, beheersbaar te houden, wordt het proces opgedeeld in fasen. Zoals blijkt uit het keuzevrijheidsverloop van Poortman (1990) in Figuur 2-1, geeft het afvallen van alternatieve keuzemogelijkheden gedurende het proces de mogelijkheid om fasen af te ronden.

Over deze fasering van het bouwproces en de benaming ervan zijn de meningen verdeeld. Niet alleen zijn er een groot aantal informatiebronnen welke op verschillende wijze procesfasen beschrijven, ook zullen onderscheiden fasen elkaar in praktijk overlappen of zelfs door elkaar heen lopen. Poortman (1990) toont de procesfasen zoals deze zijn omschreven in NEN 2634 ‘Termen, definities en regels voor het overdragen van gegevens over kosten- en kwaliteitsaspecten voor bouwprojecten’ van het Nederlands Normalisatie Instituut (2002). Deze norm richt zich specifiek op het onderdeel bouwkosten en kwaliteit en omschrijft welk product en met welke kwaliteit een opdrachtgever in elke fase mag verwachten van een bouwkostendeskundige. Figuur 2-3 geeft een deel van de hoofdtabel van deze normering weer.

Calculeren met BIM

20

Figuur 2-3; Niveau van informatieoverdracht gedurende de bouwfasen (Bron: NNI, 2002)

Uit de legenda blijkt de toename in detailniveau bij verloop van de bouwfasen, welke grafisch zijn weergegeven in de verdeling van detailniveaus in Figuur 2-2. De verdeling van bouwfasen is dus onder andere een toetsingsmiddel voor de opdrachtgever bij het bepalen van de kwaliteit van de door derden aangeleverde gegevens. Het detailniveau waarop deze gegevens zijn uitgewerkt moet immers stroken met de fase waarin het project zich bevindt.

Het onderscheid in deze nauwkeurigheid wordt aangeduid met de termen ramen, begroten en calculeren.

2.4 Ramen, begroten, calculeren De termen ramen, begroten en calculeren hebben allen betrekking op het bepalen

van bouwkosten. Het verschil in benaming ligt in de procesfasen waarin de methoden worden toegepast, de beschikbare gegevens die er zijn voor de inschatting en de nauwkeurigheid daarvan. In dossier 5 van Keyner en Rosmalen

Bouwkosten

21

(2001) worden de volgende gegevens met betrekking tot het bepalen van de bouwkosten onderscheiden;

Ramen; op basis van kengetallen of eenheidsprijzen in de oriëntatie- of projectdefinitiefase.

Begroten; op basis van prijs maal hoeveelheid in de ontwerpfasen. Calculeren; vanuit de redenering hoe het werk gerealiseerd gaat worden

in de aanbestedingsfase en op basis van meer- en minderwerk in de uitvoeringsfase.

Uit de omschrijvingen blijkt wederom het toenemende detailniveau van

informatie naarmate de latere procesfasen worden bereikt. Een combinatie van de bevindingen uit NEN 2634 (2002) en de omschrijving welke door Keyner en Rosmalen (2001) voor de kostenbepalingsvormen wordt gehanteerd levert het resultaat van tabel 2-1.

Tabel 2-1; Combinatietabel projectfasen en kostenbepalingsvormen

De raming, die zonder ontwerp in de programmafase wordt opgezet om de haalbaarheid te toetsen, bereikt in de ontwerpfase het niveau van een begroting wanneer hoeveelheden afgeleid kunnen worden uit het ontwerp. Niet alle elementen hoeven dan al fysiek in het ontwerp aanwezig te zijn, maar kunnen wel op basis van hetgeen al wel ontworpen is worden ingeschat. Ook hiervoor worden – zoals voor de raming – kengetallen gebruikt. De kengetallen blijven dus ook bij de begroting en calculatie een rol spelen, maar de functie ervan verplaatst zich gedurende het proces van een raming- of budgetteringsfunctie naar een toetsingsfunctie.

De laatste begroting, aan het eind van de ontwerpfase welke wordt afgesloten met het definitief ontwerp, is de directiebegroting die bij de aanbesteding5 wordt

5 Bij de aanbesteding wordt de aannemer geselecteerd die het werk zal gaan uitvoeren.

Fasen van het bouwproces*

Kosten- bepalingsvorm**

Beschikbare kostengegevens**

Programma Ramen kengetallen/ eenheidsprijzenOntwerp Begroten prijs x hoeveelheidUitwerking Calculeren uitvoeringswijzeRealisering Calculeren meer- en minderwerkGebruik* NEN 2634, ‘Termen, definities en regels voor het overdragen van …** Keyner en van Rosmalen (2001)

Calculeren met BIM

22

gebruikt om de inschrijfbegroting van de aannemer te toetsen. Aangezien dit een uitvoerende partij is, zal deze een calculatie op basis van de specifieke uitvoeringswijze maken. Dit geldt ook voor inschatting van eventuele meer- en minderwerken6.

2.5 Kengetallen Kengetallen geven verhoudingen weer tussen verschillende factoren welke in

vroege fasen gebruikt kunnen worden voor raming en in latere fase voor toetsing. Zo kan met behulp van kengetallen, op basis van de huisvestingsbehoefte van de initiatiefnemer, een inschatting worden gemaakt van de benodigde ruimte en de daarmee gepaard gaande kosten, zonder dat daar een ontwerp aan ten grondslag ligt. Andersom kan een eenmaal gemaakt ontwerp worden getoetst op efficiëntie door de hoeveelheid ontworpen ruimte te vergelijken met de oorspronkelijke huisvestingsbehoefte en de relatie met kengetallen.

Tabel 2-2; gebruik van kengetallen per fase (Bron: Keyner en Rosmalen, 2001)

In deze situatie wordt gebruik gemaakt van programmatische kengetallen, waarbij de wensen uit het programma van eisen worden vertaald naar benodigde ruimte. Op basis van deze resultaten – het benodigde vloeroppervlak – kunnen met behulp van hoeveelheidkengetallen weer andere gegevens, zoals het gevel- of dakoppervlak worden bepaald.

Kostenkengetallen geven indicaties van de kosten per eenheid op elk gewenst detailniveau en geven bijvoorbeeld een prijs per eenheid geveloppervlak. Tabel 2-2 laat de functie van kengetallen in de verschillende fasen zien.

6 Meer- en minderwerken treden op wanneer tijdens de uitvoeringsfase nog wijzigingen in het

ontwerp worden aangebracht of blijkt dat het ontwerp onvolledig is

Oriëntatie Project- definitie

Ontwerp Bestek en aanbeste-

ding

Uitvoering Ingebruik- name

Gebruik

xx xx xx

xx xx xx x x x xx

xx xx xx x x x xx

x = ten behoeve van toetsingxx = ten behoeve van raming en toetsing

Hoeveelheden

Kosten

Projectfasering

Soort kengetal

Programmatisch

Bouwkosten

23

2.6 Begrotingsstructuur De inschatting van kosten, die in de eerste fasen bestaat uit een raming op basis

van kengetallen op gebouwniveau, volgt gedurende het proces de indeling in de gekozen detailniveaus. Deze verdeling is niet in de laatste plaats ontwikkeld om ramingen, begrotingen en calculaties toetsbaar te houden. Bij een volgende inschatting wordt de eerste raming niet vervangen, maar met de gedetailleerdere gegevens onderbouwd, zodat op het topniveau – het gebouw – de totale kosten zichtbaar blijven. Wijzigingen op de lager gelegen niveaus in de piramidestructuur worden doorvertaald naar de bovenliggende niveaus.

Infrastructuurvoorzieningen

(0-) (1-) (2-) (3-) (4-) (5-)PROJECT FUNDERINGEN RUWBOUW AFBOUW AFWERKINGEN INSTALLATIETOTAAL WERKTUIG-

BOUWKUNDI(10) (20) (30) (40) (50)Gereserveerd Gereserveerd Gereserveerd Gereserveerd Gereserveerd(11) (21) (31) (41) (51)Bodem- Buitenwanden Buitenwand- Buitenwand- Warmte-voorzieningen openingen afwerkingen opwekking

(12) (22) (32) (42) (52)Gereserveerd Binnenwanden Binnenwand- Binnenwand- Afvoeren

openingen afwerkingen

(13) (23) (33) (43) (53)Vloeren op Vloeren Vloeropeningen Vloerafwerkingen Watergrondslag

(14) (24) (34) (44) (54)Gereserveerd Trappen en hellingen Balustrades en Trap- en helling Gassen

Bouwkundige voorzieningen Tec

Tabel 2-3; Hoofdtabel Elementenmethode 2005, partiële weergave (Bron: BNA, 2005)

Herkenbaarheid van niveaus in de inschatting wordt verkregen door een codestructuur toe te passen waarmee elk onderdeel uit de piramide aan zijn bovenliggende onderdeel kan worden gekoppeld. Doordat de indeling grotendeels projectafhankelijk is, kan ook de gebruikte codestructuur variëren. Toch zijn veel – vaak bedrijfseigen – codestructuren afgeleid van de nationaal bekende en bouwbreed toegepaste elementenmethode7 van de Bond van Nederlandse Architecten (BNA, 2005). Een voordeel van toepassing van deze methode is dat de wijze van verdeling van elementen bij een groter publiek bekend is.

7 Deze methode vindt men onder andere terug in de Nederlandse Bouw Documentatie (NBD) en

onderleggers voor lagen in bouwkundige tekenpakketten.

Calculeren met BIM

24

De elementenmethode is gebaseerd op onderscheid in functies, waarbij een verdeling in een viertal niveaus wordt gehanteerd; elementgroepen, elementen, variant-elementgroepen en variant-elementen.

Tabel 2-3 geeft een deelweergave van de hoofdtabel van de elementenmethode, waarin de verdeling in functies tot niveau van elementen zichtbaar is, overeenkomend met het derde niveau van NEN 2634 (NNI, 2002) (Figuur 2-3).

Aannemers redeneren vanuit de wijze waarop het werk wordt gerealiseerd. Zij maken hun inschattingen op het niveau van calculaties daarom op basis van een onderscheid in werksoort (schilderwerk, betonwerk, metselwerk, etc.) in plaats van een onderscheid in functie. In Nederland is de STABU-codering (STABU, 2005), die ook basis is voor het schrijven van bestekken, daarvoor de meest toegepaste methode. Het laagste detailniveau van materiaal, arbeid, materieel en onderaanneming wordt dan ook op basis van deze systematiek gecodeerd.

Stichting STABU en de Bond voor Nederlandse Architecten proberen al geruime tijd een coderingssystematiek te ontwikkelen waarin beide methoden hun weg kunnen vinden (STABU, 2005a). De eerste ontwerpen daarvoor zijn gemaakt (Figuur 2-4), maar tot een publicatie van een werkende systematiek voor algemeen gebruik is het tot nu toe nog niet gekomen.

Figuur 2-4; Toelichting van een koppeling tussen de elementen- en STABU coderingssystematiek

(Bron: STABU, 2005a)

Projectanalyse

25

Hoofdstuk 3

Projectanalyse

,,Kostendeskundigheid is kennis van bouwkosten in relatie tot de kwaliteit.’’

Ir. J.A.G. Dukers, oktober 2008

Hoe gedetailleerd van opzet ook, zowel de raming als de begroting en de

calculatie bevatten een zekere mate van onnauwkeurigheid. Wat de realisatie van een project werkelijk kost zal pas blijken als de realisatiefase is afgesloten en er door de uitvoerende partij een nacalculatie op basis van nota’s, inkoopfacturen, overheadkosten, etc. wordt gemaakt.

Voor de bouwkostendeskundige is projectanalyse een fase eerder – op het moment dat de aannemer wordt gekozen – interessant. Op dat omdat is de nauwkeurigheid van zijn kostenschatting het grootst. De uitkomst ligt dan immers het dichtst bij het bedrag waarvoor de aannemer het werk zal gaan uitvoeren.

Figuur 3-1; De calculatiecyclus

Calculeren met BIM

26

Figuur 3-1 laat zien dat de gegevens uit een projectanalyse gebruikt kunnen worden bij de raming van volgende projecten.

3.1 Resultaten Het resultaat van projectanalyse is een samenvatting van het project, waarin

kenmerken opgenomen zijn die gebruikt kunnen worden voor inschatting van volgende, soortgelijke projecten. Onderdeel van deze analyse zijn de in Paragraaf 2.5 besproken kengetallen. Doordat op het moment van analyse vrijwel alle gegevens bekend zijn is het mogelijk om zowel programmatische- als hoeveelheids- en kostenkengetallen op alle detailniveaus te bepalen. Gezocht wordt naar juist die kengetallen waarvan uit ervaring blijkt dat deze voor verschillende projecten binnen een bepaalde bandbreedte liggen. Dit zijn namelijk toepasbare kengetallen voor toekomstige projecten, omdat zij voor die projecten ook niet ver van die bandbreedte af zullen liggen.

Omdat de begrotingsstructuur projectafhankelijk is, moeten de gegevens uit een projectanalyse worden vertaald naar universeel toepasbare getallen, welke voor elk nieuw te realiseren project gebruikt kunnen worden. Het ligt voor de hand om eerst enkele algemeen toepasbare hoeveelheidskengetallen op gebouwniveau – zoals het totale vloeroppervlak – vast te stellen, omdat daarmee de eerste hoeveelheden van een volgend project kunnen worden bepaald. Dergelijke hoeveelheidskengetallen op hoog niveau, zogenaamde vormfactoren, kunnen eenduidig worden vastgelegd met behulp van NEN 2580 (NNI, 2007), waarin de bepalingsmethode voor oppervlakten en inhouden van gebouwen staat omschreven. De relatietabel, die weergeeft hoe de verhouding is van oppervlakten, is weergegeven in Figuur 3-2.

Door het toekennen van waarden aan deze verhoudingen – de vormfactoren – kan de efficiëntie van een volgend ontwerp worden getoetst. Een afnemende factor van het netto vloeroppervlak (NVO) ten opzichte van het bruto vloeroppervlak (BVO) betekent een minder efficiënt ontwerp omdat er blijkbaar meer terra oppervlakte (TO; wanden, schachten en dergelijke) nodig is om dezelfde hoeveelheid bruikbare ruimte te creëren.

Projectanalyse

27

Figuur 3-2; Relatie tussen vloeroppervlakten onderling (Bron: NNI, 2007)

Een combinatie van de vormfactoren en het programma van eisen kan resulteren in programmatische kengetallen. Een voorbeeld daarvan is een kengetal waaruit blijkt dat er voor elke medewerker van een kantoorpand ongeveer 20 m2 bruto vloeroppervlak nodig is. Kostenkengetallen worden eveneens op elk niveau bepaald. Voorbeelden daarvan zijn de bepaling van de kosten per m2 bruto vloeroppervlak op de algemene niveaus tot de kosten per m3 beton op de gedetailleerde niveaus.

Een belangrijk onderdeel van de analyse is de omschrijving van het project op verschillende detailniveaus. Informatie die kan leiden tot verschil in kosten, zoals functie, locatie, prijspeil, etc. worden opgenomen in deze omschrijving en dient als selectiecriterium bij het gebruik van de kengetallen bij volgende projecten (Keyner en Rosmalen, 2001)

Calculeren met BIM

28

3.2 Referentiemethoden Een project waarvan een projectanalyse is gemaakt, kan bij een volgend project

dienen als referentiemiddel voor zowel raming als toetsing. Zo kan bij een raming de aanname worden gedaan dat de kosten per eenheid vormfactor van het nieuwe project gelijk zijn aan die van het referentieproject. Bij toetsing kan gecontroleerd worden of de onderlinge verhoudingen tussen vormfactoren en de prijzen per eenheid vormfactor – het kostenkengetal – overeen komen met de referentie.

Een van de eerste vormfactoren die aan de hand van het programma van eisen met behulp van programmatische kengetallen bepaald kan worden is in veel gevallen het bruto vloeroppervlak. Voor veel projecten is dit dan ook de eerste vormfactor op basis waarvan de eerste raming wordt gemaakt als verder nog geen gegevens beschikbaar zijn. Vooral architecten maken van deze methode gebruik om de omvang van het ontwerp te toetsen aan het gestelde budget.

De Jonge (2005) deed onderzoek naar de wijze waarop architecten hun

verschillende ontwerpoplossingen op financiële haalbaarheid toetsen en kwam tot de conclusie dat zij wel in staat waren op algemeen niveau (het totale gebouw) en het niveau van de technische oplossingen (metselwerk wand, kalkzandsteen wand, etc.) snel een inschatting te maken, maar niet om inschattingen te maken op de tussengelegen niveaus. Juist op die niveaus moeten de alternatieve keuzemogelijkheden budgettair met elkaar worden vergeleken. Hij maakte een financiële analyse van 60 projecten en stelde een database op met projecten en hun kosteninformatie.

Op basis van deze database werd de Winket Projecten Referentiemethode ontwikkeld. Uitgangspunt bij deze methode, is dat de kosten van een project per m2 bruto vloeroppervlak worden gebaseerd op de prijs van per m2 bruto vloeroppervlak van een referentieproject uit een referentieprojecten database. De referentieprojecten zijn opgesteld aan de hand van inschrijfbegrotingen van aannemers en opgebouwd volgens de elementenmethode (Paragraaf 2.6). Het detailniveau loopt van het eerste (totale gebouw) tot en met het derde (elementen) detailniveau van deze methode. De eenheidsprijzen op het elementniveau zijn gebaseerd op zogenaamde gestandaardiseerde recepten van technische oplossingen. Een recept is een combinatie van losse handelingen die tezamen leiden tot een geheel (het element). Het idee van Jonge (2005) achter deze methode is, dat wanneer een passend referentieproject wordt gekozen – een referentie die voldoende aansluit bij het nieuwe project – pas in de detailfasen van het ontwerp gekeken hoeft te worden naar alternatieve technische oplossingen. In de periode

Projectanalyse

29

daarvoor zijn wijzigingen in de grovere maten van het gebouw voldoende om de inschatting van bouwkosten te maken.

In 2007 werd een combinatie gelegd tussen de Winket Projectenreferentie Methode en het calculatiepakket Kubus Calc (Jonge, Zonneveld en Rimmelzwaan, 2007), waardoor gebruik van de referentieprojecten sterk vereenvoudigd is. De referentieprojecten zijn allen opgebouwd in de niveau indeling volgens de in Hoofdstuk 2 benoemde NEN 2634 (2002). Het definiëren van een eigen structuur is in deze methode dus niet mogelijk, omdat de referentie gebonden is aan een algemeen toepasbare structuur.

3.3 De factor kwaliteit Dukers (2004) zet de nodige kanttekeningen bij het bepalen van kosten op basis

van het bruto vloeroppervlak en een referentieproject in vroege fasen en verwijst daarbij naar documentatie van het bouwcentrum waarin diverse projecten zijn geanalyseerd. Een deelresultaat daarvan is weergegeven in Grafiek 3-1. De grafiek toont het programmatische kengetal van benodigd vloeroppervlak per medewerker voor diverse projecten. Uit de grafiek blijkt de enorme spreiding van dit kengetal bij gelijksoortige projecten en daarmee de spreiding in de inschatting van het benodigde vloeroppervlak. Bij een verkeerde keuze van de referentie zal de spreiding in vloeroppervlak zich rechtstreeks doorvertalen naar een afwijking in de raming. Bij gebruik van referentieprojecten is de keuze van het juiste referentieproject dus bepalend voor de nauwkeurigheid van ramingen in vroege fasen.

Grafiek 3-1; netto en bruto vloeroppervlak per medewerker voor diverse kantoorgebouwen (Bron:

Dukers, 2004)

Calculeren met BIM

30

Naast de spreiding in dergelijke programmatische kengetallen is er volgens Dukers (2004) een spreiding in de kostenkengetallen op de hoger gelegen niveaus in de piramidestructuur – zoals de kosten per eenheid vloeroppervlak – waarneem-baar als gevolg van variaties in kwaliteit en vormfactoren tussen projecten. Juist deze factoren worden door Keyner en Rosmalen (2001) als kostenbepalende factoren van het ontwerpproces genoemd, waarmee zij bedoelen dat variatie in de factoren een sterke invloed heeft op de uiteindelijke projectkosten.

Om de nauwkeurigheid van ramingen in vroege fasen te vergroten stelt Dukers (2004) daarom dat de inschatting van hoeveelheden van elementen gerelateerd zou moeten worden aan het hoeveelheidskengetal waar zij wegens hun functie aan verbonden zijn – en dus niet alleen aan de vormfactor BVO – waarbij op basis van het programma van eisen al een uitspraak wordt gedaan over de kwaliteit van de elementen.

Op basis van de eerste aannamen voor benodigd vloeroppervlak, zou in deze methodiek een inschatting moeten worden gemaakt van meerdere vormfactoren, zoals het aantal bouwlagen en het bebouwd-, gevel-, en dakoppervlak. Door inschatting van hoeveelheden op elementniveau op basis van een projectenhistorie en de juiste vormfactor – gevelelementen op basis van het geveloppervlak, trappen op basis van het aantal bouwlagen, dakconstructie op basis van het dakoppervlak, etc. – wordt de foutmarge die ontstaat door variatie in de vormfactoren deels geëlimineerd. Wijzigingen aan de vorm van het gebouw in vroege fasen hebben bovendien invloed op slechts een deel van de elementen.

Onnodige afwijkingen tussen realiteit en inschatting ontstaan als op basis van een (verkeerd) gekozen referentieproject de hoeveelheid fundering op staal wordt bepaald terwijl bekend is dat de omliggende panden van het project gefundeerd zijn op palen. Een goed programma van eisen en kennis van de locale omstandigheden maakt het vaak al in vroege fasen mogelijk om uitspraken te doen over de te kiezen technische oplossingen (kwaliteit) van elementen. De tweede oplossing van Dukers (2004) is dan ook om op basis van een aantal voorgedefinieerde kwaliteitsomschrijvingen per element eenheidsprijzen te bepalen die in vroege fasen als ramingsmiddel gebruikt kunnen worden.

Gebruik van deze methode vereist een goed uitgewerkt programma van eisen en specifieke kennis van diegene die de inschatting van kosten maakt. De bouwkostendeskundige dient de nodige ervaring te hebben met de oplossings-mogelijkheden van het soort gebouw (appartement, kantoor, woning, etc.) en de kosten ervan in relatie tot de kwaliteit, zoals Dukers met zijn stelling aan het begin van dit hoofdstuk aangeeft.

Projectanalyse

31

Figuur 3-3; Kostenmatrix voor het bepalen van elementprijzen op basis van vormfactoren en

kwaliteit (Bron: Dukers, 2004)

In navolging op de publicatie van Dukers (2004) werden een aantal modellen voor diverse soorten projecten ontwikkeld, waarmee in een vroeg stadium kosten kunnen worden bepaald op basis van enkele vormfactoren en keuzes voor kwaliteit op elementniveau. Deze modellen werden enkele jaren uitgegeven als budgetsystemen door Kluwer Informatiesystemen. Een van de aan deze modellen ten grondslag liggende matrices voor het gebruik van de vormfactoren en de keuze voor kwaliteit is deels weergegeven in Figuur 3-3.

3.4 Het (traditionele) inschattingsproces Samenvattend kan gesteld worden, dat het inschattingsproces van de

bouwkostendeskundige bestaat uit het inschatten van kosten gedurende het hele bouwproces. Daarnaast heeft hij een controlerende en sturende functie op dit proces op basis van zijn resultaten. Middels kengetallen – al dan niet onderbouwd met referenties – die symbool staan voor een ingeschatte kwaliteit, is hij/ zij in staat om op basis van aannamen een schatting van de kosten te doen. Naarmate het proces vordert zal de nauwkeurigheid toenemen als gevolg van een afname van het aantal aannamen. De afname in aannamen zijn het resultaat van definitieve ontwerpbeslissingen door de deelnemende partijen.

Het Bouw Informatie Model (BIM)

33

Hoofdstuk 4


Het Bouw Informatie Model (BIM) kan gezien worden als de volgende stap in de ontwikkeling van de werkmethodiek zoals geschetst in de inleiding van deze rapportage. Het is enerzijds bedoeld om naast geometrische informatie ook andere kenmerken en eigenschappen van gemodelleerde objecten te bevatten, anderzijds om het communicatieprobleem en het daaruit ontstaande verlies aan informatie te beperken.

Dit hoofdstuk is een introductie naar het universele uitwisselformaat IFC (Hoofdstuk 5), en zal een omschrijving geven van de visie achter een Bouw Informatie Model.

4.1 Tekenen en modeleren Het eerste onderscheid in de traditionele ontwerpmethoden en de werkwijze

volgens het principe van een BIM is de overgang van een geometrisch naar een informatief model. Twee- en drie dimensionale tekenpakketten, werkend met lijnen, punten en twee dimensionale tekenobjecten, bevatten modeltechnisch gezien uitsluitend geometrische informatie over het ontwerp. In informatie modellen is de geometrie slechts onderdeel van de vele eigenschappen van objecten. Eigenschappen die nodig zijn om diverse, discipline specifieke gegevens te bepalen. Dit is anders dan het uitsluitend genereren van een grafische weergave van het model, zoals bij de twee dimensionale tekenpakketten het geval is.

Voor de bouwsector zijn voor het berekenen van deze informatie ook gegevens nodig over de onderlinge relaties tussen objecten en de in het model voorkomende ruimten. Ruimten zijn dan ook een essentieel en aanwijsbaar onderdeel van een BIM.

Calculeren met BIM

34

Figuur 4-1 (Khemlani, 2004) laat grafisch het verschil in opvatting tussen de traditionele geometrische modellen en een BIM zien.

Figuur 4-1; Verschil tussen een geometrisch- (a) en een Bouw Informatie Model (b) (Bron:

Khemlani, 2004)

Het linker fragment (Figuur 4-1a) is een weergave van 2 rechthoeken, met beide een startpunt, een lengte en een breedte. Samen vormen zij een figuur waaruit een ruimte met omringende wanden is af te lezen, maar waar voor het model alleen een relatie bestaat tussen een punt en een rechthoek. Het is dus een louter geometrisch model. Het rechter fragment (Figuur 4-1b) daarentegen bestaat uit een model met vier wanden die een ruimte doen ontstaan. Aangezien het model gegevens van de wanden bevat, waaronder de dikte (depth) en lengte (length) van de wanden, zijn de vier startpunten (start point) voldoende om het model geometrisch op te bouwen. Door de aaneenschakeling van de vier wanden heeft wand 1 een relatie met de aanliggende wanden 2 en 4 (connected walls) alsmede met de aangrenzende ruimte (attached spaces).

De onderlinge relaties vereenvoudigen niet alleen het modelleerwerk – het nieuwe tekenwerk – maar bieden tevens mogelijkheden voor andere disciplines dan alleen de ontwerpende om gegevens te genereren die nodig zijn voor de uitvoering van de werkzaamheden.


35

4.2 Een centraal model En van de onderscheidende eigenschappen van het bouwproces ten opzichte van

andere processen is de variërende samenstelling van deelnemende partijen. Bij het gebruik van een BIM zou in de ideale situatie dit hele team de beschikking hebben over één digitaal model. In de praktijk zal dit neerkomen op een situatie waarbij de partijen in het bezit zijn van delen van het totale model, waarvan de gebruiker een totaalbeeld kan genereren door koppeling van de juiste informatie uit de deelmodellen. Op deze wijze kunnen alle partijen gedurende het hele bouwproces benodigde gegevens uit het model genereren en gegevens met betrekking tot hun eigen discipline aan het model toevoegen (figuur 4-2). De deelmodellen zijn over de partijen verdeeld of centraal op een server opgeslagen.

Figuur 4-2; Het Bouw Informatie Model in het bouwteam (Bron: NIBS, 2007)

De figuur laat zien, dat het BIM gedurende het hele proces, van ‘briefing’ (programma van eisen) tot en met ‘demolition’ (sloop) actief is en dat informatie van en naar het model wordt uitgewisseld met deelspecifieke programma’s.

In Nederland beginnen zich de eerste projecten voor te doen waarbij de opdrachtgever een dergelijke werkmethodiek vereist en van de deelnemende partijen verwacht te beschikken over de middelen die dergelijke werkwijze mogelijk maken8. Ook grote professionele opdrachtgevers – zoals Rijkswaterstaat en de Rijksgebouwendienst – hebben het voornemen om op korte termijn eisen te

8 Bron: presentatie Bim Bouw Box, 16 maart 2009 te Rotterdam

Calculeren met BIM

36

stellen aan de wijze van communiceren tussen partijen die het gebruik van een centraal model zullen bevorderen9. In de praktijk betekent dit momenteel nog dat de partijen de beschikking hebben over gelijke softwaremiddelen waarmee onderling gecommuniceerd wordt, omdat in de praktijk blijkt dat universele uitwisseling tussen verschillende software niet zondermeer mogelijk is.

Commercieel gezien is verdere ontwikkeling van deze toepassing van BIM

interessant voor software leveranciers die hun product bruikbaar hebben gemaakt voor meerdere disciplines van het bouwproces. Bij voorschrijven door de opdrachtgever van gebruik van een BIM worden betrokken partijen min of meer verplicht tot aanschaf van een licentie voor het door de opdrachtgever gekozen pakket omdat alleen daarmee onderlinge communicatie mogelijk is.

Het door deze leveranciers investeren in universele uitwisselingsmogelijkheden zal alleen haalbaar zijn als er voldoende draagvlak is voor gebruik van het uitwisselformaat (Khemlani, 2004). Een dergelijk universeel formaat kan bijdragen aan verbetering van de informatieoverdracht tussen de variërende partijen.

4.3 BuildingSmart Het centrale model biedt oplossingen voor de communicatieproblemen tussen

verschillende disciplines in het bouwproces, maar niet direct oplossingen voor de onuitwisselbaarheid van informatie tussen partijen. De gedachte van BuildingSmart10 gaat daarom verder dan uitsluitend het werken met één model door het introduceren van een universeel uitwisselbaar bestandsformaat; Industry Foundation Classes (IFC). Dit bestandsformaat – dat nader zal worden toegelicht in Hoofdstuk 5 – is ontwikkeld om als communicatiemiddel tussen discipline-eigen software applicaties te fungeren welke gebruikt worden in het bouwkundig ontwerpen beheerproces van een gebouw.

Evenals bij gangbare modelleerpakketten als Revit en ArchiCAD, kan binnen het concept van BuildingSmart gebruik gemaakt worden van een objectenbibliotheek. Het eveneens universele formaat hiervoor is bekend als International Framework for Dictionaries (IFD) waarin eigenschappen van objecten eenduidig zijn vastgelegd. Voor de bouwsector in Nederland is Stichting STABU verantwoordelijk

9 Bron: presentatie BIM Caseweek 2008, 21 november 2008 te Utrecht 10 Een wereldwijde organisatie, bestaande uit commerciële bedrijven en onderzoeksinstellingen,

die zich tot doel heeft gesteld de communicatie in het bouwproces te verbeteren


37

voor de ontwikkeling van deze objectenbibliotheek. Stichting STABU is daarmee deelnemer aan de IFD Library Group waarin met deelnemers uit verschillende landen wordt samengewerkt om IFD als internationale standaard gereed te maken voor marktimplementatie (Haaften, 2009).

Een derde ontwikkeling van BuildingSmart is een omschrijving van de wijze waarop informatie tussen partijen uitgewisseld dient te worden om tot de gewenste resultaten te komen. De wijze van overdracht en interpretatie van de gegevens wordt daartoe omschreven in het Information Delivery Model (IDM).

Industry Foundation Classes (IFC)

39

Hoofdstuk 5


Industry Foundation Classes (IFC) is een door BuildingSmart ontwikkeld bestandsformaat waarmee informatie uit een Bouw Informatie Model, software onafhankelijk kan worden uitgewisseld tussen verschillende partijen. Naast de term Bouw Informatie Model wordt ook wel gesproken over IFC model om een model aan te duiden dat in dit formaat beschikbaar is. In dit onderzoek is de structuur en inhoud van een IFC bestand van belang om te bepalen of er een aansluiting te vinden is met de informatie uit een kosteninschatting en dit bestandsformaat. Daarom zal in dit hoofdstuk ingegaan worden op de wijze waarop een IFC bestand is opgebouwd. Gezien de technische aard van dit hoofdstuk is ter verduidelijking een verklarende woordenlijst van gebruikte termen opgenomen in Bijlage 2.

5.1 De IFC structuur Een IFC bestand bestaat uit platte tekst, waaruit programma’s informatie

kunnen aflezen. Verschil met vele andere bestanden is dat de tekst in een IFC bestand in een open bestandsformaat geschreven is. Dat wil zeggen dat het met elke willekeurige teksteditor11 te openen en te lezen is. Een en ander heeft te maken met de niet-commerciële doeleinden van de ontwikkelende partij BuildingSmart. Diverse modelleerapplicaties zijn in staat om vanuit de eigen modelstructuur een IFC bestand middels een exporteerfunctie te genereren.

11 Een teksteditor is een programma waarmee tekst geschreven en gelezen, maar niet opgemaakt

kan worden

Calculeren met BIM

40

Volgens een benchmark van Robbemondt (2008) kan bij deze export 99% van de totaal in het model aanwezige informatie worden ondergebracht in het IFC model.

Een naar het IFC formaat geëxporteerd bestand bestaat uit twee delen, te weten;

1. De ‘header-sectie’, welke informatie bevat over het bestand als zodanig en 2. De ‘data-sectie’, waarin zich de informatie van het model zelf bevindt.

In dit hoofdstuk zal enkele malen gebruik worden gemaakt van een voorbeeld van een IFC bestand, dat afkomstig is van TNO (Bonsma, 2008).

5.1.1 De architectuur De wijze waarop de data-sectie van een IFC bestand is opgebouwd is afhankelijk

van de onderliggende architectuur. Deze architectuur, met de huidige versie ‘ifc2x3 final’ (Afbeelding 5-1) bestaat uit een viertal lagen, welke zijn verdeeld in schema’s. Elk schema heeft zijn eigen entiteiten met bijbehorende eigenschappen.

Afbeelding 5-1; Architectuur van de Industrial Foundation Classes (Bron: BuildingSmart, 2005)


41

De ‘domain layer’ (boven in de figuur) bevat entiteiten die specifiek betrekking hebben op een bepaalde discipline (domain) en derhalve specifieke eigenschappen bevatten welke niet van nut zijn voor entiteiten uit andere schema’s. Deze laag kan worden beschouwd als het meest gedetailleerde niveau van de IFC architectuur. Verder naar beneden in de structuur worden de niveaus algemener voor entiteiten die juist de communicatie tussen de domeinen mogelijk maken (de ‘interoperability layer’) en clusters van entiteiten, die op de hogere lagen verder worden uitgesplitst (‘core-layer’). De ‘resource layer’ wordt door de entiteiten in de overige lagen aangeroepen als typeaanduiding van entiteiten is bedoeld om de eigenschappen eenduidig vast te kunnen leggen (Clemen en Gründig, 2006).

De basis van de IFC architectuur – het meest abstracte niveau – is het Kernel-

schema. Het Kernel schema bevat de ‘root’ informatie van alle klassen in de overige lagen. De klassen ontstaan door een specialisatie in niveaus van de root. Het eerste specialisatie niveau van de IFC klassenstructuur is weergegeven in Afbeelding 5-2. De drie daaruit volgende klassen zijn de fundamentele entiteiten van het IFC model (Liebich, 2004);

Objecten; alle tastbare ‘dingen’, zoals wanden vloeren, daken, etc. en fysiek aanwezige ‘dingen’, zoals ruimten, stramienen en andere virtuele elementen. Ook processen, beschikbare middelen, planningen, etc. worden tot objecten gerekend.

Relaties, die verbinding leggen tussen objecten onderling en tussen objecten en eigenschappen.

Eigenschappen, die aanvullende informatie dragen over de in het model aanwezige objecten.

Afbeelding 5-2; Eerste specialisatie niveau van de IFC structuur (Bron: Liebich, 2004)

Deze drie entiteiten zijn generalisaties van de overige entiteiten in de structuur. Uit de omschrijvingen blijkt dat niet alleen de veelzijdige informatie van het te ontwerpen object (het gebouw) is opgenomen in het model, maar ook alle andere informatie die nodig is om het bouwproces van begin tot eind te doorlopen.

Calculeren met BIM

42

5.1.2 Definities De definitie van entiteiten, en de wijze waarop de entiteiten worden voorzien van

eigenschappen is gedefinieerd in de modelleertaal Express, een taal die ontwikkeld is om informatie en de onderlinge relatie daartussen te definiëren (Wilson, 1998). Een deel van het Express schema, die de architectuur van versie 2x3 final bevat, is als voorbeeld weergegeven in Schema 5-1. Hierin is de definitie van de entiteit IfcRoot en haar eigenschappen opgenomen.

Schema 5-1; Definitie van de entiteit IfcRoot in de IFC architectuur (Bronbestand: ifc2x3.EXP)

Uit het schema blijkt dat elke sub-entiteit van de IfcRoot een unieke eigenschap ‘GlobalId’ heeft en daarnaast nog een OwnerHistory, Name en Description.

5.1.3 Entiteiten De entiteit IfcRoot is een zogenaamd ‘abstract supertype’. Dit houdt in dat het

alleen bepalend is voor de eigenschappen van de sub-entiteiten – zij erven de eigenschappen van de IfcRoot – maar dat zij zelf niet als entiteit in het model kan voorkomen. Entiteiten die daadwerkelijk voor kunnen komen in de data-sectie van het IFC model worden ‘instanties’ genoemd. Een dergelijke instantie is een entiteit waarvan de eigenschappen een waarde gekregen hebben. De entiteit is dus eigenlijk het sjabloon van de instantie. Dit kunnen zowel objecten als relaties en eigenschappen zijn. Een voorbeeld daarvan is gegeven in Schema 5-2, waarin aan een object (IfcWallStandardCase), middels een relatie aan een opening (IfcOpeningElement) met daarin een raam (IfcWindow) is gerelateerd.

ENTITY IfcRoot ABSTRACT SUPERTYPE OF (ONEOF (IfcObjectDefinition ,IfcPropertyDefinition ,IfcRelationship)); GlobalId : IfcGloballyUniqueId; OwnerHistory : IfcOwnerHistory; Name : OPTIONAL IfcLabel; Description : OPTIONAL IfcText; UNIQUE UR1 : GlobalId; END_ENTITY;

Opgave van de sub-entiteiten van de root

Kenmerken van de eigenschappen van de IfcRoot

Definitie van de unieke eigenschap (GlobalId)


43

Schema 5-2; Voorbeeld van een entiteiten, eigenschappen en relaties

Schema 5-2, het voorbeeld uit het IFC bestand laat voor elke instantie een opsomming van eigenschappen zien12 maar het is niet duidelijk om welke eigenschappen het gaat. De definitie daarvan is immers onderdeel van het Express schema. Het IFC bestand zal daarom moeten verwijzen naar het gebruikte schema om aan te geven welke definities voor de opzet van het IFC bestand gebruikt zijn. Dit gebeurd in de Header-sectie van het IFC bestand, waarin tevens algemene informatie van het bestand zelf is opgenomen (Schema 5-3).

Schema 5-3; Header sectie van een IFC bestand met verwijzing naar het Exress schema

12 De eigenschappen in het getoonde voorbeeld zijn onderscheiden met een kommateken (,)

HEADER; FILE_DESCRIPTION (('ViewDefinition [CoordinationView, QuantityTakeOffAddOnView]'), '2;1'); FILE_NAME ('example.ifc', '2008-08-01T21:53:56', ('Architect'), ('Building Designer Office'), 'IFC Engine DLL version 1.02 beta', 'IFC Engine DLL version 1.02 beta', 'The authorising person'); FILE_SCHEMA (('IFC2X3')); ENDSEC;

Verwijzing naar het IFC2x3 schema

#45 = IFCWALLSTANDARDCASE('06a9Q5WebBbh3PNtAV_2Rs', #2, 'TestWall 001', 'Description of Wall', $, #46, #51, $); #97 = IFCOPENINGELEMENT('2LcE70iQb51PEZynawyvuT', #2, 'Opening Element xyz', 'Description of Opening', $, #98, #103, $); #109 = IFCRELVOIDSELEMENT('3lR5koIT51Kwudkm5eIoTu', #2, $, $, #45, #97); #124 = IFCWINDOW('0LV8Pid0X3IA3jJLVDPidY', #2, 'Window xyz', 'Description of Window', $, #125, #130, $, 1.400, 7.500E-1); #131 = IFCRELFILLSELEMENT('1CDlLMVMv1qw1giUXpQgxI', #2, $, $, #97, #124);

Definitie van de wand

Definitie van het raam

Relatie tussen wand en opening

Definitie van de opening

Relatie tussen opening en raam

Calculeren met BIM

44

5.2 Eigenschappen Elke entiteit heeft eigenschappen. Welke eigenschappen een entiteit mogelijk

kan hebben hangt af van; 1. Welke eigenschappen er volgens de IFC architectuur aan de entiteit zijn

toegewezen, 2. Van welke – meer abstracte – entiteiten de entiteit eigenschappen ‘erft’ en 3. Welke mogelijke relaties met andere entiteiten gedefinieerd kunnen

worden. Figuur 5-1 toont een voorbeeld van de instanties IfcWall en IfcSpace waarin elk

van deze vorm van toewijzing van eigenschappen is toegepast. Alleen aan de IfcSpace zijn volgens de IFC architectuur eigenschappen aan de entiteit toegewezen. Dit betekent dat deze eigenschappen specifiek van nut zijn voor deze entiteit en eventuele sub-entiteiten.

De IfcWall ‘erft’ alleen maar eigenschappen van zijn supertypen. Zowel de IfcWall als IfcSpace zijn terug te herleiden naar de entiteit IfcRoot en hebben dus ook de eigenschappen die aan de IfcRoot zijn toegewezen.


45

Figuur 5-1; Hiërarchische structuur van het IFC model (Khemlani, 2004)

5.2.1 Directe eigenschappen Onder directe eigenschappen worden in deze rapportage de eigenschappen

verstaan die volgens de IFC architectuur aan de entiteit toegewezen zijn of die de entiteit erft van zijn supertypen. Schema 5-4 laat zien welke directe eigenschappen de instantie IfcWallStandardCase heeft en van welke entiteiten de eigenschappen worden geërfd. Een en ander is ook af te leiden uit Figuur 5-1, waarin de directe eigenschappen zich voor elke entiteit boven de streep (Entity attributes above the line) bevinden. De directe eigenschappen zijn dus altijd opgenomen in het IFC bestand. Of ze verplicht van bruikbare informatie moeten worden voorzien hangt af van de definitie in de IFC architectuur – het Express schema.

Calculeren met BIM

46

Schema 5-4; Directe eigenschappen van de instantie IfcWallStandardCase

5.2.2 Gerelateerde eigenschappen Gerelateerde eigenschappen van een entiteit ontstaan door het leggen van een

relatie tussen twee objecten. Dergelijke eigenschappen zijn dus – in tegenstelling tot de directe eigenschappen – optioneel aan de entiteit toegewezen. In Figuur 5-1 zijn de mogelijke gerelateerde eigenschappen van elke entiteit onder de streep (Relationship attributes under the line) weergegeven. Een voorbeeld voor de gerelateerde eigenschap ‘HasOpenings’ van de entiteit IfcElement is weergegeven in Schema 5-5.

Schema 5-5; Voorbeeld van de gerelateerde eigenschap ‘HasOpenings’ van IfcWallStandardCase

5.2.3 Property sets Om project-, bedrijfs- of landspecifieke eigenschappen in het model op te kunnen

nemen, waarvoor nog geen oplossing in IFC voorhanden zijn, kunnen Property Sets aan het model worden toegevoegd. Een voorbeeld hiervan is weergegeven in Schema 5-6, waarin Revit een Property Set heeft toegevoegd waarin gegevens over

#45 = IFCWALLSTANDARDCASE('06a9Q5WebBbh3PNtAV_2Rs', #2, 'TestWall 001', 'Description of Wall', $, #46, #51, $); #97 = IFCOPENINGELEMENT('2LcE70iQb51PEZynawyvuT', #2, 'Opening Element xyz', 'Description of Opening', $, #98, #103, $); #109 = IFCRELVOIDSELEMENT('3lR5koIT51Kwudkm5eIoTu', #2, $, $, #45, #97);

Definitie van de wand Relatie tussen wand en opening

Definitie van de opening

#45 = IFCWALLSTANDARDCASE('06a9Q5WebBbh3PNtAV_2Rs', #2, 'TestWall 001', 'Description of Wall', $, #46, #51, $);

Description (IfcRoot)

OwnerHistory (IfcRoot) GlobalId (IfcRoot)

Name (IfcRoot)

ObjectType (IfcObject)

ObjectPlacement (IfcProduct)

Representation (IfcProduct)

Tag (IfcElement)


47

hoeveelheden zijn opgeslagen. De Revit-eigen Property Sets worden niet ondersteund door andere IFC ondersteunende systemen.

Schema 5-6; Voorbeeld van een door Revit toegevoegde Property Set en haar eigenschappen

Een bijzondere vorm van een Property Set is de Common Property Set. Dergelijke sets met eigenschappen worden algemeen geaccepteerd en zullen door meerdere IFC ondersteunende systemen worden herkend.

Schema 5-7; Voorbeeld van een common Property Set voor IfcWallStandardCase

#45 = IFCWALLSTANDARDCASE('06a9Q5WebBbh3PNtAV_2Rs', #2, 'TestWall 001', 'Description of Wall', $, #46, #51, $); #52 = IFCPROPERTYSET('18RtPv6efDwuUOMduCZ7rH', #2, 'Pset_WallCommon', $, (#55, #59, #60, #61, #62)); #55 = IFCPROPERTYSINGLEVALUE('FireRating', 'FireRating', IFCTEXT(''), $); #59 = IFCPROPERTYSINGLEVALUE('IsExternal', 'IsExternal', IFCBOOLEAN(.T.), $); #60 = IFCPROPERTYSINGLEVALUE('ExtendToStructure', 'ExtendToStructure', IFCBOOLEAN(.F.), $); #61 = IFCPROPERTYSINGLEVALUE('LoadBearing', 'LoadBearing', IFCBOOLEAN(.F.), $); #62 = IFCPROPERTYSINGLEVALUE('Compartmentation', 'Compartmentation', IFCBOOLEAN(.F.), $); #63 = IFCRELDEFINESBYPROPERTIES('3IxFuNHRvBDfMT6_FiWPEz', #2, $, $, (#45), #52);

Definitie van de waarden van de eigenschappen die horen tot de Property Set

Definitie van de relatie tussen de Property Set en IfcWallStandardCase

Definitie van de Common Property Set

#62=IFCWALLSTANDARDCASE('11e6GfhXrCTOGErWTgLOzQ',#33,'Basic Wall:Generic - 200mm:105513',$,'Basic Wall:Generic - 200mm:398',#46,#61,'105513'); #94=IFCPROPERTYSET('3tGpVJ0XP1DBIM9XRPLUye',#33,'PSet_Revit_Dimensions',$,(#79,#80,#81)); #79=IFCPROPERTYSINGLEVALUE('Length',$,IFCLENGTHMEASURE(7200.00000000),$); #80=IFCPROPERTYSINGLEVALUE('Area',$,IFCAREAMEASURE(22200000.00000011),$); #81=IFCPROPERTYSINGLEVALUE('Volume',$,IFCVOLUMEMEASURE(4440000000.00),$); #95=IFCRELDEFINESBYPROPERTIES('1No5aE0zP2XeLSTDtxAI$d',#33,$,$,(#62),#94);

Definitie van de Property Set

Definitie van de waarden van de eigenschappen die horen tot de Property Set

Definitie van de relatie tussen de Property Set en IfcWallStandardCase

Calculeren met BIM

48

Interessant is, dat in deze Property Sets (Schema 5-7) eigenschappen voorkomen, zoals IsExternal (wel of geen buitenwand) en LoadBearing (wel of niet dragend), waarop in de elementenmethode onderscheid wordt gemaakt. Een voorbeeld van dit onderscheid is grafisch weergegeven in Schema 5-8.

Schema 5-8; Onderscheidende eigenschappen in de elementenmethode en de Common Property Set

5.3 Ruimtelijke structuur Een van de gerelateerde eigenschappen van objecten, is de locatie in het project

waar zij zich bevinden. De ruimtelijke opzet van een IFC model, zoals weergegeven in Schema 5-9, is hierbij een essentieel onderdeel van het IFC model en is hiërarchisch opgebouwd. Het top niveau van deze structuur is het project. Een IFC model bevat slechts één entiteit (IfcProject) om dit niveau aan te duiden. Relaties (van het entiteittype IfcRelAggregates) vormen vervolgens de onderverdeling naar het terrein (IfcSite), de gebouwen (IfcBuilding), bouwdelen(IfcBuilding) en bouwlagen (IfcStorey).

Wanden in de elementenmethode

21. Buitenwanden 22. Binnenwanden

IfcWall/ IfcWallStandardCase

Common PropertySet: IsExternal = True

Common PropertySet: IsExternal = False

21.1Niet constructief 21.2 Constructief

Common PropertySet: LoadBearing = False

Common PropertySet: LoadBearing = True


49

Schema 5-9; decompositie van de ruimtelijke projectstructuur (Bron: Liebich, 2004)

Het eerst volgende niveau dat de ruimtelijke structuur kan onderverdelen is het niveau van de ruimtelijke delen, ofwel de instantie IfcSpace, welke in de hiërarchie op gelijk niveau zou staan met bijvoorbeeld de IfcBuildingElements en zodoende niet is opgenomen in Schema 5-9.

Projectinformatie

51

Hoofdstuk 6

Projectinformatie

,,Je moet de vraag of je een begroting uit een bouwkundige tekening af kan leiden eens omdraaien… Je zult zien dat, met uitzondering van coördinaten, je dan veel ongebruikte gegevens overhoudt.’’

Dr. Ir. T. de Jonge, oktober 2008

De opmerking die Dr. Ir. Tim de Jonge13 hier maakt en het verschil tussen een bouwkundige tekening en een Bouw Informatie Model, resulteert in de vraag welke informatie er wel-, niet of gedeeltelijk in een Bouw Informatie Model zit en welke informatie nodig is om een goede inschatting van bouwkosten te maken.

In dit hoofdstuk worden daarom de benodigde gegevens voor de inschatting

vergeleken met de beschikbare gegevens in een BIM op basis van enkele casus welke zijn opgenomen in Bijlage 4. De casus bestaat uit een aantal IFC modellen van variërend detailniveau, afkomstig van diverse bronnen en gemodelleerd in verschillende applicaties. Door het gebruik van de casus kan onderscheid worden gemaakt in de informatie die in IFC opgenomen kan worden en de informatie die daadwerkelijk in praktijkmodellen aanwezig is. Naar aanleiding van de resultaten worden mogelijke oplossingen aangedragen om een koppeling tussen een IFC model en een kosteninschatting te maken.

13 Bron: interview, 16 oktober 2008 te Roosendaal

Calculeren met BIM

52

6.1 Informatiestructuur Belangrijk bij de informatiestructuur van de kosteninschatting is dat de

bouwkostendeskundige – danwel op basis van een referentieproject, danwel op basis van eigen inzicht – zelf de structuur bepaalt (Schema 6-1).

Schema 6-1; informatiestructuur van de kostenschatting

Gedurende het proces zal de gekozen structuur worden aangescherpt of met detailniveaus worden uitgebreid. Er zijn momenteel al diverse programma’s op de markt die een dergelijke flexibele indeling mogelijk maken14. Dergelijke programma’s maken gebruik van de indeling in niveaus, waarbij op steeds gedetailleerder niveau kosten en hoeveelheden kunnen worden opgegeven. Deze worden door het programma naar de bovenliggende niveaus doorgerekend.

In dit hoofdstuk wordt gekeken naar de aansluiting met de structuur van het IFC model zoals dat is omschreven in Hoofdstuk 5. Schema 6-2 laat een vereenvoudigde weergave zien van de in een IFC model aanwezige informatie. Het kostenaspect in die informatie zal moeten worden aangevuld door de te maken kostenschatting. Deze zal dus waarschijnlijk nog niet aanwezig zijn en is derhalve gestippeld weergegeven.

14 Voorbeelden daarvan zijn Kubus Calc van Kubus Informatiesystemen en Ibis Calc van Ibis

Software

BouwkostendeskundigeStructuur

Niveau

Kosten- schatting

Regel

Hoeveelheden

Kosten

Wordt bepaald door

Is opgebouwd in

Bestaat uit

Bestaat uit

1

1…*

1

1…*

1

1 1 1…*

Bevat gegevens over

1

1

1

Projectinformatie

53

Schema 6-2; informatiestructuur van het IFC model (vereenvoudigd)

Wanneer de structuur van de inschatting wordt bepaald door de bouwkostendeskundige (Schema 6-1) dan zal de bouwkostendeskundige dus ook zelf moeten bepalen waar en welke informatie uit het groeiende IFC model wordt opgenomen in de kostenschatting. De eigenschappen van entiteiten maken het mogelijk om dit op basis van voorwaarden dit onderscheid te maken.

Schema 6-3; koppeling van informatie uit het IFC model aan de kostenschatting

Overeenkomst en volledigheid van gegevens?

Bouwkostenmanager

Structuur

Niveau

Kosten- schatting

Regel

Hoeveelheden

Kosten

Wordt bepaald door

Is opgebouwd in

Voldoet aan

1

0…*

1…*

1

1

1

1

Voorwaarde

Entiteiten

Directe- en Gerelateerde

eigenschappen Property Sets

1…*

Bevat

1…*

1

1…*

IFC model Bestaat uit

1…* 1 Bevat gegevens over

Worden toegevoegd aan

1…*

0…* 0…*

0…1 0…1

1

1

BuildingElement Space

Entiteit

IFC model

Hoeveelheden

Kosten

Bestaat uit

Is onderdeel van

1

1..*

Bevat (oa) gegevens over

Etcetera

Etcetera1…*

0…*

0…*

Wordt gevuld met

Calculeren met BIM

54

Schema 6-3 dekt de informatie in een kostenschatting af welke uit het IFC model afgeleid kan worden. De nadruk in dit hoofdstuk ligt in het gearceerde gebied in dit schema en behandeld de overeenkomst en volledigheid van de gegevens.

6.2 Detailniveau Gedurende het proces zijn het IFC model en de kostenschatting groeiende. In de

fase voorafgaand aan de uitvoeringsfase heeft de kosteninschatting volgens Hoofdstuk 2 het niveau van een calculatie bereikt en zijn gegevens tot op het meest gedetailleerde niveau (het MAMO niveau) bekend. Bouwkundige tekeningen uit de stelling van de Jonge – genoemd als inleiding van dit hoofdstuk – worden in traditionele werkwijze tot op detailniveau van technische oplossingen uitgewerkt. Gedetailleerdere gegevens komen terug in het bestek15 en in de detailtekeningen (Jonge, 2005). Uit de casus blijken de technische oplossingen niet nader gespecificeerd te worden. Dit kan te maken hebben met de oorsprong van de modelleerpakketten voor ontwerpende partijen, voor wie het doel van modelleren is om zo efficiënt mogelijk een bouwtechnisch goede tekening te produceren en niet zo zeer om een goed informatief model op te zetten. Bij het inschatten van kosten met behulp van een BIM zal specificatie van de technische oplossingen dus onderdeel zijn van de inschatting. Ook elementen die vanwege hun geringe waarde voor andere disciplines vaak ongemodelleerd blijven, zoals de afwerkingen, zullen ingeschat moeten worden.

Op dit vlak is er eigenlijk geen verschil met de traditionele inschatting van kosten, behalve dat met behulp van een BIM de inschatting vereenvoudigd – of in elk geval versneld – kan worden. Aanwezigheid van ruimten in de vorm van instanties van het type IfcSpace zouden bijvoorbeeld de lengte aan ongemodelleerde plinten kunnen opleveren op basis van de eigenschap NetPerimeter16. Deze hoeven dan niet meer handmatig te worden bepaald.

Waar wel verschil met de huidige werkmethodiek optreedt is in de aanwezigheid van detailniveaus. Modeleerpakketten maken onderscheid in hetgeen visueel op het scherm zichtbaar is, waardoor de gebruiker verschillende detailniveaus waarneemt. Modeltechnisch is dit onderscheid er echter niet. Een gemodelleerde wand kan door de modelleur willekeurig uit een objectenbibliotheek zijn gehaald om grafisch te laten zien waar de wand moet komen, zonder dat hij nagedacht

15 Een bestek is een tekstuele omschrijving van hetgeen gerealiseerd moet worden en dient

tezamen met de bestektekeningen als contractstuk tussen opdrachtgever en aannemer 16 Deze eigenschap is onderdeel van de Common Property Set voor de instantie IfcSpace

Projectinformatie

55

heeft over het materiaal waar de wand uit is opgebouwd. Voor het model is de wand een bibliotheek object dat tot op het fijnst mogelijke niveau is uitgewerkt.

De elementenmethode (Paragraaf 2.6) maakt onderscheid in detailniveaus met behulp van een hiërarchische codestructuur. Een dergelijke codestructuur kan volgens Espedokken (2006) vertaald worden naar IFC door de structuur te classificeren (Schema 6-4). Het leggen van relaties tussen deze classificering en de instanties uit het model zou echter onlogisch zijn, omdat de instanties steeds gedetailleerder zouden moeten worden.

\

Schema 6-4; hiërarchische classificatie structuur in IFC (gebaseerd op Espedokken, 2006)

Het enige onderscheid in detailniveaus dat gemaakt kan worden is door het verfijnen van de eigenschappen van instanties. Dit sluit tevens aan bij de voorwaarden structuur van Schema 6-3. Op grovere detailniveaus worden daarbij minder – of minder gedetailleerde – voorwaarden opgesteld dan op de meer gedetailleerde niveaus.

6.3 Kengetallen Net als het onderscheid in detailniveaus, zijn ook kengetallen onderdeel van het

gehele proces en spelen ook zij een belangrijke rol bij de kosteninschatting. In het traditionele proces worden de eerste kengetallen – in de vorm van vormfactoren – bepaald op basis van het programma van eisen. Eastman et al. (2008) stellen dat het belangrijk is om resultaten uit de vroege fasen in een BIM te integreren om zo hoeveelheden te kunnen bepalen. Het Onuma Planning System (OPS) is een systeem dat invulling geeft aan deze stelling door ruimtelijke eisen – volgend uit een programma van eisen – om te zetten in een IFC model. De ruimtelijke eisen worden daarbij vertaald naar instanties van het type IfcSpace en dienen

B

2- 3- 4-

21 22 23

IfcClassificationItemRelationship

RelatingItem

RelatedItems

IfcClassificationItem

IfcClassificationItemRelationship

RelatingItem

RelatedItems

Calculeren met BIM

56

vervolgens als basis voor het ontwerpproces. Deze vertaling kan gezien worden als een verrijking van het model met vormfactoren, waarbij de totale oppervlakte van de toegevoegde instanties symbool staat het netto- of gebruiksoppervlak17.

Voor de bruto maten van het project zou volgens de ruimtelijke structuur (Paragraaf 5.3) analyse van de representatie van instanties als IfcBuilding of IfcBuildingStory het meest voor de hand liggen. Uit de casus blijkt echter dat er voor deze entiteiten over het algemeen geen representatie is opgenomen en dat de IfcSpace de eerste meetbare ruimtelijke instantie is die wel een aanwijsbaar onderdeel is van het model.

Ook voor de vormfactoren geldt dat deze op basis van classificatie specifiek kunnen worden benoemd. De classificatie kan daarbij gerelateerd worden aan de in Hoofdstuk 2 genoemde norm voor bepaling van oppervlakten en inhouden van gebouwen (NNI, 2007) zodat deze ook bij andere partijen op gelijke wijze zal worden geïnterpreteerd. Schema 6-5 laat de mogelijke toepassing van deze methode zien.

Schema 6-5; een vormfactor toekennen aan een of meerdere entiteiten van het type IfcSpace

Noch de classificatiemethode, noch een andere methode voor toewijzing van vormfactoren aan entiteiten is in de casus toegepast. Op basis van instanties van het type IfcSpace, welke wel regelmatig worden gebruikt, kan een uitspraak over oppervlakten worden gedaan.

17 Begrippen van NNI (2007) uit Paragraaf 2.5 voor de aanduiding van oppervlakten

Location ItemReference = BVO Name ReferencedSource

IfcClassification

Source = NNI Edition = 2007 EditionDate = may 2007 Name = NEN 2850

Entiteit(en)

IfcClassificationReference

IfcRelAssociatesClassification

GlobalId OwnerHistory Name Description RelatedObjects RelatingClassification

Projectinformatie

57

6.4 Hoeveelheden Bij ontwikkeling van het model zullen steeds meer hoeveelheden op basis van de

entiteiten zelf – en niet op basis van gerelateerde vormfactoren – worden bepaald. Analyse van de geometrie van een IFC model is dan de basis voor het bepalen van hoeveelheden voor de inschatting van kosten. Entiteiten van het type IfcBuildingElement – en dus ook al haar subtypen – hebben een eigenschap ‘representation’, welke een erfenis is van het entiteittype IfcProduct.

Voor elk subtype van IfcBuildingElement heeft Liebich (2004) in de Model Implementation Guide omschreven hoe de representatie van elementen geëxporteerd moet worden naar IFC. Een omschrijving van de wijze waarop een IfcWallStandardCase geometrisch dient te worden opgeslagen in IFC is als voorbeeld opgenomen in Bijlage 5.

Schema 6-6; Representatie van entiteiten in IFC

De mogelijkheden om geometrische gegevens te verwerken in een IFC model (Schema 6-6) zijn voor de verschillende objecten divers en analyse van de geometrie (het bepalen van hoeveelheden) daardoor complex. Volgens Ir. P. Bonsma18 van TNO maken programma’s die hoeveelheden bepalen uit een IFC model gebruik van de methode om de vlakken van gemodelleerde elementen te verdelen in driehoeken en op basis van de sommatie van de oppervlakten daarvan de totale oppervlakte van het element te bepalen. Voordeel van deze methode is

18 Bron: interview, 29 januari 2009 te Delft

IfcBuildingElement

GlobalId OwnerHistory Name Description ObjectType ObjectPlacement Representation Tag

1…* IfcProductRepresentation

Name Description Representations IfcRepresentation

Context of Items RepresentationIdentifier RepresntationType Items IfcRepresentationItem

1

1…*

1

1

1…*

Calculeren met BIM

58

dat er maar een enkele wijze van geometrie analyse nodig is om van elk type entiteit hoeveelheden te bepalen. Gevaar is dat een object – vanwege zijn drie dimensionale geometrie – bestaat uit meerdere vlakken en dat niet met zekerheid kan worden vastgesteld of het resultaat uit een dergelijke berekening het juiste vlak van het object betreft. Een vlak dat de dikte van een object aangeeft – zoals de dikte van een wand – zal ook als vlak in de berekening worden opgenomen.

Gangbare modelleerpakketten als Revit en ArchiCad bieden de gebruiker mogelijkheden om hoeveelhedenstaten van gemodelleerde objecten op te vragen. Het is mogelijk dat de pakketten tijdens het modelleren elke invloed op hoeveelheden van objecten wegschrijven naar een database als een object wordt gewijzigd. Het pakket laat dan bij een aanvraag van hoeveelheden slechts een waarde uit een tabel zien om de response snelheid te waarborgen. Meer waarschijnlijk is het dat gebruik wordt gemaakt van de historie van wijzigingen aan een object om de gewenste gegevens bij een aanvraag te berekenen (Schema 6-7).

Schema 6-7; Mogelijke wijze van berekening van hoeveelheden door modelleerpakketten

Dat zou ook verklaren waarom een import van een IFC model naar het modelleerpakket leidt tot geen of merkwaardige waarden voor opgevraagde hoeveelheden19. Het modelleerpakket is dan namelijk niet meer in staat de historie te herleiden omdat het IFC model slechts de laatste stand van zaken vertegenwoordigd. Tevens wordt deze gedachte ondersteund doordat waarden voor hoeveelheden van objecten in de database worden opgenomen die door Revit kan worden geëxporteerd20 en de kleine onnauwkeurigheid bij weergave van opgevraagde hoeveelheden.

19 Geconstateerd bij het genereren van hoeveelhedenstaten in het modelleerpakket Revit 20 In het modelleerpakket Revit kan een model worden geëxporteerd naar een database, waarbij

voor de verschillende objecten tabellen worden gecreëerd met een kolom voor de hoeveelheden.

Gebruiker vraagt hoeveelheden op

Pakket berekend hoeveelheid op basis van het originele object (zoals

in eerste instantie gemodelleerd

Pakket berekend van elke wijziging de invloed op de

originele hoeveelheid

Pakket toont het resultaat aan de

gebruiker

Projectinformatie

59

De laatste omschreven methode van de modelleerpakketten – al dan niet

overeenkomstig met de realiteit – kan omgekeerd gebruikt worden om achteraf de hoeveelheid op basis van de gegevens in het IFC model te berekenen. Daarbij zou voor alle relaties met het object bepaald moeten worden wat de invloed op de gewenste hoeveelheid is. Ook zal voor elke mogelijke wijze van exporteren volgens Liebich (2004) een methode voor hoeveelheidbepaling moeten worden omschreven.

Figuur 6-1; mogelijke wijze van bepalen van hoeveelheden uit een IFC model

Voor een instantie van het type IfcWallStandardCase geldt bijvoorbeeld dat de lengte van het object (een wand) kan worden afgeleid uit de Axis en de hoogte kan worden afgeleid uit de Body (Bijlage 5). Wanneer de Axis een IfcPolyLine is en de Body een IfcExtrudedAreaSolid, dan kan het oppervlak van de wand dus worden bepaald door de lengte van de IfcPolyLine te vermenigvuldigen met de hoogte van de IfcExtrudedAreaSolid (de diepte van uitrekking). Deze berekening is aanzienlijk eenvoudiger dan de berekening op basis van driehoekoppervlakten, maar moet wel voor elke mogelijke representatie worden gedefinieerd.

6.5 Probleemgebieden In Nederland zijn modelleer pakketten als Revit, ArchiCAD, Tekla en Allplan op

de markt welke ontworpen zijn om specifieke disciplines binnen het bouwproces te dienen. Zij beslaan allen een bepaald aspect van de totale projectwerkzaamheden (Figuur 6-2, links), maar richten zich niet op dat werkgebied waar meerdere disciplines samen komen (Figuur 6-2, rechts). Verder ligt de oorsprong van de modelleerpakketten voor de ontwerpende partijen in de tekenpakketten als AutoCAD die hun mogelijkheden hebben uitgebreid door modelleerfuncties toe te voegen. Voornaamste doel van deze pakketten blijft echter om een goede bouwkundige tekening te genereren en in eerste instantie niet om een zo compleet mogelijk model op te bouwen.

Bepaal de wijze van representatie

Bepaald de gevraagde

hoeveelheid

Voor elk IfcBuildingElement

Bepaal de wijze van representatie

Voor elke relatie met het object

Bepaald de invloed op de hoeveelheid

Calculeren met BIM

60

Figuur 6-2; werkgebieden modelleerpakketten (l) en het BIM werkgebied (r)

Volgens benchmarks van Robbemondt (2008) zijn deze pakketten wel in staat om de gemodelleerde gegevens in een IFC structuur om te zetten (99% van de informatie), maar zijn deze niet voldoende in staat om IFC gegevens om te zetten naar de eigen structuur (gemiddeld 12% gegevensverlies). Dit kan een reden zijn dat uit de casus blijkt, dat de mogelijkheden van IFC nog niet optimaal worden benut, waardoor er momenteel nog veel ongemodelleerde projectinformatie is.

Opgemerkt moet worden dat de besproken onderwerpen in dit hoofdstuk van het model verwachten dat het zich aanpast aan het traditionele inschattingsproces. Dit is gedaan om binnen de kaders van het onderzoek te blijven waarin gekeken wordt naar de mogelijkheden om BIM toepasbaar te maken in de huidige werkmethodiek. Het is niet ondenkbaar dat op langere termijn het inschattingsproces zich aan zal passen aan de mogelijkheden van BIM. Huidige kengetallen die kosten bepalen op basis van het bruto vloeroppervlak zullen bijvoorbeeld vervangen worden voor kengetallen die betrekking hebben op meer voor de hand liggende informatie uit het BIM. Door de vele eigenschappen zijn diverse nieuwe kengetallen denkbaar die verder gaan dan het analyseren van de geometrie alleen. Uit analyse van meerdere projecten kan bijvoorbeeld blijken dat het aantal relaties tussen twee instanties voor elk project ongeveer gelijke kosten met zich meebrengt. Op basis hiervan zou dan een nieuw kengetal geïntroduceerd kunnen worden. Misschien is het ooit wel mogelijk om kosten te relateren aan de grootte van het IFC bestand21.

21 Dit is een onwaarschijnlijke aanname, maar geeft wel aan welke mogelijke verschuivingen er

in de werkmethodiek op kunnen treden.

De IFC Cost Estimator (ICE)

61

Hoofdstuk 7


,,Dependable parametric costing systems are not readily available at the time. Vendors have started to focus on this area and given time, systems that directly link to your bim model will be available.’’

Jernigan, 2007

Deze stelling van Jernigan (2007) staat haaks op de stelling die de inleiding van deze rapportage vormt22. Waarschijnlijk bedoelen Eastman et al. (2008) in die stelling met ‘the estimating proces’ de analyse die wordt uitgevoerd door de kostendeskundige om te komen tot een onderbouwde uitspraak over bouwkosten, waarbij inschatting van kosten niet alleen afhankelijk is van de in het model aanwezige informatie, maar ook van gezond verstand van de deskundige en zijn ervaring. Kennis en ervaring van een kostendeskundige kunnen immers niet volledig worden vertaald in een ‘full estimate from a building model’.

Om een IFC model als informatiedrager toepasbaar te maken in het

inschattingsproces, zal op basis van het verrichte onderzoek in dit hoofdstuk een concept worden omschreven voor een ondersteunend middel bij het inschatten van bouwkosten door de bouwkostendeskundige; de IFC Cost Estimator. Dit concept zal in Hoofdstuk 8 nader zal worden toegelicht met behulp van een prototype.

22 ‘No tool can deliver a full estimate automatically from a building model. If a vendor advertises

this, they don’t understand the estimating process’

Calculeren met BIM

62

7.1 Het (nieuwe) inschattingsproces ‘The estimating proces’, vrij vertaald; ‘het inschattingsproces’ vertegenwoordigd

de opdracht van de bouwkostendeskundige gedurende de fasen van het bouwproces. Uit Hoofdstuk 2 blijkt de inhoud van dit proces, welke bestaat uit (a) het bepalen van de begrotingsstructuur die past bij de aard en complexiteit van het project, (b) het bepalen van kosten aan de hand van ingeschatte hoeveelheden en eenheidsprijzen op alle niveaus gedurende de procesfasen en (c) het controleren en sturen van het proces op basis van de verkregen gegevens. Het bepalen van hoeveelheden en het afprijzen van eenheden op de verschillende detailniveaus zijn dus slechts ondersteunende werkzaamheden van dit proces. Dat deze werkzaamheden voor verandering vatbaar zijn is de afgelopen jaren al aangetoond met de komst van digitale meetmethoden23 en referentiedatabases. Deze winnen langzaam het vertrouwen van de kostendeskundigen. Het is te verwachten dat deze trend zich met de komst van BIM zal doorzetten, aangezien bekend is dat er op dit gebied veel tijdwinst en toename van nauwkeurigheid te behalen is24. De nadruk van de werkzaamheden zal dus meer op de daadwerkelijke kosten-deskundigheid, de controle en de sturing op het proces komen te liggen. Gezien de huidige kennis en ervaring van de bouwkostendeskundige en de enorme hoeveelheid middelen om op zijn vakgebied het ontwerpproces te controleren en te sturen, is het onwaarschijnlijk dat het inschattingsproces zich als zodanig op korte termijn aan zal passen aan de mogelijkheden van BIM. Het ontwerp voor een ondersteunend middel is dan ook niet bedoeld om een nieuwe werkmethodiek voor de bouwkostendeskundige te ontwikkelen, maar juist om BIM in de huidige manier van werken toepasbaar te maken.

Een verschuiving van de werkzaamheden zal dus plaatsvinden van de

ondersteunende naar de deskundige werkzaamheden. Het aan een model overlaten van de ondersteunende werkzaamheden – wat gedurende het proces steeds een stap verder zal gaan – betekent dat de grip op de gegenereerde getallen door de bouwkostendeskundige afneemt. Deze afname moet worden afgedekt met een toenemende controlefunctie op de automatisch verkregen gegevens. Dit principe is weergegeven in Schema 7-1.

23 De digivisor waarmee afgedrukte tekeningen digitaal kunnen worden bemeten en GeoId

waarmee tevens digitale tekeningen meetbaar zijn, zijn hier voorbeelden van. 24 Zie hiervoor ook het onderzoek van Ibis4Bim, Paragraaf 1.1


63

Schema 7-1; Toenemende controlefunctie gedurende het proces

Het concept is gebaseerd op dit procesverloop met de toenemende controlefunctie.

7.2 Beschikbare middelen Gedurende dit onderzoek, maar ook al in de periode daarvoor, zijn er, zoals

Jernigan (2007) voorspelde, diverse applicaties op de markt gebracht die op een of andere wijze op basis van een BIM een kostenoverzicht kunnen genereren25. Dit kan ermee te maken hebben dat de doelgroep voor de applicaties waar Jernigan (2007) op doelt anders is dan die van de besproken kostendeskundige. Hoofdstuk 6 concludeerde namelijk dat de modelleerpakketten waarmee de informatie modellen worden vormgegeven, de ontwerpende partijen als doelgroep hebben. Voor hen is een indicatie van de bouwkosten voldoende om te bepalen of het ontwerp nog aan de gestelde randvoorwaarden ten aanzien van het budget voldoet. Voor hen ligt het voor de hand om het BIM als basis voor de inschatting te gebruiken. Het model bepaalt dan in feite hoe de begroting is opgebouwd (Schema 7-2, links).

25 Waaronder Ibis4BIM en Winket Referentieprojecten Methode

Bouwkostendeskundige

Proces verloop

Kosten- schatting

Hoeveelheden

Kosten

BIM

Hoeveelheden

Kosten

inschatten

controleren Kengetallen/ referenties

Calculeren met BIM

64

Schema 7-2; Doel en middel bij het inschatten van kosten uitgaande van het BIM (l) en uitgaande

van de inschatting (r)

Uit het onderzoek naar de specifieke rol van de bouwkostendeskundige blijkt echter, dat vaststelling van de begrotingsstructuur juist onderdeel is van zijn inschattingsproces, omdat het een projectafhankelijke opgave is. Dit geldt eveneens voor het inschatten van de (nog) ongemodelleerde informatie en het onderbouwen daarvan. Er zijn voor de inschatting dus meerdere middelen nodig dan uitsluitend het Bouw Informatie- of IFC model (Schema 7-2, rechts).

Het concept van de IFC Cost Estimator richt zich daarom op het traditionele

inschattingsproces van de bouwkostendeskundige. Dit houdt in dat de basis voor de inschatting niet het model, maar de gekozen kwaliteit – referentie en/ of kengetallen – van de inschatting is.

7.3 Het concept Op basis van een kleine casus zal het concept van ICE worden toegelicht. Het

gaat er in deze casus nog niet om hoe het concept functioneert. Het dient alleen ter illustratie wat het kan doen.

Middel: BIM

Doel: Kostenschatting

Middel: BIM

Doel: Kostenschatting

(Hulp)middel: Kengetallen/ referenties

Middel: Kennis


65

Om een ‘kip-en-het-ei’ verhaal te vermijden, wordt er in de nu volgende

omschrijving van dit concept van uitgegaan, dat de bouwkostendeskundige in het bezit is van een projectanalyse welke eerder in dit concept is opgesteld en die – volgens zijn deskundige ervaring – als referentie bruikbaar is voor het nieuw in te schatten project. Op het moment dat er nog geen informatie over het project bekend is (het absolute begin), is er geen reden om aan te nemen dat het nieuwe project anders is dan het referentieproject. Het geheel aan kengetallen is dan onderdeel van de inschatting van het nieuwe project. BIM is op dat moment nog niet in beeld en er valt nog niets te controleren (Figuur 7-1).

Figuur 7-1; Model zonder informatie (fase 0)

Op het moment dat de eerste versie van een BIM beschikbaar is, zal deze een blijvende koppeling met de inschatting – en daarmee met de gekozen kwaliteit – krijgen. Als uit dit BIM de eerste vormfactoren afleidbaar zijn – bijvoorbeeld op basis van een massastudie die is opgebouwd uit instanties van het type IfcSpace – dan zullen de eerste aannamen uit de inschatting al door het BIM worden vervangen (Figuur 7-2).

Het concept van ICE is er op gebaseerd dat in een vroege fase aannamen worden gedaan voor de kwaliteit van het project – in de vorm van kengetallen, al dan niet onderbouwd met een referentie – op basis waarvan de eerste inschatting van kosten zal worden gemaakt. Al naar gelang een aan de inschatting gekoppeld IFC model gevoed wordt met informatie die nauwkeuriger is dan de aannamen, zal deze informatie de aannamen vervangen, waarbij de oorspronkelijk gekozen kwaliteit – referentie of kengetal – zijn ramingsfunctie zal inruilen voor een toetsingsfunctie.

BIM Kostenschatting

Geen bruikbare gegevens, het absolute

beginpunt

Kengetallen hebben een ramingsfunctie over alle detailniveaus

Calculeren met BIM

66

Figuur 7-2; Informatie op gebouwniveau (fase 1)26

Op gebouwniveau is de referentie nu een controlemiddel geworden, waaruit kan blijken dat het bruto vloeroppervlak vergeleken met de referentie bijvoorbeeld veel groter geworden is en zich dit in de kostenraming heeft doorvertaald naar de onderliggende niveaus. Door deze controle kunnen tijdig maatregelen worden genomen.

De massastudies worden voorzien van bouwtechnische elementen. De modelleur

(architect of derden) heeft voor het gemak willekeurige elementen uit een bibliotheek van zijn modelleersoftware gebruikt, maar hier verder nog geen eigenschappen aan toegekend. Door het in deze fase nog ontbreken van die specifieke eigenschappen, zal informatieoverdracht nog niet op het laagste niveau plaatsvinden, maar de onderbouwde prijzen worden wel gebaseerd op de willekeurige aannamen van de modelleur. De controlefunctie van de kengetallen op de hoge niveaus in de piramidestructuur is nu dus van groot belang, omdat de kostendeskundige aan de hand van de nieuwe resultaten actie moet ondernemen om de schatting weer dichter naar de realiteit te brengen (Figuur 7-3).

26 De gebruikte afbeeldingen om het detailniveau van het model aan te duiden zijn afkomstig uit

posters van COINS

BIM Kostenschatting

De eerste massastudies op gebouwniveau

Ramingsfunctie

Controlefunctie Informatie overdracht op grof niveau


67

Figuur 7-3; Informatie niveau van technische oplossingen (fase 2)

De deelnemende partijen voeden het BIM meer en meer. Door toekenning van steeds meer en gedetailleerdere eigenschappen aan het model kan de bouwkosten-deskundige op steeds gedetailleerder niveau de entiteiten van het model onderbrengen. Het belang van controle op de grovere niveaus neemt toe, zeker omdat de inhoud van de inschatting steeds meer bepaald wordt op basis van het model en geen handmatige handeling van de bouwkostendeskundige meer is (Figuur 7-4).

Figuur 7-4; Informatie niveau van technische oplossingen (fase 3)

Binnen dit omschreven concept moet een oplossing worden bedacht voor de koppeling tussen het IFC model en de gekozen kwaliteit.

7.4 Het ontwerp In het behandelde concept is de status van het model bepalend voor de keuze

waar de inschatting de informatie vandaan moet halen. Zit de gevraagde informatie in het model dan zal die informatie ook benut worden. Ontbreekt het, dan zal de referentie of de kengetallen het resultaat van de inschatting zijn. Het ontwerp van de koppeling tussen model en schatting – aangeduid als voorwaarden

Een volwassen model

BIM Kostenschatting

Ramingsfunctie

Controlefunctie

Informatie overdracht op fijn niveau

Een groeiend model

BIM Kostenschatting

Ramingsfunctie

Controlefunctie

Informatie overdracht op midden niveau

Calculeren met BIM

68

in Schema 7-3 – is er op gebaseerd dat de eigenschappen van entiteiten in het IFC model op steeds fijner niveau worden bepaald.

Schema 7-3; informatiestroom naar de raming/ begroting

Met het bepalen van de kwaliteit bepaald de bouwkostendeskundige het uitgangspunt voor kosten en hoeveelheden van de inschatting, alsmede de middelen die hij in latere fasen heeft om de gegevens uit het IFC model te controleren. De kwaliteit wordt op basis van een referentie van het project als totaal, danwel als referentie van delen van het project, bepaald. Op deze wijze sluit het ontwerp aan bij de methode van Jonge (2005) en biedt het tevens ruimte voor opname van de door Dukers (2004) voorgestelde vormfactoren en kwaliteitaspecten op gedetailleerder niveau.

Bouwkostenmanager

Structuur

Wordt bepaald door

1

1

Hoeveelheden en kosteninformatie

Voldoet aan

Raming/ begroting

Entiteit

eigenschappen inverse

eigenschappen

Kwaliteit

Projectmodel (BIM)

Voorwaarde

Kengetal

Niveau

Regel

Informatie is beschikbaar in projectmodel

Informatie is niet beschikbaar in projectmodel

Is opgebouwd in

Omschrijft

Bestaat uit

Bestaat uit

Bepaald

Is afhankelijk van

1

1

1…*

1

1…*

1

1

1 1

1 1

1…*

1…*

1…*

1

1

1

1

0…*

Genereert

Referentie

Heeft een zekere

Op basis van

0…1

1…*

0…* 0…1

1

1


69

7.4.1 Informatie uit het model Op basis van de eigenschappen zal de bouwkostendeskundige bepalen waar de

entiteiten in de schatting moeten worden opgenomen. Hij/ zij stelt daarvoor niveaugewijs selectiecriteria op voor de instanties uit het model.

Figuur 7-5; Toename van de selectiecriteria voor entiteiten

Figuur 7-5 toont een dergelijke selectie op 3 willekeurig gekozen niveaus. Op het eerste detailniveau wordt voor het hoofdstuk ‘Buitenwanden’ een selectie gemaakt van instanties van het type IfcWall met de eigenschap dat zij de functie van buitenwand vervullen. Deze eigenschap is onderdeel van de Common Property Set voor wanden (Paragraaf 5.2). Gedetailleerdere niveaus nemen de selectiecriteria (voorwaarden) van de bovenliggende niveaus over en worden aangevuld met aanvullende criteria. Bij het inlezen van het model, zal ICE op het meest gedetailleerde niveau controleren of er entiteiten in het IFC model zitten die aan de (meest strenge) criteria voldoen. Is dit niet het geval, dan zal een niveau hoger opnieuw naar de (minder strenge) criteria worden gekeken.

Om overlap van criteria op verschillende regels te voorkomen zal aangegeven moeten worden wat de prioriteit is van regels bij het inlezen van het IFC model.

Detailniveau 1

Detailniveau 2

Detailniveau 3

Calculeren met BIM

70

7.4.2 Informatie op basis van referentie Doel van het vooraf bepalen van de kwaliteit van hetgeen ingeschat moet worden

is tweeledig. Enerzijds is het de basis voor de onbekende – niet in het model aanwezige – gegevens, anderzijds is het een toetsingsmiddel voor de bekende – in het model aanwezige – gegevens. Naast het aanscherpen van de selectiecriteria gedurende het proces, zal ook de kwaliteit die wordt verwacht worden bijgesteld. Bij gebruik van een referentieproject volgens de methode van Jonge (2005) is de structuur van de inschatting in beginsel bepaald, maar kan de kwaliteit nog nader worden gedefinieerd op de meer gedetailleerde niveaus door gebruik van aanvullende kengetallen (Dukers, 2004).

Figuur 7-6; Resultaten op gebouwniveau

In Figuur 7-6 is (als voorbeeld) voor het netto vloeroppervlak een selectiecriterium opgegeven waartoe alle instanties van het type IfcSpace behoren. Bij het inlezen van het model blijken deze inderdaad aanwezig. De oorspronkelijke aanname – een factor van 0,8 maal het bruto vloeroppervlak – wordt overschreven door het resultaat uit het model. De factor 0,8 – een hoeveelheidskengetal – heeft nu een controlefunctie gekregen. Onderdeel van het inschattingsproces is nu, dat de bouwkostendeskundige gaat bepalen welke acties hij gaat uitvoeren naar aanleiding van dit resultaat.

Op detailniveaus van de inschatting kan ditzelfde principe worden gehanteerd.

Naast een vormfactor als basis voor de ingeschatte hoeveelheid zal hier een kwaliteit worden toegekend om het uitgangspunt voor de eenheidsprijs vast te leggen. Ook deze kwaliteit kan volgen uit een referentie op project-, of gedetailleerder niveau. Bij het bepalen van de kwaliteit op regelniveau zal de

Inschatting op basis van de referentie of gekozen kengetallen

Resultaat uit berekening van het model


71

waardering voor de eenheidsprijs dus gekoppeld worden aan de gestelde selectiecriteria voor die regel.

Figuur 7-7; Resultaten op elementniveau

Verschil in ingeschatte en werkelijke waarden in Figuur 7-7 kunnen ontstaan door het gebruik van een bibliotheek object voor de gevel, welke niet voldoet aan de verwachte kwaliteit. De bouwkostendeskundige zal ook in dit geval moeten bepalen welke acties hij gaat ondernemen. Als grote verschillen tussen geschatte en werkelijke waarden het resultaat zijn van een verkeerde aanname, kan hij zijn inschatting herzien en de waarden uit het IFC model accepteren. Wanneer hij vertrouwen heeft in zijn inschatting kan hij de modelleur vragen het model aan te passen.

7.5 Overzicht De werkvolgorde van het ondersteunende middel voor de bouwkostendeskundige

begint met het bepalen van de structuur van de kostenschatting en de kwaliteit van hetgeen bepaald moet worden. Uit deze handelingen volgt de informatie-behoefte van de bouwkostendeskundige uit de beschikbare bronnen. Een van die bronnen zal het IFC model zijn dat aan de inschatting gekoppeld word. Het inlezen van het model is dus slechts onderdeel van het inschattingsproces. (Schema 7-4).

Inschatting op basis van de referentie of gekozen kengetallen

Resultaat uit berekening van het model

Calculeren met BIM

72

Schema 7-4; Schematische werkwijze van ICE

Na het bepalen van de structuur kan de kwaliteit van de gedefinieerde niveaus

worden bepaald aan de hand van kengetallen en/ of een referentie. Wanneer instanties uit het IFC model zijn gekoppeld aan de structuur zullen deze bij het inlezen in de inschatting geplaatst worden. De originele kengetallen worden controlemiddelen, waarmee de bouwkostendeskundige het proces kan sturen als grote verschillen zijn opgetreden tussen verwachtte en werkelijke resultaten.

Handeling gebruiker

Resultaat applicatie

Informatiebron

Model vernieuwen

Structuur van de inschatting bepalen

Model uitlezen

Entiteiten uitlezen en in begroting plaatsen

Rapportage

Kwaliteit bepalen (referentie of kengetallen)

Referenties

Proces sturen n.a.v. resultaten Kennis

Aanleiding tot aanpassen structuur en/ of kwaliteit

Legenda:

Prototype van ICE

73

Hoofdstuk 8

Prototype van ICE

A prototype typically simulates only a few aspects of the features of the eventual program, and may be completely different from the eventual implementation.

Wikipedia

Om hetgeen ontworpen in Hoofdstuk 7 nader toe te lichten en aan te vullen, is

een prototype van ICE gemaakt waarin een aantal van de kernpunten uit het ontwerp zijn vertaald naar een werkende omgeving. Dit prototype is als digitaal bestand opgenomen in Bijlage 1. In dit hoofdstuk zullen de mogelijkheden van dit prototype worden toegelicht. Voor gebruik van het digitale bestand dient eerst de in Bijlage 2 opgenomen procedure gevolgd te worden.

Vanwege de vrije toegankelijkheid is ervoor gekozen het prototype te

ontwikkelen in Visual Basics for Applications (VBA). De begroting is daarbij opgezet in MS Office Excel. Het IFC model wordt bij het inlezen vertaald naar een MS Office Access database. In Bijlage 6 zijn de volledige actieschema’s weergegeven die worden doorlopen bij gebruik van het prototype.

8.1 Mogelijkheden prototype Uitgangspunt voor gebruik van het prototype is een structuur van een begroting

in MS Office Excel, welke symbool staat voor een door de gebruiker gekozen referentieproject (Figuur 8-1). Indien gewenst kan de referentie worden aangevuld met vormfactoren en eenheidsprijzen welke uitgangspunt zijn van de kwaliteit. De gebruiker kan binnen deze structuur de inschatting van kosten maken en daarbij

Calculeren met BIM

74

gebruik maken van een IFC model. Het prototype laat in een aantal stappen de mogelijke werking van een volledig functionerende applicatie zien;

1. Kwaliteit van de inschatting bepalen 2. Inlezen van een model op basis van het Express schema 3. Selecties maken van entiteiten op basis van voorwaarden 4. Het onderbouwen van de entiteiten met recepten 5. Het verreiken van het IFC model met de opgegeven kosteninformatie

Figuur 8-1; Uitgangspunt voor berekening

Omdat ondersteuning van bestaande werkmethoden een belangrijk onderdeel van het onderzoek is, zal de meerwaarde van het gebruik van een BIM worden aangetoond door middel van de mogelijkheid om wijzigingen in het model direct in de inschatting door te voeren.

8.2 Kwaliteit definiëren Een belangrijk aspect van het ontwerp is het definiëren van de kwaliteit van de

regels in de begroting en het toekennen van controlegetallen. Dit is een handeling die vooraf gaat aan het inlezen van het IFC model, zoals is toegelicht in Hoofdstuk 7. Zoals weergegeven in Figuur 8-1 zijn er in het prototype een aantal vormfactoren gedefinieerd. Deze vormfactoren kunnen middels de kolom ‘vormfactor’ worden toegekend aan begrotingsregels. Samen met de gekozen factor in de kolom ‘factor’, vormen zij het uitgangspunt voor de hoeveelheden. Het

Uitgangspunt voor kwaliteit

Vormfactoren

Uitgangspunt voor hoeveelheden

Prototype van ICE

75

aanpassen van de uitgangspunten voor de prijs per eenheid – het kostenkengetal – is mogelijk door de prijzen in de betreffende kolom te overschrijven. Een controle blijft bestaan door de uitklapbare controlekolommen, welke de originele invoer van de eenheidsprijzen laat zien (Figuur 8-2).

Figuur 8-2; Controlekolommen

Aangezien de hoeveelheden in beginsel gelijk zijn aan het uitgangspunt voor de berekening, zal de kolom voor het controlegetal van de vormfactor nog geen waarden weergeven.

8.3 Inlezen IFC model Wanneer de kwaliteit voor het te ramen project bepaald is, kan een IFC model

aan de raming worden gekoppeld. Het prototype is in staat om elk IFC model27 in te lezen. Bij het inlezen wordt het model op de achtergrond vertaald naar een database, met daarin voor elk type entiteit een tabel met de aanwezige entiteiten en hun eigenschappen (Figuur 8-3). Wanneer entiteiten gerelateerd zijn aan Property Sets, dan worden ook combinatietabellen gemaakt, met daarin de entiteiten en eigenschappen uit die Property Sets (Figuur 8-4). Tevens worden relaties gelegd tussen de entiteiten en de eventueel aanwezige combinatietabellen (Figuur 8-5).

27 Getest op diverse modellen, waaronder de modellen uit de case-lijst (Bijlage 4)

Controlegetallen voor eenheidsprijzen

Controlegetallen voor vormfactoren

Calculeren met BIM

76

Figuur 8-3; Inhoud en structuur van een entiteittabel (IfcWallStandardCase)

Figuur 8-4; Inhoud en structuur van een combinatietabel (IfcWallStandardCase met

Pset_WallCommon)

Figuur 8-5; Relaties tussen entiteiten combinatietabellen

Het totaal van deze acties is vertaald naar de actieschema’s (Schema B 4 t/m Schema B 6) in Bijlage 6. Uit de wijze van inlezen blijkt dat het prototype uitsluitend in staat is om eigenschappen aan entiteiten te relateren als deze onderdeel zijn van een Property Set. Voor dit type eigenschappen is gekozen omdat

Prototype van ICE

77

de standaard Property Sets (de common) informatie bevat die gebruikt wordt bij het samenstellen van de structuur van de inschatting (Paragraaf 5.2.3).

8.4 Entiteiten selectie Na het inlezen van het model kan voor elke begrotingsregel een selectie worden

gemaakt van entiteiten, welke blijvend aan de begrotingsregel gekoppeld zullen worden. ICE maakt daarvoor gebruik van de database met entiteiten. In de selectie kan alleen op die eigenschappen worden gefilterd die daadwerkelijk voorkomen voor de gekozen entiteit en die onderdeel zijn van een Property Set. Om de selectie te vereenvoudigen wordt de gebruiker eerst gevraagd om het type entiteit voor de geselecteerde regel op te geven (Figuur 8-6) en daarna pas om een selectie op basis van eigenschappen te maken voor het gekozen type. Doordat in de database bekend is van welke vorm (getal, tekst, optie ja/ nee, etc.) de eigenschap is, zal de gebruiker bij de selectie slechts die keuzemogelijkheden aangeboden krijgen waarop daadwerkelijk door het prototype geselecteerd kan worden (Figuur 8-7).

Na selectie zal een Front- End database worden opgebouwd, die de door de gebruiker gekozen filters opslaat in selectiequeries en zullen de entiteiten die aan de selectie voldoen worden opgenomen in de geselecteerde regel. De hoeveelheden worden bepaald op de wijze zoals is voorgesteld in Paragraaf 6.4, waarbij gekeken wordt naar de wijze waarop de entiteit is opgebouwd en aan de hand daarvan de hoeveelheid wordt bepaald.

Figuur 8-6; Selectie van het type entiteit

Calculeren met BIM

78

Figuur 8-7; Filtering van eigenschappen van de entiteit

Uit het actieschema in Bijlage 6 blijkt dat het prototype alleen hoeveelheden kan bepalen van instanties van het type IfcWallStandardCase. Ook voor het bepalen van de hoeveelheden van vormfactoren kan de filter worden gebruikt. Wanneer voor deze factoren een selectie van instanties IfcSpace wordt gemaakt zal bij het plaatsen van die instanties in de inschatting een willekeurig getal als hoeveelheid zichtbaar zijn. Deze geven een indruk van de wijze waarop de vormfactoren invloed hebben op de inschatting. De door het prototype bepaalde hoeveelheden worden in nieuwe kolommen weergegeven waardoor een vergelijk mogelijk is met de oorspronkelijke gegevens (Figuur 8-8). Ook zijn op deze manier de aangenomen en werkelijke kengetallen met elkaar te vergelijken. Met een functie ‘accepteren’ overschrijven de nieuwe gegevens de oorspronkelijke aanname.

Figuur 8-8; Controle op hoeveelheden

Berekende hoeveel-heden per instantie

Oorspronkelijke vormfactor

Berekende vormfactor

Oorspronkelijke hoeveelheid

Berekende totaalhoeveelheid

Prototype van ICE

79

8.5 Prijzen opbouwen Entiteiten van het type IfcWallStandardCase bestaan uit een lagenset van

materialen. In een afzonderlijk blad van de inschatting is voor een aantal mogelijke materialen een prijslijst opgenomen. Wanneer de materialen worden herkend, zullen de eenheidsprijzen bij het inlezen gebruikt worden om de totale eenheidsprijs van de wand te berekenen (Figuur 8-9).

Figuur 8-9; Prijzen opbouwen

8.6 Model vernieuwen Door splitsing van de informatie uit het model en de informatie betreffende de

filters in een Back-, respectievelijk Front- End database, kan het model na het opzetten van de filters worden gewijzigd, zonder de indeling en filters van de begroting te verliezen (Figuur 8-10). Telkens bij het activeren van de begroting wordt gecontroleerd of het IFC model is gewijzigd. Wanneer dit zo is, krijgt de gebruiker de mogelijkheid de begroting aan te passen aan het nieuwe model. Bij het vernieuwen van de begroting wordt de Back- End database opnieuw samengesteld aan de hand van de informatie uit het gewijzigde model. Vervolgens worden de selectiequeries uit de Front- End tabel voor elke begrotingsregel opnieuw doorlopen en worden de nieuwe resultaten opgenomen in de begroting. De nieuwe resultaten worden wederom naast de bestaande resultaten weergegeven, zodat de gebruiker direct ziet waar de verschillen zijn opgetreden. Ook deze wijzigingen zullen na acceptatie de oude gegevens overschrijven.

Achterliggende prijslijst

Herkende materiaal-combinaties

Prijsresultaat van alle materiaallagen

Resultaat op elementniveau

Calculeren met BIM

80

Figuur 8-10; Back- en Front-end databases

8.7 Verreiken model Wanneer de begroting gevuld is met de diverse entiteitfilters, heeft de gebruiker

de mogelijkheid om de gefilterde entiteiten te voorzien van eenheidsprijzen. In het prototype is het niet mogelijk de prijzen te onderbouwen. Dat wil zeggen dat de prijzen op niveau van de entiteiten worden opgegeven. De laatste functionaliteit van het prototype is de mogelijkheid om het IFC model te verrijken met de ingebrachte kosteninformatie. Omdat het prototype alleen in staat is eigenschappen als onderdeel van een Property Set te analyseren is er voor gekozen om ook de kosteninformatie eveneens als eigenschap van een Property Set aan het model toe te voegen. Bij het opnieuw inlezen van het model worden de kostengegevens uit de Property Set direct aan de inschatting toegevoegd.

Back-end database

Tabellen met instanties en hun eigenschappen uit Property Sets

Front-end database

Veranderende

back-end database

Vastgestelde filters/ selectiecriteria

Resultaten voor de inschatting

Conclusies en aanbevelingen

81

Hoofdstuk 9


,,Als niemand de nukken van een hybride auto accepteert, zal er nooit een auto komen die helemaal geen brandstof meer verbruikt.”

J. Witteman, Eindhoven, mei 2009

Gedurende het onderzoek is er een verandering opgetreden in de formulering van

de onderzoekstitel28 naar de volgende omschrijving;

‘Ondersteunen van het inschattingsproces met behulp van een IFC model’.

Reden van deze verandering is deels terug te vinden in wijziging van begripsdefinities, die het gevolg zijn van de resultaten van dit onderzoek. Hier zal nu eerst verder op worden ingegaan.

9.1 Begripdefinities Het begrip ‘calculeren’ heeft in de nieuwe titel plaatsgemaakt voor ‘het

inschattingsproces’. Uit het onderzoek blijkt namelijk dat het bepalen van bouwkosten gedurende het bouwproces een ontwikkeling is, gebaseerd op een toename van de beschikbare gegevens. In de beginfasen van het bouwproces, zijn in het verleden behaalde resultaten en aannamen op basis van het programma van eisen de belangrijkste bronnen voor kostenramingen. Naar mate het proces vordert zullen de aannamen plaatsmaken voor definitieve beslissingen door de deel-nemende partijen van het proces. Zo ontstaat in de ontwerpfase de mogelijkheid

28 ‘Calculeren met BIM’

Calculeren met BIM

82

om hoeveelheden op basis van het ontwerp te maken en te gebruiken voor een kostenbegroting. Nog later in het proces zijn definitieve keuzes op de meest gedetailleerde niveaus toepasbaar in een kostencalculatie. De nadruk blijft voor de kostendeskundige liggen in het traject dat vooraf gaat aan de uitvoering en de uitvoeringsfase zelf, waardoor er altijd een zekere onnauwkeurigheid in de kostenbepaling zit die beter kan worden uitgedrukt in het begrip ‘inschatting’.

De term ‘BIM’ heeft in de nieuwe titel plaatsgemaakt voor ‘een IFC model’. Een

BIM (Bouw Informatie Model) is een centraal opgeslagen, digitaal model, welke door alle bij het bouwproces betrokken partijen gebruikt kan worden voor het genereren van discipline-eigen gegevens. De gegenereerde gegevens kunnen vervolgens weer als verrijking van de totale projectinformatie aan het model worden toegevoegd. Het model is dus in staat om naast de geometrie, tal van eigenschappen van uiteenlopende disciplines te bevatten. Om een software onafhankelijke uitwisseling van de informatie tussen de projectpartijen mogelijk te maken wordt door de internationale organisatie BuildingSmart gewerkt aan een vrij toegankelijk en universeel uitwisselformaat IFC (Industry Foundation Classes). Vanwege de openheid en uitwisselmogelijkheden van dit bestandsformaat is in dit onderzoek gekeken naar een model van dit formaat – een IFC model. Elk IFC model is dus een BIM, maar niet elk BIM is een IFC model.

9.2 Resultaten Er zijn nu nog twee aanvullingen in de nieuwe titel onverklaard. De eerste is

‘ondersteunen van’. Deze aanvulling geeft de belangrijkste conclusie van dit onderzoek weer. Namelijk, dat het slechts de ondersteunende werkzaamheden van het inschattingsproces zijn, waaraan een IFC model op dit moment een bijdrage kan leveren. Het inschattingsproces van de bouwkostendeskundige bestaat uit controle en sturing van het proces op basis van resultaten uit inschattingen van zowel de reeds bekende ontwerpgegevens als nog onbekende gegevens uit het bouwproces. De ondersteunende werkzaamheden bestaan uit het inschatten van hoeveelheden en kosten die leiden tot genoemde resultaten. Toepassing van IFC bij deze ondersteunende werkzaamheden kan enorme positieve gevolgen hebben voor de accuraatheid waarmee op wijzigingen gedurende het bouwproces wordt ingesprongen. Het IFC model draagt bij aan invulling van de in beginsel op aanname gebaseerde inschatting.

De laatste aanvulling – ‘met behulp van (een IFC model)’ – duidt op een tweede

belangrijke conclusie, namelijk dat de informatie in IFC modellen onvoldoende


83

aansluit bij de benodigde gegevens van de bouwkostendeskundige. Gegevens waarmee hij/ zij met behulp van ervaringsgetallen in vroege fasen een inschatting van kosten kan maken, kunnen niet uit het IFC model worden gehaald omdat zij simpelweg ontbreken. De oorzaak hiervan is voor een deel terug te vinden in het feit dat de mogelijkheden van IFC nog onvoldoende worden benut. Ontwerpende partijen stellen zich nog te veel tot doel om met behulp van een BIM een goede bouwkundige tekening te genereren en te weinig tot doel om een goed informatie model te modeleren. Er zou veel meer en gedetailleerdere informatie opgenomen kunnen worden die de waarde van het model verhogen, zeker wanneer een universeel uitwisselformaat als IFC wordt gehanteerd waarmee ook de andere disciplines in het bouwproces het model kunnen verreiken met informatie. Ook zijn de applicaties waarmee de modellen worden opgebouwd nog onvoldoende in staat om goed met de IFC standaard te communiceren.

De oorzaak zal echter ook gezocht moeten worden in de traditionele werkwijze van de bouwkostendeskundige. Deze heeft nog geen gevoel bij kengetallen die beter aansluiten bij het Bouw Informatie Model en de resultaten die uit een dergelijk model al in vroege fasen behaald kunnen worden. Wanneer op dit moment van bouwkostendeskundigen verwacht zou worden om volledig over te stappen op de BIM systematiek dan zal deze discipline het BIM als ontoereikend beschouwen om de werkzaamheden nauwkeurig uit te kunnen voeren.

9.3 Ontwerp De kans van slagen van BIM voor de bouwkostendeskundige kan naar mijn

mening vergroot worden door een overgangssituatie te creëren, waarbij de nodige tijd wordt geboden op zoek te gaan naar nieuwe kengetallen. Het resultaat van dit onderzoek is een concept voor een ondersteunend middel bij het inschatten van bouwkosten door de bouwkostendeskundige dat aansluit bij een dergelijke overgang. Het is de basis voor een ontwerp dat binnen het traditionele werkproces gebruikt kan worden als hulpmiddel bij de ondersteunende werkzaamheden. Het IFC model wordt daarbij gekoppeld aan de inschatting, waarbij de eigenschappen van de in het model aanwezige entiteiten bepalend zijn voor de wijze waarop zij in de inschatting worden opgenomen. Basis voor de inschatting blijft echter een door de bouwkostendeskundige ingeschatte kwaliteit op basis van zijn ervaringen uit voorgaande projecten in de vorm van kengetallen en referenties. Het ontwerp,

Calculeren met BIM

84

waarvan tevens een prototype als onderdeel van dit onderzoek is ontwikkeld, respecteert daarmee de inleidende stelling van dit rapport29.

9.4 Aanbevelingen Met middelen als dit onderzoek en het daaruit resulterende prototype, kunnen de

voordelen van het gebruik van BIM in het bouwproces worden aangetoond. Wellicht is men doordoor eerder bereid om de ‘nukken’ die het gebruik momenteel nog kent te accepteren en een bijdrage te leveren aan het verbeteren van de werksystematiek. Voor de bouwkostendeskundige betekent dit dat er op langere termijn een omslag in zijn/ haar werkmethodiek plaats moet vinden. Om deze bouwkosten discipline mee te krijgen in de objectgeoriënteerde werkmethodiek van BIM verdient het aanbeveling om op basis van de eerste BIM projecten onderzoek te doen naar mogelijk te genereren kengetallen die aansluiten bij dergelijke modellen. Deze nieuwe kengetallen kunnen de omslag vormen in het traditionele inschattingsproces. Ontwikkelingen rondom BIM, zoals die van de ontwikkeling van objectenbibliotheek op basis van het International Framework for Dictionaries (IFD) kunnen de bouwkostendeskundige verder overtuigen. De kostenschatting kan immers beter worden geautomatiseerd als leveranciers van bouwproducten hun producten middels een dergelijke bibliotheek aanbieden.

Dat is ook een reden dat de commerciële ontwikkelingen rondom BIM niet onderschat moeten worden. Tijdens het onderzoek is namelijk gebleken dat de modeleerpakketten in de eigen systematiek zeer goed in staat zijn om gegevens te genereren die voor een kosteninschatting bruikbaar zijn en wellicht waren de resultaten van dit onderzoek eerder bereikt als voor een dergelijke commerciële oplossing was gekozen. Revit heeft bijvoorbeeld de mogelijkheid om het informatie model te exporteren naar een database waaruit gegevens als hoeveelheden per object en een eventuele eenheidsprijs direct uitleesbaar zijn.

Bovendien hebben de modelleerpakketten een grote voorsprong op het gebied van de objectenbibliotheken. Leveranciers van de pakketten zijn namelijk bereid om energie te stoppen in de ontwikkeling van dergelijke bibliotheken die aansluiten op de Nederlandse markt, omdat zij weten dat de commerciële vraag hiernaar groot is. Een samenwerking tussen de leveranciers en de bouwkostendeskundigen kan leiden tot bibliotheken die ook voor de bouwkostendiscipline zeer bruikbaar is.

29 ‘No tool can deliver a full estimate automatically from a building model. If a vendor advertises

this, they don’t understand the estimating process’

Literatuurlijst

85

Hoofdstuk 10

Literatuurlijst

BNA (2005). NL/SfB-tabellen, inclusief herziene Elementenmethode ‘91. Amsterdam: Bond van Nederlandse Architecten. ........................................... 23, 24

Bonsma, P (2008). Example 1: export of a basic IFC file with wall, opening and window, including property sets and base quantities [online], BuildingSMART. Te vinden via: www.iai-tech.org/services/get-started/hello-world/example-1 ...... 42

BuildingSmart (2006). Industry Foundation Classes - IFC2x Edition 3 [online]. Te vinden via: http://iaiweb.lbl.gov/IFC/R2x3_final/ [Geraadpleegd op 15 mei 2009] ............................................................................................................................ 42, 43

Clemen, C. en Gründig, L. (2006). The industry foundation classes (IFC) ready for indoor cadastre? [online]. Te vinden via: http://www.igg.tu-berlin.de [Geraadpleegd op 15 mei 2009] .............................................................................. 43

Dukers, J.A.G. (2008). Het gebruik van kengetallen tijdens de eerste fasen van het bouwproces. In Nederlandse Stichting voor Kostentechniek (DACE). Handboek Cost Engineers, M2010 . Alphen aan den Rijn: Kluwer bv. .......... 31, 32, 33, 72, 74

Eastman, C., Teicholz, P, Sacks, R. en Liston, K. (2008). BIM Handbook: a guide to building information modeling for owners, managers, designers, engineers and contractors. New Jersey: John Wiley & Sons. ........................................... 15, 57, 65

Espedokken, K. (2006). Associate Classification [online]. Te vinden via: http://idm.buildingsmart.no/ [Geraadpleegd op 15 mei 2009] .............................. 57

Haaften, J .van (2009). PIM – sala – BIM: informatiestromen in de bouw. CAD Magazine, 20 (3), pp. 20-21 ..................................................................................... 39

Jernigan, F.E. (2007). BIG BIM little bim. Salisbury: 4SitePress ..................... 65, 67

Jonge, T. (2005). Cost effectivesess of sustainable housing investment. Delft: Delft University of Technolgy. ....................................................................... 30, 56, 72, 74

Calculeren met BIM

86

Jonge, T. de, Zonneveld, S., Rimmelzwaan, J. (2007). Winket voor de bouw, Waarom en Hoe. Roosendaal: Winket voor de bouw. ............................................ 31

Keyner, W.R. en Rosmalen, M.M.G. van (2001). Bouwkostenmanagement. Doetinchem: Elsevier bedrijfsinformatie bv. ....................................... 21, 22, 29, 32

Khemlani, L (2004). The IFC Building Model: A Look Under the Hood [online], AECbytes. Te vinden via: www.aecbytes.com/ .......................................... 36, 38, 47

Liebich, T. (2004). IFC 2x Edition 2, Model Implementation Guide. Version 1.7. IAI Model Support Group ............................................................................ 43, 51, 59, 61

NIBS (2007). National Building Information Modeling Standard, Version 1 - Part 1: Overview, Principles and Methodologies. National Institute of Building Sciences .................................................................................................................... 37

NNI (2002). NEN 2634: Termen, definities en regels voor het overdragen van gegevens over kosten- en kwaliteitsaspecten voor bouwprojecten. Delft: Nederlands Normalisatie Instituut................................................ 19, 20, 21, 24, 31

NNI (2007). NEN 2580: Oppervlakten en inhouden van gebouwen - Termen, definities en bepalingsmethoden. Delft: Nederlands Normalisatie Instituut. ..... 28

Robbemondt, H.M. (2008). Hoe het Building SMART concept de bouw kan veranderen: Een IFC benchmark. Eindhoven: Technische Universiteit Eindhoven ............................................................................................................................ 42, 62

STABU (2005) Stabu Standaard 2005, Bestekssystematiek voor de woning- en utiliteitsbouw. Ede: Stichting Standaardbestek Burger- en Utiliteitsbouw ........ 24

STABU (2005a) Koppeling Elementenmethode 1991 en STABU2-systematiek. Ede: Stichting Standaardbestek Burger- en Utiliteitsbouw ................................... 24, 25

Wilson, P.R. (1998). STEP and EXPRESS [online]. Te vinden via: http://deslab.mit.edu/DesignLab [Geraadpleegd op 3 mei 2009] .......................... 44

Calculeren met BIM

– bijlagen –

Bijlage 1. Digitale bijlagen

De volgende bestanden behoren als digitale bijlagen tot dit rapport: 1. IfcCostEstimator.xlsm 2. Ifc2x3.exp

CD-rom: digitale bijlagen behorende bij het rapport ‘Calculeren met BIM’

Gebruik van de digitale bijlagen is geheel voor eigen risico.

– bijlagen –

Bijlage 2. Procedure voor het gebruik van het prototype

Na controle van onderstaande punten, kunt U gebruik maken van de informatie

uit Hoofdstuk 8 om gebruik te maken van het prototype dat onderdeel is van de digitale bijlagen van dit rapport (Bijlage 1). Gebruik van het prototype is geheel voor eigen risico.

1. Het systeem moet zijn voorzien van Microsoft Office 2007, met de programma’s MS Office Excel en MS Office Access.

2. Het beveiligingsniveau van MS Office Excel voor macro’s moet zijn ingesteld op ‘midden’ of ‘laag’. Bij het openen van het prototype moeten de macro’s ingeschakeld worden.

3. Op de C:\ partitie moet zich het document ‘ifc2x3.exp’ bevinden, dat onderdeel is van de digitale bijlagen van dit rapport (Bijlage 1).

4. De gebruiker moet schrijfrechten hebben voor de C:\ partitie, aangezien hier de nodige databases worden opgebouwd bij het inlezen van het IFC model.

– bijlagen –

Bijlage 3. Verklarende woordenlijst

Abstracte entiteit Een entiteit waarvan geen instantie gemaakt kan worden, maar die uitsluitend dient haar sub-entiteiten te definiëren en dus niet zelf niet in een IFC model voorkomt.

Common Property Set

Een Property Set die standaard is voor een bepaalde entiteit, waarvan verondersteld mag worden dat deze door meerdere IFC ondersteunende applicaties herkend wordt.

Data-sectie Dat deel van het IFC bestand waarin de informatie over het model en de daarin aanwezige entiteiten is omschreven.

Definitie (van een entiteit)

Een omschrijving van de wijze waarop en met welke eigenschappen een object, relatie of eigenschap voor kan komen in een IFC model.

Directe eigenschappen

Eigenschappen die volgens de definitie van de entiteit direct en uitsluitend betrekking hebben op die entiteit en haar eventuele sub-entiteiten, danwel die eigenschappen die worden geërfd van haar super-entiteit(en).

Entiteit Definitie van een object, relatie of eigenschap. Express schema Een schema in de modelleertaal Express, waarin de

definities van entiteiten staat omschreven. Gerelateerde eigenschappen

Eigenschappen die aan de entiteit worden toegekend middels een relatie met een andere entiteit.

Header-sectie Dat deel van het IFC bestand waarin de algemene informatie over het bestand als zodanig is omschreven

Instantie Een met waarde gevulde entiteit die aanwijsbaar in het IFC model aanwezig is.

Property Set Een set van een of meerdere zelf gedefinieerde eigen-schappen die optioneel door gebruikers of applicaties aan entiteiten toegekend kunnen worden (maar welke niet per definitie door andere gebruikers of applicaties herkend zal worden).

– bijlagen –

Bijlage 4. Case lijst

Onderstaande modellen zijn gebruikt bij de casus en bij het testen van het prototype van ICE. Getoonde afbeeldingen zijn gegenereerd met de Nemetschek IFC Viewer.

Case 1 miniExample

Bron: BuildingSMART

Modeller: -

Aantal entiteiten:

7

Case 2 Haus G-H (deels)

Bron: BuildingSMART

Modeller: ArchiCAD 9

Aantal entiteiten:

66

Case 3 Haus G-H

Bron: BuildingSMART


Aantal entiteiten:

301

Calculeren met BIM

– bijlagen –

Case 4 Smiley West Project

Bron: Institute for Applied Computer Science

Modeller: ADT

Aantal entiteiten:

599

Case 5 FZK House


Modeller: Allplan

Aantal entiteiten:

76

Case 6 Munkerud

Bron: BuildingSMART


Aantal entiteiten:

580

Case 7 Niedriha

Bron: BuildingSMART


Aantal entiteiten:

172

– bijlagen –

Case 8 Office Building



Aantal entiteiten:

1201

Case 9 FJK House


Modeller: ADT

Aantal entiteiten:

274

Case 10 Vrijstaande woning

Bron: MdR advies

Modeller: Revit 2009

Aantal entiteiten:

254

Case 11 Winkel en appartementen

Bron: MdR advies

Modeller: Revit 2009

Aantal entiteiten:

611

Calculeren met BIM

– bijlagen –

Case 12 Jasmin Sun

Bron: BuildingSMART


Aantal entiteiten:

102

Case 13 Gebaeude Gruppe Modeller: ArchiCAD 9/ ADT/ Allplan


Aantal entiteiten:

278

Case 14 Ettenheim Town Modeller: ADT


Aantal entiteiten:

3778

– bijlagen –

Bijlage 5. Representatie van de instantie IfcWallStandardCase

De representatie van een entiteit van het type IfcWallStandardCase (Schema B 1) bestaat uit;

1. Een Axis (de referentielijn) 2. Een Body (de opbouw)

Schema B 1; Representatie hiërarchie van de entiteit IfcWallStandardCase

De Axis en de Body worden gedefinieerd door 2 afzonderlijke entiteiten van het type IfcShapePresentation. De eigenschap Representations van de entiteit IfcProductDefinitionShape bevat dus minimaal twee verwijzingen naar IfcShapeRepresentations. De eigenschappen van deze representaties kunnen voor wat betreft een IfcWallStandardCase maar een beperkt aantal waarden bevatten, welke zijn weergegeven in Schema B 2 voor de Axis en in Schema B 3 voor de Body.

IfcWallStandardCase

IfcProductDefinitionShape

GlobalId OwnerHistory Name Description ObjectType ObjectPlacement Representation Tag Name

Description Representations IfcShapePresentation

ContextOfItems RepresentationIdentifier RepresentationType

Items

Calculeren met BIM

– bijlagen –

Schema B 2; Voorwaarden aan de eigenschappen van de Axis van een IfcWallStandardCase

De eigenschap ‘Items’ van IfcShapePresentation mag in dit geval dus slecht één verwijzing naar een ItemRepresentation hebben.

Met behulp van de IfcTrimmedCurve of de IfcPolyline is de lengte van de referentielijn te bepalen. Dit hoeft echter niet de lengte van de wand te zijn, want de lijn kan een afstand (een offset) hebben ten opzichte van de wand zelf. Bij gekromde wanden moet hier bij het bepalen van de lengte rekening mee worden gehouden.

Schema B 3; Voorwaarden aan de eigenschappen van de Body van een IfcWallStandardCase

Met behulp van de body kan de hoogte van de wand worden bepaald door de ‘depth’ van de IfcExtrudedAreaSolid te bepalen.

Voor de Body

ContextOfItems RepresentationIdentifier = Body RepresentationType = SweptSolid óf Clipping

Items = IfcExtrudedAreaSolid óf IfcBooleanClippingResult

IfcShapePresentation

Voor de Axis IfcShapePresentation

ContextOfItems RepresentationIdentifier = Axis RepresentationType = Curve2D Items = IfcTrimmedCurve óf IfcPolyline

– bijlagen –

Bijlage 6. Handelingen prototype ICE

Schema B 4; Laden van het IFC bestand (gegevens ophalen)

Vraag gebruiker een IFC file te selecteren

Bepaal of de selectie correct is

Open het IFC (tekst) bestand

Gebruiker selecteert een IFC file

Bewaar de gekozen bestandslocatie en datum van het IFC

bestand in het kostenbestand

Plaats gegevens van de entiteit in een

array met alle entiteiten

Bepaal inhoud van de eerstvolgende

regel

ja


regel

nee

<> “DATA;”

= “DATA;”

Sluit het IFC bestand

= “ENDSEC;”

<> “ENDSEC;”

Schema B 5

A

Calculeren met BIM

– bijlagen –

Schema B 5; Laden van het IFC bestand (database maken)

Maak een lege database

Bepaal of tabel van dit entiteittype bestaat in de

database

Bepaal eerstvolgende entiteittype in

entiteiten-array

Controleer of het aantal

eigenschappen in de entiteitenarray

overeenkomt met het aantal kolommen van de entiteittabel

Voeg een fout toe aan het totaal aantal

fouten

ja Voeg de entiteit met eigenschappen toe aan de entiteittabel

in de database

Schema B 6

nee

Bepaal of er fouten zijn opgetreden

Laatste entiteit

anders

Toon fouten aan gebruiker

ja

nee

nee

ja

– bijlagen –

Schema B 6; Laden van het IFC bestand (Tabel maken op basis van IFC2x3 Express schema)

Open het IFC2X3 schema


regel

Sla de eigenschap, met diens

kenmerken op in een tijdelijke array

Bepaal het soort eigenschap (unieke sleutel, verplichte

waarde en notatie)

Komt overeen met entiteittype, danwel het gewenste supertype

anders

Maak de entiteittabel


regel

Maak voor elke eigenschap een

kolom met de juiste kenmerken

= “END_ENTITY;”

<> “END_ENTITY;”

Calculeren met BIM

– bijlagen –

Schema B 7; Filteren van entiteiten (Tabel maken op basis van IFC2x3 Express schema)

Toon het venster voor entiteitselectie

Gebruiker selecteert een entiteit

Voeg pagina voor IfcPropertySet toe

aan formulier

Voeg velden voor eigenschappen, behorende tot de

IfcPropertySet toe aan de pagina

Laatste tabel

anders

Sluit entiteiten database

Toon het eigenschappen

venster voor selectie

Gebruiker maakt selectie uit de

eigenschappen van de IfcPropertieSets

Open de entiteiten database

Bepaal eerstvolgende tabel

Bepaal tabelnaamanders

Een van de entiteit_PropertySet

tabellen

– bijlagen –

Schema B 8; Filteren van entiteiten (maken van de Front-End database)

Maak een Front-End database met de tabellen van de

entiteiten database

Bepaal eerstvolgende kolom

van de tabel

Controleer of de gebruiker voor deze eigenschap een filter

heeft ingesteld

laatste tabel

anders

Maak een selectie-query in de Front-End database met de gekozen filters

Sluit de databases

Open de entiteiten database

Bepaal eerstvolgende tabel van de entiteiten-

database

Bepaal tabelnaamanders

Een van de entiteit_PropertySet

tabellen

laatste kolom

Voeg dit filter toe aan de selectie -

query

anders

ja

nee

Open de selectie-query van de

begrotingsregel

Laatste record

Bepaal eerstvolgende

record

anders

Sluit de selectie- query

Plaats de entiteit en haar eigenschappen

in de begrotingsregel

Schema B 9

Calculeren met BIM

– bijlagen –

Schema B 9; Bepalen van hoeveelheden

Bepaal het entiteittype

Representatie- waarden zijn 0

Bepaal de lengte met behulp van de

coördinaten

Bepaal de hoogte met behulp van de diepte van extrusie

Type IfcWallStandardcase

anders

Open de tabel IfcProduct-

DefenitionShape

Bepaal de eerstvolgende

record

Open de tabel IfcShape-

Representation

anders

Record is representatie van IfcWallStandardcase

Bepaal het type curve

Het prototype biedt geen oplossing

Record is een vorm van de representatie


record

anders

Bepaal het type vorm

Type Axis met een Curve

TrimmedCurve

Type Body

Bepaal het type body-lijn

Polyline


SweppedSolid


Hoogte is 0 Lengte is 0

Laatste record

Clipping

– bijlagen –

Schema B 10; Begroting vernieuwen

Controleer de datum van het model

Plaats de resultaten in de begroting,

naast de bestaande waarden

Later dan begroting

nee

Vraag gebruiker of de begroting

aangepast moet worden

Gebruiker maakt keuze

Gelijk aan begroting

ja


record

anders


begrotingsregel


selectie-query in de Front-End database

anders

Open de Front-End database

Laatste regel

Schema B 4A

Bepaal eerstvolgende

entiteit in begrotingsregel

Laatste record

Entiteit hoort bij record

Schema B 9

Laatste query

Selectie-query hoort bij begrotingsregel

anders

Laatste entiteit

anders

Calculeren met BIM

– bijlagen –

Schema B 11; Verrijken van het IFC model

Open het originele IFC bestand

Creëer een nieuw bestand met de naam van het origineel en de

toevoeging ‘_costs’

Schrijf persoonsgebonden informatie naar het

IFC model

anders


begrotingsregel

Bepaal of een selectie criteria is

opgegeven voor de begrotingsregel

anders

Laatste regel

Regel is ‘ENDSEC;’ van data-secie Lees de

eerstvolgende regel van het originele

bestand

Schrijf dezelfde regel naar het

nieuwe bestand

nee

Schrijf de kosten/ eenheid als property set naar het nieuwe

bestand

Schrijf een regel ‘ENDSEC;’ naar het

nieuwe bestand

Sluit de bestanden

Documents

Calculeren met BIM - BouwIQCalculeren met BIM Ing. J. Witteman, mei 2009 Technische Universiteit Eindhoven, faculteit Architecture, Building and Planning, afdeling Design and Decision