Embed Size (px)
Citation preview
Karl Kristian Olsson Haave
BIM og Miljøberegning 14. juni 2010
Mas
tero
ppga
ve
NTN
UN
orge
s te
knis
k-na
turv
itens
kape
lige
unive
rsite
tFa
kulte
t for
Inge
niør
viten
skap
og
tekn
olog
iIn
stitu
tt fo
r kon
stru
ksjo
nste
knik
k
Institutt for konstruksjonsteknikk Fakultet for ingeniørvitenskap og teknologiNTNU- Norges teknisk- naturvitenskapelige universitet
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
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.
TILGJENGELIGHET
Fullt tilgjengelig
SAMMENDRAG:Building information modeling (BIM) blir tatt i bruk i stadig flere byggeprosjekter, og utfordringenmed å oppnå interoperabilitet mellom ulike typer applikasjoner har etter hvert blitt et tema.Formålet med denne masteroppgaven er å vurdere interoperabiliteten mellommodelleringsapplikasjoner og analyseapplikasjoner i dag, og hvilke muligheter man har til åforbedre interoperabiliteten i tiden som kommer. I oppgaven blir ulike kommunikasjonsformater ogkommunikasjonsmåter vurdert. Videre blir interoperabiliteten mellom modelleringsapplikasjonenAutodesk 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 tilhenholdsvis Ecotect og IES VE. Masteroppgaven har blitt utarbeidet i samarbeid med COWIavdeling Trondheim, og oppgaven avsluttes med en anbefaling til COWI om valg avoverføringsformat og råd til videre arbeid for å forbedre interoperabiliteten mellom applikasjoner ifremtiden.
Institutt for konstruksjonsteknikk
FAKULTET FOR INGENIØRVITENSKAP OG TEKNOLOGINTNU – Norges teknisk-naturvitenskapelige universitet
MASTEROPPGAVE 2010for
stud. techn. Karl Kristian Olsson Haave
BIM og Miljøberegning
BIM and Environmental Analysis
Bakgrunn for oppgaven/problemstillingKandidaten har inngått i et samarbeid med bedriften COWI. COWI har tatt i bruk BIM på enrekke byggeprosjekter og ønsker å teste ut to miljøberegningsprogrammer for å kartleggehvor godt de fungerer med Autodesk Revit.
AngrepsmåteKandidaten skal sette seg inn i og teste ut programmene Autodesk Ecotect og IES VE koblet opp motAutodesk Revit. Dette arbeidet vil innebære et litteraturstudium, samt praktisk bruk avprogrammene. Referanseprosjektet som brukes for å teste programmene vil være den nyebarneavdelingen 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 medinteroperabilitet.
ResultatKandidaten skal utarbeide en rapport som inneholder en presentasjon av resultatene avdekketunder arbeidet med oppgaven. Herunder inngår vurdering av interoperabilitet mellom programvareog drøfting av hvordan COWI kan håndtere eventuelle problemer med interoperabilitet for å sikreat informasjonen er pålitelig. Til slutt skal kandidaten komme med forslag til hvilket program sombø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 forkonstruksjonsteknikk.
Kontaktperson hos bedrift: Navn: Dagfinn Bell
Epost: [email protected]
Tlf: 93081497
Navn: Ingrid Alvsåker
Epost: [email protected]
Tlf: 48991094
Veileder: Navn: Tor G. Syvertsen
Epost: [email protected]
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øtek-
nikk ved NTNU i Trondheim fullbyrdet. Masteroppgaven er utviklet i faget
TKT4900 ved Institutt for Konstruksjonsteknikk under Fakultet for ingeniørvi-
tenskap og teknologi på NTNU, i samarbeid med COWI, Trondheim.
En stor takk rettes til oppgavens hovedveileder� Professor Tor G. Syvertsen
ved NTNU� for hjelp til å stille de rette spørsmålene og for alltid å være en
ariadnetråd. Jeg ønsker også å takke COWI� da spesielt Ingrid Alvsåker og
Dag�nn Bell� for å stille arbeidsplass og programvare til disposisjon og for å
ta seg tid til å hjelpe meg.
Takk til familie og venner for hjelp og støtte, og sist men ikke minst takk til
min kjære for alle middager og all nytraktet ka�e.
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; proses-
sen 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 kommuni-
sere 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 mel-
lom modelleringsapplikasjoner og analyseapplikasjoner i dag, og å vurdere hvilke
muligheter man har til å forbedre interoperabiliteten i tiden som kommer. Pro-
blemstillingen 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 henholds-
vis 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 gbXML-
skjemaet 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 �lforma-
ter 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 ut-
fordrende 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 dataak-
sesslag og forretningslag og sammen blir enige om grunnprinsipper for hvor-
dan informasjon skal de�neres og overføres. Dette innebærer at leverandørene
vil miste noen av sine konkurransefortrinn og brukervennligheten og funksjo-
naliteten til applikasjonene vil bli desto viktigere, noe som vil være gunstig
for forbrukerne. Igangsettingen av et slikt samarbeid mellom applikasjonsleve-
randører avhenger av at aktørene i byggenæringen innser behovet for en slik
kommunikasjonsmåte og at de sammen formidler dette behovet til applikasjons-
leverandø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 . . . . . . . . . . . . . . . . . . 16
3.4 Kommunikasjon via database-server . . . . . . . . . . . . . . . . 17
3.5 IFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Architec-
ture 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
E IFC-avbildings�l . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
F Resultater fra Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . 104
G Resultater fra Test 2 . . . . . . . . . . . . . . . . . . . . . . . . . 105
VI
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 O�ce 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 Paci�c 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 Uni�ed 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 Informasjons�yt 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 gbXML-
skjemaet [gbXML, 2010] . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Verktøylinjen til Autodesk Revit . . . . . . . . . . . . . . . . . . 34
4.2 Autodesk Revit sitt Graphical User Interface (GUI) . . . . . . . 35
4.3 Inndeling av informasjon i Autodesk Revit [Autodesk, 2009b] . . 36
4.4 Eksportering til gbXML-formatet i Revit . . . . . . . . . . . . . 38
4.5 Informasjonsorganisering i gbXML [Autodesk, 2009b]. . . . . . . 39
4.6 Autodesk Ecotect sitt GUI . . . . . . . . . . . . . . . . . . . . . 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] . . . . . . . . . . 44
4.10 Importering av gbXML-�l i IES VE . . . . . . . . . . . . . . . . 46
IX
4.11 Kontroll av rom i modell som skal importeres . . . . . . . . . . . 47
4.12 IES VE PlugIn til Autodesk Revit . . . . . . . . . . . . . . . . . 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
5.13 Modell laget i Revit for Test 5 . . . . . . . . . . . . . . . . . . . 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
X
B.1 Oppbygning av Exterior Wall i gbXML . . . . . . . . . . . . . . 84
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] . . . . . . . . . . . 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-avbildings�l . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
F.21 Resultater fra Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . 104
G.22 Resultater fra Test 2 . . . . . . . . . . . . . . . . . . . . . . . . . 105
1
1Innledning
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 igang-
satt tiltak som angår bolig- og byggesektoren. Bolig- og byggesektoren omta-
les som �40% næringen� da næringen står for cirka 40% av det totale energi-
og ressursforbruket og avfallsproduksjonen i Norge. Potensialet til å reduse-
re energibruken og Norges klimagassutslipp ved innstramminger i byggenærin-
gen er med andre ord vesentlig. Kravene til bygg har blitt skjerpet av staten
gjennom juridiske virkemidler, og energikravene i tekniske forskrifter til plan-
og 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ør-
sel 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 e�ciency 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 base-
rer seg på informasjon om blant annet bygningsmaterialer, tekniske installasjo-
ner, over�ater og volumer [Krygiel and Nies, 2008]. Å modellere bygninger med
analyseapplikasjoner krever tid til å de�nere inndataverdiene, kjøre simulasjo-
nen og å analysere utdata. Man har tidligere vært avhengig av å ta ut meng-
der 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 å for-
enkle denne prosessen.
1.2 BIM og miljøvurdering
BIM-teknologi er i ferd med å få et stadig sterkere fotfeste innenfor Architectu-
re, Engineering and Construction (AEC)-industrien. BIM tar utgangspunkt i et
prosjektsamarbeid hvor alle aktører tilfører informasjon til en digital bygnings-
modell. Denne informasjonen kan blant annet være geometrisk data, byggets
lokasjon og orientering, bygningsmaterialer og -komponenter, tekniske installa-
sjoner og fremdriftsplaner. Modellen utvikles i prosjekteringsfasen, brukes til
å følge opp arbeidet i gjennomføringsfasen og kan videre benyttes i hele byg-
gets 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 analyseappli-
kasjoner 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 design-
prosessen [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ø-
serti�sering 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 ut-
viklet, 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. Problemstillin-
gen til masteroppgaven har blitt utarbeidet i samarbeid med COWI, avdeling
Trondheim. COWI har tatt i bruk BIM på en rekke byggeprosjekter og øns-
ket å teste interoperabiliteten mellom modelleringsapplikasjonen Autodesk Re-
vit 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 objek-
ter i Revit under testingen. Informasjonsoverføringen er kun testet fra Revit til
analyseapplikasjonene, da ingen av analyseapplikasjonene kan eksportere infor-
masjon 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 litte-
raturstudium 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 in-
teroperabiliteten 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 de�nisjon 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 det-
te 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
2Building 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
de�nisjon av hva BIM er.
2.2 Objektmodellering
Historie
Ole Johan Dahl og Kristen Nygaard utviklet på 1960-tallet programmerings-
språket SIMulation LAnguage (SIMULA). Språket skulle være intuitivt og an-
vendelig, 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 bygge-
næ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 mo-
dellering [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 foretruk-
ket 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 Corporation�senere
kjøpt opp av Autodesk�lanserte 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� se-
nere kalt objekt� som inneholdt både data og operasjoner. Ved hjelp av taksono-
mi 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 Uni�ed Modeling Language (UML). OMT består av de tre
aspektmodellene objektmodell, dynamisk modell og funksjonsmodell
[Syvertsen, 2009].
OMT
ObjektmodellDynamisk
modell
Funksjons-
modell
Assosiasjon Klasse Tilstand Hendelse FlytTransformasjon
Figur 2.2: Objektmodell av OMT [Syvertsen, 2009]
En klasseorientert objektmodell de�neres 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 beskri-
ver objektets oppførsel og identitet; gir objektet en unik eksistens blant alle
andre objekter. Objekter kommuniserer ved å sende meldinger til hverand-
re. 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 de�nerer et sett attributter, som beskriver egen-
skaper og tilstander til forekomster i klassen. Klasser er inndelt i et klasse-
hierarki av superklasser og underklasser. En underklasse kan arve attri-
butter og operasjoner fra en superklasse.
Anvendelse
Ved bruk i byggenæringen består objektbaserte modeller av parametriske objek-
ter 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 funksjonel-
le enheter. Detaljer kan linkes til sin posisjon i modellen og endringer gjort i en
9
komponent blir oppdatert i alle tegninger [Seletsky, 2004]. Denne parametris-
ke 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 sku�else eller kon�ikter [Jongeling, 2008]. I realiteten kan BIM
ha minst to forskjellige betydninger, avhengig av hvilket perspektiv man har.
Prosessperspektiv
Konseptet BIM har eksistert i en eller annen form så langt tilbake som på 70-
tallet. Professor Charles Eastman ved Georgia Institute of Technology var en
av de første som konkretiserte begrepet, da under navnet �Building Product
Model� [Conradie, 2009]. I denne sammenhengen var BIM en prosess, mer enn
en anvendelse av ny IT.
Byggeindustrien har tatt i bruk en rekke generelle teknologiske hjelpemidler
etterhvert som den har blitt utviklet; det er eksempelvis nå blitt vanlig med
digitalisering og elektronisk distribusjon av dokumenter, det eksisterer digitale
verktøy for tid- og kostnadsplanlegging og gra�sk visualisering av byggeprosjek-
ter. 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 innbyr-
des 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 pro-
sjektet, 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 e�ektiv 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 datamaski-
ner [Engelbart, 2003].
Teknisk perspektiv
Selve fagordet BIM ble først tatt i bruk av Phil Bernstein, visepresident i Auto-
desk, 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 mode-
ling� 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 di-
gitale 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 å kun-
ne 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, lag-
ret 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 di-
rekte ut av modellen, og man kan bruke modellen til å dimensjonere bæresys-
temer, utføre miljøberegninger og å sjekke at elementer i bygget ikke kollide-
rer med hverandre. Denne bygningsinformasjonsmodellen kan alle partene i et
byggeprosjekt samarbeide om å bruke. Ved hjelp av diverse programvare kob-
let sammen via interoperabilitet, kan aktørene bruke ulik programvare, relevant
for sitt fagfelt [Graphisoft, 2009]. Mange CAD-verktøy� slik som Revit, Archi-
CAD, DDS, AutoCAD ADT, Bentley og Tekla� tilbyr i dag BIM-funksjonalitet
[Norconsult, 2010].
De�nisjon
Det eksisterer per dags dato ingen entydig og presis de�nisjon 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 for-
virring. Uten en entydig og presis de�nisjon kan man ikke identi�sere 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 de�nisjon av General Services
Administration (GSA) Public Buildings Service (PBS) O�ce 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 mulig-
heten til å visualisere bygget og utføre kollisjonskontroller for å minimere antall
feil i prosjekteringen. Det at BIM kan benyttes til å visualisere et bygg for let-
tere å 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 e�ektivitet, som vil gi høyere verdiskapning for
aktørene og kundene i prosjektet [Eikeland, 2000].
Med BIM kan man oppnå bedre e�ektivitet 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 funksjo-
nalitet 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 e�ektene 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 OwnerContractor
Building Certifier
Quantity Surveyor/
Cost Planner
Product
Manufacturers
Information
Providers
EngineerGovernment
Agencies
Users
Facility Manager
Developer
Architect/
Interior Designers
BIM MODEL
Figur 2.4: Informasjons�yt 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 informasjonsut-
veksling, 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
3Interoperabilitet
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 byggein-
dustrien 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 program-
mene 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 å over-
fø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 imel-
lom.
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, ob-
jektegenskaper, 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å XML-
baserte 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 ap-
plikasjonene 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 for-
mat som brukes og om applikasjonene støtter det, kan kommunikasjonen foregå
begge veier. Denne typen kommunikasjon ble benyttet under testingen av ap-
plikasjonene 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.
Modellerings-
applikasjon
Analyse-
applikasjon
EKSPORT IMPORT
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 dis-
tribuerer 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 relasjons-
databaser, 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 in-
formasjon 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 kun-
ne 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øringska-
pasitet; 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. Ap-
plikasjonene har ulike funksjoner ut ifra hvilket fagfelt de er beregnet for, men
de�nerer 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 relasjons-
database, 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 li-
sensprisene 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].
Database
Applikasjon A Applikasjon B Applikasjon N
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 innehol-
der forretningsbegreper og basisoperasjoner samlet under begrepet forretnings-
logikk� 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 uli-
ke 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 utvik-
le sin programvare for å koble applikasjonene fra de ulike leverandører sammen
[Simensen, 2010].
Ved å bruke mellomvare unngår man synkroniseringse�ekter og man åpner
opp for at applikasjoner med nye funksjoner og bedre brukervennlighet kan
18
utvikles og bli koblet til databasene.
Database A
Applikasjon A Applikasjon B Applikasjon N
Middleware
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 data-
basen 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 data-
modellformatet 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
DatabaseApplikasjon A
Applikasjon B
Applikasjon N
IMPORT
EKSPORT
IMPORT
EKSPORT
IMP
OR
TE
KS
PO
RT
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 de�ni-
sjoner på informasjon og felles protokoller slik at deres applikasjoner skal kunne
kommunisere seg i mellom. Applikasjonene innehar samme grunnprinsipper for
hvordan de de�nerer 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 interopera-
bilitetsteknologien.
En stor forskjell fra dette scenarioet og de overnevnte er at programleveran-
dø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 risi-
kerer å miste noe av sitt konkurransefortrinn. Programleverandørene vil miste
eventuelle synkroniseringse�ekter, og det blir enda viktigere å fokusere på bru-
kervennlighet og funksjonalitet for å tiltrekke forbrukere.
Fri Programvare
Dette scenarioet er i store trekk likt med interoperabilitet utviklet av program-
vareleverandø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 BIM-
data. 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 prak-
tiske 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 datakil-
der. 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 tilknyt-
tet interoperabilitet. Kommunikasjonen mellom applikasjonene og serveren be-
står av enkle transaksjoner for å hente ut og putte inn informasjon. Applika-
sjoner 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 data�len, og i til-
legg 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 informa-
sjon 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 produkt-
modell 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 produksjons-
industrien 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 pro�ttfri 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 interoperabilitet�og dermed bedre informasjons�yt�i
byggeprosjekter. Dette gir prosjektdeltagere muligheten til å dele prosjektinfor-
masjon 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 å de�nere,
fremme og publisere spesi�kasjoner for deling av data. Resultatet av denne pro-
sessen 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/life-
cycle 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 bi-
dratt 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 de�nisjonene.
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 rek-
ken 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å entite-
ter. 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 dome-
nenivå. 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
fagspesi�kke 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 egenska-
pene 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 ressurs-
skjema 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 de�nerer hvordan strukturen til skjemaene i IFC-modellen
skal bygges opp. �Core Extensions� utvider og spesialiserer konseptene de-
�nert i �Kernel�, �Product Extension� de�nerer abstrakte bygningskompo-
nenter som rom, bygningstype og bygningselement. �Control�- og �Process
Extension� de�nerer prosess- og kontrollkonsepter som oppgaver, prosedy-
rer og arbeidsplaner.
Interoperabilitetsnivå Interoperabilitetsnivået består av ressursskjemaer som
de�nerer 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 de�nisjoner på de van-
ligste bygningsentitetene; �Shared Building Elements�-skjemaet består av
entiteter for bjelker, søyler, vinduer, vegger og så videre, �Shared Buil-
ding Services Elements�-skjemaet består av entiteter for akustikkegenska-
per, veske�ytegenskaper, �ytkontroll og så videre og �Shared Facilities
Elements�-skjemaet inneholder entitetsde�nisjoner som for eksempel bru-
ker og møbler.
Domenenivå Domenenivået er det øverste nivået i systemarkitekturen til IFC-
modellen. Dette nivået inneholder entiteter som er spesi�kke for prosesser
eller applikasjoner, gruppert ut i fra de ulike fagretningene innen bygge-
industrien. 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 IFC-
modellen, 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; IfcObjectDe�nition; IfcObject; IfcProduct; IfcElement; Ifc-
BuildingElement; IfcBeam;
Se Tillegg A for en nærmere beskrivelse av entitetene som blir arvet.
Overføring mellom applikasjoner
Prosessen med å overføre en BIM fra en applikasjon til en annen via en IFC-
modell 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
Eksp
ort
Ove
rse
ttels
e
Imp
ort
Ove
rse
tte
lse
P-21
OversettelseDatastruktur Datastruktur
P-21
Oversettelse
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 in-
formasjon 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 mang-
ler 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 datamodellforma-
ter fortløpende vil klare å ivareta kompatibiliteten etterhvert som nye appli-
kasjonsversjoner lanseres. Applikasjoner blir stadig oppdatert, og selv om det
jobbes med å få IFC-modellen til å overføre informasjon tapsfritt vil dette ar-
beidet 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 er-
stattet. 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 de�neres ut i fra sin senterlinje
og seksjonspro�l, 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 appli-
kasjon A til applikasjon B (se Figur 3.7). I A er veggens geometriske grunn�ate
de�nert som en sirkel med senterlinje og radius. B de�nerer 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 omde�nert til et polygon som en tilnærming
[Kalstveit, 1997].
Applikasjon A Applikasjon BNøytralt
Format
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 analyse-
applikasjoner. 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 de�nisjonene.
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ær-
mere 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å energimodelleringspro-
grammer. For å gjøre detaljerte energianalyser var man tidligere avhengig av å ta
ut mengder manuelt fra 2D tegninger. Ulempene med dette var mange; proses-
sen 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 impor-
teres 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 Cali-
fornia Energy Commission (CEC), Public Interest Energy Research (PIER) og
Paci�c 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 o�sielle 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), oppmer-
kingssprå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 de�neres av brukeren slik at man kan systemati-
sere navngiving og kategorisering av data [Eastman et al., 2008]. Skjemaene for
overføring lagres som ren tekst i for eksempel et regneark eller en database.
gbXML er et XML-skjema spesielt utviklet for overføring av informasjon
relevant for energianalyser og -simuleringer [Eastman et al., 2008]. Et så spesi-
�kt fokusområde for informasjonoverføring forenkler oppgaven med å de�nere
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
• In�ltrasjon
• 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 spesi�kk informasjon relevant for en analyseap-
plikasjon og gjør forenklinger i blant annet geometri under konverteringen. Det-
te 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 enveis-
kommunikasjon 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
Side 1
IFC
Units Units
gbXML
File Description, File name and file schema
File Version
Organization, Person, owner history.
Campus ID
Cartesian points, direction, dimensional exponents, shape representation
Location
Product definition and shape.
Area, Volume
Property value Building IDPredefined element parameters
Description
Material, layer set, Color.
Shell Geometry ID
Cartesian Points, Co-ordinates. Shell SurfaceShell Openings Space ID Surface ID Product name, version Platform
Figur 3.8: Sammenligning av IFC-modellen [buildingSMART, 2010b] oggbXML-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 fore-
komster. 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 å de�-
nere de mest generelle, overordnede bestanddelene som utgjør modellen, for så
å fragmentere disse delene i stadig �ere underkategorier helt til man er kom-
31
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]. Mo-
dellen 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 proses-
sen 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 over�ater ved hjelp av to at-
tributter: plan polygongeometri og rektangulær polygongeometri. Begge inne-
holder den samme geometriske informasjonen og brukes sammen for å dobbelt-
sjekke 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 bygnings-
geometri.
32
4Programvare
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 Auto-
desk 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 eksportev-
nene. 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 model-
len� 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 O�ce 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 Verktøy for å legge til 2D informasjon i modellen.
Modify Verktøy for å endre eksisterende elementer, data og systemer i model-
len.
Massing & Site Verktøy for mengdeberegninger og lokalisering av bygget.
Collaborate Verktøy for at �ere skal kunne arbeide sammen på en modell.
View Verktøy for å se modellen i ulike perspektiver som planskisser, tverrsnitt
og 3D.
Manage Verktøy for å endre innstillingene i prosjektet, eller preferansene i
Revit.
Element-Fane Når man har valgt et element i modellen kommer det i tillegg
opp en egen fane med verktøy relevant for dette elementet.
Plug-In Egne faner blir laget hvis man installerer tilleggsfunksjoner fra andre
applikasjoner.
34
Figur 4.2: Autodesk Revit sitt GUI
Under verktøylinjen �nner man selve tegneområdet, hvor modellen er il-
lustrert. Her kan man velge elementer man ønsker å modi�sere, 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 (plantegnin-
ger, tverrsnitt, 3D-fremvisning og så videre), ta ut mengder fra modellen og
sjekke om elementer kolliderer. Revit kan kobles sammen med andre applikasjo-
ner 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 de�nerer relasjonene
mellom elementene i modellen. Når man arbeider i tegneområdet kan model-
len 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 mo-
dellelementer 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 prede�nert i Autodesk Revit, og
man kan ikke lage nye familier i denne gruppen på egenhånd. Familiegrup-
pene inneholder vanlige bygningsdeler som vegg-, tak- og gulvelementer.
Disse elementene eksisterer i prosjektmodellen som typer av sin familie-
gruppe, lagret som *.rte maler. I tillegg inneholder gruppen systemegen-
skaper 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 inte-
grerte. Frittstående elementer kan være ting som møbler, trær, mennesker,
biler og så videre. Integrerte elementer er innlemmet i andre bygningsde-
ler. Dette kan være elementer som vinduer og dører. I tillegg inneholder
familiegruppen elementer som brukes når kommentarer legges til i model-
len.
In-place families Når man har behov for å lage et element i modellen som ikke
er prede�nert i Revit eller kan lastes inn i modellen fra Revit sitt bibliotek
(jamført System- eller Loadable Families) vil dette elementet tilhøre In-
place 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 de�neres av to typer parametere� Type- og forekomstparametere.
Typeparametere inneholder informasjon som er generell for alle elementer til-
hørende den gitte familien. Forekomstparametere inneholder informasjon som
er spesi�kk 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 forma-
ter. For en komplett liste se Vedlegg C.
Overføring med IFC
Autodesk Revit 2011 er serti�sert for import og eksport til IFC2x3 model-
len [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 over�ater. 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
over�ater og romvolum er korrekt.
Figur 4.4: Eksportering til gbXML-formatet i Revit
38
gbXML-skjemaet organiserer bygningsinformasjon i følgende hierarki: Loka-
sjon, Bygning, Rom, Over�ate 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øt-
tes av Revit Architecture 2011.
4.3 Autodesk Ecotect
Introduksjon
Autodesk Ecotect ble kjøpt opp av Autodesk i 2008. Før den tid var program-
met eid og utviklet av Square One Reaserch. Applikasjonen fokuserer på energi-
beregninger og -analyser i tidligfase i byggeprosjekter, slik at man så tidlig
som mulig kan utforme designet av bygget til å bli mest mulig energie�ektivt
[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 ele-
menter. 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 verk-
tøy relevant for hver enkelt side. I Project-side kan man legge til gene-
rell 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 fak-
torer� som for eksempel hvilke over�ater som er eksponert mot utsiden, ekspo-
nering til sollys, åpninger i over�ater og varme generert av interne varmekilder
som belysning og utstyr� i analyseprosessen. For å visualisere, simulere og ana-
lysere bygningsfunksjonene trenger applikasjonen informasjon om de romlige
aspektene til bygget, materialegenskaper og soneinndeling [Autodesk, 2010b].
Følgende analyser kan utføres med Autodesk Ecotect 2011 [Autodesk, 2010b]:
Dynamic Daylight Simulations (DAYSIM) Simulering av dagslys
Radiance Simulering av lys
Chartered Institution of Building Services Engineers (CIBSE) Energianalyser
Energy+ Energianalyser, solinnstrålingsanalyser, akustikkanalyser
NIST-FDS, Fluent og WinAir4 Dynamiske analyser av væsker og gasser.
Energianalyse
Autodesk Ecotect Analysis 2011 bruker en termisk algoritme fra CIBSE for å
utføre energianalyser av bygninger [Autodesk, 2010a]. Med metoden utviklet av
CIBSE beregnes temperatur og belastning i to forskjellige stadier. Først be-
regnes indre temperaturvariasjoner time for time, så beregnes varmebehovet.
Varmebehovet er for hvert rom og for ulike soner og tar ikke hensyn til e�ekt-
graden til varme- og kjøleanlegg. Resultatene som presenteres er årlig forbruk
og maks forbruk.
CIBSE sin utslippsmetode ble utviklet for å beregne maksimum nedkjølings-
behov til ett bygg [CIBSE, 1999], og tester viser at denne metoden ikke frembrin-
ger 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 å sam-
menligne ulike designløsninger og ikke for å dokumentere selve oppvarmingsbe-
hovet.
41
De termiske analysene av interne temperaturer og varmebehov gjøres gjen-
nom en simulering av hvordan energi beveger seg inn, ut og gjennom rom og
volum i bygningsmassen. For å gjøre dette benytter Ecotect termiske soner de-
�nert i modellen. En termisk sone er de�nert som et lukket volum, avgrenset av
gulv, vegger og tak, og de�neres 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 sonein-
formasjon 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 de�nere elementklassene til elementer som impor-
teres, 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 energie�ektive 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 spesi�sere 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
IES VE inneholder� i likhet med Ecotect Analysis� verktøy som kan brukes tidlig
i designprosessen for å 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
for å analysere bygningen blir lagret.
BOSTON, MA │ GLASGOW, SCOTLAND │ DUBLIN, IRELAND
From Analysis to UnderstandingIES <Virtual Environment>
By: INTEGRATED ENVIRONMENTAL SOLUTIONS LIMITEDDate: Monday 19 October 2009
DUBLIN, IRELAND │ LONDON, ENGLAND │ MELBOURNE, AUSTRALIA │
From Analysis to UnderstandingIES <Virtual Environment> Product Overview V6.0
INTEGRATED ENVIRONMENTAL SOLUTIONS LIMITED
│ SAN FRANCISCO, CA │ DUBAI, UAE
From Analysis to Understanding
V6.0
INTEGRATED ENVIRONMENTAL SOLUTIONS LIMITED
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 Simulering av Heating, Ventilating and Air Conditioning (HVAC).
SunCast SunCast simulerer solinnstråling i bygget.
MacroFlo MacroFlo simulerer luftstrømninger for at man skal kunne studere
naturlig- og hybridventilasjon, in�ltrasjon 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 PiscesPro brukes for å designe røroppleggsystemer.
Simulex Simulex simulerer en evakuering av bygget.
Lisi Med Lisi kan man designe og simulere heisløsninger for å optimalisere
transporteringen av personer i bygningen.
45
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 be-
nytter IES VE de termiske sonene hentet fra modellen i IDM. En termisk sone
er de�nert som et lukket volum, avgrenset av gulv, vegger og tak, og de�neres
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 applika-
sjonen blir modellen lagret i hoved�len *.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
5Må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 applika-
sjonene 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 analyseapplikasjo-
nene 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 spesi�kke innstillinger som
ble gjort med hensyn til IFC og gbXML.
48
Generelle innstillinger
De�nering av Prosjektinformasjon
Relevant prosjektinformasjon for energianalyser vil være modellens bygnings-
type, geogra�ske lokasjon og orientering. Ved å gå inn i �Project Information�
under �Manage�-fanen kan man velge �Energy Settings� hvor de to førstnevnte
attributtene kan spesi�seres (Se Figur 5.1). For å endre modellens orientering i
Figur 5.1: �Energy Settings� i Revit
forhold til geogra�sk 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 de�ni-
sjonen 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
De�nering av rom
Både Ecotect og IES VE baserer seg på termiske soner for å gjøre analyser
av en modell. En termisk sone er de�nert som et lukket volum, avgrenset av
49
gulv, vegger/romseparasjonslinjer og tak/etasjeskillere. De termiske sonene blir
de�nert 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 de�nere 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 ma-
len de�nerer familier, innstillinger som måleenheter, skalering og skravering og
geometri [Autodesk, 2009b]. De modellene som ble laget for overføring til Eco-
tect Analysis brukte �IFC Metric Template.rte� som prosjektmal.
IFC-avbildings�l
For å kunne eksportere en Revit-modell til IFC må man de�nere hvilke IFC-
klasser de ulike Revit-familiene samsvarer med i menyen �IFC Options� (se Figur
5.6). IFC-avbildings�len som ble brukt under testene for overføring mellom Re-
vit 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 automa-
tisk 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
Over�ater blir de�nert i gbXML-skjemaet ut ifra hvilke soner som tilstøter over-
�aten (Se Figur D.18 i Vedlegg D). Siden det ikke er de�nert noen rom innven-
dig i søyler� og søyler er de�nert som over�ater i gbXML-skjemaet� vil søylens
over�ate 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 feilmel-
ding i eksporteringsvinduet (Se Seksjon 4.2) som sier at det er ude�nerte 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 hvil-
ken 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 prosjektinforma-
sjon, 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 geogra�sk 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-kantet vegg
(b) Modell med en-keltkrummet vegg
(c) Modell med dobbeltkrum-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 dobbelt-krummet 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 de�nere 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
varmegjennomgangskoe�sient 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
6Resultater
6.1 Generelt
Dette kapittelet gir en presentasjon av resultatene fra testene som ble utført, en
oppsummering av resultatene og til slutt en drøfting av resultatene.
6.2 Presentasjon av resultatene
Test 1 � Prosjektinformasjon
Se Vedlegg F for resultatene fra Test 1.
Ecotect Analysis
Lokasjon Standard lokasjon for modeller i Ecotect Analysis er Perth, Australia.
Denne verdien ble ikke endret etter at IFC-modellen ble importert.
Orientering Informasjon om orientering ble overført til Ecotect, men siden
Ecotect kun bruker �True North� er verdien satt til 0. Med andre ord har
modellen blitt rotert til absolutte koordinater, relativ til �True North�.
Bygningstype Informasjon om bygningstype ble ikke overført til Ecotect.
Enhet Hvilke enheter som ble brukt i modellen ble ikke endret i Ecotect, men
tallverdiene ble konvertert til riktig verdi.
57
IES VE
Lokasjon Informasjon om lokasjon ble overført til IES VE.
Orientering Informasjon om orientering ble overført til IES VE, men siden
IES VE kun bruker �True North� er verdien satt til 0. Med andre ord har
modellen blitt rotert til absolutte koordinater, relativ til �True North�.
Bygningstype Informasjon om bygningstype ble overført til IES VE.
Enhet Informasjon om valgt enhet ble overført til IES VE.
Test 2 � Informasjon om objekttyper og rom
Se Vedlegg G for resultatene fra Test 2.
Ecotect Analysis
Figur 6.1: Modell fra Test 2 lastet inn i Ecotect Analysis
Plassering Som det tydelig fremgår av Figur 6.1 ble ikke objektene sin 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
glass�ate og vinduskarm sin orientering i forhold til hverandre var for-
dreid. 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 Ingen informasjon om etasjeskiller ble lastet inn i Ecotect.
Innerveggtype 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 glass�ater 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 over�ate 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 Analy-
sis, 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 infor-
masjon om rommet lastet inn.
60
IES VE
(a) Modell med mangekantetvegg
(b) Modell med enkeltkrum-met vegg
(c) Modell med dobbelt-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. Applika-
sjonen evner ikke å nøyaktig fremstille krumme vegger, men bruker polygon�ater
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 Ana-
lysis, 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 dobbelt-krummet 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. Applika-
sjonen evner ikke å nøyaktig fremstille krumme tak, men bruker polygon�ater
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 mate-
rialegenskaper. De forekomstene som inneholdt typeinformasjon ble tildelt stan-
dard materialegenskaper for den respektive typen.
63
6.3 Sammendrag av resultateneA
Side 1
ProsjektinformasjonLokasjon û üOrientering ü ü
û üEnhetsbenevning û ü
Vindu û üDør û üTak ü üGulv ü üEtasjeskiller û ü üYttervegg ü üInnervegg û üSøyle û ûRominformasjonNavn ü üVolum û üPlassering û üAreal til avgrensende flater ü üVeggeometriPlane vegger ü ü
û üDobbeltkrummede vegger û üTakgeometriPlane tak ü ü
û üDobbeltkrummede tak û ûMaterialegenskaperMaterialegenskaper û û
Ecotect via IFC IES VE via gbXML
Bygningstype
Objekttype
Enkeltkrummede vegger
Enkeltkrummede tak
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 avgren-
sende �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 topp�ater til rom-
64
mene ble satt til objekttypen tak, alle side�ater til yttervegg og alle bunn�ater
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øl-
gende hierarki: Lokasjon, Bygning, Rom, Over�ater og Åpninger (se Figur 6.9).
Ut i fra lokasjon- og bygningskategorien hentet IES VE informasjon om koor-
dinater, orientering og bygningstype til modellen. Romkategorien gav IES VE
informasjon om navn, volum og over�ateareal til romsoner. Ut i fra tilstøten-
de soner som omsluttet hver romsone ble romsonenes over�atetyper (innervegg,
yttervegg, etasjeskiller, tak og gulv) bestemt. Over�atetypenes materialinfor-
masjon ble dog ikke lastet inn. Åpningstyper i over�atene (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 å de�nere 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 over�atene
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 tak�ater, 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 vans-
kelig å 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 ut-
fø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
7Anbefaling 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 bereg-
ningsprogrammene som skal brukes i tilknytning til disse beregningene skal være
validert etter NS-EN 15265 [Standard Norge, 2007]. Foreløpig er det kun appli-
kasjonene 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 å do-
kumentere energibehov og varmetapstall til et bygg. Analyseapplikasjonene kan
likevel ha en stor nytteverdi i byggeprosjekter ved å være et verktøy for å vurde-
re 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. In-
formasjonsoverfø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å de�nere materialegenskapene til byg-
ningskomponentene 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 gbXML-
skjemaet var prosessen med å overføre informasjonen mer oversiktlig. Ved over-
fø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 teste-
ne 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 de�nert ordentlig, slik at disse
blir tolket riktig ved eksporteringen. Hvis modellen inneholder dobbeltkrum-
mede �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 de�neres et miljøprogram. Hensikten med miljøpro-
grammet er å få konkretisert miljømålene for prosjektet samt å lage et grunnlag
for hva slags miljøpro�l man ønsker at bygget skal ha [Marton, 2008]. Måle-
ne kan blant annet omfatte byggeprosessen, område- og infrastrukturen og be-
byggelsen [Statsbygg, 2010]. Miljøprogrammet sin utarbeidelse baserer seg på
prosjekteierens miljøpolitikk, konsekvensutredningen av prosjektet og o�entlige
lover, forskrifter og myndighetskrav som er relevante for prosjektet.
For å nå målene som er de�nert i miljøprogrammet må løsninger av en rekke
ulike aspekter ved bygget vurderes. Dette inkluderer blant annet tra�kkgenere-
ring, avfallshåndtering under byggeprosessen, valg av materialer, tekniske instal-
lasjoner, 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
re�eksjonen 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 byggepro-
sjektet jobbe samtidig opp mot samme modell. Analyseapplikasjoner kan hente
ut all relevant informasjon, analysere informasjonen og gjøre eventuelle endrin-
ger som vil bli re�ektert 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 produk-
sjonen av bygningskomponentene. I tillegg får man en dokumentasjon av hvilke
miljøfarlige sto�er 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 ap-
plikasjonene 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 over-
fø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 datatek-
nisk forstand [Howie et al., 1996]. Med andre ord vil ikke IFC-modellen være
et optimalt kommunikasjonsmedium mellom applikasjoner og databaser. Et al-
ternativ å 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 de�neres. 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
8Konklusjon 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 mel-
lom modelleringsapplikasjonen Revit Architecture og analyseapplikasjonene Eco-
tect 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 IFC-
modellen innebærer at alle applikasjonene må kunne importere all infor-
masjonen 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 tekstdoku-
menter [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 byg-
ningsinformasjon 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 geome-
tri. 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 IFC-
modellen kun støtter statiske datastrukturer vil den ikke fungere optimalt
for slik kommunikasjon.
gbXML
• gbXML-formatet henter kun ut spesi�kk informasjon relevant for en ana-
lyseapplikasjon og gjør forenklinger i informasjonen. Dette er fordelaktig
for analyseprogrammene, da formatet er enkelt å implementere. Slike for-
enklinger fører dog til at konverteringen ikke er en tapsfri prosess. Over-
føring via gbXML-formatet er derfor en enveiskommunikasjon fra model-
leringsapplikasjonene til analyseapplikasjonene.
• gbXML-skjemaet representerer geometrien til over�ater ved hjelp av to
attributter: plan polygongeometri og rektangulær polygongeometri. Kun
rektangulær geometri kan representeres med disse to attributtene og re-
presenteringen 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
ResultaterA
Side 1
ProsjektinformasjonLokasjon û üOrientering ü ü
û üEnhetsbenevning û ü
Vindu û üDør û üTak ü üGulv ü üEtasjeskiller û ü üYttervegg ü üInnervegg û üSøyle û ûRominformasjonNavn ü üVolum û üPlassering û üAreal til avgrensende flater ü üVeggeometriPlane vegger ü ü
û üDobbeltkrummede vegger û üTakgeometriPlane tak ü ü
û üDobbeltkrummede tak û ûMaterialegenskaperMaterialegenskaper û û
Ecotect via IFC IES VE via gbXML
Bygningstype
Objekttype
Enkeltkrummede vegger
Enkeltkrummede tak
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
bygningstype. Romforekomstene i modellen inneholdt navn og areal til avgren-
sende �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 topp�ater til rommene ble satt til
objekttypen tak, alle side�ater til yttervegg og alle bunn�ater 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å Beta-
stadiet. Ved en forbedring av Ecotect Analysis, Revit Architecture og IFC-
modellen 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,
over�ateareal og plassering i forhold til hverandre ble overført. Ut i fra tilstø-
tende soner som omsluttet hver romsone ble romsonenes over�atetyper bestemt.
Vinduer og dører sin arealinformasjon og plassering ble overført, men ikek de-
taljer som vindussprosser og glassareal i dører. På grunn av gbXML-skjemaet
sin måte å de�nere soner på kunne ikke søyler tas med i modellene. Ingen in-
formasjon om materialegenskaper ble overført. Ved overføring av modeller som
inneholdt dobbeltkrummede �ater ble geometrien ofte unøyaktig, og i visse til-
feller ble ikke dobbeltkrummede tak�ater en lukket �ate.
Muligheter for bedre interoperabilitet
Den viktigste funksjonen til BIM er å legge til rette for bedre menneskelig sam-
arbeid i byggebransjen. For å få til et godt samarbeid er man avhengig av
god kommunikasjon [Eikeland, 2000]. Med hensyn til BIM fordrer god kommu-
nikasjon 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 applika-
sjonene 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 dataak-
sesslag og forretningslag og sammen blir enige om grunnprinsipper for hvor-
dan informasjon skal de�neres og overføres. Dette innebærer at leverandørene
vil miste noen av sine konkurransefortrinn og brukervennligheten og funksjo-
naliteten til applikasjonene vil bli desto viktigere, noe som vil være gunstig
for forbrukerne. Igangsettingen av et slikt samarbeid mellom applikasjonsleve-
randører avhenger av at aktørene i byggenæringen innser behovet for en slik
kommunikasjonsmåte og at de sammen formidler dette behovet til applikasjons-
leverandø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 analyseappli-
kasjoner.
• 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 database-
servere 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 e�ekt bruken av BIM i byggepro-
sjekter 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 konsekven-
sene 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 de�nisjon for hva BIM er. Etableringen av en slik
de�nisjon vil være gunstig for å identi�sere 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). An object de-
sign framework for structural engineering. Engineering with Computers,
11(4):213�226.
[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. http://discussion.
autodesk.com/forums/message.jspa?messageID=6186338. 23.05.10.
[Autodesk, 2009b] Autodesk (2009b). 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 resi-
dential 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 70�83. Citeseer.
[Bourarsa, 2005] Bourarsa, N. (2005). Estimating Energy Use Early and Often.
Public Interest Energy Research, California Energy Commission. CEC-500-
2005-140-FS.
[buildingSMART, 2010a] buildingSMART (2010a). About us. http://www.
iai-tech.org/about-us/?searchterm=modelup. 12.04.10.
[buildingSMART, 2010b] buildingSMART (2010b). Iai tech international. http:
//www.iai-tech.org. 10.04.10.
[buildingSMART, 2010c] buildingSMART (2010c). Summary of ifc relea-
ses. 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. 16.04.10.
77
[CIBSE, 1999] CIBSE, E. (1999). CIBSE Guide A. The Chartered Institution
of Building Services Engineers, London.
[Conradie, 2009] Conradie, D. (2009). Building information modelling (BIM).
Green Building.
[Dong et al., 2007] Dong, B., Lam, K., Huang, Y. C., and Dobbs, G. M. (2007).
A comparative study of the IFC and gbXML informational infrastructures
for data exchange in computational design support environments. In Building
Simulation 2007, pages 1530�1537.
[Eastman, 1999] Eastman, C. (1999). Building product models: computer en-
vironments supporting design and construction. CRC.
[Eastman et al., 2008] Eastman, C., Teicholz, P., Sacks, R., and Liston, K.
(2008). BIM Handbook: A guide to building information modeling for ow-
ners, managers, designers, engineers, and contractors. John Wiley & Sons
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). Green O�ce Buildings:
A practical guide to development. Washington, DC: ULI�the Urban Land
Institute.
[gbXML, 2010] gbXML (2010). Open green building xml schema: a building
information modeling solution for our green world. http://gbxml.org. 09.05.10.
[Graphisoft, 2009] Graphisoft (2009). BIM curriculumn. Technical report,
Graphisoft Inc.
[Graphisoft, 2010] Graphisoft (2010). The archicad solution. http://www.
graphisoft.com/community/why_switch/the_archicad_solution.html. 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. http://www.ifcwiki.
org/index.php/Basic_Informations. 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). Den forunderlige reisen gjennom data-
historien. Tano/Universitetsforlaget.
[Hensen and Radosevic, 2004] Hensen, J. and Radosevic, M. (2004). Teaching
building performance simulation-some quality assurance issues and experien-
ces. In Proc. Int. Conference on Passive and Lowenergy Architecture�PLEA,
pages 1�8.
[Howard and Bjørk, 2008] Howard, R. and Bjørk, B. (2008). Building informa-
tion modelling - Experts views on standardisation and industry deployment.
Advanced Engineering Informatics, 22(2):271�280.
[Howie et al., 1996] Howie, C., Kunz, J., and Law, K. (1996). Soft-
ware interoperability. Stanford University, USA http://www. dacs. dtic.
mil/techs/interop/title. shtml, accessed January, 20:2003.
[Idehen, 1993] Idehen, K. (1993). ODBC technical white paper. http://www.
openlinksw.com/info/docs/odbcwhp/tableof.htm. 22.05.10.
[IES VE, 2009] IES VE (2009). BIM + Building Performance Analysis Using
Revit 2010 and IES <Virtual Environment>.
[IES VE, 2010] IES VE (2010). IES VE User's Guide.
[ISO, 2010] ISO (2010). Tc 184/sc 4. http://www.iso.org/iso/standards_
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). Digitale Produktmodeller i byggenærin-
gen. PhD thesis, NTNU, Institutt for konstruksjonsteknikk.
[Kemmerer, 1999] Kemmerer, S. (1999). STEP: The grand experience. of)
NIST Special Publication 939, National Institute of Standards and Technolo-
gy, Gaithersburg, MD, 1999.
[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. 08.05.10.
79
[Kommunal- og regionaldepartementet, 2009] Kommunal- og regionaldeparte-
mentet (2009). Bygg for framtida. Miljøhandlingsplan for bolig- og byggsek-
toren 2009 � 2012. Grøset.
[Kommunal- og regionaldepartementet, 2010] Kommunal- og regionaldeparte-
mentet (2010). Forskrift om tekniske krav til byggverk (byggteknisk for-
skrift). 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. Wiley.
[Laiserin, 2002] Laiserin, J. (2002). Comparing pommes and naranjas. http:
//www.laiserin.com/features/issue15/feature01.php. 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. http://www.byggemiljo.
no/. 12.06.10.
[MSG, 2010] MSG (2010). IFC documentation. http://www.iai-tech.org/ifc/
IFC2x4/beta3/html/index.htm. 08.05.10.
[Norconsult, 2010] Norconsult (2010). BIM-kalkyle med Informasjonssystemer
(ISY) calcus. http://www.nois.no/?aid=9099171. 26.03.10.
[OpenSpirit, 2010] OpenSpirit (2010). Enabling cross-discipline collaboration
in the digital oil�eld. 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. http:
//www.aecbytes.com/viewpoint/2004/issue_3.html. 16.04.10.
[Shah and Kesan, 2008] Shah, R. and Kesan, J. (2008). Lost in Translation:
Interoperability Issues for Open Standards�ODF and OOXML as Examples.
University of Illinois Legal Working Paper Series, page 97.
80
[Simensen, 2010] Simensen, K. H. (2010). Informasjon om openspirit. Samtale
med tidligere programmerer for Schlumberger.
[Standard Norge, 2007] Standard Norge (2007). NS 3031:2007 Beregning av
bygningers energiytelse � Metode og data. Technical report, Standard Norge.
[Statsbygg, 2010] Statsbygg (2010). Miljøprogram. http://www.
miljoprogrammering.no/. 12.06.10.
[Svendsen, 2007] Svendsen, P. A. (2007). Eu knuser windows-monopolet. http:
//www.nrk.no/nyheter/okonomi/1.3486728. 22.05.10.
[Syvertsen, 2009] Syvertsen, T. G. (2009). TKT4505 Objektmodellering. Fore-
lesning.
[Wikipedia, 2010] Wikipedia (2010). Top-down and bottom-up design. http:
//en.wikipedia.org/wiki/Top-down_and_bottom-up_design. 15.05.2010.
[Yudelson, 2008] Yudelson, J. (2008). Green building through integrated design.
McGraw-Hill Professional.
81
Vedlegg
82
A Eksempel på hvordan attributter arves i IFC
ENTITY IfcBeamSUBTYPE OF (IfcBuildingElement);
END_ENTITY;
ENTITY IfcBeam;ENTITY IfcRoot;
GlobalId : IfcGloballyUniqueId;OwnerHistory : IfcOwnerHistory;Name : OPTIONAL IfcLabel;Description : OPTIONAL IfcText;
ENTITY IfcObjectDefinition;INVERSE
HasAssignments : SET OF IfcRelAssigns FOR RelatedObjects;IsDecomposedBy : SET OF IfcRelDecomposes FOR RelatingObject;Decomposes : SET [0:1] OF IfcRelDecomposes FOR RelatedObjects;HasAssociations : SET OF IfcRelAssociates FOR RelatedObjects;
ENTITY IfcObject;ObjectType : OPTIONAL IfcLabel;
INVERSEIsDefinedBy : SET OF IfcRelDefines FOR RelatedObjects;
ENTITY IfcProduct;ObjectPlacement : OPTIONAL IfcObjectPlacement;Representation : OPTIONAL IfcProductRepresentation;
INVERSEReferencedBy : SET OF IfcRelAssignsToProduct FOR RelatingProduct;
ENTITY IfcElement;Tag : OPTIONAL IfcIdentifier;
INVERSEHasStructuralMember : SET OF IfcRelConnectsStructuralElement FOR RelatingElement;FillsVoids : SET [0:1] OF IfcRelFillsElement FOR RelatedBuildingElement;ConnectedTo : SET OF IfcRelConnectsElements FOR RelatingElement;HasCoverings : SET OF IfcRelCoversBldgElements FOR RelatingBuildingElement;HasProjections : SET OF IfcRelProjectsElement FOR RelatingElement;ReferencedInStructures : SET OF IfcRelReferencedInSpatialStructure FOR RelatedElements;HasPorts : SET OF IfcRelConnectsPortToElement FOR RelatedElement;HasOpenings : SET OF IfcRelVoidsElement FOR RelatingBuildingElement;IsConnectionRealization : SET OF IfcRelConnectsWithRealizingElements FOR RealizingElemenProvidesBoundaries : SET OF IfcRelSpaceBoundary FOR RelatedBuildingElement;ConnectedFrom : SET OF IfcRelConnectsElements FOR RelatedElement;ContainedInStructure : SET [0:1] OF IfcRelContainedInSpatialStructure FOR RelatedElements
ENTITY IfcBuildingElement;ENTITY IfcBeam;
END_ENTITY;
Figur A.1: Arv av attributter for IFC BEAM
83
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 *.DWGAutoCAD DXF Files *.DXFIndustry Foundation Classes *.IFCAutodesk Revit Files *.RVTAutodesk Revit Files *.RFA
Figur C.1: Autodesk Revit 2011 Importevne [Autodesk, 2010a]
Eksport
AutoCAD DWG Files *.DWGAutoCAD DXF Files *.DXFAutoCAD DGN Files *.DGNACIS CAD Files *.SATAutodesk Design Web Format *.DWFAutodesk Design Web Format *.DWFxAutodesk FBX Files *.FBXIndustry Foundation Classes *.IFCGreen Building XML *.XMLAutodesk Revit Files *.RVTAutodesk Revit Files *.RFA
Figur C.2: Autodesk Revit 2011 Eksportevne [Autodesk, 2010a]
85
Autodesk Ecotect
Import
ASCII Model Files *.MODAnalysis grid Data Files *.GRDRay/Particle Data Files *.RAYWeather data files *.WEARadiance Point Value data *.DATRadiance Scene Files *.RADEnergyPlus Input data File *.IDFEnergy Plus Model summary *.EIOAutoCAD DXF Files *.DXFStereo lithography file *.STLGreen Building XML *.XMLIndustry Foundation Classes *.IFCGoogle KML Data *.KML/KMZHPGL Plot Files *.PLT og *.HGLMaterial Library Files *.LIBCFD Output Data File *.*Windows Bitmap *.BMPJPEG Image *.JPG
Figur C.3: Model/Analysis Data [Autodesk, 2010a]
86
DXF *.DXFDXF Point Cloud *.DXFIFF to 3D *.IFFIFF to DEM *.IFFImagine *.IOBLightscape *.LPLightwave *.LWOMaya RTG *.RTGMaxNC Digital probe *.TXTMicroDEM *.DEMOpen Inventor *.IVRealiMation *.RBSRenderware *.RWXScenery animator *.LANDSculpt *.SCENEShopbot Digital Probe *.SBPSoftimageXSI *.XSIStereoLithography *.STLtrueSpace .COB og *.COAUSGS GTOPO30/SRTM30 *.DEMUSGS 1 degree DEM *.DEMUSGS SDTS *.DDFUSGS SRTM-1/SRTM-3 *.HGTVideoscape *.GEOVistaPro *.DEMVRML *.WRLWavefront *.OBJX3D *.X3DXGL, ZGL *.XGL og *.ZGLXYZ *.XYZXYZ (No Mesh) *.XYZ
Figur C.4: 3D CAD Geometry [Autodesk, 2010a]
87
Eksport
ASCII Model Files *.MODRay/Particle Data Files *.RAYAnalysis grid Data Files *.GRDMaterial Library Files *.LIB
Figur C.5: Model/Analysis Data [Autodesk, 2010a]
Radiance Scene Files *.RADRadiance Octree Files *.OCTPOV Ray Scene files *.POVVRML Scene files *.WRLAutoCAD DXF Files *.DXFEnergyPlus Input data File *.IDFDOE-2 Input Files *.INPSBEM Input Files *.INPAIOLOS Input Files *.PPAHTB2 Files *.TOPAccurate Scratch file *.*ESP-r input File *.CFGWinAir4 CFD Geometry File *.GEONIST FDS Input data File *.fdsGreen Building XML *.XML
Figur C.6: External Analysis Tool [Autodesk, 2010a]
Windows metafile *.WMFWindows bitmap *.BMPGraphics Interchange Format *.GIFJPEG Image *.JPG
Figur C.7: Image/Screenshot [Autodesk, 2010a]
88
IES VE
Import
Geometry File *.GEMGreen Building XML *.XML
Figur C.8: IES VE Importevne [IES VE, 2010]
Eksport
Geometry File *.GEM3D System ASCII File *.STLAutoCAD DXF Files *.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-avbildings�l
Category Subcategory IFC Class Name Type1 Not ExportedAir Terminals IfcAirTerminalArea Polylines IfcPolylineArea Tags Not ExportedAreas IfcSpaceAreas Color FillAreas Interior FillAreas ReferenceBoundary Conditions Not ExportedCable Tray Fittings IFCCableTrayFittingCable Tray Fittings Center lineCable Trays IFCCableTraySegmentCable Trays Center lineCable Trays DropCable Trays RiseCallouts Not ExportedCasework IfcFurnitureCasework Hidden LinesCasework Tags IfcContextDependentUnit IfcLabelCeiling Tags IfcContextDependentUnit IfcLabelCeilings IfcCoveringCeilings Common EdgesCeilings Cut PatternCeilings Finish 1 [4]Ceilings Finish 2 [5]Ceilings Hidden LinesCeilings Membrane LayerCeilings Structure [1]Ceilings Substrate [2]Ceilings Surface Pattern IfcCoveringCeilings Thermal/Air Layer [3]Color Fill Not ExportedColor Fill Legends Not ExportedColumns IfcColumnColumns Hidden LinesCommunication Devices IfcBuildingElementProxyConduit Fittings IFCConduitFittingConduit Fittings Center lineConduits IFCConduitSegmentConduits Center lineConduits DropConduits RiseConstraints IfcConstraintContour Labels Not ExportedCurtain Panel Tags Not ExportedCurtain Panels IfcCurtainWallCurtain Panels GlassCurtain Panels Hidden LinesCurtain Panels Panel Material 1Curtain Systems Not ExportedCurtain Systems Curtain System Grids Not ExportedCurtain Systems Hidden Lines Not ExportedCurtain Wall Mullions IfcCurtainWallCurtain Wall Mullions Hidden LinesData Devices IfcBuildingElementProxy
96
Demolished Not ExportedDetail Items IfcAnnotationDetail Items Heavy LinesDetail Items Hidden LinesDetail Items Light LinesDetail Items Medium LinesDimensions Not ExportedDimensions Automatic Sketch Dimensions Not ExportedDoor Tags IfcContextDependentUnit IfcLabelDoors IfcDoorDoors bovenlichtDoors BreakoutDoors Door JambDoors Door Trim-HorDoors Door Trim-VertDoors Door-Angle-1Doors Door-Angle-2Doors Door-Garage-PanelDoors Door-Int. Trim-Hor.Doors Door-Int. Trim-Vert.Doors Door-JambDoors Door-PanelsDoors Door-RailDoors Door-StyleDoors Door-TrackDoors draairichting binnenzijdeDoors draairichting buitnzijdeDoors draairichting plattegrondDoors Elevation SwingDoors Frame/Mullion IfcDoorDoors Glass IfcDoorDoors HardwareDoors Hidden LinesDoors Metal FrameDoors Moulding/ArchitraveDoors Opening IfcDoorDoors Panel IfcDoorDoors Plan SwingDoors plintDoors ThresholdDoors wood panelDuct Accessories IfcBuildingElementProxyDuct Fittings IfcDuctFittingDuct Fittings Center lineDuct Fittings InsulationDuct Fittings LiningDucts IfcDuctSegmentDucts Center lineDucts DropDucts InsulationDucts LiningDucts RiseElectrical Equipment IfcBuildingElementProxyElectrical Equipment Hidden LinesElectrical Equipment Tags Not ExportedElectrical Fixture Tags Not Exported
97
Electrical Fixtures IfcBuildingElementProxyElectrical Fixtures Hidden LinesElevations Not ExportedEntourage IfcBuildingElementProxyEntourage Hidden LinesExisting Not ExportedFilled region IfcAnnotationFire Alarm Devices IfcBuildingElementProxyFlex Ducts IfcDuctSegmentFlex Ducts Center lineFlex Ducts InsulationFlex Ducts PatternFlex Pipes IfcPipeSegmentFlex Pipes Center LineFlex Pipes InsulationFlex Pipes PatternFloors IfcSlabFloors Analytical ModelFloors Common EdgesFloors Cut PatternFloors Finish 1 [4]Floors Finish 2 [5]Floors Hidden LinesFloors Interior EdgesFloors Membrane LayerFloors Slab Edges IfcBuildingElementProxyFloors Structure [1]Floors Substrate [2]Floors Surface Pattern IfcSlabFloors Thermal/Air Layer [3]Furniture IfcFurnitureFurniture Hidden LinesFurniture Overhead LinesFurniture Systems IfcSystemFurnitureElementFurniture Systems Hidden LinesGeneric Annotations Not ExportedGeneric Model Tags Not ExportedGeneric Models IfcBuildingElementProxyGeneric Models Hidden LinesGeneric Models IfcOpeningElements IfcOpeningElementGeneric Models OverheadGrids Not ExportedGuide Grid Not ExportedHVAC Zones Not ExportedHVAC Zones Boundary Not ExportedHVAC Zones Color Fill Not ExportedHVAC Zones Interior Fill Not ExportedHVAC Zones Reference Lines Not ExportedImports in Families Not ExportedLevels IfcBuildingStoreyLighting Devices IfcBuildingElementProxyLighting Fixture Tags Not ExportedLighting Fixtures IfcLightFixtureTypeLighting Fixtures Hidden LinesLighting Fixtures Light SourceLines IfcAnnotation
98
Lines <Area Boundary> IfcAnnotationLines <Beyond> IfcAnnotationLines <Centerline> Not ExportedLines <Demolished> IfcAnnotationLines <Hidden> IfcAnnotationLines <Overhead> IfcAnnotationLines <Revision Cloud> IfcAnnotationLines <Room Separation> IfcAnnotationLines <Sketch> Not ExportedLines <Space Separation>Lines <Stair/Ramp Sketch: Boundary> Not ExportedLines Stair/RampSketch:LandingCenter Not ExportedLines <Stair/Ramp Sketch: Riser> Not ExportedLines <Stair/Ramp Sketch: Run> Not ExportedLines Axis of Rotation Not ExportedLines Hidden LinesLines Insulation Batting Lines IfcAnnotationLines Lines IfcAnnotationLines Medium Lines IfcAnnotationLines Thin Lines IfcAnnotationLines Wide Lines IfcAnnotationMass Not ExportedMass Form Not ExportedMass Gridlines Not ExportedMass Hidden Lines Not ExportedMass Mass Floor Not ExportedMass Nodes Not ExportedMass Pattern Fill Not ExportedMass Pattern Lines Not ExportedMassing IfcBuildingElementProxyMechanical Equipment IfcBuildingElementProxyMechanical Equipment Hidden LinesMechanical Equipment Tags Not ExportedMulti-Category Tags Not ExportedNew Not ExportedNurse Call Devices IfcSwitchingDeviceTypePanel Schedule Graphics Not ExportedParking IfcBuildingElementProxyParking Hidden LinesParking Parking LayoutParking Reference LineParking StripeParking Tags Not ExportedPipe Accessories IfcValveTypePipe Fittings IfcPipeFittingPipe Fittings Center linePipe Fittings InsulationPipes IfcPipeSegmentPipes Center LinePipes DropPipes InsulationPipes RisePlan Region Not ExportedPlanting IfcBuildingElementProxyPlanting Hidden LinesPlanting Tags Not Exported
99
Plumbing Fixture Tags Not ExportedPlumbing Fixtures IfcBuildingElementProxyPlumbing Fixtures Hidden LinesProperty Line Segment Tags Not ExportedProperty Tags IfcContextDependentUnit IfcLabelRailing Tags Not ExportedRailings IfcRailingRailings Balusters IfcRailingRailings Hidden LinesRailings Railings Beyond Cut Line IfcRailingRailings Rails IfcRailingRamps IfcRampRamps Down Arrow IfcRampRamps DOWN text IfcRampRamps Hidden LinesRamps Incomplete ramps IfcRampRamps Ramps Beyond Cut Line IfcRampRamps Stringers IfcRampRamps Stringers Beyond Cut Line IfcRampRamps Up Arrow IfcRampRamps UP text IfcRampRaster Images Not ExportedReference Planes Not ExportedRoads IfcBuildingElementProxyRoads Hidden LinesRoof Tags IfcContextDependentUnit IfcLabelRoofs IfcRoofRoofs Common EdgesRoofs Curtain Roof Grids IfcRoofRoofs Cut PatternRoofs Fascias IfcRoofRoofs Finish 1 [4]Roofs Finish 2 [5]Roofs Gutters IfcRoofRoofs Hidden LinesRoofs Interior EdgesRoofs Membrane LayerRoofs Roof Soffits IfcRoofRoofs Structure [1]Roofs Substrate [2]Roofs Surface Pattern IfcRoofRoofs Thermal/Air Layer [3]Room Polylines IfcPolylineRoom Tags IfcContextDependentUnit IfcLabelRooms IfcSpaceRooms Color FillRooms Interior FillRooms ReferenceRuled Curtain System IfcCurtainWallSchedule Graphics Not ExportedScope Boxes Not ExportedSections Not ExportedSecurity Devices IfcBuildingElementProxyShaft Openings Not ExportedShaft Openings Hidden Lines Not ExportedSite IfcSite
100
Site Hidden LinesSite Pads IfcSlabSite Parking LayoutSite Project Base Point Not ExportedSite Property IfcBuildingElementProxySite Property LinesSite StripeSite Survey Point Not ExportedSite Tags IfcContextDependentUnit IfcLabelSpaces Not ExportedSpaces Color Fill Not ExportedSpaces Interior Not ExportedSpaces Reference Not ExportedSpecialty Equipment IfcBuildingElementProxySpecialty Equipment Hidden LinesSpecialty Equipment Tags Not ExportedSpot Coordinates Not ExportedSpot Elevations Not ExportedSpot Slopes Not ExportedSprinklers IfcFireSuppressionTerminalTypeStair Tags Not ExportedStairs IfcStairStairs Down Arrow IfcStairStairs DOWN Text IfcStairStairs Hidden LinesStairs Incomplete Stairs IfcStairStairs Stairs Beyond Cut Line IfcStairStairs Stringers IfcStairStairs Stringers Beyond Cut Line IfcStairStairs Up Arrow IfcStairStairs UP Text IfcStairStructuralAreaReinforcement Not ExportedStructuralAreaReinforcement Boundary Not ExportedStructural Beam Systems Not ExportedStructural Beam Systems Hidden Lines Not ExportedStructural Column Tags IfcContextDependentUnit IfcLabelStructural Columns IfcColumnStructural Columns Analytical ModelStructural Columns Hidden FacesStructural Columns Hidden LinesStructural Columns Rigid LinksStructural Columns Stick SymbolsStructural Connections Not ExportedStructural Foundation Tags Not ExportedStructural Foundations IfcFootingStructural Foundations Analytical ModelStructural Foundations Hidden LinesStructural Framing IfcBuildingElementProxyStructural Framing Analytical ModelStructural Framing ChordStructural Framing GirderStructural Framing Hidden FacesStructural Framing Hidden LinesStructural Framing Horizontal BracingStructural Framing JoistStructural Framing Kicker Bracing
101
Structural Framing OtherStructural Framing PurlinStructural Framing Rigid LinksStructural Framing Stick SymbolsStructural Framing Vertical BracingStructural Framing WebStructural Framing Tags Not ExportedStructural Internal Loads Not ExportedStructural Internal Loads Internal Area Loads Not ExportedStructural Internal Loads Internal Line Loads Not ExportedStructural Internal Loads Internal Point Loads Not ExportedStructural Load Cases Not ExportedStructural Load Cases Accidental Loads Not ExportedStructural Load Cases Dead Loads Not ExportedStructural Load Cases Live Loads Not ExportedStructural Load Cases Roof Live Loads Not ExportedStructural Load Cases Seismic Loads Not ExportedStructural Load Cases Snow Loads Not ExportedStructural Load Cases Temperature Loads Not ExportedStructural Load Cases Wind Loads Not ExportedStructural Loads Not ExportedStructural Loads Area Loads Not ExportedStructural Loads Line Loads Not ExportedStructural Loads Point Loads Not ExportedStructural Path Reinforcement Not ExportedStructural Path ReinforcementBoundary Not ExportedStructural Rebar Not ExportedStructural Stiffener Tags Not ExportedStructural Stiffeners Not ExportedStructural Truss Tags Not ExportedStructural Trusses Not ExportedStructural Trusses Stick Symbols Not ExportedTelephone Devices IfcBuildingElementProxyTemporary Not ExportedText Notes IfcAnnotationTitle Blocks Not ExportedTitle Blocks Medium Lines Not ExportedTitle Blocks Thin Lines Not ExportedTitle Blocks Wide Lines Not ExportedTopography IfcBuildingElementProxyTopography Boundary Point IfcBuildingElementProxyTopography Hidden LinesTopography Interior Point IfcBuildingElementProxyTopography Primary Contours IfcBuildingElementProxyTopography Secondary Contours IfcBuildingElementProxyTopography Triangulation Edges IfcBuildingElementProxyView Titles Not ExportedWall Tags IfcContextDependentUnit IfcLabelWalls IfcWallWalls Analytical ModelWalls Common EdgesWalls Curtain Wall Grids IfcWallWalls Cut PatternWalls Finish 1 [4]Walls Finish 2 [5]Walls Hidden Lines
102
Walls Membrane LayerWalls Reveals IfcOpeningElementWalls Stacked Walls IfcWallWalls Structure [1]Walls Substrate [2]Walls Surface Pattern IfcWallWalls Thermal/Air Layer [3]Walls Wall Sweeps IfcBuildingElementProxyWalls/Interior:1 IfcWallWalls/Exterior:2 IfcWallWalls/Foundation:3 IfcWallWalls/Retaining:4 IfcWallWindow Tags IfcContextDependentUnit IfcLabelWindows IfcWindowWindows draairichting binnenWindows Elevation SwingWindows Frame/Mullion IfcWindowWindows Glass IfcWindowWindows Hidden LinesWindows MouldingWindows Opening IfcWindowWindows Plan SwingWindows Sill/Head IfcWindowWindows TrimWires Not ExportedWires Home Run Arrows Not ExportedWires Wire Tick Marks Not Exported
Figur E.20: IFC-avbildings�l
103
F Resultater fra Test 1
Revit Architecture Ecotect Analysis IES VELokasjon Latiture:60.8° Longitude:10.7° Latitude:-32° Longitude:116° Latiture:60.8° Longitude:10.7°Orientering 45° West of Project North 0° 0°Bygningstype Hospital --- HospitalEnhet Metric System Imperial System Metric System
Figur F.21: Resultater fra Test 1
104
G Resultater fra Test 2
A
Side 1
IES VE SUMRom 1 1etgNavn Gulv 397,57Volum 1005,28 0 1005,28 Tak 397,57Grunnflate 251,32 251,32 251,32 Yttervegg 319,2Yttervegg 208,656 301,463 208,656Utvendig Dør 2,6 0 2,6Utvendig Vindu 11,144 --- 11,144Innervegg 92,807 --- 92,807Innvendig Dør 2,6 0 2,6Innvendig Vindu 1,393 --- 1,393Tak 0 0 0Gulv 251,32 251,32 251,32 400,02Etasjeskille 251,32 0 251,32Rom 2NavnVolum 585 0 585Grunnflate 146,25 146,25 146,25Yttervegg 96,8 189,607 96,8Utvendig Dør 0 0 0Utvendig Vindu 0 --- 0Innervegg 92,807 --- 92,807Innvendig Dør 2,6 0 2,6Innvendig Vindu 1,393 --- 1,393Tak 0 0 0Gulv 146,25 146,25 146,25Etasjeskille 146,25 0 146,25 397,57 400,02NavnVolum 1616 0 1616Grunnflate 400,02 400,02 400,02Yttervegg 242,524 242,524 242,524Utvendig Dør 0 0 0Utvendig Vindu 79,074 79,074 79,074Innervegg 0 0 0Innvendig Dør 0 0 0Innvendig Vindu 0 0 0Tak 400,02 400,02 400,02Gulv 0 0 0Etasjeskille 400,02 0 400,02
Revit Ecotect
Dining Dining Dining
Family Study Family Study
Bedroom 3 Bedroom 3 Bedroom 3
Figur G.22: Resultater fra Test 2
105
