BIM og Miljøberegning
NTNU Norges teknisk-naturvitenskapelige universitet Fakultet for Ingeniørvitenskap og teknologi Institutt for konstruksjonsteknikk Masteroppgave Karl Kristian Olsson Haave BIM og Miljøberegning 14. juni 2010 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: BIM og Miljøberegning BIM and Environmental Analysis UTFØRT AV: 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 6.0.6 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. 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. Besvarelsen organiseres i henhold til gjeldende retningslinjer for masteroppgaver ved institutt for konstruksjonsteknikk. Kontaktperson hos bedrift: Navn: Dagfinn Bell Epost: dbe@cowi.no Tlf: 93081497 Navn: Ingrid Alvsåker Epost: ial@cowi.no Tlf: Veileder: 48991094 Navn: Tor G. Syvertsen Epost: torgsyv@gmail.com Tlf: 73594681 Besvarelsen skal leveres til Institutt for konstruksjonsteknikk senest 14. juni 2010 Trondheim, 21.01.10 Tor G. Syvertsen faglærer 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 ved NTNU Professor Tor G. Syvertsen for hjelp til å stille de rette spørsmålene og for alltid å være en ariadnetråd. Jeg ønsker også å takke COWI Dagnn Bell da spesielt Ingrid Alvsåker og 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 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 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 Innhold Forord I Sammendrag II Innhold IV Akronymer VII Figurer IX 1 Innledning 2 1.1 Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 BIM og miljøvurdering . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Oppgavens formål og omfang . . . . . . . . . . . . . . . . . . . . 4 1.4 Metodikk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5 Disposisjon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 Building Information Model/Modelling (BIM) 7 2.1 Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Objektmodellering . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Hva er BIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4 Oppsummering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3 Interoperabilitet 15 3.1 Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2 Overføringsformater 15 3.3 Kommunikasjon via loverføring 3.4 Kommunikasjon via database-server 3.5 IFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 . . . . . . . . . . . . . . . . 17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 IV 3.6 Green Building Extensible Markup Language (gbXML) . . . . . 28 3.7 Sammenligning av IFC og gbXML . . . . . . . . . . . . . . . . . 31 4 Programvare 33 4.1 Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2 Autodesk Revit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3 Autodesk Ecotect . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.4 IES VE 43 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Målemetode 48 5.1 Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.2 Innstillinger i Revit . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.3 Testmodeller 53 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Resultater 57 6.1 Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.2 Presentasjon av resultatene . . . . . . . . . . . . . . . . . . . . . 57 6.3 Sammendrag av resultatene . . . . . . . . . . . . . . . . . . . . . 64 6.4 Drøfting av resultatene . . . . . . . . . . . . . . . . . . . . . . . . 66 7 Anbefaling til COWI i forhold til BIM og miljøvurdering 67 7.1 Situasjonen i dag . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 7.2 Fremtidig arbeid med BIM og miljøvurdering 69 . . . . . . . . . . . 8 Konklusjon og videre arbeid 71 8.1 Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 8.2 Konklusjon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 8.3 Videre arbeid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Kildeliste 77 V Vedlegg 82 A Eksempel på hvordan attributter arves i IFC . . . . . . . . . . . 83 B Eksempel på oppbygningen av et gbXML-element . . . . . . . . . 84 C Import- og eksportevne til programvare 85 D . . . . . . . . . . . . . . gbXML-elementer og -attributter som støttes av Revit Architecture 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 E IFC-avbildingsl F Resultater fra Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . 104 G Resultater fra Test 2 . . . . . . . . . . . . . . . . . . . . . . . . . 105 VI 96 Akronymer 3D tredimensjonal AEC Architecture, Engineering and Construction API Application programming interface ASHRAE American Society of Heating, Refrigeration and Air-Conditioning Engineers BIM Building Information Model/Modelling CAD Computer Aided Design CDF Computational Fluid Dynamics CEC California Energy Commission CIBSE Chartered Institution of Building Services Engineers CIS/2 Cimsteel Integration Standard version 2 DAYSIM Dynamic Daylight Simulations DXF Data eXchange Format EPD Environmental Product Declaration FDS Fire Dynamics Simulator GARM General AEC Reference Model GBS Green Building Studio Inc. gbXML Green Building Extensible Markup Language GSA General Services Administration GUI Graphical User Interface HTML HyperText Markup Language HVAC Heating, Ventilating and Air Conditioning IAI International Alliance for Interoperability IDM Integrated Data Model IES Integrated Environmental Solutions VII IFC Industry Foundation Classes ISO International Organization for Standardization ISY Informasjonssystemer IT Informasjonsteknologi JDBC Java Database Connectivity MSG Model Support Group NIST National Institute of Standards and Technology NURBS Non Uniform Rational Basis Spline OCA Oce of the Chief Architect ODBC Open Database Connectivity OMT Object Modeling Technique OOP Objekt Oriented Programming PCE Parametric Change Engine PBS Public Buildings Service PGE Pacic Gas and Electric PIER Public Interest Energy Research RDB Revit Database SIMIEN SIMulering av Inneklima og ENergibruk i bygninger SIMULA SIMulation LAnguage SQL Structured Query Language STEP STandard for the Exchange of Product model data UML Unied Modeling Language VE Virtual Environment WWW World Wide Web X3D Extensible 3D Graphics XML Extensible Markup Language VIII Figurer 2.1 Utvikling innen BIM [Howard and Bjørk, 2008] . . . . . . . . . . 8 2.2 Objektmodell av OMT [Syvertsen, 2009] . . . . . . . . . . . . . . 9 2.3 Utviklingen av Computer Aided Design (CAD) [Graphisoft, 2009] 11 2.4 Informasjonsyt i BIM . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1 Kommunikasjon via loverføring . . . . . . . . . . . . . . . . . . 16 3.2 Kommunikasjonsmåte med én leverandør . . . . . . . . . . . . . . 18 3.3 Kommunikasjon via mellomvare . . . . . . . . . . . . . . . . . . . 19 3.4 Kommunikasjon via åpne datamodellformater . . . . . . . . . . . 20 3.5 IFC sin systemarkitektur [Model Support Group (MSG), 2010]. . 24 3.6 Dataoverføring via International Organization for Standardization (ISO)-STandard for the Exchange of Product model data (STEP) Part-21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.7 Avvik ved overføring mellom applikasjoner [Kalstveit, 1997]. . . . 28 3.8 Sammenligning av IFC-modellen [buildingSMART, 2010b] og gbXMLskjemaet [gbXML, 2010] . . . . . . . . . . . . . . . . . . . . . . . 31 4.1 Verktøylinjen til Autodesk Revit 34 4.2 Autodesk Revit sitt Graphical User Interface (GUI) 4.3 Inndeling av informasjon i Autodesk Revit [Autodesk, 2009b] 4.4 Eksportering til gbXML-formatet i Revit 4.5 Informasjonsorganisering i gbXML [Autodesk, 2009b]. 4.6 Autodesk Ecotect sitt GUI . . . . . . . . . . . . . . . . . . . . . . . . . 35 . . 36 . . . . . . . . . . . . . 38 . . . . . . 39 . . . . . . . . . . . . . . . . . . . . . 40 4.7 Import av IFC i Ecotect . . . . . . . . . . . . . . . . . . . . . . . 42 4.8 IES VE sitt GUI [IES VE, 2010] 43 4.9 De ulike variantene av IES VE [IES VE, 2010] . . . . . . . . . . . . . . . . . . 4.10 Importering av gbXML-l i IES VE IX . . . . . . . . . . 44 . . . . . . . . . . . . . . . . 46 4.11 Kontroll av rom i modell som skal importeres 4.12 IES VE PlugIn til Autodesk Revit . . . . . . . . . . . 47 . . . . . . . . . . . . . . . . . 47 5.1 Energy Settings i Revit . . . . . . . . . . . . . . . . . . . . . . 49 5.2 Endring av modellens orientering i Revit . . . . . . . . . . . . . . 49 5.3 Room Bounding attributt i Revit . . . . . . . . . . . . . . . . . . 50 5.4 Justering av sonehøyde i Autodesk Revit 2011 . . . . . . . . . . . 50 5.5 Romvolum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.6 Menyen IFC Options . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.7 Feilmelding i Revit . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.8 Redigering av faser i Revit . . . . . . . . . . . . . . . . . . . . . . 53 5.9 Modell laget i Revit for Test 1 . . . . . . . . . . . . . . . . . . . 54 5.10 Modell laget i Revit for Test 2 . . . . . . . . . . . . . . . . . . . 54 5.11 Modeller laget i Revit for Test 3 . . . . . . . . . . . . . . . . . . 55 5.12 Modeller laget i Revit for Test 4 . . . . . . . . . . . . . . . . . . 55 . . . . . . . . . . . . . . . . . . . 56 6.1 Modell fra Test 2 lastet inn i Ecotect Analysis . . . . . . . . . . . 58 6.2 Modell fra Test 2 lastet inn i IES VE . . . . . . . . . . . . . . . . 59 6.3 Modell med mangekantet vegg lastet inn i Ecotect Analysis . . . 60 6.4 Modeller fra Test 3 lastet inn i IES VE . . . . . . . . . . . . . . . 61 6.5 Modell med gavltak fra Test 4 lastet inn i Ecotect Analysis . . . 61 6.6 Modeller fra Test 4 lastet inn i IES VE . . . . . . . . . . . . . . . 62 6.7 Modell fra Test 5 lastet inn i Ecotect Analysis . . . . . . . . . . . 63 6.8 Sammendrag av resultatene fra de utførte testene . . . . . . . . . 64 6.9 Bygningskomponentenes hiearkiske inndeling i IES VE . . . . . . 65 8.1 Sammendrag av resultatene fra de utførte testene . . . . . . . . . 73 A.1 Arv av attributter for IFC BEAM 83 5.13 Modell laget i Revit for Test 5 X . . . . . . . . . . . . . . . . . B.1 Oppbygning av Exterior Wall i gbXML . . . . . . . . . . . . . . C.1 Autodesk Revit 2011 Importevne [Autodesk, 2010a] . . . . . . . 85 C.2 Autodesk Revit 2011 Eksportevne [Autodesk, 2010a] . . . . . . . 85 C.3 Model/Analysis Data [Autodesk, 2010a] . . . . . . . . . . . . . . 86 C.4 tredimensjonal (3D) CAD Geometry [Autodesk, 2010a] . . . . . . 87 C.5 Model/Analysis Data [Autodesk, 2010a] . . . . . . . . . . . . . . 88 C.6 External Analysis Tool [Autodesk, 2010a] . . . . . . . . . . . . . 88 C.7 Image/Screenshot [Autodesk, 2010a] . . . . . . . . . . . . . . . . 88 C.8 IES VE Importevne [IES VE, 2010] . . . . . . . . . . . . . . . . . 89 C.9 IES VE Eksportevne [IES VE, 2010] . . . . . . . . . . . . . . . . 89 D.10 gbXML Element [Autodesk, 2009b] . . . . . . . . . . . . . . . . . 90 D.11 Campus Element [Autodesk, 2009b] 90 . . . . . . . . . . . . . . . . D.12 DocumentHistory Element [Autodesk, 2009b] 84 . . . . . . . . . . . 91 D.13 Location Element [Autodesk, 2009b] . . . . . . . . . . . . . . . . 91 D.14 Building Element [Autodesk, 2009b] . . . . . . . . . . . . . . . . 91 D.15 Space Element [Autodesk, 2009b] . . . . . . . . . . . . . . . . . . 92 D.16 ShellGeometry Element [Autodesk, 2009b] . . . . . . . . . . . . . 92 D.17 SpaceBoundary Element [Autodesk, 2009b] . . . . . . . . . . . . 93 D.18 Surface Element [Autodesk, 2009b] . . . . . . . . . . . . . . . . . 94 D.19 Opening Element [Autodesk, 2009b] 95 E.20 IFC-avbildingsl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 F.21 Resultater fra Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . 104 G.22 Resultater fra Test 2 . . . . . . . . . . . . . . . . . . . . . . . . . 105 1 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 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 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 6.0.6. 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 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 www.google.com. 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 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 ka- pittelet 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 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 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 Figur 2.2) og senere Unied Modeling Language (UML). OMT består av de tre aspektmodellene objektmodell, dynamisk modell og funksjonsmodell [Syvertsen, 2009]. OMT Dynamisk modell Objektmodell Assosiasjon Klasse Tilstand Funksjonsmodell 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 be- skriver 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 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å 70tallet. 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 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 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, ArchiCAD, 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 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å Building Owner Developer Contractor Quantity Surveyor/ Cost Planner Facility Manager Users Product Manufacturers BIM MODEL Information Providers Architect/ Interior Designers Government Agencies Engineer Building Certifier Figur 2.4: Informasjonsyt i BIM til et godt samarbeid er man avhengig av god kommunikasjon [Eikeland, 2000]. 13 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 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 pro- gramleverandører for at to applikasjoner skal kunne kommunisere seg imellom. 15 Proprietære lformater Proprietære lformater utviklet av programleveran- dø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å standardi- serte 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 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 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 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 IMPORT EKSPORT Applikasjon B Applikasjon A EKSPORT EKSPORT IMPORT IMPORT 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 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 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. 3.2.2.1) 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 1995. 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 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 2007. Det er denne versjonen som brukes av Revit Architecture og Ecotect Analysis. Utviklingen av IFC 2x4 er allerede i gang [buildingSMART, 2010c]. 23 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 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 denert 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 IFC- modellen. 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 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; IfcBuildingElement; 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 Import Oversettelse Eksport Oversettelse Datastruktur P-21 Oversettelse P-21 Oversettelse Datastruktur Figur 3.6: Dataoverføring via ISO-STEP Part-21 26 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 bruker NURBS, blir geometrien omdenert til et polygon som en tilnærming [Kalstveit, 1997]. Applikasjon A Nøytralt Format Applikasjon B SIRKEL 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 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 0.37. 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å spesikt 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 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 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 A gbXML IFC File Description, File name and file schema File Version Units Organization, Person, owner history. Units Campus ID Cartesian points, direction, dimensional exponents, shape representation Location Product definition and shape. Property value Area, Volume Predefined element parameters Description Material, layer set, Color. Shell Geometry ID Building ID 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 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 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 2000. 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 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 2007. 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 Modify Verktøy for å legge til 2D informasjon i modellen. Verktøy for å endre eksisterende elementer, data og systemer i model- len. Massing & Site Collaborate View Verktøy for mengdeberegninger og lokalisering av bygget. Verktøy for at ere skal kunne arbeide sammen på en modell. 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 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 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 Loadable families Disse familiene er lagret i Revit sitt bibliotek utenfor pro- sjektet 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 2011. 37 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 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 2011. 4.3 Autodesk Ecotect Introduksjon Autodesk Ecotect ble kjøpt opp av Autodesk i 2008. 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 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 program- met. Paneler På høyre side kan man velge mellom ulike faner. Disse fanene inne- holder 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 visuali- seringsmåter. Her kan man velge og legge til elementer. Sider På venstre hånd nner man faner man kan bruke for å veksle mellom uli- ke 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 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) Radiance Simulering av dagslys Simulering av lys Chartered Institution of Building Services Engineers (CIBSE) Energy+ Energianalyser 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 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 denert 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 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 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 IES <Virtual Product Overview V6.0 i designprosessen for Environment> å vurdere konsekvensene av ulike 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: INTEGRATED ENVIRONMENTAL for å analysere bygningen blir lagret. SOLUTIONS LIMITED Date: Monday 19 October 2009 BOSTON, MA │ GLASGOW, SCOTLAND │ DUBLIN, IRELAND │ LONDON, ENGLAND │ MELBOURNE, AUSTRALIA │ SAN FRANCISCO, CA │ DUBAI, UAE Figur 4.9: De ulike variantene av IES VE [IES VE, 2010] 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 å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 å vur- dere byggets termiske egenskaper. ApacheHVAC SunCast Simulering av Heating, Ventilating and Air Conditioning (HVAC). 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 ventilasjonskana- ler. PiscesPro Simulex Lisi PiscesPro brukes for å designe røroppleggsystemer. Simulex simulerer en evakuering av bygget. Med Lisi kan man designe og simulere heisløsninger for å optimalisere transporteringen av personer i bygningen. 45 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 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 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 6.0.6. 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 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 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 2011 50 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 eller underkategori med en tilhørende IFC-klasse. Blanke felt vil Revit automatisk tolke for å tildele samsvarende klasse. Felt med teksten Not Exported 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 overaten (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 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 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 med forskjellig type veggeometri. Se Figur 5.11 for eksempler på modeller laget for Test 3. (a) Modell med mange- (b) Modell med en- (c) Modell med dobbeltkrumkantet vegg keltkrummet vegg met 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 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 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 Enhet Informasjon om bygningstype ble ikke overført til Ecotect. Hvilke enheter som ble brukt i modellen ble ikke endret i Ecotect, men tallverdiene ble konvertert til riktig verdi. 57 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 Enhet Informasjon om bygningstype ble overført til IES VE. 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 plas- sering 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 Eco- tect, 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 Dørtype I IFC-malen som ble brukt for å lage modeller for overføring til Eco- tect 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 Innerveggtype Ingen informasjon om etasjeskiller ble lastet inn i Ecotect. Geometri til innervegger ble lastet inn i modellen, men type- informasjonen 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 Eco- tect. 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 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 geome- trisk 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 mo- dellen. 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 IES VE (a) Modell med mangekantet (b) Modell med enkeltkrum- (c) Modell med dobbeltvegg met vegg krummet vegg Figur 6.4: Modeller fra Test 3 lastet inn i IES VE 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 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 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 6.3 Sammendrag av resultatene A Ecotect via IFC IES VE via gbXML 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 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- Side 1 64 ü 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 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 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 15265 [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 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 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 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 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 • 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 Resultater A Ecotect via IFC IES VE via gbXML 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 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 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 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 in- teroperabilitet 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 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 in- teroperabilitet 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 eksiste- rer 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 Bibliogra [Abdalla and Powell, 1995] Abdalla, J. and Powell, G. (1995). sign framework for structural engineering. An object de- Engineering with Computers, 11(4):213226. [Architosh, 2010] Architosh (2010). 2010 BIM survey full report. [Autodesk, 2007] Autodesk (2007). Transitioning to BIM. Technical report, Autodesk Inc. [Autodesk, 2009a] Autodesk (2009a). Revit 2010 to 2009. autodesk.com/forums/message.jspa?messageID=6186338. [Autodesk, 2009b] Autodesk (2009b). http://discussion. 23.05.10. Revit Architecture 2010 User's Guide. [Autodesk, 2010a] Autodesk (2010a). Autodesk revit. http://www.autodesk.com. 15.05.2010. [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 7083. Citeseer. [Bourarsa, 2005] Bourarsa, N. (2005). Estimating Energy Use Early and Often. Public Interest Energy Research, California Energy Commission. CEC-5002005-140-FS. [buildingSMART, 2010a] buildingSMART (2010a). iai-tech.org/about-us/?searchterm=modelup. http://www. About us. 12.04.10. [buildingSMART, 2010b] buildingSMART (2010b). Iai tech international. //www.iai-tech.org. 10.04.10. [buildingSMART, 2010c] buildingSMART ses. http: (2010c). Summary of ifc relea- http://www.iai-tech.org/products/ifc_specification/ifc-releases/summary. 11.04.10. [Chris I. Yessios, 2004] Chris I. Yessios, P. (2004). Are we forgetting design? http://www.aecbytes.com/viewpoint/2004/issue_10.html. 77 16.04.10. [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 Simulation 2007, Building pages 15301537. Building product models: computer environments supporting design and construction. CRC. [Eastman, 1999] Eastman, C. (1999). [Eastman et al., 2008] Eastman, C., Teicholz, P., Sacks, R., and Liston, K. BIM Handbook: A guide to building information modeling for owners, managers, designers, engineers, and contractors. John Wiley & Sons (2008). Inc. [Eikeland, 2000] Eikeland, P. (2000). Teoretisk analyse av byggeprosesser. Sam- spill i byggeprosessen, prosjektnr. 10602. [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). A practical guide to development. Green Oce Buildings: 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). http://gbxml.org. BIM curriculumn. 09.05.10. Technical report, Graphisoft Inc. [Graphisoft, 2010] Graphisoft (2010). The archicad solution. graphisoft.com/community/why_switch/the_archicad_solution.html. http://www. 25.03.10. [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. http://www.ifcwiki. 07.04.10. [Hansen, 2006] Hansen, T. B. (2006). Modellering av objektorienterte systemer. Technical report, Høgskolen i Sør-Trøndelag. 78 [Haraldsen, 1999] Haraldsen, A. (1999). historien. Den forunderlige reisen gjennom data- 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, [Howie et al., 1996] Howie, C., 22(2):271280. Kunz, J., and Law, K. (1996). Soft- Stanford University, USA http://www. dacs. dtic. mil/techs/interop/title. shtml, accessed January, 20:2003. ware interoperability. [Idehen, 1993] Idehen, K. (1993). ODBC technical white paper. openlinksw.com/info/docs/odbcwhp/tableof.htm. http://www. 22.05.10. BIM + Building Performance Analysis Using Revit 2010 and IES <Virtual Environment>. [IES VE, 2009] IES VE (2009). [IES VE, 2010] IES VE (2010). IES VE User's Guide. [ISO, 2010] ISO 184/sc (2010). Tc http://www.iso.org/iso/standards_ 4. development/technical_committees/other_bodies/iso_technical_committee.htm? commid=54158. 08.04.10. [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). gen. Digitale Produktmodeller i byggenærin- PhD thesis, NTNU, Institutt for konstruksjonsteknikk. of ) NIST Special Publication 939, National Institute of Standards and Technology, Gaithersburg, MD, 1999. [Kemmerer, 1999] Kemmerer, S. (1999). STEP: The grand experience. [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. http://www.aecbytes.com/feature/2004/IFCmodel.html. 79 08.05.10. [Kommunal- og regionaldepartementet, 2009] Kommunal- og regionaldeparte- Bygg for framtida. Miljøhandlingsplan for bolig- og byggsektoren 2009 2012. Grøset. mentet (2009). [Kommunal- og regionaldepartementet, 2010] Kommunal- og regionaldepartementet (2010). skrift). Forskrift om tekniske krav til byggverk (byggteknisk for- http://www.lovdata.no/cgi-wift/ldles?doc=/sf/sf/sf-20100326-0489.html. 12.06.10. [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. [Laiserin, 2002] Laiserin, J. (2002). Wiley. Comparing pommes and naranjas. //www.laiserin.com/features/issue15/feature01.php. http: 13.03.10. [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/. http://www.byggemiljo. 12.06.10. [MSG, 2010] MSG (2010). IFC documentation. IFC2x4/beta3/html/index.htm. http://www.iai-tech.org/ifc/ 08.05.10. [Norconsult, 2010] Norconsult (2010). BIM-kalkyle med Informasjonssystemer (ISY) calcus. http://www.nois.no/?aid=9099171. [OpenSpirit, 2010] OpenSpirit (2010). in the digital oileld. 26.03.10. Enabling cross-discipline collaboration http://www.openspirit.com/. 23.05.10. [Oracle Corporation, 2010] Oracle Corporation (2010). Many technologies, one platform. http://java.sun.com/javase/technologies/database/. 10.05.10. [Petersen, 2010] Petersen, A. (2010). BIM i Energi- og klimaberegninger. [Seletsky, 2004] Seletsky, P. (2004). Goodbye cad. goodbye bim. hello pen. //www.aecbytes.com/viewpoint/2004/issue_3.html. http: 16.04.10. [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, 80 page 97. [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 miljoprogrammering.no/. (2010). Miljøprogram. http://www. 12.06.10. [Svendsen, 2007] Svendsen, P. A. (2007). Eu knuser windows-monopolet. //www.nrk.no/nyheter/okonomi/1.3486728. http: 22.05.10. [Syvertsen, 2009] Syvertsen, T. G. (2009). TKT4505 Objektmodellering. Forelesning. [Wikipedia, 2010] Wikipedia (2010). Top-down and bottom-up design. //en.wikipedia.org/wiki/Top-down_and_bottom-up_design. [Yudelson, 2008] Yudelson, J. (2008). http: 15.05.2010. Green building through integrated design. McGraw-Hill Professional. 81 Vedlegg 82 A Eksempel på hvordan attributter arves i IFC ENTITY IfcBeam SUBTYPE OF (IfcBuildingElement); END_ENTITY; ENTITY IfcBeam; ENTITY IfcRoot; GlobalId : OwnerHistory : Name : Description : ENTITY IfcObjectDefinition; INVERSE HasAssignments : IsDecomposedBy : Decomposes : HasAssociations : ENTITY IfcObject; ObjectType : INVERSE IsDefinedBy : ENTITY IfcProduct; ObjectPlacement : Representation : INVERSE ReferencedBy : ENTITY IfcElement; Tag : INVERSE HasStructuralMember : FillsVoids : ConnectedTo : HasCoverings : HasProjections : ReferencedInStructures : HasPorts : HasOpenings : IsConnectionRealization : ProvidesBoundaries : ConnectedFrom : ContainedInStructure : ENTITY IfcBuildingElement; ENTITY IfcBeam; END_ENTITY; IfcGloballyUniqueId; IfcOwnerHistory; OPTIONAL IfcLabel; OPTIONAL IfcText; SET OF IfcRelAssigns FOR RelatedObjects; SET OF IfcRelDecomposes FOR RelatingObject; SET [0:1] OF IfcRelDecomposes FOR RelatedObjects; SET OF IfcRelAssociates FOR RelatedObjects; OPTIONAL IfcLabel; SET OF IfcRelDefines FOR RelatedObjects; OPTIONAL IfcObjectPlacement; OPTIONAL IfcProductRepresentation; SET OF IfcRelAssignsToProduct FOR RelatingProduct; OPTIONAL IfcIdentifier; SET OF IfcRelConnectsStructuralElement FOR RelatingElement; SET [0:1] OF IfcRelFillsElement FOR RelatedBuildingElement; SET OF IfcRelConnectsElements FOR RelatingElement; SET OF IfcRelCoversBldgElements FOR RelatingBuildingElement; SET OF IfcRelProjectsElement FOR RelatingElement; SET OF IfcRelReferencedInSpatialStructure FOR RelatedElements; SET OF IfcRelConnectsPortToElement FOR RelatedElement; SET OF IfcRelVoidsElement FOR RelatingBuildingElement; SET OF IfcRelConnectsWithRealizingElements FOR RealizingElemen SET OF IfcRelSpaceBoundary FOR RelatedBuildingElement; SET OF IfcRelConnectsElements FOR RelatedElement; SET [0:1] OF IfcRelContainedInSpatialStructure FOR RelatedElements Figur A.1: Arv av attributter for IFC BEAM 83 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>1529.75</Coordinate> <Coordinate>4</Coordinate> </CartesianPoint> <Tilt>90</Tilt> <Height>96</Height> <Width>42.81</Width> </RectangularGeometry> <PlanarGeometry> <PolyLoop> <CartesianPoint> <Coordinate>2224</Coordinate> <Coordinate>1529.75</Coordinate> <Coordinate>4</Coordinate> </CartesianPoint> </PolyLoop> </PlanarGeometry> </Surface> </Campus> </gbXML> Figur B.1: Oppbygning av Exterior Wall i gbXML 84 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 Autodesk Ecotect Import ASCII Model Files Analysis grid Data Files Ray/Particle Data Files Weather data files Radiance Point Value data Radiance Scene Files EnergyPlus Input data File Energy Plus Model summary AutoCAD DXF Files Stereo lithography file Green Building XML Industry Foundation Classes Google KML Data HPGL Plot Files Material Library Files CFD Output Data File Windows Bitmap JPEG Image *.MOD *.GRD *.RAY *.WEA *.DAT *.RAD *.IDF *.EIO *.DXF *.STL *.XML *.IFC *.KML/KMZ *.PLT og *.HGL *.LIB *.* *.BMP *.JPG Figur C.3: Model/Analysis Data [Autodesk, 2010a] 86 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 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 Radiance Octree Files POV Ray Scene files VRML Scene files AutoCAD DXF Files EnergyPlus Input data File DOE-2 Input Files SBEM Input Files AIOLOS Input Files HTB2 Files Accurate Scratch file ESP-r input File WinAir4 CFD Geometry File NIST FDS Input data File Green Building XML *.RAD *.OCT *.POV *.WRL *.DXF *.IDF *.INP *.INP *.PPA *.TOP *.* *.CFG *.GEO *.fds *.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 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 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 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 Space Element Figur D.15: Space Element [Autodesk, 2009b] ShellGeometry Element Figur D.16: ShellGeometry Element [Autodesk, 2009b] 92 SpaceBoundary Element Figur D.17: SpaceBoundary Element [Autodesk, 2009b] 93 Surface Element Figur D.18: Surface Element [Autodesk, 2009b] 94 Opening Element Figur D.19: Opening Element [Autodesk, 2009b] 95 E IFC-avbildingsl Category 1 Air Terminals Area Polylines Area Tags Areas Areas Areas Areas Boundary Conditions Cable Tray Fittings Cable Tray Fittings Cable Trays Cable Trays Cable Trays Cable Trays Callouts Casework Casework Casework Tags Ceiling Tags Ceilings Ceilings Ceilings Ceilings Ceilings Ceilings Ceilings Ceilings Ceilings Ceilings Ceilings Color Fill Color Fill Legends Columns Columns Communication Devices Conduit Fittings Conduit Fittings Conduits Conduits Conduits Conduits Constraints Contour Labels Curtain Panel Tags Curtain Panels Curtain Panels Curtain Panels Curtain Panels Curtain Systems Curtain Systems Curtain Systems Curtain Wall Mullions Curtain Wall Mullions Data Devices Subcategory IFC Class Name Not Exported IfcAirTerminal IfcPolyline Not Exported IfcSpace Type Color Fill Interior Fill Reference Not Exported IFCCableTrayFitting Center line IFCCableTraySegment Center line Drop Rise Not Exported IfcFurniture Hidden Lines IfcContextDependentUnit IfcContextDependentUnit IfcCovering Common Edges Cut Pattern Finish 1 [4] Finish 2 [5] Hidden Lines Membrane Layer Structure [1] Substrate [2] Surface Pattern Thermal/Air Layer [3] IfcCovering Not Exported Not Exported IfcColumn Hidden Lines IfcBuildingElementProxy IFCConduitFitting Center line IFCConduitSegment Center line Drop Rise IfcConstraint Not Exported Not Exported IfcCurtainWall Glass Hidden Lines Panel Material 1 Not Exported Not Exported Not Exported IfcCurtainWall Curtain System Grids Hidden Lines Hidden Lines IfcBuildingElementProxy 96 IfcLabel IfcLabel Demolished Detail Items Detail Items Detail Items Detail Items Detail Items Dimensions Dimensions Door Tags Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Doors Duct Accessories Duct Fittings Duct Fittings Duct Fittings Duct Fittings Ducts Ducts Ducts Ducts Ducts Ducts Electrical Equipment Electrical Equipment Electrical Equipment Tags Electrical Fixture Tags Not Exported IfcAnnotation Heavy Lines Hidden Lines Light Lines Medium Lines Automatic Sketch Dimensions bovenlicht Breakout Door Jamb Door Trim-Hor Door Trim-Vert Door-Angle-1 Door-Angle-2 Door-Garage-Panel Door-Int. Trim-Hor. Door-Int. Trim-Vert. Door-Jamb Door-Panels Door-Rail Door-Style Door-Track draairichting binnenzijde draairichting buitnzijde draairichting plattegrond Elevation Swing Frame/Mullion Glass Hardware Hidden Lines Metal Frame Moulding/Architrave Opening Panel Plan Swing plint Threshold wood panel Not Exported Not Exported IfcContextDependentUnit IfcDoor IfcDoor IfcDoor IfcDoor IfcDoor IfcBuildingElementProxy IfcDuctFitting Center line Insulation Lining IfcDuctSegment Center line Drop Insulation Lining Rise IfcBuildingElementProxy Hidden Lines Not Exported Not Exported 97 IfcLabel Electrical Fixtures Electrical Fixtures Elevations Entourage Entourage Existing Filled region Fire Alarm Devices Flex Ducts Flex Ducts Flex Ducts Flex Ducts Flex Pipes Flex Pipes Flex Pipes Flex Pipes Floors Floors Floors Floors Floors Floors Floors Floors Floors Floors Floors Floors Floors Floors Furniture Furniture Furniture Furniture Systems Furniture Systems Generic Annotations Generic Model Tags Generic Models Generic Models Generic Models Generic Models Grids Guide Grid HVAC Zones HVAC Zones HVAC Zones HVAC Zones HVAC Zones Imports in Families Levels Lighting Devices Lighting Fixture Tags Lighting Fixtures Lighting Fixtures Lighting Fixtures Lines IfcBuildingElementProxy Hidden Lines Not Exported IfcBuildingElementProxy Hidden Lines Not Exported IfcAnnotation IfcBuildingElementProxy IfcDuctSegment Center line Insulation Pattern IfcPipeSegment Center Line Insulation Pattern IfcSlab Analytical Model Common Edges Cut Pattern Finish 1 [4] Finish 2 [5] Hidden Lines Interior Edges Membrane Layer Slab Edges Structure [1] Substrate [2] Surface Pattern Thermal/Air Layer [3] IfcBuildingElementProxy IfcSlab IfcFurniture Hidden Lines Overhead Lines IfcSystemFurnitureElement Hidden Lines Not Exported Not Exported IfcBuildingElementProxy Hidden Lines IfcOpeningElements Overhead IfcOpeningElement Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported IfcBuildingStorey IfcBuildingElementProxy Not Exported IfcLightFixtureType Boundary Color Fill Interior Fill Reference Lines Hidden Lines Light Source IfcAnnotation 98 Lines Lines Lines Lines Lines Lines Lines Lines Lines Lines Lines Lines Lines Lines Lines Lines Lines Lines Lines Lines Lines Mass Mass Mass Mass Mass Mass Mass Mass Massing Mechanical Equipment Mechanical Equipment Mechanical Equipment Tags Multi-Category Tags New Nurse Call Devices Panel Schedule Graphics Parking Parking Parking Parking Parking Parking Tags Pipe Accessories Pipe Fittings Pipe Fittings Pipe Fittings Pipes Pipes Pipes Pipes Pipes Plan Region Planting Planting Planting Tags <Area Boundary> <Beyond> <Centerline> <Demolished> <Hidden> <Overhead> <Revision Cloud> <Room Separation> <Sketch> <Space Separation> <Stair/Ramp Sketch: Boundary> Stair/RampSketch:LandingCenter <Stair/Ramp Sketch: Riser> <Stair/Ramp Sketch: Run> Axis of Rotation Hidden Lines Insulation Batting Lines Lines Medium Lines Thin Lines Wide Lines Form Gridlines Hidden Lines Mass Floor Nodes Pattern Fill Pattern Lines IfcAnnotation IfcAnnotation Not Exported IfcAnnotation IfcAnnotation IfcAnnotation IfcAnnotation IfcAnnotation Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported IfcAnnotation IfcAnnotation IfcAnnotation IfcAnnotation IfcAnnotation Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported IfcBuildingElementProxy IfcBuildingElementProxy Hidden Lines Not Exported Not Exported Not Exported IfcSwitchingDeviceType Not Exported IfcBuildingElementProxy Hidden Lines Parking Layout Reference Line Stripe Not Exported IfcValveType IfcPipeFitting Center line Insulation IfcPipeSegment Center Line Drop Insulation Rise Not Exported IfcBuildingElementProxy Hidden Lines Not Exported 99 Plumbing Fixture Tags Plumbing Fixtures Plumbing Fixtures Property Line Segment Tags Property Tags Railing Tags Railings Railings Railings Railings Railings Ramps Ramps Ramps Ramps Ramps Ramps Ramps Ramps Ramps Ramps Raster Images Reference Planes Roads Roads Roof Tags Roofs Roofs Roofs Roofs Roofs Roofs Roofs Roofs Roofs Roofs Roofs Roofs Roofs Roofs Roofs Roofs Room Polylines Room Tags Rooms Rooms Rooms Rooms Ruled Curtain System Schedule Graphics Scope Boxes Sections Security Devices Shaft Openings Shaft Openings Site Not Exported IfcBuildingElementProxy Hidden Lines Balusters Hidden Lines Railings Beyond Cut Line Rails Down Arrow DOWN text Hidden Lines Incomplete ramps Ramps Beyond Cut Line Stringers Stringers Beyond Cut Line Up Arrow UP text Not Exported IfcContextDependentUnit Not Exported IfcRailing IfcRailing IfcLabel IfcRailing IfcRailing IfcRamp IfcRamp IfcRamp IfcRamp IfcRamp IfcRamp IfcRamp IfcRamp IfcRamp Not Exported Not Exported IfcBuildingElementProxy Hidden Lines IfcContextDependentUnit IfcRoof Common Edges Curtain Roof Grids Cut Pattern Fascias Finish 1 [4] Finish 2 [5] Gutters Hidden Lines Interior Edges Membrane Layer Roof Soffits Structure [1] Substrate [2] Surface Pattern Thermal/Air Layer [3] IfcLabel IfcRoof IfcRoof IfcRoof IfcRoof IfcRoof IfcPolyline IfcContextDependentUnit IfcSpace Color Fill Interior Fill Reference IfcCurtainWall Not Exported Not Exported Not Exported IfcBuildingElementProxy Not Exported Not Exported IfcSite Hidden Lines 100 IfcLabel Site Site Site Site Site Site Site Site Site Tags Spaces Spaces Spaces Spaces Specialty Equipment Specialty Equipment Specialty Equipment Tags Spot Coordinates Spot Elevations Spot Slopes Sprinklers Stair Tags Stairs Stairs Stairs Stairs Stairs Stairs Stairs Stairs Stairs Stairs StructuralAreaReinforcement StructuralAreaReinforcement Structural Beam Systems Structural Beam Systems Structural Column Tags Structural Columns Structural Columns Structural Columns Structural Columns Structural Columns Structural Columns Structural Connections Structural Foundation Tags Structural Foundations Structural Foundations Structural Foundations Structural Framing Structural Framing Structural Framing Structural Framing Structural Framing Structural Framing Structural Framing Structural Framing Structural Framing Hidden Lines Pads Parking Layout Project Base Point Property Property Lines Stripe Survey Point IfcSlab Not Exported IfcBuildingElementProxy Not Exported IfcContextDependentUnit Not Exported Not Exported Not Exported Not Exported IfcBuildingElementProxy Color Fill Interior Reference IfcLabel Hidden Lines Down Arrow DOWN Text Hidden Lines Incomplete Stairs Stairs Beyond Cut Line Stringers Stringers Beyond Cut Line Up Arrow UP Text Boundary Hidden Lines Not Exported Not Exported Not Exported Not Exported IfcFireSuppressionTerminalType Not Exported IfcStair IfcStair IfcStair IfcStair IfcStair IfcStair IfcStair IfcStair IfcStair Not Exported Not Exported Not Exported Not Exported IfcContextDependentUnit IfcColumn Analytical Model Hidden Faces Hidden Lines Rigid Links Stick Symbols Not Exported Not Exported IfcFooting Analytical Model Hidden Lines IfcBuildingElementProxy Analytical Model Chord Girder Hidden Faces Hidden Lines Horizontal Bracing Joist Kicker Bracing 101 IfcLabel Structural Framing Other Structural Framing Purlin Structural Framing Rigid Links Structural Framing Stick Symbols Structural Framing Vertical Bracing Structural Framing Web Structural Framing Tags Structural Internal Loads Structural Internal Loads Internal Area Loads Structural Internal Loads Internal Line Loads Structural Internal Loads Internal Point Loads Structural Load Cases Structural Load Cases Accidental Loads Structural Load Cases Dead Loads Structural Load Cases Live Loads Structural Load Cases Roof Live Loads Structural Load Cases Seismic Loads Structural Load Cases Snow Loads Structural Load Cases Temperature Loads Structural Load Cases Wind Loads Structural Loads Structural Loads Area Loads Structural Loads Line Loads Structural Loads Point Loads Structural Path Reinforcement Structural Path ReinforcementBoundary Structural Rebar Structural Stiffener Tags Structural Stiffeners Structural Truss Tags Structural Trusses Structural Trusses Stick Symbols Telephone Devices Temporary Text Notes Title Blocks Title Blocks Medium Lines Title Blocks Thin Lines Title Blocks Wide Lines Topography Topography Boundary Point Topography Hidden Lines Topography Interior Point Topography Primary Contours Topography Secondary Contours Topography Triangulation Edges View Titles Wall Tags Walls Walls Analytical Model Walls Common Edges Walls Curtain Wall Grids Walls Cut Pattern Walls Finish 1 [4] Walls Finish 2 [5] Walls Hidden Lines Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported Not Exported IfcBuildingElementProxy Not Exported IfcAnnotation Not Exported Not Exported Not Exported Not Exported IfcBuildingElementProxy IfcBuildingElementProxy IfcBuildingElementProxy IfcBuildingElementProxy IfcBuildingElementProxy IfcBuildingElementProxy Not Exported IfcContextDependentUnit IfcWall IfcWall 102 IfcLabel Walls Walls Walls Walls Walls Walls Walls Walls Walls/Interior:1 Walls/Exterior:2 Walls/Foundation:3 Walls/Retaining:4 Window Tags Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows Wires Wires Wires Membrane Layer Reveals Stacked Walls Structure [1] Substrate [2] Surface Pattern Thermal/Air Layer [3] Wall Sweeps draairichting binnen Elevation Swing Frame/Mullion Glass Hidden Lines Moulding Opening Plan Swing Sill/Head Trim IfcOpeningElement IfcWall IfcWall IfcBuildingElementProxy IfcWall IfcWall IfcWall IfcWall IfcContextDependentUnit IfcWindow IfcWindow IfcWindow IfcWindow IfcWindow Not Exported Not Exported Not Exported Home Run Arrows Wire Tick Marks Figur E.20: IFC-avbildingsl 103 IfcLabel F Resultater fra Test 1 Lokasjon Orientering Bygningstype Enhet Revit Architecture Ecotect Analysis Latiture:60.8° Longitude:10.7° Latitude:-32° Longitude:116° 45° West of Project North 0° Hospital --Metric System Imperial System Figur F.21: Resultater fra Test 1 104 IES VE Latiture:60.8° Longitude:10.7° 0° Hospital Metric System G Resultater fra Test 2 A IES VE Revit Ecotect Rom 1 Navn Dining Dining Dining Volum 1005,28 0 1005,28 Grunnflate 251,32 251,32 251,32 Yttervegg 208,656 301,463 208,656 Utvendig Dør 2,6 0 2,6 Utvendig Vindu 11,144 --11,144 Innervegg 92,807 --92,807 Innvendig Dør 2,6 0 2,6 Innvendig Vindu 1,393 --1,393 Tak 0 0 0 Gulv 251,32 251,32 251,32 Etasjeskille 251,32 0 251,32 Rom 2 Navn Family Study Family Study Volum 585 0 585 Grunnflate 146,25 146,25 146,25 Yttervegg 96,8 189,607 96,8 Utvendig Dør 0 0 0 Utvendig Vindu 0 --0 Innervegg 92,807 --92,807 Innvendig Dør 2,6 0 2,6 Innvendig Vindu 1,393 --1,393 Tak 0 0 0 Gulv 146,25 146,25 146,25 Etasjeskille 146,25 0 146,25 Navn Bedroom 3 Bedroom 3 Bedroom 3 Volum 1616 0 1616 Grunnflate 400,02 400,02 400,02 Yttervegg 242,524 242,524 242,524 Utvendig Dør 0 0 0 Utvendig Vindu 79,074 79,074 79,074 Innervegg 0 0 0 Innvendig Dør 0 0 0 Innvendig Vindu 0 0 0 Tak 400,02 400,02 400,02 Gulv 0 0 0 Etasjeskille 400,02 0 400,02 Figur G.22: Resultater fra Test 2 105 Side 1 SUM 1etg Gulv Tak Yttervegg 397,57 397,57 319,2 400,02 397,57 400,02
© Copyright 2024