BIM og Miljøberegning

Transkript

1 Karl Kristian Olsson Haave BIM og Miljøberegning Masteroppgave 14. juni 2010 NTNU Norges teknisk-naturvitenskapelige universitet Fakultet for Ingeniørvitenskap og teknologi Institutt for konstruksjonsteknikk

2 Institutt for konstruksjonsteknikk Fakultet for ingeniørvitenskap og teknologi NTNU- Norges teknisk- naturvitenskapelige universitet TILGJENGELIGHET Fullt tilgjengelig MASTEROPPGAVE 2010 FAGOMRÅDE: KONSTRUKSJONSINFORMATIKK DATO: 14. juni 2010 ANTALL SIDER: 120 TITTEL: UTFØRT AV: BIM og Miljøberegning BIM and Environmental Analysis Karl Kristian Olsson Haave SAMMENDRAG: Building information modeling (BIM) blir tatt i bruk i stadig flere byggeprosjekter, og utfordringen med å oppnå interoperabilitet mellom ulike typer applikasjoner har etter hvert blitt et tema. Formålet med denne masteroppgaven er å vurdere interoperabiliteten mellom modelleringsapplikasjoner og analyseapplikasjoner i dag, og hvilke muligheter man har til å forbedre interoperabiliteten i tiden som kommer. I oppgaven blir ulike kommunikasjonsformater og kommunikasjonsmåter vurdert. Videre blir interoperabiliteten mellom modelleringsapplikasjonen Autodesk Revit 2011 og analyseapplikasjonene Ecotect Analysis 2011 og IES VE testet. Overføringsformatene IFC 2x3 og gbxml 0.37 ble brukt for å overføre informasjon fra Revit til henholdsvis Ecotect og IES VE. Masteroppgaven har blitt utarbeidet i samarbeid med COWI avdeling Trondheim, og oppgaven avsluttes med en anbefaling til COWI om valg av overføringsformat og råd til videre arbeid for å forbedre interoperabiliteten mellom applikasjoner i fremtiden. FAGLÆRER: Tor G. Syvertsen VEILEDER(E): Ingrid Alvsåker og Dagfinn Bell UTFØRT VED: Institutt for Konstruksjonsteknikk, Fakultetet for Ingeniørvitenskap og Teknologi, NTNU.

3 Institutt for konstruksjonsteknikk FAKULTET FOR INGENIØRVITENSKAP OG TEKNOLOGI NTNU Norges teknisk-naturvitenskapelige universitet MASTEROPPGAVE 2010 for stud. techn. Karl Kristian Olsson Haave BIM og Miljøberegning BIM and Environmental Analysis Bakgrunn for oppgaven/problemstilling Kandidaten har inngått i et samarbeid med bedriften COWI. COWI har tatt i bruk BIM på en rekke byggeprosjekter og ønsker å teste ut to miljøberegningsprogrammer for å kartlegge hvor godt de fungerer med Autodesk Revit. Angrepsmåte Kandidaten skal sette seg inn i og teste ut programmene Autodesk Ecotect og IES VE koblet opp mot Autodesk Revit. Dette arbeidet vil innebære et litteraturstudium, samt praktisk bruk av programmene. Referanseprosjektet som brukes for å teste programmene vil være den nye barneavdelingen til Ålesund Sykehus. Kandidaten ønsker å kartlegge følgende punkter: Interoperabilitet mellom Revit og de to programmene. Komme med forslag til hvordan COWI skal kunne håndtere eventuelle problemer med interoperabilitet. Resultat Kandidaten skal utarbeide en rapport som inneholder en presentasjon av resultatene avdekket under arbeidet med oppgaven. Herunder inngår vurdering av interoperabilitet mellom programvare og drøfting av hvordan COWI kan håndtere eventuelle problemer med interoperabilitet for å sikre at informasjonen er pålitelig. Til slutt skal kandidaten komme med forslag til hvilket program som bør velges, basert på disse resultatene. Oppgaven kan underveis tilpasses arbeidets forløp og kandidatens interesser.

4 Besvarelsen organiseres i henhold til gjeldende retningslinjer for masteroppgaver ved institutt for konstruksjonsteknikk. Kontaktperson hos bedrift: Navn: Dagfinn Bell Epost: dbe@cowi.no Tlf: Navn: Ingrid Alvsåker Epost: ial@cowi.no Tlf: Veileder: Navn: Tor G. Syvertsen Epost: torgsyv@gmail.com Tlf: Besvarelsen skal leveres til Institutt for konstruksjonsteknikk senest 14. juni 2010 Trondheim, Tor G. Syvertsen faglærer

5 Forord Med denne masteroppgaven er et femårig masterstudium i Bygg- og Miljøteknikk ved NTNU i Trondheim fullbyrdet. Masteroppgaven er utviklet i faget TKT4900 ved Institutt for Konstruksjonsteknikk under Fakultet for ingeniørvitenskap og teknologi på NTNU, i samarbeid med COWI, Trondheim. En stor takk rettes til oppgavens hovedveileder Professor Tor G. Syvertsen ved NTNU for hjelp til å stille de rette spørsmålene og for alltid å være en ariadnetråd. Jeg ønsker også å takke COWI da spesielt Ingrid Alvsåker og Dagnn Bell for å stille arbeidsplass og programvare til disposisjon og for å ta seg tid til å hjelpe meg. Takk til familie og venner for hjelp og støtte, og sist men ikke minst takk til min kjære for alle middager og all nytraktet kae. Trondheim 14. juni 2010 Karl Kristian Olsson Haave Nunc est bibendum, nunc pede libero pulsanda tellus. I

6 Sammendrag For å gjøre detaljerte energianalyser var man tidligere avhengig av å ta ut mengder manuelt fra 2D tegninger. Ulempene med dette var mange; prosessen var tidkrevende, kostet mye og i store prosjekter kunne man fort regne feil og få unøyaktige mengder. Derfor ble antallet kalkyler og analyser ofte holdt på et minimum [Jongeling, 2008]. I prosjekter som bruker Building Information Model/Modelling (BIM) kan modellen importeres i en analyseapplikasjon, og man kan bruke denne informasjonen for å utføre kalkyler og analyser. Prosessen er raskere og mer nøyaktig, og fører ofte til at man utfører ere analyser og oppnår et bedre resultat [Bourarsa, 2005]. Et byggeprosjekt består av en rekke ulike aktører, som ikke nødvendigvis bruker samme type programvare. Det at en analyseapplikasjon skal kunne hente ut informasjon fra en BIM avhenger av at applikasjonene som skal kommunisere er interoperabile. Den viktigste funksjonen til BIM er å legge til rette for bedre menneskelig samarbeid i byggebransjen. For å få til et godt samarbeid er man avhengig av god kommunikasjon [Eikeland, 2000]. Etter hvert som mer og mer BIM-programvare har blitt utviklet har behovet for en standardisert måte applikasjonene kan kommunisere på kommet tydelig frem. Formålet med denne masteroppgaven er å vurdere interoperabiliteten mellom modelleringsapplikasjoner og analyseapplikasjoner i dag, og å vurdere hvilke muligheter man har til å forbedre interoperabiliteten i tiden som kommer. Problemstillingen til masteroppgaven har blitt utarbeidet i samarbeid med COWI, avdeling Trondheim. COWI har tatt i bruk BIM på en rekke byggeprosjekter og ønsket å teste interoperabiliteten mellom modelleringsapplikasjonen Autodesk Revit og analyseapplikasjonene Ecotect Analysis og Integrated Environmental Solutions (IES) Virtual Environment (VE). For å vurdere interoperabiliteten mellom applikasjonene ble en rekke ulike modeller laget. Disse modellene ble konvertert til Industry Foundation Classes (IFC)-modeller og Green Building Extensible Markup Language (gbxml)-skjemaer for å bli overført til henholdsvis Ecotect Analysis og IES VE. Informasjonen som ble testet for overføring er prosjektinformasjon, rominformasjon og informasjon om objekttyper, geometri og materialegenskaper. gbxml-skjemaet klarte ikke å overføre informasjon om materialegenskapene til bygningskomponenter og formatet hadde til tider problemer med nøyaktig å representere kompleks geometri. Til tross for disse svakhetene kom gbxmlskjemaet klart best ut i de ulike testene. Vesentlig informasjon gikk tapt ved overføring via IFC-modellen, og modellene som ble overført ble svært fordreid. II

7 Full interoperabilitet mellom applikasjoner ved kommunikasjon via lformater innebærer at alle applikasjonene må kunne importere all informasjonen i - len, og i tillegg kunne eksportere all informasjon til samme format. Å oppnå full interoperabilitet ved en slik type kommunikasjon har vist seg å være svært utfordrende selv for overføring av enkle tekstdokumenter [Shah and Kesan, 2008], og for informasjon i en BIM blir oppgaven tilnærmet umulig. Å gå over til server-klient kommunikasjonstypen vil gi store muligheter til å oppnå full interoperabilitet mellom applikasjoner. Kommunikasjonen mellom applikasjonene og en database-serveren består av enkle transaksjoner for å hente ut og putte inn informasjon. Applikasjoner sender spørringer til serveren for å få den informasjonen som er relevant, og trenger ikke å kunne tolke all informasjon i den digitale modellen. På grunn av dette er prosessen med å gjøre applikasjonene interoperabile med serveren langt enklere enn å gjøre applikasjonene direkte interoperabile med hverandre. Full interoperabilitet mellom applikasjoner som kommuniserer via en server avhenger av at applikasjonsleverandørene gir hverandre innsyn i sine dataaksesslag og forretningslag og sammen blir enige om grunnprinsipper for hvordan informasjon skal deneres og overføres. Dette innebærer at leverandørene vil miste noen av sine konkurransefortrinn og brukervennligheten og funksjonaliteten til applikasjonene vil bli desto viktigere, noe som vil være gunstig for forbrukerne. Igangsettingen av et slikt samarbeid mellom applikasjonsleverandører avhenger av at aktørene i byggenæringen innser behovet for en slik kommunikasjonsmåte og at de sammen formidler dette behovet til applikasjonsleverandørene. III

8 Innhold Forord Sammendrag Innhold Akronymer Figurer I II IV VII IX 1 Innledning Generelt BIM og miljøvurdering Oppgavens formål og omfang Metodikk Disposisjon Building Information Model/Modelling (BIM) Generelt Objektmodellering Hva er BIM Oppsummering Interoperabilitet Generelt Overføringsformater Kommunikasjon via loverføring Kommunikasjon via database-server IFC IV

9 3.6 Green Building Extensible Markup Language (gbxml) Sammenligning av IFC og gbxml Programvare Generelt Autodesk Revit Autodesk Ecotect IES VE Målemetode Generelt Innstillinger i Revit Testmodeller Resultater Generelt Presentasjon av resultatene Sammendrag av resultatene Drøfting av resultatene Anbefaling til COWI i forhold til BIM og miljøvurdering Situasjonen i dag Fremtidig arbeid med BIM og miljøvurdering Konklusjon og videre arbeid Generelt Konklusjon Videre arbeid Kildeliste 77 V

10 Vedlegg 82 A Eksempel på hvordan attributter arves i IFC B Eksempel på oppbygningen av et gbxml-element C Import- og eksportevne til programvare D gbxml-elementer og -attributter som støttes av Revit Architecture E IFC-avbildingsl F Resultater fra Test G Resultater fra Test VI

11 Akronymer 3D AEC API tredimensjonal Architecture, Engineering and Construction Application programming interface ASHRAE American Society of Heating, Refrigeration and Air-Conditioning Engineers BIM CAD CDF CEC CIBSE Building Information Model/Modelling Computer Aided Design Computational Fluid Dynamics California Energy Commission Chartered Institution of Building Services Engineers CIS/2 Cimsteel Integration Standard version 2 DAYSIM Dynamic Daylight Simulations DXF EPD FDS GARM GBS gbxml GSA GUI HTML HVAC IAI IDM IES Data exchange Format Environmental Product Declaration Fire Dynamics Simulator General AEC Reference Model Green Building Studio Inc. Green Building Extensible Markup Language General Services Administration Graphical User Interface HyperText Markup Language Heating, Ventilating and Air Conditioning International Alliance for Interoperability Integrated Data Model Integrated Environmental Solutions VII

12 IFC ISO ISY IT JDBC MSG NIST NURBS OCA ODBC OMT OOP PCE PBS PGE PIER RDB SIMIEN Industry Foundation Classes International Organization for Standardization Informasjonssystemer Informasjonsteknologi Java Database Connectivity Model Support Group National Institute of Standards and Technology Non Uniform Rational Basis Spline Oce of the Chief Architect Open Database Connectivity Object Modeling Technique Objekt Oriented Programming Parametric Change Engine Public Buildings Service Pacic Gas and Electric Public Interest Energy Research Revit Database SIMulering av Inneklima og ENergibruk i bygninger SIMULA SIMulation LAnguage SQL STEP UML VE WWW X3D XML Structured Query Language STandard for the Exchange of Product model data Unied Modeling Language Virtual Environment World Wide Web Extensible 3D Graphics Extensible Markup Language VIII

13 Figurer 2.1 Utvikling innen BIM [Howard and Bjørk, 2008] Objektmodell av OMT [Syvertsen, 2009] Utviklingen av Computer Aided Design (CAD) [Graphisoft, 2009] Informasjonsyt i BIM Kommunikasjon via loverføring Kommunikasjonsmåte med én leverandør Kommunikasjon via mellomvare Kommunikasjon via åpne datamodellformater IFC sin systemarkitektur [Model Support Group (MSG), 2010] Dataoverføring via International Organization for Standardization (ISO)-STandard for the Exchange of Product model data (STEP) Part Avvik ved overføring mellom applikasjoner [Kalstveit, 1997] Sammenligning av IFC-modellen [buildingsmart, 2010b] og gbxmlskjemaet [gbxml, 2010] Verktøylinjen til Autodesk Revit Autodesk Revit sitt Graphical User Interface (GUI) Inndeling av informasjon i Autodesk Revit [Autodesk, 2009b] Eksportering til gbxml-formatet i Revit Informasjonsorganisering i gbxml [Autodesk, 2009b] Autodesk Ecotect sitt GUI Import av IFC i Ecotect IES VE sitt GUI [IES VE, 2010] De ulike variantene av IES VE [IES VE, 2010] Importering av gbxml-l i IES VE IX

14 4.11 Kontroll av rom i modell som skal importeres IES VE PlugIn til Autodesk Revit Energy Settings i Revit Endring av modellens orientering i Revit Room Bounding attributt i Revit Justering av sonehøyde i Autodesk Revit Romvolum Menyen IFC Options Feilmelding i Revit Redigering av faser i Revit Modell laget i Revit for Test Modell laget i Revit for Test Modeller laget i Revit for Test Modeller laget i Revit for Test Modell laget i Revit for Test Modell fra Test 2 lastet inn i Ecotect Analysis Modell fra Test 2 lastet inn i IES VE Modell med mangekantet vegg lastet inn i Ecotect Analysis Modeller fra Test 3 lastet inn i IES VE Modell med gavltak fra Test 4 lastet inn i Ecotect Analysis Modeller fra Test 4 lastet inn i IES VE Modell fra Test 5 lastet inn i Ecotect Analysis Sammendrag av resultatene fra de utførte testene Bygningskomponentenes hiearkiske inndeling i IES VE Sammendrag av resultatene fra de utførte testene A.1 Arv av attributter for IFC BEAM X

15 B.1 Oppbygning av Exterior Wall i gbxml C.1 Autodesk Revit 2011 Importevne [Autodesk, 2010a] C.2 Autodesk Revit 2011 Eksportevne [Autodesk, 2010a] C.3 Model/Analysis Data [Autodesk, 2010a] C.4 tredimensjonal (3D) CAD Geometry [Autodesk, 2010a] C.5 Model/Analysis Data [Autodesk, 2010a] C.6 External Analysis Tool [Autodesk, 2010a] C.7 Image/Screenshot [Autodesk, 2010a] C.8 IES VE Importevne [IES VE, 2010] C.9 IES VE Eksportevne [IES VE, 2010] D.10 gbxml Element [Autodesk, 2009b] D.11 Campus Element [Autodesk, 2009b] D.12 DocumentHistory Element [Autodesk, 2009b] D.13 Location Element [Autodesk, 2009b] D.14 Building Element [Autodesk, 2009b] D.15 Space Element [Autodesk, 2009b] D.16 ShellGeometry Element [Autodesk, 2009b] D.17 SpaceBoundary Element [Autodesk, 2009b] D.18 Surface Element [Autodesk, 2009b] D.19 Opening Element [Autodesk, 2009b] E.20 IFC-avbildingsl F.21 Resultater fra Test G.22 Resultater fra Test

16 1 Innledning 1.1 Generelt Den norske stat har gjennom Klimameldingen og Klimaforliket forpliktet seg til å redusere Norges utslipp av klimagasser tilsvarende 30% av Norges utslipp i 1990 [Kommunal- og regionaldepartementet, 2009], og har blant annet igangsatt tiltak som angår bolig- og byggesektoren. Bolig- og byggesektoren omtales som 40% næringen da næringen står for cirka 40% av det totale energiog ressursforbruket og avfallsproduksjonen i Norge. Potensialet til å redusere energibruken og Norges klimagassutslipp ved innstramminger i byggenæringen er med andre ord vesentlig. Kravene til bygg har blitt skjerpet av staten gjennom juridiske virkemidler, og energikravene i tekniske forskrifter til planog bygningsloven skal etter planen justeres minst hvert femte år. Ny plan- og bygningslov med tilhørende forskrifter trer i kraft fra og med 1. juli 2010, og for å øke fokuset på miljø må nyoppførte bygg etter dette være energimerket [Kommunal- og regionaldepartementet, 2009]. I tillegg har staten tatt i bruk økonomiske virkemidler som miljøavgifter og tilskudd gjennom Enova for å påvirke bolig- og byggesektoren til å bygge mer miljøvennlige bygg. Stadig strengere krav fra staten, muligheter for økonomisk støtte gjennom incentiver, byggeindustriens eget samfunnsengasjement og en økende etterspørsel fra brukere er alle omstendigheter som underbygger hvorfor det er viktig for byggeindustrien å bygge miljøvennlige bygg populært kalt grønne bygg. A sustainable building, or green building is an outcome of a design philosophy which focuses on increasing the eciency of resource use energy, water, and materials while reducing building impacts on 2

17 human health and the environment during the building's lifecycle, through better siting, design, construction, operation, maintenance, and removal [Frej and Anne, 2005]. I et byggeprosjekt hvor man har som mål å bygge et grønt bygg er man avhengig av energi- og miljøanalyser for å nne frem til optimale løsninger og design [Krygiel and Nies, 2008]. Energi- og klimaanalyser av bygninger baserer seg på informasjon om blant annet bygningsmaterialer, tekniske installasjoner, overater og volumer [Krygiel and Nies, 2008]. Å modellere bygninger med analyseapplikasjoner krever tid til å denere inndataverdiene, kjøre simulasjonen og å analysere utdata. Man har tidligere vært avhengig av å ta ut mengder manuelt fra 2D-tegninger for å gjøre detaljerte energianalyser av bygninger [Jongeling, 2008]. Ulempene med dette er mange; i store prosjekter kan man fort regne feil og få unøyaktige mengder. I tillegg er prosessen tidkrevende og koster mye, og antall kalkyler og analyser blir derfor holdt på et minimum. Det er ikke uvanlig at erfaringstall fra lignende bygninger har blitt brukt for å analysere bygget, noe som også bidrar til at analysene blir unøyaktige [Jongeling, 2008]. Implementeringen av ny teknologi i byggebransjen har gitt muligheten til å forenkle denne prosessen. 1.2 BIM og miljøvurdering BIM-teknologi er i ferd med å få et stadig sterkere fotfeste innenfor Architecture, Engineering and Construction (AEC)-industrien. BIM tar utgangspunkt i et prosjektsamarbeid hvor alle aktører tilfører informasjon til en digital bygningsmodell. Denne informasjonen kan blant annet være geometrisk data, byggets lokasjon og orientering, bygningsmaterialer og -komponenter, tekniske installasjoner og fremdriftsplaner. Modellen utvikles i prosjekteringsfasen, brukes til å følge opp arbeidet i gjennomføringsfasen og kan videre benyttes i hele byggets levetid for forvaltning, drift og vedlikehold, eventuelle ombygginger og ved riving. Det har blitt erfart at 50% av tiden det tar for å modellere og analysere en energimodell går med til å gjenskape bygningsgeometrien i en analyseapplikasjon [Krygiel and Nies, 2008]. Det å benytte BIM i et byggeprosjekt gir analyseapplikasjoner mulighet til å hente relevant informasjon direkte ut fra modellen, noe som gjør prosessen raskere og mer nøyaktig. Ofte fører dette til at man utfører ere analyser, og man kan bruke energimodeller som en integrert del av designprosessen [Yudelson, 2008]. Særlig i tidligfase vil det være fordelaktig å utføre 3

18 ere energianalyser, da det her er størst muligheter for å påvirke utformingen av designet [Yudelson, 2008]. Analysene gir et bedre grunnlag for å foreta valg, og ved å bruke dette aktivt i designprosessen kan man få gode miljøløsninger. Prosessen med å dokumentere byggets egenskaper i forhold til krav for en miljøsertisering blir også enklere [Jongeling, 2008]. Dette kan i tiden som kommer være med på å heve miljø som konkurransefaktor. Et byggeprosjekt består av en rekke ulike aktører, som ikke nødvendigvis bruker samme type programvare. Det at en analyseapplikasjon skal kunne hente ut informasjon fra en BIM avhenger av at applikasjonene som skal kommunisere er interoperabile. Etter hvert som mer og mer BIM-programvare har blitt utviklet, har behovet for en standardisert måte applikasjonene kan kommunisere på kommet tydelig frem. 1.3 Oppgavens formål og omfang Formålet med denne masteroppgaven er å vurdere interoperabiliteten mellom modelleringsapplikasjoner og analyseapplikasjoner i dag, og hvilke muligheter man har til å forbedre interoperabiliteten i tiden som kommer. Problemstillingen til masteroppgaven har blitt utarbeidet i samarbeid med COWI, avdeling Trondheim. COWI har tatt i bruk BIM på en rekke byggeprosjekter og ønsket å teste interoperabiliteten mellom modelleringsapplikasjonen Autodesk Revit og analyseapplikasjonene Ecotect Analysis og IES VE. Versjonene som ble brukt under testene er Autodesk Revit 2011, Ecotect Analysis 2011 og IES VE Overføringsformatene IFC 2x3 og gbxml 0.37 ble brukt for å overføre informasjon fra Revit til henholdsvis Ecotect og IES VE. Det ble valgt å teste overføringen av den informasjonen som er mest relevant for å utføre analyser: Lokasjon, orientering, bygningstype, geometri til romavgrensende ater, navn til rom, romvolum, bygningsmaterialer og objekttypene tak, gulv, etasjeskiller, yttervegg, innervegg, dør, søyle og vindu. Det ble kun benyttet standard objekter i Revit under testingen. Informasjonsoverføringen er kun testet fra Revit til analyseapplikasjonene, da ingen av analyseapplikasjonene kan eksportere informasjon til et format som kan lastes inn i Revit. 4

19 1.4 Metodikk Fagstudie Gjennom faget TKT4505 Objektmodellering har grunnleggende forståelse av teori rundt objektmodellering blitt tilegnet. Litteraturstudium For å få en grunnleggende forståelse av BIM og interoperabilitet har et litteraturstudium blitt benyttet. I all hovedsakelighet har relevant litteratur blitt funnet via søkemotorene BIBSYS og BIBSYS ble benyttet for å nne bøker innenfor temaene BIM og miljøvurdering. Google sin søkemotor ble benyttet for å nne relevant informasjon om ulike kommunikasjonsmodeller, kommunikasjonsformatene IFC og gbxml og applikasjonene Autodesk Revit, Ecotect Analysis og IES VE. Testing av applikasjoner For å vurdere interoperabiliteten mellom applikasjonene ble modeller laget i Revit konvertert til kommunikasjonsformatene IFC og gbxml, for deretter å bli importert i henholdsvis Ecotect og IES VE. Deretter kunne informasjonen i disse modellene sammenlignes med informasjonen i den originale modellen, for å vurdere hvilken informasjon som ble overført og hvilken som falt bort under prosessen. I utgangspunktet skulle COWI sin modell av Ny Barneavdeling for Ålesund Sykehus være referansemodell, men dette ble valgt bort. Isteden ble det laget en rekke enkle modeller i Revit. Dette ble gjort for å ha bedre kontroll på hva slags informasjon som var i hver modell, noe som gjorde prosessen med å kontrollere hva slags informasjon som ble overført til analyseapplikasjonene enklere. I tillegg var det behov for å lage egne modeller for å kunne teste interoperabiliteten mellom applikasjonene ved spesialtilfeller, som for eksempel modeller som inneholdt tak og vegger med særegen geometri. 1.5 Disposisjon Masteroppgavens videre oppbygning er strukturert på følgende måte: 5

20 Kapittel 2 Kapittel 2 gir en kort innføring i BIM. Dette omfatter en beskrivelse av objektmodellering, en presentasjon av BIM sin utvikling, en vurdering av hva BIM faktisk er og til slutt en denisjon av BIM presentert. Kapittel 3 Kapittel 3 beskriver ulike kommunikasjonsmåter, og presenterer utfordringer og muligheter ved å bruke disse i byggenæringen. I tillegg blir IFC-modellen og gbxml-formatet nærmere omtalt. Kapittel 4 I Kapittel 4 blir applikasjonene Autodesk Revit, Ecotect Analysis og IES VE presentert. Presentasjonen gir en innføring i hvilke funksjoner applikasjonene har, hvordan de fungerer i bruk og hvordan import- og eksport av modeller utføres. Kapittel 5 Kapittel 5 omhandler selve testingen av applikasjonene. Først i kapittelet beskrives de grepene som ble gjort i Autodesk Revit for å legge til rette for eksporteringen av modellene. Videre presenteres COWI sitt byggeprosjekt Ny Barneavdeling ved Ålesund Sykehus", og hvorfor dette ble valgt bort som referansemodell. Til slutt beskrives testene som ble gjennomført. Kapittel 6 I Kapittel 6 blir resultatene fra testene presentert og oppsummert. Kapittel 7 Kapittel 7 omfatter anbefalingene til COWI. Kapittel 8 Kapittel 8 gir en konklusjon til oppgaven og en presentasjon av forslag til videre arbeid. 6

21 2 Building Information Model/Modelling (BIM) 2.1 Generelt Dette kapittelet gir en kort innføring i Building Information Model/Modelling (BIM); det innbefatter en presentasjon av BIM sin utvikling og struktur og en denisjon av hva BIM er. 2.2 Objektmodellering Historie Ole Johan Dahl og Kristen Nygaard utviklet på 1960-tallet programmeringsspråket SIMulation LAnguage (SIMULA). Språket skulle være intuitivt og anvendelig, og skulle gi datamaskiner nok informasjon til å generere tilhørende simuleringsprogrammer for selv svært komplekse systemer. Med SIMULA ble grunnlaget lagt for objektorientert programmering slik vi kjenner det i dag [Haraldsen, 1999]. Den kommersielle utviklingen av objektmodellering i hjelpemidler for byggenæringen ble først utviklet på 1980-tallet. Graphisoft ArchiCAD ble introdusert i 1984 som et av de første programmene i næringen basert på objektorientert modellering [Graphisoft, 2010]. Denne type programvare slo likevel ikke igjennom før senere, siden programvaren var svært ressurskrevende for datidens datama- 7

22 skiner. Isteden var det mindre ressurskrevende, entitetsbasert programvare som for eksempel Autodesk AutoCAD og Bentley MicroStation som ble foretrukket i bransjen. Forskjellen mellom entitetmodellering og objektmodellering er at en entitet kun inneholder data, mens et objekt i tillegg inneholder operasjoner [Hansen, 2006]. Etter hvert som utviklingen innen Informasjonsteknologi (IT) ga billigere og bedre maskinvare kom objektbasert programvare på banen igjen, og utviklingen skjøt fart på 1990-tallet [Eastman, 1999]. Etter årtusenskiftet tilbød ere og ere leverandører objektbasert programvare; Revit Technology Corporationsenere kjøpt opp av Autodesklanserte Revit i 2000, Bentley Building Information Modelling ble lansert i 2002 og GraphiSoft lanserte ArchiCAD 9 i 2004 (se Figur 2.1). Figur 2.1: Utvikling innen BIM [Howard and Bjørk, 2008] Konsept Programmeringsspråket SIMULA introduserte komponentbegrepet prosess senere kalt objekt som inneholdt både data og operasjoner. Ved hjelp av taksonomi kunne objekter med lik struktur på data og operasjoner bli delt inn i klasser. Gjennom arv via klassehierarki kunne komponentbegreper for første gang bli generalisert og spesialisert [Haraldsen, 1999]. I dag omtales denne type dataprogrammering som klasseorientert Objekt Oriented Programming (OOP). Modellering forut for programmering har blitt standardisert via modelleringsspråket Object Modeling Technique (OMT) (se 8

23 Figur 2.2) og senere Unied Modeling Language (UML). OMT består av de tre aspektmodellene objektmodell, dynamisk modell og funksjonsmodell [Syvertsen, 2009]. OMT Objektmodell Dynamisk modell Funksjonsmodell Assosiasjon Klasse Tilstand Hendelse Transformasjon Flyt Figur 2.2: Objektmodell av OMT [Syvertsen, 2009] En klasseorientert objektmodell deneres av følgende aspekter [Abdalla and Powell, 1995]: Entitet En entitet er en fysisk eller konseptuell ting, representert gjennom en samling dataverdier. Entiteter representeres av objekter. Objekt Objekter er entiteter som kombinerer attributter; dataverdier som beskriver objektets tilstand, operasjoner; prosedyrer og metoder som beskriver objektets oppførsel og identitet; gir objektet en unik eksistens blant alle andre objekter. Objekter kommuniserer ved å sende meldinger til hverandre. Ethvert objekt i en klasseorientert objektmodell må tilhøre en klasse, og betraktes som en forekomst av den klassen. Klasse En klasse beskriver et sett objekter med like egenskaper, føringer og operasjoner. Hver klasse denerer et sett attributter, som beskriver egenskaper og tilstander til forekomster i klassen. Klasser er inndelt i et klassehierarki av superklasser og underklasser. En underklasse kan arve attributter og operasjoner fra en superklasse. Anvendelse Ved bruk i byggenæringen består objektbaserte modeller av parametriske objekter som vegger, vinduer og dører. Disse objektene er knyttet til en database hvor man kan hente ut plantegninger, detaljskisser, seksjoner og så videre. Vegger og dører kan bli endret i relasjon til hverandre og fungerer sammen som funksjonelle enheter. Detaljer kan linkes til sin posisjon i modellen og endringer gjort i en 9

24 komponent blir oppdatert i alle tegninger [Seletsky, 2004]. Denne parametriske fremstillingen gjør modellen interaktiv og selvanalytisk, noe som er positivt for designprosessen [Chris I. Yessios, 2004]. Programvare brukt i byggenæringen som er basert på objektbaserte modeller går inn under fellesbetegnelsen BIM. 2.3 Hva er BIM Oppfatningen av hva BIM er varierer blant aktører i byggenæringen. Noen ser på BIM som et rent 3D-visualiseringsverktøy, andre som et CAD-verktøy, og relativt få som en prosess der informasjon bearbeides på en objektorientert måte. Dette kan skape misforståelser og feilaktige forventninger og krav, som videre fører til skuelse eller konikter [Jongeling, 2008]. I realiteten kan BIM ha minst to forskjellige betydninger, avhengig av hvilket perspektiv man har. Prosessperspektiv Konseptet BIM har eksistert i en eller annen form så langt tilbake som på 70- tallet. Professor Charles Eastman ved Georgia Institute of Technology var en av de første som konkretiserte begrepet, da under navnet Building Product Model [Conradie, 2009]. I denne sammenhengen var BIM en prosess, mer enn en anvendelse av ny IT. Byggeindustrien har tatt i bruk en rekke generelle teknologiske hjelpemidler etterhvert som den har blitt utviklet; det er eksempelvis nå blitt vanlig med digitalisering og elektronisk distribusjon av dokumenter, det eksisterer digitale verktøy for tid- og kostnadsplanlegging og grask visualisering av byggeprosjekter. BIM skiller seg ut i denne rekken ved å være en ny tilnærming til hvordan man designer og prosjekterer bygninger på, mer enn en implementering av ny IT [Autodesk, 2007]. BIM er med andre ord en ny måte å organisere og strukturere informasjon i byggeprosjekter på; prosessen går ut på å samle all geometrisk informasjon og funksjonelle krav, og å sette sammen informasjonen for å lage en innbyrdes sammenhengende beskrivelse av byggeprosjektet gjennom hele dets livsløp [Eastman, 1999]. Hensikten med denne omstruktureringen er å legge til rette for bedre samarbeid mellom mennesker. Å samle all informasjon om et bygg i en modellserver gir muligheter for et tettere samarbeid mellom aktørene i prosjektet, og resultatet kan bli at man kommer frem til den beste løsning ved å ta hensyn til alle fagene. En slik modell er også mer eektiv enn den klassiske 10

25 måten å arbeide på, da man kan dra nytte av den informasjonen som allerede er lagt inn i modellen, og at ere mennesker kan arbeide med modellen samtidig. Nøkkelen for å løse vanskelige og komplekse utfordringer ligger ikke i IT alene, men i å legge til rette for bedre menneskelig samarbeid ved hjelp av datamaskiner [Engelbart, 2003]. Teknisk perspektiv Selve fagordet BIM ble først tatt i bruk av Phil Bernstein, visepresident i Autodesk, for å beskrive en type programvare innen byggenæringen. Ordet ble etter hvert en akseptert neologisme i byggebransjen, og utkonkurrerte andre forslag som single building model, virtual building model, integrated project modeling og project lifecycle management [Laiserin, 2002]. For å få en forståelse Figur 2.3: Utviklingen av CAD [Graphisoft, 2009] av hva BIM-programvare er, kan det være hensiktsmessig å se på utviklingen som har foregått innen CAD (se Figur 2.3). Det hele begynte med bruk av digitale tegnebrett til å lage modeller, fremfor å gjøre dette med håndtegninger. Ved å digitalisere tegningene kunne man raskere gjøre endringer på modellene, man kk bedre nøyaktighet og arbeidsprosessen gikk raskere ved at man kunne kopiere lik geometri. Etter hvert ble det også utviklet CAD-programmer som kunne fremstille 3D-modeller. I første omgang ble dette kun benyttet for å kunne lage en visuell fremstilling av bygg digitalt, slik at man slapp arbeidet med å lage fysiske modeller. Ved å integrere mer informasjon enn bare geometriske verdier i modellene har man gått over fra å bruke modellene kun for plantegnin- 11

26 ger og visualisering til å ta modellen i bruk på en rekke andre områder. Denne modellen, som består av objekter som beskriver komponentene og funksjonene til et bygg, betegnes som BIM. BIM omtales også som en virtuell bygning, eller en bygningssimulering. BIM er informasjon om hele bygget og et komplett sett med designdokumenter, lagret i en integrert database [Krygiel and Nies, 2008]. All informasjon kan være parametrisk og sammenkoplet. Dette betyr at en endring i et objekt i modellen automatisk forplanter seg i hele modellen. Ved å legge til dimensjonene tid og kostnad får man en femdimensjonal modell. Mengder, plantegninger, kostnadsanalyser og tidsplaner kan hentes direkte ut av modellen, og man kan bruke modellen til å dimensjonere bæresystemer, utføre miljøberegninger og å sjekke at elementer i bygget ikke kolliderer med hverandre. Denne bygningsinformasjonsmodellen kan alle partene i et byggeprosjekt samarbeide om å bruke. Ved hjelp av diverse programvare koblet sammen via interoperabilitet, kan aktørene bruke ulik programvare, relevant for sitt fagfelt [Graphisoft, 2009]. Mange CAD-verktøy slik som Revit, Archi- CAD, DDS, AutoCAD ADT, Bentley og Tekla tilbyr i dag BIM-funksjonalitet [Norconsult, 2010]. Denisjon Det eksisterer per dags dato ingen entydig og presis denisjon for hva BIM er [Architosh, 2010]. Dette har ført til at BIM lett blandes sammen med teknologi som parametrisk modellering og interoperabilitetsinitiativer, og det skaper forvirring. Uten en entydig og presis denisjon kan man ikke identisere grensene og dermed manglene til BIM, og målrettet jobbe for å forbedre disse manglene. I tillegg er det utfordrende for bedrifter som ønsker å ta i bruk BIM å vite hva dette i sin fulle forstand innebærer. For denne oppgavens formål har følgende denisjon av General Services Administration (GSA) Public Buildings Service (PBS) Oce of the Chief Architect (OCA) blitt valgt for BIM: Building Information Modeling is the development and use of a multi-faceted computer software data model to not only document a building design, but to simulate the construction and operation of a new capital facility or a recapitalized (modernized) facility. The resulting Building Information Model is a data-rich, object-based, intelligent and parametric digital representation of the facility, from 12

27 which views appropriate to various users' needs can be extracted and analyzed to generate feedback and improvement of the facility design. [GSA PBS OCA, 2007] 2.4 Oppsummering Fordeler med å benytte BIM i byggeprosjekter som ofte trekkes frem er muligheten til å visualisere bygget og utføre kollisjonskontroller for å minimere antall feil i prosjekteringen. Det at BIM kan benyttes til å visualisere et bygg for lettere å kunne oppdage feil er vel og bra, men det er ikke en dekkende beskrivelse av BIM sitt potensiale. Den viktigste funksjonen til BIM er å legge til rette for bedre menneskelig samarbeid i byggebransjen. Dette er en nøkkelfaktor for å oppnå bedre indre og ytre eektivitet, som vil gi høyere verdiskapning for aktørene og kundene i prosjektet [Eikeland, 2000]. Med BIM kan man oppnå bedre eektivitet ved at aktører kan jobbe parallelt og at informasjon lagt inn av én aktør kan benyttes av alle andre aktører i det videre arbeidet. Man kan oppnå et bedre resultat på grunn av at man lettere kan vurdere ulike alternativer og iterere seg frem til et design med ønsket funksjonalitet og kvalitet. Feil kan unngås, slik at endringer og forsinkelser i byggefasen blir redusert. De utførende får en lettere jobb da plantegninger og skisser er mer nøyaktige og detaljerte. Listen er lang, men disse positive eektene er ikke et direkte resultat av at man benytter BIM-applikasjoner i byggeprosjektet. Det er derimot et resultat av at aktørene i byggeprosjektet samarbeider bedre. For å få Developer Building Owner Contractor Facility Manager Quantity Surveyor/ Cost Planner Users BIM MODEL Product Manufacturers Architect/ Interior Designers Government Agencies Building Certifier Engineer Information Providers Figur 2.4: Informasjonsyt i BIM til et godt samarbeid er man avhengig av god kommunikasjon [Eikeland, 2000]. 13

28 Med hensyn til BIM fordrer god kommunikasjon at alle aktørene arbeider opp mot en felles modell (se Figur 2.4). Dette kan gi en pålitelig informasjonsutveksling, og sikre at alle arbeider med gjeldende modell [Eastman et al., 2008]. Gjennomføringen av dette avhenger av at alle applikasjonene som brukes av de ulike aktørene klarer å kommunisere seg i mellom, via en modellserver. Ulike kommunikasjonsmåter og overføringsmåter omtales nærmere i Kapittel 3. 14

29 3 Interoperabilitet 3.1 Generelt Opp gjennom tiden har mangfoldet av ulike typer bygg og teknologien som inngår i disse byggene bare økt. Som en naturlig reaksjon på dette har byggeindustrien blitt mer fragmentert og delt seg inn i aktører med ulik spisskompetanse [Krygiel and Nies, 2008]. I et byggeprosjekt vil disse aktørene nødvendigvis ha ulike behov, noe som har ført til utviklingen av en rekke ulike applikasjoner. Når man skal jobbe sammen om en modell i et byggeprosjekt, må disse programmene kunne kommunisere. Etter hvert som ere og ere BIM-applikasjoner blir utviklet har behovet for en standardisert måte disse applikasjonene kan snakke sammen på kommet tydelig frem. Det eksisterer mange alternative måter å overføre informasjon mellom ulike applikasjoner på. Dette kapittelet beskriver ulike kommunikasjonsmåter og presenterer utfordringer og muligheter ved å bruke disse i byggenæringen. I tillegg blir IFC-modellen og gbxml-formatet nærmere omtalt. 3.2 Overføringsformater Overføring av informasjon mellom ulike applikasjoner kan deles inn i re grupper [Eastman et al., 2008]: Proprietære koblinger Proprietære koblinger utviklet og vedlikeholdt av programleverandører for at to applikasjoner skal kunne kommunisere seg imellom. 15

30 Proprietære lformater Proprietære lformater utviklet av programleverandører for bruk til sine programmer. Innenfor byggeindustrien er Data exchange Format (DXF), utviklet av Autodesk, et utbredt proprietært lformat. Åpne datamodellformater Åpne overføringsformater basert på standardiserte bygningsmodeller som overfører geometri, materialegenskaper, objektegenskaper, funksjoner og koblinger. Cimsteel Integration Standard version 2 (CIS/2) standard for produksjon og ingeniørarbeid innenfor konstruksjonsstål og IFC standard for bygningsplanlegging, design og konstruksjon er eksempler på åpne datamodellformater. Extensible Markup Language (XML)-baserte formater XML er et sett med regler for hvordan man skal kode digitale dokumenter. XML-skjemaer brukes for overføring av data mellom applikasjoner. Eksempler på XMLbaserte formater innenfor byggeindustrien er aecxml og gbxml. 3.3 Kommunikasjon via loverføring Med denne metoden å kommunisere på lagrer senderen modellen i en l, som så sendes ved hjelp av elektronisk distribusjon til en mottager. Hvis de to applikasjonene ikke benytter samme lformat må informasjonen eksporteres av avsender og importeres av mottager (se Figur 3.1). IFC og gbxml er eksempler på formater som kan brukes under denne prosessen. Avhengig av hvilket format som brukes og om applikasjonene støtter det, kan kommunikasjonen foregå begge veier. Denne typen kommunikasjon ble benyttet under testingen av applikasjonene Autodesk Revit, Autodesk Ecotect og IES VE, som er beskrevet senere i oppgaven (se Kapittel 5). Utfordringer med denne kommunikasjonsmåten beskrives nærmere i Avsnitt 3.5 og 3.6. EKSPORT IMPORT Modelleringsapplikasjon Analyseapplikasjon Figur 3.1: Kommunikasjon via loverføring 16

31 3.4 Kommunikasjon via database-server Generell beskrivelse av en database-server En database-server lagrer som navnet tilsier data internt i en database og distribuerer informasjon til klientapplikasjoner via kontrollerte grensesnitt. Revit har for eksempel utviklet et eget verktøy ved navnet Revit Database (RDB)- Link for å overføre data til og fra en database. RDB-Link støtter relasjonsdatabaser, som for eksempel MS Access og Structured Query Language (SQL)- servere [Autodesk, 2010a]. Det er også utviklet generelle databasedrivere som applikasjoner kan benytte for å kommunisere med databaser; ved hjelp av Java Database Connectivity (JDBC) kan Java-baserte programmer hente og sende informasjon fra en rekke ulike typer databaser [Oracle Corporation, 2010]. Open Database Connectivity (ODBC) et Application programming interface (API) som streber etter å bli uavhengig av programmeringsspråk, operativsystemer og databasesystemer [Idehen, 1993] åpner opp for at ulike applikasjoner skal kunne snakke sammen via en felles database. Databasen kan være relasjonsbasert som for eksempel en SQL-database eller objektbasert. Sistnevnte er lite brukt, men kan være aktuell å bruke da de har stor lagringskapasitet og overføringskapasitet; det eksisterer objektdatabaser som inneholder 1000 Terrabytes og som har en overføringshastighet på 1 Terrabyte i timen [Becla and Wang, 2005]. Ulike scenarioer for kommunikasjon via en BIM-server Her presenteres ulike scenarioer for hvordan kommunikasjon via en BIM-server kan foregå. Bruk av applikasjoner fra én leverandør I dette scenarioet har én programvareleverandør oppnådd monopol på markedet og tilbyr alle nødvendige applikasjoner som er nødvendig i et byggeprosjekt. Applikasjonene har ulike funksjoner ut ifra hvilket fagfelt de er beregnet for, men denerer og strukturerer informasjon på samme måte og er basert på samme forretninger, begreper, basisoperasjoner og dataaksessmetoder (se Figur 3.2). Dermed vil all informasjon i en BIM være forståelig for alle applikasjonene, og de kan kommunisere seg i mellom uten informasjonstap. Alle prosjektdeltagerne henter ut informasjon fra en server med en database for eksempel en relasjonsdatabase, eller en objektdatabase hvor BIM er lagret, ved hjelp av proprietære 17

32 koblinger. Her vil interoperabiliteten være god, men dette scenarioet vil likevel ikke være gunstig for forbrukeren; siden programleverandøren har monopol vil lisensprisene være høye, og uten konkurranse er drivkraften for å produsere bedre og mer brukervennlige applikasjoner falt bort. Monopolloven sørger for at et slikt scenario blir forhindret, noe blant annet Microsoft har erfart [Svendsen, 2007]. Applikasjon A Applikasjon B Applikasjon N Database Figur 3.2: Kommunikasjonsmåte med én leverandør Mellomvare Mellomvare er programvare som kjører på delt eller dedikert maskinvare. Ved hjelp av PlugIn-programvare kobler mellomvare ulike applikasjoner sammen slik at de kan hente ut informasjon fra hverandres databaseservere [Krakowiak, 2003] (se Figur 3.3). PlugIn-programvaren består av et forretningslag som inneholder forretningsbegreper og basisoperasjoner samlet under begrepet forretningslogikk og et dataaksesslag som inneholder dataaksessmetoder. Disse lagene er hentet ut fra de ulike applikasjonene. Et eksempel på et slikt konsept er OpenSpirit, som ble utviklet slik at ulike applikasjoner brukt i oljebransjen skulle kunne kommunisere seg i mellom [OpenSpirit, 2010]. Utviklingen av OpenSpirit ble støttet av Schlumberger, Shell og Chevron ved hjelp av nansiering og av at bedriftene delvis åpnet opp sine forretningslag og dataaksesslag til OpenSpirit. OpenSpirit kunne dermed utvikle sin programvare for å koble applikasjonene fra de ulike leverandører sammen [Simensen, 2010]. Ved å bruke mellomvare unngår man synkroniseringseekter og man åpner opp for at applikasjoner med nye funksjoner og bedre brukervennlighet kan 18

33 utvikles og bli koblet til databasene. Applikasjon A Applikasjon B Applikasjon N Middleware Database A Database B Database N Figur 3.3: Kommunikasjon via mellomvare Kommunikasjon via åpne datamodellformater Med denne metoden henter og sender applikasjonene informasjon til og fra databasen ved hjelp av et åpent datamodellformat. Før informasjon kan sendes må applikasjonen sitt eget format eksporteres til det åpne datamodellformatet, og informasjonen som blir hentet fra databasen må importeres fra det åpne datamodellformatet til applikasjonens eget format (se Figur 3.4). Et eksempel på et slikt format er IFC, som omtales nærmere i Avsnitt 3.5. Her beskrives også en rekke utfordringer med et slikt system. 19

34 Applikasjon B IMPORT EKSPORT EKSPORT EKSPORT IMPORT IMPORT Applikasjon A Database Applikasjon N Figur 3.4: Kommunikasjon via åpne datamodellformater Interoperabilitet utviklet av programvareleverandørene I dette scenarioet har en gruppe programleverandører delt kildekodene med hverandre og samarbeidet for å utvikle felles overføringsformater, felles denisjoner på informasjon og felles protokoller slik at deres applikasjoner skal kunne kommunisere seg i mellom. Applikasjonene innehar samme grunnprinsipper for hvordan de denerer informasjonen, vet hvordan de kan hente ut og putte inn informasjon i den eksterne databasen og tolker informasjonen på lik måte. Det er dog ikke gitt at dette samarbeidet inkluderer alle leverandører, og utenforstående vil ikke ha tilgang til hverken kildekodene eller den utviklede interoperabilitetsteknologien. En stor forskjell fra dette scenarioet og de overnevnte er at programleverandørene har samarbeidet direkte og åpent. Dette gir et mye bedre utgangspunkt for faktisk å oppnå interoperabilitet. Viljen til å etablere et slikt samarbeid er dog ikke alltid tilstede, da dette innebærer at programvareleverandørene risikerer å miste noe av sitt konkurransefortrinn. Programleverandørene vil miste eventuelle synkroniseringseekter, og det blir enda viktigere å fokusere på brukervennlighet og funksjonalitet for å tiltrekke forbrukere. Fri Programvare Dette scenarioet er i store trekk likt med interoperabilitet utviklet av programvareleverandørene. Den klare forskjellen er at kildekodene til applikasjonene er tilgjengelig for allmennheten, og ikke bare for utvalgte samarbeidspartnere. Med andre ord kan alle programvareleverandører som ønsker det tilpasse sine appli- 20

35 kasjoner slik at de blir interoperabile med den frie programvaren. Fordelen med kommunikasjon via en database-server BIM-applikasjoner bruker vanligvis digitale ler for å laste inn og lagre BIMdata. Det er ikke uvanlig at bedrifter lagrer disse lene på en server, slik at informasjonen kan være tilgjengelig på forskjellige steder og for ere brukere. Når det i dette avsnittet snakkes om kommunikasjon via en server er det dog ikke denne type kommunikasjon det er snakk om, men derimot kommunikasjon via en server hvor informasjon lagres i en database. Å lagre informasjonen i en database-server har en rekke tekniske og praktiske fordeler. Alle applikasjonene henter og sender informasjon fra den samme digitale modellen, noe som legger til rette for samprosjektering og sikrer at alle brukerne arbeider på gjeldende modell [Eastman et al., 2008]. En annen fordel med database-servere er at de kan være koblet opp mot andre eksterne datakilder. Hvis for eksempel en leverandør endrer prisen på bygningsmaterialer kan kostnaden til bygget automatisk bli oppdatert hvis serveren er koblet opp mot leverandørens server. Kommunikasjon via en database-server reduserer også utfordringene tilknyttet interoperabilitet. Kommunikasjonen mellom applikasjonene og serveren består av enkle transaksjoner for å hente ut og putte inn informasjon. Applikasjoner sender spørringer til serveren for å få den informasjonen som er relevant, og trenger ikke å kunne tolke all informasjon i den digitale modellen. På grunn av dette er prosessen med å gjøre applikasjonene interoperabile med serveren langt enklere enn å gjøre applikasjonene direkte interoperabile med hverandre. Hvis to frittstående applikasjoner som kommuniserer via lformater skal være interoperabile må de kunne importere all informasjonen i datalen, og i tillegg kunne eksportere all informasjon. Selv for enkle tekstdokumenter har dette vært en vanskelig oppgave å løse [Shah and Kesan, 2008], og oppgaven er desto vanskeligere for BIM. 3.5 IFC Innledning I tilknytning til denne oppgaven ble IFC-modellen brukt for å overføre informasjon fra Revit Architecture til Ecotect Analysis. Dette avsnittet ser nærmere på 21

36 denne modellen. Bakgrunn 11. juli 1984 ble det første møtet til ISO TC 184/SC4 en tekniske komité for standardisering av industriell data underlagt ISO[ISO, 2010] avholdt. Formålet med møtet var å etablere en internasjonal standard for et nøytralt format ulike industrier kunne bruke for å lagre informasjon fra en databehandlet produktmodell tapsfritt. Resultatet av denne prosessen ble ISO 10303, bedre kjent som STEP [Kemmerer, 1999]. STEP er et sett med standarder som integrerer både IT- og produksjonsindustrien sine behov innen dataoverføring [Kemmerer, 1999]. Tidlige forsøk på standarder for byggenæringen var General AEC Reference Model (GARM) (ISO TC 184/SC4/WG1 doc ) og AEC Building System Model (ISO TC184/SC4/WG1 Doc. N363). Etter hvert tok International Alliance for Interoperability (IAI) over STEP sitt arbeid med utviklingen av interoperabilitetsstandarder for byggenæringen [Howard and Bjørk, 2008]. IAI er en internasjonal organisasjon, etablert i Asia, Australia, Europa og Nord-Amerika. Organisasjonen er prottfri og ble stiftet i Hovedmålet til organisasjonen har vært å utvikle innovative konsepter som forbedrer måten man deler informasjon på under et byggeprosjekt. IAI ser klare fordeler ved bedre interoperabilitetog dermed bedre informasjonsyti byggeprosjekter. Dette gir prosjektdeltagere muligheten til å dele prosjektinformasjon på tvers av disipliner og tekniske applikasjoner, som igjen gir grobunn for bedre samarbeid og bedre gjennomførte prosjekter [Haefele, 2008]. Utvikling For å realisere mulighetene for interoperabilitet har IAI jobbet for å denere, fremme og publisere spesikasjoner for deling av data. Resultatet av denne prosessen er IFC, en datamodell for deling av data på tvers av ulike applikasjoner brukt i byggesektoren, samlet under navnet BIM. IFC supports BIM as a computable representation of the physical and functional characteristics of a facility and its related project/lifecycle information using open industry standards to inform business decision making for realizing better value [buildingsmart, 2010c]. 22

37 De ansvarlige for utviklingen og vedlikeholdet av IFC er Model Support Group (MSG) [buildingsmart, 2010a]. Mange av STEP sine utviklere har bidratt i MSG sitt arbeid med utformingen av IFC. IFC-modellen er i likhet med STEP basert på datamodelleringspråket EXPRESS og bruker mange av de samme denisjonene. Den første versjonen av IFC, versjon 1.0, ble utgitt i 1997 [Khemlani, 2004]. Etter dette har det kommet ut en rekke nye versjoner, hvor den siste i rekken er IFC 2x3-TC1 fra Det er denne versjonen som brukes av Revit Architecture og Ecotect Analysis. Utviklingen av IFC 2x4 er allerede i gang [buildingsmart, 2010c]. 23

38 Konsept IFC-modellen er utformet som et generelt, abstrakt rammeverk; dette er gjort for at modellen skal kunne brukes av est mulig applikasjoner og behandle all type bygningsinformasjon. For å oppnå denne generaliteten har MSG benyttet seg av at datamodelleringsspråket ISO-STEP EXPRESS er basert på entiteter. Dette er passive data med indirekte relasjoner som må leses og tolkes av applikasjonene. Applikasjoner kan produsere forekomster i en BIM ved å koble entiteter sammen via indirekte relasjoner [Eastman et al., 2008]. Figur 3.5: IFC sin systemarkitektur [MSG, 2010]. Systemarkitektur-diagrammet (se Figur 3.5) skildrer oppbygningen av IFC, inndelt i re nivåer; ressursnivå, kjernenivå, interoperabilitetsnivå og domenenivå. Hvert nivå er videre inndelt i ressursskjemaer, som igjen inneholder EXPRESS elementer som entiteter, enumereringer, typer og funksjoner. Hver enkelt entitet kan kun referere til andre entiteter på likt, eller lavere nivå enn seg 24

39 selv. Dette gjør modellen lett å vedlikeholde og utvide, og muliggjør gjenbruk av entiteter i høyere lag. I tillegg kan modellen lettere implementeres i ulike fagspesikke applikasjoner, ved at det tydelig fremgår hvilke entiteter som er relevante for de ulike fagene [Eastman et al., 2008]. Under følger en presentasjon av de re nivåene i IFC-modellen [Liebich and Wix, 2000]: Ressursnivå Ressursnivået består av grunnentitetene til IFC-modellen. Disse entitetene representerer de fysiske eller konseptuelle, generiske egenskapene til en bygning og dens byggeprosess. Entitetene blir gruppert inn i ressursskjemaer; for eksempel materialegenskaper, kostnad, geometri og topologi. Hvis en klasse i domene-, interoperabilitets- eller kjernenivået trenger å bruke for eksempel en geometrientitet vil den referere til ressursskjema den tilhører. Entitetenes eksistens avhenger av at de blir brukt i forekomster i høyere lag. Kjernenivå Kjernenivået danner grunnstrukturen til IFC-modellen. Nivået er delt inn i Kernel og Core Extensions. Kernel danner fundamentet til kjernenivået og denerer hvordan strukturen til skjemaene i IFC-modellen skal bygges opp. Core Extensions utvider og spesialiserer konseptene de- nert i Kernel, Product Extension denerer abstrakte bygningskomponenter som rom, bygningstype og bygningselement. Control- og Process Extension denerer prosess- og kontrollkonsepter som oppgaver, prosedyrer og arbeidsplaner. Interoperabilitetsnivå Interoperabilitetsnivået består av ressursskjemaer som denerer klasser eller skjemaer som brukes innen ere domenemodeller. Ved hjelp av disse skjemaene kan modeller fra applikasjoner tilhørende ulike fagretninger kobles sammen i kjernenivået til IFC-modellen. Det er i ressursskjemaene i dette nivået man nner denisjoner på de vanligste bygningsentitetene; Shared Building Elements-skjemaet består av entiteter for bjelker, søyler, vinduer, vegger og så videre, Shared Building Services Elements-skjemaet består av entiteter for akustikkegenskaper, veskeytegenskaper, ytkontroll og så videre og Shared Facilities Elements-skjemaet inneholder entitetsdenisjoner som for eksempel bruker og møbler. Domenenivå Domenenivået er det øverste nivået i systemarkitekturen til IFCmodellen. Dette nivået inneholder entiteter som er spesikke for prosesser eller applikasjoner, gruppert ut i fra de ulike fagretningene innen byggeindustrien. En viktig funksjon i domenenivået er å sørge for at eksterne 25

40 egenskapssett (attributter som har ulik betydning i de ulike fagretningene) blir implementert korrekt. Systemarkitekturdiagrammet brukes for å systematisere entitetene i IFCmodellen, og er basert på systemarkitekturen til ISO STEP. En forekomst i en BIM vil forekomme i slutten av en rekke nedarvede entiteter. Forekomsten vil bestå av attributter og relasjoner nedarvet fra hvert enkelt nivå. En bjelke vil for eksempel arve fra følgende entiteter: IfcRoot; IfcObjectDenition; IfcObject; IfcProduct; IfcElement; Ifc- BuildingElement; IfcBeam; Se Tillegg A for en nærmere beskrivelse av entitetene som blir arvet. Overføring mellom applikasjoner Prosessen med å overføre en BIM fra en applikasjon til en annen via en IFCmodell kan deles inn i re faser (se Figur 3.6) [Eastman et al., 2008]. Først vil applikasjonen som sender informasjon konvertere informasjon fra sin egen datastruktur om til ekvivalente IFC-forekomster. Informasjonen blir deretter omgjort til ren tekst i en prosess standardisert gjennom ISO-STEP Part-21. Den mottakende applikasjonen tolker så denne informasjonen og konverterer den til IFC-forekomster den forstår. Forekomstene blir så omgjort til informasjon basert på sin egen datastruktur. Applikasjon som sender Applikasjon som mottar Eksport Oversettelse Import Oversettelse Datastruktur P-21 Oversettelse P-21 Oversettelse Datastruktur Figur 3.6: Dataoverføring via ISO-STEP Part-21 26

41 Utfordringer Ved overføring via IFC-modellen kreves det re oversettelser (se Figur 3.6). Sammenlignet med kommunikasjon via en server hvor det kun er behov for en eller to oversettelser er dette en forholdsvis besværlig prosess. Tap av informasjon ved bruk av IFC-modellen kan oppstå under konvertering fra den sendende applikasjonens egen datastruktur til IFC-forekomster, og under den motsatte prosessen hos den mottagende applikasjonen. Dette kan skyldes mangler i applikasjonene eller IFC-modellen; det kan hende applikasjonen ikke evner å konvertere informasjonen om til riktige IFC-forekomster, eller at IFC-modellen ikke inneholder entiteter som sammensatt kan representere forekomstene fra applikasjonen. Slike svakheter kan løses ved å videreutvikle IFC-modellen eller applikasjonen, men dette er utfordrende. Det er lite trolig at en utenforstående leverandør av åpne datamodellformater fortløpende vil klare å ivareta kompatibiliteten etterhvert som nye applikasjonsversjoner lanseres. Applikasjoner blir stadig oppdatert, og selv om det jobbes med å få IFC-modellen til å overføre informasjon tapsfritt vil dette arbeidet alltid ligge ett skritt bak utviklingen av applikasjonene. Endringene i applikasjonene kan være store fra versjon til versjon, og det er ikke uvanlig at en ny versjon av en applikasjon ikke er kompatibel med den versjonen den erstattet. For eksempel kan ikke Revit 2009 åpne prosjekter laget i Revit 2010 [Autodesk, 2009a]. Det er også vanskelig for programvareutviklere å tilpasse sine modeller til å være kompatible med IFC-modellen. STEP-platformen krever et stort bibliotek av funksjoner for å kunne bli lastet inn i en applikasjon, og mange av disse bibliotekene er proprietære [Marsh, 2006]. Det at IFC-modellen skal være et nøytralt format og kunne behandle all type bygningsinformasjon fører også til utfordringer. For å kunne behandle all type bygningsinformasjon har IFC-modellen en stor generalitet og eksibilitet, noe som fører til tvetydighet [Marsh, 2006]. IFC-modellen støtter for eksempel ere ulike måter å beskrive geometri på. En vegg kan deneres ut i fra sin senterlinje og seksjonsprol, plane polygoner eller Extensible 3D Graphics (X3D)-geometri. Dette kan føre til problemer med overføring fra en applikasjon til en annen. Som et eksempel kan vi se på en sirkulær vegg som skal overføres fra applikasjon A til applikasjon B (se Figur 3.7). I A er veggens geometriske grunnate denert som en sirkel med senterlinje og radius. B denerer ikke sirkler på samme måte, men bruker Non Uniform Rational Basis Spline (NURBS) for å beskrive veggen sin geometri. Når så modellen blir sendt tilbake til A, som ikke 27

42 bruker NURBS, blir geometrien omdenert til et polygon som en tilnærming [Kalstveit, 1997]. Applikasjon A SIRKEL Nøytralt Format Applikasjon B NURBS POLYGON Figur 3.7: Avvik ved overføring mellom applikasjoner [Kalstveit, 1997]. IFC-modellens kompleksitet og generalitet er særlig et problem for analyseapplikasjoner. Analyseprogrammer støtter ikke nødvendigvis kompleks geometri og boolske operasjoner, som kreves for å tolke den geometriske informasjonen [Marsh, 2006]. BIM er, som omtalt i Kapittel 2, avhengig av god kommunikasjon for å fungere optimalt. Det er derfor viktig at applikasjonene kan kommunisere seg i mellom via en felles server med en database. IFC har klare begrensninger i forhold til å oppnå dette. IFC-modellen er i likhet med STEP basert på datamodelleringspråket EXPRESS, og bruker mange av de samme denisjonene. STEP er basert på en statisk overføring av informasjon da det ble utviklet for dataintegrering og ikke datainteroperabilitet og støtter ikke objektoppførsel [Howie et al., 1996]. IFC støtter med andre ord kun statiske datastrukturer men ikke objekter i datateknisk forstand og vil derfor ikke fungere optimalt for overføring av informasjon. 3.6 Green Building Extensible Markup Language (gbxml) Innledning Autodesk Revit overfører informasjon til Integrated Environmental Solutions (IES) Virtual Environment (VE) via gbxml-formatet. Dette avsnittet ser nærmere på dette formatet. 28

43 Bakgrunn Et annet initiativ for å imøtekomme behovet for interoperabilitet ble igangsatt av Green Building Studio Inc. (GBS), da med fokus på energimodelleringsprogrammer. For å gjøre detaljerte energianalyser var man tidligere avhengig av å ta ut mengder manuelt fra 2D tegninger. Ulempene med dette var mange; prosessen var tidkrevende, kostet mye og i store prosjekter kunne man fort regne feil og få unøyaktige mengder. Derfor ble antallet kalkyler og analyser ofte holdt på et minimum [Jongeling, 2008]. I prosjekter som bruker BIM kan modellen importeres i et energimodelleringprogram, og man kan bruke denne informasjonen for å utføre kalkyler og analyser. Prosessen er raskere og mer nøyaktig, og fører ofte til at man utfører ere analyser og oppnår et bedre resultat [Bourarsa, 2005]. For å legge til rette for en slik arbeidsprosess startet GBS med støtte fra California Energy Commission (CEC), Public Interest Energy Research (PIER) og Pacic Gas and Electric (PGE) utviklingen av gbxml. Utvikling GBS startet utviklingen av gbxml i desember 1999, og seks måneder senere ble det første gbxml-skjemaet publisert. Skjemaet har gjennomgått en rekke revisjoner etter dette, hvor den nyeste utgaven er versjon GBS ble et datterselskap av Autodesk i juni 2008, mens gbxml ble en ideell organisasjon under det osielle navnet Open Green Building XML Schema som forvaltes og utvikles med støtte fra en rekke BIM-programvareleverandører [gbxml, 2010]. Konsept XML er en videretuvikling av HyperText Markup Language (HTML), oppmerkingsspråket brukt for å vise informasjon i World Wide Web (WWW). HTML har et sett med etiketter og beskriver hvordan informasjon skal presenteres på WWW. I XML kan etikettene deneres av brukeren slik at man kan systematisere navngiving og kategorisering av data [Eastman et al., 2008]. Skjemaene for overføring lagres som ren tekst i for eksempel et regneark eller en database. gbxml er et XML-skjema spesielt utviklet for overføring av informasjon relevant for energianalyser og -simuleringer [Eastman et al., 2008]. Et så spesi- kt fokusområde for informasjonoverføring forenkler oppgaven med å denere hva slags informasjon som skal overføres, og på hvilken måte informasjonen skal representeres. For eksempel er kravene for geometrisk framstilling av modeller 29

44 i et analyseprogram at det klarer å representere romlig volum, solavskjerming og termiske soner. gbxml-formatet har valgt å bruke enkel polygongeometri til dette formålet, og alle modelleringsapplikasjoner som skal overføre modeller via gbxml-formatet må konvertere komponentene i modellen til denne typen geometri. Dette er en fordel for analyseapplikasjonene, da dette gir et enkelt og entydig lformat som er lett å implementere i applikasjonen. gbxml-skjemaet har evnen til å overføre følgende informasjon [Kennedy, 2010]: Plan polygongeometri Rektangulær polygongeometri Konstruksjoner og materialer Termiske- og emmisjonsegenskaper Kostnader i et livsløpsperspektiv Vinduer med solskjerming Ventilasjonsbehov Versjon- og endringshistorikk Vegetasjonstyper, lokasjon og vannforbruk Inltrasjon Transporteringstyper Belysning Værdata Internt og eksternt utstyr Energibruk Se Tillegg B for eksempel på oppbygningen av et gbxml-element. Utfordringer gbxml-formatet henter kun ut spesikk informasjon relevant for en analyseapplikasjon og gjør forenklinger i blant annet geometri under konverteringen. Dette er fordelaktig for analyseprogrammene, da formatet er enkelt å implementere og informasjonen er forståelig. Slike forenklinger fører dog til at konverteringen 30

45 ikke er en tapsfri prosess. Overføring via gbxml-formatet er derfor en enveiskommunikasjon fra modelleringsapplikasjonene til analyseapplikasjonene. Med andre ord må man gå inn i modelleringsapplikasjonen hvis man ønsker å gjøre endringer i modellen ut i fra de analysene som er blitt utført. 3.7 Sammenligning av IFC og gbxml IFC File Description, File name and file schema Units Organization, Person, owner history. Cartesian points, direction, dimensional exponents, shape representation Product definition and shape. Property value Predefined element parameters Material, layer set, Color. Units gbxml File Version Campus ID Location Area, Volume Building ID Description Shell Geometry ID A Cartesian Points, Co-ordinates. Shell Surface Shell Openings Space ID Surface ID Product name, version Platform Figur 3.8: Sammenligning av IFC-modellen [buildingsmart, 2010b] og gbxml-skjemaet [gbxml, 2010] Figur 3.8 viser hva slags informasjon som blir overført med IFC-modellen og gbxml-formatet. Hensikten med IFC-modellen er å lage en altomfattende, generisk beskrivelse av bygninger og byggingsprosesser som er så generell at den kan brukes av all BIM-programvare til å sende informasjon frem og tilbake tapsfritt. Modellen er basert på entiteter, som settes sammen for å danne forekomster. gbxml-skjemaet sin utvikling er på sin side kun tiltenkt overføring av informasjon til energimodelleringsprogrammer, og vil ikke være en tapsfri kommunikasjonsmåte som kan brukes begge veier. IFC-modellen er laget ut i fra et top-down design; man starter med å denere de mest generelle, overordnede bestanddelene som utgjør modellen, for så å fragmentere disse delene i stadig ere underkategorier helt til man er kom- 31 Side 1

46 met ned til grunnentitetene i modellen [Wikipedia, 2010]. Modellen kan spore opp alle endringer medført av at et element i modellen har blitt endret, og kan ideelt sett automatisk vedlikeholde sin egen integritet [Dong et al., 2007]. Modellen er svært omfattende og er derfor svært krevende å programmere og å implementere i programvare. IFC-modellen krever også mye lagringsplass, siden den inneholder så mye informasjon. gbxml-skjemaet er laget ut i fra et buttom-up design; man starter med en detaljert beskrivelse av de individuelle grunnelementene i systemet, som så samles til en taksonomi i overordnede grupper [Wikipedia, 2010]. Denne prosessen itereres helt til man har kommet til det øverste nivået i systemet. Dette gir et mindre komplisert skjema enn IFC-modellen. gbxml-skjemaet representerer geometrien til overater ved hjelp av to attributter: plan polygongeometri og rektangulær polygongeometri. Begge inneholder den samme geometriske informasjonen og brukes sammen for å dobbeltsjekke at geometrien som blir importert er korrekt. Kun rektangulær geometri kan representeres med disse to attributtene, men det er tilstrekkelig for å utføre energianalyser. IFC-modellen kan teoretisk sett representere alle typer bygningsgeometri. 32

47 4 Programvare 4.1 Generelt COWI har tatt i bruk BIM på en rekke byggeprosjekter og ønsker å teste ut to miljøberegningsprogrammer for å kartlegge hvor godt de fungerer med Autodesk Revit. I dette kapittelet presenteres Autodesk Revit og de to programmene Autodesk Ecotect og IES VE. Formålet med presentasjonen er å gi en innføring i hvordan programmene fungerer i bruk. I tillegg beskrives import- og eksportevnene. Først presenteres Autodesk Revit, deretter presenteres Ecotect og IES VE, som begge er analyseprogrammer med hensyn på energibruk. 4.2 Autodesk Revit Introduksjon Revit ble først lansert av Revit Technology Corporation i Revit var den første objektbaserte bygningsmodellen hvor alle de ulike aspektene til modellen som for eksempel plantegninger, tverrsnitt, 3D-visning og tidsplaner ble automatisk oppdatert hvis man gjorde en endring. I 2002 ble rmaet kjøpt opp av Autodesk og har blitt utviklet videre av dette rmaet. I dag er Revit en plattform bestående av produkter for en rekke ulike disipliner innen byggenæringen: Revit Architecture, Revit Structure og Revit MEP [Autodesk, 2010a]. COWI bruker Revit Architecture, og herunder følger en presentasjon av denne applikasjonen. 33

48 GUI I 2010-utgaven ble Autodesk Revit sitt GUI (se gur 4.1) endret betraktelig. For å gi mer plass til å skildre selve modellen man arbeider med ble verktøyene organisert på en ny måte; ulike verktøy er gruppert og plassert under faner, et system veldig likt verktøylinjen i Microsoft Oce Figur 4.1: Verktøylinjen til Autodesk Revit Her presenteres verktøyene som tilhører de ulike fanene: Home Verktøy for å lage en rekke ulike bygningselementer i modellen. Insert Verktøy for å sette inn eksterne elementer som for eksempel CAD-ler i modellen. Annotate Verktøy for å legge til 2D informasjon i modellen. Modify Verktøy for å endre eksisterende elementer, data og systemer i modellen. Massing & Site Verktøy for mengdeberegninger og lokalisering av bygget. Collaborate Verktøy for at ere skal kunne arbeide sammen på en modell. View Verktøy for å se modellen i ulike perspektiver som planskisser, tverrsnitt og 3D. Manage Verktøy for å endre innstillingene i prosjektet, eller preferansene i Revit. Element-Fane Når man har valgt et element i modellen kommer det i tillegg opp en egen fane med verktøy relevant for dette elementet. Plug-In Egne faner blir laget hvis man installerer tilleggsfunksjoner fra andre applikasjoner. 34

49 Figur 4.2: Autodesk Revit sitt GUI Under verktøylinjen nner man selve tegneområdet, hvor modellen er illustrert. Her kan man velge elementer man ønsker å modisere, legge til nye elementer og veksle mellom ulike perspektiver å se modellen i. Til venstre for tegneområdet nner man en oversikt over prosjektet man jobber med, delt inn i ulike utvidbare mapper (se Figur 4.2). I bruk Autodesk Revit er en applikasjon som brukes til BIM. Modellen inneholder all informasjon nødvendig for bygningsdesignet. Ved hjelp av Revit kan brukeren lage en bygningsmodell som kan representeres i ulike perspektiver (plantegninger, tverrsnitt, 3D-fremvisning og så videre), ta ut mengder fra modellen og sjekke om elementer kolliderer. Revit kan kobles sammen med andre applikasjoner for å utføre analyser eller legge til mer detaljert informasjon for hvert enkelt fagfelt [Autodesk, 2010a]. Når man etablerer et byggeprosjekt i programmet arbeider man med én l. Informasjonen i len blir lagret i en relasjonsdatabase kalt Parametric Change 35

50 Engine (PCE). Revit danner automatisk parametere som denerer relasjonene mellom elementene i modellen. Når man arbeider i tegneområdet kan modellen representeres i ulike perspektiver, og ved hjelp av PCE sørger Revit for at endringer gjort i et av perspektivene blir oppdatert i alle andre perspektiver [Autodesk, 2009b]. Informasjonsoppbygning Revit håndterer informasjon ved å dele inn elementer i kategorier, familier, typer og forekomster (se Figur 4.3). Figur 4.3: Inndeling av informasjon i Autodesk Revit [Autodesk, 2009b] Kategori Øverste nivå i informasjonsinndelingen består av kategorier. Kategorien for modellelementer inneholder vegger og bjelker, kategorien for merknader inneholder notater, og så videre [Autodesk, 2009b]. Familie Revit inneholder tre ulike familiegrupper [Autodesk, 2009b]: System families Disse familiegruppene er predenert i Autodesk Revit, og man kan ikke lage nye familier i denne gruppen på egenhånd. Familiegruppene inneholder vanlige bygningsdeler som vegg-, tak- og gulvelementer. Disse elementene eksisterer i prosjektmodellen som typer av sin familiegruppe, lagret som *.rte maler. I tillegg inneholder gruppen systemegenskaper for modellens tegneark, representasjonsmåter, nivåer og så videre. 36

51 Loadable families Disse familiene er lagret i Revit sitt bibliotek utenfor prosjektet som *.rfa ler og lastes inn i prosjekmodellen etter hvert som de blir tatt i bruk. Familiene består av to elementtyper frittstående og integrerte. Frittstående elementer kan være ting som møbler, trær, mennesker, biler og så videre. Integrerte elementer er innlemmet i andre bygningsdeler. Dette kan være elementer som vinduer og dører. I tillegg inneholder familiegruppen elementer som brukes når kommentarer legges til i modellen. In-place families Når man har behov for å lage et element i modellen som ikke er predenert i Revit eller kan lastes inn i modellen fra Revit sitt bibliotek (jamført System- eller Loadable Families) vil dette elementet tilhøre Inplace familiegruppen. Dette elementet er unikt for prosjektet det er laget i, og blir lagret i en egen familiegruppe som kun inneholder én familietype. Typer og forekomster Hver familie deneres av to typer parametere Type- og forekomstparametere. Typeparametere inneholder informasjon som er generell for alle elementer tilhørende den gitte familien. Forekomstparametere inneholder informasjon som er spesikk for hver enkelte forekomst i familien. En søyle sine dimensjoner vil være en typeparameter, mens plasseringen til en av søylene i modellen er en typeparameter [Autodesk, 2009b]. Import- og eksportevne Autodesk Revit Architecture 2011 kan importere og eksportere en rekke formater. For en komplett liste se Vedlegg C. Overføring med IFC Autodesk Revit 2011 er sertisert for import og eksport til IFC2x3 modellen [Autodesk, 2009b]. Standard Revit elementer kan representeres direkte med IFC-entiteter. For eksempel vil en Revit-vegg bli eksportert som en IFCwall. Denne metoden ble brukt for å overføre informasjon fra Autodesk Revit 2011 til Autodesk Ecotect

52 Overføring med gbxml Autodesk Revit 2011 kan eksportere sine modeller til gbxml-formatet. Når man skal eksportere modellen til gbxml får man opp et eget vindu (se Figur 4.4) hvor man kan se over modellen og gjøre endringer. Under Generalfanen kan man blant annet endre bygningstype, lokasjon og velge hvor detaljert geometrien som skal eksporteres skal være. I Detailsfanen kan man velge mellom visning av romkategorier eller analytiske overater. Hvis det er åpninger i modellen vil disse vises her, og man vil også få beskjed hvis det er feil i modellen som må rettes opp. Man kan studere en forhåndsvisning av modellen for å se at alle overater og romvolum er korrekt. Figur 4.4: Eksportering til gbxml-formatet i Revit 38

53 gbxml-skjemaet organiserer bygningsinformasjon i følgende hierarki: Lokasjon, Bygning, Rom, Overate og Åpning (se Figur 4.5). Figur 4.5: Informasjonsorganisering i gbxml [Autodesk, 2009b]. Se Tillegg D for en oversikt over gbxml-elementer og -attributter som støttes av Revit Architecture Autodesk Ecotect Introduksjon Autodesk Ecotect ble kjøpt opp av Autodesk i Før den tid var programmet eid og utviklet av Square One Reaserch. Applikasjonen fokuserer på energiberegninger og -analyser i tidligfase i byggeprosjekter, slik at man så tidlig som mulig kan utforme designet av bygget til å bli mest mulig energieektivt [Autodesk, 2010a]. 39

54 GUI Autodesk Ecotect 2011 sitt GUI (se Figur 4.6) består av en hovedmeny, paneler med redigerbar informasjon, et tegneområde og sider med ulik representering av informasjon og ulike verktøy [Autodesk, 2010b]. Figur 4.6: Autodesk Ecotect sitt GUI Hovedmeny Hovedmenyen består av generelle verktøy for bruk av programmet. Paneler På høyre side kan man velge mellom ulike faner. Disse fanene inneholder paneler med editerbar informasjon om prosjektet eller valgte elementer. Man kan blant annet endre verdier i objekter, håndtere soner og skygger, endre visualiseringsinnstillinger og velge eksportformater. Tegneområde I tegneområdet blir modellen representert ut i fra ulike visualiseringsmåter. Her kan man velge og legge til elementer. Sider På venstre hånd nner man faner man kan bruke for å veksle mellom ulike sider. Disse sidene inneholder ulik informasjon om prosjektet og verktøy relevant for hver enkelt side. I Project-side kan man legge til generell informasjon om prosjektet som for eksempel bygningens lokasjon, 3D 40

55 Editor-siden brukes for å velge eller lage objekter, Visualise-siden brukes til å visualisere modellen og Analysis-siden inneholder verktøy for å utføre ulike analyser. Funksjoner Autodesk Ecotect Analysis 2011 brukes til å visualisere, simulere og analysere bygningsfunksjoner tidlig i designprosessen. Applikasjonen betrakter ulike faktorer som for eksempel hvilke overater som er eksponert mot utsiden, eksponering til sollys, åpninger i overater og varme generert av interne varmekilder som belysning og utstyr i analyseprosessen. For å visualisere, simulere og analysere bygningsfunksjonene trenger applikasjonen informasjon om de romlige aspektene til bygget, materialegenskaper og soneinndeling [Autodesk, 2010b]. Følgende analyser kan utføres med Autodesk Ecotect 2011 [Autodesk, 2010b]: Dynamic Daylight Simulations (DAYSIM) Simulering av dagslys Radiance Simulering av lys Chartered Institution of Building Services Engineers (CIBSE) Energianalyser Energy+ Energianalyser, solinnstrålingsanalyser, akustikkanalyser NIST-FDS, Fluent og WinAir4 Dynamiske analyser av væsker og gasser. Energianalyse Autodesk Ecotect Analysis 2011 bruker en termisk algoritme fra CIBSE for å utføre energianalyser av bygninger [Autodesk, 2010a]. Med metoden utviklet av CIBSE beregnes temperatur og belastning i to forskjellige stadier. Først beregnes indre temperaturvariasjoner time for time, så beregnes varmebehovet. Varmebehovet er for hvert rom og for ulike soner og tar ikke hensyn til eektgraden til varme- og kjøleanlegg. Resultatene som presenteres er årlig forbruk og maks forbruk. CIBSE sin utslippsmetode ble utviklet for å beregne maksimum nedkjølingsbehov til ett bygg [CIBSE, 1999], og tester viser at denne metoden ikke frembringer nøyaktige resultater for oppvarmingsbehovet til en bygning [Hensen and Radosevic, 2004]. De termiske resultatene fra CIBSE bør derfor brukes som en referanse for å sammenligne ulike designløsninger og ikke for å dokumentere selve oppvarmingsbehovet. 41

56 De termiske analysene av interne temperaturer og varmebehov gjøres gjennom en simulering av hvordan energi beveger seg inn, ut og gjennom rom og volum i bygningsmassen. For å gjøre dette benytter Ecotect termiske soner de- nert i modellen. En termisk sone er denert som et lukket volum, avgrenset av gulv, vegger og tak, og deneres i Revit når man designer modellen (se Avsnitt 5.2). Import- og eksportevne Autodesk Ecotect Analysis 2011 kan eksportere ulike bildeformater og data til en rekke ulike modellerings- og analyseprogrammer. Programmet kan importere 3D CAD geometri og annen modelldata. Se Tillegg C for en mer komplett liste over eksport- og importevnene til Autodesk Ecotect. Import av IFC-modeller fra Autodesk Revit Autodesk Ecotect Analysis 2011 kan importere geometri-, material- og soneinformasjon via IFC-modeller, men dette er kun en Beta funksjon (Se Figur 4.7) og har ikke blitt ferdig utviklet. I importmenyen til IFC kan man velge hvordan Ecotect skal gjøre om IFC-entiteter til Ecotect sine egne materialtyper. Dette kan gjøres basert på materialer, egenskapssett, elementtyper eller elementnavn. I tillegg kan man manuelt denere elementklassene til elementer som importeres, velge om hver entitet skal lages som en separat sone og velge om kun romavgrensninger skal inkluderes. Figur 4.7: Import av IFC i Ecotect 42

57 4.4 IES VE Introduksjon Firmaet IES ble dannet i 1994 av Don McLean, som hadde som mål å utvikle et brukervennlig program som skulle gi et godt grunnlag for å designe, bygge og drifte energieektive bygg. Resultatet ble IES VE; en rekke ulike analyseverktøy integrert i en plattform, som benytter samme datamodell for å modellere og analysere bygningsmodeller. GUI IES VE sitt GUI (se Figur 4.8) består av en hovedmeny, et tegneområde, en rullefeltsmeny for analyseverktøy, en utforsker og et felt med rominformasjon [IES VE, 2010]. Figur 4.8: IES VE sitt GUI [IES VE, 2010] Utforsker Utforskeren gir en oversikt over romgrupper og soner i modellen. Man kan spesisere hvilke elementer som skal høre til de ulike gruppene. 43

58 Analyseverktøy Dette er en rullefeltsmeny med en liste over ulike verktøy man kan bruke for å analysere byggets egenskaper. Hovedmeny Hovedmenyen består av en nedtrekksmeny med generelle verktøy for programmet, og verktøylinjer for å modellere og redigere objekter. Tegneområde I tegneområdet kan man visualisere modellen på ulike måter. I tillegg kan man velge og redigere objekter og legge til nye objekter. Rominformasjon Her vises informasjon sonenummer, navn, id, volum, areal, utvendig veggareal, utvendig åpning, farge og lag om sone/objekt som er valgt. Velger man ere objekter summeres dataen. Funksjoner From Analysis to Understanding IES VE inneholder i likhet med Ecotect Analysis verktøy som kan brukes tidlig i designprosessen IES <Virtual for Environment> å vurdere konsekvensene Product Overview av ulike V6.0 designløsninger. I tillegg kan applikasjonen brukes når mer detaljerte løsninger skal designes, og også når bygget skal driftes [IES VE, 2009]. Modellen som skal analyseres importeres inn i Integrated Data Model (IDM), hvor geometri og all annen relevant informasjon By: for å analysere INTEGRATED bygningen ENVIRONMENTAL blir lagret. SOLUTIONS LIMITED Date: Monday 19 October 2009 Figur 4.9: De ulike variantene av IES VE [IES VE, 2010] BOSTON, MA GLASGOW, SCOTLAND DUBLIN, IRELAND LONDON, ENGLAND MELBOURNE, AUSTRALIA SAN FRANCISCO, CA DUBAI, UAE Analyseverktøyene som er tilgjengelig avhenger av hvilken variant av IES VE brukeren har rettigheter til. De ulike variantene er: VE-Ware, VE-Toolkits, VE-Gaia og VE-Pro (se Figur 4.9). VE-Ware er gratis og brukes for å beregne 44

59 årlig energiforbruk og utslipp av karbon. VE-Toolkits, VE-Gaia og VE-Pro er kostnadsbelagte, og med hvert nivå får man stadig ere funksjoner. Analyser man kan utføre med IES VE-Pro [IES VE, 2010]: ApacheCalc ApacheCalc beregner varmetap og -gevinster til bygget, basert på prosedyrer utviklet av CIBSE. ApacheLoads ApacheLoads beregner oppvarming- og nedkjølingsbehovet til bygget. Dette gjøres basert på en metode utviklet av American Society of Heating, Refrigeration and Air-Conditioning Engineers (ASHRAE). ApacheSim ApacheSim bruker SunCast, ApacheHVAC og MacroFlo for å vurdere byggets termiske egenskaper. ApacheHVAC Simulering av Heating, Ventilating and Air Conditioning (HVAC). SunCast SunCast simulerer solinnstråling i bygget. MacroFlo MacroFlo simulerer luftstrømninger for at man skal kunne studere naturlig- og hybridventilasjon, inltrasjon og fasadeanalyser. MicroFlo MicroFlo er et Computational Fluid Dynamics (CDF)-system for simulering av luftstrømninger og varmeoverføring. Deft Deft brukes for å vurdere ulike designalternativer for å nne frem til det beste alternativet. CostPlan CostPlan brukes for å utføre kostnadsestimeringer i byggeprosjektet. LifeCycle LifeCycle utfører livsløpsanalyser av kostnader knyttet til operering av bygget. IndusPro Med IndusPro kan man plassere og dimensjonere ventilasjonskanaler. PiscesPro PiscesPro brukes for å designe røroppleggsystemer. Simulex Simulex simulerer en evakuering av bygget. Lisi Med Lisi kan man designe og simulere heisløsninger for å optimalisere transporteringen av personer i bygningen. 45

60 Energianalyse IES VE bruker verktøyet ApacheLoads for å beregne oppvarming- og nedkjølingsbehovet til bygget. Varmebalansemetoden som Apacheloads bruker under disse simuleringene er utviklet av ASHRAE. Med denne metoden simuleres først varmetapet til bygningen for å beregne oppvarmingsbehovet. Videre simuleres oppvarmingen i bygget fra solinnstråling, menneskelig aktivitet og så videre for å beregne nedkjølingsbehovet [Barnaby et al., 2005]. Under simuleringene benytter IES VE de termiske sonene hentet fra modellen i IDM. En termisk sone er denert som et lukket volum, avgrenset av gulv, vegger og tak, og deneres i Revit når man designer modellen (se Kapittel 5.2). I motsetning til Ecotect, som kun gir årlig og maks energibehov, kan IES VE presentere energibehov for ulike perioder, helt ned til dagsbehovet [IES VE, 2010]. Import- og eksportevne IES VE kan ikke importere mange formater sammenlignet med Ecotect og Revit, men har fokusert på formatet gbxml. Når gbxml-len er lastet inn i applikasjonen blir modellen lagret i hovedlen *.ve, i tillegg til en rekke undermapper dedikert til de ulike analysefunksjonene internt i applikasjonen. Se Tillegg C for en liste over import- og eksportevnene til IES VE. Import av gbxml Figur 4.10: Importering av gbxml-l i IES VE 46

61 Import av en modell lagret i gbxml-formatet gjøres i et eget vindu (se Figur 4.10). Her får man opp redigerbar informasjon om byggets bygningstype, bygningsmaterialer, HVAC-system og lokasjon. I tillegg kan man gå inn og velge romtype, HVAC-system og bygningsmaterialer for individuelle rom i modellen. Figur 4.11: Kontroll av rom i modell som skal importeres Før man kan importere modellen må man sjekke rommene i modellen (se Figur 4.11). Egenskaper som er utenom forventede verdier blir fremhevet i gult, slik at man kan oppdage avvik. Overføring via PlugIn Et alternativ til å laste inn gbxml-ler i IES VE er å benytte en PlugIn laget for Autodesk Revit (Se Figur 4.12). PlugIn-programvaren er kompatibel med Revit 2008, 2009, 2010 og 2011 og gjør det mulig å foreta analyser direkte i Revit. Først må man importere modellen til gbxml på samme måte som beskrevet ovenfor. Etter dette kan man utføre ulike analyser avhengig av hva slags lisens man har direkte i Revit. Figur 4.12: IES VE PlugIn til Autodesk Revit 47

62 5 Målemetode 5.1 Generelt Dette kapittelet handler om testing av programvare. Hensikten med disse testene er å kartlegge hva slags informasjon som blir overført mellom de ulike applikasjonene for å vurdere interoperabiliteten. Applikasjonene som ble brukt under testene er Autodesk Revit 2011, Ecotect Analysis 2011 og IES VE IFC 2x3 ble brukt for å overføre informasjon fra Revit til Ecotect og gbxml 0.37 ble brukt for å overføre informasjon fra Revit til IES VE. Informasjonsoverføringen er kun testet fra Revit til analyseapplikasjonene da ingen av analyseapplikasjonene kan eksportere informasjon til et format som kan lastes inn i Revit. Først i kapittelet beskrives de grepene som ble gjort i Revit for å legge til rette for eksporteringen av modellene. Til slutt beskrives testene som ble utført. 5.2 Innstillinger i Revit Innledning Her presenteres de innstillingene som ble gjort i Revit Architecture før testene ble utført. Først presenteres de generelle innstillingene for modellene som skulle eksporterest til IFC og gbxml. Deretter presenteres spesikke innstillinger som ble gjort med hensyn til IFC og gbxml. 48

63 Generelle innstillinger Denering av Prosjektinformasjon Relevant prosjektinformasjon for energianalyser vil være modellens bygningstype, geograske lokasjon og orientering. Ved å gå inn i Project Information under Manage-fanen kan man velge Energy Settings hvor de to førstnevnte attributtene kan spesiseres (Se Figur 5.1). For å endre modellens orientering i Figur 5.1: Energy Settings i Revit forhold til geogrask nord går man inn på Position under Manage-fanen og velger Rotate True North (Se Figur 5.2). I tillegg må man sørge for at denisjonen av orienteringen til bygget er endret fra Project North til True North i egenskapene til hver tegning. Figur 5.2: Endring av modellens orientering i Revit Denering av rom Både Ecotect og IES VE baserer seg på termiske soner for å gjøre analyser av en modell. En termisk sone er denert som et lukket volum, avgrenset av 49

64 gulv, vegger/romseparasjonslinjer og tak/etasjeskillere. De termiske sonene blir denert i Revit når man designer modellen, og det er kritisk at dette utføres riktig. Det er viktig å sørge for at alle vegger er koblet til hverandre, så vel som til tak- og gulvelementer, slik at det ikke blir noen åpninger i modellen. I tillegg må man påse at attributten Room Bounding er valgt for alle elementer som skal overføres til analyseapplikasjonen (Se gur 5.3). Etter at man har sørget for at Figur 5.3: Room Bounding attributt i Revit alle avgrensningsobjekter er riktig sammenkoblet må man legge inn romobjekter i alle rom i modellen. Her er det viktig å påse at romobjektene strekker seg helt opp til etasjeskiller/tak. Hvis sonene ikke rekker opp til etasjeskiller/tak, vil ikke modellen som eksporteres bli riktig for termiske analyser. Standardhøyden til romobjekter i Autodesk Revit er 2,4 meter, så hvis veggene til rommet er høyere enn dette må man gå inn og denere ny høyde (Se gur 5.4). For å gjøre romobjektenes utstrekning synlig slik at man kan kontrollere høyden må man gå inn i Visibility/Graphic og huke av for Interior Fill. Figur 5.4: Justering av sonehøyde i Autodesk Revit

65 Beregning av romvolum Standardinnstillingen i Revit er kun å beregne arealer, da dette krever mindre systemressurser. Analyseverktøyene har behov for informasjon om volum og romhøyde, og man må derfor endre innstillingen i Revit til å beregne både areal og volum. For å gjøre dette velger man Areal and Volume Computations under Home-fanen (Se Figur 5.5). Figur 5.5: Romvolum Innstillinger for eksportering til IFC IFC-mal Revit laster inn en prosjektmal når man etablerer et nytt prosjekt. Denne malen denerer familier, innstillinger som måleenheter, skalering og skravering og geometri [Autodesk, 2009b]. De modellene som ble laget for overføring til Ecotect Analysis brukte IFC Metric Template.rte som prosjektmal. IFC-avbildingsl For å kunne eksportere en Revit-modell til IFC må man denere hvilke IFCklasser de ulike Revit-familiene samsvarer med i menyen IFC Options (se Figur 5.6). IFC-avbildingslen som ble brukt under testene for overføring mellom Revit og Ecotect er lagt ved i Vedlegg E. Hver rad representerer en elementkategori, 51

66 eller underkategori med en tilhørende IFC-klasse. Blanke felt vil Revit automatisk tolke for å tildele samsvarende klasse. Felt med teksten fører til at elementet ikke blir overført [Autodesk, 2009b]. Figur 5.6: Menyen IFC Options Innstillinger for eksportering til gbxml Prosjektmal Modellene som ble laget for overføring til IES VE brukte i likhet med modellene som ble laget for overføring til Ecotect en prosjektmal. De modellene som ble laget for overføring til IES VE brukte DefaultMetric.rte som prosjektmal. Søyler Overater blir denert i gbxml-skjemaet ut ifra hvilke soner som tilstøter over- aten (Se Figur D.18 i Vedlegg D). Siden det ikke er denert noen rom innvendig i søyler og søyler er denert som overater i gbxml-skjemaet vil søylens overate bli tolket som en yttervegg. For å unngå dette ble attributten Room Bounding satt til negativ verdi for alle søyler. Tidsplan Når man skal eksportere en modell til gbxml får man til tider opp en feilmelding i eksporteringsvinduet (Se Seksjon 4.2) som sier at det er udenerte rom 52

67 i modellen (Se Figur 5.7). Denne feilmeldingen skyldes at Revit ikke klarer å Figur 5.7: Feilmelding i Revit eksportere rom som er laget i en tidligere fase. Feilmeldingen ble løst ved å kun ha én fase i modellen (Se Figur 5.8) og å legge inn alle bygningselementer i egne tidsplaner. Figur 5.8: Redigering av faser i Revit 5.3 Testmodeller Fremgangsmåte Modellene som ble testet ble laget i Autodesk Revit Architecture 2011 med de innstillingene som er beskrevet ovenfor. Modellene ble laget for å undersøke hvilken informasjon som ble overført fra Revit til Ecotect og IES VE via henholdsvis IFC og gbxml. Informasjonen som ble testet for overføring er prosjektinformasjon, rominformasjon, informasjon om objekttyper, informasjon om geometri og materialegenskaper. Detaljnivået for eksporteringen var alltid satt til Complex with Mullions and Shading Surfaces. 53

68 Test 1 Prosjektinformasjon Den første modellen ble laget for å teste hvorvidt den generelle informasjonen om prosjektet ble overført. Dette omfatter informasjon om geogrask lokasjon, orientering, bygningstype og enhetsbenevning. Modellen bestod av enkelt sone, avgrenset av re vegger, tak og gulv (se Figur 5.9). Figur 5.9: Modell laget i Revit for Test 1 Test 2 Informasjon om objekttyper og rom Denne testen ble utført for å undersøke hvorvidt informasjon om objekttyper (tak-, etasjeskille-, gulv-, yttervegg-, innervegg-, vindu-, søyle- og dørtyper) og rominformasjon (navn, volum, plassering og areal til avgrensende ater) ble overført fra Revit til analyseapplikasjonene. Dette ble gjort ved å lage modeller i Revit bestående av alle disse objekttypene. Se Figur 5.10 for eksempel på en modell laget for Test 2. Figur 5.10: Modell laget i Revit for Test 2 Test 3 Veggeometri Denne testen ble utført for å kartlegge hva slags type veggeometri som kunne overføres fra Revit til analyseapplikasjonene. Dette ble gjort ved å lage modeller 54

69 med forskjellig type veggeometri. Se Figur 5.11 for eksempler på modeller laget for Test 3. (a) Modell med mangekantet vegg (b) Modell med enkeltkrummet vegg (c) Modell med dobbeltkrummet vegg Figur 5.11: Modeller laget i Revit for Test 3 Test 4 Takgeometri Denne testen ble utført for å kartlegge hva slags type takgeometri som kunne overføres fra Revit til analyseapplikasjonene. Dette ble gjort ved å lage modeller med forskjellig type takgeometri. Se Figur 5.12 for eksempler på modeller laget for Test 4. (a) Modell med gavltak (b) Modell med enkeltkrummet tak (c) Modell med dobbeltkrummet tak Figur 5.12: Modeller laget i Revit for Test 4 55

70 Test 5 Materialegenskaper IES VE henter ikke inn informasjon om materialegenskaper via gbxml, men lar brukeren denere dette under importprosedyren (se Avsnitt 4.4). Derfor ble det kun testet om IFC kunne overføre informasjon om materialegenskaper fra Revit til Ecotect. Forekomstene i modellen inneholdt materialinformasjon som varmegjennomgangskoesient og materialtype. Se Figur 5.13 for eksempel på modell laget for Test 5. Figur 5.13: Modell laget i Revit for Test 5 56

71 6 Resultater 6.1 Generelt Dette kapittelet gir en presentasjon av resultatene fra testene som ble utført, en oppsummering av resultatene og til slutt en drøfting av resultatene. 6.2 Presentasjon av resultatene Test 1 Prosjektinformasjon Se Vedlegg F for resultatene fra Test 1. Ecotect Analysis Lokasjon Standard lokasjon for modeller i Ecotect Analysis er Perth, Australia. Denne verdien ble ikke endret etter at IFC-modellen ble importert. Orientering Informasjon om orientering ble overført til Ecotect, men siden Ecotect kun bruker True North er verdien satt til 0. Med andre ord har modellen blitt rotert til absolutte koordinater, relativ til True North. Bygningstype Informasjon om bygningstype ble ikke overført til Ecotect. Enhet Hvilke enheter som ble brukt i modellen ble ikke endret i Ecotect, men tallverdiene ble konvertert til riktig verdi. 57

72 IES VE Lokasjon Informasjon om lokasjon ble overført til IES VE. Orientering Informasjon om orientering ble overført til IES VE, men siden IES VE kun bruker True North er verdien satt til 0. Med andre ord har modellen blitt rotert til absolutte koordinater, relativ til True North. Bygningstype Informasjon om bygningstype ble overført til IES VE. Enhet Informasjon om valgt enhet ble overført til IES VE. Test 2 Informasjon om objekttyper og rom Se Vedlegg G for resultatene fra Test 2. Ecotect Analysis Figur 6.1: Modell fra Test 2 lastet inn i Ecotect Analysis Plassering Som det tydelig fremgår av Figur 6.1 ble ikke objektene sin plassering i forhold til hverandre i modellen lastet inn i Ecotect. Romtype Rommene sin typeinformasjon ble lastet inn i Ecotect. Navn og areal til rommene sine avgrensende ater ble overført, men volum ble ikke lastet inn direkte i Ecotect. Vindustype Ikke alle forekomster av vinduer i modellen ble lastet inn i Ecotect, og det ble ikke avdekket noe system for når forekomstene ble lastet inn og når de ikke ble det. Geometrien til forekomstene var intakt, men glassate og vinduskarm sin orientering i forhold til hverandre var fordreid. Forekomstene var ikke koblet til veggene de tilhørte, og de hadde mistet sin typeinformasjon. 58

73 Dørtype I IFC-malen som ble brukt for å lage modeller for overføring til Ecotect kunne man kun velge én type dør (IFC_Door). Ingen informasjon om dører ble lastet inn i Ecotect. Gulvtype Gulvforekomsten sin typeinformasjon og geometri ble lastet inn i Ecotect. Etasjeskillertype Ingen informasjon om etasjeskiller ble lastet inn i Ecotect. Innerveggtype Geometri til innervegger ble lastet inn i modellen, men typeinformasjonen var endret fra innerveggene til yttervegger. Ytterveggtype Geometri- og typeinformasjon til yttervegger ble lastet inn i Ecotect. Taktype Takforekomsten sin typeinformasjon og geometri ble lastet inn i Ecotect. Søyletype Geometrien til søylene ble lastet inn i modellen, men forekomstene hadde mistet sin typeinformasjon. IES VE Figur 6.2: Modell fra Test 2 lastet inn i IES VE Plassering Som Figur 6.2 viser, ble rommenes plassering i forhold til hverandre overført til IES VE. Romtype Rommene sin typeinformasjon ble lastet inn i IES VE. Navn, volum og areal til rommene sine avgrensende ater ble overført. 59

74 Vindutype Vindustyper ble lastet inn i modellen. Forekomstene inneholdt geometrisk informasjon, men vindussprosser ble ikke tatt med. Dørtype Dørtyper ble lastet inn i modellen. Forekomstene inneholdt geometrisk informasjon, men eventuelle glassater i dørene ble ikke tatt med. Gulvtype Gulvtype med geometrisk informasjon ble lastet inn i modellen. Etasjeskillertype Etasjeskillertype med geometrisk informasjon ble lastet inn i modellen. Innerveggtype Innerveggtype med geometrisk informasjon ble lastet inn i modellen. Ytterveggtype Ytterveggtyper med geometrisk informasjon ble lastet inn i modellen. Taktype Taktyper med geometrisk informasjon ble lastet inn i modellen. Søyletype Som beskrevet i Kapittel 5 blir søyler sin overate tolket som en yttervegg. Derfor ble ikke søyler tatt med i modeller som ble overført til IES VE. Test 3 Veggeometri Ecotect Analysis Figur 6.3: Modell med mangekantet vegg lastet inn i Ecotect Analysis Som vist i Figur 6.3 ble modeller med ate vegger lastet inn i Ecotect Analysis, men det var derimot ikke mulig å laste inn en modell via IFC som inneholdt krumme vegger. Hvis et rom var avgrenset av krumme vegger ble ingen informasjon om rommet lastet inn. 60

75 IES VE (a) Modell med mangekantet vegg (b) Modell med enkeltkrummet vegg Figur 6.4: Modeller fra Test 3 lastet inn i IES VE (c) Modell med dobbeltkrummet vegg Som vist i Figur 6.4 ble alle modellene i Test 3 lastet inn i IES VE. Applikasjonen evner ikke å nøyaktig fremstille krumme vegger, men bruker polygonater som en tilnærming. Test 4 Takgeometri Ecotect Analysis Figur 6.5: Modell med gavltak fra Test 4 lastet inn i Ecotect Analysis Som vist i Figur 6.5 ble modeller med gavltak lastet inn i Ecotect Analysis, men rommene ble stilt på høykant. Dette er en feil fra Ecotect sin side da dette også kan oppstå av og til med modeller som lages direkte i Ecotect [Autodesk, 2010b], men denne feilen var konsekvent ved import via IFC. Det var ikke mulig å laste inn en modell via IFC som inneholdt krumme tak. Hvis 61

76 et rom var avgrenset av krumme tak ble ingen informasjon om rommet lastet inn. IES VE (a) Modell med gavltak (b) Modell med enkeltkrummet tak (c) Modell med dobbeltkrummet tak Figur 6.6: Modeller fra Test 4 lastet inn i IES VE Som vist i Figur 6.6 ble alle modellene i Test 4 lastet inn i IES VE. Applikasjonen evner ikke å nøyaktig fremstille krumme tak, men bruker polygonater som en tilnærming. Som illustrert i Figur 5.12(c) var det problemer med å laste inn dobbeltkrummede tak. 62

77 Test 5 Materialegenskaper Ecotect Analysis Figur 6.7: Modell fra Test 5 lastet inn i Ecotect Analysis Modellene som ble lastet inn i Ecotect inneholdt ingen informasjon om materialegenskaper. De forekomstene som inneholdt typeinformasjon ble tildelt standard materialegenskaper for den respektive typen. 63

78 6.3 Sammendrag av resultatene A Prosjektinformasjon Lokasjon û ü Orientering ü ü Bygningstype û ü Enhetsbenevning û ü Objekttype Vindu û ü Dør û ü Tak ü ü Gulv ü ü Etasjeskiller û ü ü Yttervegg ü ü Innervegg û ü Søyle û û Rominformasjon Navn ü ü Volum û ü Plassering û ü Areal til avgrensende flater ü ü Veggeometri Plane vegger ü ü Enkeltkrummede vegger û ü Dobbeltkrummede vegger û ü Takgeometri Plane tak ü ü Enkeltkrummede tak û ü Dobbeltkrummede tak û û Materialegenskaper Ecotect via IFC IES VE via gbxml Materialegenskaper û û Figur 6.8: Sammendrag av resultatene fra de utførte testene Modeller overført til Ecotect Analysis via IFC IFC-modeller importert i Ecotect Analysis inneholdt informasjon om modellens orientering, men inneholdt derimot ikke informasjon om modellen sin lokasjon og bygningstype. Romforekomstene i modellen inneholdt navn og areal til avgrensende ater, men rommenes plassering i forhold til hverandre var blitt endret og romvolum ble ikke direkte overført. Informasjon om eventuelle åpninger (dører og vinduer) i de avgrensende atene ble ikke overført. Alle toppater til rom- 64 Side 1

79 mene ble satt til objekttypen tak, alle sideater til yttervegg og alle bunnater til gulv. Ingen informasjon om objektene sine materialegenskaper ble overført. Hvis modellen som ble overført inneholdt krumme ater ble ingen informasjon lastet inn i Ecotect. Modeller overført til IES VE via gbxml gbxml-skjemaet organiserer som nevnt i Kapittel 4 bygningsinformasjon i følgende hierarki: Lokasjon, Bygning, Rom, Overater og Åpninger (se Figur 6.9). Ut i fra lokasjon- og bygningskategorien hentet IES VE informasjon om koordinater, orientering og bygningstype til modellen. Romkategorien gav IES VE informasjon om navn, volum og overateareal til romsoner. Ut i fra tilstøtende soner som omsluttet hver romsone ble romsonenes overatetyper (innervegg, yttervegg, etasjeskiller, tak og gulv) bestemt. Overatetypenes materialinformasjon ble dog ikke lastet inn. Åpningstyper i overatene (vinduer og dører) ble lastet inn. Åpningsforekomstenes arealinformasjon ble overført, men detaljer som materialinformasjon, vindussprosser og glassareal i dører ble ikke overført. På grunn av gbxml-skjemaets måte å denere soner på kunne ikke søyler lastes inn i analyseapplikasjonen. Figur 6.9: Bygningskomponentenes hiearkiske inndeling i IES VE 65

80 gbxml-skjemaet bruker plan polygongeometri for å representere overatene i modellen. Dette er en tilnærming og vil ikke gi nøyaktige verdier for all type geometri. Ut i fra testene som ble utført viste det seg at formatet særlig hadde problemer med å representere dobbeltkrummede takater, og at dette i visse tilfeller førte til at taket ikke ble en lukket ate. 6.4 Drøfting av resultatene Som omtalt i Kapittel 3 kan tap av informasjon skyldes at Revit ikke evner å konvertere informasjonen riktig til overføringsformatet, at overføringsformatet ikke evner å representere informasjonen i Revit, eller at analyseapplikasjonen ikke evner å tolke informasjonen fra overføringsformatet. Ved overføring via gbxml ble en forhåndsvisning av modellen vist, både ved eksport i Revit og ved import i IES VE (se Figur 4.4 og 4.10). Ut i fra denne forhåndsvisningen var det tydelig at problemet med å overføre geometri for dobbeltkrummede tak oppstod allerede ved eksporteringen fra Revit sitt eget format til gbxml-skjemaet. Som omtalt i Kapittel 3 er gbxml et overføringsmedium kun tiltenkt kommunikasjon fra en modelleringsapplikasjon til en analyseapplikasjon, og fungerer forholdsvis bra til dette formålet. Formatet har dog visse begrensninger (se Kapittel 3) som fører til at man må tilføre modellen en del informasjon manuelt før man kan utføre analyser; formatet kan ikke overføre informasjon om materialegenskaper og har problemer med å fremstille dobbeltkrummede ater (se Figur 6.6). Ved overføring via IFC var det ingen forhåndsvisning av modellen, verken ved eksport i Revit, eller ved import i Ecotect Analysis. Det er derfor vanskelig å fastslå hvor i prosessen tap av informasjon forekom. IAI har som mål at IFC-modellen skal være et overføringsformat som vil gi full interoperabilitet mellom alle applikasjoner brukt i et byggeprosjekt. Resultatene fra testene utført i tilknytning til denne oppgaven viser at dette foreløpig ikke er tilfelle for kommunikasjon mellom Revit og Ecotect. Ecotect Analysis sin implementering av IFC er som nevnt i Kapittel 4 kun på Beta-stadiet, og Ecotect sin evne til å hente ut informasjon fra en IFC-modell vil trolig bli bedre med tiden. Det er dog grunnleggende utfordringer med IFC (se Kapittel 3) som tilsier at det vanskelig vil la seg gjennomføre å oppnå full interoperabilitet med dette formatet. 66

81 7 Anbefaling til COWI i forhold til BIM og miljøvurdering 7.1 Situasjonen i dag Beregning av bygningers energibehov og varmetapstall skal utføres i samsvar med Norsk Standard NS3031: Beregning av bygninger energiytelse - Metode og data [Kommunal- og regionaldepartementet, 2010]. Her oppgis det at beregningsprogrammene som skal brukes i tilknytning til disse beregningene skal være validert etter NS-EN [Standard Norge, 2007]. Foreløpig er det kun applikasjonene SIMulering av Inneklima og ENergibruk i bygninger (SIMIEN) og VIP Energy som er validert [Petersen, 2010]. Med andre ord kan verken Ecotect Analysis eller IES VE brukes til å dokumentere energibehov og varmetapstall til et bygg. Analyseapplikasjonene kan likevel ha en stor nytteverdi i byggeprosjekter ved å være et verktøy for å vurdere ulike designløsninger. Særlig tidlig i prosjektfasen er man tjent med å vurdere ulike alternativer, og analysene gir et godt grunnlag for å komme frem til de optimale løsningene. BIM legger til rette for en raskere og mer nøyaktig prosess for å foreta analyser, og energianalysene kan bli en mer integrert del av designprosessen. Det har blitt vist at 50% av tiden det tar å bygge og analysere en energimodell går med til å gjenskape bygningsgeometri og til å tilføre materialegenskaper [Krygiel and Nies, 2008]. Å automatisere dette arbeidet åpner opp for å foreta ere analyser og gir mer tid til å vurdere resultatene, noe som samlet sett gir et bedre grunnlag for å foreta valg i designprosessen [Krygiel and Nies, 2008]. 67

82 Dette avhenger dog av at applikasjonene er interoperabile. I sammenheng med denne oppgaven ble kommunikasjonen mellom Revit Architecture og analyseapplikasjonene Ecotect Analysis og IES VE testet. Informasjonsoverføringen fra Revit Architecture til Ecotect Analysis ble gjort via IFC-modellen. Informasjonsoverføringen fra Revit Architecture til IES VE ble gjort via gbxml-skjemaet. Brukeren må denere materialegenskapene til bygningskomponentene selv ved overføring via gbxml-skjemaet, og formatet har til tider problemer med å representere kompleks geometri. Til tross for disse svakhetene kom gbxml-skjemaet klart best ut i de ulike testene. Selv om det kun ble brukt standard elementer i modellen som ble overført via IFC-modellen gikk mye informasjon tapt. Ved overføring av modeller som inneholder andre elementer vil informasjonsoverføringen trolig være enda mer utfordrende. I tillegg til at mindre informasjon gikk tapt ved overføring via gbxmlskjemaet var prosessen med å overføre informasjonen mer oversiktlig. Ved overføring via gbxml-formatet ble modellen illustrert både i Revit under eksport og i IES VE ved import. Dette gav en intuitiv og oversiktlig måte å oppdage feil på. Ved overføring via IFC-modellen ble modellene derimot eksportert og importert i blinde, og man kunne ikke undersøke modellens integritet før den var lastet inn i Ecotect Analysis. Modellene som ble overført via IFC-modellen ble svært fordreid, og det var vanskelig å kartlegge hvilken informasjon som var gått tapt. I en vanlig arbeidssituasjon vil det trolig være mindre tidkrevende å lage hele modellen direkte i analyseapplikasjonen enn å gå igjennom elementene overført via IFC for å kartlegge hva som må rettes opp. Ved valget mellom IFC-modellen og gbxml-skjemaet vil jeg derfor med bakgrunn i vurderingen av formatene gjort i Kapittel 3 og resultatene fra testene som ble utført anbefale COWI å benytte gbxml-skjemaet for overføring av informasjon til analyseapplikasjoner. Ved en slik overføringsprosess er det visse ting man må ta hensyn til; under eksporteringen må man sjekke om det oppstår noen feilmeldinger, og om det eksisterer noen tomrom i modellen. Særlig er det viktig å sørge for at egenopprettede elementer er denert ordentlig, slik at disse blir tolket riktig ved eksporteringen. Hvis modellen inneholder dobbeltkrummede ater bør man kontrollere at disse atene eksporteres korrekt. Hvis ikke må disse lages på nytt i analyseapplikasjonen. For å redusere risikoen for feil ved eksport kan det være en fordel å fjerne alle elementer i modellen som ikke er nødvendige for å foreta analyser. Utenom dette bør de innstillingene som er beskrevet i Kapittel 5 følges. Denne oppgaven fokuserte ikke på å vurdere funksjonaliteten og kvaliteten til analyseapplikasjonene, og siden både Ecotect Analysis og IES VE kan importere 68

83 gbxml-skjemaer kan begge applikasjonene være aktuelle å bruke for COWI. Selv om begge applikasjonene kan bruke gbxml-skjemaet vil jeg anbefale COWI å ta i bruk IES VE. Overføringsprosessen fra Revit Architecture til IES VE var intuitiv og feil i modellen kom tydelig frem. IES VE har ere analysefunksjoner enn Ecotect Analysis og kan brukes gjennom hele byggeprosjektet. I tillegg er det en fordel at man kan bruke IES VE direkte i Revit Architecture for å utføre analyser ved hjelp av en PlugIn. 7.2 Fremtidig arbeid med BIM og miljøvurdering I starten av byggeprosjekter deneres et miljøprogram. Hensikten med miljøprogrammet er å få konkretisert miljømålene for prosjektet samt å lage et grunnlag for hva slags miljøprol man ønsker at bygget skal ha [Marton, 2008]. Målene kan blant annet omfatte byggeprosessen, område- og infrastrukturen og bebyggelsen [Statsbygg, 2010]. Miljøprogrammet sin utarbeidelse baserer seg på prosjekteierens miljøpolitikk, konsekvensutredningen av prosjektet og oentlige lover, forskrifter og myndighetskrav som er relevante for prosjektet. For å nå målene som er denert i miljøprogrammet må løsninger av en rekke ulike aspekter ved bygget vurderes. Dette inkluderer blant annet trakkgenerering, avfallshåndtering under byggeprosessen, valg av materialer, tekniske installasjoner, energikilder og arkitektonisk utforming. Utfordringene som skal løses er ofte komplekse, og krever tett samarbeid mellom aktørene i byggeprosjektet. For eksempel vil en liten detalj som hvilken malingstype som blir brukt påvirke reeksjonen av solstråler, og dermed ha konsekvenser for energiberegningen fra solinnstråling. I en ideell situasjon vil bruken av BIM under byggeprosjektet kunne forenkle oppgaven med å lage miljøvennlige bygg betraktelig. Den viktigste funksjonen til BIM er å legge til rette for bedre menneskelig samarbeid i byggebransjen, og med det bedre resultater. Ved full interoperabilitet kan alle aktørene i byggeprosjektet jobbe samtidig opp mot samme modell. Analyseapplikasjoner kan hente ut all relevant informasjon, analysere informasjonen og gjøre eventuelle endringer som vil bli reektert i hovedmodellen. Modellen kan være koblet opp mot databaser fra materialleverandører som inneholder informasjon om kostnad og Environmental Product Declaration (EPD). Dermed kan man foreta nøyaktige livsløpsanalyser for å forsvare investeringskostnader. Man får også oversikt over byggets klimagassutslipp, ikke bare fra driften av bygget, men også fra produksjonen av bygningskomponentene. I tillegg får man en dokumentasjon av hvilke miljøfarlige stoer som er blitt brukt i bygget, slik at disse blir tatt forsvarlig 69

84 hånd om når bygget skal rives. Listen over muligheter er lang, men som omtalt i Kapittel 2 er man avhengig av full interoperabilitet hvis BIM fullt ut skal komme til sin rett. Utfordringer knyttet til interoperabilitet har blitt omtalt i Kapittel 3. Full interoperabilitet mellom applikasjoner ved kommunikasjon via lformater innebærer at alle applikasjonene må kunne importere all informasjonen i len, og i tillegg kunne eksportere all informasjon til samme format. Å oppnå full interoperabilitet ved en slik type kommunikasjon har vist seg å være svært utfordrende selv for overføring av enkle tekstdokumenter [Shah and Kesan, 2008], og for informasjon i en BIM blir oppgaven tilnærmet umulig. Med andre ord er løsningen med å sende informasjon via gbxml-formatet en midlertidig løsning frem til et bedre alternativ her blitt utviklet. Å gå over til kommunikasjonstypen server-klient vil gi store muligheter til å oppnå full interoperabilitet mellom applikasjoner. Kommunikasjonen mellom applikasjonene og en database-serveren består av enkle transaksjoner for å hente ut og putte inn informasjon. Applikasjoner sender spørringer til serveren for å få den informasjonen som er relevant, og trenger ikke å kunne tolke all informasjon i den digitale modellen. På grunn av dette er prosessen med å gjøre applikasjonene interoperabile med serveren langt enklere enn å gjøre applikasjonene direkte interoperabile med hverandre. Jeg vil derfor anbefale COWI å gå sammen med resten av byggenæringen for å påvirke applikasjonsleverandørene til å satse på kommunikasjon via servere. IFC-modellen kan benyttes ved en slik type kommunikasjon, men som omtalt i Kapittel 3 støtter IFC kun statiske datastrukturer, og ikke objekter i datateknisk forstand [Howie et al., 1996]. Med andre ord vil ikke IFC-modellen være et optimalt kommunikasjonsmedium mellom applikasjoner og databaser. Et alternativ å legge til rette for kommunikasjon via servere er bruk av mellomvare. Denne løsningen er nærmere beskrevet i Kapittel 3. For å utvikle en optimal løsning for kommunikasjonen via servere er man dog avhengig av at leverandørene gir hverandre innsyn i sine dataaksesslag og forretningslag og sammen blir enige om grunnprinsipper for hvordan informasjon skal deneres. Dette innebærer at leverandørene vil miste noen av sine konkurransefortrinn, og å få til et slikt samarbeid kan være utfordrende. Brukervennlighet og funksjonalitet vil bli desto viktigere faktorer, noe som vil være gunstig for forbrukerne. 70

85 8 Konklusjon og videre arbeid 8.1 Generelt Her presenteres konklusjonen for oppgaven og forslag til videre arbeid. 8.2 Konklusjon Testing av programvare Formålet med denne masteroppgaven har vært å teste interoperabiliteten mellom modelleringsapplikasjonen Revit Architecture og analyseapplikasjonene Ecotect Analysis og IES VE. IFC-modellen og gbxml-skjemaet ble brukt for å overføre informasjon fra Revit til henholdsvis Ecotect og IES VE. Før testene ble utført ble de to overføringsformatene vurdert, og det ble avdekket en rekke utfordringer: IFC Full interoperabilitet mellom applikasjoner ved kommunikasjon via IFCmodellen innebærer at alle applikasjonene må kunne importere all informasjonen i len, og i tillegg kunne eksportere all informasjon til samme format. Å oppnå full interoperabilitet ved en slik type kommunikasjon har vist seg å være svært utfordrende selv for overføring av enkle tekstdokumenter [Shah and Kesan, 2008], og for informasjon i en BIM blir oppgaven tilnærmet umulig. 71

86 IFC-modellen skal være et nøytralt format som kan overføre all type bygningsinformasjon mellom alle typer BIM-applikasjoner. Dette krever en stor generalitet og eksibilitet, noe som kan fører til tvetydighet [Marsh, 2006]. IFC-modellen støtter for eksempel ere ulike måter for å beskrive geometri. Hvis ikke alle applikasjonene vet hvordan denne informasjonen skal tolkes vil den gå tapt i overføringsprosessen. Modellen er svært omfattende og er derfor svært krevende å implementere i applikasjoner. Kommunikasjon via IFC-modellen krever re oversettelser, noe som er en forholdsvis besværlig prosess. IFC-modellen kan brukes for kommunikasjon via en server, men da IFCmodellen kun støtter statiske datastrukturer vil den ikke fungere optimalt for slik kommunikasjon. gbxml gbxml-formatet henter kun ut spesikk informasjon relevant for en analyseapplikasjon og gjør forenklinger i informasjonen. Dette er fordelaktig for analyseprogrammene, da formatet er enkelt å implementere. Slike forenklinger fører dog til at konverteringen ikke er en tapsfri prosess. Overføring via gbxml-formatet er derfor en enveiskommunikasjon fra modelleringsapplikasjonene til analyseapplikasjonene. gbxml-skjemaet representerer geometrien til overater ved hjelp av to attributter: plan polygongeometri og rektangulær polygongeometri. Kun rektangulær geometri kan representeres med disse to attributtene og representeringen av krumme ater vil derfor være en tilnærming. gbxml-skjemaet kan ikke overføre informasjon om materialegenskaper fra Revit Architecture til IES VE og denne informasjonen må legges inn manuelt. 72

87 Resultater A Prosjektinformasjon Lokasjon û ü Orientering ü ü Bygningstype û ü Enhetsbenevning û ü Objekttype Vindu û ü Dør û ü Tak ü ü Gulv ü ü Etasjeskiller û ü ü Yttervegg ü ü Innervegg û ü Søyle û û Rominformasjon Navn ü ü Volum û ü Plassering û ü Areal til avgrensende flater ü ü Veggeometri Plane vegger ü ü Enkeltkrummede vegger û ü Dobbeltkrummede vegger û ü Takgeometri Plane tak ü ü Enkeltkrummede tak û ü Dobbeltkrummede tak û û Materialegenskaper Ecotect via IFC IES VE via gbxml Materialegenskaper û û Figur 8.1: Sammendrag av resultatene fra de utførte testene Interoperabilitet mellom Revit Architecture og Ecotect Analysis via IFC IFC-modeller importert i Ecotect Analysis inneholdt informasjon om modellens orientering, men inneholdt derimot ikke informasjon om modellen sin lokasjon og Side 1 bygningstype. Romforekomstene i modellen inneholdt navn og areal til avgrensende ater, men rommenes plassering i forhold til hverandre var blitt endret og romvolum ble ikke direkte overført. Informasjon om dører og vinduer i de avgrensende atene ble ikke overført. Alle toppater til rommene ble satt til objekttypen tak, alle sideater til yttervegg og alle bunnater til gulv. Ingen informasjon om objektene sine materialegenskaper ble overført. Hvis modellen som ble overført inneholdt krumme ater ble ingen informasjon lastet inn i Ecotect. Resultatene fra testene viser at det foreløpig er store utfordringer knyttet til overføring av informasjon fra Revit Architecture og Ecotect Analysis via IFC- 73

88 modellen. Det ble ikke fastslått hvor i overføringsprosessen tap av informasjon forekom. Ecotect Analysis sin implementering av IFC-modellen er kun på Betastadiet. Ved en forbedring av Ecotect Analysis, Revit Architecture og IFCmodellen vil interoperabiliteten bli bedre, men man er foreløpig langt i fra å oppnå full interoperabilitet. Interoperabilitet mellom Revit Architecture og IES VE via gbxml gbxml-skjemaet er et overføringsmedium kun tiltenkt kommunikasjon fra en modelleringsapplikasjon til en analyseapplikasjon, og fungerer forholdsvis bra til dette formålet. gbxml-formatet overførte generell prosjektinformasjon som lokasjon, orientering og bygningstype til modellen. Romobjekters navn, volum, overateareal og plassering i forhold til hverandre ble overført. Ut i fra tilstøtende soner som omsluttet hver romsone ble romsonenes overatetyper bestemt. Vinduer og dører sin arealinformasjon og plassering ble overført, men ikek detaljer som vindussprosser og glassareal i dører. På grunn av gbxml-skjemaet sin måte å denere soner på kunne ikke søyler tas med i modellene. Ingen informasjon om materialegenskaper ble overført. Ved overføring av modeller som inneholdt dobbeltkrummede ater ble geometrien ofte unøyaktig, og i visse tilfeller ble ikke dobbeltkrummede takater en lukket ate. Muligheter for bedre interoperabilitet Den viktigste funksjonen til BIM er å legge til rette for bedre menneskelig samarbeid i byggebransjen. For å få til et godt samarbeid er man avhengig av god kommunikasjon [Eikeland, 2000]. Med hensyn til BIM fordrer god kommunikasjon at alle aktørene arbeider opp mot en felles modell. Dette kan gi en pålitelig informasjonsutveksling, og sikre at alle arbeider med gjeldende modell [Eastman et al., 2008]. En måte å gjennomføre dette på er ved at alle applikasjonene er koblet sammen via en server som inneholder en database hvor BIM er lagret. Kommunikasjon via en database-server reduserer utfordringene tilknyttet interoperabilitet. Kommunikasjonen mellom applikasjonene og serveren består av enkle transaksjoner for å hente ut og putte inn informasjon. Applikasjoner sender spørringer til serveren for å få den informasjonen som er relevant og trenger ikke å kunne tolke all informasjon i den digitale modellen. På grunn av dette er prosessen med å gjøre applikasjonene interoperabile med serveren langt enklere enn å gjøre applikasjonene direkte interoperabile med hverandre. 74

89 Full interoperabilitet mellom applikasjoner som kommuniserer via en server avhenger av at applikasjonsleverandørene gir hverandre innsyn i sine dataaksesslag og forretningslag og sammen blir enige om grunnprinsipper for hvordan informasjon skal deneres og overføres. Dette innebærer at leverandørene vil miste noen av sine konkurransefortrinn og brukervennligheten og funksjonaliteten til applikasjonene vil bli desto viktigere, noe som vil være gunstig for forbrukerne. Igangsettingen av et slikt samarbeid mellom applikasjonsleverandører avhenger av at aktørene i byggenæringen innser behovet for en slik kommunikasjonsmåte og at de sammen formidler dette behovet til applikasjonsleverandørene. Anbefalinger til COWI Ut ifra de konklusjonene som er gjort i denne masteroppgaven har følgende anbefalinger blitt gitt til COWI: Ved valget mellom IFC-modellen og gbxml-skjemaet anbefales COWI å benytte gbxml-skjemaet for overføring av informasjon til analyseapplikasjoner. Ved valget mellom Ecotect Analysis og IES VE anbefales COWI å ta i bruk IES VE. For å etablere full interoperabilitet ved bruk av BIM anbefales COWI på det sterkeste å videreformidle behovet for kommunikasjon via databaseservere overfor resten av byggenæringen og leverandørene av applikasjoner til byggenæringen. 8.3 Videre arbeid BIM og miljøvennlige bygg Denne oppgaven har vært konsentrert rundt interoperabilitet mellom modelleringsapplikasjoner og analyseapplikasjoner. Det vil være nyttig å kartlegge hva slags eekt bruken av BIM i byggeprosjekter har med hensyn på utviklingen av miljøvennlige bygg. Endring av arbeidsprosessen ved bruk av BIM I denne oppgaven har det blitt poengtert at BIM sin viktigste funksjon er å legge til rette for bedre samarbeid mellom aktørene i et byggeprosjekt. For å gå dypere inn i denne problemstillingen vil det være behov for å undersøke hvordan aktørene i 75

90 et byggeprosjekt arbeider og hvordan denne arbeidsprosessen endres ved bruk av BIM. Serverbasert kommunikasjon I denne oppgaven har det blitt konkludert med at man må gå over til serverbasert kommunikasjon hvis BIM fullt ut skal komme til sin rett. Det vil her være aktuelt å kartlegge hva slags teknologi som eksisterer på dette området, hvor godt denne teknologien fungerer og å vurdere muligheten for videre utvikling. Kartlegging av interoperabilitetsproblemer En rekke utfordringer ved interoperabilitet har blitt nevnt i denne oppgaven. Å kartlegge konsekvensene av interoperabilitetsproblemer under byggeprosjekter vil være nyttig for å rette søkelyset på denne problematikken. Defenisjon av BIM I denne oppgaven har det blitt nevnt at det ikke eksisterer en entydig og presis denisjon for hva BIM er. Etableringen av en slik denisjon vil være gunstig for å identisere grensene og dermed manglene til BIM og dermed gi et utgangspunkt for målrettet å jobbe for å forbedre disse manglene. 76

91 Bibliogra [Abdalla and Powell, 1995] Abdalla, J. and Powell, G. (1995). An object design framework for structural engineering. Engineering with Computers, 11(4): [Architosh, 2010] Architosh (2010) BIM survey full report. [Autodesk, 2007] Autodesk (2007). Transitioning to BIM. Technical report, Autodesk Inc. [Autodesk, 2009a] Autodesk (2009a). Revit 2010 to autodesk.com/forums/message.jspa?messageid= [Autodesk, 2009b] Autodesk (2009b). Revit Architecture 2010 User's Guide. [Autodesk, 2010a] Autodesk (2010a). Autodesk revit [Autodesk, 2010b] Autodesk (2010b). Ecotect 2011 User's Guide. [Barnaby et al., 2005] Barnaby, C., Spitler, J., and Xiao, D. (2005). The residential heat balance method for heating and cooling load calculations. ASH- RAE Transactions. [Becla and Wang, 2005] Becla, J. and Wang, D. (2005). Lessons learned from managing a petabyte. In Conference on Innovative Data Systems Research, pages Citeseer. [Bourarsa, 2005] Bourarsa, N. (2005). Estimating Energy Use Early and Often. Public Interest Energy Research, California Energy Commission. CEC FS. [buildingsmart, 2010a] buildingsmart (2010a). About us. iai-tech.org/about-us/?searchterm=modelup [buildingsmart, 2010b] buildingsmart (2010b). Iai tech international. http: // Summary of ifc relea- [buildingsmart, 2010c] buildingsmart (2010c). ses [Chris I. Yessios, 2004] Chris I. Yessios, P. (2004). Are we forgetting design?

92 [CIBSE, 1999] CIBSE, E. (1999). CIBSE Guide A. The Chartered Institution of Building Services Engineers, London. [Conradie, 2009] Conradie, D. (2009). Building information modelling (BIM). Green Building. [Dong et al., 2007] Dong, B., Lam, K., Huang, Y. C., and Dobbs, G. M. (2007). A comparative study of the IFC and gbxml informational infrastructures for data exchange in computational design support environments. In Building Simulation 2007, pages [Eastman, 1999] Eastman, C. (1999). Building product models: computer environments supporting design and construction. CRC. [Eastman et al., 2008] Eastman, C., Teicholz, P., Sacks, R., and Liston, K. (2008). BIM Handbook: A guide to building information modeling for owners, managers, designers, engineers, and contractors. John Wiley & Sons Inc. [Eikeland, 2000] Eikeland, P. (2000). Teoretisk analyse av byggeprosesser. Samspill i byggeprosessen, prosjektnr [Engelbart, 2003] Engelbart, D. (2003). Improving Our Ability to Improve: A Call for Investment in a New Future. IBM Co-Evolution Symposium. [Frej and Anne, 2005] Frej, A. and Anne, B. (2005). Green Oce Buildings: A practical guide to development. Washington, DC: ULIthe Urban Land Institute. [gbxml, 2010] gbxml (2010). Open green building xml schema: a building information modeling solution for our green world [Graphisoft, 2009] Graphisoft (2009). BIM curriculumn. Technical report, Graphisoft Inc. [Graphisoft, 2010] Graphisoft (2010). The archicad solution. graphisoft.com/community/why_switch/the_archicad_solution.html [GSA PBS OCA, 2007] GSA PBS OCA (2007). GSA BIM guide overview series 01 section 01: GSA national 3d-4d-BIM program. Technical report, U.S. General Services Administration. [Haefele, 2008] Haefele, K. H. (2008). Basic informations. org/index.php/basic_informations [Hansen, 2006] Hansen, T. B. (2006). Modellering av objektorienterte systemer. Technical report, Høgskolen i Sør-Trøndelag. 78

93 [Haraldsen, 1999] Haraldsen, A. (1999). Den forunderlige reisen gjennom datahistorien. Tano/Universitetsforlaget. [Hensen and Radosevic, 2004] Hensen, J. and Radosevic, M. (2004). Teaching building performance simulation-some quality assurance issues and experiences. In Proc. Int. Conference on Passive and Lowenergy ArchitecturePLEA, pages 18. [Howard and Bjørk, 2008] Howard, R. and Bjørk, B. (2008). Building information modelling - Experts views on standardisation and industry deployment. Advanced Engineering Informatics, 22(2): [Howie et al., 1996] Howie, C., Kunz, J., and Law, K. (1996). Software interoperability. Stanford University, USA dacs. dtic. mil/techs/interop/title. shtml, accessed January, 20:2003. [Idehen, 1993] Idehen, K. (1993). ODBC technical white paper. openlinksw.com/info/docs/odbcwhp/tableof.htm [IES VE, 2009] IES VE (2009). BIM + Building Performance Analysis Using Revit 2010 and IES <Virtual Environment>. [IES VE, 2010] IES VE (2010). IES VE User's Guide. [ISO, 2010] ISO (2010). Tc 184/sc 4. development/technical_committees/other_bodies/iso_technical_committee.htm? commid= [Jongeling, 2008] Jongeling, R. (2008). BIM istället för 2D-CAD i byggprojekt. Technical report, Civil and Environmental Engineering, Luleå University of Technology, Luleå, Sweden. [Kalstveit, 1997] Kalstveit, E. (1997). Digitale Produktmodeller i byggenæringen. PhD thesis, NTNU, Institutt for konstruksjonsteknikk. [Kemmerer, 1999] Kemmerer, S. (1999). STEP: The grand experience. of) NIST Special Publication 939, National Institute of Standards and Technology, Gaithersburg, MD, [Kennedy, 2010] Kennedy, J. F., editor (2010). Green Building XML: Enabling disruptive technologies today! [Khemlani, 2004] Khemlani, L. (2004). The ifc building model: A look under the hood

94 [Kommunal- og regionaldepartementet, 2009] Kommunal- og regionaldepartementet (2009). Bygg for framtida. Miljøhandlingsplan for bolig- og byggsektoren Grøset. [Kommunal- og regionaldepartementet, 2010] Kommunal- og regionaldepartementet (2010). Forskrift om tekniske krav til byggverk (byggteknisk forskrift) [Krakowiak, 2003] Krakowiak, S. (2003). What is middleware. This is an electronic document. Date of publication: January. [Krygiel and Nies, 2008] Krygiel, E. and Nies, B. (2008). Green BIM: Successful sustainable design with building information modeling. Wiley. [Laiserin, 2002] Laiserin, J. (2002). Comparing pommes and naranjas. http: // [Liebich and Wix, 2000] Liebich, T. and Wix, J. (2000). IFC Technical Guide. International Alliance for Interoperability. [Marsh, 2006] Marsh, D. A. J. (2006). Cad geometry vs performance analysis. Natural Frequency. [Marton, 2008] Marton, I. (2008). Miljø i byggeprosessen. no/ [MSG, 2010] MSG (2010). IFC documentation. IFC2x4/beta3/html/index.htm [Norconsult, 2010] Norconsult (2010). BIM-kalkyle med Informasjonssystemer (ISY) calcus [OpenSpirit, 2010] OpenSpirit (2010). Enabling cross-discipline collaboration in the digital oileld [Oracle Corporation, 2010] Oracle Corporation (2010). Many technologies, one platform [Petersen, 2010] Petersen, A. (2010). BIM i Energi- og klimaberegninger. [Seletsky, 2004] Seletsky, P. (2004). Goodbye cad. goodbye bim. hello pen. http: // [Shah and Kesan, 2008] Shah, R. and Kesan, J. (2008). Lost in Translation: Interoperability Issues for Open StandardsODF and OOXML as Examples. University of Illinois Legal Working Paper Series, page

95 [Simensen, 2010] Simensen, K. H. (2010). Informasjon om openspirit. Samtale med tidligere programmerer for Schlumberger. [Standard Norge, 2007] Standard Norge (2007). NS 3031:2007 Beregning av bygningers energiytelse Metode og data. Technical report, Standard Norge. [Statsbygg, 2010] Statsbygg (2010). Miljøprogram. miljoprogrammering.no/ [Svendsen, 2007] Svendsen, P. A. (2007). Eu knuser windows-monopolet. http: // [Syvertsen, 2009] Syvertsen, T. G. (2009). TKT4505 Objektmodellering. Forelesning. [Wikipedia, 2010] Wikipedia (2010). Top-down and bottom-up design. http: //en.wikipedia.org/wiki/top-down_and_bottom-up_design [Yudelson, 2008] Yudelson, J. (2008). Green building through integrated design. McGraw-Hill Professional. 81

96 Vedlegg 82

97 A Eksempel på hvordan attributter arves i IFC ENTITY IfcBeam SUBTYPE OF (IfcBuildingElement); END_ENTITY; ENTITY IfcBeam; ENTITY IfcRoot; GlobalId : IfcGloballyUniqueId; OwnerHistory : IfcOwnerHistory; Name : OPTIONAL IfcLabel; Description : OPTIONAL IfcText; ENTITY IfcObjectDefinition; INVERSE HasAssignments : SET OF IfcRelAssigns FOR RelatedObjects; IsDecomposedBy : SET OF IfcRelDecomposes FOR RelatingObject; Decomposes : SET [0:1] OF IfcRelDecomposes FOR RelatedObjects; HasAssociations : SET OF IfcRelAssociates FOR RelatedObjects; ENTITY IfcObject; ObjectType : OPTIONAL IfcLabel; INVERSE IsDefinedBy : SET OF IfcRelDefines FOR RelatedObjects; ENTITY IfcProduct; ObjectPlacement : OPTIONAL IfcObjectPlacement; Representation : OPTIONAL IfcProductRepresentation; INVERSE ReferencedBy : SET OF IfcRelAssignsToProduct FOR RelatingProduct; ENTITY IfcElement; Tag : OPTIONAL IfcIdentifier; INVERSE HasStructuralMember : SET OF IfcRelConnectsStructuralElement FOR RelatingElement; FillsVoids : SET [0:1] OF IfcRelFillsElement FOR RelatedBuildingElement; ConnectedTo : SET OF IfcRelConnectsElements FOR RelatingElement; HasCoverings : SET OF IfcRelCoversBldgElements FOR RelatingBuildingElement; HasProjections : SET OF IfcRelProjectsElement FOR RelatingElement; ReferencedInStructures : SET OF IfcRelReferencedInSpatialStructure FOR RelatedElements; HasPorts : SET OF IfcRelConnectsPortToElement FOR RelatedElement; HasOpenings : SET OF IfcRelVoidsElement FOR RelatingBuildingElement; IsConnectionRealization : SET OF IfcRelConnectsWithRealizingElements FOR RealizingElemen ProvidesBoundaries : SET OF IfcRelSpaceBoundary FOR RelatedBuildingElement; ConnectedFrom : SET OF IfcRelConnectsElements FOR RelatedElement; ContainedInStructure : SET [0:1] OF IfcRelContainedInSpatialStructure FOR RelatedElements ENTITY IfcBuildingElement; ENTITY IfcBeam; END_ENTITY; Figur A.1: Arv av attributter for IFC BEAM 83

98 B Eksempel på oppbygningen av et gbxml-element Eksempel på oppbygning av gbxml-element <gbxml> <Campus> <Surface id="su1" surfacetype="exteriorwall"> <AdjacentSpaceId spaceidref="sp1" /> <RectangularGeometry> <Azimuth>0</Azimuth> <CartesianPoint> <Coordinate>2224</Coordinate> <Coordinate> </Coordinate> <Coordinate>4</Coordinate> </CartesianPoint> <Tilt>90</Tilt> <Height>96</Height> <Width>42.81</Width> </RectangularGeometry> <PlanarGeometry> <PolyLoop> <CartesianPoint> <Coordinate>2224</Coordinate> <Coordinate> </Coordinate> <Coordinate>4</Coordinate> </CartesianPoint> </PolyLoop> </PlanarGeometry> </Surface> </Campus> </gbxml> Figur B.1: Oppbygning av Exterior Wall i gbxml 84

99 C Import- og eksportevne til programvare Autodesk Revit Import AutoCAD DWG Files AutoCAD DXF Files Industry Foundation Classes Autodesk Revit Files Autodesk Revit Files *.DWG *.DXF *.IFC *.RVT *.RFA Figur C.1: Autodesk Revit 2011 Importevne [Autodesk, 2010a] Eksport AutoCAD DWG Files AutoCAD DXF Files AutoCAD DGN Files ACIS CAD Files Autodesk Design Web Format Autodesk Design Web Format Autodesk FBX Files Industry Foundation Classes Green Building XML Autodesk Revit Files Autodesk Revit Files *.DWG *.DXF *.DGN *.SAT *.DWF *.DWFx *.FBX *.IFC *.XML *.RVT *.RFA Figur C.2: Autodesk Revit 2011 Eksportevne [Autodesk, 2010a] 85

100 Autodesk Ecotect Import ASCII Model Files *.MOD Analysis grid Data Files *.GRD Ray/Particle Data Files *.RAY Weather data files *.WEA Radiance Point Value data *.DAT Radiance Scene Files *.RAD EnergyPlus Input data File *.IDF Energy Plus Model summary *.EIO AutoCAD DXF Files *.DXF Stereo lithography file *.STL Green Building XML *.XML Industry Foundation Classes *.IFC Google KML Data *.KML/KMZ HPGL Plot Files *.PLT og *.HGL Material Library Files *.LIB CFD Output Data File *.* Windows Bitmap *.BMP JPEG Image *.JPG Figur C.3: Model/Analysis Data [Autodesk, 2010a] 86

101 DXF DXF Point Cloud IFF to 3D IFF to DEM Imagine Lightscape Lightwave Maya RTG MaxNC Digital probe MicroDEM Open Inventor RealiMation Renderware Scenery animator Sculpt Shopbot Digital Probe SoftimageXSI StereoLithography truespace USGS GTOPO30/SRTM30 USGS 1 degree DEM USGS SDTS USGS SRTM-1/SRTM-3 Videoscape VistaPro VRML Wavefront X3D XGL, ZGL XYZ XYZ (No Mesh) *.DXF *.DXF *.IFF *.IFF *.IOB *.LP *.LWO *.RTG *.TXT *.DEM *.IV *.RBS *.RWX *.LAND *.SCENE *.SBP *.XSI *.STL.COB og *.COA *.DEM *.DEM *.DDF *.HGT *.GEO *.DEM *.WRL *.OBJ *.X3D *.XGL og *.ZGL *.XYZ *.XYZ Figur C.4: 3D CAD Geometry [Autodesk, 2010a] 87

102 Eksport ASCII Model Files Ray/Particle Data Files Analysis grid Data Files Material Library Files *.MOD *.RAY *.GRD *.LIB Figur C.5: Model/Analysis Data [Autodesk, 2010a] Radiance Scene Files *.RAD Radiance Octree Files *.OCT POV Ray Scene files *.POV VRML Scene files *.WRL AutoCAD DXF Files *.DXF EnergyPlus Input data File *.IDF DOE-2 Input Files *.INP SBEM Input Files *.INP AIOLOS Input Files *.PPA HTB2 Files *.TOP Accurate Scratch file *.* ESP-r input File *.CFG WinAir4 CFD Geometry File *.GEO NIST FDS Input data File *.fds Green Building XML *.XML Figur C.6: External Analysis Tool [Autodesk, 2010a] Windows metafile Windows bitmap Graphics Interchange Format JPEG Image *.WMF *.BMP *.GIF *.JPG Figur C.7: Image/Screenshot [Autodesk, 2010a] 88

103 IES VE Import Geometry File Green Building XML *.GEM *.XML Figur C.8: IES VE Importevne [IES VE, 2010] Eksport Geometry File 3D System ASCII File AutoCAD DXF Files *.GEM *.STL *.DXF Figur C.9: IES VE Eksportevne [IES VE, 2010] 89

104 D gbxml-elementer og -attributter som støttes av Revit Architecture 2011 gbxml Element Figur D.10: gbxml Element [Autodesk, 2009b] Campus Element Figur D.11: Campus Element [Autodesk, 2009b] 90

105 DocumentHistory Element Figur D.12: DocumentHistory Element [Autodesk, 2009b] Location Element Figur D.13: Location Element [Autodesk, 2009b] Building Element Figur D.14: Building Element [Autodesk, 2009b] 91

106 Space Element Figur D.15: Space Element [Autodesk, 2009b] ShellGeometry Element Figur D.16: ShellGeometry Element [Autodesk, 2009b] 92

107 SpaceBoundary Element Figur D.17: SpaceBoundary Element [Autodesk, 2009b] 93

108 Surface Element Figur D.18: Surface Element [Autodesk, 2009b] 94

109 Opening Element Figur D.19: Opening Element [Autodesk, 2009b] 95