BIM og Miljøberegning

NTNU
Norges teknisk-naturvitenskapelige
universitet
Fakultet for Ingeniørvitenskap og teknologi
Institutt for konstruksjonsteknikk
Masteroppgave
Karl Kristian Olsson Haave
BIM og Miljøberegning
14. juni 2010
Institutt for konstruksjonsteknikk
Fakultet for ingeniørvitenskap og teknologi
NTNU- Norges teknisk- naturvitenskapelige universitet
TILGJENGELIGHET
Fullt tilgjengelig
MASTEROPPGAVE 2010
FAGOMRÅDE:
KONSTRUKSJONSINFORMATIKK
DATO: 14. juni 2010
ANTALL SIDER: 120
TITTEL:
BIM og Miljøberegning
BIM and Environmental Analysis
UTFØRT AV:
Karl Kristian Olsson Haave
SAMMENDRAG:
Building information modeling (BIM) blir tatt i bruk i stadig flere byggeprosjekter, og utfordringen
med å oppnå interoperabilitet mellom ulike typer applikasjoner har etter hvert blitt et tema.
Formålet med denne masteroppgaven er å vurdere interoperabiliteten mellom
modelleringsapplikasjoner og analyseapplikasjoner i dag, og hvilke muligheter man har til å
forbedre interoperabiliteten i tiden som kommer. I oppgaven blir ulike kommunikasjonsformater og
kommunikasjonsmåter vurdert. Videre blir interoperabiliteten mellom modelleringsapplikasjonen
Autodesk Revit 2011 og analyseapplikasjonene Ecotect Analysis 2011 og IES VE 6.0.6 testet.
Overføringsformatene IFC 2x3 og gbXML 0.37 ble brukt for å overføre informasjon fra Revit til
henholdsvis Ecotect og IES VE. Masteroppgaven har blitt utarbeidet i samarbeid med COWI
avdeling Trondheim, og oppgaven avsluttes med en anbefaling til COWI om valg av
overføringsformat og råd til videre arbeid for å forbedre interoperabiliteten mellom applikasjoner i
fremtiden.
FAGLÆRER: Tor G. Syvertsen
VEILEDER(E): Ingrid Alvsåker og Dagfinn Bell
UTFØRT VED: Institutt for Konstruksjonsteknikk, Fakultetet for Ingeniørvitenskap og Teknologi, NTNU.
Institutt for konstruksjonsteknikk
FAKULTET FOR INGENIØRVITENSKAP OG TEKNOLOGI
NTNU – Norges teknisk-naturvitenskapelige universitet
MASTEROPPGAVE 2010
for
stud. techn. Karl Kristian Olsson Haave
BIM og Miljøberegning
BIM and Environmental Analysis
Bakgrunn for oppgaven/problemstilling
Kandidaten har inngått i et samarbeid med bedriften COWI. COWI har tatt i bruk BIM på en
rekke byggeprosjekter og ønsker å teste ut to miljøberegningsprogrammer for å kartlegge
hvor godt de fungerer med Autodesk Revit.
Angrepsmåte
Kandidaten skal sette seg inn i og teste ut programmene Autodesk Ecotect og IES VE koblet opp mot
Autodesk Revit. Dette arbeidet vil innebære et litteraturstudium, samt praktisk bruk av
programmene. Referanseprosjektet som brukes for å teste programmene vil være den nye
barneavdelingen til Ålesund Sykehus.
Kandidaten ønsker å kartlegge følgende punkter:
•
Interoperabilitet mellom Revit og de to programmene.
•
Komme med forslag til hvordan COWI skal kunne håndtere eventuelle problemer med
interoperabilitet.
Resultat
Kandidaten skal utarbeide en rapport som inneholder en presentasjon av resultatene avdekket
under arbeidet med oppgaven. Herunder inngår vurdering av interoperabilitet mellom programvare
og drøfting av hvordan COWI kan håndtere eventuelle problemer med interoperabilitet for å sikre
at informasjonen er pålitelig. Til slutt skal kandidaten komme med forslag til hvilket program som
bør velges, basert på disse resultatene.
Oppgaven kan underveis tilpasses arbeidets forløp og kandidatens interesser.
Besvarelsen organiseres i henhold til gjeldende retningslinjer for masteroppgaver ved institutt for
konstruksjonsteknikk.
Kontaktperson hos bedrift:
Navn: Dagfinn Bell
Epost: [email protected]
Tlf:
93081497
Navn: Ingrid Alvsåker
Epost: [email protected]
Tlf:
Veileder:
48991094
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øteknikk ved NTNU i Trondheim fullbyrdet. Masteroppgaven er utviklet i faget
TKT4900 ved Institutt for Konstruksjonsteknikk under Fakultet for ingeniørvitenskap og teknologi på NTNU, i samarbeid med COWI, Trondheim.
En stor takk rettes til oppgavens hovedveileder
ved NTNU
Professor Tor G. Syvertsen
for hjelp til å stille de rette spørsmålene og for alltid å være en
ariadnetråd. Jeg ønsker også å takke COWI
Dagnn Bell
da spesielt Ingrid Alvsåker og
for å stille arbeidsplass og programvare til disposisjon og for å
ta seg tid til å hjelpe meg.
Takk til familie og venner for hjelp og støtte, og sist men ikke minst takk til
min kjære for alle middager og all nytraktet kae.
Trondheim 14. juni 2010
Karl Kristian Olsson Haave
Nunc est bibendum, nunc pede libero pulsanda tellus.
I
Sammendrag
For å gjøre detaljerte energianalyser var man tidligere avhengig av å ta ut
mengder manuelt fra 2D tegninger. Ulempene med dette var mange; prosessen var tidkrevende, kostet mye og i store prosjekter kunne man fort regne feil
og få unøyaktige mengder. Derfor ble antallet kalkyler og analyser ofte holdt
på et minimum [Jongeling, 2008]. I prosjekter som bruker Building Information
Model/Modelling (BIM) kan modellen importeres i en analyseapplikasjon, og
man kan bruke denne informasjonen for å utføre kalkyler og analyser. Prosessen
er raskere og mer nøyaktig, og fører ofte til at man utfører ere analyser og
oppnår et bedre resultat [Bourarsa, 2005].
Et byggeprosjekt består av en rekke ulike aktører, som ikke nødvendigvis
bruker samme type programvare. Det at en analyseapplikasjon skal kunne hente
ut informasjon fra en BIM avhenger av at applikasjonene som skal kommunisere er interoperabile. Den viktigste funksjonen til BIM er å legge til rette for
bedre menneskelig samarbeid i byggebransjen. For å få til et godt samarbeid er
man avhengig av god kommunikasjon [Eikeland, 2000]. Etter hvert som mer og
mer BIM-programvare har blitt utviklet har behovet for en standardisert måte
applikasjonene kan kommunisere på kommet tydelig frem.
Formålet med denne masteroppgaven er å vurdere interoperabiliteten mellom modelleringsapplikasjoner og analyseapplikasjoner i dag, og å vurdere hvilke
muligheter man har til å forbedre interoperabiliteten i tiden som kommer. Problemstillingen til masteroppgaven har blitt utarbeidet i samarbeid med COWI,
avdeling Trondheim. COWI har tatt i bruk BIM på en rekke byggeprosjekter og
ønsket å teste interoperabiliteten mellom modelleringsapplikasjonen Autodesk
Revit og analyseapplikasjonene Ecotect Analysis og Integrated Environmental
Solutions (IES) Virtual Environment (VE). For å vurdere interoperabiliteten
mellom applikasjonene ble en rekke ulike modeller laget. Disse modellene ble
konvertert til Industry Foundation Classes (IFC)-modeller og Green Building
Extensible Markup Language (gbXML)-skjemaer for å bli overført til henholdsvis Ecotect Analysis og IES VE. Informasjonen som ble testet for overføring er
prosjektinformasjon, rominformasjon og informasjon om objekttyper, geometri
og materialegenskaper.
gbXML-skjemaet klarte ikke å overføre informasjon om materialegenskapene
til bygningskomponenter og formatet hadde til tider problemer med nøyaktig
å representere kompleks geometri. Til tross for disse svakhetene kom gbXMLskjemaet klart best ut i de ulike testene. Vesentlig informasjon gikk tapt ved
overføring via IFC-modellen, og modellene som ble overført ble svært fordreid.
II
Full interoperabilitet mellom applikasjoner ved kommunikasjon via lformater innebærer at alle applikasjonene må kunne importere all informasjonen i len, og i tillegg kunne eksportere all informasjon til samme format. Å oppnå full
interoperabilitet ved en slik type kommunikasjon har vist seg å være svært utfordrende selv for overføring av enkle tekstdokumenter [Shah and Kesan, 2008],
og for informasjon i en BIM blir oppgaven tilnærmet umulig.
Å gå over til server-klient kommunikasjonstypen vil gi store muligheter til
å oppnå full interoperabilitet mellom applikasjoner. Kommunikasjonen mellom
applikasjonene og en database-serveren består av enkle transaksjoner for å hente
ut og putte inn informasjon. Applikasjoner sender spørringer til serveren for å få
den informasjonen som er relevant, og trenger ikke å kunne tolke all informasjon i
den digitale modellen. På grunn av dette er prosessen med å gjøre applikasjonene
interoperabile med serveren langt enklere enn å gjøre applikasjonene direkte
interoperabile med hverandre.
Full interoperabilitet mellom applikasjoner som kommuniserer via en server
avhenger av at applikasjonsleverandørene gir hverandre innsyn i sine dataaksesslag og forretningslag og sammen blir enige om grunnprinsipper for hvordan informasjon skal deneres og overføres. Dette innebærer at leverandørene
vil miste noen av sine konkurransefortrinn og brukervennligheten og funksjonaliteten til applikasjonene vil bli desto viktigere, noe som vil være gunstig
for forbrukerne. Igangsettingen av et slikt samarbeid mellom applikasjonsleverandører avhenger av at aktørene i byggenæringen innser behovet for en slik
kommunikasjonsmåte og at de sammen formidler dette behovet til applikasjonsleverandørene.
III
Innhold
Forord
I
Sammendrag
II
Innhold
IV
Akronymer
VII
Figurer
IX
1 Innledning
2
1.1
Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
BIM og miljøvurdering . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Oppgavens formål og omfang
. . . . . . . . . . . . . . . . . . . .
4
1.4
Metodikk
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.5
Disposisjon
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2 Building Information Model/Modelling (BIM)
7
2.1
Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Objektmodellering
. . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
Hva er BIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.4
Oppsummering . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3 Interoperabilitet
15
3.1
Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2
Overføringsformater
15
3.3
Kommunikasjon via loverføring
3.4
Kommunikasjon via database-server
3.5
IFC
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
16
. . . . . . . . . . . . . . . .
17
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
IV
3.6
Green Building Extensible Markup Language (gbXML)
. . . . .
28
3.7
Sammenligning av IFC og gbXML
. . . . . . . . . . . . . . . . .
31
4 Programvare
33
4.1
Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.2
Autodesk Revit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.3
Autodesk Ecotect . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.4
IES VE
43
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Målemetode
48
5.1
Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.2
Innstillinger i Revit . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.3
Testmodeller
53
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Resultater
57
6.1
Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.2
Presentasjon av resultatene
. . . . . . . . . . . . . . . . . . . . .
57
6.3
Sammendrag av resultatene . . . . . . . . . . . . . . . . . . . . .
64
6.4
Drøfting av resultatene . . . . . . . . . . . . . . . . . . . . . . . .
66
7 Anbefaling til COWI i forhold til BIM og miljøvurdering
67
7.1
Situasjonen i dag . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
7.2
Fremtidig arbeid med BIM og miljøvurdering
69
. . . . . . . . . . .
8 Konklusjon og videre arbeid
71
8.1
Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
8.2
Konklusjon
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
8.3
Videre arbeid . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
Kildeliste
77
V
Vedlegg
82
A
Eksempel på hvordan attributter arves i IFC
. . . . . . . . . . .
83
B
Eksempel på oppbygningen av et gbXML-element . . . . . . . . .
84
C
Import- og eksportevne til programvare
85
D
. . . . . . . . . . . . . .
gbXML-elementer og -attributter som støttes av Revit Architecture 2011
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
90
E
IFC-avbildingsl
F
Resultater fra Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . 104
G
Resultater fra Test 2 . . . . . . . . . . . . . . . . . . . . . . . . . 105
VI
96
Akronymer
3D
tredimensjonal
AEC
Architecture, Engineering and Construction
API
Application programming interface
ASHRAE
American Society of Heating, Refrigeration and Air-Conditioning
Engineers
BIM
Building Information Model/Modelling
CAD
Computer Aided Design
CDF
Computational Fluid Dynamics
CEC
California Energy Commission
CIBSE
Chartered Institution of Building Services Engineers
CIS/2
Cimsteel Integration Standard version 2
DAYSIM
Dynamic Daylight Simulations
DXF
Data eXchange Format
EPD
Environmental Product Declaration
FDS
Fire Dynamics Simulator
GARM
General AEC Reference Model
GBS
Green Building Studio Inc.
gbXML
Green Building Extensible Markup Language
GSA
General Services Administration
GUI
Graphical User Interface
HTML
HyperText Markup Language
HVAC
Heating, Ventilating and Air Conditioning
IAI
International Alliance for Interoperability
IDM
Integrated Data Model
IES
Integrated Environmental Solutions
VII
IFC
Industry Foundation Classes
ISO
International Organization for Standardization
ISY
Informasjonssystemer
IT
Informasjonsteknologi
JDBC
Java Database Connectivity
MSG
Model Support Group
NIST
National Institute of Standards and Technology
NURBS
Non Uniform Rational Basis Spline
OCA
Oce of the Chief Architect
ODBC
Open Database Connectivity
OMT
Object Modeling Technique
OOP
Objekt Oriented Programming
PCE
Parametric Change Engine
PBS
Public Buildings Service
PGE
Pacic Gas and Electric
PIER
Public Interest Energy Research
RDB
Revit Database
SIMIEN
SIMulering av Inneklima og ENergibruk i bygninger
SIMULA
SIMulation LAnguage
SQL
Structured Query Language
STEP
STandard for the Exchange of Product model data
UML
Unied Modeling Language
VE
Virtual Environment
WWW
World Wide Web
X3D
Extensible 3D Graphics
XML
Extensible Markup Language
VIII
Figurer
2.1
Utvikling innen BIM [Howard and Bjørk, 2008] . . . . . . . . . .
8
2.2
Objektmodell av OMT [Syvertsen, 2009] . . . . . . . . . . . . . .
9
2.3
Utviklingen av Computer Aided Design (CAD) [Graphisoft, 2009]
11
2.4
Informasjonsyt i BIM . . . . . . . . . . . . . . . . . . . . . . . .
13
3.1
Kommunikasjon via loverføring
. . . . . . . . . . . . . . . . . .
16
3.2
Kommunikasjonsmåte med én leverandør . . . . . . . . . . . . . .
18
3.3
Kommunikasjon via mellomvare . . . . . . . . . . . . . . . . . . .
19
3.4
Kommunikasjon via åpne datamodellformater . . . . . . . . . . .
20
3.5
IFC sin systemarkitektur [Model Support Group (MSG), 2010]. .
24
3.6
Dataoverføring via International Organization for Standardization
(ISO)-STandard for the Exchange of Product model data (STEP)
Part-21
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.7
Avvik ved overføring mellom applikasjoner [Kalstveit, 1997]. . . .
28
3.8
Sammenligning av IFC-modellen [buildingSMART, 2010b] og gbXMLskjemaet [gbXML, 2010] . . . . . . . . . . . . . . . . . . . . . . .
31
4.1
Verktøylinjen til Autodesk Revit
34
4.2
Autodesk Revit sitt Graphical User Interface (GUI)
4.3
Inndeling av informasjon i Autodesk Revit [Autodesk, 2009b]
4.4
Eksportering til gbXML-formatet i Revit
4.5
Informasjonsorganisering i gbXML [Autodesk, 2009b].
4.6
Autodesk Ecotect sitt GUI
. . . . . . . . . . . . . . . . . .
. . . . . . .
35
. .
36
. . . . . . . . . . . . .
38
. . . . . .
39
. . . . . . . . . . . . . . . . . . . . .
40
4.7
Import av IFC i Ecotect . . . . . . . . . . . . . . . . . . . . . . .
42
4.8
IES VE sitt GUI [IES VE, 2010]
43
4.9
De ulike variantene av IES VE [IES VE, 2010]
. . . . . . . . . . . . . . . . . .
4.10 Importering av gbXML-l i IES VE
IX
. . . . . . . . . .
44
. . . . . . . . . . . . . . . .
46
4.11 Kontroll av rom i modell som skal importeres
4.12 IES VE PlugIn til Autodesk Revit
. . . . . . . . . . .
47
. . . . . . . . . . . . . . . . .
47
5.1
Energy Settings i Revit
. . . . . . . . . . . . . . . . . . . . . .
49
5.2
Endring av modellens orientering i Revit . . . . . . . . . . . . . .
49
5.3
Room Bounding attributt i Revit . . . . . . . . . . . . . . . . . .
50
5.4
Justering av sonehøyde i Autodesk Revit 2011 . . . . . . . . . . .
50
5.5
Romvolum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.6
Menyen IFC Options . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.7
Feilmelding i Revit . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.8
Redigering av faser i Revit . . . . . . . . . . . . . . . . . . . . . .
53
5.9
Modell laget i Revit for Test 1
. . . . . . . . . . . . . . . . . . .
54
5.10 Modell laget i Revit for Test 2
. . . . . . . . . . . . . . . . . . .
54
5.11 Modeller laget i Revit for Test 3
. . . . . . . . . . . . . . . . . .
55
5.12 Modeller laget i Revit for Test 4
. . . . . . . . . . . . . . . . . .
55
. . . . . . . . . . . . . . . . . . .
56
6.1
Modell fra Test 2 lastet inn i Ecotect Analysis . . . . . . . . . . .
58
6.2
Modell fra Test 2 lastet inn i IES VE . . . . . . . . . . . . . . . .
59
6.3
Modell med mangekantet vegg lastet inn i Ecotect Analysis
. . .
60
6.4
Modeller fra Test 3 lastet inn i IES VE . . . . . . . . . . . . . . .
61
6.5
Modell med gavltak fra Test 4 lastet inn i Ecotect Analysis
. . .
61
6.6
Modeller fra Test 4 lastet inn i IES VE . . . . . . . . . . . . . . .
62
6.7
Modell fra Test 5 lastet inn i Ecotect Analysis . . . . . . . . . . .
63
6.8
Sammendrag av resultatene fra de utførte testene . . . . . . . . .
64
6.9
Bygningskomponentenes hiearkiske inndeling i IES VE . . . . . .
65
8.1
Sammendrag av resultatene fra de utførte testene . . . . . . . . .
73
A.1
Arv av attributter for IFC BEAM
83
5.13 Modell laget i Revit for Test 5
X
. . . . . . . . . . . . . . . . .
B.1
Oppbygning av Exterior Wall i gbXML
. . . . . . . . . . . . . .
C.1
Autodesk Revit 2011 Importevne [Autodesk, 2010a]
. . . . . . .
85
C.2
Autodesk Revit 2011 Eksportevne [Autodesk, 2010a] . . . . . . .
85
C.3
Model/Analysis Data [Autodesk, 2010a]
. . . . . . . . . . . . . .
86
C.4
tredimensjonal (3D) CAD Geometry [Autodesk, 2010a] . . . . . .
87
C.5
Model/Analysis Data [Autodesk, 2010a]
. . . . . . . . . . . . . .
88
C.6
External Analysis Tool [Autodesk, 2010a]
. . . . . . . . . . . . .
88
C.7
Image/Screenshot [Autodesk, 2010a]
. . . . . . . . . . . . . . . .
88
C.8
IES VE Importevne [IES VE, 2010] . . . . . . . . . . . . . . . . .
89
C.9
IES VE Eksportevne [IES VE, 2010]
. . . . . . . . . . . . . . . .
89
D.10 gbXML Element [Autodesk, 2009b] . . . . . . . . . . . . . . . . .
90
D.11 Campus Element [Autodesk, 2009b]
90
. . . . . . . . . . . . . . . .
D.12 DocumentHistory Element [Autodesk, 2009b]
84
. . . . . . . . . . .
91
D.13 Location Element [Autodesk, 2009b]
. . . . . . . . . . . . . . . .
91
D.14 Building Element [Autodesk, 2009b]
. . . . . . . . . . . . . . . .
91
D.15 Space Element [Autodesk, 2009b] . . . . . . . . . . . . . . . . . .
92
D.16 ShellGeometry Element [Autodesk, 2009b] . . . . . . . . . . . . .
92
D.17 SpaceBoundary Element [Autodesk, 2009b]
. . . . . . . . . . . .
93
D.18 Surface Element [Autodesk, 2009b] . . . . . . . . . . . . . . . . .
94
D.19 Opening Element [Autodesk, 2009b]
95
E.20 IFC-avbildingsl
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 103
F.21 Resultater fra Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . 104
G.22 Resultater fra Test 2 . . . . . . . . . . . . . . . . . . . . . . . . . 105
1
1
Innledning
1.1 Generelt
Den norske stat har gjennom Klimameldingen og Klimaforliket forpliktet seg
til å redusere Norges utslipp av klimagasser tilsvarende 30% av Norges utslipp
i 1990 [Kommunal- og regionaldepartementet, 2009], og har blant annet igangsatt tiltak som angår bolig- og byggesektoren. Bolig- og byggesektoren omtales som 40% næringen da næringen står for cirka 40% av det totale energiog ressursforbruket og avfallsproduksjonen i Norge. Potensialet til å redusere energibruken og Norges klimagassutslipp ved innstramminger i byggenæringen er med andre ord vesentlig. Kravene til bygg har blitt skjerpet av staten
gjennom juridiske virkemidler, og energikravene i tekniske forskrifter til planog bygningsloven skal etter planen justeres minst hvert femte år. Ny plan- og
bygningslov med tilhørende forskrifter trer i kraft fra og med 1. juli 2010, og
for å øke fokuset på miljø må nyoppførte bygg etter dette være energimerket
[Kommunal- og regionaldepartementet, 2009]. I tillegg har staten tatt i bruk
økonomiske virkemidler som miljøavgifter og tilskudd gjennom Enova for å påvirke bolig- og byggesektoren til å bygge mer miljøvennlige bygg.
Stadig strengere krav fra staten, muligheter for økonomisk støtte gjennom
incentiver, byggeindustriens eget samfunnsengasjement og en økende etterspørsel fra brukere er alle omstendigheter som underbygger hvorfor det er viktig for
byggeindustrien å bygge miljøvennlige bygg populært kalt grønne bygg.
A sustainable building, or green building is an outcome of a design
philosophy which focuses on increasing the eciency of resource use
energy, water, and materials while reducing building impacts on
2
human health and the environment during the building's lifecycle,
through better siting, design, construction, operation, maintenance,
and removal [Frej and Anne, 2005].
I et byggeprosjekt hvor man har som mål å bygge et grønt bygg er man
avhengig av energi- og miljøanalyser for å nne frem til optimale løsninger og
design [Krygiel and Nies, 2008]. Energi- og klimaanalyser av bygninger baserer seg på informasjon om blant annet bygningsmaterialer, tekniske installasjoner, overater og volumer [Krygiel and Nies, 2008]. Å modellere bygninger med
analyseapplikasjoner krever tid til å denere inndataverdiene, kjøre simulasjonen og å analysere utdata. Man har tidligere vært avhengig av å ta ut mengder manuelt fra 2D-tegninger for å gjøre detaljerte energianalyser av bygninger
[Jongeling, 2008]. Ulempene med dette er mange; i store prosjekter kan man fort
regne feil og få unøyaktige mengder. I tillegg er prosessen tidkrevende og koster
mye, og antall kalkyler og analyser blir derfor holdt på et minimum. Det er ikke
uvanlig at erfaringstall fra lignende bygninger har blitt brukt for å analysere
bygget, noe som også bidrar til at analysene blir unøyaktige [Jongeling, 2008].
Implementeringen av ny teknologi i byggebransjen har gitt muligheten til å forenkle denne prosessen.
1.2 BIM og miljøvurdering
BIM-teknologi er i ferd med å få et stadig sterkere fotfeste innenfor Architecture, Engineering and Construction (AEC)-industrien. BIM tar utgangspunkt i et
prosjektsamarbeid hvor alle aktører tilfører informasjon til en digital bygningsmodell. Denne informasjonen kan blant annet være geometrisk data, byggets
lokasjon og orientering, bygningsmaterialer og -komponenter, tekniske installasjoner og fremdriftsplaner. Modellen utvikles i prosjekteringsfasen, brukes til
å følge opp arbeidet i gjennomføringsfasen og kan videre benyttes i hele byggets levetid for forvaltning, drift og vedlikehold, eventuelle ombygginger og ved
riving.
Det har blitt erfart at 50% av tiden det tar for å modellere og analysere en
energimodell går med til å gjenskape bygningsgeometrien i en analyseapplikasjon
[Krygiel and Nies, 2008]. Det å benytte BIM i et byggeprosjekt gir analyseapplikasjoner mulighet til å hente relevant informasjon direkte ut fra modellen, noe
som gjør prosessen raskere og mer nøyaktig. Ofte fører dette til at man utfører
ere analyser, og man kan bruke energimodeller som en integrert del av designprosessen [Yudelson, 2008]. Særlig i tidligfase vil det være fordelaktig å utføre
3
ere energianalyser, da det her er størst muligheter for å påvirke utformingen
av designet [Yudelson, 2008]. Analysene gir et bedre grunnlag for å foreta valg,
og ved å bruke dette aktivt i designprosessen kan man få gode miljøløsninger.
Prosessen med å dokumentere byggets egenskaper i forhold til krav for en miljøsertisering blir også enklere [Jongeling, 2008]. Dette kan i tiden som kommer
være med på å heve miljø som konkurransefaktor.
Et byggeprosjekt består av en rekke ulike aktører, som ikke nødvendigvis
bruker samme type programvare. Det at en analyseapplikasjon skal kunne hente
ut informasjon fra en BIM avhenger av at applikasjonene som skal kommunisere
er interoperabile. Etter hvert som mer og mer BIM-programvare har blitt utviklet, har behovet for en standardisert måte applikasjonene kan kommunisere
på kommet tydelig frem.
1.3 Oppgavens formål og omfang
Formålet med denne masteroppgaven er å vurdere interoperabiliteten mellom
modelleringsapplikasjoner og analyseapplikasjoner i dag, og hvilke muligheter
man har til å forbedre interoperabiliteten i tiden som kommer. Problemstillingen til masteroppgaven har blitt utarbeidet i samarbeid med COWI, avdeling
Trondheim. COWI har tatt i bruk BIM på en rekke byggeprosjekter og ønsket å teste interoperabiliteten mellom modelleringsapplikasjonen Autodesk Revit og analyseapplikasjonene Ecotect Analysis og IES VE. Versjonene som ble
brukt under testene er Autodesk Revit 2011, Ecotect Analysis 2011 og IES VE
6.0.6. Overføringsformatene IFC 2x3 og gbXML 0.37 ble brukt for å overføre
informasjon fra Revit til henholdsvis Ecotect og IES VE. Det ble valgt å teste
overføringen av den informasjonen som er mest relevant for å utføre analyser:
Lokasjon, orientering, bygningstype, geometri til romavgrensende ater, navn
til rom, romvolum, bygningsmaterialer og objekttypene tak, gulv, etasjeskiller,
yttervegg, innervegg, dør, søyle og vindu. Det ble kun benyttet standard objekter i Revit under testingen. Informasjonsoverføringen er kun testet fra Revit til
analyseapplikasjonene, da ingen av analyseapplikasjonene kan eksportere informasjon til et format som kan lastes inn i Revit.
4
1.4 Metodikk
Fagstudie
Gjennom faget TKT4505 Objektmodellering har grunnleggende forståelse av
teori rundt objektmodellering blitt tilegnet.
Litteraturstudium
For å få en grunnleggende forståelse av BIM og interoperabilitet har et litteraturstudium blitt benyttet. I all hovedsakelighet har relevant litteratur blitt
funnet via søkemotorene BIBSYS og
www.google.com.
BIBSYS ble benyttet for
å nne bøker innenfor temaene BIM og miljøvurdering. Google sin søkemotor
ble benyttet for å nne relevant informasjon om ulike kommunikasjonsmodeller,
kommunikasjonsformatene IFC og gbXML og applikasjonene Autodesk Revit,
Ecotect Analysis og IES VE.
Testing av applikasjoner
For å vurdere interoperabiliteten mellom applikasjonene ble modeller laget i
Revit konvertert til kommunikasjonsformatene IFC og gbXML, for deretter å
bli importert i henholdsvis Ecotect og IES VE. Deretter kunne informasjonen i
disse modellene sammenlignes med informasjonen i den originale modellen, for
å vurdere hvilken informasjon som ble overført og hvilken som falt bort under
prosessen. I utgangspunktet skulle COWI sin modell av Ny Barneavdeling for
Ålesund Sykehus være referansemodell, men dette ble valgt bort. Isteden ble
det laget en rekke enkle modeller i Revit. Dette ble gjort for å ha bedre kontroll
på hva slags informasjon som var i hver modell, noe som gjorde prosessen med
å kontrollere hva slags informasjon som ble overført til analyseapplikasjonene
enklere. I tillegg var det behov for å lage egne modeller for å kunne teste interoperabiliteten mellom applikasjonene ved spesialtilfeller, som for eksempel
modeller som inneholdt tak og vegger med særegen geometri.
1.5 Disposisjon
Masteroppgavens videre oppbygning er strukturert på følgende måte:
5
Kapittel 2
Kapittel 2 gir en kort innføring i BIM. Dette omfatter en beskrivelse
av objektmodellering, en presentasjon av BIM sin utvikling, en vurdering
av hva BIM faktisk er og til slutt en denisjon av BIM presentert.
Kapittel 3
Kapittel 3 beskriver ulike kommunikasjonsmåter, og presenterer
utfordringer og muligheter ved å bruke disse i byggenæringen. I tillegg
blir IFC-modellen og gbXML-formatet nærmere omtalt.
Kapittel 4
I Kapittel 4 blir applikasjonene Autodesk Revit, Ecotect Analysis
og IES VE presentert. Presentasjonen gir en innføring i hvilke funksjoner
applikasjonene har, hvordan de fungerer i bruk og hvordan import- og
eksport av modeller utføres.
Kapittel 5
Kapittel 5 omhandler selve testingen av applikasjonene. Først i ka-
pittelet beskrives de grepene som ble gjort i Autodesk Revit for å legge
til rette for eksporteringen av modellene. Videre presenteres COWI sitt
byggeprosjekt Ny Barneavdeling ved Ålesund Sykehus", og hvorfor dette ble valgt bort som referansemodell. Til slutt beskrives testene som ble
gjennomført.
Kapittel 6
I Kapittel 6 blir resultatene fra testene presentert og oppsummert.
Kapittel 7
Kapittel 7 omfatter anbefalingene til COWI.
Kapittel 8
Kapittel 8 gir en konklusjon til oppgaven og en presentasjon av
forslag til videre arbeid.
6
2
Building Information
Model/Modelling (BIM)
2.1 Generelt
Dette kapittelet gir en kort innføring i Building Information Model/Modelling
(BIM); det innbefatter en presentasjon av BIM sin utvikling og struktur og en
denisjon av hva BIM er.
2.2 Objektmodellering
Historie
Ole Johan Dahl og Kristen Nygaard utviklet på 1960-tallet programmeringsspråket SIMulation LAnguage (SIMULA). Språket skulle være intuitivt og anvendelig, og skulle gi datamaskiner nok informasjon til å generere tilhørende
simuleringsprogrammer for selv svært komplekse systemer. Med SIMULA ble
grunnlaget lagt for objektorientert programmering slik vi kjenner det i dag
[Haraldsen, 1999].
Den kommersielle utviklingen av objektmodellering i hjelpemidler for byggenæringen ble først utviklet på 1980-tallet. Graphisoft ArchiCAD ble introdusert
i 1984 som et av de første programmene i næringen basert på objektorientert modellering [Graphisoft, 2010]. Denne type programvare slo likevel ikke igjennom
før senere, siden programvaren var svært ressurskrevende for datidens datama-
7
skiner. Isteden var det mindre ressurskrevende, entitetsbasert programvare som
for eksempel Autodesk AutoCAD og Bentley MicroStation som ble foretrukket i bransjen. Forskjellen mellom entitetmodellering og objektmodellering er at
en entitet kun inneholder data, mens et objekt i tillegg inneholder operasjoner
[Hansen, 2006].
Etter hvert som utviklingen innen Informasjonsteknologi (IT) ga billigere og
bedre maskinvare kom objektbasert programvare på banen igjen, og utviklingen
skjøt fart på 1990-tallet [Eastman, 1999]. Etter årtusenskiftet tilbød ere og ere
leverandører objektbasert programvare; Revit Technology Corporationsenere
kjøpt opp av Autodesklanserte Revit i 2000, Bentley Building Information
Modelling ble lansert i 2002 og GraphiSoft lanserte ArchiCAD 9 i 2004 (se
Figur 2.1).
Figur 2.1: Utvikling innen BIM [Howard and Bjørk, 2008]
Konsept
Programmeringsspråket SIMULA introduserte komponentbegrepet prosess senere kalt objekt som inneholdt både data og operasjoner. Ved hjelp av taksonomi kunne objekter med lik struktur på data og operasjoner bli delt inn i klasser.
Gjennom arv via klassehierarki kunne komponentbegreper for første gang bli
generalisert og spesialisert [Haraldsen, 1999].
I dag omtales denne type dataprogrammering som klasseorientert Objekt
Oriented Programming (OOP). Modellering forut for programmering har blitt
standardisert via modelleringsspråket Object Modeling Technique (OMT) (se
8
Figur 2.2) og senere Unied Modeling Language (UML). OMT består av de tre
aspektmodellene objektmodell, dynamisk modell og funksjonsmodell
[Syvertsen, 2009].
OMT
Dynamisk
modell
Objektmodell
Assosiasjon
Klasse
Tilstand
Funksjonsmodell
Hendelse
Transformasjon
Flyt
Figur 2.2: Objektmodell av OMT [Syvertsen, 2009]
En klasseorientert objektmodell deneres av følgende aspekter
[Abdalla and Powell, 1995]:
Entitet
En entitet er en fysisk eller konseptuell ting, representert gjennom en
samling dataverdier. Entiteter representeres av objekter.
Objekt
Objekter er entiteter som kombinerer attributter; dataverdier som be-
skriver objektets tilstand, operasjoner; prosedyrer og metoder som beskriver objektets oppførsel og identitet; gir objektet en unik eksistens blant alle
andre objekter. Objekter kommuniserer ved å sende meldinger til hverandre. Ethvert objekt i en klasseorientert objektmodell må tilhøre en klasse,
og betraktes som en forekomst av den klassen.
Klasse
En klasse beskriver et sett objekter med like egenskaper, føringer og
operasjoner. Hver klasse denerer et sett attributter, som beskriver egenskaper og tilstander til forekomster i klassen. Klasser er inndelt i et klassehierarki av superklasser og underklasser. En underklasse kan arve attributter og operasjoner fra en superklasse.
Anvendelse
Ved bruk i byggenæringen består objektbaserte modeller av parametriske objekter som vegger, vinduer og dører. Disse objektene er knyttet til en database hvor
man kan hente ut plantegninger, detaljskisser, seksjoner og så videre. Vegger og
dører kan bli endret i relasjon til hverandre og fungerer sammen som funksjonelle enheter. Detaljer kan linkes til sin posisjon i modellen og endringer gjort i en
9
komponent blir oppdatert i alle tegninger [Seletsky, 2004]. Denne parametriske fremstillingen gjør modellen interaktiv og selvanalytisk, noe som er positivt
for designprosessen [Chris I. Yessios, 2004]. Programvare brukt i byggenæringen
som er basert på objektbaserte modeller går inn under fellesbetegnelsen BIM.
2.3 Hva er BIM
Oppfatningen av hva BIM er varierer blant aktører i byggenæringen. Noen ser
på BIM som et rent 3D-visualiseringsverktøy, andre som et CAD-verktøy, og
relativt få som en prosess der informasjon bearbeides på en objektorientert
måte. Dette kan skape misforståelser og feilaktige forventninger og krav, som
videre fører til skuelse eller konikter [Jongeling, 2008]. I realiteten kan BIM
ha minst to forskjellige betydninger, avhengig av hvilket perspektiv man har.
Prosessperspektiv
Konseptet BIM har eksistert i en eller annen form så langt tilbake som på 70tallet. Professor Charles Eastman ved Georgia Institute of Technology var en
av de første som konkretiserte begrepet, da under navnet Building Product
Model [Conradie, 2009]. I denne sammenhengen var BIM en prosess, mer enn
en anvendelse av ny IT.
Byggeindustrien har tatt i bruk en rekke generelle teknologiske hjelpemidler
etterhvert som den har blitt utviklet; det er eksempelvis nå blitt vanlig med
digitalisering og elektronisk distribusjon av dokumenter, det eksisterer digitale
verktøy for tid- og kostnadsplanlegging og grask visualisering av byggeprosjekter. BIM skiller seg ut i denne rekken ved å være en ny tilnærming til hvordan
man designer og prosjekterer bygninger på, mer enn en implementering av ny
IT [Autodesk, 2007].
BIM er med andre ord en ny måte å organisere og strukturere informasjon
i byggeprosjekter på; prosessen går ut på å samle all geometrisk informasjon
og funksjonelle krav, og å sette sammen informasjonen for å lage en innbyrdes sammenhengende beskrivelse av byggeprosjektet gjennom hele dets livsløp
[Eastman, 1999]. Hensikten med denne omstruktureringen er å legge til rette
for bedre samarbeid mellom mennesker. Å samle all informasjon om et bygg i
en modellserver gir muligheter for et tettere samarbeid mellom aktørene i prosjektet, og resultatet kan bli at man kommer frem til den beste løsning ved å
ta hensyn til alle fagene. En slik modell er også mer eektiv enn den klassiske
10
måten å arbeide på, da man kan dra nytte av den informasjonen som allerede er
lagt inn i modellen, og at ere mennesker kan arbeide med modellen samtidig.
Nøkkelen for å løse vanskelige og komplekse utfordringer ligger ikke i IT alene,
men i å legge til rette for bedre menneskelig samarbeid ved hjelp av datamaskiner [Engelbart, 2003].
Teknisk perspektiv
Selve fagordet BIM ble først tatt i bruk av Phil Bernstein, visepresident i Autodesk, for å beskrive en type programvare innen byggenæringen. Ordet ble etter
hvert en akseptert neologisme i byggebransjen, og utkonkurrerte andre forslag
som single building model, virtual building model, integrated project modeling og project lifecycle management [Laiserin, 2002]. For å få en forståelse
Figur 2.3: Utviklingen av CAD [Graphisoft, 2009]
av hva BIM-programvare er, kan det være hensiktsmessig å se på utviklingen
som har foregått innen CAD (se Figur 2.3). Det hele begynte med bruk av digitale tegnebrett til å lage modeller, fremfor å gjøre dette med håndtegninger.
Ved å digitalisere tegningene kunne man raskere gjøre endringer på modellene,
man kk bedre nøyaktighet og arbeidsprosessen gikk raskere ved at man kunne
kopiere lik geometri. Etter hvert ble det også utviklet CAD-programmer som
kunne fremstille 3D-modeller. I første omgang ble dette kun benyttet for å kunne lage en visuell fremstilling av bygg digitalt, slik at man slapp arbeidet med
å lage fysiske modeller. Ved å integrere mer informasjon enn bare geometriske
verdier i modellene har man gått over fra å bruke modellene kun for plantegnin-
11
ger og visualisering til å ta modellen i bruk på en rekke andre områder. Denne
modellen, som består av objekter som beskriver komponentene og funksjonene
til et bygg, betegnes som BIM.
BIM omtales også som en virtuell bygning, eller en bygningssimulering. BIM
er informasjon om hele bygget og et komplett sett med designdokumenter, lagret i en integrert database [Krygiel and Nies, 2008]. All informasjon kan være
parametrisk og sammenkoplet. Dette betyr at en endring i et objekt i modellen
automatisk forplanter seg i hele modellen.
Ved å legge til dimensjonene tid og kostnad får man en femdimensjonal
modell. Mengder, plantegninger, kostnadsanalyser og tidsplaner kan hentes direkte ut av modellen, og man kan bruke modellen til å dimensjonere bæresystemer, utføre miljøberegninger og å sjekke at elementer i bygget ikke kolliderer med hverandre. Denne bygningsinformasjonsmodellen kan alle partene i et
byggeprosjekt samarbeide om å bruke. Ved hjelp av diverse programvare koblet sammen via interoperabilitet, kan aktørene bruke ulik programvare, relevant
for sitt fagfelt [Graphisoft, 2009]. Mange CAD-verktøy slik som Revit, ArchiCAD, DDS, AutoCAD ADT, Bentley og Tekla tilbyr i dag BIM-funksjonalitet
[Norconsult, 2010].
Denisjon
Det eksisterer per dags dato ingen entydig og presis denisjon for hva BIM er
[Architosh, 2010]. Dette har ført til at BIM lett blandes sammen med teknologi
som parametrisk modellering og interoperabilitetsinitiativer, og det skaper forvirring. Uten en entydig og presis denisjon kan man ikke identisere grensene
og dermed manglene til BIM, og målrettet jobbe for å forbedre disse manglene.
I tillegg er det utfordrende for bedrifter som ønsker å ta i bruk BIM å vite hva
dette i sin fulle forstand innebærer.
For denne oppgavens formål har følgende denisjon av General Services
Administration (GSA) Public Buildings Service (PBS) Oce of the Chief Architect
(OCA) blitt valgt for BIM:
Building Information Modeling is the development and use of a
multi-faceted computer software data model to not only document
a building design, but to simulate the construction and operation of
a new capital facility or a recapitalized (modernized) facility. The
resulting Building Information Model is a data-rich, object-based,
intelligent and parametric digital representation of the facility, from
12
which views appropriate to various users' needs can be extracted
and analyzed to generate feedback and improvement of the facility
design. [GSA PBS OCA, 2007]
2.4 Oppsummering
Fordeler med å benytte BIM i byggeprosjekter som ofte trekkes frem er muligheten til å visualisere bygget og utføre kollisjonskontroller for å minimere antall
feil i prosjekteringen. Det at BIM kan benyttes til å visualisere et bygg for lettere å kunne oppdage feil er vel og bra, men det er ikke en dekkende beskrivelse
av BIM sitt potensiale. Den viktigste funksjonen til BIM er å legge til rette
for bedre menneskelig samarbeid i byggebransjen. Dette er en nøkkelfaktor for
å oppnå bedre indre og ytre eektivitet, som vil gi høyere verdiskapning for
aktørene og kundene i prosjektet [Eikeland, 2000].
Med BIM kan man oppnå bedre eektivitet ved at aktører kan jobbe parallelt
og at informasjon lagt inn av én aktør kan benyttes av alle andre aktører i det
videre arbeidet. Man kan oppnå et bedre resultat på grunn av at man lettere kan
vurdere ulike alternativer og iterere seg frem til et design med ønsket funksjonalitet og kvalitet. Feil kan unngås, slik at endringer og forsinkelser i byggefasen
blir redusert. De utførende får en lettere jobb da plantegninger og skisser er mer
nøyaktige og detaljerte. Listen er lang, men disse positive eektene er ikke et
direkte resultat av at man benytter BIM-applikasjoner i byggeprosjektet. Det er
derimot et resultat av at aktørene i byggeprosjektet samarbeider bedre. For å få
Building Owner
Developer
Contractor
Quantity Surveyor/
Cost Planner
Facility Manager
Users
Product
Manufacturers
BIM MODEL
Information
Providers
Architect/
Interior Designers
Government
Agencies
Engineer
Building Certifier
Figur 2.4: Informasjonsyt i BIM
til et godt samarbeid er man avhengig av god kommunikasjon [Eikeland, 2000].
13
Med hensyn til BIM fordrer god kommunikasjon at alle aktørene arbeider opp
mot en felles modell (se Figur 2.4). Dette kan gi en pålitelig informasjonsutveksling, og sikre at alle arbeider med gjeldende modell [Eastman et al., 2008].
Gjennomføringen av dette avhenger av at alle applikasjonene som brukes av de
ulike aktørene klarer å kommunisere seg i mellom, via en modellserver. Ulike
kommunikasjonsmåter og overføringsmåter omtales nærmere i Kapittel 3.
14
3
Interoperabilitet
3.1 Generelt
Opp gjennom tiden har mangfoldet av ulike typer bygg og teknologien som
inngår i disse byggene bare økt. Som en naturlig reaksjon på dette har byggeindustrien blitt mer fragmentert og delt seg inn i aktører med ulik spisskompetanse
[Krygiel and Nies, 2008]. I et byggeprosjekt vil disse aktørene nødvendigvis ha
ulike behov, noe som har ført til utviklingen av en rekke ulike applikasjoner. Når
man skal jobbe sammen om en modell i et byggeprosjekt, må disse programmene kunne kommunisere. Etter hvert som ere og ere BIM-applikasjoner blir
utviklet har behovet for en standardisert måte disse applikasjonene kan snakke
sammen på kommet tydelig frem. Det eksisterer mange alternative måter å overføre informasjon mellom ulike applikasjoner på. Dette kapittelet beskriver ulike
kommunikasjonsmåter og presenterer utfordringer og muligheter ved å bruke
disse i byggenæringen. I tillegg blir IFC-modellen og gbXML-formatet nærmere
omtalt.
3.2 Overføringsformater
Overføring av informasjon mellom ulike applikasjoner kan deles inn i re grupper
[Eastman et al., 2008]:
Proprietære koblinger
Proprietære koblinger utviklet og vedlikeholdt av pro-
gramleverandører for at to applikasjoner skal kunne kommunisere seg imellom.
15
Proprietære lformater
Proprietære lformater utviklet av programleveran-
dører for bruk til sine programmer. Innenfor byggeindustrien er Data
eXchange Format (DXF), utviklet av Autodesk, et utbredt proprietært
lformat.
Åpne datamodellformater
Åpne overføringsformater basert på standardi-
serte bygningsmodeller som overfører geometri, materialegenskaper, objektegenskaper, funksjoner og koblinger. Cimsteel Integration Standard
version 2 (CIS/2) standard for produksjon og ingeniørarbeid innenfor
konstruksjonsstål og IFC standard for bygningsplanlegging, design og
konstruksjon er eksempler på åpne datamodellformater.
Extensible Markup Language (XML)-baserte formater
XML er et sett
med regler for hvordan man skal kode digitale dokumenter. XML-skjemaer
brukes for overføring av data mellom applikasjoner. Eksempler på XMLbaserte formater innenfor byggeindustrien er aecXML og gbXML.
3.3 Kommunikasjon via loverføring
Med denne metoden å kommunisere på lagrer senderen modellen i en l, som
så sendes ved hjelp av elektronisk distribusjon til en mottager. Hvis de to applikasjonene ikke benytter samme lformat må informasjonen eksporteres av
avsender og importeres av mottager (se Figur 3.1). IFC og gbXML er eksempler
på formater som kan brukes under denne prosessen. Avhengig av hvilket format som brukes og om applikasjonene støtter det, kan kommunikasjonen foregå
begge veier. Denne typen kommunikasjon ble benyttet under testingen av applikasjonene Autodesk Revit, Autodesk Ecotect og IES VE, som er beskrevet
senere i oppgaven (se Kapittel 5). Utfordringer med denne kommunikasjonsmåten beskrives nærmere i Avsnitt 3.5 og 3.6.
EKSPORT
IMPORT
Modelleringsapplikasjon
Analyseapplikasjon
Figur 3.1: Kommunikasjon via loverføring
16
3.4 Kommunikasjon via database-server
Generell beskrivelse av en database-server
En database-server lagrer som navnet tilsier data internt i en database og distribuerer informasjon til klientapplikasjoner via kontrollerte grensesnitt. Revit
har for eksempel utviklet et eget verktøy ved navnet Revit Database (RDB)Link for å overføre data til og fra en database. RDB-Link støtter relasjonsdatabaser, som for eksempel MS Access og Structured Query Language (SQL)servere [Autodesk, 2010a]. Det er også utviklet generelle databasedrivere som
applikasjoner kan benytte for å kommunisere med databaser; ved hjelp av Java
Database Connectivity (JDBC) kan Java-baserte programmer hente og sende informasjon fra en rekke ulike typer databaser [Oracle Corporation, 2010]. Open
Database Connectivity (ODBC) et Application programming interface (API)
som streber etter å bli uavhengig av programmeringsspråk, operativsystemer og
databasesystemer [Idehen, 1993] åpner opp for at ulike applikasjoner skal kunne snakke sammen via en felles database. Databasen kan være relasjonsbasert
som for eksempel en SQL-database eller objektbasert. Sistnevnte er lite brukt,
men kan være aktuell å bruke da de har stor lagringskapasitet og overføringskapasitet; det eksisterer objektdatabaser som inneholder 1000 Terrabytes og som
har en overføringshastighet på 1 Terrabyte i timen [Becla and Wang, 2005].
Ulike scenarioer for kommunikasjon via en BIM-server
Her presenteres ulike scenarioer for hvordan kommunikasjon via en BIM-server
kan foregå.
Bruk av applikasjoner fra én leverandør
I dette scenarioet har én programvareleverandør oppnådd monopol på markedet
og tilbyr alle nødvendige applikasjoner som er nødvendig i et byggeprosjekt. Applikasjonene har ulike funksjoner ut ifra hvilket fagfelt de er beregnet for, men
denerer og strukturerer informasjon på samme måte og er basert på samme
forretninger, begreper, basisoperasjoner og dataaksessmetoder (se Figur 3.2).
Dermed vil all informasjon i en BIM være forståelig for alle applikasjonene, og
de kan kommunisere seg i mellom uten informasjonstap. Alle prosjektdeltagerne
henter ut informasjon fra en server med en database for eksempel en relasjonsdatabase, eller en objektdatabase hvor BIM er lagret, ved hjelp av proprietære
17
koblinger. Her vil interoperabiliteten være god, men dette scenarioet vil likevel
ikke være gunstig for forbrukeren; siden programleverandøren har monopol vil lisensprisene være høye, og uten konkurranse er drivkraften for å produsere bedre
og mer brukervennlige applikasjoner falt bort. Monopolloven sørger for at et slikt
scenario blir forhindret, noe blant annet Microsoft har erfart [Svendsen, 2007].
Applikasjon A
Applikasjon B
Applikasjon N
Database
Figur 3.2: Kommunikasjonsmåte med én leverandør
Mellomvare
Mellomvare er programvare som kjører på delt eller dedikert maskinvare. Ved
hjelp av PlugIn-programvare kobler mellomvare ulike applikasjoner sammen slik
at de kan hente ut informasjon fra hverandres databaseservere [Krakowiak, 2003]
(se Figur 3.3). PlugIn-programvaren består av et forretningslag som inneholder forretningsbegreper og basisoperasjoner samlet under begrepet forretningslogikk og et dataaksesslag som inneholder dataaksessmetoder. Disse lagene er
hentet ut fra de ulike applikasjonene.
Et eksempel på et slikt konsept er OpenSpirit, som ble utviklet slik at ulike applikasjoner brukt i oljebransjen skulle kunne kommunisere seg i mellom
[OpenSpirit, 2010]. Utviklingen av OpenSpirit ble støttet av Schlumberger, Shell
og Chevron ved hjelp av nansiering og av at bedriftene delvis åpnet opp sine
forretningslag og dataaksesslag til OpenSpirit. OpenSpirit kunne dermed utvikle sin programvare for å koble applikasjonene fra de ulike leverandører sammen
[Simensen, 2010].
Ved å bruke mellomvare unngår man synkroniseringseekter og man åpner
opp for at applikasjoner med nye funksjoner og bedre brukervennlighet kan
18
utvikles og bli koblet til databasene.
Applikasjon A
Applikasjon B
Applikasjon N
Middleware
Database A
Database B
Database N
Figur 3.3: Kommunikasjon via mellomvare
Kommunikasjon via åpne datamodellformater
Med denne metoden henter og sender applikasjonene informasjon til og fra databasen ved hjelp av et åpent datamodellformat. Før informasjon kan sendes må
applikasjonen sitt eget format eksporteres til det åpne datamodellformatet, og
informasjonen som blir hentet fra databasen må importeres fra det åpne datamodellformatet til applikasjonens eget format (se Figur 3.4). Et eksempel på et
slikt format er IFC, som omtales nærmere i Avsnitt 3.5. Her beskrives også en
rekke utfordringer med et slikt system.
19
IMPORT
EKSPORT
Applikasjon B
Applikasjon A
EKSPORT
EKSPORT
IMPORT
IMPORT
Database
Applikasjon N
Figur 3.4: Kommunikasjon via åpne datamodellformater
Interoperabilitet utviklet av programvareleverandørene
I dette scenarioet har en gruppe programleverandører delt kildekodene med
hverandre og samarbeidet for å utvikle felles overføringsformater, felles denisjoner på informasjon og felles protokoller slik at deres applikasjoner skal kunne
kommunisere seg i mellom. Applikasjonene innehar samme grunnprinsipper for
hvordan de denerer informasjonen, vet hvordan de kan hente ut og putte inn
informasjon i den eksterne databasen og tolker informasjonen på lik måte. Det
er dog ikke gitt at dette samarbeidet inkluderer alle leverandører, og utenforstående vil ikke ha tilgang til hverken kildekodene eller den utviklede interoperabilitetsteknologien.
En stor forskjell fra dette scenarioet og de overnevnte er at programleverandørene har samarbeidet direkte og åpent. Dette gir et mye bedre utgangspunkt
for faktisk å oppnå interoperabilitet. Viljen til å etablere et slikt samarbeid er
dog ikke alltid tilstede, da dette innebærer at programvareleverandørene risikerer å miste noe av sitt konkurransefortrinn. Programleverandørene vil miste
eventuelle synkroniseringseekter, og det blir enda viktigere å fokusere på brukervennlighet og funksjonalitet for å tiltrekke forbrukere.
Fri Programvare
Dette scenarioet er i store trekk likt med interoperabilitet utviklet av programvareleverandørene. Den klare forskjellen er at kildekodene til applikasjonene er
tilgjengelig for allmennheten, og ikke bare for utvalgte samarbeidspartnere. Med
andre ord kan alle programvareleverandører som ønsker det tilpasse sine appli-
20
kasjoner slik at de blir interoperabile med den frie programvaren.
Fordelen med kommunikasjon via en database-server
BIM-applikasjoner bruker vanligvis digitale ler for å laste inn og lagre BIMdata. Det er ikke uvanlig at bedrifter lagrer disse lene på en server, slik at
informasjonen kan være tilgjengelig på forskjellige steder og for ere brukere.
Når det i dette avsnittet snakkes om kommunikasjon via en server er det dog
ikke denne type kommunikasjon det er snakk om, men derimot kommunikasjon
via en server hvor informasjon lagres i en database.
Å lagre informasjonen i en database-server har en rekke tekniske og praktiske fordeler. Alle applikasjonene henter og sender informasjon fra den samme
digitale modellen, noe som legger til rette for samprosjektering og sikrer at alle
brukerne arbeider på gjeldende modell [Eastman et al., 2008]. En annen fordel
med database-servere er at de kan være koblet opp mot andre eksterne datakilder. Hvis for eksempel en leverandør endrer prisen på bygningsmaterialer kan
kostnaden til bygget automatisk bli oppdatert hvis serveren er koblet opp mot
leverandørens server.
Kommunikasjon via en database-server reduserer også utfordringene tilknyttet interoperabilitet. Kommunikasjonen mellom applikasjonene og serveren består av enkle transaksjoner for å hente ut og putte inn informasjon. Applikasjoner sender spørringer til serveren for å få den informasjonen som er relevant,
og trenger ikke å kunne tolke all informasjon i den digitale modellen. På grunn
av dette er prosessen med å gjøre applikasjonene interoperabile med serveren
langt enklere enn å gjøre applikasjonene direkte interoperabile med hverandre.
Hvis to frittstående applikasjoner som kommuniserer via lformater skal være
interoperabile må de kunne importere all informasjonen i datalen, og i tillegg kunne eksportere all informasjon. Selv for enkle tekstdokumenter har dette
vært en vanskelig oppgave å løse [Shah and Kesan, 2008], og oppgaven er desto
vanskeligere for BIM.
3.5 IFC
Innledning
I tilknytning til denne oppgaven ble IFC-modellen brukt for å overføre informasjon fra Revit Architecture til Ecotect Analysis. Dette avsnittet ser nærmere på
21
denne modellen.
Bakgrunn
11. juli 1984 ble det første møtet til ISO TC 184/SC4 en tekniske komité for
standardisering av industriell data underlagt ISO[ISO, 2010] avholdt. Formålet
med møtet var å etablere en internasjonal standard for et nøytralt format ulike
industrier kunne bruke for å lagre informasjon fra en databehandlet produktmodell tapsfritt. Resultatet av denne prosessen ble ISO 10303, bedre kjent som
STEP [Kemmerer, 1999].
STEP er et sett med standarder som integrerer både IT- og produksjonsindustrien sine behov innen dataoverføring [Kemmerer, 1999]. Tidlige forsøk
på standarder for byggenæringen var General AEC Reference Model (GARM)
(ISO TC 184/SC4/WG1 doc. 3.2.2.1) og AEC Building System Model (ISO
TC184/SC4/WG1 Doc. N363).
Etter hvert tok International Alliance for Interoperability (IAI) over STEP
sitt arbeid med utviklingen av interoperabilitetsstandarder for byggenæringen
[Howard and Bjørk, 2008]. IAI er en internasjonal organisasjon, etablert i Asia,
Australia, Europa og Nord-Amerika. Organisasjonen er prottfri og ble stiftet
i 1995. Hovedmålet til organisasjonen har vært å utvikle innovative konsepter
som forbedrer måten man deler informasjon på under et byggeprosjekt. IAI ser
klare fordeler ved bedre interoperabilitetog dermed bedre informasjonsyti
byggeprosjekter. Dette gir prosjektdeltagere muligheten til å dele prosjektinformasjon på tvers av disipliner og tekniske applikasjoner, som igjen gir grobunn
for bedre samarbeid og bedre gjennomførte prosjekter [Haefele, 2008].
Utvikling
For å realisere mulighetene for interoperabilitet har IAI jobbet for å denere,
fremme og publisere spesikasjoner for deling av data. Resultatet av denne prosessen er IFC, en datamodell for deling av data på tvers av ulike applikasjoner
brukt i byggesektoren, samlet under navnet BIM.
IFC supports BIM as a computable representation of the physical
and functional characteristics of a facility and its related project/lifecycle information using open industry standards to inform business
decision making for realizing better value [buildingSMART, 2010c].
22
De ansvarlige for utviklingen og vedlikeholdet av IFC er Model Support
Group (MSG) [buildingSMART, 2010a]. Mange av STEP sine utviklere har bidratt i MSG sitt arbeid med utformingen av IFC. IFC-modellen er i likhet
med STEP basert på datamodelleringspråket EXPRESS og bruker mange av
de samme denisjonene.
Den første versjonen av IFC, versjon 1.0, ble utgitt i 1997 [Khemlani, 2004].
Etter dette har det kommet ut en rekke nye versjoner, hvor den siste i rekken er IFC 2x3-TC1 fra 2007. Det er denne versjonen som brukes av Revit
Architecture og Ecotect Analysis. Utviklingen av IFC 2x4 er allerede i gang
[buildingSMART, 2010c].
23
Konsept
IFC-modellen er utformet som et generelt, abstrakt rammeverk; dette er gjort
for at modellen skal kunne brukes av est mulig applikasjoner og behandle all
type bygningsinformasjon. For å oppnå denne generaliteten har MSG benyttet
seg av at datamodelleringsspråket ISO-STEP EXPRESS er basert på entiteter. Dette er passive data med indirekte relasjoner som må leses og tolkes av
applikasjonene. Applikasjoner kan produsere forekomster i en BIM ved å koble
entiteter sammen via indirekte relasjoner [Eastman et al., 2008].
Figur 3.5: IFC sin systemarkitektur [MSG, 2010].
Systemarkitektur-diagrammet (se Figur 3.5) skildrer oppbygningen av IFC,
inndelt i re nivåer; ressursnivå, kjernenivå, interoperabilitetsnivå og domenenivå. Hvert nivå er videre inndelt i ressursskjemaer, som igjen inneholder
EXPRESS elementer som entiteter, enumereringer, typer og funksjoner. Hver
enkelt entitet kan kun referere til andre entiteter på likt, eller lavere nivå enn seg
24
selv. Dette gjør modellen lett å vedlikeholde og utvide, og muliggjør gjenbruk
av entiteter i høyere lag. I tillegg kan modellen lettere implementeres i ulike
fagspesikke applikasjoner, ved at det tydelig fremgår hvilke entiteter som er
relevante for de ulike fagene [Eastman et al., 2008].
Under følger en presentasjon av de re nivåene i IFC-modellen
[Liebich and Wix, 2000]:
Ressursnivå
Ressursnivået består av grunnentitetene til IFC-modellen. Disse
entitetene representerer de fysiske eller konseptuelle, generiske egenskapene til en bygning og dens byggeprosess. Entitetene blir gruppert inn i
ressursskjemaer; for eksempel materialegenskaper, kostnad, geometri og
topologi. Hvis en klasse i domene-, interoperabilitets- eller kjernenivået
trenger å bruke for eksempel en geometrientitet vil den referere til ressursskjema den tilhører. Entitetenes eksistens avhenger av at de blir brukt i
forekomster i høyere lag.
Kjernenivå
Kjernenivået danner grunnstrukturen til IFC-modellen. Nivået er
delt inn i Kernel og Core Extensions. Kernel danner fundamentet til
kjernenivået og denerer hvordan strukturen til skjemaene i IFC-modellen
skal bygges opp. Core Extensions utvider og spesialiserer konseptene denert i Kernel, Product Extension denerer abstrakte bygningskomponenter som rom, bygningstype og bygningselement. Control- og Process
Extension denerer prosess- og kontrollkonsepter som oppgaver, prosedyrer og arbeidsplaner.
Interoperabilitetsnivå
Interoperabilitetsnivået består av ressursskjemaer som
denerer klasser eller skjemaer som brukes innen ere domenemodeller.
Ved hjelp av disse skjemaene kan modeller fra applikasjoner tilhørende
ulike fagretninger kobles sammen i kjernenivået til IFC-modellen. Det
er i ressursskjemaene i dette nivået man nner denisjoner på de vanligste bygningsentitetene; Shared Building Elements-skjemaet består av
entiteter for bjelker, søyler, vinduer, vegger og så videre, Shared Building Services Elements-skjemaet består av entiteter for akustikkegenskaper, veskeytegenskaper, ytkontroll og så videre og Shared Facilities
Elements-skjemaet inneholder entitetsdenisjoner som for eksempel bruker og møbler.
Domenenivå
Domenenivået er det øverste nivået i systemarkitekturen til IFC-
modellen. Dette nivået inneholder entiteter som er spesikke for prosesser
eller applikasjoner, gruppert ut i fra de ulike fagretningene innen byggeindustrien. En viktig funksjon i domenenivået er å sørge for at eksterne
25
egenskapssett (attributter som har ulik betydning i de ulike fagretningene)
blir implementert korrekt.
Systemarkitekturdiagrammet brukes for å systematisere entitetene i IFCmodellen, og er basert på systemarkitekturen til ISO STEP. En forekomst i en
BIM vil forekomme i slutten av en rekke nedarvede entiteter. Forekomsten vil
bestå av attributter og relasjoner nedarvet fra hvert enkelt nivå. En bjelke vil
for eksempel arve fra følgende entiteter:
IfcRoot; IfcObjectDenition; IfcObject; IfcProduct; IfcElement; IfcBuildingElement; IfcBeam;
Se Tillegg A for en nærmere beskrivelse av entitetene som blir arvet.
Overføring mellom applikasjoner
Prosessen med å overføre en BIM fra en applikasjon til en annen via en IFCmodell kan deles inn i re faser (se Figur 3.6) [Eastman et al., 2008]. Først
vil applikasjonen som sender informasjon konvertere informasjon fra sin egen
datastruktur om til ekvivalente IFC-forekomster. Informasjonen blir deretter
omgjort til ren tekst i en prosess standardisert gjennom ISO-STEP Part-21. Den
mottakende applikasjonen tolker så denne informasjonen og konverterer den til
IFC-forekomster den forstår. Forekomstene blir så omgjort til informasjon basert
på sin egen datastruktur.
Applikasjon som
sender
Applikasjon som
mottar
Import
Oversettelse
Eksport
Oversettelse
Datastruktur
P-21
Oversettelse
P-21
Oversettelse
Datastruktur
Figur 3.6: Dataoverføring via ISO-STEP Part-21
26
Utfordringer
Ved overføring via IFC-modellen kreves det re oversettelser (se Figur 3.6).
Sammenlignet med kommunikasjon via en server hvor det kun er behov for
en eller to oversettelser er dette en forholdsvis besværlig prosess. Tap av informasjon ved bruk av IFC-modellen kan oppstå under konvertering fra den
sendende applikasjonens egen datastruktur til IFC-forekomster, og under den
motsatte prosessen hos den mottagende applikasjonen. Dette kan skyldes mangler i applikasjonene eller IFC-modellen; det kan hende applikasjonen ikke evner å
konvertere informasjonen om til riktige IFC-forekomster, eller at IFC-modellen
ikke inneholder entiteter som sammensatt kan representere forekomstene fra
applikasjonen. Slike svakheter kan løses ved å videreutvikle IFC-modellen eller
applikasjonen, men dette er utfordrende.
Det er lite trolig at en utenforstående leverandør av åpne datamodellformater fortløpende vil klare å ivareta kompatibiliteten etterhvert som nye applikasjonsversjoner lanseres. Applikasjoner blir stadig oppdatert, og selv om det
jobbes med å få IFC-modellen til å overføre informasjon tapsfritt vil dette arbeidet alltid ligge ett skritt bak utviklingen av applikasjonene. Endringene i
applikasjonene kan være store fra versjon til versjon, og det er ikke uvanlig at
en ny versjon av en applikasjon ikke er kompatibel med den versjonen den erstattet. For eksempel kan ikke Revit 2009 åpne prosjekter laget i Revit 2010
[Autodesk, 2009a].
Det er også vanskelig for programvareutviklere å tilpasse sine modeller til å
være kompatible med IFC-modellen. STEP-platformen krever et stort bibliotek
av funksjoner for å kunne bli lastet inn i en applikasjon, og mange av disse
bibliotekene er proprietære [Marsh, 2006].
Det at IFC-modellen skal være et nøytralt format og kunne behandle all type
bygningsinformasjon fører også til utfordringer. For å kunne behandle all type
bygningsinformasjon har IFC-modellen en stor generalitet og eksibilitet, noe
som fører til tvetydighet [Marsh, 2006]. IFC-modellen støtter for eksempel ere
ulike måter å beskrive geometri på. En vegg kan deneres ut i fra sin senterlinje
og seksjonsprol, plane polygoner eller Extensible 3D Graphics (X3D)-geometri.
Dette kan føre til problemer med overføring fra en applikasjon til en annen.
Som et eksempel kan vi se på en sirkulær vegg som skal overføres fra applikasjon A til applikasjon B (se Figur 3.7). I A er veggens geometriske grunnate
denert som en sirkel med senterlinje og radius. B denerer ikke sirkler på
samme måte, men bruker Non Uniform Rational Basis Spline (NURBS) for å
beskrive veggen sin geometri. Når så modellen blir sendt tilbake til A, som ikke
27
bruker NURBS, blir geometrien omdenert til et polygon som en tilnærming
[Kalstveit, 1997].
Applikasjon A
Nøytralt
Format
Applikasjon B
SIRKEL
NURBS
POLYGON
Figur 3.7: Avvik ved overføring mellom applikasjoner [Kalstveit, 1997].
IFC-modellens kompleksitet og generalitet er særlig et problem for analyseapplikasjoner. Analyseprogrammer støtter ikke nødvendigvis kompleks geometri
og boolske operasjoner, som kreves for å tolke den geometriske informasjonen
[Marsh, 2006].
BIM er, som omtalt i Kapittel 2, avhengig av god kommunikasjon for å
fungere optimalt. Det er derfor viktig at applikasjonene kan kommunisere seg
i mellom via en felles server med en database. IFC har klare begrensninger
i forhold til å oppnå dette. IFC-modellen er i likhet med STEP basert på
datamodelleringspråket EXPRESS, og bruker mange av de samme denisjonene.
STEP er basert på en statisk overføring av informasjon da det ble utviklet for
dataintegrering og ikke datainteroperabilitet og støtter ikke objektoppførsel
[Howie et al., 1996]. IFC støtter med andre ord kun statiske datastrukturer
men ikke objekter i datateknisk forstand og vil derfor ikke fungere optimalt
for overføring av informasjon.
3.6 Green Building Extensible Markup Language
(gbXML)
Innledning
Autodesk Revit overfører informasjon til Integrated Environmental Solutions
(IES) Virtual Environment (VE) via gbXML-formatet. Dette avsnittet ser nærmere på dette formatet.
28
Bakgrunn
Et annet initiativ for å imøtekomme behovet for interoperabilitet ble igangsatt
av Green Building Studio Inc. (GBS), da med fokus på energimodelleringsprogrammer. For å gjøre detaljerte energianalyser var man tidligere avhengig av å ta
ut mengder manuelt fra 2D tegninger. Ulempene med dette var mange; prosessen var tidkrevende, kostet mye og i store prosjekter kunne man fort regne feil og
få unøyaktige mengder. Derfor ble antallet kalkyler og analyser ofte holdt på et
minimum [Jongeling, 2008]. I prosjekter som bruker BIM kan modellen importeres i et energimodelleringprogram, og man kan bruke denne informasjonen for
å utføre kalkyler og analyser. Prosessen er raskere og mer nøyaktig, og fører ofte
til at man utfører ere analyser og oppnår et bedre resultat [Bourarsa, 2005].
For å legge til rette for en slik arbeidsprosess startet GBS med støtte fra California Energy Commission (CEC), Public Interest Energy Research (PIER) og
Pacic Gas and Electric (PGE) utviklingen av gbXML.
Utvikling
GBS startet utviklingen av gbXML i desember 1999, og seks måneder senere
ble det første gbXML-skjemaet publisert. Skjemaet har gjennomgått en rekke
revisjoner etter dette, hvor den nyeste utgaven er versjon 0.37. GBS ble et
datterselskap av Autodesk i juni 2008, mens gbXML ble en ideell organisasjon
under det osielle navnet Open Green Building XML Schema som forvaltes og
utvikles med støtte fra en rekke BIM-programvareleverandører [gbXML, 2010].
Konsept
XML er en videretuvikling av HyperText Markup Language (HTML), oppmerkingsspråket brukt for å vise informasjon i World Wide Web (WWW). HTML
har et sett med etiketter og beskriver hvordan informasjon skal presenteres på
WWW. I XML kan etikettene deneres av brukeren slik at man kan systematisere navngiving og kategorisering av data [Eastman et al., 2008]. Skjemaene for
overføring lagres som ren tekst i for eksempel et regneark eller en database.
gbXML er et XML-skjema spesielt utviklet for overføring av informasjon
relevant for energianalyser og -simuleringer [Eastman et al., 2008]. Et så spesikt fokusområde for informasjonoverføring forenkler oppgaven med å denere
hva slags informasjon som skal overføres, og på hvilken måte informasjonen skal
representeres. For eksempel er kravene for geometrisk framstilling av modeller
29
i et analyseprogram at det klarer å representere romlig volum, solavskjerming
og termiske soner. gbXML-formatet har valgt å bruke enkel polygongeometri
til dette formålet, og alle modelleringsapplikasjoner som skal overføre modeller
via gbXML-formatet må konvertere komponentene i modellen til denne typen
geometri. Dette er en fordel for analyseapplikasjonene, da dette gir et enkelt og
entydig lformat som er lett å implementere i applikasjonen.
gbXML-skjemaet har evnen til å overføre følgende informasjon [Kennedy, 2010]:
•
Plan polygongeometri
•
Rektangulær polygongeometri
•
Konstruksjoner og materialer
•
Termiske- og emmisjonsegenskaper
•
Kostnader i et livsløpsperspektiv
•
Vinduer med solskjerming
•
Ventilasjonsbehov
•
Versjon- og endringshistorikk
•
Vegetasjonstyper, lokasjon og vannforbruk
•
Inltrasjon
•
Transporteringstyper
•
Belysning
•
Værdata
•
Internt og eksternt utstyr
•
Energibruk
Se Tillegg B for eksempel på oppbygningen av et gbXML-element.
Utfordringer
gbXML-formatet henter kun ut spesikk informasjon relevant for en analyseapplikasjon og gjør forenklinger i blant annet geometri under konverteringen. Dette er fordelaktig for analyseprogrammene, da formatet er enkelt å implementere
og informasjonen er forståelig. Slike forenklinger fører dog til at konverteringen
30
ikke er en tapsfri prosess. Overføring via gbXML-formatet er derfor en enveiskommunikasjon fra modelleringsapplikasjonene til analyseapplikasjonene. Med
andre ord må man gå inn i modelleringsapplikasjonen hvis man ønsker å gjøre
endringer i modellen ut i fra de analysene som er blitt utført.
3.7 Sammenligning av IFC og gbXML
A
gbXML
IFC
File Description, File
name and file schema
File Version
Units
Organization, Person,
owner history.
Units
Campus ID
Cartesian points,
direction, dimensional
exponents, shape
representation
Location
Product definition and
shape.
Property value
Area, Volume
Predefined element
parameters
Description
Material, layer set,
Color.
Shell Geometry
ID
Building ID
Cartesian Points,
Co-ordinates.
Shell Surface
Shell Openings
Space ID
Surface ID
Product name,
version
Platform
Figur
3.8:
Sammenligning
av
IFC-modellen
[buildingSMART, 2010b]
og
gbXML-skjemaet [gbXML, 2010]
Figur 3.8 viser hva slags informasjon som blir overført med IFC-modellen
og gbXML-formatet. Hensikten med IFC-modellen er å lage en altomfattende,
generisk beskrivelse av bygninger og byggingsprosesser som er så generell at
den kan brukes av all BIM-programvare til å sende informasjon frem og tilbake
tapsfritt. Modellen er basert på entiteter, som settes sammen for å danne forekomster. gbXML-skjemaet sin utvikling er på sin side kun tiltenkt overføring
av informasjon til energimodelleringsprogrammer, og vil ikke være en tapsfri
kommunikasjonsmåte som kan brukes begge veier.
IFC-modellen er laget ut i fra et top-down design; man starter med å denere de mest generelle, overordnede bestanddelene som utgjør modellen, for så
å fragmentere disse delene i stadig ere underkategorier helt til man er kom-
31
Side 1
met ned til grunnentitetene i modellen [Wikipedia, 2010]. Modellen kan spore
opp alle endringer medført av at et element i modellen har blitt endret, og kan
ideelt sett automatisk vedlikeholde sin egen integritet [Dong et al., 2007]. Modellen er svært omfattende og er derfor svært krevende å programmere og å
implementere i programvare. IFC-modellen krever også mye lagringsplass, siden
den inneholder så mye informasjon.
gbXML-skjemaet er laget ut i fra et buttom-up design; man starter med
en detaljert beskrivelse av de individuelle grunnelementene i systemet, som så
samles til en taksonomi i overordnede grupper [Wikipedia, 2010]. Denne prosessen itereres helt til man har kommet til det øverste nivået i systemet. Dette gir
et mindre komplisert skjema enn IFC-modellen.
gbXML-skjemaet representerer geometrien til overater ved hjelp av to attributter: plan polygongeometri og rektangulær polygongeometri. Begge inneholder den samme geometriske informasjonen og brukes sammen for å dobbeltsjekke at geometrien som blir importert er korrekt. Kun rektangulær geometri
kan representeres med disse to attributtene, men det er tilstrekkelig for å utføre
energianalyser. IFC-modellen kan teoretisk sett representere alle typer bygningsgeometri.
32
4
Programvare
4.1 Generelt
COWI har tatt i bruk BIM på en rekke byggeprosjekter og ønsker å teste ut
to miljøberegningsprogrammer for å kartlegge hvor godt de fungerer med Autodesk Revit. I dette kapittelet presenteres Autodesk Revit og de to programmene
Autodesk Ecotect og IES VE. Formålet med presentasjonen er å gi en innføring i
hvordan programmene fungerer i bruk. I tillegg beskrives import- og eksportevnene. Først presenteres Autodesk Revit, deretter presenteres Ecotect og IES VE,
som begge er analyseprogrammer med hensyn på energibruk.
4.2 Autodesk Revit
Introduksjon
Revit ble først lansert av Revit Technology Corporation i 2000. Revit var den
første objektbaserte bygningsmodellen hvor alle de ulike aspektene til modellen som for eksempel plantegninger, tverrsnitt, 3D-visning og tidsplaner ble
automatisk oppdatert hvis man gjorde en endring. I 2002 ble rmaet kjøpt opp
av Autodesk og har blitt utviklet videre av dette rmaet. I dag er Revit en
plattform bestående av produkter for en rekke ulike disipliner innen byggenæringen: Revit Architecture, Revit Structure og Revit MEP [Autodesk, 2010a].
COWI bruker Revit Architecture, og herunder følger en presentasjon av denne
applikasjonen.
33
GUI
I 2010-utgaven ble Autodesk Revit sitt GUI (se gur 4.1) endret betraktelig.
For å gi mer plass til å skildre selve modellen man arbeider med ble verktøyene
organisert på en ny måte; ulike verktøy er gruppert og plassert under faner, et
system veldig likt verktøylinjen i Microsoft Oce 2007.
Figur 4.1: Verktøylinjen til Autodesk Revit
Her presenteres verktøyene som tilhører de ulike fanene:
Home
Verktøy for å lage en rekke ulike bygningselementer i modellen.
Insert
Verktøy for å sette inn eksterne elementer som for eksempel CAD-ler
i modellen.
Annotate
Modify
Verktøy for å legge til 2D informasjon i modellen.
Verktøy for å endre eksisterende elementer, data og systemer i model-
len.
Massing & Site
Collaborate
View
Verktøy for mengdeberegninger og lokalisering av bygget.
Verktøy for at ere skal kunne arbeide sammen på en modell.
Verktøy for å se modellen i ulike perspektiver som planskisser, tverrsnitt
og 3D.
Manage
Verktøy for å endre innstillingene i prosjektet, eller preferansene i
Revit.
Element-Fane
Når man har valgt et element i modellen kommer det i tillegg
opp en egen fane med verktøy relevant for dette elementet.
Plug-In
Egne faner blir laget hvis man installerer tilleggsfunksjoner fra andre
applikasjoner.
34
Figur 4.2: Autodesk Revit sitt GUI
Under verktøylinjen nner man selve tegneområdet, hvor modellen er illustrert. Her kan man velge elementer man ønsker å modisere, legge til nye
elementer og veksle mellom ulike perspektiver å se modellen i. Til venstre for
tegneområdet nner man en oversikt over prosjektet man jobber med, delt inn
i ulike utvidbare mapper (se Figur 4.2).
I bruk
Autodesk Revit er en applikasjon som brukes til BIM. Modellen inneholder all
informasjon nødvendig for bygningsdesignet. Ved hjelp av Revit kan brukeren
lage en bygningsmodell som kan representeres i ulike perspektiver (plantegninger, tverrsnitt, 3D-fremvisning og så videre), ta ut mengder fra modellen og
sjekke om elementer kolliderer. Revit kan kobles sammen med andre applikasjoner for å utføre analyser eller legge til mer detaljert informasjon for hvert enkelt
fagfelt [Autodesk, 2010a].
Når man etablerer et byggeprosjekt i programmet arbeider man med én l.
Informasjonen i len blir lagret i en relasjonsdatabase kalt Parametric Change
35
Engine (PCE). Revit danner automatisk parametere som denerer relasjonene
mellom elementene i modellen. Når man arbeider i tegneområdet kan modellen representeres i ulike perspektiver, og ved hjelp av PCE sørger Revit for at
endringer gjort i et av perspektivene blir oppdatert i alle andre perspektiver
[Autodesk, 2009b].
Informasjonsoppbygning
Revit håndterer informasjon ved å dele inn elementer i kategorier, familier, typer
og forekomster (se Figur 4.3).
Figur 4.3: Inndeling av informasjon i Autodesk Revit [Autodesk, 2009b]
Kategori
Øverste nivå i informasjonsinndelingen består av kategorier. Kategorien for modellelementer inneholder vegger og bjelker, kategorien for merknader inneholder
notater, og så videre [Autodesk, 2009b].
Familie
Revit inneholder tre ulike familiegrupper [Autodesk, 2009b]:
System families
Disse familiegruppene er predenert i Autodesk Revit, og
man kan ikke lage nye familier i denne gruppen på egenhånd. Familiegruppene inneholder vanlige bygningsdeler som vegg-, tak- og gulvelementer.
Disse elementene eksisterer i prosjektmodellen som typer av sin familiegruppe, lagret som *.rte maler. I tillegg inneholder gruppen systemegenskaper for modellens tegneark, representasjonsmåter, nivåer og så videre.
36
Loadable families
Disse familiene er lagret i Revit sitt bibliotek utenfor pro-
sjektet som *.rfa ler og lastes inn i prosjekmodellen etter hvert som de
blir tatt i bruk. Familiene består av to elementtyper frittstående og integrerte. Frittstående elementer kan være ting som møbler, trær, mennesker,
biler og så videre. Integrerte elementer er innlemmet i andre bygningsdeler. Dette kan være elementer som vinduer og dører. I tillegg inneholder
familiegruppen elementer som brukes når kommentarer legges til i modellen.
In-place families
Når man har behov for å lage et element i modellen som ikke
er predenert i Revit eller kan lastes inn i modellen fra Revit sitt bibliotek
(jamført System- eller Loadable Families) vil dette elementet tilhøre Inplace familiegruppen. Dette elementet er unikt for prosjektet det er laget
i, og blir lagret i en egen familiegruppe som kun inneholder én familietype.
Typer og forekomster
Hver familie deneres av to typer parametere Type- og forekomstparametere.
Typeparametere inneholder informasjon som er generell for alle elementer tilhørende den gitte familien. Forekomstparametere inneholder informasjon som
er spesikk for hver enkelte forekomst i familien. En søyle sine dimensjoner vil
være en typeparameter, mens plasseringen til en av søylene i modellen er en
typeparameter [Autodesk, 2009b].
Import- og eksportevne
Autodesk Revit Architecture 2011 kan importere og eksportere en rekke formater. For en komplett liste se Vedlegg C.
Overføring med IFC
Autodesk Revit 2011 er sertisert for import og eksport til IFC2x3 modellen [Autodesk, 2009b]. Standard Revit elementer kan representeres direkte med
IFC-entiteter. For eksempel vil en Revit-vegg bli eksportert som en IFCwall.
Denne metoden ble brukt for å overføre informasjon fra Autodesk Revit 2011
til Autodesk Ecotect 2011.
37
Overføring med gbXML
Autodesk Revit 2011 kan eksportere sine modeller til gbXML-formatet. Når
man skal eksportere modellen til gbXML får man opp et eget vindu (se Figur
4.4) hvor man kan se over modellen og gjøre endringer. Under Generalfanen kan
man blant annet endre bygningstype, lokasjon og velge hvor detaljert geometrien
som skal eksporteres skal være. I Detailsfanen kan man velge mellom visning av
romkategorier eller analytiske overater. Hvis det er åpninger i modellen vil
disse vises her, og man vil også få beskjed hvis det er feil i modellen som må
rettes opp. Man kan studere en forhåndsvisning av modellen for å se at alle
overater og romvolum er korrekt.
Figur 4.4: Eksportering til gbXML-formatet i Revit
38
gbXML-skjemaet organiserer bygningsinformasjon i følgende hierarki: Lokasjon, Bygning, Rom, Overate og Åpning (se Figur 4.5).
Figur 4.5: Informasjonsorganisering i gbXML [Autodesk, 2009b].
Se Tillegg D for en oversikt over gbXML-elementer og -attributter som støttes av Revit Architecture 2011.
4.3 Autodesk Ecotect
Introduksjon
Autodesk Ecotect ble kjøpt opp av Autodesk i 2008. Før den tid var programmet eid og utviklet av Square One Reaserch. Applikasjonen fokuserer på energiberegninger og -analyser i tidligfase i byggeprosjekter, slik at man så tidlig
som mulig kan utforme designet av bygget til å bli mest mulig energieektivt
[Autodesk, 2010a].
39
GUI
Autodesk Ecotect 2011 sitt GUI (se Figur 4.6) består av en hovedmeny, paneler
med redigerbar informasjon, et tegneområde og sider med ulik representering
av informasjon og ulike verktøy [Autodesk, 2010b].
Figur 4.6: Autodesk Ecotect sitt GUI
Hovedmeny
Hovedmenyen består av generelle verktøy for bruk av program-
met.
Paneler
På høyre side kan man velge mellom ulike faner. Disse fanene inne-
holder paneler med editerbar informasjon om prosjektet eller valgte elementer. Man kan blant annet endre verdier i objekter, håndtere soner og
skygger, endre visualiseringsinnstillinger og velge eksportformater.
Tegneområde
I tegneområdet blir modellen representert ut i fra ulike visuali-
seringsmåter. Her kan man velge og legge til elementer.
Sider
På venstre hånd nner man faner man kan bruke for å veksle mellom uli-
ke sider. Disse sidene inneholder ulik informasjon om prosjektet og verktøy relevant for hver enkelt side. I Project-side kan man legge til generell informasjon om prosjektet som for eksempel bygningens lokasjon, 3D
40
Editor-siden brukes for å velge eller lage objekter, Visualise-siden brukes
til å visualisere modellen og Analysis-siden inneholder verktøy for å utføre
ulike analyser.
Funksjoner
Autodesk Ecotect Analysis 2011 brukes til å visualisere, simulere og analysere
bygningsfunksjoner tidlig i designprosessen. Applikasjonen betrakter ulike faktorer som for eksempel hvilke overater som er eksponert mot utsiden, eksponering til sollys, åpninger i overater og varme generert av interne varmekilder
som belysning og utstyr i analyseprosessen. For å visualisere, simulere og analysere bygningsfunksjonene trenger applikasjonen informasjon om de romlige
aspektene til bygget, materialegenskaper og soneinndeling [Autodesk, 2010b].
Følgende analyser kan utføres med Autodesk Ecotect 2011 [Autodesk, 2010b]:
Dynamic Daylight Simulations (DAYSIM)
Radiance
Simulering av dagslys
Simulering av lys
Chartered Institution of Building Services Engineers (CIBSE)
Energy+
Energianalyser
Energianalyser, solinnstrålingsanalyser, akustikkanalyser
NIST-FDS, Fluent og WinAir4
Dynamiske analyser av væsker og gasser.
Energianalyse
Autodesk Ecotect Analysis 2011 bruker en termisk algoritme fra CIBSE for å
utføre energianalyser av bygninger [Autodesk, 2010a]. Med metoden utviklet av
CIBSE beregnes temperatur og belastning i to forskjellige stadier. Først beregnes indre temperaturvariasjoner time for time, så beregnes varmebehovet.
Varmebehovet er for hvert rom og for ulike soner og tar ikke hensyn til eektgraden til varme- og kjøleanlegg. Resultatene som presenteres er årlig forbruk
og maks forbruk.
CIBSE sin utslippsmetode ble utviklet for å beregne maksimum nedkjølingsbehov til ett bygg [CIBSE, 1999], og tester viser at denne metoden ikke frembringer nøyaktige resultater for oppvarmingsbehovet til en bygning [Hensen and Radosevic, 2004].
De termiske resultatene fra CIBSE bør derfor brukes som en referanse for å sammenligne ulike designløsninger og ikke for å dokumentere selve oppvarmingsbehovet.
41
De termiske analysene av interne temperaturer og varmebehov gjøres gjennom en simulering av hvordan energi beveger seg inn, ut og gjennom rom og
volum i bygningsmassen. For å gjøre dette benytter Ecotect termiske soner denert i modellen. En termisk sone er denert som et lukket volum, avgrenset av
gulv, vegger og tak, og deneres i Revit når man designer modellen (se Avsnitt
5.2).
Import- og eksportevne
Autodesk Ecotect Analysis 2011 kan eksportere ulike bildeformater og data til
en rekke ulike modellerings- og analyseprogrammer. Programmet kan importere
3D CAD geometri og annen modelldata. Se Tillegg C for en mer komplett liste
over eksport- og importevnene til Autodesk Ecotect.
Import av IFC-modeller fra Autodesk Revit
Autodesk Ecotect Analysis 2011 kan importere geometri-, material- og soneinformasjon via IFC-modeller, men dette er kun en Beta funksjon (Se Figur 4.7)
og har ikke blitt ferdig utviklet. I importmenyen til IFC kan man velge hvordan
Ecotect skal gjøre om IFC-entiteter til Ecotect sine egne materialtyper. Dette
kan gjøres basert på materialer, egenskapssett, elementtyper eller elementnavn.
I tillegg kan man manuelt denere elementklassene til elementer som importeres, velge om hver entitet skal lages som en separat sone og velge om kun
romavgrensninger skal inkluderes.
Figur 4.7: Import av IFC i Ecotect
42
4.4 IES VE
Introduksjon
Firmaet IES ble dannet i 1994 av Don McLean, som hadde som mål å utvikle
et brukervennlig program som skulle gi et godt grunnlag for å designe, bygge og
drifte energieektive bygg. Resultatet ble IES VE; en rekke ulike analyseverktøy
integrert i en plattform, som benytter samme datamodell for å modellere og
analysere bygningsmodeller.
GUI
IES VE sitt GUI (se Figur 4.8) består av en hovedmeny, et tegneområde, en
rullefeltsmeny for analyseverktøy, en utforsker og et felt med rominformasjon
[IES VE, 2010].
Figur 4.8: IES VE sitt GUI [IES VE, 2010]
Utforsker
Utforskeren gir en oversikt over romgrupper og soner i modellen.
Man kan spesisere hvilke elementer som skal høre til de ulike gruppene.
43
Analyseverktøy
Dette er en rullefeltsmeny med en liste over ulike verktøy
man kan bruke for å analysere byggets egenskaper.
Hovedmeny
Hovedmenyen består av en nedtrekksmeny med generelle verktøy
for programmet, og verktøylinjer for å modellere og redigere objekter.
Tegneområde
I tegneområdet kan man visualisere modellen på ulike måter. I
tillegg kan man velge og redigere objekter og legge til nye objekter.
Rominformasjon
Her vises informasjon sonenummer, navn, id, volum, areal,
utvendig veggareal, utvendig åpning, farge og lag om sone/objekt som er
valgt. Velger man ere objekter summeres dataen.
Funksjoner
From Analysis to Understanding
IES VE inneholder i likhet med Ecotect Analysis verktøy som kan brukes tidlig
IES <Virtual
Product Overview
V6.0
i designprosessen
for Environment>
å vurdere konsekvensene
av ulike
designløsninger. I tillegg
kan applikasjonen brukes når mer detaljerte løsninger skal designes, og også når
bygget skal driftes [IES VE, 2009]. Modellen som skal analyseres importeres inn
i Integrated Data Model (IDM), hvor geometri og all annen relevant informasjon
By:
INTEGRATED
ENVIRONMENTAL
for å analysere
bygningen
blir lagret.
SOLUTIONS LIMITED
Date: Monday 19 October 2009
BOSTON, MA │ GLASGOW, SCOTLAND │ DUBLIN, IRELAND │ LONDON, ENGLAND │ MELBOURNE, AUSTRALIA │ SAN FRANCISCO, CA │ DUBAI, UAE
Figur 4.9: De ulike variantene av IES VE [IES VE, 2010]
Analyseverktøyene som er tilgjengelig avhenger av hvilken variant av IES
VE brukeren har rettigheter til. De ulike variantene er: VE-Ware, VE-Toolkits,
VE-Gaia og VE-Pro (se Figur 4.9). VE-Ware er gratis og brukes for å beregne
44
årlig energiforbruk og utslipp av karbon. VE-Toolkits, VE-Gaia og VE-Pro er
kostnadsbelagte, og med hvert nivå får man stadig ere funksjoner.
Analyser man kan utføre med IES VE-Pro [IES VE, 2010]:
ApacheCalc
ApacheCalc beregner varmetap og -gevinster til bygget, basert
på prosedyrer utviklet av CIBSE.
ApacheLoads
ApacheLoads beregner oppvarming- og nedkjølingsbehovet til
bygget. Dette gjøres basert på en metode utviklet av American Society of
Heating, Refrigeration and Air-Conditioning Engineers (ASHRAE).
ApacheSim
ApacheSim bruker SunCast, ApacheHVAC og MacroFlo for å vur-
dere byggets termiske egenskaper.
ApacheHVAC
SunCast
Simulering av Heating, Ventilating and Air Conditioning (HVAC).
SunCast simulerer solinnstråling i bygget.
MacroFlo
MacroFlo simulerer luftstrømninger for at man skal kunne studere
naturlig- og hybridventilasjon, inltrasjon og fasadeanalyser.
MicroFlo
MicroFlo er et Computational Fluid Dynamics (CDF)-system for
simulering av luftstrømninger og varmeoverføring.
Deft
Deft brukes for å vurdere ulike designalternativer for å nne frem til det
beste alternativet.
CostPlan
CostPlan brukes for å utføre kostnadsestimeringer i byggeprosjektet.
LifeCycle
LifeCycle utfører livsløpsanalyser av kostnader knyttet til operering
av bygget.
IndusPro
Med IndusPro kan man plassere og dimensjonere ventilasjonskana-
ler.
PiscesPro
Simulex
Lisi
PiscesPro brukes for å designe røroppleggsystemer.
Simulex simulerer en evakuering av bygget.
Med Lisi kan man designe og simulere heisløsninger for å optimalisere
transporteringen av personer i bygningen.
45
Energianalyse
IES VE bruker verktøyet ApacheLoads for å beregne oppvarming- og nedkjølingsbehovet til bygget. Varmebalansemetoden som Apacheloads bruker under
disse simuleringene er utviklet av ASHRAE. Med denne metoden simuleres først
varmetapet til bygningen for å beregne oppvarmingsbehovet. Videre simuleres
oppvarmingen i bygget fra solinnstråling, menneskelig aktivitet og så videre for
å beregne nedkjølingsbehovet [Barnaby et al., 2005]. Under simuleringene benytter IES VE de termiske sonene hentet fra modellen i IDM. En termisk sone
er denert som et lukket volum, avgrenset av gulv, vegger og tak, og deneres
i Revit når man designer modellen (se Kapittel 5.2).
I motsetning til Ecotect, som kun gir årlig og maks energibehov, kan IES VE
presentere energibehov for ulike perioder, helt ned til dagsbehovet [IES VE, 2010].
Import- og eksportevne
IES VE kan ikke importere mange formater sammenlignet med Ecotect og Revit,
men har fokusert på formatet gbXML. Når gbXML-len er lastet inn i applikasjonen blir modellen lagret i hovedlen *.ve, i tillegg til en rekke undermapper
dedikert til de ulike analysefunksjonene internt i applikasjonen. Se Tillegg C for
en liste over import- og eksportevnene til IES VE.
Import av gbXML
Figur 4.10: Importering av gbXML-l i IES VE
46
Import av en modell lagret i gbXML-formatet gjøres i et eget vindu (se
Figur 4.10). Her får man opp redigerbar informasjon om byggets bygningstype,
bygningsmaterialer, HVAC-system og lokasjon. I tillegg kan man gå inn og velge
romtype, HVAC-system og bygningsmaterialer for individuelle rom i modellen.
Figur 4.11: Kontroll av rom i modell som skal importeres
Før man kan importere modellen må man sjekke rommene i modellen (se
Figur 4.11). Egenskaper som er utenom forventede verdier blir fremhevet i gult,
slik at man kan oppdage avvik.
Overføring via PlugIn
Et alternativ til å laste inn gbXML-ler i IES VE er å benytte en PlugIn laget for
Autodesk Revit (Se Figur 4.12). PlugIn-programvaren er kompatibel med Revit
2008, 2009, 2010 og 2011 og gjør det mulig å foreta analyser direkte i Revit.
Først må man importere modellen til gbXML på samme måte som beskrevet
ovenfor. Etter dette kan man utføre ulike analyser avhengig av hva slags lisens
man har direkte i Revit.
Figur 4.12: IES VE PlugIn til Autodesk Revit
47
5
Målemetode
5.1 Generelt
Dette kapittelet handler om testing av programvare. Hensikten med disse testene
er å kartlegge hva slags informasjon som blir overført mellom de ulike applikasjonene for å vurdere interoperabiliteten. Applikasjonene som ble brukt under
testene er Autodesk Revit 2011, Ecotect Analysis 2011 og IES VE 6.0.6. IFC
2x3 ble brukt for å overføre informasjon fra Revit til Ecotect og gbXML 0.37 ble
brukt for å overføre informasjon fra Revit til IES VE. Informasjonsoverføringen
er kun testet fra Revit til analyseapplikasjonene da ingen av analyseapplikasjonene kan eksportere informasjon til et format som kan lastes inn i Revit. Først
i kapittelet beskrives de grepene som ble gjort i Revit for å legge til rette for
eksporteringen av modellene. Til slutt beskrives testene som ble utført.
5.2 Innstillinger i Revit
Innledning
Her presenteres de innstillingene som ble gjort i Revit Architecture før testene
ble utført. Først presenteres de generelle innstillingene for modellene som skulle
eksporterest til IFC og gbXML. Deretter presenteres spesikke innstillinger som
ble gjort med hensyn til IFC og gbXML.
48
Generelle innstillinger
Denering av Prosjektinformasjon
Relevant prosjektinformasjon for energianalyser vil være modellens bygningstype, geograske lokasjon og orientering. Ved å gå inn i Project Information
under Manage-fanen kan man velge Energy Settings hvor de to førstnevnte
attributtene kan spesiseres (Se Figur 5.1). For å endre modellens orientering i
Figur 5.1: Energy Settings i Revit
forhold til geogrask nord går man inn på Position under Manage-fanen og
velger Rotate True North (Se Figur 5.2). I tillegg må man sørge for at denisjonen av orienteringen til bygget er endret fra Project North til True North
i egenskapene til hver tegning.
Figur 5.2: Endring av modellens orientering i Revit
Denering av rom
Både Ecotect og IES VE baserer seg på termiske soner for å gjøre analyser
av en modell. En termisk sone er denert som et lukket volum, avgrenset av
49
gulv, vegger/romseparasjonslinjer og tak/etasjeskillere. De termiske sonene blir
denert i Revit når man designer modellen, og det er kritisk at dette utføres
riktig.
Det er viktig å sørge for at alle vegger er koblet til hverandre, så vel som til
tak- og gulvelementer, slik at det ikke blir noen åpninger i modellen. I tillegg må
man påse at attributten Room Bounding er valgt for alle elementer som skal
overføres til analyseapplikasjonen (Se gur 5.3). Etter at man har sørget for at
Figur 5.3: Room Bounding attributt i Revit
alle avgrensningsobjekter er riktig sammenkoblet må man legge inn romobjekter
i alle rom i modellen. Her er det viktig å påse at romobjektene strekker seg helt
opp til etasjeskiller/tak. Hvis sonene ikke rekker opp til etasjeskiller/tak, vil
ikke modellen som eksporteres bli riktig for termiske analyser. Standardhøyden
til romobjekter i Autodesk Revit er 2,4 meter, så hvis veggene til rommet er
høyere enn dette må man gå inn og denere ny høyde (Se gur 5.4). For å gjøre
romobjektenes utstrekning synlig slik at man kan kontrollere høyden må man
gå inn i Visibility/Graphic og huke av for Interior Fill.
Figur 5.4: Justering av sonehøyde i Autodesk Revit 2011
50
Beregning av romvolum
Standardinnstillingen i Revit er kun å beregne arealer, da dette krever mindre
systemressurser. Analyseverktøyene har behov for informasjon om volum og
romhøyde, og man må derfor endre innstillingen i Revit til å beregne både areal
og volum. For å gjøre dette velger man Areal and Volume Computations under
Home-fanen (Se Figur 5.5).
Figur 5.5: Romvolum
Innstillinger for eksportering til IFC
IFC-mal
Revit laster inn en prosjektmal når man etablerer et nytt prosjekt. Denne malen denerer familier, innstillinger som måleenheter, skalering og skravering og
geometri [Autodesk, 2009b]. De modellene som ble laget for overføring til Ecotect Analysis brukte IFC Metric Template.rte som prosjektmal.
IFC-avbildingsl
For å kunne eksportere en Revit-modell til IFC må man denere hvilke IFCklasser de ulike Revit-familiene samsvarer med i menyen IFC Options (se Figur
5.6). IFC-avbildingslen som ble brukt under testene for overføring mellom Revit og Ecotect er lagt ved i Vedlegg E. Hver rad representerer en elementkategori,
51
eller underkategori med en tilhørende IFC-klasse. Blanke felt vil Revit automatisk tolke for å tildele samsvarende klasse. Felt med teksten Not Exported
fører til at elementet ikke blir overført [Autodesk, 2009b].
Figur 5.6: Menyen IFC Options
Innstillinger for eksportering til gbXML
Prosjektmal
Modellene som ble laget for overføring til IES VE brukte i likhet med modellene
som ble laget for overføring til Ecotect en prosjektmal. De modellene som ble
laget for overføring til IES VE brukte DefaultMetric.rte som prosjektmal.
Søyler
Overater blir denert i gbXML-skjemaet ut ifra hvilke soner som tilstøter overaten (Se Figur D.18 i Vedlegg D). Siden det ikke er denert noen rom innvendig i søyler og søyler er denert som overater i gbXML-skjemaet vil søylens
overate bli tolket som en yttervegg. For å unngå dette ble attributten Room
Bounding satt til negativ verdi for alle søyler.
Tidsplan
Når man skal eksportere en modell til gbXML får man til tider opp en feilmelding i eksporteringsvinduet (Se Seksjon 4.2) som sier at det er udenerte rom
52
i modellen (Se Figur 5.7). Denne feilmeldingen skyldes at Revit ikke klarer å
Figur 5.7: Feilmelding i Revit
eksportere rom som er laget i en tidligere fase. Feilmeldingen ble løst ved å kun
ha én fase i modellen (Se Figur 5.8) og å legge inn alle bygningselementer i egne
tidsplaner.
Figur 5.8: Redigering av faser i Revit
5.3 Testmodeller
Fremgangsmåte
Modellene som ble testet ble laget i Autodesk Revit Architecture 2011 med de
innstillingene som er beskrevet ovenfor. Modellene ble laget for å undersøke hvilken informasjon som ble overført fra Revit til Ecotect og IES VE via henholdsvis
IFC og gbXML. Informasjonen som ble testet for overføring er prosjektinformasjon, rominformasjon, informasjon om objekttyper, informasjon om geometri og
materialegenskaper. Detaljnivået for eksporteringen var alltid satt til Complex
with Mullions and Shading Surfaces.
53
Test 1 Prosjektinformasjon
Den første modellen ble laget for å teste hvorvidt den generelle informasjonen
om prosjektet ble overført. Dette omfatter informasjon om geogrask lokasjon,
orientering, bygningstype og enhetsbenevning. Modellen bestod av enkelt sone,
avgrenset av re vegger, tak og gulv (se Figur 5.9).
Figur 5.9: Modell laget i Revit for Test 1
Test 2 Informasjon om objekttyper og rom
Denne testen ble utført for å undersøke hvorvidt informasjon om objekttyper
(tak-, etasjeskille-, gulv-, yttervegg-, innervegg-, vindu-, søyle- og dørtyper) og
rominformasjon (navn, volum, plassering og areal til avgrensende ater) ble
overført fra Revit til analyseapplikasjonene. Dette ble gjort ved å lage modeller
i Revit bestående av alle disse objekttypene. Se Figur 5.10 for eksempel på en
modell laget for Test 2.
Figur 5.10: Modell laget i Revit for Test 2
Test 3 Veggeometri
Denne testen ble utført for å kartlegge hva slags type veggeometri som kunne
overføres fra Revit til analyseapplikasjonene. Dette ble gjort ved å lage modeller
54
med forskjellig type veggeometri. Se Figur 5.11 for eksempler på modeller laget
for Test 3.
(a) Modell med mange- (b) Modell med en- (c) Modell med dobbeltkrumkantet vegg
keltkrummet vegg
met vegg
Figur 5.11: Modeller laget i Revit for Test 3
Test 4 Takgeometri
Denne testen ble utført for å kartlegge hva slags type takgeometri som kunne
overføres fra Revit til analyseapplikasjonene. Dette ble gjort ved å lage modeller
med forskjellig type takgeometri. Se Figur 5.12 for eksempler på modeller laget
for Test 4.
(a) Modell med gavltak
(b) Modell med enkeltkrummet tak
(c) Modell med dobbeltkrummet tak
Figur 5.12: Modeller laget i Revit for Test 4
55
Test 5 Materialegenskaper
IES VE henter ikke inn informasjon om materialegenskaper via gbXML, men
lar brukeren denere dette under importprosedyren (se Avsnitt 4.4). Derfor ble
det kun testet om IFC kunne overføre informasjon om materialegenskaper fra
Revit til Ecotect. Forekomstene i modellen inneholdt materialinformasjon som
varmegjennomgangskoesient og materialtype. Se Figur 5.13 for eksempel på
modell laget for Test 5.
Figur 5.13: Modell laget i Revit for Test 5
56
6
Resultater
6.1 Generelt
Dette kapittelet gir en presentasjon av resultatene fra testene som ble utført, en
oppsummering av resultatene og til slutt en drøfting av resultatene.
6.2 Presentasjon av resultatene
Test 1 Prosjektinformasjon
Se Vedlegg F for resultatene fra Test 1.
Ecotect Analysis
Lokasjon
Standard lokasjon for modeller i Ecotect Analysis er Perth, Australia.
Denne verdien ble ikke endret etter at IFC-modellen ble importert.
Orientering
Informasjon om orientering ble overført til Ecotect, men siden
Ecotect kun bruker True North er verdien satt til 0. Med andre ord har
modellen blitt rotert til absolutte koordinater, relativ til True North.
Bygningstype
Enhet
Informasjon om bygningstype ble ikke overført til Ecotect.
Hvilke enheter som ble brukt i modellen ble ikke endret i Ecotect, men
tallverdiene ble konvertert til riktig verdi.
57
IES VE
Lokasjon
Informasjon om lokasjon ble overført til IES VE.
Orientering
Informasjon om orientering ble overført til IES VE, men siden
IES VE kun bruker True North er verdien satt til 0. Med andre ord har
modellen blitt rotert til absolutte koordinater, relativ til True North.
Bygningstype
Enhet
Informasjon om bygningstype ble overført til IES VE.
Informasjon om valgt enhet ble overført til IES VE.
Test 2 Informasjon om objekttyper og rom
Se Vedlegg G for resultatene fra Test 2.
Ecotect Analysis
Figur 6.1: Modell fra Test 2 lastet inn i Ecotect Analysis
Plassering
Som det tydelig fremgår av Figur 6.1 ble ikke objektene sin plas-
sering i forhold til hverandre i modellen lastet inn i Ecotect.
Romtype
Rommene sin typeinformasjon ble lastet inn i Ecotect. Navn og areal
til rommene sine avgrensende ater ble overført, men volum ble ikke lastet
inn direkte i Ecotect.
Vindustype
Ikke alle forekomster av vinduer i modellen ble lastet inn i Eco-
tect, og det ble ikke avdekket noe system for når forekomstene ble lastet
inn og når de ikke ble det. Geometrien til forekomstene var intakt, men
glassate og vinduskarm sin orientering i forhold til hverandre var fordreid. Forekomstene var ikke koblet til veggene de tilhørte, og de hadde
mistet sin typeinformasjon.
58
Dørtype
I IFC-malen som ble brukt for å lage modeller for overføring til Eco-
tect kunne man kun velge én type dør (IFC_Door). Ingen informasjon
om dører ble lastet inn i Ecotect.
Gulvtype
Gulvforekomsten sin typeinformasjon og geometri ble lastet inn i
Ecotect.
Etasjeskillertype
Innerveggtype
Ingen informasjon om etasjeskiller ble lastet inn i Ecotect.
Geometri til innervegger ble lastet inn i modellen, men type-
informasjonen var endret fra innerveggene til yttervegger.
Ytterveggtype
Geometri- og typeinformasjon til yttervegger ble lastet inn i
Ecotect.
Taktype
Takforekomsten sin typeinformasjon og geometri ble lastet inn i Eco-
tect.
Søyletype
Geometrien til søylene ble lastet inn i modellen, men forekomstene
hadde mistet sin typeinformasjon.
IES VE
Figur 6.2: Modell fra Test 2 lastet inn i IES VE
Plassering
Som Figur 6.2 viser, ble rommenes plassering i forhold til hverandre
overført til IES VE.
Romtype
Rommene sin typeinformasjon ble lastet inn i IES VE. Navn, volum
og areal til rommene sine avgrensende ater ble overført.
59
Vindutype
Vindustyper ble lastet inn i modellen. Forekomstene inneholdt
geometrisk informasjon, men vindussprosser ble ikke tatt med.
Dørtype
Dørtyper ble lastet inn i modellen. Forekomstene inneholdt geome-
trisk informasjon, men eventuelle glassater i dørene ble ikke tatt med.
Gulvtype
Gulvtype med geometrisk informasjon ble lastet inn i modellen.
Etasjeskillertype
Etasjeskillertype med geometrisk informasjon ble lastet inn
i modellen.
Innerveggtype
Innerveggtype med geometrisk informasjon ble lastet inn i mo-
dellen.
Ytterveggtype
Ytterveggtyper med geometrisk informasjon ble lastet inn i
modellen.
Taktype
Taktyper med geometrisk informasjon ble lastet inn i modellen.
Søyletype
Som beskrevet i Kapittel 5 blir søyler sin overate tolket som en
yttervegg. Derfor ble ikke søyler tatt med i modeller som ble overført til
IES VE.
Test 3 Veggeometri
Ecotect Analysis
Figur 6.3: Modell med mangekantet vegg lastet inn i Ecotect Analysis
Som vist i Figur 6.3 ble modeller med ate vegger lastet inn i Ecotect Analysis, men det var derimot ikke mulig å laste inn en modell via IFC som inneholdt
krumme vegger. Hvis et rom var avgrenset av krumme vegger ble ingen informasjon om rommet lastet inn.
60
IES VE
(a) Modell med mangekantet (b) Modell med enkeltkrum- (c) Modell med dobbeltvegg
met vegg
krummet vegg
Figur 6.4: Modeller fra Test 3 lastet inn i IES VE
Som vist i Figur 6.4 ble alle modellene i Test 3 lastet inn i IES VE. Applikasjonen evner ikke å nøyaktig fremstille krumme vegger, men bruker polygonater
som en tilnærming.
Test 4 Takgeometri
Ecotect Analysis
Figur 6.5: Modell med gavltak fra Test 4 lastet inn i Ecotect Analysis
Som vist i Figur 6.5 ble modeller med gavltak lastet inn i Ecotect Analysis, men rommene ble stilt på høykant. Dette er en feil fra Ecotect sin side
da dette også kan oppstå av og til med modeller som lages direkte i Ecotect
[Autodesk, 2010b], men denne feilen var konsekvent ved import via IFC. Det
var ikke mulig å laste inn en modell via IFC som inneholdt krumme tak. Hvis
61
et rom var avgrenset av krumme tak ble ingen informasjon om rommet lastet
inn.
IES VE
(a) Modell med gavltak
(b) Modell med enkeltkrummet tak
(c) Modell med dobbeltkrummet tak
Figur 6.6: Modeller fra Test 4 lastet inn i IES VE
Som vist i Figur 6.6 ble alle modellene i Test 4 lastet inn i IES VE. Applikasjonen evner ikke å nøyaktig fremstille krumme tak, men bruker polygonater
som en tilnærming. Som illustrert i Figur 5.12(c) var det problemer med å laste
inn dobbeltkrummede tak.
62
Test 5 Materialegenskaper
Ecotect Analysis
Figur 6.7: Modell fra Test 5 lastet inn i Ecotect Analysis
Modellene som ble lastet inn i Ecotect inneholdt ingen informasjon om materialegenskaper. De forekomstene som inneholdt typeinformasjon ble tildelt standard materialegenskaper for den respektive typen.
63
6.3 Sammendrag av resultatene
A
Ecotect via IFC IES VE via gbXML
Prosjektinformasjon
Lokasjon
Orientering
Bygningstype
Enhetsbenevning
Objekttype
Vindu
Dør
Tak
Gulv
Etasjeskiller
Yttervegg
Innervegg
Søyle
Rominformasjon
Navn
Volum
Plassering
Areal til avgrensende flater
Veggeometri
Plane vegger
Enkeltkrummede vegger
Dobbeltkrummede vegger
Takgeometri
Plane tak
Enkeltkrummede tak
Dobbeltkrummede tak
û
ü
û
û
ü
ü
ü
ü
û
û
ü
ü
û
ü
û
û
ü
ü
ü
ü
ü
ü
ü
û
ü
û
û
ü
ü
ü
ü
ü
ü
û
û
ü
ü
ü
ü
û
û
ü
ü
û
û
û
Materialegenskaper
Materialegenskaper
Figur 6.8: Sammendrag av resultatene fra de utførte testene
Modeller overført til Ecotect Analysis via IFC
IFC-modeller importert i Ecotect Analysis inneholdt informasjon om modellens
orientering, men inneholdt derimot ikke informasjon om modellen sin lokasjon og
bygningstype. Romforekomstene i modellen inneholdt navn og areal til avgrensende ater, men rommenes plassering i forhold til hverandre var blitt endret og
romvolum ble ikke direkte overført. Informasjon om eventuelle åpninger (dører
og vinduer) i de avgrensende atene ble ikke overført. Alle toppater til rom-
Side 1
64
ü
mene ble satt til objekttypen tak, alle sideater til yttervegg og alle bunnater
til gulv. Ingen informasjon om objektene sine materialegenskaper ble overført.
Hvis modellen som ble overført inneholdt krumme ater ble ingen informasjon
lastet inn i Ecotect.
Modeller overført til IES VE via gbXML
gbXML-skjemaet organiserer som nevnt i Kapittel 4 bygningsinformasjon i følgende hierarki: Lokasjon, Bygning, Rom, Overater og Åpninger (se Figur 6.9).
Ut i fra lokasjon- og bygningskategorien hentet IES VE informasjon om koordinater, orientering og bygningstype til modellen. Romkategorien gav IES VE
informasjon om navn, volum og overateareal til romsoner. Ut i fra tilstøtende soner som omsluttet hver romsone ble romsonenes overatetyper (innervegg,
yttervegg, etasjeskiller, tak og gulv) bestemt. Overatetypenes materialinformasjon ble dog ikke lastet inn. Åpningstyper i overatene (vinduer og dører)
ble lastet inn. Åpningsforekomstenes arealinformasjon ble overført, men detaljer
som materialinformasjon, vindussprosser og glassareal i dører ble ikke overført.
På grunn av gbXML-skjemaets måte å denere soner på kunne ikke søyler lastes
inn i analyseapplikasjonen.
Figur 6.9: Bygningskomponentenes hiearkiske inndeling i IES VE
65
gbXML-skjemaet bruker plan polygongeometri for å representere overatene
i modellen. Dette er en tilnærming og vil ikke gi nøyaktige verdier for all type
geometri. Ut i fra testene som ble utført viste det seg at formatet særlig hadde
problemer med å representere dobbeltkrummede takater, og at dette i visse
tilfeller førte til at taket ikke ble en lukket ate.
6.4 Drøfting av resultatene
Som omtalt i Kapittel 3 kan tap av informasjon skyldes at Revit ikke evner å
konvertere informasjonen riktig til overføringsformatet, at overføringsformatet
ikke evner å representere informasjonen i Revit, eller at analyseapplikasjonen
ikke evner å tolke informasjonen fra overføringsformatet. Ved overføring via
gbXML ble en forhåndsvisning av modellen vist, både ved eksport i Revit og ved
import i IES VE (se Figur 4.4 og 4.10). Ut i fra denne forhåndsvisningen var det
tydelig at problemet med å overføre geometri for dobbeltkrummede tak oppstod
allerede ved eksporteringen fra Revit sitt eget format til gbXML-skjemaet. Som
omtalt i Kapittel 3 er gbXML et overføringsmedium kun tiltenkt kommunikasjon
fra en modelleringsapplikasjon til en analyseapplikasjon, og fungerer forholdsvis
bra til dette formålet. Formatet har dog visse begrensninger (se Kapittel 3) som
fører til at man må tilføre modellen en del informasjon manuelt før man kan
utføre analyser; formatet kan ikke overføre informasjon om materialegenskaper
og har problemer med å fremstille dobbeltkrummede ater (se Figur 6.6).
Ved overføring via IFC var det ingen forhåndsvisning av modellen, verken
ved eksport i Revit, eller ved import i Ecotect Analysis. Det er derfor vanskelig å fastslå hvor i prosessen tap av informasjon forekom. IAI har som mål
at IFC-modellen skal være et overføringsformat som vil gi full interoperabilitet
mellom alle applikasjoner brukt i et byggeprosjekt. Resultatene fra testene utført i tilknytning til denne oppgaven viser at dette foreløpig ikke er tilfelle for
kommunikasjon mellom Revit og Ecotect. Ecotect Analysis sin implementering
av IFC er som nevnt i Kapittel 4 kun på Beta-stadiet, og Ecotect sin evne til å
hente ut informasjon fra en IFC-modell vil trolig bli bedre med tiden. Det er dog
grunnleggende utfordringer med IFC (se Kapittel 3) som tilsier at det vanskelig
vil la seg gjennomføre å oppnå full interoperabilitet med dette formatet.
66
7
Anbefaling til COWI i forhold til BIM
og miljøvurdering
7.1 Situasjonen i dag
Beregning av bygningers energibehov og varmetapstall skal utføres i samsvar
med Norsk Standard NS3031: Beregning av bygninger energiytelse - Metode
og data [Kommunal- og regionaldepartementet, 2010]. Her oppgis det at beregningsprogrammene som skal brukes i tilknytning til disse beregningene skal være
validert etter NS-EN 15265 [Standard Norge, 2007]. Foreløpig er det kun applikasjonene SIMulering av Inneklima og ENergibruk i bygninger (SIMIEN) og
VIP Energy som er validert [Petersen, 2010].
Med andre ord kan verken Ecotect Analysis eller IES VE brukes til å dokumentere energibehov og varmetapstall til et bygg. Analyseapplikasjonene kan
likevel ha en stor nytteverdi i byggeprosjekter ved å være et verktøy for å vurdere ulike designløsninger. Særlig tidlig i prosjektfasen er man tjent med å vurdere
ulike alternativer, og analysene gir et godt grunnlag for å komme frem til de
optimale løsningene.
BIM legger til rette for en raskere og mer nøyaktig prosess for å foreta
analyser, og energianalysene kan bli en mer integrert del av designprosessen.
Det har blitt vist at 50% av tiden det tar å bygge og analysere en energimodell
går med til å gjenskape bygningsgeometri og til å tilføre materialegenskaper
[Krygiel and Nies, 2008]. Å automatisere dette arbeidet åpner opp for å foreta
ere analyser og gir mer tid til å vurdere resultatene, noe som samlet sett gir
et bedre grunnlag for å foreta valg i designprosessen [Krygiel and Nies, 2008].
67
Dette avhenger dog av at applikasjonene er interoperabile.
I sammenheng med denne oppgaven ble kommunikasjonen mellom Revit
Architecture og analyseapplikasjonene Ecotect Analysis og IES VE testet. Informasjonsoverføringen fra Revit Architecture til Ecotect Analysis ble gjort via
IFC-modellen. Informasjonsoverføringen fra Revit Architecture til IES VE ble
gjort via gbXML-skjemaet. Brukeren må denere materialegenskapene til bygningskomponentene selv ved overføring via gbXML-skjemaet, og formatet har
til tider problemer med å representere kompleks geometri. Til tross for disse
svakhetene kom gbXML-skjemaet klart best ut i de ulike testene. Selv om det
kun ble brukt standard elementer i modellen som ble overført via IFC-modellen
gikk mye informasjon tapt. Ved overføring av modeller som inneholder andre
elementer vil informasjonsoverføringen trolig være enda mer utfordrende.
I tillegg til at mindre informasjon gikk tapt ved overføring via gbXMLskjemaet var prosessen med å overføre informasjonen mer oversiktlig. Ved overføring via gbXML-formatet ble modellen illustrert både i Revit under eksport
og i IES VE ved import. Dette gav en intuitiv og oversiktlig måte å oppdage
feil på. Ved overføring via IFC-modellen ble modellene derimot eksportert og
importert i blinde, og man kunne ikke undersøke modellens integritet før den
var lastet inn i Ecotect Analysis. Modellene som ble overført via IFC-modellen
ble svært fordreid, og det var vanskelig å kartlegge hvilken informasjon som var
gått tapt. I en vanlig arbeidssituasjon vil det trolig være mindre tidkrevende å
lage hele modellen direkte i analyseapplikasjonen enn å gå igjennom elementene
overført via IFC for å kartlegge hva som må rettes opp.
Ved valget mellom IFC-modellen og gbXML-skjemaet vil jeg derfor med
bakgrunn i vurderingen av formatene gjort i Kapittel 3 og resultatene fra testene som ble utført anbefale COWI å benytte gbXML-skjemaet for overføring av
informasjon til analyseapplikasjoner. Ved en slik overføringsprosess er det visse
ting man må ta hensyn til; under eksporteringen må man sjekke om det oppstår
noen feilmeldinger, og om det eksisterer noen tomrom i modellen. Særlig er det
viktig å sørge for at egenopprettede elementer er denert ordentlig, slik at disse
blir tolket riktig ved eksporteringen. Hvis modellen inneholder dobbeltkrummede ater bør man kontrollere at disse atene eksporteres korrekt. Hvis ikke
må disse lages på nytt i analyseapplikasjonen. For å redusere risikoen for feil
ved eksport kan det være en fordel å fjerne alle elementer i modellen som ikke
er nødvendige for å foreta analyser. Utenom dette bør de innstillingene som er
beskrevet i Kapittel 5 følges.
Denne oppgaven fokuserte ikke på å vurdere funksjonaliteten og kvaliteten til
analyseapplikasjonene, og siden både Ecotect Analysis og IES VE kan importere
68
gbXML-skjemaer kan begge applikasjonene være aktuelle å bruke for COWI.
Selv om begge applikasjonene kan bruke gbXML-skjemaet vil jeg anbefale COWI
å ta i bruk IES VE. Overføringsprosessen fra Revit Architecture til IES VE var
intuitiv og feil i modellen kom tydelig frem. IES VE har ere analysefunksjoner
enn Ecotect Analysis og kan brukes gjennom hele byggeprosjektet. I tillegg er
det en fordel at man kan bruke IES VE direkte i Revit Architecture for å utføre
analyser ved hjelp av en PlugIn.
7.2 Fremtidig arbeid med BIM og miljøvurdering
I starten av byggeprosjekter deneres et miljøprogram. Hensikten med miljøprogrammet er å få konkretisert miljømålene for prosjektet samt å lage et grunnlag
for hva slags miljøprol man ønsker at bygget skal ha [Marton, 2008]. Målene kan blant annet omfatte byggeprosessen, område- og infrastrukturen og bebyggelsen [Statsbygg, 2010]. Miljøprogrammet sin utarbeidelse baserer seg på
prosjekteierens miljøpolitikk, konsekvensutredningen av prosjektet og oentlige
lover, forskrifter og myndighetskrav som er relevante for prosjektet.
For å nå målene som er denert i miljøprogrammet må løsninger av en rekke
ulike aspekter ved bygget vurderes. Dette inkluderer blant annet trakkgenerering, avfallshåndtering under byggeprosessen, valg av materialer, tekniske installasjoner, energikilder og arkitektonisk utforming. Utfordringene som skal løses
er ofte komplekse, og krever tett samarbeid mellom aktørene i byggeprosjektet.
For eksempel vil en liten detalj som hvilken malingstype som blir brukt påvirke
reeksjonen av solstråler, og dermed ha konsekvenser for energiberegningen fra
solinnstråling.
I en ideell situasjon vil bruken av BIM under byggeprosjektet kunne forenkle
oppgaven med å lage miljøvennlige bygg betraktelig. Den viktigste funksjonen
til BIM er å legge til rette for bedre menneskelig samarbeid i byggebransjen, og
med det bedre resultater. Ved full interoperabilitet kan alle aktørene i byggeprosjektet jobbe samtidig opp mot samme modell. Analyseapplikasjoner kan hente
ut all relevant informasjon, analysere informasjonen og gjøre eventuelle endringer som vil bli reektert i hovedmodellen. Modellen kan være koblet opp mot
databaser fra materialleverandører som inneholder informasjon om kostnad og
Environmental Product Declaration (EPD). Dermed kan man foreta nøyaktige
livsløpsanalyser for å forsvare investeringskostnader. Man får også oversikt over
byggets klimagassutslipp, ikke bare fra driften av bygget, men også fra produksjonen av bygningskomponentene. I tillegg får man en dokumentasjon av hvilke
miljøfarlige stoer som er blitt brukt i bygget, slik at disse blir tatt forsvarlig
69
hånd om når bygget skal rives.
Listen over muligheter er lang, men som omtalt i Kapittel 2 er man avhengig
av full interoperabilitet hvis BIM fullt ut skal komme til sin rett. Utfordringer
knyttet til interoperabilitet har blitt omtalt i Kapittel 3. Full interoperabilitet
mellom applikasjoner ved kommunikasjon via lformater innebærer at alle applikasjonene må kunne importere all informasjonen i len, og i tillegg kunne
eksportere all informasjon til samme format. Å oppnå full interoperabilitet ved
en slik type kommunikasjon har vist seg å være svært utfordrende selv for overføring av enkle tekstdokumenter [Shah and Kesan, 2008], og for informasjon i
en BIM blir oppgaven tilnærmet umulig. Med andre ord er løsningen med å
sende informasjon via gbXML-formatet en midlertidig løsning frem til et bedre
alternativ her blitt utviklet.
Å gå over til kommunikasjonstypen server-klient vil gi store muligheter til
å oppnå full interoperabilitet mellom applikasjoner. Kommunikasjonen mellom
applikasjonene og en database-serveren består av enkle transaksjoner for å hente
ut og putte inn informasjon. Applikasjoner sender spørringer til serveren for å få
den informasjonen som er relevant, og trenger ikke å kunne tolke all informasjon i
den digitale modellen. På grunn av dette er prosessen med å gjøre applikasjonene
interoperabile med serveren langt enklere enn å gjøre applikasjonene direkte
interoperabile med hverandre.
Jeg vil derfor anbefale COWI å gå sammen med resten av byggenæringen for
å påvirke applikasjonsleverandørene til å satse på kommunikasjon via servere.
IFC-modellen kan benyttes ved en slik type kommunikasjon, men som omtalt i
Kapittel 3 støtter IFC kun statiske datastrukturer, og ikke objekter i datateknisk forstand [Howie et al., 1996]. Med andre ord vil ikke IFC-modellen være
et optimalt kommunikasjonsmedium mellom applikasjoner og databaser. Et alternativ å legge til rette for kommunikasjon via servere er bruk av mellomvare.
Denne løsningen er nærmere beskrevet i Kapittel 3. For å utvikle en optimal
løsning for kommunikasjonen via servere er man dog avhengig av at leverandørene gir hverandre innsyn i sine dataaksesslag og forretningslag og sammen blir
enige om grunnprinsipper for hvordan informasjon skal deneres. Dette innebærer at leverandørene vil miste noen av sine konkurransefortrinn, og å få til et
slikt samarbeid kan være utfordrende. Brukervennlighet og funksjonalitet vil bli
desto viktigere faktorer, noe som vil være gunstig for forbrukerne.
70
8
Konklusjon og videre arbeid
8.1 Generelt
Her presenteres konklusjonen for oppgaven og forslag til videre arbeid.
8.2 Konklusjon
Testing av programvare
Formålet med denne masteroppgaven har vært å teste interoperabiliteten mellom modelleringsapplikasjonen Revit Architecture og analyseapplikasjonene Ecotect Analysis og IES VE. IFC-modellen og gbXML-skjemaet ble brukt for å
overføre informasjon fra Revit til henholdsvis Ecotect og IES VE. Før testene
ble utført ble de to overføringsformatene vurdert, og det ble avdekket en rekke
utfordringer:
IFC
•
Full interoperabilitet mellom applikasjoner ved kommunikasjon via IFCmodellen innebærer at alle applikasjonene må kunne importere all informasjonen i len, og i tillegg kunne eksportere all informasjon til samme
format. Å oppnå full interoperabilitet ved en slik type kommunikasjon har
vist seg å være svært utfordrende selv for overføring av enkle tekstdokumenter [Shah and Kesan, 2008], og for informasjon i en BIM blir oppgaven
tilnærmet umulig.
71
•
IFC-modellen skal være et nøytralt format som kan overføre all type bygningsinformasjon mellom alle typer BIM-applikasjoner. Dette krever en
stor generalitet og eksibilitet, noe som kan fører til tvetydighet [Marsh, 2006].
IFC-modellen støtter for eksempel ere ulike måter for å beskrive geometri. Hvis ikke alle applikasjonene vet hvordan denne informasjonen skal
tolkes vil den gå tapt i overføringsprosessen.
•
Modellen er svært omfattende og er derfor svært krevende å implementere
i applikasjoner.
•
Kommunikasjon via IFC-modellen krever re oversettelser, noe som er en
forholdsvis besværlig prosess.
•
IFC-modellen kan brukes for kommunikasjon via en server, men da IFCmodellen kun støtter statiske datastrukturer vil den ikke fungere optimalt
for slik kommunikasjon.
gbXML
•
gbXML-formatet henter kun ut spesikk informasjon relevant for en analyseapplikasjon og gjør forenklinger i informasjonen. Dette er fordelaktig
for analyseprogrammene, da formatet er enkelt å implementere. Slike forenklinger fører dog til at konverteringen ikke er en tapsfri prosess. Overføring via gbXML-formatet er derfor en enveiskommunikasjon fra modelleringsapplikasjonene til analyseapplikasjonene.
•
gbXML-skjemaet representerer geometrien til overater ved hjelp av to
attributter: plan polygongeometri og rektangulær polygongeometri. Kun
rektangulær geometri kan representeres med disse to attributtene og representeringen av krumme ater vil derfor være en tilnærming.
•
gbXML-skjemaet kan ikke overføre informasjon om materialegenskaper
fra Revit Architecture til IES VE og denne informasjonen må legges inn
manuelt.
72
Resultater
A
Ecotect via IFC IES VE via gbXML
Prosjektinformasjon
Lokasjon
Orientering
Bygningstype
Enhetsbenevning
Objekttype
Vindu
Dør
Tak
Gulv
Etasjeskiller
Yttervegg
Innervegg
Søyle
Rominformasjon
Navn
Volum
Plassering
Areal til avgrensende flater
Veggeometri
Plane vegger
Enkeltkrummede vegger
Dobbeltkrummede vegger
Takgeometri
Plane tak
Enkeltkrummede tak
Dobbeltkrummede tak
û
ü
û
û
ü
ü
ü
ü
û
û
ü
ü
û
ü
û
û
ü
ü
ü
ü
ü
ü
ü
û
ü
û
û
ü
ü
ü
ü
ü
ü
û
û
ü
ü
ü
ü
û
û
ü
ü
û
û
û
ü
Materialegenskaper
Materialegenskaper
Figur 8.1: Sammendrag av resultatene fra de utførte testene
Interoperabilitet mellom Revit Architecture og Ecotect Analysis via
IFC
IFC-modeller importert i Ecotect Analysis inneholdt informasjon om modellens
orientering, men inneholdt derimot ikke informasjon om modellen sin lokasjon og
Side 1
bygningstype. Romforekomstene i modellen inneholdt navn og areal til avgrensende ater, men rommenes plassering i forhold til hverandre var blitt endret
og romvolum ble ikke direkte overført. Informasjon om dører og vinduer i de
avgrensende atene ble ikke overført. Alle toppater til rommene ble satt til
objekttypen tak, alle sideater til yttervegg og alle bunnater til gulv. Ingen
informasjon om objektene sine materialegenskaper ble overført. Hvis modellen
som ble overført inneholdt krumme ater ble ingen informasjon lastet inn i
Ecotect.
Resultatene fra testene viser at det foreløpig er store utfordringer knyttet til
overføring av informasjon fra Revit Architecture og Ecotect Analysis via IFC-
73
modellen. Det ble ikke fastslått hvor i overføringsprosessen tap av informasjon
forekom. Ecotect Analysis sin implementering av IFC-modellen er kun på Betastadiet. Ved en forbedring av Ecotect Analysis, Revit Architecture og IFCmodellen vil interoperabiliteten bli bedre, men man er foreløpig langt i fra å
oppnå full interoperabilitet.
Interoperabilitet mellom Revit Architecture og IES VE via gbXML
gbXML-skjemaet er et overføringsmedium kun tiltenkt kommunikasjon fra en
modelleringsapplikasjon til en analyseapplikasjon, og fungerer forholdsvis bra
til dette formålet. gbXML-formatet overførte generell prosjektinformasjon som
lokasjon, orientering og bygningstype til modellen. Romobjekters navn, volum,
overateareal og plassering i forhold til hverandre ble overført. Ut i fra tilstøtende soner som omsluttet hver romsone ble romsonenes overatetyper bestemt.
Vinduer og dører sin arealinformasjon og plassering ble overført, men ikek detaljer som vindussprosser og glassareal i dører. På grunn av gbXML-skjemaet
sin måte å denere soner på kunne ikke søyler tas med i modellene. Ingen informasjon om materialegenskaper ble overført. Ved overføring av modeller som
inneholdt dobbeltkrummede ater ble geometrien ofte unøyaktig, og i visse tilfeller ble ikke dobbeltkrummede takater en lukket ate.
Muligheter for bedre interoperabilitet
Den viktigste funksjonen til BIM er å legge til rette for bedre menneskelig samarbeid i byggebransjen. For å få til et godt samarbeid er man avhengig av
god kommunikasjon [Eikeland, 2000]. Med hensyn til BIM fordrer god kommunikasjon at alle aktørene arbeider opp mot en felles modell. Dette kan gi en
pålitelig informasjonsutveksling, og sikre at alle arbeider med gjeldende modell
[Eastman et al., 2008]. En måte å gjennomføre dette på er ved at alle applikasjonene er koblet sammen via en server som inneholder en database hvor BIM
er lagret.
Kommunikasjon via en database-server reduserer utfordringene tilknyttet
interoperabilitet. Kommunikasjonen mellom applikasjonene og serveren består
av enkle transaksjoner for å hente ut og putte inn informasjon. Applikasjoner
sender spørringer til serveren for å få den informasjonen som er relevant og
trenger ikke å kunne tolke all informasjon i den digitale modellen. På grunn av
dette er prosessen med å gjøre applikasjonene interoperabile med serveren langt
enklere enn å gjøre applikasjonene direkte interoperabile med hverandre.
74
Full interoperabilitet mellom applikasjoner som kommuniserer via en server
avhenger av at applikasjonsleverandørene gir hverandre innsyn i sine dataaksesslag og forretningslag og sammen blir enige om grunnprinsipper for hvordan informasjon skal deneres og overføres. Dette innebærer at leverandørene
vil miste noen av sine konkurransefortrinn og brukervennligheten og funksjonaliteten til applikasjonene vil bli desto viktigere, noe som vil være gunstig
for forbrukerne. Igangsettingen av et slikt samarbeid mellom applikasjonsleverandører avhenger av at aktørene i byggenæringen innser behovet for en slik
kommunikasjonsmåte og at de sammen formidler dette behovet til applikasjonsleverandørene.
Anbefalinger til COWI
Ut ifra de konklusjonene som er gjort i denne masteroppgaven har følgende
anbefalinger blitt gitt til COWI:
•
Ved valget mellom IFC-modellen og gbXML-skjemaet anbefales COWI å
benytte gbXML-skjemaet for overføring av informasjon til analyseapplikasjoner.
•
Ved valget mellom Ecotect Analysis og IES VE anbefales COWI å ta i
bruk IES VE.
•
For å etablere full interoperabilitet ved bruk av BIM anbefales COWI på
det sterkeste å videreformidle behovet for kommunikasjon via databaseservere overfor resten av byggenæringen og leverandørene av applikasjoner
til byggenæringen.
8.3 Videre arbeid
BIM og miljøvennlige bygg
Denne oppgaven har vært konsentrert rundt in-
teroperabilitet mellom modelleringsapplikasjoner og analyseapplikasjoner.
Det vil være nyttig å kartlegge hva slags eekt bruken av BIM i byggeprosjekter har med hensyn på utviklingen av miljøvennlige bygg.
Endring av arbeidsprosessen ved bruk av BIM
I denne oppgaven har det
blitt poengtert at BIM sin viktigste funksjon er å legge til rette for bedre
samarbeid mellom aktørene i et byggeprosjekt. For å gå dypere inn i denne
problemstillingen vil det være behov for å undersøke hvordan aktørene i
75
et byggeprosjekt arbeider og hvordan denne arbeidsprosessen endres ved
bruk av BIM.
Serverbasert kommunikasjon
I denne oppgaven har det blitt konkludert
med at man må gå over til serverbasert kommunikasjon hvis BIM fullt
ut skal komme til sin rett. Det vil her være aktuelt å kartlegge hva slags
teknologi som eksisterer på dette området, hvor godt denne teknologien
fungerer og å vurdere muligheten for videre utvikling.
Kartlegging av interoperabilitetsproblemer
En rekke utfordringer ved in-
teroperabilitet har blitt nevnt i denne oppgaven. Å kartlegge konsekvensene av interoperabilitetsproblemer under byggeprosjekter vil være nyttig
for å rette søkelyset på denne problematikken.
Defenisjon av BIM
I denne oppgaven har det blitt nevnt at det ikke eksiste-
rer en entydig og presis denisjon for hva BIM er. Etableringen av en slik
denisjon vil være gunstig for å identisere grensene og dermed manglene
til BIM og dermed gi et utgangspunkt for målrettet å jobbe for å forbedre
disse manglene.
76
Bibliogra
[Abdalla and Powell, 1995] Abdalla, J. and Powell, G. (1995).
sign framework for structural engineering.
An object de-
Engineering with Computers,
11(4):213226.
[Architosh, 2010] Architosh (2010). 2010 BIM survey full report.
[Autodesk, 2007] Autodesk (2007).
Transitioning to BIM.
Technical report,
Autodesk Inc.
[Autodesk, 2009a] Autodesk (2009a).
Revit 2010 to 2009.
autodesk.com/forums/message.jspa?messageID=6186338.
[Autodesk, 2009b] Autodesk (2009b).
http://discussion.
23.05.10.
Revit Architecture 2010 User's Guide.
[Autodesk, 2010a] Autodesk (2010a). Autodesk revit.
http://www.autodesk.com.
15.05.2010.
[Autodesk, 2010b] Autodesk (2010b).
Ecotect 2011 User's Guide.
[Barnaby et al., 2005] Barnaby, C., Spitler, J., and Xiao, D. (2005). The residential heat balance method for heating and cooling load calculations.
ASH-
RAE Transactions.
[Becla and Wang, 2005] Becla, J. and Wang, D. (2005). Lessons learned from
managing a petabyte. In
Conference on Innovative Data Systems Research,
pages 7083. Citeseer.
[Bourarsa, 2005] Bourarsa, N. (2005). Estimating Energy Use Early and Often.
Public Interest Energy Research, California Energy Commission. CEC-5002005-140-FS.
[buildingSMART, 2010a] buildingSMART (2010a).
iai-tech.org/about-us/?searchterm=modelup.
http://www.
About us.
12.04.10.
[buildingSMART, 2010b] buildingSMART (2010b). Iai tech international.
//www.iai-tech.org.
10.04.10.
[buildingSMART, 2010c] buildingSMART
ses.
http:
(2010c).
Summary
of
ifc
relea-
http://www.iai-tech.org/products/ifc_specification/ifc-releases/summary.
11.04.10.
[Chris I. Yessios, 2004] Chris I. Yessios, P. (2004).
Are we forgetting design?
http://www.aecbytes.com/viewpoint/2004/issue_10.html.
77
16.04.10.
[CIBSE, 1999] CIBSE, E. (1999). CIBSE Guide A.
The Chartered Institution
of Building Services Engineers, London.
[Conradie, 2009] Conradie, D. (2009). Building information modelling (BIM).
Green Building.
[Dong et al., 2007] Dong, B., Lam, K., Huang, Y. C., and Dobbs, G. M. (2007).
A comparative study of the IFC and gbXML informational infrastructures
for data exchange in computational design support environments. In
Simulation 2007,
Building
pages 15301537.
Building product models: computer environments supporting design and construction. CRC.
[Eastman, 1999] Eastman, C. (1999).
[Eastman et al., 2008] Eastman, C., Teicholz, P., Sacks, R., and Liston, K.
BIM Handbook: A guide to building information modeling for owners, managers, designers, engineers, and contractors. John Wiley & Sons
(2008).
Inc.
[Eikeland, 2000] Eikeland, P. (2000). Teoretisk analyse av byggeprosesser.
Sam-
spill i byggeprosessen, prosjektnr. 10602.
[Engelbart, 2003] Engelbart, D. (2003). Improving Our Ability to Improve: A
Call for Investment in a New Future.
IBM Co-Evolution Symposium.
[Frej and Anne, 2005] Frej, A. and Anne, B. (2005).
A practical guide to development.
Green Oce Buildings:
Washington, DC: ULIthe Urban Land
Institute.
[gbXML, 2010] gbXML (2010).
Open green building xml schema: a building
information modeling solution for our green world.
[Graphisoft, 2009] Graphisoft (2009).
http://gbxml.org.
BIM curriculumn.
09.05.10.
Technical report,
Graphisoft Inc.
[Graphisoft, 2010] Graphisoft (2010).
The archicad solution.
graphisoft.com/community/why_switch/the_archicad_solution.html.
http://www.
25.03.10.
[GSA PBS OCA, 2007] GSA PBS OCA (2007). GSA BIM guide overview series
01 section 01: GSA national 3d-4d-BIM program.
Technical report, U.S.
General Services Administration.
[Haefele, 2008] Haefele, K. H. (2008). Basic informations.
org/index.php/Basic_Informations.
http://www.ifcwiki.
07.04.10.
[Hansen, 2006] Hansen, T. B. (2006). Modellering av objektorienterte systemer.
Technical report, Høgskolen i Sør-Trøndelag.
78
[Haraldsen, 1999] Haraldsen, A. (1999).
historien.
Den forunderlige reisen gjennom data-
Tano/Universitetsforlaget.
[Hensen and Radosevic, 2004] Hensen, J. and Radosevic, M. (2004). Teaching
building performance simulation-some quality assurance issues and experiences. In
Proc. Int. Conference on Passive and Lowenergy ArchitecturePLEA,
pages 18.
[Howard and Bjørk, 2008] Howard, R. and Bjørk, B. (2008). Building information modelling - Experts views on standardisation and industry deployment.
Advanced Engineering Informatics,
[Howie et al., 1996] Howie,
C.,
22(2):271280.
Kunz,
J.,
and
Law,
K.
(1996).
Soft-
Stanford University, USA http://www. dacs. dtic.
mil/techs/interop/title. shtml, accessed January, 20:2003.
ware interoperability.
[Idehen, 1993] Idehen, K. (1993).
ODBC technical white paper.
openlinksw.com/info/docs/odbcwhp/tableof.htm.
http://www.
22.05.10.
BIM + Building Performance Analysis Using
Revit 2010 and IES <Virtual Environment>.
[IES VE, 2009] IES VE (2009).
[IES VE, 2010] IES VE (2010).
IES VE User's Guide.
[ISO, 2010] ISO
184/sc
(2010).
Tc
http://www.iso.org/iso/standards_
4.
development/technical_committees/other_bodies/iso_technical_committee.htm?
commid=54158.
08.04.10.
[Jongeling, 2008] Jongeling, R. (2008). BIM istället för 2D-CAD i byggprojekt.
Technical report, Civil and Environmental Engineering, Luleå University of
Technology, Luleå, Sweden.
[Kalstveit, 1997] Kalstveit, E. (1997).
gen.
Digitale Produktmodeller i byggenærin-
PhD thesis, NTNU, Institutt for konstruksjonsteknikk.
of )
NIST Special Publication 939, National Institute of Standards and Technology, Gaithersburg, MD, 1999.
[Kemmerer, 1999] Kemmerer, S. (1999).
STEP: The grand experience.
[Kennedy, 2010] Kennedy, J. F., editor (2010).
Green Building XML: Enabling
disruptive technologies today!
[Khemlani, 2004] Khemlani, L. (2004). The ifc building model: A look under
the hood.
http://www.aecbytes.com/feature/2004/IFCmodel.html.
79
08.05.10.
[Kommunal- og regionaldepartementet, 2009] Kommunal- og regionaldeparte-
Bygg for framtida. Miljøhandlingsplan for bolig- og byggsektoren 2009 2012. Grøset.
mentet (2009).
[Kommunal- og regionaldepartementet, 2010] Kommunal- og regionaldepartementet (2010).
skrift).
Forskrift om tekniske krav til byggverk (byggteknisk for-
http://www.lovdata.no/cgi-wift/ldles?doc=/sf/sf/sf-20100326-0489.html.
12.06.10.
[Krakowiak, 2003] Krakowiak, S. (2003).
What is middleware.
This is an
electronic document. Date of publication: January.
[Krygiel and Nies, 2008] Krygiel, E. and Nies, B. (2008).
Green BIM: Successful
sustainable design with building information modeling.
[Laiserin, 2002] Laiserin, J. (2002).
Wiley.
Comparing pommes and naranjas.
//www.laiserin.com/features/issue15/feature01.php.
http:
13.03.10.
[Liebich and Wix, 2000] Liebich, T. and Wix, J. (2000). IFC Technical Guide.
International Alliance for Interoperability.
[Marsh, 2006] Marsh, D. A. J. (2006). Cad geometry vs performance analysis.
Natural Frequency.
[Marton, 2008] Marton, I. (2008). Miljø i byggeprosessen.
no/.
http://www.byggemiljo.
12.06.10.
[MSG, 2010] MSG (2010).
IFC documentation.
IFC2x4/beta3/html/index.htm.
http://www.iai-tech.org/ifc/
08.05.10.
[Norconsult, 2010] Norconsult (2010). BIM-kalkyle med Informasjonssystemer
(ISY) calcus.
http://www.nois.no/?aid=9099171.
[OpenSpirit, 2010] OpenSpirit (2010).
in the digital oileld.
26.03.10.
Enabling cross-discipline collaboration
http://www.openspirit.com/.
23.05.10.
[Oracle Corporation, 2010] Oracle Corporation (2010). Many technologies, one
platform.
http://java.sun.com/javase/technologies/database/.
10.05.10.
[Petersen, 2010] Petersen, A. (2010). BIM i Energi- og klimaberegninger.
[Seletsky, 2004] Seletsky, P. (2004). Goodbye cad. goodbye bim. hello pen.
//www.aecbytes.com/viewpoint/2004/issue_3.html.
http:
16.04.10.
[Shah and Kesan, 2008] Shah, R. and Kesan, J. (2008).
Lost in Translation:
Interoperability Issues for Open StandardsODF and OOXML as Examples.
University of Illinois Legal Working Paper Series,
80
page 97.
[Simensen, 2010] Simensen, K. H. (2010). Informasjon om openspirit. Samtale
med tidligere programmerer for Schlumberger.
[Standard Norge, 2007] Standard Norge (2007).
NS 3031:2007 Beregning av
bygningers energiytelse Metode og data. Technical report, Standard Norge.
[Statsbygg, 2010] Statsbygg
miljoprogrammering.no/.
(2010).
Miljøprogram.
http://www.
12.06.10.
[Svendsen, 2007] Svendsen, P. A. (2007). Eu knuser windows-monopolet.
//www.nrk.no/nyheter/okonomi/1.3486728.
http:
22.05.10.
[Syvertsen, 2009] Syvertsen, T. G. (2009). TKT4505 Objektmodellering. Forelesning.
[Wikipedia, 2010] Wikipedia (2010).
Top-down and bottom-up design.
//en.wikipedia.org/wiki/Top-down_and_bottom-up_design.
[Yudelson, 2008] Yudelson, J. (2008).
http:
15.05.2010.
Green building through integrated design.
McGraw-Hill Professional.
81
Vedlegg
82
A Eksempel på hvordan attributter arves i IFC
ENTITY IfcBeam
SUBTYPE OF (IfcBuildingElement);
END_ENTITY;
ENTITY IfcBeam;
ENTITY IfcRoot;
GlobalId
:
OwnerHistory
:
Name
:
Description
:
ENTITY IfcObjectDefinition;
INVERSE
HasAssignments
:
IsDecomposedBy
:
Decomposes
:
HasAssociations
:
ENTITY IfcObject;
ObjectType
:
INVERSE
IsDefinedBy
:
ENTITY IfcProduct;
ObjectPlacement
:
Representation
:
INVERSE
ReferencedBy
:
ENTITY IfcElement;
Tag
:
INVERSE
HasStructuralMember
:
FillsVoids
:
ConnectedTo
:
HasCoverings
:
HasProjections
:
ReferencedInStructures :
HasPorts
:
HasOpenings
:
IsConnectionRealization :
ProvidesBoundaries
:
ConnectedFrom
:
ContainedInStructure
:
ENTITY IfcBuildingElement;
ENTITY IfcBeam;
END_ENTITY;
IfcGloballyUniqueId;
IfcOwnerHistory;
OPTIONAL IfcLabel;
OPTIONAL IfcText;
SET OF IfcRelAssigns FOR RelatedObjects;
SET OF IfcRelDecomposes FOR RelatingObject;
SET [0:1] OF IfcRelDecomposes FOR RelatedObjects;
SET OF IfcRelAssociates FOR RelatedObjects;
OPTIONAL IfcLabel;
SET OF IfcRelDefines FOR RelatedObjects;
OPTIONAL IfcObjectPlacement;
OPTIONAL IfcProductRepresentation;
SET OF IfcRelAssignsToProduct FOR RelatingProduct;
OPTIONAL IfcIdentifier;
SET OF IfcRelConnectsStructuralElement FOR RelatingElement;
SET [0:1] OF IfcRelFillsElement FOR RelatedBuildingElement;
SET OF IfcRelConnectsElements FOR RelatingElement;
SET OF IfcRelCoversBldgElements FOR RelatingBuildingElement;
SET OF IfcRelProjectsElement FOR RelatingElement;
SET OF IfcRelReferencedInSpatialStructure FOR RelatedElements;
SET OF IfcRelConnectsPortToElement FOR RelatedElement;
SET OF IfcRelVoidsElement FOR RelatingBuildingElement;
SET OF IfcRelConnectsWithRealizingElements FOR RealizingElemen
SET OF IfcRelSpaceBoundary FOR RelatedBuildingElement;
SET OF IfcRelConnectsElements FOR RelatedElement;
SET [0:1] OF IfcRelContainedInSpatialStructure FOR RelatedElements
Figur A.1: Arv av attributter for IFC BEAM
83
B Eksempel på oppbygningen av et gbXML-element
Eksempel på oppbygning av gbXML-element
<gbXML>
<Campus>
<Surface id="su1" surfaceType="ExteriorWall">
<AdjacentSpaceId spaceIdRef="sp1" />
<RectangularGeometry>
<Azimuth>0</Azimuth>
<CartesianPoint>
<Coordinate>2224</Coordinate>
<Coordinate>1529.75</Coordinate>
<Coordinate>4</Coordinate>
</CartesianPoint> <Tilt>90</Tilt>
<Height>96</Height>
<Width>42.81</Width>
</RectangularGeometry>
<PlanarGeometry>
<PolyLoop>
<CartesianPoint>
<Coordinate>2224</Coordinate>
<Coordinate>1529.75</Coordinate>
<Coordinate>4</Coordinate>
</CartesianPoint>
</PolyLoop>
</PlanarGeometry>
</Surface>
</Campus>
</gbXML>
Figur B.1: Oppbygning av Exterior Wall i gbXML
84
C Import- og eksportevne til programvare
Autodesk Revit
Import
AutoCAD DWG Files
AutoCAD DXF Files
Industry Foundation Classes
Autodesk Revit Files
Autodesk Revit Files
*.DWG
*.DXF
*.IFC
*.RVT
*.RFA
Figur C.1: Autodesk Revit 2011 Importevne [Autodesk, 2010a]
Eksport
AutoCAD DWG Files
AutoCAD DXF Files
AutoCAD DGN Files
ACIS CAD Files
Autodesk Design Web Format
Autodesk Design Web Format
Autodesk FBX Files
Industry Foundation Classes
Green Building XML
Autodesk Revit Files
Autodesk Revit Files
*.DWG
*.DXF
*.DGN
*.SAT
*.DWF
*.DWFx
*.FBX
*.IFC
*.XML
*.RVT
*.RFA
Figur C.2: Autodesk Revit 2011 Eksportevne [Autodesk, 2010a]
85
Autodesk Ecotect
Import
ASCII Model Files
Analysis grid Data Files
Ray/Particle Data Files
Weather data files
Radiance Point Value data
Radiance Scene Files
EnergyPlus Input data File
Energy Plus Model summary
AutoCAD DXF Files
Stereo lithography file
Green Building XML
Industry Foundation Classes
Google KML Data
HPGL Plot Files
Material Library Files
CFD Output Data File
Windows Bitmap
JPEG Image
*.MOD
*.GRD
*.RAY
*.WEA
*.DAT
*.RAD
*.IDF
*.EIO
*.DXF
*.STL
*.XML
*.IFC
*.KML/KMZ
*.PLT og *.HGL
*.LIB
*.*
*.BMP
*.JPG
Figur C.3: Model/Analysis Data [Autodesk, 2010a]
86
DXF
DXF Point Cloud
IFF to 3D
IFF to DEM
Imagine
Lightscape
Lightwave
Maya RTG
MaxNC Digital probe
MicroDEM
Open Inventor
RealiMation
Renderware
Scenery animator
Sculpt
Shopbot Digital Probe
SoftimageXSI
StereoLithography
trueSpace
USGS GTOPO30/SRTM30
USGS 1 degree DEM
USGS SDTS
USGS SRTM-1/SRTM-3
Videoscape
VistaPro
VRML
Wavefront
X3D
XGL, ZGL
XYZ
XYZ (No Mesh)
*.DXF
*.DXF
*.IFF
*.IFF
*.IOB
*.LP
*.LWO
*.RTG
*.TXT
*.DEM
*.IV
*.RBS
*.RWX
*.LAND
*.SCENE
*.SBP
*.XSI
*.STL
.COB og *.COA
*.DEM
*.DEM
*.DDF
*.HGT
*.GEO
*.DEM
*.WRL
*.OBJ
*.X3D
*.XGL og *.ZGL
*.XYZ
*.XYZ
Figur C.4: 3D CAD Geometry [Autodesk, 2010a]
87
Eksport
ASCII Model Files
Ray/Particle Data Files
Analysis grid Data Files
Material Library Files
*.MOD
*.RAY
*.GRD
*.LIB
Figur C.5: Model/Analysis Data [Autodesk, 2010a]
Radiance Scene Files
Radiance Octree Files
POV Ray Scene files
VRML Scene files
AutoCAD DXF Files
EnergyPlus Input data File
DOE-2 Input Files
SBEM Input Files
AIOLOS Input Files
HTB2 Files
Accurate Scratch file
ESP-r input File
WinAir4 CFD Geometry File
NIST FDS Input data File
Green Building XML
*.RAD
*.OCT
*.POV
*.WRL
*.DXF
*.IDF
*.INP
*.INP
*.PPA
*.TOP
*.*
*.CFG
*.GEO
*.fds
*.XML
Figur C.6: External Analysis Tool [Autodesk, 2010a]
Windows metafile
Windows bitmap
Graphics Interchange Format
JPEG Image
*.WMF
*.BMP
*.GIF
*.JPG
Figur C.7: Image/Screenshot [Autodesk, 2010a]
88
IES VE
Import
Geometry File
Green Building XML
*.GEM
*.XML
Figur C.8: IES VE Importevne [IES VE, 2010]
Eksport
Geometry File
3D System ASCII File
AutoCAD DXF Files
*.GEM
*.STL
*.DXF
Figur C.9: IES VE Eksportevne [IES VE, 2010]
89
D gbXML-elementer og -attributter som støttes
av Revit Architecture 2011
gbXML Element
Figur D.10: gbXML Element [Autodesk, 2009b]
Campus Element
Figur D.11: Campus Element [Autodesk, 2009b]
90
DocumentHistory Element
Figur D.12: DocumentHistory Element [Autodesk, 2009b]
Location Element
Figur D.13: Location Element [Autodesk, 2009b]
Building Element
Figur D.14: Building Element [Autodesk, 2009b]
91
Space Element
Figur D.15: Space Element [Autodesk, 2009b]
ShellGeometry Element
Figur D.16: ShellGeometry Element [Autodesk, 2009b]
92
SpaceBoundary Element
Figur D.17: SpaceBoundary Element [Autodesk, 2009b]
93
Surface Element
Figur D.18: Surface Element [Autodesk, 2009b]
94
Opening Element
Figur D.19: Opening Element [Autodesk, 2009b]
95
E IFC-avbildingsl
Category
1
Air Terminals
Area Polylines
Area Tags
Areas
Areas
Areas
Areas
Boundary Conditions
Cable Tray Fittings
Cable Tray Fittings
Cable Trays
Cable Trays
Cable Trays
Cable Trays
Callouts
Casework
Casework
Casework Tags
Ceiling Tags
Ceilings
Ceilings
Ceilings
Ceilings
Ceilings
Ceilings
Ceilings
Ceilings
Ceilings
Ceilings
Ceilings
Color Fill
Color Fill Legends
Columns
Columns
Communication Devices
Conduit Fittings
Conduit Fittings
Conduits
Conduits
Conduits
Conduits
Constraints
Contour Labels
Curtain Panel Tags
Curtain Panels
Curtain Panels
Curtain Panels
Curtain Panels
Curtain Systems
Curtain Systems
Curtain Systems
Curtain Wall Mullions
Curtain Wall Mullions
Data Devices
Subcategory
IFC Class Name
Not Exported
IfcAirTerminal
IfcPolyline
Not Exported
IfcSpace
Type
Color Fill
Interior Fill
Reference
Not Exported
IFCCableTrayFitting
Center line
IFCCableTraySegment
Center line
Drop
Rise
Not Exported
IfcFurniture
Hidden Lines
IfcContextDependentUnit
IfcContextDependentUnit
IfcCovering
Common Edges
Cut Pattern
Finish 1 [4]
Finish 2 [5]
Hidden Lines
Membrane Layer
Structure [1]
Substrate [2]
Surface Pattern
Thermal/Air Layer [3]
IfcCovering
Not Exported
Not Exported
IfcColumn
Hidden Lines
IfcBuildingElementProxy
IFCConduitFitting
Center line
IFCConduitSegment
Center line
Drop
Rise
IfcConstraint
Not Exported
Not Exported
IfcCurtainWall
Glass
Hidden Lines
Panel Material 1
Not Exported
Not Exported
Not Exported
IfcCurtainWall
Curtain System Grids
Hidden Lines
Hidden Lines
IfcBuildingElementProxy
96
IfcLabel
IfcLabel
Demolished
Detail Items
Detail Items
Detail Items
Detail Items
Detail Items
Dimensions
Dimensions
Door Tags
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Doors
Duct Accessories
Duct Fittings
Duct Fittings
Duct Fittings
Duct Fittings
Ducts
Ducts
Ducts
Ducts
Ducts
Ducts
Electrical Equipment
Electrical Equipment
Electrical Equipment Tags
Electrical Fixture Tags
Not Exported
IfcAnnotation
Heavy Lines
Hidden Lines
Light Lines
Medium Lines
Automatic Sketch Dimensions
bovenlicht
Breakout
Door Jamb
Door Trim-Hor
Door Trim-Vert
Door-Angle-1
Door-Angle-2
Door-Garage-Panel
Door-Int. Trim-Hor.
Door-Int. Trim-Vert.
Door-Jamb
Door-Panels
Door-Rail
Door-Style
Door-Track
draairichting binnenzijde
draairichting buitnzijde
draairichting plattegrond
Elevation Swing
Frame/Mullion
Glass
Hardware
Hidden Lines
Metal Frame
Moulding/Architrave
Opening
Panel
Plan Swing
plint
Threshold
wood panel
Not Exported
Not Exported
IfcContextDependentUnit
IfcDoor
IfcDoor
IfcDoor
IfcDoor
IfcDoor
IfcBuildingElementProxy
IfcDuctFitting
Center line
Insulation
Lining
IfcDuctSegment
Center line
Drop
Insulation
Lining
Rise
IfcBuildingElementProxy
Hidden Lines
Not Exported
Not Exported
97
IfcLabel
Electrical Fixtures
Electrical Fixtures
Elevations
Entourage
Entourage
Existing
Filled region
Fire Alarm Devices
Flex Ducts
Flex Ducts
Flex Ducts
Flex Ducts
Flex Pipes
Flex Pipes
Flex Pipes
Flex Pipes
Floors
Floors
Floors
Floors
Floors
Floors
Floors
Floors
Floors
Floors
Floors
Floors
Floors
Floors
Furniture
Furniture
Furniture
Furniture Systems
Furniture Systems
Generic Annotations
Generic Model Tags
Generic Models
Generic Models
Generic Models
Generic Models
Grids
Guide Grid
HVAC Zones
HVAC Zones
HVAC Zones
HVAC Zones
HVAC Zones
Imports in Families
Levels
Lighting Devices
Lighting Fixture Tags
Lighting Fixtures
Lighting Fixtures
Lighting Fixtures
Lines
IfcBuildingElementProxy
Hidden Lines
Not Exported
IfcBuildingElementProxy
Hidden Lines
Not Exported
IfcAnnotation
IfcBuildingElementProxy
IfcDuctSegment
Center line
Insulation
Pattern
IfcPipeSegment
Center Line
Insulation
Pattern
IfcSlab
Analytical Model
Common Edges
Cut Pattern
Finish 1 [4]
Finish 2 [5]
Hidden Lines
Interior Edges
Membrane Layer
Slab Edges
Structure [1]
Substrate [2]
Surface Pattern
Thermal/Air Layer [3]
IfcBuildingElementProxy
IfcSlab
IfcFurniture
Hidden Lines
Overhead Lines
IfcSystemFurnitureElement
Hidden Lines
Not Exported
Not Exported
IfcBuildingElementProxy
Hidden Lines
IfcOpeningElements
Overhead
IfcOpeningElement
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
IfcBuildingStorey
IfcBuildingElementProxy
Not Exported
IfcLightFixtureType
Boundary
Color Fill
Interior Fill
Reference Lines
Hidden Lines
Light Source
IfcAnnotation
98
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Lines
Mass
Mass
Mass
Mass
Mass
Mass
Mass
Mass
Massing
Mechanical Equipment
Mechanical Equipment
Mechanical Equipment Tags
Multi-Category Tags
New
Nurse Call Devices
Panel Schedule Graphics
Parking
Parking
Parking
Parking
Parking
Parking Tags
Pipe Accessories
Pipe Fittings
Pipe Fittings
Pipe Fittings
Pipes
Pipes
Pipes
Pipes
Pipes
Plan Region
Planting
Planting
Planting Tags
<Area Boundary>
<Beyond>
<Centerline>
<Demolished>
<Hidden>
<Overhead>
<Revision Cloud>
<Room Separation>
<Sketch>
<Space Separation>
<Stair/Ramp Sketch: Boundary>
Stair/RampSketch:LandingCenter
<Stair/Ramp Sketch: Riser>
<Stair/Ramp Sketch: Run>
Axis of Rotation
Hidden Lines
Insulation Batting Lines
Lines
Medium Lines
Thin Lines
Wide Lines
Form
Gridlines
Hidden Lines
Mass Floor
Nodes
Pattern Fill
Pattern Lines
IfcAnnotation
IfcAnnotation
Not Exported
IfcAnnotation
IfcAnnotation
IfcAnnotation
IfcAnnotation
IfcAnnotation
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
IfcAnnotation
IfcAnnotation
IfcAnnotation
IfcAnnotation
IfcAnnotation
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
IfcBuildingElementProxy
IfcBuildingElementProxy
Hidden Lines
Not Exported
Not Exported
Not Exported
IfcSwitchingDeviceType
Not Exported
IfcBuildingElementProxy
Hidden Lines
Parking Layout
Reference Line
Stripe
Not Exported
IfcValveType
IfcPipeFitting
Center line
Insulation
IfcPipeSegment
Center Line
Drop
Insulation
Rise
Not Exported
IfcBuildingElementProxy
Hidden Lines
Not Exported
99
Plumbing Fixture Tags
Plumbing Fixtures
Plumbing Fixtures
Property Line Segment Tags
Property Tags
Railing Tags
Railings
Railings
Railings
Railings
Railings
Ramps
Ramps
Ramps
Ramps
Ramps
Ramps
Ramps
Ramps
Ramps
Ramps
Raster Images
Reference Planes
Roads
Roads
Roof Tags
Roofs
Roofs
Roofs
Roofs
Roofs
Roofs
Roofs
Roofs
Roofs
Roofs
Roofs
Roofs
Roofs
Roofs
Roofs
Roofs
Room Polylines
Room Tags
Rooms
Rooms
Rooms
Rooms
Ruled Curtain System
Schedule Graphics
Scope Boxes
Sections
Security Devices
Shaft Openings
Shaft Openings
Site
Not Exported
IfcBuildingElementProxy
Hidden Lines
Balusters
Hidden Lines
Railings Beyond Cut Line
Rails
Down Arrow
DOWN text
Hidden Lines
Incomplete ramps
Ramps Beyond Cut Line
Stringers
Stringers Beyond Cut Line
Up Arrow
UP text
Not Exported
IfcContextDependentUnit
Not Exported
IfcRailing
IfcRailing
IfcLabel
IfcRailing
IfcRailing
IfcRamp
IfcRamp
IfcRamp
IfcRamp
IfcRamp
IfcRamp
IfcRamp
IfcRamp
IfcRamp
Not Exported
Not Exported
IfcBuildingElementProxy
Hidden Lines
IfcContextDependentUnit
IfcRoof
Common Edges
Curtain Roof Grids
Cut Pattern
Fascias
Finish 1 [4]
Finish 2 [5]
Gutters
Hidden Lines
Interior Edges
Membrane Layer
Roof Soffits
Structure [1]
Substrate [2]
Surface Pattern
Thermal/Air Layer [3]
IfcLabel
IfcRoof
IfcRoof
IfcRoof
IfcRoof
IfcRoof
IfcPolyline
IfcContextDependentUnit
IfcSpace
Color Fill
Interior Fill
Reference
IfcCurtainWall
Not Exported
Not Exported
Not Exported
IfcBuildingElementProxy
Not Exported
Not Exported
IfcSite
Hidden Lines
100
IfcLabel
Site
Site
Site
Site
Site
Site
Site
Site
Site Tags
Spaces
Spaces
Spaces
Spaces
Specialty Equipment
Specialty Equipment
Specialty Equipment Tags
Spot Coordinates
Spot Elevations
Spot Slopes
Sprinklers
Stair Tags
Stairs
Stairs
Stairs
Stairs
Stairs
Stairs
Stairs
Stairs
Stairs
Stairs
StructuralAreaReinforcement
StructuralAreaReinforcement
Structural Beam Systems
Structural Beam Systems
Structural Column Tags
Structural Columns
Structural Columns
Structural Columns
Structural Columns
Structural Columns
Structural Columns
Structural Connections
Structural Foundation Tags
Structural Foundations
Structural Foundations
Structural Foundations
Structural Framing
Structural Framing
Structural Framing
Structural Framing
Structural Framing
Structural Framing
Structural Framing
Structural Framing
Structural Framing
Hidden Lines
Pads
Parking Layout
Project Base Point
Property
Property Lines
Stripe
Survey Point
IfcSlab
Not Exported
IfcBuildingElementProxy
Not Exported
IfcContextDependentUnit
Not Exported
Not Exported
Not Exported
Not Exported
IfcBuildingElementProxy
Color Fill
Interior
Reference
IfcLabel
Hidden Lines
Down Arrow
DOWN Text
Hidden Lines
Incomplete Stairs
Stairs Beyond Cut Line
Stringers
Stringers Beyond Cut Line
Up Arrow
UP Text
Boundary
Hidden Lines
Not Exported
Not Exported
Not Exported
Not Exported
IfcFireSuppressionTerminalType
Not Exported
IfcStair
IfcStair
IfcStair
IfcStair
IfcStair
IfcStair
IfcStair
IfcStair
IfcStair
Not Exported
Not Exported
Not Exported
Not Exported
IfcContextDependentUnit
IfcColumn
Analytical Model
Hidden Faces
Hidden Lines
Rigid Links
Stick Symbols
Not Exported
Not Exported
IfcFooting
Analytical Model
Hidden Lines
IfcBuildingElementProxy
Analytical Model
Chord
Girder
Hidden Faces
Hidden Lines
Horizontal Bracing
Joist
Kicker Bracing
101
IfcLabel
Structural Framing
Other
Structural Framing
Purlin
Structural Framing
Rigid Links
Structural Framing
Stick Symbols
Structural Framing
Vertical Bracing
Structural Framing
Web
Structural Framing Tags
Structural Internal Loads
Structural Internal Loads
Internal Area Loads
Structural Internal Loads
Internal Line Loads
Structural Internal Loads
Internal Point Loads
Structural Load Cases
Structural Load Cases
Accidental Loads
Structural Load Cases
Dead Loads
Structural Load Cases
Live Loads
Structural Load Cases
Roof Live Loads
Structural Load Cases
Seismic Loads
Structural Load Cases
Snow Loads
Structural Load Cases
Temperature Loads
Structural Load Cases
Wind Loads
Structural Loads
Structural Loads
Area Loads
Structural Loads
Line Loads
Structural Loads
Point Loads
Structural Path Reinforcement
Structural Path ReinforcementBoundary
Structural Rebar
Structural Stiffener Tags
Structural Stiffeners
Structural Truss Tags
Structural Trusses
Structural Trusses
Stick Symbols
Telephone Devices
Temporary
Text Notes
Title Blocks
Title Blocks
Medium Lines
Title Blocks
Thin Lines
Title Blocks
Wide Lines
Topography
Topography
Boundary Point
Topography
Hidden Lines
Topography
Interior Point
Topography
Primary Contours
Topography
Secondary Contours
Topography
Triangulation Edges
View Titles
Wall Tags
Walls
Walls
Analytical Model
Walls
Common Edges
Walls
Curtain Wall Grids
Walls
Cut Pattern
Walls
Finish 1 [4]
Walls
Finish 2 [5]
Walls
Hidden Lines
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
Not Exported
IfcBuildingElementProxy
Not Exported
IfcAnnotation
Not Exported
Not Exported
Not Exported
Not Exported
IfcBuildingElementProxy
IfcBuildingElementProxy
IfcBuildingElementProxy
IfcBuildingElementProxy
IfcBuildingElementProxy
IfcBuildingElementProxy
Not Exported
IfcContextDependentUnit
IfcWall
IfcWall
102
IfcLabel
Walls
Walls
Walls
Walls
Walls
Walls
Walls
Walls
Walls/Interior:1
Walls/Exterior:2
Walls/Foundation:3
Walls/Retaining:4
Window Tags
Windows
Windows
Windows
Windows
Windows
Windows
Windows
Windows
Windows
Windows
Windows
Wires
Wires
Wires
Membrane Layer
Reveals
Stacked Walls
Structure [1]
Substrate [2]
Surface Pattern
Thermal/Air Layer [3]
Wall Sweeps
draairichting binnen
Elevation Swing
Frame/Mullion
Glass
Hidden Lines
Moulding
Opening
Plan Swing
Sill/Head
Trim
IfcOpeningElement
IfcWall
IfcWall
IfcBuildingElementProxy
IfcWall
IfcWall
IfcWall
IfcWall
IfcContextDependentUnit
IfcWindow
IfcWindow
IfcWindow
IfcWindow
IfcWindow
Not Exported
Not Exported
Not Exported
Home Run Arrows
Wire Tick Marks
Figur E.20: IFC-avbildingsl
103
IfcLabel
F Resultater fra Test 1
Lokasjon
Orientering
Bygningstype
Enhet
Revit Architecture
Ecotect Analysis
Latiture:60.8° Longitude:10.7° Latitude:-32° Longitude:116°
45° West of Project North
0°
Hospital
--Metric System
Imperial System
Figur F.21: Resultater fra Test 1
104
IES VE
Latiture:60.8° Longitude:10.7°
0°
Hospital
Metric System
G Resultater fra Test 2
A
IES VE
Revit
Ecotect
Rom 1
Navn
Dining
Dining
Dining
Volum
1005,28
0
1005,28
Grunnflate
251,32
251,32
251,32
Yttervegg
208,656
301,463
208,656
Utvendig Dør
2,6
0
2,6
Utvendig Vindu
11,144
--11,144
Innervegg
92,807
--92,807
Innvendig Dør
2,6
0
2,6
Innvendig Vindu
1,393
--1,393
Tak
0
0
0
Gulv
251,32
251,32
251,32
Etasjeskille
251,32
0
251,32
Rom 2
Navn
Family Study Family Study
Volum
585
0
585
Grunnflate
146,25
146,25
146,25
Yttervegg
96,8
189,607
96,8
Utvendig Dør
0
0
0
Utvendig Vindu
0
--0
Innervegg
92,807
--92,807
Innvendig Dør
2,6
0
2,6
Innvendig Vindu
1,393
--1,393
Tak
0
0
0
Gulv
146,25
146,25
146,25
Etasjeskille
146,25
0
146,25
Navn
Bedroom 3
Bedroom 3
Bedroom 3
Volum
1616
0
1616
Grunnflate
400,02
400,02
400,02
Yttervegg
242,524
242,524
242,524
Utvendig Dør
0
0
0
Utvendig Vindu
79,074
79,074
79,074
Innervegg
0
0
0
Innvendig Dør
0
0
0
Innvendig Vindu
0
0
0
Tak
400,02
400,02
400,02
Gulv
0
0
0
Etasjeskille
400,02
0
400,02
Figur G.22: Resultater fra Test 2
105
Side 1
SUM
1etg
Gulv
Tak
Yttervegg
397,57
397,57
319,2
400,02
397,57
400,02