Klik her for at hente i pdf. - BygningsInformatiker.dk

20. december 

2011 

2 

UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ 

Forord 

Dette semesterprojekt – ”Hvordan skaber man en optimal udvekslingsproces i et modelbaseret 

miljø”, er udarbejdet på Aalborg Universitet i perioden 2. september 2011 til den 20. december 

2011, svarende til 15 ECTS point. 

Baggrunden for semesterprojektet tilblivelse, kommer af en undren over byggebranchens manglende 

vilje/evne til at omstille sig til de nye teknologier. Det gælder både de nye tekniske muligheder, 

men også de nye processer. 

Semesterprojektet er skrevet på dansk. De engelske betegnelser er i så bredt et omfang, som 

muligt, blevet beholdt for at undgå at skabe forvirring omkring de tekniske begreber. 

Det har været et meget lærerigt projekt, og vi vil gerne takke Associate Prof. Kjeld Svidt for sit 

store engagement, vejledning og informative diskussioner. Udover kyndig vejledning fra Associate 

Prof. Kjeld Svidt, har vi også fået inspiration og hjælp fra Tekn. Dr. Per Christiansson Ing. Byrå 

HB (tidligere Associate Professor for Lund Universitet og Aalborg Universitet) . 

Derudover vil vi gerne takke Niras A/S, Rambøll A/S og Friis & Moltke for at stille et projekt samt 

vidensdeling til rådighed for, at vi har kunnet undersøge udvekslingsprocesserne i et modelbaseret 

miljø omkring Musikkens Hus. Samt University College, programmerings studerende Ronni 

Hansen, for bistand under udvikling af vores løsningsforslag. 

Rapporten henvender sig til folk inden for byggebranchen, med en byggeteknisk viden og som har 

interesse i at optimere byggeprocessen, ved hjælp af digitalisering i byggeriet. 

Rapporten er udarbejdet af gruppe 2, bestående af Lasse Bønnerup, Jacob Wassard Andersen, 

Thomas Dragsbæk, Ole Breiner Siig og Peter Gade. 

Lasse Bønnerup 

Thomas Dragsbæk 

Ole Breiner Siig 

Peter Gade 

Jacob Wassard Andersen


20. december 

2011 

Resume 

Dette semesterprojekt er udarbejdet i forbindelse med 2. semester på Aalborg Universitets uddannelse 

i Bygningsinformatik, kaldet Cand. Scient. Techn. i byggeri og anlæg med speciale i bygningsinformatik. 

Semesterprojektet har til formål at gøre læseren opmærksom på de problemstillinger der er i 

byggeriet omkring en mere effektiv udveksling af informationer. 

Grundlaget for at arbejde med emnet – ”Hvordan man skaber en optimal udvekslingsproces i et 

modelbaseret miljø” - har været organisationen BuildingSMARTs arbejde med åbne standarder. 

Deres standarder som Industry Foundation Classes (IFC), Information Delivery Manual (IDM) og 

International Framework for Dictonaries (IFD), har vi forsøgt at gøre mere håndgribelig, ved at 

beskrive værktøjerne i en sammenhæng med resten af byggeprocessen og de danske forhold. 

For at få en mere realistisk reference, har vi fået udleveret casen, Musikkens Hus i Aalborg. Vi har 

taget udgangspunkt i Musikkens Hus, når vi har draget relationer til virkeligheden. 

Vi har opdelt semesterprojektet i tre generelle hovedafsnit. Første afsnit omhandler Musikkens 

Hus, og de involverede parter. Anden del omhandler teori bag en effektiv udveksling af informationer 

i et modelbaseret miljø. Tredje afsnit omhandler det praktiske aspekt, hvilket omhandler 

udvekslingsforsøg og et løsningsforslag. Løsningsforslaget indeholder en konceptuel model over 

hvordan nogle af de koncepter organisationen BuildingSMART har fremsat i et nutidigt miljø. 

Afslutningsvis formulerer vi en konklusion og perspektivering, hvor vi prøver at svare på vores 

problemformulering. 

3

20. december 

2011 

4 


Abstract 

This semester report has been made in connection with the second semester at Aalborg Universitys 

education in Building Informatics, called Civil Engineering with specialization in Building informatics. 

The reports aim, was to draw the readers attention to the inefficiency of exchange of information, 

in a building process. 

Our basis for work on the topic, “To create an optimal exchange process in a model-based environment” 

- has been the work of the organization BuildingSMARTs open standards. Standards 

such as Industry Foundation Classes (IFC), Information Delivery Manual (IDM) and International 

Framework for Dictonaries (IFD). We have tried to make the somewhat complex standards more 

palpable, by describing the tools in a context with rest of the building processes and the Danish 

conditions. 

To get a more realistic reference, we have been given the case, House of Music in Aalborg. We 

have taken House of Music as a point of reference, when we have been referenced to the real 

world. 

We have divided the report into three general main sections. Initially, we focus about the House 

of Music, and the involved parties. The second part is about the theory behind an effective exchange 

of information in a model-based environment. The third section deals with the practical 

aspect, which focuses about exchange experiments and solution proposals. The solution proposal 

includes a conceptual model of how some of the concepts presented by the organization BuildingSMART 

in a contemporary environment. 

Finally, we write a perspective and a conclusion where we try to answer our problem formulation 

and perspective.

Titelblad 


Titel Udveksling af informationer i et modelbaseret miljø 

Forsidebillede Billeder er taget fra http://www.coop-himmelblau.at/ 

Uddannelsesinstitution Aalborg Universitet 

Uddannelse Cand. Scient. Techn. i Byggeri og Anlæg, Bygningsinformatik 

Opgave 2. Semester opgave, E2011 

Forfattere Jacob Wassard Andersen 

Ole Breiner Siig 

Peter Gade 

Thomas Dragsbæk 

Lasse Bønnerup 

Vejledere Associate Prof. Kjeld Svidt 

Institut for Byggeri og Anlæg, 

Sektionen for Architectural Engineering 

Bygningsinformatik 

Oplæg Digital publicering 

Udgivelsesdato 20. December 2011 

Sprog Dansk 

Anslag 143.289 Total 

Sidetal 95 Sider 

20. december 

2011 

5

20. december 

2011 

6 


1 Indledning .................................................................................................................................... 8 

1.1 Baggrund ............................................................................................................................... 8 

1.2 Problemformulering ........................................................................................................... 10 

1.3 Metode ............................................................................................................................... 10 

1.4 Afgrænsning ........................................................................................................................ 11 

1.4.1 Implicerede parter ....................................................................................................... 11 

1.4.2 Teoretiske forhold ........................................................................................................ 11 

1.4.3 Praktiske forhold .......................................................................................................... 11 

2 Case ”Musikkens Hus” i Aalborg ................................................................................................ 12 

2.1 Musikkens Hus .................................................................................................................... 12 

2.2 Historien bag Musikkens hus .............................................................................................. 12 

2.3 Coop Himmelb(l)au og Friis & Moltke................................................................................. 14 

2.4 Niras .................................................................................................................................... 15 

2.5 Rambøll. .............................................................................................................................. 15 

2.6 Fonden Musikkens Hus ....................................................................................................... 15 

3 Teoretiske forudsætninger ....................................................................................................... 16 

3.1 Analyse og kortlægning ...................................................................................................... 16 

3.1.1 BPMN - Business Process Model and Notation ........................................................... 16 

3.1.2 IDEF (ICAM Definition) metoder .................................................................................. 21 

3.1.3 IDEF1x ............................................................................................................................ 24 

3.1.4 Unified Modeling Language (UML) .............................................................................. 25 

3.1.5 Entity-Relationship model (E-R) ................................................................................... 27 

3.2 BuildingSMART.................................................................................................................... 31 

3.2.2 Industry Foundation Classes (IFC) ................................................................................ 33 

3.2.3 Information Delivery ManuaI (IDM) ............................................................................ 40 

3.2.4 Model View Definition (MVD) ...................................................................................... 53 

3.2.5 International Framework for Dictionaries (IFD) ........................................................... 58 

3.3 Klassifikation og udveksling ................................................................................................ 63 

4 Praktiske forhold ........................................................................................................................ 65 

4.1 Hvordan foregår informationsudveksling i dag? ................................................................ 65 

4.2 Møde med parterne ........................................................................................................... 65 

4.2.1 Informationsudveksling. .............................................................................................. 65


20. december 

2011 

4.2.2 Cad-manual .................................................................................................................. 65 

4.2.3 BuildingSMART ............................................................................................................. 65 

4.2.4 Sammenfatning ............................................................................................................ 66 

5 Eksport eksperimentet............................................................................................................... 67 

6 Hvordan bliver vi bedre ............................................................................................................. 72 

6.1 Problemstilling .................................................................................................................... 72 

6.2 Analyse ................................................................................................................................ 72 

6.2.1 Koncept ........................................................................................................................ 72 

6.2.2 Opbygning .................................................................................................................... 73 

6.2.3 Databasen .................................................................................................................... 76 

6.2.4 Navigationsdiagrammet .............................................................................................. 77 

6.2.5 Grafisk brugerflade (GUI) ............................................................................................. 78 

6.2.6 Dialogboksen: Bruger ................................................................................................... 79 

6.2.7 Dialogboksen: Informationskravsoversigt ................................................................... 80 

6.3 Sammenfatning................................................................................................................... 80 

7 Konklusion .................................................................................................................................. 81 

8 Perspektivering .......................................................................................................................... 82 

Kortsigtet (1-5 år) ......................................................................................................................... 82 

Langsigtet (5+ år) .......................................................................................................................... 82 

9 Kildeliste ..................................................................................................................................... 83 

9.1 Billedhenvisninger .............................................................................................................. 86 

10 Ordforklaring ............................................................................................................................ 89 

Bilag 1: Kontrol beregninger. ....................................................................................................... 91 

7

20. december 

2011 

1 Indledning 

8 


1.1 Baggrund 

Building Information Modeling (BIM) betegner bla. den proces som omfatter generering og administration 

af digitale bygningsdata. Salgsargumentet for anvendelse af BIM, er bl.a. muligheden 

for at samle alle data i en og samme bygningsmodel samt muligheden for at udføre simuleringer. 

Parterne i et projektteam undgår desuden at genere redundante data og får samtidig et struktureret 

og omfattende beslutningsgrundlag fra de resterende parter, såfremt informationsudvekslingen 

er udførlig og foregår rettidigt. BIM kan, hvis det bliver implementeret og styret rigtigt, 

resultere i en mere integreret design- og konstruktionsproces. 

Succeskriteriet for en effektiv arbejdsgang blandt mange samarbejdende aktører, er kommunikation 

og et altid opdateret beslutningsgrundlag. Udvekslingsprocessen er ofte mere kompliceret 

end man først antager. Det handler om at etablere konsensus omkring forløbet og kræver disciplin 

fra alle parter. Som bekendt er ingen kæde stærkere end det svageste led. Dette gælder også 

for anvendelsen af BIM i et dynamisk projektteam, hvor alle parter er afhængige af hinandens 

kompetencer og samarbejdsvillighed. 

Oplysningen omkring BIM foregår i vid udstrækning på et teoretisk niveau og mangler ofte at blive 

kædet sammen med ”den gode historie”. Mange virksomheder bryster sig med store lovende ord 

og imponerende salgsmateriale, men konkrete eksempler i fuld skala glimter ved sit fravær. 

Dog ser udviklingen ikke ud til at stoppe her – specielt ikke på globalt plan, hvor lande som f.eks. 

Norge befinder sig på et helt andet og højere niveau. Flere og flere virksomheder indser nødvendigheden 

for et generationsskifte i IT værktøjerne og opfatter i stigende grad BIM som et konkurrenceparameter 

på det fremtidige marked. 

Vi har i vores forarbejde identificeret udvekslingsprocessen mellem parter som en flaskehals vi vil 

fokusere på. I nærværende rapport inddrages praktisk erfaring fra projektteamet omkring ”Musikkens 

Hus” i Nordjylland samt observationer foretaget af rapportens forfattere. Også her er 

ambitionerne for anvendelse af BIM høje, og fremstilles på bl.a. Niras’ hjemmeside således; 

”På Kunstens Hus i Herning og Musikkens Hus i Nordjylland har vi gjort os mange 

erfaringer med brugen af buildingSMART’s værktøjer og anvendelsen af BIM i projekterne.” 

(Niras, 2011) 

Niras er installationsingeniør på projektet og Cowi er bygherrerådgiver: 

”COWI bruger bygningsinformationsmodellering i relevante byggeprojekter, fordi 

det giver en mere koordineret byggeproces.” (Cowi, 2011) 

På sidste semester lærte vi at der kan være langt imellem intention og handling når det gælder 

BIM i byggebranchen. Ovenstående udsagn vil være genstand for vores undersøgelse af såvel de 

reelle forhold på byggesagen samt parternes egen opfattelse. Vi vil, som før nævnt, fokusere på


20. december 

2011 

aspektet omkring udveksling og håndtering af data mellem faggrupper. Hertil inddrages værktøjer 

og metoder til at effektivisere og kvalitetssikre processen. 

Nedenstående citat fra Ingeniøren underbygger vores påstand omkring udvekslingsprocessen; 

”It-systemer, der ikke kan tale sammen, er årsag til fejl, forsinkelser og dobbeltarbejde 

for milliarder i byggebranchen hvert år. 

Masser af byggeinformationer går nemlig tabt, når digitale 3D-tegninger sendes 

rundt mellem parterne, og det betyder f.eks., at de rådgivende ingeniørers it-system 

ikke kan forstå arkitekternes tegninger og derfor må tegne forfra.” (Ingeniøren, 

2008) 

9

20. december 

2011 

10 


1.2 Problemformulering 

Projektet har til formål at undersøge, om der findes metoder til at effektivisere og simplificere 

udvekslingen af informationer mellem parter i et byggeprojekt. 

Undersøgelser viser at der ligger et stort potentiale i brugen af BIM i byggebranchen, såfremt 

metoderne bliver implementeret i alle dele af byggeriet, og de tekniske værktøjer optimeres til at 

håndtere BIM-modeller – men hvilke værktøjer er der tale om og hvordan anvendes disse? 

Vores hovedspørgsmål lyder derfor således; 

Hvordan skaber man en optimal udvekslingsproces i et modelbaseret miljø? 

1.3 Metode 

Til at undersøge og besvare problemstillingen i problemformuleringen, vil vi gøre brug af følgende 

metoder: 

Litteratursøgning 

Vi vil gennem litteratursøgning finde relevante informationer, som beskriver BIM og BuildingSMARTs 

værktøjer i byggeriet, samt hvilke erfaringer der er gjort. Vi vil anvende litteratur 

i form af videnskabelige artikler, bøger samt udgivelser fra interesseorganisationer og virksomheder 

med seriøs erfaring indenfor emnet. Derudover vil vi finde inspiration i tidligere 

specialer og afhandlinger. 

Interviews 

Vi ønsker at kombinere den faglitterære tilgang med interviews fra nøglepersoner i såvel 

branchen som helhed samt interessenter fra nærværende case, Musikkens Hus. 

Praktisk afprøvning af BIM-modellering 

”Hands-on approach”, eller praktisk erfaring. 

Til at afprøve hvordan IFC formatet kan bruges til at udveksle modeller i dag, er der foretaget 

praktiske afprøvninger med udveksling af BIM-modeller mellem modellerings værktøjer.


20. december 

2011 

1.4 Afgrænsning 

Denne rapport har til formål at give læseren et indblik i BuildingSMARTs standarder og værktøjer 

som søger den optimale udveksling af informationer i byggebranchen. 

For at kunne gøre dette, har det været nødvendigt at afgrænse til flg. 3 hovedområder: 

1. Musikkens Hus, og de Implicerede parter. 

2. Teoretiske forudsætninger. 

3. Praktiske forhold. 

1.4.1 Implicerede parter 

Grundet omfanget af implicerende parter i projektet, Musikkens Hus, har vi valgt et udsnit af aktørerne 

på byggesagen. Rapporten vil overordnet beskrive udvalgte aktører som Fonden Musikkens 

Hus, Coop Himmelb(l)au, Friis og Moltke, Niras og Rambøll. 

1.4.2 Teoretiske forhold 

Analyseværktøjer 

Til grov-analysen er der beskrevet og valgt UML, E-R, og IDEF0. Desuden vil BPMN blive belyst og 

anvendt flere steder i rapporten. 

BuildingSMART 

Rapporten vil på overordnet vis beskrive organisationen og efterfølgende give en grundig gennemgang 

af udvalgte standarder og værktøjer som understøtter udvekslingsprocessen, herunder: 

IFC 

Generel beskrivelse samt opbygning. Efterfølgende vil der blive opsummeret med en status 

iht. byggesagen samt den gernerelle anvendelse. 

IDM 

Generel beskrivelse samt opbygning. Herunder beskrivelse af Process Maps, Exchange Requirements 

og Functional Parts. Afsnittet vil blive opsummeret med en status iht. byggesagen 

samt den gernerelle anvendelse. 

- MVD 



IFD 



1.4.3 Praktiske forhold 

Semesterrapporten tager udgangspunkt i BuildingSMART, og derfor er udvekslingsformatet IFC 

valgt. 

Det praktiske forsøg er afgrænset til 4 udvalgte projekteringsværktøjer, hvorpå der er lavet eksport/import 

–forsøg. 

11

20. december 

2011 

12 


2 Case ”Musikkens Hus” i Aalborg 

Følgende afsnit beskriver Musikkens Hus, samt udvalgte parter i projektet. I den teoretiske gennemgang 

vil der drages paralleller til den konkrete byggesag. Dette suppleres med interviews 

blandt parterne. 

2.1 Musikkens Hus 

Når Musikkens Hus står færdigt i Aalborg 

er det beliggende lige ud til Limfjorden 

som en del af et dynamisk byrum, der 

forbinder byens centrum med Limfjorden. 

Byggeriet har et bruttoareal på 20.257 m 2 

og et udnyttet nettoareal på 17.637 m 2 . 

Musikkens Hus har 5 etager over terræn 

og 3 etager under som er inddelt i forskellige 

bygningsafsnit, centreret omkring 

koncertsalen med plads til ca. 1300 personer. 

Der er 3 mindre sale placeret i 

Billede 1 - Viser rendering af Musikkens Hus. Kilde: Coop Himmelb(l)au. 

kælderniveau: Intimsalen (300 personer), Klassisk Sal (150 personer) og Rytmisk Sal (150 personer). 

Formålet med Musikkens Hus er at kombinere den offentlige oplevelsesscene, med store 

koncertoplevelser, med den kunstneriske udvikling og med uddannelse på flere faglige niveauer. 

Såsom unikke uddannelses- og øvemiljøer for Aalborg Symfoniorkester, det Jyske Musikkonservatorium 

og Aalborg Universitet, Institut for Musik. (Det Digitale Byggeri) 

2.2 Historien bag Musikkens hus 

Lokale kræfter stiftede i 1986 foreningen ”Musikhusets Venner” med det formål at etablere et 

hus i Aalborg der kunne dække det lokale musiklivs behov for udfoldelse, samt danne rammerne 

om større gæsteoptrædener. I år 2000 blev der fra politisk side, besluttet at projektet omkring 

Musikkens Hus kunne opføres på havnefronten i Aalborg. Musikhusets Venner fik indsamlet 50 

mio. kr. som var kravet fra Aalborg kommune og det daværende Nordjyllands Amt. RealDania, 

dengang Realdanmark Fonden, gik ind i projektet med 60 mio. kr. 

I 2002 blev arkitektkonkurrencen udskrevet og i 2003 vandt Østrigske Coop Himmelb(l)au projektet 

hvorefter projekteringen hurtigt påbegyndte. 

I begyndelsen af 2006 blev Musikkens Hus udbudt i licitation, men det viste sig at projektet ikke 

kunne opføres indenfor den økonomiske ramme. De daværende bygherrer, Fonden Musikkens 

Hus i Nordjylland og Statens Forsknings- og Uddannelsesbygninger, valgte at skrinlægge projektet. 

I slutningen af 2006 indgik Aalborg kommune nye forhandlinger med partnere i projektet og på 

den baggrund meddelte RealDania, at de ville indgå med yderligere økonomisk støtte samt en 

stærkere organisation. I 2007 blev udpeget der en ny bestyrelse for Fonden Musikkens Hus i 

Nordjylland og der blev samtidigt etableret en driftsgruppe til at forberede den fremtidige drift.

Backstage 


Educational-U 

Figur 1 - Viser snit i Musikkens Hus 

Educational-U 

Trompet 

Cone 

20. december 

2011 

Sådan opføres huset 

Musikkens Hus opføres med bærende 

konstruktioner i præfabrikerede betonelementer 

(søjler, bjælker dæk, 

tagdæk og vægge). Omkring koncertsalen 

er vægge udført dels i bærende 

insitu beton og dels i præfabrikerede 

betonelementer. Den ydre klimaskærm 

på Koncertsalen udføres med bærende 

konstruktioner i beton, tag med stålgitterdragere 

og betondæk med udvendig 

tagisolering og membran. Den ydre 

facadebeklædning er udført i præfabrikerede 

betonelementer. Facader i Billede 2 - Viser Rambølls Teklamodel. 

backstage-området er udført som alufacader med termoglas / sikkerhedsglas. Facader i uddannelsesdelen 

(Educational-U) er betonsandwichelementer med amøbe relieffer og runde vinduer. 

Facader på Trompet og Conen er metalfacader med alu-glasfacader indbygget. På sydfacaden af 

Educational-U er der opbygget en solcelle facade. Ovennævnte områder kan ses på Figur 1. 

Byggeriet kompletteres med skillevægge, gulve, trapper, elevatorer, fast inventar, køkkener og 

malerarbejde. Der udføres VVS-arbejder, herunder ventilation, køling og vandinstallationer. Der 

udføres stærk- /svagstrømsarbejder, CTS og adgangskontrol. Arbejder i terræn omfatter terrænreguleringer 

og afsluttende belægning. ( FRIIS & MOLTKE, 2011) / (musikkenshus, 2011) 

13

20. december 

2011 

14 


2.3 Coop Himmelb(l)au og Friis & Moltke 

Hovedarkitekten på Musikkens Hus er østrigske Coop Himmelb(l)au som vandt den internationale 

arkitektkonkurrence. Efterfølgende er Friis og Moltke blevet involveret i opgaven som Coop Himmelb(l)aus 

lokale samarbejdspartner. Coop Himmelb(l)au har haft den samlede projekteringsledelse 

og ansvaret for de arkitektoniske udtryk på byggeriet, ligesom de indtil nu har produceret 

størstedelen af tegningsmaterialet. Friis og Moltke varetager bl.a. de daglige lokale kontakter, 

udarbejder budgetter og bidrager til projekteringen med dele af tegningsmaterialet og især beskrivelserne. 

Samarbejdet fungerer i praksis som om der var tale om to afdelinger af samme virksomhed. 

Coop Himmelb(l)au 

Coop Himmelb(l)au blev grundlagt i Wien af tre arkitekter, østrigske Wolf D. Prix og Michael Holzer 

samt polske Helmut Swiczinsky i 1968. Arkitekterne har siden da fokuseret på arkitektur, byplanlægning, 

design og kunst og vundet utallige internationale priser for sit arbejde. 

Blandt større projekter der er tegnet af Coop Himmelb(l)au er: 

Musée des Confluences (Kundskabens Museum) i Lyon, Frankrig. 

Busan Cinema Center i Sydkorea. 

den Europæiske Centralbank i Frankfurt am Main. 

Dalian Internationale Konferencecenter i Kina. 

boligbyggeriet ”Liesing Brewery” i Wien. 

Firmaet har hovedkontor i Wien og beskæftiger 126 medarbejdere, heraf 89 arkitekter og 20 tekniske 

designere. 

Friis & Moltke 

Friis & Moltke er en dansk arkitekt virksomhed, som blev grundlagt af henholdsvis Knud Friis og 

Elmar Moltke tilbage i 1954. De startede i Århus, men er i dag også placeret i Aalborg og Køge. 

Tegnestuen bliver ledet af 5 partnere, hhv. Palle Hurwitz, Niels Erik Thomsen, Martin Wienberg, 

Mikkel Wienberg og Mogens Husted Kristensen, sammen med associeret partner Mikkel Bahr. Der 

er i dag ansat omkring 60 medarbejdere, hvor størstedelen arbejder i Århus. 

Virksomheden arbejder indenfor alle aspekterne af arkitekturvirksomhed, lige fra enfamilieshuse, 

støttet boligbyggeri til store eksklusive boligbyggerier med mere. Tegnestuen arbejder med BIMapplikationer 

på flere projekter, hovedsagligt med Autodesk Revit. ( FRIIS & MOLTKE, 2011)


20. december 

2011 

2.4 Niras 

Niras blev grundlagt i 1956 af civilingeniørerne Jørgen Kristian Nielsen og Konrad Rauschenberger, 

og er i dag en af landets førende virksomheder indenfor ingeniørrådgivning. Derudover har Niras 

satset internationalt og har i dag kontorer i mere end 35 lande. På verdensplan har Niras over 

1200 ansatte. 

NIRAS har arbejdet med BIM gennem mange år, hvor de har gjort sig en del erfaringer med brugen 

af BuildingSMART´s værktøjer og anvendelse af BIM. 

”På Kunstens Hus i Herning og Musikkens Hus i Nordjylland har vi gjort os mange 

erfaringer med brugen af buildingSMART’s værktøjer og anvendelsen af BIM i projekterne.” 

(Niras, 2011) 

Hos Niras ser de sig selv, som en potentielle samarbejdspartner til avancerede BIM projekter. 

Niras leverer ydelser indenfor: analyse & strategi, byggeri, energi, forsyning, industri, informatik, 

infrastruktur, miljø, planlægning og udviklingsbistand. (www.niras.dk) 

2.5 Rambøll. 

Rambøll blev grundlagt i 1945, af de to unge ingeniører Børge Johannes Rambøll og Johan Georg 

Hannemann, efter en periode som medarbejdere på Anker Engelunds tegnestue. 

Rambøll Danmark er en del af Rambøll Gruppen. Rambøll Gruppen beskæftiger pt. omkring 

10.000 mennesker på verdensplan. Rambøll gruppen har ca. 200 kontorer, og er repræsenteret i 

23 lande. Fortrinsvis i Nordeuropa, Indien, Rusland og Mellemøsten. 

Rambøll levere ydelser indenfor; Byggeri & design, infrastruktur & Transport, energi & klima, industri 

& olie/gas, it & telekommunikation, management & samfund og miljø & natur. 

(http://www.ramboll.dk/services) 

Rambøll er konstruktionsingeniør på ”Musikkens Hus”, hvilket har givet dem store udfordringer, 

grundet den udfordrende arkitektur. Derfor har Rambøll udarbejdet en bygningsmodel. Modellen 

er modelleret i Tekla, hvorefter stålleverandøren har arbejdet videre på den. 

2.6 Fonden Musikkens Hus 

Byggeriet Musikkens Hus styres af Fonden Musikkens Hus i Nordjylland. Fonden er stiftet af Det 

Obelske Familiefond og Spar Nord Fonden, som en erhvervsdrivende fond, med ansvaret for opførelsen 

af det fysiske byggeri samt ansættelse af en byggeledelse. Bestyrelsen tæller, under byggeriets 

opførelse, repræsentanter fra henholdsvis Aalborg kommune, RealDania, Spar Nord Fonden 

og Det Obelske Familiefond, som støtter forskning, uddannelse og kultur i Nordjylland. Når byggeriet 

står færdigt, og senest 6 mdr. efter overtagelse af det færdige byggeri, opløses bestyrelsen og 

genopstår i en ny form, som herefter tager udgangspunkt i driften af byggeriet Musikkens Hus, 

som kulturinstitution. Her vil fondens formål desuden bestå i at fremme den musikkulturelle aktivitet 

i Nordjylland. (musikkenshus, 2011) 

15

20. december 

2011 

16 


3 Teoretiske forudsætninger 

Det teoretiske grundlag for en vellykket udvekslingsproces bygger på standardiserede løsninger 

med internationalt udbredelse. BuildingSMART er i dag branchens de-facto standard og tilbyder 

løsninger til planlægning og dataudveksling. Dette afsnit omhandler BuildingSMARTs værktøjer og 

standarder, hvilke gennemgås med en teoretisk tilgang. Alle eksempler er baseret på ønskescenariet. 

Udover BuildingSMART, vil afsnittet omhandle analyse og procesmetodologier der kan hjælpe til 

med at skabe det optimale grundlag for en optimal arbejdsproces, samt nogle af de procesfilosofier, 

som ligger til grund for BuildingSMART. 

Efter hvert hovedafsnit, sammenholder vi emnet med situationen i dag/case Musikkens Hus, og 

giver et bud på potentialet for fremtiden. 

3.1 Analyse og kortlægning 

Den optimale dataudvekslingsproces afhænger i høj grad af planlægning. Hvem skal have hvad, 

hvornår og i hvilken form? Klarer aftaler om forventninger skal være afstemt inden påbegyndelse 

af et projekt, ellers opstår der hurtigt forsinkelser i hele værdikæden. Det er vigtigt med koordinering 

og afstemning af forventninger, således alle parter har en klar prioriteringsliste for de arbejdsopgaver 

som skal færdiggøres, for at sikre den optimale udvekslingsproces. 

Til organisering af processer kan anvendes metoder som f.eks. IDEF0, BPMN, UML og ER, hvilket er 

beskrevet i det følgende afsnit. Metoderne besidder grundlæggende de samme egenskaber, men 

valget af metode bør alligevel overvejes i henhold til opgavens udstrækning og det ønskede resultat. 

Ved hver metode er beskrevet de primære fordele for hver enkelt og dets relation til BIM og 

processtyring. 

3.1.1 BPMN - Business Process Model and Notation 

BPMN er en notationsform, som bruges til at illustrere forretningsprocesser. Kommunikationsformen 

baseres på et grafisk layout og er opstillet som et diagram. BPMN er en international de 

facto standard, til at modellere og dokumentere processer i. Metoden er derfor altid den samme, 

uanset hvilket værktøj man anvender, hvilket underbygges af, at 72 softwarevirksomheder i dag 

har optaget BPMN i deres programpakker. Formålet med en international standard, er at forretningsprocesser 

kan illustreres og læses på en fælles platform - i et fælles sprog. Dermed kan forskellige 

virksomheder og organisationer hurtigt udvikle en proces for et samarbejde, på et sprog 

som alle parter kender og forstår. Offentliggjorte arbejdsprocesser kan desuden genbruges og 

modificeres til brug i andre sammenhænge. 

Der findes mange metoder til at opstille procesmodeller. Udviklingen startede for omkring 40 år 

siden og omfatter, udover BPMN, standarder som IDEF, Petri og UML. UML som i dag er den mest 

udbredte. BPMN adskiller sig fra de øvrige ved at være procesorienteret, hvor de andre er objektorienteret. 

BPMN egner sig derfor specielt til udvikling af IT-systemer til forretningsprocesser. 

(www.version2.dk, 2011) 

Motivationen bag BPMN opstod i første omgang, da man ville udvikle et værktøj til dokumentation 

af forretningsprocesser. Institutionen The Business Process Management Institut (BPMI), som i 

dag er en del af Object Management Group (OMG), udviklede først BPML – et metasprog ligesom 

XML er. I udviklingsforløbet blev man klar over at det ligeledes var nødvendigt med en grafisk


20. december 

2011 

repræsentation processerne – deraf BPMN. Gruppen Notation Working Group, bestående af repræsentanter 

fra 35 forskellige virksomheder, organisationer og enkeltpersoner blev dannet i 

2001, for at varetage denne opgave i fællesskab. I 2004 kom så den første officielle udgivelse – 

BPMN 1.0, og denne er netop fulgt op af udgivelsen BPMN 2.0 i 2010. Da BPMI fusionerede med 

OMG i 2005, blev BPML sproget erstattet af BPEL, som ligeledes er et procesudførelsessprog, men 

baseret på metasproget XML i stedet. Formålet med BPMN er et notationsværktøj som kan anvendes 

af forretningsfolk såvel som programmører. BPEL er en forkortelse for Web Services Business 

Process Execution Language, og omtales også WS-BPEL. (www.bpmn.org, 2011) / 

(www.en.wikipedia.org, 2011) 

Med BPMN kan den samme proces illustreres på mange forskellige måder, alt efter behov. Skal 

processen kun illustreres grafisk, er det en fordel at anvende et enkelt og intuitivt layout som 

giver en hurtig forståelse. Skal processen derimod anvendes til at understøtte et it-system, bør 

modelleringen tage udgangspunkt heri. Illustrationen vil i denne sammenhæng ofte få et mere 

komplekst layout, idet alle led i processer skal dokumenters, så BPMN’en ligger så tæt op af processerne 

i det færdige it-system som muligt. I Diagram 1 og 2 nedenfor, vises en BPMN designet 

til henholdsvis visuel illustration og en til baggrund for et IT-system. Den rent visuelle tager kun 

fat i de overordnede hovedpunkter for at lette implementeringen hos mennesker, hvorimod pro- 

Diagram 2 - Viser BPMN til ren illustration 

Diagram 1 - Viser BPMN til IT-system. 

17

20. december 

2011 

18 


cessen til et IT-system skal være mere detaljeret, idet computere ikke selv kan udfylde ”missing 

links”, som den menneskelige hjerne kan det. 

3.1.1.1 Objekter og symboler i BPMN 

BPMN består af en række symboler der har forskellige betydninger og forskellige regler for hvordan 

de kan og må anvendes i en sammenhæng med andre symboler. Det er ikke alle symboler 

som kan kombineres, hvilket modelleringsværktøjerne ofte gør opmærksom på. Processer illustreres 

desuden altid fra start til slut. 

Grundlæggende grupperes der efter 4 forskellige objektkategorier i BPMN standarden, henholdsvis 

Events, Activities, Gateways og Connections. Til at organisere layoutet anvendes desuden 

Pools og Lanes. I det følgende beskrives de mest anvendte modelleringsobjekter. 

Events / Begivenheder 

Events eller begivenheder vises altid med en cirkel og et symbol i midten. 

En event viser noget som skal til at ske eller er i gang med at ske (modsat 

en aktivitet, som allerede er sket). Symbolet i midten viser funktionen. Et 

brev kan for eksempel illustrere en besked, ligesom et ur kan beskrive et 

tidspunkt. Events fungerer ved at reagere på et input. For eksempel kan 

et bestemt tidspunkt eller modtagelsen af en besked igangsætte en aktivitet. 

På samme måde kan afslutningen på en aktivitet kvitteres med en 

besked fra en event. 

De mest anvendte er start og slut eventen, som beskriver henholdsvis 

Figur 2 - Viser 3 forskellige typer af 

Events. 

starten og slutningen på en proces. Slut-eventen kan ikke igangsætte andre aktiviteter. Indimellem 

disse, anvendes intermediate events, og beskriver alle andre tænkelige begivenheder. 

Activity / Aktivitet 

En aktivitet vises som en firkant med afrundede hjørner. En aktivitet 

beskriver en arbejdsopgave som skal være gennemført, for at den efterfølgende 

proces kan fortsætte. For at bevare overblikket, beskrives arbejdsopgaver 

relativt overordnet, såsom ”send en mail”. Trinene indimellem 

– tænd computer, åbn mailprogram, formuler mail, et. – beskrives 

ikke. Aktiviteter kan, ligesom events, opdeles i flere undergrupper. 

Den første er Task, som repræsenterer en enkelt arbejdsgang, og som 

ikke kan eller må nedbrydes til yderligere arbejdsgange. 

Dernæst findes sub-process eller delopgave, som bruges til at linke til 

andre delprocesser og markeres med et plus-tegn. Delprocesser anvendes til at simplificere opsætningen 

i procesdiagrammet, ved at vise/skjule delprocesser efter behov. Delprocesser fungerer 

selvstændigt med et start- og slutevent, og der må ikke laves relationer til resten af processen 

indimellem disse. Delprocesser er også måden hvorpå man effektivt kan genbruge tidligere udviklede 

processer. Disse indsættes da som en delproces i den overordnede proces. Disse klassificeres 

henholdsvis private (intern), abstract (offentlig) og collaboration (global), og beskriver hvorledes 

delprocessen kan optræde flere steder i diagrammet og i andre diagrammer. 

Figur 3 - Viser 2 forskellige Activity.


Gateway / Samlingspunkt 

En gateway illustreres med en diamantform og anvendes til at samle og sprede 

forbindelser på baggrund af bestemte konditioner. En slags universalt vejkryds, 

hvor stier. Udfaldet af gateways bestemmes af typen; Exclusive gateway tillader 

kun et enkelt output, Inclusive gateway tillader mere end 1 og Parallel gateway 

tillader alle input at passere til output. 

Connection / Forbindelse 

Connections skaber linket mellem begivenheder og aktiviteter, og illustreres med 

en stiplet eller en gennemgående streg. Forbindelser som kun fører en ene vej, 

illustreres med en pil i informationsretningen. 

Sequence Flow / Rækkefølge 

Et Sequence Flow vises med en gennemgående streg og en pil og angiver i hvilken 

rækkefælge aktiviteter må udføres. Særlige forhold angives med en lille diamantform 

i starten af pilen. I Diamanten angives et nummer, som viser en af en række 

betingede strømme fra en aktivitet, mens en diagonal skråstreg angiver standard 

flow fra en afgørelse eller en aktivitet med betingede strømme. 

20. december 

2011 

Message Flow / Besked 

Message Flow illustreres ved en stiplet linie og en åben cirkel I starten og en åben pil I slutningen. 

Denne type anvendes til at vise beskeder som udveksles på tværs af pools, dvs. beskeder mellem 

to domæner, eksempelvis to virksomheder, organisationer eller afdelinger. Message flow anvendes 

aldrig indenfor samme pool. 

Association / Relation 

Denne anvendes til at associere noget abstrakt, som en tekst eller et billede, til et objekt. En retning 

kan illustreres med en åben pil mod objektet for at repræsentere et input. Vendes pilen 

modsat, altså væk fra objektet, illustreres et resultat. 

Pools og Lanes 

Ved anvendelse af forretningsprocesser, er der ofte flere parter involveret. 

Det kunne være en virksomhed og en kunde, eller indenfor byggeriet 

– arkitekt, ingeniør, entreprenør, etc., som optræder indenfor hver deres 

domæne. Interaktion mellem proceselementer i forskellige domæner 

anskueliggøres ved at placere delprocesserne i såkaldte ”Pools”. Disse 

pools kan yderligere opdeles i ”lanes” for eksempelvis at illustrere hvordan 

forskellige processer kan tilhøre en bestemt afdeling, en fase el.lign. 

(www.bpmn.org, 2011) 

Figur 4 - Viser Illustration af 

"Gateways". 

Figur 5 – Viser illustration af 

"Connections". 

Figur 6 - Viser illustration af 

"Pool" opdelt i "Lanes". 

3.1.1.2 Nyt i BPMN 2.0 

I den nye version kan der oprettes links mellem fortløbende processer. I stedet for at illustrere 

processer i et langt kontinuert diagram, kan en arbejdsproces deles op i delprocesser, for på den 

19

20. december 

2011 

20 


måde at give læseren mulighed for at skabe sig et hurtigt overblik og en bedre forståelse. Slutningen 

af en delproces vil da være illustreret med et link som fører til starten af den næste delproces. 

Linket vil udelukkende betyde en grafisk opdeling af den fulde proces – ikke en fysisk. Delprocesser 

vil altså opfattes som en samlet proces hvis den overføres til et IT-system. 

For at understøtte intentionen om at dele og genbruge processer, er der nu mulighed for at specificere 

om BPMN’en beskriver en offentlig eller privat forretningsproces. Offentlige processer deles 

over en database, hvorimod private ikke vil blive udgivet. 

3.1.1.3 Værktøjer 

Da BPMN er en åben standard, kan metoden findes i mange forskellige applikationer. Diagrammerne 

har alle samme layout, men modelleringsproces og brugervenlighed varierer meget. Deciderede 

programmeringsprogrammer, såsom Eclipse eller Aris, giver mange muligheder for videre 

anvendelse data i diagrammerne til udvikling af IT-systemer, men har også et mere teknisk og 

kompliceret tilgang i interfacet. Skal diagrammet udelukkende give en menneskelig forståelse af 

en proces, kan programmer med fokus på layout og hurtig modellering være bedre at anvende. 

Onlineværktøjet Iyopro 1 tillader flere at arbejde sammen i samme diagram, og giver samtidig en 

grundig vejledning til funktioner og anvendelse af alle objekter igennem hele modelleringsprocessen. 

3.1.1.4 BPMN og BIM / Case 

Indenfor byggeriet bruges BPMN ofte til at illustrere bygge-, arbejds- og udvekslingsprocesser. Det 

kunne være interne arbejdsprocesser, eksterne arbejdsprocesser eller metode for udveksling af 

data med samarbejdspartnere. Her er det en stor fordel at anvende standardiserede løsninger 

som BPMN, så alle aktører kan bruge den samme løsning. Derved undgås en fragmentering af 

processen og denne kan følges fra start til slut. 

En IDM Process Map fra BuildingSMART, er eksempelvis altid baseret på BPMN. Det underliggende 

BPEL metasprog gør, at man ud fra sine Exchange Requirements (ER) kan genere en MVD, idet 

BuildingSMART har valgt denne som standard (ER/MVD uddybes senere i rapporten). 

På baggrund af de tilgængelige oplysninger i nærværende case, er BPMN ikke blevet anvendt – 

hverken i projektering eller planlægning af udførsel. 

1 http://www.iyopro.com/?lang=EN


20. december 

2011 

3.1.2 IDEF (ICAM Definition) metoder 

IDEF metoden (Integration DEFinition) er udviklet af det amerikanske US Air Force Materials laboratory. 

I 1976 grundlagde militærbasen Wright-Patterson ICAM projektet (Integrated Computer- 

Aided Manufacturing) i forsøget på at modernisere de teknologiske faciliteter til fremstilling af 

materiel. Projektet eksisterer stadig og har i dag brugt over 100 mio. dollars på udviklingen af 

teknikker, processer og værktøjer til optimering af produktionsteknikker. 

IDEF er et objektorienteret modelleringssprog, som anvendes til at visualisere produktions- og 

softwaresystemer på en let anskuelig måde gennem diagrammer og symboler. IDEF er en familie 

bestående af ca. 10 værktøjer, hvor de mest anvendte er IDEF0 og IDEF1x. IDEF0 anvendes til at 

modellere funktioner i en organisation eller et system, såsom beslutninger, handlinger og aktiviteter. 

IDEF1x er beregnet til modellering af informationer med særligt fokus på relationelle databaser. 

I det følgende beskrives først IDEF0 og dets anvendelsesmuligheder indenfor BIM projektering 

og dernæst IDEF1x. 

3.1.2.1 IDEF0 

IDEF0 er det mest simple modelleringssystem af de to - både grafisk og funktionsmæssigt, hvilket 

gør det meget anvendeligt som kommunikationsværktøj. Det giver en overskuelig måde at visualisere 

et her-og-nu billede af virkeligheden. Formålet med at anvende metoden IDEF0, er at kommunikere 

en eksisterende eller en fremtidig proces. Dette gøres vha. et diagram, med en fast 

fremgangsmåde og syntaks for opbygningen. IDEF0 har sin styrke i at kunne anskueliggøre processor 

for alle involverede parter. Effektive IDEF0 modeller bidrager til at organisere en analyse af et 

system og fremmer god kommunikation af teknisk karakter mellem analytiker og kunde/bruger. 

IDEF0 er desuden nyttigt til at fastslå omfanget af et projekt. 

Som et analyseværktøj, hjælper IDEF0 modeller med til at identificere hvilke funktioner der udføres 

i en proces, og hvilke inputs der er nødvendige for at udføre denne funktion. Ud fra diagrammet 

kan man hurtigt få et overblik over hvad et nuværende system gør rigtigt, og hvad systemet 

gør forkert. Derfor er IDEF0 modeller ofte skabt som en af de første opgaver for en systemudviklingsindsats. 

IDEF0 metoden er god, hvis man f.eks. skal opfylde flg. Scenarier: 

”Analysere eksisterende produktionssystemers funktionelle sammenhænge. 

Konstruere den funktionelle opbygning af nye systemer. 

Diskutere og kommunikere sammenhænge mellem funktioner i et system. 

Dokumentere og specificere systemer”. 

(Rasmussen, 1996) 

Grundlæggende består IDEF0 af inputs, outputs, controls og mechanisms. Kassen i midten kan 

være en aktivitet, handling, proces eller en operation. På Diagram 3 og 4 ses et eksempel på opsætningen 

af en IDEF0 funktion i et diagram. Første eksempel er en skabelon for opsætningen og 

andet eksempel viser IDEF0 anvendt på byggesagen Musikkens Hus. (www.idef.com) 

21

20. december 

2011 

22 


Diagram 3 - Viser grundelementerne i IDEF0 diagrammer 

Diagram 4 - Eksempel på IDEF0 diagram på A-0 niveau for 

Musikkens Hus. 

Inputs ”Inputs” angives med pile der tilgår funktionen fra venstre og angiver data / 

objekter som funktionen ændrer. På Diagram 3 er inputtet en konkurrence 

som bruges til at lave de færdige tegninger ud fra. En form for råmateriale 

som bearbejdes gennem funktionen. 

Mechanisms ”Mechanisms” angives med pile der tilgår funktionen fra neden og angiver 

den mekanisme der skal bruges af funktionen for at udføre processen. I Diagram 

3 er mekanismen ”software/værktøjer” og ”medarbejdere”, som funktionen 

skal bruge til at manipulere inputtet. 

Controls ”Controls” er angivet med pile der tilgår funktionen fra oven og angiver kontroller, 

betingelser og forhold der styrer / begrænser funktionen. I Diagram 3 

er betingelserne tid, ”Økonomi og krav/lovgivning” som stiller begrænsninger 

for den pågældende situation. 

Outputs ”Outputs” er angivet med pile der udgår fra funktionen til højre og angiver 

data / objekter som funktionen resulterer i. I Diagram 3 er outputtet ”Færdige 

tegninger”.


3.1.2.2 Decomposing 

For overskuelighedens skyld er IDEF diagrammer 

sammensat af underfunktioner i et hierarkisk system. 

Figur 7 viser strukturen i IDEF0. Øverst vises det generelle 

diagram, som kaldes for en ”parant” -altså en 

forældre til de mere detaljerede diagrammer som 

kommer efterfølgende. Øverste niveau af diagrammerne 

navngives Context eller A-0 diagrammer, og 

opsummerer den overordnede funktion af det valgte 

system og vises ved en enkelt kasse. Et A0 Diagram 

repræsenterer første nedbrydning af systemet. A0 

diagrammet og alle efterfølgende diagrammer indeholder 

typisk 3 til 6 nummererede bokse. Numrene 

hjælper med at binde diagrammerne sammen. Dette 

fremgår af figur xx, hvor boks 2 i diagram A0 er nedbrudt 

på diagram A2 og boks 3 på diagram A2 er nedbrudt 

på diagram A23. (William D. Waltman, 1993) 

Diagram 5 - Viser eksempel på et IDEF0 diagram på Context niveau for projektet Musikkens Hus 

20. december 

2011 

Figur 7- Viser en dekompositionen af IDEF0 metoden. 

23

20. december 

2011 

24 


3.1.2.4 IDEF0 og BIM / Case 

Ved projektering i byggeri anvendes IDEF0 ofte som et værktøj til de indledende procesanalyser. 

Metoden er meget enkel og kan derfor være hurtigere at sætte sig ind i end f.eks. BPMN. IDEF0 er 

ikke anvendt på Musikkens Hus, selvom der er fundet flere eksempler fra specielt Niras, som har 

eksperimenteret med IDEF0 i flere forskellige byggesager - bl.a. i samarbejde med BIPS. Ved BIPS 

projektmanual til 3D arbejdsmetode anbefales desuden IDEF0 som analyseværktøj, hvor også Bips 

egne illustrationer er vist efter IDEF0 metoden. 

3.1.3 IDEF1x 

IDEF1X er specielt egnet til udvikling af relationelle databaser. Metoden er forholdsvis kompliceret 

og indeholder mange regler for korrekt opsætning. Derfor vil vi i stedet fokusere på anvendelsesmulighederne 

indenfor en BIM organisation. Der henvises til www.idef.com/idef1x.htm for mere 

information omkring symboler, syntaks, etc. 

3.1.3.1 IDEF1x og BIM / Case 

IDEF1X fungerer på samme måde som E-R diagrammer. Relationelle databaser visualiseres inden 

den funktionelle database opbygges i et servermiljø. 

Ulempen ved IDEF1x, og alle andre metoder til modellering af relationelle databaser, er at det 

kræver en del erfaring at lave gode diagrammer. Det handler om at gøre diagrammerne så simple 

så muligt, uden at gå på kompromis med funktionaliteten.


20. december 

2011 

3.1.4 Unified Modeling Language (UML) 

UML er en de-facto standard for udseende af diagrammer til beskrivelse af strukturer og forløb i 

objekt-orienterede softwaresystemer. UML anvendes hovedsageligt til visualisering af funktioner 

og interface, inden en egentlig kodning af programmet påbegyndes. Det handler om at anskueliggøre 

funktioner og tilgangen til disse i softwaren, med særligt fokus på brugerens oplevelse. Af 

samme årsag er UML bygget op omkring et simpelt udtryk, som kan aflæses af folk uden en baggrund 

indenfor IT, og agere samtaleplatform mellem programmører og brugere. Resultatet lader 

programmøren arbejde ud fra et solidt grundlag for softwarens arkitektur, hvor alle forventninger 

er afstemte og et klart mål med produktet er fastlagt. 

UML er, ligesom BPMN og IDEF0, administreret af OMG organisationen, som optog standarden i 

1997. UML startede som 3 næsten identiske systemer, udviklet af henholdsvis Grady Booch, Ivar 

Jacobsen og James Rumbaugh. I starten af halvfemserne blev alle tre ansat ved firmaet Rational 

Software, og derfra blev deres systemer smeltet sammen til at danne UML. Den specielle tilblivelse 

medførte samtidig en relativt upræcis definition af standarden og gav anledning til opdateringen, 

UML 2.0. lanceringen kom i 2005, under ledelse af OMG, som så behovet for en skarpere 

definition af UML – foranlediget af den fragmentering af standarden, som et stigende antal softwareproducenter 

med hver sin fortolkning af specifikationen, havde bevirket. Filformatet er struktureret 

efter XML protokollen under navnet XMI og har opnået status som branche-standard. 

(http://da.wikipedia.org/wiki/UML). 

Det grafiske udtryk i et UML diagram bestemmes 

af diagramtypen. Det mest anvendte 

diagram, illustreret på Diagram 6, er klassediagrammet, 

som ofte bruges til systemdokumentation 

og for at skabe et hurtigt overblik 

over sammenhængen i et system. I eksemplet 

til højre er vist illustrationen af et 

program, som forener kundekartotek, projekthåndtering 

og økonomisystem. 

Formålet med UML-analysen og projektets Diagram 6 – Viser et eksempel på et Klassediagram. 

omfang dikterer valget af diagramtype. 

Der findes i dag 13 forskellige diagramtyper, under to forskellige hovedgrupper - henholdsvis UML 

1 fra UML 1.x udgivelsen og UML 2 fra UML 2.x. Alle typer er vist på OMG’s hjemmeside – se link: 

http://www.uml.org/. 


Ved UML er der metodefrihed, dvs. frit valg af værktøj/software. Dog skal man sammenholde 

projektets størrelse, med det værktøj man vælger at bruge. Mange foretrækker det dynamiske i 

en simpel skitsering på en tavle eller papir. Dette er selvfølgelig forbeholdt mindre projekter 

25

20. december 

2011 

26 


3.1.4.2 UML og BIM / Case 

Filosofien omkring BIM arbejdsprocessen beror i høj grad på interoperabilitet mellem softwareapplikationer, 

hvor data genanvendes gennem hele arbejdsprocessen og redundante data elimineres. 

Større projekteringsvirksomheder arbejder ofte med programmer designet specifikt til 

egne behov og virke, heriblandt økonomisystemer, planlægningsværktøjer, kundekartoteker, projekthåndteringssystemer, 

etc. Typisk er de ikke kompatible og forstår ikke at udnytte data på 

tværs. Her kan simple applikationer anvendes til at strømline informationshåndteringen i en organisations 

it-systemer og dermed lette arbejdsgang og ressourcer. UML bruges som indledende 

værktøj til udviklingen af de systemer som skaber linket mellem forskellige programmiljøer. 

3.1.4.3 UML og BIM / Case 

Udfordringerne ved fuld implementering af BIM i små og mellemstore virksomheder ligger ofte i 

fragmenteringen af IT systemer. Ofte anvender virksomheder software fra mange forskellige producenter, 

til forskellige formål hvilket kan resultere i lukkede softwaremiljøer som ikke taler 

sammen. Grundet begrænsede ressourcer samt igangværende projekter, er det ofte ikke muligt at 

indføre alle BIM redskaber i en samlet proces. 

I relation til BIM og optimering af egne systemer i et modelbaseret miljø, kan UML bruges som 

indledende værktøj til udvikling af systemer som skaber linket mellem programmiljøer, således 

programmerne kan anvendes effektivt i en samlet proces.


20. december 

2011 

3.1.5 Entity-Relationship model (E-R) 

E-R Modeller benyttes til at udvikle konceptuelle designs for databaser. Når en database skal designes, 

er første skridt oprettelsen af E-R diagrammer. Disse hjælper designeren til en bedre forståelse 

og specificerer ønskede dele af databasen og relationerne imellem disse. En E-R model er 

et diagram, som indeholder entiteter (Entities), relationer (Relations), og attributter (Attributes) 

på entiteterne og relationerne. Gennem E-R modellen, får man illustreret en virkelig hændelse i 

en database. I dag fungerer E-R modeller som fundament for mange system-analyse/design metoder. 

Ideologien bag E-R så for første gang dagens lys i A. P. G. Browns artikel “Modelling a Real-World 

System and Designing a Schema to Represent It” I 1975, hvorefter Peter Chen hurtigt så potentialet 

og introducerede E-R modellen i skriftet "The Entity-Relationship Model - Toward a Unified 

View of Data", som vist i citatet herunder. (wikipedia.org, 2011) 

“A data model, called the entity-relationship model, is proposed. This model incorporates 

some of the important semantic information about the real world. A special 

diagrammatic technique is introduced as a tool for database design” (Chen, 1976) 

Peter Chen erklærede E-R modellen for en konceptuel datamodel, som ser den virkelige verden 

som enheder (entities) og relationer (relations), hvor den grundlæggende del af modellen er diagrammet, 

der bruges visuelt for at repræsentere dataobjekterne i databasen. Et typisk eksempel 

ses på Diagram 7. 

Diagram 7 - Viser en typisk E-R Model. 

3.1.5.1 Peter Chens notationer for E-R modeller 

Ovenstående E-R diagram består af 3 typer objekter. Disse 3 typer er Entiteter, Relationer og Attributter. 

De repræsenterer hver især et fænomen fra virkeligheden. Definitionen på de 3 objekttyper 

er som flg.: 

Entitet (Entity) 

”En entitet er en genstand, person, sted eller hændelse, som kan identificeres, og 

som har en sådan relevans for organisationen (informationssystemet), at der er behov 

for at registrere data om den/det”. 

Relation (Relation) 

27

20. december 

2011 

28 


”en relation repræsenterer en sammenhæng mellem entiteter i 2 eller flere forskellige 

entitetsklasser. Endelig kan en relation også repræsentere en sammenhæng 

mellem entiteter indenfor én og samme entitetsklasse”. 

Attribut (egenskab) 

”Attributter er beskrivende data, som angiver egenskaber ved entiteter eller relationer” 

(Arbov) / (Pagh). 

Relationsgrader (kardinaliteten) 

Relationsgrader viser hvordan entiteterne og relationerne kan associeres med hinanden. Dette 

sker via relationsgrader eller kardinaliteten og forklares som følgende: 

1:1 (en til en) definition: 

En entitet kan kun relateres til en anden entitet. 

1:N (en til mange) definition 

En entitet kan relateres til flere andre entiteter, men ikke omvendt! 

N:N (mange til mange) definition: 

Flere entiteter kan relateres til flere andre entiteter. (Informationsteknologi). 

Nedenstående Figur 8 viser de tre anvendte relationsgrader. 

Figur 8 - Viser de forskellige relationsgrader. 

Nøgler 

Formålet med nøgler er entydig identifikation. Attributterne bruges til at navngive/identificere 

rækker i tabellen. Disse kaldes ”nøgleattributter” eller ”nøgler”. Der findes 5 slags nøgler: 

”En kandidatnøgle er en eller flere attributter, som entydigt kan udpege rækkeforekomster i 

deres tabel. Der må ikke være flere attributter med end nødvendigt.” 

”En primærnøgle er den kandidatnøgle, der er blevet valgt som den vigtigste identifikation af 

tabelens rækker. Den markeres med én understregning i tabelskitsen.” 

”En alternativnøgle er en kandidatnøgle der ikke er blevet valgt som primærnøgle.” 

”En sammensat nøgle, er en nøgle, der er sat sammen af flere attributter.”


20. december 

2011 

”En fremmednøgle, er en eller flere attributter, der indeholder en værdi, der står som primærnøgle 

i en anden tabel, eller i en anden række i samme tabel” (Gustafson, 2007). 

Normalformer 

Normalformer omhandler en måde at forædle sine data på, hvilket vil sige at gøre dem bedre. Der 

findes 9 normaliseringsformer, hvoraf denne semesterrapport kun vil beskæftige sig med de 3 

første. Dette skyldes at man utrolig sjældent kommer op og bruger de resterende normalformer. 

Normalformernes formål er at lave så godt et database design som overhovedet muligt, samt 

"ensrette" måden man udvikler en database på. Ved at have en normaliseret database sikrer man 

samtidig at der ikke er redundante data i tabellerne, hvilket ville resultere i et forkert datagrundlag. 

Man sikrer også at databasen bliver overskuelig og nem at arbejde med. De første tre normalformer 

beskrives typisk 1NF., 2NF. og 3NF. 

1. Normalform (1NF). 

”En relation er på første normalform, hvis ingen af dens domæner har elementer, der i sig selv 

er mængder” (Andersen, 2008). 


”En relation R er på anden normalform, hvis den er på første normalform, og hvis enhver ikkenøgle-attribut 

er fuldt funktionelt afhængig af enhver kandidatnøgle i R.” (Andersen, 2008) 


”En relation R er på tredje normalform, hvis den er på anden normalform og det gælder, at ingen 

ikke-nøgle-attribut er transitivt afhængig af nogen kandidatnøgle i R.” (Andersen, 2008) 

Ovennævnte punkter er de vigtigste, når vi snakker E-R. Der er som skrevet flere, men disse vil 

ikke blive gennemgået i denne semesterrapport. 


Ligesom ved UML er der metodefrihed for modelleringsværktøj - man skal dog sammenholde 

projektets størrelse, med det værktøj man vælger at bruge. Mange foretrækker E-R Modelprogrammer 

som hjælper med at designe og redigere databaseskemaer, hvilket medfører at de 

abstrakte databaseobjekter og processer kan vises i et sammenhængende diagram. 

3.1.5.3 E-R og BIM / Case 

Nutidens byggeprojekter indeholder store mængder af information og uden databaserne var det 

svært at bevare overblikket og navigere rundt i de store mængder data. En E-R Model definerer 

hvad der skal opbevares i selve databasen. Dette beskrives i termer som ”entities”, ”relations” og 

”attributes”, hvilket giver overblik over databasens opbygning. I dag bliver databaserne brugt til at 

gemme virksomhedens data, websider, tegninger, dokumenter, etc. 

29

20. december 

2011 

30 


Musikkens Hus er af en vis størrelse og kompleksitet og skulle man printe alle dokumenter og 

tegninger, ville de involverede parter både have pladsproblemer og svært ved at begå sig i dokumenterne. 

Citatet herunder, af Birger Nürnberg, Friis og Moltke, beskriver problemstillingen: 

”Traditionelt ville man vise typeoversigter til de bydende i 1:200, men for et projekt af en kaliber 

som Musikkens Hus, vil 200dels-planerne hver fylde 1 m x 1½ m og samlet fylde adskillige 

hyldemeter, som alle har vanskeligt ved at finde rundt i.” (Bipsnyt, 2005)


20. december 

2011 

3.2 BuildingSMART 

Til sammenligning med tidligere beskrevet analyse- og kortlægningsmetoder, har BuildingSMART 

udviklet et internationalt standardsæt, som skal give alle byggeriets parter en ensartet proces, og 

derved effektivisere forløbet. Vi vil i dette afsnit starte med et historisk perspektiv og dernæst 

beskrive BuildingSMART’s væsentligste værktøjer, deres anvendelsesområde samt hvilken rolle de 

har spillet på byggesagen Musikkens Hus. BuildingSMARTs hovedområder er: 

Industry Foundation Classes (IFC) 

Er udviklet som et fælles format der skal effektivisere udvekslingen af informationer. 

Information Delivery Manual (IDM) 

Er udviklet for at styre processen, med fokus på tidligger benævnte BPMN kortlægning. 

- Model View Definition (MVD) 

Anvendes til at definere i teknisk sprog hvilke informationer som er nødvendige i en given 

udveksling. MVD laves på baggrund af Exchange Requirements (ER). 

International Framework for Dictionaries (IFD) 

Er udviklet som en international ordbog der kan referere til nationale standarder og lign. 

Gennem afsnittet vil ovenstående punkter blive uddybet. 

3.2.1.1 Historie 

I 1994 iværksatte Autodesk, under navnet Alliance For Interoprability, et industrielt konsortium 

som skulle rådgive virksomheder i udviklingen af et sæt C++ klasser (multiparadigmatisk programmeringssprog). 

Udover Autodesk tilsluttede der sig tolv andre amerikanske virksomheder til 

konsortiet. I 1995 åbnede konsortiet sig op for alle internationale parter og skiftede navn til International 

Alliance for Interoperability (IAI). Efterfølgende omdannede IAI sig til en nonprofit organisation, 

og skiftede i 2005 igen navn til BuildingSMART. I dag er BuildingSMART repræsenteret i 

35 lande, og har til formål at skabe fælles standarder indenfor IKT i byggeriet. Visionen bag foreningen 

er at skabe åbne internationale standarter og neutral teknologi for at fremme en effektiv 

informationsflow gennem et byggeris livscyklus. Dette skal imødekommes gennem IFC, IFD og 

IDM, som er BuildingSMARTs hovedområder. Igennem dette kapitel vil disse tre standarder blive 

uddybet. 

3.2.1.2 Model Support Group (MSG) 

MSG er en gruppe af eksperter, der udvikler, tester og vedligeholder buildingSMART datamodelstandarder. 

Hovedformålet med MSG er en løbende udvikling, forbedring og vedligeholdelse af 

IFC specifikationen samt støtte implementering i IFC-kompatibel software. Hertil kommer, at MSG 

har ansvaret for at koordinere MVD, som er beskrevet i afsnittet IDM. Relaterede specifikationer, 

såsom IDM, og IFD, er også understøttet af MSG i samarbejde med andre teams. 

MSG arbejdsopgaver: 

Udvikling af teknisk køreplan for IFC specifikation, herunder indstilling af strategiske og tekniske 

mål for IFC specifikationens arkitektur. 

Konsolidere og integrere nye model specifikke krav, fremsat af IFC pioneer projekter. 

31

20. december 

2011 

32 


Løbende arbejde for at opretholde IFC-modellens specifikation, forbedre dens dokumentation 

og indholdet af dens properties. 

Vedligeholde en ERFA-database, korrigere fejl til kommende IFC frigivelser. 

Publicere, koordinere og harmonisere buildingSMART Internationale Model View Definitions. 

Arbejde med implementerings guider, model guider, tutorials, læsevejledninger, og andre 

ledsage dokumenter. 

Støtte arbejdet i ISG og hjælpe med udgivelsen af implementeringsaftaler. 

Samarbejde med andre buildingSMART komiteer og støtte udviklingen af andre buildingS- 

MART standarder som IFD og IDM-aktiviteter. 

Samarbejde med eksterne standardiserings grupper for at harmonisere IFC-definitioner med 

andre ISO-standarder. 

General MSG koordineringsaktiviteter, herunder regelmæssige møder og web-konferencer. 

(Liebich, 2011) 

3.2.1.3 Implementation Support Group (ISG) 

ISG er oprettet for at støtte implementeringen af buildingSMARTs standarder hos softwareudbyderne 

for derefter at certificere dem. Arbejdet ligger hovedsageligt omkring IFC import/eksport 

funktionen. Alle medlemmer af buildingSMART har mulighed for at benytte ISG. 

Formålet med ISG er: 

At støtte og koordinere brugen af IFC import / eksport funktionen hos de implementerende 

softwarevirksomheder. 

At administrere et forum for erfaringer med udveksling og implementeringen af IFC import / 

eksport funktionen, samt varetagelse af tekniske problemer. 

At promovere fordele ved IFC implementering. F.eks. ved demonstration og deltagelse i forskellige 

messer for derved at kommunikere fordelene ud til slutbrugeren. 

At varetage certifikationsprocessen, i samarbejde med MSG, for IFC import / eksport funktionen 

hos softwarevirksomheder. 

At overvåge implementeringen af IFC import / eksport funktionen hos softwarevirksomhederne 

og rapportere videre til andre grupper i buildingSMART organisationen. 

At repræsentere implementerende virksomheder og deres interesser i buildingSMART organisationen. 

(Liebich, 2011)


20. december 

2011 

3.2.2 Industry Foundation Classes (IFC) 

IFC er udviklet som et åbent fælles dataformat, der gør det muligt at udveksle og dele data mellem 

forskellige applikationer, af forskellige producenter indenfor BIM. IFC er specifikt udviklet som 

et værktøj til at udveksle modelbaseret data imellem modelbaserede applikationer i byggebranchen. 

I dag er formatet delvist understøttet af langt de fleste større udbydere af BIM applikationer 

til byggebranchen. 

Formålet med IFC er: 

At sikre, at data bliver globalt tilgængelige. 

At overføre geometrisk data mellem de projekterende. 

At overføre produktdata til projekterende, udførende og bygningsejere. 

At overføre data fra bygningsmodel til analyseprogram. 

At anvende IFC data i produktionen hos de udførende. 

At langtidsopbevare bygningsmodeller. 

At kombinere egne data med et fælles accepteret format (Bips, 2004). 

3.2.2.1 EXPRESS 

IFC formatet er baseret på EXPRESS metasproget samt en E-R model, hvilket desuden giver mulighed 

for at udvide koden med nye entities efter behov. EXPRESS sproget er formaliseret i ISO standarden 

STEP, hvilket er en international standard for repræsentation og udveksling af produktdata, 

der kan fortolkes af en computer. STEP blev påbegyndt af ISO tilbage i 1984 for at centrere 

dele af deres arbejde på standarder omhandlende repræsentationen og udvekslingen af produktinformationer 

generelt. Mange af de involverede aktører i STEP indså, at byggebranchen havde 

brug for et mere branchespecifikt format, som kunne repræsentere bygningsmodeller. 

3.2.2.2 IFC arkitekturen 

IFCs Datamodel er en kompleks størrelse. Den er skabt som et redskab til byggesektoren, men 

repræsenterer ikke kun fysiske elementer som f.eks. vægge, døre, bjælker osv., men også mere 

komplekse størrelser som f.eks. aktiviteter, områder, organisation og priser. Begge former for 

elementer kaldes ”entities”. Den implementerede og anvendte udgave, IFC 2x3, har i alt 653 entities, 

hvilket betyder, at den repræsenterer 653 forskellige typer af komponenter eller koncepter. 

Med regelmæssige udgivelser af nye versioner, senest 2x3 og 2x4, har udviklingsarbejdet været 

undervejs i flere år. Den første version af IFC, version 1.0, blev udgivet i 1997. Den nyeste version, 

IFC 2x4 Candidate 3, er netop frigivet til test, oktober 2011. For hver udgivelse tilføjes nye funktioner 

i form af flere ”entities” og flere ”relationships” relateret til en bygnings livscyklus. Udviklingen 

af IFC-modellen varetages af buildingSMARTs Model Support Group (MSG), som i dag ledes af 

Thomas Liebich. (Liebich, 2011) 

Arkitekturen i IFC-modellen er groft illustreret på Figur 9, som viser hvordan modellen er konstrueret 

og opdelt. I bredeste perspektiv kan IFC-modellen adskilles i fire lag (Domain Layer, Interoperability 

Layer, Core Layer og Ressource Layer) som hver især repræsenterer et forskelligt niveau i 

modellen. Hvert niveau består af flere forskellige koncepter og i hver koncept-kategori er flere 

33

20. december 

2011 

34 


entities defineret. De grønne viser koncepter som er certificeret efter ISO-standarden, og de 

orange er udvidelser som ikke er certificeret. 

Domain Layer: 

Domain Layer er det højeste 

niveau i IFC-modellen, og består 

af entity definitioner for 

koncepter som er specifikke 

iht. individuelle domæner, 

såsom arkitektur, statik, facility 

management, etc. Eksempler 

på dette kunne være et 

rumskema til arkitekten; sokler, 

vægge og dæk til ingeniøren 

eller kedler, rør og radiatorer 

til VVS osv. 

Interoperability Layer: 

Interoperability Layer består af 

entities i flere koncepter, som 

er almindeligt brugt og delt 

imellem parterne i hele byggeprojektets 

livscyklus. ”Shared 

Building Elements”skemaet 

har entity definitioner 

for bjælker, søjler, vægge 

osv. ”Shared Building Services Elements”-skemaet har entity definitioner som flowkontrol, lydegenskaber 

osv. 

“Shared Facilities Elements”-skemaet indeholder entities for driftegenskaber omkring bygningen. 

Figur 9 - Viser et diagram over IFC2x3s arkitektur. 

Core Layer: 

Core Layer indeholder entities som repræsenterer abstrakte begreber, som bliver brugt til at definere 

entities i de højere lag. ”Kernel” skemaet repræsenterer f.eks. aktører, grupper, processer, 

produkter, forhold, etc. ”Product Extension” skemaet definerer abstrakte byggekomponenter som 

rum, grund, bygning, bygningselement, annotationer osv. De andre to skemaer definerer processer 

og kontrol, som er relaterede koncepter, som procedurer, arbejdsplaner, arbejdsgodkendelse, 

etc. 

Resource Layer: 

Dette lag indeholder kategorier af entities som repræsenterer basale egenskaber, såsom geometri, 

materiale, kvalitet, mål, data, tid, pris osv. Grunden til at disse entities ligger i dette lag er at de 

er generiske og de ikke er specifikt til brug i byggebranchen. De fungerer som en ressource som 

bruges til at definere egenskaber i entities i højere lag.


20. december 

2011 

IFC-modellens modulære design 2 har til formål at gøre modellen lettere at vedligeholde samt at 

videreudvikle. IFC-modellens lagstruktur er udformet på en sådan måde, at en ”entity” på et givet 

niveau kun kan relatere til, eller være reference til en enhed, på samme niveau eller på et lavere 

niveau, men aldrig en enhed på et højere niveau. Eksempelvis indgår en vægenhed (kaldet 

IFCWall) i ”Shared Building Elements” som igen tilhører ”Interoperability Layer”. 

Diagrammet er yderligere opdelt i farverne orange og grøn. Den grønne del markerer ISO/PAS 

16739, som betyder at områderne er blevet certificeret af International Standards Organisation 

(ISO). For at opnå denne certificering, skal modeldefinitionerne opnå bestemte og fastsatte kriterier. 

ISO Certifikationen blev tildelt i 2002, hvilket var kritisk for IFC, da det indebærer en bestemt 

kvalitet og niveau af stabilitet, hvilket gør det nemmere for private som offentlige virksomheder, 

at indfører det som en standard. (Khemlani, 2011) 

Entity definitions 

Som tidligere beskrevet består arkitekturen af en EXPRESS-baseret E-R metode, der består af 

mange hundrede entities der er organiseret i et objektbaseret ”inheritance hierarchy”. Dette hierarki 

hjælper med at minimerer redundans og skaber rammerne og relationer imellem de forskellige 

entities. 

Hvis vi f.eks. følger en ”wall entity” og en ”space entity”, hvilke er to af de mest benyttede basis 

komponenter i et hvert byggeri. Er det vigtigt at se hvordan de er repræsenteret, dels individuelt, 

dels med hinanden. Ydermere er det kritisk at man ser hvordan de relaterer til hinanden, altså 

hvilke wall entities er forbundet til hvilke space entities. Når en wall entity er forbundet med andre 

entities som f.eks. en ”roof entity”, en ”slab entity”, en ”column entity”, en ”beam entity” osv. 

defineres den ved et ”entity hierarchy”, som vist i Figur 9. 

Dette betyder at ”wall entity” (IFCWall) definers som en undertype af ”Building Element entity” 

(IFCBuildingElement) som igen er en undertype af ”Element entity” (IFCElement) og så videre hele 

vejen op til Root entity (IFCRoot). 

Wall entity 

IFCWall arver sine ”attributes” fra den ovenstående entity i hierarkiet, i dette tilfælde fra IFCBuildingElement 

Det kaldes Supertypes. I eksemplet er IFCWalls ovenstående niveauer abstrakte, 

hvilket betyder at de ikke kan ses visuelt i bygningsmodellen. Disse entities er lokaliseret i IFC’s 

Core Layer, se Figur 9. Som man kan se af Figur 10, er IFCWall ikke abstrakt og dermed repræsenteret. 

IFCWalls attributter er defineret af den supertype (den har altså arvet; type, form, placering, 

mængde, tilslutninger, åbninger, osv.) 

2 Modulært design er en tilgang som opdeler et system i mindre dele (moduler), der selvstændigt kan udvikles og anvendes i forskelli- 

ge systemer. 

35

20. december 

2011 

36 


Figur 10 - Viser definitionen på en wall entity og en space entity og relationen 

imellem dem. 

Space entity 

IFCSpace er ligeledes defineret af 

”entity hierarchy” som det ses på 

Figur 10. IFCSpace er en ”subtype” 

af IFCSpatialStructureElement 

som igen er en “subtype” af 

IFCProduct. Ligesom ved IFCWall 

eksemplet er IFCSpace ovenstående 

entities abstrakte. Forskellen 

til IFCWall er at IFCSpace har 

foruddefinerede attrubutes, men 

modtager sine properties fra 

ovenstående entity. Dette er 

gældende idet et space (rum) 

altid er defineret ud fra givne 

rammer i form af vægge, lofter, 

dæk osv. 

Der findes forskellige typer af 

”relationships” til at lave relationer 

mellem de forskellige entities. 

F.eks. kan en “aggregation 

relationship” relater flere “space 

entities” sammen til en etage og et ”containment relationship” kan relatere et møbels placering 

til et rum. Hvis der er krævet at en væg skal relateres til et rum, kræver den det specifikke ”containment 

relationship” IFCRelContainedInSpatialStructure. Som det ses på Figur 10 opererer dette 

”relationship” på samme niveau som IFCElement og IFCSpatialStructureElement, som betyder at 

hvilket som helst element (væg, bjælke, søjle, dør, osv.) kan blive relateret til hvilket som helst 

sted i bygningen eller dens omgivelser (grund, bygning, etage, rum). 

Ansvaret for at disse relationer er lavet ordentligt og fungerer på rigtig vis, ligger ifølge brancheforeningerne 

udelukkende ved softwareudbyderne af programmerne som rummer en IFC eksport/import 

-funktion. Det giver IFC-modellen større fleksibilitet, hvis man undlader kravet om at 

f.eks. en væg skal være relateret til et specifikt rum, men i stedet til en etage, bygning eller grund. 

Dette giver på samme tid en problemstilling. Fleksibiliteten er begrænset af, hvad der er tilladt 

indenfor IFC specifikationen. Dette vil altid være afvejning af fleksibilitet, kontra driftssikkerhed. 

Driftssikkerheden vil variere, afhængig af muligheden for at ændre i tingene. 

Hvis en anden BIM-applikation senere i processen skal tolke IFC-filen og forventer netop ”relation 

med et rum” og denne relation ikke på forhånd er skabt i filen, sker der misfortolkninger og man 

opnår ikke en korrekt udveksling. Derfor er det meget vigtigt at hver enkelt applikation eksporterer/importerer 

IFC-filen efter samme forskrift. Dette er en bestemmende faktor for hvor succesfuld 

IFC udvekslinger bliver. (Khemlani, 2011)


20. december 

2011 

Entity definitioner i IFC 

På det abstrakte niveau, inddeler IFC alle entities i ”rooted” og ”non-rooted” entities. Rooted entities 

stammer fra ”IFCRoot” og har identitet konceptet, hvilket betyder at en entity har en ”GUID” 

(Globally Unique IDentifier) sammen med ”attributes” for et navn, beskrivelse og revisionskontrol. 

”Non-rooted” entities har derimod ikke nogen identitet og eksisterer kun hvis de bliver refereret 

til fra en intity eller flere entities. IFCRoot (hele IFC skemaet) er underopdelt i tre abstrakte koncepter: 

IFCObjectDefinition definerer materielle objektforekomster og typer. ”IFCObject” definerer objektforekomster 

som f.eks. ved en produktinstallation som har et serienummer og en fysisk placering. 

”IFCTypeObject” definerer typedefinitioner (eller skabeloner), som f.eks. en produkttype der 

har et modelnummer og en generel form. Forekomster og typer er yderligere underopdelt i 6 

fundamentale koncepter: 

actors (”who”) 

Repræsenterer personer og organisationer. 

controls (”why”) 

Repræsenterer regler som kontrollerer tid, udgifter eller omfang. 

groups (”what”) 

Repræsenterer samlinger af objekter til et specielt formal så som elektriske kredsløb 

products (”where”) 

Repræsenterer forekomster i rum, så som fysiske byggeelementer og rumlokationer. 

processes (”when”) 

Repræsenterer forekomster I tid, så som opgaver, begivenhed og procedurer. 

resources (”how”) 

Repræsenterer brug af noget der har begrænset rådighed, så som materialer, mandskab og 

maskiner. 

IFCRelationship definerer relationer mellem objekterne. Der er 5 fundamentale relationstyper 

mellem objekter: 

IFCRelDecomposes 

Indikerer at en entitet består af en eller flere dele af andre entiteter. 

IFCRelAssigns 

Fanger forholdet hvor et objekt omslutter en service af et andet objekt, så som en mandskabs 

ressource der er sat på en opgave der er sammenflettet med et bygnings element. 

IFCRelConnects 

Indikerer sammenslutningen imellem objekter såsom betondæk der ligger af på en stålbjælke, 

eller et rør der er sat sammen med en håndvask. 

IFCRelAssociates 

Indikerer en ekstern reference for et objekt så som et eksternt IFC biblioteks film hvor et 

object er defineret. 

IFCRelDefines 

37

20. december 

2011 

38 


Definerer en instance, af et forhold, så som et rør segment af en speciel type. 

IFCPropertyDefinition difinerer dynamiske ”properties” i objekterne. Et ”property set” indeholder 

et eller flere ”properties” som kan være en enkelt værdi (f.eks. string, nummer eller måle enhed), 

en bunden værdi (Som har et maksimum og et minimum), en tabel med værdier eller data struktur. 

Mens en IFC definerer flere hundrede ”property sets” for specifikke typer, må brugerdefinerede 

”property set” blive defineret af applikationsudbyderne eller slutbrugeren. 

IFCPropertySet 

Repræsenterer et sæt af egenskaber der er sat sammen med en forekomst eller en objekt type. 

IFCPropertySetTemplate 

[IFC2x4] fanger definationer af egenskaber og deres datatyper. (Wikipedia, 2011) 

3.2.2.3 Certificering IFC-applikationer 

Indtil til nu har certificeringen af IFC import/eksport foregået gennem flere workshops, hvor de 

forskellige softwareudviklere skulle gennemgå to trin. 

Trin 1. 

Skulle hver enkelt softwareudvikler vise at deres applikation kunne håndtere et specifik Model 

View gennem en eller flere workshops. 

Trin 2. 

Skulle softwareudviklerne teste deres applikationer, gennem selvvalgte brugere. Dette skulle 

gøre det muligt at korrigere evt. fejl og derved give slutbrugeren et bedre produkt. 

IFC Certificering 2.0 

BuildingSMART udviklede i 2010 en ny certificeringsmetode til at forbedre kvaliteten og servicen 

for deltagende softwareudviklere. Certificeringsmetoden er skabt til at fremme en mere konsekvent 

og pålidelig implementering af IFC import / eksport funktionen hos softwareudviklere. Dette 

sker gennem en række kvalitetssikringsværktøjer, testcases i eksport / import med forskellig 

kompleksitet og adgang til et team af eksperter (ISG / MSG). 

IFC certificering 2.0 ”online certification server” giver softwareudviklerne svar på følgende 

spørgsmål: 

Virker IFC i den anvendte softwareapplikation. 

Virker IFC i den anvendte proces. 

Hver enkelt certificering er styret af certificeringsmetode 2.0 og gælder for en bestemt delmængde 

af IFC skemaet (MVD som beskrives i et senere afsnit).

Diagram 8 - Viser et BPMN over en certifikation. 


”The Coordination View Version 2.0” er BuildingSMART 

International først udviklede ”View definition” og den 

mest benyttede view af IFC skemaet. Formålet med 

”Coordination View” er at muliggøre informationsudveksling 

mellem de forskellige discipliner (Arkitekt, 

Ingeniør og Facility Management). Det skal være muligt 

at tilføje og ændre i de importerede informationer 

gennem applikationen. 

”Coordination View Version 2.0” er valgt som den første 

MVD der skal certificeres under den nye certificeringsmetode 

”Certification 2.0”. 

20. december 

2011 

Model 1 - Viser ideologien bag Coordination View Version 

2.0. 

39

20. december 

2011 

40 


3.2.2.4 IFC og BIM / Case 

IFC fra BuildingSMART er uden tvivl det mest seriøse bud på et fælles filformat. Niels Treldal fra 

Rambøll udtaler til ingeniøren, at; 

“IFC ser ud til at være det eneste rigtige at bruge. Jeg opdagede, at formatet i dag kan 

håndtere langt over halvdelen af de informationer om bygningen, som der er behov for …, 

… der sker ikke en videreudvikling af IFC, så det bliver mere attraktivt for byggebranchen, 

hvis der ikke er en efterspørgsel. Derfor må branchen frem i skoene.” (ingeniøren, 2008) 

Nødvendigheden for en fortsat udvikling af formatet forklares ved den begrænsede anvendelse i 

det daglige. Ofte bruges IFC kun til kollisionstest, hvor der ikke er behov for at sende data retur til 

modellen. 

På Musikkens Hus er der, ifølge Per J. Andersen Thorsager (økonomiansvarlig på byggepladsen), 

ikke anvendt IFC til udveksling og parternes bygningsmodeller. Dels fordi IFC ikke var udviklet da 

cadmanualen til projektet blev udarbejdet, og dels fordi der, ifølge Per J. A., er for mange komplikationer 

og mangler relateret til formatet. (Niras F. &., 2011) 

3.2.3 Information Delivery ManuaI (IDM) 

IDM har til formål at afdække hvem aktørerne er, og hvilke informationer der skal udveksles mellem 

parterne i en byggeproces. Ydermere beskriver IDM hvor i faserne den nødvendige information 

skal udveksles. BIPS tegner i nedenstående citat, et billede af hvor mange aktører / aktiviteter 

der er i en byggeproces. 

”I løbet af en byggeproces skifter et væld af informationer hænder. Der arbejdes 

med arealer, priser, tidsplaner, tegninger og meget andet, og disse udveksles mellem 

arkitekt, ingeniører, entreprenører og bygherre. Men der er behov for, at alle 

dataleverancer sker på en systematisk og standardiseret måde, så den enkelte aktør 

ved, både hvad han/hun skal aflevere og kan forvente at modtage på et givent 

tidspunkt.” (BIPS) 

IDM kan bidrage til at optimere BIM, således den nødvendige information og kvalitet foreligger på 

det rigtige tidspunkt. For at illustrerer en IDM proces benyttes Figur 11 og 12 fra ISO 29481. Figur 

11 illustrerer et ”Informations skema” som dækker hele projektets fulde livscyklus, og dermed alle 

informationerne i et byggeprojekt. Måden IDM fungere på er at definere relevante informationer 

på rette tidspunkter som er illustreret i Figur 12. Her ses at informationerne bliver udvekslet gennem 

ER som er en række krav der beskriver hvad hver enkelt virksomhed skal bruge for at udføre 

deres rolle i projektet på et givent tidspunkt i byggeprocessen.

En IDM indeholder 3 bærende elementer: 


20. december 

2011 

Process Maps 

Process Maps har til formål at beskrive aktiviteterne indenfor de enkelte områder i projektet. 

Området beskrives i det efterfølgende afsnit. 

Exchange Requirements (ER) 

Er en beskrivelse af hvad der skal udveksles mellem aktørerne gennem projektets faser. Området 

beskrives senere i rapporten. 

Functional parts 

Er dele af informationer der tilsammen eller enkeltvis udgør en ER. 

3.2.3.1 Process Maps. 

Formålet med Process Maps er, at beskrive flowet af informationer og aktiviteter indenfor et defineret 

projekt. Det er derfor vigtigt, at alle aktører i fællesskab har fastlagt hvilke informationer 

de skal bruge gennem projektet og ikke mindst hvornår. Dette kræver en høj disciplin, i det hver 

enkelt aktør skal arbejde efter en overordnet struktur. Process Map indeholder: 

Mål 

Specifikke input (typisk krav fra andre udvekslingsprogrammer og datakilder). 

Særlige resultater (typisk krav til andre udvekslingsprogrammer). 

Brugerressourcer. 

Figur 11 - Viser et projekts fulde livscyklus. Figur 12 - ´Viser en IDM proces. 

En række aktiviteter, der udføres i en vis orden. 

Påvirke mere end én organisatorisk enhed. 

Skaber værdi for kundernes behov. 

Det er vigtigt, at alle aktiviteter i processen bliver etableret i logisk rækkefølge, og alle ER identificeres 

for at skabe en effektiv proces. IDM Process Map kan med fordel udarbejdes som et traditionelt 

BPMN. Grundene til, at dette kan være fordelagtigt er: 

Det støttes af organisationen OMG, som er et konsortium indenfor objektorienteret programmering. 

41

20. december 

2011 

42 


Det bliver brugt i stigende grad indenfor specifikationer og indenfor forretningsprocesser i 

større projekter. 

Der findes utallige simple og gratis softwareløsninger på internettet. 

Notationen har en omregningsmetode til BPEL, som er en standard indenfor forretningsprocesser 

med webservice. 

I dette kapitel er der anvendt softwaren, BiZagi, til at udføre diagrammerne, dette er et af de 

mange freewareprogrammer der kan hentes på internettet. (http://www.iai.no). 

Eksempel på Process Maps 

I dette afsnit vises der eksempler på hvordan Process Maps kan se ud og hvilke informationer de 

kan indeholde. Nedenstående Diagram 9 er lavet for installationsingeniørens proces. 

Diagram 9 - Viser installationsingeniørens overordnet Process Map. 

I Process Map, Diagram 9, kan man se de overordnet procestrin indenfor installationslivscyklussen. 

1. Planlægning af installationssystem. 

2. Design af installationssystem. 

3. Installation af installationssystem. 

4. Test af installationssystem. 

5. Drift af installationssystem. 

6. Vedligehold. 

Mellem opgaverne indføres handlinger eller krav, som skal være fortaget inden informationerne 

kan overgå til næste opgave. Man kan se i designfasen, at der er indtegnet handlinger mellem de


20. december 

2011 

forskellige arbejdsgange. I dette eksempel beskriver handlingerne, koordineringen af resultaterne, 

som enten kan resulterer i en godkendelse eller kassering. Pilene der går tilbage til den forrige 

arbejdsgang viser, at resultaterne evt. også kan sendes tilbage og blot ændres. 

I Process Map Diagram 10 som viser ”2.0 Design af installations system”, går vi dybere ind i processen. 

Her er flowet for udarbejdelsen af designet specificeret, dette giver de projekterende et 

overblik over arbejdsprocessen og fastlægger hvornår designet skal koordineres. 

Diagram 10 – Viser Process Map for ”Design af installation system”. 

Der hvor Process Maps virkelig kan hjælpe de projekterende, er i det projekterings forløbet, som 

er vist for ”2.1 Planlægning af design forløb” i Process Map, Diagram 10. Her kan man se hvilke 

krav og regler der stilles til udvekslingsforløbet, dette skal være med til at effektivisere og mindske 

fejl. 

43

20. december 

2011 

44 


Diagram 11 - Viser installationsingeniørens analyse periode. 

Herunder er der beskrevet hver enkelt opgave: 

Projekt analyse: 

Opgave 2.1.1 viser hvilke informationer der skal til for opstart af denne fase. Som der er vist, er 

der vurderet, at der skal bruges informationer fra BIM modellen samt virksomhedens projekt 

guide. Projektguiden skal her forstås, som en guide hvor der er samlet oplysninger fra tidligere 

projekter. Informationer fra BIM modellen, er de informationer der er tildelt netop dette område i 

tidligere faser. 

Overslag af pladskrav og tekniske områder: 

Opgave 2.1.2 viser hvilke informationer/krav der skal bruges for, at udarbejde et overslag af 

pladskrav og tekniske områder. Informationer og krav er i dette tilfælde bygherrekrav, BR10 og de 

tekniske data der er vurderet, at skulle anvendes på dette tidspunkt i forløbet. 

Definer speciale områder: 

Opgave 2.1.3 viser at evt. specialområder i processen bliver udarbejdet ud fra byggeprogrammet. 

Aftal tekniske områder for videre projektering: 

Opgave 2.1.4 viser hvilke informationer der skal bruges for, at fastlægge hvor og hvordan den 

fremtidige projektering skal forløbe, dette kunne f.eks. være en større virksomhed der har forskellige 

afdelinger med forskellige speciale områder. Dette skal i dette tilfælde som vist udarbejdes ud 

fra firmaets struktur og opbygning.


20. december 

2011 

Prisoverslag: 

Opgave 2.1.5 viser hvilke informationer der skal bruges for, lave et prisoverslag for projektet. I 

dette tilfælde bliver overslaget udarbejdet ud fra V&S og tidligere erfaringer der er gjort i lignende 

projekter. Forinden denne opgave er der lavet en koordinering for hvilke informationer fra forgående 

opgaver der skulle ligge til grundlag for beregningen. (Wix) 

Sammenfatning 

Process Maps skal bruges som et værktøj til at effektivisere og fastlægge, proces -og informationsflow 

igennem et projekt. For at dette skal kunne lade sig gøre, skal der fra start laves grundige 

analyser af alle implicerede parters behov og processer. Udover dette skal de implicerede parter 

arbejde disciplineret, for at skabe det optimale resultat. 

Eksemplerne i kapitlet har givet indblik i hvordan Process Maps kan være udformet. Dette er selvfølgelig 

ikke et facit, da ingen projekter er ens. Der vil dog altid være nogenlunde samme strategi, 

for hvert enkelt firmas interne arbejdsprocesser, som f.eks. ”2.1 Planlægning af design forløb”. 

3.2.3.2 Exchange Requirements (ER) 

ER repræsenterer forbindelsen mellem 

proces og data (Informations model). Relevante 

oplysninger defineres i informationsmodellen 

til at opfylde kravene i en 

informationsudveksling mellem to forretningsprocesser 

på et bestemt tidspunkt i 

projektet. 

ER er en klar beskrivelse af de bestemte 

oplysninger, der skal udveksles på et givent Figur 13 - Illustrerer processen med ER. 

tidspunkt i et projekt. Det er hensigtsmæssigt at beskrive ER i ikke-tekniske termer. Den primære 

målgruppe for ER, er de implicerede aktører (arkitekt, ingeniør, konstruktør, osv.). Dog bør de 

også bruges af softwareudbyderne, eftersom de er nøglen til udvikling. 

ER indeholder følgende oplysninger: 

Fase / faser for, hvor et ER bliver brugt i processen. 

En oversigt der angiver indholdet og målet med udvekslingskravet, skrevet i en ikke-teknisk 

terminologi. Brugeren skal være klar over hvad udvekslingskravet dækker over og hvordan 

man akkvirerer den rigtige information, men han behøver ikke at kende konkrete tekniske detaljer 

i kravet. 

ER kan være enkle, som f.eks. en ordre, der medfører at 

en købsproces gør det muligt for en leverandør, at levere 

de nødvendige komponenter. Alternativt kan det 

være komplekst som f.eks. at en arkitekt skal give en 

grundlæggende bygningsmodel til en VVS-konsulent for 

Figur 14 - illustrerer processen med ER. 

45

20. december 

2011 

46 


at muliggøre en termisk analyse og dertilhørende beregninger. Figur 14 illustrerer et ER i et Process 

Map. 

ER kan opdeles i følgende: 

Header section indeholder administrative oplysninger omkring udvekslingskravet, dette omfatter: 

Navn 

Et navn eller en titel til ER. Dette bør være i overensstemmelse med IDMs navngivnings regler. 

Identifier 

En ”unique identifier” bliver tildelt til et udvekslingskrav. 

Change log 

”Change log” eller ændringslogbog bruges til at markere oprettelsen af ER og har til formål at 

registrere foretagede ændringer over tid. Datoen for oprettelse / ændring bør indgå sammen 

med et id for den ansvarlige person og en kort beskrivelse af hvilke ændringer der er fortaget. 

Project stage 

”Project stage” identificerer projektets fase/faser hvor ER anvendes. ER kan gælde for et eller 

flere af projektets faser. Der bør tages hensyn til tildelingen af ER til projektfaser, da disse oplysninger 

kan være af betydning for proces udbydere og vil være vigtigt for den fremtidige udvikling 

af proces-standarder ved hjælp af udvekslingskrav. 

Projektfaser bør anvendes konsekvent på alle udvekslingskrav. IDM bruger en liste over de faser 

baseret på udvikling af Generic Process Protocol. 

Herunder ses et eksempel på en header section: 

Tabel 1 - Viser et eksempel på Header Section. 

Overview section angiver mål og indhold af et ER som er kendt af aktøren. Målet er at aktøren 

skal være klar over, hvad der opnås med et ER, men ikke behøver at kende de tekniske detaljerne


20. december 

2011 

for, hvordan det opnås. Den resterende del af ”overview section” bør udvide diskussionen og gøre 

formålet med et Process Map klart. Et eksempel på en overview section findes herunder: 

Uddrag 1 – af en Overview section. 

47

20. december 

2011 

48 


Information section opdeler de tekniske oplysninger der kræves af et ER. Det er teknisk i den 

forstand, at det giver de nødvendige oplysninger omkring tekniske aktioner indenfor projektet og 

ikke i den forstand, at det giver en detaljeret oversigt over informationsstrukturen der kræves af 

en softwareløsning. 

Oplysningerne leveres i et sæt Information units hvilke der er nødvendige for at opfylde et ER. En 

Information unit beskæftiger sig typisk med en bestemt type af oplysninger eller begreber såsom; 

det samlede projekt, vægge, vinduer m.v. Herunder i Tabel 2, vises et udsnit af en Information 

Section: 

Tabel 2 :- Uddrag af Information Section.


20. december 

2011 

3.2.3.3 Functional Parts 

Functional Parts er en detaljeret beskrivelse af de informationer, der bruges til at understøtter ER. 

Functional Parts beskriver således handlingerne der udføres gennem et ER. Hver enkelt Functional 

Part, kan stå alene som en fuld beskrevet informationsmodel, ligesom den også kan være en del 

af en samlet informationsmodel. 

Figur 15 viser sammenhængen mellem Exchange Requirements og Functional Parts. 

Functional Parts udgør de processer og handlinger, som udføres af hver enkelt aktør. En handling 

indeholder en del af eller alle informationer der udgør et Exchange Requirement. Dette vises på 

Figur 15, hvor Exchange Requirement, exchange_building_model, indeholder model_wall, model_window, 

model_door, model_slab og model_roof. 

Herunder kan hver enkelt Functional Part brydes op i flere Functional Parts. Som det fremgår af 

Figur 15, består model_door af flere Functional Parts. Functional Parts kan benyttes af flere ER. 

En Functional Part kan opdeles i følgende sektioner: 

Header section. 

Overview section. 

Result section. 

Technical section. 

Lists section. 

Schema section. 

Examples section. 

Software guidance. 

49

20. december 

2011 

50 


Header section beskriver den administrative information: 

Tabel 3 - Viser en Header section 

Overview section beskriver målet i ikke-teknisk terminologi. Selvom en Functional Part er skabt til 

softwareudviklere, skal brugerne stadig kunne tyde indholdet. 

This functional part is aimed at identification of the load bearing system(s), i.e. existing architectural information must 

be appropriately re-structured to specify all load-bearing elements. Typically it is done in early design stages and helps 

to derive structural analysis models for calculation and dimensioning. Since there is no specific class within IFC to capture 

load bearing systems, the generic class IFCSystem is used instead. For the definition of a load bearing system, which 

typically fulfills a specific task such as bearing of lateral loads, all building elements needed to carry this type of loads 

shall be contained in the system. 

Note: IFCSystem inherits a couple of kernel concepts such as unique identification, owner history, name and others. 

Consequently, the functional part is to some extend similar to other functional parts. 

Uddrag 2 - Load Bearing Systems (FP) 

Result section beskriver resultatet af målet 

A system defining a load bearing structure, which contains (via grouping) all load-bearing elements needed to fulfill this 

function. 

Uddrag 3 - Load Bearing System (FP) 

Technical section giver en detaljeret teknisk beskrivelse ved hjælp af udvalgte standarder 

Tabel 4 - Viser en Header section 

Beskrivelse og krav af de nødvendige 

informationer, specifikationer 

og værdier. 

Navn på den entity/attribute 

eller 

set/property der skal bruges 

i IFC skemaet 

Informationen skal være 

Obligatorisk (mandatory), 

Anbefalet (recomended) 

eller valfri (optional)


Lists section beskriver hvilke Entities, datatypes, functions and property der er brugt. 

Tabel 5 - Lists Section 

20. december 

2011 

Schema section presentere Functional Parts som skemaer. En Functional Part kan indeholde flere 

skemaer. Med IFC bliver tre skemaer typisk præsenteret; EXPRESS-G, EXPRESS og IFCXML. 

EXPRESS og EXPRESS-G 

EXPRESS er formaliseret i STEP (Standard for the Exchange of Product Model Data), hvilket er en 

international standard for repræsentation og udveksling af produktdata, der kan fortolkes af en 

computer. Se Diagram 12, hvor configure load bering system er vist som EXPRESS. Hvorimod EX- 

PRESS-G er den grafiske notation i EXPRESS (formal information requirements specification language), 

som er beskrevet i ISO-standarden 10303-11. Se Diagram 12, hvor configure load bearing 

system er vist som EXPRESS-G. EXPRESS-G rummer figurer for alle ikoner og symboler, der benyttes 

i EXPRESS-G-notation til oprettelse af diagrammer på enhedsniveau og skemaniveau. 

(http://office.microsoft.com) 

Diagram 12 viser et Express-G skema. 

51

20. december 

2011 

Skema 1 - Express skema 

52 


Examples section giver eksempler på hvordan Functional Part er brugt for dermed at vejlede implementeringen. 

Software guidance beskriver hvordan softwareapplikationer understøtter Functional Parts. 

3.2.3.4 IDM og BIM / Case 

IDM har i dag en meget begrænset anvendelse i Danmark, ligesom i resten af verden. Motivationen 

til at udnytte IDM, kommer først når man anvender IFC, hvilket stadig lader vente på sig. 

På Musikkens Hus har der af samme grund ikke været anvendt IDM, og kendskabet til metoden er 

i det hele taget meget begrænset hos de projekterende. (Niras F. &., 2011)


20. december 

2011 

3.2.4 Model View Definition (MVD) 

Udviklingen af MVD begyndte i 1999, af IAI og var inspireret af BLIS projektet, som er en metode 

udviklet til at konvertere EXPRESS data til XML. MVD er udviklet for at supportere og styrke IFCspecifikationen 

og fungerer sammen med IFD og IDM. MVD er det tekniske link imellem IDM og 

IFC-integrationen i softwareapplikationer. I 2005 blev MVD officielt optaget af BuildingSMART og 

godkendt til anvendelse med IFC og IDM. BuildingSMART står således for certificering og administration 

af alle MVDer udviklet af BuildingSMART og andre uafhængige organisationer, som ønsker 

en officiel anvendelse af deres MVD. 

IFC formatet dækker et kæmpe område og det er sjældent at én applikation anvender hele specifikationen 

- dels fordi de samme ting ofte kan beskrives på flere forskellige måder og dels fordi 

ikke alle funktioner er relevante. Derfor er der ofte kun implementeret de elementer af IFCspecifikationen, 

som er nødvendige for, at det pågældende program kan udføre den funktion det 

er designet til. Eksempelvis har programmer til statisk analyse ikke de samme behov som programmer 

til tidsstyring eller drift og vedligehold. 

En MVD kan betragtes som en delmængde af den samlede IFC specifikation - et ”View”/udsnit. 

For at sikre en konsekvent og ensartet IFC implementering, lader man softwareprogrammer blive 

certificeret efter MVDer, som er udviklet til et specifikt anvendelsesområde, f.eks. til energianalyse. 

View’et beskriver, iht. en specifik IFC-udgivelse, krav til udvalgte dataentiteter, som er nødvendige 

i en given IFC udveksling. Der kan bl.a. stilles krav til classes, attributes, relationships, 

property sets eller quantity definitions, som alle er elementer/entiteter i IFC-specifikationen. (BIM 

Handbook) 

MVD laves på baggrund af ER fra IDM-skemaet. Kravene oversættes til tekniske begreber og bindes 

til en specifik IFC-udgivelse (eks. IFC2x3). En specifik udgivelse er nødvendig, da der bliver 

foretaget ændringer i IFC specifikationen for hver udgivelse, hvilket kan have indflydelse på de 

elementer som indgår i MVDen. ER er, modsat MVD, ikke afhængig af en specifik IFC udgivelse. På 

Uddrag 4 ses et eksempel på en MVD beskrivelse. (buildingsmart_tech.org, 2011) 

Uddrag 4- Officiel IAI beskrivelse af MVD for Architectural Programming to Architectural 

Design. 

53

20. december 

2011 

54 


3.2.4.1 Udvikling af MVD: 

MVD er i dag baseret på EXPRESS-sproget, men der arbejdes for øjeblikket på udviklingen af en 

XML-definition kaldet mvdXML. I fremtiden er det derfor hensigten, at alle officielt godkendte 

MVD’er skal udgives i XML-formatet, for at fremme udviklingen og udbredelsen af MVDer gennem 

et format med større interoperabilitet. 

MVD’er udvikles altid på baggrund af ER fra IDM manualen. På den måde motiveres udviklingen af 

MVD’er af konkrete behov fra brugerne, og der spildes ikke kræfter på unødvendig udvikling. Udviklingen 

af MVD’er foregår derfor på to niveauer – det tekniske og det ikke tekniske, hvor det 

ikke tekniske omhandler ER modeller, og det tekniske oversættelsen til computersprog. 

En MVD samles af små ”byggeklodser”, kaldet functional parts eller concepts. Disse er små pakker 

af information, som repræsenterer en eller flere funktioner i IFC specifikationen. Koncepter kan 

anvendes enkeltvis eller kombineres i mere komplekse sammenhænge, hvor flere sub-concepts 

tilsammen danner et Concept. 

Forskellige politiske og geografiske forhold gør, at nogle funktioner i en MVD kan være forskellige 

fra region til region. For at MVD’er kan anvendes over hele verden, opfordrer IAI derfor udviklere 

til, at funktioner knyttet til regionale betingelser, laves som såkaldte extension concepts. Extension 

Concepts anvendes altid i forbindelse med andre koncepter. Dermed kan brugere gøre generelle 

Model Views specifikke for deres område, samtidig med at den generelle MVD kan anvendes 

til certificering af software. (blis-project.org, 2011) 

MVD Diagrammer 

Et MVD diagram er en visuel illustration af udvekslingskravene for data og datastruktur i en specifik 

dataudveksling baseret på IFC. Der kan laves diagrammer for alle entiteter i IFC specifikationen, 

såsom doors, spaces, MEP, systems, building, etc. 

Der findes flere forskellige programmer til at udvikle diagrammer for disse. Diagrammerne laves 

efter metoden BPMN, som er en notationsform, der anvendes til at illustrere forretningsprocesser. 

Der findes BPMN plug-ins til de mest populære udviklingsværktøjer, såsom Eclipse, Netbeans 

og Aris EXPRESS, som alle er skrevet på Java platformen. Diagrammerne bruges derefter til, at 

genere en MVD baseret på en specifik IFC specifikation. (openifctools.org, 2011) 

Figur 16 – Viser struktur i IFC specifikationen.


20. december 

2011 

3.2.4.2 Certificering af Model Views 

For at bruge en MVD skal den ikke nødvendigvis være officielt certificeret af BuildingSMART, selvom 

en certificeret MVD bliver hurtigere udbredt. Ønsker man at få sin MVD godkendt officielt af 

BuildingSMART, indsendes MVD’en, hvorefter 4 (+1, Deprecated) forskellige stadier gennemgås. 

Alle MVD starter som drafts. 

Draft 

Alle personer, organisationer og virksomheder har ret til at oprette Model Views, uden restriktioner 

og forbehold, så længe MVDen er tydeligt markeret med ”draft”. Så længe en MVD 

er i ”draft” har den ingen relation til IAI. 

Proposal 

Ønsker man at få sin MVD godkendt af IAI, markeres den med ”Proposal”, hvorefter der vil 

blive indsamlet erfaringer og foretaget små justeringer. 

Candidate 

Når en MVD markeres med ”Candidate” er den i gang med at gennemgå en validering hos IAI. 

IAI kigger på følgende kriterier: 

o Er MVDen skrevet i henhold til det officielle format?. 

o Anvendes IFC ?. 

Official 

Officiel status kan kun opnås for MVDer med Candidate status. Når mere end en softwareapplikation 

er blevet certificeret imod en MVD, med Candidate status, opnår MVDen Official status. 

Deprecated 

Når en MVD udgår efter at være blevet opdateret eller forældet, får den status som Deprecated. 

55

20. december 

2011 

56 


3.2.4.3 Anvendelse af MVD 

Softwareudviklere 

Da IFC er en meget kompleks specifikation er 

der stor variation i hvor godt IFC-integration 

fungerer fra producent til producent i de forskellige 

BIM-platforme. Problematikken ligger 

i informationstabet under udveksling og risikoen 

for fejlfortolkning af data-entiteter under 

import af IFC. Formålet med MVD er derfor 

at forbedre og dermed fremskynde implementeringen 

og brugen af IFC-integration i 

BIM-applikationer. Det er meningen, at soft- 

Figur 17 – Viser hvordan sammenhængen i mellem MVD og IDM 

er. 

wareproducenter skal kunne optimere deres egen IFC-integration, ved at kontrollere IFCeksporten, 

imod centrale Model Views, hvorefter producenter kan få certificeret deres IFC integration 

ved BuildingSMART, imod enhver MVD med Candidate eller Official status. 

Brugere 

MVDer kan være udviklet til generelle anvendelsesområder, eller rettet mod et mere specifikt 

udvekslingsbehov. 

For slutbrugere anvendes Model Views til at kontrollere og stille krav om kvaliteten af den information 

der ønskes udvekslet mellem eksempelvis arkitekt og ingeniør, på et givent tidspunkt. 

Metoden kan anvendes af både afsender og modtager, som henholdsvis afsender- og modtagekontrol. 

Som eksempel kan nævnes en MVD for ”structural analysis”. For at softwaren kan kontrollere 

om alle nødvendige informationer fra IDMen er til stede og repræsenteret korrekt i IFC 

filen, skal softwaren med IFC integration vide hvilke informationer der forventes at være indeholdt 

i IFC filen. Således skal alle informationer, som er nødvendige for at lave en statisk analyse, 

være til stede for at arbejdsprocessen kan fortsætte. Alle informationer som ikke er direkte relateret 

til den pågældende opgave kan samtidig udelades, så modellen bliver lettere at arbejde i. 

Dette gøres i programmer som Solibri eller IFC model checker, hvor MVDen indlæses sammen 

med modellen. Cuneco, center for produktivitet i byggeriet, arbejder desuden på en internetbaseret 

model-checker med samme funktioner. 

På Model 2 og 3 illustreres en arkitektmodel og 

et udtræk med Structural Analysis viewet. Det 

ses at arkitektmodellen er forholdsvis detaljeret, 

hvorimod ingeniørmodellen kun indeholder elementer 

som indgår i det statiske system. Viewet 

har desuden en call-back funktion, hvilket betyder 

at nye informationer oprettet i ingeniørmodellen 

kan føres tilbage i arkitektmodellen. 

Den første officielle MVD, som blev udviklet af 

BuildingSMART, hed Coordination View. Hovedformålet 

med dette View, er at koordinere og muliggøre 

dataudveksling mellem arkitekt, ingeniør og udfø- 

Model 3 - Viser Structural Analysis. 

Model 2 - Viser arkitektmodel.


20. december 

2011 

rende. Viewet indeholder definitioner for rumlige forhold, bygningselementer og rå-data omkring 

bygningen, som er nødvendig for at koordinere byggeriet. 

Coordination viewet er meget generelt defineret, og kaldes også en base definition. For at tilpasse 

views til projekter, er det muligt at udvide disse med extension koncepter. Det kan være nye koncepter 

eller allerede udviklede koncepter. Man tilføjer små ”dele” af andre MVD, for at gøre 

viewet specifikt for den aktuelle opgave. 

Det er intentionen at alle BIM software applikationer med IFC integration skal indeholde et eller 

flere MVDer, selvom der i dag ikke er særlig mange eksempler på dette. 

Ser man på MVD i et fremtidsperspektiv, er det sandsynligt at eksempelvis myndighederne laver 

en MVD, som beskriver alle nødvendige oplysninger I forbindelse med en myndighedsgodkendelse. 

(buildingsmart_tech.org, 2011) 

57

20. december 

2011 

58 


3.2.5 International Framework for Dictionaries (IFD) 

Til et ISO møde, i 1999, mødtes et bredt udvalg af organisationer, som udviklede standarder til 

byggesektoren. Dette møde fandt sted i Vancouver. Der var enighed om at lave nogle fælles standarder 

for byggesektoren. Disse nye standarder skulle også kunne forstås af computere, således 

det var muligt at overføre data fra én PC til en anden, på tværs af landegrænser og sprog. Det 

førte til oprettelsen af komiteen TC59/SC13/WG6. Dette samarbejde resulterede i standarden ISO 

12006-3 (Framework for Object-oriented Information Exchange). 

Efterfølgende indledte BARBi (projekt i Norge) og LexiCon (projekt i Holland) et arbejde, der skulle 

resultere i nogle standarder til byggesektoren. Begge projekter blev udviklet på baggrund af ISO 

12006-3 standarden. 

Januar 2006 blev der udformet en samarbejdsaftale i mellem BARBi, LexiCon og TC59/SC13/WG6. 

Denne aftale lagde grunden til IFD. Målet med denne organisation, var at lave en fælles ontologi 

for byggesektoren (Grant & Mehus, IFD Library Business Plan - Version 1.0, 2009). 

I 2008 blev dette samarbejde optaget i buildingSMART International organisationen. Denne gruppe 

kaldes i dag for IFD Library Group. 

Som det ses på Figur 18 ligger de brugerorienterede aktiviteter, under International User Group 

(IUG). Det er i dette forum brugernes behov og input bliver omsat til brugbare løsninger. Den tekniske 

del er placeret under ITM. 

Figur 18 - Viser hvor og hvordan IFD er placeret i buildingSMART organisationen.


20. december 

2011 

3.2.5.1 IFD Library 

IFD Library (buildingSMART ordbog) er en flersproget ordbog og/eller ontologi. I ordbogen er der 

en … 

… oppbygging av referansebibliotek som inneholder begreper med tilhørende definisjoner 

og relasjoner til andre begreper (BuildingSmart). 

Det betyder f.eks. at der er en norsk definition/beskrivelse af ”en dør”. Denne beskrivelse kan, via 

IFD API’en, oversættes til en amerikaner (et menneske) eller en amerikansk IFC fil. Dette sikre, at 

man kan kommunikere på tværs af landegrænser og definitioner. På den måde optimerer man 

informationsudveksling, både digitalt og analogt. 

Via IFD’en, er der en mulighed for at øge informationsmængden, i forhold til en standard IFC-fil. 

IFC-filen rummer ikke nødvendigvis alle de ønskede informationer, som modtagerne måtte have 

brug for. På Figur ?? ses det, hvor IFD Library kan få sine informationer fra. 

Figur 19 - Viser hvor IFD Library kan få sine informationer fra. 

Disse informationer kan tilmed blive leveret på modtagerens eget sprog. 

På Figur 19 ses et eksempel på, hvordan man kan tilføre properties/informationer. I venstre kolonne 

ses produktet. I dette tilfælde en ”Gypsum plaster board”. I kolonnen th. ses alle de properties 

der er mulighed for at tilknytte dette produkt. Kolonnen i midten viser alle de properties der 

er til valgt. Dette gøres i en ”Propertylizer”. 

59

20. december 

2011 

60 


Figur 20 - Viser hvordan man tilføjer properties/oplysninger. 

IDF Library har flere anvendelsesmuligheder. Afhængig af opgaven, kan den bruges … 

… som ”alm. Ordbog”. Dvs. at mennesker kan slå op i den, læse og forstå, det der står. 

… som ”PC-ordbog”. Dvs. at én tysk IFC export-fil, kan oversættes til en amerikansk IFC import-fil, 

i mellem 2 forskellige stykker software. 

… til hele tiden at opdaterer IFD Library 

(Bell & Bjørkhaug, http://dev.ifdlibrary.org/index.php/Ifd:IFD_for_Innovative_Sustainable_Housing). 

IFD er IKKE … 

... et klassifikationssystem. IFD kan dog indeholde flere forskellige typer af klassifikationssystemer. 

… en ontologi. IFD kan indeholde mange forskellige ontologier. 

… et alternativ til IFC. IFD er et supplement til IFC. 

(Juha Hyvärinen, 2007) 

Globel Unique Identifier/Universal Unique Identifier (GUID/UUID) 

Alle Entity’s får, via IFD’en, en Global Unique Identifier (GUID) eller Universal Unique Identifier 

(UUID). 

Det man har gjort er, at man har fjernet betydningen/informationen fra ”ordet”, og i stedet koblet 

en GUID op på ”ordet”. På den måde får man en GUID for alle koncepter, på alle sprog. Det der 

styre hvordan de forskellige koncepter relatere til hinanden, er defineret i ISO standarden 

(Bjørkhaug, 2010 ) / (Grant & Mehus, IFD Library Business Plan - Version 1.0, 2009)


Figur 21 viser hvordan dette unikke nummer bliver skabt/sammensat. 

Figur 21 - Viser hvordan en GUID/UUID bliver til, via en IFD. 

20. december 

2011 

3.2.5.2 IFD application (API - Application Programming Interface) 

I 2010 kom 2. version af IFD API’en. Den hedder v. 3.0. (første version hed 2.0.5). IFD API’en er 

lavet som en Web Services Description Language (WDSL), på EXPRESS sproget. 

I dag rummer IFD API’en 20 sprog, 15500 concepts, 67700 names, 4100 relations (Bell & 

Bjørkhaug, http://dev.ifd-library.org/images/2/23/IfcIfd1.png). 

IFD og klassifikation – DBK 

Der foregår pt. et arbejde, der skal få implementeret DBK i IFD. Dette er der et stort perspektiv i, 

da DBK så ville kunne anvendes på internationale projekter også. 

Udfordringen pt., er at få tilpasset DBK til ISO 12006- standarden (konvergens, Udviklingsplan for 

Dansk Bygge, 2010). 


Vi ser IFD som én af løsningerne (i samarbejde med IDM og IFC) på mange af de udfordringer byggebranchen 

står overfor, både nationalt og ikke mindst internationalt. Det er dog meget svært at 

se, hvor langt man er i arbejdet, og hvor langt væk man er, fra noget der ville kunne bruges. Desværre 

er vores fornemmelse, at vi er et stykke vej, fra noget der kan bruges i den virkelige verden. 

61

20. december 

2011 

62 


3.2.5.3 IFD og BIM / Case 

Projektet Musikken Hus, er et internationalt projekt. I dette forum ville en IFD være ideel, da der 

er nogle sproglige udfordringer, der skal løses (en engelsk akustiker, en Østrigsk arkitekt og danske 

entreprenører). 

Via IFD, løser man f.eks. problemet med forskellige definitioner / ontologier i byggebranchen. 

IFD blev ikke anvendt i projektet.


20. december 

2011 

3.3 Klassifikation og udveksling 

Brugen og omfanget af information, er eksploderet de seneste år. Det gælder både generelt i folks 

hverdag, men så sandelig også indenfor byggeriet. Mængden af informationer kan forekomme 

uoverskuelig, og meget svær at sortere i. Derfor er det nødvendigt at få sat informationerne i 

nogle ”kasser” og systemer. Derved bliver informationerne lettere at overskue, og dermed nemmere 

at anvende de relevante steder. Det er her klassifikation kommer ind i billedet. 

Klassifikation er vigtigt, fordi det sikrer, at vi taler ”samme sprog”, og at vi bruger de samme termer, 

om de samme ting. 

… ”Taxonomier og klassifikation anvendes overalt, hvor vi færdes i dagligdagen: i 

supermarkedet, i aviser, på biblioteket, i arkiver etc.. 

Ved klassifikation opdeles information ved hjælp af emneord efter emne, egenskab 

eller aktivitet. Disse emner grupperes i et hierarkisk system, en taxonomi, så de udgør 

en samlet struktur. Strukturen i taxonomien giver så samtidig udtryk for relationerne 

mellem grupperne.” (http://www.taxon.dk/artikler/taxonomi.htm, 2008) 

Klassifikation 

Bruger man forskellige termer og begreber, i kommunikationen, kan der meget let opstå misforståelser, 

som kan medføre fejl i vores projekt. Fejl er tit lig med ekstra omkostninger. Ekstra omkostning 

i form af tid, resurser og økonomi. Bla. derfor er klassifikation også vigtig, når vi snakker 

udveksling af informationer. Det kan være udveksling internt og eksternt, både nationalt og internationalt. 

Når vi snakker udveksling med internationale samarbejdspartnere, er det her samarbejdet 

i mellem IFD og klassifikation, kommer os til god nytte. klassifikationen sørger for at få 

ordnet og ”strømlinet” vores informationer, og IFD’en sørger for at få oversat informationerne til 

et sprog modtageren forstår. 

I byggeriet findes der flere nationale klassifikationssystemer, desværre ikke noget internationalt 

fælles anerkendt system … endnu. De nuværende systemer omfatter bla. BSAB (Sverige), DBK 

(Danmark), Uniclass (England), Omniclass (canadisk/amerikansk) og JCCS (japansk). 

Klassifikation og IFD. Det samme? 

Nej, det er det ikke. IFD er ikke et klassifikationssystem. Men IFD kan indeholde klassifikationssystemer. 

På samme måde, som IFD kan oversætte termer og koncepter fra et sprog, til et andet, 

kan IFD også oversætte fra ét klassifikationssystem, til et andet klassifikationssystem. Eks. fra DBK 

til Omniclass (DBK er ikke en del af IFD endnu, men der arbejdes på, at det bliver). 

Seneste initiativ 

September 2011, tog en dansk delegation til møde i den internationale standardiseringsorganisation. 

Målet med denne delegation var, at få revideret den internationale standard for byggeklassifikation, 

ISO 12006-2. Delegationen bestod af repræsentanter fra Dansk Standard (Jan Fuglsig 

Lambrecht), foreningen Bips (Gunnar Friborg) og Cuneco. Initiativet blev godt modtaget, og der 

var bred international opbakning til forslaget. 

63

20. december 

2011 

64 


”Forslaget fra den danske delegation går blandt andet ud på at udvikle nye tabeller 

og tydeliggøre eller omarbejde standarden, så den også giver mulighed for at klassificere 

byggeobjekter i en ”del-af”-struktur. Dvs. en struktur, hvor man kan vise, 

hvordan en given bygningsdel indgår i den mere komplekse struktur den er en del 

af. ”Del-af”-strukturen har gode anvendelsesmuligheder, når man for eksempel arbejder 

med BIM, bygningsinformationsmodellering” (Skovgaard, 2011). 

Arbejdet skal ledes af Dansk Standard, og den tilhørende projektgruppe skal sammensættes af 

internationale deltagere. Fra dansk side, har man foreslået Henrik Balslev 3 (fra Balslev & Jacobsen 

ApS), som formand for denne arbejdsgruppe 

Sideløbende med disse aktiviteter, skal Cuneco fortsætte deres udviklingsarbejde med DBK. Dette 

omfatter bl.a. flere prøveprojekter (Skovgaard, 2011). 

3 ”Henrik Balslev er formand for S-503 – et dansk udvalg for bl.a. informationsstrukturering og dokumentation – i Dansk Standard, der 

er den danske såkaldte spejlkomite til ISO SC13” (Skovgaard, 2011) .

4 Praktiske forhold 


20. december 

2011 

4.1 Hvordan foregår informationsudveksling i dag? 

Dette kapitel omhandler informationsudvekslingen på byggeprojekter, Musikkens Hus i Nordjylland. 

I denne sammenhæng er vi blevet sat i forbindelsen med Rambøll, Niras, og Friis og Moltke, 

som er projekterende på projektet. Friis og Moltke er Coop Himmelb(l)au´s danske forbindelse, 

for at skabe et projekt, der lever op til danske standarder og behov. 

4.2 Møde med parterne 

Den 24. oktober blev der afholdt et møde med Friis og Moltke, Niras og Rambøll, angående deres 

erfaringer med informationsudveksling på Musikkens Hus. Grundet den lange proces projektet 

har været igennem, har udviklingen af informationsflowet udviklet sig fra det traditionelle til et 

objektbaseret miljø. Hovedsageligt har ændringen bestået i, at parterne har udskiftet deres gamle 

2D applikationer med avancerede 3D applikationer. Denne ændring mener alle implicerede parter 

har været nødvendig, for at projekterer et så kompleks byggeri som Musikkens Hus. 

4.2.1 Informationsudveksling. 

Der er ikke stillet krav om IFC, som fælles udvekslingsformat i forbindelse med projekteringen, 

hvilket alle parter også ser som umuligt. Flere af parterne har erfaret, fra tidligere projekter, at 

brugen af IFC, ikke har været tilstrækkelig præcis, grundet applikationernes fejlbehæftede IFC 

integration. 

Projektet har været en del år undervejs. Derfor er cad-manualen ikke helt tidssvarende. Var den 

blevet lavet i 2011, var der givet andre forhold der gjorde sig gældende. DWG-formatet er det 

officielle udvekslingsformat i projekt Musikkens Hus. 

Rambøll har i samarbejde med stålleverandøren J. Langkjær Stålbyg A/S, skabt sagens mest effektive 

udvekslingsproces, idet de begge benytter Tekla Software. 

Dette gør at J. Langkjær Stålbyg A/S kan, med få rettelser, benytte Rambølls fagmodel direkte i 

deres produktion. 

4.2.2 Cad-manual 

Selvom der har været store ændringer i processen, har der ikke været grundlag for at lave store 

ændringer i CAD-manualen, da det gennem hele projektet har været 2D CAD tegninger, og dermed 

.dwg som udvekslingsformat. 

Parterne ser nærmere fremtidens CAD-manualen, som en IKT-manual, da informationer er mere 

end 2D og 3D udveksling. Rambøll har et ønske om at manualen skal indeholde krav og specifikationer 

om hvilke informationer der skal foreligge gennem de forskellige faser. 

4.2.3 BuildingSMART 

Parterne mener ikke det er muligt at benytte BuildingSMART´s værktøjer i dag, da IFCén stadig 

skaber fejl og tab ved informationsudveksling. Der er dog enighed om at ideologien bag BuildingSMART 

er noget man kan arbejde videre på, dog er man nød til at anvende det med de muligheder 

man har i dag. 

65

20. december 

2011 

66 


4.2.4 Sammenfatning 

Konklusionen på afsnittet er, at alle parter er enige om at der skal foreligge en mere struktureret 

proces, for at effektivisere anvendelsen af BIM. Før opstart skal der foreligge krav om informationsniveauer 

og standarder, ud fra parternes interne processer. 

Der er ikke anvendt IFC på trods af at både Niras og Rambøll har erfaringer fra lignende projekter, 

hvor de har kunnet benytte enkelte aspekter fra IFCén.

5 Eksport eksperimentet 


20. december 

2011 

Efter mødet med sagens parter (Niras, Rambøll og Friis & Moltke), stod det klart, at de hver især 

tidligere har oplevet udfordringer, i forhold til IFC- modellernes troværdighed. Derfor satte vi os 

for, at prøve og lave nogle tests af eksportfunktionen i forskellige typer software. Forsøgene skal 

vise de forskellige programmers evne til at eksportere en IFC – fil (IFC version 2x3). Forsøgene er 

interessante, fordi IFC er ´det filformat, som alle er enige om, skal være fremtidens udvekslingsformat. 

Testmiljø og forudsætninger 

Til forsøgene er der valgt programmerne Revit v. 2012 (Autodesk), Archicad 14 (Graphisoft ) og 

Vico Constructor 8 (Vico software). De 3 softwareplatforme har samme målgruppe mht. brugere, 

da de alle primært henvender sig til arkitektfaget/projektering. Programmerne har forskellige 

opbygninger, det gælder bl.a. måden de håndterer data på og deres brugerflade. For at sammenligne 

applikationernes eksportfunktion, er der benyttet Solibri Model Viewer. Premissen her er, at 

Solibri er en neutral aktør på markedet, og kan derfor bruges som en fælles reference. 

Forsøget er bygget op omkring en model, som indeholder nedennævnte geometri. Proceduren er 

derefter, at modellen eksporteres fra hver af de 3 platforme, og ind i Solibri. I Solibri ses resultat 

af eksporten, og eventuelle afvigelser vil kunne ses der. 

Modellen som skal eksporteres har følgende data: 

Generisk vægge (sort): 

- Bredde: 300 mm. 

- Højde: 3000 mm. 

Generisk gulv (grøn): 

- Top niveau: 0 mm. 

- Bund niveau: -300 mm. 

Vindue (brun): 

- Højde: 912 mm. 


- Placering i højde: 900 mm. 

Dør (pink): 

- Højde: 2112 mm. 


- Placering i højde: 0 mm. 

Cirkulær søjle (grå): 

- Radius: 150 mm. 

Figur 22 - Viser geometrien på forsøgsmodel. 

Placering af vindue og dør, er sat i centermidtpunkt af objekt i midten af den generiske væg. På 

samme måde er generisk gulv afsat iht. Midtpunkt i væggene. 

67

20. december 

2011 

68 


Fremgangsmåde 

Først bliver dataene, som er indtastet i de anvendte applikationer, kontrolleret, ved at se om de 

stemmer overens med dataene som er eksporteret fra applikationen. Disse findes i Solibri. 

Dataene bliver sammenlignet og der foretages en udregning på afvigelserne, som er defineret i 

kontrolmodellen i forhold til eksportmodellen. Afvigelsen er opgivet i %. Dataene som bliver hentet 

ud fra IFC modellen, som er listet op i databladet, bliver sammenholdt med beregnet kontroldata. 

Udregninger ses i Bilag 1. 

Gennem forsøget ses, hvordan geometrien bliver fortolket af de 3 anvendte platforme. Forsøget 

gennemgår tre steps: 

Step 1. 

… er at modellere modellen, i hver enkelt applikation, efter ovenstående informationer. 

Step 2 

… er at eksportere modellen til IFC formatet. 

Step 3 

… er bearbejdelsen af resultatet.

Resultat af forsøgene – visuelt: 

Revit Architecture 

2012 

Graphisoft 

Archicad 14 

Vico Constructor 

8 


20. december 

2011 

Datamodellen i oprindeligt miljø Datamodellen eksporteret til IFC 

Figur 23 - Viser det grafiske resultat, før og efter eksporten til IFC. 

69

20. december 

2011 

70 


Datablad for resultater ved forsøg: 

Generisk væg. (sort): 

- Top Elevation: 

- Bottom Elevation: 

- Geometry: 

- Area: 

- Area windows: 

- Height: 

- Thickness: 

- Volume: 

Generisk gulv (grøn): 



- Area: 

- Thickness: 

Vindue (brun): 



- Area: 

- Height: 

- Width: 

Dør (pink): 



- Area: 

- Height: 

- Width: 

Cirkulær søjle (grå): 

- Type: 

- Radius: 

- Length: 

- Skin area: 

- Volume: 

- Geometry: 

Revit 2012 Archicad 14 Vico Constructor 8 Kontrol 

3000 mm. 

0 mm. 

Extrusion 

143,45 m2 

1.01 m2 

3000 mm. 

300 mm 

43,03 m3 

300 mm. 

0 mm. 

67.68 m2 

300 mm. 

1810 mm. 

900 mm. 

1.01 m2 

912 mm. 

1110 mm. 

2112 mm. 

0 mm. 

1,93 m2 

2112 mm. 

912 mm. 

Circle Profile 

150 mm. 

3000 mm. 

2.83 m2 

0,21 m3 

Extrusion 

Tabel 6 – Viser resultaterne af forsøgene. 

+ / ÷ 

0 % 

0 % 

3,5 % 

0 % 

0 % 

0 % 

0,02 % 

100 % 

100 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

3000 mm. 

0 mm. 

Extrusion 

147,05 m2 

1,01 m2 

3000 mm. 

300 mm 

43,03 m3 

0 mm. 

-300 mm. 

67,68 m2 

300 mm. 

1810 mm. 

900 mm. 

1,01 m2 

912 mm. 

1110 mm. 

2150 mm. 

0 mm. 

1,96 m2 

2150 mm. 

912 mm. 

Circle Prof. 

150 mm. 

3000 mm. 

2,83 m2 

0,21 m3 

Extrusion 

+ / ÷ 

0 % 

0 % 

0,001 % 

0 % 

0 % 

0 % 

0,02 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

1,8 % 

0 % 

1,54 % 

1,77 % 

0 % 

0 % 

0 % 

0 % 

0 % 

3000 mm. 

0 mm. 

Extrusion 

147,05 m2 

1,01 m2 

3000 mm. 

300 mm 

43,57 m3 

0 mm. 

-300 mm. 

69,09 m2 

300 mm. 

1810 mm. 

900 mm. 

1,01 m2 

912 mm. 

1110 mm. 

2110 mm. 

0 mm. 

1,93 m2 

2110 mm. 

912 mm. 

Circle Prof. 

150 mm. 

3000 mm. 

2,83 m2 

0,21 m3 

Extrusion 

+ / ÷ 

0 % 

0 % 

0,001 

0% 

0 % 

0 % 

1,23 % 

0 % 

0 % 

2,08% 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

0 % 

3000 mm. 

0 mm. 

147,06 m2 

1,01 m2 

3000 mm. 

300 mm 

43,04 m3 

0 mm. 

-300 mm. 

67,68 m2 

300 mm. 

1810 mm. 

900 mm. 

1,01 m2 

912 mm. 

1110 mm. 

2112 mm. 

0 mm. 

1,93 m2 

2112 mm. 

912 mm. 

150 mm. 

3000 mm. 

2,83 m2 

0,21 m3


20. december 

2011 

Resultater 

Revit v. 12 (Autodesk) 

Visuelt er det tydligt, at der er sket en ændring fra vores Revit model, til IFC eksporten. Dækket er 

blevet flyttet i både X, Y og Z retningen. Geometrien på dækket, ses som uændret. Derudover ses 

det, at vægelementerne ikke har den korrekte ”Area”. Der er en afvigelse på 3,5%. 

Archicad v. 14 (Graphisoft) 

Visuelt er den eneste forskel, at der mangler en dør på IFC eksporten. Enkelte af de øvrige geometrier 

er ændret. 

Databladet viser en afvigelse i forhold til dataene på døren. Her er det parametrene Area og 

Height, der afviger. Derimod ses der næsten ingen afvigelse på vægarealet. 

En af fordelene ved Archicads IFC eksport er, at man kan eksportere dataene til en specifik modtagersoftware, 

som f.eks. Revit. Denne mulighed kan minimere fejl ved eksport til andre applikationer. 

Vico Constructor 8 

Med Vico Constructor 8, er der meget få fejl ved eksporten. Det eneste Vico Constructor har problemer 

med, er udregningen af væggenes volumen og arealet på gulvene. 


Både ud fra datene, og det visuelle, kan man se at selv en relativ simpel model, som skal eksporteres 

til IFC, kan give problemer. 

Programmernes præstationer varierede, der var afvigelser ved alle programmerne. 

Værst var Autodesk Revit, hvor dækelementet flyttede sig fra sin oprindelige placering, til udenfor 

modellen. 

Sådanne fejl får brugeren til at miste tilliden til IFC. Hvilket er meget uhensigtsmæssigt da det er 

softwareudviklerne der har ansvaret for at implementere IFC import/eksport korrekt. 

Dette bliver forhåbentlig løst gennem den nye certificering ” IFC Certification 2.0”. 

71

20. december 

2011 

72 


6 Hvordan bliver vi bedre 

6.1 Problemstilling 

I dette afsnit vil vi forsøge at give et bud på hvorfor BuildingSMARTs værktøjer – og anvendelsen 

af BIM i det hele taget - ikke er mere udbredt end tilfældet er i dag. Vi vil forsøge at identificere de 

udfordringer som knytter sig hertil, samt mulige løsninger. 

6.2 Analyse 

BuildingSMART har, som tidligere beskrevet, udviklet standarder og værktøjer til at effektivisere 

udvekslingsprocesser og samarbejdet mellem byggeriets parter. Det er en klar holdning i branchen 

at der ligger et stort uforløst potentiale i anvendelsen af disse værktøjer, om end den praktiske 

erfaring hos byggeriets parter er meget begrænset. Vi har forsøgt at identificere årsagen til 

problemet og mener at det bunder i kompleksiteten og den manglende fælles forståelse for brugen 

af værktøjerne. En mulig løsning kunne være at udvikle en applikation som kan strukturere og 

effektivisere dele af den nuværende arbejdsproces omkring brugen af værtøjer som IDM, ER og 

Process Maps. 

6.2.1 Koncept 

Konceptet for vores applikation er udviklet på baggrund af nedenstående Brianstorm, Figur 24. 

Intentionen er at inddrage så mange værktøjer som muligt, uden at gå på kompromis med brugervenligheden, 

således applikationen altid hjælper brugeren med at bevare overblikket. 

Opbygningen i templates for ER og Process Maps er ikke videre intuitiv. Ved at strukturere inputs i 

drop-down menuer o.lign. kan mulighederne anskueliggøres samtidig med at fejlmarginen reduceres. 

Applikationens GUI tilpasser sig omstændighederne for det pågældende arbejde og beder 

således kun om oplysninger som er relevante. Desuden er det meningen at samme oplysninger 

kan blive anvendt af applikationen til at genere flere forskellige outputs, såsom ER og Process 

Maps, så processen effektiviseres og man undgår dobbeltindtastninger. 

Figur 24 - Viser en brainstorm over processen.


20. december 

2011 

Applikationen er bygget op omkring en relationel database, som udvides efter behov. Da branchen 

befinder sig på vidt forskellige niveauer i forhold til implementering af BIM i virksomheden, 

forsøger vi ikke at låse os fast på BuildingSMARTs værktøjer, som det endegyldige svar. Derimod 

er applikationen bygget op omkring ideologien fra IDM, som anvendes på et generelt niveau. Vi 

har brugt iai.no’s arbejde med IDM. De har lavet skabeloner som vi har brugt som udgangspunkt 

over hvilke informationer vores applikation indeholder (se bilag 2). 

Forløbet fremgår af Figur 25. 

Figur 25 - Viser process flow. 

6.2.2 Opbygning 

Konceptet for vores applikation er udviklet gennem et usecase-diagram og et aktivitets-diagram, 

som viser funktionalitet og struktur i applikationen. Derudover indeholder løsningen en relationel 

databasestruktur lavet i Microsoft Access. Dette kan videreføres til et navigationsdiagram. 

I navigationsdiagrammet ses navigationsstrukturen, som er lavet for at give et overblik over brugerens 

mulige bevægerum i applikationen, altså de områder brugeren interagerer med. 

BPMN – Process Map 

En område som ikke beskrives med vores diagrammer, er ønsket om at implementerer en delvist 

autogenereret Process Map. Process Mapen skulle genereres ud fra de informationer som er indtastet 

i applikationen. Det er f.eks. informationer omkring udbudsform, tidspunkter og faser som 

påvirker hvor selve udvekslingskravene (ER) skal ligge, virksomhederne imellem. Det er så meningen 

at koordinatorfunktion skal tilpasse de autogenerede Process Maps, så de kan sendes ud til 

de pågældende virksomheder. Selve ideen bag denne funktion, har vi ikke fokuseret på i denne 

rapport. 

73

20. december 

2011 

74 


6.2.2.1 UML usecase-diagram 

Usecase-diagrammet illustrerer de oplysninger visuelt, som skal være tilgængelig for brugerne 

(supportaktør) og koordinatoren (primæraktør). Usecases beskriver funktionen der finder sted 

mellem aktørerne og applikationen. Relationerne mellem en given aktør og applikationen repræsenteres 

med streger. I figur 13 ser vi at koordinatoren har flere relationer end brugeren, såsom 

at varetage applikationernes fejlmeldinger og lign.. 

Diagram 13 - Viser Usecase-diagram 

Bruger og systemkoordinatorrollen 

Vi har valgt, iht. vores use-case, at have en koordinatorrolle som skal varetage brugerens adfærd i 

applikationen. Koordinatorens hovedopgave er at vedligeholde systemet og dets data, for at sikre 

konsistens og præcision. Koordinatoren vil også have den funktion, at tilpasse det autogenerede 

materiale som kan eksporteres, hvis applikationen ikke selv er i stand til at gøre det. Dette kunne 

f.eks. være et Process Map.


20. december 

2011 

6.2.2.2 UML aktivitets-diagram 

Aktivitets-diagrammet, viser brugerens vej og muligheder gennem systemet. Diagrammet består 

af startpunkt, aktiviteter, relationerne mellem disse og et slutpunkt. Gennem forløbet, bliver der 

sat parametre op for alternative veje. 

En bruger skal oprette et udvekslingskrav. 

Dette gøres ved at logge 

ind på den udviklede GUI. 

Virksomhedsdata indtastes (hvis 

de ikke allerede ligger i databasen). 

Brugeroplysninger indtastes. (hvis 

de ikke allerede ligger i databasen). 

Fase for informationsudveksling 

vælges. 

Proces tjekkes af koordinator og 

skabelon udvælges eller tilpasses. 

Informationskrav (udvekslingskrav) 

indtastes i GUI. 

Informationskrav (udvekslingskrav) 

gemmes. 

Alle informationer gemmes. 

Der uploades til server. 

Output type vælges. 

Diagram 14 - Viser Usecase-diagrammet 

75

20. december 

2011 

76 


6.2.3 Databasen 

Databasestrukturen er lavet på baggrund af førnævnte analyser, og viser hvordan vi har valgt at 

lagre informationerne i et projekt. Alle indtastede informationer overføres til databasen og er 

derfor omdrejningspunktet for vores applikation. Reglerne for udvekslingskrav (ER) i databasen, er 

opbygget på baggrund af IAI Norges ER. Kravene er dog ikke udelukkende hængt op på IFC. 

Figur 26 - Viser databaseopbygning til applikation.


20. december 

2011 

6.2.4 Navigationsdiagrammet 

På baggrund af vores tidligere analyser, har vi valgt at kortlægge vores applikation med en oversigt 

over brugerens berøringsflader. Vores navigationsdiagram viser de forskellige vinduer, hvori 

der ligger nogle muligheder for brugeren, for at kunne indtaste informationer. Et eksempel på 

dette kunne være i vinduet ”Bruger”. I dette vindue skal brugeren have mulighed for at indtaste 

fornavn, efternavn og vælge hvilken virksomhed han/hun tilhører. Udover det kan han/hun indtaste 

mobil og/eller telefonnummer samt mail. 

Alle områder er baseret på den databasestruktur som vi tidligere skabte med MS Access, hvori 

datastrukturen vises. Vi har ikke beskrevet skabelondelen, men den er ment som en del, hvori 

virksomhederne kan vælge en skabelon til udveksling af informationer, til en anden virksomhed. 

Et eksempel på dette kunne være, at en arkitektvirksomhed ofte arbejder sammen med en entreprenørvirksomhed 

som vil have sine informationer på en bestemt måde. Når der så vælges skabelon 

for et samarbejde mellem virksomhederne, er der på forhånd lavet nogle ”standard” udvekslingskrav. 

Men da to byggesager aldrig er ens, vil man blive nød til at ændre områder i skabelonen. 

Dette afhjælper og minimere gentagelser i arbejdsprocessen. 

Diagram 15 viser navigationsdiagram 

77

20. december 

2011 

78 


6.2.5 Grafisk brugerflade (GUI) 

Måden brugerne interagerer med brugerfladen, har stor betydning for at skabe det rette flow i 

hverdagen. I denne fase af udviklingen er der primært fokuseret på en enkelt og ukompliceret 

brugerflade. Des mere overskuelig en brugerflade er, jo lavere er læringskurven for brugeren. 

Brugeren vil også have lettere og større lyst til at bruge applikationen fremover. Til udarbejdelse 

af brugerfladen har vi benyttet Netbeans, som er et anerkendt softwareudviklingsprogram. 

Dialogboksen: Informationskrav 

Det nedenstående billede viser dialogboksen med informationskrav. Dette er en væsentlig dialogboks 

hvor man kan oprette og ændre i de informationskrav som fremsættes af brugeren. 

Titel 

I feltet Titel indtaster man informationskravets 

titel. 

Brugerflade 1 - viser GUI over informationskrav 

Format / Format version 

I feltet Format og format version 

definerer man det format 

som man vil have sit informationskrav 

i. 

Obligatorisk, Anbefalet og Valgfri 

Feltet angiver informationskravets 

vigtighed. 

Ansvarlig virksomhed / afsender og Informationskravsmodtager 

samt den ansvarshavende modtager er felter som viser afsender og 

modtager af informationskravet. 

Type af information 

Feltet fortæller om det er et bygherrekrav 

iht. placeringen eller lign. beskrivelse 

af information fortæller om 

selve informationen. 

Kalenderfunktioner 

Kalenderne angiver datoer for 

aflevering af informationen, og 

påmindelse. Det bliver der gjort 

opmærksom på via. sine afkrydsninger 

iht. Mail eller SMS notifikation.

6.2.6 Dialogboksen: Bruger 


20. december 

2011 

Dialogboksen ”Bruger” benyttes af alle (udvalgte) aktører på projektet og skal udfyldes for at tilgå 

applikationens øvrige funktioner. Brugerinterfacet er opbygget som følgende: 

Brugerflade 2 - viser GUI over bruger 

Bruger feltet 

Henvender sig til eksisterende brugere. Har 

man indtastet sine brugeroplysninger tidligere 

i forløbet, kan de findes under dropdown 

menuen. Hvorefter felterne udfyldes 

automatisk. 

Oplysningsfelterne 

Fornavn, Efternavn, mobilnummer, telefonnummer 

og mail skal manuelt udfyldes med 

persondata (medmindre dataene kan findes 

i førnævnte ”Bruger felt”) 

79

20. december 

2011 

80 


6.2.7 Dialogboksen: Informationskravsoversigt 

Dialogboksen ”Informationskravsoversigt” kan give en oversigt af projektets skabeloner, virksomheder, 

brugere, faser og sager. 

Brugerflade 3 - viser GUI over informationskravsoversigt 

Liste over informationskrav 

Via knappen tilgås en liste over projektets informationskrav. 

Indtast informationskrav 

Via knappen kan oprette nye informationskrav. Se GUI 

Informationskrav. 

Eksport 

Via knappen kan valgte informationer eksporteres 

Ny sag 

Via knappen kan man vælge at oprette en ny projektsag. 

Gem sag 

Via knappen kan man gemme sin projektsag. 

6.3 Sammenfatning 

Upload til server 

Via knappen kan man uploade til serveren. 

Vælg skabelon 

Eksisterende skabeloner findes i drop-down 

menuen. Valgte skabeloner kan tilgås via ”Rediger” 

knappen for tilføjelser / ændringer. 

Virksomheder 

Eksisterende virksomheder findes i drop-down 

menuen. Valgte virksomheder kan tilgås via 

”Rediger” knappen for tilføjelser / ændringer. 

Brugere 

Eksisterende brugere findes i drop-down menuen. 

Valgte brugere kan tilgås via ”Rediger” knappen 

for tilføjelser / ændringer. 

Faser 

Eksisterende faser findes i drop-down menuen. 

Valgte faser kan tilgås via ”Rediger” knappen for 

tilføjelser / ændringer. 

Sag 

Eksisterende sager findes i drop-down menuen. 

Valgte sager kan tilgås via ”Rediger” knappen for 

tilføjelser / ændringer. 

Brug af GUIer 

Disse prototyper af brugergrænsefladen, skal bruges som et redskab til tests og evaluering, til 

videre udvikling af programmet. Disse giver testpersonerne mulighed for at kunne interagere med 

programmet på en fiktiv måde, som kan give nyttig feedback til at forbedre programmet. 

Vi stopper udviklingen her, og lader det forblive en konceptuel model.

7 Konklusion 


20. december 

2011 

Resultatet af nutidens mange softwareværktøjer, formater, processer osv., samt det faktum at to 

projekter aldrig er ens, skaber kaos, forvirring og frustrationer i branchen, når informationer skal 

udveksles. Udviklingen af digitale værktøjer er gået hurtigt de seneste år og har måske overhalet 

mange virksomheder indenom. Mange virksomheder har i dag flere forskellige BIM-værktøjer i 

brug under et projektforløb, som ikke er kompatible på et tilfredsstillende niveau. 

”It-systemer, der ikke kan tale sammen, er årsag til fejl, forsinkelser og dobbeltarbejde 

for milliarder af kroner i byggebranchen hvert år” (Ingeniøren, 2008) 

Dette leder os hen til vores initierende problemstilling; ”Hvordan skaber man en optimal udvekslingsproces 

i et modelbaseret miljø?” 

Efter vores overbevisning er der to forskellige måder at anskue dette spørgsmål på. Den første 

tager udgangspunkt i verden som den ser ud i dag, herunder de teknologiske forhold, samarbejdsformer 

og ikke mindst motivation og handlekraft – eller mangel på samme. Det fulde udbytte ved 

implementering af BIM opnås først når alle parter er involveret på samme høje niveau, og så længe 

der ikke findes en åbenlys gevinst for hver enkelt part, vil det være svært at gennemføre. 

Gennem interviews med diverse interessenter, samt praktiske erfaringer opnået i gruppen, er det 

blevet tydeliggjort hvordan udvekslinger i IFC formatet mellem BIM applikationer, ofte medfører 

fejl og geometriske unøjagtigheder. Netop forholdet at kunne stole fuldt ud på datamodellen er af 

afgørende betydning for en gnidningsfri udveksling og i den forbindelse ligger problemet hos 

softwarebranchen. 

Den anden anskuelse er, at der faktisk findes nogle værktøjer, som tillader parterne at planlægge 

og kommunikere sig til et bedre udgangspunkt for udveksling af information. Her tænkes først og 

fremmest på BuildingSMARTs IFD og IDM metoder. IFC formatet og de tilhørende værtøjer fra 

BuildingSMART er måske ikke den optimale løsning i alle situationer, men vi ser kvaliteter i hver 

enkelt del, og mener derfor også at der kan være gevinster i bare at anvende dele af værktøjerne, 

og dermed starte en gradvis implementering af ideologien bag BuildingSMART. 

For at illustrere mulighederne i disse værktøjer, har vi udviklet en konceptuel applikation som 

tager det bedste fra IDM og udvider værktøjerne til en generel anvendelse, som samtidig ikke er 

låst til IFC formatet. 

81

20. december 

2011 

8 Perspektivering 

82 


Kortsigtet (1-5 år) 

På kort sigt vurderer vi, at man vil løse kompatibilitetsproblemerne mellem applikationer gennem 

udvikling af API’er til udveksling af data. Autodesk har eksempelvis netop frigivet kildekoden til 

deres IFC-exporter, hvilket tillader tredjepartsudviklere at anvende koden i skræddersyede API’er 

til dataudveksling med et specifikt formål for øje. På den måde trækker man data ud efter samme 

princip som MVD, hvor kun informationer som er relevante i den pågældende udveksling berøres. 

Papirformatet som informationsudveksling er under alle omstændigheder på vej tilbage. I det hele 

taget er en statisk datarepræsentation ikke egnet til de store informationsmængder en bygningsmodel 

indeholder i dag. Et godt eksempel på det er Pihl & søns jernbane broprojekt i Göteborg, 

hvor de har eksporteret deres armering direkte fra programmet Tekla til stålproducenten. 

”Armeringen eksporteres dermed direkte til Celsa, som kan fordele informationer vedrørende armeringen 

til virksomhedens robotter, som så klipper og bukker armeringen. Den klassiske klippebukke 

er fortid, og armeringen produceres nu med millimeters nøjagtighed.” 

(http://www.byggeteknik.dk/artikel?id=66412) 

Langsigtet (5+ år) 

På lang sigt forudser vi en markant større udbredelse af IFC som bærende informationsudvekslingsformat, 

sammen med resten af værktøjerne fra BuildingSMART. Håndtering af IFC imellem 

applikationer kan nemt blive en større konkurrenceparameter i fremtiden, og dermed tvinge 

softwareleverandørerne til at udvise større engagement overfor udnyttelsen af IFC som fælles 

standard. Den konstante eskalering i udviklingen af ny teknologi giver desuden anledning til nye 

og mere dynamiske samarbejdsformer, hvor adgangen til informationer tillader et tættere samarbejde 

mellem sagens parter. 

Udvekslingen af tegninger og data sker i dag ofte gennem projektweb eller andre serverløsninger. 

Fordelene ved altid at have opdaterede informationer vil sandsynligvis blive mere udnyttet i fremtidens 

BIM applikationer, hvilket også udnyttes bedre i mere dynamiske samarbejdsformer. 

På byggepladsen skal de udførende desuden vende sig til at anvende informationerne i bygningsmodellen 

på en helt ny måde, som bl.a. inkluderer 3d visualisering samt sporing af byggematerialer 

og materiel. I den optimale proces, vil der også være feedback til modellen fra de udførende 

på pladsen. Modellen vil altså i endnu højere grad være centrum for kommunikationen mellem 

sagens parter.

9 Kildeliste 

Internet kilder: 

www.niras.dk 

Hentet den 3. Oktober 2011 


20. december 

2011 

http://buildingsmart-tech.org/specifications/IFC-view-definition/coordination-view-v2.0/summary 

Hentet den 6. November 2011 

http://www.friis-moltke.dk/siteFM/projectdetail.asp?x=&detail=2540 


http://www.taxon.dk/artikler/taxonomi.htm 

Hentet den 15. november 2011 

http://www.blis-project.org/IAI-MVD 


http://buildingsmart-tech.org/specifications/ifc-view-definition/summary 


http://buildingsmart.com/standards/mvd/mvd-process 


http://www.openifctools.org 


http://en.wikipedia.org/wiki/Entity-relationship_model 


http://www.bpmn.org/ 


http://www.bs.dk/publikationer/rapporter/webservice/html/chapter04.htm 


http://da.wikipedia.org/wiki/Serviceorienteret_arkitektur 


http://en.wikipedia.org/wiki/Business_Process_Model_and_Notation 


http://en.wikipedia.org/wiki/Business_Process_Execution_Language 


http://www.version2.dk/leksikon/BPMN 


http://www.kim-andersen.dk/database normalisering/normalisering database sql foerste normalform.htm 


http://jesarbov.dk/mdu/semester3_09k/iau3_lekt02.html 

Hentede 26. oktober 2011 

www.asciitable.com 

Hentet den. 26. oktober 2011 

http://dev.ifd-library.org/images/2/23/IfcIfd1.png 


http://dev.ifd-library.org/index.php/Ifd:IFD_for_Innovative_Sustainable_Housing 


http://bips.dk/v%C3%A6rkt%C3%B8jsemne/buildingsmart-proces-idm 

Hentet den 24. oktober 2011 

83

20. december 

2011 

84 


http://catenda.no/index.php/2010/09/13/what-on-earth-is-ifd/ 


http://buildingsmart-tech.org/specifications/ifc-overview 


http://www.buildingsmart.no/article126.html 


http://buildingsmart-tech.org/specifications/ifc-releases/ifc2x4-release 


http://www.cowi.dk/MENU/SERVICE/BYGGERI/BYGNINGSPROJEKTERING/BIM/Pages/BIMbygningsinformationsmodellering.aspx 


http://www.detdigitalebyggeri.dk/sites/default/files/attachments/Musikkens_hus_Informationsfolder.p 

df 


http://projects.buildingsmartalliance.org/files/?artifact 


http://www.grontmij.dk/dk/ydelser/byggeri/design/bygnings%20informations%20Modellering/Pages/B 

ygningsInformationsModellering.aspx 


http://dtu20.be/ERdiagram.pdf 


http://staff.iha.dk/foh/Foredrag/UML-Light-slides.pdf 


http://docs.kde.org/ 


http://da.wikipedia.org/wiki/UML 

Hentet den 14. november 2011 fra 

http://docs.kde.org/stable/da/kdesdk/umbrello/uml-basics.html 


http://office.microsoft.com/da-dk/visio-help/om-express-g-diagrammer-pa-enheds-og-skemaniveau- 

HP089600001.aspx?CTT=1 


http://www.omg.org/gettingstarted/what_is_uml.htm#12DiagramTypes 


http://www.oreas.com/shared_img/example_big_tree.gif 


http://www.emu.dk/gym/fag/dl/inspiration/temaer.html 


http://laerer.rhs.dk/psl/rhs/HHX.../Del%204%20-%20ER-diagrammer.ppt 


http://ing.dk/artikel/84747-byggeriet-spilder-milliarder-paa-elendig-udveksling-af-data 


http://ing.dk/artikel/84748-it-standard-til-byggeriet-skal-vaere-tvang 


http://standards.eu-innova.org/Files/Report/STAND- 

INN_D15_IFC_and_IFD_feasibility_for_innovative_sustainable_housing.pdf 

Hentet den 04. november 2011


http://www.aecbytes.com/feature/2004/IFCmodel.html 


http://www.ebst.dk/file/96241/Plan_for_videreudvikling_af_DBK_fra_DiKon.pdf 


http://buildingsmart-tech.org/about-us/msg 


http://www.musikkenshus.dk/Pages/default.aspx 


www.niras.dk/Forretningsomraader/Byggeri/buildingSMART.aspx 


http://ing.dk/artikel/113967-et-vaerktoej-er-ikke-nok-til-at-bygge-med 


20. december 

2011 

http://cuneco.dk/nyhed/danmark-i-spidsen-revision-af-international-standard-byggeklassifikation-0 


http://statsbygg.no/FoUprosjekter/BIM-Bygningsinformasjonsmodell/BIM-En-kortfattetinnforing/Forretningsprosesser/ 


http://en.wikipedia.org/wiki/Industry_Foundation_Classes 


www.idef.com 


Bøger, rapporter og tidsskrifter 

Bips. 2005, Bips nyt. 

Bips. 2004, 3 / 2004. Bips nyt, 15-16. 

2007, National Builing Information Modeling Standard. National Institute of Building Science. 

Chen, P. P.-S. 1976, The Entity-Relationship Model - Toward a Unified View of Data. Massachusetts 

Institute of Technology: ACM Transactions on Database Systems. Vol. 1,No. I,. 

Grant, R., & Mehus, J. 2009, IFD Library Business Plan - Version 1.0. 

Hansen, F. O. 2005, Systematisk programudvikling med UML. Systematisk programudvikling med UML. 

2010, Udviklingsplan for Dansk Bygge. Digital konvergens. 

Rasmussen, A. 1996, Introduktion til IDEF0. Institut for Anvendt Konstruktion og Produktion. 

Chuck Eastman. 2011, BIM Handbook 

85

20. december 

2011 

86 


9.1 Billedhenvisninger 

Billeder Kilde: 

Billede 1: http://www.coop-himmelblau.at/ 

Billede 2: http://www.nordjyske.dk/erhverv/forside.aspx?ctrl=10&data=4%2C3606284%2C2805%2C3 

Figure: Kilde: 

Figur 1: http://www.topboxdesign.com/tag/fonden-musikkens-hus/7 

Figur 2: http://en.wikipedia.org/wiki/Business_Process_Model_and_Notation 




Figur 6: Egen 

Figur 7: www.webs.twsu.edu/enteng/papers/howidef0.pdf 

Figur 8: http://www.slideshare.net/koolkampus/ch02 

Figur 9: http://www.aecbytes.com/feature/2004/IFC-images/fig2.html 

Figur 10: http://www.aecbytes.com/feature/2004/IFCmodel.html 

Figur 11: ISO29481-1, 2010 

Figur 12: ISO29481-1, 2010 

Figur 13: ttp://www.iai.no/idm/idm_resources/idm_methods_guides/IDM2_Methodology_2007102 

2.pdf 

Figur 14: ttp://www.iai.no/idm/idm_resources/idm_methods_guides/IDM2_Methodology_2007102 


Figur 15: http://it.civil.aau.dk/it/education/reports/building_smart/WS6_IDM_FunctionalParts.pdf 

.pdf 

Figur 16: http://ontolog.cim3.net/cgi-bin/wiki.pl?FloorplanMarkupLanguage 

Figur 17: http://buildingsmart.com/standards/mvd/mvd-process 

Figur 18: http://www.buildingsmart.no/international 

Figur 19: http://dev.ifd-library.org/index.php/Ifd:IFD_in_a_Nutshell 

Figur 20: http://www.google.dk/url?sa=t&rct=j&q=roger%20grant%20ifd&source=web&cd=1&ved=0 

CCkQFjAA&url=http%3A%2F%2Fprojects.buildingsmartalliance.org%2Ffiles%2F%3Fartifact_i 

d%3D1537&ei=fxrqTrT_L4r44QSamOnjCA&usg=AFQjCNEdzXynrcf310OD- 

0Z3dlxiS5netw&cad=rja 

Figur 21: http://www.google.dk/url?sa=t&rct=j&q=roger%20grant%20ifd&source=web&cd=1&ved=0 

CCkQFjAA&url=http%3A%2F%2Fprojects.buildingsmartalliance.org%2Ffiles%2F%3Fartifact_i 

d%3D1537&ei=fxrqTrT_L4r44QSamOnjCA&usg=AFQjCNEdzXynrcf310OD- 

0Z3dlxiS5netw&cad=rja 

Figur 22: Egen 




Figur 26: Egen (databaseopbygning) 

Diagram: Kilde: 

Diagram 1: Egen 

Diagram 2: Egen


20. december 

2011 

Diagram 3: Egen (E-Draw) 

Diagram 4: www.webs.twsu.edu/enteng/papers/howidef0.pdf 

Diagram 5: Egen kilde (E-Draw) 

Diagram 6: http://www.jot.fm/issues/issue_2004_01/article3/images/fig2.gif 

Diagram 7: http://explainextended.com/2009/10/18/what-is-entity-relationship-model/ 

Diagram 8: http://buildingsmart-tech.org/certification/IFC-certification-2.0/IFC2x3-cv-v2.0- 

certification/bSI_IFC_Certification_2-0_Workflow.png/view 




Diagram 12: http://www.iai.no/idm/idm_resources/idm_methods_guides/IDM2_Methodology_200710 




Diagram 15: Egen (Navigationsdiagram) 

Model: Kilde: 

Model 1: http://buildingsmart-tech.org/specifications/IFC-view-definition/coordination-view- 

v2.0/summary 

Model 2: Bimbyen 

Model 3: Bimbyen 

Tabel: Kilde: 

Tabel 1: http://www.blis-project.org/IAI-MVD/IDM/GSA-002/ER_GSA-002.pdf 

Tabel 2: http://www.blis-project.org/IAI-MVD/IDM/GSA-002/ER_GSA-002.pdf 

Tabel 3: 

http://idm.buildingsmart.no/confluence/display/IDM/Configure+Load+Bearing+System+%2 

8FP%29 

Tabel 4: 

http://idm.buildingsmart.no/confluence/display/IDM/Configure+Load+Bearing+System+%2 

8FP%29 

Tabel 5: http://idm.buildingsmart.no/confluence/display/IDM/Configure+Load+Bearing+System+%2 

8FP%29 

Tabel 6: egen 

Uddrag: Kilde: 

Uddrag 1: http://www.blis-project.org/IAI-MVD/IDM/GSA-002/ER_GSA-002.pdf 

Uddrag 2: http://idm.buildingsmart.no/confluence/display/IDM/Configure+Load+Bearing+System+%2 

8FP%29 

Uddrag 3: http://idm.buildingsmart.no/confluence/display/IDM/Configure+Load+Bearing+System+%2 

8FP%29 

Uddrag 4 http://buildingsmart-tech.org/specifications/ifc-view-definition/summary 

Skemaer: Kilde: 

Skema 1: http://idm.buildingsmart.no/confluence/display/IDM/Configure+Load+Bearing+System+%2 

8FP%29 

87

20. december 

2011 

88 


Skemaer: Kilde: 

Brugerflade 1: Egen (GUI over informationskrav) 

Brugerflade 2: Egen (GUI over bruger) 

Brugerflade 3: Egen (GUI over informationskravsoversigt)

10 Ordforklaring 


ORD FORKLARING 

Application Programming 

Interface (API) 

Softwaregrænseflade der tillader et stykke software at interagere 

med andet software. 

BLIS Building Lifecycle Interoperable Software 

BPEL SE AFSNIT 3.1.1 

BPMI Business Process Management Initiative, er en gruppe som 

varetager udviklingen og arbejdet med BPMN, blandt andet. 

BPML Business Process Markup Language, noterings sprog. 

C++ Programmeringssprog 

E-R Entity-Relationship 

Entity / Entitet Dataset som indeholder attributter 

ER Exchange Requirements 

EXPRESS Programmeringssprog 

Facility Management (FM) Drift og vedligehold 

Functional Parts SE AFSNIT 2.4.2 

IAI International Alliance of Interoperability 

IDM Information Delivery Manual 

IFC Model Specification 

IFC Binding IFC Binding indeholder ”agreements” for individuelle ”functional 

parts”/”concepts” 

IFC integration Når et program indeholder IFC eksport/import 

IFD International Framework for Dictionaries 

Koncepter (IFC) SE AFSNIT 3.2.2 

Metasprog Det underliggende sprog eller symboler som bruges til at beskrive 

et andet sprog 

Multiparadigmatisk programmeringssprog 

Process Maps SE AFSNIT 3.2.3.1 

ProIT 

20. december 

2011 

Renundant data Samme data optræder mere end et sted I en database eller I et 

dataset 

89

20. december 

2011 

90 


Schema/skema Informationshåndtering i computersprog? 

STEP ISO 10303 standard. Datasprog til repræsentation og udvekling 

af produktinformationer. 

WSBPEL SE AFSNIT 3.1.1 

Interoperabilitet Forskelligartede systemer eller organisationer er i stand til at 

arbejde sammen. (inter-operere) 

Inheritance Hierarchy Entiteter arver proporties fra entiteter højere i hierarkiet. 

Super Types Entiteter arver proporties fra entiteter højere i hierarkiet. 

DWG Binært filformat brugt af udviklet af Auto 

Ontologi ”En ontologi er en netbaseret og formaliseret beskrivelse af et 

emneområde. Den formelle beskrivelse gør, at computere kan 

håndtere betydningen af ord, og netværket af ord afgrænser 

ordenes betydningen bedre end almindelige ordbøger. Konkret 

er en ontologi et dokument eller fil der formelt definerer 

sammenhængene mellem ord” 

(http://buildingsmart.com/standards/mvd/mvd-process, 2011) 

WDSL ”WSDL står for Web Service Definition Language. Det er et 

XML-dokument, der beskriver en webtjeneste i detaljer. I 

WSDLen til en webtjeneste kan man se webtjenestens URL - 

den adresse, hvor webtjenesten udbydes, hvilke metoder 

webtjenesten stiller til rådighed, hvilke parametre, somwebtjenestens 

metoder tager i en forespørgsel og hvilke parametre 

webtjeneste svarer tilbage med på en forespørgsel” 

DBK ”DBK:2007 er en forkortelse for Dansk Bygge Klassifikation, og 

er frigivet den 1. januar 2007 som en del af Det Digitale Byggeri. 

Formålet med DBK er at bl.a. at skabe entydige koder der 

kan anvendes gennem hele byggeriets livscyklus. De entydige 

koder binder byggeriet sammen og medvirker til et fælles 

sprog mellem de forskellige parter i byggeriet”. 

Taxonomi ”En taxonomi er et system, som grupperer emner i en struktur. 

En taxonomi består som oftest af et hierarki af klasser, hvor 

hver klasse har én forælder” 

(http://www.taxon.dk/artikler/taxdef.htm) 

De-facto standard En alment anerkendt fremgangsmåde eller specifikation, der i 

kraft af sin udbredelse eller dominerende markedsposition har 

opnået branchestandard

Bilag 1: Kontrol beregninger. 


Væg: 

Væg 1-3: 

Volumen: ( 15 m x 3 m x 0,3 m = 13,5 m3 ) x 2 = 27 m3 

Overflade: ( 15 m x 3 m = 45 m2 ) x 2 = 90 m2 

Væg 2-4: 

Volumen: ( (10 m-(0,3m -0,3m) x 3 m x 0,3 m = 8,46 m3 ) x 2 = 16,92 m3 

Overflade: ( 10 m x 3 m = 30 m2 ) x 2 = 60 m2 

Vindueshul: 1,01 m2 

Dørhul: 1,93 m2 

Samlet hulstørrelse areal: 2,94 

2,94 x 0,3 = 0,882 

Samlet hulstørrelse volumen: 0,882 

Samlet: 

Volumen: 43,92 m3 – 0,882 = 43,038 

Overflade: 150 m2 – 2,94 = 147,06 

Vindue: 

Areal: 1,112m x 0,912 = 1,01 m2 

Dør: 

Areal: 2,112m x 0,912 = 1,93 m2 

Cirkulær søjle: 

Skin area: 

A = 2 x π x r x h 

A = 2 x π x 0,150 x 3 = 2,83 m2 

Volume: 

V = π·r² x h 

V = π·0,150² x 3 = 0,21 m3 

Filerne brugt til dette forsøg er vedhæftet denne rapport. 

20. december 

2011 

91

20. december 

2011 

92 


Bilag 2: Program, Exchange Requirement 

NAME EXCHANGE STRUCTURAL DESIGN (OUTLINE CONCEPTUAL) 

IDENTIFIER 

CHANGE LOG 

CREATED JENSHANSEN@MEGAJERN.DK 

PROJECT STAGE 0 PORTFOLIO REQUIREMENTS 

1 CONCEPTION OF NEED 

2 OUTLINE FEASIBILITY 

3 SUBSTANTIVE FEASIBILITY 

4 OUTLINE CONCEPTUAL DESIGN 

5 FULL CONCEPTUAL DESIGN 

6 COORDINATED DESIGN AND PROCUREMENT 

7 PRODUCTION INFORMATION 

8 CONSTRUCTION 

9 OPERATION AND MAINTENANCE 

10 DISPOSAL 

AN EXCHANGE REQUIREMENT REPRESENTS THE CONNECTION BETWEEN PROCESS AND DATA. IT APPLIES THE 

RELEVANT INFORMATION DEFINED WITHIN AN INFORMATION MODEL TO FULFIL THE REQUIREMENTS OF AN 

INFORMATION EXCHANGE BETWEEN TWO BUSINESS PROCESSES AT A particular stage of the project. 

An exchange requirement describes a set of information from a process that has been performed 

by an actor to enable a downstream process to be performed by another actor. 

With reference to the Process Map, an exchange requirement is the set of information associated 

with a data flow arrow on the BPMN diagram. Thus, ERs are identified from the inputs and outputs 

of the Process Map. 

Processes 

2.1.1 Consider Client’s Requirements & Restrictions 

2.1.2 Consider Site Conditions and Constraints 

2.1.3 Develop Forms of Construction 

2.1.4 Review Construction Solutions 

2.1.5 Finalize Concept Design 

Results 

Model: Outline Structural Design

Information Requirements 

Type of Information 

Precursor 

Structural Specifications 

Outline Structural Design 

Client’s Requirements 

(Outline) 


20. december 

2011 

Information Needed MAN REC OPT Actor Supplying Format 

The provisions of the exchange requirements which includes 

appropriates extracts from and references to: 

Statutory Regulations 

Codes 

Standards 

Technical Specifications 

Client Brief 

A formalized set of descriptions forming part of the project 

brief, which specify the requirements and restrictions arising 

from the client. Based on an extended version of the 

client’s brief, this information will have taken into consideration 

(from a structural engineering point of view) the 

implications of: 

Overall Layout 

Building Size & Height Limits 

Floor to Floor Dimensions 

Column Spacing 

Construction Speed 

The clients requirements and restrictions will have an impact 

on the choice of: 

foundations, 

structural form, 

stability provision, 

√ External Bodies 

Planners 

Client 

√ Structural Designer 

93

20. december 

2011 


Site Constraints 

(Outline) 

Construction 

Solutions (Outline) 

Preliminary Concept 

Design 

94 



materials 

A formalized set of descriptions forming part of the project 

brief, which specify the condition and constraints arising 

from the site. This information will have taken into consideration 

(from a structural engineering point of view) the 

implications of: 

Ground Conditions 

Ground Water 

Location 

Site Access 

Adjacent Structures 

Environmental Conditions (such as wind, snow and ice) 

A draft set of informal descriptions and specifications of a 

planned building (or building complex) and its structure. In 

the form of graphical and text information, it serves as the 

basis of a preliminary concept design and describes: 

Structural Form 

Stability Provision 

Material 

Member sizes 

A draft set of informal descriptions and specifications of a 

planned building (or building complex) and its structure. In 

the form of graphical and text information, it serves as the 

basis of a final outline concept (sketch) design. This information 

will have taken into consideration (from a structural 



√ Structural Designer


Results 

Result type 

(FP/ ER/ Document/ 

PSet/ Specification etc.) 


20. december 

2011 


engineering point of view) the appraisal of the: 

Stability provision 

Ease, speed, and cost of construction 

Structural performance 

functional performance 

In service performance 

Aesthetic impact 

Information Provided 

Model Outline Structural Design √ Geotechnical Engineer 

MAN 

OPT 

Actor Receiving Result Identifier 

Structural Engineer 

Mechanical Engineer 

Electrical Engineer 

Communications Engineer 

Architect 

95

Klik her for at hente i pdf. - BygningsInformatiker.dk

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?